마우스 오른쪽 클릭 차단 : 블로그에서 마우스 오른쪽 버튼 클릭을 통해 복사 메뉴 접근을 차단합니다. 글을 복사해서 붙여넣거나, 이미지를 복사해 가는 것을 차단할 수 있습니다. 아울러 마우스 드래그를 통한 블럭 설정도 함께 차단됩니다.
거짓말하지 마세요! 왜 이래 아마추어같이.
2009년 2월 18일 수요일
Cubrid + unixODBC + OO.org
아직도 헝가리언 스타일이 유행하고 있는 ODBC 관련 코드를 보기 싫었지만 대충 동작:
여담이지만, 큐브리드는 현재 코드로는 패키징 불가능이다. 다운로드에 있는 RPM 패키지도 만들어진 모양으로 볼 때 (root 권한으로 셸 들어가서 실행하는 대모험을 할 게 아니라면) 분명히 안 돌아간다. 현재와 같이 한 폴더에 라이브러리, 클라이언트, 서버, 데이터까지 몰아 넣고 서로 엮여 있는 현재의 모양으로는 SE가 고객의 전화를 받고 출동해서 깔아 주는 경우라면 상관없을 지 몰라도, 패키징과 시스템 연동 측면에서는 환영받지 못한다. DB 포맷, 통신 프로토콜, 라이브러리 인터페이스 모두 버전 사이의 호환성을 보장하지 않고 있기 때문에 인터페이스를 만들기도 쉽지 않다. 더 문제가 되는 라이선스 충돌 문제를 해결했으니 다행이지만 큐브리드 프로젝트는 갈 길이 멀다.
여담이지만, 큐브리드는 현재 코드로는 패키징 불가능이다. 다운로드에 있는 RPM 패키지도 만들어진 모양으로 볼 때 (root 권한으로 셸 들어가서 실행하는 대모험을 할 게 아니라면) 분명히 안 돌아간다. 현재와 같이 한 폴더에 라이브러리, 클라이언트, 서버, 데이터까지 몰아 넣고 서로 엮여 있는 현재의 모양으로는 SE가 고객의 전화를 받고 출동해서 깔아 주는 경우라면 상관없을 지 몰라도, 패키징과 시스템 연동 측면에서는 환영받지 못한다. DB 포맷, 통신 프로토콜, 라이브러리 인터페이스 모두 버전 사이의 호환성을 보장하지 않고 있기 때문에 인터페이스를 만들기도 쉽지 않다. 더 문제가 되는 라이선스 충돌 문제를 해결했으니 다행이지만 큐브리드 프로젝트는 갈 길이 멀다.
2009년 2월 10일 화요일
티스토리 탈출 예정
제한적 본인 확인제 등 규제로 인한 제약도 거리끼는 부분이다. 특별히 정치적인 입장을 드러내지도 않고, 불법이나 명예훼손에 관련되지도 않기 때문에 거리낄 일은 없지만, 귀찮고 기분 나쁜 일은 누구에게든 생길 수 있는 일이므로 벗어나고자 한다. 정책적 방향이 바뀌지 않는 한 어디로 탈출하더라도 이 제도는 계속 확대되겠지만 되는 데까지 버텨 본다.
진짜 불편한 부분은, 대형 포털의 고질적인 문제로, 아무리 문제점을 피드백해도 전달이 안 된다. 고객 센터는 매우 친절하게 대응했지만 사용법을 헤매는 고객을 돕는 방법만 교육 받았지 문제점 해결을 전달하는 교육은 받지 못한 모양이다. 나는 형식적인 친절함을 원하는 게 아니라 문제의 실질적인 해결을 원한다. 아무리 구체적으로 버그의 원인을 설명해도 잘 모르겠으면 "전화 주시면 해결해 드리겠습니다"라고 결론이 나면서 단답형으로 처리가 끝나는 상황은 답답하기 짝이 없다. 물론 블로그 사이트가 프리소프트웨어도 아니고 피드백을 하면서 고쳐 쓸 생각을 하는 게 잘못일지도 모르겠지만 답답한 상황은 벗어나고 싶다.
피드백이 안 된다는 것과 더불어 변화가 느린 것도 피로하게 느껴진다. 문제점 중에는 태터툴즈/텍스트큐브에 이미 반영된 사항도 있었기 때문에 더 그렇게 느껴진다. 만약 내가 티스토리 개발 방향을 결정할 수 있는 사람이었다면, 개발 조직을 대형 포털의 체계 속에 집어 넣어 격리시키는 게 아니라, 태터툴즈/텍스트큐브 오픈소스 프로젝트에 적극적으로 참여함으로써 문제를 해결하려 했을 것이다. 지금은 갈라선 지 오래 되어서 너무 늦었을까?
어쨌든 TNC가 맨 처음 티스토리를 시작할 때 내세운 티스토리의 장점은 그것이었다. 회사가 사용자를 컨트롤하지 않는 블로그. 별도의 도메인을 허락하고, 페이지 내용의 다양한 커스터마이즈를 허락하고, 티스토리를 떠나더라도 백업이 쉽다. 새삼 이러한 방향의 결정은 옳았다는 걸 느낀다. 백업 파일 포맷이 그 사이에 달라졌다는 이야기도 있지만 (1) 불가능하지는 않겠지..
진짜 불편한 부분은, 대형 포털의 고질적인 문제로, 아무리 문제점을 피드백해도 전달이 안 된다. 고객 센터는 매우 친절하게 대응했지만 사용법을 헤매는 고객을 돕는 방법만 교육 받았지 문제점 해결을 전달하는 교육은 받지 못한 모양이다. 나는 형식적인 친절함을 원하는 게 아니라 문제의 실질적인 해결을 원한다. 아무리 구체적으로 버그의 원인을 설명해도 잘 모르겠으면 "전화 주시면 해결해 드리겠습니다"라고 결론이 나면서 단답형으로 처리가 끝나는 상황은 답답하기 짝이 없다. 물론 블로그 사이트가 프리소프트웨어도 아니고 피드백을 하면서 고쳐 쓸 생각을 하는 게 잘못일지도 모르겠지만 답답한 상황은 벗어나고 싶다.
피드백이 안 된다는 것과 더불어 변화가 느린 것도 피로하게 느껴진다. 문제점 중에는 태터툴즈/텍스트큐브에 이미 반영된 사항도 있었기 때문에 더 그렇게 느껴진다. 만약 내가 티스토리 개발 방향을 결정할 수 있는 사람이었다면, 개발 조직을 대형 포털의 체계 속에 집어 넣어 격리시키는 게 아니라, 태터툴즈/텍스트큐브 오픈소스 프로젝트에 적극적으로 참여함으로써 문제를 해결하려 했을 것이다. 지금은 갈라선 지 오래 되어서 너무 늦었을까?
어쨌든 TNC가 맨 처음 티스토리를 시작할 때 내세운 티스토리의 장점은 그것이었다. 회사가 사용자를 컨트롤하지 않는 블로그. 별도의 도메인을 허락하고, 페이지 내용의 다양한 커스터마이즈를 허락하고, 티스토리를 떠나더라도 백업이 쉽다. 새삼 이러한 방향의 결정은 옳았다는 걸 느낀다. 백업 파일 포맷이 그 사이에 달라졌다는 이야기도 있지만 (1) 불가능하지는 않겠지..
나눔고딕코딩 변환한 "무난" fontforge 스크립트
역시 DejaVu 만한 게 없다. DejaVu Sans Mono와 폭을 맞추자. 방법은 다른 곳에 많이 설명되어 있으니 생략하고, 그 과정을 앞으로도 써먹을 수 있도록 스크립트로 만든다.
http://gist.github.com/60908
실제로 Vera / DejaVu 호환을 목적으로 만들어진 글꼴도 있는데 Arundina 타이 글꼴이 그 경우이다. 한글 글꼴보다야 만드는 난이도는 낮지만 Vera / DejaVu에 호환되도록 만들어졌다. 이왕이면 기존 글꼴들과 잘 어울리게 만든 글꼴이 있으면 fontconfig에서 사용할 시스템 글꼴로는 이상적인 형태가 아닐까? (역시 디자이너들은 버럭하겠지만)
http://gist.github.com/60908
$ fontforge -script nanum2munan.pe NanumGothicCoding-Bold.ttfMunan은 OFL에 따라 이름을 바꾼 것. :-) 폭이 바뀌면서 자간이 늘어나 버렸기 때문에 이상적인 형태는 아니지만 그렇다고 스케일하면 힌팅이 망가질게 거의 확실하다.
Copyright (c) 2000-2008 by George Williams.
Executable based on sources from 00:29 GMT 29-Apr-2008.
Library based on sources from 20:49 GMT 30-Apr-2008.
Input File: NanumGothicCoding-Bold.ttf
Output File: MunanSansMono-Bold.ttf
Family: Munan Sans Mono
Fullname: MunanSansMono-Bold
$ fontforge -script nanum2munan.pe NanumGothicCoding.ttf
Copyright (c) 2000-2008 by George Williams.
Executable based on sources from 00:29 GMT 29-Apr-2008.
Library based on sources from 20:49 GMT 30-Apr-2008.
Input File: NanumGothicCoding.ttf
Output File: MunanSansMono.ttf
Family: Munan Sans Mono
Fullname: MunanSansMono
실제로 Vera / DejaVu 호환을 목적으로 만들어진 글꼴도 있는데 Arundina 타이 글꼴이 그 경우이다. 한글 글꼴보다야 만드는 난이도는 낮지만 Vera / DejaVu에 호환되도록 만들어졌다. 이왕이면 기존 글꼴들과 잘 어울리게 만든 글꼴이 있으면 fontconfig에서 사용할 시스템 글꼴로는 이상적인 형태가 아닐까? (역시 디자이너들은 버럭하겠지만)
피드 구독하기:
글 (Atom)