nashcft's blog

時々何か書く。

******

日記的なもの

From: U-NEXT (2016/05~2019/02)
To: CyberAgent (2019/03~)

2/15が最終出社日でした。

U-NEXTのみなさまには大変お世話になりました。火曜に退職決まって金曜に最終出社という唐突ムーヴ失礼しました。タイミングが良かったんです。結局挨拶もそこそこみたいな感じになってしまったので話し足りなかったとかあったらご飯とかお酒とか誘ってください。

ところで昨日以下のようなツイートをしました。

これはどういうことかというと、既に内定承諾はしているのですが、入社までの期間が短いため配属がまだ調整中だけど入社手続きをもう進めちゃうねみたいな状況で、具体的な配属がまだ決まってないので決まってからブログでも書こうということでした。でも待ってたら来週末くらいとかになるかも知れないし、イベント的にそこまで引っ張る必要もないよなーって思ったのでもう書いてしまっています。

追記:
配属はマッチングエージェントでした。タップル誕生の Android アプリ開発などをやります。

www.matchingagent.co.jp

追記終わり

というわけで、サイバーエージェントのみなさまこれからよろしくお願いします。人事のみなさまにおかれましては月の半ばにもかかわらず「今月で退職できるみたいだから来月入社しますね！」という唐突ムーヴすみません。本当にタイミングが良かったんです。あと多分最初に連絡をもらった時の「明日🍣どうですか?」の件をいまだに面白がってるのだと思います。

なお、この記事は以下のレギュレーションに則って書かれました。

DroidKaigi 2019 感想

Android 日記的なもの

DroidKaigi 2019 に参加してきた。

droidkaigi.jp

セッションのノートとかは Scrapbox にまとめてある。これを書いている時点でまとめきれていないものがあって #WIP ってついてるのがそれ。 scrapbox.io

感想

聴いたセッションで特に印象的だったもの

Deep Dive to fido.fido2 Packages

最近とんとセキュリティ関係のトピックに触れてないなーって思ってて、なんか最近FIDOっていうのが注目されてるらしいので何も知らないけどとりあえず聴いてみて雰囲気だけでも掴んでみよう！というモチベーションで聴きに行った。実際セッションを聴いてFIDOについてどれだけ理解を得たかというとまだふわっとしかできてないと思うのだけど、認証まわりのどんな課題に対してFIDOがどんなアプローチをしているのかとか、attestation と assertion の大まかな流れとか、 fido.fido2 周辺のAPIにどんなのがあってどういう風に使って認証のUIを実現するのかとか、これから学習していくための良い introduction だなーと思う。
Android でFIDOの認証フローを実装するのは、送受信するデータのプロパティが多くてゴツい印象があったけどUIに関してはAPIから Intent もらって launch するだけでUIそのものを実装しなくて良く、そんなに手間ではないように感じたので開発してるサービスでFIDOの認証採用するよ！ってなった時にシュッと実装できるようになっておくとよさそう。
それと最後にアプリの実装だけでなくFIDOを採用するにあたってカスタマーサポートやサーバサイドなど各方面と、特にユーザの認証のリカバリまわりでうまくオペレーションできるように連携しましょうねって話があってこういうの大事だよねと思った。この辺の話は同じ日の最後のセッション "Chrome + WebAuthn で実現できるパスワードレスなユーザー認証体験と開発者の課題" でより進んだ言及があったので、サービスでの運用まで情報を拾っておきたい場合は合わせて見ておきたい。

ところで新しい概念について覚えたり理解しようとするのにいっぱいいっぱいでノートがろくに書けなかったのでまた録画見て理解したことを整理してノートにまとめないとなーってなってる。

R8、Proguard徹底比較

聴く前はパフォーマンスとか shrink の比較とかかなーって雑に考えてたら Dalvik バイトコードを読み始めたり R8 の最適化の一つである lambda group がどのように行われるかを R8 の実装を追いかけながら解説したりとなかなかアツい展開になってすごく満足度が高かった。
SDKとかもそうだけど私はあんまりそういうののソースコード読まないよなーって気づいて、document だけじゃなくてコードも読んだ方がいいのかなー今年はその点を頑張ろうかなーともやもや思ったのであった。

あと、発表者の方も自分で言っていたけど発表のボリュームに対して時間が足りなくて余裕のない感じだったので50分枠だったらなあと思わずにはいられない...

multi-module Androidアプリケーション

マルチモジュールっていうとビルド時間を短縮するみたいな文脈で語られがちな印象があったけど、依存関係の強制で設計のほころびを起こしにくくするというのはなるほどってなった。確かに Java から Kotlin になって失った package private の代わり(?) の internal を活用する設計とか考えるとそうなるよねーというのはあって、そういう文脈でもマルチモジュール化の流れはあるのかーという納得があった。
あとはビルド時間の短縮のためには各モジュールのサイズとか依存関係の形にも注意が必要だとか、まだ本格的にマルチモジュール化を行ったことがない身としては知見にあふれるセッションだったし、スライドもよくまとまっているうえになんというか発表が落ち着いててわかりやすいというか聴きやすいトークだったなあという印象がある。

Lifecycle, LiveData, ViewModels - The inner wiring

droidkaigi.jp

これ聴くつもりだったのだけど当日疲れてていいやってなってパスしたところTLが盛り上がっててこれ絶対楽しかったやつだ... ってなってた。録画がもう公開されてるしあとで見る。

全体の感想

去年の DroidKaigi 2018 が DroidKaigi 初参加だったので去年との比較になるのだけど、なんだかセッションのバラエティが偏ってるように感じてどのセッションを聴くのか決めるのに少し悩んでしまったのがある。ただこれは単にネガティブな感想だけではなくて、同じトピックであっちは同じ時間帯に聴きたいセッションあるからこっちにしようみたいなことができて助かったみたいなのもあり、セッション選定とか時間割組み立てとかやっぱり難しいんだろうなと思った。
他には設計・テストみたいな大きなトピックとクロスプラットフォーム関係が多いなーという印象があった。前者は Android アプリ開発界隈が成熟してきてるのかなーって感覚で、後者はやっぱり注目度が上がっているのだなという感じ。
クロスプラットフォーム系の何か1つは習得しておきたさがあるのだけど、今のところ web も Android も iOS もそれぞれ人数揃ってて精通しているメンバーがいるようなところにいるのであんまり採用するモチベーションがないよなってなってて優先度が上がらない...
あと今回のPWAのセッションで話があったようにPWAの web アプリをモバイルアプリとして PlayStore で公開できるようになったなどあるので iOS も同じような流れがあるならPWAの方が需要でそうな気がしてちょっと立場が厳しくなるのではないかみたいなのをちょっと気にしている。

展示ブースは色々見て回れて、今年もバリスタコーヒー頂けたし Kotlin Quiz では7問中6問正答で Kotlin ももっときちんと勉強しないとなーってなったし Twitter でよく見るような方とお話できたしとても楽しかった。

運営・登壇者の皆さまお疲れ様でした。とても楽しく刺激的な2日間でした。来年もまた参加できたらなと思います。おわり。

Redux に関する昨日の出来事

日記的なもの

前提: 当時の私の Redux に対する認識や知識

  • Flux: MVC, MVP, MVVM などと同じレイヤーで扱われるアーキテクチャパターン
  • Redux: Flux を実現するための具体的な実装、ライブラリ
  • Flux については 2014年末くらいに割としっかり調べてて情報を追っていたりした
  • Redux はそういうライブラリがあって今メジャーな存在になってるな程度の知識
    • あとは Elm から影響を強く受けているとかそういう話くらい

疑問

モバイル (Android, iOS) 界隈で "redux" について言及する時に特定の実装を指していないような気がするんだけどこの場合の "redux" って何だ?

投げた一連のツイート

初めて知ったこと

誤解? してたこと

  • Android にも iOS にも reduxjs/redux に相当するような "redux" という実装 (= ライブラリ) は存在しない
    • iOS には ReSwift というライブラリが存在して、それが reduxjs/redux に相当する
      • ReSwift の redux 部分の前身として ReduxKit というのがあった
    • Android には無いっぽい?
  • "redux" という語は特定の実装を指す
    • Three principles に則っていればそれは redux と呼べるみたいな認識っぽい
    • つまり一種のパターンとして認識されていることになる

Android 界隈に関しては reduxjs/redux のコンセプトだけ輸入して各々実装をしているという状況のように見えるので私の混乱の原因はそれっぽい。上に書いたように iOS は ReSwift (ReduxKit) が redux の実装として使われているようだけど、実装と共に redux が伝えられたのかは調べてないので不明なのと、あと名前が変わって "redux" という語がなくなってしまったので結局 "redux" はコンセプトだけを指すようになっていると認識している。

結局 reduxjs/redux がJS界隈でどのように普及・認識されていって、それがどのような形でモバイル界隈に輸入されていったのか知らないまま適当な発言をしていたという感じで、今もよくわかっていない。

Kotlin Android Extensions の view binding に関する知識の整理

Android Kotlin 日記でない

Kotlin Android Extensions の解説記事、Kotlin のリファレンスとか英語ソースだったらよくまとまってるのがあるけど日本語ソースだとあんまりいい感じのないなーという印象なので自分でまとめてみる。ただし view binding の方だけ。英語が読めるなら以下の記事を読めばほぼ十分という感じの内容。

kotlinlang.org

antonioleiva.com

Read more

Ergo42 を買った

動機と購入までの経緯

一昨年前くらいに購入した ErgoDox EZ がチャタリングを起こすようになったのと、 ErgoDox の形状に100%満足していたわけではないので別のも試してみるかーと思って探してみたけど近頃の流行りは自作で電子工作力も道具もない私にはちょっと手を出しにくいなーってなってたところ、組み立て済みの物を販売していてちょうど在庫があったので買ってみた。もし工作力と設備があれば dactyl manuform 作りたいのだけど...

tanoshii-life.booth.pm

Keymap

現状こんな感じ

最初は default ベースに ErgoDox の時のを組み合わせた感じにしていたのだけど、キー数が少ない分レイヤ移動が頻繁に起こることが考慮されてない構成だったのでひたすら数字や記号が打ちにくく終わっていたのでとりあえず META レイヤの切り替えを親指の位置に持ってきたり他のキーもいくつか親指周りで重ねてみたりということをして様子を見ているという状況。

自分がまだ Ergo42 のキーの少なさに対応できていない感じがしていて、キー配置の考慮が行き届いていないと思うところがあり、もうしばらく模索しないとなーとなっている。今わかっていることはとにかくレイヤ切り替えが簡単にできること、 MO や LT だったり modifier key だったりホールドする必要があって指の可動域が制限される状況を想定した時にどの指でホールドして何ができるようにしておくべきかを考慮した配置にすること、あたりが肝ではないかという感じ。ホールド用の modifier を組み合わせたキーとか作っとくといいかも?

今のところの感想

コンパクトさ

デスクの上を占める面積だったり持ち運びやすさだったり ErgoDox と比較してこのアドバンテージはかなり大きい。また殆どホームポジションから手を動かさずにタイピングできるのも楽で、ErgoDox では外側の端や親指のいくつかのキーを押すのに指を思い切り伸ばすとか割と無理なことしていたけどそういうこともなくなった。あとは個人的な状況でいうと Roost の RKM carrying case に収まるのでそれだけでキーボードとスタンドとケーブル類、その他小道具をまとめて持ち運べて大変便利している (ErgoDox は片方すらケースに収まらない)。

www.amazon.com

キー数・配置

4x7 は割とちょうど良いかもなーと keymap 考えている時に思った。必要なキーがきっちり収まって、1, 2キー余るという印象。5行あって数字キーも BASE と同じレイヤで使える方が馴染みやすいと思うけど4行でも案外いけるものだという感じ。
ただ中指・薬指・小指の列の一番下のキーはシームレスにタイプするのは無理だなーと思ってて、この位置のキーが親指のあたりにあったらもっとやりやすいかなーという気持ちになってる。Crkbd の親指まわりのキー数が5~6個あるみたいなのがちょうど良いかもなーって考えている。

booth.pm

おわりに

まだ使い始めて2週間とかそこらで慣れきってないし keymap も定まってない状況なのでキーボードに思考が奪われることがしばしばあって生産性死んでるけど良い感じだと思う。

ここまで書き終わってからこれを読んだのだけど意図せず製作者の考えてたことをたどりながら使ってた感がありなんか (私が) よかったですねってなった。

あ、読んだ流れで pixivFANBOX の支援はじめました。

余談

Ergo42 の購入を決める前に ErgoDox EZ 買い直すかーとも考えててサイト見に行ったらなんかはんだいらずでキースイッチを付け替えられるようになってた ので最高では??????????? となりとはいえ2つも買うのはどうだろうと悩んだ末にその時は Ergo42 だけ買うことにしたんだけど結局 ErgoDox EZ も買ってしまいましたとさ。

最近もやもや考えてる事

日記的なもの

DroidKaigi 2018 が終わり続く三連休も過ぎ去って体調が低空飛行なりに業務に復帰しつつ考えてる事:

スプリント期間の短縮をしたい

今のチームというか会社では全体的に1スプリント2週間で回しているのだけど、土日を挟む事で勢いがリセットされてしまって2週目はいつもダレているような気がしている。(ダレてるのは) 自分だけかもしれないけど。
今週はその2週目にあたる週で、先週と比べて明らかにタスクの流れが滞っている。自分が持っていったタスクが一旦片付いたので昨日今日は勤務時間の半分くらいずつを使って溜まってしまっていたPRを全部レビューしてLGTMしたりコメントつけたりしたのだが、だいたい半分くらいしかその後のアクションが行われず、まあこれはうちのチームのPRとそのレビューがだらしない傾向にあるのも一因なのだけどなんだかなーという気持ちになったのでこのような事を考え出した。
それでスプリントを2週間ではなく1週間にすれば毎週新しいスプリントなので毎週リフレッシュされるしいいんじゃないかなーとか、計画とレビューが毎週発生するようになってMTGの時間がーという風にも考えられるがスプリントが短い分その中でこなすべきタスク量も2週間分と比較して少なくなって、MTG1回あたりの時間も短くなるんじゃないかとか、1週間でできるタスクの大きさに制限する事でより見積もりがしやすくなるんじゃないかとか考えていた。
とまあこの程度でまだ社内にうまく提案するまでまとまってないのでWIP。

PRとレビューがだらしない

上でもちょっと出たけどだらしないというのはどういうことかというと1つのPRが大きくなりがちだったりレビューもそれに対するリアクションも遅めで、典型的なコードレビューが開発のボトルネックになっている環境。
でかいPRというのは本当に厳しくて、まあレビュイーについてもコードを見て気持ちになってしまったというのはわかるのだけど見きれないよ... となり、レビューもだんだん雑になってきて結果的に無をしてマージ、みたいなことになる。
これは今ペアプロ・モブプロを導入しようとしている最中で、それで解決に持っていきたい。

会話の中で「話すべきこと」と「話したいこと」の分別がつけられずに発言すること

これは自分にも身に覚えがあるので自戒でもあるのだけど、相談事をしている最中に自分語りみたいなのを始めて相談や質問の回答が返ってくるまで数分以上かかったり、もしくはこちらから促さないと返ってこなかったり、真面目に議論している最中に突然脱線させて帰ってこなくなったりみたいなことが発生すると本当につらい。
これはやってしまっている本人は気づいてないというか、文脈を読み違えてしまった故の悲劇というか、意識しないと誰でもやってしまうように思われる。多分発生したら直接指摘するしかないのだと思うが、本人は自然に話をしているつもりなのだろうから忍びなく思ってしまう。故意だったら質が悪い。

年明けから今日まで

日記的なもの

継続的に文章を書くという試みとはなんだったのかという様子ですね。とりあえず年が明けてからのことを書きます。

1月上旬〜中旬

年末年始休暇が終わっていきなり気分が沈み始め、業務の進捗も出なかったことが追い打ちになって完全に精神が終了していました。この時期Twitterではずっとダメになったとか終わってしまったとか呟いてたと思います。現実ではよくわからなかったのでリムスキーコルサコフの管弦楽法のテキストを買って読んでました。
ところでこの時期割と頻繁にチームの同僚に心情の吐露をしていたような気がするのですが、振り返ってみるとうちのケースにおいてはあまり良くなかったなあという反省があり、具体的には人の面倒を見ることに明るくない人間に感情に関する曖昧な共有をしてもただ困らせことになるだけだということです。この辺は同僚に対する愚痴ではなく弊チームの成熟度合いや体制プロセスetcと様々な要素が絡んでおり何かが悪いというより不運な事故が発生したという認識で、むしろ相手からしたら唐突に「私はしらみだ...」とだけ言ってくる同僚なんてどうしろってんだという感じだったでしょう。

1月下旬〜今日

下旬くらいになってからだんだん精神が自然回復してきて、業務の進捗も出るようになりました。そういえば弊社でもやっとAndroidアプリ開発にKotlinが導入されるようになってやっと文明の火を得たという心持ちです。
このくらいに昼食を外食からCOMPとプロテインをミックスしたものに変えてみたり、『シリコンバレー式 自分を変える最強の食事』を読んで朝食をココナッツオイルコーヒー+αにするなどしてみたところ日中に頭がはっきりした状態を保てるようになって、それにつられて気分もだいぶ良くなりだいたい本調子に戻りました。最近はその辺が面白くて毎日食事の調整をしながら体調を観察して継続的に良い調子を保てる食事メニューを考えています。
最近はチームにペアプロ・モブプロを導入しようと色々やっています。弊チームは性格的にプルリクとコードレビューがだらしなくなりやすい (1つのプルリクが巨大になる、レビューが五月雨でマージされるまで時間がかかるなど) のでその辺の解決になるといいなーとか考えながら進めています。

とりあえず書きたいことをとにかく書き出そうという書き方をしたので脈絡のない乱文になりましたが何かしら文字に起こせて満足したのでいいやという所感です。溜めに溜めてビッグバンリリースをするから酷い事になるという様を表しているということにします。

ところで諸々のメモ書き的なものは使い勝手からScrapboxの方でやろうというということにしていて、こっちでは何かしら文章の体裁をとったものを投稿する時に使うことにしました。とはいえこっちもまだろくなこと書いていません。