37SignalsによるWebアプリ開発指南E-Book
BasecampやTa-Da Listでおなじみの37Signalsから、WEBアプリ開発に関するE-Bookが出ています。
https://gettingreal.37signals.com/toc.php
これまでPDFのダウンロード販売やったみたいですが、最近HTML版が無料で読めるようになったようです。
内容は、37Signalsで採用されているGetting Realという開発手法をわかりやすく解説したもの。基本的に「Webアプリはシンプルに、アジャイルに」という方向性で、プログラムの開発だけでなく管理やプロモーションなどWebアプリ製作のさまざまな側面に触れている。ぱらぱらとナナメ読みしてみたが、かなり参考になるところが多いし同意できる部分も多い。
冒頭だけ引用すると、
Want to build a successful web app? Then it’s time to Get Real. Getting Real is a smaller, faster, better way to build software.
* Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
* Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).
* Getting Real is staying small and being agile.
* Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
* Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
* Getting Real delivers just what customers need and eliminates anything they don’t.
良いWebアプリを作りたいなら、そろそろGet Realしたほうがいい。Getting Realはよりコンパクトでより素早いソフトウェア開発手法です。
・Getting Realの特徴は、「現実を表すもの」（表、グラフ、箱、矢印、スキーマ、ワイヤーフレームなどなど）は省き、実際の「現実のもの」を作る、ということです。
・少ないほうが、よい。少ない機能、少ないコード、少ない書類、重要でない何もかもを少なくします。（そして重要であると思い込んでいるもののほとんどは重要じゃありません。）
・規模をコンパクトに抑え、アジャイルに徹することが主眼です。
・まずインターフェースから始める。客が実際に目にする部分です。そしてそこから内側へ向けて作り込んでいくのです。こうすれば悪いコードを書く前に良いインターフェースが得られます。
・繰り返し作業で、変更のコストを下げる。とにかく立ち上げ、その後コンスタントに改善や改造を加えていく。これがWebアプリには理想的な開発方法です。
・Getting Realではまさしく客の欲しいものが提供でき、それ以外を省くことができます。
つまるところ、机上の空論を省いて現実と戦え、ということらしい。「こうなったらどう対処しよう」、「これじゃああなったらマズい」なんて事を延々と考えてるよりも実際に作ってみたほうが早いと。スケーリングについても「とりあえず考えなくてもいい」と大胆なアプローチ。
ビビりの僕としては耳が痛いところだが、スケーリングの問題をおいとくというのは大丈夫なんだろうかという当然の疑問が浮かぶ。やってみろという手法なだけにやってみなければ分からないが。
内容ではなく書き方の話だが、単刀直入でストレートな表現なのは気に入った。（字が太いし。）そして何より成功を収めているところが言うんだから説得力がある。37Signalsが出しているBackpackというコラボレーションツールは立ち上げから24時間以内に一万人もの登録者があったらしい。（このE-book内ではそのプロモーションにも言及しています。）
また熟読して面白い部分があれば追記します。
Googleのセキュリティ事故
僕は今ゼミかじというプロジェクトに参加している。
これは、全国の大学ゼミに対して簡単ホームページとグループウェアをホスティングし、さらに他のゼミとのコミュニケーションや学生が興味を持ちそうなイベントの紹介などさまざまな付加価値をつけて提供しようというプロジェクト。サービスの構想はほぼ出来上がっていて、細部を決定すれば開発に着手可能という状況だ。
改善していくため教授方にいろいろと話を聞いていると、セキュリティはどうなるんだということをよく聞かれる。ゼミ内でファイルを共有できるのは良いが、他のゼミや一般人に見せるわけに行かない機密情報も少なからずある。そういった情報はいかにして保護されるのか、と。
質問文がはっきりせず何を問われているのか一概には判断できないが、システムのハイレベルな設計について問われているのであれば、答えは「はい」だ。ハイレベルとは優れたという意味ではなく、俯瞰的なという意味だ。例えばアセンブリ言語に対してC言語がハイレベル、という意味でのハイレベルである。つまり、他の人が見られないようちゃんとエリア分けができるのか、という意味で質問されているのだとすれば。
当然、ロールや権限の組み合わせで、掲載者が意図してするものしか情報を閲覧できないようにするような設定は可能だし、システムはそのように設計する。
問題は、ローレベルな設計だ。「そんな風に設計するだろうが、本当に守られるのか？」と問われているとすると、こちらとしては「保障できないが、がんばる」としか答えようが無い。
Google様とて例外ではない。
TechCrunch のこの記事にGoogleのここ最近のセキュリティ事故がリストアップされている。
2004/7: Gmailで他人の登録情報を閲覧できてしまうセキュリティホール
2005/1: Gmailで他人のメールを読めてしまうセキュリティホール
2005/11: Gmailで他人のアカウントを完全に乗っ取れてしまうセキュリティホール
2006/3: 誤ってGoogle公式ブログを削除してしまう
2006/7: Writely で Platypus プロジェクトに関するGoogle内部文書が閲覧できてしまう
2006/10: Google公式ブログがハックされ、第三者により記事が投稿される
2006/10: Blogger APIを通じて投稿した記事が他人のブログに載るとユーザーより苦情
2006/10: Platypus を誤って公開
セキュリティに絶対はない。そこらの書籍に書かれているようなXSSやSQLインジェクションに対しては防御策を取るが、セキュリティホールとはその定義からして思いもよらぬところでポンと表れてしまうものだ。重要なのは、ホールが見つかったときどれだけすばやく、徹底した対応を取れるかだろう。
（誤ってブログを削除とかってどう考えてもセキュリティ事故じゃないけど。）
大きさ優先で表示されるCDカバーサーチ
僕はCDをパソコンに取り込むたびに、ネットでジャケット画像を探してきて同じフォルダに入れています。これまでGoogleイメージ検索で探していたんですが、最近発見したこのサービスでは大きい画像を優先して表示してくれるので便利。
DB_DataObjectをとりあえず克服
昨日、いやおとといから格闘し続けていたDB_DataObjectを使ってとりあえずアンケートページが作成できました。
長かった…
何回か無駄につまづいてしまいました。マニュアルの記述がもう少し充実していたら多くの人が助かっているに違いない。特にレコードを更新する update() の使い方はマニュアル上の記述がほぼ皆無で、行間を読むことを強いられてしまいました。
DB_DataObjectは、PostgreSQLで Sequence （Auto Increment）を利用する際、最後に挿入した行のIDをうまく取得できません。PostgreSQLの仕様では SELECT last_value() という関数がしっかり用意されているのですが、DB_DataObjectはそれを取得せずにTrueを毎回返してきます。そのため、これを最後のIDだと思って扱うと「1」とみなされ、意図した操作と食い違った結果になってしまいます。なので、ここでは DataObject の query() 関数を使って生のクエリを実行するしかありません。
もしくは、バックエンドが pgsql の場合にも正当な処理をするよう insert() をオーバーライドしてもいいかもしれません。 insert() の中身を見ていないので具体的な方法はわかりませんが。
ちなみに query() 関数もドキュメンテーションが不充分だったため、自分で var_dump しながらの試行錯誤でした。
今のところ、学び始めとはいえ単純なデータベース操作でこれまでと比べ物にならない程手間取っています。これははたして本チャンアプリでうまくいくんだろうか。