2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。
朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。
以下セッションタイトルは2月13日時点の公式サイトより。
株式会社アトラクタ 原田騎郎(@haradakiro)氏
やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。
*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7
GitHub 池田尚史(@ikeike443)氏
GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。
株式会社grasys 長谷川祐介氏
サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。
ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
前半永瀬氏による enPiT 事例紹介。
後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。
こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。
ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。
東工大生イジりが嫌味がないのも素敵。
株式会社コロプラ 廣本洋一氏
機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。
株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏
ECナビについて2年弱かけて AWS 移行した話。
サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。
別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。
株式会社ZOZOテクノロジーズ 塩崎健弘氏
BigQuery 移行事例についての、味わいのある発表。
今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。
高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。
Pixel 4 で撮影してそのまま Lightroom で現像/編集し、あとで PC 上の Lightroom Classic 管理に移す私的フローを明確にしてみた。2年前に書き出した手順のアップデートである。
Pixel 4 上の下記のフォルダを FolderSync Pro で Dropbox に同期するようにしてある(記事)ので、そこからオリジナル画像ファイル・書き出したファイルを PC 上の保存先フォルダに移動してリネームする。
JPEG ファイルを編集した場合は、現像設定を含まないオリジナル JPEG ファイルをここで保存しておく。 DNG ファイルから現像の場合は現像設定未書き込みファイルまでは保存管理していないのでスキップ。
Lightroom Classic を起動し、 Lightroom と同期されているのを確認したあと以下の手順で。
現像設定をメタデータとして書き込んだ JPEG ファイルは、一般のアプリケーションで開いても編集前の画像しか見えず区別しづらいので -Lr をつけるルールにしている。
昨年11月2日に Pixel 4 に乗り換えてからはや7カ月。評判の良い Pixel 4 のカメラだが、画像処理の結果によっては撮った写真に好みではない不自然さを感じることがままある。 Pixel 4 は(どこまで生なのかわからないが) RAW 画像形式でも同時に保存ができるので、 JPEG 画像が好みではなかった場合には JPEG 画像からの補正以外にも RAW 現像という選択肢もあるのは嬉しい(色合い以外は Pixel 4 内で画像処理されたものの方が綺麗に感じることも多かったりするわけだが)。
前のスマートフォンに比べてカメラの性能がずっと良くになったのに「家に帰って仕上げてから」という意識が強くて外出先でその場でシェアするという活用が最近できていなかった。これでもうちょっとサクサクっとその場でやっちゃう意識がもてるようになるといいな。
Zettlr 4日目。18,000 弱テキストファイルがあるディレクトリーツリーをワークスペースとして開いたらかなり重かった。使い込んでいくにはパフォーマンスに問題があるな。
Zettlr をしばらく使ってみて、UI とエディタが美しい iA Writter が恋しくなってきた。 iA Writer ならファイル数が 19,000 超えても問題ないし安心だし iA Writer メインに戻ることにしよう。
ローカルホスト上のテキストファイルで管理していると、アプリケーションを乗り換えやすくていい。
Zettlr を使っていいなと思った内部リンクのための記述方法
は iA Writter で取り入れてみてもいいな。
現在日時で %Y%M%D%h%m%s 文字列を生成する Alfred ワークフローを作った。それから
cd ~/notebook pt -l -e "^ID:\\s+$query" . | head -n 1
で見つかったファイルを iA Writter で開く Alfred ワークフローを作成し、ID を指定して iA Writer を開けるようにした。 もっとサクッと開けるように PopClip のエクステンション化もしておきたいな。
キーを「ID」ではなく「ZID」に変更した。
[ ノート・日記はテキストファイルに ] [ Zettelkasten ]
日常生活の中で出来事や気づいたことを細かくキャプチャ(メモ)しておくと、あとで思い返して日記をまとめる際に楽(記事)。
その時々でキャプチャツールや書式を変えてきていて、今は日別のデイリーノートテキストファイルに iA Writer (Mac・Android) や 1Writer (iOS) で書き込んだり Alfred (Mac) のワークフローからさくっと追記したりしている。最終的に1日分の記録をまとめるテキストファイルに書き込んでいるので整理が煩雑にならないメリットがある。
その代わり iA Writer や 1Writer から書き込む時に、毎回今日の日付のファイルを選ぶというステップが入る。このほんの少しの負担がユビキタスキャプチャしにくくする要因だ。
Google Keep・Day One・瞬間日記のようにアプリを開いてから1タップで入力画面に入れるのが理想だが「日時記録問題」「テキストファイルへの個別転記の手間問題」「同期問題」などがありこれらも一長一短だったりする。
まず日付ファイルを選ぶという手間を減らすため、キャプチャ先を today.txt に一元化するスタイルをまたやってみることにした。
1つのファイルに追記していくやり方では書き込む位置までカーソルを動かすのが一手間でさっと書けないデメリットもある(記事)が、しばらくやってみよう。
[ ユビキタスキャプチャ ] [ ノート・日記はテキストファイルに ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。