複数人で開発しているプログラムのリポジトリで、自分用のAIエージェントスキルを作りたいということがある。 将来的には共有するかもしれないが、雑なものをリポジトリに入れて他の人の環境で意図せず発動して迷惑をかけるのもよろしくないといったときだ。
$HOME/.claude/skills/に置けば自分用のスキルになるが、ここに置くとプロジェクトに関係なく発動するものになってしまう。
なので、プロジェクト内に配置しつつGitに管理させないようにしたい。
.gitignoreを使えばそれも可能だけど、.gitignoreは共有物なので自分だけが使うスキルの名前をそこに書き足していくのは理想的ではない。
要するに、.gitignoreを使わずにプロジェクト内のファイルをGitの管理対象から外したい。
こういうときは .git/info/exclude を使うことができる。
次のように書いておけば自分だけが使うスキルを手元のリポジトリに置いておける。
echo .claude/skills/my-skill/ >> .git/info/exclude
IntelliJのエディタ上でVitestのテストを実行しても "No tests were found" などとだけ表示されてテストが実行されなくて困っていたが、Vitestがv4に上がった際の変更でうまく機能しなくなっていたようだった。
https://youtrack.jetbrains.com/issue/WEB-75191/No-tests-found-when-running-Vitest-4-tests
IntelliJを最新に上げたらテストが実行されるようになった。
Manning社で書籍を買うとliveBookといって購入した書籍をブラウザで閲覧できるようになる。
この閲覧画面の右上にAIというアイコンが出ていて、そこのテキストボックスをクリックすると下にいくつかの典型的な用途と思われるテキストが表示された。
そこに "summarize this chapter" とある。 出版社が直々に要約機能を提供するのは目新しいのでは。
要約であれば事前に作っておいたものを出した方が速いし、AIを使った便利機能を試行錯誤する中で一時的に利用できているだけの可能性が少なからずありそうだけど、公式の要約が付くのが当たり前になってくれると個人的にはありがたい。
Markdownで書いたテキストをGoogle Docsに手軽に取り込めないかと思って検索すると、Docs自身にすでにMarkdown記法フレンドリーな機能を有効にする設定があることを知った。
この機能を有効にしてMarkdownのテキストをコピーし、「マークダウンから貼り付け」コマンドを編集メニューまたはコンテキストメニューから実行すれば見出しや箇条書きなどが反映されたテキストになる。
個人アカウントだからかコードブロックが通常のテキストになってしまいちょっと残念。
AI向けの指示書きで情報を構造化するのにMarkdownが標準的に使われるので、人間向けとAI向けの書き物間でコピペするのに重宝しそう。
macOSでPDFを読むとき、skimというアプリを使っている。 今となってはmacOS標準のPreviewアプリでもわりと快適にPDFを読むことができるのでskimを使い続けている必然性は薄れているが、使い慣れているので惰性で使っている。
今日もskimを使っていたところ、検索ワードを入力すると途中でクラッシュすることを繰り返した。 そこでPreviewで開き直して同じワードで検索したところ、スペース区切りの二つの単語に対して、単語の並びではなく、入力した単語すべてを含むページがヒットするという挙動をしているようだった。 Googleの検索よろしく二つの単語をダブルクオーテーションで囲ってみたが、そうすると一件もヒットしない。
Previewでフレーズ検索する方法を求めてWebを検索して、検索バーの虫眼鏡アイコンをクリックして“exact phrase”に変えられるよという掲示板の書き込みを見つけた。 言われてみると虫眼鏡アイコンの横に意味ありげな印がついている。 そしてそれをクリックすると「正確な語句」という設定が出てきた。
これにチェックを入れると意図した検索ができるようになった。 めでたしめでたし。
ちなみに古い情報だと引用符で囲うことでフレーズ検索ができるというものも見かけた。 どこかでこの辺の挙動が変わったのかも。
pgModelerはPostgreSQLを対象とするモデリングツールで、ビルド済みのバイナリは有料で販売していてソースから自分でビルドするのはご自由にという形で提供されている。 ちょっと試してみたいという程度なので今回はソースからビルドしてみた。 多少の試行錯誤があったので、手順をメモする。
$ brew install postgresql $ brew install qt@5 $ git clone https://github.com/pgmodeler/pgmodeler.git $ cd pgmodeler
libxml2も使うがXcodeに付いてくるものがあるので別途インストールする必要はない。
バージョン番号などの詳細は実行したタイミングによって異なるので適宜修正する。
diff --git a/pgmodeler.pri b/pgmodeler.pri index 1ab60335..e2dbdd1b 100644 --- a/pgmodeler.pri +++ b/pgmodeler.pri @@ -195,8 +195,8 @@ unix:!macx { } macx { - !defined(PGSQL_LIB, var): PGSQL_LIB = /Library/PostgreSQL/12/lib/libpq.dylib - !defined(PGSQL_INC, var): PGSQL_INC = /Library/PostgreSQL/12/include + !defined(PGSQL_LIB, var): PGSQL_LIB = /opt/homebrew/Cellar/postgresql/14.1_1/lib/libpq.dylib + !defined(PGSQL_INC, var): PGSQL_INC = /opt/homebrew/Cellar/postgresql/14.1_1/include !defined(XML_INC, var): XML_INC = /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml2 !defined(XML_LIB, var): XML_LIB = /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libxml2.tbd INCLUDEPATH += $$PGSQL_INC $$XML_INC
$ /opt/homebrew/Cellar/qt@5/5.15.2_1/bin/qmake -r CONFIG+=release pgmodeler.pro $ make $ make install
これで/Applications/pgModeler.appが作られるが、アプリをクリックしても実行できない。 実行するにはコード署名が要るようで、以下のコマンドでそれができる。
$ codesign --force --deep --sign - /Applications/pgModeler.app
これでpgModeler.appを実行できた。
最初Qt5をインストーラでインストールして使おうとしたが、ビルドが通らなかった。 コンソール出力を見るとリンカがエラーを出していて、x86_64とarm64が混じってるらしかった。 qmakeで生成されたMakefileにx86_64という指定があったので、インストールしたQtがx86版だったっぽい。 postgresqlに合わせてqt5もhomebrewでインストールしてqmakeからやり直すとビルドできた。
コード署名のやり方は、アプリの実行ができなくてコンソールアプリでエラー内容を確認して、そこにあった
Namespace CODESIGNING, Code 0x2
という文言で検索すると同様の問題に遭遇して解決できたケースを見つけることができた。
pgModelerのサイトにソースからのビルド方法はあるが、コード署名については触れられていない。 pgmodeler.io
More Effective Agile “ソフトウェアリーダー”になるための28の道標
Code CompleteのSteve McConnellさんによるアジャイル開発についての本。 Code Completeは地味だけど実践可能で有益な良いコードを書くためのアドバイスが詰まった本という印象だったので、アジャイル開発方法論は若干食傷気味ではあるけれども読んで損はしないだろうと思って手を出してみた。 そして読んで良かったと思える本だった。
この本は4部構成で、それぞれ
となっている。 この中で自分にとって新鮮味があった、得るものがあったと思った点をかいつまんで書いてみる。
アジャイルな開発方法論の話はチーム内のプラクティスに焦点を当てたものが多いので、チームを外側について書かれた4部が個人的には新鮮味があった。
より効果的なアジャイル：リーダーシップという章に
という節がある。 チームに指示を出す立場の人とチームとの間の距離感についての話だ。 スプリント中はチームを邪魔しない、チームにはプロジェクトの目的と求められている最終状態と各人の役割を伝える程度にして細かいやり方まで口出ししないといったことが書いてある。
こういうさじ加減については他の書籍などでも見かけた。 BasecampのShape Upには、イテレーションの間は基本的にはプロジェクトを止めたり方針変換しないことや、チームがプロジェクトに取り掛かる際にタスクレベルに分解するのはチーム自身でやることなどが書いてある。 また、Think Like Amazonという本には、チームの仕事の成果を測るための指標を設定するものの目標をどのように達成するのかまでは関与しないということが書いてあった。 チームメンバーが気分よく仕事ができて管理する側もなるべく手間がかからないようにしつつ目的を果たすということを目指すと、大体この辺に落ち着くようだ。
予測可能性という章がある。 プロジェクトにはスコープ、コスト、期日といったパラメータがあり、プロジェクトによって期日が固定だったりスコープが揃うことが必須だったりと事情が異なる。 スコープ最優先だと終了日やコストを予測することになり、期日を優先するとスコープ（盛り込める機能）を予測することになり、それぞれのケースでどのように予測するか、という話である。 一方、インセプションデッキというものがある。 プロジェクトのスコープ、コスト、期日、品質のうちどれを優先するかメンバー間で意識合わせをするためのプラクティスだ。 つまりこの章の内容は、インセプションデッキの結果によってプロジェクトにおいて予測することになる対象が変わりうるという話である。 これまでそういう認識を持っていなかったので、ちょっとした気づきだった。
作業レベルの話にはわりと馴染みのある話が多かったが、それでもいくつか印象に残る箇所があった。
要求の作成の章に、プロダクトバックログに入れる要求の作り方にはトップダウンなやり方とボトムダウンのやり方があるという話があった。 要求を獲得する方法は開発の方法論ごとに独立して語られることが多いと思うが、いろんなやり方を集めてそれらをトップダウンとボトムアップに分類して提示されたのを見て頭が整理された。
また、仕事の質を測るのに、作業を新しいことをする作業と手戻り作業に分けて手戻り作業のストーリーポイントの割合を見るという話があった。 これまでアジャイルな方法論の文脈で仕事の量を見る指標（ベロシティ）の話は何度も見てきたが質を測るという話を見た記憶がなく、本書に書いてある方法が素朴で手を出しやすそうなものだったので虚をつかれた感があった。
