2018年2月11日日曜日

DroidKaigi2018で登壇してきました『Androidではじめるデザインスプリント』

DroidKaigi2018 Day.2 Room2 16:50〜 『Androidではじめるデザインスプリント』というテーマで登壇しました。



当日はたくさんの方に足を運んでいただき緊張もMAXでしたがとても良い経験をさせていただきました。

なぜこのテーマを選んだのか


  • 応募リストを見て「デザイン」というキーワードがほとんどなかった
  • 当時後輩の育成について、企画プロセスの体験やチーム内の暗黙知の共有のためにデザインスプリントが役に立つのではと考えていた
  • 「チームビルディング」カテゴリが今年から追加されたので関心が高いのではと思った
  • 締め切り3分前に思いついてしまった


もう一本暖めていたConstraintLayoutに関するテーマもちょっと前に応募していたのですが、
こういうときって勢いで書いたもののほうがよかったりすることありますよね。
今回トーク採用いただいて、DroidKaigiの講演のバリエーションを広げるのに貢献できたのならよいなと思います。

一方「デザイン」という単語を含む応募が少なかったかつたくさんの方にご聴講いただいたということはまだまだ需要と供給がマッチしてないのかなと思ったりします。
というか私がもっとデザイン系のお話聴きたかったです。
来年はもっとデザイナーの方などにも応募してもらえるといいなと思います。

内容についての補足


デザインスプリントそのものについての説明はかなり端折っているので、実践する前にできるだけ参考リストのリンク先を読んでほしいです。
手法が色々選べるのがデザインスプリントのよいところであるしそういった面を中心にした説明を行ってしまったけれど、
本質的にはチーム全体でユーザーに向き合って失敗しながら良いプロダクトを目指すのがデザインスプリントです。
手法にとらわれず、実行すること、検証すること、ユーザーと向き合うことを大切によいプロダクトを目指していただければと思います。

準備について


  • 本は目次ができたら8割勝つるけど発表は目次ができたらそこがスタート、発表練習を始めてからが本番
    •   執筆以上に答えがない
    •   文字で伝えるのと登壇で伝えるのは全然違う
    •   アガリ症なんだからもっと飽きるくらい練習してもよい
  • 家のサブディスプレイで画面構成チェックしといたのはよかった
  • 同僚に2回ほど練習に付き合って聞いてもらったのが本当によかった
    •   構成自体のブラッシュアップがすごく効いた
    •   プレゼンのTips虎の巻を共有してもらったのがすごくよかった


発表について


  • 直前に控室でプルプルしてたらスタッフのひとたちがちょいちょいいじってくれたのが心強かった
  • 発表時のPCの状態は単純に「デスクトップを掃除しておく」「余計なアプリケーションを切る」「Wifiを切る」がよさそう。別垢に切り替えようとしてパニクった
  • マイクの向きは難しいなぁ
  • マイクチェック時に「2階席ー!」とか適当な喋りを入れてすみませんでした。乗ってくださったご聴講者の方々ありがとうございました
  • 発声、ジェスチャーの入れ方などはまだまだ改良の余地がありそう
  • 本番30分ピッタリで喋れてよかった


謝辞


発表の準備期間中に転職、私生活、他のタスクなどが重なり、考えていた以上に発表が近づくにつれてパニック状態に陥ってしまっていました。
この時期にフォローしていただいたDroidKaigiの仲間たち、家族、新しい同僚には感謝してもしきれません。
また、退職したにもかかわらずブログから画像の利用や会社でやったことの発表を快く許可していただいた前職にも感謝いたします。

最後に


自分にとっての当たり前が他の人にとっては貴重な知見になることもある、という言葉を糧に準備をして発表をしてきましたが実のある発表になったかは自分ではよくわかりません。
ご聴講の方はDroidKaigi2018公式アプリからフィードバックをいただけると嬉しいです。

2018年1月1日月曜日

2017年ふりかえり

mochicoです。
shirajiさんや釘宮さんがやってるふりかえりテンプレートで1年をふりかえりたいと思います。

2017年を振り返る - アナログ金木犀


なんだか疲れていたらしい。
この頃は技術書典とDroidKaigiと東工大の産学連携プロジェクトEDPに参加していてぐったりしていた気がする。
おもしろそうなことには首を突っ込む主義だけどさすがにやりすぎた。

2月


ペパボテックカンファレンスモバイル編で喋らせてもらいました。
iOSとAndroidと両方やるということでテーマを絞りきれず的を得ない話になってしまったと反省しております。。。


EDPの発表会もありました。
EDPは東工大を中心に美大生、社会人ソフトウェアエンジニア、大田区に籍を置く企業の社会人などが入り交じるチームで半年間かけてデザイン思考のプロセスに則って全く新しいプロダクトを作るというプロジェクトです。
今考えるとこのプロジェクトでは個人的にはモノを形にしなければならないというところに寄りすぎたのは良くなかったかなぁと思います。
ここで学んだことは社でも生かしております。一緒に参加していた同僚のスライドが良いです。


この前後咳が止まらず死ぬかと思った。
書典の方で勉強会ひらいたりサークル応募締め切りだったり配置やったりいろいろやってて相当疲れてたらしい。

3月


DroidKaigiやってました!主に企業ブースのお手伝いしてたけど当日のツイートみてるとかなり楽しんでた様子

4月




技術書典なんとか無事開催〜〜〜


続けて超技術書典。
二連続開催やらライブ執筆やら見本誌展示やら初めての試み続きで本当羊さんはどうかしていると思った。



今年前半はこれで死ぬかと思った・・・

5月

LTでお話しました。

GoogleI/Oいってきました。
InstantApps追ってたんだけど結局形にできてない。。。

6月


弐瓶勉のBLAM!が最高だった


この頃から少しずつ生活を楽にしようとしているっぽい。
また、ツイートはないけどカレンダーを見るとオンリーイベント準備本格的にやり始めたのもこの辺っぽい。


そして次の準備が始まる。

7月


スプラトゥーン2楽しいですね。ちなみに今もB帯・・・


ペアプロよかったらしい



地味な不調が多かった1年でした。今は膝が痛い。

8月


夏コミでした


事件

9月


オンリーイベントのため仕事から外してもらい気味でしたが、いろいろ準備してました。
例のアプリの話で他のメンバーがめうめう言ってるのをハラハラしながら見守ってました。

10月



次回の開催前は晴天祈願に行くつもりです。

11月


ヤバい。がんばる。


11月はオンリーイベントラストスパート&ペパボ最終出社に向けてお片付けしてました。

12月


退職してました。
前の会社で受託やゲーム中心の会社でアプリやってきて、それをちゃんとサービスとして継続的に開発し続けられる、自分のやっていることを説明できる、自信をもって自分はプログラマーだと言えるようにさせていただいた最高の会社でした。
理念の「もっとおもしろくできる」に則り、次のチャンスが見えたのでチャレンジすることにしました。
ペパボのみなさま、本当にありがとうございました。


そして、オンリーイベントもとい結婚式してました。
この辺のあれやこれについてはあちらが書いてたりするけど私も技術書典でなんか書くかもしれない。

他、論理無職として12月はゆうちょダイレクトが停止されてるの解除したりdocomoの氏に回線を解約したりドラム式洗濯乾燥機買ったり本読んだりとおやすみいただいてました。


2018年


本年もよろしくお願いします。

2016年11月28日月曜日

技術書の歩き方勉強会「達人プログラマー」編 で登壇してきました

技術書典のご縁で @takahashim さんにお誘いいただいて
技術書の歩き方勉強会「達人プログラマー」編 で登壇してきました。
トークセッションの自己紹介でもお話したとおり、
新卒の頃に本の編集者を目指していたこともあったのですが
まさか技術本の紹介イベントでお話することになるとは、ちょっと不思議な気持ちでした。


トークセッションでお話しした内容などは #TechBookWalk で実況されています。
イベント開催にあたって、人数配分やハッシュタグ、イベントタイトルなどで入れ知恵をさせていただいてうまくハマった施策もあっておもしろかったです。
いくつか特によかったなと思う点を挙げておきます。

参加人数とキャパ

最初は募集40人から始めてすぐにいっぱいになりましたが、広い会場をご提供いただいたspeee様のおかげで100人まで増やすことができました。
東京のイベントでは6割近くドタキャンが発生することも少なくないのですが、会場がいっぱいになるまでご参加いただけてよかったです。

発表内容について

久しぶりの登壇でしたがちょっと練習して臨んだのであまり緊張せず発表ができてよかったです。
@moro さんの発表の「本と出会うタイミング、コンテキストが重要」というお話が印象深かったです。
トークセッションは初めて経験する発表形式でしたが、
@takahashi さんの絶妙な司会と主催 @shimada さんの鋭い引用に引っ張っていただいて、
好きな本について好き勝手お話させてもらうことができとても楽しかったです。
最後に、いつも良い技術書を出してくださるオーム社さんに拍手が沸き起こる暖かい会場でした。

#TechBookWalk

ハッシュタグでたくさんの方に実況していただいてTLにも会場の雰囲気が伝わってよかったです。
気になる技術書があったらまたこのハッシュタグを使っていただけたらと思います。
実は事前に日本語ハッシュタグで質問内容を募集したりもしていたのですが全然利用されなかったので、
イベントのハッシュタグは分散させてはいけないなと反省しました。

自分はまだ達人プログラマーには程遠いかもしれませんが、
技術書好きの一人として登壇させていただいてとても楽しかったです。
テーブルに並べてた本で読んでないものもあるのでまた読みます。

2016年8月29日月曜日

Android N PreviewのCookieManagerでCookieが取得できなくなる問題を踏んだ

Android N Previewで、CookieManager に変更があり、N以前では取得できたCookieが取得できなくなる問題に当たったのでメモです。

同じ問題はフォーラムでも報告されていました。
情報が少ないと言って閉じられているようですが。

NからOpenJDK に移行するにあたり、expiresでパースできるDateFormatが変わったようです。

N以前

N

NのexpiresのDateFormatはRFCの定義に沿っているようです(10.1.2  Expires and Max-Age)。

N以前もNも、定義されていないフォーマットの場合maxAgeに0がセットされます。

CookieStoreの実装も変更されています。
N以前ではaddメソッド内で追加時にCookieの値のチェックはありませんでしたが、NではmaxAgeが0の場合はcookiejarに追加されません。

つまりN以前でCookieManagerから取得できていた`Mon, 29 Aug 2016 21:15:00 -0000` のようなフォーマットのexpiresをもつCookieは、Nでは取得できないことになります。

expiresのパースに失敗したらCookieStoreに追加しない、というのはRFCに従えというのはそうですが、ちょっと困るケースもあります。

暫定的な処置としてmaxAgeを上書きしCookieManagerに再度追加するコード例です。
https://gist.github.com/mochico/c1acf4ca0d5caf76d29fd12d239053f3

2016.12.31 追記
https://code.google.com/p/android/issues/detail?id=220564
こちらの問題修正されたそうで近いうちにリリースされるそうです。
今からだと7.1.2以降ですかね。

2016年5月20日金曜日

GoogleI/O2016で発表されたAndroidInstantAppsについて聞いてきた

今年もGoogleI/Oに参加することができまして、実りの多い旅になっております。

わくわくする発表が多々あったkeynoteですが、私が特に気になったのは、
モバイルバックエンド系の機能をまとめなおしPlayServicesを置き換えようとしているFirebaseと、
ダウンロードなしにアプリを実行させるというInstantAppについてです。

Android Instant Apps

https://developer.android.com/topic/instant-apps/index.html

keynoteとWhat's new in Google Play for developersで発表されたAndroid Instant Appsの概要は次のとおりです。

  • ダウンロードなしにアプリを起動しほぼ製品版と変わらない機能を使用することができる
  • Android4.1から使用できる
  • 次の4点を守ることでInstantAppにすることができる
    • ディープリンクをサポートすること
    • Module化すること
    • 制約を適切に処理すること(Handle Restrictionsと書いてあったけど訳があってるか自信ない)
    • 新しい機能に対応すること



このInstantAppにするための条件の内容について、不明な点が多かったのでGooglePlayのサンドボックスで聞いてきました。




ざっくり言うとツイートの通りですが、もう少し詳しく書きます。

  • InstantAppのAndroidManifestとAPKはPublishしているアプリ本体とは別
  • 機能(Activity)ごとにModuleに分割する。これをModularizeと言ってたらしい
  • 1Moduleあたり4MB以内に収めること
  • InstantAppのModuleは対応するためのTempleteが公開される(AndroidStudioの新規Moduleウィザードに追加される)予定
  • ひとつのInstantAppにModuleは複数含めることが可能
  • Module間での呼び出しも可能。DeepLinkで各画面を起動する
  • DeepLinkで呼び出されるたびに対応するModuleが一時的にPlay経由でダウンロードされる
  • Permissionは本体と同じものをAndroidManifestに指定する。ただ、これが推奨なのか機能的な制限なのかまでは未確認

対応方法自体は特別難しいことは言ってないように見えますが、実際に現在動いているアプリを機能ごとにモジュール単位に分割するのはかなり覚悟が必要そうです。


ここに書いた内容はこの機能が使用可能になるまでまだ間が(だいぶ)あるため、変更がある可能性が大いにあります。
実際に使用できるようになるまでは油断はできません。




keynoteのロードマップで見ても年内に使用できるようになる可能性は低そうです。

AndroidInstantAppsのページの「I'M INTERESTED IN ANDROID INSTANT APP」の登録フォームに、アプリの情報について入力する項目があるので、使ってみたい人は登録してみると今後何か情報が得られるかもしれません。

2016年4月24日日曜日

ドメイン駆動設計読書会 第2章 コミュニケーションと言語の使い方

エリック・エヴァンスのドメイン駆動設計の読書会で理解したことをメモしていきます。今日は第2章です。

第2章 コミュニケーションと言語の使い方

ユビキタス言語:ドメインモデルが対象とするスコープ内で使用するドメインエキスパート、開発者間での共通言語
プロジェクトではモデルによるコミュニケーションのみでなくユビキタス言語による会話が不可欠である。
ユビキタス言語は使用中にひっかかりや違和感があれば変更されなければならず、それに伴いモデルも変更されるべきである。

声に出してモデリングする

ドメインモデルを改良するためには声に出してみるとよい。表現すべきことをより簡潔に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること

1つのチームに1つの言語

ドメインエキスパートが抽象化したモデルを理解できないからといってドメインモデルから遮断したり、別のモデルを作成してはいけない。ドメインエキスパートがモデルを理解できない場合には、モデル側に何らかの問題がある。
ユビキタス言語を用いることにより、開発者間の会話やドメインエキスパート間の議論、そして、コードそのものでの表現がすべて、共有されたドメインモデルから得られた同一の言語に基づくようになる。

ドキュメントと図

UML図はオブジェクト間の関係性を表現するのには役立つが、オブジェクトの概念の定義については表現しきれない。また、実装の詳細はコードで表現されるべきである。モデルは図ではない。図はモデルについてコミュニケーションするためのツールである。

書かれた設計ドキュメント

ドキュメントはコードや会話でのコミュニケーションを補わなければならない。アジャイルやXPではコード自体を設計ドキュメントとして扱うが、「なぜそうするのか」という背景の部分までは表現できない。ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない(むしろその方法を知りたいんだけど、詳細なドキュメントについて指示するつもりはないと筆者は書いている)。
ドキュメントはプロジェクトの活動に取り込まれていなければならない。ユビキタス言語に耳を傾け、ドキュメントとの相互作用を観察することで、活動にドキュメントがプロジェクトの活動に取り込まれているかどうかを確認できる。

実行可能な基盤

コードが引き起こすふるまいこそが現実である。コードによって伝えられるメッセージができる限り正確であるためには、規律を守り、設計について特定の考え方をし、要件を書くのに使用されたユビキタス言語に基づいていなければならない。

説明のためのモデル

実装、設計、チーム内のコミュニケーションの根底にあるモデルは1つだけであるべきだが、説明のためにソフトウェア設計とは直接関係しないモデル(この文脈だと図と言ったほうが正確な気がする)を使用することは人々の理解を助ける。

2016年4月7日木曜日

ドメイン駆動設計読書会 第1章

ひょんなことからエリック・エヴァンスのドメイン駆動設計の読書会をすることになりました。
会話の中で理解したことをメモしていきます。今日は第1章です。

第1部 ドメインモデルを機能させる

  • ドメイン:ユーザーの活動や関心についてプログラムを適用する対象領域
  • ドメインモデル(モデル):ドメインについての知識を抽象化したもの。特定の図ではなく、図で表された考え方そのものを指す。
  • 言語:共通認識を共有するための記号・手段・取り決め。かな。
  • エンティティ:データのかたまり

ドメインモデルの有用性

  • モデルと設計の確信が相互に形成し合う
  • チームメンバが使用する言語の基盤になる
  • もっとも関心のある要素を区別する

ソフトウェアの核心

ドメインについて理解することで適切なソフトウェア開発を行うことができる。

第1章 知識をかみ砕く

PCB基盤の設計支援ツールを例に、モデルを作ることで共通言語を得、本当に関心のある事柄を抽出し、プロトタイピングを行い、イテレーションを回すこと=知識をかみ砕くことで効果的なソフトウェア開発を行うことができることを説明

効果的なモデリングの要素

  • モデルと実装を結びつける
  • モデルに基づいて言語を洗練させる
  • 知識豊富なモデルを開発する
  • モデルを蒸留する
  • ブレインストーミングと実験を行う
これにより知識をかみ砕く。

知識のかみ砕き

ドメインエキスパートと開発者チーム全員がモデルを噛み砕くことで、モデルにビジネスに関する深い知識が反映され、実装の助けになる。

継続的学習

継続的にドメインモデリングのスキル、技術的な知識、ドメインについて学習する。
初期の作業によって知識のかみ砕きというプロセスを発動させ、それによって以降の全作業を効率的に行う。

知識豊富な設計

これらのプロセスによって知識をかみ砕くことで、モデルを変化させ、実装をリファクタリングし、新しい知識をアプリケーションで使用することができるようになる。