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の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
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
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ
Javaのコネクションプーリングの仕組み - ひがやすを技術ブログ
Javaのコネクションプーリングがどのような仕組みになっているのか、知らない人は結構多いんじゃないかと思います。 Slim3のコネクションプーリングの実装を見ると、この辺が理解できるようになります。トランザクションとコネクションプーリングがどのように連携しているかを把握することは重要です。 http://svn.slim3.org/browse/trunk/slim3/slim3-datasource/src/main/java/org/slim3/datasource/ 登場人物は、4人しかいないから簡単ですね。 最初に見て欲しいのは、ConnectionWrapper。DataSource.getConnection()したときに戻されるコネクションの実態です。このコネクションを論理的なコネクションと呼ぶようにします。 主な役割は、コネクションがクローズされたときに、コネクションをプー
Slim3入門 - ひがやすを技術ブログ
Slim3 Container、略してS3ContainerのDI部分は出来上がったので、機能を軽く紹介します。 まだ、サイトのデザインが決まってないので、サイト自体がないのですが、興味のある方は、https://www.slim3.org/svnのリポジトリにアクセスすることで最新のソースを見ることができます。 はしもとさん、はやくSlim3のサイトの打ち合わせをしましょう。 S3Containerを動かすには、以下のjarファイルが必要です。 slim3-commons-xxx.jar slim3-container-xxx.jar geronimo-annotation_1.0_spec-1.0.jar geronimo-ejb_3.0_spec-1.0.jar geronimo-interceptor_3.0_spec-1.0.jar javassist-3.4.ga.jar ge
Rails 2.2すげぇ - ひがやすを技術ブログ
Rails 2.2RCがリリースされました。 国際化(i18n)、スレッドセーフ化など、 うれしい機能が多数追加されているようです。 リリースノートが公開されていたので簡単に日本語訳してみました。 誤り等あればご指摘ください。 変わりすぎだろうと思うRails 2.2ですが、自分の中でもっとも大きいと思うのは、スレッドセーフのサポート。Ruby自体がスレッドセーフじゃない(スレッドセーフじゃないCのライブラリを使っているので)と思っていたけど、勘違いだったのかな。それともRailsが独自にがんばっているのか。 スレッドセーフ化の細かい内容はこちらをどうぞ。 http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html ひとつのインスタンスで、複数のリクエストを同時に処理できるとのことです。でも、グリーンスレッドだと
タイプセーフなデータベースプログラミング - ひがやすを技術ブログ
最新版のSeasar2とS2JDBC-Genによって、タイプセーフなデータベースプログラミングが可能になっています。それをHibernateと比較しながら見ていきましょう。 Hibernateの元ネタはこちら。 Hibernate 入門記 クリテリア 最初は単純なLikeを使う例。 Hibernateはこうなります。Expression.*をstaticインポートしています。 session.createCriteria(Model.class) .add(like("name.firstName", "Yu%")) .list();これまでのS2JDBCだとこんな感じ。 jdbcManager.from(Model.class) .where("name.firstName like ?", "Yu%") .getResultList()S2JDBCのタイプセーフな書き方だととこうなりま
流れるようなインターフェースをViewのように再利用 - ひがやすを技術ブログ
SELECT文の骨格は同じなんだけど、where句があったりなかったり、Pagingがあったりなかったりするなど、微妙に違うSQL文は良くでてきます。 S2JDBCを使うと、SELECT文の骨格を返すメソッドを用意することで、それをViewのように再利用することができます。例えば、次のような感じ。 protected AutoSelect createView() { return select().leftOuterJoin(dept()) .leftOuterJoin(address()); } public List findAll() { return createView().getResultList(); } public Emp findById(Integer id) { return createView().id(id).getSingleResult(); } pu
Railsバブルは終わった - ひがやすを技術ブログ
Railsバブルは終わったと思う。良い意味で。 Railsは世の中の技術者に大きな影響を与えたフレームワーク、そして偉大なフレームワークですが、バブルを起こそうと変に煽っている人たちが前から気になっていました。 最近、Railsについて何度も取り上げているのは、手放しに近い状況で「Rails良い」と煽りまくっている人が目に付くから。こういうのは、バブルにつながるし、バブルは最終的に、はじけてしまうものです。Railsバブルは、もうとめられない気もしますが、Rubyはバブルになってほしくない。 だってバブルがはじけて生き残るのはほんの一握りですよ。自分たちが原因で、失敗するならあきらめもつきますが、バブルを起こして運がよければもうけられるみたいに思っている人に散々利用されて失敗するのは、納得がいかないですね。過剰に評価されれば、それだけ失敗する案件も増えてくる。 煽られてそのプロダクトを採用
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
Seasar2系のノウハウをSpringコミュニティに提供 - ひがやすを技術ブログ
私がSlimというプロジェクトをはじめるということは、Seasarカンファレンスで発表しました。 http://itpro.nikkeibp.co.jp/article/NEWS/20080524/303949/ もともとSlimのコンテナ部分は、Seasar2からもってくるつもりでしたが、最近、NTTデータやCTCのフレームワークをやってる部隊がSpringベースのフレームワークにいろいろ悩んでいることを聞いて、Slimのコンテナは、Springベースにしたほうが、世の中のためになるんじゃないかと思い直しました。 NTTデータと真昼の対決 CTCと夜の決闘 もちろん、SpringベースでHOT deployを提供します。エイプリルフールネタを現実にやるということですね。 Super Agile Spring HOT deploy可能なSpringの上に、SAStrutsとS2JDBCを移
CTCと夜の決闘 - ひがやすを技術ブログ
昨日、CTCに「お前は最近、Railsに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、Railsを嫌っていると思っているRuby関係者は、実際多いようです。 「JavaからRubyへ」の本に対して、それはちょっとおかしいんじゃないのといったことはありますが、Railsを嫌いといったことはもちろんないはず。 呼び出されたのは、Rubyの話じゃなくて、Javaの社内フレームワークの話でした。 Struts、Spring、独自データアクセスフレームワークの生産性を何とかして改善したいという悩みでした。裏を返せば、今が低いと思っているということでしょうね。 あるいは、生産性が低いというより、大手SIerにとって必須の大規模開発をするのには、つらいということなのかもしれません。 CTCの話だと、SAStrutsを使えればいいんだけど、
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
Railsが成功しEJB3が失敗したわけ - ひがやすを技術ブログ
Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。 ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。 ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。 「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。 「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満
「日米トップJ2EEアーキテクトが語るフレームワーク」の未来のみどころ - ひがやすを技術ブログ
http://itpro.nikkeibp.co.jp/article/COLUMN/20080416/299267/ Gavin:Railsの中で使われているテクノロジー自体は，それほど新しいものではありません。オールドスタイルとさえ言える。 これは、悪い意味ではなく、テクノロジーが新しくなくても、開発スタイルが新しければ、価値のあるものを生み出すことができるということです。 Gavin:そして，（ソースコードの変更が再コンパイルすることなく即座に反映される）ホット・デプロイメントの重要さが注目されるようになった。この点に関してはJavaのバーチャル・マシン（JVM）はあまり良くなかった。そして，Javaのフレームワークもさらに悪かった。 Javaの世界では、今後ますますHOT deployが重要になってきます。Gavinも私もJVM任せではなく、フレームワークで解決しようとしているとこ
みえてきたSpringの戦略 - ひがやすを技術ブログ
ロッドジョンソンのこのエントリやHibernateの中の人のエントリをみるとSpringの戦略が大体見えてきます。 まず、Springの現状を整理すると VCから出資を受けた 教育中心のビジネスモデルでは、VCの期待するリターンを稼げない ということ、意外なのは、サポートはあまりビジネスになっていないということですね。 教育のビジネスは、長く続けるのは、実は難しいんですよ。一度教育を受けたお客様は、次の案件で引き続き同じプロダクトを使う場合でも、教育は二度は買わないから。ビジネスを継続させるためには、新規のお客様が、増え続けなければいけない。それに対して、サポートビジネスは、案件が続く間、サポートフィーを払ってもらえるし、次のプロジェクトでもきっと、サポートを買ってくれる。 教育ビジネスは、かならず人を張りつけなければいけないので、スケールしにくい。売上を増やそうと思えば、人を増やさなけれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Domain Driven Design読書会 - ひがやすを技術ブログ
