ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
2010になって、私は感じました。ITの流れが変わった。 これからの主役は、エンタープライズではない、ソーシャル系のビジネスだと。 勘違いしないで欲しいのは、エンタープライズ系のビジネスがだめだと言っているわけではないということです。今という瞬間なら、エンタープライズ系のビジネスは重要でしょう。 しかし、儲からないし、未来はない。 これが下記のエントリにつながってきます。 SI業界からはさっさと抜けだしたほうがいい http://d.hatena.ne.jp/higayasuo/20110111/1294718077 サービスを考える人と、プログラムをする人は、求められているスキルが違うから、両方をやるのは難しいんじゃないというような、眠たいコメントもあったけど、誰もができるようなことをしてたんじゃ、それは金になりません。 誰もができないことができるから金になる。人と差別化できなければ、そ
2011年のPaaSはAmazonの独り勝ちか? - ひがやすを blog
AmazonからBeanstalkが発表されました。 http://aws.typepad.com/aws_japan/2011/01/introducing-amazon-beanstalk.html Beanstalkを間違っているけど、分かりやすく例えると制限のないAppEngineのようなものです。 GoogleからはApp Engine for Business(4Bと省略)、SalesforceからはVMforceが登場し、2011年のPaaSは、これらの技術の戦いになるでしょう。 どの技術が勝つのか予想する前に、PaaSには、二つの分野が存在することを理解しておきましょう。ソーシャル系などのスケールアウトが必要な分野とそれ以外です。 それぞれの分野で必要とされるものが違うので、分野ごとに勝者を予想する必要があります。 スケールアウトを必要としない分野で求められるのは、制限の無
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
google appengine に関してふた言 - ひがやすを技術ブログ
AppEngineでJavaとPythonどっち使ったほうがいいのかはみんな気になるよね。 根拠なしに、Javaがいいとか、Pythonがいいというのは、聞いて(読んで)くれている人に対して、ちょっと不親切。聞いている人も、自信を持って選ぶためには、その根拠をきちんと納得しておきたいでしょう。 では、どちらがいいか根拠つきで答えましょう。 AppEngine上のJavaとPythonは、生産性/パフォーマンスの違いがホトンドないので、好きな方を使うとよいでしょう。他に好きな言語があって、JavaもPythonと特に好きではないという方は、LL使いならPython、硬い言語が好きならJavaを選ぶといいでしょう。使い心地は似ているのでそれほど違和感を感じないはずです。 「AppEngine上のJavaとPythonは、生産性/パフォーマンスの違いがホトンドない」の根拠を知りたいと今あなた思い
AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ
AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000
AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って
Seasar3がやってくる - ひがやすを技術ブログ
Seasar2は、機能を枯れさせることに徹し、機能追加は行わないと宣言してから、二年以上たちます。 で、Seasar2が冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさらに開発者が離れていく。 こういうスパイラルが発生するかもしれないことについては、どう考えますか？ このような声もありました。「機能を枯れさせることに徹する」というのは、かなりの冒険でしたが、今のところ、うまく行っていると思っています。 「RubyやSeasar2、OpenPNEが“定番”に、Linux Foundationが活用動向調査」という記事も出てましたね。 http://itpro.nikkeibp.co.jp/article/NEWS/20100527/348514/ しかし、二年の間
プロが仕事で使う場合にApp Engineでどの言語を選べばいいのか - ひがやすを技術ブログ
App Engineではどの言語を使えばいいのか - yvsu pron. yasで書いたとおり、App Engineで使う言語は、素のSDKで比べるとPythonの方がJavaより断然出来がいい。 ただ、仕事で使う場合は、素のSDKで開発することはなく、何らかのフレームワークを使うことが普通です。App Engineに特化したKay frameworkやSlim3のレベルで比べるとそんなに違いはありません。 これは、単純なリクエストの処理だと、Javaの方が10倍速いが、実際に行われている処理で比べるとそんなに違いはないのと似ています。 私は、Javaを使っているので、Javaへの評価が良くなりすぎないように、意識的にJavaのデメリットを強調し、Pythonのメリットを強調していますが、実際の仕事で使うレベルにおいては、差はほとんどないということです。 んんーーーー。 たまには本音を書
App Engineではどの言語を使えばいいのか - ひがやすを技術ブログ
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
Slim3 1.0.0 Released - ひがやすを技術ブログ
Slim3 1.0.0をリリースしました。 リリースノートはこちら http://sites.google.com/site/slim3appengine/release-notes ダウンロードはこちら http://code.google.com/p/slim3/downloads/list Slim3の主な特徴は次のとおりです。 Global Transactions Faster than JDO/JPA Fast spin-up HOT reloading Type safe query 詳しくはこちらをどうぞ http://slim3.org Seasar2譲りのHOT reloadingやS2JDBC譲りのType safe queryなどもありますが、最大の特徴は、Global Transactionsを実装していること。 http://d.hatena.ne.jp/hig
Google App EngineでGlobal Transaction - ひがやすを技術ブログ
Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi
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を実行することで実現しま
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
