강창기
Haxe and SWFMill ¶Haxe는 정말 만능 언어이다.
이번에 아바타 프로젝트를 하면서 SWF를 생성하는데 사용했는데 이것은 빙산의 일각이다.
SWFMill XML로 SWF 파일을 만들 수 있다.
꽤 재미있는 기술인데 전부 오픈소스이다.
SWF 파일을 서버쪽에서 조작하기에는 아주 좋다.
JSON and JAXP ¶data를 전달하고 전달받을 경우가 많다.
이번 아바타 프로젝트에서 XML을 사용해서 data 송수신을 처리하는데 JAXP를 사용했다.
항상 느끼는 거지만 Java쪽은 간단한 일에 너무 복잡한 구조를 가지고 있다.
성능을 위해서 패턴의 컴파일을 분리시키 것은 좋다.
하지만 꼭 이런식으로 factory의 factory를 도입하는게 옳았는지는 모르겠다.
이제는 으례 Java하면 복잡한 구조가 나올거라고 짐작하고 어느정도 포기를 하고 있는 상태이지만.
반면 JSON은 매우 직관적이고 간편한 구조를 가지고 있었다.
표기 자체도 그러하지만 Java 라이브러리도 그러했다.
Apache Commons ¶왜 다른 프레임워크를 배우는 것보다 Apache Commons를 배우는 것이 더 유익한가?
Apache Commons는 여러 Apache 프로젝트를 수행하면서 공통된 부분을 추출한 것이다.
즉, refactoring된 공통 코드이다.
이런 라이브러리는 더 많은 사용 범위를 가지고 있다.
어떤 일을 해야 해서 관련된 프레임워크를 사용하는 것보다 Apache Commons 라이브러리를 사용하는 것이 더 간편한 경우가 많다.
게다가 요즘의 프레임워크는 너무 비대해져 있다.
내가 쓰고자 하는 기능 때문에 대부분의 필요없는 부분까지 같이 포함되는 경우가 많다.
이런 경우에 Apache Commons는 제 역할을 한다.
Maven and CI ¶Maven은 개발을 편하게 해준다.
1. 프로젝트를 빨리 시작할 수 있게 해준다.
2. binary의 버전을 관리해준다.
3. continuous integration과의 연계를 쉽게 해준다.
1, 2도 꽤 편리하다.
하지만 3번의 경우는 개발 프로세스에 관련된 기능이므로 더 중요하다.
CI는 정말 중요하다.
우리가 필요한 것은 정말로 돌아가는 결과물이다.
어디선가 숨겨진 뒷면에서 깨진체 돌아가는 프로그램이 아니라 항상 테스트가 마쳐진 실제 돌아가는 결과물이 필요하다.
이것은 심리적으로도 팀원들에게 자신감을 심어주고 관리자에게는 모든것이 잘 되고 있다는 확신을 준다.
코드는 변화에 반응하여 refactoring된다.
이 얼마나 아름다운 모습인가.
Maven을 사용하면 Cruise Control이나 Continuum과 같은 Continuous Integration Server와 개발 프로세스를 연계시킬 수 있다.
그냥 surefire plugin을 사용해서 test cases를 돌리는 것이 아니라 서버에 올리고 테스트를 수행하고 리포트를 하는 기능을 콘솔에서 수행할 수 있다.
Emacs ¶Scheme을 알고나서부터 Lisp의 코드가 반갑다.
더불어 Emacs의 강력함에 눈뜨게 되었다.
당장 모든 서버에 몰래 Emacs를 깔아서 쓰고 있다.
이 편한걸 왜 그동안 몰랐었을까?
AM과 RoR의 migration ¶RoR의 migration은 한번 써보면 그 유용성을 깊이 느끼게 된다.
Database의 형상 관리는 정말 필요하지만 이에 대한 인식은 정말 낮다.
이것에 더 나아간 Agile Modeling은 더더욱 관심을 못받고 있다.
하지만 나는 이것인 Database Modeling의 나아가야 할 방향이라고 믿고 있다.
Spring and AspectJ ¶Spring은 DI 전용으로 사용하는 것이 좋다.
AOP는 정말 좋지 않다.
특히 동적 방식으로 동작하기 때문에 성능이 좋지 않다.
반면 AspectJ는 정말 컴파일시에 코드를 생성하는 방식으로 동작하기 때문에 성능상 뛰어나다.
거기에 더해서 Eclipse의 AspectJ 플러그인을 사용하면 더 쾌적하게 코딩할 수 있다.
그런데 AOP 방식으로 프로젝트를 진행하려면 코딩 규약을 지키는 것이 중요해진다.
왜냐하면 point cut을 잘 지정해야 advice를 잘 연결 시킬 수 있기 때문이다.
또한 개발 순서에도 영향을 미치는데 iterative development 방식으로 해야 한다.
기본이 되는 중요 기능을 먼저 구현하고 나서 이것에 계속 덧붙여서 개발해야 한다.
Apache Typestry and Apache Wicket ¶예전에 Typestry를 살펴본 적이 있는데 컴포넌트 방식의 웹 개발이라는 것이 맘에 들었었다.
그런데 Typestry의 약점은 도대체 문서가 없다는 것이었다.
이번에 Wicket을 보게 되었는데 Typestry 보다 더 깔끔해진 구조가 맘에 들었다.
게다가 비교할수 없을 정도로 풍부한 문서가 있었다.
정말 맘에 든다.
그러나 문제는 둘다 컴포넌트 방식이라서 HttpReqeust나 HttpResponse를 밖으로 노출시키지 않는다.
그렇기 때문에 그것을 사용하는 라이브러리가 있다면 같이 사용할 수 있는 수단이 없어진다.
패러다임이 바뀌면서 모든것이 같이 바뀔수 밖에 없는 구조이다.
그런 이유로 쓰고 싶어도 쓸수 없다.
残念
GWT ¶GWT는 JUnit으로 테스트 스위트에 포함시킬 수 있다는 것 만으로도 정말 중요하다.
이것은 생각보다 중요한데 과연 Javascript를 엔지니어링 할수 있을 것인가?
Selenium IDE로 Javascript 테스트 스위트를 따로 구성하게 되면 continuous integration을 어떻게 구성한단 말인가.
Javascript, Mootools and Firebug ¶NCsoft Japan에서 새롭게 눈뜬 것중의 하나가 Javascript의 유용함과 Mootools라는 Javascript library였다.
사실 대부분의 Java프로그래머들이 Javascript를 무시한다.
하지만 웹 환경에서 Javascript는 정말 강력했다.
Javascript와 Java는 서로 다른 언어이다.
Javascript는 최초의 널리 사용되는 함수형 언어이다.
단지 마케팅상 Java의 이름과 일부 Java언어의 문법이 들어갔지만 함수형 언어의 특징인 lambda와 closure가 존재한다.
Javascript를 잘 사용하면 정말 웹 프로그래밍이 쉬워진다.
또한 거기에 더해서 일반적인 웹 프로그래밍에서 불가능한 것도 가능해진다.
Javascript는 원래 웹의 presentation logic 부분을 도맡아서 처리하기 때문이다.
그 위에 잘 만들어진 library가 올라가면 더욱 강력해진다.
JQuery, Mootools, Prototype 등등 수많은 library가 존재하지만, 그중에서 가장 활용도가 뛰어나다고 생각했던 Mootools를 사용하고 있다.
거기에 Firebug까지 합세하면 정말 못하는게 없을 지경이 된다.
하지만 정말 동적인 환경을 만들기 위해서는 역시 Flash가 들어가야 한다.
또한 SEO를 고려해서 사용해야 한다.
Structure and Interpretation of Computer Programs ¶이 책이 처음 보는 것은 아니다.
사실은 꽤 오래전에 이 책을 접하게 되었었지만 너무 어려운 내용이 들어 있었기 때문에 포기하고 How to Design Programs 라는 책을 대신 봤었다.
이번에 다시 이 책을 다시 접하게 된 계기는 이 책의 한글판이 나왔었고, 이 책에 대한 이야기가 인터넷상에 많이 퍼졌기 때문이었다.
이 책에 대한 좋은 평판을 읽고 이 책을 끝까지 읽어보고 싶다는 생각이 들었었다.
그러다가 한국에 휴가를 갔게 되었는데 서점에서 이 책을 발견하게 되었다.
한참동안 서서 읽어보다가 사버리고 말았다.
과연 좋은 책이었다.
여러가지 깨달음을 얻게되었다.
Enumerate Filter Map Accumulate 같은 일종의 EDSL은 너무 좋았다.
많은 생각을 하게 되었고 SQL도 이것의 일종이라는 영감을 받게 되었다.
Iteration과 Recursion에 대해서 정말로 알게 되었다.
C 계열의 loop 보다 더 높은 표현력을 얻게 되었다.
함수를 결합하여 Abstraction을 이루는 법을 알게 되었다.
과연 함수형 언어가 왜 문제를 더 복잡하게 하지 않고 더 간단하게 만드는지 알게 되었다.
특히 수 시스템을 사용해서 거대 시스템을 설계하는 방식을 나타낸 것은 이 책이 입문서임에도 불구하고
꽤 넓은 범위를 다루고 있다는 것을 알게 되었다.
병렬컴퓨터에서 돌아가는 동시성에 대한 언급은 정말 좋았다.
왜 상태를 덮어쓰는 것이 위험한지에 대해서 알게 되었다.
상태 덮어쓰기를 대체하는 Stream 자료구조는 생각의 전환을 이루게 만들었다.
하지만 Stream 자료구조가 생각보다 쓰임새가 제한되어 있다는 느낌이 든다.
이것 때문에 Haskell의 Monad를 공부하게 되었고 결국 Haskell까지 공부하게 되었다.
함수형 프로그래밍에 대해서 새롭게 눈을 뜨게 되었다.
하지만 생각보다는 시간이 너무 오래 걸렸었다.
장장 4개월이란 시간을 폐인으로 지냈다.
또한 이 책 자체만으로 이해가 안되는 부분이 많았었다.
그래서 각종 자료를 따로 찾아보아서 겨우 이해한 것도 많았었다.
일본의 개발 환경에 대한 생각 ¶일본에서 본 것중에 하나가 MS Office를 사용해서 프로그램 개발 과정을 자동화시킨 것이었습니다. 하지만 이런 것에 저는 부정적인 시각을 가지고 있습니다. 프로그램은 한번에 개발되지 않으며 여러번 고쳐가면서 개발하게 됩니다. 그렇기 때문에 개발 문서와 개발 산출물(application)간의 연계가 중요합니다.
개발 문서에서 개발 산출물의 방향으로만 되어 있는 것이 문제라고 생각합니다. 양쪽 방향으로 원활하게 움직일수 없다면 개발과 문서가 분리되어 존재하게 될 수 밖에 없고, 그것을 맞추기 위해서는 많은 노력이 드는 것이 사실입니다.
RUP에서는 이것을 Iterations로 해결하고 있고, XP에서는 문서를 테스트케이스로 만들어서 해결하고 있습니다. 제가 생각하는 가장 좋은 방법은 XP형식의 실행이 가능해서 검증을 자동으로 수행할수 있는 문서의 형태입니다.
Who Am I ¶
문서 번역 ¶우연히 HowToBeAProgrammer 라는 문서를 보았고 그 문서가 번역되고 있다는 걸 알게 되었습니다.
작으나마 보탬이 되고 싶어서 번역에 참여하게 되었습니다.
실제적인 대부분의 번역과 교정을 처로님이 하셨습니다.
저는 별로 한일도 없는데 이렇게 이름을 올려주시네요.
Ruby, Ruby on Rails ¶아래에 있는 글을 오래전에 작성한 것입니다. Ruby와 Rails에 대한 관심은 계속 가지고 있지만 업무에 바빠서 요즘은 많이 하지 못하고 있습니다.
Ruby와 Rails에 관심이 많습니다.
지금 그것과 관련된 프로젝트를 운영하고 있습니다.
한글 문서 프로젝트 http://wiki.rubykr.org/show/KoreanDoc
Rails 적용 프로젝트 http://wiki.rubykr.org/show/RailsApplicationProject
제가 번역을 하게 만든 첫 글이 바로 이 HowToBeAProgrammer 였습니다.
감사합니다.
저에게 연락하고 싶으시다면 changki.kang_at_gmail_dot_com 으로 연락을 주십시오.
Ruby on Rails: An Interview with David Heinemeier Hansson 복구완료
그런데 한글 문서 프로젝트에 있는 글도 살아 있습니다. 단지 rubykr.org의 서버가 불안해서 원문에 있는 한국어버전 링크를 이곳으로 옮겼을 뿐 입니다.
|
   
|
