Eclipse 3.6 에서 Subversive Team Provider 플러그인을 설치하고, Update / Commit / Synchronize 단축키를 쓰려 해도 동작하지 않는다. 기본적으로 비활성화되어 있기 때문인데, Window –> Customize Perspective –> Command Groups Availability 에서 활성화시켜 줄 수 있다.
위 창에서 Available command groups 에서 체크해주면 활성화가 되는데, 이 작업만 해줄 경우 툴바에도 단축 아이콘들이 나타난다.
툴바에서 보고 싶지 않다면, Tool Bar Visibility 탭에서 체크를 빼주면, 단축키만 동작하고 툴바에서는 보이지 않는다.
평소 BC로 결제하려면 으레 보게 되는 요 창도 맘에 안들었는데,
이젠 넷피아까지 설치하려 든다. (분명히 Ctrl + PrtSc 를 눌러서 캡처를 뜬 거 같은데 클립보드에 저장되지 않아서 설치 팝업 이미지는 여기를 참고… )
그래서 기껏 ActiveX 범벅을 설치해가며 결제 마지막 단계에까지 도달한 수고에도 불구하고, 망설임 없이 결제를 취소한 뒤 비자 안심클릭으로 다시 결제했다. 넷피아 참 질기다. (그리고 나도 참 까칠하다.)
이런 광고 참 성가시다. 컨텐츠 위로 마우스만 지나가려 치면 불쑥 불쑥 나타나서 사라지지도 않는 저 DirectKeyword 검색을 비롯해서, 화면 조금만 멈출 성 싶으면 불쑥 튀어나오고, 심지어는 스크롤 시에 종종 사라지지도 않는 RealClick 등등... 스마트폰에서는 훨씬 더 심각하다. 닫기 버튼을 누르기도 쉽지가 않다.
그래서 만들었다. 컨텐츠내 광고 제거 북마클릿.
사용법은 다른 북마클릿이랑 크게 다르지 않다. 북마클릿을 즐겨찾기에 저장해 뒀다가, 필요할 때 즐겨찾기에서 찾아 실행해주면 된다. hosts를 차단하거나, 브라우저 확장 기능을 만드는 등의 과격한(?) 대응도 가능하지만, 뭐 그렇게까지 씩이나... 게다가 스마트폰에서도 쓰고 싶었다는 게 가장 큰 이유... (였는데 어째서인지 아이폰에서 잘 동작 안한다. 뭐가 문젤까. -ㅂ-; )
적용한 결과
아, 깨끗하고 알흠답다.
덧. 차단하는 광고 종류가 추가되어도, 북마클릿을 새로 생성할 필요는 없음. 클릭 시마다 최신 스크립트를 가져옴.
메일서버가 하는 일을 나누자면 크게 3가지가 있다. 메일 접수, 메일 발송, 메일 수신. (RFC 명세상의 용어는 MSA, 즉 Message Submission Agent 이다. 하지만 '제출'은 받는 입장이고, '접수'는 하는 입장이라 메일서버를 주어로 했을 때는 '접수'가 더 어울리는 듯하여 접수라고 썼다.)
Outlook 등을 통해서 메일 서버에 접속하여 메일 발송을 의뢰하면, 메일 서버는 이 메일을 수신자의 메일 서버로 발송한다. 그리고 타인이 해당 메일서버의 사용자에게 보낸 메일을 수신해준다. 뿐만 아니라, 제3자의 메일을 중계해 주기도 한다. 이를 Relay라고 한다.
초창기 인터넷은 학교나 연구소 등지에서만 사용 가능했기 때문에, 당연히 스팸메일 같은 것을 고려할 필요는 없었고, 이에 따라 메일 서버는 SMTP (RFC 821) 프로토콜에 따라 '누구에게서 받았건 상관하지 않고 적합한 메일서버로 전달해주는' 형태로 구성되어 있었다. 그러나 인터넷이 널리 보급되면서, 스팸메일이 점점 늘어났는데, Relay가 열려있는 메일 서버를 사용하여 스팸메일을 발송하는 일이 빈번하게 발생하였다. 이때문에 Extemded SMTP (RFC 1869) 라는 확장 규격이 제정되면서, SMTH AUTH (RFC 4954)라는 인증 규격을 새로 정의하게 된다. 그리고 이 기능은 꾸준히 보급되어 1998년에 55%의 메일 서버가 Relay를 허용했던 것에서, 2002년에는 1% 미만으로 감소하였다.
SMTP AUTH를 도입한 메일 서버는, 접속자가 자신에게 등록된 사용자인지를 확인하는 인증을 거치면 자신을 발송 서버로 사용할 수 있게 해주지만, 인증을 거치지 않으면 메일 서버의 로컬 사용자에게만 메일을 보낼 수 있고, 제3의 목적지로는 보낼 수 없다.
그러자 스패머들은 마침 급속히 보급되던 초고속 인터넷망을 십분 활용하여, 개인 PC를 메일 서버로 만들어 메일을 직접 발송하였다. 개인 PC를 메일 서버로 구성하여, 수신자의 메일 서버에 직접 접근하여 스팸을 남기기 시작한 것이다. 뿐만 아니라, 일반 사용자의 PC를 감염시켜 사용자도 모르는 사이에 PC를 스팸 발송용 메일 서버로 만들어 버리는 사례도 빈발하였다. 이렇게 발송되는 스팸메일을 필터링하기 위해 각국 ISP 및 메일 업체들은 다방면으로 노력을 해왔다. 그중 몇 가지 시도가, 메일 발송 블랙리스트를 만들고 관리하는 RBL 이라던가, 자신의 메일서버를 인증시키는 SPF (RFC 4408, Experimental) 나 DKIM (RFC 4871, Proposed Standard) 같은 방법들이 강구되어 왔다.
그러나 이러한 방법들은 발신자가 스패머라는 것을 확증하도록 할 수 있는 방법은 아니었다. 오래 전에 셋업된 후 업그레이드 되지 않은 메일 서버들은 정상 서버임에도 불구하고 SPF나 DKIM 설정 등이 없기 때문이기도 하고, IP 대역의 사용처가 바뀌거나 했을 경우 RBL은 종종 멀쩡한 IP를 블랙리스트로 지정하곤 했기 때문이었다. 이러한 방법들은 단지 해당 메일이 얼마나 스팸에 가까울지를 판별하는 스팸 점수 산정에 참고가 될 뿐이었다.
그래서 메일 서버의 기능을 분리하고자 하는 시도가 RFC 2476, Message Submission이라는 형태로 정리되었다. 이 명세는 사용자의 메일 클라이언트 (MUA: Message User Agent - Outlook, Firebird와 같은)로부터 메일 발송 요청을 접수하는 (MSA:Mail Submission Agent)기능과 메일을 수신자의 서버로 전달하는 (MTA: Mail Transfer Agent) 기능을 분리하기기 위한 명세를 정의하였다. 그리고 MSA에 접속한 사용자는 인증이 없이는 어떤 일도 할 수 없도록 설정하는 것을 권장하였다.
시간 상으로는 RFC 2476이 정의된 것이 SPF(2006), DKIM(2007) 보다 훨씬 이전이다. 다만, 사용자의 설정을 바꿔야 하는 부담과, 한 사업자만 이 규칙을 적용해봤자 거의 쓸모가 없다는 이유로 적용되지 않았다. 그러다가 JEAG (Japan Email Abuse Group) 에서 2006년에 이 Message Submission 적용을 권장하고, 각 ISP에게 유동 IP로부터는 25번 포트 접속을 할 수 없도록 차단하도록 요청하는 한편. 이를 OP25B (Outbound Port 25 Block) 라고 명명하였다. 대략적인 구조는 다음과 같다.
이와 같은 정책을 적용한 결과, 포트 차단을 시행한 ISP의 스팸 발송 비율은 급격히 감소하였다. (자료 출처 : 한국 인터넷 진흥원 )
반면, 이 정책을 적용하지 않은 ISP는 오히려 스팸 발송 비율이 급상승 하였다. 스패머들이 스팸 발송이 가능한 ISP로 옮겨갔기 때문으로 추정된다. 이는 최대한 많은 ISP가 이 정책 적용에 동참하여야 효율적으로 스팸 발송을 차단할 수 있음을 의미한다. 이에 따라 한국 인터넷 진흥원에서도 유동 IP 대역에서의 25번 포트 접속 제한을 2010말에 시행하도록 권고하고 있다.
http://www.block25.or.kr/ 홈페이지에서 메일서버별 설정 방법 등이 제공되므로, 자세한 내용은 이를 참고하여도 좋다.
11.8.6 The instanceof operator
The production RelationalExpression: RelationalExpression instanceof ShiftExpression is evaluated as follows:
15.3.5.3 [[HasInstance]] (V)
Assume F is a Function object.
When the [[HasInstance]] internal method of F is called with value V, the following steps are taken:
11.2.2 The new Operator
The production NewExpression : new NewExpression is evaluated as follows:
13.2.2 [[Construct]]
When the [[Construct]] internal method for a Function object F is called with a possibly empty list of arguments, the following steps are taken:
교훈: 삽질 하지 말고 명세 보자.
Manager - 직역하자면 '관리자'다. 코딩 하면서 이런 이름 붙은 클래스 한 번쯤 안 본 사람은 없으리라 생각된다. 하지만, 여기서 말하는 관리, 즉 Manage는 무엇일까? 근태관리? (응?)
Manager라는 이름은 정체를 너무 모호하게 정의했을 때 나오기 쉽다. 클래스가 제공하는 메서드들을 보면 그 클래스의 정체를 알 수 있는 경우도 있다. 그러나 유감스럽게도, 이런 이름을 가진 클래스들 중 관련 메서드를 응집성 있게 구성한 클래스는 거의 찾아볼 수 없다. '이것 저것 다 들어있는' 코드에 이름을 붙이기 어려우니 Manager락고 붙이는 경우가 대다수이다.
또, 이 Manager 가 다루어야 하는 대상 - 종종 도메인 객체 - 가 지나치게 빈약할(Anemic)때 이런 이름 패턴이 등장하기도 한다. 그나마 이 경우는 좀 낫다. 도메인 객체 안에 녹아 들어가 있어야 할 코드가 밖에 나와 있는 정도의 해악이기 때문이다. 그러나, 유감스럽게도 이 경우는 극히 드물며, 대다수는 개개의 도메인 객체 제어 + 집합적 제어 + 직/간접적 연관 관계를 한꺼번에 들고 있다.
Manager라는 이름을 금지(!) 하자고 하면 너무 극단적일지 모르겠는데, 금지에 가까운 강력한 정책이 필요할지도 모른다. 적지 않은 경우, Manager는 여러 개의 객체로 분리될 수 있으며, 각각은 좀 더 명확한 이름을 가질 수 있다. 또, Manager 코드의 상당수는 도메인 객체에게 돌려줘야 할 코드일지도 모른다.
ps. 금지해야 할 이름 몇 가지 더 모아보자면 뭐가 있을까? 라는 질문에 EP님은 Manager handler processor type dao bo action 를 추천해 주셨다. ㅋ
유시민은 내게 좋아할래야 좋아할 수는 없는 사람이다. 100년가는 풀뿌리 정당을 만들겠다고 시작한 개혁당을, 현실적 한계가 너무 분명하다며 그리도 쉬이 접어 버렸던 그 허탈함을 아직도 마음으로 용서하긴 어렵기 때문이다. 하지만 좋아하는 것과는 별개로 지지할만한 사람이다. 그가 보건복지부 장관 당시, 맞부딪혀야 할 수많은 난제들을 회피하지 않고 맞섰다는 점은 분명히 평가 받을 일이라고 생각한다.
다른 무엇보다, 나는 유시민이 이명박과 맞짱뜨는 것을 보고 싶다. 그는 후보 토론회에서 얘기했다. 자신이 경기도지사가 된다면 모든 법적 권한과 행정적 수단을 동원해서 4대강 사업을 막겠노라고. 중지시킬 강제권은 없겠지만, 수질 오염 측정이나 과적 단속 등을 말 그대로 '법대로' 하겠다고 했다.
이런 방법은 꽤 재미있는 전략이다. 거물과 싸우면 거물 취급을 받는다. 게다가 이 게임은 무리한 사업 추진과 공기 단축 시도, 무엇보다도근본적으로 환경에 대한 무지 때문에 이명박에게 매우 불리한 싸움이 될 수 밖에 없다. 필연적으로 흠잡힐 곳은 수두룩할 것이고, 이를잡아서 쟁점화 시키기만 하면 기본적으로 남는 장사가 되는, 이런 셈법은 흔치 않다. 게다가 이로 인해 정치적 탄압을 받을 경우, 박해받는 지사(志士)의 이미지까지 덤으로 얻을 수 있다. 노무현이 부산에서 얻었던, 그리고 그를 대통령의 자리에까지 올려놓았던 바로 그것 말이다.
만약 그가 도지사가 된다면 유일하게 주의해야 할 것은, 식물 도지사가 되지 않는 것이다. 그러나 결코 쉬운 과제는 아니다.
황우석 때와는 달리, 여전히 어느 쪽의 해석도 썩 명쾌하진 않다.
그 와중에 얻은 소득이라면, 구독하던 몇 몇 블로그 주인장들도, 딱 그들이 원하는 만큼만 이성과 합리성을 보인다는 아주 당연하면서도 평범한 사실이랄까.
역시 사람은 자신의 기존 견해를 강화하기 위해서는 얼마든지 정보를 선택적으로 취사한다. 남 욕할 것 까진 없고, 내가 그러진 않는지나 한 번 더 조심할 일이다.
그와는 별도로,
희생되신 모든 분들께 깊은 조의를.
Javascript에서 하나, 혹은 그 이상의 동일 타입 인자를 받는 메서드를 만든다면, 대략 두 가지 방식이 있다.
가령 <add() 메서드는 전달받은 인자를 내부 파라미터로 저장한다>고 하면, 외부 인터페이스는 보통 이렇게 만든다.
o.add(a)
여기서, 여러 개의 인자를 전달할 수 있도록 기능을 추가하려면,
o.add(a, b, c)
이런 방법도 있고,
o.add([a, b, c])
이런 방법도 있다. (물론 둘 다 지원하도록 하는 방법도 있지만, 오히려 지원하는 방법이 어떤 것이었는지 헷갈릴 수 있다.)
더 좋은 방법은? 보편적으로는 후자다. (동일 타입의 인자일 때만 그렇다) 해당 루틴을 사용하는 지점에서, 넘겨줄 변수의 개수가 몇개이든 고정적이라면, 괄호 하나쯤 더 타이핑 해주는 건 썩 귀찮은 일이 아닌 반면, 넘겨줄 변수가 가변적일 땐, 전자라면 apply 를 사용하여 호출하는 수밖에 없기 때문이다.
코드로 표현하자면,
var args = [a, b, c]
o.add([a, b, c])
가
var args = [a, b, c]
o.add.apply(o, args)
보다는 읽기 (쓰기도) 편하다는 얘기다. 단, 인자로 배열 형태를 받을 수 있는 경우에는 저렇게 쓰면 안된다.
굉장히 사소한 부분이긴 하지만, 의외로 전자의 형태로 구성된 곳들이 꽤 된다. 유명 라이브러리도 예외는 아니다.
Reverse DNS Lookup은 접속한 클라이언트의 IP를 바탕으로, 그 클라이언트의 hostname을 얻어내는 DNS 질의이다.
일반적인 서비스에서 리얼타임으로 이 Reverse DNS Lookup을 쓸 일은 많지 않다. IP로 로깅하고, 추후 분석 시 Reverse DNS Lookup을 실행하는 것이 더 일반적이다.
DNS 설정이 잘못되거나, 상위 Reverse DNS Resolver Server에 문제가 발생할 경우, 이 단계에서 시간을 소모하여 접속이 느려지는 상황이 발생할 수 있다. 다른 장애 조짐과는 달리, 최초 접속이 심각하게 느리고, 나머지 처리는 정상적인 속도를 보이는 특징이 있다.
MySQL
MySQL이 Reverse DNS Lookup 을 사용하는 상태에서, Reverse DNS Lookup 응답이 늦어지면, 다음과 같은 특징을 보인다.
원인은 connection을 받아들일 때 Reverse DNS Lookup을 수행하기 때문이며, 다음과 같이 해결 가능하다. ( 참고 )
[mysqld]
skip-name-resolve
Apache
Apache에서는 다음과 같은 사항을 검토한다. ( 참고 )
|
