· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
강창기

Haxe and SWFMill


Haxe는 정말 만능 언어이다. 이번에 아바타 프로젝트를 하면서 SWF를 생성하는데 사용했는데 이것은 빙산의 일각이다.

SWFMill XML로 SWF 파일을 만들 수 있다.

꽤 재미있는 기술인데 전부 오픈소스이다. SWF 파일을 서버쪽에서 조작하기에는 아주 좋다.

Apache Velocity


Java template engine이다. 꽤 쓸만하다. Java 라이브러리 치고는 꽤 간편했다.

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의 나아가야 할 방향이라고 믿고 있다.

Hibernate, iBatis, Apache Commons DBUtils, ActiveRecord


Hibernate는 mapping configuration file을 생성시켜주는 툴을 사용하면 더 편리하게 사용할 수 있었다.

iBatis는 중앙에서 SQL을 관리해주는 장점이 있고 SQL의 표현력을 그대로 사용할 수 있다는 장점이 있었다.

Apache Commons의 DBUtils를 사용해 봤는데 꽤 간편하고 쓸만했다.

Active Record 패턴은 언어와 결합된 형태이기 때문에 Hibernate와 같은 방식보다 더 쉽게 사용할 수 있는 장점이 있다. RoR의 ActiveRecord는 정말 좋았다.

Spring and AspectJ


Spring은 DI 전용으로 사용하는 것이 좋다. AOP는 정말 좋지 않다. 특히 동적 방식으로 동작하기 때문에 성능이 좋지 않다.

반면 AspectJ는 정말 컴파일시에 코드를 생성하는 방식으로 동작하기 때문에 성능상 뛰어나다. 거기에 더해서 Eclipse의 AspectJ 플러그인을 사용하면 더 쾌적하게 코딩할 수 있다.

그런데 AOP 방식으로 프로젝트를 진행하려면 코딩 규약을 지키는 것이 중요해진다. 왜냐하면 point cut을 잘 지정해야 advice를 잘 연결 시킬 수 있기 때문이다.

또한 개발 순서에도 영향을 미치는데 iterative development 방식으로 해야 한다. 기본이 되는 중요 기능을 먼저 구현하고 나서 이것에 계속 덧붙여서 개발해야 한다.

Apache Typestry and Apache Wicket


예전에 Typestry를 살펴본 적이 있는데 컴포넌트 방식의 웹 개발이라는 것이 맘에 들었었다. 그런데 Typestry의 약점은 도대체 문서가 없다는 것이었다.

이번에 Wicket을 보게 되었는데 Typestry 보다 더 깔끔해진 구조가 맘에 들었다. 게다가 비교할수 없을 정도로 풍부한 문서가 있었다. 정말 맘에 든다.

그러나 문제는 둘다 컴포넌트 방식이라서 HttpReqeustHttpResponse를 밖으로 노출시키지 않는다. 그렇기 때문에 그것을 사용하는 라이브러리가 있다면 같이 사용할 수 있는 수단이 없어진다. 패러다임이 바뀌면서 모든것이 같이 바뀔수 밖에 없는 구조이다. 그런 이유로 쓰고 싶어도 쓸수 없다. 残念

GWT


GWT는 JUnit으로 테스트 스위트에 포함시킬 수 있다는 것 만으로도 정말 중요하다. 이것은 생각보다 중요한데 과연 Javascript를 엔지니어링 할수 있을 것인가? Selenium IDE로 Javascript 테스트 스위트를 따로 구성하게 되면 continuous integration을 어떻게 구성한단 말인가.

Subversion


얼마전부터 SVN을 콘솔로도 사용하기 시작했다. 일반적인 작업은 콘솔이 더 편하고 diff나 log를 확인하는 것은 그래픽 환경이 더 좋다.

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개월이란 시간을 폐인으로 지냈다. 또한 이 책 자체만으로 이해가 안되는 부분이 많았었다. 그래서 각종 자료를 따로 찾아보아서 겨우 이해한 것도 많았었다.

OpenOffice.org


생각보다 잘 만들어진 툴이다. 과연 이것을 사용해서 프로그램을 자동으로 생성시킬수 없을까? 아직까지는 MDA는 멀었다고 생각한다.

일본의 개발 환경에 대한 생각


일본에서 본 것중에 하나가 MS Office를 사용해서 프로그램 개발 과정을 자동화시킨 것이었습니다. 하지만 이런 것에 저는 부정적인 시각을 가지고 있습니다. 프로그램은 한번에 개발되지 않으며 여러번 고쳐가면서 개발하게 됩니다. 그렇기 때문에 개발 문서와 개발 산출물(application)간의 연계가 중요합니다.

개발 문서에서 개발 산출물의 방향으로만 되어 있는 것이 문제라고 생각합니다. 양쪽 방향으로 원활하게 움직일수 없다면 개발과 문서가 분리되어 존재하게 될 수 밖에 없고, 그것을 맞추기 위해서는 많은 노력이 드는 것이 사실입니다.

RUP에서는 이것을 Iterations로 해결하고 있고, XP에서는 문서를 테스트케이스로 만들어서 해결하고 있습니다. 제가 생각하는 가장 좋은 방법은 XP형식의 실행이 가능해서 검증을 자동으로 수행할수 있는 문서의 형태입니다.

일본


일한정보시스템. 2007 NCsoft Japan. 2007-2008 ? 2008-?

Who Am I


  • 주력언어: C, C++, Java, Ruby, Scheme, 영어, 일본어

    • 영어는 영어로 된 책과 글을 많이 읽다 보니 저절로 말을 할 수 있게 되었습니다. 뉴스 받아쓰기를 하면 귀도 트입니다. 나중에 영국문화원에서 다시 영어를 배웠습니다.

    • 일본어는 한국정보통신인력개발센터에서 배웠습니다. 일본에 취직하는 코스이므로 정말 빡세게 가르칩니다.

  • 사용해본언어: Scheme, Lisp, Haskell, Python, Perl, Pascal, Fortran, COBOL 등등

    • 훌륭한 프로그래머가 되기 위해서는 1년에 1개의 새로운 언어를 익혀야 한다는 말을 듣고나서 실천하고 있는 중 입니다. 제가 듣기로는 언어의 패러다임이 완전히 다른 새로운 언어를 익혀야 문제 해결의 새로운 생각을 틀을 키울 수 있다고 합니다.

  • 툴: Eclipse, RationalRose 2000, ERWin, 종이, 펜, index card, white board, 카메라, Ruby

    • Eclipse를 너무 좋아해서 초창기때 부터 사용하고 있습니다. Eclipse 기능 중에서 가장 좋아하는 기능은 역시 JUnit 내장, refactoring, 그리고 template 기능 입니다.

    • 분석, 설계, 모델링을 할때는 절대 low tech 툴을 사용합니다. 그 다음에 툴로 옮깁니다.

    • Ruby는 스크립트 언어이지만 이것만큼 강력한 툴이 없습니다. 뭐든지 필요한 것을 빨리 만들수 있고 쉽습니다.

  • 기술1: Database Modeling, 객체지향 분석/설계 그리고 RUP, 엉뚱하지만 XP, AM(Agile Modeling), Design Pattern

    • 객체지향 분석/설계는 대학시절부터 관심을 가지고 있었던 분야였습니다. RUP는 박영만 전산학원(SE 125 기) 이라는 곳에서 처음 접했습니다. 그 다음에는 책을 보면서 익혔는데 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development와 Writing Effective Use Cases 라는 책이 크게 도움을 주었습니다.

    • 그러던 중에 엉뚱하게 읽었던 Refactoring: Improving the Design of Existing Code 라는 책이 저를 XP로 이끌었습니다. 그렇게 해서 wiki, 김창준씨, xper.org 등등을 알게 되어 이제는 XP를 사용할 수 있습니다.

    • XP 다음에 DB 설계에 XP의 원칙을 적용하면 좋겠다는 생각이 저를 AM(Agile Modeling)으로 이끌었습니다. 저는 이전에 Database Modeling을 정규화(1NF, 2NF, 3NF, BCNF)를 통해서 했었다가 패턴에 의한 Database Modeling을 바꾸었는데 AM을 계기로 Test에 의한 Modeling 방식으로 바꾸게 되었습니다.

    • 사실 RUP와 XP를 서로 다른 개념이 아닙니다. 사실 공통점이 아주 많습니다. 그리고 Jolt Award에 나온 책은 반드시 읽어두는 것이 좋습니다.

  • 기술2: JSP/Servlet(MVC), Ruby on Rails, Oracle 9i, MySQL, MS-SQL, CVS, Subversion, JUnit, Ant, Maven2

    • 방랑벽이 도져서 일본에 가보고 싶다는 생각이 들었고 한국정보통신인력개발센터에 들어가서 IHD 7기가 되었습니다. 아무래도 다른 방법보다는 안전하다는 생각도 있었고 일본어도 배울겸 몰랐던 웹 프로그래밍도 배울 겸 했습니다. 그곳에서 JSP/Servlet을 배웠습니다.

    • Ruby on Rails는 Ruby에 대해서 관심을 가지고 있었기 때문에 자연히 옮겨가게 되었습니다. 과연 편하더군요. 하지만 Eclipse의 WTP도 만만치 않더군요.

    • 버전관리는 필수입니다. 그런데 CVS는 너무 느려서 Subversion으로 옮겼습니다.

    • JUnit은 Unit test tool이기도 하지만 쓰기에 따라서 만능툴 이기도 합니다.

  • 해본일:

    • 각종 Turbo-C/C++/DOS 조합의 프로그램들.
    • 각종 VisualC++/MFC/Win32 조합의 프로그램들.
    • 한국올림푸스ERP - VisualC++/MFC, MS-SQL, RationalRose 2000(OJT-SE125)
    • 그룹웨어 서버 - Java, Socket, Jxta(오성링크)
    • 메신저 서버 - Java, Socket(오성링크)
    • 인터넷서점사이트 - Java, Servlet/JSP, Oracle 9i, Ruby, Eclipse WTP(Servlet/JSP 프로젝트-한국정보통신인력개발센터)

  • 취미: Pair Programming, 세미나 참석하기, 술마시기

    • XP의 습관 중 하나인 Pair Programming을 해보면 프로그래밍에 대한 재미를 느낄 수 있습니다. Pair Programming 이란 것은 두 사람이 한 컴퓨터를 사용해서 프로그램을 만드는 것입니다. 재미있습니다. Ruby문화에서는 Kata라는 것이 있습니다. 마치 가라데의 품세처럼 미리 정해진 문제를 반복해서 푸는 것 입니다. 매번 전에 했던 방식과 다른 방식으로 해보면 그 문제를 다른 시각으로 볼 수 있습니다.

    • 저를 C++, Win32 프로그래머에서 Java 프로그래머로 바꾸어 놓은 계기는 Java tech days라는 행사였습니다. 그 전에는 Java라는 언어를 알고만 있었는데 적극적으로 공부하게 되었고 결국 Java 프로그래머가 되었버렸습니다.

    • 대안언어축제(Altlang.org) 첫회에 참여했습니다. 역시 재미있더군요. 거기서 임시로 Code Battle을 했었는데 우승을 해버리고 말았습니다.

문서 번역


우연히 HowToBeAProgrammer 라는 문서를 보았고 그 문서가 번역되고 있다는 걸 알게 되었습니다. 작으나마 보탬이 되고 싶어서 번역에 참여하게 되었습니다. 실제적인 대부분의 번역과 교정을 처로님이 하셨습니다. 저는 별로 한일도 없는데 이렇게 이름을 올려주시네요.

Ruby, Ruby on Rails


아래에 있는 글을 오래전에 작성한 것입니다. Ruby와 Rails에 대한 관심은 계속 가지고 있지만 업무에 바빠서 요즘은 많이 하지 못하고 있습니다.



Ruby와 Rails에 관심이 많습니다. 지금 그것과 관련된 프로젝트를 운영하고 있습니다.


제가 번역을 하게 만든 첫 글이 바로 이 HowToBeAProgrammer 였습니다. 감사합니다.

저에게 연락하고 싶으시다면 changki.kang_at_gmail_dot_com 으로 연락을 주십시오.



Ruby on Rails: An Interview with David Heinemeier Hansson 복구완료


그런데 한글 문서 프로젝트에 있는 글도 살아 있습니다. 단지 rubykr.org의 서버가 불안해서 원문에 있는 한국어버전 링크를 이곳으로 옮겼을 뿐 입니다.

Dear 김창기

HowToBeAProgrammer 가 번역완료되었다 생각하여 작업일지에서 제거하였습니다. --CN


ID
Password
Join
Let not the sands of time get in your lunch.


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2008-05-14 15:12:42
Processing time 0.0122 sec