App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
App Engineのユニーク制限を正しく理解しよう - ひがやすを技術ブログ
Google App EngineではRDBMSのようなUnique Indexをサポートしていません。ユニーク制限を実現する場合は、トランザクション中でKeyを使ったgetとputを組み合わせる必要があります。 ここでは、email addressがユニークだったらそれを確定してtrueを返し、そうでない場合にはfalseを返すコードを考えます。 最初にトランザクションを使わないコードを見てみましょう。KeyFactory.createKeyの最初に引数は、kindといってテーブル名みたいなものです。 public boolean putUniqueEmailAddress(String value) { DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Key key = KeyFactory.cr
Slim3 Preview release - ひがやすを技術ブログ
Slim3の正式リリースは、来年の一月くらいになりそうですが、ドキュメントも最低限のものはそろったので、今の段階のものをPreview版として紹介しておきます。 サイトへは、http://slim3.org でアクセスしてください。 Getting Startedをやり、Slim3 Datastoreのドキュメントを読み、Online demoをみれば、Slim3のことは把握できるようになっています。 Oneline demoからソースも見れるようになっているので、動かしながらソースを確認することができます。Online demoは、IE6で見るとレイアウトが崩れていますが、これはIE6を使うなというメッセージということで。(IE7,8では未確認) Slim3は、Google App Engineに対して最適化されています。 例えば、最近、App Engineで問題になっているのは、spi
AppEngineのDatastoreの学び方 - ひがやすを技術ブログ
Google AppEngineではBigtableの上にDatastore Serviceが構築されていて、開発者は、このDatastore Serviceを利用してBigtableにアクセスすることになります。このDatastore ServiceはPython版もJava版も機能はほとんど同じです。もしかすると、全く同じものかもしれません。 GAE/Jの場合、JDOを通じて、Datastore Serviceを利用するのが推奨されていますが、実はこれが嵌りポイント。 JDOは汎用的なインターフェースなので、Datastore Serviceを理解するのには向いていません。Datastore ServiceがRDBMSのような高機能なら、JDOを通じて抽象化し、Datastore Serviceのことは知らなくても済すのもぜんぜんありなのですが、残念ながら、そうなってはいません。 Da
App Engineではどの言語を使えばいいのか - ひがやすを技術ブログ
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
Springの新しいメンテナンスポリシーでJava界の勢力図が変わる - ひがやすを技術ブログ
Springの新しいメインテナンスポリシーが発表されました。 http://www.springsource.com/node/558 それに対するTSSの反応はこちら。 http://www.theserverside.com/news/thread.tss?thread_id=50727 新しいメンテナンスポリシーがどういうものかというと、 新しいメジャーバージョンをリリース後、3ヶ月はコミュニティー(無償)バージョンをリリースする。 3ヶ月たった後のメンテナンスリリースは、エンタープライズ(有償)版のお客様だけにリリースする。 エンタープライズ版は、3年間保障する。 3ヶ月たった後に行われた修正は、次のメジャーリリースには含まれる。 というものです。メジャーバージョンとは、二つ目の数字までのリリースのこと。例えば、2.1.xの次に2.5.0がリリースされれば、メジャーバージョンのリリ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
典型的なJava屋といえるほどJavaの世界は均質ではないよ - ひがやすを技術ブログ
これが典型的なJava屋の実体ではないだろうか。与えられた仕様を覚えるだけで、JSPやStrutsやJSFに何の疑問も持たない。疑問を持たないから、本来どのような仕様がいいのかなんて考えるわけがない 「典型的」という言葉がくせものですが、典型の意味は、「代表的」、「その集団の特徴」だとすると、「典型的なJava屋は与えられたことを覚えるだけで何も疑問に思わない」というのは言いすぎだと思いますね。 いろんなタイプの人がいるもの。これが代表的な特徴だと言うのは難しい。 少なくとも、Strutsの設定ファイルがうざいと思っている人は、かなりの数いますよ。 「典型的なStruts屋は設定ファイルがうざいと思っている」という話なら、私の経験上、ほとんど当てはなります。これだけみても、「典型的なJava屋は与えられたことを覚えるだけで何も疑問に思わない」というのは、間違いなんじゃないでしょうか。 JS
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
