LoRaWAN ハンズオン by SORACOM ✕ I-O DATA ✕ JAWS-UG金沢 に行ってきた

jawsug-kanazawa.doorkeeper.jp

その前の土曜日も、Kanazawa.rbのために金沢まで行っていたので、中三日で金沢でした。

早めについたので、会場近くにあったマルツ金沢西インター店に行ってみました。

富山で電子部品を買おうと思うと、無線パーツぐらいしか知らないので、それ以外の久々の電子部品屋(?)でした。

売り場が広くて、抵抗だったり、センサー系だったり、TWE-Lite系のデバイスだったり、いろいろありました。

ただ、無線パーツにあったような?RaspberryPi用のディスプレイとかは見当たりませんでした。得意不得意とかはあるのかな?知らんけど。

まぁ、家からはかなり遠いので、次来る機会とかはあんまりなさそうかなーと思います。大抵のものはネットでも変えますしね。

ハンズオン前のセミナー?

  • 深センの話は面白かった。成長度合い・混沌度合いがやばそう。資料は公開されてなさ気?
  • 本編の、LPWAの資料は https://www.slideshare.net/SORACOM/jawsug-lpwa
  • IoTの用途としては、工場・デバイス(困ったら再起動で動く)・自販機などの通電してるもの・移動するものあたり?
  • 消費電力と通信速度は比例するので、画像とか送りたいのであれば、ちゃんとした電源が必要。長期間電池駆動させたいのであれば、データを絞る。
  • LoRaWANの一式を準備しようと思うと、10万近くかかる?ゲートウェイが高い。けど、1個で10km程度をカバー出来るっぽい。
  • また、消費電力もかなり低い。送信時でも、LED光らせる程度の電流量。
  • ライセンス系であれば、LTE Cat.1はすぐにでも使える。ただし、スループットが高い=消費電力も多い。LTE-MやNB-IoTは、基地局の更新が必要なので、今後に期待。
  • LPWAの通信量はかなり少ない。4.4秒に11Byteしか送れない。
  • SORACOMに乗っかっておけば、Funnelなどを間に置いておくことで、アプリケーション側の変更がなく、LoRaWANとSigfoxを入れ替えたり出来る。

ハンズオン全体の雑感

  • 資料は https://github.com/soracom/handson/wiki/LoRaWAN%E3%83%8F%E3%83%B3%E3%82%BA%E3%82%AA%E3%83%B3 。これを見ながらやれば、問題なく進められた。
  • 温度センサとArduinoをつなぐぐらいだったら、ジャンパ3本ですぐに出来る。
  • SORACOMすごい。Arduino側のコードに数行追加するだけで、値が送れる。
  • SORACOM Funnelすごい。AWS IoTに簡単に送れる。
  • AWS IoTすごい。簡単にAWSの他のサービスに値を送れる。今回はCloudWatchに送って、グラフ化・アラームなどが少ない手順で出来てた。
  • 来てる人は、デバイス系の人が多かったっぽい?詰まってそうな人はほとんどいなかった。

全体の感想

一定の区域(牧場とか、ライブ会場とかも行けるかも?)内にセンサーを撒いて、それらの情報を監視するのであれば、LoRaWANのゲートウェイを1台用意して、サービスを提供することは出来るかも。ただ、それなりの初期・ランニングコストは掛かる。10万単位ぐらい?(要計算)
ビジネスとしてやるのであれば、すでに選択肢には入るのかも。

もっと広範囲、BtoCでデバイスを売ることを考えると、ライセンス系のLTE回線を利用したものになりそう。
"SORACOM Air for セルラー"を使いのが良いのかな?

ガチデバイス勢になることは難しいけど、ちょっとした試作だったり、デバイス側の言葉を理解できるってのは今後は武器になりそうなので、このへんの領域も張っていこうと思いました。
何より、現実世界と相互作用を起こせるというのは、アプリ系だと無いので、楽しいですね。

あとは、雑なメモ

IoTで用意するもの。 モノ・ネットワーク・クラウド モノ・コトをデジタル化する=IoT 例:工場・デバイス(電源入れれば通信が出来る)・自販機・持ち運べるなど

中長距離無線が課題になってくる。 セルラーの回線は「人」が利用する前提になっているので、IoT用途に向かない。

LPWA 消費電力と通信速度は比例する。 NFCとかは近距離・低電力。 BLEなどはちょっと電力が必要。 Wi-Fiは電力必要だが、速度出る。 セルラーなどは1 - 10km程度。電力は必要。 LPWAは低電力、速度は低い。 アンライセンス系は、許可不要で建てられる。LoRaWANとかSigfox。 メンテナンス・オフィスセキュリティ・ホームオートメーションで使われるであろう、と言われている。

LoRaWAN, Sigfox kmレンジの長距離通信 安価、低消費電力・低速度 20 - 30mAぐらいで送信出来る。 LoRaWAN標準構成:デバイス - ゲートウェイ - ネットワークサーバ - アプリケーション

ライセンス系は、3大キャリアしか基地局を作れない。 LTE Cat.1はスループット高い、消費電力も高い。今すぐにでも使える。 LTE Cat.M1, LTE Cat.NB1は、基地局側のアップデートが必要。M1はスマホみたいにつながり続ける。

LoRaシールドは8,000円ぐらいするけど、それを合わせても2万円ぐらいで1デバイスを試作出来る。

LPWAでは4.4秒に11Byteしか送れない。それ以上が必要であればセルラー通信。 電池駆動で数ヶ月〜数年稼働出来る。

LoRaWANとSigfoxはほとんど同じ。 ただ、LoRaWANは基地局を自分たちで立てないといけない。

SORACOMに乗っておけば、Funnelの先を同じで、LoRaからSigfoxやセルラーに乗り換えやすい。

LoRaは変調方式。AMとかFMとか。LoRaWANはプロトコル。 AS923は、アジアの923MHzを利用するもの。海外では使えない。輸入などの際には注意。

DroidKaigi 2018 に参加してきました。

droidkaigi.jp

2/8, 9で開催された、DroidKaigi 2018に参加してきました。

前回は、DroidKaigiアプリへのコントリビュートだけで、現地には行けなかったのですが、
同僚の根回しのお陰で、会社のお金で参加できました!(「来年からは、スピーカーじゃないと金出ないですよ?」と脅されましたがw)

雪のせいで、ちゃんとたどり着けるのかが不安でしたが、予約していた高速バスは無事運休になり(キャンセルする手間が省けた)、
朝の6時台の新幹線に乗って、10時には余裕で着席出来ました。
(建物の入口を探して、ちょっと迷いましたが。。。建物デカすぎ。)

今年も、事前にアプリのコントリビュートは出来ましたが、この3件だけ で、あんまりインパクトのある修正はできなかったなーという反省はあります。
ただ、気がついたら私の作った danger-checkstyle_format が使われていたのは嬉しかったです。 https://github.com/DroidKaigi/conference-app-2018/pull/219#issuecomment-357939250

全体的な感想

  • お祭り感があって、とりあえず最高だった。(語彙
    • セッションごとの民族大移動も、今思えば楽しかったようなw
  • スライドに出てくるサンプルコードは、ほとんどがKotlin。(Javaもいくつかは見かけた)
    • Kotlinやっとかないと、、、という焦りは覚えました。
  • アーキテクチャ系の話になると、Dagger2やRxJavaが当たり前に出てくる。
    • これも、やっとかないとついていけなくなる、、、という焦りが。
  • 聞きたいセッションが同時間帯にいくつもあり、体が足りない。
    • あとで動画は公開されるそうですが、いつでも見れると思うとなかなか。。。
  • 1日目のアフターパーティーで初めましての人と、そのまま飲みに行け、次の日にはセッションの合間に喋れた。
    • ただ、2日目のスピーカーは、顔と名前が一致してないので、風船つけててもどう声をかけていいのかわからない。。。(コミュ力。。
  • アーキテクチャ系のセッションを多めに回りましたが、唯一の正解はなさそう。
    • 当たり前かもですが、Android Architecture Componentの登場も決定打にはならない。

あとは、個別のセッションの感想メモ。

ウェルカムトーク

久々(始めてかも?)の大規模なカンファレンスでした。
オープニングのアニメーションがちょーかっこいい。

Kotlinのカンファレンスを日本でやるらしい。やっぱり、Kotlinは熱いっすね。

Kotlinアンチパターン

Kotlinアンチパターン

Kotlinは、言語仕様的なところはちらほら見てますが、がっつり実戦投入したことはないので、とてもためになったセッション。

実際に使い始めると、このへんで困りそうなので、そのときに見返すべきですね。

全般的に、Kotlinは表現力が高いというか、いろいろ書き方があって、うまいこと使いこなせれば便利だけど、下手なことをすると可読性が下がりそうな印象。
やるときは、メンバー間でいろいろと事前学習、共通認識の作成が必要な気がしました。(コーディング規約とか)

Android アプリの中を覗いてみよう

DroidKaigi 2018 // Speaker Deck

やる場合は自己責任で。

大体は知っていた内容でしたが、改めて最新の情報がまとまっていたので良かったです。

やはり、「Androidのコードは覗かれる前提で作る」というのが大事ですね。

Android における Model-View-Intent アーキテクチャ

Android における Model-View-Intent アーキテクチャ // Speaker Deck

MVIという、あまり聞いたことが無かったアーキテクチャの話。

Twitter見てても、やはりFluxと概念が近そう。

RxJavaの知識が足りなくて、ついていくのがやっとでしたが、処理の順番にうまく説明してもらったおかげで、逆にRxJavaの勉強になった気がします。(subjectをプロキシとして作ったり、autoConnectでUIの死に対応したり。)

やはり、Kotlin + RxJavaの表現力というか、きれいに書ける感じがすごい。

責任の分割がうまくされていて、慣れてしまえばうまくいくのかも?と思いますが、学習コストはけっこう高そうな印象。
テストは書きやすそう。

NavigationやSnackBarの表示方法などのデメリットは、MVVMで普通に作ってても感じるところなので、MVVMにも近そうな印象を受けました。

うちの会社でこれをそのまま取り入れるのは難しそうだなーと思う一方で、部分的に取り入れることもできそうな印象を受けたので、もうちょっと理解を深めてみたいところ。

まだAPI定義管理で消耗してるの?〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜

まだAPI定義管理で消耗してるの?〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜 // Speaker Deck

いい感じの煽りタイトル。

Swaggerは、軽く触ったことがある程度でしたが、あまり"コードの自動生成"を好きになれず、
そうなると、あまりメリットを感じられずに逃げた経験あり。

ただ、今回聞いていると、コードの自動生成も悪くない気がしてきたので、機会があれば実戦投入してみたい。
Javaで、Retrofit+RxJavaでいい感じのインターフェースを生やしてくれてるっぽいし、ValueObjectはふつーに作ってくれるだろうし。

手軽に作れるモックサーバの方は、なるほど?と思う反面、データの種類によって到達できる画面が違う、とかはどうするんだろう?とは思いました。リストのアイテム数も2以上に出来ないっぽいですし。
このあたりは、個人のアプリで一回やってみる必要がありそうです。

FOLIOさんでは、マイクロサービス+BFF(Backend For Frontends)という構成だから、という部分もありそう。
特に、ワークフロー周りではそれを感じました。

MVVMベストプラクティス

MVVMベストプラクティス // Speaker Deck

MVVMの案件を外部から見ていたことがあるので、「実際に作ってみると...」という部分は、完全に同意でした。

実際の開発の現場だと、「テストコードを書いて、メンテしていく暇がない」というのは、残念ながらよくある話で(スキルが足りないのが一番の問題ですが。。。)、とはいえ書かないにしても「テスタビリティの高いコードを書く」ことを指標にするのは確かに良さそう。

他の発表でもあったけど、Repository?Model?UseCase?がObservableを公開しつつ、"コマンド"を外部に公開するってのが良さそう。
ViewModel側では、DataBindingのObservableFieldとする必要がありそう。

ダイアログとか、画面遷移はたしかに悩む。
Navigatorは、Daggerが無いときれいにならない印象があるので、やっぱり早急にDagger2の学習が必要。。。

RecyclerViewについては、なるほどなーと思う部分と、あまり理解できなかった部分があるので、やっぱり一回ちゃんと実践してみる必要がありそう。
他の発表でもあったけど、とりあえずKotlinのsealed classは便利そう。これだけでも、Javaをやめたくなった。
RecyclerView関連のライブラリは食わず嫌いしてたけど、使ったほうが便利そう。

複数のViewModelが親子関係になるのは、やっぱりやばそう。
単一のデータソースを、複数のViewModelを見るのが良さそう。それぞれの生存期間をちゃんと考えないとですね。
(DroidKaigi関係ないですが、 iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い をまた読み直そうと思いました。)

マルチモジュールのすヽめ

DroidKaigi 2018で「マルチモジュールのすヽめ」という内容で発表して来ました - アナログ金木犀

興味はあるけど、なかなか実案件で投入できていないマルチモジュールの話。

いままでは、レイヤードアーキテクチャの層ごとにわけて、間違った依存を防ぐため、という意識が強かったのですが、機能単位でもわけるというのはなるほどなーと思いました。
このへん、Annictという使ったことのあるサービスを例にしてもらえたのは分かりやすかったです。

DataBinding周りのつらさは把握してなかったですが、もうすぐ解消されるのであれば実戦投入しやすいし、素振りを始めないと、、、という機運。

いままでは、モジュール分けたら未熟なチームでは学習コストが高すぎるのでは?という躊躇もあったのですが、依存関係を明確化して強制する、というメリットも知れて、弊社でも導入したほうがよいのでは?と思い始めました。

アフターパーティー、そして二次会?

顔の広い同僚のおかげでスピーカーの人とちらっと話せたり、
業務委託?で数年前に来てもらっていたエンジニアの紹介で企業の人と話せたり、
数年?前に転職してしまった人と久しぶりに話せたり、
初めましての人と喋って、そのまま飲みに行けたり、いろんな人と交流できました。

あまりスピーカーの方とは話せなかったのは残念でしたが、一人でぼーとしてる時間はほとんど無かったので良かったです。

Day.2

Android Studio30分集中超絶技巧100選

Android Studio30分集中超絶技巧100選メモ DroidKaigi 2018 #DroidKaigi #DroidKaigi_room3 · GitHub

BuriKaigiぶりの山本ユウスケさん。

UpsourceなどのJetBrains関連製品の話は、BuriKaigiで聞いていた部分でしたが、それ以外のIDE機能の部分はすごかったです。(語彙

印象に残ったのは、下記の通り。

  • ウィンドウの操作などは、いつもトラックパッドでしていたのですが、そんなに複雑なコマンドでも無いので、覚えて活用していきたい。
  • あらゆるポップアップはインクリメンタルサーチできる
  • Cmd + F12の構造ポップアップは、Eclipseでは常時表示させてましたが、ASでは見つけられてなかったので、検索ばかりしてました。活用せねば。
  • Ctrl + Gや、option + ↑などの選択範囲系のは活用の機会も多いと思うので、使っていきたい。
  • XocdeやAtomなどのエディタも常用している関係から、すべてのコマンドを覚えることは出来ないだろうけど、Shift + Cmd + AやCtrl + Tなどの起点となるコマンドは覚えておき、いろいろと活用していきたいです。

Surviving a discontinuous world

Surviving a discontinuous world // Speaker Deck

名前とか覚えるのが苦手なのですが、声を聞いて dex.fm の人だと思い出しました。

たしかに、Androidアプリの開発においては、いろんな非連続性があり、正しく動くアプリが作りづらい気がしています。
また、それを下手に回避しようとすると、プログラムがとっちらかって、保守性の悪いコードになってしまう。

RxJavaやAACのViewModel、EventBusなどを使って、いくつかの問題は解決できそうですが、学習コストが高そうだったり、使ってもそこまできれいに書けない場面もありそうな印象。
ただ、こういった不連続性があることを理解しておくことが大切だなーと思いました。
特に、他のプラットフォームに慣れた人とかは、陥りやすそう。

Relay Activityのところでは、プロセスは死んだけど、途中のActivityから復帰する場合がある、ということを知り、自分が勘違いしていたことに気づきました。
また、Emulatorやadbコマンドを使えば再現できることも学べたので、不安なときやCrashログから再現させるときは試してみようと思います。

詳解 Android Auto - 使い方からそれを支える技術まで

詳解 Android Auto - 使い方からそれを支える技術まで - // Speaker Deck

普段から車に乗るので、興味はあったAndroid Autoの話。
途中まで部屋が暑かったし、登場人物(音楽アプリ、Autoアプリ、Systemとそれぞれの中のクラス)が多く、理解しきれない場面もありましたが、概要は理解できた気がします。

Messageの部分では、CarExtenderという拡張があることを知れて、アプリ側としてこれだけは対応しておく、というのもありかも?と思いました。(Android Autoを使っている人がどれだけいるのか不明ですが。。。)

むかーし、 カーナビもどき なアプリを作ろうとした経験があるので、いまからやるのであればAuto互換みたいなアプリを作るべきなんだろうなーと思いました。まぁ、DrivemodeとかAuto自体を使えよ、という気もしますね。

Dagger2を活用してAndroid SDKの依存関係をクリーンにする

Dagger2を活用してAndroid SDKの依存関係をクリーンにする // Speaker Deck

サンプルリポジトリ

GitHub - kr9ly/dagger2-sampleapp

たしか、前説の間で「初参加で初登壇」と言っていた記憶があります。強いですね。(私は日和りました。。。)

Dagger2の話でしたが、一部は理解できましたが、一部はちゃんと理解できなかったと思います。
資料やサンプルを見直す必要がありそうです。

理解できた部分でいくと、Contextの処理をwrapしたクラスを作るってのは良し悪しだなーと。
ただ、下手なメソッド使われるよりは、制限つけたクラスを渡すというのはいいなーと思う一方で、作るのはめんどいなーとも。

すばらしきGraphQLのSEKAIへようこそ

すばらしきGraphQLのSEKAIへようこそ // Speaker Deck

アイコンしか見たことなかったので、どんな奇抜な人かと思ってたけど、見た目は普通の人でした。

GraphQLは気にはなってるけど、サーバ側の負担が高そうな印象があり、外部公開しない(開発アプリ用のサーバサイド)APIという案件が多い中では、あまり使えないかなーと思ってました。
今回は全体感の話と、クライアントサイドの話だったので、そこの不安は残ったままですが、クライアント開発者としては「面白そう」と思えました。

Schema-Driven Development(SDD)は確かに大事だなーと。
個人で小さいものを作っていても、数カ月後には忘れているので、きちんと定義しながら開発を進めるというのは大事ですね。

GraphQLは、取得系の処理が柔軟に記述出来るそう。ただ、更新はそんなに強くないとのこと。
このあたり、アプリの特性に合わせて、SwaggerやgRPCなどと使い分けて行ければ良いのかなと思いました。

GraphiQLというIDE的なツール?は便利そう。補完を利用しながら、リアルタイムで結果が見れるっぽい。

Relayというライブラリは面白そうですね。
View Componentとqueryを同じ場所に書くというのは、ある意味スマートUIとも言える気がしますが、面白い解決方法という印象。

Android Things codelab / Android Things であそぼう

  • 認証と認可と君と / The Triple-A: Authentication, Authorization, and Android
  • All you need is isolating the domain (How to apply DDD to Android Application Development 2)
  • 体育会系女エンジニアの孤独なアプリ開発教室

の3つで悩んでたら、ちょっと興味はあったAndroid Thingsのハンズオンに捕まりましたw

たしか、「5分で終わるよ!」と言われた気がしましたが、さすがに5分では終わりませんww

Android Things であそぼう!

こちらの機材が用意してあって、Android Studioから利用できるサンプルを順次試していく形。
全体の電力消費とかはそれなりにでかいかな?と思いますが、Androidの開発の延長線上で、物理世界とインターフェース出来るのは面白いですね。

おみやげにRainbow HATを頂いたので、家にあるRaspberry Pi 3と組み合わせて、ちょっと遊んでみたいですね。

ウィンドウサイズの変更に強い堅牢な画面の構築

ウィンドウサイズの変更に強い堅牢な画面の構築 / DroidKaigi 2018 // Speaker Deck

Surviving a discontinuous worldにつづいて、Androidのつらい部分をどうにかする話。

画面回転だけではなく、マルチウィンドウが当たり前になってきつつあり、対処が必要なアプリが増えてくる印象。

fitsSystemWindows はあまり気にしたことが無かったですが、NavigationDrawerだとステータスバー部分も描画しているのは、これをうまく使っている、ということなんですね。
たしかに、雰囲気で使ってしまっています。

二つ目は「構成の変更時の画面の状態保持について」。
受託でやる際には、いろいろな問題があって縦固定にしてしまうことが多いので、configChanges使っておけば?とか雑に思ってましたが、たしかにリソースの切り替えなどを考えるとActivity/Fragmentは再生成されるべきですね。

onSaveInstanceStateと、setRetainInstance(true)なFragment(AACのViewModel)のそれぞれのメリット・デメリット、使い分けには「復元が可能なのか」を考える、といったことがきれいに説明されてたのはありがたい。
ちゃんと使い分けていかないと、と思わされました。

マルチログインの実装方法

droidkaigi-2018 // Speaker Deck

サンプルは GitHub - yuyakaido/Android-Blueprint

TwitterInstagramなどで出来ている、アカウント切り替え機能をどのように実装するかの話。

個人的にはあまり使ったことも無かったので、想定されるバグなどが事前に知れてよかった。

設計方針としては、アカウントを透過的に操作できる層を追加して、そこでの切り替えをしっかりやる、というイメージかと。

ここでもDagger2をうまく利用していたようなので、やっぱりDagger2をやらねば、、、と再認識しました。

Gradleプラグインを作って開発効率を改善しよう

最後のセッション。

個人的に、Gradleプラグインを使って最低限品質の向上とか、プロジェクト間での便利機能の共通化に興味があるので、事前にスライドも読んでました。
結果としては、スライドに書いてあった情報がほぼすべてだった(スライド単独でもわかりやすい)ので、聞かなかったら聞かなかったかなぁともw

Plugin自体は簡単に作れそうで、公開も簡単そうなので、どこかのタイミングでやってみたいな。と思いました。
(おそらく、Android Plugin DSL Referenceや、groovyの記述周りで詰まりそうではありますが。。)

最後のセッションということで、mhidakaさんに事前に「いい感じに締めておいて」的なことを言われて、実際に発表後に締めていたのは単純に、すげぇな、と思いました。

期間中に書いていたメモ

あとはメモです。

# DroidKaigi 2018

## Day.1

## Kotlinアンチパターン

普段使ってる人が半分ぐらい。

リリース済みの巨大なアプリのフルリニューアル。
最大11名という大人数の開発チーム。

### lateinitと

Kotlinでは、基本的に初期値が必要。(Javaはnullが初期値)

Androidでは、onCreate以降に初期化。強制unwrapなどが必要に。

アンチパターン:通信後に得られる情報をlateinitにする。
通信中にonClickListenerなどでアクセスしてしまうなど。

解決策の例:Nullableにする。

isInitializedが導入された。
もともと、テストコード用に導入された。
プロダクションコードでの仕様は避けたほうが良さそう。

### スコープ関数

let/run/also/apply/withの5つ。
null関連の制御に便利。
初期化処理をまとめる。

アンチパターン:apply内でプロパティアクセス形式の処理を書く
ローカル変数を定義すると、アクセス先が変わる。

解決策の例:apply内では関数呼び出しにする。
2:this必須というルールにする。alsoと似た感じになってしまう。
3:apply禁止。alsoを使う。

### NullableとNonNull

アンチパターン:Nullableのままデータを引き回す。
いたるところでnullチェックが必要になる。
すべてNonNullにするために無効なデータを入れる。

解決策の例:「nullが何を表すか」で処理するレイヤを決める
nullではなく、例外を投げる、別クラスにするなど

### data class

アンチパターン:インスタンス生成用のメソッドで、制約を保証したい。
data classにはcopyメソッドがあるので崩壊する。

解決策の例:なんでもdata classにしない。

### interfaceとabstract class

アンチパターン:Baseクラスを肥大化させる。
解決策の例:「継承よりも異常」より、interfaceのデフォルト実装でも良いかも。

状態を持ちたい場合も、class delegationを使うと出来る。

### トップレベル関数と拡張関数

ファイルに直接関数を書ける。
クラスに関数を追加する事ができる。

アンチパターン:一般性がない、局所的にしか使わないメソッドを追加する。
アンチパターン:公式でありそうなのに、雑に実装。

チーム内で拡張関数を作る基準・間隔を揃える。
interfaceのデフォルト実装で、スコープを限定する。

### lazyとcustom getter

lazyは一回、custom getterは毎回計算。

解決策の例:値の性質に応じて、適切に使い分ける。

delegated property
プロパティのget / setを別のクラスに移譲出来る。

### Fragmentとlazy

アンチパターン:FragmentのViewをlazyにする
onCreateViewが複数回呼ばれ、古いViewを参照し続けてしまう。

解決策の例:lateinitを使う。

### custom getter

アンチパターン:値を取得する過程で副作用がある場合。
2:計算量が多い

呼び出す側からは、通常の変数と同じに見えるため、性能劣化しやすい。

custom getterを使いすぎない。

### custom setter

変数の移譲

アンチパターン:常に必要ではない処理を書いてしまう。
それにより、値だけを変えることができなくなる。

更新用の関数を公開する。

### last one

無理やり使わない。
operator overload, infix, tailrec
チーム開発では、わかりやすさも大事。

## Android アプリの中を覗いてみよう

内容を試す際は、自己責任で。

Androidアプリの中身は、簡単に覗ける。

APKを用意する。
ミラーサイトから入手 or 端末から入手
APK Downloaderというサイトも有る。自己責任で。
APK Extractorというアプリで、端末から抜き出せる。

APKを解析する
ASでBuild -> Analyze APK
中身を見れる。dexファイルの数とか。

APKTool コマンドラインから実行できる。
AndroidManifestがそのまま参照出来る。

unzip/dex2jar/JD-GUI
拡張子をzipにしてunzip。
dexファイルをdex2jar
jarをJD-GUIで見れる。

kotlinのライブラリ?ランタイム?が入ってる。

著作権法違反:
見たコードをそのまま使う。
リソースの流用。
非公開のAPIを叩く。

アプリの実装をブログで解説するのは、かなりグレー。

Androidアプリは覗かれる前提で作る。
会社の重要なビジネスロジックは書かない。

英語版があれば、そっちを使ったほうが、そのままコードで利用されている可能性がある。

## Android における Model-View-Intent アーキテクチャ

AさんとBさんが会話する=AさんのInput -> BさんのOutput
人とAndroid端末も同じ。それをアーキテクチャに落としたもの。

user -> intent -> model -> view -> user...
view(model(intent()))

ユーザの操作・初期化処理などをTasksIntentに各クラスをつくる。
sealedクラスの中にdata classとobjectで作る。

Fragmentの中に、Observableを返すintentsメソッドを作る。
mergeでつなぐ。
intentから、actionを作る。whenでマッピング出来る。

switchMapであれば、前の実行をキャンセル出来る?ネットワークの複数リクエストが不要な場合に便利そう。
startWithの位置が大事。

1つのクラスがあれば、1つの画面を作れるようにしておく。
SnackBarの表示についてもbooleanプロパティとして保持する。
初期値も定義しておく。

StateとResultをもとに、new stateを作るのがreducer

画面を変更するメソッドは、renderにしかない。

side effects
複雑性のもと。スコープを制限する。
intentsを作るところ。ただし、UIの変更は禁止。
Processor部分。ただし、UIの変更は禁止。
reducer部分。ただし、データの読み込みは禁止。stateにあるはず。

user interfaceの影響を制限する。ViewModelでは、Androidの世界と切り離す。

イベントが詰まったあとに、onStop。
ViewModel以降のやりとりがonStopで止まらなければ、Stateの更新は進む。
onResumeで再描画出来る。(renderはべき等)
AACのViewModelのスコープを前提としている。

Rxだと、sourceが消える(UIが死ぬ)と、Stream全体が死ぬ。
ViewModel内のsubjectをプロキシとして作る。
subscriberもUIの死で死ぬ。autoConnect(0)を使う。
reply(1).autoConect(0)で、最新の状態を再度受け取れる。

Fragmentでは、viweModelをlazyで初期化。
onStartでsubscribe
CompositeDisposableに入れておく。
onDestroyでdispose
subscribeしてから、intentを投げる。

initialはtake(1)でmergeする。

テスト。
UI層は、それぞれEspressoなどでテスト出来る。
ViewModel内は通常のJavaとしてテスト出来る。

oldergod/android-architecture にサンプルあり。

デメリット
・クラスの数が増える。
・Rxの知識が必要。
・Navigation
・SnackBar。booleanをいつ解除する?Timerで消している。

メリット
・処理の責務が明確。問題が発生したときの切り分けがしやすい。


## まだAPI定義管理で消耗してるの?〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜

FOLIOという証券会社。

暗黙知を残さない。形式化する。
暗黙知を書き出す。→ドキュメント化。
事例の共有。→サンプルデータ。

API定義を管理するメリット
認識齟齬をなくす。

Swagger / Protocol Buffers / api blueprint / Excel

Swaggerを用いた管理
OpenAPI InitiativがAPI記述のためにSwaggerを採用

REST APIの設計、ドキュメント化、テスト、デプロイまでをカバー
Core/Editor/UI/Codegen

Editor
API定義をレンダリングしながら編集できる。
必須と任意のプロパティを定義できる。
exampleデータは書いておいたほうがよい。
type+formatで型が決まる。

UI

コードは機械的に生成しましょう。(ミスを無くすため)
Java+Retrofitだけでなく、Kotlinも使える。(完璧ではない)
codegenを使うことで、工数が削減できる。
ドキュメント通りの実装が出来る。

Kotlinであれば、NonNullなども反映される。
Javaであれば、Retrofitのinterfaceも出てくる。ただし、Kotlin版は微妙。

codegenでモックサーバも作れる。
サーバの実装がまだでも、アプリが作り始められる。
サーバに反映されても、アプリは古いモックで動き続けられる。
デメリット:リストのアイテム数は常に1つ

FOLIOでの運用
Microserviceで運用してる。BFFでまとめていて、スマホはそこと通信している。
BFF開発者がPRを出し、スマホエンジニアがレビュー。
スマホエンジニアが意見をPR、BFFエンジニアがレビュー。

masterにタグを切る。
該当のタグをsubmoduleとして参照している。
BFFは、フロントに向けて作っている。

編集時は分割 -> multi-file-swagger。
API定義のバリデート -> swagger-cli
pre commitでチェックしている。

gRPC+ProtocolBuffersであれば、あまりいらない。
SwaggerUIは使える。
Swagger用のJSON定義を出力、Swagger UIで見る。

proto3でrequiredがなくなった。
互換性を保つため。
BFFがあるから、型が欲しい。
広報互換性は、v1, v2などで管理できる。

Flowtypeの型が生成出来る。
iOSは自動生成の結果を利用しやすい。

codegenのカスタマイズ
XxxClientCodegen+mustacheのテンプレート
生成時のコマンドラインオプションで、テンプレートを指定できる。
swagger-codegenのresources以下に言語ごとのテンプレートがある。
FOLIOでは、kotshiを使ってる。

codegenのリリースサイクルは遅め。新しいものはmasterブランチ。
Javaはいい感じ。Kotlinはまだ発展途上。

## MVVMベストプラクティス

カカクコムの新規事業担当。

VMが大きくなりがち。
RecyclerViewとか。
VMが複数存在したり。
反省を踏まえて、ベストと思われるプラクティスの紹介。

### 関心の分離

VMが太ってしまう。
再利用性・保守性の向上。
PDS

#### MVVMにおける、関心の分離。
V+VMがP、MがDomain。

Viewはデータの表示・イベント。
ModelはV+VM以外。
ViewModelは、Viewの状態を抽象化して保持。ModelとViewの接続。

ViewはVMを持つが、逆は持たない。
VM -> Modelの状態変更を要求。

Androidにおける実践的な方法
・テスタビリティを基準として使う
ViewModelのUnitテストが出来るかを基準にする。
テストを書かなくても、指針としては使える。
依存するオブジェクトは、Mockへの差し替えを可能にする。Dagger2など。
・ViewとViewModel
DataBindingを使う。
Viewに発生したイベントを、ViewModelに通知。
メソッド参照を使うと、Viewが引数に渡ってしまう。Lambdaで切る。
ViewModelはViewに状態を公開。
カスタムセッターを使ったり。Picassoに画像URLを渡したり。
Kotlinであれば、拡張メソッドを使える。
・ViewModelとModel
Modelの状態変更を要求する。
ViewModelがModelの状態を監視する。RxJavaなど。

例:設定画面。SharedPreferencesにデータが保存されている。
悪い例:VMの中でSharedPreferencesを読み取る。
→間にRepositoryを挟んで、VMはRepositoryの変更を監視する。
RepositoryではPublishSubjectを使う。外部にはObservableで公開する。
VMでは、初期化時にsubscribe。依頼があれば、repositoryにloadを依頼する。
別の画面でSharedPreferencesが変更された場合などに強い。

・ダイアログ表示・画面遷移
ViewModelからはトリガーを引く。
Navigatorを使う。
ActivityScopeなインスタンス。
・Context
機能が多すぎるので、各層で必要になってくる。
ラッパーを作ったりして、ViewModelでのみ使って良いメソッドを制限したほうが良い。特に、大人数の場合。

#### RecyclerView

・基本的な実装
Viewの種類が複数あるパターン。
sealed classでViewTypeを表現。
画面全体のVM。それぞれのVM。

ActivityのonCreateでAdapterを生成。
AdapterにModelを渡す。custom setterを利用する。
Adapterが、行ごとにMVVMを作る。
BindingをViewHolderで持つ。

・変更検知
FABで新しいタスクが作られる想定。
まるごと更新(notifyDataSetChanged) -> 変更のアニメーションが出来ない。
差分検知には2パターン
 ・ObservableListを使う。
 ObservableArrayListという実装がある。
 callbackで変更を通知できる。
 Adapterでcallbackを登録。
 ObservableListには、onItemRangeInsertedなどのそれぞれのメソッドがある。
 Adapterでハンドリングする。
 ・差分検知
 差分を自分で計算する。
 Rxとかで、新しいリストが流れてくるだけであれば、こっちのやり方が楽。
 DiffUtil support libraryに入ってる。 参考:http://blog.takuji31.jp/entry/kanmoba17
 Epoxy というのもある。

・実装の効率化
Adapterはボイラープレートが多い。
いくつかライブラリがある。プロジェクト要件にあったものを。
カカクコムの1つのプロジェクトでは、Epoxyを使ってる。(それはflux)
Airbnbが開発してる。

#### データフロー

ViewModel間が複雑に依存する。親子関係など。

例えば、メニューにタスク数を表示する場合。
1つを完了させると、ItemViewModel->Repository->WebAPI
ItemViewModle -> ViewModelにデータを渡す。

Repositoryだと、Singleで結果を一回だけ流すように作る。
Item側では、repositoryのcompleteを実行。parentに結果を渡す。

ViewModel間でのやりとりを行うこで、データフローが複雑化。

改善方法としては、それぞれのVMが参照しているRepository(実態)を一つにする。
Repositoryから、Observableで公開。そこに更新を流していく。


## マルチモジュールのすヽめ

何故するのか。

複雑化してきている。
サブ機能も多くある。
ログイン・ログアウト機能、強制アップデート、お知らせ、ログ収集。
それをモジュールで分けてしまう。
サーバ側でマイクロサービスになると、APIのまとまりも分割されることがある。

波が来ている。
Instant Apps
Gradle Plugin3.0.0でパフォーマンスが上がっている。
KotlinのMultiplatform Projectではcommonモジュールが最低限必要。

個人的に。
レイヤードアーキテクチャー。
認証機能。他のAPIからもtokenが必要。domainに置けない。
別の認証モジュールを作って、認証の上位層から別のinfra層が取ってくる。

databindingとの相性が悪い。
少し前までは、そもそもできなかった。module側でbindingが見えない。
いまでも、dependenciesに重複して記述しないといけない。
解消されようとしている。
DabaBindingCompilerV2が正式リリースはされてないけど、存在はしている。
enableV2のgradle.propertiesへの追加が必要。

モジュールの分け方
・レイヤーで分ける
依存関係
・意味のあるまとまり
独立している機能を分ける。

おすすめ
意味 or レイヤー+意味

例えば、ユーザログはUI層でしか送らない、ということが制限できる。
主要機能が3つ以上の独立した者で出来ているなら、意味のあるまとまりで分けたほうがよい。
チームが未熟なら、強制力が働くのでよい。

Annictでの事例
ユースケースを洗い出し、何を実現しているかを考える。
主要機能以外をまずは切り出す。独立しているものを。
機能ごとの依存関係を考える。
次に、実装上の依存を考える。

New Moduleしたら出来る。
Androidに依存していないならJava Module、それ以外は

modulesディレクトリを作る。
projectDirを書き換える。

モジュール間の連携について

Case1: モジュールをまたがった情報の表示
たとえば、ホーム画面にいろんな情報を表示する。
Fragmentで分けて、attachしているだけ。
Fragmentは各モジュールで定義している。

Case2: 他のモジュールから情報を取得したい。
あるモジュールのAPIが、認証モジュールからトークンを取得する。
認証モジュールで取得サービスを公開して、そこから取得する。
View/Serviceだけを公開する。domainのものは使わずに返す。primitiveやDTO。

## アフターパーティー

弊社エンジニアのお陰で、Widgetの話をしていたスピーカーの方と話せたり、(ただし、発表は聞いていない。。)
2, 3年ぶりにあった人に紹介されて、UZABASEの方と話したり、
転職していった人の近況を聞けたり、
飲み物を取りに行ったところで偶然話し始めた人と、そのまま飲みに行くことになったり(次に続く)、
あっという間の時間でした。

## 2次会

同じ会社のAndroidエンジニアの誘いもあって、
愛知から夜行バスで来た方、富山大学を出て新卒でエンジニアしてる方、弊社Androidエンジニア、自分という4名で飲むことに。

今日のセッションの振り返りや、明日のセッションどこ行く?の他にも、
「新卒」ブランドは賞味期限があるから使えるときに使っとけ、という話や、
勉強会は懇親会が本番、とかって話をしてた気がします。

## Day.2

## Android Studio30分集中超絶技巧100選

メモは後で公開予定。
https://gist.github.com/yusuke/e30257656a78ca007627e0762a5a7fbc
Eclipse使ってる人はほぼいない。
Mac OS X 10.5+ を使うべき。
Power Save Modeを使うと、バッテリー効率が良くなる。
Cmd+1 -> Escで、プロジェクトペインとエディタを行き来出来る。
ポップアップは、typeすることで絞りこめる。
Shift+Cmd+F12でエディタだけに出来る。戻せる。
Window -> Store current --> Shift+F12
Cmd+Oで、* がワイルドカード。:数字で行数。
Ctrl+tabで戻れる。
Cmd+Eでファイル選択。
Cmd+7でstructureが表示。Cmd+F12でウィンドウ表示。
Cmd+Bで定義に飛ぶが、定義で押すと使ってる箇所を表示。
Option+Cmd+bでinterfaceの実装。
Ctrl+Gでカーソル増殖。
option+↑で選択範囲を拡大。
Ctrl+Tでリファクタリング系のメニューが出る。

## Surviving a discontinuous world

不連続性。Android開発における難しさ。
大体のプログラムは上から順番に実行される。
Androidでは、callbackとかのlambdaで順番にならない。
非同期の結果が返る頃に、画面が生きているかはわからない。

コードが直感的じゃなくなる。
事前条件(実行されるスレッド、画面の生存)を、つねに気にする必要がある。
再現性のないバグになりやすい。

### 非同期処理
ボタンクリック->非同期取得->画面の反映
暗黙的にActivityを参照しているので、処理結果が帰ってこなかったらリークする。

まずは手持ちで。
runOnUiThreadでUIスレッドで実行できる。
isDestroyedでActivityの存在を確認できる。if文。

RxJava or Kotlin Croutine
RxJava
先にデータフローを定義する。
disposableで、メモリリークを防げる。
Kotlin Croutine
コードが上から下に実行される。
非同期の場合に、コードが一時停止する。スレッドはブロックしない。
suspension pointで止まる。
launchの引数で、実行されるスレッド、ライフサイクルを定義できる。

### 画面回転

バックグラウンドスレッドの結果が、古いActivityに通知される。

AsyncTaskLoader
いまはそんなに使われていない?
AACのViewModel
FragmentのsetRetainInstanceを使ってる。

### シュレディンガー Activity
リスト->詳細の構成で、詳細でいいね押して戻ってくるなど。

2つのシナリオがある。
・Activityが再生成される場合。(リスト画面が死んでる)
一般的に、サーバから取り直すので、あまり問題にならない。
・Activityが再生成されない場合。
実装が必要。

・startActivityForResult
setResultで状態の変化を詰める。
onActivityResultで反映させる。
・EventBus
Activity間でEventを送受信。
いいねのタイミングで、Eventを送信。
死んでれば、再生成時にAPIアクセスなど。
・Persistent repository
local storageで保存しておく。
Google I/Oのアプリでやっている。
まっとうな方法だけど、結構複雑。

### Relay Activity
複数の画面で、1つのデータを作成する。
下書きデータみたいなものを、複数のActivityで作る。サーバには送らない。

singletonで、下書きデータを保持する。Application classで保持するとか。
ただ、問題が起こる。
バックグラウンドの際に、データが死ぬ可能性がある。ただ、Activityは復帰される。
普通のテストで再現させるのが難しい。
Emulatorで、DeviceMonitorからStop processを押す。
or adb shellから、run-asでkillする。

・startActivityForResult
データをお手玉していく必要がある。
・Local Storage
データを永続化する。
・Fragmentを使って、データを保持する。
Fragmentは嫌われているけど、現実的な解決策。


## 詳解 Android Auto - 使い方からそれを支える技術まで
https://speakerdeck.com/keithyokoma/xiang-jie-android-auto-shi-ifang-karasorewozhi-eruji-shu-made

Autoアプリを入れて、Auto readyの車に接続すると、ナビ画面に出てくる。
Audio, Messages, Calls, Navigationが主要機能。
音声入力で操作する。
電話とNaviは公開されているAPIが無い。

### Audio Framework

登場人物
App(media contentの配信), Autoアプリ, Android system

AppとAutoアプリはプロセス間通信。
MediaSessionで状態を管理。
MediaControllerで操作。sessionの発行したtokenを受け取る。permission的なもの。
MediaSessionがMediaPlayerに支持を出す。

appのMediaSessionから、AutoアプリのMediaControllerにプロセスを超えて通信する。

app側で、Serviceを作る。
その中で、MediaSessionを作る。(support libraryにある)
callbackを設定し、isActive = trueとする。
Binderを経由して、tokenを渡す。
tokenはParcelable

Auto側でActivityを作る。
ServiceConnectionでbind、onDestroyでunbind。
onServiceConnectedでbinder経由でtokenを取得。
MediaControllerを作成、prepareを呼ぶ。(ストリーミングであれば、ダウンロード始めたりしてくれる)

App -> System
MediaSessionManager->MediaSessionService
ISessionControllerが中継して、プロセス間通信をしている。
プロセスの片方が死ぬ可能性がある。DeadObjectExceptionが起こる。

プロセスが死ぬと、binderDiedが呼ばれる。
IBinder.DeathRecipientで検知。

...登場人物が多すぎて、メモ取れない。

MediaSessionManagerだけ、5系から。support libraryも無い。

Auto側で、プレイリストなどを表示することが出来る。
MediaBrowserService -> MediaBrowser
onGetRootで、どのプロセスから来たかがわかるので、そこで拒否できる。nullを返すと、拒否扱い。
署名を見て判断もできる。
app側が許可する一覧を持っている。base64の署名。
`__ROOT__`などの構造が定義されている。
MediaItemに、BROWSABLE/PLAYABLEといったフラグを持たせる。

onLoadChildrenは、同期でも非同期でもよい。
非同期の場合は、detachしてから、非同処理を行う必要がある。
searchで、検索も行える。

### Message

アプリ側のNotificationを、Autoアプリが受け取る。
NotificationCompat.CarExtender というものがある。
UnreadConversationに、既読用・reply用のPendingIntentを渡せる。
PendingIntentは、BroadcastのIntentにしておく。
conversationIdは、任意に決める。
reply用のPendingIntentにRemoteInputを渡す。Auto側が音声を詰めて返してくれる。
対応するBroadcastReceiverを作る。

Auto側では、NotificationListenerServiceを使っている。
StatusBarNotificationの形式で受信する。
carExtenderは、フラットに、文字列をキーに取得する必要がある。
messageも、Parcelableのリストが来る。

### まとめ

プロセス間通信。
Google Assistantも、似たようなことをやっている。


## Dagger2を活用してAndroid SDKの依存関係をクリーンにする

https://speakerdeck.com/kr9ly/dagger2wohuo-yong-siteandroid-sdkfalseyi-cun-guan-xi-wokurinnisuru
https://github.com/kr9ly/dagger2-sampleapp

Kodeinというのも出てきている。
DIを使う目的は、本来色々。
Androidにおいては、SDK周りの依存を切りたい。

ベタープラクティス集の紹介。

### @Scopeを活用する

代表的なのはSingleton。
@Scopeを使うと、スコープ管理が可能。

ViewScopeアノテーションを作る際に、@Scopeを付ける。

Subcomponentを使うのがらく。

...頭が追いつかなかった。...

Component分け
Component定義が1つで済むほうがよさそう。
Module内で処理を分ける必要がある。

### Context依存を切り離す

2つやり方がある。
Context自体を公開するか、そこを隠蔽するか。
プロジェクトに依存する。

### 画面遷移を整理する

画面遷移用のinterfaceを定義する。
Intent生成用のIntentBuilderを作ってしまう。

### Activity/Fragmentのコールバックイベントを整理する。

・AACのLifecycleを使う
・自前でコールバックを定義する

## すばらしきGraphQLのSEKAIへようこそ

https://speakerdeck.com/gfx/subarasikigraphqlfalsesekaiheyoukoso

Kibelaを作っているgfxさん。

Kibelaで、GraphQLを採用。
GraphQL rubyを使っている。
アプリはReactNativeを採用予定。GraphQLと相性が良い。

### Schema-Driven Development
APIとデータ構造の定義と、ロジックの開発を同時に進めること。
schemaをベースにコミュニケーションしやすい。
自然言語ではないので、変更箇所の検知がしやすい。

SDDで有名なもの。
Swagger, gRPC, GraphQL

他人・他チームとの界面はしっかり定義しておく必要がある。
そうしないと、あとから困る。

### GraphQLについて

クエリ言語。SQLと同じ領域。
WebAPIを想定している。
プロトコルはHTTP
内部APIとしても、外部APIとしても使える。

リソース取得系が非常に柔軟かつ強力。
更新は、GraphQLであるメリットは少ない。
Fileアップロードとかは、かなり難しい。

GraphiQL(ぐらふぃくる) GraphQL IDE
補完が効く。
GraphQLの仕様の中に、Deprecatedもある。GraphiQLで見れる。
ドキュメントビューアーもついている。

リクエストを見ると、レスポンスの構造がわかる。
計算が必要なカラムも、必要な場合だけ取得できる。(サーバに優しい)
intとfloatが区別される。
すべての方はnon-nullに出来る。

Mutation
自由に名前を点けられる。

Relay

1. GraphQLを前提としたViewFramework
2. Relay(1)がサーバに対して求める仕様であるRelay Server Specificationのこと。

これに従っておくのが無難。
Relay Connection
リソースリストのページング。RESTだと、特に指定が無いので、自由に作りがち。

クエリは手書きしろ、という設計意図を感じる。
GraphiQLで書いて、それをコードに貼り付ける。
クエリは静的に書いて、ビルド時にデータ型を作成する。

### GraphQL in Android

本番で使っているわけではない。
Apollo clientが有名。
クエリから、Javaコードを生成する。Kotlin対応はまだはじまったばかり。
ORMのように、コードからクエリを作るわけではない。
リクエスト・レスポンスクラスを生成する。
通信はOkHttpに依存。
viewと同じファイルに置きたいが、Apolloは別ファイル。Kotlin対応がすすめば。。?

JavaScriptであれば、Relay。JSそのままでも扱える。
View componentと同じ場所にqueryを書く。

Kibelaでは、TypeScriptとの相性が悪い。
発想は良さそうなので、そこは参考に出来る。

モデル・腐敗防止層という概念は不要なのでは?
(他の会社のAPIを叩く場合は別かも。)

スキーマの共有。
スキーマをエンドポイントで返す。
ビルド時にエンドポイントを叩いて取得する。

HTTPのステータスコードは複数のところが返す。(proxyとか)
GraphQLでは、処理が成功したら200。

まとめ

## Android Things

https://codelabs.developers.google.com/codelabs/androidthings-playground-jp/#0

## ウィンドウサイズの変更に強い堅牢な画面の構築

定義
画面回転・マルチウィンドウ

問題
レイアウト崩れ。マルチウィンドウの下側なのに、ステータス領域をとっていたり。
画面の状態が失われる。ロードが発生したり。状態が保持できていない。

考慮することが増えた
・幅・高さともに表示領域が狭いレイアウト
・通常と異なるシステムUIの配置。WindowInsets周り。

ステータスバーの一部が欠ける端末の登場など。

「ステータスバーの高さを取得する」は疑うべき。
fitsSystemWindowsをつかうべき。ただし、使うのが難しい。
FrameLayoutにfitsSystemWindows=trueのものが複数あっても、反映されない。場合もある。
自身・子Viewで、解釈をカスタマイズ出来る。DrawerLayoutなど。
オーバーライドしなくても、OnApplyWindowInsetsListenerで処理を横取りできる。
consumeしない、という選択肢もあるが、混乱を招く。
高さを取得しなければならない場合は、setOnApplyWindowInsetsListenerで取得する。

### 構成の変更時の画面の状態保持について

ウィンドウサイズの変更時は、Activity/Fragmentは再生成される。
新しい構成用のリソースを使用した表示にするため。
ゲーム、WebViewなど、仕方ない場合のみconfigChangesを使う。
Handling Configuration Changesに詳しく書いてある。
・onSaveInstanceState
シリアライズなどを伴うので、速度面が問題。
一部のViewは、自前で状態を保持する。
7.0以降で、大量のデータを保存すると、1MByte TransactionTooLargeExceptionが発生する。
toolargetoolというツールで確認できる。
・setRetainInstance(true)なFragment
シリアライズを伴わない。
AACのViewModelも、この方式。
・onRetainCustomNonConfigurationInstance は非推奨?
Android 2.xでは推奨されていた。

使い分けには、データの「寿命」を考える。
onSaveInstanceStateは、プロセスの破棄でも残り続ける。
setRetainInstance(true)は、Activityの破棄で消える。

targetSdkVersionを24にすると、TransactionTooLargeException

復元可能なものは、setRetainInstance(true)
ユーザの入力中の内容などは、onSaveInstanceState

これまでは、ほぼすべての画面でIcepickを使用していた。
Retainerというライブラリを作った。Icepick風に、状態保持出来る。

寿命の違う2つの状態
StateAwareViewModelを作った。
ViewModel側のテストで担保できる。(片方生きてる、両方生きてる)

## マルチログインの実装方法

サンプル https://github.com/yuyakaido/Android-Blueprint

eurekaの開発をしている。
テストおじさん→Rxのエラーハンドリング

Pairs本体には、マルチログインの機能は無い。

定義
複数アカウントで同時にログインできる。
TwitterやInstagramは出来ている。

会場内で5名ぐらいが経験者。

実装時の問題
・別アカウントのデータが見える。
グローバル変数や、状態を持つシングルトン
・データを上書きしてしまう。
データや非同期処理がアカウント単位になっていない
・コードが複雑化
アーキテクチャ的に考慮されていない

実装時の設計方針
Activity - ViewModel - Repositoryが一般的。ただ、これだとマルチアカウントだとつらい。
Repository以下をアカウント単位で管理するとよい。
ApplicationとAccountを明確に区別。
Applicationでは、Accountに依存しないもののみ。
各レイヤーのライフサイクルが異なる。
Dagger2などのDIコンテナを使うと、楽に実装できる。
ApplicationScope, AccountScope, PresentationScope(画面単位)
個人GitHubアカウントの、Android-Bluepirntでサンプルを公開中。

OkHttpClientも、AccountScopeで管理。

## Gradleプラグインを作って開発効率を改善しよう

build.gradleはGroovyスクリプト
JavaでもKotlinでも書ける
gradleファイルは、リモートにおける。gistとか。

Pluginというinterfaceを実装したら、それはPlugin。
メソッドは一つ。applyだけ。

設定を持つためには、ExtensionというJavaBeanを使う。
いつものandroid{}も、AppExtensionというExtension。
通例として、末尾が"Extension"というクラス。

afterEvaluateコールバック
設定値の反映とか、タスクを生やすとか。

タスクになっていれば、コマンドラインから呼び出せる。依存関係がある。

Android Plugin DSL Referenceというドキュメントがある。

applicationVariants.allで列挙、追加できる。

--stacktraceで、stacktraceが出るようになる。(デフォルトは出ない)
Androidプラグインの中身もデバッグできる?

buid.gradleから外に出すと、importが必要になる。

Gradle Plugin Portalに公開する。

BuriKaigi2018 に参加してきた

toyama-eng.connpass.com

今年もBuriKaigiに参加してきました。
天気はぎりぎりでしたが、富山県のそれも氷見市に豪華なスピーカーがたくさんでした。

今年も、私は Java+α の部屋にずっといて、Javaやら、その他もろもろやらの話を聞きました。

JavaOne 2017フィードバック - JDKリリースモデル変更とJava EEEclipse Foundationへの移行

Oracleの伊藤さんによる、2017年10月にあった、JavaOneの振り返り。
ここ最近のキーワードはNimbleだそうで、軽量だったり俊敏だったりという意味。
これもあって、JDKのリリースサイクルの話になったのか?

Java EEの策定は、OracleからEclipse Foundationに移動したらしい。
直接EEを使うことはあんまり無いけど、Oracleから距離を置くのは、良いことなのやら、悪いことなのやら。。。

で、JDKのリリースモデルの話。

時系列に沿った、各バージョンのライフサイクル。

結構衝撃的な内容かと。
JDK8は、従来よりちょっと延命されて、それでも2019年1月になってしまうと、バグ・セキュリティホールの修正といったものが配布されない模様。(要確認?
そして、今後は、

  • 基本的にはOpenJDKの最新版に追従。ただし、次のバージョンが出たら、可能な限り早急にバージョンアップを行う。(その時点から修正が入らなくなってしまうため)
  • Oracleにお金を払い、OracleJDKのLTSバージョンを利用する。ただし、JDK11の次はJDK17を利用することになる。

になるっぽい?

で、次のJigsawのときにも話してたけど、コンサバに行くのであれば、今のところはJDK8を使い続けつつ、Jigsawの影響はでかいのでそれの対応準備だけしておいて、JDK11を待つ。(順次、10, 11の準備も必要)
で、JDK11が出たら、Oracleにお金を払いつつ、OracleJDKを利用する形にバージョンアップ。
それ以降は、3年間隔ぐらいで、新しいLTSに乗り換えていく。みたいな風になりそう?

上記に関連して、今までは各バージョンにいろいろ入れようとしすぎて?リリースが2年超えて4年とか空いていたけど、次からは6ヶ月単位でリリースするらしい。間に合わない機能などは、次のリリースに持ち越し。
Rubyも毎年クリスマスにバージョンアップしてますしね)

いちおう、JDK8の個人利用は2020年12月まで可能とのこと。
ただ、企業での開発・運用には使えないので、本当にホビー要素か、官公庁?などの公共サービスでは使えるらしい。

モジュール移行の課題と対策

上記でもちらっと出てきた、JDK9にする時の難所、Jigsawに関する話。
Java in the Box の櫻庭さんの話。

スライドはこちら。 モジュール移行の課題と対策

JigsawをJavaの機能として導入した動機としては、

  • -classpath の問題。ライブラリが並列に大量に並んだり、publicがpublic過ぎ(パッケージ間では公開したいが、モジュール外部には公開しない、といったことができない)
  • rt.jarのサイズの問題。640MByteぐらいあったので、小さなアプリケーションでも、動かすときは大きなバイナリになってしまっていた。

moduleを作るのは、jdepsとかのツールを使えば比較的かんたんに行えるが、運用していくのはつらいらしい。

-add-exports-add-modulesといったオプションを駆使していくことで、JDK9でも動作するように出来る。らしい。

Running Kubernetes on Azure

ほとんどのMicrosoft MVPが.NET側の会場にいる中、+αとしてKubernetesをAzureで動かす話。 仙台から、JAZUG 東北から来ていただいた、 山本 誠樹さん。(今回のスピーカーには、「山本」さんが多い。。)

スライドはこちら。 Running Kubernetes on Azure

実は2013年には登場しており、VISAカードのインフラにもなっているDockerは、そろそろ手をつけないと。。。

また、コンテナ管理・運用ツールとしては、Kubernetes(k8s)が事実上の標準に。

Azure上で動かす場合は、Azure Container Service (AKS)を使うのが最新で、おすすめということでしたが、日本リージョンはまだ無いらしい。また、GAになってないらしい。
ただ、そのうちGAにもなるし、日本にも来るはず。たぶん。

従来のPaaSは、簡単に始めて運用できるが、複雑なことが出来ない。 これからはPaaS上でDockerを動かし、複雑なこともコード化して管理できる。Infrastructure as a Code的な。になるだろう。とのこと。

日本語入力の落とし穴

休憩挟んで、mzpさんによる「日本語入力」の話。
名古屋から来て、ちゃんとMisocaの宣伝もしてました。

スライドとか、詳しい内容はこちら。 🐟日本語入力の落とし穴 #burikaigi - みずぴー日記

日本語入力とか、パスワードとかクレジットカード情報とか全部通過させてて怖くない?私は自分が作ってるからいいけど。とのこと。
たしかにーw

SKKについて話が出てたけど、「「Lを押したらLが入力された」問題」って、何を言っているかわからないw
とりあえず、変わったことをやろうと思ったら、本気で取り組まないと行けないんだな、、、と思いました。まる。

16枚目のスライドで、ハングルの入力例が出てたけど、初めて知った。
英語的に直接入力してるか、日本語的に変換してると思ってたから、それ以外にもあることに驚き。

「確定する前の文字列」や「入力メソッド用のキー」という概念が英語圏などには無く、日中韓が連携して入力メソッド周りを良くしていく必要があるそうな。

JetBrainsでもっと楽しくコーディング、ワークフロー

株式会社サムライズムの山本ゆうすけさん。 個人的にはTwitter4Jを作ったすごい人、最近はIka4Jというのも作ってるそうな。

まずはJetBrainsの、IDE以外の製品について。

YouTrackは課題トラッキングツールでRedmineとかJIRAみたいなもの。
keyboardでの操作が強く、Agile Boardもついてる。

Upsourceはコードレビューツール。GitHubにもついてるもの。
ただ、こちらはJetBrains製品だけあって、サーバ側で参照を解決しており、宣言に飛んだりをWEB上で出来る。

TeamCityはJenkinsやCircleCIみたいなCIツール。
ただ、IDEに引きこもってる人にとっては、IDE上で通知が出てきたりして便利。

Excel芸2018

名古屋から来られた、 bleis さん。
Excelはプレゼンソフト、ということで、発表資料自体がExcelで作られてました。
ただ、Excelを直接編集して作成したわけではなく、プログラマらしく?Markdown風に書いて、それを変換して出力してるらしい。

Excel方眼紙が仕方なく必要になる場面はあるけど、プログラマらしく技術の力でそれに立ち向かうべき。
他の形式で資料を作成しつつ、最終出力としてExcelを出せば良い。
(ただし、"最終"と言っているように、出力結果のExcelを触ることは想定しない)

Excel出力といえば、JavaならPOI。
ただ、APIが低レベルすぎ、Excel自体が多機能なのでPOIも多機能。
ここも、ラッパーライブラリを作ることで対応できる。

POIとの接続部分は副作用の塊になってしまうので、影響範囲を抑えつつ、
それ以外の場所ではScalaらしい関数型の副作用の無い世界で実装されてた。

Asciidocの紹介

個人的には うさぎ組 のテスト系ですごく刺激をもらっている kyon_mm さん。 今回は、Asciidocの紹介。

設計書などの仕様の共有にはExcelがよく使われてたりしますが、Gitでの管理がやりづらい。
Wikiとかで書いてもいいが、Gitのコードの変更とつなげるのは面倒。(Atlassianの製品で揃えたりしたら出来なくはないけど)
というわけで、プレーンテキストでコードと同じように管理しつつ、見やすい形に変換できればいい。
さらに、エンジニア以外(マネージャとか経営陣?)とかでも、簡単にインストール出来るものが良い。

というわけで、Asciidocの紹介。

  • オライリーの書籍などでも使われている=本が作れるぐらいの表現力がある。
  • プレーンテキストで記述して、RubyJREがあればHTMLに変換可能。
  • テーブルなどもデフォルトで定義されている。(Markdownのテーブルは拡張機能。)
    • テーブルの記述方法が人間にやさしい。(Markdownは各セルが横に並んでいくので、追加などはしづらい。)
  • HTML変換でき、動画埋め込みなども柔軟に出来る。
  • 画像のサイズ指定が出来る。
  • PlantUMLで図が書ける。(graphvizと拡張のgemは必要)

kyonさんの会社でもすでに、受託案件のユーザガイドをAsciiDocで納品してたり、
お客さんがいつの間にか使い始めてたりしているそう。

PDFにするのであれば、HTML変換してからChromeでPDF保存がおすすめとのこと。

便利そうなので使ってみたいが、このあたりは関係者全員の理解が無いと難しいので、先は長そう。。。
とりあえず、個人的に使って見るところから始めようと思います。

まとめ

今年も、内容の濃い・バライティに富んだセッションでした。
また、人数が多すぎない(良いのか?)ので、スピーカーとも比較的距離が近く、良かったです。

個人的な反省としては、この記事を書き上げるまでに一週間かかってしまい、記憶が薄れてしまったので、
今度からはもっと新鮮なうちに記事を書かねば。。。と思いました。ブリだけに。

あとは、聞きながら取ったメモをそのまま貼り付けておきます

## JavaOne 2017フィードバック - JDKリリースモデル変更とJava EEのEclipse Foundationへの移行

JavaOneは2017年の10月に開催。
キーワード:Open, Evolving, Nimble, Scalable
Nimbleが追加。軽量化・俊敏性などの意味。

Java EE
8 Available, Open, Nimble

EEはEclipse Foundationから発表される。

Java SE
9 Available, OpenJDK, Cadence

### JDK 新しいリリースモデル
2018/1/30現在

JDK7の段階で、Coin, Lambda, Jigsawが計画されていた。
7: Coinの一部
8: Coinの一部、Lambda
9: Milling Coin, Jigsaw

JDK9は、過去最多の機能追加。
7, 8, 9と倍々ぐらいに増えてる。
リリースの間は、機能追加はほぼ無かった。(リリース間隔が長い)
他の言語は、リリース間隔がもっと短い。

#### 従来のリリースモデル
メジャーバージョンは、2年に一度を目標。
Oracle JDKの後継バージョンのリリース後、1年の無償サポート
更新リリースは3ヶ月後。基本的にはメンテナンス用のアップデート。(limited updateもあった)
有償で長期サポートもあった。

#### 新しいリリースモデル
機能リリースが6ヶ月に一度(固定) 3, 9月
無償で使うものは、基本的にOpenJDK。後継バージョンのリリースまでの6ヶ月間の無償サポート。
JDK9, 10は試用期間的な感じ。
完成した機能からリリース。予定されていたものが間に合わなくても、リリースはする。
リリースの重複期間がなくなる。
OpenJDKとOracleJDKの技術的な差分をなくす(2018年後半)

更新リリースは今まで通り。ただし、limited updateは入らない。

長期サポート(LTS) 2018年9月から開始。(JDK11に該当)
OracleJDのバイナリ(有償)
8年の長期サポートの提供。

JDK8の無償期間が伸びた。2019年1月まで、無償期間。
個人利用は2020年12月まで。企業での開発・運用には使えない。個人・公共サービスで使う場合は、使える。

リリース情報の提供
OpenJDKから提供 http://openjdk.java.net/
Deprecatedの運用ルールはそのまま。最短1年で機能が削除される可能性。

本番運用するのであれば、JDK8 -> JDK11にしたほうが良いかもしれない。

リリースモデルまとめ

Java Plug-in, Java Web StartのサポートはJava SE 8まで。
9には残っているが、10からは削除される。

Java SE 8から後継バージョンへの自動更新は行われない。
9の32ビット版のバイナリ提供の予定は現状ない。移行もしくは現状維持。

Server JREも、同じリリースモデル。

### Java EE 8
Eclipse FoundationへJava EEを移管する。
MicroProfile.ioとの統合を模索する。
まだいろいろ検討中。

## モジュール移行の課題と対策

Jigsawの話。

### 動機

#### -classpath問題。
ライブラリ多すぎ。publicがpublicすぎ。
Module導入。依存性、公開範囲を明記。

#### rt.jar問題。
640MBぐらいあった。
機能ごとにModuleに分割。

### Module

module-info.javaに依存性、公開範囲を記述する。

module モジュール名 { requires 依存するパッケージ; exports 公開するパッケージ; }

module作るのはかんたん。運用するのは難しいけど。

javac --module-path or -p
(昔は、-mpだった)

### ツールの対応

IDE NetBeansがいまいちの対応状況。
ビルドツールは、MavenもGradleも、いちおう使える、という状況。optionの記述が必要。
議論が続いていて、どうなって行くかはまだわからない。

### jdeps 依存性調査ツール
"-s"をすると、依存性が出てくる。
"--generate-module-info"で全部出てくる。必要に応じて編集が必要。

### 非モジュールシステムでの課題

#### 非公開API
com.sunとか、sunとか、java.awt.peerとかがexportされてないパッケージ。
sun.misc.Unsafe, sun.reflect.Reflectionは今後削除予定。

対策:exportを追加する。--add-exportsオプションを利用する。
非モジュールシステムでは、target=ALL-UNNAMED
これで動くようになるが、いつ消えるかわからない。

reflectionでアクセスしていると、jdepsでは見つからない。
コンパイルは通り、実行時もwarning。
--illegal-access=deny をつけると、 InaccessibleObjectExceptionが起こる。

setAccessible(true)を利用したreflectionは、--add-opensを付ける。
→そもそも、使うべきではない。

#### 非標準Module

javax.xml.bindが、標準のModulepathに含まれていない。
java.xml.ws, java.corbaも。

対策:Moduleを追加する。
--add-modulesオプション。

### モジュールシステムでの課題

modulepathとclasspathを併用しなければならない。

直接アクセス:Automatic Module
間接アクセス:Unnamed Module
として扱う。

Automaticはmodulepath、Unnamedはclasspath
jar -d --file XXX.jar とすると、Module名がわかる。それを、module-info.javaに書く。
MANIFEST.MFに書いてあればそれが、無ければファイル名が出てくる。

Automatic Moduleは依存性を記述できないので、自分で実行時に--add-moduleを書く。
依存性がわからなければ、 ALL-MODULE-PATH を指定する。

将来的には、modulepathだけで済むはず。いつになるのか。

## Running Kubernetes on Azure

仙台からJAZUG 東北から。

Docker自体は、2013年に登場してた。
2017年、Kubernetesが事実上の標準に。

VISAカードのインフラにDockerが使われてる。
そろそろ手を付けないと。

### なぜKubernetesを使うか。
コンテナ管理が必要になってくる。

### Azure上で動かす
ACS, ACS Engine, JKS

ACS
GA済み。SLAが適用される。
日本リージョン。
マスターの課金が発生。
k8sのバージョンアップが出来ない。
公式ドキュメントにたどり着きづらい。
100Nodeまで。

ACS Engine
ACSのOSS版。GitHubに公開されている。
任意のVNETに配置できる
1200Nodeのクラスタ構築できる。
展開方法が複雑。
SLAナシ。

AKS
マスターノードの課金はない。
k8sのバージョンアップが可能。
Managed Disk対応。
プレビュー段階。SLAナシ。
日本リージョンに展開されていない。
コマンド3つで作れる。

「PaaSは滅ぶだろう」
今までのPaaS:簡単ゆえに、複雑なことができない。
これからのPaaS:複雑だが簡単に使うことは可能。Infra as a Code
Dockerをベースに、それをいかに動かすか。

helm install stable/wordpressでWordPressが立ち上がる。

Docker Edgeバージョンで、k8sも一緒にインストールされる。

## 日本語入力の落とし穴

すべてのキー入力を受け取る。(パスワードとかも)
ウィンドウを持たない
日本国内では、全員が使ってる

ロシア語など、そのまま出てくる
ハングルなど、入力したところから出てくる
中国語など、音を入れると出てくる

### 「確定する前の文字列」という概念
下線が引かている状態
勝手に確定されたり、削除されたり。
SKKだと入力できない場合があったり。

### 「入力メソッド用のキー」という概念
かなキーとか。

## JetBrainsでもっと楽しくコーディング、ワークフロー

https://github.com/yusuke/ika4j とか作ってる。

Upsource, YouTrack, TeamCity などもある。

YouTrackは課題トラッキングツール
RedmineとかJIRAみたいなもの。
keyboardでの操作が強い。
Agile Boardがついてる。

".if"とか".return"
"psvm"で、mainメソッドを作れる。
".var"で編集にしてくれる。

Upsourceであれば、シンボルの参照関係に飛べる。
Intellij IDEAのエンジンが、サーバサイドで動いているイメージ。
Intellij IDEA内で、PRのコメントが見れる。コードにJUMPできる。

TeamCityは、IDE上でビルド結果が通知される。
失敗したログが見れて、テストコードにJUMP出来る。

## Excel芸2018

Excel is プレゼンソフト
Excel方眼紙も、プログラムで解決したら良い。
バージョン管理、差分が見れない、編集が面倒
Escを押すと、入力した内容が消える

人の手によって、想定していたフォーマットが破壊される。
Excel方眼紙を出力結果にする。触らせない。

VBAは、Excel内部の話。
COMは遅いとか、ライセンスの問題。

POI
Officeファイルを読み書きするJavaライブラリ。
Excelに強い。

APIが低レベルすぎる。
超多機能。ただ、未実装機能も多い。(Excelが多機能すぎる)

POIのラッパーライブラリを作ればいい。
dihyd: markdown風 -> プレゼン資料モデルに変換
mono-oxy
dhmo: Excel出力

flexmark: Markdownを解析

xls を使いたければ、 https://github.com/tonyqus/npoi の方がいいかも。
ただし、書き込みは壊れやすい。

## Asciidocの紹介

簡単に構造化して、共有できるものが便利。
Gitで管理できると楽なことが多い。
Wikiに書くと、それとGit(コード)がつながらない。

Gitで管理するためには、プレーンテキストがよい。マージとか。

チームで共通に出来るフォーマットがよい。
Emacsであれば、org-modeとかもある。
必要なツールが少ないほうがよい。マネージャとか、経営陣とかでも。

AsciiDoc
オライリーが作った。
テーブルなどもデフォルトである。(Markdownのテーブルは拡張)
HTML変換でき、動画埋め込みなども出来る。

OTR社実績
受託開発でユーザガイドをAsciiDocで納品
お客さんが使い始める。

プレーンテキスト。
RubyかJREがあればHTMLに変換可能。
Atom, VSCodeでプレビュー付きのプラグインがある。

画像のサイズ指定が出来る。
テーブルは、ヘッダ以外は1セル1行で書ける。追加とかもしやすい。
graphvizと拡張のgemがあれば、plantumlで書ける。

asciidoctor-pdfがあるけど、うまく動かないことが多い。
HTML変換してから、chromeでPDFに保存したほうがよい。
pandocもうまく動かない。

kanazawa.rb meetup #65 に参加してきた。

kzrb.doorkeeper.jp

ほぼ毎月恒例、第三土曜日は金沢まで行ってきました。

今回はもくもく会ということで、もくもく作業してきました。

具体的には、
・前日、再起動ループに陥ったNexus5Xの代わりを探す
・ReactNativeを試してみる
といったあたりをやりました。

まず、スマホですが、いろいろ迷いはしましたが、HUAWEI P10 liteを買いました。
Amazonで昼過ぎに注文しましたが、次の日に届きました。Amazonすげぇ。



で、ReactNativeは、ほとんど動かしたことない状態から、サンプル程度が動くまではできました。

ただ、ちょっと動かしてみただけだと、UI周りが寂しく感じたので、NativeBaseを入れてみました。

NativeBase | Essential cross-platform UI components for React Native

UIのタグに関しては独自のものになるので、書き換えの量はまーまーありましたが、シンプルなコードで綺麗なUIができました。

ただ、今度作りたいものは、iOS, AndroidだけでなくElectronでも動かしたいので、React Native for Webでも動かしてみよう、、、というところで時間切れでした。



他の人たちは、Rubyだったり、Elixirだったり、Sendgridだったりの勉強・調査をしていたりといろいろでした。



懇親会は三次会まであって、車で行ったので酒を飲めなかったのですが、周りが程よく酔ってたので、楽しく過ごせました。

調味料やらインスタント味噌汁?の話、これからJavaScriptをまじめにやるのはどーなんだ?とか、AIを上手くやると稼げるし下手するとやばいとか、いろんな話が出ました。



iPadで書いてみましたが、日記的なものであれば、全然書けますね。
技術的なものとか、引用がたくさん必要なものは辛いかもですが。

Toyama.rb #25 もくもく会 に参加してきた

toyamarb.connpass.com

Toyama.rb #25 もくもく会に参加してきました。
久々に、レポート的なものを書こうと思います。

今回は参加日が近づいていくと、ぱらぱらと参加者が増え、通常のもくもく会にしては多めの8人でした。

当日は雪が積もってるし、昼からさらに降る予定だったりと、天気はやばかったですが、ドタキャンなく全員集まりました。

個人的には、詰め共円iOS版をアップデートして、FirebaseのCrashlyticsとPerformance Monitoringを導入しました。

・・・Ruby関係ないっすね。



久々の更新だったので、各種のライブラリのバージョンアップから初めました。

TwitterKitのSDKを3系にすると、iOSの最低バージョンが9系になるので、そこも含めて更新しました。
(Podfileだけ変えてもダメだということに気づくのに、ちょっと時間がかかりました。)

また、TwitterKitを3.3にしたことで、インターフェースが変更されてました。
https://dev.twitter.com/twitterkit/ios/installation を見て実装していたのですが、ヘッダファイルが見つからなかったり、 Twitter クラスが見つからなかったり。。。
https://github.com/twitter/twitter-kit-ios/wiki/Installation を見ると、違うインターフェースが書かれていて、こっちだとビルド成功しました。
謎ですね。。

当初の目的だった、Firebase関連については、特に問題もなく導入出来ました。
(Performanceに関しては、時間中には管理画面上での確認はできなかったですが、エラーなかったのでそのまま進めました。。)

あとは、リリースするために、CircleCIでビルドしてもらうところでエラーになりました。
ビルドバージョンを毎回変えるのが面倒なので、gitのタグから更新するようにしました。
ここでFastlaneのFastfileを変更したので、いちおうRubyやってますね。

そんな感じで、3つのPRを作成、マージしました。

んで、申請情報を書いて、Appleの審査を送ったあたりで、時間になりました。



他の人の活動としては、

などされていたようです。

今回はかなりRuby成分多めの回でした。(いつもはこんなに多くないw



Toyama.rb のもくもく会では、Rubyにこだわらずに、ゆるーくやっています。(と思います)
基本的には毎月第二土曜日にやっているので、近隣の方で、興味のある方は一度参加いただければと思います。(主催者でもなんでもないですが。。)



来週は

kzrb.doorkeeper.jp

新型MacBook Proのために買ったUSB-C関連商品

1年ぐらい前にこんな記事を書きました。

新しいMacBook Proを買うにあたって、スマホアプリエンジニアとしてUSB Type-C関連商品を探してみた - 混沌とした備忘録

結局買ったものを紹介します。

ケーブル類

C to Cと、C to Micro Bを買いました。

今使っているスマホがNexus5XでType Cなのと、 検証機的に使っている402SOがMicro Bなので、この2つを買いました。

C to Cは、安心のAnkerのものを買いました。

USBハブ

既存のType Aの機器もあるので、ハブも買いました。

また、勉強会などで前で出力する場合はHDMIの場合も多いので、便利です。

Type Aへの変換

上で買ったハブでType Aに変換できたのですが、SuperDriveを使おうと思ったら、うまく認識されませんでした。

調べたら、Apple純正じゃないとうまくつながらないっぽかったので、これを買いました。 これだったら、無事つながりました。

ディスプレイ用ケーブル

我が家にはIODATAの4kディスプレイがあるので、それとの接続用に買いました。 ディスプレイ側では、DisplayPortしか4k 60fspに対応してないそうなので、こちらを買いました。

つなげてみると、ちゃんと4kで接続でき、HDMIで繋いでいたときのようなカクつきは感じなかったので、60fps出ているようです。 (個人PCをデスクで使うことが少ないので、あんまり使ってないですが。。。)

ほしいもの

MacBook Pro 2017にドンズバな4Kモニタ購入!LG 27UD88-W 開封セットアップ編 【動チェク!】 - YouTube

これをみて、USB C一本で、電源・ディスプレイ・ハブとして使えるのはいいな、と思いました。 ただ、曲面ディスプレイも気になってるので、もうちょっと値段が下がってきたら考えようかと。。。4kはすでにあるし。

Snapnator が届いた!

新型のMacBook ProにMagSafeを取り戻すために買った、 Snapnator が届きました。

www.kickstarter.com

今見ると、 2016/11/04 にKickstarterでbackしてました。 半年ぐらいで届いたんですね。

外箱はこんな感じ。微妙に凹んでましたが、国際郵便でプチプチに包まれてただけなので、仕方ないっすかね。

説明書と本体。

MacBookにつなげてみたらこんな感じ。

MacBookとの間に微妙な隙間空いてるし、微妙に汚い。。。

隙間空いてるせいか、動かすとちょっとぐらぐらする感じもありますね。

てきとーに引っ張ったら、磁石でちゃんと外れました。

ピンぼけしてますが、磁石の部分はこんな感じ。

で、これはなんだろう。。。?

Twitterとか見てると、熱くなるとかって話がありましたが、そもそも製造精度が微妙な感じ。 あと、思ったよりMacBook側の出っ張りが大きいっすね。

・・・使わないかなぁ。

新しい Fire TV Stick を買ってみた

ここ1,2週間はやる気が出なくて、Youtubeばっかり見てます。

寝室ではchromecastで快適に見れているのですが、リビングのFire TV Stick(旧バージョン)の調子が悪く、音と映像がずれるようになってました。

新しいのが出るということで待ってたのが、ようやく届きました。

Fire TV Stick (New モデル) ってやつですね。

最近は(?)、名前は変えずに"New"とかつけるのが流行ってるんですかね。(iPadとか)

というわけで、開封しました。

開けてみた

やっぱ、箱でっかいっすね。

外箱はこんな感じ。

で、中には2つ折りで黒い入れ物。

全部出してみた。 電池も、Amazonの電池。

上が古いやつ。下が新しいやつ。 ちょっとでかくなったみたいですね。

使ってみた

とりあえず、設定して、使ってみました。

まずは、プライムビデオを。

最初はネットワークの調子を測ってたのか、動画がかなり荒かったのですが、数分もしたらきれいな画質になりました。

で、感動したのが10秒送り。 全然遅延なく、押した瞬間10秒後の動画が始まる。 Youtubeとか、nasneの動画をAndroidタブレットで見るのに慣れてると、感動的な操作性。

次はYoutube。 最近はまってる カズチャンネル/Kazu Channel - YouTube とか 瀬戸弘司 / Koji Seto - YouTube とかを見てみました。 やっぱり、遅延なく見れます。 また、AndroidYoutubeアプリ上部にあるキャストボタンから、Fire TV Stickに飛ばして、テレビで動画見ながら次に見る動画を快適に選択できました。

感想

5,000円ぐらいかけるだけで、テレビでプライムビデオ・Youtubeが見れるようになるので、かなりお買い得かと。 あと、なんだかんだで物理リモコンもついてくるのがいいですね。音声認識とか使うかわからんけど。

BuriKaigi2017に参加してきた

toyama-eng.connpass.com

富山で.NETとJavaが一緒になったイベントに参加してきました。

.NETはほとんど関わりがないので、ずっとJavaのセッションにいましたが、オラクルの人と日本に2名しかいないJava Championの話を富山で聞ける、というのはすごいですね。 内容も、今までとこれからのJava SE / EEについてや、新しい開発手法、Microsoftのサービスを使ったデモなど、様々なことを再確認・学べました。 会場はそんなに広くなかったですが、Java側はそこまで過密じゃなかったので、ちょうどよいぐらいでした。

合同でのLTでは、別々のLTなのに、APISQLに→SQLC#にと、神がかった流れもありました。

本番は懇親会、ということでタイトル通りのブリしゃぶも美味しかったです。 5,000円で飲放題付きで、量・質ともに良い料理でした。 2名しかいないJava Championに挟まれる、というすごい状況でしたw

3次会まで、いろんな話ができ、昔話・それぞれの人の考え・自分の考えのまとめなどできました。

個人的に考えが整理できたのは、自分のやりがいをどこに求めるか、という部分です。 プロダクトとして良いものを作りたい、というのは無くはないのですが、私としてはその中でどんなアーキテクチャ設計・実装が出来るかということが大事なようです。

人と深く話すと、自分の思いを整理・理解できていいですね。

以下は、聞きながらとったメモです。

タイトル未定

伊藤敬 氏

JavaOne 2016

過去最多の日本からの登壇者 マツダの工場でJavaが動いてる。

JavaSE Update

dockerのイメージで配布される?もう少ししたら、具体的な話がでるかも。 2017/7/27に、Java9がリリース予定。 Feature Extension Completeはされたけど、まだ機能が入る。。? Java SE9では、Applet起動時に「非推奨です」の警告が出る。 非互換 →ほとんどの内部APIが利用不可になる。JEP 260。sun.misc.*などの排除。

Java EE Update

クラウド・マイクロサービスを向いている。 リアクティブ・プログラミングの導入。 dockerとの親和性も考えてる。 パッケージングにDockerモデルの採用 Serverlessについても検討を始めている。 jarを作れば、いろんなクラウドに乗る。ようにしたいと考えている。 アノテーションベースで、Configやloggingが外部サービスの実装をInjectしてくれる。 OAuth/OpenIDのサポート。 JMSやManagementは変更しない。 MVCは議論中。 JSON-B, Security, Configuration, Health Checkあたりが、Java EE8で入りそう。(Configurationは微妙かも) Bean Validation, Servlet, CDI, JSF, JAX-RS, JSON-PがJava EE8で更新される。 そろそろ、オープンな議論が始まりそう、ってステータス。 Java EE8は、2017年中に出す。予定。 マイクロサービスサポートは、JavaEE9が本番。

WebLogic ChannelがOracle Java & Developersにリニューアル。

これまでのJavaと、これからのJava

櫻庭祐一 氏

内部・匿名クラスは、Java1.1で出てきた。マイクロソフトのおかげかも。 →継承から移譲へ。関心事の分離。ラムダ式へ。 J2SE5 Ease of Development ジェネリクス クラスのパラメタ化 Type Safe=型安全 JSR201: for-each →これも、最近はstreamで書けるようになった。 Java SE7 Coin(=small changes = 小銭) try-with-resources ダイヤモンド演算子 Java SE9 Lambda 外部イテレータ→内部イテレータ。最適化しやすい。パラレルとか。 途中状態が晒されない。イミュータブルに出来る。List<Long> nums2 = nums.stream().map(n -> n*2L).collect(Collectors.toList()); interfaceのデフォルト実装は、SDK内部のコード変更が可能に。 Java SE9 Jigsaw モジュールの導入。JARにメタデータが書けるように。

機能導入の目的 ・Performance ・Ease of Dev ・Safeness Lambdaのみが、Performanceに関するもの。それは、マルチコア世代のため。 その前に、InvokeDynamicが重要な要素だった。

Future Java SE10 Valhalla / Panama / Ambar Valhalla →Primitive TypeとReference Typeの中間にValue Typeを作る。 →型パラメータにPrimitive Typeを入れられるようになる。

ハードの変革に応じて、ソフトの作り方も変えないといけない。Javaの言語仕様も、Performance関連の変更も今後入ってくる。

Engineer is Hero !!

マイクロサービスの開発手法や IoT を採用し感情や表情を解析しより良い社会を作ろう 寺田佳央 氏

マイクロソフトは、かなりクラウドを推してる。 AIもやってる。APIやPlatform化。 Cognitive Toolkit -> Microsoft R -> Machine Learning -> Cognitive Serviceの順で手軽に出来る。 Cognitive Serviceの認識率は、人間と同等化それ以上。 HololensはMR。

開発環境と本番環境を揃えるのは大変。VMとかできてきたけど、容量がでかい。 Infrastructure as code 環境のロールバックが出来る。 構築と設定の2パターンがある。

DevOpsとは、ツールの話ではない。開発プロセス改善活動の一環。 ハックフェストは、実際のコードを使う。 →今の開発プロセスを書き出す。企画からリリース管理までを洗い出す。バリューストリームマッピング。どこに人がかかり、時間がかかってるか。 実例として、リリースまでに8ヶ月かかってたのが2,3週間になった。 feature flag付けて、実際のデータで見せたほうが、理解が得やすい。

Micro Service DepOpsの先に、Micro Service。自動化されているから、生きる。 住宅建築から、いろんなものを学んできた。 住宅の寿命は30年。リフォームするみたいに、ソフトウェアも再構築? ソフトウェアのライフサイクルはもっと短い。住宅業界から学ぶのはもうやめては? water fallでは、時間が立つに連れ、変更に対するコストが大きくなる。ただ、時間が短ければそうでもない。 Ford(車外車)がFordPassというものを作った。クラウドとかmicro servieを使って、作ってる。東海岸と西海岸でDR構成。 Azureには1年に600の機能が追加されてる。1つの不具合が全体に影響しないようにしている。

いままで:モノリシック→1つの変更、障害に対して、影響範囲が大きい。ロックインされる。 マイクロサービス:影響範囲を限定化。言語なんかも再選択出来る。 考え方を変えないといけない。分散される。システムは落ちる・通信は切れる可能性はある。 マイクロサービス・デザイン・パターンが提供されている。 (https://uramoto.wordpress.com/2015/09/21/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3/ このあたりか)

MicroProfileなど、マイクロサービスを意識したJava framework。 Azure Service FabricはAkkaの人とかが馴染みやすい。 Pivotal Cloud Foundryのデモ。GitHubにコードが上がってる。

AIのサービス Cortana / BOT Framework / Cognitive Services / Azure Machine Learning / Cognitive Toolkit アロバビューという会社が、監視カメラと連携させている。サマーランドの入場者の男女比・年齢層がリアルタイムで分かる。Power BIで可視化。 OCRは精度高いけど、日本語英語が混じると、うまくいかない場合がある。 制限はあるけど、無料で試せる。ブラウザ上で試すことが出来る。

ブクログの本棚を、amakanにインポートしてみた

今までは、 ・本棚としてはブクログ http://booklog.jp/ ・新刊情報は新刊.net http://sinkan.net/ をGoogleCalendarにエクスポート してました。

ただ、 新しいシリーズを買ってブクログに登録しても、新刊.netにも登録しないといけない ってのがめんどうでした。

そこで、ふと思い立って、前から気になってたamakanにデータを移してみました。

chrome拡張が無い

amakankanというもので、ブクログから移行できるのは知ってました。

amakanのChrome拡張がブクログの本棚からの一括登録に対応しました - amakan

ただ、chrome extentionのリンクを踏んで見ると、404になってました。

なので、GitHubのコードをcloneしてきて、手元でビルドしました。

github.com

ghq get https://github.com/amakan/amakankan.git
cd /path/to/amakan/amakankan
yarn install
npm run pack

chrome://extensions/ に移動して、「パッケージ化されていない拡張機能を読み込む...」で、 dist/chromeを指定しました。

ブクログからインポートしてみた

http://booklog.jp/users/noboru114 に遷移して、chrome extentionのボタンを押しました。 「登録中」的なアラートは出るけど、何も起こらず。

不思議に思ってコードを見ると、 https://github.com/amakan/amakankan/blob/master/src/chrome/js/content-script-booklog.js#L42 で、「読み終わった」と書いてありました。

個人的に、設定がめんどいので、全て「未設定」にしていたので、データが取得できなかったっぽいです。なので、

-        const url = `${pathNamePart}?category_id=all&status=3&sort=sort_asc&rank=all&tag=&keyword=&reviewed=&quoted=&json=true&page=${i + 1}`;
+        const url = `${pathNamePart}?category_id=all&status=all&sort=sort_asc&rank=all&tag=&keyword=&reviewed=&quoted=&json=true&page=${i + 1}`;

のように、statusをallに変更して、試してみると、無事登録が開始されました。

コード変更後は、npm run packして、拡張機能のページで「リロード(⌘R)」を実行しました。

件数がたりない

ブクログは682アイテムあるのですが、amakanに登録されたのは666アイテムでした。 20アイテムが登録できなかったようです。差分はめんどいので追ってないです。

日付が、全部「今日」になった

「読んだ数」がグラフ化されますが、全部同じ日付になっちゃいました。

コード確認すると、read_atで取得してました。

https://github.com/amakan/amakankan/blob/master/src/chrome/js/content-script-booklog.js#L16

で、JSONを確認すると、create_onで登録日が取れそうでした。 なので、下のようにつぶやいて、r7kamuraさんに捕捉され、補足いただきました。

なので、

-    const readAt = book.read_at;
+    const readAt = book.create_on;

にして、再度packしてリロード。そして実行すると、いい感じにグラフが作成されました。

https://amakan.net/@noboru

こうやって可視化されるのは、微妙な気持ちになりますね。

というわけで

無事、インポートはできました。 新刊も、Google calendarでいい感じに取れてそうです。

ただこれ、どうやって追加登録するんでしょ。。。? https://amakan.net/tools にあるけど、いまいち、使い方がわからない。。 Androidのクライアントとか、作っちゃえばいいのかな。。。?