Try & Error

 is 연산자 : 두 객체가 동일한지 비교하는데 사용, is 연산자는 해당 객체가 is 오른쪽 형식과 호환되는지 확인만 한다. 객체 형식을 변경할 수 는 없다.

1. char data = 'a';
2. if(data is char)
3. System.Console.WriteLine("문자 데이터 입니다.");
4. else
5. System.Console.WriteLine("문자 데이터가 아닙니다.");

as 연산자 : 객체가 호환되지 않으면 null 값을 할당, 호환되면 형식(casting)을 시켜준다. as 연산자는 강제 형변환과 비슷하며 변환시 예외가 발생하면 null을 채운다.

1. string obj = data as string;
   if(obj != null)
   {
    ....
   }

아래의 형태는 as 연산자가 하는 기능이다.

 

출처 : http://ocplay.springnote.com/pages/2731066 

C# 코드를 짤 때 좀 더 효율적인 코드를 짜기 위한 방법들을 정리한 포스트이다.
먼저 Code Project의 아래 포스트를 번역한 후 다른 글들도 한번 찾아 봐야겠다.

원본 : http://www.codeproject.com/KB/cs/effectivecspart1.aspx#item1

포스팅한 날짜가 2005년꺼라 꽤 오래된 자료라 현재 버전에서는 어느정도 차이가 있을듯하다.

---

Item 1 - String의 사이즈를 체크할때는 Length Property를 사용하라.[Performance]

String 비교는 불필요한 overhead를 포함하고 있다. 스트링이 비어 있는지를 체크하는 것이라면

Length properthy를 사용하도록 한다.

//NO

if ( str != "")//comparison of two strings {...}

//YES

if ( str.Length > 0) {...}

Item 2 - String을 연속적으로 붙일 때에는 StringBuilder 객체를 사용하라.[Performance]

C# string은 변경되지 않는다. string 값이 변경할 때, 아래와 같은 문제들이 야기된다.

• 필요한양보다 메모리를 추가적으로 더 사용하게 된다.
• garbage collector가 작업해야 될 일들이 더 생긴다.
• 실행시 느려지는 코드를 만들게 된다.

//NO

String strConcat;
ArrayList arrayOfStrings = new ArrayList();
arrayOfStrings.Add("a"); 
arrayOfStrings.Add("b");
foreach (string s in stringContainer) {
  strConcat += s; 
}

//YES

StringBuilder sbConcat = new StringBuilder ();
foreach (string s in arrayOfStrings ) { 
  sbConcat.append(s);
}

Item 3 - 되도록이면 Boxing과 UnBoxing을 피하라[Performance]

BBoxing은 garbage-collected 힙 영역에 value types들을 저장하는데 이용된다.

value type이 box되면 새로운 ojbect가 메모리에 잡히고 생성되어야 한다.

즉, 아래의 두가지 작업이 일어난다.

  - Object 인스턴스를 할당한다.

  - 위 인스턴스에 value type 값을 복사해서 넣는다.

위의 이유로 되도록이면 Boxing을 피하는것이 좋다. ArrayList를 예로 들어보면 struct 키워드를

통해서 ArrayList의 값을 넣을 때 위와 같은 Boxing과 UnBoxing이 일어나게 된다.

//NO

struct st { public Int i; }
Arraylist arr = new ArrayList();
for (int i=0 ; i< count; i++) { 
  st s;
  s.i = 4; 
  arr.item.add(st) ; //<- Boxing (Allocating an object instance

                     // + copying the value-type value into that instance)

}
st obj = (st ) arr[0]; //<- Unboxing (casting and copy)


//YES

//Decalre the data type as class.

Class st { public Int i; }

Item4 - == 대신 Equal 함수를 사용하라 [Performance]

== 보다 equal 함수를 사용하는것이 좀 더 빠르다.

string s1= "code";
string s2 = "code1";
//No:

if(s1 == s2){...}
//Yes:

if(s1.Equals(s2)){...}

Item5 - 'foreach' 말고 'for' 를 사용해야 하는 케이스  . [Performance]

'foreach' 랑 'for'  키워드는 일부 비슷한 기능을 한다. - 블록 안에서 루프를 돌면서 기능을 수행

foreach와 for를 사용할때 가장 중요한 차이쯤은 루프문의 증가와 끝에 대해서 따로 작업이 필요 없다는것이다.  또한 foreach는 모든 collection을 사용할 수 있게 만들어졌다. foreach는for의 private한 case에 사용한다고 하기도 한다.

아래 코드를 통해서,  두 루프문이 동일한 결과를 낸다는것을 알 수 있다. 다만 foreach를 사용했을 경우퍼포먼스가 조금 떨어졌다. 좀더 무거운 변수와 큰 array를 사용하면 그 차이가 더 크게 날것이다.

foreach는 for에 비해서 좀더  사용하기 쉽지만 만약 큰 collection을 도는 경우는에는 'for' 를 사용하는것이 퍼포먼스에 좋을 것이다.

Code snippets:

 Collapse

//foreach

int[] arrayOfInts= new int[5];
int sum= 0; 
foreach(int i arrayOfInts) {
  sum+= i; 
}

//for

int[] arrayOfInts= new int[1]; 
int sum= 0;
for(int i = 0; i < arrayOfInts.Length; i++) {
  sum+= arrayOfInts[i]; 
}

Item7 - Prefer the �as� operator instead of direct type casting. [Usage]

The 'as' operator does not throw an exception. In case of bad cast, the return value is null.

Code snippets:

 Collapse

//NO

object o = 1.3; 
try
{
  string str = (string)o; 
} 
catch(InvalidCastException ex){...}

//YES

string str = o as string;
if(null != str){...}

Item8 - Use the 'checked' keyword to avoid overflow. [Usage]

Code snippets:

 Collapse

//NO

short shortNum;
int i = 32768;
shortNum = (short) i; 
// problem after statment excution

// the shortNum variable has an uninitialized value,


//YES

try {
  shortNum = checked((short)i); // solution 

}
catch(OverflowException efx) {}

Item9 - Use the 'is' operator instead of casting. [Usage]

Code snippets:

 Collapse

public class Preson{int nAge;}

//No:

static void main(object o){
  try {
    (Person)o.nAge = 45;
  }
  catch(InvalidCastException ex){...}
}

//Yes:

static void func(object o)
{
  if ( true == (o is Person) )
  {
    (Person)o.nAge = 45;
  }
}

Item10 - Use Explicit interface to 'hide' the implementation of an interface [Usage]

Implementing an interface explicitly 'hides' the interface methods. Visual Studio does not display the interface methods in the intellisense.

Code snippets:

 Collapse

//interface definition

Public interface IChild{
  bool IsHuman();
  void lie();
}

//class definition

Pubic Pinocchio: IChild {
  IChild.IsHuman() //explicit interface implementation

  {
  }
  public void Lie(); //regular interface implementation

}

//using the object

static void main()
{
  // Visual studio will not display

  // the isHuman mwthod in the intellisence.

  Pinocchio o = new Pinocchio();
  ((IChild) o).IsHuman(); // using the IsHuman method explicitly.

  o.Lie();
}

Item11 - Use @ to ease the work with literal paths. [Usage]

Code snippets:

 Collapse

//Old way

String sFilePath = �c:\\a\\b\\c.txt�;

//The C# way

String sFilePath = @�c:\a\b\c.txt�;

Item12 - Make your API assembly CLS Compliant. [Usage]

The CLS-Compliant attribute cause the compiler to check whether your public exposed types in the assembly are CLS-Compliant.

Prefer to define the attribute for the entire assembly, especially for API. The incentive to create a CLS compliant assembly is that any assembly written in one of the .NET aware languages can use your assembly more efficiently because there is no data types interoperability.

Code snippets:

 Collapse

using System; 
[assembly:CLSCompliant(true)]

Item13 - Define destructor and implement IDisposable interface for classes that use native resource directly. [Garbage Collection]

You should define a destructor whenever you use native code in your assembly, i.e., use types that are not managed by the garbage collector. The compiler changes the destructor method to Finalize method (can be seen in the MSIL using the ILDasm.exe).

The Garbage collector marks a class with destructor as Finalized and calls the Finalize method while destructing the object. This behavior guarantees that your release of resources in the destructor will occur.

But, what if you want to release the resources immediately? For this purpose, you should implement the IDisposable interface and call theDispose method when you want to release the object.

Note 1: Do not use destructor if your class does not use native / unmanaged resources. If you do so, you create unnecessary work for the garbage collector.

Note 2: If you implement the IDisposable and a destructor, you should call the Dispose method from the destructor to force the object to release resources immediately.

Code snippets:

 Collapse

~my class {
  if ( true == b) { 
  }
} 

//The MSIL code:

protected override void Finalize() {
  try { 
    if ( true == b) { 
    }
  }finally { base.Finalize();} 
}

Item14 - Avoid the use of GC.Collect. [Garbage Collection]

The GC.Collect method forces garbage collection of all generations.

The performance is hurt during the call to GC.Collect, the application execution is paused. Moreover, the method might cause the promotion of short lived objects to a higher generation, i.e., those object live longer than it should in the first place.

If you must use it in order to reclaim the maximum amount of available memory, use the method only on generation 0.

Code snippets:

 Collapse

//No:

GO.Collect();
//Yes:

GC.Collect(0);

Item15 - Use StructLayout attribute for classes and structs when using COM Interop. [COM Interop]

The attributes cause the compiler to pack the structure in sequential memory so that it can be sent to unmanaged code correctly (unmanaged code that expects a specific layout).

Code snippets:

 Collapse

using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Sequential)] 
public struct st{
  int i;
  float f;
}

What next?

The part II article, will deal with COM Interop in general, and events between managed and unmanaged code in particular.


출처 : http://www.cyworld.com/mengwi/7680825 

CTRL       - http://blog.naver.com/allmask/120094939628

ALT         - http://blog.naver.com/allmask/120094941844

Windows  - http://blog.naver.com/allmask/120094950571

etc          - http://blog.naver.com/allmask/120095093630

불펌 했어욤 ^^ 

출처 : http://coolose.springnote.com/pages/4942309

정수 자료형

실수 자료형

처음 코딩을 하게 되었을 때, 디버깅의 중요성에 대해서 전혀 모르고 있었다. 어느날 버그는 꼬였고, 중단점을 매우 많이 찍으면서 버그 사냥에 몰두하는 나 자신을 보게 되었다. 이것은 .. 디버깅은 정말 정말 중요하다는 사실을 깨닫게 해준 경험이였다.

디버깅을 위해 F9 키를 누르는건 친근한 작업이었고, 보다 더 한눈에 들어왔으면 좋겠다는 생각이 들기 시작했다. 결국 옵션에 이런것이 있지 않을까? 란 궁금증이 들게 되었고, ... 옵션을 가게 된다.

비쥬얼 스트디오 전체

위 그림에서 "도구" 를 클릭한다.

다음과 같은 화면이 나오면, "디버깅 탭"으로 이동 한다.

"디버깅 탭"에서 "일반 탭" 으로 이동 한다.

이 곳의 세부 설정중 "중단점과 현재 문의 전체 소스 줄 강조 표시" 를 체크 한다.

... 그러면 다음과 같은 효과를 내게 되는 것을 보게 된다.

이것으로 나는 가독성을 높이게 되었고, 눈과 머리로 버그를 보게 되었다.

총평

간단한데, 지금까지 모르고 했었다는게 좀 안타깝다. 이런 Tip 들이 한두가지가 아닌데, 하나씩 정리해 나가는게 좋을 것 같다. 여기서 중요한 사실을 알게 되었는데, "가독성"이란 존재는 머리에도 영향을 미친다는 것이다.

또한 사용자가 보기 편하게 만들어야 한다 는 .. 절대적인 룰으로 받아 들여 진다.

위로 가기

요구 사항

• Microsoft Visual Studio .NET 또는 Microsoft Visual Studio 2005

• Visual C# 구문
• Windows 폼

위로 가기

만들기 및 예제 양식 채우기

1. Visual C# 에서 새 Windows 프로그램을 만듭니다.
2. TreeView 컨트롤을 Form1에 추가하십시오.
3. ToolTip 컨트롤을 Form1에 추가하십시오.

위로 가기

도구 설명을 위해 TreeNodes 추가

1. Form1 로드 이벤트에 다음 코드를 붙여 넣습니다.

   // Create a root node.
   TreeNode rootNode = treeView1.Nodes.Add("Day of Week");
   
   // Create a series of child nodes and then set the Tag property for each.
   for (int count = 0; count <= 6; count++)
   {
      DayOfWeek day = (DayOfWeek)count;
      TreeNode childNode = rootNode.Nodes.Add(day.ToString());
      childNode.Tag = "This day is " + day.ToString() + ".";
   }
   
   // Expand all of the TreeView nodes.
   rootNode.ExpandAll();
   					

2. TreeView MouseMove 이벤트에 다음 코드를 붙여 넣습니다.

   // Get the node at the current mouse pointer location.
   TreeNode theNode =  this.treeView1.GetNodeAt(e.X, e.Y);
   
   // Set a ToolTip only if the mouse pointer is actually paused on a node.
   if ((theNode != null))
   {
      // Verify that the tag property is not "null".
      if (theNode.Tag != null)
      {
         // Change the ToolTip only if the pointer moved to a new node.
         if (theNode.Tag.ToString()!=this.toolTip1.GetToolTip(this.treeView1))
         {
            this.toolTip1.SetToolTip(this.treeView1, theNode.Tag.ToString());
         }
      }     
      else
      {
         this.toolTip1.SetToolTip(this.treeView1, "");
      }
   }
   else     // Pointer is not over a node so clear the ToolTip.
   {
      this.toolTip1.SetToolTip(this.treeView1, "");
   }
   					

   노트 해당 코드는 Visual Studio 2005에서 변경해야 합니다. Windows Forms 프로젝트를 만들 때 Visual C# 한 폼을 프로젝트에 기본적으로 추가됩니다. 이 폼은 Form1을 이라고 합니다. 폼을 나타내는 두 파일의 Form1.cs 및 Form1.designer.cs가 지정됩니다. Form1.cs 있는 코드를 작성할 수 있습니다. Windows Forms 디자이너 도구 상자에서 컨트롤을 끌어서 의해 수행된 모든 작업을 구현하는 코드를 기록하는 위치 designer.cs 파일이 없습니다. Windows Forms 디자이너를 Visual C# 2005에 [NULL]에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 방문하십시오.
   http://msdn2.microsoft.com/en-us/library/ms173077.aspx
3. 저장하고 프로그램을 실행하십시오. 노드 중 하나에서 마우스 포인터를 잠시 두면 도구 설명이 나타납니다.
   
   
   출처 : http://support.microsoft.com/kb/322634/ko 

[참조]

시험 기간이구나

이 글을 읽는 독자 중 다수는 아마 고등학교 시험 기간 중에 컴퓨터 전문 서적을 맹렬히 읽고 싶은 열망을 누르기 어려웠던 적이 있을 것이다. 나도 그랬다. 그러면서 우린 상상을 했다. "아, 컴퓨터에 대해 시험 공부하면 얼마나 좋을까." 그런 사람들이 대학에 들어가 컴퓨터 전공을 하면 시험 기간 중에 컴퓨터 책이 아닌 또 다른 주제를 공부하고 싶어진다(내가 그랬다). 내가 아는 뛰어난 프로그래머 몇 명은 시험 기간만 되면 재미난 프로그램을 하나씩 만든다(물론 시험과는 전혀 상관이 없는 프로그램들이다). 그래서 나는 그 친구가 프로그램을 하나 만들면 "아, 요즘 시험 기간인가 보구나"하고 추측한다.

꿈의 직장, 그리고 현실

우리는 항상 부러워하는 회사가 한 둘은 있다. 돈을 많이 주기도 하고, 좀 더 수평적이기도 하고, 야근이 없어서이기도 하고, 개인 프로젝트 시간을 주기 때문이기도 하다. 아, 식사가 맛있어서이기도 하다.

신문에서, TV에서, 블로그에서 그 회사가 소개되면 점심 시간에 남몰래 그 자료를 꼼꼼히 읽으며 마음 속으로 외친다. ‘아, 나도 저 회사에서 일하고 싶다.’ 그러고는 퇴근 이후 친구들과 어울려 술잔을 기울이며 회사에 대한 불평을 안주 삼는다. "우리 팀장은 말이야...", "우리 사장은 말이야...", "우리 회사는 말이야..." 몇 시간을 그렇게 불평하다가 집에 돌아가 자고 나서 일어나면 다시 그 불만스러운 회사로 출근한다.

필자는 여러 개발자를 보아왔다. 많은 개발자가 현재 환경이 열악하다고 생각한다(정말 그렇다). 그리고 동경하는 직장이 한 둘 있다. 그런데 그런 사람들 중 일부에게서 어떤 패턴을 지속적으로 발견했다.

1. 그 사람들은 계속 현재 상황이 문제라고 생각하며 불평을 반복하고
2. 그 상황을 개선하는 데에 자신이 할 수 있는 일은 없다고 생각하며
3. 자신은 다른 직장에 가야 빛을 발할 수 있다고 믿으며
4. 따라서 현 직장에서는 최선을 다하지 않으려고 한다.

그런데 이상한 점은 그 사람들이 스스로 그렇게도 불만스러워 하는 그 직장이 다른 어떤 사람들에게는 동경의 직장인 경우가 종종 있다는 점이고, 게다가 자신이 동경하는 직장으로 옮겨도 거기에서 또 다시 불평을 하면서 다른 직장을 동경한다는 점이다.

파랑새를 찾아

나는 이런 현상을 파랑새 신드롬이라고 부른다.

노벨문학상 수상 작가인 모리스 마테를링크는 『파랑새』를 지었다. 많은 사람이 이 『파랑새』를 동화나 TV 만화 형태로 접했다. 띨띨(Tyltyl, 치르치르)과 뮈띨(Mytyl, 미치르)이라는 아이들이 행복을 준다는 파랑새를 찾아 긴 여행을 하지만 결국 찾지 못하고 집으로 돌아와서는 자기 집 새장 속의 새가 파랑새라는 사실을 알게 된다는 이야기다(그 뒤에도 이야기가 있고, 나름 중요한 메세지를 전한다).

사람들은 저마다 파랑새 직장을 찾는다. 하지만 그냥 상상해 보자. 내 파랑새 직장이 내가 이미 퇴사한 직장 중 하나라면(실제로 내가 예전에 퇴사한 회사를 동경해 입사하는 사람들도 있을 것이다)? 혹은, 현 직장이 내 파랑새 직장이라면?

만성 파랑새 신드롬에 걸린 사람들은 항상 불행하다. 언제나 파랑새는 내가 없는 곳에 있기 때문이다. 그래서 늘 파랑새가 있는 쪽을 동경한다. 그러면서 현재에 최선을 다하지 않는다. 핑계거리가 많다. 그러다가 자리를 옮기면 파랑새는 여기에도 없다. 고개를 갸우뚱한다. 이상하네. 여기에는 파랑새가 있을 줄 알았는데. 도돌이표.

직장을 바꾸거나 직장을 바꾸거나

마틴 파울러(Martin Fowler)가 재미있는 조언을 했다.

직장을 바꾸거나 직장을 바꾸거나.

동어 반복 같다. 그러면 멍청한 표현이다. 하지만 이 말은 꽤나 현명한 조언이다. ‘바꾸다’라는 말에 여러 가지 의미가 있다는 점을 재치있게 이용했다.

첫 번째 "바꾸거나"는 자신의 현 직장을 변화시키라는 뜻이고, 두 번째 "바꾸거나"는 그래도 안 되면 직장을 옮기라는 뜻이다.

여기에서 중요한 부분은 순서다. 우선 직장을 변화시켜 보고, 안 되면 직장을 옮기라는 것이다. 그냥 직장부터 옮겨보라는 조언이 아니다. 하지만 파랑새 신드롬에 걸린 사람들은 앞 부분이 없다. 그래서 가까운 파랑새를 발견하거나 자기 집 안에서 만들어내지 못한다.

파랑새 직장에서 일하기 위해서는, 내가 어떤 직장을 고르느냐 이상으로 내가 그 직장에서 어떻게 일하는지도 중요하다. 하지만 그 사실을 깨닫지 못하고, 계속 여기 저기를 옮겨다니며 불평한다. 왜 세상에는 내가 바라는 좋은 직장이 없냐고. 그런 사람은 설사 자기가 직장을 만들더라도 만족하지 못할 것이다.

치명적 질문

애자일 컨설팅은 기업 대상으로 구인 과정을 컨설팅해 주기도 한다. 성공하는 프로젝트를 위해 필요한 것들을 하나둘 챙겨넣다 보니 결국은 "적합한 사람을 애초에 뽑았어야 했다"라는 후회에 도달해서 구인 프로세스도 포함했다. 내가 스스로 사람을 뽑거나, 다른 회사를 위해 사람을 뽑아주거나, 조언해 주는 입장에서 항상 중요하게 여기는 질문이 있다. 이직을 계획하는 사람에게 면접에서 다음과 같이 묻는다. "지난 직장에서 가장 불만스러웠던 점이 무엇인가요?" 여기는 쉬운 부분이다. 핵심은 두 번째 질문이다. "그럼 그걸 개선하기 위해 어떤 구체적 노력을 하셨나요?"

중요한 것은 그 노력이 성공했냐 못했냐가 아니다. 물론 성공까지 했으면 좋겠지만 그런 사람이 왜 굳이 이직을 하려 할까. 정말 중요한 것은 노력을 했냐 안 했냐 하는 것이다. 불만스러웠지만 정말 아무 노력도 안 한 사람이라면 파랑새 신드롬에 걸린 사람일 확률이 있다. 약간의 패배주의와 회의주의 그리고 보신주의를 조금씩 섞으면 파랑새 신드롬에 걸린다. 그런 사람들은 회사에 들어온 다음 전염병을 일으키는 경우가 있다. 쉬는 시간만 되면 밖에 담배 피러 나가 동료들에게 이 회사를 욕하고 다른 회사를 부러워하는 이야기를 한다. 뭔가 일이 안 풀리면 회사의 체제 욕을 하고, 상사 욕을 한다. 이런 이야기를 자꾸 듣다 보면 사람이 부정적으로 생각하는 습관이 든다. 전염된 것이다.

나에겐 아무 문제가 없다. 하지만 왜 내게 애인이 없는지 모르겠다고 주장하는 사람들을 잘 관찰해 보자. 몇 분 안에 백 가지도 넘는 이유를 찾아낼 수 있다. 파랑새 신드롬에 걸리면 자신은 자각하기 어렵지만 남들은 비교적 쉽게 알 수 있다.

다양한 병원체

꼭 직장에 대해서만 이런 일이 벌어지는 것이 아니다. 파랑새 신입사원, 파랑새 팀장, 파랑새 기획자, 파랑새 영업사원, ......

또 사람에 대해서만 파랑새 신드롬이 걸리는 게 아니다. 파랑새 언어, 파랑새 방법론, 파랑새 빌드 도구, 파랑새 프레임워크, ......

파랑새 언어를 좇는 사람을 예로 들어보자. 그 사람에겐 주특기 언어가 없다. 딱히 내세울 언어가 없다. 다 고만고만하다. 이 언어 집적거리다가 보면 이런 단점이 보이고, 저 언어 집적거리다가 보면 속도가 맘에 안 들고, 주변에서 이 언어가 전망이 좋다고 하니 또 잠깐 입문서 깔짝대다가 하는 식이었다. 결국 파랑새 언어들 뒤꽁무니만 계속 좇아 다니면서 항상 불안하다. 이 언어가 맞나? 그 동안 파랑새 신드롬에 안 걸린 개발자는 자신이 쓰는 언어의 결을 따라 사용하려 연구하고, 자신이 이미 아는 언어들을 상보적으로 사용하고 있다.

빌드 도구도 그렇다. 주변에서 좋다고 해서 좀 공부해 보려고 했더니 화면이 맘에 안 든다. 그래서 다른 도구를 구해다가 공부했다. 하면서도 ‘아닌데 아닌데’ 싶다. 결국 최근에 새로 급부상하는 도구를 좀 만져본다. 가장 기본적인 기능만 세팅을 했는데 ‘아뿔싸, 거시기 기능이 지원되지 않는다네.’ 오늘도 또 파랑새 빌드 도구 찾으러 웹 서핑을 한참 했다. 그러는 동안, 파랑새 신드롬에 걸리지 않은 개발자는 기존에 팀원들이 쓰던 셸 스크립트와 파이썬 스크립트 좀 엮어서 간단하게 빌드 자동화를 했다.

지금 여기

켄트 벡(Kent Beck)의 익스트림 프로그래밍 2판 서문에 감동적인 글귀가 있다.

• 상황이 어떻건 간에 당신은 언제나 더 나아질 수 있습니다(No matter the circumstance you can always improve).
• 당신은 언제나 자기 자신부터 개선을 시작할 수 있습니다(You can always start improving with yourself).
• 당신은 언제나 오늘부터 개선을 시작할 수 있습니다(You can always start improving today).

나는 이 글을 가끔씩 들춰보면서 몸과 마음을 추스리곤 한다. 사실 내가 할 수 있는 것은 정말 많다. 그리고 그것은 바로 지금, 바로 여기에서 시작할 수 있다. 지금 여기에서 시작하지 못하면 나중에도 안 될 확률이 높다.

우선은 쉽고 간단한 것부터 시작을 해보자. 또 남이 나를 행복하게 해주지 못하면 스스로에게 보상을 주고 행복하게 만들면 어떨까.

작은 변화라고 너무 실망하지 말자. 때로는 작은 변화이지만 다른 사람에게는 큰 변화로 다가오는 경우도 있다. 매일 밤 10시가 넘어 집에 오느라 애 얼굴을 사진으로만 확인하는 처지라면 하루에 30분씩 일찍 집에 와서 아이가 자기 전에 30분이라도 놀아주면 어떨까. 아이 입장에서는 천지 차이가 될 것이다. 지금 당장은 물론이고 그 앞으로 오랫 동안.

하지만

하지만 마틴 파울러가 한 조언의 마지막 부분을 늘 잊지 말자. 직장을 옮긴다고 세상이 끝나지는 않는다. 정말 불행하다고 느낀다면 떠나라. 하지만 직장을 옮기되 파랑새를 찾으러 가지 말고, 만들러 가라. 나는 수년 전에 안전한 직장을 관둔 적이 있다. 지금 생각해 보면 참 잘했다고 생각이 든다. 당시 아내가 한 말이 큰 위안이 되었다. "설마 우리가 길바닥에 나앉겠어? 때려쳐." 거창고 직업 선택 십계명의 아홉 번째 항목(부모나 아내가 결사반대를 하는 곳이면 틀림없다, 의심치 말고 가라)이 해당하지 않는 예인 듯 싶다.

관리되는 코드(C# or C++/CLI) 와 비관리되는 코드(C or C++)이 프로젝트에서 함께 사용되는 경우가 발생한다.
이때 사용되는 기술이 Interop 기술이다.

MSDN : 비관리 코드와의 상호운용

다음 두가지 경우를 생각해보자.

1. C++에서 C# 함수 호출

ps. 여기까지 C#의 컨트롤을 가져와 C++에서 운용하는 VS2003으로 되어있는 프로젝트를 VS2008로 업그레이드 하면서 Interop에 대하여 정리하였다. 

    닷넷1.1에서 동작하던 함수들이 닷넷2.0으로 넘어오면서 발생된 문제.. 
    http://www.codeforum.net/blog/pitoosung/entry/Net-Framework-11-에서-Net-Framework-20-으로의-Migration-CollectionBase-문제#comment1328

    Custom Object를 닷넷2.0에서 직접 가져와 사용하는 부분이 닷넷2.0에서는 불가능해진것 같다.(확실하진 않음)
    Object를 가져오는 인터페이스와 Collection Enumerator를 사용하면서 가져오는 부분은 에러를 리턴한다. 
    그래서 C++은 C#의 인터페이스 함수만 참조하게 단순화 시켰다. 

    그리고 예제 코드는 클래스 이름과 인터페이스이름을 바꾸면서 적은 코드로 동작안할 가능성이 있음.. 참조만 하시길..^^;
    관련 예제 - http://msdn.microsoft.com/ko-kr/library/65t81w8a.aspx