AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
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
Bigtableの使い方教えます - ひがやすを技術ブログ
GAE/Jを使うのに一番戸惑うのが、データのストレージがRDBMSではなく、Bigtableなことでしょう。 JOINが使えなかったり、WHERE句でORが使えなかったり、これまで慣れ親しんでいた方法が軒並み使えません。 これらの制限は、Bigtableに限ったことではなく、KVS(Key Value Store)型のクラウド系のデータベースではみんないえることだと思います。 最初、私も戸惑ったんだけど、いろいろ触っているうちに気付きました。昔、AS400でやってたころと一緒ジャンと。AS400とは、IBMから出ているオフコン(?)ですね。今は、System iと呼ばれているようです(最新だとまた違うようですが)。 AS400のファイル(テーブル)は、キーもしくはインデックスでアクセスします。インデックス(論理ファイル)は、ある行の特定のカラムがソートされていて、物理ファイル(テーブル)へ
GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ
Slim3 for Google App Engine/Java - ひがやすを技術ブログ
Slim3をGAE/Jに対応させました。 デモサイトはこちら。 http://higayasuo.appspot.com/ ソースコードをチェックアウトしたい場合はこちら。 http://code.google.com/p/slim3/source/checkout https://slim3.googlecode.com/svn/を指定してチェックアウトできます。デモ用のプロジェクトは、slim3-demoです。 SAStrutsのチュートリアルをやったことのある人なら、デモサイトが、そっくりだということがわかるでしょう。Slim3 Struts(SAStruts相当)がGAE/Jで動くわけです。 素のStrutsだとGAEではファイルアップロードに失敗しますが、Slim3 Strutsはその辺も対応してます。 やってみて感じたのは、GAE/Jは、制限が結構厳しいので、高度なフレームワー
「勉強ができる」ということは「努力し続ける力がある」ということ - ひがやすを技術ブログ
勉強って、ほとんど頭使わないよね。 人様に言われたことを、やればいいんだから。 あんなに頭使わなくていいのに、親は小遣いくれるたし、会社も給料くれた。 親たちはそういう甘い経験をしてきたものだから、つい子供にも「勉強しろ」って言ってしまう。頭を使ったことがなかったんだね、親たちも。 勉強の意味を狭く捉え過ぎていると思うな。「勉強ができる」ということは「努力し続ける力がある」ということですよ。学生のときの勉強だけが勉強じゃない。 学生のころ勉強ができて、高学歴な人が、社会人になってぱっとしないということはあるかもしれない。その原因は明らかですよ。社会人になって勉強しなくなったから、だめになってしまったのです。 学生のときに必要な勉強と、社会人になってから必要な勉強は違う。それぞれの環境やステージによって必要とされる勉強は違うのです。 学生のころ勉強できたとしても、社会人になって勉強することを
日本IBMのリストラが始まった - ひがやすを blog
「日本で「キャリア選択援助計画」を終了させる。浮いた１億ドルの多くを日本での「Ｗｏｒｋｆｏｒｃｅ Ａｃｔｉｏｎ」（＝リストラ）に使い、日本ＩＢＭの収益構造をより競争力のあるものにする。」 かねてから噂のあったIBMのリストラですが、現実におきてるようです。これは、景気後退局面に対するすばやい対応なのでしょうか。 直接の原因は、景気かもしれませんが、根本は、アメリカ流の株主至上主義じゃないかな。株主を大切にするのはもちろん重要なんだけど、株主のため、過度に短期の数字を良くみせようとするところにあるんじゃないかと思っています。これは、IBMに限った話じゃないけどね。 米IBMは、2005年にも欧州を中心に、1万〜1万3000人のリストラをやっています。 とはいえ、会社の業績が悪い訳ではない。米IBMの第一四半期決算は、1株あたり利益、売上高とも前年を上回っている。それでも、株主のため、飽くなき
「プログラミングばか」募集 - ひがやすを技術ブログ
今日、あるインターネット証券の人と話をしてきました。前からの知り合いなんだけどね。 新しいWebのフロントシステムを作りたい できるだけ早期にリリースしたい とのことです。 早くシステムを作るためにSeasar2が有効なんじゃないかとその人は考えたようです。 また、ホワイトボードで開発者とやり取りしながら素早くシステムを作りたいというので、プログラミングファースト開発の話をしたら、非常に乗り気でぜひやってみたいとのことです。 というわけで、私と一緒にプログラミングファースト開発をやりたい方を募集します。私も4割くらいは、そのプロジェクトに参加する予定です。 フレームワークは、SAStrutsとS2JDBC。Javaでいかに素早くシステムを構築するかという先進的な試みになるはず。 開発スタートは9中 12末(早いに越したことはないけど)立ち上げ 画面は15機能くらい。バッチもあるがそれほど難
アルファギークと学生の討論会 - 速報 - ひがやすを技術ブログ
以前、IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかがという提案をしたのですが、技術評論社さんのおかげで実現できそうです。 ありがとう、技術評論社さん。 日にちは、9月上旬の土日(たぶん9/6以外)。200名くらい入る場所で検討中とのことです。興味のある方は、予定を空けておいてください。 司会は、弾さんということで交渉中。 で、肝心の討論会なんですが、アルファギーク4人くらいと学生10人くらいの討論会を2時間1セットとして、2セット計画しているそうです。時間をたっぷりとるのはいいんだけど、学生との討論会を2セットやるよりも、もう1セットは、SI業界の重鎮との討論会のほうが面白いと思うんですが、みなさんの意見をお聞かせください。 技術評論社さんの関係者は、ここを見てると思うので、ブクマにコメントしてもらえると技術評論社さんに伝わると思います。たくさん要望のある方は、直接コメント
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
Seasar2でサクサクか炎上か - ひがやすを技術ブログ
可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
2008-03-05 - ひがやすを blog - SIerが自動車産業をまねしようとするのはいい加減やめなさい
「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを
2007-10-25 - ひがやすを blog
っていうか、Hibernateにも昔からcriteriaあるよね？ http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit
2007-10-19 - ひがやすを blog
流暢なインターフェースという訳になってみたいなので、今後は、流れるようなインターフェースではなく、流暢なインターフェースという言い方に変えたいと思います。 流れるようなインターフェースにかわったようなので元に戻します。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface http://d.hatena.ne.jp/higayasuo/20071018#1192681950 ぶくまのコメントで、 http://www.objectclub.jp/community/codingstandard/ このあたりのJava規約だとチェインさせるような書き方は避けるべき、となっているとあります(うちの会社のドキュメントじゃん)が、これはいろんな人が思うことだと思うので、私の意見を書いておきます。 まず、可読性が悪くなるという話は、昨日の
2007-10-18
Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
