「日本でゼロからクラウドを生み出すムーブメントを作り出したい」（実行委員長 門林雄基氏）---“クラウドを支える技術”の開発力を競う「クラウドコンピューティングコンペティション」が2009年6月11日、Interop 2009の会場で開催された（写真1）。企業や大学・大学院の研究者、そして高校生を含む若手エンジニアが、新しいアイディアと技術力で作り上げたクラウドコンピューティングの基盤ソフトウエアを披露した。 クラウドコンピューティングコンペティションは、奈良先端科学技術大学院大学の門林雄基准教授らの呼びかけで実現したイベント。若手のエンジニアがP2P（ピア・ツー・ピア）技術や分散データ処理技術といったクラウドコンピューティングの基盤技術を開発し、その成果を競う。検証環境として、情報通信研究機構（NICT）が運用するクラスタ環境「StarBED」のコンピュータを最大1000台まで使用可能で

ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒

TEST http://d.hatena.ne.jp/devbankh/201001　モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002　モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124　簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次

以下の説明はAndroidのroot権限が取れる環境(DevPhoneやエミュレータなど)を前提に書かれています。市販のAndroid携帯など、root権限が取れない環境では、AndroidのJavaアプリ上からインストール/実行する方法を使えば実行できます。 Androidのシェルを動かす Androidのには、adb shellというコマンドでログインしてシェルを動かすことができます。（Android SDKをC:\android_sdkにインストールしたとすると）まずC:\android_sdk\tools\emulator.exeを起動しておいてから、 > C:\android_sdk\tools\adb shell # ls ls drwxr-xr-x root root 1970-01-01 00:00 var drwxrwxrwt root root 2007-11-17 0

たとえば PHP で、 if ($hoge) { ... } とか書いてあったら、 $hoge がどんな値のときに if の中身が実行されるのか即答できますか。 こういう書き方は多くの言語で可能ですが、言語によって何が真で何が偽になるのかが異なるので、それぞれまとめてみました。 C言語 C言語には bool 型が無い。 0 （int） だけが偽となり、それ以外はすべて真となる。 NULL 定数は stddef.h で以下のように ((void*)0) と定義されているため、偽値として使える。 意見が分かれそうなところですが、個人的にはNULLを偽値として使用するは好きじゃないです。 #ifndef __cplsuplus #define NULL ((void*)0) #else #define NULL __null #endif C++ C++になると bool 型が出てくる。C と同

Vimperator Firefox Addon､ﾇ､｢､�Vimperator､ﾎｲ�(ｼ遉ﾋｳｫﾈｯｻ�ﾅﾀ) ･ﾈ･ﾃ･ﾗ･ﾚ｡ｼ･ｸ･ﾚ｡ｼ･ｸｰ�ﾍ�･皈ﾐ｡ｼﾊﾔｽｸ FrontPage ｺﾇｽｪｹｹｿｷ｡ｧID:iy6zZnngrQ 2009ﾇｯ10ｷ�23ﾆ�(ｶ�) 08:20:22ﾍ昀� Tweet ･ﾗ･鬣ｰ･､･ｫﾈｯ ･ﾗ･鬣ｰ･､･�ﾍ� liberator･ｪ･ﾖ･ｸ･ｧ･ｯ･ﾈｰ�ﾍ�(version 1.2) liberator･ｪ･ﾖ･ｸ･ｧ･ｯ･ﾈｰ�ﾍ�(version 2.0) liberator.modules･ｪ･ﾖ･ｸ･ｧ･ｯ･ﾈ､ﾎｼ遉ﾊ･ﾗ･愠ﾑ･ﾆ･｣ｰ�ﾍ� ･ｽ｡ｼ･ｹｰ�ﾍｫ､鮑ｫ､ﾆ､､､ｯ｡ﾊ･ｽ｡ｼ･ｹ､ﾎｹｽﾀｮ｡ﾋ vimperator 2.0 ･ﾘ･�･ﾗﾋﾝﾌﾗ･愠ｸ･ｧ･ｯ･ﾈ ｳｰﾉ�･ｯ Vim

タイトルは釣りですが、実際にグリモンの開発効率が気持ち悪いくらいに上がりました 2009/06/02追記 動画upしました 初めてなのでいろいろ適当ですが、ご容赦を これは何？ vimの環境設定の勉強がてら、greasemonkeyの開発環境を作ってみました 環境は、Ubuntu8.0.4です できることは以下の通り コード補完 スニペットに対応 user.jsで新規ファイルを作ると、テンプレートを自動に作ってくれる コマンド一発で、firefoxにグリモンをインストール 保存時に自動的にfirefoxの今開いてるページを再読み込み まずは、vimrcと入れたプラグイン .vimrc 上記の設定とかをまとめた.vimrcは以下の通りです set encoding=utf-8 set nu syntax on "新しい行のインデントを現在行と同じにする set autoindent "インク

$var = $bool ? $foo : $bar; という書き方はよく見ますが、 if ( $bool ) { $foo = $value; } else { $bar = $value; } 実は、こういう書き方も、 $bool ? $foo : $bar = $value; こう書くこともできます。 可読性とのトレードオフを考慮して使用してください。PBP の Damian 氏は非推奨派です。 LVALUE 属性のなせる業ですね。他に substr() も左辺値に使えます。 ちなみに、この機能はビルトイン関数以外にも Attribute を使って、サブルーチンやメソッドに自分でも実装できます。 詳しくは、perldoc perlsub を lvalue で検索してみてください。 http://perldoc.jp/docs/perl/5.10.0/perlsub.pod

Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ

この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく

プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス