+ 리스트와 맵으로 자식 객체에 접근이 가능한 상위 클래스.
+ 한 컴포넌트 내에서 발생하는 마우스 이벤트를 조합하여 드래그앤드롭의 수락, 처리를 담당하는 클래스와 구현하면 이 클래스가 발생하는 정보를 넘겨 쉽게 사용할 수 있게 하는 인터페이스.
2009년 11월 29일 일요일
메소드 추상화, 대칭성
같이 호출되는 메소드들의 대칭성을 유지하기 위해 메소드의 추상화가 요구된다. 메소드에 설명을 주기위해 다른 메소드를 그대로 한 번 더 호출 해줄뿐인 메소드를 만들 필요도 있다. 여기에 성능상의 비용은 크지 않다.
선택 메시지
조건문을 지우고 다형적 메시지를 호출하게 하는 방법. 다형성 설명에서 자주 등장하는 방법이다. 켄트 벡은 "선택 메시지를 사용하게 되면, 코드 독자가 연산의 세부 구현을 이해하기 위해 여러 개의 클래스를 살펴봐야 할 수도 있다"고 했고 "과도한 선택 메시지 사용은 좋지 않다." 라고도 했다.
선택 메시지를 무시하자는 목적으로 갈무리를 해두는 것은 아니다. 선택 메시지가 갖는 단점을 기억하기 위해서 적어둔다. "과도한"의 정의가 중요하다. 켄트 벡은 "당장 연산의 변형이 필요하지 않은 경우라면 미래 확장을 위해 굳이" 그럴필요 없다고 말한다.
추가. 단점을 기억하기 위해 쓰다보니 무조건 안좋은 것처럼 보인다. 전혀 아니다. ㅎ
양육
본성이냐 양육이냐의 문제는 사회 생물학의 중요한 내용 중 하나였고 나는 그 것을 통해 무서움을 느꼈으며 즐겨보던 매트리들리를 통해 읽은 "본성과 양육"은 본성을 통한 양육이라는 결론을 내려 안심을 하게 했다. 최근에 양육과 관련된 책 몇 권이 이래저래 보여져서 링크를 모아둔다.
양육쇼크
http://www.hani.co.kr/arti/culture/book/390196.html
죽어라 말 안 듣는 아이, 이유를 알고 싶다
http://www.yes24.com/24/goods/3092514
교사를 당황하게 하는 아이를 만났을 때
2009년 11월 25일 수요일
stackoverflow, yakov fain
http://stackoverflow.com/ 이 알고보니 Joel Spolsky랑 Jeff Atwood가 만든 거였다.
다른 서비스로 http://stackexchange.com/ 이 있다. 같은 엔진인데 각자 운영을 할 수 있나 보다. 유료다.
yakov fain이 돈을 내고 stackexchange.com 을 시작한다고 한다. 여기를 보면 관련 포스트를 볼 수 있다.
아래는 그 주소
2009년 11월 23일 월요일
모든 svn 하위 디렉토리 지우기
모든 하위 svn 정보(.svn) 지우는 배치파일.
for /f "tokens=* delims=" %%i in ('dir /s /b /a:d *svn') do (
rd /s /q "%%i"
)
pause
엉뚱한 위치에서 실행하면 안됨.
2009년 11월 21일 토요일
선택권
" 저희는 사용자들의 선택권이야 말로 구글을 비롯한 모든 기업과 사람들에게 혜택을 주는 혁신을 이끌 것으로 믿고 있습니다."
-- 구글 크롬OS와 안드로이드가 OS라는 측면에서 일정부분 겹치는 것에 대한 구글의 생각
2009년 11월 14일 토요일
몰입의 즐거움
미하이 칙센트미하이의 몰입의 즐거움을 읽었다. 플로라는 개념은 IT 조직론 관련 서적 피플웨어를 통해서 처음 접했었다. 그러다가 갖고있는 몇 개의 책에서 미하이 칙센트미하이가 여러차례 인용이 되는 것을 보면서 관심을 갖게 됐고 사보게 됐다. 저자 이름부터 몰입감이 있어보인다. 책을 살때 즐겁게 일하는 것이 몰입을 유도하고 몰입하여 일하는 것이 결과도 좋다는 것을 말하지 않을까 싶었다. 그러나 즐거움 자체가 항상 생산적일 수는 없다는 내용을 다루면서 몰입 자체에 대하여 다시 생각을 하게 됐고 여가를 어떻게 보낼지에 대해 생각을 하게 됐다. 사소한 것에서 즐거움을 얻는 방법도 배운듯 싶다. 책은 인간 관계, 여가를 다루는 방법, 삶의 태도, 가치 있는 삶 등을 다룬다. 통계에 기반하여 쓰여졌지만 학술서적은 아니다. 그래서 그런지 가르침을 주려는 문장들이 종종 보인다.
2009년 11월 12일 목요일
2009년 11월 11일 수요일
몰입감, 소음, 페어
5~7월 사이 심각하게 느꼈던 몰입의 어려움을 다시 느끼고 있다. 핵심은 전화기였다. 당시에는 전화받을 옆의 사람과 내 전화가 동시에 울리면 내가 전화를 받아서 옆사람에게 바꿔주는 굉장히 신비한 짓을 하고 있었다. 나에게 오는 전화는 5~7월 사이 한 건 정도 있었나 없었나 그렇게 기억한다. 일이 싫었는지 내 집중력이 부족했던 건지 아무튼 낮은 어렵게 보내고 칼퇴근을 한뒤 새벽에 나타나 일과 공부를 했다(사무실과 집이 가깝다 ㅎ). 당시 사장면담에서 나는 유일한 개선 요구사항으로 서버의 소음이 너무 크다고 말했다.
그 이후에는 업무 형태가 조금 바꼈다. 세 명이 돌아가며 두 명씩(페어) 일을 했다. 며칠 전 10월 말까지 그렇게 계속 일을 했는데 원래 앉던 자리와 비슷한 자리였음에도 별로 시끄럽다는 생각이 들지 않았다. 우선 말을 하게 되므로 아무래도 의미없는 서버 소리나 전화기 소리보다는 상대의 말이 더 집중됐다. 이 시기에는 야근, 철야도 많이 했기 때문에 확실히 페어워킹의 효과인지 알 수는 없다. 야근을 하면 회사는 조용하기 마련이다. 이쪽 파트가 페어를 하는 동안 근처 파트(원래 있던 파트)의 업무 능률에 대한 판단도 없다. 같은 내용이 아니니(이쪽은 Flex, 저쪽은 PHP) 대화소리 때문에 아마 떨어지지 않았을까.
최근에 자리배치가 바뀌게 돼서 딱 중앙에 있는 자리에 앉아있다. 사람이 많이 늘어서 다른 파트들은 절대적인 미팅의 수가 많아졌다. 자리를 옮기기 전에는 가까이 앉아보지 못했던 다른 개발팀은 업무지시를 파티션 너머로 말하는 문화다. 누구씨 뭐하면 뭐 줘요, 이메일 뭐에요, 커밋했어?, 미안 나때문에, 메신저가 안되는데요, 누구씨 개인적으로 밖에서 잠시 얘기좀 하죠. 까지가 정확히 오늘 있던 일 중에 기억에 남는 대화다. 옆 동료들도 묻진 않았지만 아마 기억할 것으로 예상된다. 내가 잘난 것은 아니니 개인적 집중력의 부족이면 직종을 바꿀 생각은 하고있다. 진지함.
2009년 11월 8일 일요일
2009년 11월 2일 월요일
BrowserManager로 URL 변경 알아내기
bm.addEventListener(BrowserChangeEvent.BROWSER_URL_CHANGE, onURLChange);
bm.setFragment("key=" + value);
를 하면 URL이 바뀌고 히스토리에 추가된다.
onURLChagne 에서 o.value를 얻어서 사용할 수 있다.
BrowserManager를 사용한 URL 파싱
BrowserManager
var bm:IBrowserManager = BrowserManager.getInstance();
bm.init();
bm.url : full url
bm.base : # 앞
bm.fragment : # 뒤
URLUtil
URLUtil.getPort(bm.url); // 8080
URLUtil.getProtocol(bm.url); // http
URLUtil.getServerName(bm.url); // localhost
URLUtil.getServerNameWithPort(bm.url); // localhost:8080
// 세미콜론으로 나뉘어진 url 단편들을 액션스크립트 객체로 파싱
var o:Object = URLUtil.stringToObject(bm.fragment);
ObjectUtil
// ★ Object를 찍어보기
ObjectUtil.toString(o);
// #id=goojoono;name=KooJunHo 대소문자 구분 함.
o.id == "goojoono"
o.name == "KooJunHo"
초간단 배포 batch 파일
xcopy "C:\flexprojects\BM\output\*" "C:\APM_Setup\htdocs\bm" /E /Y
/E : 비어있는 디렉토리를 포함한 하위 디렉토리를 복사
/Y : 덮어써야 하는 상황에 질문하지 말고 덮어쓰기
테스트 할때 사용
2009년 11월 1일 일요일
XML 다루기
http://koojunho.textcube.com/22
http://koojunho.textcube.com/38
http://koojunho.textcube.com/55
몇 번의 고민을 통해 XML을 직접 데이터로 사용하기 보다는 XML의 엘리먼트들을 잘 표현하는 Object로 바꿔주고 컬렉션을 통해 사용하는 것이 좋을 것 같다는 결론을 내렸다. (물론 여전히 상황따라 다를 수 있다는 전제를 깐다. ㅎ)
XML만을 사용하는 경우 XML을 데이터로 주고받는 상황에서 문제가 많이 생긴다. 어떤 XML 엘리먼트건 XML로 받을 수 있기 때문에 해당 값이 내가 받고자 하는 엘리먼트인지 아닌지를 판단하는 문제는 런타임으로 넘어가게 된다. XML이 수정되는 경우라도 컴파일 타임에는 아무런 문제를 일으키지 않기 때문에 모든 문제를 런타임으로 넘기게 된다. 문제가 런타임으로 넘어가면 프로그램의 해당 부분을 실행하기 전까지 문제가 있는지 아닌지 알 수 없게된다.
Object라고 해서 데이터가 수정될 때 아무런 작업이 필요 없는 것은 아니다. XML을 파싱해서 객체로 만들어 주는 과정과 자료구조를 만들어 주는 과정이 필요하다. 게다가 검색기능은 E4X, XPath 등에 비해 훨씬 귀찮다. 그러나 데이터가 바뀌고 클래스를 바꾸면 해당 값을 사용하는 모든 클래스들이 반응하게 된다. XML에서 특정 엘리먼트의 데이터를 다루는 방법이 바뀔경우 캡슐화된 클래스 내에서 처리방법만 바꿔주면 그 클래스를 사용하는 모든 클라이언트 코드가 자동으로 바뀌는 셈이다.
그렇지만 XML을 클래스로 만드는 것도 일은 일이다. 그래서 유닛테스트 프레임워크를 사용해서 완성된 XML을 기반으로 클래스를 만들면서 테스트를 하면 구현이 필요한 클래스의 나머지 일부가 어떤 것인지를 에러로 보여주는 클래스를 구현했다. 만약 내가 어떤 엘리먼트의 자식 엘리먼트로 <title />을 추가하고 실행을 했다면, 알 수 없는 title이라는 존재를 인식한 객체가 예외를 발생시키는 구조다. AS3.0에서 this[elementName] 으로 접근하여 값을 집어넣게 하는 방식으로 처리했다. this객체가 dynamic 클래스의 인스턴스는 아니기 때문에 동적으로 값을 넣을 수 없으면 예외를 던지는 것이다.
직접 XML을 클래스로 바꾸는 작업도 같이 진행했는데 처음에는 더뎌 보였지만 기반 클래스가 갖춰지자 테스트에 의존해서 클래스를 만들어 내는 쪽이 더 빨리 끝났다. 별로 머리 쓸 일이 없게 해준다.
엘리먼트마다 클래스가 생겨서 해당 엘리먼트 또는 자식 엘리먼트들을 처리하기 위한 기능들을 추가할 수 있게 됐다. 예를 들어 날짜를 갖고있는 XML이 있다면 XML로 접근했을 때 텍스트일 뿐이고 나중에 클라이언트 코드에서 해당 XML을 Date 클래스 등으로 변환해 주어야 한다. 클래스로 구현이 되어 있는 경우는 미리 그 작업을 베이스 코드에서 해주기 때문에 편해 보인다.
물론 XML을 OOP 구조로 치환 했을때 데이터를 제대로 표현했다고 하기에는 무리가 있다. 객체를 사용하는 게 더 좋다고 결론을 내렸다지만 XML을 객체로 치환하는 게 중요한 게 아니라 XML로 표현 된 데이터를 객체로 제대로 표현하는 게 더 중요하다. 사람의 고민이 필요한 부분에선 이 클래스들도 영 쓸모가 없다. 그래서 중요한 것은 만드려는 게 무엇인가를 먼저 봐야 하는 거고, 그 보다 더 좋은건 XML 정의하는 과정에도 참여하는 게 더 좋았을 텐데, 아직 설명은 못들었고 주말엔 쉬어야 한다는 생각이 갑자기 들었기 때문에. 오케이 여기까지. ㅎ
지속적 훈련 강요 툴 - 최종
1.
토요일동안 간단한 프로그램을 만들었다. 일종의 일정관리 툴이라고 볼 수 있는데 할 일을 기록하는 게 아니라 한 일을 기록하는 게 특징이다. 서비스에 로그인을 하면 해당 사용자가 하고자 하는 일들이 나온다. 예를 들어 일이란 영어단어 외우기, 운동하기, 청소하기 등이 될 수 있다. 각각의 일은 달력 한 개로 표현되는데 그날 하려고 한 일을 했다면 해당 날짜를 녹색으로 체크할 수 있다.
화면에 나온 달력들을 녹색 체크로 채우는 재미를 느끼게 하는 것이 이 프로그램의 목적이다. 더 정리가 된다면 사용자가 한 십 년치 녹색 체크를 가질 수 있게 유도하는 컨셉을 잡아보고 싶다. 무엇이든 꾸준히 오랜 시간을 한다면 성취할 수 있다는 내 믿음(증거는 없다. ㅎ)을 만든 것이다. 예전에 웹호스팅 받던 개인 서버에서 게시판에 후배 한두 명과 공부한 내용을 기록하던 경험을 살려봤다.
2.
어느정도 기능 구현은 완료됐다. 안정성, 편리성 따지지 않으면 당장엔 너그러운 사용자들과 함께 쓸 수 있는 수준이다. 몇 가지 익힌 것이 있고 더 필요한 것들을 알게됐다. 까먹지 않도록 해당 내용을 정리한다.
PHP 통신
Flash 기술로 서버사이드와 통신을 하는 RPC 라이브러리를 만들어 본 것은 이번이 두 번째다.
한 개는 졸작때 만든 건데 그때는 사용 툴이 Flex가 아니라 Flash였다. 주요 내용은 이렇다.
+ Flash에서 서버와의 통신을 담당하는 객체를 dynamic으로 만든다.
+ PHP 서버에 공개 할 메소드(웹메소드)를 XML로 표현한다.
+ Flash에서 웹메소드 XML을 파싱하여 동적으로 메소드를 삽입한다.
+ Flash에서 직접 구현하지 않은 웹메소드를 사용한다.
+ 자바의 리플랙션을 사용하여 소켓 서버용으로도 똑같이 만든다. (Apache MINA 사용)
위 라이브러리를 사용하여 Flash에서 PHP를 사용한 영단어 퀴즈 프로그램과 자바 소켓 서버를 사용한 멀티유저 블랙잭 게임을 만들었다.
결론적으로 웹(PHP 라이브러리)은 Request가 있으면 Response가 있으니까 라이브러리가 꽤 편리했다. 나는 호출할 수 있는 서버 메소드 목록을 찍어볼 수 있었고 Flash에서 직접 구현하지 않은 메소드 이지만 서버가 넘겨준 스팩대로 호출하면 결과가 나왔다. 그러나 Flash-자바소켓서버 통신에서는 라이브러리의 장점이 나타나질 못했다. 소켓서버는 클라이언트가 뭔가를 요구하지 않아도 서버가 메세지를 보내기도 한다. 물론 이는 소켓 프로그래밍 자체가 가지고 있는 일정 수준의 복잡성 때문이기는 하지만 내 라이브러리가 별로 필요 없어 보이긴 했다.
이번에 새로 짠 Flash-PHP RPC 라이브러리는 개념이 다르다. 졸작때 만든 라이브러리는 서버의 구현 내용을 몰라도 인터페이스가 가능하게 하는 라이브러리였다. WebService처럼 서비스 내용과 프로토콜을 알려주는 라이브러리였다. 제작 목적이 졸작이므로 "서버의 PHP에서 메소드를 만들면 클라이언트의 Flash에서 호출할 수 있습니다." 와 같은 마법같은 문장이 필요하긴 했지만 서버/클라이언트 모두 제작하는 상황에서는 타이핑 몇 줄 줄여주는 것 말고는 쓸데없다. 또 원격 객체를 동적으로 만들면 IDE가 제공하는 자동완성을 쓰지 못한다. 졸작때는 Flash를 사용했기 때문에 자동완성 기능이 약해서 그냥 그냥 넘어갔는데 Flex에서 그러고 싶지는 않았다.
새로만든 라이브러리는 아래와 같은 구조로 작동한다.
+ Request를 처리하는 클래스를 상속받아 새로운 클래스를 만든다.
+ Flex에도 위에서 만든 클래스에 대응하는 클래스를 만든다.
+ 원격 메소드를 호출하면서 class와 method를 post로 넘긴다.
+ php에서 class 이름으로 클래스를 생성하고 method를 실행시킨다.
+ 결과를 XML로 받는다.
대충 앞의 라이브러리와 비슷하지만 서버가 기능 목록을 전송하는 과정이 없고 호출하는 클라이언트도 호출 클래스를 직접 구현해줘야 하는 차이가 있다.
WebORB, BlazeDS 등으로 AMF 쓰는 것을 생각할 수도 있겠지만 남의 것 쓰면 조금 위험할 수 있다는 생각과 실제로 내 웹 호스팅에서는 이 프레임워크들이 잘 작동을 안하기 때문에 또, WebORB는 PHP 버전을 사용해 봤으니 그리 편하다는 생각은 들지 않아서 만들어 봤다.
통신을 하다 생기는 오류는 서로 다른 시스템이기 때문에 문제의 원인을 쉽게 노출시키기 어렵다. Flash가 PHP로부터 xml을 받으려고 했는데 PHP 코드에 에러가 생길 수 있다. Flash에서 xml로 형 변환을 하려다가 PHP 에러 구문이 xml이 아니니까 예외가 뜨게 되는데 이때 심각하게 고쳐야 할 것은 PHP 코드이지 Flash는 아니다(물론 예외 처리가 필요하다). 이때 아무 메세지 없이 Flash 코드를 노려보고 있다면 갑갑해지기 쉽상이다. 이를 수월하게 하기 위한 출력이 필요하다.
UX
DB에 기록하고 결과를 받아서 화면에 표현하기까지 지연이 생긴다. 만약 On/Off 버튼을 구현한다고 하면(GMail의 별표 기능 처럼) 서버 지연 때문에 엇박으로 클릭을 하다가 이제 된건가 하고 가만히 서버의 응답을 기다려야 하는 상황이 생길 수 있다. 이게 생각 이상으로 답답하다. 사용자가 클릭하면 일단은 처리된 것으로 보여주고 서버에서 데이터를 받아서 성공하면 놔두고 실패하면 실패를 알리고 화면을 갱신하는 식으로 처리하는 것이 좋을 것 같다.
당연한 효과들
화면에 보여지는 여러개의 달력 중 변경된 한 개의 달력 내용을 표현하기 위해 전체 달력 레이아웃과 체크 데이터를 새로 갱신할 필요가 없다. RIA의 장점이다. 이게 데이터 전송량에서만 이점이 생긴다고 생각했는데 서버 자원을 절약해 주기도 한다. 물론 AJAX로 할 수도 있겠지만 내 학습상태로는 Flex가 편하다. 물론 이러한 프로그램이면 Flex로 만드는 것 보다 AJAX로 만드는 게 더 좋을 것 같다는 생각이 있다.
더 필요한 것
+ 세션처리 - 세션을 담당하는 게 Flash를 담고있는 브라우저인지, Flash가 서버와 통신하는 객체인지 아직 파악을 못했다.
+ DB 생성 스크립트 - 지금이야 상관 없는데 배포가 되고나서 DB가 바뀌면 골치 아프다. DB도 버전에 따라 자동으로 스키마를 변경 해주는 유틸리티가 필요하다. 이미 있거나 만들기 어렵다는 결론이라도 어디 있을 것 같긴 한데...
+ 서버 자동 배포 - 배치파일과 FTP를 사용하여 업로드를 하던 코드는 만들었었는데 이러면 릴리즈 과정과 같이 묶이지는 못한다. Ant나 Maven을 쓸 수 있도록 변경한다.
+ 그러므로 유닛 테스팅.
+ Debug mode지원 - 앞에서도 썼지만 개발 중에 생기는 오류를 파악할 수 있는 장치가 절대적으로 필요하다.
+ 다른 사람 화면 볼 수 있게 하기.
+ 한 일 등록 정책.
3.
전반적으로 Flex로 그닥 뛰어난 성능은 아니지만 대중적인 서버와 통신하는 효율 적인 방법에 대해 학습을 했다. 앞으로는 통신부분을 더 집중하는 것이 좋을 것 같다. 아무래도 계속 사용할 수 있는 코드이고 한 번 해결해 놓으면 반복적인 테스트에서 의미없이 소비되는 접근 시간을 줄일 수 있기 때문이다.
String2Date
var date:Date = DateField.stringToDate(dateXML.toString(), "YYYY-MM-DD");
String을 Date로 바꿀때.
피드 구독하기:
글 (Atom)