개통 두달만에 스팸 SMS가 1300여건…

난 정말이지 억울하다.

아이폰이 개통되던 날 임의로 생성해 준 내 번호가 맘에 들지 않아, 근처 KT지점까지 직접 내방해서 번호를 골라서 변경해 왔다.

010-ooo5-1577   (o는 동일번호다)

뭐 딱히 좋은 번호는 아니지만.

현재 회사의 대표번호가 3oo3-1577이다보니 나도 번호를 1577로 골랐을 뿐이다.

번호를 변경하고 기분좋은 마음으로 룰루랄라~ 사무실로 들어와서 기존 핸드폰에 등록되어있던 400여명에게 동보문자를 보냈다. 번호가 바뀌었노라고….

그 이후로… 난 줄곧 스팸 SMS에 시달리기 시작했다. ㅠ.ㅠ

아이폰의 순정상태에서는 스팸 SMS나 원링등에 대처할 방법이 전무하기에 Jail Breaking을 시도하고 MClearner를 설치했다. 위 화면에서 보듯 그저 86개의 스팸SMS에 대한 번호를 등록했을 뿐인데.. 2009년 12월 3일, 아이폰 개통 이후 필터된 스팸SMS는 1338건이다. 이미 400여명의 지인에게 변경번호에 대한 동보 문자를 보냈기 때문에 다시 번호를 바꾸고 싶어도 불가피하게 계속 쓸 수 밖에 없다. ㅠㅠ

정말이지 억울한건…

난 단 한통의 060 전화를 해본적이 없단말이다!!!!

새롭게 하고자 하는 비즈니스의 철학..

인류에 있어 가장 희소성 있는 상품은 ‘시간’이다.

새롭게 하려는 비즈니스는 앞으로 남아있는 가장 큰 시간인 ‘시간’을 서비스하는 것입니다.

희소성이라고 하는 것은 조금밖에 없다고 해서 희소한 것이 아닙니다. 또한 희귀하다고 해서 희소한 것도 아닙니다. 물론 희소성은 상대적이고 주관적이기 때문에 사람들 마다 떠올리는 대답은 다를 것입니다.

하지만 시간이 가장 희소하다는 것에 대해서는 대부분 공감할 것입니다.

그렇지만 시간이 공짜라고 착각하는 사람들이 있습니다. 희소한 시간을 낭비하여 허튼곳에 쓰는 사람들이지요. 시간의 기회비용을 인식하지 못한 탓이기도 합니다.

– 이 글은 계속 작성중입니다.

오랜만의 블로그 업그레이드!?

너무 오랜만에 블로그 툴의 업그레이드를 하려다보니 본의아니게 기존에 작성되었던 포스트의 첨부 파일이 사라지는 실수를 저질렀습니다. 헌데 생각해보니 꽤 중요한 이미지는 없는 듯 해서 복구하는 시간에 몇 줄 더 코딩에 매진하려 과감히 포기합니다.

어쩌면 구글을 비롯한 검색엔진이 이미지를 수집해 갔을지도 모르지만. 대충 훑어보니 썸네일만 가져간 모양입니다. 다시 찾아서 복구하려는 시간은 과감히 포기합니다.

워드프레스를 2.9.x로 판올림 했습니다. 더불어 스킨도 변경했습니다. ;-)

잠깐의 시간동안 바꾼 결과 치고는 뭐.. 만족스럽습니다.

인터페이스와 확장메서드의 활용

기본적으로 다중 상속을 지원하지 않는 C#의 디자인때문에 인터페이스 상속을 이용해 다중상속을 구현해왔습니다. 이와 관련한 내용으로 오래전부터 포스팅해야 겠다는 생각만 했을 뿐 실천을 하지 못하던 중 여유가 생겨 정리해 봅니다.

인터페이스 선언

RegisterFrm

위 코드에서 보듯 Java와 마찬가지로 C# 역시 여러 클래스를 동시에 상속할 수 없습니다. 따라서 Java와 동일한 방법으로 인터페이스를 이용하여 이러한 결과를 얻을 수는 있습니다. 하지만 인터페이스는 메서드 시그니쳐가 포함되어있을 뿐 구현이 포함되어있지 않습니다. 인터페이스는 상수, 필드, 생성자, 소멸자, 모든 형식의 정적멤버를 포함할 수 없습니다.

따라서 C#에서 여러개의 클래스를 상속하고자 한다면 반드시 인터페이스를 이용해야 하고, 그 구현부는 상속받은 클래스에서 구현되어야 합니다.

인터페이스 사용

FiscalizacionDetailBase

이 예에서는 보여드리는 클래스인 FiscalizacionDetailBase라는 클래스는 전자결제를 사용하기 위해 IElectronicApproval을 상속하고 있습니다. 하지만 또다른 RegisterFrm이라는 클래스는 이력관리를 위한 IHistoryManagement를 상속하고 있습니다. 모두 같은 FormBase라는 슈퍼클래스를 상속하고 있습니다.

따라서 각 기능에 해상하는 상속을 구현하기 위해(=다중 상속을 이용하기 위해) 각기 다른 인터페이스를 상속받고 있습니다.

하지만 C# 3.0부터 지원하는 확장 메서드를 이용한다면 무척 편리하게 구현이 가능합니다. (물론 개발자 입장에서 구현의 편리함을 강조하는 것입니다.)

이 예에서는 전자결제에서 사용하고자 하는 매개변수들과 이력관리에서 사용하는 매개변수가 다릅니다. 때문에 해당 인터페이스에 해당하는 구현부를 각각의 클래스들에서 구현했었어야 합니다. 물론 객제지향개발 방법론에 의하면 올바른 구현이 아닙니다.

이를 OOP의 가르침대로 구현하려면 먼저 FormBase가 각 인터페이스를 상속하고, FormBase에서 인터페이스를 구현했었어야 합니다. 그 이후 FormBase를 상속하는 클래스에서는 필요한 인터페이스를 상속하여 구현된 시그내처를 사용하는 것입니다. 그러나 이렇게 구현을 했을 경우 지나치게 FormBase가 무거워질 수 있습니다. 사용하지 않는 불필요한 구현부가 있기 때문이지요. OOP에 대해 이야기 한다는것 자체가 꽤 진부하니 OOP이야기는 여기서 마무리하지요.

이야기하고 있는 인터페이스는 다음과 같이 디자인 했습니다.

   1:      public interface IElectronicApproval : IHistoryManagement
   2:      {
   3:          Enum.ButtonMode eButtonMode { get; set; }
   4:          string BizDocType { get; }
   5:          string CurrentSaveFlag { get; set; }
   6:          string CurrentStatusCode { get; set; }
   7:          decimal CurrentVersion { get; set; }
   8:          string HoldingResult { get; set; }
   9:          string ExistResult { get; set; }
  10:          string ScreenName { get; set; }
  11:          string Language { get; set; }
  12:      }

   1:      public interface IHistoryManagement
   2:      {
   3:          Enum.UIMode eUIMode { get; set; }
   4:  
   5:          string RegisterCode { get; set; }
   6:          string RegisterLocation { get; set; }
   7:          string UpdaterCode { get; set; }
   8:          string UpdaterLocation { get; set; }
   9:          DateTime RegisterDate { get; set; }
  10:          DateTime UpdateDate { get; set; }
  11:          DateTime EffectiveDate { get; set; }
  12:      }

보다시피 각 인터페이스는 메서드 시그내쳐는 없습니다. 다만 프로퍼티들만 존재할 뿐입니다.

이에 필요한 메서드는 확장메서드를 이용해 구현합니다. 다음과 같이 말이죠.

   1:          public static void SetApprovalRequiredParameter(this IElectronicApproval electronicApproval, RequestParameter rParam)
   2:          {
   3:              rParam.Add("BizDocType", electronicApproval.BizDocType);
   4:              rParam.Add("SaveFlag", ((ushort)electronicApproval.eButtonMode).ToString());
   5:  
   6:              rParam.Add("CurrentSaveFlag", electronicApproval.CurrentSaveFlag);
   7:              rParam.Add("CurrentStatusCode", electronicApproval.CurrentStatusCode);
   8:              rParam.Add("CurrentStatusCode1", GetStatusCode1(electronicApproval.CurrentStatusCode));
   9:              rParam.Add("CurrentStatusCode2", GetStatusCode2(electronicApproval.CurrentStatusCode));
  10:              rParam.Add("CurrentVersion", electronicApproval.CurrentVersion);
  11:  
  12:              rParam.Add("Language", SetNullAsValue(electronicApproval.Language, Session.LANGUAGE));
  13:  
  14:              electronicApproval.SetHistoryRequiredParameter(rParam);
  15:          }

이렇게 구현한 확장메서드를 상속받은 클래스에서는 다음과 같이 이용합니다.

SetApprovalRequiredParameter(rParam);

이와 같이 인터페이스의 메서드 시그니쳐를 확장메서드를 이용해 구현하여 사용하는 방법도 있습니다.

검색엔진이 찾아준 악플러. ;-)

MS의 Bing이 출시된 이후 재미로 입력해 본 검색 키워드 ‘zerople’의 검색 결과에 살짝 놀랐다.

2006년즈음 한 블로거가 CSS 수정을 원하기에 거리낌없이 도움을 드린적이 있다. 헌데 그분은 포스트를 통해 나에게 감사의 인사를 전했고. 그 포스트에 3년이 지난 후에 악플 하나가 달려있는것을 확인했다. 헌데 이지님은 블로그를 개편중이신가보다. 현재 링크는 살아있지 않다.

검색엔진이 저장한 페이지를 통해 확인해 본 결과. 작성된지 3년이 넘은 포스트에, 3주전쯤 달린 악플 하나.. 검색엔진을 통해서야 확인할 수 있었던 본인.

음.. 검색엔진이 가져다 주는 결과인가.. 문명의 이기는 도대체 어디까지 진화할 수 있는 것일까.

검색엔진에 걸린, 악플러!?

나에 대해 정확히 알고 있는 것을 보면 내 주변 인물임에 틀림없겠지만. ^^  그래도 부탁하나만 하자.

나도 잘 모르는 사람 블로그에 가서 악플 남기지 말고.. 차라리 내 블로그에 쓰렴.. 다른 사람 블로그에 악플 남기면 내가 찾아 보기도 힘들잖니..?

More >