Sooey

2010-11-19 00:45:49 +0900

ブログSimpleBitsのDan Cederholmさんが、A Book ApartからCSS3 For Web Designersという書籍を出した。

これだけだとなんだソレという感じだけど、個人的に、

  • A Book Apart
  • SimpleBits
    • CSSを使った小粋なデザインが得意なWebデザイナー（10年くらい前からWebデザインをやっている人なら1度は見たことあるはず）

という点で結構期待している（まだ注文してません）。Zeldmanとか懐かしいねー。CSSが登場した前後のころはとにかく彼らのサイトを分解して解析したもんだ。

SimpleBitsのCederholmさんは今年になってDribbble - What are you working on?というサイトもはじめていて、これも何ヶ月か前から注目していた。サイト自体はWebデザイナー向けの作品見せ合いっこコミュニティというもので、クオリティを保つために登録はInvitationオンリーという念の入れよう。その甲斐あってか、いつ見てもインスピレーションを受けるいいデザインが勢揃いしていて蚊帳の外でも結構楽しめる。

サイト名のとおりバスケットボールをモチーフにした構成になっていて、アップロードされた画像をShots、メンバーをPlayersと呼んだり、アップロードされた画像の累計ピクセル数をフッターに「6,522,494,874 pixels dribbbled」と表示したりする遊び心がいい（でもピクセルのドリブルって何？）。他に、アップされた画像への返信として新しい画像を登録する機能もあって、これはリバウンドと呼ばれる。

インターフェース面でも、タグ一覧ではredやblueといったタグの代わりにクリッカブルなカラー・バーを表示していたり、

Dribbble Popular Tags | Flickr - Photo Sharing!

画像に付けられたタグを表示する際に、タグ付けされた数を反映して棒グラフ状に見せたり、

Dribbble Tags Bar | Flickr - Photo Sharing!

小さいけど気の利いたデザインが多くて勉強になる。ニッチなソーシャルサイトっぽいものは、こういった細かな気配りがファンベースの拡大に寄与するんだろうね。

ところで誰かDribbble Teeのまとめ買いに興味ある人いないかな。1着だけだと$22のシャツに送料が$16.71もかかるんですよ…。

2010-11-19 00:21:33 +0900

EコマースサイトのSaaSであるShopifyが、サービスをRails 3ベースにアップグレードした際の模様をブログに公開した。

曰く、Rails 3に移行したことで当然パフォーマンスも向上したが、一番の収穫は、新しいAPIによってよりクリーンなコードを書けるようになったことと、新機能の実装が迅速に行えるようになったことの2つ。

ただ、ShopifyのようにRailsをかなり早い時期から採用しているアプリケーションでは、今回のようなアップグレードはかなりの大仕事だったようだ（Shopifyコードの最初のチェックインは2004年、Rails 0.5のリリース日である）。それから6年が経ち、最初は開発者2人だったものが、今では11人がフルタイムで取り組むまでの規模になった。

現在のShopifyのコードは、

  • app/models以下のファイルが327
  • app/controllers以下のファイルが131
  • 依存するgemの数が95
  • ヘルパーモジュールは100
  • ビューは130

というサイズ。6年間での累計コミット数は約12,000だそう。

以下、とりあえず読んだところまでの要点を抜き出してみた。興味のある人は頑張って続きを読んでみて。

  • Bundler
    • Rails 3へのアップグレードよりも前から使い始めている（9ヶ月前）
    • Bundlerの導入自体は公式サイトのドキュメントに書かれた手順に従えば簡単
  • XSS
    • ビューへの出力がデフォルトでエスケープされるようになったことの影響範囲は広い
    • この作業はRails 3.0のリリースよりも数ヶ月前に着手して終えていた
    • ビューとヘルパーをRails 3向けに変更した際の作業手順
      1. 機能テストを実行して報告された問題を修正する
      2. development環境でアプリケーションを起動して、目についた問題を修正する
      3. app/helpers以下のモジュールをすべて目視でチェックして怪しい箇所を探す
      4. コードをstagingサーバーにデプロイし、発見した問題をチームでGoogleスプレッドシートで共有
      5. コードレビュー
      6. production環境にデプロイし、問題が起きないことを願う
    • 何か新たな問題が起きたときは、ackなどの検索ツールを使って他のビューやヘルパーにも同様のコードが含まれていないかを調べて修正する
  • その他
    • BundlerとXSS対応が済めば、アップグレード作業の大部分は完了
    • その他の変更作業はXSS対応と並行して進めることができる
    • Shopifyの場合、Rails 3対応ブランチへの最初のコミットは2010年2月だった

2010-11-19 00:15:10 +0900

RSpecで書いているスペック（テスト）がどうも冗長になっている気がして、いいテストのリファクタリング指針はないかなと探してみたところ、RSpecのベストプラクティスをまとめているページを2つほど見つけたのでまとめておく。

  • (My) RSpec best practices and tips | EggsOnBread

    • specify {}やit {}、subject {}といったショートカット記法を使う
    • contextを'when'や'with'で始めて、メソッドの説明には'#'を使う
      • エラーメッセージがわかりやすくなる
    • メッセージをわかりやすいものにするためにRSpecマッチャーを使う
    • 1つのitブロックには1つのExpectationだけを記述する
    • describeとcontextをふんだんに使う
    • 妥当な値、境界値、不正な値をテストする

  • My top 7 RSpec best practices | Dmytro Shteflyuk's Home

    • before :allブロックは注意して使う
      • テストデータをbefore :allブロックで生成する際は、それらがトランザクションでラップされず、テスト後もデータのロールバックが行われないことに注意
      • after :allブロックでデータの削除を明示的に行う必要がある
      • before :eachに書き換えれば実行毎にロールバックが行われるようになる
    • For each test create exactly what it needs
      • プロジェクトが大きくなるとフィクスチャにフィールドを追加するたびにテストの大半が失敗するようになるのでfactory_girlなどのライブラリを使う
    • 個々のスペックで数百レコードものデータを生成したりしない
    • モックを造り過ぎない
    • contextを使う
    • Create several test suites to speed up your workflow
    • spec_helperが何度もロードされないようにする（重複してロードされた際は警告を表示するようにする）

でも、テストコードのリファクタリングという観点でもっとも参考になったのはid:t-wadaさんの「RSpec の入門とその一歩先へ」シリーズ。

この内容ならEPUBやPDFで販売されてても買っちゃうなあ。

2010-11-17 17:43:02 +0900

ドメイン失効を防ぐためのドメイン一括管理サービスという、あまり見かけないけどニーズはありそうなRoboDomainというサービスを発見。

RoboDomain | Flickr - Photo Sharing!

ドメイン名を登録するとExpiration DateやWHOIS情報などが一覧できるようになり、更新タイミングについてはメール通知やRSS配信でキャッチするほかに、iCalやGoogleカレンダーにインポートすることもできる。ドメインのrenewやtransferを行った際の記録を残しておけば、コストを視覚化してくれたりもするみたい。まだベータ期間中なので料金は無料です。フッターの「Handcrafted in Rome, Italy.」が素敵ですね。

ドメインに限りませんが、最近は社外のいろいろなリソース・サービスを組み合わせて使うスタイルが増えているので、地域やプロバイダーといったものをまたがってリソースを集約・一覧するサービスのニーズは高まっていると思います。例えば、ソーシャルプラットフォームのアグリゲーションだとConversocialやFlowtownとかですね。理想を言えばアグリゲーションサービス側で個々のリソースの管理・操作までできると素晴らしいのですが、そこまでいかずとも、閲覧だけでも結構便利になるだろうものは多いはず（国内サービスを対象にしたアグリゲーションだと公開APIが絶望的なのがネックですが）。