Mac + 4K@60Hzディスプレイには LG の 27MU67-B が最適

4月から社会人になり、リモートワークをしています。 ほとんど自宅で仕事をしているので、作業環境を整えたいなと思って4Kディスプレイを購入しました。

27MU67-B を買った背景

MacBook Pro Retina(15'' Late 2013) + 4K@60Hz な環境が欲しかったのですが、Macで4Kディスプレイを使うネットの記事を見ていると

表示の一部が乱れたうえ、さらに元の解像度に戻せなくなる

via Macで4Kクラスの超高解像度ディスプレイを試す

モニタ付属のDisplayPortケーブルでThunderbolt2経由接続をしてみましたが、解像度・発色ともに破綻しており、使い物になりませんでした。

via Dell UP2414Q のカスタマーレビュー

のような書き込みが割とたくさんあって、どの商品も個体差があり、Macと相性の良い4Kディスプレイはほとんどなさそうでした。

Yosemite v10.10.2 までは60Hzの場合は標準でMulti-Stream Transport (MST)という方式で4K出力をするようになっていたため、それとディスプレイの相性がなかなか合わないのではないかというのが個人的な意見です。 MSTについて簡単に説明すると、これはもともと外部ディスプレイを複数枚つなげるときに使う転送方式で、4Kディスプレイの場合には右半分と左半分を2枚のディスプレイとみなしてデータ転送をする方法です。

Appleもこういった問題が多発しているのに気づいたのかもしれませんが、Yosemite v10.10.3からSingle-Stream Transport (SST)での60Hzに対応しました。 SSTだとGPUの力が更に必要になるようで、SST@60Hzに対応しているMacの機種はMST@60Hzに対応しているものよりも更に少なくなります。(参考: Using 4K displays and Ultra HD TVs with your Mac)

よく見ると、ぼくが使っているMacBook Pro Retina(15'' Late 2013)はSST@60Hzに対応していない模様… ただこれは、MBPR標準のIris ProのGPUを使った場合であって、上位モデルに付いている外部GPU (Late 2013であれば NVIDIA GeForce GT 750M) であれば、SSTで60Hzいけるんじゃないの？　と個人的には勝手に思っていました。

そんな感じで (1) MacBook Pro Retina(15'' Late 2013)の上位モデルであれば、SSTで60Hz出力できるか (2) LG製27MU67-B はMacと相性が良いのか

を試すために、人柱になって 27MU67-B を買ってみました。

結果

7月11日に届いて、約2週間使ってみましたが100点中、90点です！

良い点

(1) 表示の一部が乱れたりするような障害は一切起きなかった 特に設定もなにもする必要がなく、DisplayPort(ディスプレイ) to Thunderbolt(MBPR) で繋ぐとすぐに表示されました。 対応するケーブルも付属していたため、ディスプレイ到着後にすぐに使えたのも好印象です。

(2) 4Kディスプレイの解像度が変更できる 当然といえば当然なのですが、こちらも問題なく自分の好みの解像度に変更できます。

(3) HDMI2.0に対応している 今のMacには関係ありませんが、このディスプレイはHDMI2.0に対応しているので、HDMIでも60Hzで表示することができます。(従来のHDMIは4K@30Hzまででした) これからHDMI2.0に対応したPCやゲーム機が出てくると思うので、長期間使えるディスプレイになるでしょう。

悪い点

(1) 入力ポート切り替えが面倒 以下のレビューにもあるように、入力ポートの切り替えにMENUに入って選択する必要があり、切り替えまでに最低でも8回のボタン入力が必要です。 複数のマシンでディスプレイを共有するという使い方には適していないかもしれません。

4台のPCに接続しているのですが、切り替えが非常に面倒です。
MENUから入って一段奥に入力切替があるのでボタンを数回押さないといけないのでストレスを感じます。

via LG 27MU67-B のカスタマーレビュー

(2) Macが発熱する やはりMBPR(Late 2013)のIris Proでは60Hzに対応していないようで、ディスプレイを繋ぐと自動的にGPUが NVIDIA GeForce GT 750M に切り替わります。 ディスプレイ上ではほとんど静的な画面を写しているだけなので、GPUの使用率は5%前後ぐらいなのですが、それでもファンの回転数が4000~5000rpmでGPUダイの温度も70℃弱になります。 GPUが力不足という事はなさそうですが、750Mの発熱によるファンの回転音が少し気になります。 (感覚的には、重い処理を走らせてCPUをブン回した時ぐらいのファンの回転音が常にしている感じです)

夏なので高温になりやすいという季節的な問題もあるかと思いますが、ぼくはフリップスタンドを使うことでこの問題が解決できました。

こういったものがあるのは今回初めて知ったのですが、結構人気の商品のようです。 (購入時には20個在庫があったのですが、翌日見たら在庫が2個になっていました)

フリップスタンドを使うことで、Mac本体の下部に隙間を作ることで排熱効率が良くなります。 これを使うとファンの回転数が3000rpmぐらいに落ち着き、ファンの音もほとんど気にならないぐらいになりました。 (音に注意すると、あっ回ってる！ とわかるぐらいの音量です)

まとめ

悪い点の(2)が解決するまでは、80点ぐらいだったのですが、それが解決できたので90点になりました。 そもそもまともに動くかどうかわからない状態での購入だったので、その反動で自分の中での評価が若干高めになっています。

HDMIを使って30Hzでも接続してみましたが、マウスポインタが滑らかに動かず、これでは普段使っていてストレスが溜まるなぁ…という感じだったので、60Hzで使用できる環境を整えることが大事だと感じました。

27インチで6万円(執筆時)となかなかの安さなので、手を出しやすいモデルかなと思います。

Mouをコマンドラインから簡単に使えるようにした

結論から言うと、この記事はMouを[mou]というコマンドで起動できるようにするための記事です。

TextMateとかだと

$ mate filename

ってやると、filenameのファイルをTextMateで開ける。

これをマークダウンエディタのMouでもやりたかった。 調べてみたら下の参考1が見つかったんだけど、このページだけだとやり方がよく分からなかったので参考2のページも参考にしながら、実現させた。
【参考1】: コマンドラインでMouを開く
【参考2】: 自作のスクリプトをコマンド検索パスに保存する

そもそもMouにはコマンドラインから起動できるらしいのだけど、コマンドが

$ open -a Mou               # Mouを開く
$ open -a Mou filename.md    # filename.mdを開く

とか、ちょっと長くて面倒なコマンドになっている。 しかも下のコマンドでは、既存のファイルを開くだけで、新しいファイルは作成できない。。。

ということで、 ・[mou]だけ打てば良くて ・新しいファイルも作成できる コマンドを作ることにする。

作業開始

適当なディレクトリで

$ vim mou

mou

#!/bin/bash

if test $# -eq 0; then
    `open -a Mou`
elif test $# -eq 1; then
    `touch ${1}`
    `open -a Mou ${1}`
fi

中身はこれだけ。 touch ${1} の部分はなくてもいいけど、これを書かないと新しくファイルを作りたいときにエラーになる。 すでにファイルが存在する場合にtouchをしても、タイムスタンプが更新されるだけなので、問題なし。

書き終わったらmouファイルの実行権限を変更しておく。

$ chmod a+x mou

でもこのままだと、コマンドを打つときに

./mou filename.md

とかしないといけなくて気持ち悪いし、そもそもmouのファイルがあるディレクトリにいないと絶対パスを打たないといけない… クソやん！！！！

ってことで、mouコマンドを使えるようにする。

$ sudo cp mou /usr/local/bin/mou

このコマンド一発で完了。 (このやり方を調べるのに10分ぐらいかかったんだけど…笑)

これで

mou filename.md

ができるようになりました！ 便利！！！！！！

要らなくなったiPhoneで玄関監視をした

実家では、人が入ってきたら分かるように、こういうドアアラームを使っているのだけど

電池の消耗が激しくて10日に1度ぐらいエネループを充電しなければならず、とても面倒だと父親が言っていた。 それなら、要らなくなった古いiPhoneをビデオカメラ代わりにして、それをMacに転送して、Macでリアルタイム画像解析してやればいいのでは？ と思って、システムを作ってみました。

全体の流れ

1. MacにReflectorをインストールして、iPhoneをAirPlayで繋げられるようにする。

2. iPhoneでカメラアプリを起動して、AirPlay先にMacを選択し、ミラーリングにする。

3. Macの画面上にiPhoneの画面が表示されるので、定期的にそのウィンドウのスクリーンショットを撮る。

4. そのスクリーンショットを解析し、玄関のドアが開いていると判断できれば、チャイム等を鳴らす。

です。 以下で詳しく説明していきます。 (詳しい説明が要らない場合には、最下部のソースコードを直接見てください。)

手順1

Reflectorは1アカウント1200円ぐらいするちょっと高めのアプリですが、パソコンに繋いだ(音質の良い)スピーカーでiPhoneに入っている音楽をAirPlayで流す使い方もできたりするので、しっかり使えば12000円ぐらいの価値はあると思います…笑

手順2

上の説明そのままです。

手順3

一番面倒だったのはこのiPhoneのウィンドウのスクリーンショットだけを撮る部分です。

普通に画面全体のスクリーンショットを撮ると
となりますが、これでは周りの画像が解析の邪魔になるので、今回欲しいのは、以下のiPhoneの部分だけのスクリーンショット。

コマンドラインからスクリーンショットを撮る方法を調べると

usage: screencapture [-icMPmwsWxSCUtoa] [files]
  -c         force screen capture to go to the clipboard
  -C         capture the cursor as well as the screen. only in non-interactive modes
  -d         display errors to the user graphically
  -i         capture screen interactively, by selection or window
               control key - causes screen shot to go to clipboard
               space key   - toggle between mouse selection and
                             window selection modes
               escape key  - cancels interactive screen shot
  -m         only capture the main monitor, undefined if -i is set
  -M         screen capture output will go to a new Mail message
  -o         in window capture mode, do not capture the shadow of the window
  -P         screen capture output will open in Preview
  -s         only allow mouse selection mode
  -S         in window capture mode, capture the screen not the window
  -t<format> image format to create, default is png (other options include pdf, jpg, tiff and other formats)
  -T<seconds> Take the picture after a delay of <seconds>, default is 5
  -w         only allow window selection mode
  -W         start interaction in window selection mode
  -x         do not play sounds
  -a         do not include windows attached to selected windows
  -r         do not add dpi meta data to image
  -l<windowid> capture this windowsid
  -R<x,y,w,h> capture screen rect
  files   where to save the screen capture, 1 file per screen

とのことで、特定のウィンドウのスクリーンショットを撮るには

-l<windowid> capture this windowsid

のオプションを使えば良さそう。しかしwindowidをどうやって調べればよいのか… How do I find the windowid to pass to screencapture -l? を見ると、Apple純正のアプリでは

screencapture -l$(osascript -e 'tell app "Safari" to id of window 1') test.png

のようなコマンドで、特定のアプリのウィンドウのwindowidを渡せるようですが、ReflectorはApple純正のアプリじゃないし、無理…

GUIのQuartz Debugアプリを使えばwindowidが分かるようだけど、それではプログラムに組み込めないし…

ということで、原点に戻ってCocoaを使って取得します。RubyからCocoaを叩きたいので、

require 'osx/cocoa'

として、

all_windows = OSX::CGWindowListCopyWindowInfo((OSX::KCGWindowListOptionAll | OSX::KCGWindowListOptionOnScreenOnly | OSX::KCGWindowListExcludeDesktopElements), OSX::KCGNullWindowID);

とすれば、現在表示しているwindowの全ての情報が取得できました。 (rbenvでRuby管理してたら、RubyCocoaが上手く使えなかったので、その解決方法は YosemiteでRubyCocoaを使う に書きました。)

あとはこの中から欲しいwindowidを抜き出して、コマンドラインからスクリーンショットを撮るだけです。 (詳細は下部のソースコード)

手順4

得られたiPhoneのスクリーンショットから、どうやってドアが開いている、もしくは人が入ってきたのを判断するかという部分ですが 1. 顔認識をする 2. 動作検出をする 辺りが簡単にできるかなと思いました。

1に関しては過去の記事にも書いたようにOpen-CVを使えば簡単に顔認識ができます。 ので、実際に実装してみたのだけど、落ち込んだ気分の人が(頭を下げたまま)玄関から入ってくると顔が認識されないのと、家から出て行く場合には後頭部しか映らないので、そういった場合には検出ができませんでした。

ということで、動作検出の方に方針を切り替えます。 具体的には、1分毎に"元画像"を保存して、2秒ごとに"現在の画像"を撮って、"元画像"と"現在の画像"を比較して変化が大きければ、玄関が開いたもしくは人が写っていると判断するようにしました。 1分毎に"元画像"を変更しているのは、うちの玄関が
こういうドアで外の光が透過して、朝と夜とか、晴れと曇りで明るさが変わってしまうので、それに対応するためです。

2つの画像の比較はImageMagickのコマンドラインツールを使って

$ composite -compose difference original.png now.png diff.png
$ identify -format "%[mean]" diff.png

とすると、最初のコマンドでdiff.pngに差分の画像が生成されて、次のコマンドでどれだけの差分があったかを数値で出力します。 (詳しいことは2枚の画像のdiff（差分）を超簡単に調べる方法を参照)

あとは、"元画像"を変更する時に、それがちょうどドアが開いている時でないことのチェックとか、 何かが起きてずっと動作検出状態になってしまっても、復帰するような工夫も一応しておきました。 (細かい部分はソースコード見てくれ〜)

ソースコード

ここまで4時間ちょっとで完成して、仕事後帰宅した父親にKyokoさんの声で

「ぴんぽおん、ぴんぽおん、ぴんぽおん、ぴんぽおん。(父親の名前)さん、おかえりなさい。私はげんかんしです。今日から玄関の監視を担当します、げんかんしです。よろしくおねがいします。」

と大音量で流したら、 「これは要らない」 と言われて、結局このシステムは採用されませんでした。 (画像解析にCPUを意外と使うから、電気代が結構掛かるかもと説明したのが採用されなかった主な理由ですが…)

1ヶ月リモートワークでインターンしてきた @中国&日本

11月は1件も記事書いてなくて、気付いたら2014年最後の月に突入していた。 11月は何をやっていたかというと、週1日だけ株式会社MMMという企業でリモートワークインターンをさせてもらっていたので、そのことについて書こうと思う。

今回はインターンの内容というよりも、リモートワークに焦点をあてて書いていく。 ちなみに、来年4月以降はこの企業で働かせていただくことが決まったので、就職した際のメリット/デメリットも少し書いてみる。

1.インターンの概要

リモートワークに焦点を当てるといいつつ、いきなりインターンそのものについてのことだけど、背景も大事だと思うので書いておく。 今回のインターンは週1日で1日8時間労働を基準にして、合計32時間分の仕事を与えてもらうことになっていた。MMMさんは"コアタイムのないスーパフレックスタイム制"なので、空いている時間に作業してもらえればOKという方針で、特にコアタイムなどは指定されなかった。APIサーバーの開発の一部を担当することになったので、リモートワークでコードを書くことも体験できた。

作業場所に関しては、11月上旬は中国にいたので、中国の杭州からリモートワーク。中旬以降は帰国したので、京都からのリモートワークで参加した。

2.リモートワークのメリット

どこでも仕事ができる

大学卒業後は上海で生活するつもりなので、これはぼくにとってとてつもなく大きなメリットである。 中国で生活するといっても、半年に一回はビザの関係で帰国しないといけなかったり、たまには2週間ぐらい日本に帰りたくなったりする(かもしれない)ので、日本でも中国でも仕事ができるというのは非常に素晴らしい環境である。 今回も上述のように11月は中国と日本に半々ぐらい滞在していたけど、特に大きな問題なくインターンに参加できた。

いつでも仕事ができる

これは正社員になってからというよりは、インターンに関すること。 今回のインターンでは一応自分の中で毎週金曜日に作業すると考えていて、社員の方にも伝えていた。 しかし、木曜日に帰国して、翌日金曜日にいろいろ書類を整理したり、1ヶ月放置していた部屋の掃除をしたり…　あるときは、研究が忙しくて昼間に時間が取れなかったりと、思うように"金曜日昼間"の時間が確保できないことがあった。それでもリモートワークなら、金曜日夜にも作業できるし、あるいは土曜日午前中にも作業ができる。 これを正社員になっても続けてしまうとコミュニケーション面でいろいろと問題が起こるけれど、別の事をしながら短期間のインターンに参加させてもらうという状況では、リモートワークのメリットが出たかなと思う。

仕事中に邪魔されない？

「？」が付いているのは、リモートワークの記事を読むとよくこのメリットが書かれているのだけど、今回はこのメリットが実感できなかったからである。というのも実際にオフィスで働いたことがないので、同僚たちがどれぐらいうるさいものなのか知らず、比較ができない…笑 MMMさんではチャット上でも主に業務に必要な情報しか流れてこないし、たまーに気晴らしに雑談が入るぐらいなので、特にうるさいと感じることもなかった。

3.リモートワークのデメリット

作業環境がネットワーク環境に依存する

ローカルワークでも、そうといえばどうなのだけど、リモートワークではさらに顕著になる。 ミーティングをするときにはSkypeなどの音声通話コミュニケーションツールを使うのだけど、ネットワーク環境が悪いと突然切れたりする。 特に日本↔中国間では、回線が細く、最高で7Mbspしか出たことないし、Free Wi-Fiとか適当な場所で繋ぐと数百kbspだったりするので、複数人でSkypeをすると少し厳しいこともある。 もちろん上海では最高速度の固定回線を引くつもりだけど、リモートワークはどこでも仕事ができるからといって、"どこでも"仕事ができるわけではない。

自己管理ができないと大変

今回のインターンは週1だったので、あまり感じなかったけど、普段リモートで受託開発をしているとこれを感じたりする。特に作業場所が自宅だと、自分の中でいつからが仕事で、いつからが自分の時間なのかという区切りが付けづらい。週末ずっと家に引きこもっている自分なんかだと、家の中の風景は見飽きてるし、ずっと同じ座った格好だしで、特にそれがひどい。 そういう人はコワーキングスペースに行って、働く時間をある程度固定するのが良いと思う。

4.リモートワークをしてみての感想

受託開発では1人でリモート開発しているので、チームでのリモート開発というは今回はじめてで、最初はコミュニケーション面での心配があったのだけど、思ったよりも障害がなくて特に不自由は感じなかった。 MMMさんではSqwiggleのような社員の顔が見えるようなツールは使っていなくて、HipChatを使って連絡しあっている。ただ、チャットでも顔文字を多用するように心がけているようではあったし、単なる文字だけではなくて、感情を上手く伝えようとしているのが感じられた。 ぼくは個人的には、カフェで作業するような"見られている感"が大事で、それがないとダラダラしてしまうことがよくあるので、機会があれば社員の顔が見れるツールを使いませんか！と提案してみようかと思っている。(コワーキングスペースに行けば"見られている感"があるのでいいのだけど)

1ヶ月間リモートでずっと仕事していたのではなくて、実は11月末に(1人を除いた)社員さんみんなで名古屋に集結して、社員の方々と顔合わせをして、直接コードレビューをしてもらったりした。 この時感じたのは実際に会うと、"一緒にいる時間を大切にできる"ということで、普段リモートで働いているからこそ実際にあった時の時間がさらに濃く感じられるのかなと思った。(実際に社員の方も夏にローカルワーク開発合宿をやったのがスゴイ良かったと言っていた) ぼくは中国に住んでいる彼女と遠距離恋愛をしているのだが、これは遠距離恋愛と通じるものがあると思った。彼女とは実際に会うのは年に数回だけで、いつもはFacetimeとかで連絡を取っているが、普段一緒にいないという面では、(努力すればカバーできるレベルの)不便や不都合が起きることもある。しかし、その分実際に会った時には、喧嘩せず楽しい時間を過ごせるようにしようとお互い心がけるし、その時間を最高の時間にすることでお互いの仲ももっとよくなれることを実感している。 そういったメリットもリモートワークにはあるのかなと思った。その証拠にMMMの社員さんはすごく仲が良さそうである。

まとめ

将来日本と中国を数年おきに行ったり来たりする可能性もあって、リモートワークができる能力を今のうちに身に付けておくことが必要だと思っているので、新卒でリモートワークが経験できるのは非常に嬉しい限りである。 リモートワークを許可している企業でも、新卒は最初1年間オフィスで働いてもらいますとか、フリーランスの方のみリモートワークを許しているんですよ、とか言われることがあったので、自分にあう株式会社MMMを見つけることができて本当に良かったなと思っている。 来年4月から頑張ります！╭( ･ㅂ･)و ̑̑ｸﾞｯ !

30倍使いやすくなったFeVPN 1.1.0をリリースした！

2ヶ月前にFeVPNを作ったんだけど、使い勝手が良くなくて自分でも使ってなかった…笑 (まぁ日本にいる時にはVPNなんて必須じゃないしね)

10月2日から中国に滞在してて、再びFeVPNを使い始めたんだけど、やっぱり使いにくいから修正してバージョン1.1.0としてリリースした。 (ここから1.1.0のFeVPN.zipをダウンロードしてね。)

使いにくかった点

• スリープから立ち上がったばっかりでWi-Fiがまだつながってない時にも、VPNを繋ぎにいこうとして「VPNが繋げません！！」ってダイアログが出てくるからうるさくて嫌だった。
• オフラインのまま作業する時にも15秒ごとにVPN繋げませんダイアログが表示されてまともに作業できないし、その度にいちいちアプリを落としたり起動したりしないといけなくて面倒だった。

追加機能

1. オンラインの時のみVPN接続を試みる 上の問題を解決するために導入した。 オンラインかどうかを判定するにはwww.apple.comにpingをして、レスポンスが返ってくればオンラインと判定してる。 確認先をgoogle.comにしようかと思ったけど、中国からはgoogle.comにつながらないのでダメだった…笑

2. 連続で複数回接続に失敗したらFeVPNを終了する VPNサーバーの調子が悪くて、しばらくうまく繋がらない時があるけど、その間ずっと15秒ごとにダイアログが出てくるのはクソなので、3回(15秒x3)連続で接続に失敗したら「アプリを終了しますか？」と聞いてくれるダイアログを出すようにした。

あとはたいした機能を追加してないけど、気になる人はCHANGELOGを見てください。  

これ使ってくれてる人がいるのか知りたいんだけど、ダウンロード数とか簡単にログ取れないかなぁ…

初めてのPull RequestがMergeされた！

今日GitHubで初めてのPull Request(以下PR)がmergeされたので、mergeされるまでの一連の流れを書いてみようと思う。 showwinみたいな素人プログラマのPRでもmergeされることがあることを示して、だれでもOSS(オープンソースソフトウェア)の開発に貢献できるんだということを伝えたい。

『脱 PR童貞！！！』

1ヶ月前ぐらいに、「OSSの開発してみたいなぁ」って思って、PRの送り方とかネットで調べてみた。 コードを書いてPRを送ることももちろんひとつの貢献だし、普段使っているライブラリやソフトで不満に思っていることをissueとして投稿することもひとつの貢献方法らしい。

ぼくはコードを書いて、それを製品のなかに取り入れて欲しかったから、自分が開発できそうなプロジェクトをGitHubであちこち探した。  

Railsで開発するときに、通知機能の部分でよく使っているtoastrでこんなissueを見つけた。 しかも、enhancementついてる。  

中身を見てみると 上中央に表示される通知をみんな欲しがっているぞ！！！ (toastrには右上、右下、左上、左下、上Full-width、下Full-widthの6種類の通知場所しかなくて、みんな欲しいと言っているのは上中央に適度な大きさで表示される通知)

ちなみにぼくもこの上中央に表示される通知が欲しくて、なんとすでにその部分を自作して使っていた！

ownerも "feel free to open a PR." と言っていることだし、 オリジナルのプロジェクトから自分のレポジトリにforkして、 変更が必要な部分を自分のローカルtoastrからコピペして、上中央に通知を表示させるtoast-top-centerのpositionを作成した。

それで送ったのがこのPR

初めてのPRだから、ちょっと手間取ることもあるかもだけどよろしくって一応書いとく。

しっかり動くのを見せるために@uiureo氏が作ったGifzoを使って、Gif画像も載せておく。 (Gyazo GIFを使わずにGifzoを使ってるのは、個人的にはこっちの方が使い勝手が良いから。)

PR投稿してから、20日ぐらいずっと放置されていたんだけど、 ある人(Eagle3386)が、「おれのプロジェクトでtop-centerの機能が必要なんだよ！早くmergeしてくれ！」って3日前にコメントしてくれて、そこから管理人達も加わって、いろいろと話が進んでいった。

詳しくはPRのページを直接見てもらえればいいけど、 この後の流れとしては、

「top-center作ったんだから一貫性保つためにbottom-centerも作ってね」 「toastr.cssだけじゃなくて、.lessと.scssと.min.cssのupdateも頼むね」 「今回作成した部分のUnit tests作ってくれる？」

って感じ。 それぞれぼくが対応して、最後にCollabolatorの人にfinal lookしてもらって、問題なかったので無事にmergeされた。  

いきなり2200★StarぐらいついてるプロジェクトにPR送ってしまって、ちょっと怖かったけど、このファイルが足りないよとか丁寧に教えてくれたから、特に問題はなかった。 issueでも+1が連発されてたし、PRの中でも「この機能が欲しいんだ！」って言ってくれる人がいたので、今回この機能を自分が追加できたのは満足度が高い。

PRを送ったことがない人は、自分が貢献できそうなプロジェクトを探してPRを送ってみるといいと思う。

『脱 PR童貞！！！』

クックパッド 5-dayインターンシップ に参加してきた

9月1~5日の5日間、クックパッド(COOKPAD)の5-dayインターンシップに参加してきた。 選考からインターン内容まで、ひと通り書いてみる。

きっかけ

きっかけは@uiureo氏のツイート

交通費一部支給!!!!!! / “【エンジニア・総合職向け】5-dayインターンシップ /  スマホアプリ開発 | クックパッド株式会社” http://t.co/rAX9Vecfqy

— ウイウ (@uiureo) 2014, 7月 1

(交通費支給されることに惹かれたわけではないけど…笑)

自分は4回生だし、日本で就職する予定もないから今年はインターンに行くつもりはなかったんだけど、 優秀なエンジニア(特にRubyist)が多いことでクックパッドは気になっていて、 今までコードを書く系の開発インターンには参加したことがなかったこともあって申し込むことにした。

選考

2時間の技術系Webテスト
　↓
Skype面接
　↓
インターン決定！
な感じだった。

Webテストは中身ヒミツにね！って言われたから割愛。 Skype面接は技術系のことを深く聞かれることもなく、「普段どんなことに気をつけて開発してる？」的なことを聞かれた気がする。"面接"って感じじゃなくて、雑談してる感じだったから、気付いたら終わってたし、あんまり中身覚えてない。 (人事部の方々は事前にFacebookで確認済みだったから、特に緊張することはなく…笑)

長期インターン/バイトの案内も頂いたんだけど、自分は就職は考えてなかったり、日程的にも都合が悪いこともあって、結局短期インターンに参加させていただくことになった。 ありがとうございます！

インターンまで

今回はモバイルネイティブアプリの開発インターンで、Androidで開発するかiOSで開発するか事前に選択する感じだった。 Apple信者なので、もちろんiOSを選択したけど、 Apple信者なのに、普段はRuby,RailsでWeb系ばっかりやってるから、 Obj-CとiOS開発の勉強を事前にやらないとなー やらないとなー やらないとなー … と思いつつ、気付いたらインターン1週間前。

1週間あったら余裕だろと思ってたけど、実際に勉強し始めたら、Web開発との違いにかなり戸惑って、かなり焦った。 2日間Obj-Cの勉強して、3日間ネイティブアプリ開発の勉強して、 「事前にこんなサンプルアプリを練習で作ってきてね！」なアプリも完成することなく

インターンに突入！

5日間のインターン

そんなクソ技術力でインターンに臨んだわけだけども、結論から言えば最終日には作りたいアプリは完成した！ (バグは残っていて、発表時のDEMOでもちょっと上手くいかなかったけど…笑)

iOSとAndroidと1人ずつメンターの方が5日間ずっと付いてくれていたから、わからない部分はすぐに聞くことができたし、インターン参加者にも「バイトで4年間iOS開発してます！」なすごい方がいて、いろいろ教えてもらえて良い環境だった！

  インターンの内容は、総合職(ディレクター役)とエンジニアが二人一組になって、 「クックパッド公式アプリで解決できていない問題を解決する」アプリを作成する課題に取り組んだ。

クックパッドは「問題解決」にすごい重きをおいていて、社員さんからのフィードバックも「それはどんな問題を解決してるの？」とひたすら突っ込まれた記憶がある。

(ユーザ)は
(欲求)したいが
(課題)できないので
(製品の特徴)することに価値がある

を明確にすることを常に求められた。

“技術力"があることはもちろん重要だけど、 それがあることが前提で、それを"どう使うのか"を常に考えている会社だなという印象を受けた。

そういう意味では、技術力だけではなくて、ものづくりに対する姿勢も勉強できた、素晴らしいインターンだったと思う。

まとまらないまとめ

たった5日間でも「問題解決」という会社の方針がビンビン伝わってきて、社内全体で考えが共有されているのがすごくよくわかった。 どんな方針であれ、組織全体で考えを共有できているというのはやっぱりすごい強いと思うんだけど、 クックパッドは最近海外企業をいくつか買収していたりして急速にスケーリングしている。 そういった状況の中で、いかに方針を 共有する/浸透させる ことができるかが、これからも強い組織であり続けるためのキーポイントになるのかな、と思ったりもした。 (どの立場で言ってんだよ！！笑)

大事なことなのでもう一回言うけど、 総合職の非エンジニアも、もちろんエンジニアも、ものづくりに対する「問題解決」の姿勢を学ぶことができる最高のインターンです！！

人事部の方々、技術メンターの方々、共に全力を尽くしたインターン参加者のみんな、 楽しい最高の経験をさせていただき、本当にありがとうございました。

おまけ

なんと、rebuild.fmの@miyagawaさんが取材で日本オフィスにいらっしゃっていて、インターン生のrebuildリスナーで一緒に写真を撮らせてもらいました！