サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
新内閣発足
songmu.jp
ポッドキャスト「趣味でOSSをやっている者だ」 を1年くらい続けてきたので、今のマイク環境について書いてみようと思う。あまり大げさな機材を使わず、リーズナブルでコンパクトな構成を志向している。なので、普通の人のリモート会議用にも使える構成だと思うので、参考にしてもらえると嬉しい。 現在のマイク周りは以下のようになっている。これはデスクの左側の壁の様子で、この右側にPCやモニターがある。 マイク - JBL QUQNTUM STREAM マイクは JBL QUANTUM STREAM。USB接続できるコンデンサマイクで、本体は缶コーヒーを一回り大きくしたくらいにコンパクト。ゲーム配信者なども使っているモデルで信頼度も高く、実際音質も悪くない。あとは、サイドトーン機能という、マイクにモニターヘッドフォンを挿して自分の音声を聞きながら収録できる機能も備えている。これが1万円程度で買えるのは破格。
GitHubのImmutable Releasesがパブリックプレビューとなりました。ソフトウェアを公開している方は積極的にオンにすると良いでしょう。suzuki-shunsukeさんが早速zennを書かれているので、詳しい解説はそちらに譲ります。 Releases now support immutability in public preview - GitHub Changelog GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう ここでは、Go製のソフトウェアで実行ファイルもリリースされている方の中には、tagprと goreleaserを組み合わせて使っている方がそれなりにいると思うので、その場合の設定についてお知らせします。 Draftリリースを作り、それを再利用する これだけです。具体的には以下です。 .tagpr に re
https://github.com/Songmu/chapel ターミナル上でMP3のチャプターやメタデータを編集したくなり、コマンドラインツールを作った。名前の chapelは"chapter editor"を適当にもじった。動作は以下を見て欲しい。 使い方は簡単で以下のように chapel コマンドの引数にMP3ファイルを指定するだけ。 # install % brew install Songmu/tap/chapel # edit metadata in your.mp3 % chapel your.mp3 エディタが開き、YAML化されたメタデータが表示される。それを適宜編集して保存・終了すれば、その内容がMP3に書き込まれる。 アートワーク(artwork:)にローカルファイルパスやURLでも指定でき、その内容をMP3に埋め込んでくれる。その他標準的なメタデータにも対応してい
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対応などもされなさそうなので新たに開
フリーランスになって、複数の案件を同時に進める必要が出てきたこともあり、タスク管理方法を見直した。何なら手法やツールも自作してしまおうと考えた。何かを始めるときに、まず道具から作り始めてしまうのは自分らしい振る舞いで面白い。 これをTaskMD Shelfと名付け、仕様を公開した。 https://github.com/Songmu/TaskMD-Shelf これは、1 タスク = 1 Markdownファイルとして管理する手法。各ファイルはTaskMDと呼び、それに最小限のメタデータ設計と運用ポリシーを定めたもの。単純なアイデアで、類似の方法でやっている人も既にいるだろう。 既にこれでタスク管理をしていて上手く回っている。ObsidianのDataviewプラグインがとにかく役に立っているのだが、その辺りの話は別途。 怠惰な自分でも続けられる手法 個人的に、強すぎる制約があるタスク管理手
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://crates.io/crates/r2sync コマンドラインツールであり以下でインストールできる。 $ brew install Songmu/tap/r2sync # or $ cargo install r2sync これはローカルディレクトリの中身をCloudflare R2に簡易的に同期するごく単純なツールで以下のように使う。 $ r2sync ./dir r2://your-bucket/path リモートに同一ファイルが存在する場合にputをスキップするようになっていて、それが欲しくて作った。ちなみに、--public-domain というオプションを付けると、同一ファイルチェックを公開URL経由で行うようになってAPIアクセスを減らせる。 $ r2sync --public-domain files.example.com ./dir r2://your-b
サイト: 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.
https://github.com/Songmu/podbard 結果としてできたものはyattecastとHugoの間の子のようなモノになった。音声ファイルとそれに対応するエピソードファイルをfrontmatter付きのMarkdownで記述する。最終的に静的サイトとしてポッドキャストサイトを生成する。 podbard-starterというテンプレートリポジトリがあるので、ここからリポジトリを作ればすぐにポッドキャストサイトを作成できる。このテンプレートはGitHub Pagesにデプロイするモノだが、Cloudflare Pagesにデプロイする、podbard-cloudflare-starterや、それを応用してプライベートプッドキャストを構築する、podbard-private-podcast-starterというのも用意している。 まだ不十分だがドキュメントも以下に用意してあ
前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。 ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。 コード内に認証情報を載せない 複数ユーザーのIDとパスワードを管理できるようにする パスワードは定数時間比較してタイミング攻撃を防ぐ これらを以下のように解決することとした。 認証情報は環境変数
所属している、ヘンリー社には、社内ラジオコンテンツがあり、Notion上に音声ファイルを置く形で実現されている。これを、ポッドキャスト化してポッドキャストクライアントで聞きたいというのが動機。ちゃんとしたオープンな規格としてのポッドキャストにしたい。 もちろん、公開はせずプライベートなものにしたい。ただ、ポッドキャストはオープンコンテンツ前提の規格になっているため完全な実現は難しい。認証のかかっていないRSSフィード及び、そのRSSフィードに埋め込まれたMP3等の音声ファイルにも認証がかかっていないことが前提となるからだ。 やるからには、あまりコストを掛けずに静的配信をベースにしたい。お手軽なプライベートポッドキャストサービスもあまりないようだ。 基本方針 それに対する現実的な妥当解を考え、その実現のために、まずポッドキャストサイトを生成するpodbardというOSSを作った。そして、それ
MacでオンラインMTG中に電球を点ける仕組みを構築した pic.twitter.com/qhpXTbv4cY — songmu (@songmu) August 15, 2024 夏休みに入って、子供たちが仕事部屋に乱入してくることが増えた。何番煎じかわからないが、オンラインミーティングが始まったら電気を点ける仕組みを作って投入した。カメラがついている時にミーティング中だという判定をしてライトを点灯する。概要は以下。 カメラ(及びマイク)のon/offを検知する OverSight を使う 検知をトリガーにプログラムを実行 mtglight というのを作った プログラムからIoTライトを操作する Yeelight の製品を使った 一応多重実行を防ぐ排他制御をしこむ setlock を使う 私以外にこの仕組みを使う人がいるとは思わないが、以下の手順で導入できる。 Yeelightを調達して
関連: NFCタグ入りの自己紹介アイコンバッジを自作する song.mu という結構良い短いドメインを確保しているので、これをプロフィールサイト兼、個人用短縮URLサービスにしたいと長らく思っていたので重い腰を上げて作った。 最近オフラインイベントが増えている中で、こういうプロフィールサイトを活用しているケースを見るようになったのがきっかけ。Webエンジニアとしてはこういうの自作したいし、自分のドメインでホストしたいと思っていたのだ。 song.mu がリンクが並んだプロフィールページで、 song.mu/blog でブログに飛び、 song.mu/x でTwitterに飛ぶ、みたいな具合。 技術スタック こういうの作る時は興味がある技術の砂場にしたいので、HonoでSSGしてCloudflare Pagesでホストしている。ローカル開発でのTypeScript実行環境も mise で管理
大吉祥寺.pmの前夜祭「生存者バイアスナイト」で話してきた。 https://junkyard.song.mu/slides/survivor-bias-night/#0 同年代の優秀なエンジニアの方から「自分のキャリアは再現性が無いから他人の参考にならない」という話をよく聞く。果たしてそうだろうか。私はそういう人たちにもっと自分の経験の話をしてもらいたいと常々思っていた。 彼らは「思い込みの結果として上手く行った」「単に運が良かった」「だから普遍的なノウハウにならない」そんなふうに自覚している。だから、そんな普遍的ではないノウハウを偉そうに声高に話したがらないし、ましてや、それを押し付けるような老害的振る舞いになることを恐れているようにも見える。そういう謙虚なスタンスは好ましくも思う。 でも実際は一つ一つの経験には大きな意味がある。普遍的ではないかも知れないが、それでも話してみると、自分
自己紹介グッズを作っていた pic.twitter.com/cFffmWsMYm — songmu (@songmu) July 9, 2024 このバッジにスマホをかざすと、song.mu という自己紹介サイトに飛べるようにした。バッジにはNFCタグが仕込まれている。最近よくあるやつ。 缶バッジだとNFCタグが読み込めない罠 最近は自己紹介グッズとして、pixivFACTORY でアイコン缶バッジを作るのが、lacolaco手法として知られている。私も持っています。 参考: 自分のアイコンの缶バッジを作ると便利 しかし、缶バッジは金属製なのでNFCタグをくっつけても読めません。なので、こういう素人手作り感満載のグッズを作ることにしたのでした。ちなみに、pixivFACTORYはアクリルキーホルダーも作れるのでそれを活用しても良さそうです。 NFCタグシール やったことは簡単で、以下のNF
ロードバイクを新たに一台買った。久しぶりに外でのサイクリングを楽しんでいる。 新車でヤビツサイクリングしてきた。半原越も行きたかったけど、入り口が以前と変わっていて入りそびれてしまった pic.twitter.com/YrjzuzKKtp — songmu (@songmu) April 28, 2024 新車はCannondaleのSuperSix Evo 3べースにホイールをMavicのKSYRIUM SLにアップグレードした。KSYRIUM大好き。 町田のたかだフレンドに10年以上ぶりに顔を出して組んでもらった。ORBEAのORCAが欲しかったのだが、扱いがなかったので勧められたこのバイクにした。信頼できるショップに組んでもらうことが大事。Cannondaleも僕がロードレース見ていた頃のSaecoチームの印象もあるし、このバイクも今どきのバイクにしてはそこまでゴツすぎないのも良かっ
当サイトをFediverseに対応させました。 @songmu.jp@songmu.jp でMastodonなどでリモートフォローできます。 やったことは、 このブログがFediverseに対応しました というtyageさんのエントリーをそのままなぞっただけです。このエントリーはh-cardのサイトトップへの掲出に関する説明が書き漏れていそうでしたが、それも実施しました。 当サイトは静的サイトであり、付随機能は外部サービスに頼りたいと考えている。例えば、コメント機能はDisqusを使っている。Fediverseに関しても何かそういうサービスがないかと思っていたが、Bridge Fedというサービスがあり、上記のエントリー内で懇切丁寧に解説されていたので導入は比較的簡単で、作業時間は小一時間でできた。大まかな手順は以下。 Bridgy Fed というサービスを利用してサイトをFedivers
このエントリーはバズレシピ Advent Calendar 2023、11日目の記事です。 日本人皆が大好き肉じゃが。メジャーな料理なので、多くのYouTuberがレシピを公開してくれている。ここでは私がよく見ている料理系YouTuberの中から以下の動画を参考にして、最高に美味い肉じゃがの作り方を考察してみたい。 リュウジのバズレシピ | 至高の無水肉じゃが クラシル | 野永喜三夫が教える究極の肉じゃが シズルチャンネル | 最高の肉じゃが まかないチャレンジ | 肉じゃがの極意 くまの限界食堂 | 肉じゃが321 コウケンテツ公式チャンネル | 王道肉じゃが 豚肉か牛肉か、男爵かメークインか まず主役の肉とジャガ。意外と肉は牛肉派が多かった。リュウジさんだけ豚肉。さすがは庶民の味方ですね。まかないチャレンジは分量が多いので、半量くらいにすれば他のレシピと大体目方が揃いそう。 肉 芋
ヘンリーでVP of Engineeringを務めるSongmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023 、11日目の記事です。 はてなブログとblogsync はてなブログにはAtomPub APIという、はてなブログをAPIで操作できる機能があります。これは実は結構古くからある機能で、2013年にリリースされています。当時のはてなインターン生によるもので、moznionさん、krrrrさんが担当されたようです。歴史を感じますね。 そのAtomPub APIを利用し、はてなブログを管理するためのCLIツールとして、当時はてな社のチーフエンジニアで現CTOのmotemenさんが「個人で」開発したGo製のOSSがblogsyncです。これは2014年にリリースされています。社員が自社サービスのユーザーであり、社員が趣味の個人開発でそのサービス利用のため
数年前から業務上では同僚に通りの良いあだ名がない場合、極力「さん」付で呼ぶように意識している。新卒やインターンの大学生を無条件で君付けで呼ぶみたいなのをやめたいと思ったのだ。 呼称から暗黙の権威勾配が生まれることは少なくない。例えば、上司が部下を君付けで呼び、部下が上司をさん付けで呼ぶという光景はよく見られる。上下関係が前提にあり、逆転させると違和感を感じるはずだ。こういう暗黙の権威勾配は双方の心理に染み付いてしまい、構造を変えるのが難しくなる。 逆に、我々のIT業界では、新卒やインターン生が数年後に自分の上司になることも珍しくない。流動性が高くて素晴らしいことである。その時に呼び方を「君」から「さん」に変えるのもおかしな話である。そもそも上下関係によって呼び方が変わるのはナンセンスだと私は思っていて、仕事の上ではお互い一人前の大人でリスペクトしあいたいし、個人的にフラットさを志向している
もうだいぶ前になってしまいましたが、3月に京都でYAPC::Kyotoに参加してきました。 YAPC::Kyotoは運営の皆さま、本当にお疲れ様でした。コロナ渦で運営の継続には色々苦労があったかと思います。そんな中、世間的にコロナ明けの雰囲気になってきている中、ちょうど先陣を切るような形でオフラインイベントが開催できて、大きな盛り上がりを見せたのは、皆様の苦労が報われたようにも思いました。旧交も温められたし、それだけではなく、学生支援制度などのお陰で、若い人も参加していて交流が盛り上がってよかったです。 思えば、2019年のYAPC::Tokyoのときに僕がベストトーク賞を受賞した勢いで、懇親会の最後にで胴上げされた後に、無責任に「次は京都でやるぞ!」と、勝手に宣言したのが実現した形でした。JPAにも禄に関わっていないのに(当時は一応末席で参加することもあった)。とはいえ、懇親会で @__
次のページ
このページを最初にブックマークしてみませんか？
『おそらくはそれさえも平凡な日々』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く