Method Chaining in POJO/DTO/JPA/Hibernate Persistence Objects 포스트를 보고 유관 내용을 엮어서 메모 화두로 던진 method chaining(이하 MC) 개념 정리는 역시 위키피디아(http://en.wikipedia.org/wiki/Method_chaining)에서 Method chaining is a common technique for invoking multiple method calls in object-oriented programming languages. Each method returns an object (possibly the current object itself), allowing the calls to be chained together in a single statement. 가장 먼저 드는 궁금증은 Fluent Interface(이하 FI)와 차이다. 또, 위키피디아(http://en.wikipedia.org/wiki/Fluent_interface) 내용에 따르면 FI는 읽기 좋은 코드를 만들기 위한 객체지향 API 구현방안의 하나로 설명한다. 하지만, 구현 방안으로는 보통 method chaining을 쓴다고 설명한다. 즉, FI 실현의 사용 예를 하나만 들었다. 분명히 표현하는 개념이 다르긴 하지만, 새로운 구현 방법을 찾..

사회 문제를 다양한 관점에서 진보적 시각에서 두루두루 옴니버스 형식으로 다루고 있다. 보수적인 분들에겐 비추. 가장 인상적인 내용은 2장 중에서 20대에 대한 기성세대의 왜곡된 시선을 비판하는 '20대는 찌질이? 486한테 보고 배운 것뿐인데'이다. 그리고, 메모하고픈 구절은 다음 2가지 내용이다. 누군가의 '대박'뒤에는 노동자에 대한 '착취'가 반드시 존재하는 것입니다. 그렇다면 1997 ~ 1998년을 기점으로 한국 사회에 무슨 일이 있었던가요? 정부의 공식 통계를 봐도, 1997년 이전에는 비정규직이 250만 명이 안 되었습니다. 그런데 2009년도 비정규직은 570만 명입니다. 정부 통계를 그대로 따라도 노동자 300만 명이 정규직에서 비정규직으로 전락했습니다. 1997년 이전에 월 250만 원을 받았던 노동자 300만 명이 이제는 150만 원씩 월급을 받고 일하는 것입..

요즘 내가 처한 상황을 설명하는 네 글자다. 장미빛 미래를 그리며 달려왔으나 돌아보니 내우외환에 처했다. 내면에서는 갖가지 핑계가 떠오르지만, 결국 내 선택과 행동에서 비롯된 일이다. 이번 일을 계기로 책임감을 배우고, 능력의 한계를 확인할 수 있다고 단호하게 다짐해보지만, 사실은 힘들어 하는 스스로에 대한 위로다. 나약한 감상에 빠지지 않기 위해 이번에 내가 배워야 할 사실을 명확히 해봐야겠다. 관련 글: 내우외환의 유래

Toby 형이 (묻지도 따지지도 않고) 보내준 기사를 어제 퇴근 길에 읽었다. 성철형이 찾아낸 링크를 통해 누구나 구할 수 있다. 무려 97년 글이지만, 상당 부분은 프레임워크 이해에 도움을 준다. 그래서, 간단히 메모해둔다. Frameworks are a component in the sense that venders sell them as products, and an application might use several framewkrs. 프레임워크도 컴포넌트 일종으로 보는 근거로 두 가지를 제시한다. 제조사가 판매하고 이를 애플리케이션에서 사용할 수 있기 때문. 하지만, 다른 컴포넌트와 구분해야 하는 이유를 역시 두 가지로 제시한다. frameworks provide a reusable context for components frameworks make it easierto develop new components 프레임워크가 컴포넌트가 재사용하는 맥락(context)을 제공하고, 새로운 컴포넌트 개발을 쉽게 해주기 때문. 두 번째 흥미로운 내용은 프레임워크를 설..

다시 블로깅을 한다고 해놓고 휴업 중이다가 폭발적인 소재는 아니지만, 친한 두 사람의 논쟁에 괜히 끼고 싶은 마음에 몇 자 적는다. 무릇 논쟁을 하려면 문헌을 찾아가며 사실에 기초하는 태도가 옳다고 하겠으나 그랬다가는 쓰다가 포기할 것이 뻔하고, 할 일도 많아서 오래전 대학원에서 공부한 내용과 일하면서 습득한 내용을 버무려서 개입하려고 한다. 그래서, 읽는 이의 오류를 줄이기 위해서 주장의 근저에 있는 가치관을 밝히면 나는 대체로 문헌에 대한 정확한 해석보다 지식을 현장에서 어떻게 활용하느냐 하는 실용적인 측면을 중시한다. 프레임워크 = 디자인 패턴 + 라이브러리 논쟁의 시발점이 된 문구인 듯하다. 직관적으로 느껴지는 생각은 야매(?)스럽지만, 간결한 맛이 있어 괜찮아 보이는 구석도 있다. 골똘히 생각해보니 야매스러움..

출근 길에 DDD 번역 내용 검토를 하다 120% 공감하는 내용이 있어 블로그에 담는다. 바쁜 와중에 가장 좋아하는 책 중에 하나인 DDD를 후배가 번역을 해 검토를 돕고 있다. 사실, 번역 검토까지 거들 여력은 없는데, DDD 책을 번역하겠다고 덤벼든 장본인이 바로 나이기 때문에 나몰라라 할 수가 없었다. 블로그를 뒤져보니 2006년에 흔적이 남았다. 각설하고 다시 책 내용으로 넘어가서 공감했던 내용을 발췌하면... 문제는 사람들이 UML을 통해서만 전체 모델이나 설계를 전달해야 한다고 느낄 때 생긴다. 많은 객체 모델 다이어그램은지나치게 완전한 동시에 많은 부분이 생략돼 있다. 전체 모델이 지나치게 완전해지는 까닭은 사람들이 앞으로 코딩할 것을 죄다 모델링 도구에 집어 넣어야 한다고 생각하기 때문이다. 이러한 모든 세부 사항이 존재하는 상황..

1. 당신은 왜 애자일을 선택했습니까? 알다시피(?) 여러 가지 이유로 SI 프로젝트가 수렁에 빠지는 일이 다양하다. 프로젝트 경험에서 배운 바는 프로젝트 계획 수립과 계획 이행의 경직성이 수렁에 빠지는 프로젝트가 밖으로 빠져 나오지 못하게 막는 장치가 되는 모습을 다 년간 목격했기 때문. 그리고, 주로 기사를 통해 배운 애자일 실천방안은 개인과 팀의 성숙도 향상을 위해 매우 유익하다 판단해서. 다시 말해서 '애자일 or Not' 같은 식의 판단은 경험이 부족한 이가 접근하는 방식이고, 반복이 주는 이점과 진화라는 원리를 어떻게 차용할까 구체적인 방법을 찾아야 한다고 확신함. 2. 애자일 선언문(Agile manfiesto) 중 생각나는 부분이 있다면 어느 부분인가요? 외우는 데 소질이 없어서 블로그에 여러 차례 인용했지만 문구는 기억이 안남. 어구는 모..