タグ

Goとmakeに関するraimon49のブックマーク (9)

  • Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ

    はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる+調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

    Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
  • Golangでバイナリを配布するとき、go-licensesとgoxzを使って利用モジュールのLICENSE、NOTICEを同梱する - 理系学生日記

    Golangで作ったプロダクトを公開・配布するとき、課題となるのが利用するモジュールのライセンスです。 MITライセンスであれ、MPLライセンスであれ、利用するモジュールのLICENSEやNOTICEファイルを同梱することになるでしょう。 goxzとgo-licensesを使うと、クロスビルドした実行バイナリと利用モジュールのLICENSE等を含め頒布物を作成できるようになります。 最終イメージ 同梱されていることの確認 go-licenses ハマりポイント goxz まとめ 最終イメージ 最終イメージですが、以下のようなMakefileを用意しました。 プロダクトに設定したライセンスで利用できないモジュールがあるかどうかをlicense-checkで確認した後、cross-build.shを呼び出します。 .PHONY: license-check license-check: go-

    Golangでバイナリを配布するとき、go-licensesとgoxzを使って利用モジュールのLICENSE、NOTICEを同梱する - 理系学生日記
  • Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり - tellme.tokyo

    Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり February 4, 2020 lt;dr GoReleaser と GitHub Actions を使うと簡単にビルドしたバイナリを作ってアップロードできる。 2つの YAML を書いてリポジトリにコミットする .github/workflows/release.yml .goreleaser.yml git tag して push する バイナリがリリースされる 専用のツールをローカルにインストールする必要はない。 題 前に、Go のコマンドラインツールを簡単にリリースする | tellme.tokyo というブログを書いた。 それよりももっと楽になったので紹介する。 基的にこのページで紹介する方法では 2 つの YAML をリポジトリに置くだけで終わる。 ロー

    Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり - tellme.tokyo
    raimon49
    raimon49 2020/02/04
    ldflagsもYAMLへ。
  • 至高のDockerイメージ生成を求めて -2019年版- - Qiita

    この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP

    至高のDockerイメージ生成を求めて -2019年版- - Qiita
    raimon49
    raimon49 2019/09/20
    ちょうどマルチステージビルドでコンパイル時間を短縮したいと考えていたので、BuildKitやBazel触ろうと思った。
  • isucon7予選のアプリをRustに移植したから解説するね | κeenのHappy Hacκing Blog

    κeenです。こういう流れがあったので移植しました。 keenさんが「2028年、Rust でイケてる web application framework はこれだ!」みたいな記事を書くとと "余力" が生まれるかもしれません…!! — FUJI Goro (@__gfx__) 2018年8月28日 まずISUCONを知らない方に雑に説明しておくと、意図的に遅く作られたWebアプリケーションが与えられるので7時間くらいでどれくらい高速化できるかを競うコンテストです。 このお題のWebアプリケーションが参加者や流行りに合わせて複数言語で提供されるのですが、今年はRustが来そうだということで参加者の肩慣らしのために過去問を移植しましたというお話。 ひとまずソースコードは こちら 手元でベンチマークをしてみた限り、Pythonの2倍くらいは速いもののGoには劣るようでした。これの考察については

    isucon7予選のアプリをRustに移植したから解説するね | κeenのHappy Hacκing Blog
  • 最近のGoプロジェクトのMakefile - 詩と創作・思索のひろば

    最近は仕事でも新しくGoプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール(golint とか gobump とか)であったりのインストールをどうするかという話。 npm であれば devDepende

    最近のGoプロジェクトのMakefile - 詩と創作・思索のひろば
  • Go でツール書くときの Makefile 晒す - Qiita

    Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。 $ cd $GOPATH

    Go でツール書くときの Makefile 晒す - Qiita
    raimon49
    raimon49 2017/01/11
    -ldflagsでバージョン埋め込みやstatic linkバイナリ生成を強制
  • 至高のDockerイメージ生成を求めて - Qiita

    稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ

    至高のDockerイメージ生成を求めて - Qiita
    raimon49
    raimon49 2016/12/22
    ビルド環境用Dockerfileと分ける。
  • makeのくびき - saneyuki_s log

    gulpって何だよ、makeでいいじゃん(要約」論争について、私もちょっと一講釈をぶってみることにする。あれやこれやといった実利的な話をするつもりはない。そういうものは既に書いた人がいるのでそちらを参照のこと。 Gruntの思い出 Gruntは、私の印象で言えば車輪の再発明の失敗作のようなもので、タスク間の依存関係が破滅への一途をたどり管理不能に至るなど、宣言型の負の側面が強く出てしまった。しかし、設定は当にサンプルコードのコピペだけで組み立てられるので、JSが不得手なデザイナーなどには非常に受けが良かったという点は忘れてはならない。ちょうど、html5ブームが格化して, Apache Antとかに慣れ親しんだJava(主にSIer)系の人が入ってきたタイミングにあった道具かつ、Yeomanファミリーにも組み込まれており、それでいて簡単な事をやらせるには悪くはない具合のシンプルさ、

    makeのくびき - saneyuki_s log
    raimon49
    raimon49 2016/01/17
    「何でGruntがそれなりに普及していたか?」が整理されていて読み応えがある。誰もがコマンドラインファーストな国に住んでいる訳じゃない。
  • 1