読者です 読者をやめる 読者になる 読者になる

ナカザンドットネット

Android Developer's memo

Code for Niigata 真夏のハッカソンに参加してきたよ #c4ngt

Code for Niigataのイベントがあったので参加してきました。

8/1-8/2に「真夏のハッカソン!」( #C4NGT )を開催します!! | Code for Niigata

前夜に突発的に参加を決めたため 家庭の都合により、2日間構成の1日目のみの参加となりました。しかも、

出入り自由ですので、ご都合の良い時間のみの参加でも全く問題ありません

と書いてあったので、完全に鵜呑みにして、13時から18時までという中途半端な時間だけいた感じでした。(自分が一番半端かと思ったら、夕方に1時間だけいた @ パイセンのほうが半端だったのでちょっと安心した)

色々と雑多に感想を書いていこうと思います。

会場について

f:id:Nkzn:20150802000042p:plain

http://tsubamesanjo-style.jp/

今回のイベントは、昨年の秋にオープンした、燕三条トライクというシェアスペース(コワーキングスペース?)で行なわれました。知りあいづてに存在は知っていたのですが、行くのは今回が初めてです。

感想としては、めっちゃ雰囲気のいい古民家でした。*1

f:id:Nkzn:20150801235824j:plain f:id:Nkzn:20150802000537j:plain

このへんについては、 id:kedamatti さんがいい感じに紹介してくれています。

kedamatti.hatenablog.jp

周辺のお店で売っているソフトクリームとかシュークリームも美味しかったので、機会があればまた行きたいなあという感じです。

内容について

私は昼からの参加だったのでぐだぐだしてましたが、朝からいた方々はいちおうテーマを持って何かしてたみたいです。

  • 2日目テーマに合わせて、トマソンレーダーを作る
  • 新潟県内のIT勉強会の紹介や、IT勉強会カレンダー的なことをするハブサイトを作る

この辺ですね。ハッカソンというよりは、団体の活動としての開発のキックオフイベントみたいな感じになってました。私はどちらにも属さず、新潟ラーメンバトル2015アプリ用サーバーのためのお勉強をしていました。

ちなみにトマソンってこんなの。

matome.naver.jp

余談ですが、2日目は新潟市内のトマソンを探しに行くみたいです。

あとは、ミニセミナーが2本ありました。

  • jQueryについて
  • サイボウズ Kinotoneについて

軽く感想を書きます。

jQueryについて

jQueryの文法をひたすら並べていくやつでした。動画によるデモもあったようなのですが、機材トラブルにより見れず残念。

網羅性は高かったのですが、正直これなら本とか公式ドキュメント読むぜ的な内容でした。分量を10分の1にしてもいいので、もっとハンズオン的な要素があるといいなあと思いました。

ハンズオンが来るものだと思って、話を聞きながら手元のAtomでjQuery+TypeScript環境を作っていた身としては、ちょっと寂しかった・・・。

あ、スライドの中に @ さんが出てきたのは笑った。講演者の方がng-japanに行ったときに一緒に写真撮ってもらったそうです。

Kintoneについて

kintone.cybozu.com

  • 表構造を作成済みのExcelをアップロードすると、データベースなアプリケーションができるよ
  • 顧客にとってどういう価値になるのか
  • 作り手にとってどういう価値があるのか

といったことをお話ししてもらえました。キントレンジャーというエヴァンジェリスト活動をしている方だったので、実務を踏まえた具体的な内容でした。

kintoranger.jp

「地方の中小企業が期待しているシステム作りというのは、ちゃんと見積もってみると、期待されている金額と1ケタ違うこともある。そういうときに、あまり複雑ではないシステムであれば、Kintone製のシステムにすることで、期待通りの予算で実現できることも多い」という話は最近身に覚えがあったので、強く関心を持ちました。

参加者からも活発に質問が出ており、他の人の関心の強さも伺えました。初出の頃はトンデモ系サービスだと思って敬遠してたんですが、どうやら結構実用的なものになっているようです。

私が一番関心を持った用途は、「Excelで表を作ってアップロードすると、Web上にその内容のデータベースができて、さらにWeb APIまで用意される」という特徴です。まあ、Web APIといってもデータの特製ごとにまとまったエンドポイントができるとかそういうものではないのですが、モバイルチームでプロトタイプ開発をしているときにちょっとしたサーバーを用意するには、すごくいいよなあと思った次第です。

会社でKintoneのスタンダードプランを1アカウントくらいとってくれないかな。1契約で1000アプリ作れるみたいだからガンガン使ってみたい。

私の本日の成果

f:id:Nkzn:20150802004855p:plain

今年こそ、新潟ラーメンバトルアプリに入力した食べ歩きデータをWeb上に置いてランキングページとか作りたいなとか思っておりまして。Web APIサーバー作れないかなーという試行の一環として、AWSのLambda + API Gateway + DynamoDBでWeb API作ってみよう的なことをやっていました。

参考というか丸パクリしたのは、以下の記事です。

mizukisonoko.hatenablog.com

ちょっと時間内におさまらなくて、家に帰ってからもしばらく取り組んでいたんですが、ようやくそれっぽいものが一つできました。node.jsコードだけは微妙にうまく真似できなかったので、blueprintを改良する形でなんとか乗り切りました。

var doc = require('dynamodb-doc');
var dynamo = new doc.DynamoDB();

exports.handler = function(event, context) {
    var params = {
        TableName: "Test",
        Key: {
            id: event.id,
            category: "admin"
        }
    };

    dynamo.getItem(params, context.done);
};

id:mizukisonoko 版との大きな違いは、DynamoDBへのアクセスに使っているライブラリです。あちらはrequire('aws-sdk')でしたが、こちらはrequire('dynamodb-doc')ですね。DynamoDBの操作に特化したライブラリのようです。

github.com

おかげさまでなんとなくAWSづくしのWeb API作成の方法が分かってきたので、今後またしばらく弄ってみたいと思います。

そのうち、この辺の取り組みもC4Nで発表したいなあ。

どっとはらい。

*1:元商店らしいので、古「民家」ではないのだけれども

Icepickにノスタルジックな変更が入りました

ポエムです。

皆さん、Icepickをご存知でしょうか。ActivityやFragmentに書いたプロパティをSavedInstanceStateで保存/復元する責務だけを持つ、アンチAndroidAnnotations界隈では人気のあるAndroid向けライブラリですね。

このIcepickに、下記のコミットが行われました。

github.com

さよなら、@Icicle。

分かる人には分かる、寂しい変更です。この記事ではAndroid界の老害たちに向けて、昔を懐かしむ話をしたいと思います。

何が変わったのか

これまでのIcepickは、@Icicle アノテーションを付加することで、状態保存の対象を指定していました。

class ExampleActivity extends Activity {
  @Icicle String username;
  ...
}

しかしこれからは、代わりに@Stateアノテーションを付加することになります。

class ExampleActivity extends Activity {
  @State String username;
  ...
}

Icepickがやりたいことは、 onCreateonSaveInstanceStateonRestoreInstanceState などで行われる、savedInstanceStateに対するI/O操作の簡略化です。この責務において、この名称変更は理に適ったものと言えるでしょう。

Icicleという名前の由来

そもそも、Icicleという言葉はどこから出てきていたのでしょうか。それを説明するには、Androidクロニクルにおける紀元前、Android 1.0より前の時代まで遡らなくてはなりません。

Significant API Changes
onFreeze(Bundle) renamed to onSaveInstanceState(Bundle), to better reflect the fact that it does not represent an actual change in application lifecycle
Release Notes for Older SDK Versions | Android Developers

Android 0.9 SDK Beta (r1)での代表的な変更の中に、

  • onFreezeonSaveInstanceState に改名

というものがありました。そしてこの頃、onCreateは下記のような形でした。

@Override
protected void onCreate(Bundle icicle) {
    super.onCreate(icicle);
    setContentView(R.layout.any_layout);
}

現在では savedInstanceState と記されている場所に、 icicle (つらら)の名を冠した変数が置かれていたのです。

おそらくは、「onFreezeで凍らせた"状態"が、onCreateでつららのように上から降ってくるよ」というニュアンスだったのでしょう。

Icicleの時代

日本にAndroidが上陸した2009年時点では、既にAndroidのバージョンは1.5 Cupcakeになっていました。もちろん、onFreezeはとっくに滅びています。

しかし、何故か、その名残はしばらく残っていたのです。

stackoverflow.com

2009年のStackOverflowに、ハッキリとicicleの文字が載っていますね。また、2011年終盤の時点でも、Android Maps周りには古いコードが残っていたようです。

それらもいつしか savedInstanceState へと置き換わっていき、 Icepickが故人を偲ぶように@Icicleを残し続けるばかりとなっていました。

さよなら、Icicle

Icepickが@Icicleを捨てたことで、恐らくAndroid界隈からicicleという言葉はほとんど消えてなくなるでしょう。機能の命名は過度に詩的であってはいけません。寂しさはありますが、Icepickにとっては、@Stateが正しいのです。

さようなら@Icicle。いままでありがとう。僕たちはこれからも頑張っていくから。見守っていてください。

あとがき

  • そういえば俺、Icepick使ってるプロダクトないなー(
  • それにしても、ButterKnife 7.0の件といい、Robolectric 3.0の件といい、命名の見直しが流行ってるんだろうか。

読み書きソロバンから、読み書きコンピュータへ

BBCさんの取り組みがあまりにもアツくて、ちょっと気持ちが盛り上がってしまったので、今回は珍しく、かなりポエミーな内容を書きたいと思います。

読み書きソロバンの時代から、読み書きコンピュータの時代へ。

英国BBC、ミニ基板コンピュータ『Micro Bit』100万台を無償配布。中1生全員にコーディング教育 - Engadget Japanese

全ての人がコンピュータを自在に操れる数十年後の世界に向けての取り組みが、どんどん増えてきています。

Scratch - Imagine, Program, Share

Kano - Make a Computer

こういった取り組みへのコメントを見ていると、「普通の人がコンピュータを覚える必要なんて無い」と言った意見を見かけます。これは、昔の下流階級の人々が「普通の人が文字を覚える必要なんて無い」と言っていたのと同じことだと、私は思ってます。

手紙を書くにも、文字の読み書きができる人を探してきて、お願いするなりお金を払わなければいけなかった時代。現代の、プログラミングができる人、できない人の関係と似ていますね。

プログラマーは職を失うのか

(私はプログラマーなので、ここから先の話はプログラミングに寄ります。コンピュータの広大な分野の中から一部分だけをピックアップすることをお許し下さい。)

こんな話をすると、「普通の人がプログラミングできるようになったら、プログラマーが職を失うじゃないか」という話が出てきますが、そうです、一般の人々が最低限作れるような、メモ書きレベルのプロダクトしか生み出せないプログラマーは職を失います。代筆を生業としていた人々も、同じく職を失っていったのでしょう (要出典) から、自然な流れです。

では、文章を書くプロの仕事はなくなったのでしょうか。そうではないのです。 作家、記者、詩人、作詞者、脚本家。現代でも、文章を書くことを生業にする人たちは、確かに残っているのです。

プロであるということ

プログラミングによってものを作る職業は、きっと無くなりません。

ですが、おそらく、他人に頼まれたものをそのまま作る、という仕事は、少しずつ少しずつ、なくなっていくのでしょう。だって、ちょっとしたものならば、世間一般の(私達の子の世代や孫の世代の)人々は、自分で作れてしまうのですから。現在でも、Excelを上手に扱える人々は家計簿ソフトなどを買うことなく、家計簿を電子的に作成・集計できている*1ことを考えると、その片鱗は少しずつ現れているとも言えます。(Excelの式を書く作業は紛れも無くプログラミングです)

基板となる技術が一般に普及した後にも、生業としてお金を稼ぐことができるのは、その技術を「上手く」使って、他人にとって価値のあるものを生み出せる人です。私は、そう思っています。

識字率の上昇に伴い職を失っていった人がきっといたように、識コンピュータ率の上昇によって、職を失う人々が出てきます。でもきっと、その後にプロの仕事として残ったものが、プログラミングの、エンジニアリングの、本質的な価値なのではないでしょうか。

10年後なのか50年後なのか分かりませんが、そんな時代がいつかやってきます。

その時に向けて、エンジニアとしての自分の価値を、見直し続けていけたらいいなと、そんな風に思うのです。

どっとはらい。

反省会

タイトルはソロバンとコンピュータの対比みたいになってたのに、実際には識字率にしか注目していなかったことに書き終わってから気がついた。まあ寺子屋教育が日本にもたらしたもの的なニュアンスでなんとか。

*1:もちろん、クラウドにアップロードしたりといった付加価値の点では、市販のものに分があります

勉強会の発表下書きにQiitaを使うスタイル

第40回勉強会(2015/02/21) - 長岡 IT開発者 勉強会(NDS)

第40回 長岡IT開発者勉強会に参加した皆様、お疲れ様でした。初心者Dayという名前ながら知見にあふれた良いイベントだったと思います。

さて、私は「Android再入門 〜Eclipseのことは忘れろ〜」と銘打ち、Android初心者向けにネット情報の取捨選択を行うにあたって考慮してほしいことを発表しました。

また、今回は講演内容をQiitaに下書きして、勉強会と同時に公開するという初めての試みも行いました。

Android再入門 〜Eclipseのことは忘れろ〜 #nds40 - Qiita

1週間で400ストックという凄いペースで伸びていて、承認欲求が大幅に満たされつつもビクビクしている日々です。

この記事では、今回試みたことを簡単に紹介したいと思います。

公開までの流れ

  1. 初期構想
    • Android Studio便利だよ!
      →でも情報が氾濫してるね
      →初心者向けに1度整理しよう
    • Eclipseへのdisはうっかり紛れ込んだだけで本筋ではないのです
  2. 全体構想
    • 概要(見出しレベル)をMarkdownでゴリゴリ書く
  3. 原稿作成
    • ↑に肉付けしつつ、Qiita向けの技術記事として当たり障りなさそうな体裁の文章をKobitoで書く
  4. スライド作成
    • 「原稿の内容を喋っている時に背景として表示されていてくれると嬉しいスライド」という観点でスライドを作成する
  5. 勉強会中にQiitaに原稿を公開
  6. 勉強会でセッションを発表
  7. 発表しましたレポとともにスライドを公開(本記事)

この順でやってみて、全体的には良かったと思っていますが、もちろんデメリットもありました。それぞれ紹介します。

悪かったこと

二度手間

単純に数だけ見れば資料を2本仕上げたことになるので、作業量としてはただスライドを作るよりも少し重くなりました。とはいえ、倍という程ではなかったと思います。

分量が測りづらかった

スライドだけを作っている分には、枚数を見ながら「1枚○分ずつは喋れるな」のような算段ができたのですが、Qiita向けの原稿を書く体で作っていると、実際に喋るときの分量が想像しづらく、作りすぎてしまいました。(実際に、15分枠だったセッションを30分枠に変更してもらうことになりました)

良かったこと

テーマの深堀りができる

技術記事として成り立つものにしようというスタート地点で原稿を書き始めると、スライドにキーワードを書き連ねていくよりも具体的に発表テーマについて検討することができます。また、スライドに比べて1つの見出しに書ける一連の情報を大きくできるため、情報に深みを持たせることができました。

細かい話題まで入った資料を公開できる

勉強会の後にSlideShareSpeaker Deckに資料を公開して、当日会場にいた人やいなかった人が見れるようにすることは一般的になってきています。公開を前提にしてスライドを作成する講演者も多いのではないでしょうか。

資料の公開自体はありがたいのですが、少し困ったことが起こります。喋る内容を概ね再現した資料を作成しなければならなくなるのです。講演者が読みながら喋るための「原稿としてのスライド」は、聴き手が読むことに集中してしまい、肝心の口頭の話を聞けなくなってしまう危険性を帯びています。

私の感覚では、講演スライドには2種類あります。

  • 資料としてのスライド
    • 後日読む分には、情報量も多く発表内容が伝わってくるいい資料になる
    • 会場にいると文字を追うのと話を聞くのが同時進行になって大変
    • MSの講演でよく見かける
  • 背景としてのスライド
    • その時喋っている内容を象徴するキーワードだけが載っているスライド
    • 聞き手が読む文字が最小限になり、話を聞いてもらいやすくなる
    • ジョブズ的なアレ

この2つのどちらを採用するかは、現場での読みやすさと公開時の資料としての価値を天秤にかけることになり、非常に悩ましいところでした。

ですが、今回のように「資料としての内容はQiitaに投稿する」と最初から決めてしまっていれば、迷う必要はありません。スライドだけなら冗長すぎて書けなかったような余談も含め、話題をガンガン深めていくことができます。

深めすぎた結果、喋れない分量になったらどうするって? そうなったらスライドを作るときに推敲して、省ける項目を原稿から省いてしまえばよいのです。

スライドがすっきりする

前述のとおり、「資料としてのスライド」を作る必要性が薄くなったので、「背景としてのスライド」に寄せられるようになりました。

文章量は極力抑えてみたところ、これまでのイベントでの講演に比べて、聞き手の目が僕に向いている時間がとても長かったように思います。ただ、当の僕が練習不足で、別途カンペを見ながらでないと喋れない状態だったので、聞き手のほうを見ながら喋ったりができなかったのが悔やまれます。

スライド作りにはそこまで時間がかからない

原稿にある内容を表現すればいいという性格上、新しくネタを考える時間は取られませんし、文章量も原稿に比べればかなり少ないです。そのため、原稿+スライドでかかる時間は、中身を悩みながらスライドだけを作る場合の1.5倍程度の時間でできるのではと思います。

まとめ

Kobitoで重厚な原稿を書いて、軽いスライドで発表して、Qiitaに公開する。このサイクルで、公開スライドが抱えていたジレンマが少し解消されそうです。

スライドだけを作ると話題が中途半端になってしまうような感覚を持っている方は、是非このスタイルを試してもらえればと思います。

宣伝

ウォーターセル株式会社では、農業分野でのITツールの開発・改善に一緒に取り組んでくれるAndroidエンジニアを募集しています。

農業IT分野がどんなものなのか話を聞いてみたいレベルでも結構ですので、興味のある方は@まで空リプを飛ばすなり何なりして、コンタクトを取っていただければと幸いです。

スティーブ・ジョブズ 驚異のプレゼン

スティーブ・ジョブズ 驚異のプレゼン

Android版ChatWorkアプリ内で使われているOSSを眺めてて見つけた15のライブラリ

12/10に、ビジネス用途向けのチャットサービス「ChatWork」のAndroidアプリが大幅リニューアルされました。

チャットワーク社といえば、国内有数のTitanium Mobileをガッツリ触っている会社としても有名ですが、今回のリニューアルではAndroid SDK + Javaによるネイティブ化を断行したようです。(ツール選びに関する感想は最後に書きました)

というわけで、Facebookアプリのときに続きまして、OSSライブラリのライセンス一覧を眺めていたら面白かったので、各ライブラリに感想を入れていきたいと思います。

ActiveAndroid

クックパッドAndroidアプリにおける最近のDB運用事情 - クックパッド開発者ブログ

クックパッドでも採用されて、苦しみの声が上がっているやつです。弊社では少し実用した後でContentProviderとの相性が死ぬほど悪い(検証当時)という理由でリプレイスしたことがある思い出深いライブラリでもあります。

現在ではContentProvider対応のPullReqがマージされたので、そのへんは解決されていると思われますが、作者が「5年以上ActiveAndroidやってきたけどさー、今の設計だとコレ以上パフォーマンス出ないんだよね。だから発想変えて別のO/Rマッパー作るわ!」とかぶっちゃけてて、今後の開発どうなるんだろう、と不安になるところです。 ただ、当のOllieとやらも数ヶ月更新が無いので、pardomさんが何かの拍子に我に返ったという可能性もあります。 (2015/1/19訂正:別ブランチで作業をしていただけなのか、全然活発に開発してらっしゃいました。)

後述のRealmと用途が被ってる部分もあるので、何と使い分けてるのかなという気持ちもあります。

とりあえず、O/Rマッパーとしての使い勝手や、クエリの発行しやすさで言えばORMLiteよりも楽な気がするので、良いライブラリだと思います(こなみ)

Android Priority Job Queue (Job Manager)

今回初めて存在を知ったやつです。やたら動く(+)ボタンで一世を風靡したPathが公開しているライブラリなんですね。

順番に実行したいタスクをAsyncTaskとかLoaderとかServiceとかで実装するのは大変手間なので、良い感じに順次実行してくれる的なやつでしょうか。便利そうです。

Butter Knife

安定のJW。(広義で)Squareからの刺客その1。

アノテーションによるfindViewByIdsetOnClickListenerの簡素化といったどこか聞いたことのある機能を提供してくれるライブラリですが、他のライブラリに比べると責務を絞ってあり軽量であるという印象があります。

今度弊社でも採用しようかなと思っているところです。

というかAndroidAnnotationsは重厚すぎて全力でロックインする覚悟がないと採用しづらいし、RoboGuiceはスーパークラスを汚染するしで他に選択肢がない

Chunk Templates for Java

今回初めて知ったやつです。

Java向けのHTMLテンプレートエンジンらしいです。このへんを見ると分かりやすいでしょうか。WebViewに表示を任せている部分があるということだと思います。

EventBus

出た!死ぬほど便利なやつ!

従来はBroadcast Intent+BroadcastReceiverなどで実現していた「ある場所から別の場所へイベントを通知する」という目的を良い感じに果たしてくれるライブラリです。一説では、Fragment→Activityの通知や、Service⇔Activityの通信はもう全部これでいいんじゃないかという話もあります。

もちろん飛び道具の類なので、多用すると状態が増えすぎて死ぬ危険が増しますが、適切に使えば強い味方になってくれるはずです。

FloatingActionButton

チャットワークアプリの新UIの中で、一番おもしろかった部分です。

今回のリニューアルの目玉の1つがMaterial Designへの対応でしたが、その中でもFloating action buttonの実現にフォーカスしたライブラリがこちらになります。

他にも makovkastar/FloatingActionButton(★1024) や FaizMalkani/FloatingActionButton(★450) がある中で、このライブラリが選ばれたのは、ボタンが増えるアニメーションの面白さでしょうか。

image

実際、チャットワークアプリの新UIをひと通り触った時は、僕もこの(+)ボタンを連打してしまいました。楽しいです。

しかしこれ、近いうちにappcompat-v7でサポートされて、リプレイスするかどうかの選択に迫られそうだなあ。ActionBarSherlock(→ActionBar)やViewPagerIndicator(→PagerTabStrip)が通ってきた道ですね。

Icepick

SavedInstanceStateを扱うのをちょっと楽にしてくれるライブラリみたいです。Android 1.6くらいの時代に使われていたIcicleという言葉が使われていて、古参の琴線をフルスイングで殴ってくる感じのライブラリになっています。

AndroidAnnotationsにも@InstanceStateっていう似たようなアノテーションあるけど、たぶんIcepickのほうがいい。

Joda-Time

java.util.Calendarがアホみたいに使いづらいのを何とかしてくれる神ライブラリ。あまりにも神すぎて、JDK1.8ではJoda-Timeにインスパイアされた形で"Date and Time API"(JSR-310)というのが入ったりしました。

参考: http://acro-engineer.hatenablog.com/entry/20130213/1360691391

ちなみに内部のメソッド数が4611個とかある(当社調べ)ので、dexのメソッド数65536上限問題に立ち向かうときには少しお気をつけて。

jQuery

言わずと知れたJavaScriptライブラリ界の巨人ですね。Chunkと組み合わせてWebViewに使っていると予想されます。

json-simple

公式のorg.jsonをシンプルにしたやつらしい。

たまにorg.json.JSONObjectorg.json.simple.JSONObjectが紛らわしくてアレなイメージしかないんだけど、動作が速かったりするんだろうか。

OkHttp

Squareからの刺客その2。お手軽な使い勝手のHTTPライブラリ。

現状、AndroidSPDYプロトコルが使える、数少ないネットワークライブラリなので、近年いろいろなところで重宝されているようです。

Picasso

Squareからの刺客その3。素晴らしい画像読み込みライブラリです。

URL, Drawableリソース, java.util.Fileオブジェクトなど、様々な形で画像を指定すると、とりあえずロードしてきてImageViewに放り込んでくれる素敵なライブラリです。画像表示はこれがないとやっていられません。

内部でOkHttpを全力で使って、画像のキャッシュにも対応しています。

Realm (realm-java)

iOSのCoreDataやSQLiteを置き換えるために生み出されたという、C++RDBMSライブラリですね。

@さんがたまに 言及しておられるような印象があります。

ActiveAndroid的なクエリ発行の使い勝手の良さも感じますし、速度が凄いとのことなのでちょっと興味はあるんですが、流石にプロダクトに使っていい品質ではないだろうなあと邪推して、今のところは手を出していません。

流石チャットワークアプリさん、チャレンジャーだぜ!

と思っていたんですが、チャットワークアプリver3.0.3ベースで本記事を書き始めた後、ver3.0.4でRealmがライセンス一覧から消えました。どうやらRealmを使うのをやめたようです。

やはり人類にはまだ早すぎたのでしょうか。

Secure-preferences

SharedPreferenceに保存するKey, Valueそれぞれを256-bit AESで暗号化してくれるやつだそうです。自分でやるよりは楽そうですね。

TimesSquare for Android

Square最後の刺客。カレンダーライブラリです。

おしゃれ感ありますよね(小並感)

まとめ

ちょいちょい攻めてる感じのライブラリ選定をしていてアツいなと思いました(既に1件思い直されていますが)。ただJSON周りはJsonPullParserとか使うと型安全にマッピングできていいんじゃないかなと思ったり(ステマ

あとやっぱりSquare社とJWに足を向けて寝られないことになっているアプリって多そうだなと再認識したところであります。

その他、RoboGuiceやAndroidAnnotations重すぎてつらいということを再認識できました。

チャットワークさんは社内チャットとして大変お世話になっておりますので、今後とものご繁栄をお祈り申し上げます。改めまして、リニューアルおめでとうございました。

余談:発足初期の技術選択について

やっぱりクロスプラットフォームツールは保守が大変だったのかなあ、と邪推してはいるものの、「だったら最初からJavaで作ればよかったのに」とは思っていません。

恐らく、初期のメンバーのスキルセットの範囲で、最も早く顧客に価値を届けうる選択肢がTitanium Mobileだったのでしょう。

サービス発足初期は、迅速にプロダクト(≒価値)をユーザーに届け、使ってもらいながらサービスのどの部分の価値を最大限に高めていくのか見極めるのも、また1つの戦術です。

「顧客に本来届けたいもの」が出来上がるまで顧客に価値を全く届けないことより、80%くらいの中核となる価値を真っ先に届けた上で、フィードバックを得ながら時間をかけて「本来届けたかったもの」を届ける。外部から見て、チャットワーク社はこれを実践したように思います。

というわけで、現代のサービスの立ち上げ方、育ち方として、良い事例が1つ生まれたなあと思う次第でございます。

12/15 9:20追記

チャットワークCTOの山本さんも、似たようなお話を講演されていました。既に公知の話題だったことを改めて書いた形になって恥ずかしい(´・ω・`)

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み

自分がいなくてもうまくいく仕組み

TypeScriptの型定義が思ったより柔軟だった楽しい

TypeScript 1.0のリリースを機に、ちょっとJavaScript方面にも手を出してみようかということで、最近はわかめ本を読みながらチマチマとコードを書いております。

TypeScriptリファレンス Ver.1.0対応

TypeScriptリファレンス Ver.1.0対応

今日は技評さんのjQuery記事をTypeScriptで写経しながら読み進めていました。

もちろんjquery.d.tsを使って型チェックを利かせながらの写経です。メソッドがサジェストされるのもなかなか気持ちが良いですが、 ajax(settings: JQueryAjaxSettings) への渡し値であるJQueryAjaxSettingsがしっかり定義されているため、キーがサジェスト&プロパティ存在チェックされるわ、値に型チェックが入るわで、超気持ちいい感じです。

しかし、こうも型で守られた中で写経していると、むしろ型が付いていないところが気になってしまいます。特に今回の写経では、ジェネリクスが利いている each<T>(collection: T[], callback: (indexInArray: number, valueOfElement: T) => any): any; にany型のcollectionを渡してしまうのは、型の確定を心待ちにしているであろう valueOfElement さんにあまりにも申し訳が立たないと感じました。

というわけで、自前でインターフェースによる型定義を行ってみることにしました。YouTubeAPIから返ってくるJSONは、本来ならばそれなりに複雑ですが、今回の例に使う部分だけならば、下記のようなJSONを想定すれば充分でした。

{
  "feed": {
    "entry": [
      {
        "media$group": {
          "media$player": [{"url": "http://hogehoge"}],
          "media$thumbnail": [{"url": "http://fugafuga"}]
        }
      },
      ...
    ]
  }
}

で、実際に写経してみたのが以下になります。

YouTubeResponseFeedまでは真面目に書いていたのですが、途中から面倒くさくなってEntryインターフェースではエイヤッと超適当に書いてみたら通って逆にびっくり。構造的部分型の真骨頂を垣間見たような気がします。

そんなわけで、successに定義した関数は、JavaScript版と変わりなく書かれているように見えますが、

  • ジェネリクスによる型の確定(data.feed.entryEntry[]型であり、itemEntry型である)
  • 型チェック(group.media$playerは配列である)
  • パラメータ存在チェック(group.media$player[0]urlというパラメータを持つ)

のようなことがコンパイル時に行われています。タイポしたり、存在しないメソッドやパラメータを勝手に生やすと速攻で叱られるので、私のようなゆとりプログラマーでも安心してコードを書くことができますね。

まとめ

構造的部分型を活用してインターフェースを定義すると大変捗る!!!

おまけ

むりやり1つのインターフェースにまとめてみた。可読性はクソ悪い*1けど、TypeScriptの型システムとしては、これでもOK。

interface YouTubeResponse {
  feed: {
    entry: Array<{
      media$group: {
        media$player: Array<{url: string;}>;
        media$thumbnail: Array<{url: string;}>;
      };
    }>;
  };
}

*1:慣れるとそこまででもない?

僕がEclipseをやめてAndroid Studioを使っている10の理由

どうも、nkzn.netの更新を忘れてて転売屋に取られた人です。

今日はAndroid Bazaar and Conference 2014 Springですね。僕は業務都合的なアレで今回のABCに参加できないため、夜の裏会だけ行きます。

ただ、全くなにもしないのも寂しいので、景気付けに1本記事を書かせてもらいました。Effective Androidトラックの発表内容とネタ被りしたらごめんな!!

たぶん@とか@さんがこの記事より良いこと喋ってくれると思うので、みなさん秋葉原UDXで著者たちと握手!!(宣伝)

Effective Android

Effective Android

  • 作者: TechBooster,小太刀御禄,出村成和,重田大助,西岡靖代,宮川大輔,柏本和俊,あんざいゆき,八木俊広,木村尭海,小林慎治,有山圭二,中西良明,わかめまさひろ,新井祐一,桝井草介,久郷達也,寺園聖文,shige0501,山下智樹,前田章博,秋葉ちひろ,末広尚義,中澤慧,日高正博,塚田翔也,井形圭介,中川幸哉,山崎誠,山下武志,なまそで,橋爪香織,さとうかずのり,l_b__,ゼロハチネット,長汐祐哉
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2014/01/17
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (7件) を見る

はじめに

さて、ここ何ヶ月かで、「実際Android Studioどうなん」という質問を受ける機会が増えてきたので、ここらで一度、僕がAndroid Studioを常用していて嬉しいと感じていることを書きなぐってみました。

昨年11月から、業務で約4ヶ月使ってみての感想です。新人研修にも1ヶ月ほど使ってみています。

前半はどちらかというとAndroid Studioを使うことで利用可能になるGradleがいいよね的な話、後半はAndroid StudioというIDE自体の話です。

IntelliJ IDEA + Android Pluginでも同じようなことできると思うので、「IntelliJ IDEAを使うべき〜」に読み替えてもいいです。Android StudioをやめてIntelliJ IDEAを使うべき10の理由を書きたい人は是非お願いします!!!

※ここ4ヶ月、ほとんどEclipse+ADTの環境を触っていないので、「それEclipseでもできるよ!!!!」なことがあったらごめんなさい&お知らせください

1. Gradleが標準ビルドツールとして採用されている

この記事を書き始めたモチベーションはこれが8割です。でも書き終えてみたら愚痴ばかりであんまり面白くなかったので、読み飛ばして次へ行ったほうがいい気がします。

読み飛ばす方のための1行まとめ:Android Studioが標準対応しているGradleは、Androidアプリ向けのビルドツールとしてAntやMavenより柔軟で使いやすいので良いよ!!

原初の時代:Ant

Eclipse(というよりは、旧来のAndroid App Projectの構造)では、コマンドライン向けの標準ビルドツールがAntでした。で、Eclipseからならサクッとできる方法が、コマンドラインからだとクソ面倒くさかった印象があります。

模索の時代:Maven

ビルドプロセスやライブラリ依存性をもっと柔軟に管理したかった人々が次に手を出したのがMavenでした。MavenにはMaven Central Repositoryというライブラリ置き場があり、設定ファイルにライブラリ名とバージョンを記述することで、ライブラリをダウンロードしてきてプロジェクト内で利用できるという、バージョン管理システムに優しい感じの仕組みもあり、有望かと思われました。少なくとも、コマンドラインからビルドやテストが実行できるという点で、CIのしやすさという条件は満たしていました。

が、そもそもMavenの設定ファイルであるpom.xmlはちょっと闇が深い系のアレであったことや、公式ツールではないことによる不安定さ(環境を安定させるために熟練の業を要した)、環境構築の度にmaven-android-sdk-deployerを実行するのがダルい、などの理由により、使いやすいかと言われるととても頷けるものではなかったと思います。

新たなる息吹:Gradle

そこにGoogleが公式にぶっ込んできたのがGroovyベースのDSLであるGradleとなります。手続き型な感じのスクリプトで、個人的にはMavenXMLよりも何が書いてあるのか読みやすいと思いました。また、Maven Central Repositoryも利用できるため、ライブラリの取得も容易です。Groovyがそのまま書けるため、いざとなれば柔軟な処理も書けるのも、ポイントが高いところです。

Gradle Wrapper(gradlew, gradlew.bat)の仕組みにより、デベロッパーの手元にシェルやbatの実行環境(と、Android SDKへのパス)があれば、それだけでプロジェクトのビルドができてしまう点も、チーム開発やオープンソース開発を行う上では嬉しい点です。

そして、Android Studio側でビルドなボタンを押した時の挙動は、コマンドラインから ./gradlew assembleDebug をしたときと同じ。もう「IDEからは動くのに、コマンドラインからだと動かない」なんて謎現象に悩まされる必要はありません。*1

何を言いたかったかというと

Mavenでプロジェクト管理するの凄く苦しかったからGradleで管理できるようになって嬉しかった。(私怨 && 小並感)

2. dependencies設定でライブラリ取り放題

さて、Eclipse+Mavenだとpom力(ぽむりょく)を磨かないといけなくてマジファックでしたが、Android Studio + Gradleでは、↓のようなコードをbuild.gradleの中に書くだけでライブラリのダウンロードを行い、Androidアプリの中で使えるようにしてくれます。

dependencies {
    compile "com.nineoldandroids:library:2.4.0"
}

compile "group_id:artifact_id:version" な感じですね。Mavenの枠組みで配布されているライブラリはこれで取ってこれます。DaggerだってPicassoだってすぐに使えるようになります。

GradleやAndroid Studioはまだまだ浸透してきたとは言いがたいですが、Maven Central RepositoryでJARライブラリを公開するのはJava界隈で既に広く浸透している文化ですので、この仕組みによって得られる恩恵は計り知れないと言ってもいいでしょう。

ライブラリ導入のコストが滅茶苦茶下がりました。やったね!!!

3. AARなライブラリプロジェクトもdependenciesで取ってこれる

AARはAndroid ARchiveの略らしいです。JARのAndroid版だという認識ですけどよくしらない。どうやらライブラリプロジェクトをビルドしたときに生まれる、ファイルとしての実体みたいですね。(そういう意味では、APKファイルに類する存在なのかも)

さて、この形式のライブラリプロジェクトは、作者が頑張ってくれている場合、gradleのdependenciesで取ってこれます。

詳しくはゆーいち先生の記事を御覧ください。

実際にこの形式で配布されているライブラリとしては、@さんのIndirectInjectorなどがあります。

4. ビルドの種類を定義してソースフォルダ単位で切り替えられる

社内向けデバッグ用、モニターユーザー向けリリース用、Playストア向け無料版リリース用、Playストア向け有料版リリース用、などの切り替えを、ビルド時にコマンドによって切り替えられる機能があります。Build TypeはDebugとReleaseの2種類ですが、Product Flavorは任意の数だけ用意できるので、色んなパターンのアプリを作らないといけない場合には便利な機能ですね。

下記の記事が詳しいです。

Build Variants によって別バージョンの Android アプリを同じプロジェクトからビルドする (Gradle 使用) - ひだまりソケットは壊れない

5. Android Studioのプロジェクト設定がGradle依存

f:id:Nkzn:20140320232131p:plain

プロジェクトフォルダの構造が少し複雑になってきたりすると、ソースが入ったフォルダをビルドパスに追加し忘れる凡ミスにより、上手くビルドできなかったりした経験はないでしょうか。

Android Studio + Gradleの環境では、settings.gradleやbuild.gradleに記述した内容がAndroid Studioのプロジェクト設定に直接反映されるため、そういったミスが起きづらくなっています。

また、チーム開発時にも、IDEの初期設定に割く時間を減らせそうです。

Intellij IDEAみたいに Mark Directory As > Test Source Root みたいな感じでIDEからソースフォルダを指定したくなるときもありますけどねー。

6. 画像リソースの小さいプレビューがXMLJavaから見える

f:id:Nkzn:20140321001504p:plain

JavaXMLで、drawableリソースの中身がエディタの左端に出てきます。

f:id:Nkzn:20140321001540p:plain

Javaのほうは式として成り立っていなくても出てきたので、判断基準が結構適当みたいです。

7. colorリソースの色がXMLJavaから見える

f:id:Nkzn:20140321000328p:plain

JavaXMLで、colorリソースの色がエディタの左端に出てきます。

color.xmlはなかなか壮観ですね。

f:id:Nkzn:20140321000713p:plain

いまどんな色が画面に出ているのかコードを書きながらイメージしやすいのは、嬉しい時もあるのではないでしょうか。(実はあんまり嬉しい場面が思いついていないけど綺麗なので挙げた)

8. 各種リソースの参照が文字として見える

f:id:Nkzn:20140320234612p:plain

XMLファイルやJavaファイルの中で、dimenやstringで定義した要素の値が、一時的に置き換えて表示されます。実際のファイル上で指定した値が書き換わるわけではなく、あくまでも見た目だけで、マウスオーバーすると元の値を見ることができたりします。

実際には↓のようになっているファイルも・・・

f:id:Nkzn:20140320235104p:plain

こんなふうに見えます。

f:id:Nkzn:20140320235151p:plain

Javaの中でgetString(resId: int)で呼ばれている値も同様に置き換えられます。

f:id:Nkzn:20140320235839p:plain

↑これが↓こうなる

f:id:Nkzn:20140320235854p:plain

これで、「あれ、このstringリソース、中に書いた日本語なんだったっけ?」とか「このdimen、実際には何dpだっけ?」なんて悩まずに済みますね!

9. レイアウトXMLテキストエディタモードでもリアルタイムプレビューできる

f:id:Nkzn:20140320233553p:plain

レイアウトのXMLを編集すると、ほぼリアルタイムでプレビューに反映されます。Android Studio登場以前から、IntelliJ IDEAでAndroid開発をする際の魅力的な機能として挙げられていました。

何を置くとどんなふうに見えるのか、トライアンドエラーが大変捗るので、デザイナーさんやAndroid初心者なプログラマーの人にレイアウトXMLを勉強してもらう際にも、効果バツグンです。

10. Kotlin言語が使える

Android StudioJetBrains製のIDEであるIntelliJ IDEAをベースにしているので、ちゃんと設定すればKotlin言語を利用することができます。Androidで使えるベターJava言語を探している方にオススメです。

Null-safety機能すっげえいいよ!!!!

まとめ

現状、僕がEclipseを使う理由は(業務上やむを得ないアレが無い限り)どこにもありません。*2

でも僕が魅力を感じているのはどちらかというとGradleのほうなので、ADTがGradleに対応したらそれはそれで触ってみたい気がします。

今回は「IntelliJ IDEAが元々持ってた良さ」みたいなものは基本的に挙げなかったので、他にもAndroid StudioやIDEAを敢えて使う利点はありそうです。そのへんは他の方が記事書いてくれてると思うので、探してみてください。

それでは、良いAndroidアプリ開発ライフを。

あわせて読みたい

Android StudioでEclipseのアレをやるには? - _development,

*1:もちろん動かない時はどっちでも動かない

*2:フォーマッターの取り回しでいうとEclipseのほうが良いけど