たかが電気、されど電気
メルマガ「週刊 Life is Beautiful」で「なぜ日本は原発を止められないのか」という連載を始めた。通信業界の東京電力に相当するNTTで働いていた経験を活かし、霞ヶ関や東電のエリートが何を考えてあんな行動に走るのかを解説する。ちょうど良いタイミングで先日の「さようなら原発１０万人集会」での坂本龍一氏の「たかが電気のためになんで命をさらさなければいけないんでしょうか」という発言が注目を集めているので、このブログでもひと言書いておく。 「たかが電気」という発言に対して「電気を止めたら死んでしまう病人がいる」「真夏にクーラーがかけられなければ、熱中症で死ぬ人がいる」と噛み付いている人がいるが、これらの指摘は大間違いである。日本は、原発を止めたぐらいで、病人の生命維持装置が止まってしまったり、熱中症で死ぬ人が増えたりする国ではない。 本当の理由は別のところにある。日本経済が重度な「原発依
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
無名関数を使った非同期通信のススメ（JavaScript）
ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の
米国空軍がPS3 2500台で380TFLOPSのスパコンを作ることにしたらしい
日本でスパコン産業支援のための予算が事業仕分けで見送りになった件については、Twitterとかでつぶやいても来たが、そろそろ「産業支援のありかた」を根本的に見直すべき時が来ていると思う。特にIT産業においては、勝負すべきレイヤーが大幅に変化している時期でもあり、過去の産業構造に捕われた支援の仕方をしても税金が無駄になるだけ。 特に今朝米国で報道された「なぜ米国空軍がPS3を2200台を追加発注したのか」という記事は、この業界の変化を顕著に表すもの。要約すると、 1. 米国空軍はさまざまなシミュレーション（空軍なので、弾道ミサイル、迎撃ミサイル、戦闘機の性能シミュレーションと考えられる）にスパコンを使って来ているが、現時点では、（IntelのチップやGPUよりも）CELLチップで構成したスパコンがもっとも現実的である。 2. ただ、CELLチップを二つ搭載したサーバー(1チップあたり200G
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
Amazon S3、何も日曜に落ちなくてもいいのに！
「不適切な画像」の投稿などのユーザーレベルでの運用上の問題はいくつか出たものの、サーバー自体はリリース後一週間の間なんの問題もなく稼働していたPhotoShare。今日は天気のよい日曜日なので、家でのんびりしようとPhotoShareで遊んでいると、朝の９時（シアトル時間）を過ぎたあたりからどうも動作がおかしくなる。サービスそのものは稼働しているようだが、画像の読み込みに失敗しているようだ。 あわてて増井君に連絡をして調べてもらうと、ユーザーから投稿してもらった写真をしまってあるAmazonのS3サーバーが落ちているという。Amazonのウェブサービスのステータスページを見ると、どうやらS3は全滅らしい。 幸いなことに、ユーザーがPhotoShareにアップした画像は、一度EC2側のアプリケーション・サーバーにキャッシュし、そこから非同期でS3に移すというアーキテクチャになっているため、S
Amazon ec2のエコノミー、月72ドルでレンタルするのと、999ドルのマシンを買うのはどちらが得か？
最近、私のまわりにもAmazonのレンタル・バーチャル・サーバーであるec2を使用している人、もしくは使用を真剣に検討している人が増えて来た。「自分でサーバーを用意するのとどっちが得か？」という話は、ビジネスにもよるのでさまざまだが、ごくシンプルな「事務所サーバー」（もしくは「マンションサーバー」）を比較対象のモデルとして簡単に損得勘定を計算してみた。 もっとも安価な Small Instance (1.7 GB of memory, 1 EC2 Compute Unit, 160 GB of instance storage, $0.10/hour）だと、一日２４時間使い続ければ月に７２０時間、つまり月に７２ドル必要となる。 同じようなマシンを事務所（もしくはマンション）に置く場合、Dellのエントリーレベルのサーバー（Dual core Pentium, 1GB memory, 160
HTML+JSでプレゼン、YAML版も作ってみた
一つ前のエントリーに対して、アップルの増井さんから「もうちょっとシンプルな『メタ言語』で良いんじゃないでしょうか。YAMLみたいなのとか。」という良いアイデアをいただいたので、早速実装。先のサンプルが、ページ内にこんな感じで直接記述できる。 ==iAnime.js: Benefits *Small footprint (<6KB compressed) *Lightweight (runs fine on iPhone) *Works well with jQuery.js and prototype.js *Free (MIT license) ==iAnime.js: Power *Easy to use (only three methods) *Powerful JSON-based animation language *Extensivle ("effects" and "pl
Life is beautiful: あるはずのない「カジノでの必勝法」が実はあったという話
ずいぶん前に「ギャンブルの心理学：攻略法と必勝法」というエントリーで、どうして「パチンコや競馬には必勝法がある」と思い込まされている人たちがなぜこれほどたくさんいるのかについての考察を書いたが、今回は本当の必勝法の話。それも実際にそれをビジネスにしている会社でしばらく働いていたMBAのクラスメートから聞いた話なので、かなり信頼できる。 ビジネスモデルは至ってシンプル。「カジノが提供するJackpot付きのスロットマシンでの＄１の投資に対する期待値が＄１以上になったところで人を送り込んでマシンを占領し、Jackpotが出るまでスロットマシンをまわし続けること」である。 「Jackpot付きのスロットマシン」とは、数台〜十数台のスロットマシンをつなぎ、それぞれのマシンからの売り上げの３〜５％をJackpotに貯めておき、最初にJackpot（特定の数字の組み合わせ）を出したスロットマシンにその
Ruby on Rails: なぜActiveRecordが必要なのか？
Railsの勉強がしばらくストップしてしまったので、今日はビデオを見てお勉強。Rails Envyの「ActiveRecord Tutorial」は長さも２５分とちょうど良いし、「ActiveRecordとはなんぞや」を具体例を交えて簡潔に教えてくれるのでとても良い勉強になる。 英語だが、冒頭の部分を乗り越えればあとはプログラミングの話なので、日本人にもそれほど難しくないはず。念のため、オープニングの部分のみ、超訳しておいた。 ActiveRecordのアイデアは、いったいどこから来たのか？ まずは"Active Record"の意味から （ActiveRecordではない点に注意） "Active Record"とは、デザイン・パターンの一つ。 どうやってデータベースにアクセスするか？ SQLにプログラムから直接アクセスする方法もあるが...ちょっと不便 データベースのテーブルをオブジェ
Life is beautiful: ソフトウェアの資産計上に関する素朴な疑問
会計の勉強をしはじめてから、今まで見過ごして来たようなことが気になるようになった私だが、最近一番気になったのが、日経エレの８月１３日号に書かれていた、Aplixの７６億円の特別損失の計上の件（参照）。要約すると、過去２年の間「ある顧客が買う予定」と言う名目で（経費としては報告せずに）資産として計上してきたソフトウェア資産を、「やっぱりすぐには売り上げにはつながらなそうだから」と一気に特別損失として計上した、というニュースである。 建物や原料のようにはっきりと形のあるものを資産として計上することは会計上もっともなことだが、自社で開発したソフトウェアやパテントのようなものを資産として計上することには非常に大きな危険がともなう。Aplixのケースのように社内で開発したソフトウェアが将来売り上げに繋がらないということはしばしばあるわけで、そんなにあやういものを資産計上されてしまっては、投資家はどの
色や大きさを後から変更できる AQUA風ボタンの作り方
二日ほど前のブックマークの人気エントリーに入っていた、「AQUA風ボタンの作り方リンク集」を見てつくづく思ったのだが、Photoshopは奥が深く、同じような効果を作り出すのに何通りも方法があるのが興味深い。そこで、今日は、Photoshopにも関わらずあえて全てをベクターデータで書くという特殊な技法（知り合いのデザイナーから教わった技法）でAQUA風ボタンを描いてみた。 まず最初に、"Rounded Rectangle Tool"で適当な大きさの角の丸い四角を書く。角の丸みは、Radiusの値で変更できるが、この場合は16pxとした。 この時自動的に作られたレイヤーをダブルクリックして、レイヤースタイルのInner Glow属性をオンにする。Blend ModeはMultiplyで、Opacityは４０％程度が適切、色は黒にする（黒にしておくと、後でメインの色を変更したときにここを変更し
Life is beautiful: リーダーシップについて思い出したこと
アメリカの人口の１２％が「貧困層」であり、そう言った人たちは日々の食事も満足に食べることの出来ない生活をしている、などの報道は、米国に住んでいると新聞やニュースでは良く見かける。しかし、中流以上の生活をしている我々にとってみれば、生活圏がほとんど重ならない彼らの生活の実態は、なかなか実感として捉えられず、単なる「統計データ」としてしか頭に入って来ない、というのが正直な所である。 しかし、今回のハリケーンで、彼らの生活の基盤がいかにもろいものか、そして、その数がものすごいものであることを、映像を通して目の当たりに見させられることになったことにショックを受けている人はとても多いはずだ。 今回のハリケーンの被害は、政府からの非難命令にも関わらず、逃げるための交通手段も持たず、逃げたところで避難先のホテル代も払うことが出来ない人達が「予想に反して」１０万人も市内に残ってしまったために大きくなってし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
映画「タイタニック２」の予告編