雌伏の時 | おそらくはそれさえも平凡な日々
カッコつけたタイトルを付けてしまった。中二っぽい。 強がりと言うか、自分に言い聞かせている部分もあるのだと思う。 有り体に言うと、新しい環境にまだ苦しんでいて、上手く動けていない。こんなことを書くと同僚に心配されてしまいそうだが、同僚には現状を伝えていて、その上で信頼してくれているとも感じている。会社に不満があるわけではなくて満足している。 少し精神的に参っていたので、今週前半は少し休ませてもらった。これは休んだほうが良いな、と思ってyoshioriさんに相談したところ、こちらから休みについては何も言わずとも「休んだほうが良いよ」と言ってくれた。話が早くてありがたかった。 現状意識していることや感じていることについて書き留めておく。 成果を完璧に出せてはいないが淡々とやる 現状、社内では成果目標を定めて、達成度を振り返るというのを毎月やっているが、1月に関しては100%をつけることができた
VPSを解約してFirebase Hostingにブログを移した | おそらくはそれさえも平凡な日々
タイトルの通り。なんとなく自分のサイトを自分で運用したいと思っている。それはWebエンジニアとしてのポートフォリオ的な側面もあるし、それに加えて、自分の書いた文章を自分の管理下におきたい欲求があるのだと思う。 サブブログを、はてなブログに持っていますが(https://blog.song.mu)、これもまた、コンテンツはblogsync を使って管理しています。 このサイトはもともとVPS上のNginxから静的配信されており、 VPS上のgit bareリポジトリに直接push post-receive Hook で riji を呼び出してサイト再構築 という結構カッコいいフローを組んでいて 、これがなかなか気に入っていた。以下のような点が良かった。 国内のVPSへのgitリポジトリへのpushはかなり早い GitHubへのpushに少し引っかかりを感じるレベル とはいえコンマ数秒程度の違
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
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 ./... -
ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々
追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい
Goでテスト中に現在時刻を差し替えたりするflextimeというのを作った | おそらくはそれさえも平凡な日々
https://github.com/Songmu/flextime flextimeはテストコードの中で現在時刻を切り替えるためのライブラリです。Sleep時に実際に時間を止めずに時間が経過したように見せかける機能もあります。 つまり、PerlのTest::MockTimeやRubyのtimecop的なことをしたいわけですが、Goだとグローバルに関数の挙動を切り替えるといったことはできないため、利用にあたってはtimeパッケージで使っている関数を、flextimeパッケージに切り替える必要があります。 具体的には、flextimeはtimeパッケージと同様のインターフェースを備える以下の9つの関数を提供しています。 now := flextime.Now() flextime.Sleep() d := flextime.Until(date) d := flextime.Since(da
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が下限のようなので、その額に設定させてもらいま
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
最近のGo Modulesプラクティス ~ ghqユーザーの場合も添えて | おそらくはそれさえも平凡な日々
最近Go Modulesを使っていて、だいたいプラクティスが定まってきたのでまとめてみる。 個人的な結論 Go Modulesは積極的に使っていけばいい 幾つか課題はある $GOPATH から出る必要もない $GO111MODULE を適宜設定すればよい どうせ次のGo 1.13からはどこに置こうが関係なくなる 2つのモード $GOPATH/src にプロジェクトを置いていると、今(Go 1.12)の標準動作はGOPATHモードになる。これは、$GOPATH/src 以下からサードパーティパッケージを読み込むこれまでのGoと同様の動作になるということ。 それ以外の場所では go mod コマンドを使ってGo Modulesを利用することができる。これをmodule-awareモードという。go.mod と go.sum を使って依存ライブラリを管理する方式になる。これらのファイルはgo m
Go Conference'19 Summer in Fukuokaで登壇してきた | おそらくはそれさえも平凡な日々
https://junkyard.song.mu/slides/gocon2019-fukuoka/#0 色々あってお声がけ頂き、登壇させてもらえることになったので、福岡に行ってきました。出張扱いで、出張費用も所属のNature Japan株式会社に出してもらいました。 話した内容は、Go Conference 2019 Springで20分で話した内容を、単なる再演にならないように内容を膨らませて40分で話した感じです。割と好評のようで良かったです。資料は口頭で説明した部分も多いので、トピックに分けて改めてブログ記事にしたいと思っています。 イベント全体を通して スタッフの皆さまが少人数ながら的確に動いていて、何もストレスなく快適にイベントを過ごすことができました。すごく楽しかった。ビールや生ハム、スピーカーディナーも楽しませてもらいました。スポンサーの各社に感謝。 会場のFukuoka
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ツールのクロスビルドとパッケージングのためのgoxzというツールを作った | おそらくはそれさえも平凡な日々
Goツールのクロスビルドと成果物生成には個人的に長らく、goxcを愛用していましたが、その乗り換えとして、goxzというのを作った。go + x(cross) + z(zip)でgoxz。便利です。 https://github.com/Songmu/goxz goxcは非常に高機能なのですが、僕がその機能の一部しか必要ないことや、goxcのメンテ自体も止まっている(とオフィシャルでも案内されている)ことが気になったので作りました。 具体的には「Goツールのクロスビルドと成果物のアーカイブ生成をパラレルにおこなう」ことしかしない。アーカイブ生成時に、リポジトリからLICENSEやREADMEを自動的にかき集めるのはやってくれます。 基本的には「設定より規約」という感じで、良い感じのデフォルトを決め打ちにして、あまり細かい設定項目などは作らない想定です。 インストール https://git
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
恐らくそれなりに正確なGoのApacheログパーザーを書いた | おそらくはそれさえも平凡な日々
https://github.com/Songmu/axslogparser/ 下記のようにすれば、ApacheログかLTSVログをよしなにパーズしてくれます。 import "github.com/Songmu/axslogparser" log, err := axslogparser.Parse(line) Apacheのログ形式として知られるアクセスログはいろいろな形式があり、正確なパーズが何気に困難であることが知られています。よく使われるのは以下のような形式です。axslogparserはこれらの形式をサポートしています。 commonログ commonログの先頭にvhostが付いたもの combinedログ combinedに独自フィールドが追加されたもの フィールドの区切り文字は一般的には半角スペースが使われますが、パーズし易さのためにタブ文字が使われることもあります。現在は
Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々
近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp も本質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って
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
Gitのtagとpull requestのマージ履歴からChangelogを自動生成する `ghch` | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghch mackerel-agent のリリースフローでは、前回のリリース以降の、pull requestのマージ履歴を拾って、そこからChangelogを自動生成するということをおこなっている。 これは、1年半前くらいにPerlで書いていたのだが、この度汎用的にしてGoで書きなおした。それが ghch。前回打ったsemverっぽいgit tag以降のマージ履歴を抽出してくれる。例えば、こういう風にmackdownで出力がされる。 % ghch --format=markdown --next-version=v0.30.3 ## [v0.30.3](https://github.com/mackerelio/mackerel-agent/releases/tag/v0.30.3) (2016-04-27) * retry retire
より良い `go run` を実現する goshim | おそらくはそれさえも平凡な日々
https://github.com/Songmu/goshim プロジェクトでちょっとしたスクリプトを書いてリポジトリで共有したいとなった時に、スクリプト言語なら楽ですが、Goで書くのはやや面倒です。リポジトリを分けるようなものでもないし、わざわざ go install させるようなものでもないけど、ビルドしたバイナリをどこに置くのかなどが悩ましい問題です。macを使っている人もいればlinuxを使っている人もいるのでバイナリをリポジトリに配置するわけにもいきません。 go run でも良いかと思われるかもしれませんが、本当にちょっとしたものならよいいのですが、以下の様な問題があります。 複数ファイルになった時に go run main.go hoge.go とかやるのがダルい (% go run $(go list -f '{{join .GoFiles " "}}') [args..
horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
ISUCON5で優勝してきました | おそらくはそれさえも平凡な日々
毎回素晴らしいイベントを主催されているLINE株式会社様、毎回ホスピタリティあふれる運営に尽力されている@941さん、出題の@tagomorisさん@kamipoさん、その他協賛企業や運営スタッフの皆様に感謝申し上げます。 ということで、ISUCON5に出場し、優勝してきました。 ISUCON1の優勝チームの再結成で @fujwiara, @sugyanと僕というメンバー構成です。4年前のISUCON1の時にチーム名を「fujiwara組にしよう」と強く言ったのは実は僕で、そのまま僕が代表者として申し込んだのですが、まさかここまでfujiwara組ブランド(?)が定着するとは思いませんでした。今年もfujiwaraさんの力が大きい勝利ですが、僕も大分貢献できたと思います。 ということで当日を振り返ります。 お題 外部APIを叩くネタで驚いた。可能性は考えていましたが、まさか来るとは思ってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
