Go のバイナリには -ldflags '-w -s' でコンパイルしてもたくさんパスが埋め込まれていた - Qiita
とコンパイルすることで、 DWARF とシンボルテーブルの情報をバイナリに残さずコンパイルできる。 しかし、自分は気になったので strings コマンドを生成後のバイナリにかけてみた。 するとバイナリには というような行が、まだたくさん残っていた。 どうやら DWARF やシンボルテーブルの情報を削除しても、コンパイルの際のパスなどの情報は残ってしまうようだ。 消してみると 10% くらい節約できた そこで、全て浅いディレクトリでコンパイルしなおしたところ、約 5MB のバイナリが約 4.5MB ほどまで節約できた。 ソースコードを細分化していればしているほど、モジュールを使っていれば使っているほど、含むパスは多くなるので、これらにより節約できるサイズは大きくなる。 Go の単一バイナリを Docker コンテナにするような状況では、 10% の節約は心理的に大きい。 (嬉しい) 使い所
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
masterブランチでちょっとした変更をしたいんだけど、devブランチで作業しているから切り替えるのはめんどくさい。 そんな時はgit worktreeを使ってみてください。複数のブランチを切り替えずに操作できます。 ※git worktreeを使うにはGit 2.7.0以降が必要です。それ以前のバージョンだとgit worktree listがありません。 ブランチの追加 操作したいブランチはこんな風に持ってくることができます。 すると、作業ディレクトリ以下に指定したブランチの中身がリンクされます。 たとえば、git worktree add ./worktree-dev devとコマンドを打つと、./worktree-devディレクトリが作成され、その下にdevブランチの内容ができるわけです。 git worktreeは今いるブランチに影響を与えません。 つまり、作業中であっても操作し
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
