以前PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;のようなことをやってみたのだが、BigQueryにデータを送ることでもう少し柔軟に変更のリードタイム*1などを可視化してみたのでメモ。 BigQueryで可視化するためにやったことは3つ。 BigQueryにマージされたPullRequest情報を送るスクリプトを作成 上記スクリプトをGithub Actionsで動かし、定期的にデータを送る BigQueryでViewを作り、Data Studioで可視化 BigQueryにマージされたPullRequest情報を送るスクリプトを作成 こういうイメージ。 import { execFileSync } from "child_process"; import { writeSync } from "fs"; imp

VSCodeでFindしている時に、マッチしているwordは背景色が変わって分かるのだけど、今どこにフォーカスしているかが分かりづらかった。これが特に問題が起こるのがReplaceをしようとしている時で、Replaceするたびに今どこ？とマッチ箇所を探していた。これだと時間がかかって困る。 調べてみるとTheme Color | Visual Studio Code Extension APIに書かれているように、自分のsettings.json内で自分用に色を調整し、見やすくカスタマイズ出来ることが分かった。これでFindの現在のマッチ箇所を見やすくしてみる。 Findの色のカスタマイズは editor.findMatchBackground: Color of the current search match. editor.findMatchHighlightBackground:

個人的にEmacsの置換のy/nで一つずつ置換するかしないか決められるUXが好きなので、VSCodeの置換でも近しいことが出来るように設定してみた。以下のような設定をすると、Replaceのインプットにフォーカス中にcmd+yでReplace実行、cmd+nでスキップということが出来る。便利。 keybindings.json // replaceでy/nでreplaceするかしないか選べることを模倣 { "key": "cmd+y", "command": "editor.action.replaceOne", "when": "editorFocus && findWidgetVisible && replaceInputFocussed" }, { "key": "cmd+n", "command": "editor.action.nextMatchFindAction", "whe

最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価

管理画面の時だけ認証をかけたいみたいな要件はよくある。今回はその要件をALBで特定のpathの時だけCognito認証を通すという構成で実装してみたのでメモ。構成はaws-cdkを使った。 やりたいこと /admin/以下の場合はCognitoの認証をかけ、許可したユーザーしかアクセスできないようにする それ以外のパスではアプリケーションに認証なしで繋がるようにする 実装 aws-cdk 1.62.0を使って実装した。なお今回のコードは実際の実装をミニマムに変更しているので、動作確認はちゃんと出来ていない（たぶんそのままだと動かなそう）。雰囲気だけ感じてください。 import { IVpc, Port } from "@aws-cdk/aws-ec2"; import { Ec2Service } from "@aws-cdk/aws-ecs"; import { Application

useEffect/useLayoutEffect周りで絶賛ハマり中で、また React17におけるuseEffectの破壊的変更を理解する の記事が面白かったので、自分の手元で動かしてみて理解を深めてみた。調査したことを自分用のメモとして取っておく。React 17でuseEffect周りで破壊的な変更が入るということなので、Reactのバージョンは17.0.0-rc.1で試した。 気になっていたこと 親子のコンポーネントでuseEffectがどの順で実行されているのか useLayoutEffectが途中にあるとどのような挙動をするか useEffect/useLayoutEffectとレンダリングやDOMへの反映の実行順序 調査メモ shibayu36/typescript-playground/react-playground あたりで試した。react-playground ディ

スプレッドシートで保育園の在庫管理をしようとして失敗した...いい方法があれば教えてもらいたい。 失敗したけど学びはあったので、ここにメモしておく。 困っていたこと 毎日保育園で子供二人の服やおむつなどがどのくらいあるか把握するのが難しかった アイテムリストとそれぞれの個数があって、プラスマイナスボタンで増減できるみたいなのがあると便利そうと考えた。またそれを妻と共有もしたい だがiOSアプリで便利そうなアプリが見つからなかった そのため、GoogleスプレッドシートとGoogle Apps Scriptで、簡易的なストック管理が出来るのでは？と考えた。 やってみたら失敗した 実装は出来た。 https://github.com/shibayu36/gas-stock-management この実装をGoogle Apps Scriptにアップロードし、画像でプラスマイナスボタンを作り、ス

Jamboardを使ってオンラインでプラニングポーカーをするお試しをしてみたので知見を共有します。 課題 リモートワークで全員がオンライン前提となり、かつプライベートエリアなのでミーティングではビデオを付けたくないメンバーがいる。もちろんミーティングの円滑化のためにビデオを付けることを強要したくはない。 しかし、プラニングポーカーはこれまで指でフィボナッチ数を出すというモデルでやっていた。ビデオを付けない人がいる場合、このやり方ではプラニングポーカーができない。 こういう状況で、どのようにプラニングポーカーで見積もりを行うかが課題となっていた。 Jamboardを使ってオンラインでプラニングポーカーをする解決案 GoogleのアプリでJamboardというホワイトボードアプリがある。これを使ってプラニングポーカーをしてみた。 やり方 付箋でフィボナッチ数とカーソル置き場を並べたJamboa

indent-rainbow (VSCode拡張) https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow インデントに色を付けてくれる。それだけなのにすごく見やすくなって便利。 TabNine (VSCode拡張) https://www.tabnine.com/ deep learningでいい感じに補完候補を出してくれるやつ。書きたいことが思った以上に補完で出てくるので助かっている。 Tree Style Tab (Chrome拡張) https://chrome.google.com/webstore/detail/tree-style-tab/oicakdoenlelpjnkoljnaakdofplkgnd Chromeのタブをツリー状に表示してくれる。ツリー状で出すツールはたくさんある

最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす

最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が

最近TypeScriptの学習をしようと思い、何でもTypeScriptで作ってみている。今回はCLIツールを作ろうと思ったのだが、ビルド環境やeslint環境など考えることが結構あった。そこでTypeScriptでのCLIツールのプロジェクトサンプルを作りながら勉強してみた。 作成したのは https://github.com/shibayu36/typescript-cli-project 。 npm install -g shibayu36/typescript-cli-project でtypescript-cli-projectというコマンドがインストールされ実行できるようになった。 このプロジェクトサンプル作成を通して学んだことをメモしておく。 参考文献 以下2つの文献が入門として非常に参考になった。この2つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。

開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。 ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。 以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうま

これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの

github.blog こういうの来て便利だな〜と思ってたけど、デバッグにも有用だった。 例えばGithub Actionsのon scheduleを使ってcronのように実行したい時、これまでだと デフォルトブランチにmergeして、その時間になるまで待つ ワークフローをトリガーするイベント - GitHub Docsのrepository_dispatchを有効にして、eventを発行する ただし ノート: このイベントがワークフローの実行を引き起こすのは、そのワークフローのファイルがmasterもしくはデフォルトブランチにある場合のみです。 という制約があって、変更をデフォルトブランチにmergeしないと試せなかった のように、両方とも一回デフォルトブランチにmergeしないとお試し出来なかった。 しかしworkflow_dispatchはブランチも自由に選べるので、変更しているブラ

いつの間にか普通に出来るようになっていた。 git stash push hoge.txt fuga.txt 参考 Stash only one file out of multiple files that have changed with Git? - Stack Overflow Git 2.13くらいから出来るようになったっぽい？

10年前からブログを始めて、10年間コツコツコツコツ学んだことや考えたことを記事として書き続けてきた。その結果、ついにブログの記事総数が1000記事近くになってきた。10年間かなり頑張ってきたなあと感慨深い。ありがたいことに読者数も1000人ほどいて色んな人に見てもらえるようになり、これも継続的に書き続けたおかげだなあと思う。 また、ずっとブログを書き続けてきたことで、以下のような多くのメリットを受けることができた。 ブログを書くこと自体が自分の頭の整理に繋がる その後知識を忘れたとしても、ブログを見返せば思い出せる 初めからブログに書くつもりで勉強すると、勉強の効率が上がる 反対意見とかツッコミを入れてくれる人が出てきて、自分の思い違いを正したり、より考えを洗練させることができる 記事を書き続けていると意外と読者が増えていて、気合を入れた記事を書いた時もみんなに見てもらえる 完全公開の場

社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組

エンジニアをやっていく上で、ビジネス側の素養もあったほうがビジネスサイドの人からも相談しやすかろうと思い、昔おすすめされていた「MBAより簡単で英語より大切な決算を読む習慣」を読んだ。 MBAより簡単で英語より大切な決算を読む習慣 作者:シバタナオキ日経BP社Amazon この本は、決算を読む上で何を重視して読むのか、それぞれのビジネスモデルごとでどういう指標が大事かを教えてくれる。ビジネスモデルごとの売上を決める方程式を教えてくれた上で決算から読み解くという流れになっているので、ビジネスと決算が直接結びつくイメージが付いてよかった。 以下印象に残った部分のメモ。 本に載っている実例を見ると決算を見る時は以下のようなところを見ておくと良い？ 売上・営業利益・利益率 YoY(対前年比) ビジネスモデルの方程式を抑えて、その指標を見る 競合/類似企業と指標を比較する(特に王者と比較する) 市場

今見ているファイル内をSearchしやすくする「Search in Current File」というVSCode拡張を作ったので紹介です。 https://github.com/shibayu36/vscode-search-in-current-file https://marketplace.visualstudio.com/items?itemName=shibayu36.search-in-current-file 背景 Emacsにはhelm-occurという拡張があって、インクリメンタルサーチからスムーズにファイル内の検索結果一覧を見れる拡張がある。これが現在のファイルを探索するのに非常に便利で愛用していた。 VSCodeでも同じようなことが出来ないかなと思ったので、勉強がてら拡張を作ることにした。 使い方 Search in Current File - Visual Stu