けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

Android Test Casual Talks #1

2013年12月13日(金曜日)にリクルート Media Technology Lab にて開催された、
「Android Test Casual Talks #1」なるイベントに参加し、登壇させて頂きました。

# 実は就職して、また東京に来て初の勉強会登壇でした。緊張しました!

めちゃオシャレな会場で、「うわっすげっうわっ」って言ってました。

スライド

今回、僕は「テスト配信プラットフォーム」について発表させて頂きました。

Androidアプリのテスト手法では色んなレイヤーの話があり、主に技術的な解決作としてはJUnitを使ったりRobotiumとかCalabash-androidとかEspressoとか色々あるのですが、あまりユーザーテストやそのツールについては情報少なそうだったので、あえて焦点を当ててみました。

TestFlightやDeploygateの話は皆さんご存じという印象でした。今回はQuoraで偶然見つけた「Vessel」というプラットフォームを調査してご紹介しました。これは多分日本語の記事がなかったので初めて知ったという方が多かったのではないかと思いました。

Vesselが得意とする「A/Bテスト」は「Android Test Casual Talks」のネタとして扱うテストの範疇外な気はしますが、まぁ多少はね?

反省点としては、時間配分がちょっとまずかった(スライド枚数多かった)のと、個人的な「推し」についてあまり紹介できなかったところです。

会社としてはTestFlightを使ってますが、システムとしてはDeploygateのほうが魅力的ですし、今後重要になってくる効果測定をやっていきたいのであればVesselは使いたい、、、というようなことを入れたかったんですが失念してしまった。。

他の皆様のLTを拝見して

テストフレームワークを色々触ってみた ( @dagezi さん )

今流行のlessでプレゼンするスタイル良かった(こなみかん)

BDDとしてNative系(Robotium、Espresso)、Web系(Appium、Calabash)の分類があり、それぞれ特徴を紹介して頂きました。

Robotiumを使っていこうかな〜という話だったと記憶しています。ですよねーという感想でした。(とはいえEspressoもアーリーアダプター的に触っておきたい感はあります)

Androidで使えるモックフレームワーク ( @nowsprinting さん )

Test Doubleというワードを初めて知りました。積極的に使っていこうと思います!

テストをやるにあたりDOC(依存オブジェクト)を解決するのが重要で難しいという話から、AndroidのMockフレームワークの歴史もおさらいして下さり、大変ためになりました。

「最強」のチームを「造る」技術基盤 ( @hageyahhoo さん )

自分が徳島に居た頃に、吉岡さんと接する機会があったのですが、楽天のおじさまエンジニアの方々はアツい方々が多くていいな〜と思いました。

楽天で取り入れられたCI・CDについての苦労・要点などを紹介して頂き、非常に良かった。「これなら俺達でも出来そう!」って思うような説得力のあるプレゼンだったと思います。

なにげに周囲の理解を得るやりかたについても言及されていて参考になりました。

Androidアプリの自動テストケース作成へのチャレンジ ( @geotana さん )

実際の数字を交えたAndroidのテストの状況と、自動テストケース作成への試行錯誤が面白かったです。フランス人エ・・・

詳しい数字は出せませんが、Androidで機種依存は切っても切れそうにないな、と思いました。また、自動テストケース作成は夢物語かと思いましたが、案外いけそうな気もしました。あと1年後くらいにはGoogleがサービス提供してそうだ。

uiautomatorを使うときの一工夫 ( @sumio_tym さん )

Modified-UTF7を挿入して言語入力するアイデアはすげーと思いました。

基本的にAndroidのテスト環境に限らないことですが、日本語やマルチバイト文字の扱いはめんどくさかったりします。(KitKatで文字列関連のAPIがぶっ壊れて酷い有様だった時期もある・・)

「全て選択」を認識できないのには笑ってしまいましたw

Espressoに関して ( @ngsw_taro さん )

熱いKotlin推し。

Espressoは今年Googleが出したテスト用フレームワークで、僕もかなり気になっていたので非常に興味深かったです。ただ本利用するには少し機能が少ないかなという印象もあります。

Fixture Replacement on Android ( @rejasupotaro さん )

レジャスポ太郎さんのブログはよく参考にさせて頂いており(しかもAndroidのトピックかつナウい話題がたくさんある)、是非お会いしたかったのですが。。残念。

まとめ

久々に人前で話す機会を得て、だいぶ緊張しましたが良かったです!機会を下さった @androhi さんと @hotchemi さんに感謝m(_ _)m

あと懇親会のピザうまかったです^^ またピザ食べたいです^^

はじめに

艦これメンテナンスなのでブログ書きますね 意識高いのでブログ書くことを己に強いている

FrameLayout内のViewがFrameLayoutの外に出ても描画されるようにするには

ちょっと意味わからないと思うので図で示します。

@numa08 https://t.co/qNMZRqUkkb pic.twitter.com/a1FACMN8a8— 今中幸太 (@pside) 2013, 11月 26

FrameLayoutの中身としてImageViewなりなんなりが入っている状態でアニメーションなりなんなりをさせてLayoutの境界線を超える場合、基本的にはLayoutの外にいった領域は描画されないようです。

実はこれが非常に微妙で、手元のAndroid2.3端末では境界の外の部分も描画されていたように見受けられたのでちょっと困惑しました。
どうもAndroid4系とAndroid2系ではmarginやpaddingの扱いが微妙に異なるっぽく、そこで機種依存を出していたような気がします。今となってはどうでもよいことなので詳しく検証してません!

結果的には以下のようにして対応しました。

@numa08 僭越ながら自己レスさせていただきますと、 FrameLayout にandroid:clipChildren="false" android:clipToPadding=“false" と書くことで顧客がほんとうに必要だったものを得ることが出来ました— 今中幸太 (@pside) 2013, 11月 26

なんてことないですが、ViewGroupクラスについてのリファレンスをよく読まないと気が付かない感じでつらかった。。。

ちなみに

iOS(Cocoa touch)で同じことをするには、 UIView の clipToBouds なるフィールドを@NOとかにすると良い感じっぽいです。

# 前職でこれを使ったUI改善を行って大満足だった事案ある

はじめに

ひっさびさに技術的な話を書くよ。でも技術の話というよりも、俺はこう思うという話なのでQiitaに上げるよりはブログに書くことにした次第。

extends Activity OR extends MyActivity

Androidアプリ開発するうえで、以下のようにしてActivityクラスを継承したクラスを作ることは非常に多いかと思う。

public class HomeActivity extends Activity {
    // snip
}

まぁ最近はandroid.support.v7.app.ActionBarActivityとかを継承することが多いのですが。
それはそれとして、Activityをそのまま継承する方法はサンプルコードでは非常によく出てくることです。
しかし、Githubなどで公開されているプロジェクトを見ると、あえてActivityクラスを継承したMyActivityという具合のクラスを作り、実体となるHomeActivityなどではMyActivityを継承しているケースが多い。こんなかんじ。

public class HomeActivity extends MyActivity {
    // snip
}

public class MyActivity extends Activity {
    // snip
}

で、どっちが良いかという話が個人的にずっと付きまとっていたのだけど、最近やっと自分なりの答えが出たので書いておきます

結論:どんな規模のアプリであれActivityを継承したクラスを作ったほうが良い

理由としては、例えば以下のようなことをしたいときが多々ある。

  • ネットワーク通信中にProgressBarもつ画面をスクリーン全体に表示させたい
  • 頻繁に似たデザインのダイアログを表示する
  • Toastをよく出す

こういう場合に、直接Activityを継承していると、毎回別々のActivityに同じような命令をコピペしていくことになるわけです。
今更書くことでもないですが、全く同じ実装が複数箇所に点在するというのはひどい。

しかし、Activityを継承したクラスを継承している場合、「Activityを継承したクラス」に実装しておけば命令を使いまわせるわけですね。

public class MyActivity extends ActionBarActivity {

    ProgressDialogFragment progress;

    // snip

    private void toggleProgressHID(boolean isVisible) {
        FragmentManager manager = getSupportFragmentManager();

        if (isVisible) {
            if (progress == null) {
                progress = new ProgressDialogFragment();
            }
            progress.show(manager, "progress");
        } else {
            if (progress != null) {
                progress.dismiss();
            }
        }
    }
}

ちなみに ProgressDialogFragment は以下のURLにあるコードを参照しました。
- Full screen ProgressDialog (for Android)

こうしておけば、toggleProgressHID(true)すると画面全体をProgressBarで覆い、toggleProgressHID(false)すると消えるようになるはず。

注意点として、DialogFragmentを使っているので、Activityを継承していると古い端末で使えないので、継承するクラスはFragmentActivityとかActionBarActivityを使うと良いです。

はじめに

最近まとまったブログ書いてないっすね。。。良くない。

もっと自分をアピールしていかなければ駄目なんだが、リハビリがてらブログを書いてみる。

マチアソビ行ってきた

ちょっと特殊な形でマチアソビに参加していた。非常に良かった。

眉山山頂で日光に当たりすぎて顔面が焦げた。ビビった。

マチアソビの良さは、あらゆる面で非常に緩いこと。これは資金面とか人的リソースという面で仕方ない面もあるんだけど、その緩さを観衆も含めた関係者一同で守ろうとするのが良い。

(尤も、そのあたりの事情をよく知らない方々が緩さを壊してしまうところがあって難しい。暗黙的なものなので、知らない人にとってはそりゃ知らんがな、という事情も理解できるので、そういう問題が出てきたということはかなりメジャー化してきたということの現れなんだろうなぁ)

幾原邦彦と庵野秀明と星野リリィの対談

今回、一番印象に残っているイベントは、幾原邦彦と庵野秀明、星野リリィの対談。渋い。

マチアソビで幾原邦彦と庵野秀明、星野リリィの対談を聞いたのだけど、そのときに庵野さんが「個性を出すということは(東映という)組織には必要とされていない」ということを言ってた気がする。
詳細は覚えてない、俺はこういう風に受け取った。

会社としてのルーチンやスキームにはめていけば収益は保証されるということで、これに逸脱することは許されない。まぁ確かに合理的である。ただ、これは「経営者目線での合理的」である。

IT系業界と人月

IT系業界におけるプロジェクトの大きさとか作業量を表す単位で「人月」というワードがある。ひとりの人間が1ヶ月かかる仕事量を1人月。10人が6ヶ月かかるならば60人月。

この単位はプロジェクトの規模を経営者なり営業担当者が"特殊事情をそぎ落として"勘案するには非常に便利な言葉だと思う。

けれど、微妙な感じである。全員の能力がすべからず一定であれば成り立つと思うが、そうではない。そもそも、俺と俺より優れた人の1ヶ月あたりの生産性であれば、俺のほうが少なくなるに決まっている。俺と俺より劣った人であれば、俺のほうが多くなる。それを平均化してまとめて10人月だ何だと言われれば、能力的に優れた人は優れている部分を評価してもらえないし、劣っている人にとっては高いハードルとなる。場合によっては連日の残業必至である。土日?なんですかねそれは状態。

思うに、ちゃんと人物の得意不得意を考慮できるマネージャであれば人月での丸め込みはしないと勝手に思っている(とはいえ営業担当や経営者や外部とのやりとりで人月という言葉を使う可能性はあるだろう)。もっと言えば、世の中には人月で判断できない生産性を出す人がいる。そういう人をプロジェクトに組み込む意義なりを理解している人間というのはどのくらいいるのだろうか。ともあれ、人月という単位で人を評価し続ける限り、没個性化していくと思う。そこから良いアイデアが生まれるとは思わない。「お前はプログラムを書くためのモジュールなのだ、我々は10のモジュールを6ヶ月稼働させて60人月分のプロジェクトを成功させるのだ!」

俺はIT系業界で仕事をしていて、おおよそ人月で図るには微妙なスキルばかり持っている。だいたいのポピュラーな言語はそれなりにこなせるが、けれど広く浅くなので速度が出ない。そういう意味で自分を人月単位に当てはめれば雑魚そのものである。ただ、JenkinsなりGitなりを使ってビルド環境を構築したり、業務支援ツールをこさえてみたりするというのは、人月に含まれない概念だと思う(そして直接的に組織の利益に関与するわけでもないのでなかなか評価して貰えない)。そういう方向性ばかり強くなってしまった自分にとっては人月という言葉に支配された世界はアウェイな環境だった。

ちょっと話が横道にそれてしまったけれども、自分の強みやアピールポイントがはっきりと分かっていて、その強みを生かして働きたい場合、多くの大きな組織にいることでミスマッチを起こしてお互い損をすると思う。重大な問題が出る前に早くその組織から抜けてアピールポイントを生かせる場に行くほうが良いのかも知れない。あるいはフリーランスとして活動するとか。(ただ、土地という鎖に縛られている人もいる。これは別の機会があれば書きたいけれど、都心部ほど地方は職業選択の自由がない。)

ともあれ自分にとっても何が正解かはよく分からない。人それぞれだとも思う。けれど自分にとっては人月という言葉はいろいろあってNGワードになってしまった。やれやれ。

影響を受けた記事

こういう真面目なこと書くのは、以下のブログを読んだからです。

俺は今はAndroidアプリエンジニアとして活動してますが、高校・大学時代はもっぱらウェブエンジニア的側面のほうが強かったりして、結果いろんなことを知ったり適用できています。それでも知らない世界は広い。

ともあれ、自分の方向性とかを考えなければならないのだけど、自分の創作意欲の根底にある「人を幸せな気持ちにするものづくり」というところはずっとあって、それはかなり原始的な考えで、でも原始的であるからこそ揺るぎなくて強くて。

自分が「一人月」で満足か

人月より、人間がスケールする方を選ぶし、その手段をとる

この見出し文は2013年上半期の自分に対する苛立ちへの回答そのものだと思った。

ルーチンは人月によって解決できるが、そもそもルーチンのタスクはプログラマがコードによって解決するべきであるし、実際にそうされてきた。それを認めないのは非生産的な場所にいた人間の自己保身であると思っている。

これは2013年上半期の周囲に対する苛立ちとか怒りへの回答そのものだと思った。

マチ★アソビ

10月12日から14日にクライマックスを迎える、徳島県徳島市で行われるマチ★アソビも今回で11回目です。どんどん規模が大きくなっていき、徳島の地で学生をしていた私といたしましても非常に感慨深い思いでございます。

マチ★アソビのイベントを纏めたGoogleカレンダーをつくりました!

さて、マチ★アソビのフライヤーも、年々大きくなったり折り方が変わったりしております。年々密度が高くなっていくのはイベントが大きくなっていると言うことで嬉しい限りです。

ただ、お目当てのイベントを探すのがけっこう難しい感じです。

個人的に「このイベントの裏のイベントなんだっけ?」というのを一発で見れるようにしたかったので、せっかくなのでGoogleカレンダーにイベントをまとめてみました。

マチ★アソビのGoogleカレンダー

※当カレンダーの制作者はマチ★アソビおよびこのイベントの主催や関係者とは関係がございません。よって、当カレンダーの妥当性を保証するものではございません。当カレンダーに記載されている会社名並びに商標は各団体や各企業に属します。

つかいかた

上記リンクを開くと、「予定リスト」の形式で主要会場のイベント一覧が確認できます。

右上の「週」「月」で表示形式をお馴染みのカレンダー表示にすることができます。

右下にある「+ Googleカレンダー」リンクを押すことで、あなたのGoogleカレンダーにイベント一覧カレンダーをインポートすることができます。

例えば「林間ステージ」だけが欲しいという操作も可能です。

Googleカレンダーにインポートして、お使いの携帯端末でイベントの情報を見たり作戦を立てたり、色々とお使い頂けると思います。

間違いを見つけたら・・・

以下のフォームからご連絡頂ければ対応させて頂きます。

つくったひと