hagikuratakeshi's diary

I work as a Developer Programs Engineer @ Google. This is my personal blog and any views or opinions presented in this blog are solely mine, not my employers.

First impression with 8pino

I got two 8pino Arduino(s) lately and this is my first impression with them.

What is 8pino?

8pino is the world smallest Arduino, which is fully compatible with Adafruit Trinket 3.3V (8MHz).

f:id:hagikuratakeshi:20150215220729j:plain

Adafruit Trinket is also featured by its small size, but 8pino is even smaller. It's smaller than my little finger!

f:id:hagikuratakeshi:20150215221817j:plain

Start blinking an LED

As with Adafruit Trinket, 8pino has 5GPIOs. Let's start with blinking an LED. Blinking an LED (Lチカ in Japanese) worked as instructed in the top page of 8pino. (I used Mac for following)

  1. ' Connect the 8pino with my Mac through USB (A-microB type)

f:id:hagikuratakeshi:20150215230348j:plain

  1. ' Download the Mac Arduino 1.0.5 for Trinket
  2. ' Open the Arduino IDE
  3. ' Select Tools -> Board -> Adafruit Trinket 8MHz
  4. ' Select Tools -> Programmer -> USBtinyISP
  5. ' Copy the same code in the top page to the editor
int led = 1;

void setup() { 
  pinMode(led, OUTPUT); 
}

void loop() {
  digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
  delay(888); // wait for 888msec
  digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
  delay(888); // wait for 888msec
}
  1. ' Click Upload in the Arduino IDE
  2. ' Then you need to remove and insert the 8pino through the USB connector again to reset your 8pino (otherwise you will see the error message Could not find USBtiny device (0x1781/0xc9f). If you don't see the error message, you have successfully uploaded the code to your 8pino.
  3. ' Pinch the GND port and the #1 port with an LED ...

Ta-da!

f:id:hagikuratakeshi:20150215220902j:plain

Impression

Maybe at the stage of creating a prototype, you might still find it easier to use other Arduino compatible boards such as Adafruit Trinket because 8pino itself doesn't have pin headers to connect to a breadboard (of course it's possible to plug pin headers to 8pino). But it's surprisingly small than it seems, I think its tininess makes it possible to integrate Arduino into tools that were not even considered about possibilities of working with electronics.

Actually according to the interview of the creator of 8pino (Akichika Tanaka-san), the idea of creating a tiny Arduino board came from his own frustration that there were no Arduino compatible boards tiny enough to fit into a pen. (Tanaka-san was developing a pen with a built in pedometer by installing an acceleration sensor into the pen cap to record how many centimeters the pen had travelled). More interestingly, he worked (and is working) as a full time engineer for an electronics firm. He worked on 8pino as his side project!

I'd like to thank him for sharing his experience in such a way.

By the way I bought 8pino from the Japanese online hardware store, called switch science. Not sure if they ship overseas.. :) If you wanna try 8pino, stay tuned for updates from VITRO, a creative unit which Tanaka-san formed.

Google Compute Engine でUbuntuのイメージをISOから作って動かしてみる

English version, Building an Ubuntu custom image from scratch for Google Compute Engine is here.

Google Compute Engine上でUbuntuのイメージ(2014年5月時点では公式にはサポートされていない)をISOから作成して動かせたのでそのメモを残しておきます。 元々はdokkuという、HerokuのようなMini-PaaSがUbuntu上でしかインストールできないけどそれをCompute Engine上で動かしてみたかったためです。

注: この手順はFreeBSD用の似たような手順を参考にしています。 ブログポストだけでも完結できるように重複する手順もここに書いています。

Raw disk イメージを作成してUbuntuをインストールする

1. qemu の安定版をダウンロードしてローカルのワークステーション上でビルド

$ bzip2 -d <downloaded-file>
$ cd qemu-2.0.0
$ ./configure
$ make
$ make install

注: 試してないですがsudo apt-get install qemuのようにパッケージマネージャ経由でインストールしても大丈夫だと思います。

2. UbuntuのISOをダウンロード

後々の手順ではダウンロードしたファイル名は ubuntu-14.04-desktop-amd64.iso であると仮定します。

3. qemuを使用してraw diskを作成

$ qemu-img create disk.raw 10g

4. qemuVMを起動しUbuntuのISOからブート

$ qemu-system-x86_64 --enable-kvm -smp 1 -m 3750m -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd,physical_block_size=4096 -drive if=none,id=hd,file=disk.raw,cache=none -cdrom ubuntu-14.04-desktop-amd64.iso

注: qemuのゲストOSに後でsshできるようにローカルワークステーション(ホストOS)のTCP 2222番をゲストOSのTCP 22番にフォワードするようにしています。 -net user,hostfwd=tcp::2222-:22

うまくqemuインスタンスが起動できればVNCで接続できるようになるはずです: VNC server running on 127.0.0.1:5901

5. qemuVMインスタンスVNCクライアントで接続。ここの例だとクライアントとしてvncviewerを使っています

$ vncviewer -noshared -depth 16 -compresslevel 0 -quality 9 :<the last 2 digit of the port of the running VNC server>

E.g.

$ vncviewer -noshared -depth 16 -compresslevel 0 -quality 9 :1

6. Ubuntuを先ほどのISOからインストール (vncviewerのGUI経由)

f:id:hagikuratakeshi:20140510232127p:plain

GUI上の設定はデフォルトの値を設定しておきましょう。

このままvncviewer経由で以降の設定をしてもいいですが、カーネルオプションを変えたりする次のステップがやりやすいようにsshdをインストールしておきます。 sudo apt-get install ssh

Compute Engine上で起動できるように設定変更

7. Compute Engine上のイメージとしてブートできるための必須の変更をする

/etc/default/grubに以下のカーネルオプションを追加しておきます。

# to enable paravirtualization functionality.
CONFIG_KVM_GUEST=y

# to enable the paravirtualized clock.
CONFIG_KVM_CLOCK=y

# to enable paravirtualized PCI devices.
CONFIG_VIRTIO_PCI=y

# to enable access to paravirtualized disks.
CONFIG_SCSI_VIRTIO=y

# to enable access to the networking.
CONFIG_VIRTIO_NET=y

インストールしていなければPythonとsshdをインストールしておきます。

$ sudo apt-get install python
$ sudo apt-get install ssh

注: qemuVMインスタンスを立ち上げる時にポートフォワードの設定をしたのでローカルワークステーションからssh -p 2222 127.0.0.1のようにしてゲストVMsshできるはずです。

注: ここでは必須の変更しか取り上げていませんが、Compute Engineの公式ドキュメントに必須の設定に加えて、推奨される設定も記載してあるのでチェックしておくことをすすめます。

8. qemu VMをシャットダウンする

ここまでできたらqemuVMをシャットダウンします。

作成したraw diskをtar.gzでパッケージしてCompute Engineにアップロード。 (ここからまたローカルワークステーション上の手順)

9. イメージのパッケージング

以下のコマンドでtar.gzのパッケージを作成します。

$ tar -Szcf ubuntu_14.04_image.tar.gz disk.raw

10. 作成したパッケージをGoogle Cloud Storageにアップロード

Cloud StorageとCompute Engineのコマンドラインツールが必要なので、まだGoogle Cloud SDKをインストールしていなければ インストール手順にしたがってインストールしてください。

Google Cloud Storage上にバケットを作成します。

$ gsutil mb gs://<bucket-name>

作成したバケットにパッケージをアップロードします。

$ gsutil cp ubuntu_14.04_image.tar.gz gs://<bucket-name>

11. Cloud StorageにアップロードしたパッケージをCompute Engineのイメージとして登録

$ gcutil addimage ubuntu-14 gs://<bucket-name>/ubuntu_14.04_image.tar.gz

12. 先ほど登録したイメージからインスタンスを作成

$ gcutil addinstance ubuntu-14 --image=ubuntu-14 --zone=asia-east1-a --machine_type=n1-standard-1

13. 起動したインスタンスSSH接続

$ gcutil ssh --ssh_user=<Created-user-in-the-qemu-guest-image>  ubuntu-14

問題なければssh接続できるようになっているはずです。

$ gcutil ssh --ssh_user=thagikura ubuntu-14
INFO: Zone for ubuntu-14 detected as asia-east1-a.
INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sat May 10 13:31:42 2014 from xx.xxx.xx.xxx

thagikura@ubuntu-14:~$ uname -a
Linux ubuntu-14.c.gcp-samples.internal 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Building an Ubuntu custom image from scratch for Google Compute Engine

This is a memorandum that I got running an Ubuntu image to work on Google Compute Engine (as of May 2014 which isn't officially supported). The original motivation was that I wanted to run dokku that requires Ubuntu 14.04 x64 or 12.04 x64.

Note: These steps very much refer the instructions on the similar ones for FreeBSD. For simplicity, I'm logging the steps that are covered by that post as well.

Create a raw disk image and install Ubuntu

1. Download and build the stable version of qemu in your local workstation.

Extract the downloaded package.

$ bzip2 -d <downloaded-file>
$ cd qemu-2.0.0
$ ./configure
$ make
$ make install

Note: Haven't tried it yet, it should be working fine if installed via a packaging manager such as apt-get install qemu.

2. Download the ISO for the Ubuntu.

Assuming the downloaded file name is ubuntu-14.04-desktop-amd64.iso

3. Create a qemu disk image as a raw disk.

$ qemu-img create disk.raw 10g

4. Launch a qemu VM and boot from the Ubuntu ISO

$ qemu-system-x86_64 --enable-kvm -smp 1 -m 3750m -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd,physical_block_size=4096 -drive if=none,id=hd,file=disk.raw,cache=none -cdrom ubuntu-14.04-desktop-amd64.iso

Note: To ssh to the guest os later, forwarding the 2222 port to the 22 port of the guest os by specifying -net user,hostfwd=tcp::2222-:22

If succeeded you should get a VNC server running like this: VNC server running on 127.0.0.1:5901

5. Connect to the VNC server. The below illustrates the vncviewer as a client

$ vncviewer -noshared -depth 16 -compresslevel 0 -quality 9 :<the last 2 digit of the port of the running VNC server>

E.g.

$ vncviewer -noshared -depth 16 -compresslevel 0 -quality 9 :1

6. Install Ubuntu from the ISO image (through vncviewer).

f:id:hagikuratakeshi:20140510232127p:plain

Selecting the default values should work here.

After installing the OS image, install the sshd package sudo apt-get install ssh

Change configurations to boot the image on Compute Engine.

7. Change required configurations.

Add following kernel options to /etc/default/grub

# to enable paravirtualization functionality.
CONFIG_KVM_GUEST=y

# to enable the paravirtualized clock.
CONFIG_KVM_CLOCK=y

# to enable paravirtualized PCI devices.
CONFIG_VIRTIO_PCI=y

# to enable access to paravirtualized disks.
CONFIG_SCSI_VIRTIO=y

# to enable access to the networking.
CONFIG_VIRTIO_NET=y

Install python and sshd (it you haven't)

$ sudo apt-get install python
$ sudo apt-get install ssh

Note: You can ssh to the guest os by something like ssh -p 2222 127.0.0.1 (as you specified the hostfwd-tcp::2222-:22 option)

Note: As in this official Compute Engine document, there are some recommended configurations as well. I'm not taking these instructions here, but it's highly recommended to go through the document

8. Shut down the qemu VM instance

After editing configurations, shutdown the qemu instance.

Package the image and upload it as a Compute Engine image. (From your local workstation again)

9. Package the image

Package the image as follows:

$ tar -Szcf ubuntu_14.04_image.tar.gz disk.raw

10. Upload the package to Google Cloud Storage

If Google Cloud SDK is not installed, install the SDK as in this document

Create a bucket in the Google Cloud Storage

$ gsutil mb gs://<bucket-name>

Upload the image to the bucket

$ gsutil cp ubuntu_14.04_image.tar.gz gs://<bucket-name>

11. Add the uploaded image as a Google Compute Engine image

$ gcutil addimage ubuntu-14 gs://<bucket-name>/ubuntu_14.04_image.tar.gz

12. Create an instance from the uploaded image.

$ gcutil addinstance ubuntu-14 --image=ubuntu-14 --zone=asia-east1-a --machine_type=n1-standard-1

13. SSH to the instance

$ gcutil ssh --ssh_user=<Created-user-in-the-qemu-guest-image>  ubuntu-14

If everything goes fine, you should be able to login to the instance.

$ gcutil ssh --ssh_user=thagikura ubuntu-14
INFO: Zone for ubuntu-14 detected as asia-east1-a.
INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sat May 10 13:31:42 2014 from xx.xxx.xx.xxx
thagikura@ubuntu-14:~$
thagikura@ubuntu-14:~$ uname -a
Linux ubuntu-14.c.gcp-samples.internal 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Sonar が失敗した原因についての検討

最近 Sonar という物理的に近くにいる人とのコミュニケーションをはかりやすくすることで人のコネクションを作っていくモバイルアプリケーションがあったことを知りました。 日本では流行っていた声は聞きませんでしたが、栄光と失敗を経験したスタートアップの一つとして考えられているようです。 創業者のBrett Martin が Postmortem を発表していて興味を持ったので本人にも連絡して翻訳してみました。

この記事はPostmortem of a Venture-backed Startupを Hagikura が翻訳したものです。正確な表現は原文を参照してください

*1 2014/1/30 @ さんにご指摘いただき Jack Welch の引用文を修正しました

以下翻訳

Sonar を知らない人達のために少し説明しておこうと思います。Sonar とは近くにいる人とのつながりを持ちやすくすることであなたの周りの世界を少し良いものにするAmbient Social Networking(訳者注:周りの人、ものを活用したソーシャルネットワーキング。以下同じ単語は原文使用)の先駆けとなったモバイルアプリケーション でした。

何百万人ものユーザにダウンロードされ、AppleGoogle から100ヶ国以上でプロモーションされ、TechCrunch Disrupt や Ad:Tech Best Mobile Startup など数多くの賞を受賞し、著名な投資家やベンチャーキャピタルから200万ドル以上の投資を受け、300を超える New York Times, CNN、CNBC、TechCrunch、TIMEなどのメディアで紹介されました。

ただ私達は失敗しました。

私達は Sonar でたくさんの正しいこと、間違ったことをしました。そこから学んだいくつかのことをここで紹介したいと思います。

プロダクト、市場に対しての方向性について

“人々が望むものを作りなさい” —Paul Graham

ユーザの声に耳を傾けること:聞くべきではなかったこと

私達は当初 Facebook, Twitter, Foursquare に対応して Sonar をリリースしました。ほどなくして、ユーザからたくさんの LinkedIn のサポートのリクエストがくるようになりました。表向きは彼らは権威のある専門家と会うために Sonar を使いたかったのだと思います。

私達は急いで LinkedIn のサポートを追加しました。効果があったかって?何もありませんでした。私の予想では追加のリクエストをしていた人達は実際に Sonar を使っていたユーザではなく、使ってみようかなと思っていた人達だったのだと思います。私達はそれが人々が求めているものだと思ってしまったのです。

ここからの学び

"この機能があったら使ってみるのに"といった声を聞くのは危険です。実際に使ってみるまではユーザはこんなものが欲しいとあれこれ想像するのですが、起業家と同じようにそれらはよく間違ったものになります。

エンタープライズ企業は彼らの顧客が彼らの要望に対して本当にお金を使ってくれるか検証すべきです。メディアやソーシャルネットワークの企業は実際のユーザの行動を観察、分析することに注力すべきなのです。

ユーザの声に耳を傾けること:聞くべきだったこと

最もよくリクエストされた機能は私達の Check-in 機能に対して "foursquare のような地図" を提供することでした。その機能は追加せずに私達はユーザがアプリ内で共有したことをテキストとして "@Sonar" から読めるようにしました(訳者注:@SonarTwitter アカウントと Facebook ページだと予想)。確かに地図を作ることは構想にはありましたがそれが実現されることはありませんでした。 "Ambient Social Networking" の未来を作るのに忙しすぎたのです!

失敗でした。人々は面白みがない"@Sonar"が好きではなかったのです。彼らは "@Sonar" の更新を共有することを止めました。 そもそも彼らの友達は"@Sonar"の更新に興味がなかったのです。Facebook はそのことに気が付き私達の投稿をユーザの目につかないようにしました。 私達は既にユーザが使用している機能(Check-in機能のこと)を改良することなく、代替案の検討を数えきれないほど行い無駄にしてしまいました。

ここからの学び

あなたはおそらく____についての Steve Jobs ではありません。

既に使われているもの(Check-in機能)を改良することはほとんどの場合において空に城を浮かべること(新しい機能の仮説、検証を行うこと)より投資効率が良いものです。新しいものを作る前に既存の製品の最適化/局所解を求めるべきなのです!

成長か成熟か

私達は製品を成長させるか成熟させることのどちらがより重要か、について相反する助言をたくさんの賢明な人達から受けました。 私達は成熟させることを重視し、実際それは桁違いによくなりました。ただ誰も気にしませんでした。

ここからの学び

もしソーシャルネットワークをを作っているなら成長こそ間違いなく唯一重要なことです。 成熟させることも必要ですが、売上があるしきい値を超えないかぎりは成熟を考えることすら意味がありません。 (しきい値は Seed、Series A、広告を売る段階それぞれによって変わってきます)

割く時間を少なくすべきだったこと

“集中とは1000の良いアイデアに対して No と言うことである”  — Steve Jobs

イベント

私は製品を売り込もうとした小さい Meetup によろよろと向かっているときに私の顧客獲得戦略が間違っていたことに気が付きました。 火曜日の夜11時、疲れきっていましたが家に帰ったら今度は通常の仕事が待っています。 欠席にするわけにはいかないので参加はするものの、そのみすぼらしいバーでは他の誰かの Sonar に反応して彼らのアプリケーションをインストールしてくれと頼まれるのを避けるために人を避けるようにしていました。

ここからの学び

イベントは市場調査、事業開発、採用のために行うものであって10,000,000 ダウンロードを達成するために行うものではありません。

ブランディング代理店

MTV、Kraft、Digitasのような代理店が私達に連絡してきたとき、彼らが何を求めているかわかりませんでした。 彼らは全てお膳立てした状態で私達のことを売り込んでくれるわけではなく、理解するのに少なくとも10回の会議をする必要があったのですが、私達の事業がうまくいったら私達の支持者に取り入れるように目をつけていたのです!

ここからの学び

代理店に対しては丁寧に、ただあなたが支持者を獲得するまでは彼らの売り言葉は先送りにして接してください。 もしあなたが支持者を獲得したら自ずと彼らはやってきます。

投資家は当然のこととしてこれを知っています。もしあなたが"XYZ"ブランドを構築することでとてつもない顧客と収益を獲得できると話していたら滑稽に聞こえることでしょう。

サイドプロジェクト

2011年の冬に私達は Wired Magazine と、彼らの Times Square の短期間営業店舗の顧客に店舗内のおすすめ商品を表示させるパートナーシップ契約を結びました。 その"とるに足らないプロジェクト"は開発に6週間かかりましたが、 Wired で働いている、クールな人達と関わりになったこと以外はこれといった利益はありませんでした。

ここからの学び

20%の時間はないのです。3つの最も重要なことを決めてください。そうしたら2番目と3番目は捨ててください。

競合

2012年の SXSW に向けての準備を進めているとき、あるメディアが Highlight (訳者注:HighlightSonar と似たコンセプトの競合 )こそが Sonar の後継となるものであるとでっち上げ、彼らよりもっと都合のいいときしかあてにならない投資家達が私達のことをこきおろし、私は自信を失いかけていました。私達はロードマップの優先付けをしなおし、Highlight と競合する機能(ただ私達の方が遅れている)を優先させるようにしました。 私は平然を装おうとしていましたが内情はひどかったものです。オースティンに向かう飛行機の中で「くそ、俺達が持っていたものを失おうとしている」と思っていたことを今でも覚えています。

ああ!Highlight は特に何をしたわけでもないのに私達はものすごい時間とエネルギーを浪費し、私達自身のビジネスをうまくいかせることを考えるべきときに、脅威にどうやって立ち向かうかを考えて過ごしていました。

ここからの学び

あせらないこと。あるスタートアップが別のスタートアップをつぶすのは完全に勝負がついたと分からせるくらいでないと無理でしょう。

信用できないなら立証してみてください。あなたの競合はあなたがロードマップに持っているのと同じ機能をたくさんリリースしていますか?しているって?ならあなたはあなたのユーザーが何を望んでいるか知っていますか?知らない?いいでしょう、あなたの競合も知りません。 戻ってあなたのユーザーが何を求めているか考えるように!

*ヒント:すでに考えているなら、もう何をするべきか分かっているはずです。

会社の売却

2012年の春に Ambient Social Networking のブームが去った時 Sonar の所有権があった投資家達は資産を売却する時だと判断しました。彼らは "ビッグデータ"のソリューションを探している Daily deals(訳者注:Groupon などのような一日限定のクーポンを配信するようなサービス)の会社と私達を引き合わせるようにしました。 私達はアプリケーションの開発をすることを止め、私達のバックエンドの技術を彼らの問題を解決するように変更していきました。 その時期でも採用を続け、バックエンドの強化をしていましたが、既に縮小傾向にあった私達のビジネスを強化するものではなかったのです。

Daily deals の市場は崩壊していきましたが私達は9ヶ月もの間ミーティングを重ね、数十万ドルものお金をほとんど倒産していた会社に Sonar を売却しようとするために使っていたのです。

ここからの学び

会社は売られるものではありません。買われるものです。買われるための最も良い方法は何か価値があるものを作ることです。そしてそれはあなたが会社を売ろうとしているときは難しいものでしょう。

不協和

Sonar は私が2010年にローンチを助けたインキュベーターから生み出されたものです。誤解のないように言っておきますがそのインキュベーターには Sonar が順調にスタートする助けになってもらいましたし、それ以降も多大な協力をしてもらいました。 しかし不運ながらインキュベーターたちと経営者には構造上の問題が多数ありました。そのいくつかをここで紹介しましょう。

責任の所在と所有権を分離してしまったことは、不明瞭さ、混乱、緊張、フラストレーションを生み出すことにつながってしまいました。 従業員の契約交渉などの日常のことから会社レベルでの決定、例えばいつ会社を売却するかなどに関して関係者の利害を一致させることは常に困難を伴っていました。単に、私達はしばしば対立しあっていたのです。

おそらくインキューベーターのモデルに関して最も有害な一面は、脆いということではなくむしろ支援関係に関するものでしょう。 つまり、誰かは会社を運営、経営していくことに責任を持っていますが所有権は結局は持っていなかったのです。そのような状況で一つのゴールを共有することはとてもうまくいくものではないでしょう。 (訳者注:TechCrunch の記事によると Sonar は複数の関係者が所有していたらしい。Brett 自身も最後期は誰が持っていたか、何をしていたか完全に把握できていたわけではなかった)

最も悲惨な例は私たちのインキュベーターが、(受けていれば会社を再建したであろう)会社の資金繰りを努めていたときのことです。 一ヶ月にも及ぶ議論の末、投資家になるつもりだった人は「これ以上の交渉はできない。48時間に決められなければこの話はなしだ」との条件を提示しました。 会社を再建する希望を持ちながら、私は最後の申し出をインキュベーター達に行いました。「一緒に再建の道を進みましょう。それができないなら私は出て行く」誰もぴくりとも動きませんでした。時は過ぎ投資の話は流れました。約束どおり私は辞任しました。私の子ども同然だった会社を台無しにした彼らを非難しながら。

ここからの学び

John Burroughs はこう述べています。「人は何回でもしくじることができる。ただ誰か他の人のせいにしだすまでは失敗ではない」 どうにもならない厄介な人と関わらないでください。ただどうしてもそういう状況に陥ってしまったときは、境遇を嘆くことに貴重なエネルギーを使うより、うまくいかなければとっとと次に進んでください。

人について

“人々が考え行っていることが重要であると、私たちが信じさせるとき ー そしてその邪魔をしないとき ー 真の競争が生まれる”  — Jack Welch

チームビルディングに関しては現実的になるべき

私達は最初の採用すべき人材、すばらしい Google のエンジニアを逃してしまいました。私達が彼の契約について検討しているとき彼は他のオファーを受けてしまったのです。反対に私達は彼に比べたらずっと劣ると見られていたエンジニアをそのポジションに採用しました。 彼は会社の文化にとても合うと思われませんでしたが、V1をリリースするのに大いに役立ってくれました。

もしあなたが経験豊富な起業家で、たくさんの選択肢を持っているなら絶対に強気の交渉をするべきです。もし初めての起業なら強気の交渉を続けていては一生うまくいかない危険があります。

スタートアップを始めたばかりのころは既に名声がある人は多分あなたと働きたいとは思わないでしょう。未開の地にもダイアモンドが見つかること(名声が確立されていなくても素晴らしい人材が存在すること?)をあなたが示してください、あなた自身がそうであったように。彼らの力を借りればあなたの組織のレベルを高められ、次は偉大な人物にも参加してもらうことができるでしょう。

企業文化は共同創業者

私達は Sonar で素晴らしいチームを作りました。全員が信じられないほど聡明で、情熱を持ち、献身的で勤勉でした。 私達はマイルストーンがあるとビーチに集まりテキーラでお祝いしたものです。厳しいスケジュールの時もみんなその時できるかぎりのことを成し遂げてくれました。私は一緒に働いていた彼らが大好きですし、彼らも同じように感じていたことを信じています。

ですから私達の企業文化は議論を重ねて作ったというよりは自然発生したものだったのです。 もちろん私達はたくさんのブレインストーミングを行いましたし、ゴールもはっきりと宣言しましたが、企業文化のほとんどは私達自身から吸収したものだったと言えるでしょう。

ここからの学び

企業文化を、あなたがいないときに代わりとなってくれる共同創業者だと思ってください。あなたは物事を決定でき、コミュニケーションがとれ、尊敬される人物です。ただあなたがいないときに、みんなにどうすれば良いか教えてくれるのは企業文化なのです。その声を明瞭にし、自信を与えてください。

人を消沈させるような言葉を避けることがこつです。なぜならスタートアップの企業文化は間違いなく創業者を反映しているからです。あなたにできることはあなたが何者であるかをわかってもらうために熱心に働くことでしょう。それを書き出しチームに共有してください。もしあなたが誠実であったなら振る舞いの一つ一つがあなたの価値を高めてくれるでしょう。

これからのこと

“私達はとるに足らないものと戦っていて、私達が勝ったときは私達自身が取るに足らないものになっているだけ。私達はただ崇高なものにこんてんぱんに何度も打ち負かされたいだけなのです。 — Rainer Maria Rilke via Tim O’Reilly"

スタートアップはお金が尽きたら無くなるのではなく、創業者がいなくなった時に無くなるのです。 私はそれまでかけてきたものがどれだけだったとしても、みんながもう一度もっと素晴らしい新しいことを始められるように Sonar から身を引くことを決心しました。 それは難しい決断でしたが戦いに勝つためには一つの局面を諦めなければいけない時もあります。

私はかけがえのない時間、お金、愛を注いでくれた人達、3年もの間働いてくれた同僚、もしくは電話ででも応援してくれた多くの人達に借りができました。 驚くほど素晴らしい同僚、信頼できる投資家、助言を与えてくれた方、支えてくれた家族、友人達に心から感謝します。 Sonar を使っていただいた何百万人ものユーザの方たちに伝えておきたい。あなたたちが Sonar でボーイフレンドに会うことができたという話を聞くだけで全ての努力は報われていました。

私達はあらゆる人はもっと素晴らしい可能性を秘めているという信念を持って Sonar を作っていました。 そしてテクノロジーがそれを可能にするだろうと信じて。 Sonar での経験はその信念を強固にすることに他なりませんでした。ここで学んだ全てのことを糧にして次に何をするか考えるとわくわくして止まりません。

さあはじめましょう。

I'm joining Google

ワークスアプリケーションズを退職しました。
(在籍上はもうちょっと続きます)

在職中はたくさんの方にお世話になりました。本当にありがとうございます。人間的にも魅力ある人が多かったなあと思います。直接ご挨拶できなかった方は心苦しいです、、、ちゃんととても感謝していますよ!
そして在職中はよくコード書いてたなあと思います。6, 7割くらいの時間は書いてたのかな。
前職はSIerだったのでコードを書いてもらう人からコードを書く人になったわけですが、ワークスでの経験がなければコードを書くことを仕事としたいと思うようになっていなかったでしょう。
働いてたのは2年半くらいになるのですが、2年半前にたまたま声をかけてもらうまでは会社のこと知りませんでしたし、なんか怪しそうな会社に声をかけられたなあくらいに思ってました笑。
そう思うとどこの会社にいたのかって長い目で見るとあまり差はないのかという気にもなってきます。

これからのこと

来月からはGoogleで働きます。
職種はDeveloper Programs Engineerという、Developerのみなさんがアプリやサービスを作るのをサポートするDeveloper Relationsの内の一つです。
こちらにもDeveloper Relationsの説明があります。


第二回 #Playframework 勉強会 in Tokyo #play_ja : ATNDでSiena-MongoDBについて発表した時など、勉強会に参加いただいていた方に好意的に受け取ってもらえたと思います。その時の経験が強烈に印象に残っていてこの職種を選んだと言えるでしょうか。
オープンソース開発者は承認欲求とか好奇心のためにコミュニティに参加する方もいると聞きますが、その片鱗を体験したというか。


ところで僕と付き合いが長い人ほど、なんでGoogleのような会社からオファーもらったのかと思う人もいるかと思います。
実際自分もちょっと意外だったし笑。

Googleに多くいらっしゃるような一流の大学出身というわけでもないし、経歴としては少数派になるのかなと予想してます。
ただ、Computer Scienceとプログラミングと英語を地道に勉強してきたとは自信持って言えます。
特に、@mayahjpさんという今はGoogleに行っているけど以前は弊社にいらしていた、カズが24時間サッカーのことを考えてるように、24時間プログラミングのことを考えてるんじゃないかという方がいまして。


彼に感心すると共にソフトウェアエンジニアをやっている以上自分もこのままではいかんなあと勝手に刺激をもらった面があります。

それからは空いている時間は勉強に充てる比率が高くなっていました。
そのうちプログラミング自体が趣味の一つになっていたので、あんまり頑張ってやっているという感じではなかったのですが。

そんな地道な努力がInterviewとかでのアウトプットにもつながったのかなあと。


今は来月からInterviewなどでお会いしたようなエンジニアと一緒に働けるのがとても楽しみです。
それまではちょっとゆっくりする時間をもらいます。
と言ってもコード書きまくりな休みにしたいなあとか思うとあんまり変わらないんですけどね!!

Just for syntax highlight test

Seems not supported yet.

sh

history | sed "s/ *[0-9]* *//"

java

public static void main(String[] args) {
  System.out.println("Hello world");
}

// sed // to test if sed will get keyword highlighted

c

#include <stdio.h>

int main() {
  printf("hello world!¥n");
  return 0;
}


scala

object DefaultArrayValue {
  def main(args: Array[String]) {
    println("Execute test")
  }
}


python

a = (1, 2, 3)
a1, a2, a3 = a
print a1
print a2
print a3


js

(function() {
  var localSettings = {
    bookmarkKeyChar: 'D',
    bookmarkSpecialKey: 'alt'
  };
})


ruby

 class Hoge
   def fuga
     'fuga' # return fuga
   end
 end


Auto Recognition (?)

 #!/usr/bin/env sh

COMMANDS=( "qstat" "qalter" "checkjob" )
ERROR=0
for (( i=0; i<${#COMMANDS[@]}; i++ ))
do
  cmd=${COMMANDS[$i]}
  CMD_PATH=`which $cmd 2>/dev/null`
  if [ $? -ne 0 ]
  then
    echo Could not find $cmd in PATH
    ERROR=1
  fi
done

Playframeworkについていろいろ

Play! framework Advent Calendar 2011 jp #play_ja : ATNDの8日目です。
そしてこのBlogを開設して初めて書きます。

@hagikurというIDでTwitterやってます。どうぞよろしく。
Playframeworkで一番好きなModuleはSienaです。
Playframeworkとの馴れ初めを書く前に僕自身の事を少し書いてみようと思います。

前の会社のこと

まず今はERPパッケージを作る会社でソフトウェアエンジニアとして働いています。
その前は新卒としてSIerの会社で働いていました。

SIerの会社では仕様決めから、設計、開発、テスト、導入までと開発サイクルのひと通りを経験させてもらいました。(ただ、開発、テストの多くは協力会社と呼ばれる外注の方に発注することが多い)

今思い返してみても非常に厳しい現場だったので仕事をするとはこういうことなんだという意識を植え付けられたのはもちろん、ソフトウェアエンジニアリングとかインフラについてもたくさんのことを学べる場所でありました。
よく怒られたなーというのが懐かしい。


SIerというと、よくTLなどで技術力の低さなどを揶揄するハッシュタグが流れたりしていますがw、そのハッシュタグのTweetと照らしてみても幸運にも(?)そういう揶揄されるようなことは少ない、恵まれた場所であったと思います。

ただ、なんで転職を決意したかというとやっぱり開発を自分でできないというもどかしさがあったことが一番でした。
大学で情報工学を専攻してたり、仕事外でも趣味でプログラミングの勉強はしていたこともあって、(能力的に)プログラムが書けないということはなかったと思うのですが、SIerという仕組み自体が発注側がプログラムを書いてはいけないということを強制していました。


なぜなら、全ての工程は人月という単位に換算され誰が作業しても同じ効率で工程が終わるという前提のもと物事が進むからです。
そうすると、相対的に人月単価が高い発注側の人間は必然的に管理側に回ることが多くなります。
(ただ幸運だったのはさっきも書いた通りその中でも丸投げするだけのことはなく、技術的にも学べることは多かったことです)


で、漠然と転職を考えてた時に運良く今の会社に拾ってもらいました。

今の会社のこと

で、今の会社に入ってからはR&Dのようなところに配属になりました。
自分で開発ができるということを楽しく感じ、できればずっとソフトウェアエンジニアを続けていきたいと思うようになったのもここでの開発経験があったからだと思います。


と思うのと同時に社内社外問わずアウトプットをすること(つまりエンジニアとしてはプログラムを書くこと)を強く意識するようになりました。
考えるようになったいきさつは色々あるような気がしますが、多分こんなところです。

  • プログラムを書いてそれを誰かの為に役立たせるという体験が楽しく、それを本気でやって行きたいと思うようになったこと。
  • プログラムを書くことを今後の仕事にしていきたいと思うようになった一方、社外とか世界でみると自分はどれくらい通用するんだろうと思うようになったこと。

Playframework

で、そんな風にアウトプットを出さなきゃと思っていた時に偶然Playframeworkに出会いました。
最初見たときはJavaでRuby on Rails 的な開発とか言ってるけど何これ!
Controllerにrequest, responseがstatic フィールドであるし!
とかthrow Throwable をgoto文的に使っててキモい!
とか一般的にはJavaの書き方でしちゃいけないということをFramework内部のソースではやってたのにまず驚きました。


が、実際使ってみると直感的な開発ができることにもまた驚き、すぐにこのFrameworkが好きになりました。
だって開発中にサーバ一回立ち上げたらその日を終えるまでサーバ上げなおさなくていいんですよ。

僕も含めてプログラムを書く人は総じて面倒くさがりな人が多いです。
そういう人たちはなるべく無駄なことは無くしたいと思っているはずなんですよね。
開発中にサーバの上げ下げするの面倒だなあとか思ってる人は一回騙されたと思ってPlay! 使ってみてください。


でなんやかんやあってPlayframeworkを使って小さいながら自分のアプリケーションを公開できたり作った過程なりを第二回 #Playframework 勉強会 in Tokyo #play_ja : ATNDのような勉強会で発表させてもらったり、GAE -> Heroku に移行する際に必要になったSiena-MongoDBのPluginのpull request送れたりするようになったわけです。(残念ながらまだmergeされていないですが)


またこの頃からありがたいことに、エンジニアとしての職の紹介をちらほらいただくようになりました。
もちろん職探しをするためにアウトプットをしたかったわけではなかったのですが、エンジニアとして評価していただける方がいらっしゃるのはアウトプットが最も重要と考えたことと、そのアウトプットをするためになるべく無駄なことを排除してくれるPlayframeworkを選んだことはそんなに間違ってなかったのだろうとの励みになりました。

最後に

いいことばかり書いてきましたがもちろん全てメリットばかりというわけではありません。
例えば、Play! は生産性を重視するFrameworkであるためにController, Modelなどの書き方は自由に書かせるよりFrameworkに従った書き方を期待しています。なので、既存のWeb Application を移行するといった使い方にはあまり向いていないかもしれません。
(もちろん一概には言えませんが。既存のものが適切なクラス単位に分割されていれば大部分は再利用できるでしょう)


が、Javaでスクラッチで開発するのだったらまず検討しがいのあるFrameworkであると思います。いくつかJavaのFramework経験しましたがそれくらい開発しやすかったです。
そしてPlay2.0からはScalaについてもそういうポジションになれるように願ってます!


なんかPlay! の紹介というより使った上での心持ちみたいになっちゃったけどAdventCalendarにも一つくらいこんなのがあってもいいよね!
と言うわけで9日目は @teppei_tosa さんに担当していただきます。お楽しみに!