반응형



칼로의 유쾌한 악마들
카테고리 소설
지은이 이장욱 (문학수첩, 2005년)
상세보기


우연찮게 지하철에서 집어들은 책이었는데  한번 읽기 시작했더니 책을 손에서 놓기가 힘들어지네요..

 

결국 한번에 다 봐버렸습니다.

 

스토리전개가 참 인상적이었습니다. 문체는 거칠게 써 내려갔다는 느낌이 많이 들고요.. 그래서 더욱 와닿는약간의 폐쇠적인 느낌.

 

남들과 다른 시간 속에서 살아가는 여자와 마지막 쯤에 등장하는 외팔이 케릭터가 가장 인상에 남는군요..

 

반응형

겨울에 여름 회식 사진을 올리다니.. 
나도 모르게 과거를 회상하고 있는 건가?


반응형









 
 
2002년 월드컵
그해 여름 이테리 vs 한국 전은
인테리에서 봤다.
 
:
:
공포스러운 날이었다.!!!
반응형

Nokia forum에서 퍼온 자료입니다.

아키텍쳐를 공부하면서 현재 open되어있는 solution들은 아키텍쳐를 어떻게 잡아가고 있는지 참고하기 위해서 여기저기서 찾아보고 있는 중이랍니다.!!


S60WebKit & Nokia Browser Architecture

From Forum Nokia Wiki

Introduction

The Nokia Web Browser is built upon S60WebKit, a port of the open source WebKit project to the S60 platform.

WebKit contains the WebCore and JavaScriptCore components that Apple uses in its Safari browser. Based on KHTML and KJS from KDE's Konqueror open source project, this software has enabled Nokia to achieve improvements in Web site usability on smartphones through the re-use of a proven desktop rendering engine that has been developed and optimized by a large open source community over many years.

This browser enables smartphone users to browse full Web pages on a smartphone screen with features such as:

Preservation of the original page layout, presented just as the Web site designer intended; Easy navigation of Web pages through page miniatures, reducing the amount of scrolling; Pop-up blocking, enhanced start page, and simplified menus; Visual History, an easy-to-use back function, showing miniature views of previous pages; Text Search, which works as you type, taking you directly to the interesting part of the page; Dynamic HTML, supporting dynamic menus, rollovers, and scripted behavior such as AJAX applications; Extensive support of industry standards including W3C's HTML, XHTML 1.0, DOM, CSS and SVG-Tiny; other Web standards such as SSL and ECMAScript; and Netscape style plug-ins such as Flash Lite and audio. Figure 1 explains the architecture for the Nokia Web Browser.


Figure 1: S60 Browser Architecture

Documentation and source for the WebKit project are available at WebKit .

For Information about KDE's Konqueror please visit KDE's Konqueror.

Building S60Webkit

For instructions building S60Webkit, see Building S60Webkit .

'개발 Note > it 이야기' 카테고리의 다른 글

UI Modal 컨셉  (0) 2009.01.06
C++ 상에서 발생하는 name mangling 에 관한 내용  (16) 2009.01.04
Feature modeling - 아직 정리되지 않은 주제.  (0) 2009.01.04
Refactoring  (0) 2009.01.04
S60 platform architecture  (0) 2009.01.04
반응형

내가 하는 일들과 해야할일 그리고 관심있는 부분들을 블로그에서 작업하려 하다보니 맘대로 안되는 부분들이 많은 걸 알게 되었다.

가장 큰 부분이 회사에서 하는 일을 개인 블로그에 올릴수 있는가 하는 예기이다.!

참 민감한 부분이기도 하다고 생각되는데.... 

단도직입적으로 과연 회사에서 배운 지식과 정보들이 어디까지가 개인의 것이 될 수 있을까?

유재석이 놀러와 작가가 써준 원고의 내용과 자기 계약상의 내용을 블로그에 올려서 여러 사람들과 공유하고 있다면 어떨까?

 
과연 원고가 저작권법에 걸릴까?
아니면 계약서가 에이전트의 영업 비밀 보장 계약에 문제가 될까?

음... 둘다 걸릴거 같군요.. ㅡㅡ;;;


그러면 유재석이 그동안 여러 프로그램을 진행하면서 익힌 노하우나 개그, 그리고 개인기 등을 
블로그에 올리는것은 문제가 될까?

글쎄???~~~~@@@!!!######  

아리까리 하네요.


떡진 머리를 한 프로그래머가 게시판에 자신이 코딩 하고 있는 부분에서 영 꽉꽉 막힌 버그가 있는데 다른 개발자들도 이런 문제를 가지고 있는지 묻고 예기 하고 싶을 때 어떻게 해야 할까?

참으로 안타까운 부분이지만 구체적으로 어떤 부분이 꽉 막히는지 "콕!"찝어서 예기 하지 못하고, 모듈 인터페이스를 COM 으로 사용하고 있는데 COM instance 가 계속 구 버젼으로 동작해요!! 
이런 식으로 돌려서 예기 할수밖에 없으니 대답해주는 사람도 돌려서 물어본 질문에 대해서 추측해서 대답해줘야 하니... 답답할 노릇이죠!!!

그리고 개발자는 떡진 머리를 한 채 몇시간을 더 보내다가 결국 자기  PC를 끄고 머리좀 식히고 잠도 좀 자고 일어나서 어제 문제를 마저 해결하려고 컴을 켰더니 문제가 해결되었네요.!!

다행히도 앞으로 몇일간은 이 프로그래머는 머리가 떡질 일이 없을 지도 모릅니다.

하지만 문제는 이런 일은 언제나 있다는 것이죠!!!

과연 개발자 포럼이나 이런곳에서 어느정도 까지 정보가 공유될 수 있을까? 정확히 말하면 회사에서 개발하고 있는 프로젝트의 정보가 맞겠지만...

어찌되었건 지금의 개발자들이 안고 가야 하는 부분이기도 하죠!!..

개발자들의 입장에서는 그렇게 대단치도 않다고 생각하되는 부분이지만 다른 상황에서 바라본다면 매우 골치 아픈 문제들이 있는 것입니다.

예를 들면,,, 자동차 영업사원인 뺀질한 금자씨가 영업에도 활용할겸 블로그를 운영하고 있는데 , 피서철을 앞둔 6월자신이 판매한 차량 대수가 140대가 넘게 되어 자랑 할겸 , 블로그에 올렸습니다.

"나 이번달 140대 팔았다" 리고 말이죠!. 그러면서 자기 영업소 직원들 평균 판매 대수가 40대인데 이건 엄청난 숫자라고 예기 했다고 합시다.

별 문제 안되어 보이는 글이지만, 이미 경쟁사에게 6월달 해당 영업소의 판매실적을 공개한 것이나 다름없는 결과를 낳을 것입니다. 


하지만 어떤 화장품 업체의 연구소에서 근무하는 이준기씨가 새로 블로그를 운영하게 되면서 
자신이 몇년전에 개발했던 "아조아!" 로션개발 당시, 아토피성 피부 트러블을 해결하기 위해 실행했던 실험 방법들을 소개했다면 이는 문제라고 보기 힘들어 질 것 같습니다!!! 그렇죠???


결국!!! S/W 개발자들이 공유 할 수 있는 것은 "문제 해결 방법" 이나 "개발중인 코드"가 아니라 "문제 해결 방법을 찾는 방법"이나 "framework ,API, solution"등의 올바른 사용방법이 되겠죠?

물론 자신의 Idea는 누가 뭐라 하겠습니까?



'개발 Note > UI Framework 개발하기' 카테고리의 다른 글

STL : List  (0) 2009.01.04
Coding  (0) 2009.01.04
아키텍쳐를 잡아 나가는 일  (0) 2009.01.04
새로운 시작!!! framework  (0) 2008.12.29
오늘 읽은 "프레임워크 개발의 이해와 시작"  (0) 2008.12.19
반응형

Mobile 쪽에 몸담고 있으면서 , file system에서 부터 UI 까지 모든 과정에 참여하여 아이디어를 내고 개발하고 결과를 보고 아키텍쳐를 수정하여 다시 설계하고 하는 작업들이 즐거웠던 시절이 있었다.

하지만, 이런 점진적인 발전과 시행착오들은 점점 부담과 위기로 다가오기 시작한 것 같다.

Hand Phone S/W의 시장에 존재하던 Normal phone 과 smart phone의 경계가 무너지면서 기존에 Normal Phone S/W들이 Open OS와의 경쟁을 시작하게 되었기 때문이다.

최근 내가 지금 관심을 가지고 지켜보고 있는 기존 Embeded S/W의 경쟁력에 관한 부분이다.
우선 첫번째가 "Embeded S/W가 Open OS 들과 경쟁하기 위해 어느정도 개선되어야 하는가" 하는 부분이고,
두번째는 "Embeded S/W가 Open OS들만큼의 기능을 갖추는 것이 과연 메리트가 있는가" 하는 부분이다.
세번째는 "시장의 Needs는 이미 Open OS의 기능을 요구 하기 때문에 최대한 빠르게 Open OS 로 전환하는 것이 옳은가" 하는 것이다.

Open OS( Window Mobile이나 Linux , Symbian 등)의 포팅이나 개발 업무 보다는 기존에 꾸준히 Embeded S/W만 해왔기 때문에 Embeded S/W 쪽으로 훨씬 애착을 가지고 있는 편이다. 그럼에도 불구하고 Embeded S/W 냐 Open OS냐를 두고 고민하는 것은 10년 20년이 지나면 Open OS로 달려가고 있을것으로 예상 하기 때문이다.

여기에도 한가지 변수가 있는데 기존의 Window mobile, embeded linux, OSX, Symbian 등과 어깨를 나란히 할 수 있는 Open OS를 만들어 내고 배포할 수 있는가 하는 것이다.

개인적인 입장에서는 내가 지금 하고 있는 프로젝트가 이런 Open OS 개발의 가능성을 열고, 기업입장에서도 투자가치가 충분한 부분이라 인식되었으면 하는 바램이다.!!



'개발 Note > UI Framework 개발하기' 카테고리의 다른 글

STL : List  (0) 2009.01.04
Coding  (0) 2009.01.04
아키텍쳐를 잡아 나가는 일  (0) 2009.01.04
회사 일? 내 일? 그리고 블로그  (0) 2009.01.04
오늘 읽은 "프레임워크 개발의 이해와 시작"  (0) 2008.12.19
반응형

글을 읽는 도중 다음과 같은 문구를 보게 되었습니다.
Framework 없이 어플리케이션을 만드는 것은 프로그래머의 역량과 컨디션에 따라 어플리케이션의 구조가 만들어지게 된다. 라고 적혀있었는데 생각해보면 맞는 예기인것 같습니다.

Framework이라는 것이 사실상 생산성을 높이고 제공하고자 하는 기능을 구조화 하여, 개발자들에게 기능 사용구현에 대한 Guide 역할하고, 기능 동작을 보장 해주는 것이라 볼수 있습니다.

때문에 Framework없이 S/W를 개발한다면 사실상 개발자의 역량에 맡길수 밖에 없게 됩니다.

이전에 이와 같은 기능을 구현해 봤는가, 아닌가에 따라 S/W의 질이 달라지게 되겠죠.

Framework이란 무엇인가? 

 Ralph Johnson 이라는 사람은 추상클레스( abstract class) 들의 집합과 상호 협조하는 클래스들의 인스턴스 동작 방법으로 이루어진 재사용 가능한 디자인이라 정의했습니다.

프로젝트에 어울리는 잘만들어진 프레임워크를 이용한 어플리케이션은 비록 거대해 지더라도 프레임워크의 의도에 맞게 어플리케이션의 설계가 이루어집니다. 때문에 어플리케이션에 의해 System의 안정성을 해치거나, 터무니없이 낮은 퍼포먼스를 내는 일은 거의 없을 것입니다.

라이브러리와 프레임워크의 차이!
라이브러리는 개별적인 기능들을 집단형태로 묶음을 의미합니다.
때문에 라이브러리를 이용해 문제를 해결하고자 할때는 메소드의 기능을 정확히 이해하고 사용해야 합니다..

프레임워크는 원하는 기능을 제공하는 모듈의 인스턴스와 이에 수반되는 여러가지 장치 들의 상호작용까지의 묶어서 정의 하게 됩니다. 

때문에 프레임워크에서 제공되는 기능을 사용하게 되면 이와 수반된 이미 검증된 작업의 플로우까지 함께 사용하게 되는 것입니다..


이렇게 함으로 해서 어플리케이션의 코드를 줄일 수 있고, 안정성을 높이며 개발 속도를  빠르게 할 수 있습니다.



좋은 프레임워크
좋은 프레임워크를 사용하면 소프트웨어 개발 비용이 줄어들지만, 아이러니하게 좋은 프레임워크를 개발하기 위한 비용이 많이 들게 됩니다.

좋은 framework을 만들기 위해 설계에 들어가는 시간, 퍼포먼스 향상을 위해 투자하는 시간, 그리고 안정성 확보를 위해 테스트에 들어가는 시간 이 모든 것들이 비용이 되기 때문에 많이 들 수 밖에 없습니다.


Framework 설계에 들어가는 원칙들.

의존관계 역전 원칙( The Dependency Inversion principle)
인터페이스 분리 원칙(The Interface Segregation Principle)
리스코프 치환 원칙(The Liskov Substraction Principle)
단일 책임 원칙(The Single Responsiblity Principle)
개방 폐쇄 원칙(The Open-closed Principle)


프레임워크는 많은 도메인에서 여러가지 문제를 해결할 수 있도록 만들어지기 때문에 특정 도메인의 간단한 문제를 해결하기 위해 기능과 구현이 복잡해지고 코드의 크기나 객체의 크기가 커질 수도 있다.



'개발 Note > UI Framework 개발하기' 카테고리의 다른 글

STL : List  (0) 2009.01.04
Coding  (0) 2009.01.04
아키텍쳐를 잡아 나가는 일  (0) 2009.01.04
회사 일? 내 일? 그리고 블로그  (0) 2009.01.04
새로운 시작!!! framework  (0) 2008.12.29
반응형


Let's enjoy the bloging!!!!

Wow... :)

+ Recent posts