『技術プレゼンのための10のTIPS』
※ この記事は、Ross Mason氏（MuleSource CTO）の記事「Ten Tips for Technical Presentations」を本人の許可を得て翻訳したものです。 ----- 今日は、マルタ島で開催されたSunオープンソースデイのモーニングセッションに参加した。セッションの質には、たいへん失望した。こういったイベントには時間も金もかかっている訳で、質の悪いセッションを見せられるのは百害あって一利なしだ。今日はSunにとっても、得るものは何もなかったと思う。 私が長年にわたって集めてきたTIPSを、紹介したいと思う。このTIPSのおかげで、これまで私の技術プレゼンを聴いてくれた人によりよい体験を提供してこれたと思っている。 自分が誰なのかと、これから何をプレゼンするのかを必ず紹介すること。今日は4つのプレゼンを見たが、1人しかこれをやっていなかった。聴き手は、誰がし
『翻訳: 同期的非対称性と非同期的対称性』
gregors-ramblings-jaプロジェクトにeverpeace君が参加してくれました。彼は、「The Core Protocol」の翻訳などもやっている人です。さっそく、記事「"同期的な非対称とか非同期的な対称"って言ってごらん（Can You Say "Synchronous Asymmetry or Asynchronous Symmetry"?）」を翻訳してくれました。 SOAの世界では、非同期のメッセージングが非常に重要な役割を果たします。オブジェクト指向においても古くから「オブジェクト同士のメッセージのやり取り」こそが本質とされてきたので、SOAにおける「メッセージング」とオブジェクト指向の「メッセージのやり取り」の違いが見出せず、混乱してしまうことがあります。 私は、オブジェクト指向とSOAとはやはり本質的に異なるパラダイムだと思っていますが、そのポイントがこの記事の
『翻訳: スターバックスは2フェーズコミットを使わない』
『Enterprise Integration Patterns』の著者の1人であり現在GooglerのGregor Hohpe氏が「Gregor's Ramblings」というブログを書いていますが、著者本人から許可をいただいたので、それを翻訳するプロジェクトを始めました。 http://code.google.com/p/gregors-ramblings-ja/ Hohpe氏のブログは、EIPの著者であるだけに、EAIやSOAに関する最先端の面白いアイデアがたくさん書かれています。第一回目は、その中でももっとも有名な記事「Starbucks Does Not Use Two-Phase Commit（スターバックスは2フェーズコミットを使わない）」を翻訳しました。 この記事は、Joel Spolsky編著の書籍『The Best Software Writing I』にも選ばれた記事
『ルールエンジンの使い方』
JBoss Rulesをはじめ、Jess、ILOG JRulesなど、ルールエンジンは商用／OSSを問わずいくつか出回っている。ルールエンジンは、SOAの文脈でもよく登場する。しかし、実際のところどうやって使っていいか、なかなかイメージが湧きにくいミドルウェアでもある。 Ronald G. Rossという人が、「ビジネスルールアプローチ」という手法を以下の書籍で提唱しているのだが、その中でルールエンジンの使い方を体系的に分類しているので、参考になる。 Ronald G. Ross, Principles of the Business Rule Approach (Addison-Wesley Information Technology Series) 1. 拒否機能（Rejector）・・・ルールに違反したイベントを棄却する 2. 生成機能（Producer）・・・イベントから何かを生
『アノテーション症候群』
最近のJavaフレームワークは、アノテーションを乱用しすぎだと思う。アノテーションが大好きなプログラマも多い。 たとえば、EJB 3.0 はアノテーションでEoD（Ease of Development）を実現したと言っているし、JUnit 4 はメソッド命名規約からアノテーションベースのフレームワークに切り替えた。Google Guice はアノテーションを使ってDIコンテナを作っている。 （話題とは関係ないが、Guiceについては、シンプルだとか速いとか、そういった部分で評価されているが、他のDIコンテナに対する最大のアドバンテージは、依存性設定時の「流暢なインタフェース 」にあると思う。これは実際設計しようとすると、結構難しいらしい） こうした流れを見ていると、アノテーションを使うのが最先端のベストプラクティスのように見えてくるが、本当はそんなことないと思う。単に、Java言語でアノ
『パッケージ図とマインドマップ』
私の本『ソースコードリーディングから学ぶ Javaの設計と実装』では、Javaのソースコードを読む際にはまず「ソースコードの地図」となるパッケージ図を描いて、そのパッケージ構造を把握してから読むことを薦めている。 パッケージ図を使って依存関係まではっきり把握するのがベストなのだけれども、実際にやってみるとパッケージが膨大にあって描ききれない場合や、依存関係が複雑に入りくんでいて明確な構造を見出せないことが多い。その場合は、単にディレクトリの階層構造を表すような図を描くだけでもいいと説明している。 上記のように素っ気なく描くのもいいのだが、パッケージ構成をマインドマップを使って描いてみるのはどうだろうか、と最近ふと思った。さっそく試しに、JRubyソースコードのパッケージ構成をマインドマップで描いてみた（ツールにはFreeMindを使った）。 かなりいい。マインドマップは空間を上手に使うので
『サービスとオブジェクトの違い （SOA vs OO）』
SOAもオブジェクト指向も、ソフトウェアアーキテクチャのスタイル（様式）の1つだ。つまり、それぞれソフトウェアの構造に関するまったく異なるパラダイムを提示している。では、サービス指向における「サービス」と、オブジェクト指向における「オブジェクト」とは、どんな違いがあるのか？ その違いを思うままに挙げてみると、以下の点が思いつく。 ● オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」 ● サービスには継承・ポリモーフィズムが無いが、メッセージ交換パターンや契約・ポリシーがある ● オブジェクトは同期的、サービスは同期／非同期両対応 ● オブジェクトは構造に注目し、サービスは相互作用に注目する オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」 オブジェクトを使うには、まずオブジェクトを生成しなければならない。用の済んだオブジェ
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
