どくぴーの備忘録

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

いい写真を最速で共有する技術 〜DroidKaigi 2024本番運用編〜

どーも、どくぴーです。

2024/9/11〜2024/9/13にDroidKaigi 2024が開催されました。今年もスタッフとしてお手伝いをさせていただきました。

2024.droidkaigi.jp

今年も車を運転して物を運んだり、いろんなことをスタッフとしてもやってたなぁと思うんですが、当日会期中はカメラをもって会場内をあっちこっち歩き回っていました。
もっているカメラにやたらとデカいsomethingがひっついていたり、謎の様相を呈していたので見かけて不思議に思った方もいるのかな〜、とか思っていました。
スキマ時間を縫って以前から試していた写真共有フローも新しく開発し直し、「写真爆速上げるくんV3」が完成したのでその本番運用の機会でもありました。

そんなわけでこの記事は参加レポートの体をした下記記事の続編となります。

e10dokup.hateblo.jp

前提:写真爆速上げるくんV1について

上記記事でも言及しているtry! Swift Tokyo 2024でお手伝いに参加した際に運用した写真を高速にアップロードするシステムのことです。
ビューワとしてPHPを多少書いた程度で、実際はほとんどなにか手を加えることなくソニー製のアプリを使って写真を打ち上げる技術検証的な要素を多分に含んだものでした。

技術検証として運用した結果、やりたいフローを実現できはしたものの以下の問題が残っている状態でした。

  • スマホWi-Fiテザリングで運用している以上、以下の課題がある
    • カメラからスマホに送る時点で遅く、エラーによる欠損が発生する。送信時の画素数を小さくしていても耐えきれない場合もある
    • 常時Wi-Fiテザリングをしている以上、スマホ側のバッテリーが最後まで持たない
    • 参加者のWi-Fiテザリングと重なったり、会場Wi-Fiが強すぎるとそもそも通信が成り立たなくなる
  • 最大1000枚オーバーの写真から必要な写真を選ぶ運営サイドの負荷がある
    • 広報で使う写真を選ぶ、幕間のスライドショーに使うなど
    • フロントエンドがページング付きとはいえ単純な写真一覧だと、時系列で並んでいるだけでは満足ではない

というわけでこれらを解決するには…作るしかねえな!ということでDroidKaigi 2024での写真爆速上げるくんV3に繋がります。

余談:V2はどこに行ったのか

V2はKotlin Fest 2024でカメラマンとしてお手伝いしていたときのものです。
システムとしては何も変化していないんですが、アップロード用の機材がPixel 8から Sony PDT-FP1 のレンタル品に切り替わっています。

これにより、渋谷ならタイミングさえ良ければpovo 2.0との組み合わせで下り1Gbpsオーバーの5G回線と有線LAN接続による端末側への転送が可能になったことでV1での問題点であったWi-Fiテザリングによる課題が解決しました。

ちなみに、このタイミングで一緒にカメラマンをしていた @KeithYokoma さんにCanon EOS 5D Mark IVからSony Transfer & Tagging経由でのアップロードを試してもらったところ、メタデータを見ているのかエラーを出したので現状のシステムはSony専用であることが発覚しています。一応直接JPGファイルをアップロードすれば関係はないんですが、それをするとストレージとビューワへの負荷が大きいのであんまり取りたい策ではないという感じです。

写真爆速上げるくんV3、つくるぞ

機材方面を整える

毎年DroidKaigi直前に同じくスタッフの @satsukies と機材を増やす(謎の)文化があるのですが、今年はPDT-FP1になりました。V2での検証の結果、行けると判断したうえでの購入です。これが僕にとってのPixel 9です(?)
べ、別にα9IIIが値上げで更に買いにくくなった腹いせじゃないんだからね!(ちなみに @satsukies もなにか色々と買っていました)

カメラについてもいつもはα9IIとα7RIVを2台持ちし、登壇者のアップや遠景を撮り分けられるようにしていました。しかしPDT-FP1の有線接続が1台にしかできないこと、Sony Transfer & Taggingの転送待ち受けが有線接続 + Wi-Fiテザリングのような併用ができなさそうなことから今年はα9IIのみでの運用に変更し、レンズを付け替えるためにPeak Designのスリングでレンズを詰め込むことにしました。PCとかも持てるじゃんと言いながらあれこれ突っ込んだ結果、ほぼ使わなかったくせに開催2日後も右肩が激痛に苛まれているので反省しています。

ちなみにカメラ自体にはどうやってつけていたのかというと、PDT-FP1には背面に三脚用のネジ穴があるので、同じく三脚用のネジ穴があるSmallRig製のL字プレートを装着し、ネジで結合する形で装着しています。

システム方面を再開発する

設計が完了したタイミングでは8月も半ばに来ており、ここからFTPサーバのアップロードとかを調べる余裕がないし、サービスデプロイも学生の頃試した程度で調べながらになります。フロントエンドも新しく作るとなると2018年頃の知識しかないので調べながらです。ということで一旦FTPアップロードに関してはV1時代のものを流用することを決定しました。それにより、システム全体を眺めると以下のような構成になります。

これで見れる

なお、「写真爆速上げるくん」と英語で名前につけるのはシュールだったので、ここでプロジェクト名を考えました。Photospeedwayって名前をつけたんですが、これはDroidKaigi 2024の2日後に富士スピードウェイ世界耐久選手権というレースを見に行く予定があったので、それにちなんでつけています。実際スピードがほしいのもあるのでちょうどいいかなと。略称は元ネタにちなんでPSWとかPISCOとかですかね?

バックエンド編

せっかくAndroidアプリ作ってるんだし、Kotlin Multiplatformでサーバサイドを作るかぁと思ったんですが、ドキュメントもある程度は揃っていて、調べながらで進められるだろうとJVMでKtor + Exposedを使い開発することになりました。サーバーサイドKtor、エンドポイント定義のDSLがわかりやすくてだいぶとっつきやすいですね。

ktor.io

バックエンドとしては、とりあえずFTPサーバの情報を登録してイベントアルバムとしてDBに登録する機能、イベントアルバムDBのアクセス情報から写真一覧を返す機能、お気に入りに登録した写真を別のアルバムとして返却する機能を実装しました。お気に入り登録はV1の問題点である写真を選ぶ運営サイドの負荷削減を目的としたもので、イベントアルバムレベルで保持されることでそのアルバムを見ることになる人全員が同じお気に入りを確認することができます。なお、お気に入りから消す機能を作るのを忘れました。

また、Firebase Authenticationによる認証をイベントの登録機能にはかけており、指定された人だけがイベントの登録を行うことができます。時間の都合、新規登録画面などはなく、Firebaseのコンソール上で裏で登録をすることになりますが、今のところ広く公開されるサービスではないので多分大丈夫でしょう。

デプロイ先としてはGCPAWS…ではなく、依然使ったことのあるさくらのVPSを選択しました。ローカルと同じ感じで環境を立ち上げられたらいいなと思い、KtorのプロジェクトでビルドしたJARファイルやクレデンシャルをSCPなりでアップロードしたあと、Docker Composeを使って立ち上げるという感じです。Gitのプロジェクトクローンからのコマンドによるビルドがいいのかな〜とも思っていたのですが、実際に借りたVPSが2 Core/1GB RAMのものだったのでビルドを始めた瞬間にターミナルがうんともすんとも言わなくなってしまったので諦めました。さくらのVPSの管理画面で確認したらCPU使用率が100%にぺったりと1時間位張り付いていて「ごめんな…」と思わず声が出たのをよく覚えています。

なお、CORSのことを全く認識しておらず、このあとのフロントエンド開発中にひたすらKtorのCORS周りのドキュメントを読み漁ることになります。この辺はネイティブアプリメインだと認識しないので難しいですね。

ktor.io

フロントエンド編

(さっきと同じ書き出し)せっかくAndroidアプリ作ってるんだし、Kotlin Multiplatform(Kotlin/Wasm)でフロントエンドを作るかぁと思ったんですが、調べてみるとKotlin/WasmはSafari上ではまだサポートが怪しい(Wasm GCをサポートしていないみたい?)ので諦めました。いろんなフレームワークを調べてみたところ、Vue.jsがチュートリアルもわかりやすく、とっつきやすかったのでこれを使って先程のバックエンドにaxiosでAPIアクセスをしながら実装することを採用しました。ちょうど知り合いにVue.jsを推している人もいたので、わからなくなったら質問してみようかな〜と考えたのもあります。

実際にできたもの。ページングの動作確認を擬似的に10枚単位で行っていたのが災いし、運用当日に酷いバグに気づくことに

最終的にはGitHub Pagesでデプロイすることになるのですが、Vue.jsによる実装は先述のCORSの件に時間を割いた以外は比較的簡単に進められました。あんまりデザインに気を使ってる余裕がないのでVuetifyを使ってMaterial Designな感じで進めることができたのも大きいですね。Androidアプリと違ってViteによるオートリロードなどですぐ実装したものが確認できたりしたのが特に楽ちんでした。

vuetifyjs.com

Androidアプリ編

ここまで作ったらもう十分だったんですが、Androidアプリも作ってみようということで急遽クライアントアプリを開発することにしました。会場を歩きながらXアカウントで告知する、みたいなケースを想定すると、アプリから直接写真がダウンロードできるとすごく都合がいいな?と思ったので一旦作ってみた次第です。

実際にできたもの

設計的にはNavigation Compose、Material 3、ViewModel、Kotlin Flow、Dagger Hiltといった「今から新規にアプリを作るならどういう構成で作る?」みたいな面接っぽい質問に自分で回答するような気持ちで考えました。規模感的にマルチモジュールは採用しなかったんですが、ある程度馴染みのある構成だったこと、バックエンド、フロントエンドで慣れないものを触り続けてきたあとだと異様にスピード感をもって開発できました。やはりひとつある程度技術的に慣れのあるものをもっておくというのは良いですね。

いずれはスライドショー表示にも対応したいなと思い、このタイミングでAPIにもExifを解析して撮影情報を返すエンドポイントを増設し、全画面表示を出来るようにしてみました。意外とそれっぽいものができて嬉しかったです。

実際に動いたものの出来には満足だったんですが、画像の読み込みが少し不安定でリロードとか再起動をひたすらに繰り返していました。多分Coilのキャッシュ設定がミスっていたので、改善するならそこだったり、時間表示をkotlinx-datetimeのInstantで担っているので時間レベルでのフィルタリングを実装して読み込み数を減らす必要がありそうです。

このアプリは別の場所でとある形で再利用されることになったのですが、それについてはまた別のお話ということで。

最後に:DroidKaigi 2024でのV3本番運用を経て

基本的にはシステムは満足に動いてくれていました。幕間のスライドショーにも、Xの投稿にも「え、今の写真じゃんこれ」となる写真が沢山出せたので、カンファレンスカメラマンは良い写真を撮ってくれるけどすぐ出せないのでスマホによる撮影が結局必要、みたいな課題を解決できる良いものができたと僕も満足しています。自分が使って「便利じゃねえの」と思うものを仕事じゃない部分で作れて嬉しかったですね。

実際に起きた不具合や写真絡みのイベントもいくつかあったので、それは箇条書きにしておきます。

  • 初日の夜にシステムが最新100枚までしか表示してくれない不具合に気づいた
    • FTPアップロード側を流用したのにそっちがデフォルトで100枚ずつしか返さない仕様だったことを忘れていた
    • ページングの動作確認を擬似的に10枚単位で行っていたので気づいていなかった
    • FTPアップロード側のファイル数制限処理を消して再デプロイし直したら解決した
  • 4部屋のセッションを撮って、Xに投稿できる準備をして、会場を撮り歩いて…とやっていると時間がギリギリだった
  • とあるタイミングで写真がアップロードされないな?と思ったら、JPG側のSDカードが不調になってJPGが全部こわれていた
    • RAWは別のSDカードに保存していたので致命傷ではないが、SDカードのフォーマットを現地ですることになった。SDカードはちまちま買い替えよう!
  • 知り合いを含め参加者の方に「その…なんだ?その…、スマホ…?」と不思議な顔をされる。Sony PDT-FP1がXPERIAベースの端末なので、とにかくでかい

また、現状のシステムの改善点もいくつかあり、以下の改善をしてどこかでV4を運用したいですね。

  • 1イベントで大量にアップロードするとシステムがうんともすんとも言わなくなる
  • FTPアップロード自体をAPIサーバ側に統合する
    • FTPアップロード先を外部にする設計は柔軟だが、正直少し大きめなサーバを借りてそこで管理してしまう方が安上がりだと思った
    • なぜかアプリに至ってはAPIサーバをホストとして選べるようにしていたので、RetrofitのAPI記述が全部おかしなことになっている
      • APIサーバ自体はワンショットで立ち上げられるので誰が立ち上げたサーバでも使えるように…みたいな気の利かせをしたけど、よく考えたら使わなさそう
  • スライドショー表示を作る
    • 幕間などのスライドショーに載せるために、例えば現状ダウンロード -> Google Slidesなどに手で配置 -> 更新といった作業が発生している
    • お気に入りに入れた画像をベースにランダムにスライドショーをさせて、会場内での連絡事項なども画像で入稿してもらいつつ、別途で載せれるAPIを作れたら多分幕間としては完全なものが用意できそう
  • お気に入りのカテゴリを分けれるようにする
    • 「あのシーンの写真、ある?」という要望が出るとお気に入りに入れたかどうかすら不明でずっと探していたので、ユースケースとして漏れていたっぽい
    • というか撮っている側も「あのシーンあったっけ」って大体覚えていないので、チェックリストとして機能しそう
  • FTPアップロードアプリを作る
    • AndroidアプリにFTPサーバを立ち上げる方法は調べたらでてきそう。Play Storeを見ていると実際にそれをやっているアプリも存在はしている。
    • Sony Transfer & Taggingで出来ることを他メーカー製のアプリでも出来るように再実装すれば、「FTPアップロード機能があるカメラをもっている人」に対象範囲を広げられる。
    • なんならサービスに打ち上げなくてもそのアプリ内で処理できるだけで嬉しいかも

DroidKaigi 2024のスタッフや会社のお仕事も忙しい時期で大変でしたが、余暇(?)に久々に面白い個人開発ができました。とっても楽しかったです。 しばらくは積んでいたゲームなどを消化しながら、ゆっくり過ごそうと思います。ありがとうございました ( ˘ω˘)スヤァ

いい写真を最速で共有する技術

どーも、どくぴーです。

3/22-3/24に開催されたtry! Swift Tokyo 2024でご縁もあってカメラマンを担当していました。
普段通りに撮影して…とも思ったんですが、「単純に写真撮るだけだと味気ないなあ」とも思ったので実は新型ワークフローを試験的に導入してみました。
テスト運用も何もしてなかった(むしろごめんなさい)のですが、タイトルにもある通り、撮影した写真を爆速で必要な人が使うのを可能にするワークフローが実現できていました。

こんなポストとか

こんなポストに添付されている写真はそのワークフローを使って「その場で僕が撮った写真」ということになっています。
あとは会場で休憩時間の間に流れていたスライドショーの写真にも使ってもらっていました。

モチベーション

需要がありそうだった

どくぴー「try! Swift Tokyo 2024のカメラマンかぁ〜、どんな写真撮ろっかな」  
配信スタッフさん「ねえねえ、幕間に使うスライドショーに写真載せたいんだけどできそう?」  
どくぴー「サブスロットのSDカードのJPG渡すとかならできそうだなあ」  
本隊スタッフさん「ねえねえ、撮った写真をSNSですぐ使いたいんだけどどうするとできそう?」  
どくぴー「同時にSDカードを2枚渡すのはできなさそうだなあ」  
どくぴー「どっかのサーバーにそこそこの画質で上がってたら便利そうですか?」  
配信スタッフさん・本隊スタッフさん「よさそう」  

みたいな会話だったような気がします。記憶が薄いので嘘かもしれない。

ほしい機材があった

www.sony.jp

最近発売されたポータブルデータトランスミッターというやつです。名前は大仰ですが「有線LANとHDMIキャプチャと空冷ファンがembedされたAndroid端末」ってノリの機材です。
2月末に開催されたCP+のソニーブースで実機を触って話を聞いてたんですが、毎回写真の管理に苦しんでいたので何に使えるかわからんけどほしいな〜Androidバイスだしな〜って思っていました。
普段はモータースポーツの写真を撮ってたりするんですが、毎回出てくる2万枚の写真を雑にSNS共有しようと思うとまあまあめんどくさいんですよね。カメラメーカーのBluetoothで共有できるコンパニオンアプリ、結構クセがあったりもするので…。
CP+の会場で説明員さんの話を聞いてやりたい事自体は同じアプリをPlay Storeからダウンロードして手元のスマホアプリで無線LAN使えば代替できるよ〜って教えてもらったので、try! Swift Tokyoで使うには発売日が間に合わないこともありそれで一旦試験してみるかあという流れです。

普段撮ってるような写真。1日1万枚なんてザラにあります。整理って大変だよね。

手法を考える

SDカードを抜き差ししてなんとかする

上の会話シーンにも出てきた「サブスロットのSDカードを渡す」という手法です。要は物理でデータを手渡す一番わかり易い方法になります。
ある程度のクラスのカメラ(最近のSony α7シリーズとかNikon Zシリーズとか)を使っている場合はダブルスロットを装備していて、1stにRAW画像、2ndにJPG画像を分けて保存する機能がついているのでJPG側を渡しながらSDカードを入れ替え差し替えなんとかする…みたいな流れでした。

とはいえ、幕間でもSNSでも使うとなると担当が違っていたり、物理的な位置も離れているので今回はこの手法はマッチしません。却下です。

SDカードからどこかのサーバに打ち上げる

SDカードを適当な端末(PCでもなんでもOK)に繋いで、コードを書いてFTPを用いてレンタルサーバに打ち上げたり、マクロ的にGoogle Driveに上げるようにする手法です。
これだとインターネット環境さえあれば複数人が同時に見ても問題ないので良さそうに見えますが、以下の問題がありました。

  • そもそもそんな端末が余っていない。そういえば最近使ってない端末売り払った
  • 結局SDカードを抜き差し入れ替えしないといけない。本部に戻ったりするのは手間だし壊しそう
  • 現地についてからネットワークの設定調べたりしないといけないのでワンチャン破綻する

というわけでこれも今回は現実的ではないので却下です。

カメラのFTP機能を使ってどこかのサーバに打ち上げる

今使っているSony α9II、α7RIVにはともにWi-Fiなどで指定されたIPアドレスに対してFTPで撮影直後に写真を逐次送信する機能が備わっています。この機能を使って、インターネットにつながってさえいればどこからでもFTPを開いたサーバにアップロードできるという寸法です。 ソニー機だとTransfer & Taggingというアプリが使えて、テザリング/有線LANなどで同一ネットワークにあるカメラに対してFTPサーバを立ち上げ、そこを踏み台にして別のFTPサーバにアップロードする事ができるので、カメラがずっとどこかにつながっていてカメラのバッテリが負担になることもないなぁと考えました。

support.d-imaging.sony.co.jp

ネットワークもテザリングさえ繋がせてもらえばギリギリ成り立つんじゃない?自宅で動作検証もできそうだし設定をそのまま持ち込めば解決できそうだし…。ということで今回はこれを採用することにしました。
FTP送信機能のついていないカメラはどうするんですか?」という話はあるんですが、今回はメインカメラマンが僕一人でどちらもソニー機だったので今回は気にしていません。

サーバを選定する

今回は試験的に運用したこともあり、機能的な充実よりも「限りなく低コストでさっさと動かせられる」ことをターゲットにしました。選択肢としては「FTPアップロード機能を備えたクラウドストレージ」か「昔ながらのレンタルサーバ」が考えられます。流量もあまり想像できないので、できることなら容量も転送量も無制限に使えるのが理想です。

前者は HStorage などがFTPアップロード機能もついていてコストも安く、魅力的でしたが年額払いしかできないのでワンスポットで使うにはコスパが悪すぎて断念、AWS S3の従量課金に頼る案もありましたがData Transferなどが必要になったときに課金額がイメージできず、そのへんのコスト感のあたりがつかなかったのでこちらも一旦棚上げです。

結果的に昔ながらのレンタルサーバを探す事になりました。GMOさんが提供している Z.com というサービスが一番魅力的だったんですが2023/9あたりから申し込みを停止しているみたいで、最終的な選択肢としては ロリポップ! が残りました。懐かしいですね。

実際に打ち上げてみる

FTP設定をする

契約してFTPの設定だけをゴニョゴニョしたら実際に上げるのはコードを書くことなくできるので、とりあえず試してみます。
カメラ側のFTPの設定などはソニーがマニュアルを用意しているので、それを読みながら設定していました。ページタイトルが無茶苦茶すぎる。

helpguide.sony.net

実際にカメラのFTP設定に書き込むのはサーバ側のFTPの情報ではなく、スマホ(Transfer & Tagging)側の設定です。スマホ - サーバ間のFTP設定をしたらスマホ - カメラ間のFTP設定がアプリ内に表示されるので、それをカメラに流し込みます。機種によってはカメラでポチポチやらなくてもNFCで書き込めたり、SDカードに設定ファイルをおいて書き込めたりします。

カメラをWi-Fiに繋いでアップロードしてみる

あとはカメラをスマホから発したテザリングに繋いで、Transfer & TaggingFTP待ち受けを有効にしたら適当にパシャリと1枚撮ってみます。
特にここはなんてこともなく、ロリポップ!のFTP管理画面に写真が飛んできたので「おお〜〜〜、見れるじゃん!」とチピチピチャパチャパドゥビドゥビダバダバしてました。

必要な人が打ち上がった写真を確認できるようにする

よっしゃ、これで終わり!ってなれば一番良かったのですが個人で使うようなロリポップ!のレンタルサーバを選んでしまったので必要な人が見れるようにしないといけません。
FTPのアクセス情報を渡す…ってのも考えたんですが、クライアントをインストールしてもらうにしても DSCxxxxx.JPG みたいな無機質なファイル名のみで「これが必要な写真だな」と判別してもらうのは至難の業どころか不可能です。

というわけでGoogle Photosのアルバム並に一覧性の高いシェア方法が求められました。スマホアプリ…よりも画面の大きいPCで見れるWebアプリ的なものが必要です。
そういえばロリポップ!を借りたということはPHPPerl CGIJavaScriptのいずれかを書けばそれっぽいことできそうだな?って思ったので「一旦作るか〜」ということにしました。

PHPを書く

PHPよりむしろPerlのほうが書いたことあったんですが、まぁ書けば動くじゃろということでPHPで一覧表示をサクッと組んでみました。
ファイル一覧を表示して glob 関数を使って一覧表示するだけならすぐできるんですが、3000-4000枚の写真を管理するにはこれだけだとまぁ力不足って感じがします。
ファイル名ソートすればいい感じになるかなとも思っていたんですが、よく考えたらカメラは自分だけで2台あるのでそのファイル名が連続するのはあり得なさそうですしもっと根本的な対応が必要そうです。

この時点でスタッフさんだったりに見せて、「あれも欲しいな〜」ってなったものから時間的に間に合いそうなものをちょこちょこ選んで作っていました

  • 撮影時系列ソート: EXIF情報欲しいな〜って思ってたらexif_read_data 関数を使うといい感じに構造体が取得できたのでできた。あとはファイルパスと撮影日時でクラスを作って array_multisort 関数を使ってソートするだけ。
  • ページング:ないと確実に困りそう。今回はライブで更新されたりポーリングしたりは必要なさそうだったので、リロードしたタイミングで取得した時系列ソート済みの配列を100枚ごとに slice 関数で切り分けて、クエリパラメータから取得してページ数を決定した。
  • クリックしたらダウンロードできるようにしてほしい:適当なタグに download 属性をつけるだけ。秒。

ここまでやると「あれ?これで便利なのでは?」となったので終了。あとはちゃんと見れるのか〜とか、どれくらい連写しても耐えられるのかとかの確認をしたりしながらカメラのメンテナンスをして当日を迎えました

完成したので最終的なチェックをしてるとき。被写体はうちに転がっていたポヨポヨしたやつとこねたものです。

結果とその考察

結論から言うと「なんかええもん作ったわ!」みたいな感想です。久々に自分が使ってて便利だなって思うものを作りました。

これまでは写真を早く現像して渡さなきゃ〜〜〜、みたいな気持ちで作業していて、最終的に運営の人に渡す(公開タイミングじゃないよ)にしても1週間は確実にかかっていたんですが、リードタイムが1分程度になったので10080倍速で必要な人の手に渡る圧倒的な高速化を果たしました。
SNSや会場の幕間でその写真が見れて参加者の人の反響が聞けるのも嬉しかったですね。当日はスタッフとしてお手伝いさせていただいているDroidKaigiパーカーを着ていたので「!?」ってびっくりさせた方いらっしゃったら申し訳ないです。

感想としてはこんな感じなのですが実際の運用フェーズについて考えてみると

  • テザリングで用意しておいて良かった。サブのスマホにpovo 2.0の使い放題プランを有効にしておいてサイドポーチに突っ込んでいたので通信量も問題なし
    • 会場Wi-Fiがあるケースだと2.4GHz帯が強すぎてテザリングが潰されて動かなくなるケースもある。そういうケースは会場Wi-Fiに頼ったほうが安定する
    • Day.1/2でテザリング運用したときはエラーレート10%弱、Day.3で会場Wi-Fiに乗っかったときはエラーレート1%程度だった。
  • フロントエンド側は手の込んだことをしなかったおかげかぶっつけ本番でも安定稼働をしていた(ように見える)ので安心した
  • どれくらいの通信量が起きるかわからなかったのでロリポップ!のスタンダードプランを契約していたが実際は6GBいかない程度のサイズ感だった。オーバースペックっぽい

という感じでした。とはいえ試験運用としては求めている動作ができたので100点です。対戦ありがとうございました。

ロリポップ!のストレージ使用量。余りまくり。

打ち上げた写真について

基本的には撮って出しをいい感じのサイズ感にしたものを出しています。スマホFTPするにしても、サーバへFTPするにしてもサイズは可能な限り小さいほうがいいのと、最終的に使うことになるのはSNSと幕間動画であることはわかりきっていたので、別途最終的にできることになるアルバムとは別のルートになります。そのため、カメラ側で出力設定を最低値(α9II:6MP / α7RIV:16MP)に設定し、JPGファイルサイズは必要最小限にしました。Transfer & TaggingアプリではFTPアップロード時に更にJPG画像を縮小することができるので、最終的にフロントエンドに表示される画像は「最大幅2560px」としました。1枚あたりのファイルサイズはだいたい2MBという塩梅です。

今後を考えるなら

他のイベントで流用(それこそDroidKaigiとか)でも流用できるように色々と何かやったほうがいいな〜と思っています。

  • 認証系を設計したい。今はURLがわかったりするとすぐ見れてしまうし、せいぜいBasic認証をかけるくらいしか思いつかない。多分Firebase Authを使うことになりそう
  • スライドショーをできるようにしたい。例えばお気に入りフラグをつけてランダムでスライドショーできる画面を作るとか
  • 画像をダウンロードする際に16:9のアスペクト比にするオプションを付けたい。撮影時のアスペクト比って大体3:2とか4:3だけどスライドは16:9だった
  • 写真一覧をjsonで返すようなAPIをつけたい。Android TVのようなサイネージでライブでスライドショーをできるアプリがあると盛り上がりそう
  • 画像に対しておそらく10-20GBくらいあれば運用はできそうなのでストレージサイズのでかいレンタルサーバでなくてもVPSとかで乗り切れそう。dockerなどを使ってワンショットで立ち上がるようなシステムにしてもいい
    • 写真の上がる先だけレンタルサーバにして、必要なときだけフロントエンド/APIサーバを立ち上げるような形にしてもいいけどコスト感が問題そう
  • ソニー機以外のカメラを使ったときのワークフローの確立
    • 富士フイルムなどはそもそも外付け機器がないとFTPアップロードができなかったりする。その時のためにSDカードを挿入したらJPGだけ打ち上げるような端末がサブプランとしてあるとやはりよさそう
    • Transfer & Taggingソニー製以外のカメラからのFTPを受けられるか試していない。できそうではあるけどなぁ…?

V2はあるのか、こうご期待です。

部屋の掃除や整理はメンタルに(多分)効く

どーも。どくぴーです。

今年はちょっと早めの先週くらいに大掃除をしました。例年1日かけて休日にやる程度なんですが今回は余りに余った有給休暇をつぎ込んで4日間くらいかけてやってました。長い。
大掃除そのもののtips...というものはないのですが、真面目に大掃除をやって思った以上に副次的な効果があったのでまとめておこうかなと。

※あくまで個人の感想文なので万人に適用できるかと言われると責任は取れません。僕はやたらとものが増えるタイプの人間なのでその時点で外れ値かもしれません。

部屋の状況が悪いのと気が滅入るのは(多分)相関がある

物が多いのか、ホコリが多いなどで汚いのか、はたまた…という話ではあるのですが部屋の掃除や整理ができていないというのは精神的な影響が多分にあるなと感じました。
気が滅入ってるから部屋の状況が悪くなるのか、部屋の状況が悪くなるから気が滅入るのか…みたいな鶏卵感もあります。でも結局寝たり起きたりするのは家ですし、いずれにしても精神的な余裕が部屋に反映されてるなと言うのは感じますね。

最近はReturn to Officeの流れもあって一人暮らしをしていると以前のように仕事して家に帰って少しなにかやって寝て、起きて会社にまた向かって…というループをしていたので、なおさら部屋の状況が悪くなっていたような気がします。
特に置き場がなくて…とかじゃなくて、時間やらなんやらで余裕がなさすぎて買ってきたものとかを一旦おいたままどうもしなくなっちゃうような感じのムーブが増えると本当に良くない。本当は自覚する前に対策したいんですが…。

そういう意味でもどこかで悪い流れ的な何かを断ち切るように掃除をするのは大事だなと思いました。多分「テスト勉強をしてると部屋の掃除がしたくなる」というのはこれに近いなにかなんだろうなと感じています。

「使うかもしれないし」で残しておくのはマジでやめた方がいい

いつ買ったのかすらわからないものを後生大事に残しておいて、「全然使ってないけどもしかしたら使うかもしれないし…」とか言ってたんですが毎年言ってる上にマジで使ってないので諦めて「使ってないや」と言い切ってしまうべきだなと思いました。もし必要になったらもう一回買えば良くて、そうできないものくらいしか残すべきではないなと感じています。

今回の大掃除では押し入れに訳がわからない積み重なり方をしているので場所も取っていたし、別に売ってどうにかなるようなものでもないままホコリを被ってマジで使わないケースがあまりに多くて反省しています。微妙なサイズ感の思い出にふける精神的余裕だけはあるの、何なんでしょうね。

大体理想通りには上手く行かないのでそれっぽくいったら満足して終わる

究極的な大掃除の解答は「引っ越す」なので、多少「今回はここまでやろう」にたどり着けなくても「頑張った!終わり!」と時間を決めて潔く諦めるのがいいですね。仕事ではないんだから「なんで終わらないんだろう…?」とか考えていると心がつらくなってしまいます。

大きな物を動かす、とかじゃない限りは収納道具の買い足しや整理し直すことで再チャレンジできるので、また気が向いたらやるか〜、くらいの心づもりでいると良さそうですね。実際今回の大掃除でも諦めたところがあるのでまた落ち着いたらもうちょっと整理しようと思っています。

終わりに

結構ここ二ヶ月くらい忙しかったり諸々のイベントが起きて「家にいて寝るだけでもごちゃごちゃしすぎてまあまあ嫌気が…」みたいな状態であんまり休まっていなかったのですが、大掃除を経て一気に改善しました。やったね。
とはいえ部屋の整理については定期的にやっていたほうがマジで困らないので、普段からできる掃除はちまちまとやっておきましょう。周りの人やSNSの話を聞いていると家事代行とかを頼むのも全然ありだと思うので、またやばくなる前にはそういうのも検討してみようと思います。

余談1:今回の大掃除について

  • 倉庫を契約した
    • ほら、配列をソートするにもtmpな領域って必要じゃん(?)
    • 大掃除が終わってからはこの冬に使わないキャンプ用具とか、バドミントンの道具とかカンファレンスのノベルティとかが入っている状態
    • 土地の都合上0.5畳しか借りてないのにばっかみたいな料金がかかっているので早いとこ解約したいが…
  • 物を捨てる…というかほぼ断捨離をした
    • 少しでも迷ったら捨てる、をひたすらに繰り返してたらとんでもないゴミの量になった。正直一番時間がかかった
    • 下手に折りたたみコンテナとか使って収納してたので目に見えてない圧縮された不要物が大量にでてきてしまった
    • 自治体によるけど一回で一定量以上の燃えるゴミの回収は不可能 or 電話で申請して有料での回収になる場合があるので要注意
  • 模様替えをした
    • 明るいからとデスクの後ろに窓が来るようにしていたが、リモートワークをしているときは窓越しに見えちゃうのでカーテンを閉める圧倒的本末転倒具合だったので動かした
    • ついでに古いカーペットとかもポイポイできたし、床もクイックルワイパーをかけるとかじゃなくてフローリングマジックリンを使ってある程度綺麗にできたので良かった
  • 水回りの大掃除をした
    • キッチンや冷蔵庫の道具や古くなってしまった調味料などを全部すごい勢いで捨てた
    • 一人暮らしで買う調味料、マジでサイズを考えたほうがいいと痛感しています。小さいの買っても下手すりゃ使い切れない
    • レンジフードのクリーニングもしました。ここが一番しんどかったです
  • 洗濯機をオキシクリーン漬けした
    • 定期的にはやってたが「お湯でやろうぜ」と言われたのでバケツを買ってきてお湯でやってみた。(詳細は省きますが)とても効果がありました。
  • すべてが終わったあとご褒美に温泉にいった
    • とっても 気持ちが いい

余談2:今後どうしたいの

  • 状況当時から使ってるデスクチェアや布団を新しくしたい
    • バロンチェアとかそういうのはいいとは思うが高すぎるものを買ってもしょうがないのでニトリとかで探そうかなと
    • とりあえず1月に粗大ごみ収集所に行く予約はしたので車で行こうと思う。多分そこでついでにニトリとかにいく
  • ディスプレイ背後の配線をなんとかしたい
    • Mac/Windowsそれぞれが繋がってるディスプレイにキーボードやらオーディオインターフェイスやらカメラやらが繋がっていてまあまあケーブルが多い
    • ついでにPS5/Switchもサブディスプレイに繋がっていたりするのでケーブルがムダに多い。なんか上手く吊り下げたりしてまとめるやつ買うかぁ。
  • (いずれは近いうちに)引っ越ししたい
    • 1Kみたいな部屋だと居間に近い機能を持たせるのはほぼ無理だと察した
      • ローテーブルを用意する、とかならまだしも、椅子やらソファをおいてテレビを置いて…みたいなものは出来ない。となると1LDKくらいはほしいよなあ…
      • 作業場的なものと寝床が一緒になるのもつらい
    • 勤務地から離れていていいので駐車場がある or 取りやすいところだとといいなあ。車がほしいよ〜

今年買ってよかったもの2023

この記事は mhidakaが建立した Advent Calendar 2023 の8日目の記事です

いきなり感想文

久々にブログを書くなって思った。今年は勉強会とかでちょいちょい登壇したけどアウトプットの数は激減したので来年はもっとアウトプットできるようにブログとかも使わないとまずいですね。

最初に

DroidKaigiやらでお世話になっている @mhidakaさん に「おい、Advent Calendar建立したぞ、なんか書くんだよな?」と頂いたので参加しました。
adventarの内容を見ているとゆるくていいとのことなのでゆるく筆を執ってみようと思います。

今年もなんやかんや色々買い物をしたと言いたいが

今年はカメラのボディやらレンズを買っていないし、新しいパソコンも買いませんでした。意外〜。
何買ったんだっけって思い出しつつ、これは買ってよかったなと思ったものをかいていこうと思います。
モノだけに限らずサービスとかもかいていこうか。

ストレッチポール

知り合いに「巻き肩とか猫背気になるならこれ買って15分毎日寝てみろ」と言われて買いました。実際どちらもそれなりにマシになった気がします。
言われた通り15分ぼーっと寝てみたり、グリグリと左右に揺らしてみたりしてます。

買ったのはストレッチポール®(登録商標)ではない、要はジェネリックなやつ(リンク忘れた)ですが確かセールで3000円ちょっとくらいだったような。

Fit Boxing 2

fitboxing.net

SwitchのJoy-Conを使ってボクササイズ音ゲーするゲームですね。北斗の拳仕様とかもありますがあれは別ゲーです。
Fit Boxing(初代)も持っていたんですが、ステップ系の判定が全然でなくて苛ついたのでアクションごとに判定キャンセルができる2を買いました。
結局ゲームなので「ちゃんとやってるはずなのにうまく行ってない」みたいなストレスがなくなったのでゲームをやるからにはちゃんとスコア出したい人間からすると快適になったので良かった気がします。

なお、3ヶ月くらい毎月20日ほどひたすらにやっていた結果10kg+程度痩せました。今はランニングに切り替えています。

作業用手袋

www.monotaro.com

軍手ではない手袋です。なんかゴム手袋っていうよりは手のひら側がきっちりゴム素材になっていて滑りにくそうな手袋って感じのやつ。 運送とかやってる人が使ってるようなやつですね。

スタッフとして参加しているDroidKaigiでお手伝いをさせていただく(要は力仕事をしたりする)機会があるんですが、これまで使っていたよく見るタイプの軍手だと軍手の内側で手が滑ってかぶれたりとか血が出たりとかで大変だったので買ってみました。

結果としては大正解。ちゃんとフィットするし、大きくて重めの荷物を持つときに滑って力入れにくいなーと思っていたものが一気に改善しました。滑らないってマジで偉大。
重いものを持つなど、素手でやると危険が危ない作業を1日の中で頻繁にやる方はぜひ購入を検討しましょう。別に高くないので。世界が変わります。

PeakDesign エブリデイ スリング 10L

www.mapcamera.com

今年買った唯一まともなカメラ用品かもしれない。みんな大好きPeakDesignの肩掛けカバンです。
10Lで一番大きなモデルなので普段遣いしているα9II + SIGMA 24-70mm F2.8がすっぽり入って、あと一本レンズが入るかな?って感じのサイズ感です。
一応14インチまでのPCが入るとのことなので私物のMacBook Pro 14インチが入ると思って買ったらギチギチでした。大丈夫かこれ?

アニメ「星のカービィ」HDリマスター版 まるごとコンプリートBOX

www.hallab.co.jp

2001年頃から放送してたいわゆる「アニカビ」のブルーレイBOX。どこの配信サービスでも見れないし、土曜朝にやってた子供向けアニメとは思えない風刺とブラックジョークが押し寄せるある意味では指定文化財
もはや永久保存版みたいなもんです。時々インターネットで流れてくるトンチキ語録な陛下をアニメ本編で見ると余りの懐かしさにノスタルジックな気分になりますね。

ダメで元々ぉ!人生はギャンブルZOY!

GeoGuessr

www.geoguessr.com

ゲーム実況系YouTuberがやったりいつぞやのRTA in Japanで走ったりしてたGoogleストリートビュー上で落とされた場所がGoogle Mapsのどこなのかを当てるゲーム。月額プランの399円のやつ(PRO)を払うとなんか自分でエリアを指定したりしてゲームを作ることができるようになります。
暇つぶしとしてめっちゃ楽しい。Japanマップで延々とプレイしてます。知ってるところに落とされたり移動して通り過ぎると脳汁がでてくる感じがいいですね。

povo 2.0

povo.jp

メイン回線のahamoが渋谷近辺(特に電車で渋谷に突入したり離脱したりするとき)に致命的なレベルでグズってしまうのでサブ回線として契約。渋谷勤務なのでアクティベートしたときの感想は「はっやーい!」でした。
イベント事とか、お出かけとかでずっとインターネット繋がってる状況がほしいときに330円を雑に払って無制限のネットワークを得たり、F1を見るためにDAZNの7日間プランを有効にするときとかに使ってます。無制限、いい響きですよね(むやみに圧迫するような使い方はダメ)

地元だと全然ドコモ回線のほうが都合がいいので、ahamoを解約したりすることはなさそうだなって思います。

まだ良かったかどうか決めあぐねてるもの

特に良さげな感想が思い浮かばなかったり、まだ買って時間が経ってなかったりするものもたくさんあります。

256GBのSDカード

いっぱい写真が撮影できます。

www.kenko-pi.co.jp

勢いで買ったワイヤレスマイクのキット。ノイズが乗るなあって首を傾げてたら先日「アレってソニーのカメラにつなぐときはカメラ側の入力音量をギリギリまで落とすとええやで」って言われたので今度試してみます。

Nreal Air(現XREAL Air

XREAL Airjp.shop.xreal.com

スマートグラス。USB-CのDP Altモードで繋がってPCの外部ディスプレイとして繋いだり、専用のアダプターを噛ませてゲームのディスプレイとして使ったりしてます。
作業用にはそれなりに使える…んですがmacOS用のNebulaという連携ツールが当時ベータでまぁまぁ使い勝手がよろしくなかったというか、挙動に怪しいポイントが多かったので全然試せていません。新型が出た今は良くなってるのかな?

WI-1000XM2

www.sony.jp

ブラックフライデーの時期にノジマ電気にフラッと寄ったら定価の8000円引きでAmazonよりやすかったので購入。アクティブノイズキャンセリング搭載イヤホンなんて5年ぶりくらいに買ったんですが静かですね。
最新のWF-1000XM5とか買えばよかったじゃんって聞かれるんですが、「充電ケースを持ち歩くの絶対忘れる」ためやめました(ズボラ)

Pixel 8

store.google.com

まだ移行終わってねえ(ズボラ) この間のGeminiの発表を見ているとGemini nanoが使えるPixel 8 Proにしとけばよかったなって気がしなくもありません。

結論:色々買ってた

来年はα9IIIとかほしいなーって思ってるので、仕事頑張ります。

社会人になって6年が経ったらしい

まずはじめに

ご期待いただいている方がいらっしゃるかもしれないですが、こちらは 在職エントリ となります。なので干し芋のリストを貼ったりもしません。
こいつは2022年度も元気に生き抜いたんだな、程度の感覚でご覧ください。

社会人になって6年がたった

エイプリルフールに書くのもなんだかなあと思って筆を眠らせていましたが、社会人になって6年が経ちました。明日から7年目として初日の出社です。
良いのかどうかはわかりませんが最初に入った会社でずっとAndroidアプリエンジニアをしています。

転職は考えなかったの

正直考えました。とりあえず転職ドラフトやらを通して10社くらいお話させていただいたこともありました。その節は本当にありがとうございました。
でも理由はともかくとしてなんやかんや現職を選び直して1年位たってマインドセットやらも変わったので、個人的には「まぁ、よかったんやろなあ」くらいの感想です。後戻りはできないしね。

なんかいい転機はあったの

2つあるかなあと思っていて、まずはこれからやることに対して「なぜ」を追いかけることや、自分に期待されていることの納得感みたいなのを意識するようになったことは大きいかなと思っています。

先述の他社の方とお話させていただいたときもそうなんですが、組織が戦略として出すものに対して「なんでこれからこれに注力するんだろう?」とか「ぼくには一体何が期待されているんだろう?」みたいなものをどうやって伝えたり、それを目標として起こすんだろうとすごく不安になっていた時期があって、それを自分が知らない領域( = 社外)の人と話して「そういうことなのかもしれないな」って折り合いをつけられたのはとても良かったなあと思っています。実際2022年はいってから目標設計の組み方も大きく変わったと思っていますし、まどろっこしい道のりを歩んでいるのは承知の上で「よし、とりあえずこれでがんばってみっか」って気持ちになれるのはとてもクリアな思考を保つのには有効だなあと。

もう1つは、どこかで拾ってきた言葉なのですが「ネガティブ・ケイパビリティ」という言葉を意識するようになったことだと思っています。たしか最初に見たのはところてんさんのツイートだったかな…

この前のスレッドツリーで言及されている hotchemiさんのscrapbox があるんですが、引用させていただくと「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」という意味を持ちます。
1つめに上げたような「なぜ」を求めたり、そこから今やることを逆算して頑張るというのはscrapbox中でも言及されている対義語であるポジティブ・ケイパビリティだと思っていて、身近な話をしてしまえば組織が渡せる・渡せない情報がある状況をなんとなく「まぁ〜そういうこともあるんだろう、これから決めるとか、まだ固まりきってないとかそういうステータスってこともあるんだろう。とりあえずは今見えてるものに順応してから考えてみるかぁ」みたいな一歩引いたような姿勢を取れるのがネガティブ・ケイパビリティなのかなあと自己流に解釈しました。違ったら恥ずかしいなこれ。

とはいえ、そういう思考になったよってマネージャと1on1をしたときに話したときに「最近視座の持ち方変わったと思ったらその言葉良いっすね」みたいなことを言われたので多分いまの組織がほしい何かしらにはなったんだろうなあという感想文になりました。ちなみに視座というワードは個人的には響きがむず痒いのであえて言わないようにしています。

本も買ってみたんですがなかなか面白かったです。久々にこういう活字を黙々と集中して読めた気がする。

やることは増えた

Androidエンジニアとしてぼちぼちやっていたんですが、2022年から急に(新卒・中途問わず)採用活動に協力したり、内定者の人たちに何かを教えるような立場についたりしたりすることが増えました。
これまでやってなかったの?というと、ちょこちょこ面接に出てきたり採用イベントの主催をする程度だったんですが、より積極的に施策に携わったり、スカウト文を書くようになった感じです。

採用、人とお話するのは楽しいなあと思う一方で、話を聞きに来ていただいている方のためになる時間になれば良いなあとか考えつつ、いざ選考にお誘いするとなると「人の人生に干渉している」という事実をまじまじと見つめることになるので、積極的に関わるけど慎重にやっていきたいですね。どこかでぼくとお話することがあったら何卒宜しくお願いします。

あとは腕に覚えがあるとは全く言わないんですが、プロダクトの開発施策の提案や仕様策定をしたり、その後の効果測定でクエリを叩いて様子を見るなんてのもちょこちょことやったりしました。
Androidアプリだけゴリゴリ書いていた頃から比べると意外と見えるものも変わってきていて、「こういう作り方すると良いんだろうなあ」とか、「ユーザに届けるのに必要な仕様ってこれで過不足ないんだっけ」みたいなことを考えられるようになったのはいい話だなと思っています。

くだらない話

よく物が壊れた

というか地面に落としちゃう、みたいなシーンが増えました。高価なものだとM1 MacBook AirとPixel 6でやらかしました。前者はヒンジが曲がっただけで済んだんですが後者は即死したので、新宿にあるスマホを完全に壊してくれる店で動画を撮りながら潰れていくPixel 6を眺めました。ちいかわみたいなリアクションをしていたんですが他のお客さんの声が入っていたので特にどこかに上げることはありません。丁寧にものを扱うことを心がけようと思います。

散財グセは悪化した

落としたM1 MacBook Airの代替でM1 Pro MacBook Proを買ったり、DroidKaigiの前日にα9IIを買ってしまったり、引き続き散財グセは止まりませんでした。α9IIは本当に買ってよかった。いいカメラだこれは。
文房具もきっちり沼にハマったのでもう逃げられないんだと思います。

今年も一人旅をした

旅というかレースを見に鈴鹿に行ったり岡崎に行ったり、情報科学若手の会の運営のために軽井沢に行ったり、色んな所に車で行ってました。運転たのちい。
車買わないの?って聞かれるんですが駐車場が全然ないしいまレンタカーやカーシェアで借りてるお金よりずっと高くなるので散財グセを先に止める必要があると思います。欲しい車はある。

おわりに

まぁ7年目に入るからなんだ、という話はなく、これからも適度にがんばって行こうと思います。
今まで関わっていただいた方、本当にありがとうございました。これからも何卒よろしくお願いいたします。 これから関わることになる方、ぜひ優しくしていただけますと幸いです。

最近、メモをペンと紙で取るようになった

久しぶりにブログ書いてるな。どくぴーです。

写真のことはアメブロに書くようにして、ちょこちょここっちは書いていたんだけどようやくこっちを書く気になった。

ameblo.jp

メモを取るようになった

1年くらい前から、仕事で必要とされる目標設計に関わる思考とか、いわゆる「ドキュメントではない」書き起こしをするようになった。
会社で契約しているドキュメントサービスだとesaやらNotionやらを持っているが、月500円でesaを私的に契約してメモを取ったりするようになった。

会社のことは会社のesaなりに書く、それ以外のことは私的なesaに書く、程度の使い分けをしていたが、始めてみると意外と書くことが多くて、「なにかコーディングする時間」がどんどん「文章を打つ時間」に変わっていった。
当時の選定基準としては「Markdownで雑にメモが取れると良いよね」みたいなイメージだった気がする。

今年の8月くらいまではそれでやっていたんだけど、今思い返すとぼんやりと以下の変化があった。全体的には悪くない変化だったと思う。

  • 思考をまとめるまでのスピードが少し上がった
  • 頭の中に置きっぱなしにして「なんかやろうと思ってたんだけどすっぽ抜けていった」が減った
  • 文章をしっかり書くようになった。直近で仕事の中でも文章を書くシーン(採用とか)が出てきたので反映されてる気がする
  • 上から下にガッと書いていたので何かと何かを結びつけたりするような簡単な図みたいなのをイメージすると思考がフリーズした

要するに「頭の中だけだとRAMが不足しているんだな」みたいなのが如実に実感できるような事象が起きた。
ラバーダッキング法みたいなものがあるように、喋らずともなにかに対して思考を自分の外に出す、というのは合っているらしい。

とはいえ、上から下にガーッと書いているだけなので単純な記述しかできず、それが離れた2つのアイディアを結びつけたりする、みたいな表現ができなくて頭の中が逆にこんがらがってしまう、みたいなケースもまあまあ存在した。単純な記述で賄えるように自分の思考を噛み砕くべきだったのか、miroのようなホワイトボードっぽいサービスを使うべきだったのかと言われると正直ピンとこないが、自分としてはこれ以上「デジタルでメモを表現する」という行為に限界を感じていたような気がする。

おもむろにペンを買った

ジェットストリームプライム シングル 0.5mm

9月に入って、ふとした衝動で「なんかそこそこに良いペンがほしいな」と思って気づいたら会社の近所にある東急ハンズに駆け込んでいた。そのときにYouTubeでレコメンドされたしーさー文房具がきっかけだったと思う。

www.youtube.com

学生の頃、シャープペンシルステッドラーパイロットの1000円位するやつを買ってみたりはしたが、社会人になってからはめっきりペンを握る機会も減ったし、その頃ついていたペンだこももう引っ込んでいるし別に「字を書くのがきれい・うまい」というわけでもない。でもまぁとりあえず買ってみるかということで3000円をぽんと出したのである。

試しに書いてみるとまぁこれが「カリカカリカリ…」という感じで心地よい。ジェットストリームといえば100円程度から買えるシリーズではあるが、最上位機種となるとこんなにも変わるのかと。ずっと書いていても指に来る負担がぜんぜん違うので、学生の頃使っていたペンと比べると握り続けているのがつらくない。これにはちょっとカルチャーショックを受けた。

これは面白いということで、近所のローソンで無印良品のルーズリーフを買ってメモを取るようにしてみた。デジタルから思考のアウトプットが飛び出してきた瞬間である。

紙でメモをとるようになって変わったこと

結論的にはデジタルでメモを取っていたときとあんまり変わらない。ただ、学生当時の講義ノートでそうやっていたように、書いていることを座標的に結びつけたりといった位置関係で表現できることができるようになったことで思考整理の自由度がだいぶ増した感じがある。
PCを開くほどのスペースや余裕、インターネット回線がない場合でも紙とペンだけ取り出してガリガリと書けるというのも性に合っている。「あー、とりあえずメモ取っておくか」って思ったときにサクッと取り出せるのがすごく手軽で良いなと思った。

PCを開きながらメモをとるのにも変化があった。作業中にメモを落とすときにこれまではIDEや作業してたタスクからドキュメントツールに切り替えてメモを取っていたので、画面に映っているものが切り替わることでコンテキストスイッチが起きていたらしい。紙でメモを取るようになってからは見ながらダイレクトに書き起こせるようになったので集中が切れることがなくなった。調べ物などをするときにこれが原因で集中が長続きしないことが最近ちょくちょくあったのがこれである程度解決したのがとにかく嬉しかった。

あと、興味深かったのが、自分は「書いたメモを読み返す」ことをしたいのではなくて、「書くことで思考を整理する」「書くことで記憶に留める」みたいな方向に自分の比重が置かれていることに気づいたこと。上から下にガーッとタイピングするのでは上手くそこができていなかったみたいで、どこに書くか、どう要素を結びつけるかを考えるのが自分にとっては大事なことだったと理解できたのは大きそう。

結局沼にハマった

ここからはオチ。

カメラにハマって沼に落ちていったので、ここまでしっくり来ると色々と買い集めたくなる悪い性分がここでも発動した。いろいろ調べたり、しーさー文房具の他の動画をみてあれもこれもほしい、試してみたいとなった結果自分で買ったり誕生日のプレゼントでもらったりして、あれやこれやと色々揃えてしまった。

ペンケースも誕生日にステッドラーのロールタイプをもらったので使い出したんだけど、多分使い方が間違ってるような気がしなくもない。でも満足はしているからいい…、いいのか?

こうなると紙もこだわりたくなってくるっぽくて、無印良品のルーズリーフを使い切った今は MDノート を使いだした。いい紙を使うと書き心地も良くなった気がするが確定的な変化を感じていないのでこっちはよくあるやつに戻すかもしれない。
ついでに日記も書き出した。こっちは毎日書ける自信がないので、自由度の高そうな キングジム HITOTOKI NOTE にしてみた。今のところ毎日書けているので、このペースだと習慣にできそうな気もする。

以上、特に字を書くのが得意でも好きでもないけど急にペンを買いだした人の話でした。

今更「dp」について考える

この記事は 飲酒プログラミング Advent Calendar の15日目の記事です。

どーも。どくぴーです。

会社の方で、デザイナーの方に「dpがよくわからない…、というかAndroidって画面サイズバラバラだけどiPhone SE(1st gen)みたいな小さい画面みたいな考えってあるんですか?」という質問を頂き、せっかくなので今更dpを考え直してみようと思いました。 これはスライドの要点の書き起こしであり、スライドだけを見れば十分な場合が多そうです。



導入

f:id:e10dokup:20201214220732j:plain:w640

僕が仕事をする上で、デザイナーさんがiOSアプリのデザインをされている時に「小さい画面のデザイン」というと、横幅320pxの画面に対するデザインのことだと考えています。ではAndroidではどうでしょうか。

f:id:e10dokup:20201214220932j:plain:w640

物理的に小さいデバイス…、って言うと。最近だと楽天モバイルで販売されているRakuten Miniがありますよね。ほかにも小さいデバイスなんていっぱいありました。でもそれはデザイナーの方が言うところの「小さい端末」でしょうか?という話です。

f:id:e10dokup:20201214221227j:plain:w640

dpとは?

Androidの画面デザインでは、昔から dp を用いています。これはdensity-independent pixels(密度非依存ピクセル)の略で、dipとも呼ばれたりします。この単位のおかげで、多種多様なAndroidバイスの画面サイズ・解像度において、(ある程度は)同じ表示ができるようサポートができるわけです。

f:id:e10dokup:20201214221449j:plain:w640

f:id:e10dokup:20201214221527j:plain:w640

f:id:e10dokup:20201215000557j:plain:w640

f:id:e10dokup:20201214221613j:plain:w640

dpにまつわる単位としては、デバイスそのものの画面解像度になるpx(pixel)、1インチ幅にどれだけのドットがあるかを示し、hdpiとかxxxhdpiとかの汎用密度に分類することのできるdpi(dots per inch)、そして本題のdp、フォントサイズの指定に使うsp(scale-independent pixels:スケール非依存ピクセル)等が挙げられます(pt/mm/inもありますがここでは一旦見なかったことにします)。px/dpi/dpについては

px = dp * (dpi / 160)

の関係が成り立ちます。画像リソースのサイズには

  • mdpi → 1倍
  • hdpi → 1.5倍
  • xhdpi → 2倍
  • xxhdpi → 3倍
  • xxxhdpi → 4倍

のような倍率で指定していましたが、これはあくまで上の式「dpi / 160」の形式化をしたものであるというわけで、実際に1dpが各端末のデバイス上で厳密に何pxになるか、という意味だと必ずしもこれらには一致しないと認識しています。

また、spはdpと似たような挙動をしますが、「ユーザのフォントサイズ設定」に応じて表示サイズに倍率がかかるので、アクセシビリティ等を観点に含めればより重要な値となります。

では、「小さい端末」ってなんだろう

少し前の話かもしれませんが、Androidの画面サイズ(16:9のとき)は一般的にはdpで表記すると 360 x 640dp であるという話でした。

f:id:e10dokup:20201214222758j:plain:w640

例えば、Sony XPERIA XZの画面サイズをdpで表記するとたしかにxxhdpiで360 x 640dpです。

f:id:e10dokup:20201214222828j:plain:w640

一方、物理的に小さい端末のはずのRakuten Miniも計算してみるとxhdpiでこちらも360 x 640dpになりました。

つまりRakuten Miniは「(デザイン的には)別に小さい端末とは言えない」という話になります。

逆に大きいデバイスで考えてみると、Nexus 6/Nexus 5Xあたりを皮切りに360dpより横幅の大きい端末が出てきました。

f:id:e10dokup:20201214223059j:plain:w640

例えばPixel 3を見てみると、xxhdpiですが px = dp * (dpi / 160) の (dpi / 160) に相当する部分が2.75になるので、392 x 786dpという画面サイズが得られます。

以下のサイトを見ていると、特に最近出た端末なんかは (dpi / 160) の値が整数ではなくなってきた感じがあるので、そこらへんが大きな変化なのかなぁと思います。

yesviz.com

ちなみに1/1.5/2/3/4ではなくなったら「mdpi/hdpi/xhdpi/xxhdpi/xxxhdpiはもう用済みなのか」というとそういうわけではなくて、やはり画像リソース(非Vector Drawable)を使用する際は適切なリソースサイズを配置する必要があるので依然大事な値だと考えています。

f:id:e10dokup:20201214223620j:plain:w640

しかしここまで360dpより小さい値が出てこなかったので、「もしかしてAndroidにおいて小さい端末というのはもう存在しないのでは…?」というとそうではありません。Android 7.0以降から、ユーザ補助 > 画面サイズで画面をスケールさせることができ、これを最大にしたとき、画面の横幅が320dpになります。ある意味ではこれがAndroidにおける「小さい画面」の回答であり、どの端末でも適用可能なので、横幅320dpでの表示には気を使う必要がありそうです。

f:id:e10dokup:20201214223913j:plain:w640

逆に縮小して画面幅を広げることも可能で、そちらでは領域不足の表示崩れ…が起きるわけではないとは思いますが、実際にどのように表示されるかはチェックしておくべきでしょう。

エンジニアとしてどう気をつけるべきか

f:id:e10dokup:20201214224036j:plain:w640

Android Studio 4.0からLayout Validatorが搭載されました。これによって、実際に手元にデバイスが揃っていなくとも、擬似的に様々な画面での表示を検証することができます。少し話はそれますがフォントサイズ設定や色弱の方向けの比較表示も可能なので、アクセシビリティ的な対応を行う意味でも使いこなすメリットは大きいでしょう。

f:id:e10dokup:20201214224226j:plain:w640

また、adbコマンドを使ってWindowManagerを操作し、実機上で表示がどのように変化するか検証することも可能です。これらによって「320dp以下ではどうしてもレイアウトの実現が厳しい」という話になるのであれば、 sw320dp のような設定修飾子を付与したdimens/layoutディレクトリを用意することで、各マージンやレイアウトそのものを切り分けるのが対策として考えられそうです。

終わりに

f:id:e10dokup:20201214224448j:plain:w640

久々にdpやAndroidの画面周りについてガッツリ調べてみたのですが、「以前よりもめんどくさくなってない…?」という感じでした。Pixel 3でdp -> pxの倍率がxxhdpiだから3…というわけではなく2.75になっているのは言われてみると「確かに…」という感じにはなるんですが普通に見落としていたので、デザイナーさんにわかりやすく説明しようと思う過程で自分の勉強にもなりました。dp周りはAndroidの画面デザイン・画面実装の基礎だと思うのでしっかり把握して認識を合わせてきれいに無理なくレイアウトできるようになりたいものですね。

References

余談:お前飲酒したの?

資料を書いているときは流石に飲酒していないんですが、構想中は横浜ビールを、資料の執筆中は軽井沢高原ビールのワイルドフォレストを頂きました。どちらも好きなビールなので美味しかったです! ところでリモート環境下になって途端にお酒に弱くなったんですが僕だけでしょうか。