C# & VB.NET2007. 2. 12. 15:33

현재, 몸담고 있는 회사의 솔루션 코드를 보다가 이런 것을 발견했다.

Imports System.Threading

Public Class Metadata
    Private myMetadata As New InsightMetadata

    Private Shared _singleton As Metadata
    Private Shared myInstanceMutex As New Mutex


    Private Sub New()
    End Sub

    Public Shared Function GetInstance() As Metadata

        myInstanceMutex.WaitOne()

        Try
            If _singleton Is Nothing Then
                _singleton = New Metadata
            End If

        Finally
            myInstanceMutex.ReleaseMutex()
        End Try

        Return _singleton

    End Function

    Public ReadOnly Property Appset(ByVal appsetID As String, ByVal app As String, ByVal userName As String, ByVal context As String, ByVal security As String) As Appset
        Get
            If (IsNothing(myMetadata.Appset(appsetID))) Then
                load(appsetID, app, userName, context, security)
            End If

            Return myMetadata.Appset(appsetID)
        End Get
    End Property

    Public Overloads Sub refresh(ByVal appset As String, ByVal app As String, ByVal userName As String, ByVal context As String, ByVal security As String)
        load(appset, app, userName, context, security)
    End Sub

    Private Function load(ByVal appsetID As String, ByVal app As String, ByVal userName As String, ByVal context As String, ByVal security As String) As Appset
        ...
    End Function
End Class

이 코드는 클래스 이름으로도 대충 짐작이 가듯이 전체 프로그램의 공용 Meta 데이터들을 저장해 놓는 모듈이다. 이런 메타 데이터들은 많은 모듈에서 사용하면서도 프로그램이 구동 중일 때는 거의 바뀌지 않는다는 속성이 있다. 그래서 이런 메타데이터는 메모리에 하나 올려놓고, 그것을 모두 사용하면 가장 좋을 것이다. 매번 읽어오지도 않고, 각 모듈에서 각각 호출하지도 않게 하는 최선의 방법일테니까 말이다.

싱글턴 패턴

이렇게 메모리에 딱 하나의 인스턴스를 올려놓을 필요가 있을 때 쓰는 것이 바로 "Singleton" 패턴이다. "Design Patterns"에 나오는 정의를 보자면 "ensure a class has only one instance, and provide a global point of access to it""한 클래스가 단지 하나의 인스턴스만을 가지게 하고, 그것에 액세스할 수 있는 글로벌한 포인트를 제공하는 것"이라고 되어 있다. 아래 위키 백과 페이지를 참조하면 더 자세하게 알 수 있다.

싱글턴 패턴 - 위키 백과

싱글턴 쓰임새

싱글턴 패턴은 쓰임새가 그렇게 다양하진 않다. 주로 위의 코드와 같은 메타 데이터, 혹은 파일 로깅 등의 공용 모듈에서 사용된다. (물론 위의 조건 - 하나의 인스턴스, 글로벌한 액세스 - 을 충족시킨다면 그 쓰임새 자체는 제한이 없다) 하지만 아래 글에서 볼 수 있듯이 이 Singleton 클래스는 다른 클래스들과 단단하게 결합되는(tightly-coupled) 경향이 있고, 이는 Unit Test를 어렵게 하고 전체적으로 각 모듈의 독립성을 저해하는 요소로 작용할 수도 있다. 아래와 같은 글들을 참고할 만 하다. (물론 주의깊게 읽어야 할 것이다. 단지 주장일 뿐이니)

IBM Developerworks: Use Your Singleton Wisely
PrestonLee.com: Singletons causes cancer

권장하는 닷넷 코드

MSDN: Exploring the Singleton Design Pattern

Implementing the Singleton Pattern in C#

MSDN의 Article도 괜찮긴 하지만, 2번째 글은 그야말로 총정리다. C#에서 가능한 모든 경우의 Singleton 구현에 대해서 모두 그 장단점을 서술해놓고 있다. 2번째 글을 보면 이 글의 처음에 나온 코드는 (MSDN 글을 봐도 그렇다) 그다지 좋지 못한 예라는 것을 알 수 있다..^^ 그래서 나도 현재 코드를 바꾸고 있는 중이다. 2번째 글의 네번째 버전으로(아래와 같이) 바꿀 예정이다. MSDN Article에 있는 코드와도 거의 같다고 보면 된다.

public sealed class Singleton
{
static readonly Singleton instance=new Singleton();

// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{
}

Singleton()
{
}

public static Singleton Instance
{
get
{
return instance;
}
}
}

Posted by kkongchi
.NET General2007. 2. 12. 11:09
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/a59935de-6b8f-4c0a-8479-e30bc0509698.asp

COM+ 서버 애플리케이션에는 아래와 같은 Authentication Level을 설정할 수 있다.

사용자 삽입 이미지


None: No authentication occurs. 즉 어떤 인증도 수행하지 않는다.

Connect: Authenticates credentials only when the connection is made. 최초 연결할 때만 인증을 수행한다.

Call: Authenticates credentials at the beginning of every call. 매번 호출 시마다 Credential을 인증한다.

Packet: Authenticates credentials and verifies that all call data is received. This is the default setting for COM+ server applications. Credential을 인증하면서 모든 호출 데이터가 도착했는지 검사한다. 이것이 디폴트 설정이다.

Packet Integrity: Authenticates credentials and verifies that no call data has been modified in transit. Credential의 인증과 함께 모든 호출 데이터가 도중에 변조되지 않는지를 검사한다.

Packet Privacy: Authenticates credentials and encrypts the packet, including the data and the sender's identity and signature. Credential의 인증도 하면서, 데이터와 호출자의 Identity와 Signature를 포함하는 모든 데이터를 암호화한다.

대부분 디폴트 레벨을 그냥 쓸 것이다. 나도 그랬고.. 하지만 이 인증 부분은 사실 각 애플리케이션 별로 고려되어야 할 사항임에는 분명하다. 더 중요하고 크리티컬한 애플리케이션에 대해서는 Packet Integrity나 Packet Privacy까지도 고려되어야 할 것이다. 특히 원격에서 COM+ 컴포넌트를 호출할 수 있도록 구성되어 있다면 더더욱! 그리고 그렇게까지 보안에 신경 쓸 필요없다면 더 낮은 레벨로 낮추는 것도 생각해 볼 수 있다. 보안 레벨이 낮아지면 낮아질 수록 성능이 더 좋아지기 때문이다.

Posted by kkongchi
Software Engineering2007. 2. 9. 15:18
현재 일하고 있는 회사에서는 버그 관리 시스템으로 Bugzilla를 사용하고 있다. 개발팀에서 빌드가 이루어진 제품을 QA팀이 가져가서 테스트를 하게 되고, 테스트 중에 발견된 버그들이 이 Bugzilla에 등록되게 된다. 그리고 개발자들은 등록된 버그를 해결하고 다시 그것을 QA팀에 통보를 한다. 이런 과정들을 반복하면서 버그가 줄어들고 또 제품의 Quality가 높아지게 되는 것이다.

나는 지금까지 3개의 버그 관리 시스템을 사용했다. 처음 써 본것은 Microsoft의 RAID이다. 이 제품은 상용 제품은 아니고, Microsoft에서 내부적으로 사용하는 것인데, Microsoft 컨설턴트 분들과 프로젝트를 진행할 때에 이것을 2번 정도 사용을 했었다. 그리고 얼마전까지 속했던 프로젝트에서는 Microsoft Visual Studio 2005 Team System에 포함되어 있는 버그 관리 시스템을 사용을 했다. 그리고 지금은 Bugzilla까지..

이 3개의 시스템은 사실 아주 비슷한 구조를 가지고 있다. 버그를 등록하고 상태를 변경하고(상태에는 Open, Resolved, Fixed, Re-open 등등이 있고) 그리고 메일 등으로 alert을 제공하고 등등.. 그래서 사실 어떤 버그 관리 시스템을 쓰더라도 특별한 차이가 있는 것은 아니다.

중요한 것은 어떻게 쓰느냐이다. 버그 관리 시스템을 그냥 버그 리스트로만 봐서는 안 된다고 생각한다. 버그 관리 시스템은 버그의 관리 뿐 아니라. 버그와 그에 연관된 많은 정보들이 모두 모아져야 한다. 그러기 위해서 내가 생각하는 몇 가지 원칙을 좀 제안해 보고자 한다.

1. 자신의 코드에서 버그를 찾아서 수정했을 때에도, 버그로 기록하자.

버그의 갯수는 물론 개발자를 평가하는 기준이 될 수도 있다. 그래서 대부분 테스트 팀에 넘어가기 전에 자기가 발견하고 수정해 버린 버그에 대해서 버그 관리 시스템에 등록을 하지 않는 경우가 대부분이다. 하지만 나는 그것들도 기록해두는 것이 좋다고 생각한다. 어떤 버그 혹은 이슈는 두고두고 개발자를 괴롭히는 경우가 많다. 그럴 때에 대부분 "그게 뭐였지.." 하면서 기억을 뒤지게 되는데, 버그 관리 시스템에 등록되어 있다면 더 쉽게 찾을 수가 있다.

그리고 하나의 버그를 찾아서 그것을 기록하고 정리하는 과정에서, 그 버그에 대해서 완전하게 이해할 수가 있다. 그러면 자신의 코딩 습관에서 버그를 유발시키는 코드에 대해서 더 잘 이해할 수 있을 것이고 그럼으로써 더 좋은 코드를 작성할 수 있게 될 것이다. 그리고 처음에 말했던, 자신의 버그 숫자가 늘어나는 문제 때문에 등록을 망설인다면, 더 좋은 코드를 작성할 수 있기 때문에 가면 갈수록 버그 숫자는 줄어들게 될 것이다.

2. 버그를 기록할 때는, 재현에 필요한 모든 정보를 남겨야 한다.

이것은 사실 개발자보다는 테스트, 매니저 등에게 사실 하고 싶은 말이다. 우리는 버그 관리 시스템에서 자주 이런 아주 간단한 버그의 내용을 보게 된다. "OOO 기능 작동하지 않음", ""XXX 기능 에러 남" 등등.. 그런데 개발자들에겐 이런 정도의 말은 사실 이해하기에 너무나 부족한 말이다. 틀림없이 테스트해서 내보낸 것인데, 어떤 상황에서 에러가 나는 것인지, 무슨 짓을 하다가 발생한 에러인지 확실히 알 수가 있어야 한다. 이런 식으로 커뮤니케이션하다가 서로간에 사이가 안 좋아지기도 한다..^^;;

버그를 해결하는 과정의 첫 걸음은 바로 "재현(Reproduction)"이다. 즉 다른 사람이 발견한 버그를 개발자가 재현해보고, 그것을 해결할 실마리를 얻을 수가 있는 것이다. 그런데 이 재현을 하기 위해서는 상세한 정보가 필요하다. 버그가 발견된 머신의 소프트웨어 상황이라던지(어떤 브라우저, 어떤 OS 등등) 어떤 오퍼레이션을 어떻게했는지 등의 상세한 정보가 있어야 바로 그 버그를 재현할 수가 있다. 이런 정보가 없이는 버그를 재현하기가 힘들다. (아예 잘 되지 않는 경우도 있다. 실제로 소프트웨어 사용 습관이 사람마다 매우 다른데, 그래서 개발자는 자신의 사용습관만을 테스트해서 버그를 찾지 못했지만, 테스터는 사용 습관에 따라서 버그를 찾을 수도 있기 때문이다. 이 경우, 개발자는 이런 사용습관에 대한 정보가 없이는 버그를 재현해내기가 매우 힘들다)

재현에 필요한 모든 정보를 남겨야, 개발자가 재현하는 데 드는 시간도 줄어들 수 있고, 개발자와 테스터 간의 커뮤니케이션(혹은 말다툼) 시간도 줄일 수가 있고 결과적으로 많은 시간을 절약할 수가 있다. 그 시간에 버그를 더 수정할 수도 있을 것이고, 전체적인 퀄리티를 더 높일 수도 있으며 혹은 뭔가 다른 일을 하면서 개인적인 성취를 이루거나, 사회에 공헌을 할 수도 있을 것이다. ^^;;

3. 개발자는 버그에 대해서 되도록 자세한 정보를 Comment로 남기는 것이 좋다.

개발자들도 버그를 수정한 다음에 Comment를 자세하게 남겨야 한다. "버그 맞습니다. 고치겠습니다", "버그 수정되었습니다", "버그 아닙니다" 이 정도의 커멘트로는 역시 대화가 되지도 않고, 이후에도 아무런 도움이 되지 않는다.

재현이 안 되었다면 자신이 재현을 한 과정과 환경을 써야 하고, 재현이 되었고 실마리를 찾았다면 그 실마리를 적어야 한다. 수정을 했다면 어떤 모듈을 어떤 식으로 고쳤는지 기록해야 한다. 물론 이것이 개발자만 보는 시스템이 아니기 때문에, 자세한 기술적 내용을 쓸 필요가 없기도 하고 그렇게 쓰지 말라는 말을 들을 지도 모르겠다. 하지만 그런 부분은 그 사람들이 가려서 읽으면 된다.

기술적인 내용 등을 자세하게 쓴다면, 개발자는 이 버그 관리 시스템을 일종의 KnowledgeBase로 활용할 수가 있다. 그리고 개인적으로뿐만 아니라, 전체적으로도 이런 자세한 내용은 분명히 도움이 될 것이다. 비슷한 증상이나 버그 혹은 기술적인 문제 때문에 다른 개발자가 지금 고생하고 있을 수도 있다. 그런 사람들에게 장황하게 설명하기보다는 Bug No XXX를 참조하세요라고 말할 수가 있다.. 훨씬 편리한 것이다.

4. 버그로 인해서 소스 코드가 수정되었다면, 그 수정된 부분에 등록된 버그ID등을 주석으로 남겨서 연결고리가 될 수 있도록 해야 한다.

버그를 해결하기 위해서 소스 코드를 수정하게 될 것이다. 아마 대부분 수정하면서 그 내용을 주석으로 남길 것인데, 거기에 버그 번호를 붙이는 것이 좋다. 나중에 "이 버그는 어떻게 해결하셨어요?" 라고 누군가 물어볼 때, "아..기억이 안나..ㅜ.ㅜ" 보다는, 에디터를 열고 버그 번호로 찾으면 쉽게 찾아서 잘난 체 할 수가 있다.

Visual Studio Team System처럼 소스 제어와 버그를 링크할 수 있다면, 더 쉽게 찾을 수가 있다. 이런 기능은 적극적으로 활용해야 한다. 물론 귀찮다. 나도 VS2005 Team System 사용했을 때 이 기능은 전혀 사용하지 않았다. 하지만 나중에는 좀 후회를 했다. 나중에 버그나 Work Item과 관련된 소스 혹은 코드 일부를 찾는 일은 정말 힘들다. 코딩한지 3달 이상된 코드에 대해서는 거의 못 찾는다고 해도 과언이 아니다. 미리미리 준비를 해두는 것이 좋다.

이상, 버그 관리 시스템을 잘 쓰기 위한 생각들을 좀 정리를 해 보았다. 처음에는 귀찮고 개발할 시간을 뺐는 것처럼 보여도 결국에는 도움이 되는 것이 바로 버그 관리 시스템이라는 생각이 든다. 기왕 쓰는 것이라면 최선의 활용방법을 찾는 것이 더 좋을 것이다.

* 더 좋은 아이디어나 노하우가 있다면 댓글이나 트랙백으로 한 마디씩 해주셨으면 합니다..
Posted by kkongchi
.NET General2007. 2. 6. 15:05
윈도우즈 서비스로 만든 닷넷 모듈에 문제가 생겨서 디버깅할 일이 있었다. 알다시피 윈도우 어플리케이션은 일반 닷넷 어플리케이션처럼 확장자는 exe이지만, 독립적으로는 실행되지 않고, 서비스에 등록되어서 실행되게 된다.

그래서 디버깅을 하기 위해서는 Visual Studio의 프로세스 디버깅 기능을 이용해야 한다. 즉 아래 그림처럼 서비스의 프로세스를 비주얼 스튜디오 디버깅 메뉴에서 직접 연결해서 디버깅하는 것이다.

사용자 삽입 이미지


그런데 오늘은 위 방법을 쓰기가 힘든 상황이 발생했다. 왜냐하면, 초기 작업에 문제가 있었던지 서비스 시작이 아예 되질 않는 거다..-_-;; 서비스 시작이 되질 않으니 프로세스를 디버깅할 수가 없는 문제가 발생했다.

결국 난감한 상황에서 언제나 한줄기 빛을 던져주시는(^^;;) 구글님에게 문의를 해보았고, 원하던 답을 찾을 수가 있었다. http://weblogs.asp.net/paulballard/archive/2005/07/12/419175.aspx 즉, 윈도우 서비스 초기화 코드에 아예 아래 코드처럼 디버깅을 시작할 수 있는 코드를 삽입하는 것이다.

<MTAThread()> _
Shared Sub Main()

#If DEBUG Then
        System.Diagnostics.Debugger.Launch()
#End If


이렇게 컴파일된 모듈을 서비스 MMC에서 시작시키면, 아래 그림처럼 디버깅 윈도우가 뜨고 비주얼 스튜디오를 이용해서 디버깅할 수가 있다.

사용자 삽입 이미지


내가 참조한 포스트의 저자는 Debugger.Break()을 사용해서 중단점을 걸면 된다고 말하고 있지만, 물론 컴파일할 때에 비주얼 스튜디오에서 중단점을 걸어놓는다면, 그것도 작동된다.
Posted by kkongchi
Software Engineering2007. 1. 28. 21:29

Empower team members

멤버들에게 많은 권한을 위임한다.


이 항목에 대해서 MSF White Paper는 다음과 같은 구절을 인용한다.


“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. The structure of a team is a network, not a hierarchy."

"최고의 팀에서는 각각 다른 개인이 각자의 전문 분야에 대해서 리더십을 그때마다 제공한다. 누구도 계속해서 리더가 될 수없는데, 항구적인 리더는 동등한 관계의 팀 상호작용을 파괴시키기 때문이다. 팀의 구조는 계층 구조가 아니라 네트워크이다."


Tom DeMarco and Timothy Lister "피플 웨어"



다분히 이상적인 말이지만, 지향해야 할 길이라는 건 분명하다. 소프트웨어 개발 프로젝트가 아닌 모든 분야에 적용할 수 있는 말이기도 하다. 어떤 분야에서건 모든 것을 다 알고 있는 사람이란 있을 수가 없기에, 동등한 자격의 팀 구조에서 어떤 이슈에 대한 최고의 전문가가 각 이슈에 대해서 팀을 이끈다면, 당연히 최고의 성능을 낼 수가 있을 것이다.

현재는 많은 곳에서 이런 시도가 있다. 사회의 전반적인 분위기도 많이 바뀌었을 뿐 아니라 이런 변화가 없는 기존 구조로는 많은 문제점이 나타나기 때문이다. 물론 가야 할 길이 많은 것이 아직도 우리 나라의 전체적인 분위기는 조금은 경직된 상명하복 식이기 때문일 것이다.

SI 프로젝트에 적용해서 말해보자면, 역시 PM 혹은 팀 리더의 노력이 요구가 된다. 결국 커뮤니케이션이 잘 되고, 팀 멤버들에 대해서 많은 것을 파악하고 있어야 이런 일들이 가능하기 때문이다. 손쉽게 편한 방법으로 가고자 한다면 이런 것들이 왜 필요하겠는가? 아무리 자그마한 이슈라고 하더라도, 최선의 방법을 찾으려는 노력이 있어야, 그리고 그러기 위해서 모든 팀 멤버들의 의견을 청취하는 노력이 있어야 할 것이다.


다른 원칙 보기

Foster open Communications (열린 커뮤니케이션을 장려한다)

Work toward a shared vision (비전을 공유하고, 그 비전을 목표로 작업한다)
Empower Team Members (팀 멤버들에게 많은 권한을 위임한다)
Establish clear accountability and shared responsibility (팀,개인의 의무를 분명히 하고, 동시에 책임을 모두가 공유해야 한다)
Focus on delivering business value(비즈니스 가치에 초점을 맞춰야 한다)
Stay agile, expect change (언제나 유연하게 변화에 대응할수 있도록 한다)
Invest in Quality (품질에 투자한다)
Learn From all Experiences(모든 경험으로부터 배운다)
Posted by kkongchi
asp.net2006. 11. 19. 01:19


특정 폴더에 있는 이미지를 웹 화면에 출력해야 하는데, 그 폴더를 웹 가상 디렉토리로 만들기가 힘든 상황이 있을 수가 있다. 아무래도 웹 가상 디렉토리로 노출되는 것은 보안에 문제가 있을 수 있다는 것을 의미하고, 그 폴더가 이미지 외에도 많은 내부 자료들이 들어있는 공용 스토리지라면 가상 디렉토리로 만드는 것은 좋지 않은 선택이다.

이럴 때, 이미지 파일을 읽어서 웹 화면에 출력해줄 수 있는 ASPX 웹 페이지 코드를 소개한다. 아래 코드는 서버의 파일명을 파라미터로 받아서, 그 파일을 이미지 형태로 웹 화면에 출력하는 코드이다.

일단, ASPX 페이지에는 아무런 HTML 코드가 없어야 한다. 아래와 같이 ASPX 페이지 지시자만 놔두고 모두 삭제하도록 한다.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

비하인드 코드는 다음과 같다. 아래 코드는 Page_Load 이벤트 핸들러에 두면 된다.

System.Byte[] arrBytes = null; //파일을 바이트로 읽기 위한 변수를 선언
string fileName = null; //파일명을 받을 변수 선언

try
{
  Response.ContentType = "image/jpeg" //Content Type을 반드시 image/jpeg 혹은 image/gif 등의 image 유형으로 지정해야 한다.
  fileName = Request["FileName"];

  if (!String.IsNullOrEmpty(fileName)) //파일명이 전달되지 않았을 때의 분기
  {
   arrBytes = new System.Byte[1000000]; //바이트를 넉넉하게 지정하자. 이 크기가 파일보다 작다면 에러가 발생한다.
   System.IO.FileStream fs = null; //파일을 읽기 위해 파일스트림 선언
   string filePath = fileName;
   string defaultFilePath = "c:\\camels.jpg" //파일이 존재하지 않을 때 사용할 이미지
   if (System.IO.File.Exists(filePath))
   {
     fs = new System.IO.FileStream(filePath, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
   }
   else
   {
     fs = new System.IO.FileStream(defaultFilePath, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
   }

   fs.Read(arrBytes, 0, 1000000);
   fs.Flush();
   fs.Close(); //파일스트림객체는 사용한 후에 반드시 해제해야 한다.

   Response.Clear();
   Response.OutputStream.Write(arrBytes, 0, arrBytes.Length); //웹 Response에 파일을 직접 쓴다. 이로써 이미지가 출력된다.
  }
  else
  {
   throw new Exception("파일명이 지정되지 않았습니다");
  }
}
catch (Exception ex)
{
  Response.Write(ex.ToString());
}


이 ASPX 페이지는 다음과 같이 사용하면 된다.

<img src="default.aspx?FileName=C;\\Camels.jpg"/>


사실, 이렇게 이미지를 웹 페이지로 출력하는 방법은 그렇게 좋은 방법은 아니다. 사실은 HttpHandler를 사용하는 것이 더 좋다. HttpHandler를 사용하는 방법은 Dino EspositoImage Generation Service for ASP.NET 1.1를 참조하기 바란다.

그리고, 위 샘플 코드는 파일 경로가 GET 파라미터로 완전히 보이기 때문에 그냥 사용하면 안된다. 적어도 파일 명 앞의 경로는 Config 파일에 두는 방법을 사용하길 바란다.

Posted by kkongchi
.NET General2006. 11. 3. 14:32

어제, 오늘 아주 깜짝 놀랄만한 뉴스가 연이어 터지고 있다.
어제는 MS가 PHP Zend와 기술 제휴를 하더니, 오늘은 Suse Linux의 노벨과 전격 제휴를 했다고 한다.

Zend의 경우, .NET Framework에서 PHP 소스가 한 줄의 코드 변경도 없이 완벽하게 동작하는 것이 목표라고 한다. PHP.NET? 그러면 ASP.NET은?

Suse Linux의 경우, MS에서 공식적으로 밀어주기로 한 모양이다. 즉, MS 제품 고객들이 윈도우즈 서버와 함께 리눅스 서버를 함께 쓰길 원하는 경우에 Suse Linux를 추천하게 될거라고 한다. 그리고 공동 개발을 통해서 한 대의 머신에서 두 OS를 같이 쓸 수 있도록 한다는데...

아무튼, 굉장히 충격적인 소식이다. 이건 마치 한나라당과 열린우리당이 손을 잡았다는 얘기와 똑같은 게 아닐런지...-_-;;


Posted by kkongchi
Internet Explorer2006. 10. 30. 14:10
http://blogs.msdn.com/ie/archive/2006/10/27/msxml5-not-in-this-ie.aspx

IE Blog에 얼마전에 올라온 글인데, MSXML 5.0은 Internet Explorer 7.0에서 자동으로 쓸 수가 없고 반드시 사용자가 한 번 사용하겠다는 확인을 해 줘야 한다. 즉, MS에서 만든 것임에도 불구하고 여타의 액티브X와 같은 취급을 받는 거라고 볼 수 있다. 만약 예전에 만든 웹 애플리케이션에서 MSXML 5.0을 사용했다면 이런 사태를 겪기 전에 바꿔야 할 듯... (물론 사용자들에게 허용하라고 해도 된다.)



* 지금 다시 읽어보니, 심각한 오해가 있었다...-_-;; 없다는 것이 아니고, (어차피 MSXML은 따로 설치할 수도 있기 때문에..) 그래서 글을 급히 수정...
Posted by kkongchi
규칙클래스이름:TypesThatOwnDisposableFieldsShouldBeDisposable
규칙ID:CA1001
분류:디자인 규칙
메시지 레벨:심각한 에러
확실도:95%

원인: System.IDisposable 인터페이스를 구현한 인스턴스 필드를 선언한 클래스에서 IDisposable 인터페이스를 구현하지 않은 경우에 해당한다.

규칙설명
클래스는 가지고 있는 관리되지 않는 리소스(파일 스트림 등의)를 제거하기 위해서 IDisposable 인터페이스를 구현하게 된다. IDisposable 형식의 인스턴스 필드가 있다는 것이 바로 그 필드가 관리되지 않는 리소스를 가지고 있다는 것을 말해 주는 것이다. 간접적으로 관리되지 않는 리소스를 가지고 있는 IDisposable 필드를 선언한 클래스는 반드시 IDisposable 인터페이스를 구현해야 한다. 또 주의해야 할 것은 직접적으로 어떤 관리되지 않는 리소스를 가지고 있지 않는 클래스는 finalizer를 구현해서는 안된다.

예제코드

[C#]
using System;
using System.IO;
 
namespace DesignLibrary
{
   //규칙을 위반한 예제이다.
   public class NoDisposeMethod
   {
      FileStream newFile;

      public NoDisposeMethod()
      {
         newFile = new FileStream(@"c:\temp.txt", FileMode.Open);
      }
   }

   //이 클래스 구현은 규칙을 만족한다.
   public class HasDisposeMethod: IDisposable
   {
      FileStream newFile;

      public HasDisposeMethod()
      {
         newFile = new FileStream(@"c:\temp.txt", FileMode.Open);
      }

      public void Dispose()
      {
         newFile.Close();
      }
   }
}


[VB.NET]
Imports System
Imports System.IO
 
Namespace DesignLibrary

  '규칙을 위반한 예제이다
   Public Class NoDisposeMethod
   
      Dim newFile As FileStream

      Sub New()
         newFile = New FileStream("c:\temp.txt", FileMode.Open)
      End Sub

   End Class

  '규칙을 만족하는 구현이다.
   Public Class HasDisposeMethod
      Implements IDisposable
   
      Dim newFile As FileStream

      Sub New()
         newFile = New FileStream("c:\temp.txt", FileMode.Open)
      End Sub

      Sub Dispose() Implements IDisposable.Dispose
         newFile.Close()
      End Sub

   End Class

End Namespace


관련 규칙
삭제가능한 필드는 삭제되어야 한다.
삭제가능한 형식은 finalizer를 선언해야 한다.
Dispose 메서드는 베이스 클래스의 Dispose 메서드를 호출해야 한다.
native 리소스를 가지고 있는 형식은 삭제가능해야 한다.


원문주소: http://www.gotdotnet.com/team/fxcop/Docs/Rules/Design/TypesThatOwnDisposableFieldsShouldBeDisposable.html
Posted by kkongchi
MS office2006. 10. 16. 23:27

Windows Live Writer는 Window Live Idea 팀에서 만든, Blog 툴이다. 사실 Blog 툴로 이 블로그에서 이미 소개했던 Microsoft Word나 Google docs & Spreadsheets 등의 많은 툴이 있지만, 이 툴도 나름대로 쓸만하다..

일단 이렇게 생겼다..



블로그를 설정하는데, 역시 친숙한 마법사 형식을 제공하기 때문에 상당히 쉽게 느껴질 것이다.



물론 다른 블로그 툴과 마찬가지로 기존 글도 열 수 있는데, MS Office 제품군과 유사한 UI를 제공한다.



이 툴에서 가장 좋은 점은...역시 이 화면이다.. 블로그에 올라간 모습을 미리 보기가 가능하다는 것...이 점은 마치 이 툴이 그 블로그의 내장된 에디터처럼 느껴지게 한다.

'MS office' 카테고리의 다른 글

[Article]Word 2007 Blog Post 기능  (2) 2006.10.15
[Article]OWA 2007의 모습...  (0) 2006.09.15
[Article]Office 2007 Beta 2  (0) 2006.05.29
Posted by kkongchi