우승이의 블로그

저는 아직도 초록색컬러의 단색화면을 가진 핸드폰을 사용하고 있습니다. -.-; 물론 저도 칼라 화려하고 사운드 빵빵한 핸드폰을 가지고 싶지만서도 경제적으로나 그 용도로나 그리 땡기지는 않습니다. 그돈이면 그냥 하드디스크 용량큰거 하나살까 하는 생각이 더 앞서는 편이죠. 그런데 우연힌 Mobile ESPN 사이트를 들어가서 산요가 만든 ESPN의 각종 정보를 볼 수 있는 전용 핸드폰이 있더군요. ESPN만이 가지고 있는 컨텐츠를 볼 수 있는 전용 핸드폰이라니 참으로 대단하다는 생각을 했습니다. 그만큼 미국에서는 스포츠에 관심이 많으니까 가능하다는 생각도 했구요. 그런데 플래쉬로 만든 데모화면에서 그 좁은 화면에 아기자기하게 UI을 만든것에 눈이 가더군요. 그 좁은 화면에 어떻게 하면 ESPN의 컨텐츠를 잘 보여줄까 고민들을 했을텐데 문자위주의 컨텐츠를 보던 저로써는 상당히 재미있는 모습이더군요. 플래쉬를 핸드폰에 올려서 UI을 만든 것 처럼 보이던데. 아마도 국내에서도 매직앤이나 네이트에서도 이러한 형태의 보다 편리한 핸드폰(모바일) UI가 곧 적용되겠지요. 그만큰 핸드폰도 성능이 좋아질 것이고 소비자들도 좀더 편하게 필요한 정보를 얻고자 할테니까요. 핸드폰에서 적용될 수 있는 Results-oriented UI는 어떤 형태가 될지 여러분들도 한번 생각해 보시죠. 화려한 것이 아닌 편리한 모바일UI 의 모습을 말이죠.

http://mobile.espn.go.com/See-It.html

J2EE의 복잡함에 질려버린 분들이라면 LAMP에 관심을 가지시는 것은 어떨지요? 가끔 J2EE을 보고 있자면 , 특히 WebLogic이나 WebSphere 을 보자면 호미로도 충분한 일들을 가래를 가지고 막는다는 생각이 많이 듭니다. 톰캣과 MySQL로도 충분한 것들도 많은데 굳이 시스템 리소스를 배로 요구하는 웹어플리케이션 서버를 구입해야 한다는 것이 좀 아이러니하더군요. 그것도 오픈소스라는 이유때문에 외면 당한다면 더욱 그렇지요. LAMP에 비하면 톰캣도 그리 가벼운 환경은 아닙니다. 자바라는 그 태생때문에 말이죠. 마찬가지로 닷넷프레임워크도 그렇고. 최근 닷넷2.0은 설치되고 나면 100MB가 넘더군요. 실제 동작할 때 메모리는 얼마나 차지할 지 모르겠지만 암튼 하드웨어 업체와 짜고 어플리케이션 프레임워크를 만들고 있나 의심이 들 정도입니다. 저의 이러한 생각에 반론도 있겠지만 암튼 그렇습니다. 전직 SUN의 CTO을 지냈다는 양반도 J2EE는 결국 실패할거라고 얘기하더군요. (물론 지금은 LAMP을 기반으로 하는 솔루션을 만들어 파는 회사에 있긴 합니다. 아이러니한 일이 아닐 수 없지요.) 아래 글을 한번 읽어보시길 바랍니다. 세상은 이래서 돌고 도는 군요. 다른얘기지만 미국이라는 나라가 기술만 있으면 얼마나 쉽게 비지니스를 시작할 수 있는지도 느낄 수 있겠더군요. 우리나라에서는 2000년 전후로 이러한 비젼을 가지고 리눅스를 기반으로 사업을 시작한 분들이 많았지만 다들 어디에 있는지 모르겠네요. (사실 저도 그 중 한사람이었다는 -.-; 음, 한사람은 확실이 어디있는지 알겠지요? 바로 여기에 ...)
아참 그러고 보니 요즘엔 IBM 과 Oralce도 PHP을 적극적으로 지원한다는 얘기도 있고, MS, Oracle, IBM의 경우 자신들 DBMS의 Lite 버전을 자유롭게 다운받아서 사용할 수 있도록 하던데 이러한 오픈소스기반의 LAMP 솔루션 같은 것들에 자극을 받아서이겠지요?

http://www.theserverside.com/news/thread.tss?thread_id=36129

Jakob Neilsen 이라는 Usability의 대가가 최근에 쓴 글을 우연히 보게 되었습니다. 제목이 R.I.P. WYSIWYG 인데, 더이상 Mac-Style의 인터랙션 디자인은 그 한계에 왔다는 글이었습니다. 그러면서 주장하는 것이 What You Get Is What You See, 즉 WYGIWYS 이 되는 것이죠. 그러면서 대표적인 어플리케이션으로 최근 베타버전이 공개된 Office 12 을 그 예로 들었습니다. 이를 results-oriented UI 라고 불리우는 새로운 패러다임의 등장이라고 생각하는 것 같습니다. MS Office을 사용하는 사람들은 자연스럽게 다른 어플리케이션도 Office 처럼 되기를 원하기 때문에 향후에는 MS Office 12와 같은 UI 형태로 어플리케이션이 만들어 질 것이라는 것이죠. 동영상으로 Office 12가 동작하는 것을 보았는데 어쩌면 Office보다는 캐드나 그래픽소프트웨어에서 더욱 이러한 개념이 잘 받아들여지고 사용될 것으로 보여집니다. 사실 이러한 개념은 Alan Cooper가 주장한 Goal-Oriented Design과 같은 맥락입니다. 길은 하나이란 거죠. 다만 어떻게 그 길을 가느냐만 조금씩 틀릴 것입니다. 간단히 그 UI의 동작이 어떻게 이루어지는 것인지를 설명하면 다음과 같습니다. 내가 어떤 작업을 하고 있을 때 어떤 텍스트나 오브젝트 또는 레이아웃 작업을 하게 될 때 실제 결과의 형태가 이렇다는 것을 보여주고 사용자는 그 모양을 보고 직관적으로 속성이나 레이아웃을 정하는 개념입니다. 현재 작업상태에 따라서 불필요한 메뉴나 버튼은 안보이게 되구요. 비슷한 기능이 Photoshop의 필터작업을 할 때 일부 볼 수 있습니다. 특히 사진의 색이나 레벨을 보정할 때 여러가지 값이 설정되었을 때의 여러장의 사진을 미리 좌악 보여주고 사용자는 이중에서 가장 최적의 설정값을 정할 수 있게 해주는 것이죠. 이러한 개념들이 다양한 어플리케이션에 적용된다면 많이 편리해 질 것입니다. 분명 오해하지 말아야 할 것은 위저드나 자동 철자 체크처럼 어설픈 자동화 기능은 아니라는 것입니다. 눈보다 정확한게 있겠습니까? 하지만 시각장애우들에게는 다른 방법의 접근방법들이 고려되어야 하겠지만요. 예를들어 음성인식과 같은 방법말입니다.


정신병원을 뛰쳐나온 디자인
류한석의 피플웨어 MS Word 1.0 (1989년)과 MS Word 12 (2006년)의 스크린샷 비교 참고
http://www.useit.com

블로그 서버를 제 PC에서 IDC에 있는 서버로 옮겼습니다. 옮기는데 15분밖에 안걸리는군요.IDC 서버의 DB 암호를 알아내는 시간이 제일 오래걸렸습니다. 워낙 암호가 복잡해서 찾고 입력하느라. 그런데 응답속도는 집에서 운영하는게 더 빠른 것 같아요. 거의 두달동안 집에 있는 PC을 끄질 않았었는데 나름대로 신뢰성이 있는 것 같습니다. 올초에 컴이 망가지면서 작은 크기의 베어본을 사서 쓰고 있었는데 좋네요. 이번 PC을 이용한 블로그 서버 운영을 계기로 앞으로는 Intel이 아닌 AMD 머쉰을 더 좋아할 것 같습니다. 매우 만족스럽습니다. 그다음 고민은 집의 컴을 이제는 끄고 다닐것이냐 아니면 지금처럼 켜놓도 다른 용도로 사용할 까 하는 것이죠. 다시 변덕이 생겨서 IDC의 블로스 서버를 집으로 옮겨올 수도 있구요.

여러분들은 여전히 http://www.kimws.com 으로 들어오시면 됩니다.

친구가 굳이 얘기해서 지금 본가의 마당을 지키고 있는 푸치와 메리입니다. 참고로 저희집에서는 어떤개가 오든 세가지 이름 중 하나로 불리웁니다. 푸치, 베스, 메리 . 아버님은 늘 이 셋중에서 개의 크기를 중심으로 부르시지요. 대략 큰 개는 푸치, 중간 크기는 베스, 작은 강아지 크기는 메리라고요. 커나가면서 이름이 저 순서대로 바뀔 때도 있었습니다. 왠만한 개는 베스라고 부르시지요.


예전 푸치의 뒤를 이어 마당을 지키고 있는 2대 푸치



강아지때는 그리 이쁘더니 크고 나니 저런 잡종이 되버린 메리. 하지만 엄청 영리하답니다.

역촌동 본가의 마당 모습입니다. 몇개의 사진을 이어붙이다보니 조금 잘린 부분도 있지만 연결해서 하나의 사진으로 만드니까 마당의 모습이 3배로 커보이는 군요. 평생 아버님과 어머님이 가꾸어오신 마당이 겨울을 준비하고 있군요. 여름에는 초록색의 잔디와 온갖 색의 꽃으로 정말 멋지답니다. 같이 살때는 잔디깍는 것 때문에 이핑계 저핑계 대고 도망가곤 했었지요. 여름엔 특히 상추나 가지도 기르셔서 맛난 야채를 먹곤 한답니다.


원본을 보실려면 여기를 누르세요.



몇년전에 찍은 여름사진을 찾았습니다.
여름때 마당 모습을 보실려면 여기를 누르세요

Ruby라고 하는 언어로 만들어진 웹어플리케이션 프레임워크입니다. 프로그래밍 언어에 관심이 많다보니 알게 되었는데 여러분들도 한번 즐겨보시길 바랍니다. 아래의 링크에 가셔서 주~욱 따라가 보세요. 마이크로소프트웨어에도 관련 기사가 있으니 보시구요. MVC 모델을 충실히 따른 프레임워크 및 Agile 프로그래밍 환경이라고 생각이 듭니다. 아래는 오릴리 사이트에 올라와 있는 튜토리얼입니다.


Rolling with Ruby on Rails
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

http://www.rubyonrails.org/ 그런데 회사에서는 이 사이트가 접속이 안되네요. 집에서는 잘 접속이 되는데.

게임을 즐기기보다는 구경하기를 좋아해서 설치해보구 그림보구 바로 지우곤 합니다. 최근에 Call Of Duty2 라는 것을 설치해서 잠깐 해보았는데, 훌륭하군요. 2차세계대전 중 러시아 소총수가 되어서 싸우는 시나리오로 시작하는데 정말 리~얼 하네요. Medal Of Honor 도 비슷한 류인데 Military 매니어들은 정말 좋아할 것 같네요. 여하튼 독일군은 항상 적으로 나오는 군요. 심지어 러시아군 입장에서도. 그러고 보면 Medal Of Honor Pacific Assult에서는 일본군이 적으로 나오구요.같은 총싸움 게임도 HALO나 Quake, Doom 류보다는 Call of Duty 같은 게임이 더 나은 것 같습니다. 몇발 쏘면 장전하느라 숨는게 더 긴장감 있습니다. 다행히 상대방도 그러고 있어서 더 재미있지요. 아무래도 저는 스타크래프트 보다는 이렇게 마구 총쏘다가 마는 게임이 더 맞는 것 같습니다. 또는 Burnout 같이 자동차로 내달리다가 끝나는 게임이나.

http://www.callofduty.com/

정말 전 이런게 좋아요. 문자만 좀 편하게 보게 액정이 두줄정도면 충분할 것 같거든요.단축번호를 위한 하얀 스티커. ^^

기간확정 개발법은 제작시기에 쓰는 개발법으로, 개발팀에게 절박감을 느끼게 만들어 가장 중요한 기능에 프로젝트 초점을 유지하도록 도와준다. 기간확정 개발법은 일정을 프로젝트에 맞춰 재정의하는 대신 제품을 일정에 맞춰 재정의하여 일정 단축을 이끈다. 이 방법은 내부 비지니스 소프트웨어에 가장 적합사지만, 고객 맞춤식이나 기성품 프로젝트의 특정 부분에 대해서도 선택적으로 활용할 수 있다. 기간확정 개발법이 성공하려면 이를 활용하는 데 있어 적합한 프로젝트 선정과 최종 사용자가 일정을 늘이는 대신 기능을 줄이는 의지가 필요하다.


주요 위험요소

• 부적절한 제품에 기간확정 개발법을 적용하기


• 기능 대신 품질을 희생하기

주요 상호작용과 상충요인

• 발전적인 프로토타이핑에 의존한다.


• 기능 통제를 희생해서 개발 시간 통제를 얻어낸다.


• 때때로 RAD 프로젝트에서 JAD, 케이스 도구, 발전적인 프로토타이핑과 결합한다.


• 내용보다도 출시 시점을 중요하게 여길 때, 발전적인 출시와 결합한다.

스티브 맥코넬의 "Rapid Development" 에서


아마도 소프트웨어 개발 프로젝트중에서 가장 많이 사용되는 것이겠죠. 장점과 리스크가 정리된게 눈에 띄어서 올려봅니다. 많은 S/W개발자들이 기간확정 개발법에 반발이 많지만, 적절하게 적용하고 긍정적으로 이에 대처한다면 나름대로 의미가 있는 방법이네요. 그래도 불합리한 여건속에서도 열심히 힘써 준 분들에게 가장 고맙지요.