サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
k1low.hatenablog.com
エラーパッケージを作った話です。 www.m3tech.blog 私は、上記のエントリの「ぼくがかんがえるエラー処理の要件」に完全同意*1で、パフォーマンスをある程度犠牲にしてでもスタックトレースを「カジュアルに」受け取りたいと考えています。 また、 tech.kanmu.co.jp にもあるように「移行のしやすさ」も欲しいです。 というのも、 methane.hatenablog.jp にあるように、将来的にGoの標準パッケージにスタックトレースを取得できる機能が登場する可能性があるからです。標準パッケージ最高。 で、 speakerdeck.com に「独自に実装するのもおすすめ」とあったので、既存のエラーパッケージを参考に独自に実装してみました。 github.com/k1LoW/errors github.com 特徴としては次のとおりです。 import "errors" を i
「user そーだい」で検索することN回目— k1LoW (@k1LoW) 2024年4月15日 soudai.hatenablog.com gihyo.jp scrapbox.io scrapbox.io よく参照するならまとめておけばいいじゃない。 ラインナップからフェーズ的なものについては察してください。 ガッチガチに「こうあるべき」というような話というよりも、モデリングやテーブル設計においての固定観念*1を崩すためのキッカケに使っていることが多い気がします。 ちなみに私は、十数年、散々失敗した挙句にこのような有益なURLを有益だと理解して参照したりしているわけで、最初から(もしくは短期間に)ここに行き着ける人ってすごいなと尊敬しています。 追記 そーだいさんから有益情報を教えてもらったので並べておきます。 @k1LoW ここ最近のソフトウェアデザインの僕の連載見てほしいです。めちゃ
先日、機会をいただきましてCI/CD Test Night #7でAPIテスティングツール*1を開発している中で考えていることをお話しさせていただきました。 testnight.connpass.com 詳細はスライドをご覧ください。 speakerdeck.com APIテストはスモールテストと比べて効果は大きいがコストも大きい 私はAPIテストの一番の課題はこれだと思っています。 APIテストは、「APIに対してリクエストを投げてそのままテストする」というわかりやすさがあります。 また、テストあたりにおけるカバレッジの広さというメリットもあります。 なので、できればデメリットであるコストの大きさをなんとかしたいわけです。 この課題の解決には2つの方法があります。 コストを小さくする 範囲を広げて効果を大きくする 先に、範囲を広げる方法について考えると 作ったテストをそのまま負荷テストに
今年も参加してきました。 phperkaigi.jp 聴講した発表へのフィードバックも終わり、このエントリで私のPHPerKaigi 2024はフィニッシュです。 #runn開発者会議 最近恒例の廊下での会議ですが、テストランナーのシンタックスの改善の方向性についてどうしてもしめじさん( @smeghead さん)から直接フィードバックをもらいたく、3日間「いつか会えるだろう」とフラフラしていました。 気にかけていただいた皆さんありがとうございました。無事邂逅できました! runnのランブックの一級言語がYAML(?)なのでYAMLシンタックスをうまく使ってかつニーズを満たす構文が思いつけばいいのですが、もう一歩アイデアが降ってこない。。。というところまででした。しめじさんにも言われたのですが「一度作ってしまうとなかなか変えられない」ものなのでどうにか降りてきてほしいっ!!! あとはカンフ
このエントリは GMOペパボエンジニア Advent Calendar 2023 および、 Go Advent Calendar 2023 シリーズ3 の19 日目の記事です。 以下のエントリでも少し触れられていますが、現在プロキシサーバをGoで書くプロジェクトがあります。 ten-snapon.com k1low.hatenablog.com 主な実装をしているのは @pyama86 さんで、それはもうブルドーザーのように実装が進んでいるわけですが*1、私も少しだけですが書いています。 必要そうな機能をGoの薄いHTTPミドルウェアハンドラとしてOSSとしていくつか切り出していました。 そして、本体の実装が進むにつれて足りない機能を Pull Request ベースでもらったりしていたのですが、関連OSSを作る必要が発生したりなど個人リポジトリだとまとまらないため、それらをまとめるためだ
このエントリは Go Advent Calendar 2023 12 日目の記事です。 Goのテスティングパッケージで一番好きなパッケージは net/http/httptest です。 テスト実行時に実際にHTTPサーバを立ててHTTPリクエストを受けるというシンプルかつ強力なアプローチが良いです。 クライアント側にエンドポイントを変える仕組みさえあればクライアントのリクエストを受け付ける形でテストを構築することができるので、選択肢に入れておきたいテスト構成です。 ところで、私たちは runn (ランエヌ)というシナリオテスティングツールを開発しています。 github.com runnはHTTPクライアントでありgRPCクライアントでもあるのですが*1、そのrunn自体のテストのためにhttpstubとgrpcstubを作って使用しています。 httpstub github.com ht
京都に行ってきました。 Go Conference mini 2023 Winter IN KYOTO kyotogo.connpass.com すでに、ne-sachirouさんによりスライド資料などが集められています。感謝! scrapbox.io 「miniとは?」となるGoで濃縮された1日になりました。運営の皆様、本当にありがとうございました! 私はと言うと、登壇はしたものの完全にカンファレンスを楽しんでいました。 本編 以下、一言感想です。 Deep dive into log/slog package 既に使ってはいましたが、実装は特にみていませんでした。普通に使えるイメージ。 「nAttrInline = 5」の理由がなるほどなあという理由でした。これ再度計測してレポートしたら変わってくるような値なんですかねー。 Goプログラムがビルドされるまで(コンパイラーの仕組みを探る)
現在、実験的にですが少しパフォーマンスを気にしたいパッケージを書いています。 ちなみに、その1つはリバースプロキシです。 github.com 「気にしたいパフォーマンス」というのは以下の2つです。 現在のGoの実装がNGINX(のリバースプロキシ機能)と比べてリクエストあたりの処理時間が小さいか 現在の実装が以前の実装(Pull Requestであればmainブランチ)と比べてリクエストあたりの処理時間が極端に大きくなっていないか GitHubにリポジトリがあるのでCI環境としてはGitHub Actionsがあります。 そこで、上記2点をGitHub Actions上で継続的に計測したいと考えました。 まず、1つ目の「NGINXとの比較」ですが、これはただNGINXを使ったベンチマークと自分の実装を使ったベンチマークをそれぞれ実行することにしました。 NGINXを使ったベンチマークの結
octocov octocovはコードカバレッジのためのツールキットです。 github.com コードカバレッジなどのコードメトリクスを手元のターミナルで確認したり、GitHub ActionsのActionとしてPull Requestにレポートしたりできます。 計測したコードメトリクスを、さまざまなデータストアに蓄積することもできます。 octocovはコードカバレッジ、Code to Test ratio、テスト実行時間の3つのコードメトリクスを計測しますが、今回、任意のメトリクスに対応しました。 カスタムメトリクス カスタムメトリクスの使用方法は簡単です。 計測したメトリクスを指定のフォーマットで保存する(カスタムメトリクスJSON) octocovに環境変数経由でカスタムメトリクスJSONの保存パスを渡す これだけです。 1. 計測したメトリクスを指定のフォーマットで保存する(
元エントリは↓で、これが全てです。 dev.to 最高じゃんhttps://t.co/c1hfSYhgx2— k1LoW (@k1LoW) 2023年8月26日 Goでツールではなくライブラリ(パッケージ)を作っているとき、テストにしか使わないパッケージがgo.modに入って依存関係ができてしまうのが、いつも気になっていました。 ただ、「まあ別にいいかな」と思っていたのですが、ちょうど標準パッケージだけで機能が実現できるパッケージができたので、どうしてもgo.modを綺麗にしたくなりました。 そして、えいっと調べてみたらすぐに解決方法が見つかったのでした。 テストでしか使わないパッケージをgo.modに含めない方法 方法は次の通りです*1。 テスト用に go_test.mod ファイルを用意して -modfile オプションを使って go_test.mod ファイルを指定して go tes
やっとgh auth loginで得たクレデンシャル(OSのセキュアストレージに保存されているもの)のみを使う生活になったぞ— k1LoW (@k1LoW) 2023年5月15日 GitHub CLIの gh auth login で作成されたクレデンシャルはOSのセキュアストレージに保存されるようになりました。 次のエントリが詳しいです。 blog.kyanny.me 「じゃあ、もう全部セキュアストレージに保存されたクレデンシャルを使えばOK」となるのですが、なかなかそうはいきません。 なぜかというとGitHubのクレデンシャルを使うツールによって環境変数の扱いが異なるからです。 GitHubのクレデンシャル設定の歴史(私の記憶版) 注意: 以下は、あくまで私の記憶であって実際と異なるかもしれません。 前史 GitHub CLI( gh )やGitHub Actionsの登場以前は、クレ
提供する機能とは関係なくリリースを定期的に実施するようなプロダクトや、バージョンにSemantic Versioning(以下SemVer)のような意味付けがしにくいプロダクトの場合、バージョン管理手法にCalendar Versioning(以下、CalVer)というものが採用されることがあります。 calver.org 例えば、CalVerのサイトに掲載されているケーススタディで私が知っていたものとしてはUbuntuのバージョニング( YY.0M.MICRO )があります。 22.04 とか 22.10 とかのアレです。 そしてちょうど私がバージョニングしたいプロダクトも 1ヶ月に1度定期的にリリースしたい しかし、なにかしらの要因で1ヶ月に1度以上リリースすることがある というものでSemVerではない気がするし、とは言え単純に 年月 でバージョニングすると同月リリースがあるとバージ
3月23日から25日までPHPerKaigi 2023に参加してきました。 phperkaigi.jp 参加してみての感想は、一言で表すと かつて思い描いていたカンファレンスと、想像以上を提供してくれるカンファレンスの融合を体験できて楽しかったし嬉しかった です。 想像以上の体験を提供してくれるカンファレンス これはPHPerKaigiのことです。 カンファレンス運営に対して狂気ともいえる情熱を注ぎ続ける主催者と、それを強固にバックアップするスタッフの方々が存在することにより実現される体験。まだ今年で4回しか参加していませんが、常にアップデートされています。アップデートの方向も想像がつかないです。毎回毎回楽しい(毎回同じでも楽しいのに!)。 あらゆる場所にエンターテイメントがあり、おもてなしがあり、当日以前にもカンファレンス開催前のビッグなノベルティボックスや、事前登壇の自動録画機能など驚
タイトルが何を言っているのかよくわからないと思いますので順を追って紹介したいと思います。 tblsをセットアップするGitHub Actionとしてsetup-tbls を作った setup-tblsはtblsをインストールしてくれるGitHub Actionです。 github.com 各所で「ないの?」とは言われており(最近Issueもたった)、いつか作らないとなと思っていたのですが、いろいろ重なって作りました。 github.com 私はGoで作ったツールのActionはDocker container actionを使うのですが、tblsでそうするとDockerコンテナ上で動くtblsからデータベースサーバの名前解決ができなかったりして、それも手を鈍らせている原因でした。 今回作成した setup-tbls はComposite actionで作っているので上記のような心配もありま
久しぶりのtblsの新機能紹介エントリです。 ドキュメントのER図出力にMermaidを指定できるようになりました ER図の出力フォーマットにMermaidを指定できるようになりました。次のように er.format: セクションか --er-format オプションに mermaid を指定することで変更できます。 er: format: mermaid 開発裏話 GitHubがMermaid対応したことで「tblsもMermaid対応してほしい」という要望や提案は以前より多く受け取っていました。 しかし、個人的にあまりメリットを見出せずそのままPull Request待ちとなっていたのですが、今回エイッと作ってみました。 Mermaid対応をするにあたって1つとても面倒な仕様がありました。それはMermaidはER図の多重度(カーディナリティ)の指定が必須となっていることでした。 もと
この記事はMackerel Advent Calendar 2022の5日目の記事です。3年ぶりのMackerel Advent Calendarへの参加です。 4日目は id:buty4649 さんで、サーバの温度を監視するmackerel-plugin-thermalを作った - ぶていのログでぶログでした。自宅サーバ、私にはまだ未知の領域です。自宅にサーバがあるということは自宅がDCになるわけで、温度管理も必要ということか...。 octocovとは github.com octocovはOSSのコードメトリクス計測ツールです。 コードメトリクス(コードカバレッジやCode To Test Ratio、テスト実行時間など)を計測するだけでなく、取得したメトリクスをPull Requestへのレポートしたり、サポートしている任意のデータストアにメトリクスを送信したりすることができます。
これがtagprで実現したかったこと 統制されていながらも自由なリリースの自動化 エイッと踏み込んでくださった @katzchum さんに感謝 https://t.co/OEXq6i5xXC— k1LoW (@k1LoW) 2022年10月1日 私の趣味は少し実用的で小さなOSSを書くことです。 今までも多くの小さなOSSを書いてきました。そして、エコシステム的にリリースすべきものはリリースしてきました。 ここで言うリリースと言うのはバージョンをつけてパッケージとしてPublishすることです。 PHPであればpackagist.orgに、Rubyであればrubygems.orgに、JavaScriptであればnpmjs.comにPublishするまでのことを指します。 Goであれば、バージョンのタグをつけてGitHubのリポジトリにプッシュすればリリース完了です。必要であればアセットをG
TL;DR GitHub "のみで" 構築するコードメトリクス計測基盤 バッジ生成機能 CIで計測したコードメトリクスのバッジを生成したとして、そのバッジを誰が配布するのか CI上で生成したバッジをそのままリポジトリのコミットしてしまう Central modeを使う GitHub Actions Artifacts GitHub のみで コードメトリクスバッジ基盤を構築する方法 まとめ TL;DR 長いので要約すると octocovは計測したコードメトリクスをGitHub Actions Artifactsに保存すると、単体リポジトリでメトリクスの比較レポートなどもしてくれて便利 さらに octocovs-template を使って、各リポジトリのArtifactsに保存されているメトリクスを収集する専用リポジトリを作るとバッジも生成・配布できて便利 となります。 「GitHub」という
octocovは私が開発しているコードメトリクス計測のためのツールキットです。 主となる用途であるCI(GitHub Actions)に組み込む使い方は会社のテックブログで紹介させてもらいましたのでそちらをご覧ください。 tech.pepabo.com 私自身もドックフーディングをしていて、自分の主だったリポジトリはすでに octocov に移行済みです。 Fix handling for bind runner by k1LoW · Pull Request #47 · k1LoW/runn · GitHub 実は octocov にはもうひとつ便利な使い方があるので、そちらを紹介したいと思います。 コードカバレッジを確認する octocov は実は単体のCLIツールとしても使うことができます。.octocov.yml といった設定ファイルも一切必要ありません。ただ、インストールするだけ
椅子と机が最終形態となりました。 もう、壊れない限りは「他のものが欲しい」とならないと思います。 Mirra 2 Chairs 椅子です。 www.hermanmiller.com 2020年にリモートワークが増えることになったことをきっかけに購入しました。 会社ではとても良い椅子を提供してもらっていたので、それがなくなると身体的に大変なことになるかも?と思っていろいろ調べていた記憶があります。 当時、各所で椅子購入ブームだったので、得られる情報も多くとても迷いました。 決め手はハーマンミラーというブランドへの信頼と、調節要素の多さでした。 というのも椅子は奥さんと共有して使用する予定だったので*1、それぞれの体型や姿勢にあった調整ができたほうが良いだろうと考えました。 さらに、コロナ禍で店舗もあまり空いておらず、椅子ブームで在庫もなく、結局「座って確認」ができませんでした。そう言った意味
データベースを伴うテストを書いていて、何故かテスト結果が安定しない事象に出くわして「なんでだ?????」と混乱した結果、データベースの状況をprintデバッグをしたくなって作りました*1。 github.com 使い方は package main import ( "database/sql" "log" "github.com/k1LoW/qp" _ "github.com/mattn/go-sqlite3" ) func main() { db, err := sql.Open("sqlite3", "path/to/db") if err != nil { log.Fatal(err) } defer db.Close() qp.Print(db, "SELECT * FROM users WHERE username = 'alice'") } みたいにqp.Print() に *
1年以上前からの久しぶりのアップデートです。 k1low.hatenablog.com --role-arn --source-profile 複数のAWSアカウントを横断して作業することがあり、AssumeRoleのための設定を~/.aws/(config|credentials)に書くのすら面倒になってきたので、設定なしでAssumeRoleができるようにするためのオプション --role-arn と --source-profile を追加しました。 委任元のアカウントAのロール arn:aws:iam::AAAAAAAAAAAAAA:role/example-role を委任先のアカウントBに委任できるようにしている場合、 委任先のアカウントBの設定が ~/.aws/(config|credentials) にある場合は( profile-b )、 $ awsdo --role-a
既存の開発に参加するときや、0->1の開発をしているとき、いつも「せめてリポジトリの各ディレクトリの概要説明だけでも欲しい」と思っていました。 既存のプロジェクトに参加するときは「プロジェクトの理解をする側」、0->1のプロジェクトで開発をしているときは「説明をする側の立場」で、です。 Ruby on Railsのような基本のディレクトリレイアウト決まっていてもそのプロジェクトの独自性がでてきますし、Goのようにスタンダードなレイアウトがないのであればなおさら初見ではわかりません。 「じゃあREADME.mdにでも書いておけばいい」というのはその通りです。 ただ、概要説明であっても一度書いたら終わりではなく、更新は必要になります。特に0->1のプロジェクトの初期ではディレクトリレイアウトすら途中で変わるということはままあります。 (ここらへんは「継続的ドキュメンテーション」として私の興味の
1つのディレクトリに雑に放り込んでいた電子書籍をPDFとEPUB横断でCLIからタイトル検索して開けるようになった。 オライリーとかファイル名から中身を類推できなくて困っていたのでこれで「あの書籍どのファイルだっけ?」がはかどる。 pic.twitter.com/0wVSj4UoYh— k1LoW (@k1LoW) 2021年11月21日 私は買った電子書籍を1つのディレクトリに保存しているのですが、ファイル名はダウンロードしたときのそのままにしていることが多いので、良く「あの書籍はどのファイルだっけ?」が発生していました。 電子書籍リーダーで管理すればいいとは思うのですが、それを整備することすらしていない有様です。 とりあえず「あの書籍はどのファイルだっけ?」や「あの書籍って買ってたっけ?」をなんとか解消したいと思っていました。 PDFファイルやEPUBファイルの電子書籍のタイトルだけで
毎回、go-githubのclientをGITHUB_*やらGH_*やらを判定して組み立てたり、外部パッケージのgo-githubのバージョンに合わせたりするのが面倒になって、カッとなって作ったhttps://t.co/8zhsP3V8cv サブディレクトリの使い方がひどい(go-githubのバージョンに合わせて切っている)がもうこれでいい— k1LoW (@k1LoW) 2021年11月6日 GitHubやGitHub Actionsが好きで、いろいろツールを作ったりするのですが、毎回毎回go-githubのClientのインスタンス生成のために何行かコードを書いています。 最初の頃は GITHUB_TOKEN のことだけを考えていていたのが、その後GitHub Enterpriseのエンドポイントも考えるようになり、GitHub Actionsの登場からはActions上の環境変数を
git grep 便利ですよね。 私は git grep と git gsub は本当によく使います。 ところで git grep はローカルリポジトリがないと実行できません。 ローカルにリポジトリがなければ git clone して、 git grep すればいいのですが、もう少し簡単にgrepするために gh-grep を作りました。 github.com gh-grep gh-grepはGitHub APIを使ってGitHub上のリポジトリに対してgrepをするツールです。 特徴は、全てGitHub APIを通じて実行するためローカルに git clone することなくgrepできることです。 また、APIを使っている特徴を活用して複数リポジトリに対してgrepすることなども可能になっています。 あと実行が遅いです。ひたすらGitHub APIを叩いているので...*1。 インストー
注意: 本エントリで紹介するツールは現時点でPoCな実装であり、効果や効率を保証するものではありません。 ちょっと前に社内でGitHub Actionsのサプライチェーン攻撃についての話題があがって、「なるほどー。今時は、リポジトリのコードだけの脆弱性や第三者コードの混入とかだけを気にしていても足りない時があるのか」いう感想でした。 いろいろな軽減策が提案されているので*1基本的にそれらを実践するが良いとする上で、「GitHub Actionsのサプライチェーンをたどって脆弱性スキャンとか危険なコード混入をチェックできたら意味あったりするかなあ」とふと思って、その「GitHub Actionsのサプライチェーンをたどる」というところに興味がでてきたのでツールとして作ってみました。 github.com oshka oshka*2の振る舞いは以下の通りです。 指定したディレクトリ( fs )
wsa.connpass.com オンライン開催に参加してきました。 予稿 github.com 発表資料 システムの変化に追従可能でかつ理解し易いドキュメントシステム 発表内容はドキュメントシステム(ドキュメンテーションツール)についてです。 私は、システムを理解するためにかかる時間(いわゆる「オンボーディングまでのコスト」。私は「開発開始までのオーバーヘッド」と呼んでいます)をいかに継続的に削減できるかに興味をもっています。 それはなぜかというと「私がシステムの理解のセンスがないからそれをなんとか技術で解決したい」という個人的欲求に他ならないのですが、「まあオンボーディングのコストが小さくなればそれはエンジニア全員にも良いことだろうな」と勝手に思い込んでいろいろ作ったりしています。 実は今回の発表にいたるまでには過程があって、July Tech Festa 2021 winter では
GitHub Actions便利ですよね。 ペパボではGitHub Enterprise Server(以下、GHES)が運用されており、GHESでもGitHub Actionsが利用できます。 uses: だけで利用できるリポジトリを横断で再利用可能なActionの存在はかなり生産性を上げていると思います。 そういった便利なワークフローを複数のリポジトリに対して適用していきたいことが時々あります。 一気に複数のリポジトリに同じワークフローを適用したいこともあれば、「あ、このリポジトリにはあのリポジトリのワークフローをいれたほうがいいな」となることもあります。 その時、それぞれのリポジトリに対して「突然のデフォルトブランチへのpush」はあまりにも乱暴なのでPull Requestを作成していくことになります。 ただ、適用したいレポジトリが2桁あったとき、Pull Requestを作成する
次のページ
このページを最初にブックマークしてみませんか?
『Copy/Cut/Paste/Hatena』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く