AWS Community Day Kanazawa に参加してきました

awscommunityday2019.jaws-ug.jp

日本で初開催のAWS Community Dayが隣の石川県であるということで、平日ですが参加してきました。

AWSについては、2, 3年前は仕事でちらほら触っていたのですが、最近ではAndroidアプリなどのクライアント側が多く、ここ1ヶ月ぐらいでまた触り始めた、という感じでした。
そのため、最近の事情に疎く、そのあたりのキャッチアップをしたかった、というのも参加の動機でした。

直近で富山Ruby会議の運営に関わっていたこともあり、スポンサーがいっぱいだったり、2トラック+ハンズオンだったりで、大変だったろうなーと思いました。
進行はスムーズで、様々な種類のトークがあり、すごく良かったです。

平日の、AWS自体が共催?ということで、もっとスーツ系の人が多いのかと思ってましたが、実際にはそんな雰囲気ではなく、実際に手を動かして使っている人が多い印象を受けました。

以下、参加したセッションと、その感想など。

基調講演 ~インフラからテクノロジープラットフォームへ~

AWS亀田さんのセッション。

基調講演らしく、「なぜAWSを使うのか?」や「そもそもクラウドを利用することでどんな利点があるのか?」といった幅広い話だったと思います。

個人的には、「AWS内の"非"マネージドサービスはEC2しかない(と言っても過言ではない、ぐらい?)」というのが意外と衝撃的でした。
たしかに思い返してみるとそうなのですが、意外と実感してなかったです。

あとは、「社内にテクノロジーblackboxを作らない」のが良いなと思いました。
受託の開発をしていると、納品後の動向がわからないこともあり、このあたりまで追ってあげる方がお客さんのためなのでは?と感じました。

今覚えておきたいWell Architected Framework(W-A)と便利なツール

AwS舘岡さんのセッション。

Well Architected Frameworkについて、なんとなく存在は知っていたけど、今回で初めてちゃんと中身を知った気がします。
直近で、インフラの構成やそのレビュー?をする機会があるので、こういったツールも使いながらやっていこうかと思いました。

また、ほとんど知らなかったSystems Managerがかなり便利そうでした。
SSM Inventoryでのデータ収集や、Sessions ManagerでのSSHなど、すぐに使えそうな知識を得られたのが良かったです。

AWSでAlexaスキル開発をスケール&ブーストする

Alexaスキルをがっつり作る話。

「Alexaスキルを作る」ことは「Lambdaの関数を作る」とほぼ同義とのこと。
(音声の解釈などは勝手にやってくれるし、そこから音声化するのも勝手にやってくれる)

ASK CLIというものがあって、手軽に始めるには良さそう。
とはいえ、がっつりAWSのサービス群と組み合わせようとすると、いろいろつらみがありそう。

Cognitoと組み合わせたり、Amplifyと組み合わせたりで、Webとの接続も比較的簡単にできそう。

海外リモートワークとAWS運用

年に2ヶ月程度、台湾でリモートワークをしている話。

昔ながら?のオンプレ環境だと、物理サーバの世話など、リモートワークでは出来ない作業も多かったけど、AWSだとそもそも手元にないので、どこにいてもそんなに変わらないとのこと。

リモートをする上で気をつけていることとして、連絡が取れるように(取れない場合は事前に伝えておく)したり、サポートし合う関係を作ったりなど、自分も納得できる内容だったので、改めて気をつけていこうと思いました。

AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル業界出身で、父の事業の一部を受け継いで?薬局関連のサービスを開発している話。

異業種から入ってきて、これだけ出来ているのはすげぇなーと思いました。
また、こういった企業が北陸にもあるんだなーという再認識が出来、よかったです。

AWS運用の事例紹介

受託のアプリ開発を、AWSのインフラを利用して行っている話。

開発期間が2〜6ヶ月が多いというのは、結構驚きつつ、よく考えれば自分たちも半年ぐらいでリリースする案件はちらほらある気もしました。
とはいえ、ユーザ数が結構多いアプリが多かったので、自分たちももっと効率よく作れるのでは?と考えさせられたセッションでした。

多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション。

「玉田工業株式会社」という社名は聞いたことがなかったのですが、ガソリンスタンドなどの地下タンクにおいて大きなシェアを持っている会社とのこと。

そこから、ガソスタの監視システムなどを、AWSを利用して構築しているとのこと。

製造業で実はすごいシェアを持ってて、そこから派生してシステムを作れば強いのに、そこに気づいていない企業は結構ありそう?と思いました。

拡張して使う Serverless & Amplify

アプリのリニューアルをするのに、ServerlessとAmplifyを使った苦労話。

TypeScriptをLambdaとReact Nativeで利用することで、同一言語でサーバサイドもクライアントも作ったとのこと。
たしかに、言語が同じであれば考え方もある程度共通化でき、少人数や短期間ではかなりメリットありそう。

Serverless Frameworkは、pluginがかなり充実しているようで、困ったら作る前に探してみたら良さそう?と思いました。

Amplifyのカスタマイズ方法も興味深く、機会があったらやってみたいと思いました。

クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

いわゆる"情シス"を、ちゃんとやっていった記録の話。

情シスは、縁の下の力持ち的なイメージで、目立たないイメージがありましたが、こうやってきれいにまとめてもらうとかなり重要なポジションだと感じました。

また、昨今はいろんなサービスがあり、試用期間が設けられているものが多く、とりあえず小規模に導入してみてダメだったら乗り換える、というのが良さそう。

感想まとめ

Systems ManagerやAmplify、LambdaといったAWSのサービスを知る・理解することが出来たのはもちろん良かったのですが、
自分が住んでいる北陸で、独自のサービスや付加価値を提供している事例を知れたのがよかったです。

自分は、北陸に住んでいるとはいえ、東京の会社に所属して仕事をしているので、こういったコミュニティ経由でしか北陸の事情を知ることが出来ないので、 こういったイベントを企画してくれた運営の方々には感謝の気持ちでいっぱいです。

タイミング・知識が合致したら、今度は自分も登壇できるように頑張ろうと思います。

以下、当日にとってたメモ。

## オープニング

JAWS-UGについて
JaWS-UG 金沢について 2011年1月に活動開始。
AWS Community Dayについて AWsと共催。Community Dayとしては、日本で初めて。

トラックAが基本的なものがメイン。トラックBが応用的なものメイン。
写真撮影NGの人のために、ストラップの色が違う。

#jawsug #awscommunityday
が本日のハッシュタグ。

## 基調講演 ~インフラからテクノロジープラットフォームへ~

AWSのモデル。固定資産型からサービス型へ。
コスト削減だけでなく、ノウハウをためていくことを推進。
Digitalization(ソフトウェアによる価値最大化)を、開発者とともに目指していきたい。
モノは、買ったときが最大の価値を持っている。サービスは、日々進化していく。
アプリケーションを請負で塩漬けしても、AWS部分が進化していく。もったいない。
よく出るキーワード「サーバレスコンピューティング」
ただ、インフラ費用の見積もりが課題。プログラム実行回数とメモリで課金。
CAPEX / OPEX クラウドを利用することで、無駄のない投資。
CAPEXのほうが、価格が変動しないので良いと考える人もいる。
AWSはマネージドサービスを推進している。非マネージドサービスはEC2だけと言ってもいいぐらい。
ただ、マネージド・サービスはロックインに感じる人もいる。
アメリカの大きな企業の平均存続年数は67年->15年と、かなり短くなっている。サイクルの速さが大切になってくる。
障害を踏まえた設計指針:RTOとRPO このあたりの設計を、事前に行っておけば、決まってくるものが多い。
良いものを作ろうと思うと、コストが上がってくる。
AWSには、最新テクノロジーを利用するためのサービスが多くある。
ownershipを置いてきぼりにするのは問題が大きい。(データを外部のSIerに丸投げして機械学習させるなど)
「社内にテクノロジーのblackboxを作らない」という考え方が大事
re:inventでラスベガス行くなら、観光などと合わせ、UBERなどのサービスを経験してみるのがおすすめ。
Uberlization: 異業種がITを駆使して既存ビジネスを変えていく。
AWSでは、「強化学習」に力を入れている。
教師あり学習では、人間の能力でキャップされやすい。
強化学習:コンピュータ同士で囲碁の対戦をさせるなど。良い行動に対して報酬を与える。
DeepRacer:ラジコンカー。そこに搭載する学習モデルのシミュレーションなどを提供している。
ハンズオン「はじめての迷路学習」を提供している。
新しいことは失敗する。ただし、その経験を蓄積することで、良くなっていく。
10年間に何が変わるか?よりも、何が変わらないか?を考えたほうが良いことが多い。その実現方法を進化させていく。

## 今覚えておきたいWell Architected Framework(W-A)と便利なツール

パートナーソリューションアーキテクト
賢く・安全に使うために。ベストプラクティス集としてWell-Architected Frameworkがある。
クラウドネイティブとリフト&シフトの2つのアプローチがある。
2015年のre:Inventにて発表後、毎年アップデート。
10年以上のSAとお客さんのベストプラクティスを無料で使える。
記載されたホワイトペーパーと、支援するAWSのSAで構成される。
最近、日本語化や、(PDFから)Web化された。
Well-Architected Toolが日本語対応。(ただし、動画は英語)
あくまで「原則」
クラウドでの一般設計原則
質問・回答の形式で、ベストプラクティス。
ただし、全てに則っているのが必須ではなく、リスク・改善点を顕在化させることが目的。
要件検討や、設計・構築・運用の各場面で、AWS W-Aを活用できる。健康診断のように、定期的に確認するのがおすすめ。
Cyber Agentでは、カスタマイズしたものを利用している。AWS W-Aは、あくまでAWSの考え。
W-Aのレビューは、システムの関係者全員を呼ぶのがポイント。それぞれで、優先することが違っている場合がある。
レビューの進め方が重要。ホワイトペーパーでは、3ページも解説している。
・お菓子を用意する。
・監査ではない。
・複数回実施する必要がある。設計前と本番前など。
短くて3時間ぐらい。長いと8時間とか。
r5.xlargeのほうが、r3.xlargeより性能高く安かったりする。見直しが大事。
マネージドサービスの9割ぐらいは、お客さんの声から生まれている。
GuardDutyなど、セキュリティ対策サービスなども登場してきている。
Systems Manager:サーバ群を管理するツールセット

Demo
EC2 -> SSM Inventoryに集約し、S3 -> Athena -> Quick Sightで可視化
Amazon Linuxであれば、Systems Managerにつながっている。(他のOSなどは、Agentのインストールが必要)
インストールされているソフトウェア・バージョンなどが一覧で出てくる。
Systems ManagerからSSHできる。踏み台が不要かつ、SSHのポートも開けなくてよい。
古くからAWSアカウントを持っている場合に、権限が足りなくてQuick Sightが上手く作れなかったりする。

## AWSでAlexaスキル開発をスケール&ブーストする

Alexaスキルを作るのは、ほぼLambdaの関数を作ること。
ASK CLIというものが提供されており、標準の環境がかんたんに作れる。
構成管理はしてくれない。Nodeのバージョンが変わったりは手動で対応する必要がある。
CloudFormationが使えるASK CLIも作成中。現時点では、がっつり作りたい場合は別管理したほうが良さそう。
CodeStarを使うと、プロジェクトの作成がかんたんに行える。
S3をデータベースにする選択肢もある。DynamoDbより、従量課金がゆるやか。
クエリしないデータは、DynamoDBよりS3のほうが管理が楽。
adapterを差し替えれば、DynamoDBからS3に変えられる。
コールドスタート問題。VUIだと、ローディング表示もできず、ユーザが不安になりやすい。
serverless-warmup-pluginなどでウォームアップや、Lambdaではなく常時稼働(EC2など)に置き換えるなど。
Pollyは機能限定で、無料で使える。(自分で組み込まなくても良い)
AlexaはOAuth2でアカウントリンクできる。Congito User PoolsはOAuth2に対応している。
Amplifyを経由して、mobileアプリなどとも連携できる。
Alexaスキルを作成すると、$100クレジットがもらえる。

## 海外リモートワークとAWS運用

5年くらい前から、台湾と日本を行き来している。
1年で2回、1ヶ月程度が台湾。
そもそも、AWSのリモートを扱う場合、すべて手元にないもの。
そのため、国内にいても、海外にいても大差ない。

顧客・案件ごとにAWSアカウントを分離。
構成管理はCloudFormation。YAMLで書いて、GitHubで管理。
CloudFormation / Roadworkerの2つで管理。

オペレーションとしては、SSMを利用。
作業用の環境として、WorkSpacesを利用している。Office事務用など。

基本的には、SystemsManager経由でSSH。

リモートで気をつけていること。
・"システム"を止めないこと。冗長構成だったり。
・電話連絡がつくように。つかない時間は、予め連絡。
・リモート機関にできない仕事を残さないように、スケジューリング
突発の場合
・社内でプロキシしてくれる人
・ビデオコールでのサポート
・サポートし会える環境・関係性を作っておく
・最悪、帰国する覚悟

海外での通信環境
・LTEのみ。30日無制限で4,000円ぐらい。
・スマホ3台体制。日本のSIM端末も持ち、SMSでの2段階認証など。
 着信を確認し、050 plusで折り返す。通話料の問題など。

## AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル出身。
兄と会社を立ち上げた。医療関係者向けのサービスを提供している。

在庫管理システムを作り、Xamarinでのアプリ、API/SDKを作りプラットフォーム化、AIで需要予測などと広げていっている。
父のシステムのノウハウを継承している。

薬局のインフラを整えていきたい。-> 在庫管理システムをプラットフォーム化。
本当のところは、自分たちの開発工数・管理工数を下げたい。セットアップを簡単にしたい。というのが本音。

## AWS運用の事例紹介

受託のアプリケーション開発がメインの事業。
開発は、2〜6ヶ月程度が一般的。
EC2とRDSとS3のみを利用することが多い。
Management Console、CloudWatch Backupを、リリース後の運用で利用する。

## 多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション

## 拡張して使う Serverless & Amplify

20年ぐらいやってるサービスをリニューアルしたい。既存の開発会社に不満があり、スイッチ。
リニューアル内容が固まっていない。現行の基本機能は必須。iOS/Android両方。
-> 動くものを早く作る必要があった。
バックエンドに、一部オンプレ環境があった。
そのまま移行すると、インフラの管理などに大きな工数がかかってしまう。 -> サーバレス
スマホ側は、Obj-CとJavaだった。それぞれ作る期間・経験値が無かった。
Node.js / React Nativeの組で作ることに。TypeScriptが共通。
serverless frameworkを利用することに。ローカルで実行でき、YAML+コマンドでデプロイできる。
serverless-offlineというプラグインで、ローカル実行できる。
オンプレとの接続に固定IPが必要 -> serverless-vpc-plugin
CloudFormation templateが200で制限されている。1APIで複数のCloud Formationリソースが作られる。 -> serverless-plugin-split-stacks
構成を再構築したい。EIPが変わってしまう。 -> serverless-plugin-additional-stacks -> vpc-pluginが不要に
VPCに入れたLambdaは、コールドスタートに10秒程度。 -> serverless-plugin-warmup
開発環境だけ欲しいリソース。 -> serverless-plugin-ifelse
こんな感じで、現在ではいろいろなpluginが入っている。探せばだいたいある。最終手段は、CloudFormationテンプレートを書く。

AWS Amplifyの拡張性
CLI + Cloud Services + Framework + Developer Tools
今回は、CLIとバックエンドが中心。
amplify <category> addなどを実行すると、CloudFormation templateが作成される。pushすると、適用される。
categoryとして存在しないもの、カスタマイズが必要になるものも出てくる。
・既存カテゴリーのテンプレートを編集
・カスタムCloudFormationスタックの追加
・プラグイン(最もパワフル)
例:クライアントからS3へアップロード。CloudFrontの署名付きURLを発行して任意のユーザに共有。
スタックを追加することで対応した。
1. CloudFormationテンプレートを追加する
2. amplify/backend/backend-config.jsonを編集する
3. コマンドを実行し、CLIに認識させる
backend-config.jsonに書くことで、他のリソースのARNなどを引き継ぐことができる。
プラグインには4つのタイプがある。category / provider / frontend / util。category / utilあたりをよくつくる。
pluginを作るコマンドがある。
プラグイン実装に関する情報は、まだ少ない。amplify-cliのソースが一番参考になる。
amplify-helpers配下には、便利な定義がいろいろ入っている。
最初はカスタムスタック作って、2, 3度必要になったタイミングでプラグイン化するのが良さそう。

## クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

2018年の内容をアップデートしたもの。
情シスとして使っているAWSの話。
6年で、40人から370人になった。

独自の請求システムを使っていた。
営業と営業事務のやりとりなどで、てんやわんや。
-> IT推進室を結成して、関係者を消臭。(社長直轄の"推進室"とすることで、立場を明確に)
Salesforce -> 請求データ作成 -> マネーフォワード請求
見積システム・請求システム・個別のスプレッドシートなど、それぞれのパートで作成していた。
AWSから請求を吸い上げるサービスがあり、それをSalesforceに投入、そこからマネーフォワードに連携。
3年前は600通だった請求書が、現在では3200通になっており、昔の仕組みだったらかなり無理があった。
Lambdaを使っているが、そこは月4000円ぐらいで動いている。

次に、ユーザー管理に手を付けた。
各種サービスを利用していたが、人によってはパスワード使いまわしや、ポリシーを強制できなかったり。
ID基盤をActive Directoryに集約。SSOやLDAP導入。1Password Teamsを全社導入。
Slackだけは、連絡がとれなくなってしまうので、別管理としている。
ID無効化を集中管理できる。
パスワード定期変更運用を廃止できた。<-ISMS認証とかで突っ込まれても、上記の対応のほうが強いと回答できる。

リモートワーク
AWS上に、Sophos UTM設置。MarketPlaceにある。
本社に、SOCKS4プロキシーを設置。これで、本社のIPから出ていける。(DirectConnectを利用)
AWSをハブに、全拠点と通信可能。

労務周り
給与明細を手渡し・郵送、経費精算はExcelを印刷・押印だった。
SmartHR・マネーフォワードを導入

1 - 3 - 5 目指す人数・規模よりも大きなものを対応できる状況を。
誓約より制約。やってはいけないことは、出来ないようにする。
システム導入にあたって、机上比較より、トライアル。自社運用。業務の方を合わせる。
帳票のデザインなど、細かな部分は自社で構築・運用。コアな部分(Salesforceの処理部分)は、専門家に任せる。

富山Ruby会議01に運営の一人として参加しました

toyamarb.github.io

11/3(日)、三連休の真ん中に富山Ruby会議01が開催されました。

富山では(北陸でも)初のRegional RubyKaigiということで、Toyama.rbにほぼ毎回参加している私も、運営の一人として参加しました。
(運営とは言っても、細かな落ち穂拾いと当日の写真撮影ぐらいで、そこまで役に立てなかったかもですが。。。)

参加人数について

1週間前ぐらいになっても、思ったほどに人が集まらず、結構不安がありました。
懇親会も、お店からは「貸し切りのためには30人以上でお願いします」と言われており、「足りなかったらどうしよう。。?」と思ってました。

そもそも、富山で "Ruby" を主題にした大規模なカンファレンスをやって、どの程度来てくれるんだろう?という不安がずっとありました。

ただ、数日前になると続々と申し込みが増えて、椅子足りたっけ。。?ぐらいとなりました。
結果としては、本編60人オーバー(+16人の発表者)、懇親会も当日追加を含めて38名(だったかな?)ぐらいの大盛況となりました。

本編

本編の最中は、写真撮影をしていたので、真剣に聞けなかった場面も多々ありましたが、覚えてる限り・スライド見直しながらで感想などを書いていきます。(敬称略)

招待講演「○○からRubyへ」伊藤 淳一

○○からRubyへ / #toyamark - Speaker Deck

○○からRubyへ・Ruby事始めコーディング動画 #toyamark - YouTube

型がない(語弊あり)言語でも、ある言語でも、結局は動作確認するし、テスト・レビューするよね。そんなに変わらなくね?とのこと。
たしかに、ある程度チームのスキルレベルが高ければ確かにと思う反面、それが不安定な状況では、型の安心感はあるなーと思います。

そのためにスキルアップし、良いコードを書いていく必要があるよね。ということで、"良い"の一つである"読みやすいコード"の話(次のセッション)に続く。

他にも、経験者が語るRubyの利点などが多く、今後比較が必要な場面では見返したら良さそうなスライドでした。

「読みやすいコードとRubyらしいコード」黒曜

読みやすいコードとRubyらしいコード

個人的にも、いつも気にしている"読みやすいコード"について、リーダブルコードからエッセンスを抽出した感じ。
また、そこに"Rubyらしい"を付け加え、Rubyにおける"読みやすいコード"についての考察。

名前の付け方や処理の書き方など、自分でも気をつけつつ、教育もできるようになっていかないとなーと思いました。

「初心者PHPerがRubyキメて思うこと」oratake

初心者PHPerがRuby(+Rails)キメて思うこと - Speaker Deck

初心者に近い視点から、どのようにしてWeb系企業を目指し、学習していったかというお話。
個人的には、だいぶ昔に通った道、、感がありましたが、今ではRailsチュートリアルが整備されていたり、各種いろんな動画教材があったりと、便利な時代になりましたね。
ただ、情報がありすぎて、その取捨選択するスキル・良い情報にたどり着くためのスキル、などが必要になるのかなーと。
そのために、コミュニティに参加するのは良いですね。

「Crawler on Rails」suginoy

GitPitch Slide Deck

お昼を挟んでクローラーを作るお話。
サーバと逆の動作だからRailsを使えるのでは?って発想が面白かったし、実際に意外と使える部品が多いのも面白かったです。
個人での開発だと、それに合わせた選択が必要だよなーというのは共感しました。
外部サービスに依存してるアプリケーションでも、外部サービス側の動作が想定外だったり、急に変わったりするので、どこまで厳密にチェックすべきか?というのは考えないといけないよなーと思いました。

「TracePointから学ぶRubyVM」joker1007

TracePointから学ぶRubyVM - Speaker Deck

ガチ枠。
写真撮りながらというのもあったけど、おそらく半分も理解できてない気がします。
(そもそも、TracePointとは?ってのが、いまいち理解できてない気がする。)
わからないなりに、「プログラムもプログラムで動いている」ということが改めて実感できた気がします。
また、これだけ強い人でもコードから変数名の意味は推測するしかないということだったので、コメントだったり略さないことだったりは大事だなーと思いました。

「北陸で Ruby なお仕事に携わるための3つの戦略」清原 智和

北陸で Ruby なお仕事に携わるための3つの戦略 - Speaker Deck

エモい話枠。
特に地方だと、自分のやりたい仕事をやりたければ、いろいろ越境しないと難しいよね、という話。
実際に経験したことがベースの話だったので、かなり納得感のある話だった。
とはいえ、自分にここまでできるのか?という気持ちも大きいので、今の会社を辞めたとしても、リモートできる企業を探そう、、、というきもちになりました。

「業務で!Rubyを!キメる!」伊藤 浩一

Project automation for internal affairs - Speaker Deck

ちょっとしたツール(ワンショットのツール)であれば、比較的自由に技術選定しやすく、やりたいことをやりやすいという話。
個人的には静的解析とかにちょっと興味があり、RuboCopの話に興味があったけど、想定外の使い方で面白かったです。
ASTってちゃんと見たことなかったんですが、説明を聞いているとなんとなーく読めそうな気はしてきました。

「mrubyでハローワールド!」羽角 均

mruby de Hello World! - HASUMI Hitoshi - Rabbit Slide Show

弊社からのスピーカースポンサーということで、mrubyの話。
mrubyとかmruby/cが別ということは知っていたけど、ROMやRAMの使用量も違っているとのこと。
その分制約も違うので、使う場所にあわせて考える必要がありそう。
そこから、コンパイラを作る話になったけど、わかるようなわからんような。。。
ただ、順々に説明されることで、なんとなくの流れはわかったような気がしました。

LT1: muryoimpl

RSpec導入奮戦記/The struggle of introducing RSpec - Speaker Deck

Rspecでのテストコードを、短期集中で増やしていく話。
テストを広めていくための方法や、その際に気をつけたことが紹介されていました。
自分もテストを書いて、広めていかないとなーと思っているので、参考になりました。

LT2: ふぁらお加藤

俺 と Ruby - Speaker Deck

個人事業主として、なぜRubyを選択するのか?という話。
Rubyで仕事してる人は、比較的こだわりの強い人が多く、ハズレが少ない印象とのこと。
個人的には、Ruby書いている人たちは、そういう層と、"Railsでしか書けない層"に大きく二分されると思ってるので、そこだけ見分けられれば、いい感じの人と仕事できそうというのは納得。

LT3: 相生ゆら

元富山県民から見たRubyコミュニティ - Speaker Deck

富山弁枠。かつ初心者枠。
実務経験4ヶ月で、この規模の会場でLTしたのはいい経験だろうなーと思いました。
パーフェクトRuby読んで、アルゴリズムの問題をゲーム感覚で解き、Railsチュートリアルをサクサク進められるって、かなり優秀なのでは。。?と思いました。

LT4: wtnabe

join-kanazawarb-or-7years-passed-since-it-was-borned - Speaker Deck

地方勉強会の歴史の話など。
Kanazawa.rbは7年継続しているとのこと。すばらしい。
地方で"Ruby"で完全に縛ったコミュニティ・勉強会を開いてもつらいのは、全力で同意。(そもそも、自分もそんなにRubyを書かない)
最近行けてなかったのですが、Kanazawa.rbも久々に参加したくなりました。

LT5: Yuka Kato

(スライドは公開されてなさそう?)

Capybaraの裏側の話。あと、Capybaraのかんたんなおさらい。
BrowserとDriverにいろいろ種類があって、用途によって選ばないとなーと思いました。
PhantomJSがメンテ終了してたのは聞いたことあった気がしますが、それに引きづられる形でDriverも世代交代してる?
次に使うことがあったら、Apparitionはちょっと調べてみようと思いました。

LT6: 水尻裕人

RUBYでアッカーマン関数の計算をがんばる方法 / How to write ackermann function in ruby - Speaker Deck

アッカーマン関数って、聞いたことあるようなないような、、ぐらいでしたが、たしかにまともに計算できなさそう。
再起って、アプリケーション開発ではあんまり使うことがないけど、いざ使うとなるとテクニックが必要になるので、覚えておいて損はなさそう。
最適化オプションつけてみたけどだめでした -> Ruby自体のコンパイル時に指定が必要だよ(うろ覚え)的なツッコミがすぐに入るあたり、すごく強い人達を呼べたんだなーと再認識しました。

LT7: よしだ たけひこ

RubyによるC言語コードのメトリクス測定

組み込みエンジニアが、本業のすぐ隣の開発(調査)ツールとして、Rubyを使う話。
小さなプログラムをかんたんに動かせて、正規表現がさくっと使えて、外部のライブラリもかんたんに導入できるということで、ちょっとした調査ツールには確かに良さそうですね。
で、厳密なツールを作るのは難しいものでも、用途に合わせて、人力の補助ツールとして作るのは良さそうですね。

LT8: 羽角 均

(スライドなし)

2度目の登場。
先程の発表で入ってなかった、Generate Codeの部分のライブコーディング?
vimでライブでバイナリ列を書いていくという荒業に出て、なんとなくやりたいことはわかったけど、途中のハプニングで完成できずに終了でした。
なんとなく、バイナリ列がどうなっているか?が、わかったような、わからんかったような。

招待講演「型なし言語のための型」松本 宗太郎

型なし言語のための型 - Speaker Deck

最後に今後のRubyの話。
Ruby3で型を入れようとしていることは知っていたけど、パフォーマンスが目的ではないというのは知らなかった。
型関連の歴史についても全然気にしたことがなかったので、型推論が思ってたよりも昔からあったことには驚きました。
最初の招待講演で好きなメソッドとして挙げていた map が、最後の招待講演で邪魔者扱い(語弊)されていたのが面白かったですね。
Union typesやflow-sensitive typingなど、"型なし言語のための型"として必要な要素を徐々に理解できました。
TypeScriptの成功は、たしかに特異なことだったんだと、なんとなく理解できました。
「人類は型を書く」ってのは確かに面白いと思いました。型を書かなくて済んでいたJavaScript界隈で、これだけTypeScriptが流行っているのが面白いなと。
TypeScriptは、センスよく型を解決しているんだなーと感じました。
型なし言語に型を導入するという意味で、 incompatibleという指定の必要性は理解できるけど、もともと型のあるJavaから入った自分としてはなんだかなーという思いもあったりします。

全体の感想

懇親会でも話に上がりましたが、発表の順番が絶妙だったと思います。

別言語からRubyに入った話・Rubyの良さの話

Rubyらしいコードの話

初心者がRubyに抱いた感想
という比較的初心者向けのセッションを午前中に聞いて、
Rubyでちょっと変わったアプリケーションを作る話

RubyVMの話で深淵をちょっと見せて

頭使ったところで、北陸(地方)特有のエモい話

エモい話入れつつ、ちょっとASTの話

mrubyをベースに、言語の作り方の話

LTでちょっと閑話休題

型のがっつりした話

という感じで、緩急つけつつ、前に聞いたことがちょっとずつ関連する流れでした。

毎年やるのは運営的にきついですが、数年後にはまたやれたらいいなと思いました。
まずは、Toyama.rbに継続的に参加しつつ、集客など手伝えることは手伝っていきたいと思います。

Algolia 勉強会 in 金沢に参加してきた

最近はバタバタしてて参加してなかったkanazawa.rbさん中心で、
全然行けていないJAWS-UG 金沢さんの協力と、
DMM GAMESさんの会場で、
Algoliaという検索サービスの勉強会に参加してきました。

connpass.com

数週間前に、「Firestoreのデータに対して全文検索的なことをしたい場合はどうすれば。。。?」と悩んで、

全文検索  |  Firebase

にたどり着いていたので、タイムリーな勉強会でした。

Algolia のご紹介

www.slideshare.net

日本にいる唯一のAlgolia社員である篠原さんの発表。

Algoliaは世界中でいろんなところで使われており、日本でも100社以上が実際に利用しているとのこと。
→ 実績があるので、安心感がある。

フランス発だけど、最初から世界展開をめざして、ドキュメントも英語だし、社内も英語。
→ すげぇ。どこぞの会社とは違う。

検索のコアな部分はAWSなどのクラウド環境ではなく、自分たちで物理インフラの調達もしてるっぽい?
それによって、物理レイヤまで含めた、突き詰めた高速化をしているらしい。
→ 懇親会でも聞いたが、速度へのこだわりはかなり強いらしい。たしかに、デモなどでも信じられないレベルで高速。

社内でも自分たちのサービスを利用して、社内ドキュメントの検索エンジンを作成することで、各人の作業効率が上がったらしい。
→ よさげ。自社でもやりたい。インクリメンタルに高速に結果が出るのは、ちょっと体験が変わる。

検索では、TF-IDFに重みづけなどのチューニングすることで適合性を上げる=良い検索結果を出すようにすることが一般的?なところだが、職人芸な部分が出てくる。
Algoliaでは、Tie-breaking Algorithmを利用し、チューニングをやりやすくしている。(また、高速なレスポンスにも寄与しているっぽい)
→ サービスごとに「良い検索結果」は変わると思うので、難しい部分ではありそう。ただ、その試行錯誤がやりやすそうなのは良い。

Algoliaはダッシュボードも充実しており、結果0件だったクエリや、ユーザの選択が検索結果の何番目だったかなどを追える。
特定のキーワードに対して一番上に表示させたりもできる。特定のキーワードを、別の条件式に変えることもできる。
→ 実際のユーザの行動からチューニングへフィードバックしやすそう。

Algolia ハンズオン

www.slideshare.net

AlgoliaのInstantSearch.jsを利用して、step by stepでwidgetを追加していく。

とりにかく、「こんなにかんたんに、検索周りのUIを実装できる!」というのがよくわかるハンズオンでした。

いい感じにstepを踏んでもらっていたし、答えも用意されている状況だったので、並行して自分で作成したアカウントでもやってみました。
ただ、 refinementList widgetなどがエラーになったままなのは謎のまま。。。(プランに依存したりするのだろうか。。?)

にしても、価格.comみたいな、カテゴリとか価格とかいろんな軸での検索をかんたんに作れるのはすごかった。

Algolia 利用事例紹介

speakerdeck.com

クラウドファンディングプラットフォームであるCAMPFIREでの具体的な事例。
実際に使っていった中で、良かったところや難しかったところが聞けたのは良かった。

クラウドファンディングの特徴として、文章部分に熱い想いが入って文章が長くなりがち。
エンドユーザからも、複数キーワードからあいまいにマッチした結果を求められる。
→ 通常のショッピングサイトとは、求められるものが違いそうで、難しそう。

使ってみて、実際にレスポンスが爆速だった。
また、ドキュメントは充実しており、SDKもオープンになっているので迷いづらい。
monitoring、analyticsが優秀。
→ 検索性能の向上とかは難しそうだけど、consoleが充実してて試行がやりやすそう。

レコードごとのサイズ制限や、ソートは難しい。
→万人向けではなさそう。ただし、ハマる場面は多そう。

開発者ごとのdevやstgなど、環境ごとの切り分けを考える必要がある。
dev環境を共用してたりすると、誰かの開発によって不正データが発生し、開発が止まったり。
→このあたり、ローカルシミュレータがほしい気がしました。

超高速リアルタイム検索APIをたぶん支えているAWS

speakerdeck.com

https://techracho.bpsinc.jp/hachi8833/2018_06_20/57589 をもとに、AWSの構成紹介と、それぞれの要素の最近のリリース。
Algoliaの管理側インターフェースは、AWSの鉄板構成らしい。(ただし、資料時点からはいろいろアップデートされてる。。?)

AWSのアイコンが一新されてた、ってのが一番の衝撃的アップデート。

EC2で24TBメモリインスタンスとか、C5nインスタンスが増えた。
→24TBメモリインスタンスとか、誰が使うんだろう。。。

ELBは、L7的な動きをするALBも出てきたし、Lambdaをバックエンドにもできる。
→EC2インスタンス立てて、フルスタックなフレームワークをやらないって選択肢もありそう。

RDSにサーバレスモードもできた。
→利用頻度の低いアプリとかは良さげ。

AWS Well-Architectedを読もう。
それをベースに、要件に合わせてカスタマイズしよう。
ただし、「本当に外れる意味があるのか?」は問い続けよう。
→ベース知識は大事。作るサービスごとに特性が違うから、それに合わせてカスタマイズする。しない選択肢もある。

以下、メモそのまま

## Algolia のご紹介

日本のAlgolia社員は現在1名のみ。
元AWSの社員。
アルで利用されている。
https://speakerdeck.com/vexus2/alu-algolia いい感じの資料らしい。
世界で7000社以上に利用されている。
日本にも、東京と大阪にデータセンターがある。
東京にもオフィスが解説される。
日本でも、100社以上が利用している。
KARTEのサポートサイトなどでも利用されている。
shopifyやzendeskのオプションとしても利用され始めている。
Twitchでのインクリメンタル検索などでも利用されている。
Algoliaは、最初から世界展開をめざし、フランス発だけど最初から英語メイン。

すばやく構築、高速な検索。
開発者の使いやすさ以外にも、ビジネスの人やエンドユーザーの使いやすさも求めている。
HTTPでリクエストして、JSONで返却される、というのがメイン。
99.999%以上のSLA。高速なレスポンス。
インフラのぶっちゃけ話が、ブログになっている。
Railsからalgoliaを使うための翻訳記事もある。
最近、Azure上でも動くようになった。
Algoliaは、基本的にメモリに情報を載せている。ベアメタルサーバでは対応できないレベルのデータ量の利用も出てきた。

社内での、いろんな情報をインデックスさせてみたら、社員それぞれが10分ぐらい時間を節約できたのでは?という状態に。

件数が少なく、更新頻度が低いのであれば、JSONファイル+grepでも良い。
ある程度までは、RDBMSのlike検査でも対応できる。
全文検索エンジンを入れようとすると、運用経験が必要。

検索自体は難しい技術じゃない。
転置インデックスを作成する。
データがでかくなってくると、管理するのが難しくなってくる。
"適合性"、良い検索とは?
TF-IDF
特定のフィールドをブーストしようとすると、勘の部分が多くなってくる。
日本語の区切りは難しい。
Algoliaは、自然言語処理に充填をおいているわけではない。
Tie-breaking Algorithm
typo検索について、日本語もできるようになった。
geo検索できる。
ランキング方式をWeb上で変更することができる。

dashboardも充実している。
結果0件だった率など。
クリックされたのが、何番目の検索結果だったのか?など。
特定のキーワードに対して、一番上に出したいものを指定できる。
"安い"というキーワードに対して、"$20以下"に置き換えることができる。

## Algolia 利用事例紹介

CAMPFIREでの事例
月間200万アクティブユーザ
23,000プロジェクトぐらいがある。

文章については、1,000,000文字を超えることもある。
複数キーワードでのあいまい検索。
→自前でやろうとすると、コストが高い。 →Algoliaを導入。

本当に爆速。
想定以上にSDKとドキュメントが充実。
想定以上に、monitoring、analyticsが便利。

index size limitとjson frameとSDK
リミットが10KB。登録データをトリミングしたり。
POSTするJSON frame全体で10KB

ソートとreplicaとrecord limit
複数のソート種別を実現しようとすると、replicaを用意する必要がある。
レコード数が倍で増えてくる

deploymentとtestとqa
環境ごとに、どのように切り分けるか。
手元でのテストをするために、indexを切り分けるか?
他の人が作った不正なデータで壊れる。


## 超高速リアルタイム検索APIをたぶん支えているAWS

メモ取るの忘れて聞いてたので、スライド見直しながらメモとりなおし。

https://techracho.bpsinc.jp/hachi8833/2018_06_20/57589 をもとに、AWSの構成紹介と、それぞれの要素の最近のリリース。

管理インターフェースは、AWSの鉄板構成で作られてるっぽい。(ただし、記事から更新されているものもあるという噂)

AWSのアイコンが一新されたらしい。

EC2
18TBと24TBメモリのインスタンスが追加される予定。
C5nインスタンスという、通信速度関連に特化したインスタンスが追加された。

ELB
L7的な動きをするALB。
ACMでhttpsの証明書を設定できる。
Lambdaの実行もできる。(EC2インスタンスがなくても、独自処理を実行できる)

RDS
サーバレスモードもできた。
ただし、寝た後の一発目は遅いらしい。

AWS Well-Architectedを読もう。
それをベースに、要件に合わせてカスタマイズしよう。
ただし、「本当に外れる意味があるのか?」は問い続けよう。

おまけ

車で行ったので飲めなかった日本酒

過去の経験を生かして、控えめな量のピザ(どうせ二次会?行くので)

金沢 - 富山間の2時間弱の運転後の、深夜のギルティ。

BuriKaigi2019に参加してきた

今年も BuriKaigi がありました。

toyama-eng.connpass.com

私は、Java側のセッションを聞きました。

下にそれぞれのセッションの個人メモを貼ってますが、印象に残ったところとして、

  • JDKの有償ライセンスは思ったより安い?
  • 当たり前だけど、Kubernetesが向かないプロジェクトもある。
  • Kubernetesの要素って、なんであんなにジェネリックな名前なんだろ。。?
  • Loomはまだまだ?使えなさそうだけど、これが出て、ライブラリもアップデートされたら勝手に性能が上がりそう。
  • スレッドとかロックとか、知らない・覚えてないことがいっぱい。。。
  • GraalVMはいろいろヤバそう。(いい意味で)
  • RESTのゆるふわさをどうにかするために、ODataとかOpenAPIとかGraphQLが出てきたと考えれば、理解しやすい感じ。
  • ODataは初めて聞いたけど、表形式のデータを提供するためには、考えることが減らせそう?(APIパラメータとか)

って感じでした。

懇親会やその後の2次会、次の日の朝など、いつもは話せない人たちだったり、観測範囲の違う人たち(.NET側)と話せてよかったです。

Oracle Code One 2018 の概要 と JDKライセンスモデルの変更(最新版)

https://www.slideshare.net/itakashi/jdk-burikaigi-2019

Oracle Code One 2018

Java One から、 Code One になった。

JDK

JDK 11 ドキュメントの日本語版が公開。 (英語以外では、日本語のみ)

1/15のアップデートで、Java8の最終アップデート。 次からは、新しいライセンスになる?

去年、世界中でやったアンケートで、8割ぐらいJava 8。 LTSで行こうと思ってる人が3割ぐらい。 都度考えようと思ってる人も3割ぐらい。 Open JDKを使っていく人は8%。少なめ。

今までのリリース Open JDKのコミュニティが、コード公開までしてる。バイナリは作ってない。 JavaFXとかを追加して、Oracleがバイナリとして提供。BCL(企業内でのコピーなどはできる。)ライセンス。

いままでのアップデートリリース Oracleがアップデートリリースを開発。年4回。 セキュリティやバグフィックス、たまに機能追加もあった。 Open JDKのアップデートリリースは、同期されてなかった。

JDK11以降のリリース Open JDKがコードを作るのは変わりなし。 Oracle Open JDKとして、オラクルが無償提供。6ヶ月ごとに出てくる。(オラクルによるアップデートのリリース) Oracle JDKは有償。商用ライセンス or OTNLA for Oracle Java SE。バージョン固定のニーズに特化。開発・テスト・試作・デモ用途には無償。

Oracleでは、リポジトリが2つある。OpenJDKとOracle JDKOracle JDKの方は、11, 17などのタイミングで、ブランチが切られ、個別にアップデートされていく。

メジャーバージョンアップは3月と9月。 アップデートは1, 4, 7, 10月。

リリース情報は、今までどおりOpenJDKのサイトで確認できる。 Deprecatedになったら、最短1年で削除される可能性がある。Release Notesを確認する。 for removable = trueになったら、ほんとに1年で消える。

Java8の無償サポートは続くが、今のところはNon-corporateのみの制限になっている。 有償サポートであれば、25年3月まで伸ばせる。 Java6を使ってるのは、いいかげんまずい。 有償サポートの契約では、バージョンの固定が無い。8のサポートだけ欲しくても、11とかも利用できる。

1プロセッサで年間36,000円。 プロセッサの数え方は、チップベンダーなどにも依存する。

Oracle Code One 2018 Java関連のフィードバック

(スライドは見当たらず)

一昨年まではJava Oneだったので、Javaだけだった。 Oracle Code Oneになって、Java以外もある。(とはいえ、Javaがメイン)

セッションのスライドや動画は、公開されている。 ハンズオン資料も公開されている。

OracleJava関連のいろいろなものをオープン化していく。

Javaでコンテナやるってのは向いている。 管理ツールなども、いままでのものが使いやすい。 ただし、ランタイムが大きい。普通にやると、500Mのイメージとかになる。 Jigsawとかでうまくできると、100Mを切れる場合がある。 slimというイメージを使うと、ベースイメージの容量を減らせる。 Alpine linuxにポートするのがProject Portola。(12に入る?)

Java on Kubernetes 全部デモ

(スライド無し)

Podは、いくつかのコンテナをまとめたもの。

IstioというProxyサーバ?を置くことで、DI/AOP的にできる。

Podの冗長構成をするために、"Deployment"という仕組みがある。 アプリのローリングアップデートとかも仕組み化されている。 サービスの死活監視とかもしてくれる。(ちゃんと書けば)

Deploymentを管理するためには、yamlで書く必要がある。

kubectlで、コンテナに対してport forwardしたり、コマンドを実行できたり。 /bin/sh を実行させることで、ログインすることもできる。

Deploymentで管理されているものは、基本的にprivate IPしかふられていない。(外部からアクセスできない) "Service"(Load balancer的なもの)を定義することで、外部からアクセスできる。(ただし、基本的にはprivate ID) typeを変えることで、パブリックにできる。(ただし、あんまり使わない)

Ingressを経由するのが、正しい外部公開の仕方。

https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure から勉強するのがよい。3章が特に重要。

kubeは、万能ではない。 マイクロサービスとか、新機能をどんどん追加していくとかは向く。 長く安定的に動かす基幹システムとかは、あまり向かない。(学習コストの方が高くつく)

Project Loom - 軽量スレッドと限定継続

https://speakerdeck.com/skrb/project-loom-qing-liang-suretudotoxian-ding-ji-sok

Loom自体はまだ固まってない。

Thread 糸 Fiber 繊維 Loom 織機

並列・並行は難しい。そもそも、それぞれの単語が難しい。 スレッドセーフでもスケールしない。 CPUが遊んでる。使い切れない。ロックがとれないとか、IOのウェイトとか。 待ち状態になったら、スイッチするべき。

wait - notifyAllのペアで使う。 java.util.concurrent では、そのあたりをうまく実行してくれている。

Context switchは遅い・重い。中断するだけで、大量のメモリを必要とする。 ->OSによらず、JVMが管理するスレッドが必要 => Fiberの導入。

中断/再開の仕組み -> (限定)継続と言っていいのでは? Fiber = Continuation + Scheduling(ForkJoinPoolが使える)

java.lang.Continuation run / yield / Runnableでのタスク記述

計算処理だけであれば、Parallel streamとかを使えばいい。 IO待ちとかに、Fiberが使える。

java.lang.Fiber スレッドはそのままで、その上のタスクだけが切り替わる。 Runnable / Callableでタスク定義 schedule park / unpark(駐車するという意味)ただし、ユーザは使わない。 CompletableFutureに変換して、待ち合わせる。 たとえば、LockSupportがparkメソッドを利用している。 それ以外にも、Thread, java.util.concurrent, I/OのNetworkingやPipeが対応してる。(Fileは未実装)

制限 ネイティブスタック・モニタからはyeildできない wait/notifyAllではなく、ReentrantLockなどを利用したら使える。

Fiberは、おおよそThreadの代わりになる。 ThreadLocalやThread.currentThreadが使えない。

LinuxMacはサポートされてるけど、Windowsがまだ。

おれの書いたPHPがこんなに速いわけがない(PHP7.3比3倍)

(資料見当たらず)

GraalVM : Oracleが開発してるJVMをベースにした多言語環境 CE版と商用EEがある。(本番で使う段階ではなさそう。。?)

Graal と GraalVMは別物。

Graal Javaで書かれたJITコンパイラ 現状Client(C1)とServer(C2)があるが、C2部分を置き換えるもの。 C2は秘伝のタレ化(新機能の追加を出来る人がいない)してるので、それを置き換えたい。

Truffle AST処理エンジン 動的言語のためのLLVMと言える。

Sulong LLVM bitcode -> Truffle ASTに変換出来る SwiftはLLVMが改造されてる?ので動かない。

Polyglot Truffleをベースにした多言語環境 言語をまたがった最適化が可能。

Microsoft AzureではじめるJava開発

https://slides.com/hiroyuki_onaka/java-on-azure-burikaigi/#/

Azure x Javaの選択肢 AKS / Virtual Machines / App Service / Functions(まだプレビュー)

今回はApp Serviceの話。

warが動く。wildflyも動く。

App Serviceにも、WindowsLinux、コンテナのバリエーションがある。

特に理由がなければWindowsでいいが、最新のもの使いたければContainer。 windowsならfreeプランで試すことも出来る。

Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

https://www.slideshare.net/sugimomoto/java-api-rest-vs-graphql-vs-odata-vs-openapi-swagger

API management市場が2022年で3000億円規模になる予想。 (Apigeeとか。)

APIエコシステム」が重要性を増していく。 freeとかmoneyforwardがAPI提供したり。 提供者側の文脈が多いけど、利用者が必要。

RESTは原則が定義されているだけで、規約などは無い。 デシリアライズ先のクラス定義が面倒。 リクエストのパラメータなどは、ドキュメントを見る必要がある。

Swagger (OpenAPI) RESTをうまく記述するためのフレーム。 (主に)yamlで記述する。 Codeの生成や、モックの作成が出来る。

OData RESTの上にプロトコルを乗せたイメージ。 表形式のデータの取扱をしやすくした。(SQLのイメージに近い) 使えるURLパラメータが全て決まっている。 Metadata Endpointサポート。 サービスごとにAPIの仕様を学ぶ必要が無い(統一されている)

GraphQL Web API用のクエリ言語 1つの画面で複数のリソースの情報を表示する必要があるので、画面側でリクエストしたい情報を組み立てる必要が出てきた。

Toyama.rb #30 オフラインリアルタイムどう書く に参加しました

toyamarb.connpass.com

毎月恒例Toyama.rbに参加してきましたが、今回はいつもの「もくもく会」ではなく、「オフラインリアルタイムどう書く」でした。

やる前は、「制限時間付きの実装、何かのプロダクトになるわけじゃない実装、とかってあんまり好きじゃないんだよなー」とか実は思ってましたが、やってみたら想像以上に良かったです。

前日

Toyama.rbというRubyのコミュニティですが、利用する言語はRubyに限らないということだったので、直近で仕事で必要そうだけど実力が追いついてないSwiftでやろうと思いました。 また、ググって出てきたどう書くの問題を眺めて、「文字列を受け取って、文字列を出力、それが提示されている値と一致しているか」というフォーマットっぽかったので、assertのやり方を調べたり、いくつかのループのやりかた(Rangeを使ったり、forEachを使ったり)を調べておきました。

1問目

1問目は「フォークじゃない」 http://nabetani.sakura.ne.jp/hena/ord18notfork/ でした。 並んでいる状態をどうやって保持するか、"x"のお客をどうやって管理するか、といった部分で実装方法が別れていた印象です。

私は、実装速度・コードの簡潔さよりコードの読みやすさを優先して、ある程度オブジェクト指向的に書いていきました。 StoreクラスにRegiStateが5個あり、RegiStateにCustomer enumの配列を持ち、Customer enumでは normal | stop("x"の人)を表現しました。

1時間の制限時間だったのですが、「どのレジに並ばせるのか」の部分がうまく行かず、すべての人が最初のレジに並んでしまったまま制限時間を迎えてしまいました。 その当時の実装状況としては、 https://github.com/noboru-i/toyamarb30/blob/687815b5784bea04bb1fe0a41b7bcc3b67700500/ord18notfork.playground/Contents.swift です。

次の日、ちょっと修正したら、すべてのテストがパスしました。やっぱり、落ち着いて考えることは必要ですねー。。。

時間内に解けたのはkunitooさん1人だけで、Rubyで実装していました。 https://gist.github.com/kunitoo/624fcc785385c76168f6f1005183b954 min_by などを利用して、かなりスッキリしたコードで実装されている印象です。

みなさん、RubyJavaScriptC++Pythonなど、いろいろな言語で解いていました。 解く順番も、私みたいにオブジェクトの状態・操作を考えて一気に実装した人もいれば、TDD的に各メソッドの入出力をテスト書きながら進めた人、たくさんあるテストデータの中から簡単そうなものが通る実装を書きそれを育てていく、などいろんな人がいました。

2問目

2問目は「積み木の水槽」 http://nabetani.sakura.ne.jp/hena/ord13blocktup/ でした。 これもいくつかやり方があったようで、「下の段から走査していって、水が入る可能性のあるブロックを特定する」というものや、「列単位に、その左右の堰となるブロックの高さを求める」などがありました。

私は前者で、マス目を2次元配列と考え、マス目の状態を block | water | fall(0の列+そこに水が流れていってしまうマス) | undefined(まだ確定できていないマス) に分類し、undefinedで埋まっている状態から順に確定していくイメージで進めました。 手順としては、 ・入力文字列から block の位置を確定していく ・0の列を fall として、そこに水が落ちていくマス目も fall としていく ・まだ undefined の箇所について、隣接するマス目を確認しながら water を確定していく と考えました。 実装状況としては、 https://github.com/noboru-i/toyamarb30/blob/928b2f6fd4ee1d417350c0860d4b758e128a0c5f/ord13blocktup.playground/Contents.swift です。 問題の理解と考え方をまとめるのに時間がかかり、実装面でも2次元配列の扱い(どっちがx座標?など)に戸惑ってしまい、やはり1時間では解けませんでした。。。

ただ、mugi_unoさんの説明を聞いていると、3つ目の手順で undefined になっている部分は、すでに waterで確定っぽいですね。

これも制限時間内に1人だけ解け、しかも解いたのは学生、社会人は誰も解けずというちょっと不甲斐ない結果となりました。

これも次の日に修正しようと思ったのですが、列単位で水の量を計算できるというのを知ってしまったあとだと、今のやり方を進める気が起きず、とはいっても別のやり方を新規にやる気にもなれず。。。 やっぱり、オフラインで集まってやるからやる気になるんだなーと思いました。

感想など

実装・確認はXcodeのPlaygroundで実装を進めました。 リアルタイムで実行してくれるのは便利だったのですが、書きかけの状態でも動作してしまうためコンパイルエラーがじゃんじゃん表示されたり、Xcodeが急にクラッシュしたり、書き換えても実行結果が更新されなかったり、まだうまく使いこなすことができませんでした。。

個人的には、もうちょっと時間を使って、読みやすいコードにするとか、言語機能やライブラリをフルに使って短いコードで書くとかをやるのも面白いかなーと思いました。 (個人的に、時間に追われるのが苦手、というのが大きいですが。。。)

1時間やって、全員分の説明・レビューする流れは良かったです。 今までもくもく会で何をやっているかは知っていましたが、みんなが同じ時間に同じ問題を解くことで、それぞれがどういった考え方で実装を進めていくか、どんな言語をどの程度かけるのか、といったことがなんとなーく知れたのはよかったです。(特殊なケースではあるので、実際の仕事能力とは別の次元だとは思いますが)

個人的には「もくもく会」が好きなので、Toyama.rbはそれがベースだとうれしいなーと思いますが、定期的にこういったイベントがあるのはやっぱり楽しいですね。

新しい技術を取り入れるための実験のやり方 〜サーバーレス・機械学習・PWAを実戦に投入するまで〜 に参加しました

火曜日の夜、イベントに参加しました。

guildworks.doorkeeper.jp

と言っても、富山に住んでるので現地に行けるわけもないんですが、Zoomでの参加が可能だったので登録してみました。

久しぶりの平日夜の勉強会でした。

内容としては、ギルドワークスが1ヶ月4名ぐらいで、いろんな新規技術を詰め込んだ自社プロダクトWebアプリを作成、そのときの知見共有、といった感じ。

個人的には、「受託の実案件にどうやって新技術を突っ込むか」を聞きたかったのですが、話を解釈すると「実案件にいきなり突っ込むのは難しいから、先に小さめのアプリで一度やる」なのかなーと感じました。

個別の技術の話は、下のメモに書いたとおり。知ってること半分、知らなかった・再認識した話半分、という感じ。

運営に関しては、珍しいZoomでの配信ということでしたが、概ね良かったと思います。(上から目線。。。 マイクオンのまま入ってくる参加者がおり、最初だけはホスト側の対応が遅かった気がしますが、それ以降は快適に聞けました。 (弊社の全体会議も、これぐらい上手く進めばいいんですが。。。)

欲を言えば、スライド以外に会場の様子・スピーカーを映したカメラもあったら良かったかも?と思いました。

あと、ハッシュタグも決めてもらったほうが、Twitter上で盛り上がってよかったのでは?と思いました。 (Zoom配信に結構な人数いたので、そこも含めた一体感も出やすいかなーと。)

地方在住者はなかなか勉強会に参加できないので、こういったリアルタイムの配信が増えてくるといいなーと思います。(設備とか大変だろうけど。。 最近はYoutubeとかでアーカイブ配信も多いですが、「いつでも見れる」状態ってなかなか見ないんですよね。。。 そういった意味でも、リアルタイムで他の人も聞いている、という状況がいいなーと思います。

以下、メモ。

リスク
技術のリリーススケジュールに、デリバリーが引っ張られる。

漸進的な改善と根本的な転換
取り入れやすさを取るか、大きなリスクを取るか

ギルドワークスでは
GraphQLを一部利用、SPAを部分的に利用などしている。
React Nativeを全面採用しようとしたが、速度が出なかった。

やりたいこと=根本的な転換を、低リスクで実行
新規自社プロダクトのMVP開発を対象にする。

AWS Elastic Beanstalkを使ってる。
Spring/Spring security, Rails/deviseを使っている。

課題
ボイラープレートコードが多い。(データのCRUD/認証など。微妙に違う。)
フロント開発が3ターゲット分必要。

今回の挑戦
SaaSで外部に出す。Cognitoの利用。
大きなフレームワークから、Lambdaへ。
PWA(Ionic)

Lambdaを利用しようと思うと、SPA->API Gatewayや、DynamiDBが必要になってくる。

## Lambda + Java

LambdaでJavaを使う理由
言語として利用したことがある。リスク低減。
Lambdaでのサポートしては歴史が長い。安心感。

課題
DynamoDBの利用。RDBのように扱う。
AWSのデプロイなどは、AWS Toolkit for Eclipseを利用。とっつきやすかった。

DynamoDBの利用
DynamoDBMapperが標準である。入れ子のデータ構造などもサポートしてる。
JPAなどと同じように使える。

デプロイ
AWS SAM形式のテンプレートから、Eclipseでデプロイする。
BluePrintがいくつか用意されていて、ウィザードもある。
AWS Toolkit for Eclipseは、GUIでとっつきやすい。コマンドでの再現も出来る。

認証
Cognitoでクライアント認証。
API Gatewayでヘッダを見て弾く。
Java側では、認証チェックなどは行わない。

ステージング環境の構築
DynamoDBの扱いがアノテーションベースだったので、テーブル名の付替えが難しい。
別リージョンでステージング環境を構築した。ベストではないけど、ちゃんと動く。

Java+Lambdaの問題
起動が遅い。出来るだけコンパクトにしても10秒などかかる。
ポーリング?ローディングのタイミングを工夫?ユーザからのAPIはJavaを避ける?
Goで再実装中。

純粋なJavaになるので、テストコードは書きやすそう。ただ、今回はDynamoDBとのIn-Outだけなので書いていない。

1週間スプリントのスクラムで実施。大きな問題があれば、検知が出来たはず。(今回は、特に出なかった)

## Ionic

Angularをベースに、UIコンポーネントが充実。
cordobaと連携することで、アプリ化も出来る。
ドキュメントが丁寧。(インタラクティブなドキュメント)
CLIのサポートが充実。(Angularを踏襲)

標準テンプレートで作成すると、Service Worker設定済み。
ファイルキャッシュ、APIのキャッシュが簡単に設定できる。

Ionicを使う上でのポイント
CLIを出来るだけ使う。構成を保って、generateが出来る。
TypeScriptの型定義を利用する。ミスを防ぐ。

Ionic標準から外れるUIの作成は高コスト。
標準で使うのが良い。作る場合も、Web技術で作ってしまうほうが楽。Angularの資産も使える。

クライアントでのCognito認証
AWS Amplifyを利用することで、認証コードの作成が楽になる。

## 機械学習

導入の難しさ
データセット足りない。最低でも1k程度のデータが必要。
技術的ハードルの高さ。数式などが必要。

今回のスタンス
データセットが集まっている分野に絞る。Googleなどが学習済みのものなど。
画像認識・言語分析・音声認識
技術的ハードルについては、SaaSをフル活用する。

Google Natural Language APIを利用。日本語に強い。

都度実行すると高いので、バッチで叩いたほうが安い。

## トライしたこと

4人で1ヶ月。そこまで大きくない。
やったことないことを詰め込んでやっている。
リリース前提なので、実際のプロジェクトに向けた知見を得られた。

次の実験に向けて
MBaaSにチャレンジ。Google FireStore / AWS AppSync。
Ionicの他に、React/Vue.js や ReactNative/Nuxt。
機械学習もSaaSからPaaSへ。AWS SageMaker。

方針決定は、オフラインで集まってやった。2,3時間。
受託だったら、今回ほど大規模に新しいことはやらなかっただろう。ただ、今回の知見があるので、次以降で一部導入などは出来そう。
今回の開発で懸念も出てきたので、次の自社プロダクトで別の方針を試す。
Cognitoはかなり使えた。DynamoDBも、特定用途に限れば、かなり使える。積極的に使っていきたい。

Essential Phoneを買ったはなし

Android P がすごいらしい

というのを聞き、 下記サイトから使える端末を探しました。

Android P Beta Devices  |  Android Developers

Pixel たちは技適の問題があるし、 Sony Xperia XZ2 はまだ発売日が発表されていませんでした。

Essential Phone も良さそうだなーと思って調べたら、数週間前に日本への発送に対応したとのこと。 セールは逃しましたが、発表時よりも値段も下がっており、素の Android に近いとの話も見かけたので、買ってみることに。

探してみると、 Amazon でも並行輸入品が出品されてました。

ただ、"並行輸入品" ってのが微妙に怖かったのと、値段を見ると微妙に公式サイトの方が安かったので、 https://shop.essential.com/products/phone?variant=34714129089 の公式サイトから購入することにしました。 (このとき、送料のことを甘く見てました。。。)

で、色なんですが、誰かとかぶりたくないこともあり、 Stellar Gray にしました。この時点で +$100 です。

360 Camera も悩みましたが、買った当初は良いけど、すぐに使わなくなりそうなのに $199 するのは高いと思い、見送りました。

購入

結局買うのは本体だけになったので、 $599 と送料だから、7万ぐらいで収まるだろうと思ったら、送料は $79.33 とのこと。

https://pbs.twimg.com/media/Dc2PRUDV4AA-mUd.jpg:large

合計は $678.33 になり、最終的に引き落とされたのは ¥75,535 でした。。。

5/10 25:00 に購入しました。

受取まで

その朝6時ぐらいには tracking number が発行され、FedEx のサイトを見ると、5/14 18:00予定になってました。

土日挟んだので、体感的には長かったですね。。。

実際には 5/14 17:30 ぐらいに届いたので、3日と16.5時間で SAN JOSE から Toyama に着くんですね。

開けて使ってみた

かっこいい箱に、かっこいい充電器とともに入ってました。

Stellar Gray は背面がマットな質感で、あんまり指紋も目立たなくていい感じです。


Essential Phone Stellar Grayの外観

とりあえず、初期状態のアプリ一覧。

本当に素の Android という感じ。 キャリアのアプリも、端末メーカーのアプリも入ってなかったら、こんなにすっきりしてるんですね。

買った当初は 7.1.1 がインストールされていました。

そのまま、 8.1.0 が降ってきたのでインストール。

あんまり使うこともなく、Android P developer Preview を下記を参考にしながらインストール。

Essential Phone PH-1にAndroid P Betaをインストールする手順 Developer Overview

こんな感じに、 Android P になりました。

f:id:suzaku114:20180516230459p:plain

Android P の操作感

※前に使っていた HUAWEI P10 lite (WAS-LX2J) は Android 7.0 だったので、8系で変わった部分もあるかもしれません。。

ホームボタン周り

まずは大きく変わったホームボタン周り。

(実際の操作感は、 Youtube などで動画を見てもらったほうがわかりやすいかと。)

ホームボタンを右にスワイプしていくと、起動中の画面がスライドしていきます。

また、ホームボタンを上に少しスライドさせると、 Recent Task の一覧が表示されます。 さらに上にスライドさせると、アプリドロワーが表示されます。 単純に長押しすると、以前と同様に Google Assistant が起動します。

Recent Task を表示させるさじ加減が難しく、Google Assistant が起動したり、ドロワーが表示されたりします。。。

画面回転

他に気がついた機能としては、画面回転の機能。 基本的に回転を固定して使っているのですが、寝転がって使っていると、ホームボタンの右側にボタンが表示されました。

これを押してみると画面が回転されました。

画面が回転された状態で、スマホを縦にすると再度ボタンが現れ、元に戻すことも出来ました。

画面回転がかなり使いやすくなった印象です。

古いバージョンのアプリ?

https://pbs.twimg.com/media/DdKkJO5V0AIte5X.jpg:large

targetSdkVersion が古いものとかが出てるんですかね?

私の作った 共円チェッカー でも出てました。。。

display cutout

いわゆる「ノッチ」ですね。

これがあるせいで、一部のアプリは app bar がめり込んで、タップエリアが少なくなってしまっていました。

例えば、 bitFlyer アプリはこんな感じ。

f:id:suzaku114:20180516232722p:plain

動かないアプリ?

意図的なのか、意図的じゃないのかわかりませんが、いくつかのアプリは動きませんでした。

まず、 BOOK WALKER アプリは、OSバージョンを見ているようで、エラー画面(ブラウザ)に飛ばされました。。

楽天銀行アプリは、ログインの途中でワンタイムキーを入れるところでエラーになり、先に進めませんでした。。。

楽天カードアプリは、ログインしようとしたところで「予期せぬエラーが発生しました。」というエラーでログインできませんでした。。。。

nasneに貯めた番組を見るために使っている ソニーの Video & TV SideView は、機器登録の直後や、アプリ起動して数秒後に何も言わずにアプリが終了してしまいました。。。。。

こんな感じで、まだ動かないアプリが結構ありそうです。 Developer Previewだからなのか、アプリ側で変わったことをやっていて問題があるのか、とりあえず正式リリースまではこのままですかね。。

カメラ

あんまり使わないのですが、始めての二眼カメラなので、ポートレートモードで撮ってみました。

背景がおもしろいほどボケました。

細かいことはわかりませんが、それなりの写真が撮れていると思います。

今のところ、「起動が遅い」みたいなこともあまり感じていないです。

その他、使用感

前に使っていたのが、 HUAWEI P10 lite というミドルスペック端末だったこともあり、動作はかなりスムーズになった気がします。

ただ、画面が大きくなったせいもあるのか、文字のフリック入力で思ったように入力できない場面が多くなりました。このへんも、たぶん慣れですね。

まとめ

素に近い Android で、 Developer Preview 状態の Android P を触れたのは良かったです。

Developer Preview ということで(?)動かないアプリも幾つかあったり、慣れないと難しい操作感だったりしますが、付き合っていこうと思います。

ちなみに、

さっそくスマホリングを貼りました。

内側がシリコンになっており、指が痛くなりづらいかなーと思って買いましたが、結構固め。

また、回転もけっこう固め。

ただ、貼ったばっかりなので様子を見ようと思います。

5/30追記

購入して1, 2週間後、FedExから封筒が送られてきました。 税金などで追加で3,500円を払え、という内容で、コンビニ決済用と銀行振込用の用紙がついていました。

結果、Essential Phoneを買うためにかかったお金は、¥79,035 となりました。。。

kanazawa.rb meetup #68 に行ってきた

kzrb.doorkeeper.jp

自分の発表

今回はLT大会ということで、私も発表しました。

gitpitch.com

GitPitchを初めて使いましたが、便利ですね。今後は使っていこうと思います。

(Pro版じゃないので、確認しようと思ったらpushしないといけないんですが。。)

ISSUE_TEMPLATEの利用、Gatsbyを使ってPWAを構築ってのを共有できて良かったです。

他の人達の発表

色んな人のリアルな作業環境が見れてよかったです。 とくに、ディスプレイの配置とかは悩んでるので、ちょうどよかったです。

また、知らなかった話も多く、 "Web to macOS native app"で紹介されてたネイティブアプリ化はちょっと試してみようと思いました。

以下、聞いてたときのメモ。

MAC TIPS

Brewfileをチームで共有してる JSON XML Parser ユーザ辞書に開発用語の登録 スクリーンキャプチャを、defaults writeで置き場を変えている 熱対策に割り箸

Raspberry Piのインストールイメージ改変

WiFiの接続設定とか、シリアルコンソールの設定とかが面倒 Raspberry PiのカスタムをRaspberry Piでやる mountしたら書き換えられる。 書き換え終わったら umount する。 イメージの名前をリネームしておく。 それをddしたら、その変更したものが動く。

オレチョコ!!

カカオ・ポリフェノール、香り、テオブロミンなどの効能 チョコ摂取により、イライラから正常化 間食は200kcal/日が適量

VLOG環境

過去12ヶ月で4000時間かつ1000人登録が必要 大雪のときに毎日投稿してた。そのときに伸びた。 SONYの新しいカメラ紹介でも増えた。 黒い服を着る(動きやすい) 筋肉大事

(開発)環境紹介

横浜と比べて、面積広がって家賃が安くなった。 エアロバイクに乗りながらスマホゲームしたり。運動不足解消。 モニタ2台で1つ縦置き。 ケーブルを使わないときは、壁にかけてる

俺とディスプレイ

道具も含めて実力 同じディスプレイでも色が違う。ロットを合わせるしかない。 上下・左右で視野角が違うので、回転するときは注意 結論:大きいディスプレイの中央を使い、左右は通知などを表示

デスク周り晒し2018春

リープチェアV2:正規の価格だと17万 ディスプレイ:32インチ FILCOウッドパームレスト FIFINE USBマイク:マイク自体に音量調節つまみがあるので、ミュートも出来る コクヨ キャンパスノートパッドB5:方眼になってる

Raspberry PiBluetoothでシリアルコンソール

通常、HDMIディスプレイ+USBキーボード もしくは、SSHしてつなぐ。ただしIPがわからなかったり。 もしくは、TTLシリアルケーブル。これもケーブルがめんどい。 Bluetoothが無線でよい。 bluetoothd 起動後、 spdtool で SP も追加する。 ペアリング成功すると、PC側にシリアルが生える ディスカバーするのだけは、別の手段で入らないといけない。 Aliasを設定しておかないと、同じ名前のBluetoothバイスになってしまう。

俺とキーボード

洋ゲーやプログラム言語は、英字キーボードを想定されてる。

44歳ノンプログラマの開発環境

ウェブディレクタ。ExcelとかXD、Wordとか。 Googleカレンダーに落ち着く。TODO Listとか。 左手でトラックボール。Kensington。肩こりは治らない。 健康が一番重要。筋トレ+有酸素運動。 筋トレは、ネット上のコミュニティに入ったりしてモチベーション管理。

俺と通知

AppleWatchを買いたくなる、というのがゴール 仕事・私生活・タスクなどで分類出来る。 即対応が必要か。儲かる・重要な相手からの通知。 集中してるときは通知しないでほしい。超重要なものは通知してほしい。 おやすみモードを活用。watchで受ける。 通知をそのままタスクリストとして使いたい。 iPhoneに集約させる。通知がほしければアプリをインストール。不要ならメール。 メールはGmailに統合。 エイリアス機能でサービスごとに分ける。 メールのフィルタで重要度を設定し、watchを鳴らす。

最近の開発環境

庭のベンチとか。 一人用テント・タープとか。 スノーピークは国産。ちょっと高い。 キャンプ用品の出し入れをサービス化してたり。 テント乾燥サービスとか。 シュラフのクリーニングとか。

Web to macOS native app

Webサイトをmacのネイティブアプリ化。 PWAではない。 すばやくフォーカスチェンジしたい。Alfredとか。 複数アカウントを切り替えたい。 ブラウザマニア:それぞれ専用のブラウザとして使ってしまう。 特別な知識は不要。ただ、リソースを多く使う。 nativefier:npmでインストールして利用する。 ChromeベースでElectronで動く。ただ、メモリも結構つかう。 Fluid:macOS用のGUIアプリ Safariベース。スクリプトなど、機能が豊富。比較的リソースが少ない。

頑張らないzsh環境

環境作るのがめんどい。 「じーしぇる」 高機能・多機能なシェル。全容の把握が難しい。 oh-my-zsh:設定を管理するフレームワーク デフォルトで、gitコマンドの補完設定が設定済み。description的なものも出る。 テーマを変えることで、git上のstagedなファイルなどが見える。

開発環境改善活動2018

スキルアップ兼ねて、ツールを開発したりしている。 1:GitHubのレビューワークフローを改善 マージまでに時間がかかる。 交通整理役がほしい。プルリくん。 Lambdaで構築したSlack Bot。DMで通知。オートアサイン。 マージ数が1.3倍。 ユニットテストカバレッジをサクッと見たい。 機能を追加する際には、テストが必要。 エディタの中で見たい。Coverage Markers。Atom拡張機能

開発環境自慢

デバイスドライバ開発。RTOS用とか、ファームウェア開発。 Tera TermはWindows95から対応。 Visual Studio2015で作ったバイナリはVistaで動かなかったりする。

私のWorkstation環境遍歴

80年代後半、SUN-3でLatexでの文章作成から。 グループの共有マシンにログインし、先輩のdotfileを参考にカスタマイズ。 次に、使うマシンが指定され、default主義に。 機械学習などで、ゲーミングPC 今は、PCが多いので、最小限のカスタマイズ。

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に公開する。