'분류 전체보기'에 해당되는 글 1243건

.NET Framework의 대가와 MOSS 2007 프로그래밍의 대가들이 구축한 소스에 특정 사이트에 맞게 일부 커스터마이징되고 알지 못할 사람들이 이런 저런 업데이트를 가한 소스를 보고 있다. 이 코드가 Package라는 이름이 붙은게 조금 웃기는 사실이긴 하지만, base가 대가들이 만든거니 뭔가 특이하고 신기하긴 하다.

그런데, 도통 이해가 안되는 것 있다.
MOSS 2007 프로젝트를 하다가 보니 공통이라는 모듈 개념에 DAC(Data Access Component)와 BIZ(Business Logic Module)이 포함되어 이 둘이 Component 라는 형태로 붙어 있다. 그런데 이 모듈을 업데이트 하신 분은 DAC는 반드시 BaseDAC을 상속 받아야 되고 BIZ는 BaseBIZ에 상속 받아야 하는 강박관념에 빠지신 것 같다.

물론 DAC의 특성상 Database와 연관되는 작업이 많으니 BaseDAC을 상속 받아 기본 데이터베이스 연결에서는 반드시 쓸 필요가 있을지 모르겠다. 그런데 이 BIZ 부분은 도통이해가 안된다. 최소한 내가 예전에 배웠던 MVC(Model - View - Control) 부분의 Control 정도로 알고 있다. Workflow가 될 수 있고, 단순 계산 처리도 있을 수 있다. 그런데, 꼭 BaseBIZ를 상속 받고 Transaction을 태워야 될까? 크리티컬한 데이터라면, 반드시 All or Nothing을 추구해야 하는 데이터라면 반드시까지는 아니지만 태워야 하는게 기본이라고 생각한다. 하지만 단순한 계산이나 단순한 데이터인데 꼭 태워야 될까?

지금 로직들을 보고 있으면 참 답답한 마음이 그지 없다. 그냥, 적당히 분류해서 계통에 맞게 분리해서 모듈을 구성했으면 간단한 것을 이리 꼬아 저리 꼬아 놓으니 어느 순간에 순환 참조(참조가 계속 연결되어 자기 자신으로 돌아오는 참조)가 되어 그 고리를 끊기 위해 어셈블리(DLL)를 분리하는 불상사가 벌어진 것 같다. ( 해당 어셈블리(DLL)에 클래스 달랑 2개 들어 있다. 굳이 분리해서 따로 구성할 필요도 없는 그런 모듈인데....)
더 웃긴건, DAC이 있는데, Database 접근하는 모듈이 View에 해당하는 어셈블리에 담겨 있다. 왜 DAC을 만든건지.....

대가들이 만든걸 어설픈 누군가가 망친건지.. 아니면 대가 분들이 너무 오바해서 생각들을 하신 건지... 단순하게 만들어서 간단하게 끝낼 수 있는 것을 무쟈게 힘들게 짜놨다. 이제 슬슬 어느정도 그림이 그려지고 있는 판국이라 다행이긴 한데, 이걸 언제 정리해야 하는지는 도통 모르겠다.

UPDATE :
처음에는 프로젝트 수정작업을 할까 했지만, 이미 관계가 얽히고 섥혀 있어 대규모 공사가 되버릴 것 같다. 이 공사 하면 10중 8,9는 PM이 버럭 모드 들어갈 것 같다. GG. GG. 내비두자. 내버려 두자.

쓰다보니 제목이 길어졌다.
간혹 .NET 프로그래밍 하다보면, C:\Windows\Assembly 폴더를 자주 사용한다. 실행 창에서 assembly라고 입력하면 나오는 목록이 있는데, 이 목록을 이용해 .NET Assembly를 등록하거나 제거할 때 유용하게 쓰고, 현재 Assesmbly 목록을 체크해볼 때도 좋다.

그런데, 아주 간혹 이 창의 내용이 안뜨고, Gacutil 을 사용해 등록하려고 하면, 해당 파일에 대한 접근 권한이 없다는 오류가 종종 뜬다. Gacutil 이야 쓰는 사람만 쓰니 안되도 그만이겠지만, Assembly 창이 안뜨면 닷넷 초급, 중급이고 뭐고 상당히 당혹 스럽게 만든다.

간혹 이게 안되면 재부팅을 하거나, 아니면 운영체제를 아예 다시 깔곤 한다.

그럴때... 한번 체크해야 할 부분이 있다.

Start(시작) -> Control Pannel(제어판) ->Administrative Tools(관리도구)
  -> Services(서비스)

에 들어간다. ( 즉, 관리도구의 서비스 항목에 들어간다. )

그리고 아래의 항목이 활성화 되어 있는지 확인한다.

Indexing Service(인덱스 서비스)

만일 활성화 되어 있으면 당장 서비스를 Stop(중지) 시키고 다시는 자동으로 실행되지 못하게 Disable(비활성화)로 만들어 버린다.
원인이야 다양하고 많겠지만, 최소한 나같은 경우에는 저 Index 서비스가 동작하면서 내 Assembly들을 찝적 거리는 것 같다. 그래서 안되는 지도.....

일단, 지금 그 서비스 당장 저세상으로 보냈더니 정상적으로 동작한다.

요즘 보여주는 나와는 다른 세대의 전형적인 모습을 보여주는 가사이다. 멜로디는 O15B인데, 가사는 완전 요즘 스타일 요즘 20대, 10대를 위한 노래로 보인다. 전형적인 독점형 모습을 보여주고, 집착적이며 짜증나는 스타일.

처음 잘해줄때 잘하지 떠난 뒤 왠 지랄?

자기 잘못이 있으면 절대 인정하고, 다음 부터는 다른 사람과 만나게 되면 잘해주지, 괜히 후회나 하고 왜 인터넷 탓을 하는지 모르겠다. 잘해주지도 못하고 뭐하는짓인지 모르겠다. 제정신인지 체크가 필요한 가사인듯.

뭐 노래 부른 사람이나 작사한 사람은 그런 사람이라고는 생각은 안되지만,
( DMC 라는 애니 보면 더욱더 이런 생각이 강해지긴 한다.)
참 미치광이 같은 가사였다.

짜증 게이지 15% 상승;;;;

맨 처음에는 회사에서 연대리님과 권주임과 함께 시작했던 게임이였다. 사실 스포츠 게임에 대해서는 젬병에 가깝기 때문에, 그리 하고 싶지 않았지만, 그 둘이랑 하면 나름대로 재미가 있었다. 그래서 시작한 위닝.

울산 내려가기 2주전. 돌연 XBOX 360을 사게 되고 당연 타이틀을 위닝 일레븐으로 결정했다. 그리고 무척이나 열씸히 했다. 그러나 역시 저 두사람에게는 이길 수 없었다. ( 더욱이 네어라는 친구가 나랑 1:1 하면 늘 난 대파 당한다 - -;;;) 대전으로 시작한 게임이긴 하지만, 연습을 빙자한 솔로 게임을 하다보니 이것 또한 나름 재미가 있었다. 처음에느 연습게임만 하다가, 클럽하나를 선택해서 하는 단순 LEAGUE를 시작했는데, 내가 알고 있는 몇안되는 클럽 중에 하나인, AC 밀란을 택했다.

처음에는 잘 몰랐는데, 가만히 사람들의 이름을 보니, 나름대로 어디선가 주워들은 이름들이였다. 카카, 인자기, 호나우두(처음에는 Ronalodo 라고 적혀 있어 로날도 라고만 알고 있었다는...) 여기서 한참을 휩쓸고 놀았다. AC 밀란을 하면서 툭하면 카카 드리블하다가, 가끔 어시 하여 인자기 또는 호나우두가 골을 넣는... 환상의 팀.

그러나, 여전히 네어군에게는 늘 참패를 당하고 만다.
그러다 거기서 마스터 리그라는 신기한 세상을 배우고 커스텀 팀을 통해 나만의 팀을 만들어서 할 수 있다는 것도 배웠다. 여기서 처음에는 카카 없이 기본 값으로만 하다, 너무 어려워, 결국 카카와 박지성을 영입했다. 그러고 처음 시즌은 잘 보냈는데, 네고시에이션(협상) 모드에서 트레이드를 잘 못해, 변변한 스트라이크 없이 새 시즌에 들어가다 참패를 당하고 말았다.

이 교훈을 초석 삼아, 새로 팀을 꾸렸다. 욕심 탈탈 털고, 일단 카카와 30살 먹은 스트라이커를 영입했고, 그 둘을 기반으로 꾸준하게 우승을 했다. 처음에는 선수들을 키워야 되는 마음에 자꾸 써먹어야지... 라는 생각도 있었는지만, 다 접고, 걍 뛰었다. 체력 없으면 갈리고, 패스한 결과 좋은 포지션을 차지하고 있으면 망설임 없이 슛을 내질렀다.

결국 시즌 첫번째 트레이드에서 지성이를 데려왔고, 지금은 루니를 영입했다. 수비수도 대거 교체했다. 지금 대중 인기도가 E에서 출발해 A를 거쳐 S까지 올라갔다. 최소한 트레이드에서 꿀리지 않고 잘 나갈 것 같다.

아직까지 무패를 유지하고 있다. 카카의 몸값도 무쟈게 올랐다. 단, 공격수는 30살 처먹어서 걍 트레이드 시켰다. 일단 33세 이상된 선수들은 나중에 재계약을 하지 않거나 트레이드 할 예정이다. 이번 협상은 훌륭하게 끝낸것 같다. 공격수도 루니를 필두로 안정적으로 배치된 것 같고, 수비수도 수비수 제어가 가능한 친구가 둘 이나 되고, 수비 능력도 어느정도 된다.  잠깐 자동으로 켜보았는데, 한골도 안먹고 도리어 한골을 먹는 자동화된 모습도 볼 수 있었다.

이번 시즌 게임은 정말이지 기대된다.

예전 포스팅 중 [ Javascript, 객체화 하기 ] 라는 제목으로 올린 것이 있다.
그 때 쓴 포스팅 방법에 의거해서 예제 소스를 하나 구성하면 아래와 같다.

var objTest = {
      valDisplay : "",
      displayValue : function () {
            alert(this.valDisplay);
      }
     
      setValue : function(val) {
            this.valDisplay = val;
      } 
};

위의 예제를 실행해 보려면, 적절한 위치에서 아래와 같은 코드를 실행해 보면 된다.

objTest.setValue("Go Go Objected Javascript World");
objTest.displayValue();

그런데, 위와 같은 코드를 하게 되면 문제가 하나 있다. 예를 들어 objTest와 같은 로직을 부르는 곳이 많을 때다. 여기서 부르는 곳이 많다는 의미를 단순히 호출 자체의 횟수가 아니고, valDisplay를 독립적으로 운영해야 되는 경우를 말하는 것이다.
예를 들어 아래와 같은 코드를 보도록 하자.

objTest0.setValue("Go Go Objected Javascript World");
objTest0.displayValue();
objTest1.setValue("No, I Want to new display valueGo Go Objected Javascript World");
objTest1.displayValue();

위와 같은 코드를 실행하려면 아래 처럼, 처음 코드를 두개 넣어야 한다.

var objTest0 = {
      valDisplay : "",
      displayValue : function () {
            alert(this.valDisplay);
      }
     
      setValue : function(val) {
            this.valDisplay = val;
      } 
};
var objTest1 = {
      valDisplay : "",
      displayValue : function () {
            alert(this.valDisplay);
      }
     
      setValue : function(val) {
            this.valDisplay = val;
      } 
};

처음에는 단순하게 생각했었다. objTest0 = objTest; objTest1 = objTest; 이렇게 하면 되지 않을까 하고....그런데, 그렇게 쉽게 되지는 않았다. 두개의 변수는 하나의 objTest를 바라보고 있어, 결국 값은 valDisplay를 공유한 꼴이 되버린 것이다.

이에 구글링과 테스트를 반복하여 그 방법을 드디어 찾아냈다.
즉 첫번째 소스를 이렇게 변경하면 된다.

objTest = function() {
     this.valDisplay = "";
     this.displayValue = function () {
            alert(this.valDisplay);
      }     
      this.setValue = function(val) {
            this.valDisplay = val;
      } 
};

실제 실행하는 코드는 아래 처럼 짜면 된다.

var objTest0 = new objTest();
objTest0.setValue("Test0 objTest!!!!");
var objTest1 = new objTest();
objTest1.setValue("Test1 objTest!!!!");

new 라는 것을 사용해서 만들기 때문에, 새로운 인스턴스가 생성되며 별개의 메모리 상에서 동작하게 되는 것이다. 이렇게 될 수 있는 건 자바스크립트의 미묘한 마법때문이다. 예전에 이런 문제 발생한적이 있지 않은가?

var realVar = "Init Data";
reelVar = "Update value!!!";
alert(realVar);

결과는 의도한 "Update value!!!"는 안찍히고 "Init Data"가 찍힌다. 그 이유는? reelVar 라는 변수 명이 잘못된 것이다. 그러나 씹고 그냥 진행되고 도리어 reelVar라는 변수가 하나 더 생기고 그 안에 값이 들어가 버린다. 맨 아랫줄에 alert(reelVar) 찍어보면 그제서야 "Update value!!!" 가 찍힌다. 자바 스크립트에서는 새로운 형태의 변수가 발견되면 일단 변수를 멋대로 만든다.

이런 기묘한 자바스크립트의 성질을 이용해 구성하는 것이다.
코드를 하나씩 뜯어 보도록 하자.

objTest = function() {      
};

     this.valDisplay = "";

     this.displayValue = function () {
            alert(this.valDisplay);
      }

이번에는 displayValue 라는 형안에 또다른 함수를 때려 박는다. 이 함수는 objTest.displayValue로 호출 된다. 그런데 만일 아까 this.valDisplay = ""; 가 아닌 var valDisplay = "" 라고 쓴다면 저 함수 안에서는 밖에서 정의한 변수를 쓸 수 없다. (물론 무한한 자바스크립트 세계에서 "완전 불가"/"절대" 란 없으니 "완전 불가"/"절대" 라는 말을 뺐다.) 즉 내부에서 사용하기 위한 변수로 쓰기 위해서 this. 라는 것을 붙여서 처리한 것이다.

여튼, 지금 필자는 MOSS 2007에 WebPart라는 개념이 있는데, AJAX 스럽게 만들려다 보니, 같은 스크립트를 여러 다른 웹파트들이 쓰게 되었는데, 일단 저렇게 간신히 해결하는데 성공했다. 미묘한 감동 찌리리링 상태다.

지금 MOSS 2007을 기반으로 다양한 인트라넷을 개발해왔다.

SK 에너지 부터 SKT 마케팅 부문, SKT 전체 인트라넷 시스템, FS 2.0 이라는 솔루션에 지금은 현대 중공업 인트라넷 시스템이다.
물론 초반에는 나도 별로 아는 것 없어 그냥 하라는대로 따라하는 경향이 좀 강했다. 모르니 할 수 없었다. 그런데, 계속 이런 저런 삽질과 헤딩을 해본 결과, 이런 결론을 얻었다.

패키지가 제공하는 기본기능은 그냥 둬라.
커스터마이징이 필요하면 복사 한뒤, 다른 이름으로 동작시켜라!

아마도 어디를 고쳐야되는지 모를 때, 해당 페이지 부분을 따라가보니, 이런 이런 마스터 파일을 기본으로 제공하는데 이걸 수정하니깐, 다 바뀌더라 .. 라는 생각으로 MOSS 2007 패키지에서 제공되는 기본 파일을 낼름 수정해 버리는 경우가 많다.
(지금 여기서는 application.master 파일을 막 수정하곤 한다.)

그런데 만일, 진짜 만일이다. MS의 WSS 또는 MOSS 2007 개발팀에서 application.master에 심각한 오류를 발견했다. 그래서 Service Pack 또는 Patch에서 이 application.master를 업데이트 했다면? 패치하고 나니 화면이 이상하게 변하거나, 안뜬다고 한다면.....
아무 생각없이 고치던 사람인 경우, 다분 이런 상황에 빠지면 즉시 서버 Rollback 들어간다. MS에서 고민고민해서 설정한 보안 문제나 버그는 딴 세상 이야기가 된다.

제발이지... 커스터마이징을 시작했다면, 기존 패키지 기본 제공 코드나 페이지, 이미지들은 그대로 두었으면 한다. 단지 그 하위에 새로운 폴더를 만들거나 다른 이름의 파일을 만들어 마음껏 커스터마이징을 하고, web.config 나 SPSite의 설정을 변경하여 그 변경된 사항이 기본이 되도록 하도록 했으면 한다.

오늘도.... 코드 작성 중 필요한 기능이 있어서 12 폴더 내용을 모두 복사하다가 반파 된 내 MOSS 2007 사이트 꼬라지에 어이가 없어 한마디 적는다.

그런데 최소한 내가 지금까지 같이 프로젝트를 뛴 프로그래머들 중 대부분은 자신의 코드를 혹은 저명한 누군가의 코드를 절대 신뢰하고, 그것을 기준 삼아 이야기를 펼친다. 그래서 분명 잘못되었음을 지적해도 절대 그렇지 않다고 한다. 때로는 원래 그렇다고 한다.이래서는 아무것도 개선할 수도 오류를 수정할 수 없게 만든다.

자신의 자식 새끼 같은 코드이고, 믿음직한 코드들일 수는 있겠지만, 최소한 컴퓨터에서 돌릴 때, 수많은 다양한 상황에 처하면 완전 배반의 모습을 여과없이 보여준다. - 프로그래머의 실수나 잘못된 로직을 스스로 고치면 이미 그건 프로그램이 아니고 생명체일 것이다. -
컴퓨터에서는 자신에게 장착된 H/W와 그 안에 구성된 프로그램대로 동작할 뿐이다. 신뢰하는 누군가가 만든 코드든, 제 잘난 맛에 사는 자기 자신이 짠 코드든, 분명 헛점이 있고, 오류가 있을 수 있다. 그래서 컴퓨터에서 오류가 발생하면 눈에 보이든 보이지 않던 의도하지 않은 오류가 분명 어딘가에 있다. 물론 내가 지적한 부분에서도 오류가 있을 수 있다. 혹은 무언가를 간과하고 짚은 부분도 있을 것이다.

그러나 그러기 앞서 같이 논의할 자세는 취해주어야 하지 않을까? 특히 다른 이의 코드를 멋대로 수정하기 앞서 자신의 코드 부분부터 확인해주는 센스도 같이 있으면 정말이지 좋겠다.

최소한 프로그래밍으로 밥벌이한다고 한다면, 조금은 완고한 자신의 생각을 접고 스스로를 의심하는 것이 좋지 않을까? 아니 같이 고민하는 열린 자세 정도는 필요하지 않을까....내 멋대로 생각해본다.

VS 2005나 VS 2008에서 참조를 추가 할 때, .NET 탭에 보면 각종 Assembly DLL 목록을 볼 수 있습니다. 여기에 보면 각종 MS 제품들에 딸린 Assembly들을 보는 대신, 우리가 만든 Assembly들은 보이지 않습니다. 물론 실제 Runtime시에는 GAC에서 직접 읽어오기 때문에, VS 2005나 VS 2008에서 보이지 않는다고 동작하지 않는 것은 아닙니다.

단지 개발하는데 있어 왠지 소외된 느낌? 왠지 개발 중 DLL 등록하는데 조금 뭔가 부족한 느낌? 그런 것 때문에 그런 것일 뿐입니다.
뭐 그래도 개발자에게 찜찜한 느낌은 개발 속도 향상에 나쁜(?) 영향을 주므로 이런 부분을 해결하는 방법을 알려드리도록 하겠습니다.

(원문 : http://support.microsoft.com/default.aspx?scid=kb;en-us;306149&Product=vsnet )

"참조 추가" 대화상자에서 어셈블리들을 표시하는 방법.

VS 2005, 2008 등에서 참조 추가 대화 상자가 떴을 때, .NET 탭을 열어보면 각종 Assembly들의 목록을 볼 수 있는데, 이 안에 직접 만든 DLL들의 목록도 뜨도록 하는 것입니다.

이 내용안에 추가하려면, 아래의 레지스트리 위치로 이동합니다.

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders]

그리고 새로운 키(폴더)를 만든 뒤, 그 안의 default 안에 등록할 Assembly들이 있는 경로를 넣어주십니다.

레지스트리 경로표현하면 아래와 같이 정리될 수 있습니다.

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]@="C:\\MyAssemblies"

등록 후 VS 를 다시 시작하시면 됩니다.

참고 : 위의 경로에서는 HKEY_CURRENT_USER 로 되어 있는데, 위의 경로로 하면 현재 로그인된 사용자만 적용됩니다. 모든 사용자 단위로 적용하시려면 HEKY_CURRENT_USER 부분을 HEKY_LOCAL_MACHINE 으로 변경하시면 됩니다.