最近、自分が作る Web アプリケーションで、日本語圏に限らず使ってもらえそうな物は最初から一応国際化(というか英語対応)して作るようにしています。国際化対応しておくと、はてブに限らず、del.icio.us や digg で取り上げられたりして、いろいろな人に使えてもらって嬉しいし海外からも adsense 収入gです。del.icio.us のトップや /popular/ からのリファラは、はてブトップ or 人気エントリーからのリファラとそんなに変わらないぐらいなのですが、digg からのアクセスはその十数倍あって驚きでした。 で、本題の国際化の方法なのですが、favicon2dots や polaroizeぐらいの小粒なアプリケーションなら、ほんの数分〜十数分作業時間を増やすだけで対応できてしまうので、その方法のご紹介を。 ruby-gettext 武藤さん作の ruby-gett
● [Rails] グランドリファクタリング 会社で1年前に凍結されたプロジェクトが再始動したのだが、この業界で1年前の技術は既に過去であることを実感した。 Rails自体の問題 (1.0 時代は機能的に貧弱。Cascaed Eager も RJS もないとか) プラグイン環境の充実 (便利なプラグインが現れ日々便利になっている) テーブル設計の問題 (7NFとか考えてると has_many 連発はありえない) 3 は個人的な問題に寄る所であるが、当時はまだ道具(Rails)的に他に選択肢がなかったのも大きい。 ● 修正項目 ということで、1年前の Rails アプリを見て手直ししたくなる項目ベスト5。 テーブル設計 権限管理 1はやはり流行りの三テーブル構造で。関係テーブルをどんどん挟んでエンティティを疎な関係に保ちたい。テーブル数は多くなるけど気にしない。というか、既に100個以上はあ
Railsbench Railsbench is a small collection of ruby and shell scripts which make measuring raw performance of rails apps a snap. All tests are run from the command prompt making performance regression testing easy. Railsbench measures the raw performance of Rails request processing, ignoring the time spent passing the request from the web server to the Rails application. In addition, a patch for t
● [Rails] DRY化チェックリスト DRYにする方がいいのはわかる。でも実際どういう手順でやるのかに関する情報は意外と見つからない。それは「重複を避ける」という人間の感覚に訴えるものだから詳細は不要、という考え方もありえるが、そのままでは余りに概念的すぎて手が動かず、どう修正するかの方向性(ヒント)さえもない状況はやはり辛い。ということで、DRY化の手順を考えてみた。まだ自分でも探り探りな叩き台なので、意見はウェルカムである。 [DRY化チェックリスト2006冬] 定義は1ヵ所で行なう 無意味を排除する 繰り返しは共通化する 規約と関連付ける 責務を疑う 言語を拡張する 最後のは、手順というより、やるとしても一番最後にやれ、ぐらいの意味で。6番目というより999番目と表記してもいい。 ● 絶対DRY感 私はプログラマは本来怠け者であり、自分が楽をするためにコンピュータを駆使する生き
jp's domain coding like crazy Constructive reasons to use Django instead of Rails Browsing around the wonderful programming.reddit.com last night, I came across a post titled Why Django kicks Ruby on Rails' collective ass. This is an interesting article, mainly because in a sense it is right, but it goes about explaining Django's benefits all wrong. First of all, Ruby on Rails ain't plural, and th
羽生さんはじめ、出席してくださった皆様、ありがとうございました。おかげさまで無事に開催できました。 今回は羽生さんがABDについてまとめてくださった資料をいただいたんですが、それを見ながらお話を聞いて、これまでの理解がそれなりに正しかったことを確認できました。ただ、実戦投入はまだ早いかもしれないという由、確かに前にちょっとだけ試した感じでは、(少なくともRailsでは)まだ難しい感はありました。ERDレッスンがちょうど良いというのも実感してます。 で、Rails界隈の人がABDに興味津津なのは何か不思議、という話を高井さんがおっしゃってたんですが、それはたぶんRailsではDB設計の部分がすっぽり抜けてるんですよね。 「DBのデザインを決めたらあとはカッコよくいけるよ」というDavidさんですが、じゃあどうやってデザインすんのよ、と。いい替えると、他の部分が楽になりすぎたので、必然、残りの
It seems a few people share the opinion that RJS can prove to be a little abstraction too far sometimes, and would rather just code in JavaScript with the occasional bit of RJS embedded in. Now they have their wish. Dan Webb has created "RJS Minus R", a Rails plugin that takes the R out of RJS. Even David Heinemeier Hansson gives it a careful thumbs up. (Found via Dr. Nic Williams)
Why invent another templating engine? In short, to be able to use standard web design tools such as WYSIWYG editors to design and lay out pages for a rails site, without giving up the power and productivity of layouts, partials, and rails helpers. As programmers, we want to be able to create rails view templates which can also be worked on by web designers with their own tools for complex graphics
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
(※ 本当はコントローラ処理の任意の箇所で render を実行できるので正確ではないが大筋で) php5 のフレームワークである Canvas(参考2)はまさにこの理想系が実装されているようだ。素晴らしい。Railsはと言うと、表中の "before_action", "after_render" に関しては既存のフィルタ機能で代用できるため、残りは中央の2つになるが、現在のRailsにおけるアクション実行を考えると、CV間に密接な関係がありユーザが介入することができないため、これら "after_action", "before_render" は同じにしても構わないだろう(*1)。 (*1) 理想的には、アクションとレンダーの間にメソッドを用意して、そこでインスタンス変数の assignment 等を行うようにすべきだと思う。(将来的に、ERb以外のビューを使う場合など)。現在のRa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く