2008년 12월 19일 금요일
2008년 8월 27일 수요일
code_swarm
code_swarm - Eclipse (short ver.) from Michael Ogawa on Vimeo.
2008년 7월 1일 화요일
2008년 6월 18일 수요일
Mate Flex Framework
Mate ( 'mah-tay' '마떼'로 발음합니다. 'latte' '라떼' 처럼... )
- 홈페이지 : http://mate.asfusion.com/
- What is Mate?
Mate is a tag-based, event-driven Flex framework.
Flex applications are event-driven. Mate framework has been created to make it easy to handle the events your Flex application creates. Mate allows you to define who is handling those events, whether data needs to be retrieved from the server, or other events need to be triggered.
Mate는 MXML 태그를 사용한다는 점에서 AS를 사용하는 다른 플렉스 프레임워크와 차별화 됩니다.
이벤트 드리븐 방식을 사용하여 뷰와 비즈니스로직, 그리고 모델간의 의존 관계를 끊고,
뷰와 모델, 뷰와 뷰들의 통신 메카니즘을 Event Maps에 정의하여 중앙에서 관리하므로,
이벤트 방식 구현시 발생할 수 있는 문제들을 최소화 해 줍니다.
무엇보다 UI의 계층구조에 구애받지 않고 이벤트를 처리할 수 있게 해 줍니다.
또한 이벤트 발생시 연쇄적으로 처리해야 하는 작업들을 쉽게 정의할 수 있습니다. 물론 상위 작업의 결과값을 다음 작업으로 넘겨줄 수도 있습니다. (이 모든 것들이 MXML 태그로 가능합니다!)
원하는 클래스를 런타임시 생성하여 사용할 수도 있고, 런타임시에 모델과 뷰를 바인딩할 수도 있습니다.(Dependency Injection)
- 작동방식
- 뷰에서 이벤트가 발생합니다.(예를들어 조회 버튼을 클릭)
- Event Maps으로 이벤트가 전달됩니다.
- Event Maps에 정의된 내용에 따라 서비스를 호출하거나 비즈니스 로직을 실행합니다.
- 다시 뷰에 데이터를 전달하기 위해 이벤트를 발생시킬 수도 있고, injection을 이용하여 직접 모델과 뷰를 바인딩할 수도 있습니다.
-
생각해 볼 점
- 프레임워크 사용에 익숙하지 않을 경우 약간의 적응기간이 필요할 수 있습니다.(물론 Mate가 배우기 어렵지는 않지만, 그냥 사용하는 것과 '제대로' 사용하는 것은 큰 차이가 있겠죠)
- Event Maps이 핵심입니다. 먼저 어플리케이션에 사용될 이벤트들을 정리하고 MVC패턴에 따라 디자인 하기 위해 생각할 시간이 필요할 수 있습니다.
- 런 타임 오류 발생시 디버깅하기 힘들 수 있습니다. Event Maps에서 호출될 메소드명이나 바인딩할 프로퍼티명을 스트링으로 넘겨주기 때문에 컴파일시 에러를 잡아낼 수 없고, Mate에서 제공하는 디버깅 기능을 사용하더라도 FlexBuilder의 IDE 기능에 통합된 것이 아니라 콘솔 창에 출력되는 메시지를 분석해야 하는 번거로움이 있습니다.
- 참고
Flex로 개발시 프레임워크가 불필요하다는 발표자료도 참고하세요.
결론은 프레임워크보다는 패턴을! (하지만 이 발표를 한 발표자도 Mate 발표를 보고 감동했다는...)
2008년 1월 31일 목요일
오픈소스란 어떤 것인가?
GPL 라이선스를 갖는 코드가 한 줄이라도 들어가면 GPL 라이선스를 따라야 한다고 하네요. 다른 오픈소스 라이선스는 오픈소스 코드를 이용한 사용 소프트웨어에 대해 강제하는 조항은 없는 것 같은데요... GPL 라이선스로 배포된 소스코드를 사용하게 될 경우 꼭 이 점을 염두에 두고 있어야 겠군요.
비영리 기구인 Open Source Initiative 가 오픈소스 소프트웨어를 촉진시키고, 이를 관리하기 위해 Open Source Definition라는 것을 만들었다. 오픈소스 역시 상용 프로그램과 마찬가지로 라이선스하에 배포가 된다. 이미 30개 이상의 오픈소스 라이선스가 난무해 오픈소스 사용자들 입장에서는 골치가 아닐 수 없다. 이를 돕기 위해 정의된 Open Source Definition는 오픈소스 라이선스가 되기 위해선 어떤 내용이 포함되어야 하고, 어떤 내용은 포함되지 않아야 하는지를 명시한 것이다.
Open Source Definition에 부합하기 위해서 오픈소스 라이선스는 다음의 항목들을 제공해야 한다:
- 소스 코드 제공(Source Code Access): 오픈소스가 되기 위해서는 어떠한 형태더라도 소스 코드를 제공해야 한다.
- 수정 허용(Derivative Works): 오픈소스 코드를 수정해서 동일한 조건하에 다시 배포가 될 수 있어야 하고, 이를 칭하는 법률 용어가 " Derivative Works"이다. 이를 통해 오픈소스 소프트웨어가 빠르게 진화하는 것이 가능해진다.
- 차별 배제(No discrimination): 오픈소스 코드를 이용하는데 어떠한 차별도 두어서는 안된다. 멋진 규약이다. ^^; 라이선스를 준수하는한 누구에게도. 이는 상업적인 목적의 사용자가 오픈소스 커뮤니티에 합류하는 것을 허용한다.
- 다른 소프트웨어에 대한 무제약(No restrictions on other software): GPL을 제외한 대부분의 오픈소스 라이선스는 오픈소스 소프트웨어가 사용 소프트웨어에 포함될 경우 해당 상용 소프트웨어가 오픈소스일 필요는 없다. 즉, 해당 소프트웨어가 아닌 다른 소프트웨어에 대해 어떠한 강제도 하지 않다. 다만, GPL의 경우 GPL이 포함된 소프트웨어는 무조건 GPL이다. ^^;
OSI의 인증을 받은 모든 라이선스의 목록은 아래 사이트에서 찾아볼 수 있다.
: http://www.opensource.org/licenses/
오픈소스의 라이선스는 대체로 "COPYLEFT" 성향의 정도에 따라 분류할 수 있다. COPYLEFT라 함음 저작권(COPYRIGHT)에 대한 반감 혹은 조롱을 나타내는 표현이다.
Copyleft 성향이 가장 강한 것은 GPL (General Public License) 이다. GPL은 쉽게 말해서, GPL 하에 배포된 코드를 수정한 경우, 즉 자신이 만들 소프트웨어에 GPL 라이선스를 갖는 코드가 할줄이라도 들어가면, 소유권을 포기하란 얘기다. 완전한 평등. 완전한 공유 정신이다.
오픈소스 소프트웨어의 대명사격인 리눅스가 바로 GPL을 대표한다고 할 수 있다. GNU GPL은 최초의 오픈소스 라이선스이면서, 여전히 가장 많이 사용되는 오픈소스 라이선스이기도 하다. 오픈소스의 대부격인 리차드 스톨먼(Richard Stallman)과 에벤 모글렌(Eben Moglen)은 GPL을 만들고, GPL을 촉진시키고 이를 관리하기 위해 Free Software Foundation을 설립했다.
Copyleft 성향이 약한 오픈소스 라이선스들이 몇 가지 있다. 그 중 유명한 것이 Mozilla Public License (MPL) 이다. 네스케이프 브라우저의 오픈소스 버전인 Mozilla가 채용한 라이선스이다. MPL의 경우 MPL 하에 배포된 코드를 포함하는 파일이나, MPL 하에 배포된 파일 자체를 수정한 경우에만 소스코드 배포를 요구하며, MPL 하에 배포되었던 파일이 아닌 새로운 파일은 MPL의 제약을 받지 않는다. 코드 공개 기간에 있어서도 최소 일년 내지 6개월 정도의 기간동안 공개해야 하는 제약을 갖는다. 그래도, 완전 공개의 GPL에 비하면 상당히 사적 소유권을 인정하는 것이다.
다음으로 Copyleft 성향이 없는 오픈소스 라에선스들이 있는데, 가장 유명한 것은 Berkeley Software Distribution License (BSD)이며, 이와 유사한 것으로 Apache Software License 와 the MIT license 가 있다. 이것은 구워먹든 삶아먹든 신경을 안쓰는 것이다. 코드를 수정해서 상용화해도 전혀 무방하다는 것이다. 맘대로 하란 것이다. 다만, 원조 개발자들의 이름을 명기하는 정도의 예우를 요구하고 있다. 이 정도야 최소한의 양심 문제 아닌가. ^^;
그러나 주의할 점은 GPL 라이선스도 인터넷이나 CD 등의 미디어를 통해 공개적으로 배포가 되었을 때의 이야기다. GPL 하의 코드를 포함하여 제작한 프로그램을 개인적으로 사용하거나, 조직내에서 사용할 경우는 어떠한 제약도 받지 않게 된다. 또한, GPL 오픈소스 코드를 활용하여 서버의 코드를 수정하고, 공개적으로 서비스를 수행하는 경우도 배포가 이루어지지 않았기 때문에 소스코드를 배포할 필요가 없다.
이상은 ONLamp.com의 "What is Open Source"의 일부를 발췌하여 의역한 것입니다.
원문: http://www.onjava.com/lpt/a/5330
2008년 1월 9일 추가:
간단한 요약표를 오픈소스 라이선스 가이드라인에서 찾을 수 있어 추가한다.
2008년 1월 18일 금요일
REST란?
Roger L. Costello
I will first provide a brief introduction to REST and then describe how to build Web services in the REST style.
What is REST?
REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.
Why is it called Representational State Transfer?
The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL:
http://www.boeing.com/aircraft/747
A representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representational State Transfer!
Here is Roy Fielding's explanation of the meaning of Representational State Transfer:
"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."
2008년 1월 14일 월요일
2008년 1월 10일 목요일
나쁜 관리자 VS 좋은 관리자
나쁜 관리자
나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.좋은 관리자
첫째, 바라는 결과를 명확히 알려주어야 한다. 어떤 관리자들은 자신이 무엇을 원하는지 자기 스스로도 정확히 모르는 채 작업을 지시하고, 팀원의 작업 결과를 그날그날의 기분에 따라 자신의 기호대로 판단하곤 한다.
둘째, 위임을 적절하게 수행해야 한다. 혼자서 모든 일을 처리하려고 하는 관리자는 탈진증후군(burnout syndrome)에 빠지게 된다.
셋째, 방법보다는 결과에 초점을 맞추어야 한다. 결과가 올바르다면 방법은 팀원에게 맡겨두라는 뜻이다.
넷째, 피드백을 주고, 코칭을 하고, 경력 개발을 지원해야 한다.
다섯째, 좋은 관리자는 자기 자신을 관리하는 사람이다.
2008년 1월 9일 수요일
축구 선수에서 공부 1등으로
애자일 공부법이라~ 책 읽는 진도가 너무 안 나가는 데 한 번 적용해 봐야 겠다.
우리 회사에서는 다음 주 계획을 미리 세워놓고 JIRA 시스템에 등록해서 주간보고를 대체하려고 한다.
미리 추상적인 계획을 세우기 보다는 일을 시작하면서 세부적이고 구체적인 계획을 세우는 것이 좋을 것 같다는 생각이 든다.
저희 집은 TV 시청을 거의 하지 않습니다만(TV 팔아버리자는 이야기가 종종 나옵니다) 가끔 우연히 TV를 틀었는데 재미있고 유익한 방송을 보게 되는 경우가 있습니다. 지난 11월 24일이 그랬습니다. 공부의 제왕MBC에서 매주하는 공부의 제왕이라는 프로.... 글 전체보기
무료 Database design tool - Toad™ Data Modeler Freeware
기능과 Freeware 제한 기능은 아래와 같다.
다운로드 : Database design tool - Toad™ Data Modeler Freeware
Key features
- Visual creation of Entity Relationship Diagrams (Database design)
- Both Physical and Logical modeling
- Generation of complex SQL scripts
- Model Verification
- To-Do list
- Support for Unicode
- UNDO / REDO
Freeware version limit
- You cannot save a model with more than 25 entities.
2008년 1월 8일 화요일
직관적인 믹서 인터페이스
아! 감탄하게 만드는 UI 입니다. 비슷하게 이퀼라이저에도 응용할 수 있을 것 같구요.
여러가지 변수들을 조합해서 결과물을 얻어내는 경우에 멋지게 응용할 수 있을 것 같습니다.
여기에서 볼 수 있어요.
마우스로 하얀 점들을 움직이면 소리의 크기가 변해요. 그에 따라 하얀 점을 둘러 싼 원의 크기도 변해요. 음은 베이스, 리드, 킥, 힛햇, 스네어가 있어요. (아마도, 베이스 기타, 리드 기타, 킥드럼, 드럼의 힛햇과 스네어드럼을 의미하는 듯)
중심부로 가져다 놓을 수록 소리가 커져요.
음향 기기 인터페이스 만들 떄 응용할 수 있겠어요.
2008년 1월 2일 수요일
Adobe - Flex Quick Start Basics: Validating Data
Adobe - Flex Quick Start Basics: Validating Data
