2015年の振り返りと2016年に向けて
2015年
2015年はRailsをやってる時間が長かった。Androidを少々書いていた時期もあり、ほんの僅かな時期iOS（Objective-C）をちょろっとやってた。Rails自体への意識を高めていこうとした時期もあり、その結果として初のrails本体へのコミットも果たした。ただ、コードを書くこと自体よりも、チーム全体の成長や開発効率を高めることに集中していたように思う。どれか一つに注力していたわけではなかったので、外部イベントで話せるような深い話がまったくできなかったのが歯がゆかった。
関数型プログラミング、DDD、Go言語など新しい分野の勉強もしていた。特にGo言語は、自分用の小さいツールをたくさんGoで書いたことでそれなりに書けるようになってきたと思う。一番驚いたのは、naoty/Timepieceがなぜかバズって、海外からStarをたくさんいただいたことだった。
開発以外のトピックとしては、7、8年かけてたメガネをやめてコンタクトにしたこと、卓球ハウスが解散して練馬区に引っ越したこと、いろいろあって"社会的状況"になりつつあることがある。
開発以外の時間が充実しすぎてあんまり開発してなかったが、最高の一年となった。開発してても幸せにはなれない、そこに幸せはない、という数年来の想いが確信へと変わった一年だった。
2016年
今年こそはiOSアプリ開発に専念できたらしたい。Railsはいい加減コリゴリなので。アプリ開発に専念するからには、UI設計などのデザイン業務にも徐々に慣れていきたいなーと欲が出てきている。
前述のTimepieceの保守も継続させて☆1000を突破したい。ただ、これ以外にも他のジャンルで新しいiOS開発関連ライブラリを作っていきたい。できれば、少し大きめのイベントでも発表できるようになっていきたい（これまではあまり外部での発表に重きを置いてなかったけど、なんだかいろいろ心配になってきたので）。
あとは、12月の引っ越しを期に人生初の自炊生活を始めたので、ちゃんと自炊を習慣にしていきたいというのが大きな目標。
本年も何卒宜しくお願い致します。
近況
最近大きな環境の変化があったり先日行ってきたYAPCで影響を受けて心境が変わってきたので、近況という形でブログに残しておきたい。
大きな心境の変化として、プライベートの時間の使い方を変えようと思っている。より優先度の高いことに時間を使うようにして、プライベートでプログラミングする時間は以前より少なくなりそう。あれこれ手を出すというよりは1つのことに集中して時間を充てる方が効果的なんじゃないかと思うようになったので、何にしようか考えている。
- 仕事で使う可能性がありそうなScalaとPlayFrameworkに興味がある。以前にすごいH本を読んで関数型プログラミングを実践してみたい気持ちがある。
- あとは、いま仕事ではRailsプロジェクトに携わっているけど、リファクタリングを喫緊の課題として感じていて、プライベートの時間でいかに対処すべきか本を読んで考えてみたり、必要なライブラリの開発に時間を充てるのもいいかもしれない。
- JavaScriptをキャッチアップしたい気持ちもちょっとある。YAPCのセッションでES6の話を聞いて、ちゃんと学んで既存のプロジェクトに手を加えたい気持ちが湧いてきた。ただこれは上のリファクタリングが済んだ先の話だと思った。
- 「ドメイン駆動設計」をずっと読んでたけど、引き続き「実践ドメイン駆動設計」も読んでみようかなという選択肢もある。ただ、まだ仕事で使えるような段階にはない気がする。
- naoty/Timepieceの開発は停滞しているけど、どうしようかなと思っている。仕事でSwiftが書けるのであればまだモチベーションを維持できるのだけど、残念ながらそのような環境にはいない。
こう整理してみると、リファクタリングについてプライベートでも時間をとるのがよさそうだなと思う。それが一段落ついたらJavaScriptのリファクタリングとかDDDとかに移っていけそう。もっと余裕が出てきたらScalaやろうかなぁ。
なんとなくあと2, 3年先までの見通しが立ってきた。仕事ではとりあえず今のプロジェクトを地道に改善していくことになりそう。自分の成長というよりはプロダクトの成功やチームの成長にフォーカスしていきたいという気持ちに移ってきている。Rubyの上にも3年、という感じ。iOS/Androidもやるけど。プライベートでも、今の生活の先に明るい未来が見えてきている。堅実に仕事を進めつつ、貴重な時間を大切にしていきたい。
#potatotips でTimepieceについて発表した
potatotips
資料
最近のTimepiece
- GW前あたりから急激にバズってきた。一時GitHubのトレンドで1位になった。それまでは☆70くらいだったけど、もうそろそろ☆500になりそうな勢いだ。
- それに伴っていくつかの要望をPull requestでいただいた。それらはほぼすべてmergeした。機能追加やバグ修正まで自分では見落としていた部分を指摘していただいて、多くの方に使われていそうだという実感がある。
イベントの感想
- 最近はiOSではなくAndroidアプリ開発をしているので、iOS/Android両方楽しめて非常に良かった。
- Timepieceを検討したけど採用を見送った方の意見を聞けたのが非常に良かった。そういう方の意見を聞ける機会は多くないからだ。いただいた要望について今実装方針を考えていて、ちゃんと形にしていきたい。
- 最近気になっているResultについての議論はとても勉強になった。naoty/SwiftCSVでエラー情報を扱う際にResultが使えそうだと思っていた。ただ、議論を聞いてオレオレResultが乱立しそうな流れがありそうだというのを知った。そうなると、ライブラリ提供者が実装するよりも利用者側でResultを定義する方が利便性を損ねないのでは、という意見に変わった。
- ドキュメントだけではよく理解できなかったDagger 2については、あまりよくわかってなかった
@Provideについて理解が深まった。Androidのテストについて意見交換をさせていただいて、自分の意見は間違ってなさそうだという確信を得られたのもよかった。 - その他、Androidの
@Nullable,@NonNullはすぐに使おうと思ったし、Lastlaneやdeliverといったワークフローを自動化するツールも実践的な内容で勉強になった。
半年経ちました・引っ越しました
2013年もあっという間に半年が経ちました。上半期の半分はiOSアプリやAndroidアプリを書いたり、プライベートでgemを書いたりしてました。上半期のもう半分は新しい会社でハードウェアの企画・開発に携わりました。この期間は自分のなかで失敗の連続で落ち込む日が多かったように思います。そしてけっこう太りました。技術面のみならずいろんなところで自分の至らなさを突きつけられました。プライベートでの時間の使い方が散漫だったのが最大の反省点です。もっとハードウェアという未知の領域の理解に時間をかけるべきでした。まだまだwebへの未練が捨てられず、ついついハードウェアよりweb的なものやアプリを作ったりvimいじりをしてしまうのがよくなかったです。ただ、昨年の大晦日にたてた目標、「ハードウェアを開発すること」は少しずつ実現していっているように思います。
そして、おととい引っ越しました。シェアハウスです。数年前に一度トライして失敗に終わりましたが、念願かなって実現できました。自分史上最高にいい家です。足が伸ばせるお風呂は初めてでした。住民は同年代のプログラマーで、僕よりはるかに優秀な人たちです。あと、彼らと親交のあるインターネッツ勢が来客されるので、僕は末席でじーっとしてます。
半年経った反省を基に、新たな環境で、なんとか2013年の目標を達成できるよう努力したいです。あと、かなりの出費で瀕死の状態がしばらく続きそうなので、アプリで一発あてたいです。よろしくお願いいたします。
konashi make-a-thonに参加してきた
6/1と昨日6/22の2日間、konashi make-a-thonに参加してきた。konashiを使ってiOSと連携するハードウェアをmakeするイベントだった。数人のチームに分かれてアイデアのブレーンストーミングから実際の開発まで行った。
一日目はワークショップ形式でたくさんのアイデアを出しまくった。その中から実装するアイデアを決めた。二日目までの3週間、僕はiOSアプリ担当ということで90%くらい完成させた。で、二日目にはハードウェアと筐体とkonashiを結合して、アプリから操作するところまでを確認し、微調整をした。で、できたのがこれ。
なにこの完成度ww
このコースターはグラスのビールが空になるとiOSにバイブで通知する。コースターには感圧センサーが入っていて、重さをkonashiを使ってbluetoothでiOSアプリに送信する。で、アプリ側で重さが一定値を超えるとバイブするようになっている。上司のグラスが空になったらアプリが教えてくれるので、飲み会の席でうまく立ち回れる。アプリのソースコードはGithubで公開しているので、konashiのサンプルコードとして参考にしてもらえるとうれしい。
感想としては、自分では思いもよらない面白いアイデアがどんどん出てきて面白かった。もっとこういう話をいろんな人としてみたいと思った。makeのための環境や技術はどんどん進歩していく一方で、相対的にmakeするもののアイデアが不足しているように感じていたところ、こういう機会に参加できたことはいい刺激になった。
あと、不特定多数が利用するデバイスを利用者それぞれにパーソナライズして利用できるようにするための手段としてスマホを捉えるのは、すごく興味深い応用範囲のひろい考え方だと思った。スマホには利用履歴や設定が保存されており、それを共用デバイスと通信することで共用デバイスをパーソナライズすることが可能、というのは考えたことなかった。コンビニで買い物するときいちいち「TSUTAYAカード持ってません」って言うの誰の得にもなってない気がする。TSUTAYA_CARD = falseみたいな設定をスマホに保存し、なんらかの形でコンビニと通信することでこの問題を解決したい。
ちょっと話が脱線したけど、どのチームも完成度が高くて面白かった。イベント終了後の懇親会では、言い知れぬ充実感とものづくりの喜びと今後のmakerムーブメントへの期待とでいい気分になった。よかった。
LTのスライドつくるのだるい
Keynoteの使い方よくわからないし、なんでこんなものに数千円はらったのか意味がわからない。だいたい、マスタという概念はwebでいうCSSなんだからテキストファイルとして定義できるようにすればいいのに。そうすれば、githubとかで共有できるから、かっこいいスライドのマスタを再利用することができる。そういうところでLTのスライドつくるのがだるくなる。明らかな非効率性を目の前にするとまったく手が進まなくなる。
だるいことは自動化するのがプログラマの美徳なので、土日で自動化を試みた。
cloneして、content.mdというファイルにスライドの内容をmarkdownで書いて、rakeすればHTMLのスライドができる。cssでスライドを自由にデザインできる。面倒なGUIの操作をいちいち覚える必要はなくなった。cssということはそれを共有することで、感じのいいスライドを再利用できる。あの人のスライドで使ってるフォントをいちいち調べる必要もない。
こういうフレームワーク的なものは既にいくつかあって、最初はreveal.jsを使おうと思った。ただ、実際に使ってみると確かにかっこいいアニメーションがついていい感じなんだけど、いくつか不満な点があった。まず、海外で作られたデザインなので、日本語を使うと文字サイズや余白のバランスに違和感を感じる。で、カスタマイズしてみようと思ったんだけど、どこをいじっていいのかわからなかった。いや、これは僕のスキルに問題があるだけかもしれない。実際、sassを使ったりmixinを使ったり工夫がこらしてあった。でも、正直、ここまで複雑で凝ったものはいらなかった。なんでもそうだと思うけど、長く使っていくツールに必要なのは"カスタマイズしやすさ"だと思う。違和感を感じたときにすぐに修正できないとストレスがたまっていって、ずっと使っていくことができなくなる。カスタマイズしやすいツールに必要なのは、疎結合な設計だと思う。設定の変更が及ぼす影響をなるべく小さくしないと、恐ろしくてカスタマイズできない。
というわけでreveal.jsもよかったけど、もっと小さいライブラリを自作することにした。
上のテンプレではこのライブラリを使ってHTMLをスライドっぽくしている。これまでJSのライブラリ（というには小さくておこがましいけど）を作ったことがなかったので、yak-shavingをすることになった。まず生JSはイヤだったのでcoffeescriptで書くことにして、coffeescriptをJSにコンパイルするためにgruntを使った。コンパイルされたJSは自動的にminifyするようにした。ここらへんの環境構築については以下のエントリが参考になった。
昨今のWebアプリケーションのひな形その2 - Grunt - naoyaのはてなダイアリー
で、このライブラリをテンプレで使うためにbowerのレポジトリに登録することにした。これが思ったより簡単でbower.jsonを決められたフォーマットで記述して
$ bower register haas.js git://github.com/naoty/haas.js.git
を実行するだけだった。
テンプレの話に戻ると、rakeタスク内でRedcarpetとTiltを使ってmarkdownやhamlをHTML化している。で、そのHTMLを上のhaas.jsでスライドっぽくすることで、なんとかスライドの体裁を整えることはできた。あとは、肝心のデザインをなんとかしなくちゃいけない。デザインについてはCSS難しいしできればどなたかにお願いしたいところではある。というか、それがこのテンプレをgithubで公開する目的なんだけど。
以上のような話を今度のebisu.rbで話すので、参加者の方はあんまり見ないようにお願いします（もう遅い
追記
ebisu.rbで話したので、上のテンプレで作ったスライドを公開します。
todoリストをwebに公開した話
自分が開発したいこと、勉強したいことをwebに公開した。
以前に書いた記事の通り、ここ数週間vimでtodoリストを書くようになった。これがなかなかよくて、.vimrcをいじってtodoリストを書きやすいようにvimをカスタマイズした。GUIアプリだと自由にカスタマイズできなくて、痒いところに手が届かずに使わなくなってしまうケースがあったけど、vimだと自由にいじれるからそういうこともなく長続きしているのだと思う。
そうこうしてるうちに、vimで書いたtodoリストはどんどん増えていった。その中には誰かがやってくれればいいものもあったので、公開していいかと思った。あと、todoリストを買い物リストのように使うことがあって、そういうときに外出先でiPhoneからチェックしたいと思ったのでwebで公開した。viewportを設定してモバイル端末からも見やすいようにした。
公開の仕組みは単純で、todo.mdというファイルをguardで監視して保存されたら自動的にあるスクリプト（下記リンク）とscpが実行されるようにした。このスクリプトはtodo.mdをパースし用意しておいたテンプレートとくっつけてHTML化する。そして、そのHTMLがscpでサーバーにアップロードされる。
あとRedcarpetをちょっと拡張して- [ ], - [x]をチェックボックスに変換するようにした。これはGithub Flavored Markdownで実装されているTask Listの形式を参考にした。
余談
最初はこの仕組みをSinatra、Heroku、Dropbox APIで作ろうとしたのだけど、いろいろ問題があって今の仕組みにいたった。結局「markdownの変換」「scpによるアップロード」の2つを自動化しただけのシンプルな形になった。最近これ以外にも、仕組みを選択する段階で失敗する経験があった。単純な仕組みであるほど問題は少ないし、起きたときに解決しやすいと思った。
「todoリストをテキストファイルとして扱う」というアイデアは、vimを十二分にカスタマイズ可能なtodoアプリとして扱えるようになっただけでなく、今回のようにtodoリストをwebに公開するというところまで行き着いた。なんかで読んだけど、データをテキストとして保存した方が扱いやすいというのが身にしみて理解できたのでよかった。
