'프로그래밍'에 해당되는 글 5건
- 2008/08/17 뽀샵질과 프로그래밍
- 2008/07/11 PuTTY 한글/영문 글꼴 분리하기 (5)
- 2007/02/15 Django 웹프레임웍 (4)
- 2006/10/07 프로그래밍을 다른 사람들과 공유한다는 것 (19)
- 2006/10/04 PHP 6.0
뽀샵질과 프로그래밍
요즘 건축 관련 공모전을 준비하느라 바쁜 형에게 가끔씩 뽀샵질에 대해 도움을 주고 있다. 그런데 이것저것 설명하다보니 포토샵으로 무언가를 하는 과정은 프로그래밍할 때의 사고 과정과 매우 유사하다는 생각이 들었다. 예를 들어, 서울시 지도를 스크린샷으로 떠서 비트맵 이미지를 갖고왔다고 할 때, 서울시 행정구역의 윤곽을 따내고 거기에 목표하는 어떤 철도나 도로를 벡터로 표시한다고 생각해보자.
윤곽을 따내는 방법으로는 lasso 툴로 선택 영역 지정하는 방법, pen 툴로 shape layer로 그려내는 방법, magic wand로 배경을 지워 투명하게 만들어 원본을 그대로 이용하는 방법 등 여러 가지가 있다. 또한 서울시의 특정 위치를 그 그림에 표시하려면(그 위치는 줌인하여 스크린샷을 떴으므로 윤곽과는 다른 스케일이다) 화면 좌표 측정 도구로 노가다로 몇 번 찍어 픽셀값을 상대좌표로 계산하는 방법이 있고, 윤곽선 따내듯 따낸 다음 적당히 확대·축소하는 방법이 있고 또 여러 방법이 있을 것이다. 또한 CS2 이상이라면, 원본 비트맵을 가지고 확대·축소를 하더라도 원본 내용을 잃지 않기 위해 smart object 기능을 이용할 수도 있다. 또한 레이어 위치를 어떻게 놓는지, 어떤 필터나 어떤 blending option, merge를 어떤 순서로 적용하는지 등 작업 방법과 순서에 따라 굉장히 다양한 조합이 나올 수 있다.
이러한 수많은 방법의 조합들 중에서 주어진 시간 내에, 주어진 목표를 달성하기 위해 가장 최선의 조합을 선택해야 한다. 예를 들어 우리 형은 건축 공모전을 준비하고 있으므로, 큰 포스터를 만들기 위해서는 고해상도 인쇄가 필수적이기 때문에 가능한 한 벡터 방식을 이용하는 것이 좋다.
마치 알고리즘 문제를 풀기 위해 어떤 종류의 알고리즘 설계를 이용할 것인지 파악하고(dynamic, greedy, back-tracking, heuristic 등등) 구현 난이도와 제한 시간을 고려하여 적당한 것을 고르는 것과 거의 같다고 볼 수 있다. 그래픽 작업 또한 결국은 이러한 최적화로 아우를 수 있을지 모르겠다. (물론 머릿속으로 미리 완성물의 이미지를 그려내는 미적 요소는 알고리즘 문제와는 다른 접근이겠지만.)
아무래도 전산을 전공하다보니 어떤 현상과 행동의 패턴을 알고리즘적으로 대입하여 보는 시각이 강해졌는데, 분명히 이렇게만으로는 설명될 수 없는 것--대표적으로 연애--도 있지만, 적어도 '일'을 하는 데 있어선 이러한 사고방식이 밑바탕에 깔리는 게 어느 분야든지 필요한 것 같다.
이올린에 북마크하기
이올린에 추천하기
PuTTY 한글/영문 글꼴 분리하기
오늘도 삽질 하나. 날씨도 너무 덥고 텍스트큐브 코딩도 안 되고(?) 해서 PuTTY를 뜯었다.;; 그동안 오랜 숙원사업(?)이었던 한글/영문 글꼴의 완전한 분리에 성공했다.
스크린샷. 전체 사이즈 보려면 여기 클릭.
PuTTY 소스코드가 생각보다 난잡(...)해서 찾는 데 좀 시간이 걸렸지만 더위는 이열치열(?)이라는 생각으로 삽질을 해주니 마침내 어디를 고쳐야 하는지 찾을 수 있었다.
방법은 간단히 다음과 같이 window.c를 패치해주고 컴파일하면 끝.;; 보다시피 급조한 거라 글꼴 설정은 소스코드에 하드코딩되어 있다; 기준 소스는 0.60 최신 버전. 아참, 생성만 하고 소멸시키지 않는 것처럼 보이나 다른 부분에 보면 FONT_MAXNO까지 배열을 순회하며 DeleteObject를 호출해주는 부분이 있으므로 걱정 안 해도 된다.
//...
#define FONT_OEMBOLDUND 0x23
#define FONT_NONLATIN 0x30
#define FONT_MAXNO 0x30 //0x2F
//...
static void init_fonts(int pick_width, int pick_height)
{
//...
f(FONT_NORMAL, cfg.font.charset, fw_dontcare, FALSE);
fonts[FONT_NONLATIN] = CreateFont (font_height, font_width, 0, 0, fw_dontcare, FALSE, FALSE, FALSE, \
cfg.font.charset, OUT_DEFAULT_PRECIS, \
CLIP_DEFAULT_PRECIS, FONT_QUALITY(cfg.font_quality), \
FIXED_PITCH | FF_DONTCARE, "Dotum");
SelectObject(hdc, fonts[FONT_NORMAL]);
GetTextMetrics(hdc, &tm);
//...
}
void do_text_internal(Context ctx, int x, int y, wchar_t *text, int len,
unsigned long attr, int lattr)
{
//...
} else {
/* And 'normal' unicode characters */
static WCHAR *wbuf = NULL;
static int wlen = 0;
int i;
if (wlen < len) {
sfree(wbuf);
wlen = len;
wbuf = snewn(wlen, WCHAR);
}
for (i = 0; i < len; i++)
wbuf[i] = text[i];
/* EXTRA PATCH for non-latin font replacing... */
SelectObject(hdc, fonts[FONT_NONLATIN]);
text_adjust = 1;
/* print Glyphs as they are, without Windows' Shaping*/
general_textout(hdc, x, y - font_height * (lattr == LATTR_BOT) + text_adjust,
&line_box, wbuf, len, IpDx, !(attr & TATTR_COMBINING));
//...
}
유니코드 렌더링 부분을 바꾼 것이기 때문에 CP949나 윈도98과 같은 환경에서는 어떻게 나오는지 모르겠지만 일단 나는 유니코드 터미널만 쓰고 있으므로 패스; =3
내가 VS2005로 컴파일한 바이너리는 KLDP를 참조하기 바란다.
추가: 앞으로 원활한 개발을 위해 공개 subversion 저장소를 생성하였다. ViewVC를 통해 살펴보려면 이 링크를 참조하기 바란다. SVN 프로토콜로 접근하려면 경로에서 view를 빼면 된다.
Django 웹프레임웍
요즘 새 스팍스 홈페이지를 만들면서 Python 기반의 웹프레임웍인 Django를 사용하고 있는데, 정말 편리하고 깔끔하다. 프레임웍 기반은 Model - View - Template의 개념으로 각각 MVC 모델의 Model - Controller - View에 해당한다고 보면 된다. (View가 로직·동작과 template에 보여줄 내용을 결정한다. Template은 간단한 if, for 정도의 프로그래밍이 가능한 스킨이라고 보면 된다) DB 백엔드가 완벽하게 추상화되어 있어 쿼리문을 전혀 쓸 필요가 없고, 프로젝트 설정파일만 바꿔주면 백엔드를 언제든지 교체할 수 있다. (이때 존재하는 데이터의 백업 등은 어떻게 하는지 아직 잘 모르겠다)
다른 것보다도, 웹프로그래밍에 처음 입문하는 사람들이 가장 쉽게 접하는, C와 비슷한 스타일의 php에 요즘 질려 있던 터라 Python의 깔끔함을 그대로 이어가는 것이 매우 맘에 들었다. Python 자체가 원래부터 디렉토리 단위로 만들어지는 package라는 개념과 namespace가 명확히 구분되는 특징을 가지고 있었던 데다, 정규표현식을 이용한 URL 패턴 매칭이 접목되어 매우 높은 자유도로 URL 형식을 정의할 수 있다. 또한 설치 환경마다 매번 magic quotation, safe mode 등을 고려하여야 했던 PHP와 달리 그렇게 보안 취약점을 만들 수 있는 부분이 없는 것도 좋다. (PHP6에서는 이런 단점들이 개선된다고 하니 그또한 나름대로 기대할 만하다.)
또 하나의 장점은, 웹개발할 때 보통 DB 스키마를 정의해놓고 html과 로직 등을 합치는 과정에서 실제 데이터가 어떻게 보일지 예시로 넣어보는 게 은근슬쩍 귀찮은데, admin 모드를 제공하여 model에 정의된 필드 형식에 맞도록 적절한 입력폼이 주어진다는 사실이다. 따라서 방문자에게 보여질 model과 view, template을 만드는 것만으로 별도의 관리자 모드를 제작할 필요 없이 내장된 것만으로도 블로그를 만들 수 있을 정도다. (물론 위지윅 에디터 같은 건 아니지만...)
한 가지 더, django에서 사용하기 위해 정의한 model 클래스들은, 웹사이트가 아닌 전혀 다른 프로그램에서 적당히 import해오기만 하면 그대로 사용이 가능하다. 따라서 model 객체를 만들어 사용하면, 그 model이 속한 DB 설정에 따라 알아서 쿼리를 수행해주고, 우리는 그냥 그런 오브젝트가 원래 있었던 것처럼 쓰기만 하면 된다. 따라서 웹사이트의 데이터를 다른 프로그램에 매우 쉽게 이식할 수 있다는 장점이 있다. (이것은 백업·복원과 같은 작업에 큰 도움을 줄 수 있을 것이다)
아무튼 이 Django 프로젝트가 꾸준히 발전하였으면 좋겠다. Python을 Apache에 모듈로 올리면 속도가 좀 느리다는 단점이 있긴 하지만 앞으로 FastCGI 등이 일반화되면 성능도 크게 뒤떨어지지는 않을 것 같다. (PHP6도 fCGI를 기본 지원한다) 사람들이 php와 asp, jsp의 세계에서 벗어나 보다 다양한 웹프레임웍에 관심을 돌려본다면 django와 같이 재미있는 물건들을 많이 발견할 수 있을 것이다. (RoR은 이미 너무 유명해져 버렸나...-_-)
프로그래밍을 다른 사람들과 공유한다는 것
정말 공감가는 내용이다. 지난 주 같은 기숙사동에 사는 친구들과 밥 사먹으러 나가면서 했던 얘기 중에, 다른 과 아이들에 비해서 특히 전산과 다니는 사람들은 전공에 관한 얘기를 많이 하는 것 같고, 그럴 때마다 다른 과 사람들은 대화에 참여하기가 힘들어진다는 것이었다.개발자들은 저주 받았습니다. 자기 일하는 것을 주변의 다른 사람들(개발을모르는)과 공유하지 못합니다. 아버지 어머니는 도대체 내 딸이 무슨 일을 하는지 모릅니다. 저는 이 벽을 넘어서 보고 싶습니다.내가 평소 하는 일을 조금이라도 다른 사람들과 공유할 수 있기를 기대합니다.
제가 해보고 싶은 것은, 바로 컴퓨터프로그래밍을 아는 사람과 모르는 사람이 함께 섞여서 서로 학습하고 또 즐거운 시간을 보내는 겁니다. 그 사람들이 모여서 정치이야기나 탤런트 스캔들 이야기, 혹은 유치한 게임 외에 도대체 뭘 같이 할 수 있을지 상상하기도 힘들죠? 저는 확신을 갖고있습니다. 이것은 가능하며, 엄청나게 재미있고 유익하며 모두에게 큰 계발을 줄 것이라는 것을. 예를 들면 소프트웨어 전문가들,하드웨어 전문가들, 예술가들, 일반인들이 섞여서 2박 3일간 같이 미디어 아트를 배우고 실험하고 협력해서 뭔가 만드는 걸 할수도 있겠죠. 여기에 대해서는 뭔가 작당하고 있는 것이 있습니다. 차후에 성과가 있으면 공유하도록 하겠습니다.
by 김창준, from Agile blog
사실, 물리·수학·생물·화학 같은 것만 해도, 기본적으로 과학고를 나오고 1학년 공통 기초과목들을 제대로 들었다면 학부생 수준에서는 대략 말이 통하게 마련이다. 그런데 유독 전산―그러니까 프로그래밍―쪽은 그렇질 못하다. 물론 기초과목으로 Java를 가르치는 '프로그래밍 기초'가 있긴 하지만, 프로그래밍이라는 것 자체가 어렸을 때부터 공부해왔던 '교과목'들과는 많이 다른 성격을 띠기 때문이다. 프로그래밍 문법을 익히거나 컴퓨터의 역사를 배우는 것은 정말 그런 교과목을 익히는 방식으로 가능할 지 모르겠지만, 실제로 전공 이상의 수준에서 프로그래밍을 다룰 때는 그런 것들과 그에 대한 공부 방식은 거의 도움이 되지 않는다. 몇 가지 기본적인 룰 안에서 고차원적 문제를 해결하기 위한 알고리즘을 생각해내는 것이라든가, 코딩 과정에서 발생하는 수많은 삽질과 디버깅, 경험에서 우러나오는, 마치 인간 라이브러리인 양 갑작스레 툭툭 튀어나오는 geek스런 답변들…. 조금이라도 이런 것이 대화에 끼어들게 되면 비전산전공자(..)들은 마치 안드로메다 관광열차를 타는 듯한 느낌을 받는다(고 한다 -_-).
그나마 비교적 균질하다는 같은 KAIST 학생들끼리도 그러할진데, 하물며 같은 과학이나 공학 분야를 전공하지 않은 부모님이나 친척, 다른 학교/과에 다니는 친구들, 다른 직업을 가진 사람들은 어떠하겠는가? 그래도 나같은 경우는 부모님과 대화를 많이 하는 편이라 어렸을 때부터 계속 관심사의 변화를 서로 추적·공유해왔기 때문에 전문적인 내용은 몰라도 대충 서로 뭘 하고 있다는 것 정도는 이해하지만, 같은 전산 전공 친구들도 보면 '공부'는 꼭 책상에 앉아서 책펴고 하는 것이라는 생각에 집에서 컴퓨터를 못하게 한다거나 하는 경우를 볼 수 있었다. 아마도 현재 개발자라는 직업을 가진 분들 중 다수가 어린 시절 이런 경험을 하셨으리라 짐작한다. 요즘은 많이 바뀌었지만 대신 '그런 3D 업종을 누가 하냐'라는 이야기가 많아진 듯하다.
프로그래밍이라는 그 자체를 들여다보면 매우 재미있는 활동이다. 칙센트미하이 교수가 쓴 『Flow』라는 책에서 말하는 '플로우' 상태에 빠기지 딱 좋은 예가 바로 프로그래밍이다. 다만 개발자가 3D 업종이 되는 건 그러한 플로우 상태를 방해하는 외적 요인(흔히 말하는 갑을병정 관계 같은 것들)이 프로그래밍의 자기목적성을 해치기 때문이다. 어쨌든, 끊임없이 눈앞의 작은 목표(기능·함수 단위의 구현 따위)를 두고 제대로 실행되었을 때의 적절한 피드백 타이밍 등은 플로우의 조건으로써 충분하다. 물론, 수학이나 물리학 같은 다른 이공계 과목들에서도 충분히 이런 플로우는 가능하다. 문제는, 전산 전공자가 다른 학문에서의 플로우 상태를 이해하거나 경험하기는 비교적 쉬운데, 반대의 경우는 힘들다는 것이다. 왜 그런 것일까?
내가 생각하건대 다양한 원인 중에서 하나를 꼽자면 교육의 문제라고 볼 수 있을 것이다. 주변에서 '전산 잘 하는 애들 보면 머리가 굉장히 좋은 것 같애'라는 말을 심심찮게 들었는데, 그렇게 말하는 사람들의 생각을 가만히 따져보면 스스로 터득해온 과정을 놀라워하는 경향이 있다. 대체로 중고등학교 무렵에 프로그래밍을 잘 하는 사람들은 거의 독학이기 때문이다. 나도 체계적으로 전산 지식을 배운 건 대학 와서이지 그 전엔 고등학교 때 C++을 거의 문법 수준으로만 배운 게 전부였다. 하지만 프로그래밍 자체는 초등학교 때 이미 시작했다. (물론 올림피아드 준비 등으로 학원에 다니거나 집중 훈련을 별도로 하는 경우도 있다.)
사람들은 왜 그 과정을 놀라워할까? 프로그래밍을 책만 보고 공부하는 건 마치 피아니스트가 악보만 읽고 곡을 끝내는 것과 같다. 실질적인 스스로의 노력과 의지에 의한 연습 과정(우리 식으로 말하면 삽질-_-)이 많이 필요하다. 적어도 대학 입학 전까지의 다른 분야들은 그러한 삽질 없이 외부 의지(부모님의 압박이나 학원의 압박 등)로 때워지(는 것처럼 보이)고, 그렇게 공부해왔던 사람들에겐 그 누구한테도 배우지 않고 혼자 그 복잡한 프로그래밍을 터득해가는 과정이 신기해보일지도 모르겠다. 하지만 다른 분야들도 프로그래밍을 공부하는 것과 같은 방식으로 이루어지는 것이 궁극적으로 가장 바람직한 방향일 것이다. 그만큼 응용력과 창의력이 높아질 수 있다.
한편, 프로그래밍을 하는 사람들에게 발생하는 문제점도 있는데, 바로 인간 관계와 사회성의 결여다. 보통 학생 시기에 프로그래밍을 독학하는 사람이 자료를 얻는 출처는 거의 90% 이상이 인터넷 커뮤니티나 각종 레퍼런스 사이트다. 그러다보니 아무래도 온라인 상의 활동에 치중하게 되고, 독학의 특성 상 누군가 옆에서 체계적으로 지도해주지 않기 때문에 한쪽으로 치우친 성향을 갖기 쉽다. 글로 대화하는 능력은 뛰어난데 실제 얼굴을 마주보고 대화하는 능력이 점점 떨어지고, 점점 더 논리적으로만 소통하려고 하게 된다. 이것은 주변인들이 '재미없는 사람'으로 인식하게 되는 가장 큰 요인이다. 또한 플로우에 쉽게 빠지는 만큼, 운동이나 친구들과의 놀이 등 다른 사회적 활동에 소홀하게 되는 경우가 많고, 사람마다 다르긴 하지만 일반적으로 학과 성적은 떨어지는 경향이 나타나기 때문에 부모들과의 관계도 나빠진다.
동아리 프로젝트도 해보는 등 여러 사람들과 함께 프로그램을 짜면서부터, (나를 포함해) 사람들이 능력이 안 되어서가 아니라, 순전히 의사소통 방법의 미숙함에서 오는 문제가 굉장히(사실은 거의 다) 많다는 것을 깨달을 수 있었다. 같은 프로그래밍을 하는 사람들끼리도 발생하는 문제인데 다른 사람들과 대화할 때는 더욱 심한 것이 당연한 것이다. 뭐랄까, 이런 면에서 생각해본다면 프로그래머와 일반인들 사이의 가교를 놓아줄 수 있는 사람이 필요할 것 같다는 생각마저 든다. (최근의 신생 직업 중 하나인 Web Publisher도 개발자와 디자이너 사이의 아교 역할을 하는 것처럼.)
결론적으로 창의성을 기를 수 있는 스스로의 의지와 노력에 의한 공부, 그 과정에서 지나치게 불필요한 삽질을 막아주는 적절한 지도자가 있다면 다른 학문을 배우는 것이 프로그래밍을 배우는 것과 보다 유사해질 것이고, 전산 전공자들과 타 전공자들 사이의 간극을 좁히는 데 도움이 될 것이다. 또한 프로그래밍을 독학한 사람들에게서 나타나는 사회성 부족을 채우기 위해서도 절제력을 길러줄 수 있는 지도가 필요할 것이다. 이와 함께 발전적인 토론과 전문 지식의 의사소통 방법도 체계적인 교육이 꼭 필요하다. (물론 이것만이 전부는 아니겠지만, 프로그래머의 긍정적 geek스러움이라는 것의 원천이 어디서 나왔는지, 또 반대로 프로그래머는부정적 의미의 geek스러움에서 벗어나기 위해서 어찌해야 할 지 서로 이해하는 데 도움을 줄 것이다) 현재까지 내가 보고 듣고 느낀 교육과정이 양쪽에게 모두 심각한 문제가 있다. 이런 문제들이 지금 우리가 느끼는 프로그래머와 일반인들 사이의 괴리감·이질감을 발생시킨 여러 원인들 중 하나다.
다시 처음 이야기로 돌아와서, 대안언어 축제와 그와 비슷한 행사들을 통해 전산 전공자와 비전공자 사이들이 함께 뭔가 창조적인 활동을 하게 하고 싶다는 김창준 님의 그 글은, 지금의 다소간 답답한 상황을 풀어줄 수 있는 아주 긍정적인 시도로 평가하고 싶다. 비록 근본적으로 사람들의 인식을 바꿔놓기는 어렵지만(위에서 언급한 교육의 문제 해결은 아니므로), 그런 활동에 참여하는 프로그래머나 다른 분야 사람들 모두 새롭고 놀라운 경험이 되리라 믿는다.
덧붙여, 내가 미래에 하고 싶은 일이 바로 그런 융합이다. 단순히 프로그래밍 혹은 전산 분야만 하기보다는, 전혀 다른 분야의 사람들과 협력하여 창조적인 일을 해보는 것이다. 프로그래밍 그 자체도 무척이나 매력 있는 활동이지만, 그보다는 내가 가진 다양한 재능과 관심―피아노 연주, 작곡·편곡, 그림 그리기, 디자인, 생물학, 신경과학 및 인지과학, 물리학과 천문학, 로봇공학과 기계공학 등―들을 하나도 남김없이 충분히 활용하고 싶다. 내가 가진 전산학과 프로그래밍에 대한 지식과 기술들은 그런 활동을 하는 데 기초가 되어줄 수 있을 테고, 그동안 살면서 지속적으로 다른 분야에 관심을 가져왔던 것은 아교 역할을 해낼 수 있을 것이다.
PHP 6.0
드디어 php6에 대한 논의가 이루어지는 모양이다. (실은 2005년 말부터라고..-_-)
php4에서 php5로 넘어가면서 가장 크게 달라진 점이라면 완벽한 OOP의 지원일 것이다. php4에서도 부분적으로는 지원하고 있으나 버그도 많고 불완전한 형태여서 아직까지는 많은 웹어플리케이션들이 이를 제대로 활용하고 있지 못했고, 이제서야 Symfony와 같은 프레임웍들이 본격적으로 php5 전용으로 개발되고 있다. (아직도 배포용 웹어플리케이션은 하위호환성을 지켜야 하는 것이 현실이나 프레임웍처럼 CMS 수준의 사이트 단위로 쓰이는 것들은 하위호환성을 깨기 시작했다.)
그런 와중에 들려온 php6은 더욱 기대가 된다. 우선 내 입장에서 가장 크게 반기는 것이라면,
- register_globals, magic_quotes, safe_mode가 마침내 사라진다.
- 64비트 정수 추가
- 유니코드 지원 추가
- ?: 연산자의 추가 - $a ?: $b는 $a ? $a : $b와 같은 동작을 한다.
- 문자열에서 문자를 액세스할 때 {}와 []를 쓸 수 있던 것을 []로 통일하고, []에 범위를 쓸 수 있다. (substr() / array_slice() 처럼)
- 이름 공간(namespace) 추가
- 메소드의 리턴 타입 힌팅 추가
- microtime()이 문자열이 아닌 float를 리턴한다.
특히 sql injection 등을 막기 위해 mysql 쿼리문을 작성할 때마다 addslashes/stripslashes 등을 해주는 게 여간 귀찮은 게 아니었는데(더군다나 배포용 프로그램의 경우 서버마다 설정이 다 다르니 말이다), 아예 옵션을 없애버린다면 한 가지 방법으로 일관되게 처리할 수 있을 것이다.
어쩐지 php가 점점 C++/Java화되는 것 같다는 느낌을 지울 순 없지만(특히 리턴타입 힌팅 같은 것들), 점점 강력한 웹어플리케이션을 만들고 대규모의 개발을 가능하게 하기 위해선 어쩔 수 없는 선택이기도 하다. 나름대로 많이 익혀왔고 재밌게 써온 php가 더욱 발전하길 바라며, 무엇보다도 국내 호스팅업체들의 발빠른 업그레이드(ㅠㅠ)가 있었으면 좋겠다.;;
