yourProsoft: MFC "encountered an improper argument" message

yourProsoft: MFC "encountered an improper argument" message: Hi there, The story: My MFC application "Schedule" that I work in 2 years ago faced by a very strange bug, the application is built...

다준이 100일 사진

Diving in the Data Binding Waters

code_swarm

Visualizing the commit history of the Eclipse IDE project.



code_swarm - Eclipse (short ver.) from Michael Ogawa on Vimeo.

Create Custom Chrome For AIR APP

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 발표를 보고 감동했다는...)
  • Flex: No Frameworks Required by Maxim Porges

오픈소스란 어떤 것인가?

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일 추가:
간단한 요약표를 오픈소스 라이선스 가이드라인에서 찾을 수 있어 추가한다.