아… 정봉쥬 전위원은 프로페시아를 복용하시는구나… 정력감퇴제가 뭔가 나꼼수 듣다… 대머리 방지약인데 의사 양반도 남성호르몬 파괴약이라고 안드신다고 증언한 약… 나도 먹으려다 포기한 거임 me2mobile

favicon 바꿔달라는 얘기 오랜만에 들어보네… 고양이 톰이 뭐 어때서 그러세요~ 파비콘이 뭔지도 모르던 옛적이 떠오른다. 그 때는 못한다고 엄청 싸웠지... ㅋ me2mobile

물질적인 면에서 성공하지 못한 것은 부끄럽지 않다. 다만, 내가 20년 전에 이루었던 능력을 이제는 잊어버린 사실이 안타깝다. 나와 후배들이 씨앗 뿌린 결실로 동아리 후배들이 만든 회사가 며칠전 10주년 되었다고… 구 사이에 난 팀을 이끄는 능력을 상실했지. 후배들이 음료 시설을 구글 부럽지 않다고 자랑 me2mobile

첫 회사를 다니던 시절 뜬구름 잡는 야기를 하시던 사수가 지금은 모 컨설팅 회사의 부사장님이신데, 그러고보니 나도 참 많은 괴물들 사이에서 커왔구나… 아직 길을 헤매고 있지만 올바른 방향으로 걸어온 것 같다. 질식하지 않은 것도 다행이지 me2mobile

코드에 주석을 많이 달아야 할까? 다음과 같은 주석을 보자면, “// 동의서 발송 여부 (0: 미수신, 1: 수신)”. flag 가 코드로 확장되거나, 코드 설명이 변경되면 “정보 불일치”가 발생한다. 주석을 남용하지 말자는 얘기를 하게 된 계기가 내가 짠 코드를 리뷰하다 보니... T.T

자바는 엄격한 타입 체크로 악명 높은 언어이지만, apache commons DynaBean 같은 꼼수가 오픈소스로 제공된다는 점 때문에 다들 자바를 갑이라고 하는 것 같다. 장황한 리포트를 출력하려는데 겨우 한 번 쓸라고 클래스를 만드느니, DynaBean 으로 샥샥~ 좋다...

DDD 다시 공부하기 아주 오래만에 블로그질 다시 재개… 나도 확실히 몰랐던 자바의 숨은 진실들이 있더라. 역시, 개념으로 이해하는 것 뿐 아니라, 코드를 작성해 봐야 한다. 앞으로도 해보지 않고 아는 척 하는 인간들을 저주할테다.

기술 기반 기업에서 “교육”은 절대 양보할 수 없는 “투자”인거다. 공장에서 감가상각된 기계를 새로 사들이는 것과 같다고… 그런데, 교육 시간에 제한을 두어야 한다는 의견듣고 정 떨어져서 교육 못하겠다. 엔지니어는 무슨 물만 주면 크는 식물인가? 대학에서도 기업에서도 가르치지 않으면 어디서 배우나교...

DDD 재정리 중인데, 불변 클래스 작성을 강제할 수 있는 방법이 무얼까? 1) 철저한 교육, 2) 어노테이션 등으로 불변임을 지정하고, eye check or validator를 구현. 세상에 가장 못 믿을 게 '코드'라지만 결국 사람을 못 믿는게 문제인듯…

개념을 이해하는 것과 현실에 적용하는 사이에는 거대한 바다가 존재한다. 그 사이를 극복하는 길은 열심히 헤엄치는 것 뿐… 하아~ 푸욱 잠수해버리고 싶은 상황. 멀리 신기루가 보이는 것 같아 포기도 못하고...

역시, 은탄환은 없었다. JPA를 사용하니 CRUD가 단순해 지기는 했는데… Update는 여전히 모호하고, Join을 이용한 자유로운 데이터 조합은 불가능한 듯(?) 보이고, 통계는 아예 넘사벽 이더라. 이런 문제에 대한 해결책을 논의할 시간과 자원은 없고~ 아는 것과 경험이 늘어갈수록 고민의 깊이를 더하는구나... 사람 불러야 돼!

자바의 어노테이션을 처음 봤을 때는 뭐 저런 군더더기를 코드에 붙이고 난리야? 라는 생각도 했었는데 이제는 설계자와 개발자 간의 갈등을 해소할 수 있는 좋은 도구가 될 수 있을 것 같다는 느낌도 든다. MDA, DDD를 탁상공론이라고 생각하던 때도 있었꼬… 현실 상의 문제는 코딩을 가이드할 수 있는 설계자가 없다는 것?

열정도 중요하지만, 때로는 현실과 타협하는 자세도 필요하다. 말처럼 쉽지 않아서 문제인거지… 하고 싶은 일만 할 수도 없고, 해서도 안되는 법. 먹고 살아야 하니까...

DTO/VO/Entity 클래스 작성을 자동화하고, 날짜/주소/전화번호 입력 값 전달(변환)을 표준화해보려고 이리 저리 기술들을 알아보다가… 어노테이션, Velocity, javassist 조합이 가장 괜찮아 보이네… 10년째 같은 문제에 집착하다가, 관련 기술이 성숙하니 구현할 수 있게 되었다. 징허다~

음… 나 너무 산만한게 아닌가 싶은데… 어노테이션 공부하다가, 어느새 Javassist를 보고 있어… 물론 이걸 써먹을 일이 있기는 하지만… 과연 바른 길을 가고 있는지는 모르겠고...

소프트웨어 개발에 대한 오해 중 하나. 개발자는 책 한권 읽고 나면 그 책에 나온 내용을 곧바로 응용해서 개발할 수 있을 거라는 기대… 코드 작성도 연습과 숙련이 필요한 겁니다. 패턴을 이해하는 것과 사용하는 건 다른 문제인 겁니다. 하일성 해설위원 더러 선수로 뛰라고 하면 게임 되겠어요?

fupfin 제가 초보 개발자들을 위한 책을 읽는 이유는 함께 일하는 사람들이 대부분 초보이기 때문입니다. 저 혼자 잘하는 방식으로 일할 수는 없으니까요. ^^;

fupfin님의 감수 멘트 인용 : “프링을 왜 써야 하는지, 스프링을 쓰면 어떤 이득을 볼 수 있는지 알고 이 이점을 살려 사용하는 곳” : 이런 질문을 던져봤는데, 답 해줄 사람이 없더군요. 제 스스로 써내려가야 겠죠. 그런고로 감수하신 책부터 사야겠어요. 이번 달에 사야할 책이 5권을 넘어가고 있다... 감수하신 책이 강컴 주간 베스트 올랐더군요.

javascript 는 장난감이라는 인식이 있던 시절도 있었지만 1997년에도 server-side javascript 플랫폼이 있었습니다. 물론 그거 가지고 엔터프라이즈 솔루션을 만들었더니 만든 사람들 조차… '너희 왜 그랬어?' 이런 반응이었죠. 세상에 쓸모없는 시도는 별로 없습니다. 그리고 node.js는 꼭 살펴봐야겠네요.

“A good architecture is not created in a vacuum.” Fielding 씨의 박사 논문 중에서… 단, 한 줄의 정의에 매료되는게 얼마 만인가? 아키텍쳐를 설명하려면 문맥과 논리를 바탕으로 해야한다. 닥치고 써라 하는 글들이 넘쳐난다… 영감을 주는 논문을 만났네~