はてなブックマーク

AI Agentも賢くなってきたとはいえ、ローカルで何をしでかすかわからない怖さは拭いきれない。かと言って、細かく認可を与えるのもめんどいし、ザルな見過ごしも起こりやすくなって危ないので、できればファイル・ネットワークアクセス、コマンド実行等に適切に制限をかけたサンドボックス環境で放し飼いにしたい。 CLIとして動かすAI Agentの場合、引数に指定したコマンドをサンドボックス内で動かすコマンドラッパーがあると嬉しい。自作しようかと思っていたが fence というツールがまさしくそれだったので、これを使うことにした。Goで書かれていて、macOSとLinuxをサポートしている。早速、GitHub Copilot CLIでも利用しやすいようにpull requestを送って、取り込んでもらった。 https://github.com/Use-Tusk/fence https://fence

Markdownの中に 「@copilot 〇〇について調べて」みたいなプロンプトを書けば、コーディングエージェントが自動でそれを認識して非同期で動作してくれると嬉しい。なので、そういうツールを作った。それが ghsummon。その名の通り、手元からAI Agentを召喚するツールで、GitHub Actions上で動かす。 https://github.com/Songmu/ghsummon @copilotで始まる行がGitHub上にpushされると、pull requestが自動で作成される。該当行をプロンプトとして認識し、GitHub Actions上でCopilot coding agentが動き、pull request上でファイルを編集してくれるという仕組みだ。 動作イメージのpull requestがこちら。"Who is @Songmu" というプロンプトに対して、Git

CLIをAI AgentフレンドリーにするためにAgent Skillsがあると嬉しい。Agent Skillsは絶賛リポジトリで協議されているが、オープンスタンダードであり、各ベンダーがそれなりに足並みをそろえながら仕様がアップデートされている。フロントマッター付きのSKILL.md というMarkdownを .agents/skills/skill-name/SKILL.md のような場所に配置することで、Agentにskillを備えさせられる。配置場所も各ベンダー独自の場所もあったが、最近は主要ベンダーが .agents/skills もサポートし、その点では安定した。 OSS作者もリポジトリルートに skills/ ディレクトリを掘り、その中にAgent Skillsを置く人も増えてきた。そうしておけば、skills add などのインストーラーでスキルを導入しやすくなる。 そこで

開示ブームに乗り遅れたが、去年末から今年頭にかけてアップデートがあったので記録しておく。ものぐさなので、割と古いままだったりデフォルト厨寄りだったりするのだが、AIコーディングの流れもあり、多少は新しめのものも導入した。 OS: Mac 長く惰性で使っている。バックアップや他のスマートフォンやタブレットとの連携や、ファミリーアカウントなどの兼ね合いもあって、お金はかかるがAppleプラットフォームにどっぷりになっている。 dotfiles管理: 自前リポジトリ管理 https://github.com/Songmu/dotfiles 去年末に業務Macの設定する時に、リポジトリcloneしてリポジトリ内のsymlinkを適当に張るスクリプトを動かしたら大体動いたので、それで満足して良いかとなっている。 chezmoiへの乗せ変えを検討したが、dotfileはPC設定の初期にやることなのでそ

しばらくフリーランスとしてフラフラしていましたが、縁とタイミングが合って、12/16付でGitHub Japanにシニアソリューションエンジニアとして入社しました。開発職ではなく技術営業職で、担当は主にエンプラ領域の予定です。 GitHubが好き 「SongmuさんてGitHub好きですよね」 Mackerelのプロダクトマネージャーをやっていた頃、一緒に事業を手がけていたビジネスマネージャーのnkakoさんにそう言われたことを覚えています。これは「そういうふうに見えているのか」という気付きを与えてくれました。GitHubはもちろん嫌いではありませんでしたが日常的に使うサービスなので、好き嫌いはそこまで意識してはいませんでした。 ただ、MackerelのPdM時代はかなりGitHubを意識していた事は確かです。個人の道具としても仕事でも使えることや使いたくなるサービスであることを目指してい

この記事はPerl Advent Calendar 2025の9日目の記事です。 さて、Cで書かれたMarkdown実装の１つであるDiscountのPerlバインディングである、Text::Markdown::Discountを sekimura さんから去年末に引き継ぎ、今年の頭からメンテナンスしていました。 ありがたいことに大本のDiscountが継続開発されていることもあって、Text::Markdown::DiscountはPerlで利用可能な最も実用的なMarkdownライブラリの１つです。このブログでも使っている拙作のブログエンジンであるRiji内部でも使っており、私にとっても欠かせないライブラリです。 かねてから、Discount本体側のバージョンが上がるタイミングなどでsekimuraさんには度々pull requestを送っていましたが、これはメンテナンスを引き取らせて

ポッドキャストを始めるにあたり、まず配信サイトをどうするかという話があり、その辺りについての個人的見解や調査結果をまとめてみる。ポッドキャスト配信に興味がある人の参考になれば幸いです。 ポッドキャストの捉えられ方も多様になってきていますが、ここでは、特定のアプリやサイト内で独占的にしか音声を聴けないものではなく、配信者が様々なメディアに登録できて利用者が無料で利用できるオープンな形式のものを指すこととします。そちらの方が広くリーチしたい場合には効果的でしょう。 メイン配信プラットフォーム選定 大本の配信元をどこにするか。これは、以下の分類になる。ただ、何れのパターンを選ぶにせよ、Spotifyへの登録はお勧めする。(後述) Spotifyが無難。特に企業でやるなら シェアが大きい 担当者も前提知識少なく始められる 分析機能も見やすい 個人でやるならLISTENもオススメ コミュニティ要素が

今年のYAPCは、前日入りして全日程堪能し、会期翌日の日曜日もホテルに留まり、月曜日に帰る満喫プランで楽しんだ。 2日開催の充実の内容となりましたが、今回も素晴らしいカンファレンスでした。関係の皆様は本当にお疲れさまでした。ありがとうございました。2日開催なので、トーク本数も充実していながら、質疑応答の時間やトーク間の休憩時間もゆったりと取られていて良かった。 話してきた トークを採択していただいたので、k1LoW/deckへの貢献に関する話をしてきた。今年後半はdeckの開発に熱狂していたので、その総括的な内容。 k1LoW/deckを急激に(100倍以上)高速化する方法 by @Songmu OSS開発への貢献をどのように始めたか、どのように機能追加やパフォーマンスチューニングをしたか、一般的なパフォーマンスチューニングの心得という構成で、いつもの私のYAPCトークらしく盛りだくさんと

GitHubのImmutable Releasesがパブリックプレビューとなりました。ソフトウェアを公開している方は積極的にオンにすると良いでしょう。suzuki-shunsukeさんが早速zennを書かれているので、詳しい解説はそちらに譲ります。 Releases now support immutability in public preview - GitHub Changelog GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう ここでは、Go製のソフトウェアで実行ファイルもリリースされている方の中には、tagprと goreleaserを組み合わせて使っている方がそれなりにいると思うので、その場合の設定についてお知らせします。 Draftリリースを作り、それを再利用する これだけです。具体的には以下です。 .tagpr に re

9/8(月) 追記: ツール名を Chapel から Chape に変更しました https://github.com/Songmu/chape ターミナル上でMP3のチャプターやメタデータを編集したくなり、コマンドラインツールを作った。名前の chapeは"chapter editor"を適当にもじった。動作は以下を見て欲しい。 使い方は簡単で以下のように chape コマンドの引数にMP3ファイルを指定するだけ。 # install % brew install Songmu/tap/chape # edit metadata in your.mp3 % chape your.mp3 エディタが開き、YAML化されたメタデータが表示される。それを適宜編集して保存・終了すれば、その内容がMP3に書き込まれる。 アートワーク(artwork:)にローカルファイルパスやURLでも指定でき、そ

7月頭に技術支援先でプレゼンをする機会があり、いつもの僕の雑なHTMLプレゼンではなくて、ちゃんとしたプレゼンフォーマットにしたいと考えて、 k1LoW/deck を使い始めた。MarkdownをソースとしてGoogleスライドを生成できるツールだ。 GitHub - k1LoW/deck: deck is a tool for creating deck using Markdown and Google Slides. 良かった点 これまで15年以上主にMarkdownからプレゼンテーションを作るスタイルでやってきたので、乗り換えやすかった。 私的MarkdownとGoogle Slidesでスライドを作成する方法（またはdeckの紹介) - Copy/Cut/Paste/Hatena 使い始めた6月時点で、上記の紹介エントリーからさらに進化を遂げており。感動的に体験が良かった。特に以

https://github.com/Songmu/laminate 文字列から画像を生成するコマンドラインツールがいくつか存在する。例えば以下のようなものだ。 silicon: コード文字列からシンタックスハイライトされた画像を生成する qrencode: URL等からQRコードを生成する mmdc (mermaid-cli): Mermaid画像を生成する プロンプト文字列から生成AIに画像を生成させる laminate はそれらを一元管理する。laminate コマンドを実行すれば、設定ファイル上の適切なコマンドに処理が渡され、画像が出力される。例えば以下のように使う。 % cat main.go | laminate -lang go > main.go.png k1LoW/deck との連携 最近、k1LoW/deckというMarkdownからGoogleスライドを作成するツール

この話は、goccy/go-yaml 作者のgoccyさんと、YAMLの話を…止めない!という私のポッドキャストエピソードでも話した内容だが、口頭では説明が難しかったり、上手くまとまってなかった部分もあったので、補足的にエントリーを書いた。ポッドキャストでは裏話的な話やgoccyさんの生の意見も聞けるので、そちらも是非聞いてみて欲しい。 GoのYAMLライブラリとそのアーカイブ事件 GoのメジャーなYAMLライブラリには大きく以下の2つがある。 gopkg.in/yaml.v3 (gopkg.in/yaml) 7k stars github.com/go-yaml/yaml が開発リポジトリ github.com/goccy/go-yaml (goccy/go-yaml) 1.7k stars 他にもYAMLライブラリはいくつかあるが、実態は、gopkg.in/yaml のラッパーであるこ

Songmu/action-create-branch READMEにも書いてあるが以下のように使う。これは、指定ブランチがあれば作るし、無かったら何もしない簡単なGitHub Actionだ。分岐元指定のrefにはブランチ名、タグ、コミットハッシュを指定できる。refは省略可能でデフォルトではgithub.refを使う。 - uses: Songmu/action-create-branch@v0 with: branch: feature/new-feature ref: main 何故作ったか 先のエントリーの、action-push-to-another-repositoryのフォーク元には、元々、create-target-branch-if-needed という、指定ブランチがなかったら作るオプションがあった。しかし、私がフォークしたものからはそれを削除した。コードの複雑性が増

あるリポジトリの一部または全部を別リポジトリのルートなりサブディレクトリにpushしたくなることがたまにある。一般的にもニーズがありそうだが、ちゃんとメンテナンスされているモノが見当たらなかったので、以下に公開した。かなり便利。 https://github.com/Songmu/action-push-to-another-repository https://github.com/marketplace/actions/songmu-action-push-to-another-repository これはイチから作ったわけではなく、cpina/github-action-push-to-another-repository をforkしたものです。このfork元は、私も使っていたのですが、メンテナンス停止が宣言されており、signed commit対応などもされなさそうなので新たに開

2025年4月より、所属していた株式会社ヘンリーは非常勤となり、フェローという肩書きを拝命しました。フェローとしては技術広報や採用広報の支援を中心に活動します。 ヘンリー理想駆動ラジオ というポッドキャストを始めたのもその一環で、今後書き起こしなども出していく予定です。 背景としては、プライベートの状況や色々もあってフルタイムで働くのは辞めようと考え、そういう状況でVPoEの責務を果たすのが難しくなったというのがあります。元々は退職予定でしたが、パートタイムで在籍を残させてもらうことになりました。 独立 元々個人事業主ではありましたが、フリーランスとしても正式に(?)独立となります。しばらくあまり稼働時間は増やさず、自分がやりたいことにもう少しフォーカスしたいとは思っています。 やりたいこととしては、今、本を書いているのですが、そういう文筆業だったり、OSSやBlog、ポッドキャストを含め

この記事は pyspa Advent Calendar 2024 の14日目の記事です。この記事で言いたいことを先にまとめると以下になります。 日本の技術系アドベントカレンダー文化は独自の進化を遂げている エンジニアに限らない広がりも見せている 良い文化だし長く続いて欲しいと思う 元の文化への敬意を忘れてはいけない 宗教色があるものだし、少なくともアドベント期間外に拡張しない方が良いと私は思う 長くこの文化を楽しむためにも 技術系以外のトピックでもアドベントカレンダーが作られることがありますが、この記事では便宜上それらも含めて技術系アドベントカレンダーと呼称します。 技術系アドベントカレンダー 日本の主に技術系のインターネット界隈では毎年12月になると、技術系アドベントカレンダーというムーブメントが発生します。ある技術トピックに対して、12月1日から25日まで複数人が持ち回りでブログを書く

最近、Webエンジニア界隈で、共通項を感じる印象的な出来事があった。具体的には以下の2件。 ゆーすけべーがHonoを作ったこと Hono - ゆーすけべー日記 おぎじゅんさんが職業プログラマーに戻ってきた(きていた)こと 転職してソフトウェアエンジニアをやっている 猫廼舎を閉店しました 共通項はそれぞれ長めのブランクがありながら、ソフトウェアエンジニアリングの世界に戻ってきて一線級以上の活躍をしているということだ。二人とも僕と同世代かそれ以上の年齢でもある。これは勇気と希望をもらえることだ。 もちろん彼らの能力の高さゆえに第一線に戻ってこられたのかもしれない。ただ、どちらにせよ、別のことに興味があれば、職業エンジニアを離れて、フォーカスする期間があっても良いと言うことだ。能力不足ならなおさら中途半端になるよりフォーカスしたほうが良いとも言える。 それに多分戻ってこられる。ゆーすけべーの様に

当ブログのRSSを全件配信するようにした。Perl製OSSの拙作ブログエンジンであるところのRiji側に手を入れた。ファイルサイズが大きくなるし、RSS分割を実装するのもめんどいので単純に直近30件配信にとどめていたが、今日日普通に1ファイルで全件配信して良いだろうと思い変更した。時代の流れで富豪的アプローチが許容される(?)よくある話。 ちなみに、全件配信しようと思ったきっかけは、ポッドキャスト「趣味でOSSをやっている者だ」を始めるにあたって、RebuildのRSSを観察したところ、全件配信しているのに気付いたので、じゃあいいか、となったというのがありました。 その昔の以下のnaoyaさんの19年前の記事で、RSS内に単独エントリの全文配信の是非について書かれているが、今や全件全文配信である。 RSSの全文配信をはじめました Riji v1.1.1をリリースした https://git

サイト: https://oss4.fun X: https://x.com/oss4fun ハッシュタグ: #oss4fun GitHub: https://github.com/Songmu/oss4.fun 最近御存知の通り(?)ポッドキャストづいていて、ポッドキャストについて色々調べてサイト構築ツールなどを作っていたが、ツールを作ったらやはり使いたくなってポッドキャストを始めてみることにした。 以前アナウンスした拙作のポッドキャスト生成OSSのPodbardの実例を示す場にもしたかったので、運営リポジトリも公開している。是非参考にしてみてください。一応、同期しているprivateリポジトリもあって、そのあたりの仕組みは別途解説するかも。 更新頻度はあまり考えてないけど、月に数本、できれば毎週、30分程度のエピソードを出したいと思っている。第2回目までは録り終わっていて今週公開予定。

Podbardはpodbard.yamlに設定を記述するが、これをエディタで補完したりヒントを出せたりするようにした。 yaml-language-serverとJSON Schema 普段vimで開発してて、GitHub ActionsのYAMLを触ってるときなどに、エディタが適切にヒントを出してくれるのを便利に感じつつ「多分LSPがうまいことやってくれてるんだろうな」くらいに考えて深く追いかけていなかった。これは、JSON Schemaで実現されていることを、今回podbard.yamlの仕様をJSON Schemaで記述している過程で発見した。 GitHub ActionsのJSON Schemaは https://json.schemastore.org/github-action.jsonやhttps://json.schemastore.org/github-workflow.

前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。 ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。 コード内に認証情報を載せない 複数ユーザーのIDとパスワードを管理できるようにする パスワードは定数時間比較してタイミング攻撃を防ぐ これらを以下のように解決することとした。 認証情報は環境変数