Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
アンチ防衛コード派の立場は弱い - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ずっと（いつからかは覚えてない）「防衛コードを書くな」と言い続けているのですが、これは受け入れられないことが多いですね。 まず言われることは「それじゃまったくセキュアなシステムにならない」とか「ユーザー（人間）は無謀な操作をするから」とか。そういう事とは関係ないのだけどね。 次に、しばしば責務の放棄と誤解されます。例えば、構文解析で期待してないトークンに出会うとイキナリ例外を投げて終了してしまうプログラムが実際にあったので問い質すと「檜山さんがエラーリカバリーするなと言ったから」と。ここらへんの事は、Erlangに絡めて少し話したことがあります。「Erlang実験室：武士道と云ふは死ぬ事と見付けたり」の「潔さと無責任は違う」のあたり。 実は、僕が推奨したいことは、「××を書くな」よりは「○○を書け」のほうなんです。○○の部分は、ホーア論理に基づくアサーションとか契約（コントラクト）で
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
DDDについて、だらだらと - みねこあ
ちょっと体調を崩しまして、病院にいってきたのですが（インフルエンザではない）、待ち時間が半端ないのはわかっていたので、Domain-Driven Design (DDD)を持って行きました。 Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113回この商品を含むブログ (89件) を見る MVC のネタを書いたときに、梅澤さんに WebのMVCですが、Domain-Driven Designの言葉で語れば混乱は生じないと思うんですよね。 とコメントを頂いたのですが、DDDが積読状態なので「そうですよね〜」と言えないわたしは、あ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
UMLet - Free UML Tools for fast UML diagrams
UMLet 15.1 Free UML Tool for Fast UML Diagrams UMLet is a free, open-source UML tool with a simple user interface: draw UML diagrams fast, create sequence and activity diagrams from plain text, share via exports to eps, pdf, jpg, svg, and clipboard, and develop new, custom UML elements. Find below the full-featured UMLet as stand-alone app for Windows, macOS, and Linux, or as Eclipse plugin. It is
OOエンジニアの輪！ ～ 第 42 回 黒枝 真(makotan) さんの巻 ～ | オブジェクトの広場
ＯＯエンジニアの輪！ 第 42 回 黒枝 真(makotan) さんの巻 今回のゲストは、makotan さんです。ワークステートエンジン Buri の開発などをはじめ Java のオープンソースプロジェクトの開発で知られています ■ 始めに --- 前回インタビュイーの arton さんから makotan さんをご紹介いただきました。arton さんとはどのようなつながりですか？ あの、宴会です。(笑) 20世紀ギリギリくらいの頃ですね。Seasar ( の開発 ) が始まる前後に飲み会があって、そのときに arton さんに初めて会いました。この人が arton さんなんだ、あの Ruby 邪道編を書いた人なんだ、というところから入りつつも、技術の話は一切してなかったですね。 --- じゃあ、Seasar 本関連とか Seasar プロジェクト関連とかとはちょっと違う。プライベート的
Ruby の例外クラスは分類が粗すぎる or 細かすぎる - まめめも
と思いません？ def foo(x) end foo(1, 2) #=> wrong number of arguments (2 for 1) (ArgumentError) 1.step(10, 0) { } #=> step can't be 0 (ArgumentError) a = []; a << a a.flatten #=> tried to flatten recursive array (ArgumentError) 確かにどれも Argument に関する Error ではあるんだけど *1 、全部同じ例外クラスというのは粗すぎですよね。メッセージ読めば意味はわかるからデバッグには困りませんが、ArgumentError の中の特定の例外だけ拾いたいときに困ります。 具体的には、テストです *2 。例えば foo(1, 2) で wrong number of arg
GUI Architectures
There have been many different ways to organize the code for a rich client system. Here I discuss a selection of those that I feel have been the most influential and introduce how they relate to the patterns. 18 July 2006 This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention sinc
楽々ERDレッスン 第1回：「お持ち帰りご注文用紙」編
はじめに システム構築においてデータベース設計は不可欠です。そこで多くの方がデータベースの設計技法について書籍で学んだりするのですが、なかなか身についたと感じられないことも多いのではないかと感じます。 その理由は、実務で任せられる機会というのが少ないからというのが大きなものとして挙げられます。データベース設計というのは、やはり重要な箇所ですから自然と経験のある人に任せられることが多いのが実態です。しかもデータベース設計を担当するのはプロジェクト全体の中でもごく少数だけになりますから、なかなかチャンスが巡ってきません。 しかし、それを嘆いているばかりではスキルが身につかないのも道理です。そこで身近にあるものを何でも手当たり次第にデータベース設計のネタにしてしまうことで、コツコツと地力をつけていこうというのがこのシリーズの主旨です。 合言葉は、「表組みを見たらERDを描け！」 。では、張り切っ
アルゴリズムコンテストの挑み方 - d.y.d.
17:29 08/09/30 クロスワード 暇つぶしに "Clueless Crossword" という冊子を買ってみて意外とハマっています。 クロスワードパズルなんだけど、単語のヒントの代わりに、 各マスに1～26の数字が振ってあって同じ数字のマスには同じA～Zが入るように埋めるというもの。 「母音っぽくて二連続して語尾にも出てくるのは多分 E だろう、もしかしたら O の可能性はなくもないけど」 みたいに埋めていく。 ちょっと違うけど フラッシュであった。 20:15 08/09/28 だいちのよろい そろそろ日本に戻る前に観光するぞ月間、ということにして、ウルル（エアーズロック）に行ってきました。 もっとワイルドな感じかと思ったら、完全にリゾートのリゾートによるリゾートのための地帯になってました。 まあそんなもんか。 本日は強風のため登るの禁止とのことだったので、周りから見るだけ。
極小８ビットプロセッサ: State of the Analog Electronics [最先端計量電子工(作)学]
（通称：インチキ電子工作研究所） （降格中：ＦＰＧＡで囲碁プログラムを作ってみるブログ ～まずは冗談で） （正式名称：「囲碁のプログラムは何であんなに弱いんだ！俺がサクっとFPGAでハードウエア化して２年以内に９路盤で圍棋文化研究會の岡崎正博(39)に勝つシステムを作ってやるぜ、焼酎を50升賭けるぞ！」と大口を叩いてみるブログ） 【ご注意】 弊Blogに登場する企業・人物（政治家や足し算も怪しい男を含む）・部品・回路図は大抵実在のものですが、謎電の作者の激しい冗談と偏見を含んだフィルタを通し、更に独自の芸風が加味されて書かれています。従いまして、ここに書かれてあることは個人的な意見や感想、提案、あるいは分析結果、場合によっては憶測、最悪勘違いに過ぎず、最善で正しい内容とは限りませんし、特定企業のスポンサードを受けて提灯記事を書いているわけではありません。 謎電の作者「足し算を間違うなあああ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
java.net: Automatic User Interface with OpenXava: An Evolutionary Option for GUIs
OpenCores