はてなブックマーク

CursorやClineなどで生成AIを使ってコーディングをしていると、Reasoningモデルとか、Thinkingモードとか、そういったワードに出会うことが多い。これらが意味することについて理解できてないと感じていた。 何かを学ぶとき、資料を読むだけではなく手を動かしてみると理解が早くなる。そこでChatGPTのDeep Researchでハンズオン資料を作り、それを元に学ぶと効率が良いのではないかと考えた。今回の記事ではハンズオンの作成と実施の過程をまとめておく。 ハンズオン資料をDeep Researchで作る 次のように質問してDeep Researchでハンズオン資料を作る。 すると https://chatgpt.com/share/6819d686-5ae0-8010-8196-d532528dc82a のような資料が作られた。 序文 実験の章の一部 見出しはこういう感じ。

最近CLINEに全部賭けろのような記事もあったように、AIエージェントによるコーディングが非常に話題になっている。一方自分は色々試してみるものの、仕事上ではなかなかAIエージェントによるコーディングをうまく使いこなせていない。 ただAIエージェントによるコーディングは置いておいて、エンジニアリングに普通に便利にAIを使えている。それによって数年前と比較するとかなり生産性が上がっている。 そこで今回は自分がエンジニアリングにどうAIを活用しているか、何が便利に思っているかをまとめてみる。 CursorのTabキーによる補完 自分が知りたい技術領域について壁打ちしてもらって作りながら学ぶ コードを読み込んで概要をmermaidで図にする 7割くらいの精度でざっくり理解したい時のコード調査 コーディングエージェントでPoCを作る 枯れた技術の使い方のキャッチアップにChatGPT、新しい技術にP

AIを使ってMySQLのクエリを書くときは、自分が関わっているプロジェクトのスキーマ情報を読み込ませることが必須である。ただし超巨大プロジェクトに携わっていると、特定データベースのテーブル数が数百規模になってしまう。この場合スキーマのダンプ情報を読み込ませるとコンテキスト長が非常に長くなってしまい、失敗することが多かった。 この問題を解決するため、MCPを使ってスキーマ情報をいい感じに圧縮して返すことでSQL生成がもっとうまくいくのではないかと考えた。そこで、テーブル一覧と詳細情報を段階的に取得できるMCPサーバーを、MCPの勉強がてら作ってみた。 作ったもの https://github.com/shibayu36/mysql-schema-explorer-mcp 次のように動く。 実際に大きめなプロジェクトで試したところ、いつもよりうまく生成できるようになった気がする（仕事のプロジェ

GitHub上のOSSにcontributeするためにcommitメッセージやPullRequestのコメントを英語で書くことがある。もう自分で英語を書くのは無理なので自動翻訳を活用したい。この時DeepLなどを使ってもいいのだが、もう少しチューニングを加えたい。たとえば 英語非母語話者同士の会話になることが多いので、できるかぎり平易な表現を使う 1行の場合はcommitメッセージとして、複数行の場合はPullRequestのコメントとして翻訳したい すぐに使えるようにgit commit用のコマンドやMarkdownで出力したい などなど。 そこで最近はChatGPTのProjectsを使って翻訳をしている。 たとえばこんな感じに指示を用意しておいて ソフトウェアエンジニアリングでのコミュニケーションに用いるために和英翻訳をします。以下のことに注意して翻訳してください。 - 英語非母語話

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

最近はGoの並行プログラミングを学んでおり、ちょうど「Go言語で学ぶ並行プログラミング」という本が出たばかりだったので読んでみた。この本は自分にめちゃくちゃ刺さって面白かった。 Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ 作者:James Cutajar,柴田 芳樹インプレスAmazon この本はGoで並行プログラミングをどうやるかという本ではない。そうではなく並行プログラミングの概念が分かりやすいGo言語を活用することで並行処理の原則や技術を学べる本になっている。そのため、Goを使って独自にRWMutex、Semaphore、WaitGroup、channelを実装していきながら理解を深めていく内容となっている。実装することが一番理解を深める良いやり方と自分も感じているため、とても参考になった。 実際に本を読み

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

エディター側でなくCLI側でgit grepするのはいろんなオプションを渡せて便利だ。たとえば --and や --or でいろんな条件で絞り込んだり、-C オプションで周辺の行も一緒に見ることもできる。 一方でCLI側でのgit grepでは、エディター側をさっと開きにくいという問題がある。そこで、git grepの結果をfzfでさらに絞り込んだ上で選択するとすぐにエディターで開けると便利そうと感じ、git-grep-fzfというコマンドを作ってみた。 使ってみている様子はこんな感じ。grepした後にfzfで絞り込んで該当行をエディターで開いている。https://github.com/golang/go に対してgit-grep-fzf Sortedしている様子。 また、git grepに渡せるオプションはこのコマンドに渡すことができるので、複数条件で絞り込んで周辺行を見ながら開くこと

最近仕事では機能開発ではなくデータ分析の仕事をしばらくやっているのだが、同僚から「本物のデータ分析力が身に付く本」というムックが良かったと聞いたので読んでみた。 本物のデータ分析力が身に付く本 (日経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の出現回数は変わってないのでマッチしない