Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
DellのAndroidケータイが意味するもの
CNet/WSJにも書かれていたが（参照）、DellがAndroidを使ったスマートフォンのリリースに向けて着々と準備を進めているらしい。 Microsoft/Intel連合がOSとチップセットという組み合わせでパソコンビジネス（ハード）への参入障壁を極端に低くし、大量の新規参入組と自然淘汰により一気にパソコンの低価格化・コモディテぃ化が進んだことは記憶に新しいと思うが、それと同じような波がようやく携帯電話の世界に押し寄せて来ている。 ここに来てはっきりと見えて来たことがいくつかある。 Androidにより参入障壁が大幅にさがり、中国・台湾・韓国などからメーカーが大量に参入してくる そういったメーカーに製造をまかせ、自分はデザインとブランドだけで勝負する企業も参戦する（Dellはだぶんここに位置することになる） スマートフォンとそれ以外の境があいまいになり、フルブラウザーを搭載するのがあた
Life is beautiful: チームとは (The Discipline of Teams)
今日紹介するのは、Harvard Business Reviewの記事の中でも特に評価の高い、Katzenbach & Smith による「The Discipline of Teams（このリンクをたどれば全テキストが原文で読める。日本語で詳しく読みたい人は右に紹介した「好業績チームの知恵」を参照）」。彼らは「単なる人の集まりはチームと呼ぶべきではない。メンバーそれぞれの力を合計した以上の力が出せる人の集まりだけをチームと呼ぶべきだ」と主張し、チームを以下のように定義する。 a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves
Life is beautiful
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業