나도 잠시 즐겼던 게임 기타히어로(Guitar Hero)의 커뮤니티 사이트가 레일스로 개발된듯. 해당 커뮤니티 사이트를 개발한 주요개발자 3명이 발표한 세션. 게임과 레일스 웹 애플리케이션의 연동 중심의 특이사항을 기대했지만, 보통의 사례발표와 다르지않았다. 컨퍼런스에 와서 "튜토리얼"과 "사례발표"는 참가 후보에서 제외해야겠다는 교훈을 남겨준 세션.

그래도, 사례발표중 소개된 sparrow라는 큐(queue) 서버는 한번 살펴볼만하다. 타이틀을 보니 아래와 같다.

Sparrow is a really fast lightweight queue written in Ruby that speaks memcache. That means you can use Sparrow with any memcached client library (Ruby or otherwise).

memcached 프로토콜을 사용한다는 점이 아주 마음에 든다. 개별적으로 큐잉 처리를 해야한다면 사용해봐야겠다. 예전에 살펴봤던 starling역시 memcached프로토콜을 썼던것 같은데, 어떤 차이가 있을지 살펴봐야할 듯.

사이트 주소는,


Posted by hatemogi 트랙백 0 : 댓글 0
github.com에서 일하는 개발자의 세션. git의 활용방법을 깊숙히(!) 훑어주는 세션이었는데, 내 입장에서는 저렇게까지 심각하게 버전컨트롤 시스템을 쓸 일이 없어서, 크게 와닿지는 않았으나, 그래도 git이 저렇게 심각하게 -- 하지만 편리하게 -- 버전관리에 관련한 일들을 하고 있다는 것은 반길 일이었다.

세션발표자가 운영하고 있다는 Git Community Book도 훌륭해 보인다.
Posted by hatemogi 트랙백 0 : 댓글 0
무서워질정도로 더욱 더 몸매가 거대해져서 걱정이 앞서는 Jim Weirich의 세션. 노련한 베테랑답게, 자신을 한 회사의 Chief "Scientist"라고 소개하면서, 하나로 통합된 과학이론 하나를 예로 들며 돌아돌아 시간내에 결론을 이뤄내는 발표가 인상적이었다. 하지만 노련한 사람답게 "바로 이거다"라는 결론을 내리지는 않았다. 마치 영화 매트릭스의 의회대표 노인이 네오에게 "There's no point"라고 얘기하는 것 같았어.

주된 요점은, 좋은 소프트웨어 디자인을 위한 척도들이 수없이 많지만, 하나의 척도로 통합될 수 있다는 생각을 언급하는 내용이었다. 그 용어는 Connascence. 기존 다양한 척도들을 Connascence의 한 부류로 설명하며 세션 진행. 발표제목은 낚시용이었다고 했고, 실제 생각했던 제목은 "The Grand Unified Theory of Software Development"란다.

  • Connascence of Name (CoN)
  • Connascence of Position (CoP)
  • Connascence of Meaning (CoM)
  • Connascence of Algorithm (CoA)
  • Connascence of Timing (CoN)
  • Contranascence

이것이 다양한 Connascence(에구, 스펠링도 어려워)의 다양한 형태.
 
예를 들어 DRY(Don't Repeat Yourself)같은 디자인 원칙의 경우는 CoA를 CoN으로 변환한 형태(CoA의 Degree가 더 나쁘기때문에 조금더 나은 CoN으로 조금 나은 디자인으로 바꾸는 것).
 
흠, 어려운 용어들이다. 결론적인 얘기는 Connascence라는 하나의 통합된 척도로 소프트웨어의 좋은 디자인을 평가할 수 있다는 제안을 한것. 자세한 것은 묻지말아줘, 나도 이해 못했어. ㅋㅋㅋ



Posted by hatemogi 트랙백 0 : 댓글 0
37signals의 UI개발자의 세션이었는데, 코딩수준의 이해가 깊은듯 보였다. 인상적인 관점으로는, 결국 웹애플리케이션이 상대하는 고객은 사람이고, 최대한 사람과의 대화 관점에 가까운 UI디자인을 추구했다는 점. 개발자 관점에서는 데이터 필드의 나열이 되기 쉽지만, 사람을 상대로 대화하는 느낌의 대화방식 사용자 인터페이스를 강조했다.

UI is a layer of software, It's not independent
From the customer's point of view, the UI is the entire application
유치원에서 배웠을 법한 너무도 당연한 얘기지만, 개발에 집중하다보면 쉽게 잊혀지는 중요한 사항. 게다가 말로는 참 쉬운 일이지만, 실제 구현을 그렇게하기까지는 많은 노력과 연습이 필요한듯.

발표자는 37signals에서 일하는 사람답게 model이나 RESTful 컨벤션에 대한 이해도 적절해보였다. 자신의 레이어가 확실한 업무중에서도 관련있는 다른 레이어에 대한 이해도가 높은 점은 더욱 전문가답게 보인다. 나역시 관련있는 레이어에 대한 공부와 노력을 해야겠다는 자극을 받았지.

시선 이동과, 부분강조, 그리고 반강조(de-emphasizing, 보통 본문에 대비해 흐리게 표시) 활용을 보여주는 예제도 그럴싸해 보였지. 지극히 개발자스러운 나로서는 많이 보완해야할 부분임에 분명하다.

발표중에 추천한 책도 기회가 되면 읽어볼 예정. (과연 언제가 될런지...)

  • The Visual Display of Quantitative Information, Edward R. Tufte
  • Domain-driven Design: Tackling Complexity in the Heart of Software

Posted by hatemogi 트랙백 0 : 댓글 0
RSpec 프로젝트의 리드 개발자의 세션이었는데, RSpec에 관련한 내용은 최대한 자제했고, Mock과 Stub에 대한 전반적인 내용과 활용 가이드라인 소개였다. 워낙 BDD관련한 프레임웍들이 많은데다, 각각의 주장이 강한데다, 나같은 소비자의 입장에서는 단순하게 보면 그게 그거인거라.

Mock과 Stub의 구분과 활용, 그리고 팁을 논했고, 특히 레일스 애플리케이션에서의 접근을 customer specs와 developer specs로 나누어 접근하면 좋겠다는 제안을 했다. 사용자 기능성 테스트 수준이 될 수 있는 customer specs 레이어에서는 webrat이라는 프레임웍을 추천했는데, 클라이언트 사이드 테스트를 하려면 한번 써볼만 할듯. Selenium 스타일의 접근을 루비DSL로 할 수 있는 프레임웍인듯.

일단 접수해 놓을 프레임웍.


Posted by hatemogi 트랙백 0 : 댓글 0
(RailsConf2009에 참석중이지만, 따로 정성껏 정리할 여력이 없을것 같아서 -- 난 여행중이잖아? -- 별다른 깊은 생각없이 마구 써내리는 형식으로 기록을 남기려고 한다. 이렇게 하지 않으면 아무런 기록이 남지 않을것 같아서, 빠르게 마구 남기는게 좋은 방법일듯. 틀린 내용 또는 어설픈 내용이 많을 것 같아 겁나기는 하지만, 그 정도 두려움은 감수해야할 것 같다)

http://en.oreilly.com/rails2009/public/schedule/detail/9035

RailsConf2009의 시작을 알리는 첫번째 키노트, DHH의 발표자로는 위 주소에 PDF로 바로 올라와있다. 주된 내용은 Rails 3에 대한 소개이지만, 예상대로 아주 새로운 내용은 없는듯. 아마도 많은 정보가 관련해서 쏟아져 나올테므로, 나로써는 단지 주관적 느낌을 정리해 놓으면 충분할듯.

이미 레일스는 충분히 성장한데다 노련해지고 있는 단계임을 느끼는 키노트였다. 한창 떠오를 때의 레일스가 만개하는 젊음의 아름다움을 뽐냈다면, 이제는 성숙해서 다듬어지고 우아해지는 단계인 것 같다. 심지어는 노련미가 느껴지는 단계이지만 그 대신 화려한 느낌은 줄어든 듯 하다.

그리고, 중간에 -- 원래도 그런 용어를 썼었는지 모르겠지만 -- 더 나아진 자동화(?)관련해서 agnosticism이라는 단어를 사용했다는 것도 새로이 다가왔다. 최근 agnostic이라는 종교적(철학적?) 관점에 관심을 가진 상황이었거든.

Rails 3가 Merb와 합쳐진다는 발표가 이미 충분히 강력한 사항이어서, 나머지 상황들은 그다지 새롭지는 않았다. 단지 지속적인 철학적 관점을 재확인한 정도였다. 확실한 가치관을 갖고 프로젝트가 성장해나가는 것이, 마치 어떤 한 사람이 살아가며 성장해 나간다는 것과 비슷한 흐름으로 느껴진다는 것은 지나친 연결또는 비유일까? 여기까지는 지나칠 지 모르지만, 분명 소프트웨어 프로젝트도 하나의 생명체임을 부인하는 사람은 없겠지.

레일스의 철학내지는 가치관이 마음에 들면, 그 매력을 느끼는 사람이 모이고 연결되는 거고, 그렇지 않으면 떠나가는 것일듯.


Posted by hatemogi 트랙백 0 : 댓글 0

RailsConf2009 시작

2009.05.05 23:53 from programming
RailsConf2009에 참석하러 라스베가스 힐튼에 왔다. 등록을 마치고, 아침 식사 전. 다행히 한국에서 오시는 한분과 연락이 닿아서 힐튼의 트윈룸을 같이 쓰는중. 아마도 이번여행중 가장 화려한(!) 숙소리라.

역시 개발자스러운(!) 사람들의 모습이 눈에 띈다. 미국이나 우리나라나 개발자스러운 이미지는 공통인가봐. 그리고 역시 레일스 컨퍼런스답게 맥북프로가 거의 표준인듯 많이 보이고. (이젠 그게 익숙한 느낌). 역시나 동양인도 거의 없고, 여성도 거의 없다. (훗, 이 문장을 쓰는 순간 동양인 여자가 앞에 지나가는 건 뭐람)

아직 전혀 쓸 내용이 없지만, 자랑욕구(!)를 참을 수 없어. 블로깅!

오늘은 DHH의 키노트로 하루가 시작될 듯. 그래도 아직 두근거리며 설레이는거보니, 아직 개발자스러운 성향이 많이 남아있나보다.


Posted by hatemogi 트랙백 0 : 댓글 4
지난 주에 간단한 아이템으로 개발하기 시작한 내 아이폰 어플 1호. 간단한 타이머를 개발중이다. 과연 다른사람에게 구매가치가 있을까 싶지만, 일단 적어도 나에게는 필요하고, 또 만들면서 아이폰 환경에 적응하는 경험의 의미도 크다(뭐야, 자기만족뿐이잖아?).

루비같이 편한 언어로 놀다가  오브젝티브-C로 하려니 재적응해야할 것도 많고, 또 iPhone OS의 프레임워크에도 적응해야한다. 이래저래 문서 뒤져가며 하다보니, 이제나마 얼추 돌아가는 어플이 준비되어 간다. 실제로 AppStore에 등록하려고 하니, 이래저래 준비해야할 것들이 많아, 다른 시간들이 필요한데, 어제는, 홍보용 웹페이지를 어설피나마 만들다가 시간이 다갔다.

홍보용 웹페이지를 뭘로 만들까 하다가, 이번엔 Ramaze를 써보기로 했다. 늘 하던 Rails로 개발하면 빠르게 만들겠지만, 뭔가 새로운 거를 할때 조차 새로운 시도를 하지 않으면 늘 하던대로만 하게되는 아쉬움이 있는거 같아서, 시간은 조금 더 걸릴지 모르겠지만 Ramaze로 시도했다. 작은 규모의 MVC 웹애플리케이션을 위한 프레임워크라는 점은 동일하지만, 이미 Ramaze의 규모가 커져서 Camping정도 보다는 훨씬 큰 것같다. Sinatra와 Ramaze중에 뭘 쓸까 고민하다가 Ramaze를 선택했다. 몇 달전에 이 둘의 문서를 보고 한쪽이 맘에 든다는 결론을 내렸었는데, 왜 그런 결론이었는지를 잊은거 있지. 최근 이런 기억들이 가물가물해. 후후. 다음에 또 이런기회가 있으면 Sinatra도 써보기로 하고 이번엔 패쓰!

아무튼 어제는 이 Ramaze로 대충 만든 웹페이지를 호스팅 서버에 올렸는데, 로컬머신에서 띄울 때는 잘되던 다국어처리가 잘안되는 것이었다. (아! 어플은 한국어/영어/일본어 지원!) 호스팅서버는 아파치로 운영중이라 별도의 nginx나 mongrel처리 없이 아파치에서 직접 Phusion Passenger로 연결하기로 마음먹고, Rack인터페이스로 연결해서 Ramaze를 띄웠는데, 이상없이 잘 돌면서도 유독 다국어 출력부분만 원하는대로 되지 않아서 한참 소스를 들여다봤다.

결국 소스를 한참 들여다 본 끝에 원인을 찾아 해결했지만, 이런 일로 시간이 한참 흐르고 나면, 삽질을 열심히 했다는 생각을 버릴 수 없다. 한편으로는 개발이 삽질의 연속이고, 어떻게 그 삽질을 효과적으로 하고, 반복하지 않느냐의 문제인거 같기도 하지만 말이다. 이런 경험이 쌓여서 본연의 개발작업에 집중할 수 있는거고, 그것이 이번 프로젝트의 목표이기도 하고 말이다.

한가지 또 다른 작업은 애플에 유료 어플 등록을 위한 계약서 작성이 남아 있는데, 이 작업도 간단치만은 않다. 그냥 계약하고 등록하면 기본 세율인 소득금액의 30%를 미국에 내게 되는데, 한국인의 경우 10%만 내는 조건을 적용할 수 있고, 이를 위해서는 미국 IRS에서 코드를 발급받아야한다. 이걸 발급받기 위해 해당 문서를 작성하고, 팩스로 보내놓은 상태. 4~5일이면 처리된다던데, 이번 주 중에 올 것으로 기대한다.

이런 저런 동반작업들을 해나가며, 틈틈히 개발하고 있는 타이머 어플의 스크릿 샷 공개!




퇴근하고 밤시간이나, 주말에만 개발 할 수 있어서, 좀 오래걸리고 있지만, 조금씩 진행되고 있다는 점은 긍정적이다. 은근히 재미도 있고말이다.

이번주말은 설연휴까지 있으니 등록 신청할 수 있겠지. 실제 AppStore에 등록되려면 시간이 꽤 걸릴 수 있다고 하니, 어느정도 마무리 되면, 그 다음 프로젝트를 시작해야겠다.

간만에 "취미로 하는" 프로그래밍, 재밌구나.
Posted by hatemogi 트랙백 0 : 댓글 6
작년부터 마음먹었던 아이폰용 애플리케이션 개발에 박차를 가하는 중이다. 마음만 먹고 $99짜리 멤버십도 가입한 채 시간만 흐르고 있다가, 지난 주에 장난감 스러운 아이템을 하나 잡고, 열심히 개발중.

이래저래 문서 읽어가며 새로운 환경에서 개발하자니 버거울 법도 한데, 오히려 재밌다. 아주 오래전에 정말로 재밌게 개발하던 시절의 생각도 떠오르고 말이야. 너무도 간단한 애플리케이션이라 과연 팔릴까 싶지만, 일단은 열심히 개발중이다.

이 아이템을 시작으로 틈틈히 이거저거 만들어 볼 생각이다. 여기저기 기웃거리다 보니, 실제로 어플리케이션을 애플스토어에 등록하려고 시도한지 두어달만에 실제 판매가 시작되었다는 얘기도 보여서, 생각보다 간단하진 않은거 같지만, 일단은 시도해보는거다.

아이폰 기다리는 것은 포기하고, 오늘 오전에 아이팟 터치를 하나 구매했다. 이번 주말부터는 실제 Device에서 테스트해 볼 수 있을 것으로 기대한다.

그나저나, 특이한 상황 한가지. 어제 이거저거 하다보니, 아이폰 개발자 관련 아이튠즈 링크에 접속이 되지 않아서 문의 메일을 보냈다. 되지도 않은 영어로 끙끙거리며 문의 메일을 보내고, 느긋하게 기다리다보니, 오늘 답장도 왔고, 문제도 해결이 되어서 아주 만족스러웠다.

그런데, 답장메일이 한글로 오네? 한국 개발자가 많아서일까? 애플 개발자지원을 한글로 받게 될줄이야. 깜짝 놀랬다. 작년에 멤버십관련 문의메일을 보낼 때까지만 하더라도 영어지원을 받았었는데, 오늘 이렇게 한글로 답장을 받으니, 반갑기도 하고, 어렵사리 영어로 문의메일을 보낸 사실이 당황스럽기도 하네.

어쨋든 금주중에는 Ad Hoc버전으로 돌려볼 수 있기를 기대한다.


Posted by hatemogi 트랙백 0 : 댓글 4



git이라는 Revision Control System에 대한 리누스 토발즈의 테크토크.

내 경우, 회사에서는 svn을, 개인적으로는 git을 쓰고 있다. 회사에서도 git으로 이전할까 고민중. svn에서 보다 훨씬 간단하게  branch/merge작업이 가능해보인다. (git은 개인적으로 쓰는 중이라 branch떠서 해볼일이 없어서 매뉴얼만 훑어본 수준)


Posted by hatemogi 트랙백 1 : 댓글 2

티스토리 툴바