はてなブックマーク

データベースを伴うテストを書いていて、何故かテスト結果が安定しない事象に出くわして「なんでだ？？？？？」と混乱した結果、データベースの状況を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 Container Registoryにpushしたコンテナイメージをリポジトリに紐づけてPackages欄に出す方法がやっとわかった— k1LoW (@k1LoW) 2021年3月5日 GitHub Container Registoryは、GitHub Package Registryとは異なりPublicなDockerイメージのpullにGitHub認証の必要がないなど、利用者にとって便利です。 また、リポジトリとの紐付けが強制されていないので自由に様々なイメージを管理できます。 イメージはProfileページのPackagesタブにリストアップされます。 ただ、私の主な用途としてはリポジトリで公開しているライブラリのDockerイメージの提供なのでリポジトリと紐付けたい。 具体的にはリポジトリの Packages の欄に表示させたい。 どう紐づければいいのかわからなか

Goでフォントを扱うことって（おそらく、たぶん、きっと）ほとんどないと思うのですが、私はなぜか文字が入っているpngファイルの生成とかER図とかを出すようなOSSを開発していることから、フォント周りのGoパッケージを作る機会がありました。 どれもパッケージというには小さいコード片で紹介することもないだろうと思っていたのですが、せっかくなので紹介したいと思います*1。 fontdir github.com フォントを指定するためには大抵フォントファイルのパスを指定しなければいけません。 fontdirは各環境でフォントファイルが格納されているディレクトリを取得できるだけのパッケージです。 これはパッケージを作ったと言うより https://github.com/flopp/go-findfont のフォントディレクトリ取得関数がprivateだったのでその関数だけポーティングしました。 ff

久しぶりに使うAWSのprofileがありまして、そのprofileについての記憶が失われていた結果、コマンド実行成功までに時間を溶かしてしまいました。 というのも、私は普段使うprofileではaswrapでAssumeRole（と多要素認証）を透過的に便利に実行していた結果、IAMの認証設定については何も考えなくなっていて「とりあえず aswrap 」を実行していました。 そして、 $ AWS_PROFILE=myaws aswrap aws s3 ls An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied 「あれ？認証情報無効にしたっけな 🤔」とか、トンチンカンな推測をしていました。 よくよく確認してみたらそのprofileは「MFAは必須だがAssumeRole

あれ、もしかしてNO_TABLE_OPTIONSってMySQLから消えてる…？ tbls でどうすればいいんだ…。— hamaco (@hamaco) 2020年6月11日 上記のツイートで知りました。 NO_TABLE_OPTIONSが削除されたVerのリリースノートは以下です。 docs.oracle.com NO_TABLE_OPTIONSとは SHOW CREATE TABLE の出力で MySQL 固有のテーブルオプション (ENGINE など) を出力しません。このモードはポータビリティモードで mysqldump によって使用されます。 ( MySQL 5.6 リファレンスより ) SHOW CREATE TABLE はテーブル定義をDDLで出力するコマンドです。例えば SHOW CREATE TABLE により以下のようなDDLが出力されたとします。 CREATE TABL

ghput pr-comment ghput issue-comment のデフォルトの挙動について注意点を追記しました 最近はGitHubやGH:Eといったサービスのリポジトリと、そのリポジトリと連携するCI/CD環境がある前提で、様々なパイプラインを作ることが普通になってきています。 git push や Pull Request をトリガーにCI/CD環境で実行されるのもテストの実行だけではなく、master mergeのタイミングでのプロダクションデプロイやプロビジョニング、その前段階としてPull Requestタイミングでのdry-runやplanの実行など。 GitHubは便利ですし、それと連携するCI/CD環境があるとその2つだけで様々なものの自動化ができて便利です*1。 そんなGitHub+CI/CDな環境で使えるであろう ghput というツールを作りました。 gith

Cacooで「データベーススキーマを自動生成できる」という素晴らしい機能が先週発表されました。 cacoo.com Cacooが提供するSQLクエリをデータベースで実行して、その結果をCSVファイルとしてエクスポートしてCacooにアップロードするだけでER図が生成されるというものです。 現時点で公式サポートされているのはMySQLとPostgreSQLですが、 一応1列目にRDBMSの名前が入るようになってるんですが、CSVのフォーマットとしては統一されてます。— Kohei Kimura (@cohhei) 2020年4月16日 ということなので、tbls out のサポートフォーマットにCacooのデータベーススキーマ機能用のCSV（ cacoo ）を追加しました。tbls v1.33.0で試すことができます。 MySQLのデータベーススキーマ まずはMySQLのデータベースで試して

ここ最近tblsのアップデートエントリを書いていなかったのですが、最近変更をいくつか行いました。 このまま放置するとちょっと紹介しきれなくなりそうなので、ここら辺で放出しておこうと思います。 紹介時点のtblsのバージョンはv1.29.0です。 PostgreSQLでの public. スキーマ表示仕様変更 tblsでは、もともとPostgreSQLの public. スキーマ（ schema_name.table_name.column_name の schema_name ）だけ特別に非表示にしていました。 こうなっていた理由は、私がPostgreSQLでのスキーマを意識した運用経験がなかったことに寄る部分が大きいです。「デフォルトだから非表示で良いだろう」と。 ところで、tblsにはlintの機能があります。「テーブルカラムにコメントが書かれているか？」とか「外部キーの参照元にIND

結論は最後に書いてあります。 PTFという社内勉強会で、私が端々が間違っていたりするちょっと微妙な紹介をしてしまったので、改めてエントリに記載しておこうと思います。 PTFについては以下をご覧ください。 tech.pepabo.com The Go Playgroundでいつの間にかサードパーティパッケージをimportできるようになっていた。 私が気づかなかっただけで結構前からそうだったみたいです。 https://play.golang.org/p/w0uRS17zhjR 上記URLのコードでは github.com/goccy/go-yaml を importしているのがわかると思います。 go.mod でパッケージバージョンを指定できるようになっていた さらに、go.modでパッケージバージョンを指定できるようになっていました。 https://play.golang.org/p/

2014年のアイデアを実装している— k1LoW (@k1LoW) 2020年1月18日 2週に1度くらいFukuoka Growth Nextのコワーキングスペースを使わせてもらっています*1。 その時ちょっとだけ席を立ちたいときに、展開しているMacBookやバックパックを「置いておくか」「持っていくか」いつも悩みます。 バックパックはワイヤーを持ち歩いているので机に縛ってしまえばいいのですが、MacBookはそうもいかないので少しだけ安心できるような仕組みが欲しいなと思っていました。プライベートのMacBookとはいえ、盗まれたら家計に大打撃です*2。 日本ですしコワーキングスペースという出入りが限定されているエリアなのでそこまで気にする必要はないんですが。 「そういえば昔そんなこと考えていたなー」と思ったら、アイデアをエントリに残していました。 k1low.hatenablog.c

明けていました 2019年の振り返り 嵐のように過ぎ去った1年でした。 と言っても残念ながら私が何かを成し遂げたわけではなく、子供の成長についていくのと仕事面でも周りの変化/進化についていくのに精一杯だった受動的な1年だったような気がします。 その結果、おそらく1年前の私ならブログエントリやツイートに残していたであろう数々のイベントがスルーされています。イベント消化で精一杯。 2019年の目標は「変化に適応することを楽しむ」でした。 確実に変化を楽しめてはいたと思うのですが、その変化が予想以上でした。 24時間3-4時間おきにミルクを飲ませておけば瞬殺で寝ていた子が、保育園に行き、離乳食を食べ、喋りだし、歩きだし、踊り、生えた歯で噛みつき、おもちゃをぶん投げるところまできました*1 。 最近知ったのですが、これから「夜泣き」というものがはじまるらしいですね。もうそういう深夜インシデントは落

この記事はMackerelアドベントカレンダー23日目の記事です。 22日はshiimaxxさんのMackerelで負荷テスト中のリソースモニタリングを行うでした！ そして今日はMackerel Day #2ですね！ Mackerel 5周年おめでとうございます！ 🎉🎉🎉🎉🎉 Mackerel pluginを書いたことがない 実は私、Mackerelアンバサダーになっていたのでした（公ではじめて言った）*1。 ただ、まだMackerel pluginを書いたことがない のでした。 そして今回 id:a-know さんにたまたまツイートを拾ってもらいアドベントカレンダーにお誘いを受けたので、「とても良い機会！」ということで書いてみました。 こちらとか、ぜひっ！https://t.co/ZCTEhLt0PB— a-know (@a_know) 2019年12月1日 Mackerel

"トライアルアンドエラーパイプ"ことfiltに、tail -F /path/to/access.log なストリームだけでなく cat /path/to/access.log な標準出力に対しても何度でもコマンドをパイプで繋げて試行錯誤できる機能を追加しました。 k1low.hatenablog.com 今回新たに追加された機能もあわせて、使い方を紹介します。 使い方 filt v0.5.0の時点で使い方は2種類あります。 ストリームデータ（従来の使い方） 連続してデータが流れ続けてくるような標準出力には、パイプで filt を繋げます。 $ tail -F /path/to/access.log | filt このときのユースケースとしては、 「今リアルタイムに流れているデータに対して 何度でもコマンドを試行錯誤したい」 というものになると思います。 filtの標準入力にはそのまま途切れ

RDBMSのレプリケーションなど、なんとか調べてギリギリ理解して組んで、その後新規レプリケーションを組むか障害が発生したとき、また一から調べている気がするので、動く環境として記録していくことにしました。 github.com これはなに 今のところ、PostgreSQLの ストリーミングレプリケーションの構築->フェイルオーバー->再レプリケーション までをひと通りMakefileにまとめたものです。 2019年10月時点では、非同期と同期のストリーミングレプリケーションを1種類づつ作っています。 コードでまとめることで良かったこと 何度も試せる まず何度も試せるのが良いです。設定変更の検証などもすぐです。 私は今回試行錯誤した結果、2桁はレプリケーションを組んだので、レプリケーションがあまり怖くなくなりました。 設定に多くのパターンがあることがわかった 実際に手を動かすと頭に入ってくると

Harvest のログ取得期間指定をより柔軟にできるように --duration オプションを追加したかったのですが、 標準の time.ParseDuration() ではあまり柔軟ではない 既存パッケージを探したけれども time.Duration を返すものを見つけられなかった ので作りました。 github.com 使い方 duration.Parse() は time.ParseDuration() と同じように利用できます。 time.ParseDuration() と異なる点は 4hours や 1minute などの単位表記も判定できるという点です。 package main import ( "fmt" "github.com/k1LoW/duration" ) func main() { d, _ := duration.Parse("3 days 4 hours")

Consulでちょっとしたヘルスチェックを追加したいと思ったのですが、例えば iowaitが高いかつuserは低いとき という条件を書こうとしたときに、「うっ。。！どう書けばいいんだ。。」となってしまったので、作りました。 github.com これはなに metr は次のような利用を想定したコマンドです シェルスクリプトにホストやプロセスのメトリクスの値を使った条件を組み込む Nagios pluginとして利用する Mackerel check pluginにチェックコマンドとして利用する 使い方 インストールはHomebrew以外にdeb/rpmパッケージを用意しています。基本的にサーバにコマンドとしてインストールするのが良いでしょう $ dpkg -i metr_0.5.1-1_amd64.deb metr list 取得できるメトリクスは metr list で確認できます。また

Go Conference ‘19 Summer in Fukuokaでも少し紹介したcolrです。 github.com これはなに まずは以下のスクリーンキャストをご覧ください colr は tail -F /path/to/access.log のようなログにカジュアルに色をつけるツールです。 $ tail -F /var/log/nginx/access.log | colr POST GET 404 500 search のように何個でもカラーにしたい文字列を指定できます。 これだけです 色の指定もできませんし、その他のオプションもありません。 colr の後に引数としてカラーにしたい文字列を並べるだけです。 実は正規表現っぽい文字列を渡すと正規表現マッチに変更してくれますが、それでも使い方は変わりません。 これだけの機能、ただその分、何も考えずに利用できます。 是非ご利用くださ