2014-09-24

形から入るリーンスタートアップ

リーン開発手法 tips Webサービス

無駄を徹底的になくす、と言われているリーンスタートアップ。

2012年ごろから話題でしたがようやく最近勉強を始めました。

新しい手法を取り入れるときはその導入コストに悩まされるものですが2014年の今、
リーンスタートアップをとにもかくにも始めるためのツールが充実してきていると感じたのでまとめておきます。

リーンスタートアップとは

リーンスタートアップとは何でしょうか？
以下のように参考になる資料はネット上にたくさんあります。

ざっくり言うと「検証を重ねて無駄を最小限に抑えながらサービスを構築していく手法」と言ってしまって良いかと思います。

検証の対象は多岐に渡ります。

課題は解決すべきものか
解決方法は顧客が求める形か
顧客はお金を支払ってくれるか

詳細を知りたい方はぜひとも資料をお読みください。

リーン・スタートアップ

作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
出版社/メーカー: 日経BP社
発売日: 2012/04/12
メディア: 単行本
購入: 24人クリック: 360回
この商品を含むブログ (92件) を見る

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

作者: アッシュ・マウリャ,渡辺千賀,エリック・リース,角征典
出版社/メーカー: オライリージャパン
発売日: 2012/12/21
メディア: 単行本（ソフトカバー）
購入: 3人クリック: 14回
この商品を含むブログ (18件) を見る

とにかく形から入ろう

ここからが本記事のメインの内容です。

リーンスタートアップを始めるにあたっての手順は本来様々だとは思いますが、
いくつかのツールを使えば本で紹介されるような内容を押さえた形でかなり素早くリーンスタートアップの導入をすることができます。

ここでいう「形から」という部分の具体的な内容は以下のとおりです。

サービス全体をまとめる
課題が適切かどうかを問う
顧客がサービスに興味を持ってくれるか問う

それぞれを少し詳しく説明していきます。

サービス全体をまとめる

リーンスタートアップでは「リーンキャンバス」というものを書きます。
課題やその解決方法、顧客層、マネタイズなど様々な内容を書くことでサービスを俯瞰して捉えることができるとされています。

このリーンキャンバスを書く、というときにに使えるのがTinyCanvasです。
非常にシンプルなツールで起動したらログインなどは何もなくすぐさま書くのみで、URLさえ取っておければいつでも途中の状態を維持できます。
もちろん無料です。

こちらのツールで書いてみたのがこちら、OnlineIdです。

f:id:shoma2da:20140924203141p:plain

リーンキャンバスを書くにあたっての参考になればと思います。

課題が適切かどうかを問う

次に進みましょう。

特に技術者は、サービスを考えた時点ですぐに製品を作ろうとしてしまいがちですがリーンスタートアップの考えではこの時点で製品開発を始めるのは時期尚早です。

まずは課題設定が適切かどうかを確かめましょう。
課題を設定した時点ではほぼ全ての場合、「hogehogeは解決すべき問題だと思われる」といった未確認（サービス提供側の思い込み）の状態のはずです。

基本的にはこのときのおすすめの検証方法は顧客に直接話を聞くことです。
先ほどのリーンキャンバスで書いた顧客を見つけて話を聞きましょう。
（ここでのコツは解決方法についてはまだ触れないことです。課題のみを話して共感してくれるかどうかで「解決くべき課題である」ということを検証します。）

直接話を聞くのが難しかったり、とにかく早く回答数が欲しいといった場合はQuestantを使ってみるのも一つの手でしょう。
<a href="https://questant.jp/">アンケートをつくろう。驚きを見つけよう。│Questant（クエスタント）</a>

PC、スマホの両方に対応しておりかなり簡単にアンケートを作成することができます。
アンケートの作成や回答の収集が無料でできます。

ソリューションに問題がないか問う

課題が解決すべきものだと確認できた場合は解決方法が妥当かどうかの検証に入ります。

この段階でのやることも多岐に渡って考えられますが、個人的なおすすめはサービスのランディングページを作ってしまうことです。
サービスの概要をいち早く世に出すことで「解決すべき課題を適切な方法で解決しようとしているか」を検証することができます。

このときのおすすめサービスはStrikinglyです。
サクッとWebページを作ることができます。
<a href="http://www.strikingly.com/">How To Make Your Own Website - Best Website Builder | Strikingly</a>

Strikinglyを使えばWebサーバは愚か、HTMLやCSSの知識がゼロでもキレイなUIのページを簡単に作成できます。
用意するのは表示する文言と（載せたければ）数枚の画像だけです。
アクセス解析情報の閲覧やメールアドレスの登録フォームも用意できてかなり便利です。

このサービスを使って作成してみたのがMyBooks ~あなたにおすすめの本を月に１冊お届けします~ on Strikinglyです。
この程度のサイトであれば20分程度で作ることができました。参考になればと思います。

以上で今回の記事は終了です。
みなさまのリーンスタートアップの入り口になれば嬉しいです。

2014-06-03

Swiftことはじめ：String?のクエスチョンマークって何？

iOS Swift tips

Swift出ましたね！

WWDCで突然の言語発表で驚きです。

f:id:shoma2da:20140603232720p:plain

無料のドキュメントが提供されており、ざっと読んでみた限り最近の言語のエッセンスを色々と取り込んだ良い意味で特徴のない（かなり書きやすそうな！）言語という印象を受けました。

今回はそんなSwiftの中のoptional valueなどと呼ばれている言語仕様について取り上げていきます。

どれのこと？

ドキュメント中に出てくる以下の様な記述です。

var optionalString: String? = "hello"
optionalString = nil
println(optionalString)

このString?、なんのことだかわかりますか？

このクエスチョンマーク、どうやって使うの？

使い方を見ていきましょう。

まず普通の変数宣言で以下の様に書いてみましょう。

var normalString = "aaa"
normalString = "bbb" //普通に代入できる
normalString = nil //コンパイルエラー！

なんとnilの代入ができません！

これは次のように書いたのと全く同じ意味になります。

var normalString:String = "aaa"
normalString = "bbb" //普通に代入できる
normalString = nil //コンパイルエラー！

normalStringの型はStringです。

ではnilを代入したい場合はどうするのでしょうか？

そんな時に出てくるのがこのクエスチョンマークです。

var optionalString:String? = "aaa"
optionalString = "bbb" //普通に代入できる
optionalString = nil //代入できるようになった！

optionalStringの型はString?です。

このようにSwiftではデフォルトでは変数にnilが入らないようになっており、

nilを代入したい場合は型に?を付けた型で宣言します。

こうしたクエスチョンマーク付きの型は変数だけでなく関数の引数や返却値としても使用できます。

func optionalReceiveMethod(string:String?) {
    println("received value is [\(string)]")
}

optionalReceiveMethod("hello")
optionalReceiveMethod(nil) //関数の引数がStringだとエラーになります

func optionalReturnMethod() -> String? {
    return nil //返却値の型がStringだとエラーになります
}

次に変数の使い方を見て行きましょう。

使うときには?と!が重要になります。

var noarmalString:String = "aaa"
println(noarmalString.uppercaseString)

var optionalStringFirst:String? = nil
//println(optionalStringFirst.uppercaseString) コンパイルエラー！
println(optionalStringFirst?.uppercaseString)
//?が付いたところを評価してnilならそこでメソッド呼び出しをやめて結果をnilとする

var optionalStringSecond:String? = nil
println(optionalStringSecond!.uppercaseString)
//!の場所はnilだろうがなんだろうが無理やり実行する→ここだとクラッシュします…

!を使ってしまうとoptional valueを使う意味がほとんどなくなってしまうので基本的には使わない方が無難でしょう。（詳細は後述します）

また以下のようにifで囲めばnilでないことがわかるので?や!を使う必要はなくなります。

var optionalString:String? = "aaa"
if optionalString {
    println(optionalString)
}

使い方はここまでを把握できていれば十分かと思います。

なんでこんな言語仕様があるの？

結論から言ってしまうと「コンパイル時点でnilをチェックするため」です。

今までnilに起因したクラッシュが発生したことはありませんでしょうか？

おそらくみなさん経験していることでしょう。

Objective-Cでは値がないことをチェックするにはいわゆるnullチェックをしていたかと思います。

※厳密にはNSNull、nil、nullなどでそれぞれ対応は異なったりしますが話を簡単にしています。

しかし通常のnullチェックの場合、以下の様な欠点がありました。

nullになり得るかどうかをプログラマが考える必要がある→対応忘れが頻繁に起きる
ほんとにnullになるかどうかは実行時にわかる→ストア配布後などにテスト漏れによるnilに起因したクラッシュが発生する

こうした状況に対処できるのが今回説明しているoptional valueです。

上記の欠点についてoptional valueなら次のことが言えます。

nullになり得るかどうかは型で把握しているのでコンパイラが判断できる
ほんとにnullになるかどうかはコンパイル時点でわかる

つまり今まではプログラマが考えたり実行してテストしていたものをコンパイラという機械にまかせてしまうことができます。

さきほど!は使わない、と言いましたが!を使うとコンパイラによって得られる恩恵を全て無視してしまっていることがわかるかと思います。

良くないですね。

まとめ

optional valueは「値がない場合」の対応をほぼコンパイラに任せたような言語仕様でした。

nullについてはnull参照の考案は10億ドル単位の過ち？などと言われることもあるように旧来の言語ではなかなか苦戦していた部分でした。

今回はSwiftで説明しましたが他の言語を見てみると、KotlinやCoffeeScriptではSwiftと似たような機能が既に取り入れられています。

またScalaなど関数型の色が濃い言語ではMaybeモナドによる解決策なども図られています。

最近は自動テストやCIなどこれまでプログラマが行ってきたことはどんどんと機械に任せられていっています。

様々な言語の仕様でもその流れに沿っていて、メモリ管理・暗黙の値・遅延評価・今回のようなnull対応など、コンパイラや実行マシンに任せる比重もどんどんと増えているように感じます。

人にしかできないことがより強く重視されていくんでしょうね！楽しみ！！

2014-05-06

続エンジニアだけでアプリアイコンを作る

tips 制作

昨日「エンジニアだけでアプリアイコンを作る」を書いたのですが、500はてブ以上と思わぬ反響をいただいて驚いています。

ほぼツールの紹介だったので大方予想はできていたのですが「で、結局絵はどう書くの？」といったコメントを多くいただきました。

このあたりについてもどのようにやってきたかをざっくりですが紹介しておきたいと思います。

アイコンを書けるようになるまで

模写する
勉強する
自分なりに作る（ゴール）

ざっくり言うとこの３つの手順です。

あくまで「なんとか書けるようになるまで」なのでデザイナーさんから見ればまだまだなレベルにしか到達しないでしょうが、やれないよりはマシなはずです。

模写する

まずは今あるアイコンと同じものをとにかく作っていきます。

ここでの主な目的はツールの使い方を把握することです。（前記事ではInkscapeを紹介しました）

10個ほど作ればおそらくツールの使い方はほとんどわかってくるでしょう。

初めに模写するおすすめのアイコンを並べておきます。

アプリ名の横にどんな機能を使えば模写できそうかも載せておきます。

とにかくアイコンを作ってみる

以下の３つのアイコンは基本的には丸と多角形だけで作れるはずです。

さくさく作っていきましょう。

Yahoo!リアルタイム検索（四角、三角、角丸）
Dropbox（四角、角丸、オブジェクトの差分（白い影））
Presso（四角、角丸、パスのノード（カップの下端））

影の付け方を覚える

続いて影の付け方を学んでいきます。

影は以下のように黒くて少し透明な図形を重ねれば表現できます。（もっといい方法あれば教えて下さい…）

f:id:shoma2da:20140506223559p:plain

TED（文字の内側に影）
Flat TO-DO（アイコンの外側に影）
Google Adsense（色んなところに影）

曲線の使い方を覚える

これが一番むずかしいですが曲線の使い方です。

使うツールとしてはベジェ曲線やパス、ノードなどです。（Inkscape、Illustatorのどちらでも使えます）

難しければはじめはやらなくては良いでしょう。。。

Tumblr（「t」の左肩が曲線）
Vine
ボケて

勉強する

上記のようなアイコンの模写をしていくとツールの使い方がだいたいわかってくるはずです。

このようなタイミングで一度「デザインってどうやるの？」を勉強しておくと自作する際の大きな足しになるでしょう。

ここは本を購入することをおすすめします。

「デザイナーじゃない人向けのデザイン本」というまさにドンピシャな本です。

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

作者: Robin Williams,吉川典秀
出版社/メーカー: 毎日コミュニケーションズ
発売日: 2008/11/19
メディア: 単行本（ソフトカバー）
購入: 58人クリック: 1,019回
この商品を含むブログ (104件) を見る

アプリアイコンに限らず、スライドやWebサービスのUI設計にも大きく活かせますので必読です。

内容は４つの大原則の説明です。それぞれ一行で説明します。

近接
関連の濃いものを近くに、関連の薄いものを遠くに配置する
整列
一つの直線を軸にして要素を配置する
反復
繰り返し同じ表現を使って統一感を出す
コントラスト
意味を変えたい場合ははっきりと違いを表現する

一行で説明しましたがそれぞれかなり奥が深いです。続きは是非本で呼んでください。

自分なりに作る（ゴール）

模写と勉強が終われば、「ツールの使い方がわかる、かつ、なんとなくデザインのことを知っている」という状態になるでしょう。

ここまで来ればひとまずゴールです。

自分なりにアイコンを作っていきましょう！

それでもアイディアが全然浮かばない、という方におすすめなのは現実にあるものを極力シンプルに表現する方法です。

例としてクマを挙げておきます。

f:id:shoma2da:20140506225720j:plain 　（これが）→　 f:id:shoma2da:20140506225741g:plain （これ！！）

このようにアプリに関連のあるものを極力シンプルに表現するアイコンにしてみましょう。

この他良い方法などがありましたら是非教えて下さい！

以上です。

2014-05-05

エンジニアだけでアプリアイコンを作る

tips Webサービス制作

エンジニアが自分一人でアプリ開発などをしているとかなり困るのが画像素材の作成。（もっというとデザイン全般ですが。。。）

その中でもアプリアイコンを作る際に個人ではどうしているかを晒してみようと思います。

アイコンを作る手順

ざっくり手順を言うと以下２つです。

Inkscapeで元アイコン作成
makeappiconで全サイズのアイコン画像作成

Inkscape

アイコン作成といえばIllustratorやPhotoshopを使うのが一般的かと思うのですが、非デザイナーにとってこれらのソフトはまだまだ高価で簡単に手を出せるものではありません。

そこでこのInkscapeです。

公式サイトはこちら。

Inkscapeはオープンソースの無料のベクター画像編集ソフトです。（ものすごく簡単に言うとIllustatorと同じことができる無料のソフトです）

無料ですが、基本的なアイコン作りには困らない機能が揃っているので、エンジニアが手を出すには丁度いいソフトではないでしょうか。

アイコンを作る

こちらのソフトを使って幅1024、高さ1024のサイズのアイコンを作成していきます。

f:id:shoma2da:20140505232531p:plain

検索すると日本語の情報もたくさん出てくるので、使い方に困ることは少ないでしょう。

アイコン画像を書き出す

アイコンができあがったら画像に書き出していきます。

ファイルメニュー内に書き出し項目があるのでこちらから書き出しましょう。

f:id:shoma2da:20140505232737p:plain

makeappicon

アイコンができあがったら各アイコンサイズにリサイズしていきます。

このときに非常に便利なのがmakeappiconです。

このmakeappicon、1024✕1024の画像を渡すだけでiPhone/Androidアプリに必要な全てのサイズの画像を作成してくれます。

手順は非常に簡単です。

画像をドラッグ＆ドロップしてメールアドレスを入力するだけ！

f:id:shoma2da:20140505233350p:plain

↓（画像をドラッグ＆ドロップ）

f:id:shoma2da:20140505233430p:plain

↓（完成！）

f:id:shoma2da:20140505233512p:plain

会員登録なども一切必要ないので使わない手はないかと思います。

その他

たまにですが「これこれのサイズの画像が欲しい！」なんて思うことがあります。

そんなときはPlacehold.jpを使ってます。

画像サイズを入力するだけでダミー画像を用意してくれるサービスです。

これまためちゃ便利！

-------

ここ１年ぐらいはこんな感じの環境で作業してますが、みなさんの画像素材などの作成環境も知りたいです。

是非コメントなどで教えて下さい。

追記：続きの記事を書きました→続エンジニアだけでアプリアイコンを作る

2014-02-02

テストがないコードをどのようにテストしていくか

テスト tips

みなさんテスト書いてますか？
最近のプログラマ界隈ではテストや自動化の話題が非常に多くなっていますよね。
そんなことを言いつつ僕もつい最近テストについて発表しました。

テストが書けるようになってくると実装に自信が持てたり、変更を恐れなくなったりなど良いことが非常に多いです。

基本的には是非書いたほうが良いテストですが、実際の開発現場ではそう簡単にいくものではありません。
これまでに誰か（もちろん自分でも！）が書いたテストのないコードに手を入れていくことが非常に多いのではないでしょうか。

リーン開発の現場にこうしたレガシーコードについての戦略が記載してあったというのもありますが、自分自身もこのような状況に出くわすことが多いので今の思いをまとめておきます。

どうやってテストしていく？

実際にテストのないコードをテストしていこうとする場面を想像してみてください。
僕の知っている中では選択肢として以下の２パターンが挙がることが多いです。

チーム全体でテストを書くことを決意して、一気にテスト環境やテストを揃えていく
コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテスト環境やテストを揃えていく

結論を言うとほとんどの場合、後者がベターな選択肢ではないかと考えています。
そのように考えている理由を説明していきます。

この２パターンは「テストをすること」に関してははチーム全体の合意が取れている前提のものです。
名著レガシーコード改善ガイドでは「編集して祈る」か「保護して変更する」かという２パターンの方法ついて述べています。
しかしこれらはあくまで修正の方法論について述べているものですので上記とは意味合いが異なります。

それで、誰がテストに詳しいの？？

仮に先程述べたうちの前者、「チーム全体でテストを書くことを決意して、一気にテスト環境やテストを揃えていく」を選択したとします。

ではテストを書きましょう！となりますが、実際問題としてテストに詳しい開発者はそう多くないはずです。
（一方ではてなやクックパッドはテストに関してかなり先行していそうですね。すごい！！）

そのような状況でテストを初めてしまっても、そもそもテストの粒度や書き方を学ぶのに相当の時間的コストがかかってしまいます。

また、テストするということはプロダクトのコードにもほぼ必ず手を入れることになります。
（テスト不可能だったりそのままのプロダクトコードだと非常に複雑なテストを書かなければならない場合が出てくるため）

テストへの理解があやふやなまま、テストができるようにプロダクトコードを変える。
これは非常に危険なことではないでしょうか？

実装が非常に簡単、といった箇所であれば問題ないかもしれませんが「一気にテスト環境やテストを揃えていく」と決めるということは、そのような箇所だけではなく全ての箇所を見ていくことになります。

長い期間書けてテストを揃えたけど、プロダクトとしての動作を保てなかった...では全く意味がありませんよね。

そこってほんとに手を入れるべき？？

ソースにはどうしても「良く変更する箇所」と「全然変更しない箇所」が出てきます。

このうち「良く変更する箇所」については是非とも早めにテストを用意しておくべきでしょう。
変更ごとにテストを実行することによって安心してプロダクトに組み込んでいくことができます。

一方で「全然変更しない箇所」はどうでしょうか。
もう少し詳しく言うと「全然変更しないけど期待通り動いている箇所」です。
結論から言えばこうした箇所のテストは後回し、更にいえばそのままずっとテストなしでも問題ないのではないかと思っています。
（ここに対する意見は人それぞれ大きく異なりそうな気がしています）

冒頭に述べた後者の選択肢「コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテスト環境やテストを揃えていく」としていればこうした箇所は触れられることはなく、半自動的にテストされないままになります。

昨今のソフトウェア業界は以前にも増して更に加速度を増しています。
「今は修正の必要がないけどテストコードでより高い安全性を確保する」よりも「新機能の追加や既存の不具合を修正」を素早く行ってユーザに価値を届けていくことの方に基本的には重点を置くべきではないかと思います。
（テストを揃えておくことはもちろん大事ですよ！！念のため。）

YAGNIという言葉もありますし、過度な先読みは最終的には無駄な作業を生む可能性を考えると良いのではないでしょうか。

自動化も一緒にやる？？

テストを書いていくとJenkinsなどを使って自動化(CI)したくなってきます。
確かにコミットしただけでビルドやテスト、デプロイなどを自動で行えることは革命的に素晴らしいものです。

しかし、テストと合わせて自動化ツールもほぼ同時に導入しようとするのには少し考えなおした方が良いかもしれません。

テストを書いていくとテスト用のデプロイ環境やダミーの入力値の準備といった周辺環境の念入りな準備が必要になります。
自動化ツールはあくまで手動で実行できるものをトリガーのタイミングで実行させるだけのものです。

テスト自体の周辺環境があまり固まっていないのに自動化ツールを導入すると、 テストの周辺環境を変える→テストが通ることを確認する→!!自動化の設定を変える!!→!!自動化できているか確認する!! などと自動化に関する工程が増えてしまいます。

テスト自体に慣れてきていれば自動化の設定変更は苦にならないかもしれませんが、テスト自体があやふやなのに自動化についても気にしなければならない！となると精神的負担も非常に大きくなってしまいます。

楽になるための自動化ツールで苦しくなってしまっては元も子もありませんよね。

まとめ

テストのないコードに対するテストをどう行っていくかについて述べました。

一気にテスト環境を整えきろう！と意気込んでしまいがちですが、その方法ではスーパーエンジニアでもない限り失敗してしまうことが多いのではないでしょうか。

個人的には「コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテストの環境やテストを揃えていく」という選択がベターな気がしています。
テストを少しずつ書いていくことによってテスト自体（あるいはプロダクトの特徴など）に慣れ、それを続けていくことで環境が整い自動化していける、といった少しずつ前に進んでいく手順です。

是非みなさんも考え、実践してみてください。
また、より良い方法などあれば是非教えていただきたいです！

2014-01-21

アプリ開発者じゃなくてもわかるクックパッドアプリ勉強会まとめ #potatotips #android #ios

勉強会 Android tips iOS

クックパッドでは月に一度、potatotipsという名で社外の開発者も招いてアプリ勉強会を行っています。詳細としては発表者だけが参加できる、持ち時間1人5分のtips共有会です。発表内容はiOS/Androidに関するTipsとされています。これまでに３度開催されました。

まとめ

早速まとめていきます。発表内容とその簡易的な説明をしていきます。各タイトルの頭にAndroidならA：、iOSならI：を付けます。

（詳細な資料があるもののみをまとめの対象とさせていただきます。）

第一回

発表内容一覧です。

A：No More 手書きViewHolder
→Andoridのリスト表示の際にはパフォーマンス向上のための"おなじみの仕組み"を毎回実装することが多いがこれを簡単にする方法について
I：No More いろんなサイズの画像(スノーマンから始めよう)
→ユーザの端末（iPadやiPhoneなど）の画面サイズはそれぞれ違うのでいろいろな大きさの画像が必要になってしまう。この問題に対する文字のパスを取得し、ベクター画像のように扱う方法の提示
I：Downloadable Storyboards!
→iOSアプリの見た目を作成するためのファイル（通常はアプリに含まれます）をアプリの実行時にダウンロードして使う方法
I：5分で分かるiBeacon
→Bluetoothを使った位置や距離感をつかむための最新技術について、その概要や実装について
I：UINavigationBarの隅々までタップしたい
→通常、iPhoneの上部のバーのタップ領域は限られているが、この領域の拡張方法とライブラリ化について説明
A：Anroid Design Guide 3つのポイント
→Androidの画面デザインについて。色、部品の大きさ、文字
I：ユーザービリティ向上ネタ
→アプリを提供する上でのユーザビリティ向上策について１１個。画像取得タイミングやタイトル表示、階層の行き来の仕方など
A：Development, Staging, Production...
→アプリの配布環境ごとのビルドの自動化についてその実例
I：Switching Icon.png depending on each enviroment
→本番用と開発用のアプリのアイコンを変える試みとスクリプトによる自動化
I：Debugger の Tips
→デバッグ時に使用するコンソールを便利に使うための設定
I：iOS 7 compatibility issues (UITextView)
→iOS7のテキスト表示部品に残っているバグに対する対処方法。また、拡張されたテキスト表示部品の実装と公開
I：AVSpeechSynthesizerとロケール
→音声読み上げの際の簡単な言語判定方法
A：Android SDK Toolsのおさらい
→Android開発環境に含まれるコマンド24個について
I：５分でわかるiOS7のiAdとTips
→iOSで使える広告iAdの使い方
I：iOSでジオコーディング
→緯度経度と住所の変換方法。サーバサイドの負荷に注意。
A：New Android Bootstrap
→Webでは有名なBootstrap、そのAndroid版について設定方法や実装方法について

第二回

発表内容一覧です。

I：Xcode 5 & iOS 7でカバレッジを取る話
→最新の開発環境を使ったテストカバレッジの取得
A：ActiveAndroidの初期化にかかる時間を4分の1にする
→DB入出力に係る時間コストを抑える方法
I：Objective-CでRAII便利最高 →オブジェクトとリソース管理のパターンについて
I：XXXKit ~ それははしかのような物 ~
→画像をグリッジ（画面のチラツキ）させるライブラリの紹介と、Objective-Cのカテゴリ機構について
A：ViewStickerを作りました
→iOSと同様なリストセクションの表示ができるようになるライブラリの作成
I：～時には起こせよエクセプション
→例外処理をさまざま試すことでクラッシュを防ぐコードを書いていこうという試み
A：Custom Lint Check
→不具合を発見するためのツールにおける設定を自作

第三回

発表内容一覧です。

I：下位互換コード隠蔽のストイシズム
→バージョン対応のコードをいかにして自然に実装するか
A：アプリの評価を良くするということについて考える →Android/iOSのストア評価について。ライブラリの紹介など
I：便利なSyntax及びUnicodeを使ってアイコンを出す方法
→便利なブロック文法説明、Unicodeでアイコン表示、三項演算子の使用方法について
A：アプリでもオブジェクト指向エクササイズ ★おすすめ！★
→オブジェクト指向を身につけるための強力なコーディング規約について紹介
I：Provisioning Profileファイルを活用してみる！Tips
→アプリを端末に入れる際に必須である設定ファイルの便利な活用方法について
I：iOS 7 なMessage Appの作り方
→LINEのようなアプリをiOSでどのような実装で作れるかの紹介
A：ちょっと優しい入力項目
→決定ボタンを押した際の挙動など、こまかな入力項目に関する実装方法
I：やはりお前らのiOS7対応は間違っている
→多く語られるiOS7の対応方法についての誤解と好ましい実装方法について
I：Secrets of launch arguments
→実行時の引数を便利に渡す方法の紹介
A：TDDでアプリ開発。カバレッジ8%を目指せ（消費税連携！？）
→全解像度、全OS、全CPUに対応した自動テストについて
I：xctestコマンドを知っていますか？
→最新の開発環境におけるテスト用のコマンドについて紹介
A：KotlinでAndroidアプリ開発！(後編)
→Android開発は通常Javaだが、Kotlinという言語を使った開発の紹介
I：死んだオブジェクトの生まれ故郷を探す
→オブジェクトのメモリ使用についてのログを見ることでオブジェクトの生成から破棄までを追う
A：Gradleの共通ルーチンをテストする（後編）
→Android開発は通常Javaだが、Groovyという言語を使った開発の紹介とビルドシステムを使ったテストについて
I：mogeneratorでモデルクラス作成
→クラスを作成するためのツールの紹介と使い方
A：AndroidのHTTPライブラリってどれがいいんでしょうか
→多数あるHTTPリクエストの実装方法について３つを提示して比較

詳細を知りたい方は

iOS

Android

potatotips (iOS/Android開発Tips共有会) 第１回
（まとめページ見つからなかったので見つからなかったので参加者一覧ページです）
potatotips (iOS/Android開発Tips共有会) 第2回
（まとめページ見つからなかったので見つからなかったので参加者一覧ページです）
第3回 #potatotips で発表されたAndroid Tipsのまとめ

2014-01-16

第3回 #potatotips で発表されたAndroid Tipsのまとめ

Android 勉強会 tips

クックパッド主催の勉強会potatotips、月に一度の会で昨日は３度目でした。

今回はヤフーオフィスでの開催ということで発表までさせていただきました！

potatotipsは一人５分のアプリ(iOS/Android)に関するTipsを発表する、というとてもシンプルなコンセプトの勉強会です。

iOSのまとめは早々と第3回はヤフー開催！ #potatotips で発表されたiOSのtipsまとめ - Think Big Act Localにできていました！@himara2早い！

今回のAndroid Tipsは８個でした。

Android Tips

アプリの評価を良くするための工夫

発表者：rejasupotaro さん
資料：http://rejasupotaro.github.io/blog/2014/01/16/29/
発表概要

・レビューの高いアプリであるほどそれだけ高い数値を出せる
・評価ダイアログの是非について最近は議論が活発
・ユーザにとって意味のあるレビューとは？
i・OS/Androidそれぞれに評価ダイアログ用のライブラリがあります

アプリでもオブジェクト指向エクササイズ

発表者：shoma2da このブログの著者です！！
資料：http://www.slideshare.net/shoma2da/potatotips3-shoma2da
イチオシ資料：ThoughtWorksアンソロジー
発表概要

・未だに世の中のソースコードは汚い
　→一方でみんな柔軟なコード書きたいし、自動テストもしたい
・書籍で提唱されたエクササイズをアプリにも導入しましょう！
・９つエクササイズについて説明
・パフォーマンスへの影響
質疑応答

業務レベルで導入した方がいいのか？エクササイズにとどめておくのが良いのか？
　→まずはエクササイズにとどめた方が良いと思う。他メンバーとの意思疎通の問題もある。
変更に対する柔軟性は落ちないのか？
　→どんなソースの書き方をしても変更するときは変更する。細かくソースが分かれて責務が分散されている状態になるだけなので柔軟性が落ちることにはつながらないと思う。

Fitting 解像度対応β

発表者：tq_ne_jp さん
資料：公開されていないようです...
発表概要

・Androidの画面サイズ、解像度対応はほんとに大変
・どの端末でも同じ大きさの比で画像を表示したい
・画面の縦横サイズを取得し、画像を動的に引き伸ばすと解決する
質疑応答

発表に使っているツールは何ですか？
　→イラストレーターです。（一同どよめきw）
検証に使っている端末数は？
　→現状３台。動的に引き延ばしているのであまり深刻に検証しなくても大丈夫だと思っている。
エミュレータは使っている？
　→使っていない。遅くて使い物にならない。

ちょっと優しい入力項目

発表者：sakebook さん
資料：http://www.slideshare.net/sakebook/ss-30043058
発表概要

・Enterをおした時の挙動が意図したものと違うことがある
・SingleLine + NextFocus + OnEditorActionで制御しよう。

Reflectionを使おう、というお話

発表者：kobito_kaba さん
発表資料：公開されていないようです...
発表概要：セキュリティに絡む話が出てくるので割愛します。問題ないことを確認しだい記載します。

TDDでアプリ開発。カバレッジ8%を目指せ（消費税連携！？）

発表者：tarotaro4 さん
発表資料：http://www.slideshare.net/tkawashita/20140115-potato-tips-no3-android-app-test-development-driven-and
発表概要

・Androidのフラグメンテーション問題を全OS、全解像度、全CPIで自動テストして解決する
・クラウドCIサービスがあるのでこれを利用すると良い CloudBees

KotlinでAndroidアプリ開発！(後編)

発表者：sys1yagi さん
資料：http://www.slideshare.net/bs_yagi/potato03
発表概要
・Kotlin(Java系言語) + Android Studioでの開発
・拡張関数で捗る！
・関数リテラルで捗る！
質疑応答

クックパッドでKotlinを導入するのはいつですか？
　→４月くらいの予定

Gradleの共通ルーチンをテストする（後編）

発表者：__gfx__ さん
資料：http://www.slideshare.net/gorof/potatotips3
発表概要

・Groovyを使った開発
・ビルドシステムGradleを使ったテストについて
・Power Shell便利！

AndroidのHTTPライブラリってどれがいいんでしょうか

発表者：ninjinkun
資料URL：公開されていないようです。
発表概要

Retrofit / Volley / android-async_http のうちどれが良さそうか

参加した感想

とにかくレベルの高い発表の連続でした。驚きです！

発表後は発表された方々との情報交換の場にもなって非常に有意義な時間が過ごせました。

自分の発表については思いのほか盛り上がったので正直嬉しかったです。実際にアプリ開発でエクササイズを実施していく中でどこか大変か、などについてまた発表しようかとも思いました。

次回はクックパッドオフィスに戻るそうです。是非また参加したいです。