Idelines....

[플러그인] Attachment2Link V 1.0.4 ( 첨부파일을 링크로서 본문에 삽입!)

(마루바램) — Thu, 04 Dec 2008 05:48:52 +0900

1. 소개

테터툴즈에는 첨부파일이라는 좋은 기능이 있지만 다른 첨부파일리스트와는 달리 이미지 삽입 등의 용도로만 사용되고 있습니다. 카페나 스레드를 세울 때에는 파일을 첨부하면 다운로드 할 수 있는 링크가 생기는 반면에 테터툴즈에서는 링크를 삽입할 길이 없습니다. 이런 상황에서 링크를 삽입하기 위한 플러그인을 만들었습니다.

2. 업데이트 상황

08.08.19 V1.0.4 Textcube 1.7에 대응
07.08.19 V1.0.2 파이어폭스에서 http://idelines.net/blog/attach/1 라는 치환자를 제대로 넘겨받지 못해 생기는 문제점을 해결하였습니다. (그냥 치환자 대신 직접 치환된 경로를 주입하는 방법입니다.)
07.08.19 V1.0.1 Attachment2link 버튼의 id가 중복되는 현상 제거
07.08.18 V1.0 플러그인 제작

3. 기능

V 1.00 기준으로 단순하게 첨부파일을 본문에 삽입하는 기능뿐이 없습니다.

4. 사용가능 버젼

테터툴즈 1.1 이상, 텍스트큐브 1.5 이상 사용가능

5. 설치 및 사용 방법

먼저 아래 파일을 다운로드 받고 압축을 풉니다.

Attachment2Link.rar (2.41 KB)

압축이 풀린 파일들을 테터툴즈 or 텍스트큐브 경로/plugins 에 업로드합니다. 이때 폴더이름은 아무거나 상관없습니다.
관리자 센터로 로그인한 후 플러그인 목록으로 들어간 후 attachment2link를 찾아 사용중으로 설정합니다.

본문글 작성 혹은 본문글 수정으로 들어오신다면 밑에 Attachment2Link버튼이 있습니다. 첨부리스트에서 링크로 삽입하기 원하는 파일을 선택한후 Attachment2Link를 누르시면 본문에 삽입됩니다.

6. 앞으로의 개발 방향
버그가 생긴다면 버그해결이 주목적이며, 기능 개발은 딱히 없습니다. 다만 파일 종류에 따라서 아이콘을 삽입해주는 기능을 넣을까 검토중입니다.

7. 넋두리

... 테터에서도 저런 링크를 달수있더군요. 처음알았습니다.
위에 연결된 링크중 위에꺼가 테터에서 쓰는 링크 아래꺼가 플러그인을 이용한 링크입니다..만 별반 다르지 않네요. 만든게 아까워서 제 테터에선 그냥 쓰렵니다.. 흐윽.

본래 만들었던 목적을 상실했습니다; 원래 만들었던건 이미지파일,MP3등 텍스트큐브에서 실행혹은 어떠한 형태로 파싱되는 것들에 대한 다운로드 링크를 만들기 위해서였는데... 아무튼 필요에 의해 다시 사용하려다가 1.7이후로 작동이 안되는 걸 보고(;;) 손봐서 작동합니다. 거진 1년만에 업이군요;

이연희 바탕화면(Wallpaper)

(마루바램) — Thu, 04 Dec 2008 05:33:27 +0900

포맷을 하고 나서 보이는 바탕화면이 어색해보이길래, 그냥 이연희 바탕화면을 만들어버렸다;
원래는 깔끔하고, 심플한 바탕화면을 선호하는 나이지만, 순정만화를 보고 와서 그런지 이연희로 어느샌가 컴퓨터 화면이 도배가 되었다 (!!)

기본적으로 와이드로 작업했고, 1900X1200의 크기이다.(1920의 20은 어디다 팔아먹었냐고 물어본다면, 실수로 잘못 작업했는데... 다시 고치기 귀찮아서 그냥 늘이기로 해놓고 있다. 만약 요청 들어오면 수정한다.)

이연희.jpg (1900x1200 / 442.73 KB)

p.s 개인적으로는 순정만화에 나오던 이연희의 모습을 좀더 많이 넣고 싶었는데, 어찌나 스틸컷들이 없던지... 나중에 디비디 나오면 캡쳐 해가면서 만들던지 해야겠다;

자바스크립트를 통한 제약설정의 한계 및 위험

(마루바램) — Sat, 22 Nov 2008 17:16:16 +0900

웹 발전이 빠르게 이루어지고 또한 최근 Ajax의 대두로 인해 자바스크립트가 다시금 기지개를 켜고 있다.
그런 의미에서 잠깐 자바스크립트를 통한 제약 설정이 얼마나 취약한지 알아보려 한다.
설정되는 상황은 서버사이드에서는 어떠한 제약 설정도 존재 하지 않으며 자바스크립트에만 제약 사항이 존재한다고 가정한다.

간단한 예를 들어보자.
DB 스키마에 아이디 속성이 8글자로 한계지어져 있다고 하자.
그렇다면 프로그래머는 이용자가 가입시에 아이디를 8글자 이내에서만 받기를 원할 것이다. 이 때 자바스크립트로 아이디 필드를 체크해서 서버사이드로 넘기게 프로그래밍을 하였다고 한다면, 이 제약사항은 풀리기 쉽다.
파이어폭스에 Firebug라는 플러그인을 사용한다면 매우 손쉽게 동적 페이지의 구성을 변경하고 적용해볼수 있다.
단순히 Firebug에서 제약사항이 담겨있는 자바스크립트를 찾아 제약사항을 바이패스(bypass) 하게끔 편집하고 페이지에 입력해서 넘기면 제약사항은 간단하게 풀려버린다.
이 예의 경우는 단순히 사용자의 문의가 생겨서 프로그래머가 곤혹을 겪기만 할 문제이지만, 이게 해킹으로 연결되면 문제는 무시무시해진다.

예를 들어 SQL Injection 해킹을 막기 위해 프로그래머가 보안을 위해 제약 설정을 했다고 하자. 그런데, 너무나 귀찮은 나머지 그냥 스크립트로 휙 하고 체크하고 넘기게 했다면, 이 프로그래머는 짤릴 위험성을 스스로 열어버린것이다.

뿐만 아니라 필자는 이러한 방법을 통해 ZB XE 솔루션을 통해 만들어진 학교 게시판에서 익명의 글들의 작성자가 누구인지 알아 내기도 했었다. 익게에는 스크랩 버튼이 없지만, 다른 페이지에 있는 스크랩 소스를 익명 게시판에 Firebug를 통해 붙이고 스크랩해서 확인하는 방법을 사용했었다. (물론, 되는걸 확인 후에 바로 건의해서 이 취약점은 학교 게시판에서 없어졌다.)

이처럼 WEB2.0이 대두되고, 많은 프로그래머들이 웹프로그램의 레벨을 일반 오프라인 프로그램(적당한 단어가 생각이 안나네요) 수준으로 올리기 위해 자바스크립트가 많이 사용되고 있다. 하지만 자바스크립트가 쉽고 편하다 할 지라도, 그리고 동적이기에 좀더 친사용자 적이라 할 지라도, 프로그램의 눈길이 닫지 못하는 곳에 중요한 부분을 만들어두는 방법은 지양해야 할 것이다.

...너무나 당연하고 모두 아는 내용을 적은건지 하는 의문도 들긴 하지만,, 워워..

Seal (실), 실타래를 보다.

(마루바램) — Mon, 17 Nov 2008 20:30:00 +0900

WWW를 서핑하다보니, 어떤 블로그에서 실타래,SEAL 이라는 것을 알게되었고, 공식 홈페이지로 가게 되었다.
공식 홈페이지의 소개로는 다음과 같다.

영어로 'Seal'은 휘장/명찰
한글로 '실'은 무언가를 이음
나를 표현하는 "휘장, 명찰",그리고 블로그/카페를 모두 하나로 "잇는"기능

뭐, 나를 표현하는 Icon,같은 Seal을 달고 있는 사람들과 소통기능, 진화하는 Seal 등 특징들이 나와있지만 그냥 딱 보는 순간, 이거 동맹아니야? 하는 생각이 들었다.

한때 WWW의 보급과, 초고속인터넷의 각 가정의 보급 이후 우후죽순 생겨난 개인홈페이지들은 동맹이란걸 달고 있었다. 그 때는 한참 네띠앙 개인홈페이지등등 공간을 제공하던 곳도 있었고, 지금이라면 생각도 못할 50MB 라는 파격적인 엄청난 공간을 제공하는 하이홈도 있었다. 거기에 슈퍼보드등의 무료 게시판을 연결시켜서 만들던 홈페이지가 재미가 솔솔했던지..
아무튼, 동시에 튀어나온게 여러가지 만화 캐릭터나 어떤 작품, 영화 등등으로 하나의 동맹을 맺는 홈페이지들이 있었다.
(지금도 물론, 여러 블로그 사이들에서는 존재한다. )

동맹의 한 예

홈페이지 귀퉁에 주렁주렁 매달아 두던 동맹 배너와 동맹 홈페이지들이 한때는 자랑이던 시절도 있었지요.

실타래의 경우에는 개인이 만든게 아니라 실타래 쪽에서 제공해주는 실들에 한정되어 있는게 기존의 동맹과는 많이 다른 부분이지만, RSS로 실을 단 블로거들끼리 포스트를 공유할 수도 있으니 첨단 기능이 부가된걸로 만족해야 하나?

DOM(createElement) VS innerHTML

(마루바램) — Wed, 12 Nov 2008 02:10:17 +0900

새벽에 열심히 프로젝트를 진행하다가 문득 궁금해져버렸다.

DOM 에 직접적으로 접근하여 개체를 생성, 삭제, 갱신 하는 방법과
innerHTML로 그냥 쉬릭 써버리는 방법 중 어느게 빠를까.

원래 예상은 표준인 DOM을 통한 억세스가 좀더 낫지 않을까 였으나, innerHTML 방식이 더 빠른 벤치 결과를 보게되었다.

나름 innerHTML에다가 쓰면 자바스크립트와 브라우저 나름대로 파싱을 다시 해서 DOM에 넣어버리는게 아닐까....라는 이상야릇 추측성 생각을 가지고 접근했었는데 아니었다 보다;

속도는 거의 3배 정도 innerHTML이 빠르더라.

그런데, innerHTML이 비표준이라 앞으로 나오는 브라우져들은 점차 지원을 안할 계획이란다.

표준을 따르는 것에도 이유가 있겠지만, 속도를 포기하고 표준을 중시하는 것.

그냥 조금 이상하다고 생각되었다. 목적이 속도인가? 아니면 어떠한 규칙, 표준을 지키는 것이 목적인가.

뭐, 어쨌든 innerHTML을 지원하지 않는 플랫폼이 나온다면야 당연히 DOM으로 가야하지만.....

문득..

(마루바램) — Sun, 09 Nov 2008 23:52:31 +0900

어쩌다가 아이마스 관련 영상을 보게 되었다.
멍하니 보다가 문득 그런 생각이 들게 되었다.

'이런 것처럼, 비슷하게 공연 기획 혹은 시뮬레이션
프로그램이 있으면 자라나는 공연 기획자들이 쉽지 않을까?'

아마도 최근 교회에서 한달정도(라지만, 주일에만) 방송실에서
예배 진행을 도운 경험이 좀더 작용했으리라..

게다가 아이마스 영상 가운데 간간히 보이는 조명 장비들은
다 실제에서도 보던거 아닌가! 뭐 아이마스를 해본게 아니기에
어느 정도로 세세하게 설정할 수 있을지는 모르겠지만...
필터나 등등 여러가지 다 조정할 수 있다면야..

매주 토요일 예배 때 사용할 씬을 짜느라 밤을 새우시던 조명
간사님이나. 열심히 카메라들 호출하고 싸인 주시면서
전체 영상 담당하시던 실장님....

그래서 혹시나 하고 찾아봤는데, 왠걸 있더라;

쩝. 역시 프로그래밍의 세계에서 블루 오션 찾기란...

[자동 저장 문서]

(마루바램) — Fri, 03 Oct 2008 23:19:41 +0900

[Flash]

교회 광고 때 쓸만한 광고

(마루바램) — Tue, 30 Sep 2008 16:13:08 +0900

http://www.adic.co.kr/ads/list/showNaverTvAd.do?ukey=149292&oid=&pageNumber=5

+ 하이마트 광고드,ㄹ..

http://www.adic.co.kr/ads/list/showNaverTvAd.do?ukey=64182&oid=&pageNumber=6

시간좀 내주오;

당분간 닫아 둡니다.

(마루바램) — Sun, 03 Aug 2008 23:16:00 +0900

블로그의 존치 목적의 상실과.....또한 개인 제작 홈페이지로의 회귀를 마음에 두고 있길래

당분간 블로그는 방치합니다.

사진과 이미지의 경계

(마루바램) — Mon, 30 Jun 2008 13:18:17 +0900

디카가 보급된 이래로 인터넷 그리고 수많은 가정에는 사진들이 대량 생산되고 있다. 어떻게 보면 이러한 사진의 붐은 반길만한 부분이다.

그런데, 요새는 사진과 이미의 경계가 무너져 가는 모습을 볼 수 없다.

후보정을 비난하고자 하는 글은 아니다. 디카 이전 시대에도 후보정은 있었으니 그걸 비난하고자 하는 것이 아니다. 다만, 이미지와 사진의 구분은 해주었으면 \하는 마음이다.

하늘 사진으로 예를 들어보자면 절대로! 찍어서 나올 수도 없고, 그런 하늘을 볼 수 도 없는 시퍼런 하늘의 색을 가진 사진들이 있다.
딱 볼때 나는 위화감을 느낀다. 이게 사진인가 싶다. 물론 그냥 하늘을 찍어서 포토샵등지에서 보정을 해준 것이다. 무슨 생각을 담고자 하여 그러한 보정을 했는지 궁금하기도 하다.

사진이라는 단어의 의미를 살펴보면 진실을 담고 있다는 말이다. 표현될 수 없는 모습을 보정을 통해 사진이라고 말한다면 내가 보기엔 그건 사진이 아닌 이미지이다.

보정은 보정에만 머무르는 것이 보정이라고 생각한다. 사진이라는 경계를 넘어선 보정이 가해질때 이는 사진이 아닌 이미지이다.
사진에는 생각이 담겨야 하고, 이는 후보정을 할걸 예상하는 게 아닌 찍을 때 담는 것이라고 본인은 생각한다.

결론은 과도한 보정을 삼가자. 로 한줄 요약