« 2009年7月 | トップページ | 2009年10月 »

2009年8月

2009年8月 7日 (金)

Railsで掲示板を作成

Railsの案件を受注する条件として一晩でRailsで掲示板を作ってくれと言われた。
夜の7時ぐらいに連絡があり、朝の9時10時には、仕上げてほしいと、かなりの無茶振り。
でも、せっかくなので、作ってみた。
Commentboard

12時まで、デザインで悩む。
いろいろなサイトを参考にして、上記のデザインに決定。
Rspecのテストファーストで開発をする。はっきりいって、使い捨てのシステムにテストファースト開発する意味など無かった。
ただ、癖にしとかないと、ついつい言い訳をしてテストファーストをしない体質になるのが怖かったので、時間が掛かるのを承知でテストファーストにした。

案の定、Rspec_on_railsのpostメソッドの使い方が解からず2時間ほどはまった。
モデルのフィールド、たとえばcommentモデルのbodyフィールドの場合、ブラウザからサーバに渡す形式ってcomment[body]=???の形で渡るので、同じようにpost(create,'comment[body]'=>'??? ')としてみても、サーバー側でparams[:comment]は空。試行錯誤のうち、post(create,:comment=>{:body=>'??? '})が正しいことが判明。この時点で4時近くになっていた。
コメントの投稿と閲覧ができるまでの実装は順調に進み、6時に終わった。

ただ、その時点の状態では、コメントは無限に投稿できるし、コメントの表示も今まで投稿された全部が一画面に表示される状態だった。
これだと本当に最低限すぎて実用性がまったくないのはいやだなーと思い、掲示板作成機能を追加することを画策。
そうなるとBoardモデルが必要になり、いままでのCommentモデルにBoadモデルのリファレンスを追加し、また、掲示板作成画面もどうすんのよ。って話になり、さらには、作成機能があったとしても、掲示板一覧を表示する画面も必要になるよね、やっぱり2chのように1掲示板の投稿を1000件ぐらいに制限する必要もあるよねということで、明らかに残り3時間では無理だと判明。

次に考えたのがページネーション機能。前のエントリにもあったようにJavaScriptでできるフレームワークがあるって思っても、無限に投稿されていくと日々重くなっていくのは、明らか。
素直にページを変える度にサーバにアクセスしてもいいのだが、それだとJavaScriptのフレームワークの大部分を改造する必要がある。ページングするには、全レコード数がでないといけないから、Model.find(:all).sizeみたいなこともしないといけないし、それって軽いんだっけと悩む。select_sqlだと速いのかなー。

どれも制限時間内に無理だと気づいたら、7:30を回っていて、あーこれは最低限の機能のソースを渡すしかないなと思っていたら、なにもこっちでデータをどう絞るか考えなくても、ユーザに選択させればいいじゃんと思いついた。
そこで、自分の作った家計簿の日付選択のライブラリがあることに思いあたり、思いのほか簡単に取り込めた。サーバー側も渡された日付をパースして、find時のconditionに渡すだけ。

すべて完了したのが9時過ぎ。あっという間だけど、永かった。
画面も一画面、モデル、コントローラも1個とかなりしょぼいが、一応実用できるとこまではいったんじゃないかなと思っている。

一応最近得意のgithubに挙げました。
http://github.com/takeshy/commentboard/tree/master

これで面接落ちたら、ショックでかそう。

| | コメント (0) | トラックバック (0)

2009年8月 5日 (水)

JavaScriptでソート・ページネーション対応テーブルを作る。

ページネーションをするのに、Railsではよくwill_paginateが使われるが、前回も言ったように、サーバー側でビューのロジックを書かないといけないのは好きになれない。

なので一度、データをすべてJSONで取得し、クライアント側のJavaScriptでソートやページネーションを行う対応をした。その分、初期表示が遅くなるかもしれないが、1000件ぐらいのデータだと、ものの10秒以内に表示できる。それ以上は表示しても、誰も見ないだろうから問題ないとしている。

ソースはgithubに上げました。
   git clone git://github.com/takeshy/sortable_table_with_pagination.git

  使い方
  table.jsを読み込み、下記のフォーマットでnewする。

 var tableObj = new SortableTable({id:'テーブルを表示するノードの親のID',
    data_set: テーブルデータ※後述
    block_num:1画面最大表示件数
    call_back: 画面描画後に呼び出すフック関数
   });
テーブルデータ
   { option: 出力するテーブルタグに付加する属性(style="width:52em;"など),
     header:[
      {name:'列のタイトル',sort:'ソート種別(number or normal)',width:'列幅'}
             :  ←列の数だけ上記エントリを作成
   ],
     data:[
      [行1、列1のデータ, 行1、列2のデータ,…],
                  :    ←行の数だけ上記エントリを作成
    ]
   }

(例) 本aが290円、本Bが330円,本Cが450円で1画面最大表示レコードが2件の場合

 var tableObj = new SortableTable({id:'book_div',
    data_set:{option:'class=”list”',header:
  [{name:'書籍名',sort:'normal',width:'10em'},
     {name:'金額',sort:'number',width:'6em'}],
     data:[['a','290円'],['b','330円'],['c','450円']]},
    block_num: 2,
    call_back:null
   });

イメージ
Table1_3  

| | コメント (0) | トラックバック (0)

2009年8月 4日 (火)

テンプレート・エンジンが好きになれない。

Webアプリ作成でjspやerbのようなテンプレート・エンジン使うのが好きに
なれません。
プレゼンテーションの処理がテンプレート・エンジンとJavaScriptでごっちゃ
になって複雑になりそうに感じます。
データをすべてjson形式で取ってきて、それをJavaScriptを使って画面に表示
するようにして、プレゼンテーション関連の処理はJavaScriptに統一するように
すればいいのに、と常々思っています。

長所

サーバーの負荷が減る

動的に内容が変わるHTMLではキャッシュが難しいですが、固定HTMLだと
HTMLを書き換えた時以外はキャッシュしたものを使えます。
また、プレゼンテーション周りの処理がクライアントに移る分負荷が減ります。

クライアントの自由度が増す
json形式のインターフェースがすでに用意されているので、表示をFlashに変えた
り、マッシュアップしたりする対応が簡単になります。Webサービスに対応する際
も認証を追加するぐらいで対応できます。

短所

携帯電話のようなJavaScript非対応のブラウザでは表示できない

これは、どうすることもできないですね。こういう場合はerbのような
テンプレートをガンガン使えばいいと思います。

テストが大変

ブラウザのコンポーネントを扱うJavaScriptをテストファーストで書くのは
かなり至難の業。
seleniumもありますが、あのテストを動作前に書くのはかなり効率が悪そう。

私が作ったWebアプリのWeb家計簿では、テンプレート・エンジンを使わず
データはすべてAjaxで反映しています。サーバ側の言語環境であるPythonを
習いたてだったにもかかわらず、機能的には実装しようと思ったものはすべて
実装できました。
JavaScriptが得意だったら、完全Ajaxベースにするのも、ありなのでは?

| | コメント (0) | トラックバック (0)

« 2009年7月 | トップページ | 2009年10月 »