페이지

2018년 6월 6일 수요일

솔로 스타워즈 무비...



별: ***

(참고로, 로그원:****, 라스트제다이: *, 에피소드6: *****)

주변에 망작이라는 소문과 달리 생각보다 재미있게 영화를 봤다. 디즈니가 라스트 제다이에서 워낙 실망을 많이 줬고 제작 도중 감독이 교체되는 일이 있는 등.. 사실 캐스팅도 개인적으로 잘한건지 의심이 들기도 해서 큰 기대를 하지는 않았다. 자, 한 솔로가 주인공이니까.. 확실히 뭔가 달라야한다는 기대는 있었다. 그런면에서 영화에 다소 힘이 덜 들어가고 비장미도 없어서(제다이가 없으니까..) 좋았다. 대신 약간의 유머와 배신 이런게 돗보인, 약간은 B급 무비 같은 줄거리.. 이런 부분이 한솔로와는 잘 어울렸다. 도대체 원래 감독을 많은 분들이 어떻게 영화를 만들려고 했을까 궁금하기도 하다.

제일 좋았던 부분은 역시 추바카와 만나는 부분이다. 상당히 설득력이 있고, 유일한 오리지널 멤버가 나와서 더욱 좋았다. 상당히 장수하는 종족인 듯 보인다. 이미 150(?) 살 이상 살았으니.. 두고 두고 스타워즈 시리즈에 나올 듯.. 란도와 로봇 L-3와 관계도 묘하다. L-3는 로그원에 나온 로봇 처럼 인간 보다 더 인간답다. 게다가 로봇의 권리까지 주장한다.

음악은 존 윌리암스 옹께서 다시 맡으셨다. 경의를 표하는 바이다. 음악듣기

감독은 론 하워드. 이름 낯익어 찾아보니, 내가 좋아하는 영화를 찍은 분이다. 아폴로13, 백드래프트 등...

3부작으로 만들어질 예정이라는데, 이번에 흥행에 실패해서 어떻게 될지 모르겠다. 스타워즈 시리즈 사상 처음으로 손해가 예상되는 영화라하는데, 여러가지로 디즈니가 스타워즈를 말아먹는 것 같아 아쉽다. 다음 에피소드9은 다시 JJ 에이브람스가 맡는다고 하니.. 다시 신화를 재건할 수 있을까..

몇가지 영상 공유:




이 배우 참 맘이 든다. :-)




Young Han Solo Alden Ehrenreich와 해리슨 포드가 만났군요.



참고로, SF 블로그에 올린 글입니다.

2018년 5월 5일 토요일

남들이 짠 코드 읽기...

처음 개발자로서 일할때는 모든 프로젝트가 정말 바닥부터 코딩을 했다. 한마디로 main으로 코딩을 시작했다. 이런 코딩은 아주 재밌다. 내가 모든 것을 지배하니까..
그런 즐거움도 잠시 대기업이 들어간 이후 부터 지금까지 남들이 짜 놓은 방대한 코드에 뭔가 기능을 구현해야했다. 이때 부터 본격적인 코드 읽기가 시작되었다. 방대한 코드를 이해하는 것은 쉽지 않다. 그냥 코드만 읽어서는 절대 이해할 수 없는 것이 코드 읽기다. 오죽하면 이런 책도 있다.  그래서 지금까지 경험한 것을 잠깐 공유하려고 한다.

1.gdb로 step into를 통해 프로그램 동작을 이해한다.
call graph를 복사해 놓고 sequence diagram을 그려 놓으면 좋다. 이것을 바탕으로 class diagram을 그려놓고 프로그램 전체 구조를 이해한다. 그리고 layered architeture diagram을 그려 놓는 것도 좋다.

2. 버그를 잡는다.
오픈소스인 경우 버그를 잡아본다. 그러면서 코드를 이해한다. 버그를 잡은 경우에는 어떻게 잡았는지 잘 문서화 해 놓는다. 이렇게 여러군데 버그를 잡다보면 부분 부분 이해가 늘어나고 어느새 전체 구조를 이해하게된다.

3. 기존 문서나 비디오 등을 꼭 본다.
기존 개발자가 만들어 놓은 기술 문서, 기술 토크 비디오를 찾아서 질리도록 본다. 사실 코드가 자주 바뀌지만, 대부분 문서를 아주 자세한 경우가 드물기 때문에 좀 오래된 문서들도 도움이 된다.

4. 프로젝트내에 있는 작은 데모, 테스트케이스 코드를 본다.
이들 프로그램은 꼭 필요한 코드만 담겨져 있어서 이해가 쉽다.

5. Design Pattern에 익숙해진다.
많은 프로젝트가 익숙한 Design Pattern을 사용한다. 디자인 패턴에 익숙할 수록 코드 이해가 빠르다.

6.  Concurrent programming, IPC에 익숙해진다.
Chromium이 Multiple Process Model을 도입한 이후, 프로그램 동작을 이해하기가 까다로워졌다.

7. API에 익숙해진다.
당연한 이야기지만, 윈도면 윈도 API, 유닉스면 POSIX API에 익숙해져야 한다..

8. Domain knowledge에 익숙해진다.
웹브라우저를 개발한다면, 웹기술에 익숙해져야 하듯이, 게임을 만든다면, 게임 자체를 이해해야 한다.

9. Refactoring을 해본다.
한동안 Blink Editing component을 기여한적이 있었다. Chromium 코드 가운데 복잡하기로 악명 높은 코드다. 여러 사람이 개발을 했고 Editing API가 표준화가 덜 된 탓도 있다. 어찌되었던 이런 시도는 코드 건강에 좋다.

지금 끝도 없는 방대한 코드를 보려다가, 그냥 두서 없이 정리해보았다. 자 이렇게 남의 코드를 볼 노력으로 그냥 나만의 프로그램을 만들자. ㅎㅎ

참고로 읽어본 글

2018년 4월 21일 토요일

hanterm

한글 관련 오픈소스 프로젝트를 좀 찾아봤는데, hanterm과 libhangul/nabi가 떠올랐다. libhangul은 지금도 잘 관리되고 있는데,  hanterm 은 2000년에 마지막 업데이트가 있었던 것 같다.

소스코드를 찾아보니, 우분투에도 흔적이 있고,
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/feisty/hanterm-classic/feisty/files

젠투에도 코드가 남아있다.
https://gpo.zugaina.org/x11-terms/hanterm

han.ccomp.hangul에서도 hanterm에 대한 글을 찾을 수 있다.
https://groups.google.com/forum/#!searchin/han.comp.hangul/hanterm%7Csort:date

kaist ftp 사이트에서 여러버전의 hanterm과 다른 유닉스, 윈도우에 포팅된 코드도 있는 것 같다.
ftp://ftp.kaist.ac.kr/hangul/terminal/hanterm/

한텀을 처음 만드신 송재경님 인터뷰도 찾았다.
https://sites.google.com/site/koreainternethistory/interview/interview-for-writing-a-book/jksong

현재 홈페이지는 접속이 안되며, archive.org를 통해서 예전 홈페이지 내용을 볼 수 있다.
https://web.archive.org/web/20070205200906/http://www.hanterm.org:80/
한글 처리에 대한 정보 등이 담겨져 있다.

시간나면 빌드를 해봐야할 듯.