はてなブックマーク

Google Spreadsheetを使っているとき、別のマスターデータシートから特定列だけ読み込みたい時がある。この時簡単に読み込む方法としてはIMPORTRANGEやQUERY関数を組み合わせて使う方法がある。 ただこのやり方だと、マスターデータシートに列が追加された時に壊れやすいという問題がある。QUERY関数などはヘッダー名を指定して読み込むことができず、SELECT Col1, Col3 のような書き方をする必要がある。これだとマスターデータの途中に列を追加した場合に簡単に壊れてしまう。 そこでマスターデータシートのヘッダー名をキーにして読み込む方法を考えてみた。サンプルは こちらのspreadsheetにおいている。 できること 以下のようなマスターデータがあるとして 別シートで一部だけ読み込みたい。この時にマスターデータに列追加しても壊れないようにしたい。 ヘッダー名をキーに

最近Goの並行処理を理解する必要が出てきたので、「Go言語による並行処理」を読んだ。 Go言語による並行処理 作者:Katherine Cox-BudayオライリージャパンAmazon 並行処理とはそもそも何か、goroutineやsyncなどの並行処理のためのパーツ、さらにchannelの基本的な使い方などを学べる内容だった。いろんなパターン例も入っていて、頭の整理に活用できた。 特にchannelの所有権をどう考えると扱いやすいかという点が参考になった。channelを使うときはまず所有権 = 初期化、書き込み、閉じる責任を持つgoroutineを決定し、以下を心がけるということだった。 所有するゴルーチンは次の手順を踏む チャネルを初期化 書き込みを行うか、他のゴルーチンに所有権を渡す チャネルを閉じる 上の3手順をカプセル化して、読み込みチャネルを経由して公開 所有権のスコープはで

並行プログラミングを学ぶ一環で、「Contextを完全に理解する」というテーマでGo Conference 2021 Autumnに登壇しました の記事を見つけ、contextのcancel伝播の実装方法が気になった。そこで自分でcontextのcancel部分だけを自作することで伝播の理解を深めてみた。 実装はこちらで、context.WithCancel的なものとcontext.WithDeadline的なものを実装している。またテストコードも用意している。 実装してみて面白いなと思ったのは、contextの実装は可能な限りgoroutineを起動しないようにうまく実装されているということ。 自作する前にgolangのcontextの実装を眺めていたが、最初はこの辺りを見て、子の側でgoroutineを起動して親のDone()を見ているのだなと思い込んでいた。しかし実際には、 親となる

UXリサーチ学ぼうシリーズ。今回は「カスタマーマニアになろう」というスライドを読んだ。 speakerdeck.com 顧客の深い理解の手法として、顧客インタビュー・没入・同化の手法があると述べた上で、特に顧客インタビューについて詳しく教えてくれるスライドだった。 特に顧客の意見ではなく事実を聞く方法やその時の心構えについての情報が非常に参考になった。今後顧客インタビューをしたいと考えている人は一読をおすすめする。 読書ノート - カスタマーマニアになるための構造 - 事実 => 推論 => 洞察 => 製品の順。とにかく事実を集める！ - 顧客インタビューは、「仮説の探索 or 検証」 x 「課題 or 解決策」の軸で4つに分かれる - 多くの場合は課題仮説のインタビューを行うことが重要 - インタビューの基本姿勢は聞く、話すは2割くらい - 相手に弟子入りするつもりで！ - 顧客の意見

施策のヒット率を高める方法について学んでいる。今回は「NO FLOP!」を読んだ。 Ｇｏｏｇｌｅ×スタンフォード ＮＯ ＦＬＯＰ！　失敗できない人の失敗しない技術 作者:アルベルト・サヴォイアサンマーク出版Amazon 定性調査・定量調査の両方で参考になりそうな前提知識を学べたと感じた。印象に残ったのは 「身銭」を切ってない人の意見を聞くな 結果に対して、何かしら失うものや得るものを持っている人の意見だけを聞く 気づき: 確かにこれが欲しいと言った意見を聞いて実装しても、それにお金を払う段階では使われないということはよく起こる 「あいまいな思考」を「検証可能な仮説」に変えるためには、できる限り数字で表現することが大切 あいまいな意見例: この申し込みボタンの横幅をもう少し広げたら、クリック率もちょっとは上がるんじゃないかな 検証可能な仮説: この申し込みボタンの横幅を20%広げた場合、申込

オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️‍🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分

dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め

最近仕事では機能開発ではなくデータ分析の仕事をしばらくやっているのだが、同僚から「本物のデータ分析力が身に付く本」というムックが良かったと聞いたので読んでみた。 本物のデータ分析力が身に付く本 (日経BPムック) 作者:河村 真一,日置 孝一,野寺 綾,西腋 清行,山本 華世日経BPAmazon この本は「データを集計し計算する」といった、いわゆる一般的にはデータ分析のメインと考えられていていろんな書籍で語られているような部分には焦点を当てず、その前後で何をすべきかを語ってくれている。たとえば データ分析実行の前には、開発設計で書くようなdesign docのようなものをデータ分析設計としてまとめる。さらに生データを見てデータの信頼性や傾向を事前チェックし、設計と事前チェック結果を見て分析方法を選択する データ分析実行の後には、結果の確からしさの検証をしつつ、バイアスを避けた結果の解釈を行

前回MySQLのREPEATABLE READとREAD COMMITTEDの違いを知るために色々試した - $shibayu36->blog;という記事を書いたところ、yoku0825さんにMySQL 8.0以降だとperformance_schema.data_locksが使えると教えてもらったので試した。 ちなみに、後ろからロックがぶつかるクエリを実行しなくても、MySQL 8.0だとSELECT * FROM performance_schema.data_locksでロックの範囲を確かめることができます。 ギャップつきロックがInnoDBのスタンダードで、X lockがレコードとギャップのロック、X not gapが単なるレコードロックになります— yoku0825 (@yoku0825) February 27, 2024 テーブル定義 CREATE TABLE `posts`

Goのパッケージごとのビルド時間を計測したいんだけど (どのパッケージのビルドに何秒かかってる、とか見たい) どうしたらいいのか、ちょっとググってみたけどランタイムにおけるパフォーマンス測定の話題ばっかり出てくる— うたがわきき (@utgwkk) February 26, 2024 前やったことあるがブログに書いてなかったのでメモしておく。 まずGoのビルド時間についてはAnalyzing Go Build Times | howardjohn's blogが非常に分かりやすく参考になる。この中でAction Graphというものに言及があり、これを使うことでパッケージごとのビルド時間を可視化できる。 例えば自分のgo_todo_appというものを使ってみる。 まずgo buildでactiongraph.jsonを吐き出し $ go build -debug-actiongraph=a

MySQLのトランザクション分離レベルについてふんわりとした理解しかないなと感じた。もう少し理解するために、とくにREPEATABLE READとREAD COMMITTEDの違いを手を動かして色々確認してみた。 以下の記事を参考にした。 [RDBMS][SQL]トランザクション分離レベルについて極力分かりやすく解説 #SQL - Qiita MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.1 トランザクション分離レベル 大まかな違い 公式ドキュメントを見る限り ノンリピータブルリード、ファントムリードが発生するか 範囲に含まれるギャップへのほかのセッションによる挿入をブロックするか の違いがありそうに見える。 ノンリピータブルリード、ファントムリードが発生するかを試す 以下のテーブルを作る。 CREATE TABLE `posts` ( `title`

Goで関数の引数に、struct Aという型もしくはstruct Bのどちらかを受け取るということをしたかった。interfaceをちゃんと切ってそれに必要なメソッドをAとBに実装することで実現できることを知った上で、あまり丁寧にそういうことをせずにやりたい。 色々調べると、genericsを使うとできるようだ。 package main import "fmt" type A struct { Field1 int } type B struct { Field2 string } type AorB interface { A | B } func PrintAorB[T AorB](s T) { // Tで受け取ったものをそのままs.(type)とは出来ないので、一旦anyへキャスト switch v := any(s).(type) { case A: fmt.Println(v.

最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理

異文化理解力という本がおもしろいと聞いたことがあり、興味があったので読んだ。想像以上に面白く夢中になって一気に読んでしまった。 異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養 作者:エリン・メイヤー,田岡恵英治出版Amazon この本は、国ごとの文化が、そこに属する人々の知覚・認識・行動へどれほど影響を与えているかを教えてくれる。指標として8つを提示し、それぞれの中で各国がどのような位置にいるかを相対的に示してくれる。8つの指標とは次のようなものだ。 コミュニケーション：ローコンテキストvsハイコンテキスト 評価：直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック 説得：原理優先vs応用優先 リード：平等主義vs階層主義 決断：合意志向vsトップダウン式 信頼：タスクベースvs関係ベース 見解の相違：対立型vs対立回避型 スケジューリング：直線

あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか

たとえばユーザー向け開発とリファクタリングなどの内部改善を、スプレッドシートの別シートで管理していたとする。これらを別シートに分けている理由は管理したい情報がそれぞれで違うためだ。 一方、それら進行状態については全部一覧で見たいことがあった。そうすることで、全てのタスクを含めて状況を把握しやすいためだ。 これを対応するためにGoogleスプレッドシートでいろいろ試してみたのでメモ。 シートの例 https://docs.google.com/spreadsheets/d/1IJ4qORImjfzVDodH0Z4vINRmXcqYjg9095uRVlTfSRI/edit#gid=0 にサンプルを作ってみた。シート1には機能開発一覧としてID、ステータス、タイトルという列を使って管理している。シート2にはリファクタリング一覧としてID、ステータス、名前、担当者が入っている。 QUERYと配列結

git stashをもっと便利に扱いたいと思い、fzfを使って使いやすくしてみた。以下のURLに載っているものを参考にして自分にとって使いやすいように改変した。 fzfでGUI選択したファイルをgit stashするシェルスクリプト git-stash-explore できたこと 今の変更ファイルをfzfを使って選択して、選択したものだけをstash (git-stash-select) stash一覧の中から中身をpreviewしながら選び、apply or deleteする (git-stashes) 現在の変更ファイルから一部を選んでgit stashするコマンド fzfでGUI選択したファイルをgit stashするシェルスクリプト を参考に、git-stash-selectというコマンドを作った。 #!/usr/bin/env bash # Get the root direct

gotesplitにAdd -race to list when it is specified for test optionsというPullRequestを投げたのだが、この背景を書いておこうと思う。 まずGoでは-raceオプションについて、以下のような挙動を起こす。 -raceフラグをつけるとruntime/raceがおそらく一番依存の深いところに追加されてコンパイルされるっぽい？ https://github.com/golang/go/blob/go1.21.2/src/cmd/go/internal/load/pkg.go#L2573-L2576 あたり？ そのため、go testとgo test -raceはビルドキャッシュが全く異なる。つまりgo testのビルドキャッシュはgo test -raceのビルドに全く使われないし、その逆も同じである gotesplitの以前

ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない

あるファイルが最近どの程度の頻度で更新されたのか、マージコミット単位(≒PullRequest単位)で調べたいことがあった。git logのコマンドを使ったら簡単に調べられたのでメモ。 たとえば1年以内に https://github.com/x-motemen/ghq のレポジトリで .github/ 以下に変更を加えたマージコミットを取得したい場合はこんな感じ。 $ git log --merges -m --first-parent --pretty=format:"%cd - %an: %s(%H)" --since="1 year ago" .github/ Sun Apr 16 23:27:26 2023 +0900 - Masayuki Matsuki: Merge pull request #359 from x-motemen/coverage(e7f736f22376d

エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満

会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると

あるディレクトリ以下で特定のパターンにヒットする行を全て削除する - $shibayu36->blog;に引き続き、やり方を模索してみた。 たとえばgolangを使っていて、ある処理をt.Cleanupに寄せたので対応するdeferを全部消したい時がある。 // StartHogeHelperの中でt.Cleanupを使って自動でhogeHelper.Close()を呼ぶことにした hogeHelper := StartHogeHelper(t) // この行を消したい defer hogeHelper.Close() これはつまり「StartHogeHelperを呼んだ次の行でdeferを呼んでいたらdeferの行を削除する」と言い換えられる。もちろんこのやり方だと間違ったものも削除することもあるが、そこは手動で直すとして、ひとまず大多数を自動削除したい。 awkを使って実現する。また効

良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また

ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス