아샬

아샬은...

코딩의 신(神).

코딩 도장에서 관장이라고도 불립니다.

dooing.net의 개인 블로그에 Ruby on Rails에 관한 글을 모아보려고 합니다.

• • 미투데이: http://me2day.net/ahastudio

  • 두잉: http://dooing.net/ahastudio

  • 필통: http://filltong.net/ahastudio

  • LETS: http://metawiki.net/wiki/lets2008.cgi/_be_c6_bc_a3

루비 튜토리얼

• 루비 튜토리얼 준비 페이지

• 루비 튜토리얼 페이지

경험한 것

금요일

• 1. Project Hour 1 - 자유 프로젝트 - 보드 게임 만들기

  2. 저녁 식사

  3. 언어 튜토리얼 1

  4. 스탭 회고

  5. 준비 회의

토요일

• 1. 아침 식사

  2. 언어 튜토리얼 2 - ActionScript

  3. 점심 식사

  4. 언어 튜토리얼 3 - 루비

  5. Project Hour 2 - 자유 프로젝트 - 청소년을 위한 웹 어플리케이션 - Jumping!

  6. 저녁 식사

  7. LETS - TDD, Ruby on Rails, 이성과 친하게 지내는 방법

  8. 스탭 회고

  9. 전체 공유 준비 회의

일요일

• 1. 전체 회고 (긍정 회고)

회고

배운 점

• 1. 위키 등을 활용하려면 템플릿이 중요하다. 처음 Pattern Writing을 했을 때 적절한 Template과 Sample이 없었다면 매우 어려웠을 것이다. RTD 같은 걸 준비할 때 템플릿 자체를 테스팅하자. (예를 들어, 보드 게임 만들기에서 참가자 항목이 없던 점이라던가...)

  2. 여럿이 작업할 때는 자주 묻자. 혹시 누군가 혼자 팀을 주도하고 있는지 알고 싶다면 얼마나 자주 활동 자체에 대한 질문이 있는지 보면 된다. 여럿이라면 여럿이라는 점을 장점으로 활용하도록 하자.

  3. 사람들은 누구나 가능성을 가지고 있다. 이걸 사용할 수 있도록 적절한 기회를 마련해주는 것이 중요하다.

좋았던 점

• 1. 개인적으로 목표로 했던 것과 방법들을 자유롭게 실험할 수 있었다. 내가 지향하는 바가 틀리지 않았다고 확신할 수 있었고, 좋은 성과와 함께 더 나은 방법에 대한 아이디어를 얻을 수 있었다.

아쉬운 점

• 1. 준비 과정에 낭비가 많았다. 준비 과정 자체를 애자일하게 했다면 어땠을까?

  2. 기획 단계에서 내가 "안돼"라고 말한 게 있던 것 같다. 현실적인 가능성과 무관하게 논의를 최대한 하고, 그 다음에 가능성을 타진했으면 좀 더 의욕적으로 더 많은 것을 실험할 수 있지 않았을까?

  3. 인프라의 중요성은 아무리 강조해도 부족하지 않다. 인터넷 문제부터 시작해서 구글의 뒷통수 치기까지 인프라가 흔들리는 사건이 너무 많았다. 다음부터 장소(오프라인/온라인 모두!)를 선정할 때는 주의를 기울이는 게 좋겠다.

Dear 아샬

아샬에게 하고 싶은 말을 아래에 남겨주세요. :)