どくぴーの備忘録

真面目なことを書こうとするクソメガネのブログ。いつ投げ捨てられるのかは不明

電動昇降デスクFLEXISPOT E3が届いたので組み立てRTA(Solo Any%)して使ってみた

どーも、どくぴーです。

とあるご縁でFlexiSpotの電動昇降デスクをレビューする機会を頂き、実際に実物が届いたので組み立てて使ってみました。

f:id:e10dokup:20201024214607j:plain:w640
前々から知り合いが使ってていいなぁとは思ってた一品。

ちなみに送っていただいたのはFlexiSpot E3というモデルで、天板は140cm x 70cm x 2.5cmのMaple 角丸にしました。

flexispot.jp

2020/10/24現在でキャンペーンをしていて、ノートパソコンスタンドがもらえるみたいですね。天板はFlexiSpotさんが用意しているものの以外に自分で用意してDIYすることもできます。 脚(?)のスペックとしては

  • 耐荷重100kg
  • 対応天板幅110cm-180cm
  • 昇降スピード38mm/sec
  • メモリ、アラーム機能搭載

という感じです。脚を左右に広げたり縮めたりできるので、それで天板の幅に合わせるという感じですね。

届いた

f:id:e10dokup:20201024215321j:plain:w360
どうしようもないので玄関に安置しました

当然組立前の状態で届くのでこの時点で家に入らないんじゃね?みたいな心配はありません。ただし35kgあるので姿勢が悪いと多分腰をやるので気をつけましょう。 届いた後にFlexiSpot組み立てRTA(Solo Any%)の前走者の知り合い何人かに「何用意したらいい?」「何を気をつけたらいい?」って聞いていたら

  • 電動ドリルが無いと死ぬ。錐で穴を開けたら大変な思いをします(1敗)
  • 重いなーと思って頑張ってたら床を傷付けるのでタオルを敷きます(1敗)
  • 動かす時は床にタオルや布を敷いて引っ越し屋の要領で頑張る
  • 時間はかからんが1日潰すくらいの気持ちでやれ

等、ありがたいお言葉を頂いたので、とりあえず電動ドリルを用意しようと思いサクッと購入しました。買ったのは他のFlexiSpot組み立てレビューでも上がっていたBOSCH IXO5のドリルビットセットです

www.bosch.co.jp

f:id:e10dokup:20201025000101j:plain:w640
BOSCH IXO5 + ドリルビット。めっちゃコンパクト

漢ならマキタっしょみたいな頭の悪い思考があったのですが、やはり高いし用途として十分そうだったので今回はmicroUSBで充電できたりコスパの良さそうなこちらを採用です。車好きとしてはBOSCHは多少滾るものがあります。

組み立てた

まずは一旦天板を床に引っ張り出します。天地逆転で組み立てて最終的にひっくり返して配置するイメージです。ちなみに初手で写真を撮り忘れたのでここはガバです。 FlexiSpotさん公式の天板を使う場合はすでに一部に穴が空いていて、それには操作パネル用の穴が長辺側に空いています。ひっくり返した際に手前に来るように、その穴を奥向きに置くと吉でしょう。

一旦天板を引っ張り出したら脚側の箱を開けてネジが揃ってるか確認します。微妙に一品足りないとか無いと中途半端に組み立てたデスクが鎮座することになるので、念には念を入れます。大体現場猫レベルの勢いで「ヨシ!」ってなるので大丈夫そうだったら説明書を読み出します。使うネジがABCで袋分けされていてわかりやすいなって思いました。

f:id:e10dokup:20201024220725j:plain:w640
ネジが足りているか確認する図

そしたらまずは脚の部分と天板の裏に這わせるビームを組み立てていきます。この時点ですでに重いので早速作業には要注意です。ネジ締めは歪んだり、バランスを崩さないように対角線上のネジをまずは軽く締め、全部終わったらそれぞれをしっかり締め切る対角締め・増し締めで落ち着いてやっていきます。

f:id:e10dokup:20201024221451j:plain:w640
もうこの時点で剛性を感じる

その後も勢いよく足を組み上げ、天板と合体していきます。天板には釘ネジで固定するのですが、天板に穴の空いていない部分にも釘ネジを打つ必要があるので、ここでドリルを使って下穴を開けるのが必要でした。説明書通りに入れると22本釘ネジを打つ必要があるので、一番時間がかかる工程です。

f:id:e10dokup:20201024222433j:plain:w640
足をつけて

f:id:e10dokup:20201024222958j:plain:w640
天板に脚を固定していきます

その後は配線したり電源ユニットや操作パネルと言った昇降に必要な部品を組み付けていって、組立自体は完了です。

f:id:e10dokup:20201024235847j:plain:w640
電源ユニットとかはケーブルホルダーでふたをすることで落ちてこないようになってます

f:id:e10dokup:20201025000012j:plain:w640
操作パネルも固定。ここにも釘ネジを使います

ひっくり返して配置した

多分一人で組み立てる場合はもっとも危険なポイントです。40-50kgサイズのものをひっくり返すので床や壁に傷をつけるくらいならまだしも、怪我をしかねないので慎重に進めました。 とりあえず手前に半回転回してみたんですが、重心が足元側に来るのと天板の奥行きが70cmと大きめなのでとにかく立ち上げにくくて、「詰んだのでは…?」って5分くらい遠い目をしていました。

f:id:e10dokup:20201025000417j:plain:w640
一旦手前方向に半回転返した図。詰んだ感が半端ない

腰を覚悟しながら頑張ったら無事に立ち上がったので、完成です。

f:id:e10dokup:20201025000704j:plain:w640
「立った!机が立った!」か「机、床に立つ」どちらかは想像におまかせします

後は壁側に頑張って押し込んで、電源をつないで高さを最大にしてみます。超高い。

f:id:e10dokup:20201025000959j:plain:w640
最大高の123cm。流石にこれは自分には高すぎる

ひたすら上下してみて、満足したら後は前の机にあったものをいい感じに再配置したらFlexiSpot組み立てRTA(Solo Any%)完走です。朝10時から始めて13時位に終わったのでタイムはだいたい3時間でした。

f:id:e10dokup:20201025001331j:plain:w640
特に何か配置を大きく変えたわけではない。

完走した感想(激ウマギャグ)

組み立てそのものはガンプラみたいなプラモデルや自作PCみたいな組み立てよりよっぽど簡単でした。家具の組み立てとか初めてだという人も説明書だけで十分理解できると思いますし、幸いYouTubeなどに公式さんや色んな人が組み立てている動画を上げているので、コツみたいなのもなんとなく分かると思います。ただしとにかく部品一個一個が重くて大きいので作業スペースの確保と床や壁の保護と工具(電動ドリルドライバー)は必須だと思いましょう。僕は大丈夫だったのですが組み付けが悪いと昇降が動かなかったりするらしいです。ネジの締め方(対角締め、増し締め)、配線のコネクタの挿抜確認はしっかりやっておくと後で確認したりする手間がなくなるので、落ち着いて時間をかけて組み立てましょう。 基本的にはやっぱり重いので一緒に誰かが作業してくれたほうが楽で安心なのは間違いないです。

一週間ほど使ってみて

間違いなく快適になりました。もともと使っていたのがそんなにしっかりしたデスクというわけでもなかったというのが大きいですが、全然揺れることもないので剛性は本当に高いと思います。FlexiSpotさんの天板が厚さ2.5cmあるので、マイクアームやディスプレイアームなんかのクランプで留めるような部品も安心して固定できます。

肝心の昇降部分についても、メモリが3つあるので僕は「作業用」「スタンディング用」「レースゲーム(ハンドルコントローラ)用」に割り当てました。昇降時のモーター駆動音なんかも静かで、深夜に動かすのも安心ですし、昇降速度も速いので高さを変えるのも億劫にはなりません。アラーム機能はスマートウォッチやアクティビティロガーで「同じ姿勢になっていたらアラートを鳴らす機能」を使ってる人にはあまり意味がないかなぁとは思うのですが、特に自宅での作業でそういうの付けずに集中するような人には気分転換や座り疲れの予防に良さそうだなって思いました。まだ組み立てて一週間ほどしか使っていない上に、この一週間は諸事情でリモートワークではなく出社していたために使い倒せているわけでもない状態なのですが、長く付き合うデスクはいいものを入れると捗る気がしてきますね!

チラシの裏の話

昇降時にケーブルを繋いでいる機材が落ちる

PCの裏にHDMIセレクターやHDMIセパレータ等のHDMIケーブルを束ねてつなぐ物があり、一番高くしたときにケーブル長としては余裕があるのを確認していたのですが、引っかかったりして机の上からずり落ちてしまうケースがあったのですが、セレクター等に地震用の滑り止めシートを貼り付けたら解決しました。

www.monotaro.com

梱包がすごく厳重

DroidKaigiのスタッフとかをしている都合で梱包を良くするのですが、届いて箱を開けて真っ先に出た感想が「梱包のガチ具合がすごい」でした。天板の角を保護する部分の素材がダンボールのみじゃなくて発泡スチロール、ウレタン混合になってたり、脚もすごく分厚いダンボールとウレタンを使いながら隙間がないように配置されてて、すごかったです。

f:id:e10dokup:20201025003527j:plain:w640
これがプロの梱包ってやつですか

昨今リモートワークが盛んなので環境を構築した話

どーも、どくぴーです。

昨今ご時世的にリモートワークがお盛んですね。 自分も絶賛リモートワークなうなので、お家で開発したり、ビデオ会議したりしています。 暗い話題が多くなりがちですがそんなにめげずに散財の証…じゃなかった、リモートワークでも諸々効率化させるために用意したものの話をしましょう。

家具

そもそも大事ですね。上京した当時から使ってる7000円くらいのどこのブランドかわからない140x70cmのデスクと6000円くらいのドウシシャのオフィスチェアを使っています。 そんなに困っていないんですが、会社のローテーブル勢の人とかを見ていると「腰が大変なことになった」とかなんとかでAKRacingのゲーミングチェアだったりを揃えようとしているのを見ると座る環境って大事なんだなぁと思います。会社の椅子、メッチャいいんだなって思います。

140cmもあれば余裕なのでは、とは思っていたのですが、デスクの左半分に

gaming.logicool.co.jp

こんなのが装備されていて、半ばレースゲーム専用のスペースと化しているので、生きているスペースは実質半分ってところです。

モニタ

kakaku.com

@puhitaku から譲ってもらったEIZO FORIS FS2332を使っています。足を引っこ抜いてVESAマウントにこれまた貰い物のモニターアームを装着して使っています。 PCの出力以外にもPS4,Switch、自作PCの出力にも使っているので4入力のHDMIセレクターを挟んでいます。ゲームの録画も出来るようにAVerMedia AVT-C285もキャプチャ後段に刺さっていますがそれはまた別の話。

開発環境

会社/自宅のMacBook Proを付け替えながら使っています。会社にいるときは自作キーボードのMint 60とMagic TrackPadを使っているのですが、今の机だとディスプレイを体の前には持ってこれそうにないのでMBP側をメインスクリーンとして扱っています。なのでキーボードもMacBook Proの筐体キーボード。

eucalyn.shop

自作キーボード環境に戻そうとすると、多分ディスプレイもWQHDのやつにしてデスクもゲーミングスペース排除して広くして…ってなりそうですね。

ミーティング環境

リモートで仕事する以上、ミーティングもリモートなのでビデオ通話が中心になります。Slack CallとかGoogle MeetsとかZoomとか。 なんにもこだわらなければMacBook ProについてるFaceTime HDカメラとマイクで十分じゃんってなるのですが、多分部屋の照明の影響で自分だけ顔色が悪くなったり、声が通りにくかったりすると言われたりしたので、もうこうなりゃヤケだと言うことで大散財をしました。

音声周り

なんか入門ド定番らしいということでマランツプロフェッショナル MPM-1000とヤマハ AG03を購入しました。

www.marantzpro.jp

jp.yamaha.com

今となってはAmazonを見ても軒並み売り切れているらしいですね。音声周りはだいぶ改善したみたいです。ノイズが小さくなったって言われたんですが、指向性があるのも多少あるのかなマイク自体はオーディオテクニカのAT2020とかが競合製品なので、そっちを狙うのはありかも。これを書いている時点ではまだサウンドハウスには在庫があるみたい。

www.soundhouse.co.jp

ちなみに、カメラにマイクが映り込むと「え?YouTuber?」とか「ガチじゃん」とか言われて若干インパクトが出てしまいます。気をつけましょう。

MPM-1000はXLRケーブルで接続するので、PCに接続するためにはXLR端子を挿せるオーディオインターフェイスが必要なので、合わせてヤマハAG03を買いました。USBに直に接続できるMPM-1000Uというモデルもあるので、本当はそっちを買えば安く済んだはず…。AG03側でボリュームを調整したり出来るので咄嗟にミュートにしたいときとかはAG03のつまみをイジイジしています。

これらの機材はDroidKaigiのセッション録画環境構築のために購入したので実際買ったのは3月の頭とか、そんなころでした。気づけばセッション録画では使うことなく、ビデオ通話で使うことになるとは…。

動画周り

こうなりゃいっそビデオ通話の映像も画質を良くしたいぜということで、カメラ周りも機材を調整しました。カメラ自体は手持ちのSony α7IIIとSEL24105Gを使っています。

www.sony.jp

www.sony.jp

どう見ても明らかにオーバースペックなんですが、今家にある機材がこれしかなかったので登板です。LUMIX G8/G9 Proとかもあるんですが、諸事情で会社で使ったあと置いているうちにリモートワークに突入してしまったので回収が必要そう…。

カメラからはHDMI出力で映像を引き回してPCに取り込んでいます。PCにHDMI出力を取り込む際にはHDMIキャプチャが必要なので、そこはj5Create JVA04を使うことにしました

JVA04 USB Type-C ゲームキャプチャーjp.j5create.com

HDMIパススルー対応のHDMIキャプチャです。HDCPは非対応なので、Macの出力とかを直接つなぐと映像を拾えなかったりします。カメラのHDMIとかPS4、Switchは行けるのでゲーム配信もできそう。
こちらもDroidKaigiのセッション録画環境のために購入したものでした。ちなみに2入力を実現するためにHDMIキャプチャはもう一台、I-O DATA GV-HUVCを持っています。

www.iodata.jp

その他

リングフィットアドベンチャー

運動不足不可避だったので、仕事がスイスイ進んだ日はリングフィットアドベンチャーをしています。まじで買えないゲームなんですが、奇跡的にNintendo Storeのダウンロード版を1月に購入できたのがラッキーでした。

www.nintendo.co.jp

今は運動強度25前後でワールド13でやっています。レベリングをしていたわけじゃないんですが、クエストこなしながらガシガシリングコンを押し込んでたらレベル130になってしまったので多分推奨レベルとかガン無視してて、RTA動画を先に見てリングコン押し込み走法を覚えるんじゃなかったという気持ちです。バンザイスクワットが超きつい。
あと、気分的に柔軟体操もはじめました。もともと体がめちゃくちゃ硬いのでなんとかしたかったんですが、少しずつだけど効果がある実感をしています。

サンコー おひとりさま用超高速弁当箱炊飯器

www.thanko.jp

これもリモートワークが始まったから買ったものじゃないんですが、秋葉原をぶらついてたらたまたまサンコーレアモノショップの店頭に置いてたので買いました。
気軽に1合までならサクッと米が炊けるので、炊きたてご飯が簡単に味わえます。おかげで自炊が捗る。
買っちまったツイートをしたらサンコーレアモノショップの中の人に補足されてTwitterでパスタ茹でたり炊き込みご飯炊いたりしてる人がいるのを教えてもらいました。

部屋の大掃除

東京一人暮らしだと部屋はせいぜいそんなに広くないので散らかってると気が滅入って仕方ないのでリモートワークが始まった週の週末に大掃除を決行しました。おかげさまで足の踏み場ができてハッピー。リングフィットアドベンチャーもはかどっています。

そんなこんなで

デスクの上はこうなりました。はっきり言って汚いので整理したい気持ちがあります。

f:id:e10dokup:20200412225040j:plain

ここまで揃えるとゲーム配信とかもできちゃうよなぁという気持ちになってきたので、レースゲームかリングフィットアドベンチャーをやってる様子をTwitchなりで流してもいいんじゃなかろうかみたいな顔になってきました。マイクもあるしPodCastとかもしたいななんて、色々妙なことを考えています。

飲酒プログラミング失敗ログ

本記事は飲酒プログラミングAdvent Calendar 2019の記事です。

adventar.org

TL;DR

  • 飲酒プログラミングに失敗しました
  • お酒は飲みました
  • 部屋の掃除をしました

はじめに

去年もやったんですが飲酒プログラミングをしました。金-土の今日くらいまで飲酒しながらプログラミングして進捗を出そう的な。
実際飲酒してプログラミングしてある程度進捗を出したんですが特に成果が出なかったのでただのログになります。

ログ

2019/12/6(土)

21:00-22:00 ランニングする
22:00-22:30 シャワーを浴びる
22:30-25:00 満を持して飲酒プログラミング
25:00 就寝 .

とりあえず夜も遅かったのでセブンイレブンのしたらば(プレーン)をつまみにサッポロ黒ラベルをキメました。
作業内容としては新規Androidプロジェクトのひな形づくりです。そんなに規模が大きくないプロジェクトを対象に1からDaggerを組み込んだMVP構成のプロジェクトテンプレートっぽいのを作り出しました。
ココ最近本業とかでDagger周りでハマることが多くてふええって顔になってたんですが Android Dagger codelab やMaster of Daggerを読みながらDagger周りの再勉強をしてたんですがようやく仲良くなれた気がします。詳しくは別の記事にでも書く…つもりです。

2019/12/7(日)

08:30 起床
08:30-09:30 支度
09:30-10:30 歯の定期検診で歯医者に
10:30-11:30 朝食
11:30-12:30 DroidKaigiの資料構想練り
12:30-13:30 昼食
13:30-17:30 部屋の掃除
17:30-18:30 夕食
18:30-20:00 DroidKaigiの資料で使うサンプルアプリの開発を始めた
20:00-今 このブログを書いている

飲酒タイミングは夕食時にもう一本のサッポロ黒ラベルでした。
全ての敗因は部屋の掃除をしたことです。部屋がきれいになったので反省はしていません。
ちょくちょく出てきてますがDroidKaigi 2020に登壇することになりました。40分も話すのは初めてなので緊張してます…。
Android Studioを使ったデバッグ周りの話をするのでデバッグにお悩みの方はぜひお話しましょう :pray:

f:id:e10dokup:20191207210942p:plain

考察

飲酒するとパフォーマンスが落ちることがわかりました。当たり前ですね。
アルコールが抜けてきたのでちゃんとプログラミングします。すいませんでした。

Bonfire Android #5 レポートを書くのが遅れたらJetpackに大リリースが来てた

はじめに

開催からだいぶ空きました(忙しくて時間がとれなかった…)が、8/19に開催されたBonfire Android #5 に参加してきました

yj-meetup.connpass.com

なのでレポート的に各発表をまとめようと思います。今回のテーマは「Jetpackとサービス」ということで、Jetpackに関連する話題を中心とした発表が揃っていました。

navigationを見据えたリファクタリング~マルチモジュール化を添えて~

木内 啓輔さん (@fei_kome) ◆ ヤフー株式会社

speakerdeck.com

実装・運用されている期間が長いアプリをマルチモジュール化・navigation componentsをする際に考えられていることについてお話されていました。

マルチモジュール化自体、近年トレンドになった話題で(僕はDroidKaigi 2018でマルチモジュールに関する話を初めて聴いて、そこから話題になったと感じているだけかもしれないです)、やはりそれ以前からずっと開発されていたアプリは「マルチモジュール化されることを想定していない」「モジュール分割に耐えうるような依存関係・設計ができていない」という状態にあると思っています。

それを踏まえて、実際にマルチモジュール化を実現するためUI-Presenter間の相互依存を解消するための腐敗防止層的なInterfaceを作ったりすることでnavigation componentの導入を視野に入れた切り分けを実現するといったリファクタリング過渡期の実装tipsについて紹介されていました。

マネーフォワードMEにおけるJetpackの活用事例

syarihuさん (@syarihu) ◆ 株式会社マネーフォワード

speakerdeck.com

syarihuさんが以前他で発表された内容も織り交ぜながら、マネーフォワードMEがどのようにAndroidXを始めとするJetpackの導入を行っていたのか、導入から1年経って何が変わったのかについてお話されていました。 マネーフォワードMEでのJetpackの導入は

  • 手入力画面のリファクタ、設計変更を含めたJetpack導入
    • MVVM by AACな設計に変更
    • Dagger2、Jetpack(ViewModel/LiveData)の導入
    • チームメンバー(新卒を含めた)への設計のフォロー
  • 月額課金機能へのPlay Billing Library導入
    • LiveData、ViewModel、Lifecycleを用いてBillingViewModelを作り、どの画面でも課金機能を作りやすい状況に
  • 入出金履歴画面へのBottom Navigationの導入
    • 複数の遷移元が存在し複雑になってしまった更新リクエストをRxJavaのBehavingProcessorとLiveDataを用いることで簡単に扱えるように

という感じだったそうです。導入を始めてからはおおよそ1年とのことで、古い機能の刷新と並行して行う機会が多かったようで設計適用のためのリファクタではなく、多くの部分に導入を進めることができたことや、このJetpackの導入、設計変更によってテストの記述効率の向上を果たせたとのことでした。

Paging Libraryでのアイテムの更新

釘宮 愼之介さん (@kgmyshin) ◆ 合同会社DMM.com / CTO室エバンジェリストチーム

speakerdeck.com

Paging Libraryを使って、チェックボックスの操作といったリストのアイテムの更新をどのようにUIまで反映させるかについてお話されていました。 基本的な実装手順からよく躓くポイントとして

  • アイテムがアップデートされない
    • ItemRepositoryに新しいデータを保存する
    • DataSourceをinvalidateして再取得を走らせる
  • 更新はしたもののスクロール位置が急に最初に戻る
    • initialzeKeyがPageKeyedDataSourceを使ってる限りnullになるから
    • 対策としてRoomを使う
      • DatabaseとDaoを作ることでDataSource周りをよしなに作ってくれる
      • マイグレーションが大変、このためだけにDBを持ちたくない場合はInMemoryでも使える
    • Roomを使わなくてもできる
      • BoundaryCallbackを扱うItemDataProviderを自前で実装することで実現できる
      • Repositoryがページ単位を、DataSourceがItem単位を扱うと考えて実装する

それぞれのやり方についてサンプルも公開されているので、気になる方は確認してみましょう。

github.com

Roomとコルーチンと私

荒木 佑一さん (@yuichi_araki) ◆ Google

docs.google.com

Room 2.2.0-alpha02でのアップデートとして様々な機能が追加されましたが、その中でもCoroutines Flowを主眼において解説されていました。

Room自体、2.1.0でsuspend functionに対応して、coroutineで書くとメインスレッドでinsert等のメソッドを実行してもsuspendしてバックグラウンドに行ってくれる、というような解釈をしてくれるようになっており、更に Transaction アノテーションを付与することでcoroutinesが取り消されたり、エラーになったときに処理全体を取り消したりできる機能が追加されています。

Room 2.2.0では、これらに加えてCoroutines Flowに対応しており、Coroutines Flowの特徴である

  • コールドストリーム(cf. Channel:ホットストリーム)
    • アクセスされるまで処理が実行されない遅延評価
  • コンテキスト保持
    • Dispatcherを指定できる
  • 例外透過
    • .catchで例外を補足できる

といった恩恵を受けることができ、DB操作を監視した処理ができるようになるなどしています。

また、RoomのDaoの内部実装でどのようにCoroutinesを実行しているかという話や、Roomが非同期実行の際にトランザクション、スレッドを適切にハンドリングしていることについても言及されていました。

jetpackのNavigationと関連UIコンポーネント

樫村 実紅さん (@k_miku) ◆ ヤフー株式会社

www.slideshare.net

開発されているアプリにNavigationを導入された際のことについてお話されていました、ヤフーニュースアプリ、一つの大きい改修を行う際には一つ新しい技術にチャレンジすることを掲げているそうですね。

各画面の遷移をなめらかにするために1-Activity / n-Fragment構成を実現すること、Fragmentの遷移管理の負担を下げること、トレンドへの追従を目的としてNavigation導入を行ったということで、実際に導入する中で躓いたポイントとして

  • ActionBarと連動をさせようとすると仕様に合わない
    • Resource XMLに定義した文字列のタイトル反映はできるが画像やEditText、動的な文字列といったものは出せない
    • 結果としてActionBarと連動させることは諦め、各画面でActionBarをそれぞれ操作することにした
  • 画面遷移時のアニメーションのカスタマイズ
    • NavigationUI#setupWithNavControllerを使う際、デフォルトで指定されているアニメーションしか使えない
    • OnNavigationItemSelectedListenerを自前で作り、その中でNavOptionsをbuildすることでカスタムのアニメーションを設定した
  • 画面遷移時に遷移以外の操作を行いたい
    • 遷移したというユーザ行動等のログを取る必要がある
    • 同様に、OnNavigationItemSelectedListenerを自前で作り、その中でItemのIDをみてログを送信した

という手段とをって解決されていました。

あまりにも遅筆過ぎた結果Jetpackが大リリースしてた

完全に怠慢の限りなのですが、イベント後しばらくたった9/5のタイミングでJetpackに大きなリリースがやってきて、いろんなコンポーネントがstableになったりしました。Room 2.2.0もrc1になったりしています。

developer.android.com

speakerdeck.com

先日あったca.apk #8で発表された資料を引用するのですが、Activityも1.0.0でFragmentのバックハンドリングが onBackPressedDispatcher で行えるようになっていたり、Activity(1.0.0) / Fragment(1.1.0)でLayout ID Constructorが追加され、layoutのリソースIDを引数に渡すことでsetContentView / onCreateViewを省略できるようになったり、いろんなトピックスが起きています。

Androidに限らず、この手のアップデートがすごい勢いで行われるのでBonfireを始めとした勉強会で新しい知識を気軽に知ることができるのはすごい素晴らしいと思います。インプットした知識を現場に還元し、また新たなアウトプットを生み出せるといいなと思いました。

最後に

Bonfire Androidを主催してくださったヤフーさん、本当にありがとうございました。レポートを書くのが非常に遅くなってしまい大変申し訳ありませんでした… :bow:

Bonfire Android #4 に参加してきた #yjbonfire

久々に勉強会に行ってきたブログを書きます。

Yahoo! Japanさん主催のBonfire Android #4にブログ枠として参加してきました。

yj-meetup.connpass.com

Bonfire Androidでは毎回テーマを決めてYahoo! Japanさん内外から登壇されるのですが、今回は「UI」がテーマと言うことで、5人のデザイナー・エンジニアの方がチームでのデザイン手法、UI開発といったトピックを発表されていました。本記事では、各発表を振り返っていこうと思います。

Yahoo!乗換案内アプリでのデザイナーの役割について(山浦優樹さん)

エンジニア・デザイナーそれぞれ二人づつで開発されているというYahoo!乗換案内アプリでのデザイナーの立ち回りについて話されていました。初期はデザイン工数等の関係で以前はAndroid/iOSで共通のデザインを使っていた状況からMaterial Designを始めとしたAndroidデフォルトなデザインへ寄せていく中で、デザイナーがMaterial Design、Theme、Design Support LibraryといったUIに関わるAndroidの技術に対しての知識を持っていったことや、実際にLayout XMLをデザイナーが編集する、というようにデザイナーができることを大きくしていく中で

  • デザイナーはUIの磨き込みに集中できるように
  • エンジニアは実装に集中できるように

という2つの環境を実現するためのデザインフローについてのお話をされていました。

一方で、実際にデザイナーがAndroid Studio上でLayout XML/Drawable XMLといったResourcesを作るという役割の拡大について、自分で触ることでエンジニア以外には得にくかった「アプリデザインではプラットフォームごとにどのパーツが使えるかを知れる」というメリットはあるもののそこに踏み込むことの難しさについても触れられていて、HTML/CSSでのWebDev領域のようなハブとなれるプレイヤーを立てることでうまく回るのでは、と述べられていました。

Material Designの変化”の中でアプリエンジニアができること(中村恵太さん)

speakerdeck.com

2014年6月に公開されたMaterial Design Guidelineにおよそ4ヶ月で準拠したラクマのフリル時代から今の新ラクマまでのMaterial Designまでの変遷に触れて、初期のMaterial Designのメリットとして

  • ユーザエンゲージメントにとどまらないメリットがある
    • 開発効率
    • エンジニアのデザインへの意識が上がる
      • デザイナーとデザインについて議論する際の共通言語になれるかも

という点があるものの

  • ガイドラインに引きずられてしまい、ブランド表現に難がある
    • Google感がやはり出てしまうため
    • iOSと比較すると全体的に暗く、画面遷移も別れてしまう

といったデメリットが有ると述べられていました。その後Material DesignにLaunch ScreenやBottom Navigationといった新しいコンポーネントや2018年5月に公開されたMaterial Design Guideline 2.0によってブランド表現が柔軟になったこと、変化を継続していくデザインシステムになったことを説明し、その中でアプリエンジニアは何ができるのかということで

  • 変化に柔軟(であろう)というエンジニアの強みをUI領域にも持ち込む
    • 個人的にはアンテナを張っている、新しい情報へのリーチが早い、ということかなと解釈しています
  • Material Designのキャッチアップをただの情報共有ではなく課題解決目線として提案していく
    • 何が表現できて、どうプロダクトに取り込めて、結果何が解決できるのかという具体的な提案

というアクションの提案をされていました。この提案のためにSketchプラグインであるMaterial Theming Editorをエンジニアが提案のためのツールとして用いることでデザイナーの改善イメージのサポートに役立てようと動いていることが興味深かったです。

自由度の高いアプリ内UIを実現するためのKARTE SDKの仕組み(中間亮彬)

ラッキングや分析、アプリ内メッセージやプッシュ通知を行うことができるKARTEのアプリSDKについて、特にアプリ内メッセージについての実装面でのお話をされていました。アプリ内メッセージへのアプローチとしてフォーマットに従って配信するネイティブ実装とHTML/CSSを管理画面上で記述するWebView実装があること、カスタマイズ性を重視してWebViewでの実装を選択したことについてまず触れ、実際にKARTE SDKの内部構成やその中でのデータフローといった技術的な要素によってWeb・アプリ双方で同じUIとしてアプリ内メッセージを提供することを実現することについてお話されていました。

UI改善に繋がるエンジニアの立ち回り(瀬戸優之さん)

speakerdeck.com

デザイナーとやり取りができる、工数の巻き戻しができる人を対象として、必要な知識がデザイナーとエンジニアで重なる部分があるUI改善のためにエンジニアはどう立ち回るべきか、というお話をされていました。

まず普段からエンジニアができることとして、デザイナーがアンテナを張っていても情報を得にくい部分である、

  • 環境について
    • ProgressDialogが非推奨になっている、というような実装レベルでのUIパーツの使用可否
    • Material Design Components(MDC)についての情報
      • そもそもAndroidXが必要
      • ではプロダクトがいつからAndroidXに対応して、いつからMDCを使えるようになるのか
  • 実装について
    • 工数見積
    • Material Design Guideline 2.0で定義されたExtended FABがボタンで作れること
    • ダイアログがダイアログを出すのような二重表示ができないこと

というような情報を共有することで早い段階での気付きにつなげていくという点に触れ、そのためにコミュニケーションポイントを増やす必要があり、頻度が高いコミュニケーションほどコストが掛かるものの、Material Design Guideline輪読会のような定期的な会を行うことでMaterial Designの知見や共通認識・AnimationやComponentといった環境や実装の話といったコミュニケーションを実現するという提案をされていました。また、エンジニアが気にするべきデザインのチェックポイントとして

  • 画面回転や横レイアウト
    • 直しにくい、工数的に厳しい場合は画面回転・横レイアウトを許可しないという手もある
  • Empty Status
  • オフライン時挙動
    • キャッシュを出すのかそもそも動作を止めるのか
  • マルチウィンドウ、縦長ディスプレイ
    • そもそも非対応にするのか、UIの要素を伸ばすならどこか
  • コードレベルでのチェックポイント
    • エラー通知
      • try-catch / onErrorのフィードバックが存在しているか
    • 仕様が複雑化していないか
      • 異常に複雑な実装は仕様からすでに複雑になっているかもしれない
  • ユーザ目線でのチェックポイント
    • 操作の手数
      • エンジニアが操作に疲れるならユーザも疲れる
      • 大体1画面3操作を意識する
    • RAILモデルを利用した動作速度ベンチマーク
      • 操作から100ms反応が無いとユーザは困惑する
      • 1000msかかるとユーザの離脱率が上がる

という点を挙げられていました。日頃の仕事でも考えているものもあれば、全然気にしていなかった事もあって、すぐ効果が出るわけではないものの、これから意識して実践することによって少しでも改善に貢献していきたいと思いました。

エクストリーム・プログラミング開発におけるUIテスト〜ライブコーディングを添えて(飯島彩輝さん、松田悠吾さん)

LEAN XPを導入しているヤフオクチームでの実際の開発事例をライブコーディングを交えて説明されていました。

何を作るか?を絞るLEANとどうやって作るか?を絞るXPを組み合わせたLEAN XPにまず触れ、その中の要素としてペアプログラミングテスト駆動開発、ユーザーストーリー(とストーリーポイント)を始めとしたものがあること、実際にヤフオクチームで実践しているPivotal Tracker上でのユーザーストーリー管理からのじゃんけん見積もりによるストーリーポイントを決定することによるチーム内での認識齟齬の解消、片方がテストを先に組み、片方が実装を行うペアプログラミングによるテスト駆動開発をライブコーディングしていく中で

  • 同じ画面を見ながら開発で早い段階でミスに気づくことができる
  • どういう実装をチームの人がするのかをリアルタイムで見れることでレビューコストを減少できる
  • テストコードが仕様書と化すので、開発へ大きく時間を割くことができる
  • ユーザーストーリーの実装ごとにリリースを行うことで効果を都度確認することができる

という利点を挙げられていました。また、実際の導入効果として、

  • シナリオテストの失敗率の大幅な減少
  • 手戻りが減った

といった点をお話されていました。

後記

登壇者の方々、主催、運営のYahoo! Japanさん、本当にありがとうございました!
ちゃんとレポートをしたのは久しぶりなのですごく疲れました。

エンジニア懇親会というと、寿司!ピザ!みたいなイメージなのですが、今回の懇親会はすごくおしゃれな感じでした。 きっきパイセン( @dnc_pop30 )に聞いてみたところ、ツイートに上げた写真を使っていいと言われたので飯テロ写真を置いておきます(ありがとうございます)。

DroidKaigi 2019に参加していました(スタッフ)

感想録です。DroidKaigiも終わって2週間位たったのでエモい気持ちも落ち着いてきたかな?という感じなので気持ち的なものを備忘しておこうかなという…。

今年もDroidKaigiが行われました。 DroidKaigi 2016からなんやかんやで就活といい感じに予定を合わせて参加させてもらったり、上京したので気兼ねなく参加できるようになっていったのですが、今回はスタッフになっていました。登壇者になりたいなーって言っていたらスタッフになっていました。

スタッフになるまで

2018に参加する前後(だった気がする)に @pside さんとランチに行ってそのタイミングで「スタッフ興味ある?」「それなりにはあります」みたいな会話をしていたら、忘れた頃にDMでスタッフにリクルーティングされました。「一緒に血反吐を吐こうな」という言葉で契約(?)を結んだのがとても印象的でした。

何してたの

当日に向けては大体Codelabs班・写真班として活動していました。

Codelabs

Day 1/2ともにRoom5(ロビー入って左に進むとある小さめの部屋)でやっていたCodelabsのスタッフを主たる業務として動いていました。いわゆる「メンターさん」的な感じにしようかなーと意識はしていて、大体次のムーブをできればいいなと思いながらこなしていました。

  • 部屋の隅に固まらない、くるくる歩く
  • 手の上がった人がいればすぐ行く
  • 手の上がっていない人にも軽く話しかけたり、困ってそうであれば一緒にコード見てみたり
  • 本当は今何をしているか、どうすれば解決できるかをうまいこと理解レベルの溝を埋めながら話ができると良かった
    • 気にはしていたものの多分できてない…

「初心者からその先へ」みたいな感じをキーワードに当初はしていて、Google Codelabs で選べるものとは別に以下のような題材を選んでいました。

developer.android.com

Googleが2018/10に公開したAndroidの基礎コースですね。ActivityやUI周りといった基礎的なコンポーネントや非同期処理、ユーザデータの保存と言ったトピックをConstraintLayoutやRoomなどの新しいポイントを使って学んでいく、という感じのCodelabs集という感じです。

medium.com

github.com

App Improvement Challengeという、DroidKaigiのためにCodelabs班で開発したオリジナルのCodelabsです。イメージとしては「Androidを始めた人が現場に入って、案件とどう向き合うべきなんだろう…?」みたいなものを題材に、既存コードにどう影響を加えずに手を入れていくか、また余裕があるときに Jetpack Architecture Guide を基準としてどうリファクタしてくべきなんだろう…?みたいな思いを込めていたはずだったのですが、題材開発がやたらと盛り上がった結果何かよくわからないけどすごいものが出来上がりました(ちょっと難易度がハードコアすぎた感があるので反省点かなと思ったりしています…)。このタイミングに「修正すべき点があるコード」というapproveを行うために LBTM(Looks Bad To Me)という謎の褒め言葉が生まれました。メイン開発をしていた @ymnd さん、 tomoya0x00 さん、本当にお疲れ様でした!

このCodelabsにずっと入り浸って参加してくださった方々がいらっしゃったり、参加してくださった方々からリファクタの結果をPRとして送っていただいていたりしていて、なんか語彙力がない感じでいうと「すごい、うれしい」としか言いようのない感じでした。本当にありがとうございました!

ちなみにこのリポジトリの中で一番好きな部分は計測通信を行っている(という体の) IngestManager クラスとやたらめったらテクニカルなAsyncTaskが跋扈する記事一覧を取得する loadTopStories メソッドでした。

カメラ班

上のアルバムに載せるような写真を撮影をするなどしておりました。腕章付けてカメラ2台を肩から下げて、基本Codelabs部屋を常駐しながらワイワイ撮影していました。

装備としては

自前:Sony α7II + SEL24105G + Godox TT350s(ほぼストロボ炊いていない)
レンタル:Sony α7III + SEL70200GM

という感じで二日間過ごしていました。新古品からα7IIを買っただけだったのでα7IIIにあまり食指が動いていなかったんですがα7IIIってすげぇんだなと思いました。AF-Cで瞳AF追尾できるってすごい。

後日、社内で撮影の用事があったので自前装備を使ったんですが足りねぇ…!!という気持ちになったので近い内にSEL70200G(GMじゃないよ)を買うことになりそうです。さっき発表されていたタムロンの35-150mmとかすごくいいなぁと思っているのですがEマウント用出ないですかね…?

Fireside Chat

Codelabs班の一環なのですが、パーティ前にホールでやっていたFireside Chatの話題の用意やスライド作成といった下準備をやっていました。当日は撮影担当をしていたので司会は @satsukies@shanonim さんにお願いしました。@takahirom さんを始めとした公式アプリメンバーの方々にも急に参加をお願いしてしまったんですが最終的には沢山の方々に来ていただいて、盛況だったと思います(盛況すぎてほぼ最前にいないと話がよく聞こえてこないようなレベルだったので申し訳ないです…)。本当にいい感じに進めていただいてありがとうございました…!

Visualizer

同時期にスタッフに参加した @satsukies@pside さんからVisualizerの開発を引き継いだので、二人で2019年対応をしていました。これまでのVisualizerについては次の記事を見ると良さそうです。

p-side.net

OP前に流れていたアレです。リポジトリも今の時点で公開されているものをそのまま引き継いで二人で開発していました。

やったこととしては大体以下の感じでした

  • 画面サイズが去年の4:3から16:9に変化したのでそれに合わせて画面を有効に使えるように変更してみた
    • 会場では左右が若干見切れていたみたいでくるくる回っていた部分がよくわからない感じになっていたぞ
  • 色とかロゴの2019化
  • スライドの告知文言の追加・変更
  • VisualizerのVisualizer(?)部分が動かなくなっていたので動かせるように修正
    • ChromeのAutoplay Policyのせいでユーザ起因でないとAudioContextが取れなくなってたので、マイクが使えなくなっていた
    • なのでもうSTARTボタンを押すと始まるようにした(安直)

satsukiesもぼくもJSよくわかんないReact.jsよくわかんない言いながらなんとかそれっぽくなったので一旦満足です。ただ、コードベースには昨年比でほとんど手を加えていないのと、Typescript化したいとかいうissueが立っていたりするので勉強して来年頑張る…頑張る…?という気持ちです。

ほか

Codelabsの参加者アンケートでお配りしてめっちゃデカイ缶バッジ、自称ドデ缶バッジを作っていました。直径は10cmです。

あとは開催後に荷物の片付けをしたりしていました、帰りは @satsukies と @ymnd さんとsteamだったりゲームボーイカラーだったり、ゲームの話をしながらゆるゆる帰っていました。

終わってみて

なんやかんや12月付近からすっごい慌ただしくなったなという感じでした(忙しくてもなんやかんやOK出してくれた会社の人には感謝です…)。

とは言うものコアな部分にはあまりいなかった(ここで言うコアは会場周りとか司会周りとかの人だと思っています)ので、本当に忙しい人はもっと忙しかったんだよなぁ…と。

来年もなにか力になれるといいなと思ったし、来年こそ忙しくなってもいいから登壇をしたいという気持ちになりました。来年は時期が来たらCfPを頑張って書いていこうな。

かしこ

お酒を飲みながらWorkManagerのCodelabsをしてお勉強をした

なにこれ

本記事は 飲酒プログラミング Advent Calendar 2018 - Adventar の22日目の記事になります。

え?投稿日がそれより遅いって?知らないなぁ…。初日がまだ未投稿らしいのでそれより早ければセーフという謎理論で挑みたいと思います。

どうやらdescriptionを見ている限り、お酒を飲みながら何かしらのプログラミングに関するアクションを起こせばセーフということで、前々から理解しないとなぁと思っていたWorkManager周りのお勉強をCodelabsベースで概観だけでも把握すべくお酒を飲んでダラダラと実行しました。

書き始める前に

やっぱりお酒を飲むということで今回の飲酒の証拠を残しておきます。

ヤッホーブルーイングのTOKYO BLACKです。なんでまともに正面から撮らないんだこいつは。
ちなみにこれはCodelabs実践中の飲酒で、記事執筆のためにスーパードライと余っていた久保田 千寿も摂取するなどしております。昨日は飲んでコード書いていたら終了しました。

WorkManagerとは?

Android Jetpackのひとつであり、アップロード処理やフォアグラウンドで実行してしまうとUIを長時間ロックしてしまいそうな適宜実行されたり実行保証が必要なバックグラウンドタスクを行うArchitecture Componentです。

これまでAndroidのバックグラウンド処理を扱う物というとForeground Serviceでベッタリ書いてみたりJobScheduler, FirebaseJobDispatcher, AlarmManagerといったものをAPIレベルに応じて使い分けたりする必要があったのですが、WorkManager内でこれらを適切に使い分けてくれるようになります。

ちなみに現在はstable、というわけではなく、12/19にbeta01がリリースされました。思ったよりタイムリー。

Codelabsをやっていく

Background Work with WorkManager

Google I/O 2018のタイミングでWorkManagerが登場したのですが、それに合わせてCodelabsも公開されているので、これとにらめっこしながら概観を追いかけていくことができます。

ちなみに12/23時点でCodelabs内で指定されているバージョンが1.0.0-bata01になっているのですが、Codelabs中で扱っているコードがBreaking changeの発生した1.0.0-alpha13より前の物となっており、いわゆるコピペコードでは動作しないものになっているので注意しましょう。Codelabsで用意されているリポジトリはちゃんと1.0.0-beta01に追従されているのでそちらを参考にする場合は特に不都合ないと思います。

参考 -> Architecture Components Release Notes  |  Android Developers

ちなみにCodelabsではバックグラウンドで画像にブラーをかけるアプリが題材になっています。実際にブラーをはける処理はすでに実装されていて、WorkManagerにつないだりする部分だけを自分で加えていく形なので本質を捉えやすいかと。

f:id:e10dokup:20181223225018p:plain
題材となっているアプリ、画像を選んでそれにブラーをかけ、かかった画像をストレージに保存します

とりあえずWorkManagerで出てくる登場人物を知る

Worker

WorkManagerによってバックグラウンドで処理されるロジックを扱うクラス。
Worker をextendsし、 doWork() 中に実行されるロジックを記す。

doWork() の返り値となっている Worker.Result の返り値が1.0.0-alpha13で変更されており、Codelabs中に記されている Worker.Result.SUCCES という定数指定から Worker.Result.success() というような形になりました。後述のoutputDataもここに引数に入れることでよくなります。

WorkRequest

Workerを実行するリクエスト。 作ったWorkerを渡してRequestを作成し、WorkManagerに渡すクラス。このWorkRequestが実行キューに積まれる感じ。 OneTimeWorkRequest(一度だけ実行)/PeriodicWorkRequest(定期的な実行)があり、Constraintsを使って実行条件を指定したりできる。

WorkManager

依頼されたWorkRequestをスケジュールして実行するクラス。WorkRequestで指定したConstraintsを満たしつつ、負荷を分散しながらスケジュールしてキューに入っているWorkRequestを実行する。

簡単な扱い方

  • extends Worker なクラスを用意する
    • doWork() メソッドをオーバーライドして必要なロジックをそこに実装する
    • 処理の成功、失敗を Worker.Result.success() / Worker.Result.failure() でreturnする
  • WorkRequestに作ったWorkerを入れて、Requestを作成する
    • 特に指定がなく、一度だけ実行するだけなら OneTimeWorkRequest.from(HogeWorker.class) でOK
  • WorkManagerにenqueueする
    • 特になんてことはなく、作ったWorkRequestを workManager.enqueue(request) するだけ

Workerに値を渡す

ファイルを取得して実行するためにURI Stringとかが必要な場合はDataクラスがあるのでこれを使います。扱い方としてはIntentのExtraみたいな感じで、Data.Builder().putString("KEY", "VALUE").build() のようにし、WorkRequestを from で一発で作らずにbuilderを使って作ります。

OneTimeWorkRequest.Builder(HogeWorker.class)
        .setInputData(data)
        .build()

実際に受け取った値をWorker中で取り出すためには、Worker側で getInputData().getString("KEY")

複数の処理を連結して実行する。

CodelabsではChain your worksと書いてある節です。複数のWorkerを逐次実行することが可能で、題材となっているアプリでは

ディレクトリのクリーンアップ -> ブラー処理(強度に応じて複数回) -> ファイル保存

という一連の流れをchainしています。実装としてはWorkContinuationクラスを使います。 WorkManager#beginWith で起点となるWorkRequestを渡して、 WorkContinuation#then にそれ以降に続くWorkRequestを渡していき、最終的にWorkContinuation自体をenqueueすることで実行されます。

// AWorker -> BWorker -> CWorkerの順に実行されていくWorkContinuationの例
val continuation = workManager.beginWith(OneTimeWorkRequest.from(AWorker::class.java))
continuation.then(OneTimeWorkRequest.from(BWorker::class.java))
continuation.then(OneTimeWorkRequest.from(CWorker::class.java))
continuation.enqueue()

また、このままだと重複実行を許すので beginWithbeginUniqueWork にすることで重複実行を防ぐことができます

var continuation = workManager.beginUniqueWork(
        "unique_work_id",
        ExistingWorkPolicy.REPLACE,
        OneTimeWorkRequest.from(AWorker::class.java)
)

Constraintsを使って実行を制限する

WorkRequestのBuilderがsetConstraints()というメソッドを持っており、この中に以下のようにビルドしたConstraintsを渡すことでWorkerの実行を状態に応じて制限することができます。

/// 端末充電中でのみ実行するConstraints
val constraints = new Constraints.Builder()
                .setRequiresCharging(true)
                .build();

この他にも、NetworkTypeに応じて実行を制限できたり(METERED/UNMETEREDがあるのでおそらく従量課金かそうでないかを判断している…らしい?)、バッテリ残量、ストレージ残量に応じて実行を制限できたりします。

まとめ

寄った勢いなのでがっさり + この話は色んな人が先に触れている気がするのでなんとなくやってみたレポートでした。これ以外にもWorkerでの実行状態の取得(WorkStatus)ができたり、これまでAPI分岐を考えたり自前で実行可否の判定処理を実装していたりした部分が割とWorkManagerが吸い取ってくれそうでいい話感があります。

なんでこれを扱おうと思ったのかというと、以前勉強会で発表した資料がForeground Serviceをガッツリ使っていて、WorkManagerとか使ったらいいのに…というアドバイスを頂きまして、そのノリで「じゃあお酒飲みながら勉強してみますかー」という感じでした。

実際多分ググったほうが詳しい解説をしていらっしゃる方がいると思うのでほぼ備忘録です。ここまでお付き合いくださりありがとうございました。