Got my Gameduino Working ( @gameduino )

I received my gameduino on Sunday and stacked and plugged the parts.   It's pretty easy to get the gameduino kit ready, even for me with almost no experience with assembling these kind of parts.  Mine was pre-loaded with the asteroids game.

I got one for backing the gameduino project via Kickstarter:

and here's the gameduino project page (?):


Just wish I have time to play with it today but it's time to go back to work...

Thanks James!


Tips: Multiple Python Versions with MacPorts

I wanted to try python3 with MacPorts on my macbook, but wasn't sure if I want to remove older versions yet (for GAE and such).

Anyways I searched and installed the latest one available with MacPorts.
$ port search python3
which lists python versions 3.1.2 and 3.2.  I wanted the newer one, so I did:
$ sudo port install python32
to install python 3.2 successfully.

Then I checked the version:
$ python -V
Python 2.5.4

So python still pointed to an old version.  I could type "python3.2" and run the 3.2 version (actually I've managed to use other versions like that).

Then I found a discussion on this topic:

OK, so the python_select package seems just what I wanted.
$ sudo port install python_select
$ python_select -l
gave me some output:
Available versions:
current none python26 python26-apple python27 python32
Now I tried:
$ python_select python32

which didn't work, because it modifies the macports system info...

A command that works:
$ sudo python_select python32
$ python -V
Python 3.2


Gas Shortage in Japan after Earthquake and Anxieties

It's been 5 days since huge earthquakes hit Japan.  My family and relatives live in Tohoku region.  Luckily they survived and the houses are ok.  For those who are in similar situations (who doesn't have to evacuate from their residense), there's a common anxiety growing larger and larger; they don't have enough gas to maintain their ordinary activities. 

Tohoku region is, generally speaking, a very rural area.  Most people can't commute or go buy groceries without cars.  Even most of public transportations like buses and trains (you know, in quite a few areas down there, they are not electric) need gases.  Of course grocery stores can't get items, which happens at especially small stores.  I guess in less populated areas, if this situation continues, there's going to be shortage of foods and economic activity will nearly halt.  In Tokyo too, either gas stations don't have enough supply or people are rushing into gas stations out of worries.   As in a press conference, it seems it's true that there's not enough gas for everyone to stock unnecessary amount. 

As you might already know, gas is also critical for helping those who are directly damaged in the disaster and waiting to be rescued.  To provide foods and water for evacuated people, gas is necessary.  Rescue vehicles need gas.   So for now, lack of gas affects severely damaged areas.

There's already a short term problem in effect.  In a long term, lack of gas affects those who have survived, which in turn may slow down the economy in Japan.  Everyone here needs to calm down a bit and help manage limited amounted of resource.


TopCoder Training in Shibuya, Tokyo

This month here's a series of TopCoder training lectures in Shibuya, Tokyo.   It was the first day, and there are 3 days to go (on coming Saturdays).  Luckily I could reserve a seat for myself.

The lecture series is organized by Application Planet Inc., and they are trying to double the number of "active" TopCoder members in Japan ("active" means to join competitions frequently enough... at least once in last 6 months).  They've been working on the lectures since last year (or so I've heard).

I hope there'll be more active members in Japan, and maybe better single round match schedules for members in Asia, at least once in a few months.  TopCoder single round matches are so great in that it's open to everyone, but it's virtually impossible to join one if it's held like at 11 am on a weekday..., especially if you work for a normal company (I mean, if you are a developer for certain companies, you might be able to manage to join a competition and still show up not so late for your average day...).

The lecturer is Naohiro Takahashi, a famous redcoder in Japan, who goes by "chokudai."  He's a junior student in a university and writer.   He's got so many great achievements (you can find a bunch of them if you just google it).

Lectures and labs there were great, and it's also really a good opportunity to actually be able to listen to red coders and to know they are also human :-) and (some part of ) how they've got so far.  It's mostly aimed at beginners and good for people looking for other folks who are struggling too, like me.

So I just need to practice more and more...


Google URL Shortener Fixed Now?

I don't believe it matters much anymore, so I'm writing about a bug (or maybe a feature back then) in Google URL Shortener.  As far as I tested today it's already taken care of.

In short, I think there was a chain-of-shortened-URLs bug, so to speak.  On the release day or so I read about the URL shortener and tried it to see if how it was different from other shorteners.  I liked the simple interface with some extra features like access stats and 2D matrix bar codes.  Anyways, then it occured to me if it can shorten just any URL (well, even when they are descending people still call moving staircases an escalator...).  

So an URL 'http://goo.gl/' is obviously shorter than URLs "shortened" by goo.gl.  Unexpectedly goo.gl actually lengthened the URL, with a hash code:

Then I also wondered what would goo.gl return if a shortened URL by goo.gl itself,  i.e. "goo.gl/I349", was given.  The result:
And you could repeat the process, making a chain with each time generating a different hash code... 

I'd have reported them if it was really serious problem, or I liked the way google support team responds generally.  So far as I know I don't think they are very good at communicating with users.  Maybe they just don't reply but listens well, I don't know:
my days and responses: Google Translator Toolkit

As for goo.gl I don't know what's been going on, so I can't say if it was really a bug, but to me there were lessons learned:
- Try to find test cases carefully (and never think they are complete).
- Users might help you reporting bugs if you are little more friendly :)

Common sense, but really important...


Thanks to Twitter...

Thanks to people tweeted on my last post, finally there were lots of accesses.  I figure twitter is the quickest way to notify people of such a personal blog post (as most of you already know).



Read an Interesting Article on Facebook Developers(和訳)

I enjoyed reading the article and thought people might find it interesting too... so I roughly translated the article to Japanese.


2011年1月17日 — yeeguy

Facebook社のやり方に感心している。とても個性的な環境で、同じ環境を簡単に作れるようなものではない (もしやってみたとしても、他の会社全てでうまくいくわけではないだろう)。以下に示すのは、会社でどのようにソフトウェア開発をしてリリースをしているのか、Facebook社に在籍する多くの友人と話しているうちに集まったメモだ。

また、 Facebook社の開発者主導の文化が大いに世間の詮索の的になってい、一方他の会社では開発者主導の文化が実現可能なのか、どんな方法で実現するのかという難しい問題に取り組んでいるしかしながら、Facebook社では内部のプロセスをとても慎重に選定する。新機能や内部のシステムについてFacebookのエンジニアチームはメモを公開するが、これらは大抵「どのように」ではなく「どんな」という類の記事である… そのため、外部の人間にとってはFacebookが他の会社と比較して大幅に効率的にサービスを改良し最適化しているのかが簡単にはわからない。Facebook社がどのように機能しているのかをもっと理解するための試みとして、外部の人間の立場で個人的にこれらの考察を数ヶ月の期間にわたってまとめた。情報提供者に対するプライバシーを尊重し、全ての氏名、特定の機能や製品について言及している部分は削除した。また、これらの考察をまとめてから公開するまでに6ヶ月以上も待ったので、きっとこれらのメモの内容は少し古くなってしまっている。これらのメモを公開することで、Facebook社がカオスな状況に陥らずに組織の意志決定をどのように行ってきたかをいくらかでも解明するために役立つことを期待している… Facebook社の成果、あるいはFacebook社がいかに首尾一貫して製品を提供してきたかについて反論するのは難しい。一般ユーザー(コンシューマ)を対象としている多くのインターネット企業がFacebookの例から学べると思うし、学んで欲しい。

  • 2010年7月の時点でこの会社には2000人近くの従業員がおり、およそ1100人の従業員がいた10ヶ月前よりも増えている。一年たたずにほぼスタッフが2倍!
  • 規模において上位2つのチームはエンジニアとオペレーション担当で、それぞれ400から500人のチームメンバーが所属する。これらの2チームだけで会社のおよそ50%を占める。
  • プロダクトマネージャとエンジニアの比率は大ざっぱに言うと1対7から1対10程度
  • 全てのエンジニアは4週間から6週間の「ブートキャンプ」トレーニングを経験する。このトレーニングを通してバグの修正をしたりシニア/テニュア(永任権を持つ?)エンジニアによる講義を聴いたりすることでFacebookのシステムについて学ぶ。
  • ブートキャンプを終えると、全てのエンジニアが本番環境のDBにアクセスできるようになる(「大きな権限は大きな責任を伴う」ことについての標準的な講義と「クビに値する違反事項」、例えばユーザーの個人データの公開、の明確なリストも同時に提供される)
  • [記述編集、fryfrog氏の指摘] “内部の権限を持ってすれば可能になってしまうと想像できるようなひどいことを社内の誰かが実行してしまうのを防ぐため、とても優れたセーフガードがある。サポートに連絡するような「立場に」ならざるを得ない場合、その内容が記録されるのには理由があり、しっかりとレビューされる。ここでは道を踏み外す者は許容できない。以上。”
  • エンジニアなら誰でもFacebookのコードベースの任意箇所を思い通りに変更でき、チェックインできる
  • 大いにエンジニア主導の文化である。「ここではプロダクトマネージャは基本的に役に立たない」というのはあるエンジニアによる言葉の引用。エンジニアは開発過程の途中で設計を変えたり、プロジェクトの順位を変更したり、アイデアが浮かんだらいつでも新しい機能を加えたりする。
  • 異チーム合同の月例ミーティングでは、エンジニアが進捗報告を発表する。プロダクトマーケティングやプロダクトマネジメントの人間もこれらのミーティングに参加するが、これらの人が話し過ぎると「この間のミーティングではプロダクトがおしゃべりしすぎた」などという評価がリーダーに対して返ってくる。彼らはエンジニアが公的にプロダクトを所有する状態を望んでおり、開発するものについてエンジニアがコンタクトの中心となるのを望んでいる。
  • プロジェクトに対しての人員配置は完全に自主的である。
    • プロダクトマネージャがエンジニアのグループに声をかけ、アイデアを説明し、熱心に興味持たせるよう働きかける。
    • エンジニアは、取り組むならどのアイデアが面白そうか判断する。
    • エンジニアは上司(マネージャ)に「今週はこの5つのことに取り組みたい。」と話す。
    • エンジニアマネージャはたいていエンジニアの希望をほうっておき、時には特定のタスクをまず片付けるように指示することもある。
    • エンジニアは機能全般にわたって取り仕切る --- フロントエンドのjavascript、バックエンドのデータベースコード、またそれらの間にあるもの全て。デザイナーに助けを求めたければ(人数は限られるが専属のデザイナーがいる)、デザイナーを説得してプロジェクトに参加するように興味を持たなければいけない。アーキテクトに助けを求める場合も同様。しかし一般的には、エンジニアは必要なもの全てについて自ら対応するよう期待される。
  • 機能についてのあるアイデアが実現するに値するかどうかの議論は、一般的に1週間を実装に費やしてユーザーの一部に対してテストすることで解決する。例えば、ネバダ州のユーザーのうち1%を対象とする。
  • エンジニアは一般的にインフラ、スケーラビリティや「困難な問題」に取り組みたがる --- そこに全ての名声があるから。フロントエンドのプロジェクトとユーザーインタフェースに取り組むことについてエンジニアの熱心な興味を引くのは難しい場合がある。「ここは私が作ったんだ」と特定の機能を指差したいがためにお客さんが触れるような箇所に関わる、というようなコンシューマービジネスの場合とは反対の状況である。Facebookでは、ニュースフィードのアルゴリズム、広告のターゲットを絞るアルゴリズム、memcacheの最適化などのようなバックエンドの案件はうまみが多くエンジニアが欲しがるプロジェクトだ。
  • 特定の高優先度の機能(例えばニュースフィード)に影響があるコミットはマージ前にコードレビューを受ける。 News FeedについてはZuckerberg氏が必ずどんな変更点もレビューするほど重要だが、これは例外的なケースだ。
  • [訂正、epriest氏の指摘] “全ての変更点についてコードレビューは義務となっている(つまり、一人以上のエンジニアによってレビューされる)。 この記事の言わんとしているところはZuck氏が個人的に全ての変更点を見るわけではないということだと思う。”
  • [訂正、fryfrog氏の指摘] “全ての変更点は最低1人によりレビューされ、特に招待しなかったとしてもシステムは他の誰にでも簡単に見ることができ、コードをレビューすることができる。レビューされていないコードを混入するには、意図的かつ悪意を持った行動が伴うはずだ。”
  • QAは全く存在しない。関わった仕事についてエンジニア自らがテスト、バグ修正、リリース後の運用に責任を負う。単体テストや結合テストのフレームワークは存在するが、時々利用されているのみである。
  • [訂正、fryfrogの指摘] 実際には会社にQA(チーム)が存在していることを付け加えたい。ただし、正式なQAグループではない。職場にいる、あるいはVPN経由で接続している全ての従業員は次のタイミングでリリースされる全ての変更点を含むバージョンのサイトを使っている。このバージョンは頻繁に更新され、世間のユーザーに見えるものよりも通常1〜12時間先行している。全ての従業員はどんなバグでも報告するように推奨され、これらの報告に対しては迅速に行動が起こされる。”
  • QA(品質保証)や自動ユニットテストが欠如していることの驚きについて — “多くのエンジニアはバグのないコードを書くことができる。ほとんどの会社がそれに対してのインセンティブを設けていないだけだ。QA部署があるなら、単純に彼らに任せてエラーを見つけてもらうのが簡単だ。”  [EDIT: これは主観的な意見であったということに注意してください。他の会社での標準的な開発プラクティスと対照的に述べるためにこの記述を入れました。]
  • [訂正、epriest氏の指摘] “我々はテストを自動化した。その中にはリリースが世に出る前にパスしなければいけない「push-blocking」テストも含まれる。 「ほとんどのエンジニアはバグのないコードを書くことができる」ということは我々は全く信じておらず、ビジネスの基礎とできるような妥当な考えだとも思っていない。
  • プロダクトマネージャに影響力と権力がないことの驚きについて — プロダクトマネージャは独立性と自由さを持っている。影響力を持つカギは、エンジニアリングマネージャと本当に良い関係を築くことである。ばかげたアイデアを提案しない程度に、十分な技術が必要。それはさておいても、ロードマップやバックログを作成する際に許可やレビューを受ける必要がない。”プロダクトディレクタはロードマップに載っている事ついてすら全てきちんと知ってはいない。”  プロジェクトマネージャの数は比較的少ないが、彼らは皆、社内の本当に重要で個人的に興味のある部分について責任を負っていると感じている。
  • デフォルトではコミットした全てのコードは週ごと(火曜日)のリリースパッケージに含められる
  • さらに多くの手続きを踏めば、同日に変更点をリリースすることも可能
  • 火曜日のコードリリースの条件として、その週のリリース候補に対してコードをコミットした全てのエンジニアがon-site状態であること
  • エンジニアは「コードのリリースの知らせ(roll call)」を待つためリリースが開始される前に特定のIRCチャンネルに現れる必要があり、そうしないと公に「さらされる」
  • オペレーションチームはリリースするコードを徐々に反映させることにより実行する
    • Facebookには60,000台程度のサーバーがある
    • 新しいコードのリリースには9つの concentricレベルが存在する
    • [CORRECTION thx epriest] “この9つのレベルは同心的(concentric)ではない。3つの同心的なフェーズが存在する(p1 = 内部リリース、p2 = 小規模な外部リリース、 p3 = 完全な外部リリース)。 他の6つの段階は付属的なものであり、内部ツール、ビデオアップロードホストなどである。”
    • 最小のレベルでは6サーバーだけになる。
    • 例えば、火曜日の新規リリースが6サーバーを対象に行われる(レベル1)場合、オペレーションチームはそれら6つのサーバーを監視し、正しく機能していることを次のレベルへと移行する前に確認する。
    • リリースが問題を引き起こした場合(例えば、エラーが出る、など。)には更新を停止する。問題となるチェンジセットをコミットしたエンジニアは問題の修復に専念することになる。そしてリリースはレベル1からやりなおしとなる。
    • リリースは同じレベルを繰り返し通過する場合がある:  1-2-3-修正。 1に戻る。 1-2-3-4-5-修正。1に戻る。  1-2-3-4-5-6-7-8-9。
  • オペレーションチームはよく訓練を積んでおり、大いに尊敬される存在であり、ビジネスにとても敏感だ。彼らのサーバーメトリクスは通常のエラーログ、負荷やメモリ使用統計の上を行く --- ユーザーの行動も守備範囲だ。例えば、新規のリリースによってFacebookの機能に関わるユーザーの割合が変化した場合、オペレーションチームは彼らの基準でそれを検知し、それを理由にリリースを中止して調査を行うことができる。
  • リリースの過程において、オペレーションチームはIRCベースのページングシステムを使用してFacebook、メール、IRC、メッセンジャ、SMS経由で個々のエンジニアに対して必要に応じて通知できる。おぺれーshチームに対して応答しない場合は公にさらされる。
  • コードがレベル9に達して安定している状態になったら、週ごとの更新で完了する。
  • ある機能がその週の更新に間に合わなくても、大したことではない(外部的に重要な依存関係がない限りは)--- 一般的に、ある機能は完成した段階でいつでも投入される。
  • svnでblameされたり(ソースレポジトリ上のある変更点について非難されたり)、公にさらされたり、プロジェクトを頻繁すぎるほど失敗させたりすると、エンジニアは解雇される。「とても高度な達成度が要求される文化だ。」  マネージャ(上司)は文字通り達成度の低い者たちを6ヶ月の雇用期間で振り分けて「どうもこれではうまくいかない。君はうちの文化には合わない。」と伝える。これは実際のところ、この会社のあらゆるレベルにおいて行われることであり、C(最高責任者)レベルやVP(副社長)レベルであったとしても、彼らが「超」生産的ではない場合は即刻免職となる。
  • [訂正、epriest氏の指摘]  “バグを出すことで呼び出されることはない。 リリース時に変更点を含める依頼をしているのに、そのときに念のため対応できるように待機していない(そして代わりにそれを補ってくれる人も用意していない)場合にのみ呼び出される。
  • [訂正、epriest氏の指摘] “非難されたからといって解雇はされない。 この観点から言うと我々は極度に寛容であり、シニアエンジニアのほとんどが最低1度は恐ろしいことをしでかしており、私も例外ではない。知る限りでは、このような性質の過ちを犯したことで解雇された者はいない。”
  • [訂正、fryfrog氏の指摘] “この記事に書かれているような間違いを犯したことで解雇されてしまったというような人は私も知らない。不注意でサイトをダウンさせた人達を知っている。問題を引き起こしたものが何であれ頑張って修正するし、誰でも失敗から学ぶ。個人的な意見では、公の場でさらされるのは解雇の恐れよりも格段に効果的だ。