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端末はデカすぎる。日本のメーカーはあれだけ小型化・薄型化が好きだったのに、 なんでスマホになると大型化するのか意味がわからない。

退職のお知らせ

3月末をもって、アルバイトの頃から約2年ほど勤めていた会社を退職することになりました。アルバイトの頃はRailsでサーバーサイドの開発を担当し、大学卒業後は正社員としてAndroidアプリとiOSアプリの開発を担当しました。未経験の自分にアプリ開発を任せていただけて、いろいろな面で勉強させていただきました。

4月からは、これまでとは違うフィールドで働く予定です。偶然に偶然が重なって(このブログもきっかけの一つ)、以前から興味のあった領域に携われることになり、この度転職を決意しました。これまた未経験の領域に飛び込むことになるので、これから必死に勉強する必要がありそうです。ですが、この約2年間でずいぶんと未知の領域にチャレンジしてきたので、その経験と身につけた自信でこれからも頑張っていけそうです。

これまでお世話になった皆様、有難うございました。今後とも宜しくお願い致します。

人間の脳みその限界とツールについて

複数の設定があり、それらの組み合わせによって挙動が変わるアプリを書いていると、だんだんそれぞれの組み合わせについて頭がこんがらがってくる。コードを修正するたびにそれぞれの組み合わせについて、どのように影響が出るか考えなければならなくて、つらくなってくる。つらいだけでなく、確実にミスが生まれる。

こういう状況が続くと、人間の脳みその処理能力について限界を感じてくる。人間はこういうことに向いていないと思うようになる。人力によるチェックにも自信が持てなくなる(そして、それでいいのだと思うようになる)。人間の脳みそに限界を感じるようになると、ツールに頼りたくなってくる。限界を感じることで自分自身に対して謙虚になり、ツールの使い所を実感するんだと思う。

例えば、脳内で多数の組み合わせをシミュレーションするのをやめてプログラムにテストさせるとか、手でひとつひとつ丁寧にメソッド名を置換するのをやめて、Eclipseに任せるとか。何度も同じコマンドを手打ちするのをやめてシェルの補完を使うとか。あと、publicなメソッド・プロパティを必要最小限にすれば、そのクラスを使う人は考えることが減るんだから、public/privateという概念も脳みその負荷を減らす工夫なのかもしれない。

とにかく、脳に強いストレスを感じたら、たぶんその作業は人間には向いていないと思うので、ツールに任せられないか一回検討した方がいいと思う。もっと自分の脳みその能力を疑った方がいいと思う。

ハッカソンでgithub連携のnode.jsアプリ作った話

疲れたので手短に。

土日2日間ぶっ通しのハッカソンでnode.jsを使ったgithub連携アプリを作った。仕事はRailsで、まともなアプリをnode.jsで書いたことなかったし、せっかくだからnode.js使ってみた(っていうか、勝ちに行っても勝つ見込みないから、楽しむことに専念した)。

ソースコードはこちら。

https://github.com/naoty/arounds

Express 3.x, MongoDBでHerokuにデプロイしてます。

github認証

認証ライブラリはいろいろあるようだけど、Passportを使ってみた。github認証したい場合はpassport-githubというものがあるので、それを併用する。使い方は載ってるので割愛。

まだnode.jsでのセッションの取り扱いとかちゃんと理解してないから、passport.serializeUserらへんがよくわかってない。

mongoose, MongoLAB

MongoDBのORMとしてmongooseを使った。Heroku上のMongoDBにはMongoLABを使った。ブラウザからコレクションの中身とか見れるのでよかった。

$ heroku addons:add mongolab:starter

環境ごとの設定

github APIのclient IDやDBのホストのために環境ごとに設定ファイルを用意した。

// app.js

require config = process.env.NODE_ENV == 'production' ? require('./config/production') : require('./config/development');
// configs/production.js

module.exports = {
    github: {
        clientID: process.env.GITHUB_CLIENT_ID,
        clientSecret: process.env.GITHUB_CLIENT_SECRET,
        callbackURL: process.env.GITHUB_CALLBACK_URL
    },
    mongodb: {
        path: process.env.MONGODB_URI || process.env.MONGOLAB_URI
    }
};

本番環境ではAPIキーをHerokuの環境変数を経由して参照する。

// configs/development.js

module.exports = {
    github: {
        clientID: 'GITHUB CLIENT ID',
        clientSecret: 'GITHUB CLIENT SECRET',
        callbackURL: 'http://127.0.0.1:3000/auth/github/callback'
    },
    mongodb: {
        path: 'mongodb://localhost/arounds'
    }
};

ソースコードを公開する場合は、APIキーを隠すためにconfig/development.jsを.gitignoreに追加しておく。

まだよくわかってないこと

とりあえずnode.jsでアプリを作ってみてわかんなかったところをメモ。

MVCな書き方

Expressは放っておくと、ルーティングやルーティングに対するアクション、モデルの定義などいろんなものをapp.jsに書くことができてしまう。viewは分かれてるけど。Rubyで言うと、RailsよりはSinatraが近い。簡単なアプリケーションなら1ファイルにまとめてしまった方がラクかもしれないけど、すぐにMVCが崩壊してしまう。

また、socket.ioを使ったコードを書くとき、view側のjavascriptにも複雑なロジックを書くことになる。

コールバック地獄

上のにも関連するけど、あっという間にコールバック内にコールバックを書いて、その中にコールバックを書くケースが出てくる。deferというものを教えてもらったので、それ使ってみたい。

ミドルウェア

app.use()みたいなのがたくさんあるけど、あれらが何をやってるのかまだよくわかってない。express newすると勝手にできてしまうから、あんまり意味を考えなくても動く。express newに頼らずに書いて覚える。

東京Ruby会議10にいってきた

1/13, 1/14に千葉で行われた"東京"Ruby会議10にいってきた。

受付でまず渡されたのが、砂浜でMacを開く謎のバッヂ×4(後にささたつバッヂであると知らされる)。幸運にも、受付から3時間程度でバッヂをコンプし、レアバッヂをゲットできた。最初はよくわからなかったけど、楽しかった。スタッフの皆さんが楽しんでるのが伝わってきてよかった。

内容はというと、個人的にはmrubyの話がよかった。ルーターのこととかはよくわからなかったけど、組み込み機器の世界はまだまだレガシーらしく、mrubyにかかる期待は大きいみたい。"Internet of Things"的なことに興味があるので、CとかC++とかやる必要あるのかなと思ってたけど、mrubyでできるならmruby身につけたい。mrubyでつくられたスマートなルーターは実用性がありそうなデバイスでよかった。僕もmruby覚えて、一発ネタじゃない実用的なデバイスつくってみたい。mruby興味あるけど、どこから始めていいかよくわかってないので、なんとかしたい。

あとは、これまでTwitterでのみ知ってた方と初顔合わせできたのがよかった。#p4dをはじめ、コミュニティの楽しさも再確認できた。ひきつづき何かしらのコミュニティに参加したい。

2日目は大雪で途中で中断してしまったけど、スタッフの皆さんの英断のおかげで何事もなく帰宅できました。有難うございました。

2012年の振り返り・2013年の目標

KDDIの障害が復旧するのを見守るハメになったので、それまで2012年の振り返りをしようと思う。

2012年の技術面での目標は「iPhoneアプリをリリースすること」だったような気がする。これは無事に達成できた。おまけにAndroidアプリもリリースできた。あと、いくつかRailsでサービスをつくった。特にcui-about.meはなかなか好評で、海外の方にも使っていただいた。使ってもらえるサービスを作ったということも大きい成果だったと思う。覚え始めてもう2年くらいになるRailsでは、特にRSpecを書けるようになったことが一番の進歩だったと思う。まあ大半がAndroidかiOSを書いていたので、そこまで大きい進歩はなかったんだけど。最近はnode.jsをちょっとやり始めて、だんだんとわかってきたところ。Arduinoも買ってみて、ハードウェアに強い興味がでてきた。

総括すると、未知の領域にどんどんチャレンジできた年だった。

2013年の目標は「ハードウェアを開発すること」にしようと思ってる。ハードウェアといってもいろいろあるけど、とりあえず製品として売れるものを開発したい。いま一番興味があるのはハードウェアで、特にモノとモノとがインターネットにつながった未来に興味がある。Webサービスやアプリの開発自体もすごく楽しいんだけど、これまでの路線から想像がついてしまう未来ではなく、一歩先の未来を実現できるエンジニアになりたいと思う。そのために、これまでとはまったく異なる領域にチャレンジしたい気持ちが強い。2013年は2012年よりもっと大きくステップアップしたい。

HTMLも分からないまったくのド素人だった2年半前からここまで来れたという事実は今ではすごく自信になっていて、新しくチャレンジすることにポジティブになれる。今年だって、iPhoneアプリだけじゃなくAndroidアプリも作ることができて、さらに自信につながった。だから、来年もまた大きなチャレンジをしたいと思う。毎年そうやってチャレンジを繰り返して成功体験を重ねていけたら幸せだなぁと、年の瀬にしみじみ思いました。

今年お世話になった皆様、ありがとうございました。来年も宜しくお願い致します。よいお年をお迎えください。

Qiita Hackathon参加してきました

Qiita Hackathonに参加してきました。

HeartBeat」というアプリを7時間あまりで作りました。Androidの加速度センサーとnode.jsを使ったアプリで、スマホの振動を定期的にサーバーに送信することで、その人の活動状況(生きてんのか、死んでんのか)をリアルタイムに把握できます。毒のあるデザインが味わい深さを際立たせています。

f:id:naoty_k:20121208234807g:plain

↑スマホの振動によって生死を彷徨う様子がリアルタイムで更新される図

結果的には入賞を逃しましたが、得ることが多かったのでメモを残しておこうと思います。

技術的なアレコレ

  • 時間節約のために使ったLoginActivityのテンプレートが便利だった。ログイン画面が一瞬でできあがった。バリデーションや非同期処理も完璧に書いてあって、UIもキレイな優れもの。これはいい教材になりそう。
  • 加速度センサーをネイティブで実装したけど、他のチームがHTML5+JSで実装していた。HTML5でできることを知っていれば、Javaはいっさい書かずにこのアプリできた気がする。日頃ネイティブで開発しているせいか、HTML5についてまったくといっていいほど関心がなかった。反省。
  • 僕たちのチーム以外にも「加速度センサー+リアルタイム」なアプリがいくつかあった。やはり、node.jsのようなリアルタイムウェブの技術があると、実現できるアイデアの幅が広がると改めて感じた。やりたいとは前々から思ってたけど、その優先度を上げようと思う。
  • DeployGateマジ便利。TestFlightもかなり便利だったけど、それ以上に使いやすかった(iOSはAndroidより配信までのプロセスが多いことが主因だけど)。デプロイまでのプロセスがとても短い。よく考えられてると感じた。ただ、うちの会社で使うかはちょっと微妙かもしれない。配信だけならJenkinsを使って簡易な仕組みはできそう。たくさんの端末で検証する場合であれば、各機種の詳細なログがほしいのでDeployGate使うと思う。

ハッカソンについて

  • ハッカソンではWebViewを使うのが簡単で速いと思った。
  • ハッカソンでよくやるミスとしては、ログイン/サインインの実装に時間をとられること。本来作りたい機能以外で時間をとられて悲しくなる。やめよう。ユーザーはHTMLでいるっぽい感じにしちゃえ。作りたい機能に集中した方がいい。
  • ハッカソンのいいところは、いろんなアプリの実装方法をその場で知ることができる点にあると思う。同じようなアプリでもネイティブで作るチームとHTML+JSで作るチームがある。出来上がりを見ても、そこに大差はない。いろんな実装方法を知ることで、選択肢が広がり、目的に対してより適切な選択ができるようになると思う。