2011/01/18 00:42 Developer

asynchronous servlet in servlet3.0

servlet3.0에서는 asyncronous servlet을 지원한다.
http://blogs.sun.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3

Asynchronous Support Features
- Annotation Attributes
- Servlet Request Methods
- AsyncContext Class
- Asynchronous Listener Class

Apache Tomcat version 7.0 implements the Servlet 3.0 and JavaServer Pages 2.2 specifications
http://tomcat.apache.org/tomcat-7.0-doc/index.html

tomcat7.0부터는 servlet3.0을 지원하는데 7.0이 많이 사용하게 되면 비동기 서블릿이 많이 활용될 것으로 보인다.

Posted by ologist
트랙백0 댓글0

2011/01/16 15:04 Developer

컴포넌트의 R&R, 그리고 시스템R&R


내가 기능을 구현할 때도 컴포넌트(클래스) 간에 R&R도 애매할 때가 있다. R&R은 비즈니스 로직을 어디에 두는 가를 결정해야 하기때문에 객체지향설계 시에 매우 중요한 요소이다.

R&R은 boundary하고도 밀접하다. 이 기능에 대한 문제의 해결의 R&R은 My boundary안에 있다면 문제를 해결하는 곳에서 처리를 해야 한다. 어떤 구조적인 문제로 문제가 전파가 되는 경우라면 그 문제를 My boundry에 갇아두고 다른 곳에는 영향을 끼치기 않게 해야 한다.  

그렇게 R&R과 boundary를 만들어도 애매할 때 가장 중요한 원칙은 중복제거과 I/O throttling이다. 중복없이 역할을 가질 수 있는 방법을 찾거나 중복을 최소화해야 한다. 변경에 대해서 도메인 지식으로 가장 많이 알고 부분에서 주도권을 갖는 것으로 엑세스는 권한을 한군데로 집중해서 분산되지 않아야 한다. 둘다 애매한 경우에는 새로운 R&R을 가지는 컴포넌트를 만드는 경우가 있다. 새로운 R&R을 가지는 컴포넌트는 애매한 역할을 명확하게 만들고 그 역할의 문제를 해결해야 한다.

지난 주에는 2개의 인프라성 서비스와 회의를 할 시간이 있었다.

하나의 인프라는 새로운 기능 추가에 대한 업무를 최소화하기 위해서 중복을 허용하면서 R&R을 줄이려는 얘기를 계속한다. 원칙이나 룰도 없이 "어렵다/힘들다/공수가 많이 든다/자신이 없다"만 반복한다.

또 하나의 인프라는 이미 추가된 기능일지라도 인프라성으로 가져갈 수 있는 부분을 더 제공해서 서비스에서는 서비에 충실한 비즈니스 로직에만 집중을 할 수 있게 해준다. 오히려 너무 많은 부분에서 고려를 하는 것 같아서 메인Role에 집중을 할 수 있게 의견을 주었다. 

정확한 분석/설계으로 통해서 R&R을 정확하게 만들지 않고 업무량을 줄이기 위한 방법으로 방향성을 정하는 경우가 있다. 주로 꼼수라는 표현을 많이 쓰는데 꼼수는 또 다른 꼼수를 하게 되고 변경에 제약사항이 계속 늘어가게 된다. 이 부채의 비용은 시간이 흐를 수록 급속도로 높아져서 결국에는 전체 시스템에 부담을 주게 된다.

객체지향설계/개발을 통해서 얻는 배움은 올바른 객체지향시스템에 대해서 알수 있게 하고 더 나아가서는 조직업무에도 적용을 할 수 있는 사고이다. 다양한 사람과 큰 그림에 대해서 이야기를 하다가보면 코드를 작성할 때도 어떤 식으로 하는지 뻔히 보인다. 구분하고 나누는 것은 쉽지 않은 일은 맞지만 원칙에 맍게 끊임없이 좋은 방향에 대해서는 고민을 해야 한다. 이미 잘못되어있다면 개선하는 것 그게 우리가 해야할 일 아닌가?
 
Posted by ologist
트랙백0 댓글1

2011/01/12 10:06 Developer

Apache Cassandra 0.7 announce

Cassandara를 살펴보다가 적용한 서비스에서는 서버를 몇대정도 가지고 있을까 궁금했는데, 이번 annouce에 언급이 되고 있다. machine의 정확한 스펙은 모르겠지만, 대략 400대이상이라....

Apache Cassandra is successfully deployed at organizations with active data sets and large
server clusters, including Cisco, Cloudkick, Digg, Facebook, Rackspace, and Twitter. The largest
Cassandra cluster to date contains over 400 machines.

http://mail-archives.apache.org/mod_mbox/www-announce/201101.mbox/%3c854673.8467.qm@web30806.mail.mud.yahoo.com%3e
Posted by ologist
트랙백0 댓글0

2011/01/05 22:56 Developer

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison


NoSQL에 대해서 간단하게 요약비교가 잘 되어 있네요.
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

지금 당장은 선택하기 어려울 수도 있지만, 성장이 빠르므로 멀지 않은 시간에 일반화 되리라 봅니다.

http://www.readwriteweb.com/cloud/2011/01/how-twitter-uses-nosql.php

 

Posted by ologist
트랙백3 댓글0

2010/06/07 23:18 Developer

mock vs stub

개념만 이해를 하고 있고, 설명을 하려니 그림/표가 부족해서 정리 잘 된 문서 몇개 정리를 해봤다.



mock

mock object http://www.c2.com/cgi/wiki?MockObject

mock aren't stubs http://martinfowler.com/articles/mocksArentStubs.html

mock roles, not object http://www.jmock.org/oopsla2004.pdf

mock vs stub

http://weblogs.asp.net/rosherove/archive/2007/09/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.aspx
  • Stubs provide input for the application under test so that the test can be performed on something else.
  • Mocks provide input to the test to decide on pass\fail. the opposite direction.

image 

A stub can never fail a test.


xunit patterns http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html

Terminology Cross-Reference

I'm listing some sources of conflicting definitions just to make it clear what the mapping is to my pattern names:



Sources and Names Used in them
PatternAstelsBeckFeathersFowlerjMockUTWJOMGPragmaticRecipes
Test Double






Double or stand-in
Dummy ObjectStub


Dummy


Stub
Test StubFake
FakeStubStubDummy
MockFake
Test Spy




Dummy

Spy
Mock ObjectMock
MockMockMockMock
MockMock
Fake Object




Dummy


Temporary Test Stub




Stub


OMG's CORBA Stub





Stub

Posted by ologist
 TAG mock
트랙백0 댓글1

2009/09/06 20:37 Developer

단위 테스트를 습관화 시키기

단위 테스트의 중요성을 인식하고 여러 개발자들과 얘기를 하고 pair개발도 했지만, 대부분의 개발자는 아직까지 단위 테스트 개발에 어려움을 많이 느끼는 듯하다.

개발에 대한 품질에 대해서 항상 고민하는 개발자들은 알아서 실천을 하고 있지만, 보통 개발자 이하인 사람들은 교육을 시키고 코칭을 해도 적용을 못하고 있다.

어떤 부분이 그들에게 넘지 못하는 산이 되고 있을까?

제일 큰 부분은 동기부여일 것이다. 이 부분은 가장 어려운 문제중에 하나이다. 동기부여는 너무 개인적인 요소들이 강해서 하나의 주제로 드라이빙을 하더라도 다른 사람들에게는 매력적인 요소가 되지 않을 수도 있다.

지금까지 내가 전달한 동기부여에 대해서 큰 의미를 주지 못했다면, 다른 방법을 생각을 해봐야겠다.
좋은 의견이나 성공한 케이스가 있으면 덧글 달아주세요~^^


Posted by ologist
트랙백0 댓글1

2009/04/01 19:12 Developer

새로운 코드 개발하기와 기존 코드 이용하기

개발자가 코드를 개발을 잘하는 것은 당연히 갖추어야 할 능력이다.

새로운 코드를 개발을 할때 다른 이들이 사용을 할수 있는 인터페이스를 만들어야 할때 많은 정성을 기울여야 하고, production code로 올라간 뒤에 유지보수를 잘 해야 한다.고객이 원하는 요구사항과 인터페이스를 추가하는 일은 그 중에 가장 중요한 요소이다.

또 하나의 중요한 능력은 다른 개발자의 좋은 코드를 잘 이용을 하는 것이다.

어떻게 하면 잘 이용을 할수가 있을까?

1. 다른 개발자들이 만든 production과 code를 관심있게 봐야 한다.
요구사항이나 필요성을 느꼈을 때 무작정 개발을 시작하는 것 보다는 선배님들이 주위에 개발자들이 만든 코드들을 살펴보는 것도 중요하다.

2. 적용전략을 골라야 한다.
예를 들면, 직접 의존을 걸어서 쓸 것인지, 한번 wrapping(delegation)을 해서 사용을 할 것인지에 대한 이슈에대한 결정은 선택에 따라서 추후에 발생할 비용은 차이가 많다. 물론, 2가지 방법 다 장단점이 있다.
Posted by ologist
 TAG 개발자, 중복코드, 코드작성
트랙백0 댓글0

2009/03/28 15:09 Developer

진정한 개발자...그리고, 월급쟁이 개발자

나도 월급을 받으면서 개발을 하는 사람 중에 하나지만, 내가 하는 일에 있어서 금전적인 잣대를 가장 우선시에서 생각을 한적은 없다.(아니..가끔 있을 수도 있다)

금전적인 문제에 100% 자유로울 수는 없지만, 개발자로서 이루고 싶은 품질이나 목표. 비젼이 있는 사람은 동반자로서 받아 들이기 아주 쉬운 경우이다. 이런 부류를 "진정한 개발자"라고 부르겠다.

내가 어렵게 느끼는 사람 중에 하나는 개발자체에 흥미를 가지지 못하는 사람이다.
개발자가 자신의 하는 일에 만족도가 무척 떨어진고, 먹고살기위해서 어쩔 수없이 해야 한다는 생각만을 가진 사람에게 어떤 얘기를 해줘야 하며, 어떤 비젼을 공유해야 할 것인가?

개발에 흥미가 없는 사람에게 개발관련된 일이란 노가다일 뿐이고, 새로운 도전은 피곤한 일상이 될 것이다. 이런 부류를 "월급쟁이 개발자"라고 부르겠다.

진정한 개발자와 월급쟁이 개발자 사이에는 분명히 다른 비젼들이 존재하기때문에 같은 이슈를 해결을 할때도 크게 다른 방법으로 처리를 한다.

우리가 아는 모든 레퍼런스들은 대부분 진정한 개발자라고 가정을 하고 얘기들을 하지만, 그렇지 않은 월급쟁이 개발자도 있는 것이다. 주위의 모든 개발자들이 "진정한 개발자"라면 좋겠지만, 아닌 사람들도 많다.

하지만, "월급쟁이 개발자" 부류들도 버릴 수 없는 우리의 동료들이다. 그 부류들도 너무 힘들지 않을 정도의 프로세스로 "월급쟁이 개발자"에서 "진정한 개발자"와 유사한 형태로 만들어 주는 것은 아주 중요한 일이다.

근본적인 사상으로 올라가다가 보면, 세상의 모든 일이 비슷하다.
열심히 일하는 사람과 일하지 않는 사람..그로 이해서 생기는 빈부의 격차..이건 포기할 수 없는 문제이다. 가난한 사람도 이끌어 가야할 이 시대 구성원이기때문이다.


Posted by ologist
 TAG 개발자
트랙백1 댓글10

2009/03/21 22:32 Developer

어느 개발자의 생각

개발자라는 직업을 가지고 일한 것도 꽤나 오랜 시간이 흘렀다.

수만은 개발자들을 만나왔고, 앞으로도 수많은 개발자들을 만날 것이다.

뒤돌아 생각을 해보면, 내가 만난 사람들은 다행스럽게도 에너지가 가득하고, 좋은 마음을 가진 사람이 많은 편이라 힘들지 않게 지내왔던거 같다.

각각의 개발자들 모두와 깊게 얘기한 것은 아니지만, 개발자들 사이에서도 불신이라는 것이 저변에 많이 깔려있는 경우가 있다.

또한, 자신만 불이익을 당하고 있다고 생각을 할 수도 있고, 모든 사람이 나처럼 바보같이 살 것이라는 생각을 할 수가 있다.

주위를 조금 더 관찰하면서 살펴보면, 꼭 그런 경우가 아닐 경우가 있다. 자신의 경험을 전체에 확대하는 것은 위험한 일이다.

나도 "hello, world"를 처음 찍을 때를 생각하면서, 동반자로서의 마인드를 좀더 깊게 생각하겠다.
한번더..한번더...성장을 할수 있는 기회가 주어진 것인가?

Posted by ologist
 TAG 개발자, 생각
트랙백0 댓글0

2009/03/19 11:27 Developer

지식 공유를 위한 좋은 방법은 없을까?

서비스를 운영하다가 보면, 히스토리라는 것이 생긴다.

코드를 개발하다가 보면, 좀더 나은 코드의 pattern이 생긴다.

시간이 흐르면서 강건하게 만들어지는 이런 규칙들을 새로운 사람들과 쉽게 공유를 할 수 있는 방법은 없는 걸까?

하나의 장소에 오래 머물러 있기도 어렵지만, 새로운 장소에 있을 때 빨리 그 장소에 맞는 규칙들을 빠르게 습득하게 할수 있는 방법이 필요하다.
Posted by ologist
 TAG 시간은흐른다
트랙백0 댓글4
이전버튼 1 2 3 4 5 ... 41 이전버튼
블로그 이미지
ologist

공지사항

Yesterday221
Today25
Total34,406

달력

 « |  » 2012.02
일 월 화 수 목 금 토
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

최근에 받은 트랙백

글 보관함