iOS用グラフ描画ライブラリを書き始めた
卓球ハウスに来てから楽しすぎてコード書いてないことに気づいたので、なんか書こうと思った。最近はセンサーのデータをどうにかiOSに転送したくていろいろ試しているのだけど、送られたデータを表示するときに何かとグラフを描画したくなる。
iOSでグラフを描画したいとき、まずCorePlotを試してみる。だけど、ドキュメントがあんまりないし、見た目がダサい。githubじゃないのもなんかなぁと思ってすぐにやめてしまう。で、CorePlotはやめてwebviewでJSのグラフ描画ライブラリを使うことにする。highchartsが便利なのでよく使う。でも、やっぱりいちいちHTMLとJSのファイルを用意しなくちゃいけないのがダルいとは思っていた。
そこでせっかくだしグラフ描画ライブラリをObj-Cで実装してみることにした。
まだぜんぜんできてない。かろうじて上のような折れ線グラフを表示できるレベル。負値すらうまく表示できない。もちろんテストもない。地味に頭を使う実装が多い気がする。
将来的には折れ線グラフだけじゃなくて円グラフと棒グラフも実装したい。けっこう時間かかりそうなので、ヒマなときにゆっくり実装したい。
半年経ちました・引っ越しました
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ムーブメントへの期待とでいい気分になった。よかった。
slide_template改めglideの今後について
LTのスライドつくるのだるい - naoty.to_sの続き。
"slide_template"という名前はあまりに味気なかったので"glide"という名前をつけた。"slide"に近い単語で、スムーズにスライドを作成できるイメージから名付けてみた。あと、ギタフリで好きな曲の名前でもある。
slide_template改めglideの今後の方向性と課題について考えてみた。glideが目指している方向性を端的に言うと「slide版のtwitter bootstrap」だと思う。すごく凝ったスライドをつくる人には向いてないけど、時間をかけずにそれなりにいい感じのスライドを作りたい人に向けたプロダクトにしていきたい。プログラマーがプログラミング以外のところで時間を奪われるのは社会的な損失だと思う。一方で、プログラマーによる勉強会は増えてる気がする。いちおう僕もEbisu.rbを月1で開催してたりする。勉強会が増えるとスライドを作成する時間も増える。勉強会自体はいいことだと思うけど、スライド作成に時間が奪われるのはよくないことだと思う。そこで、スライドを簡単に作成するフレームワークが必要だと思った。ここらへんがglideをつくるきっかけとなってる。
で、この方向性に沿って今後やっていくことは、以下のように考えてる。
- デフォルトのテーマを豊富にそろえる。今のところほとんどCSSがない状態なので、bootstrapみたいな感じでクラスを指定するだけでかっこいい感じのスライドになるようにしたい。
- スライドをPDF形式で出力できるようにする。htmlをアップするサーバーを持たない人はspeakerdeckとか使うと思うので、PDF化が必要。
- bowerに依存せずにセットアップできるようにする。デザイナーさんなどに協力をお願いするにあたって一番のネックは環境構築だと思う。今のところJSとCSSのセットアップにbowerを使っているけど、bowerはnodeとnpmが必要なので慣れてないときついかもしれない。なので、bower以外のセットアップ方法も用意する必要がある。
とりあえず3.を片付けてデザイナーさんと協力できる体制を整えて1.に取り掛かりたいと思ってる。2.についてはPDF用のCSSが必要っぽくて未知の領域なので、ここもやはりデザイナーさんに教えてもらいたいところ。
一人でできるレベルを超えてきた感じがしてきたので、まずはこうやってブログを書いてみることが大事だと思った。
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に公開するというところまで行き着いた。なんかで読んだけど、データをテキストとして保存した方が扱いやすいというのが身にしみて理解できたのでよかった。
Androidに乗り換えるかも
自分のために作ったアプリを公開したい場合にiOSはとてもハードルが高い。 仕事でやるなら別にいいんだけど、自分で使うのが主のモチベーションで 「他の人もこれ使ったら便利だと思う」程度のモチベで公開しようとするとそのハードルの高さに愕然とする。 審査が入るから、かなり完成度を高めないと落とされる。 完成度を高めていく作業はけっこう根気がいる。
iOSは審査プロセスもビルドプロセスも複雑で、開発以外の部分で時間をとられるのがむかつく。 なぜかよくわからないけど、Androidはantとかmavenでビルドを自動化するノウハウがたくさんあるのに、 iOSはビルドの自動化に関して情報が少ない気がする。 とりあえずrakeでビルドとTestFlightへのアップロードを自動化したけど、けっこう時間がかかった。
Rakefile for building and uploading to testflight
iOSはAndroidとくらべてUIがキレイというのはある。 だけど、Android2.3なんかと比べるとそうだと思うけど、4以降になるとそんなに気にする程でもなくなったと思う。
今のところiPhone5を使っているけど、片手で使えるNexusシリーズが出たらAndroidに乗り換えると思う。 Android端末はデカすぎる。日本のメーカーはあれだけ小型化・薄型化が好きだったのに、 なんでスマホになると大型化するのか意味がわからない。
