2016年11月28日月曜日

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

技術書典のご縁で @takahashim さんにお誘いいただいて
技術書の歩き方勉強会「達人プログラマー」編 で登壇してきました。
トークセッションの自己紹介でもお話したとおり、
新卒の頃に本の編集者を目指していたこともあったのですが
まさか技術本の紹介イベントでお話することになるとは、ちょっと不思議な気持ちでした。
トークセッションでお話しした内容などは #TechBookWalk で実況されています。
イベント開催にあたって、人数配分やハッシュタグ、イベントタイトルなどで入れ知恵をさせていただいてうまくハマった施策もあっておもしろかったです。
いくつか特によかったなと思う点を挙げておきます。

参加人数とキャパ

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

発表内容について

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

#TechBookWalk

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

自分はまだ達人プログラマーには程遠いかもしれませんが、
技術書好きの一人として登壇させていただいてとても楽しかったです。
テーブルに並べてた本で読んでないものもあるのでまた読みます。
投稿者 時刻: 0 件のコメント:
ラベル: ,

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以降ですかね。
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

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」の登録フォームに、アプリの情報について入力する項目があるので、使ってみたい人は登録してみると今後何か情報が得られるかもしれません。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2016年4月24日日曜日

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

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

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

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

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

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

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

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

ドキュメントと図

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

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

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

実行可能な基盤

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

説明のためのモデル

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

2016年4月7日木曜日

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

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

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

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

ドメインモデルの有用性

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

ソフトウェアの核心

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

第1章 知識をかみ砕く

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

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

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

知識のかみ砕き

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

継続的学習

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

知識豊富な設計

これらのプロセスによって知識をかみ砕くことで、モデルを変化させ、実装をリファクタリングし、新しい知識をアプリケーションで使用することができるようになる。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年2月23日火曜日

DroidKaigi2016を支えたロジスティクス

2月18日・19日に開催されたDroidKaigi2016に、運営として参加してきましたmochicoです。
11月ごろCFPの公募とともに開始されたスタッフの募集に応じ、スタッフウェア調達とランチボックス搬入・搬出、アフターパーティの受付を担当していました。
先日主催の羊さんに「それ（調達）はロジスティクスだね」と言われてカッコいいのでロジスティクス担当ということにします。
（実際にはロジスティクスとは調達流通在庫管理や兵站管理のことですので、ここでは本来の意味と異なると思います。）
ここでは主にランチボックスのロジスティクスについて、またそれを支えたDroidKaigiの運営方法についてお話します。
これから技術系カンファレンスを運営する人の参考になればと思います。

プロジェクト管理とインフラ

DroidKaigiは運営もほぼ全員エンジニアなので、プロジェクト進行管理がすごくソフトウェア開発っぽかったです。
タスク管理は全てgithubのissue。
コミュニケーションはSlack。
ドキュメント管理はGoogleDrive。
2週に1回くらいの物理的な定例MTGはハングアウト参加者もいたり、週1でSlack上でissueをさらう遠隔定例MTGもありました。
実は、当日の連絡経路も全てSlackでまかなっていました。これには良い点と悪い点があったのですが後述します。

ランチボックス作戦


私がランチボックス担当に着任したのは年も明けた頃でした。
普段工数は見積もっていますが、参加者の数や配布率の見積もり、ランチのクオリティと予算の調整や搬入・搬出など初めての規模と経験でした。
なお、私は事前調査と当日のまとめ役はやらせていただきましたが、直接の業者さんとの交渉はもぐたそさんの機転と剛腕に支えられております。
ランチボックス作戦はこんな感じでした。
  • めしくるさんのコンシェルジュに相談。今回はお願いできなかったですが、とても丁寧なご対応で、ランチの予算感や業者で対応できることを教えていただき大変助かりました。
  • 東工大搬入実績のあるSushi&Beyondさんに教室までの搬入をお願いすることに決定。名前のインパクトからしばらく「ビヨンドする」がスタッフ間の流行語になる。のちにアフターパーティも含めこのSushi&Beyondさんにお願いしたもぐたそさんの英断をたたえることになる。
  • 前日に、連絡の行き違いがありSushi&Beyondさんから予定していた休憩時間の間に各教室内に搬入は難しいと判明する。講演中は絶対に音を立てない配慮が必要なため、講演中に運び込むことができない。止むを得ず予定を早めて基調講演からの移動時間中に間に合うようにすると決めたが、実際に教室に置いておくことができるかは正直賭けでした。
  • 当日、教室を見て先に搬入可能と判断
  • 担当5人で基調講演中に他の仕事から抜け、Sushi&Beyondさんと合流し、4教室にそれぞれランチ・お茶を搬入。12:00の午前の公演終了まで待機。
  • 12:00より、大きいA・B教室に2人、C・D教室に1人づつ+遊撃ヘルプの計6人の体制で配布開始。私は控え室とヘルプ要員として待機。A・Bの混雑が割と強かったが、Slackで連絡を取り合い、なんとか無事配布完了。様子を見つつ、13時までにSushi&Beyondさんの指示通りの方法でゴミを回収し、順次搬出。
  • 2日目、PDCAを回し混雑度から再分配を考えC・DからA・Bに2箱ずつ搬入をずらす。A・Bではあらかじめ箱を開けておき、手渡しをスムーズにできるよう改善 が、ゴミ袋の用意を忘れてたため、配布のために走り回る。（後にゴミ袋は前日に控え室に預けられ埋まってたことが判明）
  • 参加者のご協力とスタッフ、Sushi&Beyondさんの慣れもあり2日目の配布・ゴミ回収は割とスムーズに完了
実は当日一番難しかったのは、どうしても出てしまうあまりの廃棄の判断でした。
なんとか撤収までにきれいにお片づけすることができましたが、この辺は次回に生かせる知見の山でした。
また、経験値のない中でぶっつけな状況の多い当日を支えたのはSlackでの連絡でした。
部屋ごと、係ごと、話題ごとに分かれたchannelで文字ベースで現状報告やヘルプ要請を行っていました。
適度に分かれたchannelは情報の取捨選択をスムーズにし、手が足りない中で文字ベースのコミュニケーションはリアルタイムもタイムシフトも自由自在で助かりました。
ただ、これは今回なんとかスタッフ用のWi-Fiを確保できたからできたことであり、本来は無線などを使用するべきかもしれません。
また、スタッフがみんなスマホにかじりつく光景はどのように参加者のみなさんの目に映っていたのでしょう・・・
こんな感じで、至らないところもあったと思いますが、ランチの写真をTwitterにあげていただいたりとDroidKaigiのひとつのコンテンツとして楽しんでいただけたようで嬉しい限りです。


公式アプリへのContribute

DroidKaigi2016のアプリは@konifarさんが作ったアプリをベースに、オープンソースで公開され、開催中も（3日たってこの記事を書いている今も）コミットが飛び交うこの上なく生きのいいリポジトリでございます。
実は、最終MTGであるパンフレット類の袋詰めの日に、@teshi04とカフェでDroidKaigiを眺めて気づいたバグを、帰って見直したらさっくり直せそうだったので、ちょっとpull-requestを送ったら@konifarさんが一瞬でマージしてくれました。
ほんの小さな修正でしたが、Contributorに乗せていただいてちょっと（かなり）嬉しい。

DroidKaigi2016を終えて

こんな感じで当日は水とお茶とランチボックスを持って駆け回っていたためほとんどセッションを見ることができなかったのですが、タイムキーパーで @konifar さんのセッションと北村さんのセッション、中西さんのセッションだけ参加させていただくことができました。
どれも本当におもしろくて学びがあって、本当にこのカンファレンスを開くことができて、少しでも貢献することができてよかったと思いました。
正直、運営として参加するのは自分の時間を削ることも気を使うこともかなりあり、無条件にオススメはできません。
ですが、コードを書く以外でもAndroidのために何かしてみるというのは案外おもしろいです。
全部終わった後@tnjさんの作ったオープニングを見て、ちょっと泣きそうになったのは内緒です。
最後になりますが、全ての参加者、講演者、スポンサー、スタッフ、業者のみなさま、控えめに言って最高でした！ありがとうございました！
投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)