[HTML1]

コード5 – get [java] public T get(String key, String fieldName, Class entityClass, Keyspace keyspace) { T o = null; Keyspace keyspace = null; try { keyspace = getReadKeyspace(); /** ← 1： 読取用のConsistencyLevelを持つKeyspaceを取得 hoge1 hoge2 */ ColumnParent columnParent = new ColumnParent(entityClass.getSimpleName()); List columnList = new ArrayList();

Map dataColumnMap = toColumns(entityClass.newInstance()); /* ← 2： entityから、どのカラムを取得するかを抽出 */ for (String dataColumnName : dataColumnMap.keySet()){ byte[] name = dataColumnName.getBytes("UTF-8"); columnList.add(name); } SlicePredicate slicePredicate = new SlicePredicate(); slicePredicate.setColumn_names(columnList); List columns = keyspace.getSlice(key, columnParent, slicePredicate); /* ← 3： cassandraから結果を取得 */ o = (T) getByEntity(columns, entityClass, key); /* ← 4： Columnをentityに変換 */ } catch (Exception e) { Logger.getLogger(this.getClass()).error(e.getMessage(), e); } finally { releaseKeyspace(keyspace); /* ← 5： 1で取得したKeyspaceを開放 */ } return o; } [/java] コード6 – entity分解 [java] private Map toColumns(T entity) { Field[] fields = entity.getClass().getDeclaredFields(); Map columnMap = new HashMap(); for (int k = 0; k < fields.length; k++) { Object o = null; try { if (EntityUtil.isFamilyField(fields[k])) { // ↑ 1：@Familyの付いたFieldだけを処理する String familyColName = fields[k].getName(); o = fields[k].get(entity); if (!EntityUtil.hasDeclaredFields(fields[k])) { // ↑ 2：子クラスであるかどうか判定する columnMap.put(familyColName, o); // ↑ 3：子クラスでない場合、そのフィールド名と値を登録する } else { Field[] innerFields = fields[k].getType().newInstance().getClass().getDeclaredFields(); for (int i = 0; i < innerFields.length; i++) { columnMap.put(familyColName + "@" + innerFields[i].getName(), innerFields[i].get(o)); // ↑ 4：子クラスであった場合、親フィールド名@子フィールド名で登録する } } } } catch (Exception e) { Logger.getLogger(this.getClass()).error(e.getMessage(), e); } } return columnMap; } [/java]

ありえるえりあに戻ることにしました。1年間ありがとうございました。

アリエルとワークス兼務は続けます。

アリエルの大谷さんと保坂さんが書いた「パーフェクトPython」を読みました。

基本的に、この本はPythonが好きな人、あるいは好きになりたい人に向けた本だと思っています。この点で、自分は対象読者層から外れていそうです。Pythonを嫌いではないのですが、特に好きでもないからです。

Pythonの経験はゼロではない、と言った程度です。10年以上前、趣味で3ヶ月ほど使っていたのがすべてと言っていいぐらいです。当時(10年以上前なので正確にいつだか思い出せませんが)、唐突に、今更Perlでもないだろうと思ってPythonを始めました。手元のちょっとしたスクリプトを書くためです。特に書籍は読まず、Webの情報だけで書いていました。他のスクリプティング系言語(Perl、Ruby、JavaScript、Shell)は、使い始める時一応なんらかの書籍を読んでいるので、Pythonに対しては、最初からいまいち本気さが足りていなかったようです。それが原因かわかりませんが、その後、Pythonを使う機会がなくなり10年以上の月日が流れました。

書籍を読まずに書いていましたが、当時からPythonはWeb上の言語リファレンスが充実していて、見よう見まねで普通に使えていた記憶があります。高度なことはせず、簡単なことを簡単にできていた程度の話ですが。

そんな感じでPythonと距離のあるプログラマ人生でしたが、思想的には共感できる部分が多々あります。その辺の思想を再確認する意味でも、「パーフェクトPython」の第1章で紹介されている「Pythonの禅」は非常に良かったです。特に次のふたつに強く共感します。

• Explicit is better than implicit. 暗黙より明示するほうが良い
• Although practicality beats purity. ただし実用的に耐えるようにする

ただ、これはどうかなと思った部分もあります。記号への過剰な忌避です。たとえばコードの美しさの例として次のふたつのコードが提示されます。

if (obj != null && obj.make_order(2, true) == true) { ... }
より
if obj is not None and obj.make_order(2, pay_now = True): ...

前者の記号を使うコードより、後者の英単語を使うコードのほうが美しいと本書は主張します。この主張にはやや違和感があります。

そもそもこのふたつのコードは公平な比較になっていない気がするので、公平になるように前者を書き換えると次になると思います。

if (obj != null && obj.make_order(2, pay_now = True)) { ... }

記号のせいでこのコードが美しくないというのは言い過ぎだと感じます。むしろ記号を適切に活用して読みやすいと感じます。過剰な記号は可読性を落としますが、適度な記号の活用はむしろ可読性を上げると思います。こう思うのは、自分が既に普通の感覚を失っているのでしょうか。

この部分だけが「Pythonの禅」への違和感です。他は共感することばかりです。

Part2は言語仕様の説明です。著者の名前から、嘘は書いていない安心感があります。自分が嘘を書かれても分からない程度のPython知識なので大事な点です。

嘘はないと思いますが、説明不足な部分はあると感じました。たとえば、森本さんも指摘していますが、タプルの説明は気になりました。この本の説明だけだと、本の後半にでてくる、多値を返す関数のコード例を説明できないからです。

本書で一番面白く読めたのはPart4です。こう書くとPythonサポーターズに怒られるかもしれませんが、Pythonの言語仕様に特に魅力は感じません。しかし、Part4にあるような、豊富なライブラリのほうには魅力を感じました。特にグラフ(データ構造)を扱えるNetworkXはいつか使う機会があれば使いたいと思いました。また、シンプルですがsshを同時実行できてpsshも便利そうです。

3DグラフィックツールBlender、SDLを扱うpygameは、もし自分が無職で暇になったら遊びたいツールです。pygameとか、子供時代にやったN88-BASICを思い出しました。pygameのような開発環境とPythonの組み合わせは、小中学生が最初に使うプログラミング環境としてありだと思います。時代的に、JavaScriptとWebブラウザ環境も最初に試す開発環境としてありですが、いかんせん余計な落とし穴が多すぎる嫌いがあります。Pythonのほうが素直な気がします。

本書の最後はSphinxを扱います。Sphinxは最近自分のまわりでも妙に人気の高いツールです。なぜこんなに人気なのか実は分かりませんが、デファクトスタンダード感を漂わせる印象です。類似ツール(プレインテキストからHTMLや各種フォーマットへ変換するツール)はいくつもあった気がしますが、Sphinxだけが突出した印象です。出来が良かったのでしょうか。

最後に残念な点をひとつ書きます。誤植やtypoが多いです。森本さんブログで紹介されている正誤表ページがあるので、間違いを見つけたら追記すると良いと思います。自分も追加で5件書き足しました。これだけ貢献したので自分もPythonサポーターズを名乗ろうと思います。嘘です。

WEB+DB PRESS Vol.74の第一特集の「Web開発1年目に身につけたい 良い設計の基礎知識」の記事を書きました。

最初に小さな訂正です。記事中のサンプルコードでCollections.synchronizedMapを使っていますが、ConcurrentHashMapを使うべきでした。訂正が間に合いませんでした。すいません。

記事を書く上で気をつけたのが、「なんとかだから良いコードです」の「なんとか」の部分に技術用語を使わないことです。「なんとか」の部分には、たとえばオブジェクト指向や関数型プログラミングが来ます。こういう技術用語で説明した気になるのは良くないと思いますし、分かった気になるのも良いとは思えません。これらを盲目的に良いと思い込むのは単なる思考停止です。良いという実証はなく、せいぜい特定の基準の下でのベストプラクティスに過ぎないからです。コードはこう書くべき、というべき論から入るのは健全と思っていません。

と偉そうなことを言いながら、記事の後半は少し息切れしました。人によっては、記事を読んでWebアプリはMVCアーキテクチャで書くべき、と思ってしまうかもしれません。書き手の気持ちは、MVC先にありきではない、ですが、どう読まれてしまうかは、もう自分の手を離れています。「モデル」という用語が多義的なことは説明しましたが、「エンティティ」の用語の多義性を説明しなかったのは失敗しました。JPAなど一部の世界では「エンティティ」は永続化対象のオブジェクトという意味づけがあるので、それに触れなかったのは片手落ちでした。こういう多義的な用語は混乱の元です。モデルとかもはや未定義に近い気すらします。本音ではあまり使いたくないのですが、新しい用語を作り出してしまうと、それはそれで新しい混乱を生む危険があります。悩ましいところです。

アリエルで一番女性にもてると自称する岩永さんが書いた「JavaScriptテクニックバイブル ~効率的な開発に役立つ150の技」を読みました。

献本してもらったのは去年ですが、ようやく読みました。献本、ありがとうございました。

本書は副題にもあるように全部で150の項目があります。本の値段が2980円なのでひとつ当たり約20円です。お得な本だと思います。

150の項目は全11章で分類されています。以下、章ごとに軽く感想を書きます。

Chapter01 開発を取り巻く環境を改善する

Emacsやその他のエディタ(Vimとか)でJavaScript開発をする場合の便利設定など書かれています。他にもいくつか便利ツールの紹介があります。

自分は使っていませんが、IEの各種バージョンの動作チェックができるIETesterは便利そうです。

Chapter02 デバッグ手法を改善する

Firebugなどのデバッガの使い方の話です。自分はだいたい知っていたので新しい発見はありませんでした。しかし、意外にこの辺のツールの存在を知らない人もいるので、有用な情報だと思います。

個人的になるほどと思った小技は、「2-5 条件付きブレークポイントを使う」の中の「一歩進んだ使い方」で、条件付きブレークポイントの条件にconsole.debugコードを書く技です。コード中にconsole.debugを書かず、かつ実行停止もしないまま、変数の値だけ知りたい時に使えます。頭が固くて思いつきませんでした。

Chapter03 テスト環境を改善する

JavaScriptのテストツールは百花繚乱なので、情報を一定の粒度でまとめてくれた本書は参考になります。

ただ、残念ながら、本の構成上、ツール同士の関係性がわかりません。その点、現在書店に並んでいる「WEB+DB PRESS Vol.73」の「JavaScript活用最前線」が、各種テストツールの関係性を図示してまとめてくれているので必読です。本書と合わせて読んだほうが良いと思います。

この本に限りませんが、JavaScriptのテストに関して雑誌やWebで書かれた記事は、やればできます、のレベルから先に進んでいない印象です。テストコードはないよりあったほうがよいに決まっています。しかし、本当に考慮しなければいけないのは、テストコードがコストに見合うかです。JavaScriptのテストコードは黎明期なので、その辺の考慮のないまま、単なるツールの紹介で終わっているのが残念です。

Chapter04 関数を活用する

言語仕様に関する章で、特に、自分に得る部分はありませんでした。

言語仕様は、本書のような中途半端なTipsではなく、パーフェクトJavaScriptとか読んでほしいところです。

Chapter05 ネットワーク通信を改善する

こういう応用編の小ネタのほうがこの本に向いていると思います。

スクリプトの並列読み込みライブラリのLABjsとか知りませんでした。

Chapter06 タイマー・イベントを活用する

普段DOMまわりのコードを書かないので、まれにDOMまわりのコードを書こうとすると、毎回WebでDOMのイベントについて調べます。そして次の機会までにはすっかり忘れています。困ったものです。

本書を手元に置いておくと少し楽になりそうです。

Chapter07 組み込みオブジェクトを活用する

言語仕様に関する章で、特に、自分に得る部分はありませんでした。

Chapter08 パフォーマンスを改善する

もっと目から鱗みたいなテクニックを期待していましたが、期待しすぎだったかもしれません。

しかし、知らない人にとっては、YSlowの活用や、CSS SpriteやDocumentFragmentの技法の情報は有用だと思います。

Chapter09 DOMを活用する

6章に同じく、DOMの情報は自分にとっては有用です。他の人に有用かどうかは知りませんが。

Chapter10 HTML5を活用する

HTML5情報はやや食傷気味ですが、本書のような小型本だとすぐに参照できるので役に立ちそうです。

Chapter11 ライブラリを活用する

ライブラリひとつの説明に数ページの割り当てなので、内容は深くありません。内容より、本書を執筆するJavaScriptの目利きがどんなライブラリを選んだかのほうに興味があります。と言うのも、JavaScriptライブラリは群雄割拠の時代が続いているからです。

本書で選ばれたライブラリは、JSDeferred、Backbone.js、Flotr2、Gmaps、Underscore.js、jQuery、Prototype.js、Sencha Touch、Titanium、Closure Tools、Globalizeです。

選ばれない代表格で、ぱっと思いつくのは、Ext.js(Sencha Touchを取り上げているので仕方ないかも)、MooTools(マイナーすぎる?)、Yahoo! UI Library(YUI)(著者がYahoo!嫌い?)、Dojo Toolkit(著者がIBM嫌い?)、AngularJS(著者がGoogle嫌い?)、Ember.js(マイナーすぎる?)当たりです。

たぶん、選択に大きな意図はないと思いますが。

3ヶ月程ブログを書いていませんでした。雑誌記事の執筆で忙しかったためです。雑誌記事で、前編、中編と続いた「プログラミングのなぜに答える会」の後編で書こうと思っていたネタを書いてしまいました。このため、ブログでの後編掲載はなくなりました。続きは雑誌で読んでください。雑誌が出たらアナウンスします。

先月のささやかな小ネタは、IBMのWatsonがどんなプログラミング言語で書かれているか関係者に教えてもらったことです。Watsonはアメリカのクイズ番組での勝利で有名になった人工知能のようなプログラムです。言語は、名前がCで始まる言語、Pで始まる言語、Jで始まる言語の3つです。ちなみに、COBOL、PL/I、Javaをあげたら、ひとつだけ正解です。

何の脈絡もない前置きは終わりにして本題です。

アリエルの川野さん、大谷さん、稲垣さん、土江さんたちが執筆した「HTML5モバイルアプリケーションフレームワーク Sencha Touchパーフェクトガイド」(以下、Sencha Touchパーフェクトガイド)を献本してもらいました。ありがとうございます。なお、著者の並びは、「Sencha Touchパーフェクトガイド」が大谷さんの本と呼ばれるのは心外です、という川野さんの強い希望を受けて、川野さんを最初に書きました。

「Sencha Touchパーフェクトガイド」と一緒に、これまたアリエルの大谷さん、保坂さんの書いた「パーフェクトPython」も献本してもらいました。保坂さんから名前の並びについての不満を聞いていないので、年功序列で大谷さんの名前を先に書いておきます。

「パーフェクトPython」より「Sencha Touchパーフェクトガイド」のほうが気合を入れずに読めそうだったので「Sencha Touchパーフェクトガイド」から先に読みました。

なお、直近でSencha Touchを自分で使う予定はないので、読む視点が想定する読者と違うかもしれません。自分の興味はSencha Touchの細かいAPIよりも、クライアントサイドJavaScriptを保守可能なコードにするための設計の部分です。Sencha Touchの設計方針に興味がありました。

この視点で見ると、特に「7章 データパッケージ」がもっとも秀逸でした。この章は文章も非常に読みやすいです。続く「8章 リストとテンプレート」も文章は読みやすいのですが、JavaScriptによるテンプレート言語が、うーんという感じでした。正直言うと、クライアントサイドでのJavaScriptによるテンプレート言語には気持ち悪さが抜けません。自分の頭が固いだけで、初めかこういうものだと思うとありなのかもしれません。

第3部の「12章 プロジェクト開始」「13章 CRUD」「15章 Sencha Touch Charts」も面白く読めました。「14章 カスタムコンポーネント」は説明放棄が多すぎていまいちでしたが。

Sencha Touchは、クライアントJavaScriptでのMVCフレームワークを提供しています。

ここ数年、JavaScriptでのMVCが流行りなので個人的に少し調べていますが、自分の中で過剰設計にならないための線引きがまだできていません。そんな中、Sencha Touchは考えるヒントになりました。

以前、タイトルがそのものずばりの「ステートフルJavaScript ―MVCアーキテクチャに基づくWebアプリケーションの状態管理」をパラパラと眺めてみたのですが、しっくり来ませんでした。この本を読むよりは、「Sencha Touchパーフェクトガイド」のほうがしっくり来ました。

Sencha TouchのMVCフレームワークは、いわゆるプルモデル(pull model)のM(モデル)を採用しているようです。開発者次第ではプッシュモデル(push model)でも書けますが、フレームワークの思想はプルモデルなんだろうと思います。

プルモデル、プッシュモデルの用語はロッド・ジョンソン氏の「実践J2EEシステムデザイン」から拝借しました。

プッシュモデルは、モデルのオブザーバとしてビューを登録して、モデルの状態更新などの通知をビューが受け取る(pushされる)形態です。ロッド・ジョンソン氏によれば「真の」MVCでの形態です。プルモデルは、登場時、MVC2やJSP2と呼ばれていたもので、Webのサーバサイドで使われる形態です。ビューがモデルから状態などを取得(pull)します。

今ほど、Webのサーバサイドのアプリ開発が一般的になると、どちらが「真」と言ってもたいした意味を感じないので、プッシュモデルとプルモデルの用語を使います。

半年ほど前まで、プルモデルはHTTPの制約から生み出された妥協の産物で、その制約のないクライアントJavaScriptでMVCをするなら、当然、プッシュモデルなんだろうと根拠なく思っていました。

しかし、最近、そうでもないかも、と思い始めています。プルモデルは妥協の産物だったかもしれませんが、プルモデルの制約は結果として成功したような気がするからです。Sencha Touchのプルモデルを見ると、ますますその思いが強くなってきました。

Sencha Touchのモデル(Ext.data.Model)は、ほとんどデータです。ちなみに、ストア(Ext.data.store)がデータソースの抽象化です。どちらも、原則、処理をたくさん持たせる印象ではありません。

処理、Javaっぽい用語を使うとドメインロジックやビジネスロジックはどこに書くのか?、という疑問に対しては、JavaOneでのAvator Q&Aから言葉を借りると「behind REST」、つまりサーバサイドに書く、というのがHTML5を選んだSencha Touchの答えなんだろうと思います。

• Q:ビジネスロジックはクライアント(サイドのモデル)とサーバサイドのどちらに書くのが正しい?
• A:サーバサイドのサービスに書くのが正しい(behind REST)

クライアント側のモデルを、ロジックをたくさん含むドメインモデル(エンタープライズ アプリケーションアーキテクチャパターン(以下PofEAA)から言葉を拝借)にしない設計方針にしても、現実は、クライアントで書くべきロジックは残ります。「Sencha Touchパーフェクトガイド」では、このようなロジックをサービスとして切り出しています。

再びPofEAAの言葉を借りると、このロジックはアプリケーションロジックと呼ぶべき部分だと思っています。自分はマーティン・ファウラーほど頭が良くないので、ドメインロジックとアプリケーションロジックの明確な定義にしっくり来ていません。このため、アプリケーションロジックの定義は、オブジェクトにしづらいその他の処理、程度で理解しています。この程度の理解ですが、アプリケーションロジックをサービス、要は手続きとして持たせるのは実践的にうまく機能します。

総論としてSencha Touchの設計方針は、自分の中では納得感のある方針です。

最後に、「Sencha Touchパーフェクトガイド」のもうひとつ良い点は、サンプルコードが綺麗な点です。ただ一ヶ所だけ気に入らないのは332ページの次のコードです(一部だけ抜粋しています)。

getCalculator: function() {
    var me = this,
        calculator = me._calculator,
    省略
    calculator = Ext.create('Ext.ux.calc.Calculator');
    省略
    me._calculator = calculator;
    省略
}

オブジェクトのメンバ変数をローカル変数で受けて、途中でローカル変数に代入して、最後にメンバ変数に書き戻すという書き方です。記述の一貫性のほうを重視したのだと理解していますが、個人的には気持ち悪く感じます。