nDiki : ワークフロー

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

Alfred から指定したチャンネルを Mac 版 Slack デスクトップクライアントで開く

 slack://channel?team={TEAM_ID}&id={CHANNEL_ID}

という URL で Mac 版 Slack デスクトップクライアント上で指定したチャンネルを開けるということがわかったので Alfred でワークフローを作って開けるようにした。

deep linking を使うだけなら認証・承認まわり関係ないのでお手軽。

TEAM_ID と CHANNEL_ID はデスクトップ版のサイドバー上のチャンネルでリンクをコピーして確認。

• Deep linking into Slack clients | Slack

Alfred のワークフローをまとめる

Alfred からテキストノートに書き込んだり開いたりするワークフロー、ちょっとした亜種(書き込むファイルの違いとかタイムスタンプの有無とか)毎にとりあえず複製してアレンジして増やして済ませていたのだけれど、さすかにごちゃごちゃしてきたのでようやく1つにまとめることにした。

フローの途中で変数を設定して run scripts しているシェルスクリプトの動作をコントロールする形でまとめた。

ああ Alfred の Android 版が欲しいな。

nNote ノートテキストファイルを Alfred で一発で開けるようにした

Alfred からテキストノートに書き込んだり開いたりするワークフローを整理していて「そういえば最近 nNote 活用していないな」と気がついたので、その日の nNote ノートテキストファイルも Alfred からさくっと一発で新規作成 & iA Writer でオープンできるようにしておいた。

[ ノート・日記はテキストファイルに ]

Pixel 4 撮影からの私的 Lightroom ワークフロー

Pixel 4 で撮影してそのまま Lightroom で現像/編集し、あとで PC 上の Lightroom Classic 管理に移す私的フローを明確にしてみた。2年前に書き出した手順のアップデートである。

【Pixel 4】Pixel 4 で撮影しシェアできる画像を書き出して使う

1. Pixel 4 で撮影する。
2. Lightroom に写真(DNG または JPEG) を追加。
3. Lightoom で編集。
4. 「JPG を保存(小)」(JPG・2048px・画質90%)で書き出し。

【PC】オリジナル画像ファイル・書き出したファイルの保存

Pixel 4 上の下記のフォルダを FolderSync Pro で Dropbox に同期するようにしてある(記事)ので、そこからオリジナル画像ファイル・書き出したファイルを PC 上の保存先フォルダに移動してリネームする。

• DCIM/Camera/
  • Pixel 4 のカメラが保存したオリジナル JPEG ファイル
• Pictures/RAW/
  • Pixel 4 のカメラが保存したオリジナル DNG ファイル
• Pictures/AdobeLightroom
  • Lightroom で書き出した JPEG (SNS などにシェアしたであろうもの)

JPEG ファイルを編集した場合は、現像設定を含まないオリジナル JPEG ファイルをここで保存しておく。 DNG ファイルから現像の場合は現像設定未書き込みファイルまでは保存管理していないのでスキップ。

【主に PC】現像設定が含まれる画像ファイルの保存

Lightroom Classic を起動し、 Lightroom と同期されているのを確認したあと以下の手順で。

1. DNG ファイル(現像設定はメタデータ書き込み済み)を別フォルダにコピーしリネーム。
2. JPEG ファイル(現像設定はメタデータに書き込み済み)を別フォルダにコピーしリネーム(ベース名の末尾に -Lr をつける)。
3. Lightroom Classic でコピー先のフォルダを同期しカタログにのせる。
4. Lightroom で画像を削除。
5. Pixel 4 の Google フォトアプリでデバイスから各画像ファイルを削除。
6. (必要があれば)現像設定が含まれる画像ファイル(DNG/JPEG)から元サイズで JPEG で書き出して、仕上げ済みのフォルダへ移動したり Google フォトにアップロードしたりしておく。

現像設定をメタデータとして書き込んだ JPEG ファイルは、一般のアプリケーションで開いても編集前の画像しか見えず区別しづらいので -Lr をつけるルールにしている。

背景

昨年11月2日に Pixel 4 に乗り換えてからはや7カ月。評判の良い Pixel 4 のカメラだが、画像処理の結果によっては撮った写真に好みではない不自然さを感じることがままある。 Pixel 4 は(どこまで生なのかわからないが) RAW 画像形式でも同時に保存ができるので、 JPEG 画像が好みではなかった場合には JPEG 画像からの補正以外にも RAW 現像という選択肢もあるのは嬉しい(色合い以外は Pixel 4 内で画像処理されたものの方が綺麗に感じることも多かったりするわけだが)。

前のスマートフォンに比べてカメラの性能がずっと良くになったのに「家に帰って仕上げてから」という意識が強くて外出先でその場でシェアするという活用が最近できていなかった。これでもうちょっとサクサクっとその場でやっちゃう意識がもてるようになるといいな。

日次・週次・月次まとめをいい感じにやりたい【日記】

週次報告・月次報告が少し増えてきたので、日次ノートから週次レポート・月次レポート化していくワークフローとドキュメント管理について整理しなおし。

日次・週次・月次の階層別にデータを表示(あるいは入力)したうえで考察を書き込めて、あとでそれぞれ日次・週次・月次のビューを作れるようなドキュメント管理をしたいなあ。できればテキストファイルベースで。

Alfred でのノートテキストファイル作成ワークフローのバリエーションを作りすぎた

• 日別の「デイリーノート」
• ちょっとした「ノート」
• ちょっとした公開用の「nNote」

に加えて

• 「issue ノート」
• 「thoughts ノート」

も Alfred ワークフローで一発作成できるようにしてあったのだけれど、ちょっとやりすぎで最後の2つはすぐ使わなくなったので削除。

今日のさえずり: 我が家にもキットカットのダウンサイジングの波がやってきた

• 09:41 そっか、今年は新成人ではない自分も日本中の成人式を YouTube ライブで観られるんだ。
• 15:13 今日は2008年の写真を整理して Google フォトにアップロード。
• 15:17 我が家にもキットカットのダウンサイジングの波がやってきた。ちょっと悲しい。
• 18:21 Unison File Synchronizer を呼び出す Alfred ワークフローを作った。なるほど Script Filter input は JSON でリストを返すスクリプトを用意すればいいのね。

Zettlr 4日目、iA Writer に戻す

Zettlr 4日目。18,000 弱テキストファイルがあるディレクトリーツリーをワークスペースとして開いたらかなり重かった。使い込んでいくにはパフォーマンスに問題があるな。

Zettlr をしばらく使ってみて、UI とエディタが美しい iA Writter が恋しくなってきた。 iA Writer ならファイル数が 19,000 超えても問題ないし安心だし iA Writer メインに戻ることにしよう。

ローカルホスト上のテキストファイルで管理していると、アプリケーションを乗り換えやすくていい。

Zettlr を使っていいなと思った内部リンクのための記述方法

• %Y%M%D%h%m%s 形式の ID を YAML front matter に書く。
• - [[%Y%M%D%h%m%s]] の形でリンクを書く。

は 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 のエクステンション化もしておきたいな。

2021年2月3日追記

キーを「ID」ではなく「ZID」に変更した。

[ ノート・日記はテキストファイルに ] [ Zettelkasten ]

キャプチャ先を today.txt に

日常生活の中で出来事や気づいたことを細かくキャプチャ(メモ)しておくと、あとで思い返して日記をまとめる際に楽(記事)。

その時々でキャプチャツールや書式を変えてきていて、今は日別のデイリーノートテキストファイルに iA Writer (Mac・Android) や 1Writer (iOS) で書き込んだり Alfred (Mac) のワークフローからさくっと追記したりしている。最終的に1日分の記録をまとめるテキストファイルに書き込んでいるので整理が煩雑にならないメリットがある。

その代わり iA Writer や 1Writer から書き込む時に、毎回今日の日付のファイルを選ぶというステップが入る。このほんの少しの負担がユビキタスキャプチャしにくくする要因だ。

Google Keep・Day One・瞬間日記のようにアプリを開いてから1タップで入力画面に入れるのが理想だが「日時記録問題」「テキストファイルへの個別転記の手間問題」「同期問題」などがありこれらも一長一短だったりする。

まず日付ファイルを選ぶという手間を減らすため、キャプチャ先を today.txt に一元化するスタイルをまたやってみることにした。

1つのファイルに追記していくやり方では書き込む位置までカーソルを動かすのが一手間でさっと書けないデメリットもある(記事)が、しばらくやってみよう。

[ ユビキタスキャプチャ ] [ ノート・日記はテキストファイルに ]