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

A 태그(<A>) 라든가, DIV 태그(<DIV>), 또는 SPAN 태그(<SPAN>)을 이용하여 안에 각종 Text를 넣을 수 있다. 그런데, 이 Text에 대한 설명이나 말을 줄여 놓으면 그 원래 크기의 문자열을 표시하고 싶을 때가 있다.

이 때 괜찮은 방법이 바로 툴팁이라는 조그만한 노란 창이 좋다. 이것을 사용하려면, 태그 안에 title 이라는 속성 내에 값을 넣어주면 된다.

다양한 Tag 내에서 속성 값으로 title 이라는 속성 값 내에 툴팁으로 표시하는 방법이다. 현재까지 테스트된 태그로는 <A> <DIV> <SPAN> 이며 이외에도 다양한 태그들 안에서 동작가능할 것 같다.

만일 특정 테이블 안에 Text에서 툴팁이 나오게 하기 위해서는 <span title="툴팁내용">test</span>  또는 <div title="툴팁내용">test</div> 라는 형태로 넣어주면 나오게 된다.

테스트 결과 FF 3.0과 IE 7.0 에서 정상적으로 표시된다.
(FF 2.X에는 어떤지는 잘 모르겠다.)

6년 동안 제 홈페이지를 운영해오고, 여기저기 neohihd 라는 계정으로 회원가입 부터 글 작성까지 다양한 활동을 해왔죠.

그래서 한번은 다음과 같은 실헙을 했습니다.
과연 저를 나타내는 검색어에 뭐가 표시되는지 한번 보았습니다.

내가 구글을 사랑하는 이유중 하나인듯. "인도짱"을 제외한 모든 검색에 최상단에 위치해 있습니다. 물론 비인기 검색어인 인도짱이 3위에 오르고 있는 야후도 만만치 않지만, 저 검색어를 대부분 소화하는 건 구글 밖에 없는듯 싶군요. 나머지는 손으로 하는지, 특이하게 분석하는지 잘 검색은 안됩니다. 게다가 대부분의 포탈들은 통합 검색이라는 제한 요소 덕에 제 웹페이지 검색은 저 뒷전 입니다.(笑)

뭐 검색이 되든지 말든지라는 생각은 들지만, 이런거 잘 되면 나름 홈페이지 광고지 않을까 싶기도 합니다.

P.S. 그런데, 제 홈페이지는 비영리다 보니(Google AdSense도 날아가서 더더욱) 광고가 되든지 말든지 상관은 없는데 왜 이런데 연연하는지는 잘 모르겠습니다. 유명세를 타고 싶은 욕망일까요?

이 홈페이지는 벌써 운영한지 6여년이 흘러 흘러 지금까지 온 홈페이지 입니다.

2001년도 여름 즈음, 도메인을 하나 구매했습니다. hind.pe.kr.
그 당시 유행했던 pe.kr의 도메인을 하나 산 거죠.
최초에는 당시에 다니고 있던 명지대학교 객체지향 연구실에 있는 한 서버에
연결해 놓고, 제로보드와 Wiki를 설치해서 운영하고 있었습니다.
아마 그 때 즈음 친구들에게도 이런 저런 사이트를 나눠 주곤 했는데,
사이트를 제공 받던 한 친구와 미묘한 의견 대립으로 인해 완전 찟어지는
사태가 발생하기도 했습니다. 물론 그 이후로는 친구들에게 사이트 자원은
나눠주지 않았습니다. ( 딱 한명 정광선이라는 친구에게만 잠시 자원을 추가해서
나눠 준듯 싶군요)

그 당시에는 많은 실험과 실험을 반복했습니다. 잘 알지 못하는 HTML과 Javascript.
그리고 PHP 언어의 혼란 속에서 이런 저런 시도를 했습니다.
최초 이 사이트를 만든 주요 관심사는 제가 알고 배워왔던 것들을 까먹지 않기 위해서 였습니다. 때로는 메모 형식으로 때로는 길게 장문으로도 써왔던 것 같습니다.

그러다 언젠가, 학교 서버가 맛탱이가 가버렸습니다. 그거 간신히 회복하니 이번에는 교내 망 자체가 맛이 가더군요. 무제한에 가까운 자원(서버 HDD, 네트워크 트레픽 등등)의 매력은 완전히 상실된 결정적인 계기가 되었습니다. 그러나 마땅히 어디로 옮겨야 될지 판단이 서지 않더군요. 그러다, 초등학교 친구인 이선경이라는 친구가 cafe24.com의 저렴함을 알려주었고, 그 기회에 냅다 옮겼습니다. 물론 미어터지게 작은 HDD 용량(100M), 무지하게 작은 트래픽(1G? 4G?)였지만, 나만의 공간이 생기는점에 행복했습니다.

제로보드를 설치하고 내 홈페이지로써의 디자인을 한 뒤, 게시하였고, 차츰 Apache 및 PHP에 대한 이해와 함께 제로보드의 장점들도 서서히 눈에 들어오더군요.

그런데, 실제 제가 쓰는 의도는 기술 나열이라고 했으나, 자꾸 모든 컨텐츠를 게시판 별로 쪼개는게 마음에 들지 않았습니다. 더욱이 제목만 덜렁 덜렁 보이는 것도 마음에 들지 않았고요.

그러다 문득, 외국 한 사이트에서 블로그 라는 기능을 보게 되었고, 그 기능에 감동했습니다.
제목과 글이 쭉 나열되어 바로 제가 찾던 그 모습이였죠.
그러나, 이런 블로그를 개발하는데는 한계가 있었습니다. HTML이나 PHH 그리고 제로보드를 어느정도를 이해한다고 했지만, 그건 단순히 머릿속에서 깨달은 것이였고, 실제 개발이나 완벽한 수술을 위한 지식은 아니였죠. 그러다 문득 제로보드용 블로그로 제시하는 스킨을 받았고, 그걸로 업데이트하기 까지 이릅니다.그.러.나. 태생이 게시판. 게시판의 한계는 계속 되었고, 저의 불만은 점점 커졌습니다. 분명 제목과 글이 나오기는 하는데, 글은 어딘가 부족하게 출력되는 것 같고, 간혹 보이는 알 수없는 버그들과, 글이 이상하게 표시되기도해 하여, 점점 제로보드 게시판 글 작성 자체에 짜증이 물씬 물씬 오르더군요.

그러다, 테터툴즈라는 것을 우연히 보았습니다. 공개 블로그 툴이라 더군요. 초기에 각종 블로그 툴들에 마음은 있었지만, 지금껏 작성한 게시판 글들은 어떻게 해야 하나 하는 고민이 있었습니다.  그러나 다행이도 저와 같은 고민을 하신분이 있었고, 제로보드의 글을 이 테터툴즈로 이전시킬 수 있는 기능을 찾아냈고, 그 즉시 그 작업을 수행하기에 이릅니다. 쉽고 간편하더군요.

그리고 지금까지 왔습니다.

운영한지 6년. 많은 검색엔진들의 로봇이 들락 달락했으며, 종종 제 글을 찾아볼 수 있더군요.( 사실 대부분 검색에 걸리는 부분은 google쪽입니다. 우리나라 검색엔진에서는 잘 찾을 수 없습니다. ㅎㅎ)

.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 스럽게 만들려다 보니, 같은 스크립트를 여러 다른 웹파트들이 쓰게 되었는데, 일단 저렇게 간신히 해결하는데 성공했다. 미묘한 감동 찌리리링 상태다.