NFCタグ入りの自己紹介アイコンバッジを自作する | おそらくはそれさえも平凡な日々
自己紹介グッズを作っていた pic.twitter.com/cFffmWsMYm — songmu (@songmu) July 9, 2024 このバッジにスマホをかざすと、song.mu という自己紹介サイトに飛べるようにした。バッジにはNFCタグが仕込まれている。最近よくあるやつ。 缶バッジだとNFCタグが読み込めない罠 最近は自己紹介グッズとして、pixivFACTORY でアイコン缶バッジを作るのが、lacolaco手法として知られている。私も持っています。 参考: 自分のアイコンの缶バッジを作ると便利 しかし、缶バッジは金属製なのでNFCタグをくっつけても読めません。なので、こういう素人手作り感満載のグッズを作ることにしたのでした。ちなみに、pixivFACTORYはアクリルキーホルダーも作れるのでそれを活用しても良さそうです。 NFCタグシール やったことは簡単で、以下のNF
退職 | おそらくはそれさえも平凡な日々
12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき本当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい
リリース用のpull requestを自動作成し、マージされたら自動でタグを打つtagpr | おそらくはそれさえも平凡な日々
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
GitHub Actionsのmatrixを動的に生成してGoの最新安定バージョンでテストする | おそらくはそれさえも平凡な日々
Goのライブラリを提供している場合、Goの最新の安定バージョンでテストしたくなることがあるでしょう。具体的にはマイナーバージョンの直近2バージョン、今だと1.18と1.17です。GitHub Actions定義への記述は以下のようになるでしょう。 jobs: test: runs-on: ubuntu-latest strategy: matrix: go-version: ['1.17', '1.18'] steps: - uses: actions/setup-go@v3 with: go-version: ${{ matrix.go-version }} - run: go test ./... しかしこのようにベタに書いてしまうと、Goのバージョンが上がったときにチマチマ上げるのが地味にめんどくさい。なのでこれを動的に生成したい。 これは事前にGoの安定バージョン一覧を取得するjo
Montereyと(After)Shokzの相性問題とその解決方法 | おそらくはそれさえも平凡な日々
macOSをMontereyにあげてからShokzの骨伝導ヘッドフォンが不調になる、具体的にはミーティング中に突然ミュートになるという問題がある。ボヤキや暫定解決方法含めてTwitter上に書き散らしていたが、困っている人が相変わらずいるようなのでまとめておく。と言っても、以下のredditに書かれている内容そのままです。 https://www.reddit.com/r/Zoom/comments/qhmpkg/aftershokz_aeropex_on_zoom_and_macos_monterey/ 自動音量調整が効いている場合それが悪さをする サウンド環境設定を開いて観察するとよく分かる マイク音量がどんどん下がっていってミュートされてしまう 音量自動調整を無効にすれば暫定解決 会議ツールの設定でそれができればOK (zoom等) 設定できない場合もChromeであれば以下の拡張を
Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で
マンション購入記(勢いで購入を決めるまで) | おそらくはそれさえも平凡な日々
家を買うつもりはあまりなかったが、ライフステージの変更に伴い買った、という良くある話です。2016年までの昔話です。 一応今の住所はあまり積極的にはネット上では公開していません。ただ、分かる人にはどのあたりか分かってしまいそうなので、その場合はそっとしてもらえると嬉しいです。 二子新地時代の購入未遂事件 結婚当初は僕は持ち家志向は強くなく、妻の方が比較的強かった。ただ、当時住んでいた二子新地が非常に気に入っていたこともあり、一度、近くの不動産屋に行ったことがあった。2011年頃の話。 確か二子玉の再開発絡みで周辺にマンションや建売住宅が建ちはじめていて、その中で当時の近所に建設中の分譲住宅が悪くない金額で売りに出されていたことがあった。それをふらっと内見させてもらい、それが良かったため、興奮した妻に連れられて不動産屋にまでも行くことになった。 「あーこれは買わされる流れかもな」と思っていた
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
GoのテストをCIで簡単に並列実行する | おそらくはそれさえも平凡な日々
https://github.com/Songmu/gotesplit gotesplitというかなり便利なツールを書いた。Goのテストをいい感じのサブセットに分割して、それを実行するものです。このアプローチで、社内のテストを15分から3分くらいまでに短縮しました。 これを使えばCI環境での高速なテストの並列実行を簡単に実現できます。 実例 CircleCIやGitHub Actions上で簡単に導入できます。 CircleCIの場合 parallelism: 5 docker: - image: golang:1.15.3 steps: - checkout - run: command: | curl -sfL raw.githubusercontent.com/Songmu/gotesplit/main/install.sh | sh -s bin/gotesplit ./... -
Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
ghq v1リリースとghq-handbookのお知らせ | おそらくはそれさえも平凡な日々
https://github.com/motemen/ghq/releases/tag/v1.0.0 年末にアナウンスしていた通り、先程ghq v1.0.0をリリースしました。変更点は以下のエントリでお知らせしていたとおりです。その他Subversion周りの対応を無駄に頑張って強化したりしました。 https://songmu.jp/riji/entry/2019-12-28-ghq.html 是非ご利用ください。 年末年始休暇中にドキュメントを書いていたのですが、思ったよりもしっかりとした分量になったので、思い立って電子書籍にして販売してみることにしました。 https://leanpub.com/ghq-handbook 日本語で20ページほどです。値段は$1.99くらいにしたかったのですが、Leanpubで収益を上げる場合には$4.99が下限のようなので、その額に設定させてもらいま
GitHub Actionsを使ってGoプロジェクトのCI/CD及びカバレッジ計測をおこなう | おそらくはそれさえも平凡な日々
GitHub Actionsを遅まきながら使ってみて、自分のアクティブなGitHub上のGoのOSSプロジェクトで知見がたまったので、共有するものである。 GitHub Actionsについて 非常に良い。VCSとCI/CDの統合は体験が良い。各種イベントをハンドリングできるが、そのイベントが元々Webhookで提供されていたものなので、Webhookを弄っていた身からすると非常に親しみやすかった。コードpush以外のイベントもハンドリングしてプログラマブルに扱えるので夢が広がる。 使い勝手とか具体的に良くなった点 リポジトリ直下の.github/workflows配下に既定のYAMLをpushすると、その設定にしたがって自動でアクションが動いてくれる。ブラウザ操作必要ないのは快適。 GitHub上でいろいろ完結できる Windowsのテストもできる! GITHUB_TOKEN 管理もうま
GitHubのprivate repositoryを含んだ場合のGo Modules管理 | おそらくはそれさえも平凡な日々
tl;dr CI/CD環境から複数のGitHubのprivate repositoryにアクセスさせたい場合にはmachine account(machine user)を使うと良い SSH KeyでもAPI tokenでもどちらでも良いけどSSH方式がGo公式repoでも紹介されている CircleCIだとSSH Keyの設定(User Key)が簡単でその他の設定がほとんど不要 本題 Goに限った話ではありませんが、プロジェクトで使っているprivate repositoryからまた別のprivate repositoryを参照している場合、CI/CDなどの外部環境からどのようにそれらにアクセスさせるか困ることがあります。 例えば、git submoduleを使っている場合や、Goの場合ですとGo Modulesで指定しているパッケージがprivate repositoryである場合な
お知らせ | おそらくはそれさえも平凡な日々
日頃お世話になっている皆様へのお知らせです。なるべく多くの方に直接お伝えしたかったのですが、この場でのお伝えになってしまった方には申し訳ありません。 はてなを退職します。4/17(水)が最終出社でした。所属は5/31(金)までです。 ずっとはてなで働きたいと思っていましたし、この絶好のタイミングで辞めてしまうのは勿体無いという気持ちもあります。ただ、次の挑戦に関して時間的な制約もあったため退職させてもらうことになりました。この詳細はまた別途お知らせできればと思っています。 2014年に現在のはてな東京オフィスの一人目のエンジニアとして入社し、その後、チーフエンジニアと、Mackerelのプロダクトオーナー(マネージャー)を兼務してきました。 チーフエンジニアとして組織に、Mackerelではプロダクトとビジネスに関わりました。入社当時、私一人だけだった東京オフィスのエンジニアも今では二桁に
オライリーの「入門 監視」の付録Cを執筆しました | おそらくはそれさえも平凡な日々
入門 監視 ―モダンなモニタリングのためのデザインパターン この本はPractical Monitoringの邦訳です。原著は持っており、良い本だと思っていたので、翻訳者の松浦さんが邦訳されている話を聞いたときには嬉しく思いましたし、そこで付録を執筆して欲しいという依頼もいただき、身に余る話でしたが、引き受けさせてもらいました。 そして「実践 監視SaaS」と言う内容を付録Cとして20ページほど書かせていただきました。原著が監視SaaSの活用を推奨してはいるのですが、内容的にはツールに偏らない、概念的で中立的な本であるため、監視SaaS活用に関してはもう少し具体的、実践的な話を補強して欲しいというオーダーを受け、書いたものです。 私は、Mackerel という監視SaaSのプロダクトマネージャーを務めており、それもあって依頼を頂いた形ですが、逆に、原著の中立的な良さを損なわないように公平さ
JSONを使ってコマンドラインを動的に組み立てて実行するjfillを作った | おそらくはそれさえも平凡な日々
https://github.com/Songmu/jfill 標準入力からJSONを受け取り、その値を使ってコマンドラインを組み立てて実行するユーティリティです。以下のような具合です。 インストール % go get github.com/Songmu/jfill/cmd/jfill もしくはGitHub Releasesからご利用ください。 使い方 % echo '{"name":"jfill"}' | jfill echo Hello {{name}}! Hello jfill! {{name}} の部分がプレースホルダーです。それがJSONの入力を元に置換され実行されています。 プレースホルダー内には以下のようにデフォルト値を指定することも可能です。 % echo '{}' | jfill echo Hello {{name:jfill}}! Hello jfill! {{name
GoでSingletonぽいことを実現する、とある方法 | おそらくはそれさえも平凡な日々
ちなみに今回のコードはそれほど実用性はありません。ここまで頑張って、シングルトンぽいことを実現する必要性は感じられないからです。サンプルコードはこちら。 https://www.github.com/Songmu/go-sandbox/ Goでシングルトンを実現する方法として以下の様なコードが良く見られます。 package singleton import "sync" type singleton struct{ } var ( instance *singleton once sync.Once ) func GetInstance() *singleton{ once.Do(func() { instance = &singleton{} }) return instance } このコードのグッドポイントとしては、 sync.Once を使っていること。以下のように素朴に nil
何のためにバージョンロックをするか | おそらくはそれさえも平凡な日々
外部ライブラリに依存する時に、どのようにバージョンロックをすべきかどうかという話。僕個人のスタンスです。 開発しているのがライブラリであれば依存ライブラリをバージョンロックをするべきではない 最低バージョンの指定に留めるべき(これは寧ろ積極的にやって良い) 依存ツリーが大変なことになってコンフリクトが避けられないため 実運用しているサービスやアプリケーション的なソフトウェアであればバージョンロックした方がいい これは「ある時点のビルドやリリースの再現性」のためが一番大きいと思っている 古いバージョンにとどまって良いというわけではない 基本的には、開発しているものがライブラリであれアプリケーションであれ、 とにかく依存先の最新についていく のが前提で、その前提に立った場合に、上のような考え方になるかな、と思っている。 特にライブラリ作者は依存ライブラリに非互換変更が入って動かなくなったら、頑
`ghg` で GitHub Releasesから適切な実行ファイルを統一的に取得する | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghg tl;dr % ghg get motemen/ghq とかやれば、GitHub Releasesに上がった最新の実行ファイルを取得できる。 % $(ghg bin)/ghq とかで実行可能。 $(ghg bin) を $PATH に追加してもよい。 % ghg get Songmu/ghch@v0.0.1 とかでバージョン指定も可能。 本文 Goで書いたツールを提供する場合、クロスビルドしたものを GitHub Releasesに上げるのが定番となっています。 なぜ、 go get ではないのかというと go get の場合以下のような問題があるからです。 go get するにはGoの環境が必要 安定版ではなく、開発中の最新をビルドしてしまう ビルド情報などをバイナリに埋め込めない ただし、GitHub Releasesに上げる
Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々
同僚がGoを始める上で、案外まとまった資料が無さそうだったので書いてみることにしました。 Macでhomebrewが入っていることが前提です。事前に brew update をおこない formula を最新のものにしておくと躓くことが少ないでしょう。 Goのインストール % brew install go エントリ執筆時点では、1.6.2 が入ります。Goはメジャーバージョンが同じ場合は、後方互換が保たれているので、基本的に新しいやつを入れて問題ありません。 環境変数の設定 $GOPATH だけを決めればOKです。$GOPATH はどこでも良いのですが、ここでは $HOME/dev を $GOPATH に設定します。また、 $GOPATH/bin に $PATH も通しておきます。 export GOPATH=$HOME/dev export PATH=$GOPATH/bin:$PATH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
