Wordpress 2.3 Beta1 사용시작
어제 오후부터 Wordpress 2.3 Beta1으로 블로그 페이지가 개편된 상태.
사실 플러긴이나 페이지 출력, 기타 등등의 큰 변화는 없는 것 같고 - 그랬으면 메이저 버젼 넘버가 바뀌었겠지만 - 가장 많이 변화한 것으로 보이는 것은 크게 2가지.
우선 각 블로그 포스트에 태그를 달 수 있게 변경 되었음 (현재는 플러그인을 사용해서 태그/태그 클라우드를 찍어내고 있음). 그런데 태그 클라우드라거나 태깅 관련된 페이지/옵션이 없어서 좀 난감함 -_-;; 아마 이에 맞춰서 테마들도 다시 나와야할텐데 이것도 좀 골치아플지도?
두번째로 바뀐 부분은 에디터. 원래 wordpress 에디터가 크고 훌륭한데 - TinyMCE 라는 JavaScript/ajax 기반 에디터인데 별도의 설치(JVM이라거나 등등;; )없이 편안하게 쓸수 있는 WYSIWYG 에디터다 - 이번에(혹은 이전일지도 모르지만 인식못했으니) 어드밴스드 메뉴를 추가하면서 맘에 드는 기능이 하나 생겼다.
특수 문자 입력 메뉴가 생긴 것인데 덕분에 인용 기호로 자주 사용되는 † (dagger), ‡ (double dagger) 같은 문자를 편안하게 입력할 수 있게 되었다. 위 첨자; super script를 입력하는 방법을 모르는 관계로(…) 제대로 된 인용부호를 쓸 수 없었는데 - 사실 숫자 첨자는 예쁘지 않기도 하다
- †, ‡ 등등을 쓸 수 있게 되어서 맘에 들어하는중 (덤으로 λ, ζ, Θ, ø 같은 기호들도 입력하기 쉬워져서 좋음)
…라지만 SVN 업데이트 받아가면서 사용하는 중이라 이상한 점을 발견하면 - 페이지가 깨진다거나/코멘트가 안달린다거나/RSS가 이상한 반응을 보인다거나 - 사용 중인 웹 브라우져/OS/이상현상을 알려주세요 ![]()
소위 지적설계론에 대해
100% 사실? 글쎄 과연 _-_;; , 진화론 vs. 창조론 에서 트랙백
지구 상에 존재하는 생물체의 다양성을 설명하기 위해서 생물학에서 동원하는 이론은 “진화론”이다.
이 이론은 진화라는 자연계에서 관찰되는 현상†에 그 근거를 두고 있으며, 생물학의 수많은 부분을 통합하는 방법론으로도 사용되고 있다.
진화이론에서는 이런 진화로 인해 나타난 변형된 개체들이 더 잘 살아남을 수 있는가 - 정확히는 다음 세대에 더 많은 자신과 같은 유전정보를 지닌 개체를 퍼트릴 수 있는가; 즉, 자연선택 - 에 따라 더 많은 개체가 생겨나고, 이런 과정이 누적되면서 서로 생식할 수 없는 새로운 종이 탄생하게 된다는 내용을 담고 있다‡. 물론 이런 과정 자체가 지질학적인 시간 단위(100년 1000년하는 짧은 단위가 아닙니다)에서 일어나기 때문에 쉽사리 이해되지 않을 수도 있다. 그렇지만 생물학계에서 가장 많은 지지를 받고 있으며, 창조론자들의 비판용으로 사용되던 비어있던 고리들을 채워가는 과정에 있다.
반면에 지적설계론이란 것은 - 개인적으론 창조가설(이건 이론이라고 부를 이유를 아직 못찾으니 가설이라 부르겠다)의 화장한 얼굴이라고 생각하지만 - 어떤 지능을 가진 인격체(이게 신이 아니면 대체 뭐임)가 생물 개체의 변화/혹은 새로운 생물종의 생성을 진두지휘해서 현재의 생물학적 다양성이 존재한다는 내용이다 - 변형에 따라선 미시적인 수준의 진화론을 도입하기도 한다(…)
트랙백한 곳 중 한곳에서 언급한 “심판대의 다윈 - 지적 설계 논쟁 “라는 책을 찾다가 BRIC의 웹진 기사를 발견했는데, 사실 여러가지 면에서 충격적(?)인 배경을 가지고 있었다. 일단 저 지적 설계론을 주장하는 사람은 생물학자도 화학자도 아니고 “법학자”다(…). 뭐랄까 야구선수가 항공기 안전성을광고 하는 것만큼 신뢰도가 떨어지는 순간이었다(…)
미국 진화론논쟁의 최근 쟁점: 지적설계론 라는 2005년도 BRIC 웹진 기사였는데, 글 저자가 리뷰한걸 실어준걸 보면서 BRIC이 어쩌다 이렇게라는 생각을 좀 해주고(…) (리뷰어 리스트인 줄 알았는데 해당 글쓴이의 다른글 리스트 였음) 읽어보았다 - 저자이자 리뷰어인 박희주씨는 국내 창조론 지지자의 대부급이라 한다. 물론 저 내용에는 저명한 진화생물학자/지질학자인 하버드 대학교의 스테픈 제이 굴드 교수가 비판했다는 사실(…)을 언급해주긴하지만, 이미 케케묵은 - 그러니까 현재 해결되었거나 해결 중인 - 진화이론의 비어있는 고리들을 반복해서 말하고 있다. 그리고 그 대안으로 지적인 설계자의 개념을 언급하지만 일단 저 글에서는 그 지적 설계자가 어떻게 존재한다거나, 어떤 형태로 개입하는지에 대해서는 언급되어 있지 않다 - 한마디로 과학적인 서술과는 거리가 좀 -_- 있다. 그리고 저 글은 생명윤리 항목으로 분류되어있음에 유념해 주시기 바란다.
개인적으로 - 그리고 지금까지 받은 과학적 방법론의 도움으로 - 지적 설계론은 창조가설/종교적 근본주의자들의 마지막 발악이라고 생각한다. 진화이론에서 비어있는 고리라고 생각했던 몇몇 지점들 - 예를 들어 하나의 공통 조상에서 그렇게 많은 종의 생물들이 태어났다? -> 유전자적으로 보면 인간과 생선도 크게 차이나지 않는다(…) -은 이미 해결되어가고 있고, 이런 현상이 앞으로 축적되다보면 지적 설계자 혹은 인격신의 개념없이도 생물학적 다양성을 설명하는 진화이론은 더욱 완벽해져갈 것이라고 생각한다. (종교적으로 흔히 사용되는 믿는다는 표현을 피하려고 노력 중이다( –))
stvast 님의 도움으로 위에 링크한 BRIC웹진 기사에 대한 반박문을 얻었습니다. 보실 분은 지적 설계론 논쟁의 문제점을 따라가 주세요. 웹진 기사에서는 각 언론 보도 - 특히나 권위 있는 과학 저널들과 과학자들의 반응 - 를 많이 인용하고 있습니다.
시대를 앞서간 소수가 미친 놈 소리를 듣는다곤 하지만, 모든 미친 소리를 하는 사람들이 시대를 앞서가는 누군가는 아니라는 사실을 모두 주의 깊게 가지고 살아야겠습니다[..............]
*
† 자연계에서 관찰되는 현상의 예: 특정 박테리아 - 1개라도 좋고(…) - 를 배양액에 넣고 몇 일간며칠간(세포 분열이 빠른 경우라서 몇 달도 필요없다) 배양해보고, 이 들의 유전자를 분석해보면 상당한 수준의 유전적 다양성(DNA의 돌연변이들)을 획득하는 것을볼수 있습니다. 이런 유전자의 변이를 통해 실제 표현형 - DNA는 단백질을 생성하기 위한 정보 - 들이 변화를 일으키며 실제적인 각 개체가 서로 다른 형태/종을 이루게 된다는 현상.
내 프로그램의 병목은 어디에?
몇 분 전에 IRC에서 나눴던 대화,
[21:04:24] <rein> 지금 느끼고있는 세월의 흐름
[21:04:28] <rein> 씨디 립핑하는데
[21:04:31] <rein> IO가 병목이야
[21:04:31] <rein> …
[21:04:43] <ㅇㄹㅋ@A_i_e> 아
[21:04:45] <ㅇㄹㅋ@A_i_e> MP3립?
[21:04:46] <ㅇㄹㅋ@A_i_e> …
[21:04:53] <ㅇㄹㅋ@A_i_e> 압축도 어느새 IO 병목이 돼버렸지.
대략 내가 음악 CD를 MP3로 처음 떠 본게 대학교 1학년 (2001년) 때의 일일 것 같은데 그 때만 해도 wave 데이터를 mp3 데이터로 바꾸는데 병목현상을 일으키는 것은 인코딩하는데 걸리는 시간 이었다.
(대충 10분 길이의 음악 하나를 바꾸는데 6분에서 15분 정도가 걸렸던 것 같다)
책장에 꽂혀있던 좀 된 음악씨디들을 꺼내서 iTunes에서 적당히 MP3로 바꾸는데 뭐랄까 IO속도를 풀로 쓰더라(….)
아마 52배속까지 지원되는 ODD일텐데 - DVD RW라 정확한 CD롬 속도를 모르겠음 - 43.x 배속까지 올라가는걸로봐선 IO를 풀로 하고 있다고 밖엔. 실제로는 저 시점에서한 트랙 립뜨는게 종료가 되니 실제 속도는 저보다 잘 나오겠지.
만약 최적성능의 씨디 리핑 프로그램을 만든다면 2001년에는 인코딩 시간을 최적화하는데 신경쓰면 될꺼고, 2007년인 지금은 신경을 쓰지 않는다거나 - 뭐 씨피유 쓰는 양으로 볼 때 적당히 짜도 될 듯 - 편하고 직관적인 UI에 집중하는게 맞을것 같다 - I/O 병목은 ODD 속도 증가없이는 힘들테니 or IOCP처럼 overlap된 I/O를 처리하기 위한 시스템 콜을 쓴다거나;
사실 프로그램을 만들 때도 저렇게 원래 병목이었다고 생각했던게 병목이 아니어서 성능이 거꾸로 나오는 일이 일어난다.
특정 연산의 결과로 나오는 데이터를 미리 계산해서 저장해두면 - 일종의 pre-computation / caching쯤 되겠다 - 전체적인 시스템 성능이 향상되는 결과가 나온다. 적절한 길이의 프로그램 루프를 풀어버리는 것(loop unrolling)도 프로그램 실행 속도가 증가하게 된다.
그런데 말이지 대용량의 데이터를 처리하는 서버 프로그램의 경우엔 정 반대의 일이 일어나기도 한다. 미리 값을 계산해두고 저장하는 것 때문에 데이터 캐쉬에서 캐쉬 미스(cache miss; CPU에서 메모리를 읽을 때 바로 읽는게 아니라 cache를 거쳐서 읽는데 cache에서 못 찾은 경우를 가리키는 용어)가 나는 경우 속도가 급속히 떨어진다. 비슷한 경우로 루프를 너무 많이 풀어서(…) 자주 실행되는 루프가 명령어 캐쉬에 다 들어가지 않는 경우에도 실행속도가 대폭 느려진다.
결국 컴퓨터 엔지니어들이 해야하는 일은 어디가 병목인지 파악하고 거기를 최적화 하는것 밖에 없겠다 - 그리고 이건 하드웨어가 바뀌고 주변 환경(특히 응용의 속성)에 따라 계속해서변화하게 될 것이다.
불펌 블로그 방지 이미지
밑의 글에서 생각했던 것을 구현.
아이디어는 매우 단순함 - 현재 구현은 더더욱 -_-;
- HTTP Referer로 전달되어오는 부분 (HTTP 리퀘스트 쪽에 헤더로 넘어옴)을 해석해서 upnl.org 가 있으면 1 pixel by 1 pixel의 하얀 투명 이미지를 전송
- 그렇지 않은 경우 800 by 40의 “Not allowed referer: 실제 리퍼한 주소” 라고 적힌 이미지가 전송됨
구현한 코드는 매우 짧은 PHP 코드다 - libpng와 php-gd 가 설치된 곳에서 실행 가능함
header( "Content-type: image/png" );if( FALSE != strpos( $_SERVER["HTTP_REFERER"], "upnl.org" ) ) { imagepng( imagecreatefrompng( "pixel.png" ) ); } else { $im = imagecreatetruecolor( 800, 40 ); $color = imagecolorallocate( $im, 255, 255, 255 ); imagestring( $im, 10, 10, 10, "Not allowed referer: ".$_SERVER["HTTP_REFERER"], $color ); imagepng( $im ); imagedestroy( $im ); }
이런 코드로 위의 내용이 구현된다. 실제로 플러긴을 짠다면 리퍼러 부분이 좀더 복잡해지거나 하겠지만 - 아마 설정 가능한 필드로 해야 할 듯 - 구현 자체는 어렵지 않을 것 같다. 다만 이미지 생성하는건 부담이 가니 적절한 짤방(…)이미지를 쏴주는게 좋을듯함;
1 by 1 투명 이미지는 IE 6.0에서는 투명화가 안되서 희게 보이더라 -_-; - 아마도 PNG 지원이 잘 안되는 6.0 문제인 것으로 보이며 firefox와 opera에선 잘 보임; IE 7.0에선 투명화 잘 되고 있기도하고 ( –)
…그런 의미에서 투명화 안될 때를 대비해서 1픽셀 짜리 이미지의 색을 설정해야할 듯 하기도 싶고;
정상적인 - 원본 블로그에 해당 - 글이면 다음 화면이 나오게 됨
반대로 퍼가서 다른 주소의 페이지에서 나오게 되면 중간에 들어있던 공백 이미지들이 크게 확장[...]
뭐 이런식으로 주소가 나오는게 아니라 엄한 사진이 나온다거나, “매너있는 블로깅을 합시다” 정도의 문구가 찍힌 이미지가 나와도 재미있을듯 (야)
일단 Wordpress 용 플러긴을 만들어보고 잘 되면 태터 용도 생각해봐야;
불펌 블로그 대책
네이버 불펌 해결책! 에서 본 재밌는 방법을 약간 확장해본 것.
우선 1 px by 1px 의 아주 작은 이미지를 뿌려주는 페이지를 만든다.
예를 들어 http://rein.upnl.org/dummy_img.php 같은 페이지를 실행(?)하면 투명 png 혹은 gif 이미지 하나가 온다고 치자.
그러니까 실제 HTML 코드는 <img src=’http://rein.upnl.org/dummy_img.php’ /> 같이 나오는 것이고. 실제로는 작은 그림이라 안 보이는 그런 그림이 끼어들어가는 상황
그리고 저 페이지(그림 내용을 보내는 php 페이지)에서는 딱 한 가지 일만 한다. 웹 페이지에 있는 그림을 웹 서버에 요청할 때에는이 그림이 어디 있었던 건데 요청한다라는 식의 referer URI가 전송된다. 이걸 이용해서,
- Referer URI가 upnl.org / rein.upnl.org 혹은 신뢰할 수 있는 호스트 주소이면 잘 안보이는(…) 1 px by 1px 이미지를 보내 준다. (물론 투명 이미지여야 배경색이 바뀌어도 안 들키겠지)
- Referer URI가 위 내용에 해당하지 않으면 적절하게 큰 이미지를 보낸다 - 여기에 홈페이지 주소나 불펌즐 같은 문구가 들어가면 재밌겠다.
물론 불펌할 때 전부 찾아버리면 곤란하니 저런걸 여러개 집어넣고, 일정 확률로만 큰 이미지가 전송되게 하자.
대충 100개 집어넣고(공배 글자 부분에 넣으면 되겠다), 나올 확률이 한 3% 정도면 적절할 듯 싶다. 다 찾아내진 못하겠지[...]
StarLight 님의 아이디어에 내가 추가한 것은 딱 한가지. 정직한 블로거의 시간은 줄여주되 - 공백 문자 부분에 적절히 저 그림을 넣는 일은 wordpress 플러긴 같은 걸로 자동화 하고; 혹은 TT의 디비 쓰기 코드 직전에 적절히 넣는다거나 플러긴으로 만들면 자기 자신은 신경을 꺼도 될 듯 - 반대로 불펌 블로거의 일은 늘리자는 것.
일단 퇴근하면[...], 간단한 페이지를 만들어서 테스트를 해봐야 겠음. FF말고 다른 웹브라우져 Referer가 어찌 오는지도 궁굼하고;
경선 음모론
어제(일요일) 딴한나라당 경선이 있었다.
그런데 어디였는지 기억도 못하지만, 선거 용지에 기표한 것을 핸드폰에 달린 카메라로 촬영한 것들이 있다고 한다.
이런 것들이 여러 개 나왔다고 하니 여기에서 나오는 음모론[...]
- 둘 중 한명은 진다.
- 진 사람은 핸드폰 촬영 건을 빌미로 경선 투표 자체의 무효화를 선언한다.
- 재 경선을 요구하는데 새로운 운동 기간 + 기타 등등으로 대선 전 까지 경선이 안 끝난다고 주장한다.
- 각자 단독 출마 ㄳㄳ
믿으면 지는 겁니다
블로그 검색어를 살펴보다가
바로 밑의 글의 작업을 하다가 발견한 사실 하나
주요 리퍼러를 살펴보면 모든 검색 리퍼러를 살펴보면 구글 / 네이버 / 다음 순인데,
구글은 웹 페이지 검색과 블로그 검색에서 (그러니까 유입 순서) 들어온 것이었고 - 특히나 스핀 버퍼 ㄳㄳ(…),
다음의 경우에는 블로그 검색으로 유입된 것이었다.
그런데 네이버는 왜 웹 페이지 검색으로만. 해당하는 검색어로 블로그를 검색해도 나오지 않는다.
뭐 블로그가 웹 페이지의 부분 집합이긴 한데, 그래도 해당 분류 검색에 안나오는건 무슨 센스(…)
설마 이글루, 티스토리, 태터 툴즈만 블로그냐[...]. 아 정말 네이버 갈 수록 맘에 안드네 -_-
최근의 네이버 복사 방지 시스템 네이버 블로그 우선 검색 시스템에 따라 얼마 후면 어차피 네이버 쪽에 이 블로그 내용이 나오지도 않을 것 같으니 신경 끌까. 뭐 다행히도 펌해간 네이버 블로그는 없었지만 (이런 마이너 블로그를 펌질할 인간은 없겠지)
검색어 인코딩 문제
현재 이 블로그는 wordpress 2.x 버젼으로 운영되고 있다. 한국어 번역 판이 있다는 것을 알지 못해서 그냥 영문판으로 쓰기 시작했었고, 그런 의미에서(?) 계속해서 그렇게 운영되고 있다.
그렇지만 UTF-8 기반이기 때문에 한국어 인코딩 문제는 없다 - 덤으로 서버로 사용되고 있는 유리엘이 최근 재설치 후에 기본 인코딩이 UTF-8이 되어서 파일 시스템 쪽과 호환성 문제도 없다. 사실 그래서 UTF-8이 아닌 방식으로 - 예를 들어 시스템 로케일(한글윈도우의 경우 UHC) 로 - URI를 보내는 구형 웹브라우져를 쓰는 경우 (혹은 호환성 모드에서 강제로 옛날방식으로 사용하는 경우), 이 홈페이지 전체에 있는 한글 이름 파일들 - 당연히 UTF-8으로 인코딩 된 이름 - 에 접근할 수 없게 된다.
잡설은 여기까지고, 이 블로그에서 사용되고 있는 몇 가지 플러그인 중에는 검색 엔진을 통해 유입된 트래픽을 추적해주는 유틸리티가 있다. 거기에서 검색어를 별도로 저장해주는데, 여기에 깨진 문자들이 한참 나타난다.
1 2000 search.naver.com : ����� id3 ���ڵ� vs. 윈도우 id3 인코딩
2 5074 search.naver.com : ����Ʈ���� vs. 벨라스트라즈
9 10052 web.search.naver.com : javascript select onchange ���� vs. javascript select onchange 막기
10 10892 search.naver.com : USB ���� vs. USB 붓팅
17 17796 search.daum.net : ȫ���Ա� �ϻ��� vs. 홍대입구 북새통
18 18209 search.daum.net : �ݵ�ط�Ͻ����� vs. 반디앤루니스사당점
19 18407 web.search.daum.net : �Ϳ� ������ vs. 와우 동인지
20 18795 search.daum.net : ¥��� ������� vs. 짜증나는 동부지검
(앞 자리는 다음/네이버를 통해 유입된 것들의 일련번호다; 빈 번호들은 영문 검색어만 있는 경우)
vs. 앞 쪽이 원래 문장, 뒷 쪽이 euc-kr로 풀어낸 후 utf-8 인코딩으로 재해석한 경우.
국제화된 - 그러니까 다국어를 다뤄야하는 - 세계에서 우리나라 사이트들만 다루니까 euc-kr로 버티는 건진 모르겠지만; 그런 의미에서 네이버랑 다음은 꽝이네효 가능하면 UTF-8만 쓰려고하는 이 블로그에선 좋지 않단 말이지[...]
그래서 간단한 PHP 코드를 짜서 해결하고 문제를 일으켰던 wp-slim-stats 에도 약간의 패치를 가했음 - 슬프게도 이 플러그인은 더 이상 업데이트가 이루어지지 않고 있음
$result = mysql_query("SELECT id, searchterms from wp_slim_stats where searchterms != '' and ( domain like %daum%' or domain like '%naver%' )"); while( $row = mysql_fetch_array($result) ) { $id = $row['id']; $term = $row['searchterms']; $term = iconv( "euc-kr", "utf-8", $term ); mysql_query( "Update wp_slim_stats set searchterms='$term' where id = $id" ); }
이런 코드로 해결. iconv가 킹왕짱 …짜 놓고보니 SQL 효율/보안이랑은 천만광년쯤 거리가 있을듯한 코드네(…)
wp-slim-stats 에선 naver, daum을 검색어 추출코드에서 따로 인식하게 하고, iconv를 한 번 적용시키는 걸로 했음.
결론: 네이버나 다음에서 다국어 검색을 할 생각이 있다면 - 없는 것 같지만 - UTF-8 지원 좀 해줬으면 함.



3 comments