並行プログラミングを学ぶ一環で、「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割くらい - 相手に弟子入りするつもりで！ - 顧客の意見

小1の子供が夏休み明けに週1くらいの頻度で「学校に行きたくない」と言い始めた。そういう日はどれだけ行かせようとしてもひたすら泣いて怒って行かない。 話を聞いてみると、本人にとっていろんな不安がある時に行きたくない気持ちになるらしい。たとえば必要な持ち物があると聞いたけどそれが何か分からない、鍵盤ハーモニカのテストがうまくできるか分からないなど。 行きたくないなら最悪行かなくてもいいかと思っていた一方で、学校へ行かないと親はまったく仕事はできなくてイライラしてしまうし、学校の手軽に多様な学習をしてもらえる環境を活用できないし、と可能なら学校に行ってほしいなと感じていた。 なんとか学校に行ってもらうには親の最初の行動が重要そうだなと考え、色々調べながら対策していった。今回は何をしていたかメモを残しておく。 行き渋りや不登校についての知識を得る まずは知識が大切だということで、行き渋りや不登校に

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

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

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

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

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

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

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.

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

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

あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $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 にあるように、サブツリーマージという方法も取れる。しか

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

あるファイルが最近どの程度の頻度で更新されたのか、マージコミット単位(≒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

ずっと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の出現回数は変わってないのでマッチしない

A Tour of Goが終わり、もう少しGo自体の深掘りをしたいためGoの書籍をいくつか読んでみたのでメモ。今回読んだ書籍は以下の三冊。 実用 Go言語 ―システム開発の現場で知っておきたいアドバイス 作者:渋川 よしき,辻 大志郎,真野 隼記オライリージャパンAmazon Go言語プログラミングエッセンス エンジニア選書 作者:mattn技術評論社Amazon 改訂2版 みんなのGo言語 作者:松木 雅幸,mattn,藤原 俊一郎,中島 大一,上田 拓也,牧 大輔,鈴木 健太技術評論社Amazon それぞれの感想としては 実用Go言語：業務で使っていると起こるような色んなHowToを大量に提供してくれている。今の段階で全部読むというより、必要に応じて再度読むインデックス的な使い方が良さそう。クックブック的。 Go言語プログラミングエッセンス：最近出た本のため、最近のGoに即した内容を学

Rails勉強し直している - DB操作編 - $shibayu36->blog;に引き続きRailsを勉強し直している。今回はHatena-TextbookのWebアプリケーションの課題を通して学習した。 作ったもの diffはこの辺。ユーザーが存在する前提で、記事のCRUD処理を実装した。 今回学んだことを雑多に記録していく。 /:username/entries/:id のようなルーティングを作る方法 あるユーザーの記事一覧というURLを作るため、/:username/entries/:id というルーティングが作りたかった。gitlabのこの辺とかを参考にすると、scopeを使うと良さそうであった。 例えばこんな感じ。 scope '/users/:username' do resources :entries end またルーティングヘルパーにUserモデルを渡すだけで /use

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム 作者:石田保輝,宮崎修一翔泳社Amazon アルゴリズム図鑑を眺めていて、二分ヒープ構造は優先度付きキューに使われることを知った。面白いなーと思うと同時に、そういえば二分ヒープ構造の実装をしたことがなく、あまり理解できていないことに気づいた。そこで簡単にRubyで実装をしてみたのでメモ。簡単なテストケースを作ったので多分合ってると思うけど、もしかしたらバグっているかも... 二分ヒープの詳細は二分ヒープ - Wikipediaも参考。 【2023/01/03 14:01追記】要素数が1の時に要素が空にならないバグがあったので修正しました。コメントありがとうございます。https://github.com/shibayu36/algorithms/commit/6c2ce588f7bc7fb890c6a560c7ab062c6f531a9a

すごく焦ったけど良い形で対応できたので書いておく。 状況 子供が40度近い熱が出たので小児科へ。インフルエンザA型の診断を受けて薬をもらう。自転車での帰り道に違和感を感じたので後ろを振り向いたら、子供がけいれんを起こしていて泡も吹いていた。 熱性けいれんのことも頭によぎりつつ、今まで体験したことなかったので自転車を停めてすぐに119連絡。呼吸を確認してくださいと言われたので確認すると大丈夫だった。けいれんが治っても意識は戻らなかったので救急車の到着を待つ。救急車の中でけいれんの様子を救急隊員に報告する。この時熱は40.6度まで上がっていた。受け入れ病院の電話を聞きながら1~2個から断られているのを聞いて、医療崩壊怖いと感じる。 病院に着いた時、反応は薄いが多少子供の意識が回復していた。けいれんの様子や意識の回復の様子から考えて、単純性の熱性けいれんだろうと病院が判断。けいれんを防ぐ坐薬を入