mkdir build-release ../configure --disable-debug --enable-optimize --enable-win32-target=WIN95 make 5. SpiderMonkey 1.8.5 compile with NSPR (Mozill Build에서 제공한 MinGW를 사용한다.)
: 아래 파일 경로는 실제 파일 경로이다. 자기가 실제로 설정한 경로를 넣어주면 된다. mkdir build-release ../configure --disable-debug --enable-optimize --enable-win32-target=WINNT --enable-ctypes --enable-threadsafe \ --with-nspr-cflags="-I \ D:\project\Library\mozilla\nsprpub\build-release\dist\include\nspr" \ --with-nspr-libs=" \ D:\project\Library\mozilla\nsprpub\build-release\dist\lib\nspr4.lib \
처음에 맥북프로를 사용하면서 멀티터치패드가 상당히 마음에 들었다. 넓은 패드도 그렇고 멀티핑거 기능도 쓰임새가 아주 많았다. 하지만 아무래도 마우스를 완전히 대체하기엔 어쩔 수 없는 한계가 있는지라 마이티 마우스를 사용했다. 그런데 사용하다보니 마우스의 휠을 없애버리고 맥북프로의 멀티터치패드처럼 멀티핑거를 지원하면 좋겠다는 생각이 들었다. 그러면 쓰기는 더 편해질 것이고 휠이 없어지는 것이기 때문에 고장도 덜 발생할 것 같았다. 하나 더 얘기하자면 디자인도 더 깔끔해지고 말이쥐~
그런데 진짜로 나와버렸다. 매직 마우스~ 오~ 지름신이~ ^^;
1. Legacy DOM - 1996년 Netscape Communication Navigator 2.0 은 JavaScript를
Internet Explorer 3.0 은 JScript (a part of JavaScript) 를 릴리즈 함. - 이 스트립트들은 제한된 detecting user-generated events 기능과 HTML 수정 기능을 제공함. - 이후 이를 DOM Level 0 라고 함. - 엑세스 할 수 있는 elements 가 제한됨. - Form, link, image elements 는 root document object로 시작하는
계층적 이름 (hierarchical name)을 통해서만 접근이 가능함. - 계층적 이름 (hierarchical name)은 names 또는
the sequential index of traversed elements 로 만들어짐. ex) names : document.formName.inputName index : document.forms [0].elements [0] - client side 의 form validation과 rollover 기능이 가능함. 2. Intermediate DOM - 1997년 Netscape Navigator, Internet Explorer 4.0 은 DHMTL 기능을 추가 지원함. - DHTML은 로딩된 HTML을 변경하는 기능 : Legacy DOM 을 확장 - JScript 가 JavaScript 를 기반으로 되어 있기 때문에 큰 틀에서는 호환성
(Largely Compatible)을 가짐에도 불구하고 DHTML DOM extension 이 벤더별로
각각 개발됨으로 인해 서로 비호환성을 가지게 되었다. - 이 DOM 버전을 Intermediate DOM 이라고 한다. - Display 에 영향을 주는 CSS properties 를 다룰 수 있다. - Layer 라고 불리우는 new feature 에 접근할 수 있다. ex) Netscape : document.layers 로 접근 Microsoft : document.all 로 접근 - 이 후 후속 버전에서는 Intermediate DOM 에 대하여 Netscape 는 호환성을 포기,
Microsoft 는 backward compatibility 를 유지함. 3. Standardization - W3C (World Wide Web Consortium) 에서 주관함. - 1997년 ECMAScript 를 발표 : JavaScript 와 JScript 는 cross-browser compatibility를 위해 ECMAScript 를 구현함. : 이 후 DOM 표준화를 진행함. - 1998년 DOM Level 1 을 발표 : document 의 어떤 위치의 element 든 바꿀 수 있는 방법을 포함하여 전체적인
HTML, XML 에 대한 complete medel 을 제안함. : 그러나 2000년 까지 표준을 따르지 않는 Netscape 4.x, Explorer 4.x 가 계속 사용됨. - 2000년 DOM Level 2 를 발표 : getElementById, event model, XML Namesapces, CSS 등을 도입함. - 2004년 DOM Level 3 를 발표 : XPath, keyboard event handling, interface for serializing document as XML 를
vim 에디터를 이용해서 /etc/bashrc 파일을 수정하려고 했더니 w! 명령도 먹히질 않았다. 그래서 sudo 명령을 써봤는데 패스워드를 물어본다. 그러고보니 난 root 권한 패스워드를 설정한 기억이 없는데 ... ^^; 그래서 찾아보니 root 계정은 기본적으로 가려져 있는 것으로 보였다. 이걸 활성화 시켜야 한다. 만약에 피치못할 사정으로 반드시 root 계정을 사용해야 한다면 아래와 같이 수행하면 된다.
이 후 권한 사용시 sudo -i 또는 sudo [수행할 명령]을 입력 후 설정한 패스워드를 넣어주면 된다.
[뱀발바닥] 사실 위에 보이는 캡쳐 화면을 만들어 올리는데도 시간이 좀 걸렸다. 기본적으로 화면 캡쳐를 하면 tiff 파일로 만들어지는데 이 놈이 웹에서는 보이질 않는다. 때문에 jpeg파일로 바꾸고 싶은데 방법을 찾질 못했다. 구글신에게 물어보니 automator라고 하는 어플을 소개해 주셨다. 기본적으로 존재하는 명령들을 조합하여 새로운 기능을 만들어내는 개념이다. 참고한 사이트는 요기다. http://macheart.tistory.com/tag/leopard 요기를 참조하여 겨우 캡쳐한 tiff 파일을 jpeg파일로 변경하는데 성공했다. 그런데 알고보니 미리보기 프로그램에서 파일 포멧을 변경해서 저장할 수 있었다. 아직 맥에서의 상단에 고정된 메뉴가 익숙하지 않아 그쪽은 보지도 않는 바람에 찾질 못한거였다. 결론적으로 그냥 삽질하다가 automator라고 하는 새로운 프로그램을 사용하게 된거다. ㅋ
문제 어떻게 하면 같은 제품군에 속한 제품들의 객체만을 생성해서 사용하도록 명확히 보장받을 수 있는가? 예를들어 타입A 제품의 종류는 A1, A2가 있으며 타입B 제품의 종류는 B1, B2 가 있다. 제품 생산시 1번 제품군은 A1, B1이며 2번 제품군은 A2, B2이다. 조건에 따라 제품군으로 분류된 제품만을 생성해야 한다.
방법1 - 제품군을 생성할 때마다 조건 비교를 한다. - 이 방법은 조건문이 곳곳에 들어가게 된다. 추후 제품이 추가되는 경우 조건문이 들어간 부분을 모두 찾아서 수정해야한다. 아래 코드와 같이 생성함수에서 추가된 제품의 종류를 비교해야 한다. - 샘플 [code cpp] class productA {}; class productB {}; class productA1 : public productA {}; class productA2 : public productA {}; class productB1 : public productB {}; class productB2 : public productB {};
int main () { ... CreateProductA (); CreateProductB (); ... } [/code]
방법2 - Factory Method 패턴에서 사용했던 팩토리 메소드를 가진 클래스를 제품군별로 생성한다. - 이점 1. 개별 제품 클래스의 객체를 생성할 때마다 일일이 조건을 검색할 필요가 없어진다. 2. 새로운 제품군의 생성시 기존 소스코드는 건드릴 필요가 없다. 3. 팩토리 클래스가 별도로 존재하기 때문에 클라이언트는 추상클래스의 인터페이스만 바라보면 된다. 4. 반드시 선택된 제품군에 포함된 제품들만 생성해야하는 경우 유용하다. - 단점 1. 제품군이 늘어나면 어쩔 수 없이 팩토리 클래스의 수도 늘어나게 된다. 2. 기존 제품군에 새로운 제품이 추가되면 모든 팩토리 클래스에 새로운 제품을 추가해야한다. - 샘플 [code cpp] class AbstractProductA {}; class AbstractProductB {}; class ProductA1 : public AbstractProductA {}; class ProductA2 : public AbstractProductA {}; class ProductB1 : public AbstractProductB {}; class ProductB2 : public AbstractProductB {};
객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스에서 책임지도록 한다.
유용한 경우 - 구체적으로 어떤 클래스의 객체를 생성해야 할지 미리 알지못하는 경우 - 객체의 종류별로 객체 생성과 관련된 부분을 국지화 시키는 경우
장점 - 어떤 객체를 생성할 것인지와는 무관하게 동일한 형태로 프로그래밍이 가능하다. ; 당연하다. 클래스 상속을 통한 다형성을 구현하므로 ... - 클라이언트가 직접 객체를 생성하는 것보다 유연한 확장성 구조를 가지게 된다. ; 새로운 객체를 생성하거나 이전 객체를 확장해서 생성하고자 할 때 새로운 하위 클래스를 정의하고 Factory Method에 해당하는 멤버 함수만 Override 시키면 된다. ; 다시 말하자면 객체 생성과 관련된 변경을 국지화 시킬 수 있다. - 서로 연관된 클래스들의 상속관계가 병렬로 존재하는 경우 한 쪽 상속 관계의 클래스들이 다른 쪽 상속 관계의 클래스 객체를 생성할 때 유용하다. - 상속관계에 있는 클래스들의 멤버 함수가 동일한 프로그램 로직을 가지고 있으면서 내부적으로 생성할 객체만 서로 다를 때 편리하다. ; 로직은 상위클래스에서 구현하고 생성과 관련된 부분만 하위 클래스에서 구현한다.
단점 - 객체의 종류가 달라질 때마다 새로운 하위 클래스를 정의해야한다. ; 따라서 불필요하게 많은 클래스들을 내포할 가능성이 있다.
[뱀발바닥] 패턴의 유용성을 알리기 위해 좀 어거지라고 생각되는 예를 (지극히 내생각이다.) 들었다는 느낌이 많이 들었다. GoF 패턴에 대한 해설서이므로 저자가 의도적으로 설명하기 위해서 그렇게 한 것 같긴 하지만 나에겐 좀 아쉬운 부분이다. 하지만 아직 이쪽부분에 대해 용어나 표현에 대해 미숙하기 때문에 그렇게 생각하는지도 모르겠다. 어쨌든 패턴이라고 하는 영역이 소프트웨어를 설계할 때 많은 도움이 되리라고 확신하지만 너무 이쪽 이론에 빠지게 되면 자칫 말장난에 빠질 수도 있겠다는 생각이 든다. 패턴은 객체지향언어를 제대로 쓰기 위해 필요한 기본적인 테크닉일 뿐이라고 생각한다. 나머지는 자신의 영역에 맞게 적용하는게 문제라고 본다. 뭐 그게 어렵겠지만 ㅋㅋㅋ
지금 쓰는 노트북에 OS를 설치한지 2년이 약간 넘는다. 요즈음들어 좀 버벅거리더니 이젠 Word를 띄우면 그냥 죽어버린다. 설치한지도 좀 되고 해서 금요일 저녁부터 백업을 하고 지금 다시 설치중이다. 백업을 하려고 보니 USB 하드라고 있는게 고작 30 기가 정도다. 어쩔 수 없이 네트웍으로 다른 컴에 백업을 했다. 어제는 이거 하느라 시간 다 보냈다. ㅎㅎ 대충 추려도 백업 용량이 한 80 메가 정도는 되는 것 같다.
오늘은 드디어 백업을 완료하고 숙원(?)이던 포멧에 들어갔다. 처음엔 windows 2008 standard 버전을 설치했다. 그런데 회사에서 쓰는 백신을 깔자마자 처음본게 호환성 문제 창이었다. 개인용으로 쓰는 노트북이면 상관없는 업무용이라 초장부터 이러는 건 아니다 싶어 다시 다 밀어버리고 XP로 설치했다. 그리고나서 한게 드라이버 설치였는데 이게 참 너무 많았다. 귀찮기도 하고 해서 주요 드라이버만 설치하고 나머지 드라이버들은 그냥 자동 설치 프로그램을 설치하려고 했다. 그런데 또 이놈이 .NET 프레임웍을 사용한단다. -_-; 아놔~ 굳이 또 .NET을 쓰는 이유는 뭘까나? 요즘 대세인가? ㅎㅎ 뭐 암튼 .NET이 필요하다니 설치는 해야겠고 일단 Visual Studio를 설치하고 나머지 드라이버를 설치하기로 했다. Visual Studio 설치하면 .NET도 설치되니까 말이다. 그런데 Visual Studio 설치하다보니 약간 화가났다. Visual Studio는 각 버전별로 전부 새로 설치해야하기 때문이다. 회사에서 사용하는 버전은 Visual Studio 6, Visual Studio 2003 .NET 버전이다. 하지만 차후 관리하는 제품 코드를 전부 Visual Studio 2005나 2008로 옮길 생각이고 개인적인 욕심도 있어서 2005, 2008을 함께 설치하고 있다. 그러니깐 지금 개발툴만 4개를 설치하고 있는거다. 하다보니 이거 너무 불편하다. 그냥 라이브러리만 버전별로 따로 설치하고 UI 같은 부분은 하나만 설치해도 될 것 같은데 왜 이렇게 만들어놨는지 모르겠다. 쩝~ Visual Studio 6 야 너무 다른 버전이라 그렇더라도 2003 부터는 좀 통일해도 될 듯한데 ... 우찌하리 파는 넘이 그렇게 만들었고 난 그걸 써야하니 ~ ㅋㅋㅋ 거기다 오늘 설치하려고 보니 2003, 2005 버전은 어디갔는지 보이질 않았다. ㅜㅜ 어쩔 수 없이 두 개 버전은 어렵게 다운을 받아 설치 중이다. 크기도 전부 GB 단위라 이게 받는게 시간이 좀 많이 걸렸다. 영화를 몇 편 봤는지 원~ 이짓거리를 하고 나니 오늘 하루는 다 가버렸다. -_- 물론 아직까지도 Visual Studio 업데이트 중이다. 400 메가 정도인데 다운 받는 속도가 겁나게 느리다.
내일은 다시 오피스 설치하고 남은 드라이버만 설치하면 기본적인 설치는 끝날 듯 싶다. 한가지 문제는 내가 쓰는 Mozilla ThunderBird 라는 프로그램이 좀 불편해서 아웃룩으로 다시 바꾸려고 하는데 이게 기존 데이터에 대한 변환이 될지 잘 모르겠다. 아웃룩이 너무 무거워서 메일 전용으로 이 놈을 썼는데 좀 많이 불편하다. 버전업도 별로 안되는 것 같공~ 이거 옮기려면 시간 좀 걸릴 듯 싶다. 천둥새로 계속 쓰다가 방법 찾으면 아웃룩으로 옮겨야할 것 같다.
내일은 코딩도 좀 해야하고 좀 바쁠 듯 싶다. 주말은 좀 한가하게 보내야하는데 이번 주말은 컴만 들여다 보고 말았다. 다음주엔 흠~ 뭐 다른 일이 있으려나~ ㅎㅎ
4월 1일부터 지금까지 사이트 업무를 진행중이다. 신규 제품이라 개발에 참여한 인원은 대부분 사이트에서 테스트를 진행하고 있다. 아무래도 하드웨어와 섞인 부분이 많은지라 기본적인 기능 테스트 이외의 부분은 사이트에 나와서 할 수 밖에 없다. 현재는 가오픈 상태이고 발견된 문제점을 해결하고 월말쯤 정식 서비스를 오픈할 예정이다. 이번 프로젝트는 상당히 어려운 점이 많았다. 우리가 구성하는 시스템의 가장 앞단에 위치하는 시스템을 만드는 업체가 계속해서 문제를 발생시키는 바람에 2주 정도는 그냥 시간을 날려버렸다. 결국 업체가 바뀌어서 문제는 해결되었지만 나머지 뒷단 시스템에 대한 테스트가 상당히 지연이 되어버렸다. 불행히도 이게 내가 만든 모듈이 들어있는 부분이다. 다행히 가오픈을 하긴 했지만 테스트 기간이 짧아 상당히 신경이 쓰이는 부분이다. 아직까진 모듈자체의 문제점은 발견되질 않지만 잠재된 문제들이 있다면 가오픈 기간동안 나와주기만을 바래야 할 것 같다. ^^; 일단 프로젝트는 어느 정도 진행이 완료되어 가고 있지만 내가 생각하기에 아니다 싶은 부분이 있어 몇 자 적어본다.
1. 관리자들의 의사 결정 난 솔직히 밤샘작업을 하는 부분에 대해서 반감은 없다. 물론 되도록 안하는게 좋기야 하겠지만 일정상 어쩔 수 없는 경우가 많다. 사람이 세운 계획이라는게 뜻대로 되는 것 보단 되지 않는 부분이 더 많기 때문이다. 더구나 여러 업체들이 함께 진행하는 경우엔 말이다. 계획에는 일정이라는 부분도 포함되어 있기 때문에 기간을 맞추기 위해서는 어쩔 수 없이 밤샘작업은 발생할 수 밖에 없다고 생각한다. 그런데 이번 건은 좀 심하다는 생각이든다. 앞서 말했다시피 가장 앞단을 담당하는 업체가 교체되었다. 이 업체 때문에 2주일을 까먹어버렸고 오픈 취소되고 소송까지 건다는 얘기도 나왔었다. 이게 가오픈 약 일주일 반쯤 전 얘기다. 왜 이런문제가 발생했을까? 그 업체에 대한 기술적 평가나 제품에 대한 테스트 진행이 전혀 되지 않았다. 그런 제품을 사이트에 들고 들어왔으니 계속 죽고 버그 생기고 하는게 당연하다. 처음엔 그 쪽 엔지니어를 탓했지만 그럴게 아니라는 생각이 들었다. 도데체 관리자들 (이 프로젝트를 진행한)은 무슨 생각으로 일을 이렇게 까지 만든 것일까? 그냥 된다고 사이트에 넣어버리고서 엔지니어들이 알아서 진행하라고 하면 다인가? 어떻게 해서 이런 업체에 대한 의사결정이 이루어졌는지 이해가 가질 않는다. 업체에 대한 선택이 기간상 어쩔 수 없는 부분이 있었나? 그럼 그 기간이라는 부분을 왜 그런식으로 잡았을까? 내가 앞서 사람이 하는 일이라 어쩔 수 없는 부분이 있다고 했지만 그건 누가 봐도 도저히 예측 못할 일이 벌어졌을 때의 일을 말하는 것이다. 이런 일을 예측 못했다고 하면 그 사람들은 그 자리에 있으면 안돼는 사람들이다. 그 사람들도 나름대로의 이유가 있을 것이겠지만 (핑계없는 무덤이 있겠는가!) 지금 내 위치에서는 이렇게 밖에 생각할 수 없다. 근데 정말 궁금하다. 왜 그랬을까? -_-;
2. 기술적인 부분에 대한 책임 현재 프로젝트에 대해 처음 얘기가 나왔을 때 신나게 진행하던 분들이 있었다. 말그대로 신나게 프로젝트에 대한 그림을 그렸다. 그런데 지금은 손을 빼버리고 남아 있는 사람들끼리 끙끙 앓으면서 진행했다. 뭐 솔직히 그래도 해결은 됐다. 그런데 말이다 자기가 그렇게 했으면 최소한 문제가 발생한 부분에 대한 분석 정도는 해야 하는거 아닌가 하는 생각이든다. 내가 정말 열받는 건 문제가 다 해결될 시점에 전화 한 번 해서는 어떻게 되가냐고 물어본다는 거다. 사이트 나와달라고 하면 내가 가서 할 일이 뭐있냐고 한다. 뭐하러 물어보나 그냥 사이트 멤버들이 알아서 할거고 P.M도 여기 있는데 그냥 여기서 알아서 하게 냅두지~ 자기가 다 그려놓고 나한테 당연히 되야할게 되는지 물어보는건 뭔가~ 될지 안될지 모르는거 그려놓은건가? 아니면 혹시나 하는 마음에 책임회피하는건가? 그냥 다시는 그 사람이 벌이는 일을 하지 않았으면 하는 바램만 생긴다. 오~ 신이여 내 마음 속의 화를 잠재우소서~ ㅠㅠ
뭐 상당히 많은 얘기를 쓰게 될 줄 알았는데 프로젝트도 마무리되가고 하니 이 정도만 쓰겠다. 솔직히 지난 달 말엔 누가 건드리면 폭발하기 일보 직전이었다. 그런데 이젠 많이 가라 앉았고 궂이 더 생각해내서 이전 감정으로 가고 싶진 않다. 사람은 개개인 마다 생각이 다르고 또 그래서 싸우고 화해하고 하는 일을 반복한다. 그런데 이 높으신 양반들은 내가 어떻게 해야 잘 지낼 수 있을지 잘 모르겠다. 대놓고 싸울 수도 없고 말이다. 쩝~ 회사 정리 해고 한다는 말도 있고 증말 돌아가시겠네~ ㅋㅋㅋ
위 사이트에 있는 순서대로 진행하면 될 듯하여 시작했는데 각 단계별로 소스를 받아 컴파일하고 설치하는 과정이 너무 길어서 하루에 다하기는 힘들다. 컴파일 시켜놓고 멍하니 모니터보기도 뭐해서 켜놓고 자기도 했다. 다음 날 출근을 해야하기 때문에 ... ^^; 우여곡절끝에 오늘 드디어 마지막 단계까지 왔다. 그런데 마지막에 에러가 하나 떴다. 쩝~ 어쩌라는건지 통 모르겠다. 중간에 뭔가 빼먹은 것 같기도 하고 환경세팅이 잘못된 것 같기도하고... @@ 아무튼 해결할 방법을 찾지못했다. 아쉽지만 처음부터 다시 해봐야 할 것 같다. 어짜피 설치한 경로가 맘에 안들어 다시 할 요량이었으니 다시 한 번 차근차근 해봐야겠다.
쩝~ 누가 이런걸 비참한 셋방살이라고 하던데~ ㅋㅋ 좀 비참하긴 하다. 그냥 맥북 있으면 해결될 일을~ ^^; 누가 맥북하나 선물 안해주려나~ ㅋ
