[이미지 출처 : Amazon.com]

아주 기초적이지만 막상 누군가 묻는다면 대답하기 어려울 때가 많습니다.

CLR의 기능이 무엇인가 묻는다면 여러분은 뭐라 답하시겠어요?
Jeffrey Richter의 CLR via C# 3rd에서는 CLR의 기능을 이렇게 정의합니다.

  • Exception Handling and State Management
  • Automatic Memory Management
  • CLR Hosting and AppDomains
  • Assembly Loading and Reflection
  • Runtime Serialization

아주 당연한 내용이라서 무심코 지나치다 보면 기초가 흔들리겠지요.
기초를 탄탄하게 하는 것. 무엇보다 중요합니다~



Posted by spponge

댓글을 달아 주세요

오늘 Office 2010 Professional 버전이 MSDN에 등록되었습니다.
2007과의 호환 여부를 살펴보다 알게 된 정보입니다.

Office Open XML 표준(ECMA-376) File Format를 Office 2007에서 완전히 준수하지 않았고, 2010에서 ISO/IEC 29500:2008 호환 버전을 지원하기 위한 업데이트를 포함한다고 하네요. 하지만 이마저도 완전하지는 않답니다.

결국 Office 2007 과 2010은 같은 파일 포맷인 Office Open XML 표준을 사용하지만 표준을 좀 더 지원하느냐 아니냐의 차이로 해석됩니다.

참고문헌은 http://en.wikipedia.org/wiki/Office_Open_XML



Posted by spponge

댓글을 달아 주세요


[출처 : Gizmodo.com]

Gizmodo에서 일러스트한 플랫폼 패권 전쟁 3강 구도입니다.
(이 사이트는 참 재미난 짓을 많이 하네요)

"플랫폼을 가진 자가 천하를 평정한다"는 말이 현실로 드러나고 있습니다.

구 글이 구체화 시킨 Cloud Service & Software as a Service(SAAS)
애플이 일으킨 Online Application Market Model & 개발자 생태계 그리고 사용자 경험
마이크로소프트의 Desktop OS 점유율 및 Business Software 부분에서 전통적 강세

그리고 모바일 플랫폼 전쟁...

세 기업 모두 우열을 가리기 힘들 정도로 세계적 거대 기업이고
각자의 분야에서 최고의 기술력과 사용자를 확보하고 있습니다.

앞 으로도 이 삼각 구도는 오랜 기간 지속되겠지만, 결국 데스크탑과 모바일, Cloud Service 그리고 사용자 경험과 개발자 지원 등을 아우르는 통합된 단일 플랫폼을 누가 먼저 선점하고 사용자를 확보하는가 하는 점이 앞으로 패권의 향방을 가르지 않을까 생각합니다.

지금이 가장 중요한 시기이자 가장 불확실한 시기인 듯 합니다.
발빠른 대처로 변화의 바람을 잘 타는 기업이 최후의 승자가 될 것 같습니다만...
(순간 삼성의 바다 플랫폼 홈페이지에 있는 돗단배가 떠오릅니다 ㅋ)
그런 점에서 조직 구조가 과도하게 비대해져 버린 마이크로소프트 같은 기업이 어떤 혁신을 보여 줄 지는 기대와 동시에 우려를 하지 않을 수 없군요.

옛날 옛적 중국 채륜이 발명한 "종이"라는 플랫폼이 중국 문명을 혁신과 발전으로 이끌었고 전 세계로 퍼져나가 인류의 역사를 바꾸었습니다.

현재 진행형인 인터넷의 발전에서 그 플랫폼을 거머쥐는 자가 보여 줄 먼 훗날 인류 문명의 미래를 상상해 봅니다.



Posted by spponge

댓글을 달아 주세요

  1. 망스 2010.04.20 23:13  댓글주소  수정/삭제  댓글쓰기

    난 내가 MS랑 친해서 그런지 모르겠지만 MS가 이겼으면 좋겠네요 ㅋ


다운로드 및 설명 : http://msdn.microsoft.com/ko-kr/library/ms742404.aspx



Posted by spponge
TAG .net, Tools, WPF

댓글을 달아 주세요


Posted by spponge

댓글을 달아 주세요



계속 업데이트 됩니다...



Posted by spponge

댓글을 달아 주세요

Stack:

  • Stored in computer RAM like the heap.
  • Variables created on the stack will go out of scope and automatically deallocate.
  • Much faster to allocate in comparison to variables on the heap.
  • Implemented with an actual stack data structure.
  • Stores local data, return addresses, used for parameter passing
  • Can have a stack overflow when too much of the stack is used. (mostly from inifinite (or too much) recursion, very large allocations)
  • Data created on the stack can be used without pointers.
  • You would use the stack if you know exactly how much data you need to allocate before compile time and it is not too big.
  • Usually has a maximum size already determined when your program starts

Heap:

  • Stored in computer RAM like the stack.
  • Variables on the heap must be destroyed manually and never fall out of scope. The data is freed with delete, delete[] or free
  • Slower to allocate in comparison to variables on the stack.
  • Used on demand to allocate a block of data for use by the program.
  • Can have fragmentation when there are a lot of allocations and deallocations
  • In C++ data created on the heap will be pointed to by pointers and allocated with new or malloc
  • Can have allocation failures if too big of a buffer is requested to be allocated.
  • You would use the heap if you don't know exactly how much data you will need at runtime or if you need to allocate a lot of data.
  • Responsible for memory leaks

출처 : http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap



Posted by spponge
TAG heap, Memory, stack

댓글을 달아 주세요

원문을 읽어 보면 수긍이 가는 내용도 있고 아닌 내용도 있다. 한번쯤 읽어 보고 참고하면 좋겠다.

원문 요약

절대로 실패하지 않는 Software는 불가능에 가깝다
  • 초기에 Check하라.
  • 외부 Data를 신뢰하지 마라.
  • 유일하게 믿을 수 있는 Device는 Video, mouse, keyboard 뿐이다.(다른 외부 데이터 소스는 신뢰할 수 없다는 의미)
  • Write(디스크 등에 쓰기 작업을 의미) 도 실패할 수 있다.
  • 안전한 코드 작성
  • throw new Exception() 금지. 대신에 ApplicationException 에서 상속하여 직접 만든 exception class를 사용할 것.
  • Message Field에 중요한 예외 정보를 넣지 말것.
  • Thread 당 단일 catch 블럭을 두라.
  • 일반 예외가 발생하면 기록되어야 한다.(여기 저기 catch 블록이 득실거려서 예외 상황이 중복하여 기록되지 않도록 하라는 의미)
  • Exception.ToString()을 사용하여 기록하고 Exception.Message만 기록하는 것 금지.
  • thread 에서 예외를 한 번 이상 catch 하지 말라.
  • 예외를 꿀꺽 삼키지 말라.(아무 것도 하지 않는 그런 catch block은 안좋다)
  • 자원 정리 코드는 반드시 finally block에서 작성.
  • 모든 곳에 using 키워드를 써라.(Dispose() 패턴을 구현하는 객체을 사용할 때는 using block을 쓰라는 의미)
  • 에러 상황에서 특별한 값을 return하지 말라.(예외 상황에 값을 반환하는 것은 비효율적이고 아무 도움이 되지 않기 때문 등등..)
  • method로 부터의 반환 정보의 의미로 예외 처리를 사용하지 마라.
  • 에어 처리를 위한 예외는 무시되어서는 안된다.
  • exception을 re-throwing 할 때에는 statkc trace 정보를 함께 전달해야 한다.
  • 의미없이 예외를 수정하지 마라.
  • 예외는 직렬화 가능 해야 한다.(user defined exception을 사용할 경우..)
  • 예외 발생 가능성이 있는 코드에는 Assert 대신 throw an Exception사용.(Assert는 Unit Test를 위해서 남겨 둘 것)
  • 각 Exception class에는 최소한 원래 세개의 생성자를 가지도록 할 것.(참고 http://msdn.microsoft.com/en-us/library/aa328363.aspx)
  • AppDomain.Unhandled Exception Event를 사용 할 때는 주의하라.
  • 시간과 노력을 낭비하지 말 것.(Exception Management Application Block, Microsoft Enterprise Instrumentation Framework 등의 좋은 Framework 들이 있다)

원문 링크 : http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx



Posted by spponge

댓글을 달아 주세요

사용자에게 뭘 원하는지 묻지 마라.
사용자도 자신들이 뭘 원하는지 모른다.
그들은 실제로 제품을 사용해 보고 나서야 뭘 원하는지 알게 된다.
- Steve Jobs
그렇다. 사용자는 언제나 체험을 원한다. 보고 느껴보기 전에는 이렇다 저렇다 말만 많을 뿐 쉽게 결정하지 못한다. 그래서 Software 개발자는 "제품이 실제 이런 모습일 것이다" 하고 Prototype을 보여주고 사용자는 "음... 대충 이렇군... 이건 좀 고치고 저건 좀 뺐으면 좋겠군..." 하고 생각하게 된다.

하지만 문제는 아무리 Prototype일 지라도 사용자 입장에선 좀 그럴듯한 모양새가 갖춰진 결과물을 원한다는 데 있다. 개발자 입장에서야 당연히 "나중에 다 뜯어고쳐져야 할 프로그램에 좋은 껍데기가 뭐 필요하겠어. 그냥 기능만 보고 말자구. 좋은 껍데기는 나중에 입혀도 충분하단 말이야." 할 수 있겠지만, 사용자는 그렇지 않다는 말이다. 보기 좋은 떡이 먹기도 좋다고 하지 않았던가.

이럴 때 간편하게 사용할 수 있는 것이 Blueprint 이다. 프로젝트의 최종 결과물에 비할 정도는 아닐지라도 그럭저럭 깔끔한 UI를 초기~중간단계까지 선보이고 싶을 때 사용하면 좋다. 초기에는 Google Code 사이트에서 호스팅하다가 현재는 별도의 사이트로 옮겨서 제공되고 있다.



Posted by spponge

댓글을 달아 주세요

.net framework 3.5 sp1 혹은 3.5 언어 팩 sp1을 설치한 후에 MSBuild를 이용해서 빌드시 아래와 같은 오류 코드를 내뱉는 경우가 있다.

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (1353,9):
           
            errorMSB3095: 잘못된 인수입니다. 문화권 ID 2155(0x086B)은(는) 지원되는 문화권이 아닙니다.


이 오류 코드는 .net framework 3.5 sp1 혹은 3.5 언어 팩 sp1을 설치하고 시스템을 리부팅 하지 않아서 발생하는 문제이다.

해결 방법은 당연히 "리부팅"



Posted by spponge

댓글을 달아 주세요


IE8을 이용하여 웹페이지를 열면 IE8 표준모드(웹표준 준수)로 웹페이지를 렌더링하는데 기존 웹사이트 대부분은 IE7에 최적화되어있거나 IE을 기준으로 개발되어있을 것이다.

그렇기 때문에 IE8에서 기존 웹페이지를 테스트했을 때 깨져보이는 현상이 있을 수 있다.

물론 최적의 솔루션은 기존 페이지를 웹표준을 준수하도록 수정하는 것인데 임시방편으로 IE7에 맞게 개발된 페이지를 IE8에서 열었을 때 IE7에서 테스트했을 때와 똑같이 표시되도록 하는 방법을 소개한다.

자세한 내용은 아래 링크를 클릭.




Posted by spponge

댓글을 달아 주세요

  1. Favicon of http://himarx.sisain.co.kr BlogIcon himarx 2008.08.16 21:07 신고  댓글주소  수정/삭제  댓글쓰기

    그럼 IE8에선 웹 표준 준수를 요구한다는 겁니까?
    헐........... 즈그들이 할 소리는 아닌 것 같네요-_-;;;;;
    이제 인터넷 뱅킹부터 싹 갈아야-_-;;;;;(뭐 즈그네 ActiveX니까 지원은 하겠지만....)

  2. Favicon of https://portno80.tistory.com BlogIcon spponge 2008.08.17 14:05 신고  댓글주소  수정/삭제  댓글쓰기

    IE8에선 기본적으로 W3C 표준안을 준수하도록 변경됩니다.
    html, css등등 말이죠...
    진작에 바뀌었어야하는데 늦었지만 지금이라도 바꿀것은 바꾸는게 맞겠죠.
    인터넷뱅킹 문제는 아마도 각 은행들이 전용 어플리케이션을 배포하는 형태로 가는게 좋을텐데 일단 IE8에서 active-x가 완전히 배제되지 않는 한 힘들지 싶습니다.


최근 웹사이트 보안이 이슈화 되면서 사이트 보안 담당자들이 SQL Injection을 막기 위해 Dynamic SQL 사용을 제한하고 있다.

상황에 따라 변화하는 SQL 생성을 위해서 대부분의 개발자들이 Client Side에서든 Server Side에서든 Dynamic SQL을 문자열로 조합하여 실행하는 방법을 사용하는 상황에서 기존에 개발되어 있거나 앞으로 개발하게 될 SQL 문을 Static SQL로 변환하는 것은 골치 아픈 문제거리이다.

예를 들어, 검색 조건 3개(@cond1, @cond2, @cond3)를 Parameter로 가지는 프로시져에서 Parameter의 값 조건에 따라 SQL을 Dynamic하게 구성하여 생성하던 것을 Static SQL로 변환한다고 가정해 보면 아래와 같은 조건 분기에 따라 Static SQL(초록색부분) 총 8개를 만들어 넣어야 한다.(세상에나!!!)

<예제 코드>
IF @cond1 IS NOT NULL
BEGIN
  IF @cond2 IS NOT NULL
  BEGIN
     IF @cond3 IS NOT NULL
     BEGIN
        -- Static SQL
     END
     ELSE
     BEGIN
        -- Static SQL
     END
  END
  ELSE
  BEGIN
     IF @cond3 IS NOT NULL
     BEGIN
        -- Static SQL
     END
     ELSE
     BEGIN
        -- Static SQL
     END
  END
END
ELSE
BEGIN
  IF @cond2 IS NOT NULL
  BEGIN
     IF @cond3 IS NOT NULL
     BEGIN
        -- Static SQL
     END
     ELSE
     BEGIN
        -- Static SQL
     END
  END
  ELSE
  BEGIN
     IF @cond3 IS NOT NULL
     BEGIN
        -- Static SQL
     END
     ELSE
     BEGIN
        -- Static SQL
     END
  END
END


이 방법은 작업 시간도 많이 걸릴 뿐 아니라 코드의 가독성, 수정, 유지 보수성 모두를 어렵게 만들어서 개발자의 여름 휴가 따위는 꿈도 꾸지 못하게 할 수 있다. 저멀리 해변에 널린 육떡진(^^;;) 츠자들이 그립지 않겠는가 말이다.

더구나! 이 경우는 조건이 달랑 3개뿐인 경우이다. 잘 생각해보면 조건의 갯수가 n개라고 했을 때 이에 비례하여 늘어나는 Static SQL의 갯수는 2의 n승 개임을 알 수 있다. 이는 우리가 알고리즘 강의시간에 배운 시간 복잡도 측정 방법 즉, Big O 표기법을 이야기 할 때 가장 시간이 오래 걸린다고 알려져 있는 "O(2의 n승)"이 아닌가 말이다. 다시 말해서 조건이 10개가 되면 2의 10승 = 1024가 된다. 1024개의 Static SQL을 작성하여 분기문 사이에 붙여넣고 있다 보면 인생을 비관하게 될 지도 모르겠다...

하여... 이에 대한 해결책을 제안하고 있는 유명한 자료들을 링크해본다.
조만간 아래 자료들을 종합하여 Dynamic SQL 을 Dynamic SQL 변환하는 방법을 올릴 예정이다.

Posted by spponge

댓글을 달아 주세요

프로젝트 이해 관계자에게 주어진 권리

  1. 개발자는 비즈니스와 목표에 대해 배운다.
  2. 개발자는 자신들이 사용하는 언어로 배우고 말한다.
  3. 개발자는 요구 사항을 인식하고 이해한다.
  4. 프로젝트 이해 관계자와 함께 일하는 작업의 일환으로 개발자가 사용하는 창조물에 대해 설명한다. 창조물에는 생성을 위한 모델(예: 사용자 스토리, 핵심적인 UI 프로토타입)이나 표현 결과물(예: UML 배포 다이어그램) 등이 있다.
  5. 개발자를 존중하기를 기대한다.
  6. 요구사항을 위한 아이디어와 대안을 듣는다.
  7. 제품을 쉽게 사용하도록 특징을 기술한다.
  8. 재사용을 허용하고, 개발 시간을 단축하거나 개발 비용을 줄이도록 요구사항을 조정할 기회를 제공한다.
  9. 선의에서 나온 추정값을 제공한다.
  10. 기능과 품질 요구를 충족하는 시스템을 제공한다.

프로젝트 이해 관계자에게 주어진 책임

  1. 프로젝트 팀에게 자원(시간, 돈, ...)을 제공한다.
  2. 개발자에게 비즈니스에 대한 교육을 진행한다.
  3. 요구사항을 제공하고 명확하게 하기 위해 시간을 투자한다.
  4. 요구사항을 구체적이고 정확하게 만든다.
  5. 시의적절한 결정을 내린다.
  6. 비용과 가능성이라는 개발자 추정을 존중한다.
  7. 요구사항 우선 순위를 정한다.
  8. 개발자가 만들어낸 유효한 작업과 관련해 시의적절한 검토와 피드백을 제공한다.
  9. 요구사항 변경이 일어나면 바로 알려준다.
  10. 조직에 필요한 소프트웨어 프로세스를 직접 만든다. 프로세스를 따르는 동시에 필요할 때 수정하도록 적극적으로 도와준다.


출처 : IBM Developer Woks

Posted by spponge

댓글을 달아 주세요

  1. Favicon of http://youlsa.com BlogIcon youlsa 2008.09.01 01:26  댓글주소  수정/삭제  댓글쓰기

    참 당연한건데 실생활에서는 무시되는 경우가 너무 많은 것 같습니다. 조금씩 나아지고는 있습니다만... 우리나라의 소프트웨어 산업이 전체적으로 낙후된 데에는 이런 원인이 꽤 큰 역할을 하고 있는 것 같습니다.

  2. Favicon of https://portno80.tistory.com BlogIcon spponge 2008.09.06 08:59 신고  댓글주소  수정/삭제  댓글쓰기

    그렇죠... 실속 없이 비대해진 IT 산업 구조에서 원인과 결과가 꼬리를 물고 도는 형국이라 현실을 개선하기란 참 어렵습니다. 그렇거나 말거나 노력은 개속 되어야죠. 그것이 우리의 희망이니까요. :D


먼저 위키에 올라온 이슈 트랙킹 시스템 비교를 보면 Windows Server + IIS + SQL Server 조합에서 사용할 수 있는 툴들이 별로 없다. 있다해도 상용이라 구입해야 한다.
오픈 소스로 많이 쓰이는 아래 도구들은 아래와 같다. (그중 인기가 좋은것만)
  • JIRA
  • Mantis
  • Bugzilla
  • Trac
  • Atadesk - 심플하고 기본기능에 충실하며 세련된 UI 또한 맘에 들지만 한글 지원이 안되는 것이 최대 단점!



Posted by spponge

댓글을 달아 주세요


Posted by spponge
TAG PMS, 협업

댓글을 달아 주세요







Posted by spponge

댓글을 달아 주세요

Posted by spponge
TAG DI, IoC

댓글을 달아 주세요

사용자 삽입 이미지

현재 .NET 2.0에 VSS로 소스 관리는 하는 환경으로 프로젝트 중이다. CI(Continous Integration) 를 하고자 생각 중에 .NET 에 알맞은 것으로 물망에 오른 것들이
  • Microsoft Team Foundation Server
  • CruiseControl.NET
  • Draco.NET
요런 것들이다. TFS는 .NET 프로젝트에 가장 최적의 기능을 제공하지만 라이센스도 있어야 할 뿐더러 서버 리소스도 많이 먹고 Slq Server 2005도 있어야 한다. 현재 개발서버에 오라클과 웹서비스가 돌아가는데 TFS와 Sql Server 2005까지 깔아서 돌릴려면 무리지 싶다. 더구나 제대로 쓸려면 AD 올리고 TFS와 Sql Server도 별도의 서버에 설치하는걸 권장하는지라 일단 보류...

CruiseControl.NET은 오픈소스이면서도 아주 다양한 기능을 제공하고 .NET이 아닌 다른 플랫폼 버전도 나와있어서 가장 많이 쓰고 안정성도 입증된 듯 하다. 하지만 요놈은 빌드 구성 파일(ccnet.config) 설정이 무척 까다롭다. 기능이 많으면 사용법이 까다로운 법이리라... 구성 파일 생성해주는 툴이라도 있으면 좀 쉬울텐데... 매뉴얼을 봐도 뭔말인지 와닿지가 않는다. 삽질끝에 빌드 자동화까지는 성공했지만 소스세이프에서 소스를 끌어오는 부분이 잘 안된다. 여러가지 설정하는 것도 좀 번거롭고 해서 좀더 심플한 놈을 찾았다.

바로 Draco.NET이다. 설치하면 웹으로 구성파일 셋팅 및 빌드할 프로젝트 설정까지 가능하게 해준다. 설정도 간단히 몇가지만 해주면 된다. 심플한 것이 맘에 든다 싶었는데 한국어 OS에서는 VSS로 부터의 소스 버전 체크가 안된다. Culture를 "en-US"로 해주면 된다는 글을 보고 해봐도 여전히 안된다. Draco.NET의 소스를 VS.NET 7.1로 열어서 DateTime 포맷을 en-US로 고정해주고 컴파일하여 다시 서비스에 올려봐도 여~전히 안된다. 아~미쳐!

위에 말한 두가지 CI 툴들은 분명 사용자가 왠만큼은 되는 툴들인데 이렇게 레퍼런스 할 만한 리소스가 없다니 참... 어이없음이다. Draco.NET의 Wiki는 DB오류로 접속도 안되고... 개똥도 약에 쓸려면 없다더니... 정녕 개발서버의 부하를 안고 TFS로 가야하나?
Posted by spponge

댓글을 달아 주세요