まとめを先に 自分のGitHub上にtapリポジトリをサクッと作る そこにFormulaと呼ばれるファイルをコミットする maltmill というツールを使うと簡単！ 用語 Formula 各ツールのインストール手順を記述するファイル maltmill.rb であれば maltmillのインストーラー RubyのDSLで記述 tap Formulaを配置するリソースリポジトリ GitHub上に"homebrew-"プレフィクスで作成する これらは自前で簡単に作ることができます。公式リポジトリに頑張ってpull requestを送ることもできますが、個人的なものであれば気軽に自前で作ってしまうことがおすすめです。 tapリポジトリの作成 前項で書いたとおり"homebrew-"プレフィクスを付けて命名すればOKです。僕の場合homebrew-tapという名前で作っています。 https://
常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr
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の証明書切替周りその後 このサイトは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
システムを運用していく以上、ライブラリは常に最新を使いたい。最近は依存ライブラリの更新を検知してくれる便利なサービスがいくつかあって、Nature社ではDependabotを使っている。 https://dependabot.com/ Renovateの方が便利そう、という話も聞くのだが、とりあえずDependabotはGitHubが買収して、privateリポジトリでも無料で使えるので利用している。 導入自体は簡単で、画面のガイドどおりに進んでいけば、良い感じに言語や依存管理ツールも自動検出してくれる。設定ファイルは特に置いていない。慣れてきたり、設定を横展開したくなった場合に置くと便利そう。 参考: Dependabotの設定ファイルを置くようにした 動作の様子 前提としてGo Modulesで依存管理をしているが、依存ライブラリの更新があると以下のようにpull requestを上げ
2020年1月5日追記: v1リリースしました https://songmu.jp/riji/entry/2020-01-05-ghq-v1.html https://github.com/motemen/ghq 最近のghqの状況と、v1リリースに向けた非互換変更などのアナウンスです。現状の最新のv0.17.4を前提に書きます。 ghq.<url>.root 設定により細やかにclone先を設定可能に 例えば、gitconfig上に以下のように設定すれば、デフォルトでは"~/src/hobby" に、仕事用は"~/src/work"にcloneされます。 [ghq] root = ~/src/hobby [ghq "https://github.com/myorg"] root = ~/src/work [ghq "https://myvcs.example.com"] root = ~
motemenにcollaboratorに追加してもらったので、滞留していたissue及びpull requestを大体さばきつつ、機能追加などをおこない、先程v0.11.1をリリースしました。GW中になんと45個のpull requestをマージしました。 今回の目玉は go get/import の機能追加です。具体的には、ghqで取り込んでいるリポジトリの一括アップデートや、Goの依存の一括取得が簡単になりました。 変更点 詳しくは、 v0.10.0以降のCHANGELOGを見てもらえればと思いますが、一部ピックアップして取り上げます。 ghq get/import への入力にホストも受け付け可能に https://github.com/motemen/ghq/pull/119 実はこれまで以下のようにホスト名をつけられなかったのですが、それができるようになりました。ghq impo
前提として、/bin/sh は、デフォルトでは、RHEL系の場合bashシェル、Debian系の場合dashシェルへのsymlinkになっています。この2つのシェルの挙動は細かいところで結構異なります。そもそもの思想として、dashシェルはPOSIX互換を目指す軽量なシェルであり、bashは拡張された高機能なシェル。なのでbash前提で書かれたシェルスクリプトがdashでは動かない、みたいなことはよくあります。そういう感じで困ることがままありますが今回もそういう話。 例えば % sh -c "sleep 100" のようなコマンドを実行した場合、呼び出し元の子プロセスが sh になり、その更に子プロセスが sleep になると直感的には思うでしょう。つまり以下のような具合。 . \_ sh -c sleep 100 \_ sleep 100 しかし、 sh の実体が bash である場合な
前回: Goツールのリリースにおけるバージョニングについて 前回挙げた以下のリリース5段階の中で、バージョニングだけで1エントリになりましたが、今回は、2,3について。 versionをbumpする CHANGELOGを更新する 1,2での変更をgitに反映してタグを打つ ビルドする ビルドをアップロードする 具体的には、リリースに纏わるファイル更新をgitに反映さえてタグを打つところまで。ビルドする直前までとも言えます。 CHANGELOG.mdを自動更新する CHANGELOGは ghch で自動生成させている。規定の CHANGELOG.md をリポジトリに配置して、 % ghch -w -N $next_tag とすれば、魔法のように CHANGELOG.md を更新してくれる。生成された CHANGELOG.md はこんな感じ。 https://github.com/Songmu
実質一行。異常に簡単だった。 import ( "net/http" "net/http/httptest" "testing" ) func TestDownload(t *testing.T) { ts := httptest.NewServer(http.FileServer(http.Dir("testdata"))) defer ts.Close() resp, err := http.Get(ts.URL + "/test.txt") ... } ちなみに、テスト用のファイルを testdata という名前のディレクトリに置くのは、公式のドキュメントにも書かれている慣習ですね。 https://golang.org/cmd/go/ The go tool will ignore a directory named "testdata", making it available
Goのツールをリリースする時、個人的には以下のような手順を踏んでいる。もちろんスクリプトで一撃でできるようにはしている。今回は1.の話。セマンティックバージョニングの話は出てきません。 versionをbumpする CHANGELOGを更新する 1,2での変更をgitに反映してタグを打つ ビルドする ビルドをアップロードする versionは -ldflags を使って動的に埋め込む方法があるが、最近は明示的にソースコードに書いた方が良いと思うようになってそうしている。 理由としては、ユーザーが go get/build で実行ファイルを取得した場合でもバージョンは表示されて欲しいというのが一つ。 -ldflags で実行ファイルに色々な値を埋めることはできますが、基本原則として、それらを埋めてない状態でもちゃんと実行ファイルが正常に動くようにすることを意識した方が良い。 もう一つの理由と
外部ライブラリに依存する時に、どのようにバージョンロックをすべきかどうかという話。僕個人のスタンスです。 開発しているのがライブラリであれば依存ライブラリをバージョンロックをするべきではない 最低バージョンの指定に留めるべき(これは寧ろ積極的にやって良い) 依存ツリーが大変なことになってコンフリクトが避けられないため 実運用しているサービスやアプリケーション的なソフトウェアであればバージョンロックした方がいい これは「ある時点のビルドやリリースの再現性」のためが一番大きいと思っている 古いバージョンにとどまって良いというわけではない 基本的には、開発しているものがライブラリであれアプリケーションであれ、 とにかく依存先の最新についていく のが前提で、その前提に立った場合に、上のような考え方になるかな、と思っている。 特にライブラリ作者は依存ライブラリに非互換変更が入って動かなくなったら、頑
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
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に上げる
http://sourceforge.net/projects/checkbaskisms/ 「#!/bin/sh なのにbashでしか動かないシェルスクリプトを書くな！」みたいなことはよく言われるわけですが、僕はゆとりなので正直どうでもええやろとか思ったりもしてました。実際、CentOSだと、/bin/sh は /bin/bash へのリンクだし、OSXでも /bin/sh の実態はbashだしね。 しかしそこで立ちふさがるのがUbuntu。Ubuntuだとデフォルトで /bin/sh は /bin/dash だったりするわけです。dashはPOSIX準拠のsh実装で、bash独自の記述があると見事に動かない。 とはいえ、それで困るのだったら、デフォルトシェルをbashにしたVMテンプレートを作ればいいんじゃないかって思うやろ。僕もそう思う。 しかしそこで立ちふさがるのがTravisで、
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
