FLATzブログ ページ 88 ｜Webシステム開発の株式会社フラッツ

Ruby on Rails のレシピ本が出るようです。

(少し詳しい紹介:Rails Recipes premieres in beta book form)

PragmaticBookshelfから引用

Rails is large, powerful, and new. How do you use it effectively? How do you harness the power? And, most important, how do you get high-quality, real-world applications written?

From the latest Ajax effects to time-saving automation tips for your development process, Rails Recipes will show you how the experts have already solved the problems you have.

(This is a beta book. The contents below are current as of February 1st. Considerably more content will be added before the book ships in its final form.)

Railsはデカくて、パワフルで新しいんです。
で、あなたは効果的に使っていますか？
Railsの力を使えていますか？
そして、Railsによるハイクオリティーな実際のアプリケーションの書き方をどうやって入手していますか？

この本では最新のAjaxエフェクトから開発時間節約のための自動化Tipsなど、達人たちがすでに使っている方法をあなたにも与えます

(この本はベータ本です。以下の目次は2006年2月1日現在のもので、最終的なものにはいくつか付け足されると思います。)

• Part I—User Interface Recipes
  o 1. Live Preview
  o 2. Live Search
  o 3. Creating a Drag-and-Drop Sortable List (extract)
  o 4. Update Multiple Page Elements With One Ajax Request
• Part II—Database Recipes
  o 5. Rails Without A Database (extract)
  o 6. Connecting to Multiple Databases
  o 7. Self-referential Many-to-Many Relationships
  o 8. Tagging (extract)
  o 9. Versioning Your ActiveRecord Models
  o 10. Convert an Existing Application to Migrations
• Part III—Controller Recipes
  o 11. Authentication
  o 12. Role-Based Authorization
• Part IV—Testing Recipes
  o 13. Creating Dynamic Test Fixtures
  o 14. Extracting Test Fixtures From Live Data
• Part V—Big Picture Recipes
  o 15. Automating Development With Your Own Generators
  o 16. Continuous Integration
  o 17. Getting Notified of Unhandled Exceptions
  o 18. Creating Your Own Rake Tasks
• Part VI—E-Mail Recipes
  o 19. Send Gracefully Degrading Rich-Content Emails
  o 20. Testing Incoming Email
  o 21. Sending Email With Attachments

久末です。

ペアプログラミング(プログラミングする際に、2人一組のペアを作って作業すること。ペアプロ)の使いどころについて。

いま、ある案件をペアプロで開発している。
この案件はRubyOnRailsを使ったはじめてのプロジェクトだ。
進めているうちに、このプロジェクトはペアプロでやっているほうが早いのではないかと思うことがいくつかあった。

ドライブ感

プログラミングをしているとき、進んでいる感じ→ドライブ感は非常に大切で、モチベーションの素になる。
一人でプログラミングする場合、

「○○の場合、△△すれば実装できる」

というポインタが頭の中に入っていて、そのポインタが指すのが内部記憶ならば、記憶から引き出し、外部ならばネットや書籍で実際に調べる。
しかし、未知の部分が多い場合、このポインタの精度が悪い、または、間違っていることが多々あり、それを調べるのに時間がかかる。また、調べている間にわき道にそれたり、スタックオーバーフロー(つまり忘れる)して、そもそもやりたかったことに戻るのに時間がかかったりする。

ペアプロはその調べる部分をパートナーにまかせながら、プログラミング担当は制限されたスコープの中で試行錯誤することができる。これにより、作業を進めることができ、ドライブ感が増す。

また、実装方法を取捨選択する際に、パートナーに相談することで意思決定をすばやくすることができる。(一人でやっていると結構悩む→ドライブ感低→萎え)

共有

知識、知恵、経験が少ない場合、ペアプロはプログラミングを同時に経験するため、知識、知恵、経験を同時に共有することができ、一人一人でやっている場合のコミュニケーションにかかるコストが下がる。

何度も経験のあるようなシステムのプログラミングならば、上述のコストは一人一人でやってもほとんどないだろうし、
ペアプロするためのコスト(ペアがいないとできない、同じ場所にいないとやりにくい、プログラム担当がガーっと書いているときに暇)が相対的に重くなるのではないだろうか。
また、通常のプロジェクトの場合、自然に、場合に応じてペアを組んで、当面の問題が解決されたら解消というケースが多く、ペアプロを完全に遂行したことは今のところ無い。
当然、定量的な評価を出せないので、「良い感じがする」以上のものにはなっていないところが微妙。

結論

チームのプログラミングの方法が同じようになされる(誰でも、誰かがかいたプログラムをほとんどコストなく途中で代わることができる状態)のであれば、ペアプロによる利益はあまりなく
難しい課題、初めての要求などに応える場合はペアプロによる問題解決のほうが時間的、精神的コストを抑えることができ、プロジェクト遂行に役に立つと思われる。

余談

私(久末)が東京コンピュータ専門学校で非常勤講師をしているときに出した課題をペアプロの場合と一人一人でやるという場合に分けたことがある。
彼らの専門はゲームプログラミングで私が教えていたのはWebプログラミング。つまり、彼らにとって未知の部分が多い課題ということになるのだが、この場合、全体的なスキルはペアプロの方が良い。ただ、デキル生徒は一人でやらせたほうが伸びる率は高いと感じた。