2021年5月19日水曜日

GoogleI/O 2021メモ

今年も感染症の影響でGoogle I/Oはオンラインです
すでにKeynoteもアーカイブ公開されているので詳細は直接動画をみましょう


オンラインで参加者の交流を図るFlutter製WebアプリAdventure

日本ではDroidKaigi主催で解説を聞きながらセッションを見る応援上映会がありました

気になったコンテンツはリアタイでTweetしたのが割とまとまってると思うのでこちら

Android周りではAndroid12の新機能紹介Jetpackの更新が主なトピックですがそれは別途

注目トピック




Personal Material Design (Material You / Next?)

アプリのテーマカラーを壁紙などの設定から個人に合わせたカスタマイズできるように

FirebaseのRemote configのPesonalizeも話題にあがっており、Personalizeは今回ひとつのキーワード

Privacy in Android 12

Androidフレームワーク機能レベルでは正確なLocationをアプリに共有しない設定
Bluetoothを使った新しいLocation permission

モバイルレベルではアプリごとの権限設定のスイッチングに楽にアクセスできるようになったり、新しいPixel(?)ではマイクなど利用ランプがつくように

サービスレベルではPhotoでローカルMLによるグルーピングや共有範囲の設定など

Google Shopping

現在検索結果に出てくるカルーセル




他、Flutter2.2やWear OSの統合、Google CanvasというオンラインコミュニケーションシステムやMLの進歩など幅広くまんべんなく話題が多い回でした

各セッションもすでに公開されているので随時キャッチアップしていきます 

2020年8月4日火曜日

Build app fast on Android Studio 4.+(Android 11 Meetup登壇)

Android 11 Meetups にて、Android Studio 4.0以降に追加された Build Analyzer、CPU Profiler、Database Inspectorなどの新機能を使って効率的に高性能なアプリを開発する方法について発表しました。

https://developersonair.withgoogle.com/events/a11meetups-jp/watch?talk=android-dev-tool

Android 11 Meetups は Android 11 Beta のリリースを機に、アプリ開発の最新技術情報をお届けすべく、Google と GDG (Google Developer Groups)が共催するオンラインセミナーシリーズです。

以下に発表のスクリプトを公開します。


Build app fast on Android Studio 4.+

Android Studio Releases

はじめに今公開されているAndroid Studioのバージョンについて紹介します。

Android OSのアップデートとともに開発環境Android Studioも便利な機能が追加され、更新されています。

Android StudioのリリーストラックはStable、Beta、Canaryがあります。
正式リリース版であるStableは4.0、次のリリース候補のBetaは4.1、開発中版のCanaryは4.2まで公開されています。
BetaやCanaryはまだ大きな変更が入る可能性があるので、実際の開発に使う場合は自己責任ですが、Android studio最新の機能を試すことができます。
更新も頻繁に行われており、Gradle Pluginのアップデートも含めるとそれぞれのバージョンで月に数回アップデートが配信されています。

Gradleの更新などが入るとコードやビルドスクリプトの修正が必要になる場合があります。
差分が大きくなると修正が難しくなるため、できる限りこまめにバージョンアップすることをおすすめします。

Pick up New Features

Android Studio4.0以降で追加、更新された主要な機能としては、ビルドに関する機能、UIの構築をサポートする機能、作ったアプリを分析して改善につなげる機能があります。
本セッションでは特にアプリの開発速度とパフォーマンス向上を支援する機能をピックアップして紹介します。

Android Studio 4.0で大きく改善したアプリの開発速度向上のための機能であるBuild Analyzer、アプリのパフォーマンス解析と改善のための機能であるCPU Profilerについてと、4.1 Preview で導入された Database Inspector の紹介をしていきます。
4.2 Canary の注目機能であるJetpack ComposeのサポートやUI開発系のツールについては、この後のセッションで詳しく解説しますのでここでは触れません。

Build Analyzer

早速機能の紹介に移ります。
はじめにアプリの開発速度を向上するための機能として、Build Analyzerを紹介します。

Build Analyzer

Build AnalyzerはAndroid studio上でのビルドの速度をPlugin、taskごとに解析しビルドを最適化する助けになるツールです。
Android Studio4.0でAndroid Gradle plugin 4.0.0以降から使えます。

Open Build Analyzer window

Build AnalyzerのウィンドウはAndroid Studioの下部のBuildウィンドウの中のBuild Analyzerタブで開きます。
Buildウィンドウがメイン画面で開いていない場合は画面上部のViewセクションからTool Windowsの中のBuildを選択してください。
Build AnalyzerはAndroid Studio上で行われるすべてのビルドを解析しています。
RunボタンやBuildコマンドを実行したらその結果が表示されているので開いてみましょう。

Tabs

Build AnalyzerにはOverview、Tasks、Warningsのタブがあります。
Overviewではビルドが実行された時間や合計時間などが表示されます。

Tasks

Tasksを開いてみてみます。
ウィンドウの左側のツリーには、ビルド時間に直接影響を与えるタスクが表示されます。
pluginごとまたはtaskごとの表示を切り替えられます。
右側のペインではビルド時間へのインパクトの視覚的な表示と、タスクの詳細が表示されます。

Which tasks determine build duration

一番ビルド時間に影響を与えているタスクの詳細に注目してみましょう。

Which tasks determine build duration

この解析結果を見てみると、processDebugResources という、デバッグ build type でのリソースの処理に時間がかかっていそうです。
これを改善するには、不要なリソースをビルド対象外としたり、画像リソースを軽量化するなどが考えられます。

不要なリソースをビルド対象外とする場合、特定のロケールの言語リソースのみをビルドに含めたり、画面サイズに応じたリソースを開発中はビルド処理の対象から外すようにflavorで指定すると良いかもしれません。
Resourceに画像が多く含まれるのであればWebPなどで画像を最適化するのも良いかもしれません。
Android Developersサイトのビルド速度を最適化する記事をみると多くのヒントが提供されているので、ボトルネックが解消できるか試してみるのがよいでしょう。

Warning tab

[Warnings] タブではビルド時間に悪い影響があると考えられる部分への警告が出ます。

この例では古いプラグインによって依存関係の解決が重複している可能性があると出ています。
古いプラグインでは最新のGradleで改善されているビルド最適化の機能を利用できないためビルドが遅くなります。
Warningに従ってプラグインをアップデートしましょう。

Build duration

Build Analyzerでの注意点は、ビルド時間自体はCacheの状態や変更の内容によって大きく変わることです。
これはAndroid Studio4.2上で同じプロジェクトで小さな変更をおこないビルドしたときの記録です。
初回のビルドでは542秒かかっているのに対して2回目はなんと15秒、3回目は50秒と大きく変動しています。

Build duration

Build Analyzerによるビルド速度の最適化は、一回一回のビルドを細かく解析していくというよりも、プラグインを足したときやビルドが遅いときにチェックし、継続的に対処していくのがよさそうです。

CPU Profiler

次にアプリのパフォーマンス解析と改善のための機能として、Android ProfilerのCPU profilerの更新を紹介します。

CPU Profiler

CPU Profilerではアプリの CPU 使用量やスレッド アクティビティをリアルタイムで確認したり、記録されたメソッド トレース、関数トレース、システム トレースの詳細を調べたりできます。

Android Studio4.0ではCPU ProfilerのUIがアップグレードされて、より分析しやすくなりました。

アプリのCPU使用率を最適化するとアプリの動作が高速でスムーズになります。

またCPUの使用率は端末の電池の使用量と密に関係しており、CPU使用率を最適化すると電池消費が減るなどのメリットもあります。

Open CPU Profiler

CPU Profilerを使う流れをみていきます。

Android Studio画面上部の[View] > [Tool Windows] > [Profiler] 、または画面下部の [Profiler] でプロファイルウィンドウを開きます。

ProfilerからCPUのタイムラインをクリックするとCPU Profilerが開きます。

CPU Profiler(動画)

動画でみてみます。

Android Profilerウィンドウの左側のSESSIONSで実行中の解析したいアプリを選択すると、
そのアプリの CPU 使用率やメモリ使用率がグラフがリアルタイムに表示されます。
解析結果が右から左へ流れていきます。
上部の赤い表示がユーザーのインタラクション、その下の明るい緑のラインが実行されているActivityです。
CPUのグラフをクリックすると、CPUの使用率をより詳細に解析するためのCPU Profilerが開きます。

Record methods

CPUの使用状況をより詳細に解析するためにはメソッドの呼び出しを記録する必要があります。

画面上部または記録が選択されていない場合はウィンドウ中央部からプロファイリングモードを選択します。
モードにはSample Java Methods、Trace Java Methods、Sample C/C++Functions、Trace System Calls、または自分でカスタムするモードがあります。

一番シンプルにアプリのJavaベースのメソッド呼び出しを記録するSample Java Methodsを使ってCPU使用量を最適化する流れを見ていきます。

Sample Java MethodsはアプリのJavaペースのメソッド呼び出しのコールスタックを頻繁に取得しトレースデータを作成します。
Sample Java Methodsはアプリの実行速度を落とすことなく記録ができますが、サンプリングが間に合わない短いライフサイクルのメソッド呼び出しを取り落とすことがあります。

Trace Java MethodsはSampleと同じくJavaのメソッド呼び出しを記録するプロファイルで、インストルメント化という手法を使う事によってライフサイクルの短いメソッドも記録できますが、
アプリの実行速度が落ち本来のパフォーマンスが出なかったり、トレースの上限に達して記録ができなくなる場合もあります。

Javaのメソッドを記録する場合ははじめにSample Java Methodsで解析し、より正確な解析が必要な場合にTrace Java Methodsを使うとよさそうです。

Record methods

ここではRecyclerViewのスクロール時に動作がカクつく原因をメソッド呼び出しを記録して探る例を想定します。

アプリを実行している状態でCPU Profilerのウィンドウ上部かタイムラインの下部にあるメニューでプロファイルを選び、Recordボタンをおして記録を開始します。
パフォーマンスを計測したい操作をアプリで行い、終わったら記録をStopします。
自動的に記録された結果が読み込まれ、表示が変わります。
Recording の開始と終了のタイミングを解析したい箇所に合わせて記録するのがコツです。

Record Methods

Sample Java Methodsプロファイリングを記録するとこのように表示されます。
左側のペインには、横軸を経過時間としてCPUの使用率、ユーザーのインタラクション、Activityのライフサイクル、スレッドのコールチャートが表示されます。

CPU使用率のラインで選択したタイムボックスのコールチャートを下部に詳しく表示します。
黄色、緑、青で視覚的に表示されているのが記録されたコールチャートです。

左右に長いほどCPUの使用時間を占めています。
実行時間を占めていたり、メソッドコールスタックが縦に多く重なっている部分がパフォーマンス低下を引き起こしている原因だとあたりをつけてより詳細に追っていきます。

Select a method call

ひとつのメソッドコールを選択すると右側のペインにコールチャートの詳細が表示されます。
Summary、Flame Chart、Top Down、Bottom Upの4つのタブがあります。

はじめにFlame Chartを選択してみます。

Flame Chart

Flame Chartは同一のコールスタックを集約し反転したチャートです。
同じコールスタック内で同じ経路で呼び出されたメソッドコールをまとめ、積み上げて表示します。

左右に長いほどCPU時間を占めています。
繰り返し呼び出されているメソッドも集約されているので、合計時間としてCPUを占めているメソッドコールを見つけられます。

時間がかかっているものを絞り込んでいくために、このグラフのスタックの上の方でこのように左右に広がっている部分に注目します。
発見したメソッドコールをTop Down、Bottom Upでより詳細に見ていきます。

Top Down

Top Downチャートでは呼び出し元からのコールスタックをツリーで表示していて、時間のかかる処理を絞り込むのに最適です。
それぞれのメソッドコールにかかる時間をself、子の呼び出しでかかる時間をchildrenから詳細に読み取れるので時間のかかるメソッドコールを特定するときに使います。

Flame Chartでみつけたメソッドコールが実際にどれくらいの時間がかかっているのかをこのViewで詳細に確認します。

Bottom Up

Bottom Upは呼び出し一覧から呼び出し元をノードで表現するグラフです。
記録されたすべてのメソッドコールが一覧で並んでいるので時間のかかっているメソッドコールを見つけるのに適しています。

これらのチャートの考え方の詳細はAndroid DevelopersサイトのCPU のホットスポットを特定する、の記事を参照してください。

Flame ChartやTop DownやBottom Upであたりをつけたら該当するメソッドのコードの問題を修正し、再度CPU Profilerで修正されたか確認しましょう。

このようにSample Java MethodsプロファイルでCPU使用量に問題があるメソッド呼び出しを見つけることができますが、
必ずパフォーマンス低下の原因を見つけられるとは限りません。
メソッドの記録が適切ではないと感じたらTrace Java Methodsプロファイルで記録をしてみたり、Memory Profilerでメモリ使用に問題がないか確認してみたりしましょう。

ここまでがRecord MethodsのSample Java MethodsでCPUのパフォーマンスを確認する流れです。

ここでもうひとつUIレンダリングパフォーマンスの最適化に使える、Record MethodsのTrace System Callsプロファイルを紹介します。

Record methods (Trace System Calls)

Trace system calls では、メインスレッドでの画面の描画にかかる時間を解析でき、UI ジャンクや低フレームレートの原因を探る手がかりとなります。

Renderingウィンドウではメインスレッドと RenderThread で各フレームをレンダリングする際にかかる時間を調べて、UI ジャンクと低フレームレートの原因となるボトルネックを調査できます。

Framesで赤く表示される16msを超えるフレームを探しましょう。
対応するThreadを選択するとJava Sample Methodsのときと同様にトレース情報の詳細から原因を探ることができます。

Improve App Performance

ここまでCPU Profilerの新しいUI、機能を使ってボトルネックを検証する方法を紹介しました。
CPU Profilerはタブからすぐに起動できるので、開発中にアプリの動作が重いなと感じたらすぐにひらいて改善に繋げられるとよいでしょう。

Android Profilersには今回紹介したCPU Profiler以外にもパフォーマンスを改善する機能として、メモリ使用量をモニタするMemory Profiler、ネットワーク通信の状況を監視するNetwork Prodiler、電池の消費量への影響が見れるEnergy Profilerがあります。
アプリの動作が重いときの原因がCPUだけに起因することは稀です。
Android Profilersの機能を横断的に使って効果的にアプリのパフォーマンスを上げていきましょう。

Database Inspector

最後におすすめするAndroid Studioの新しい機能は4.1で追加されるDatabase Inspectorです。

Database Inspector

今までAndroidアプリの書き込むSQLite databaseのデータはデータベースファイルをデバイスから引き出しツールで詳細を見るか、ADB shell経由で確認するしかありませんでした。
Database Inspectorは実行されてるアプリのDatabaseをAndroid studioから変更して反映させ動作を確認できます。

開発中のアプリにAndroid Studioからクエリを実行してデータの検証ができたり、値の更新をしてデータをモック化したりと開発に役立てることができます。

新しいDatabase InspectorはAndroid studioからDatabase Inspectorを開けばそれだけでAndroid Studio上でリアルタイムにDatabaseの状態を確認できます。
特に難しい設定は不要です。Roomを使っていても、SQLiteDatabase APIを直接利用していてもDatabase Inspectorは使えます。

Database Inspectorウィンドウが開いていない場合は[View]>[Tool Windows]>[Database Inspector]から開きます。

Run query from the code

Android JetpackのRoomを使っている場合はクエリの検証を簡単にできます。
Android StudioでRoomの@Queryアノテーションの左側をみてください。
テーブルと虫眼鏡のマークが表示されます。

Run query

これをクリックして実行すると実行結果がタブが表示されます。
ここからクエリを修正し実行もできるため、クエリの調整が素早く簡単にできます。

Update database

Database Inspector でデータベースに変更を加えると、アプリの UI にもその変更が反映できます。
テーブルのデータを直接編集してRefresh Tableをクリックするとデータベースの値が書き換えられます。

データベースの値を表示するアプリであれば画面を更新するとデータの書き換えが確認できます。
サンプルのようにLiveDataを使っている場合アプリ上での操作なしにデータベースの更新が即座に画面に反映できます。

Database Inspector

このようにアプリのデータベース周りの実装の確認を簡単にできるようになりました。
なお現在のところクエリの実行と値の書き換えはできますが、データのinsertはサポートしていないようです。

また、この機能は他のデータ書き換えに比べてとても簡単で反映も速いため、
例えばAPIレスポンスのモックなど、データを変更してのテストも簡単にできるかもしれません。

終わりに

Android Studio4.0以降の更新でパフォーマンスの高いアプリを高速で開発するのをサポートするおすすめの新機能を紹介してきました。

AndroidはOSも開発環境も高い頻度で便利で高性能な機能を発表しています。

開発効率化のためにもできるだけ最新のアップデートに追従するようにしましょう。

Gradleやpluginのバージョンによってはアプリの修正が必要になりますが、差分が大きくなるとより修正が困難になるのでこまめにメンテナンスをしましょう。

最後にもう一度ですが、Beta、CanaryバージョンはあくまでPreviewなので開発に悪影響を及ぼす場合もあるので、製品アプリで試す場合は慎重に行いましょう。
自分の場合は複数バージョンの開発環境をキープしておいて試すなどしています。
しかし新しいバージョンごとに便利な機能が追加され、ビルドも高速化しているので、できるならばぜひ新しいバージョンを試して、なにかあったらフィードバックを送り、パフォーマンスが高いアプリを効率的に素早く開発していきましょう。

ご視聴ありがとうございました。

2018年11月25日日曜日

Report of Firebase Summit 2018 in Prague / Czech

会社から機会をいただきチェコ・プラハで開催されたFirebase Summitに参加し、そのレポートを Mercari x Merpay Tech Talk for Android Engineers - connpass にて発表しました。


Summary

  • Firebase Summit本体で発表されたサマリは次のとおり
    • GCP Integrations - AnalyticsのGCPへの連携
    • Machine Learning - MLKitの更新、Prediction・ABTesting・RemoteConfigなどのAIを利用した機能の拡張
    • Open Source - Firebase SDKのオープンソース化

Firebase Summit

当日のスケジュールと動画はこちら↓ https://firebase.events/
Keynoteでアップデートの発表、セッションやワークショップで理解を深めるという構成でした。


Workshop

Codelabを解説しながら進める形式でした。 単純なCodelabなのでちょっと残念に思いましたが、ここで実践したことであとで開発者とdiscussionすることができたのでよかったです。 個人的にはFirebaseという共通するコードの解説のハンズオンをFlutterでおこなうと環境構築や説明が冗長にならないのは興味深く思いました。


Firestoreがリアルタイムに反映されるアプリのCodelab

https://codelabs.developers.google.com/codelabs/flutter-firebase/
インターネッツが貧弱でDL難民頻出でした。 Firestoreコンソールから追加したエンティティを変更した瞬間にアプリ側でも表示が変わります。 Vote数を記録するサンプルアプリでしたが、実アプリでいいねだけをFirestoreに任せるなどしてみたらおもしろそうだと思いました。


MLKit

https://codelabs.developers.google.com/codelabs/mlkit-image-objects-android/ テキスト画像からの検出、モデルの追加によるアラビア語など珍しい文字の検出、顔の輪郭検出、物体検出の4つをMLKitを利用しておこなうアプリのCodelabです。 今回新登場したCompress機能で圧縮された数百KBのモデルをコンソールにアップして軽量で精度の高い文字検出ができました。


AskFirebase

Firebase teamメンバーがテーマごとにブースにいて質問ができるコーナーです。


HackFirebase

CodelabにチャレンジしたりGooglerに質問できるスペースです。 Flutterの開発チームのFillipさんとお話して、MTCを紹介したりその開発の上でMaterialDesignを導入すると20MB近く日本語フォントでアプリが太ってしまう問題やAndroidだったらDownloadableFontを利用できるようにしたらよいのではという意見をしたり、Codelabでみつけた減少の共有をしたりできました。 FillipさんはCARTUNEのことをご存知で、MTCアプリのデザインも褒めていただき嬉しかったです。


Other activity

AppShipというFirebaseを利用したゲームや、プリクラみたいなselfieコーナー、Googleのイラストレーターによる似顔絵イラスト作成、これらを回るとプライズがもらえるスカベンジャーハントなど参加者同士やGooglerと交流するためのアクティビティがありました。


Firebase update summary

更新の詳細についてはGoogleの公式ブログに記載されています。 英語と日本語版のブログの掲載場所が異なリます en / jp
  • Firebase is used everymonth 1.5M+ app
  • Keywords
    • AI
    • Transparency&Exhibitication
    • Sophisorogy
  • Hotstar india has 150mill user, they using Firebase features
  • GDPR transparency support
  • Firestore asia europa region comming soon
  • Prediction, A/B Testing, Crashlytics can export to BigQuery
  • Client app SDK Opensource
  • MLでユーザー行動からセグメンテーションをおこなうPredictionsがBeta卒業
  • Audienceもより細かくIn-app billingやイベントのステータス設定がコンソールからできるように
  • FCMで自動で定期的にプッシュを送るなどのlong-running-campaignが登場
  • Remote config update : realtime propagation
  • Firebase Management API : APIでFirebaseのConfigrationができる
    • これによりGlitchなどのオンラインIDEから直接デプロイできるようになった
  • FabricのFirebase統合が進んでいる
  • Crashlytics + PagerDuty integrations https://www.pagerduty.com/docs/guides/firebase-integration-guide/
  • Firebase performance monitoringにtrace sessionsが登場
  • Test Lab for iOS released!
  • ML Kit update : face contours API


所感など

Firebase Summitは最新情報をただ受け取るだけでなく、あらゆるところで参加者からのフィードバックを得ようというGoogleの意思を感じました。 クライアントアプリエンジニアとしてはFlutterの開発者と直接お話できて日本語フォントによるアプリサイズの問題についてフィードバックし改善したいと言っていただけたことが嬉しかったです。 またSDKがオープンソースになったこと、MLKitのアップデートなどはとてもテンションがあがりました。


Tips of business trip for Europa


language

チェコは歴史的経緯からチェコ語をメインとし、スロヴァキア語、ドイツ語、たまにロシア語などが入り乱れる上にアルファベットが英語とかなり異なるのでめっちゃ読めない。 プラハは観光客が多く英語が通じたり、たまに観光地で日本語のパンフレットがあったりする。 市街地、若い人はだいたい英語わかるけど市内から外れると全然通じない。 駅員やバス運転手も。 ややこしいのがチェコ語の'Yes'が'Ano(no)'なので全く逆に聞こえるという。 ちなみに'No'は'Ne'。 カンファレンスはオール英語なので大変助かった気持ちになった。


SIM card

AIS(タイ?の会社、4000円くらい)というのを買った。 これが大変優秀で乗り換え地のモスクワ・シェレメーチエヴォ国際空港でも通じた。 シェレメーチエヴォ空港のWi-fiの認証が電話番号にボイスコールで認証番号を届けるというものなので 国際電話が通じる状況じゃないと認証通らないという無理ゲー。 このSIMカードがなかったら大変つらいことになってた。


交通

市街ならUberがかなり走ってる。比較的安価。バス・地下鉄・トラム(路面電車)もかなり走っており便利。 中心街から離れるとUber少ないので注意。 トラムは乗る機会がなかったのが残念。


治安

あまり怖い思いはしなかったけど夜一人で出歩いたりしなかったからかな。 外でタバコを吸ってたらホームレスに追いかけられたという話も聞いたので注意は必要そう。


物価

チェココルナがほとんどで一部ユーロも使える。 でもやっぱりコルナ。 水よりビールが安いのは本当だった。


持ってってよかったもの

  • 変換プラグ ないと死ぬ
  • 室内用スリッパ
  • マスク ちょっと変な目で見られる

2018年8月26日日曜日

Kotlin Fest 2018で「start from Convert to Kotlin」トークしました



Kotlin Fest 2018 に登壇者兼スタッフ(オープニングトーク司会)として参加してきました。
Kotlinへの愛と熱気にあてられた一日でした。



「start from Convert to Kotlin」というタイトルで初学者向けにすでにあるJava製Androidアプリで『Convert Java File To Kotlin File』という機能を使って自動変換したコードをベースにKotlinの良さとどのように改善していくかというお話をしました。
登壇中大変緊張してしまい聞きづらいところもあったかと思いますが、聴講いただいた皆様ありがとうございました。

後日動画も公開されるそうです。怖い。

いくつか要点と補足です。

  • KotlinコードでもJavaは意識せざるを得ないので随時Decompileを駆使して確認する
  • AndroidアプリではNull許容・非許容を適切にハンドリングすることで効果的にバグを回避することができるが、単純なConvertのみでは適切な形にならないこともあるので留意する。特に!!が出てきたら要注意
  • KotlinテストコードでのassertNotNullではそのあとのスマートキャストが効かないがkotlin-test-junitのfailを使うとスマートキャストが効くようになる
  • Javaでは名前付き引数が使えないと話しましたが、正確にはJava8以降でオプション機能としてサポートされています。しかしKotlinからはJava6との互換性のためJavaの名前付き引数を解決できないとのことです(Kotlinイン・アクション P62より)。
  • 実装では名前付き引数を使うと読みやすいだけでなく引数の定義順の入れ替えが起こっても壊れないので堅牢になるが、Java混在プロジェクトの場合は順番を保証したいのでテストコードで名前付き引数を使わないことで変更による影響を検知できる
  • lateinitとby lazyの最大の違いは宣言がvarになるかvalになるか。サンプルプロジェクトの場合だとby lazyのほうが良かったかもしれません




Kotlin可愛い。

2018年2月11日日曜日

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

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



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

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


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


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

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

内容についての補足


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

準備について


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


発表について


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


謝辞


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

最後に


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

2018年1月1日月曜日

2017年ふりかえり

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

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


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

2月


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


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


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

3月


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

4月




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


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



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

5月

LTでお話しました。

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

6月


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


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


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

7月


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


ペアプロよかったらしい



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

8月


夏コミでした


事件

9月


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

10月



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

11月


ヤバい。がんばる。


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

12月


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


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

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


2018年


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

2016年11月28日月曜日

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

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


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

参加人数とキャパ

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

発表内容について

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

#TechBookWalk

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

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