DHH流のルーティングで得られるメリットと、取り入れる上でのポイント - KitchHike Tech Blog
はじめに こんにちは。KitchHikeエンジニアの小川です。KitchHikeでは主にサーバーサイドを担当しています。 少し前のものですが、「DHHはどのようにRailsのコントローラを書くのか (原文)」というすばらしい記事があります。Railsのコントローラ分割の(DHH流)ベストプラクティスについて解説した記事なのですが、私はこの記事に大変感銘を受け、KitchHikeのルーティング定義にもこのプラクティスを取り入れるようになりました。 本日はこのDHH流ルーティングを取り入れることで得られるメリット、実際の routes.rb でのルーティング定義のしかたについて紹介したいと思います。 DHH流ルーティングとは？何がうれしいの？ 詳しくは元記事を是非とも読んで下さい・・・なのですが、かいつまむと、ここで示されているのはたったひとつの単純明快なルールです。 コントローラはデフォルト
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
分散システム設計のチェックリスト - ワザノバ | wazanova
http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか？その障害がゆっくりと起きたらどうか？ システムをどのようにスムーズにデグレードさせることができるか？ システムは想定以上の負荷にどう対処するようになっているか？ 大きな障害が起き
CoffeeScriptのリファクタリング - ワザノバ | wazanova
http://blog.arkency.com/2014/07/6-front-end-techniques-for-rails-developers-part-i-from-big-ball-of-mud-to-separated-concerns/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 シングルページアプリもあり、それでなくてもフロント側のコードを書く機会は増えてきてますが、コードをうまく整理して、 簡単に、もっとテストしやすいコードを書く。 クオリティを下げることなく開発スピードをあげる。 ためのノウハウの一端を開発会社のArkencyがシェアしてくれています。 シリーズの初回は、シンプルなリファクタリングのケーススタディ。 CoffeeScriptのコードが、DOM変換、イベントハン
パターン・ランゲージとUI設計 | OVERKAST ROUGHKUT
WebサイトのUI設計のアナロジーとして、建築家クリストファー・アレグザンダーのパターン・ランゲージについて考えてみたい。 ツリー構造とセミ・ラティス構造 まずはアレグザンダーの最初の気付きから。 長い年月にわたりともかく自然に出来上がった都市を＜自然都市＞、又デザイナーやプランナーによって慎重に計画された都市やその部分を＜人工都市＞と呼びます。（中略）今では多くの人々がなにか本質的なものが＜人工都市＞には欠けていると感じている。 クリストファー・アレグザンダー「都市はツリーではない」 アレグザンダーは人工都市と自然都市の差異、そして人工都市のあり方を考えた末に、引用元のタイトルでもある「都市はツリーではない」という結論に至る。そして人工都市をツリー構造として計画してしまう問題を次のように考察している。 我々がツリーを考えているときは、デザイナー、都市計画家、行政当局、開発業者だけに適合の
「設定」を設計するための資料 - Hibariya
プログラムは、なるべく何もしなくても良い感じに動いてくれるのが理想的だけど、実際には何らかのかたちでユーザの設定を必要とすることがある。 Rails を使うときは config/application.rb でタイムゾーンを指定したり、DB へ接続するための情報を config/database.yml に指定する。 Bundler の挙動を変えたければ bundle config で設定を変更する。 Gem をインストールするときに毎回指定したいオプションがあれば、~/.gemrc に追記する。 もし自分の関わるプロダクトに「設定」のAPIが必要になったとき、何を判断の基準にして設計すればいいだろう。 ちょっと近所を見渡すだけでも、「設定」のやり方には色々ありそうだ。 設定という視点から、Rubyist にとって身近なプロダクトたちを資料として眺めてみた。 (NOTE: ちょっと悩みなが
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
L'eclat des jours(2013-10-25)
_ WebMVCと設計パターン WebMVC（面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい）というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装（貧血）と最悪のDomain Model実装（鬱血 ）が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど
サバクラ両方で動く JavaScript の大規模開発を行うために
サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
なければ作る。Wassrの代わりになる「Massr」開発中 - ただのにっき(2012-09-16)
■ なければ作る。Wassrの代わりになる「Massr」開発中 先月発表になったWassr閉鎖。その後、代替サービスを探していくつものSNSを試用したもののどれもしっくりとせず、こうなったら自分たちで作るしかあるめぇよ、ということに。 とはいえ本格的なSNSが欲しいわけではない。主として鍵付きユーザで構成される我々の使い方は、端的に言えば「クローズドな掲示板」なわけで、そこにWassr風のイイネ機能がついていればよい(ただしイイネは最重要機能である)。 話がそんな流れになったので、とりあえずGitHubにリポジトリを作り(名前はMini Wassrの意味で「Massr」)、WikiでAPIやDBの設計をざっくりと書いておいたら…… なんだかんだでコードやらパッチやらドキュメントやら、あとマスコットキャラまで集まって、そこそこ動く状態に。FOSSって、多くのばあい個人プロジェクトとして始まっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: データの削除は非推奨
データベース設計徹底指南
Web API Design - 開発者が愛するインターフェイスを作る
リソースモデリングパターンの提案 #sendagayarb