継続的デリバリー vs 継続的デプロイ
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） ティモシー・フィッツの継続的デプロイに関するブログは、デイブと私が継続的デリバリーについての本を出版する1年以上も前に、すでに書かれていた。そんな中でなぜ私たちは異なる名前を選んだのだろうか。実際に違いはあるのだろうか？それとも単に我々が不親切なだけなのだろうか？ 我々はいくつかの理由で本の名前を「継続的デリバリー」とすることにした。まず第一に、デプロイがリリースを意味しないというちょっと学者ぶった事実。我々が本の中で言っているように、継続的に顧客受け入れ環境にデプロイすることはできるだろう。それ自体はたいしたことはない。継続的デプロイを特別なものにするのは、自動テスト(加えて非常に短いQAゲート)を通った全ての変更を本番環
golang の const と var のコンパイル時解釈
Goでは定数と変数をそれぞれconstとvarで宣言します。とても基本的なことですが、コード内での使い方によってはコンパイラの解釈が変わるので、今回はその紹介をします。 はじめにGolang Allstars 2 では、下記のスライドを使って登壇しました。 スライドでは定数のことをお話しましたが、アセンブリコードを読んだわけではなかったので、今回はアセンブリコードからのアプローチになります。 上記スライド内にある下記のコードに今回はフォーカスします。 var Day = 24 * time.Hour const Day = 24 * time.Hourコードレビューをしていると、 const Day = 24 * time.Hour のように定数として宣言すればよいところを、 var Day = 24 * time.Hour として実装しているとして指摘をすることが何回かありました。 ただ
go build -tagsを使ってRelease/Debugを切り替える - flyhigh
Goでウェブアプリのクライアントを書いている。 ローカルでテストする場合は、サーバもローカルにたてるので、アクセスする先はlocalhostになる。 リリースするときは正しいウェブアプリのURLを指定しなければならない。 この際、切り替えはナイーブにコメントアウトで行ってきた。 const ( // APIServer = "http://www.mywebapp.com" APIServer = "http://localhost:8080" ) 当然、デバッグ用を有効にしたままリリースしてしまったり、その逆だったりと、混乱があった。 このような、デバッグ・リリースで機能を切り替えたい場合はBuild constrainsを使えば良いらしい。 Build Constrainsとは？ 従来の機能が充実しているGoに抜かりはない。Build constrainsとは必要に応じてビルドするファ
- 自動化のためのGNU Make入門講座 - Makefileの基本：ルール
ここでは，メイクファイルの基本的な書き方としてルールの説明をしましょう．ここからは，Makefileといえばmakeが参照するメイクファイルのことを指すものとします． コメントと改行 その前に少しコメントの書き方について解説しておきます．Makefileでは，#から行末までがコメントです．例えば， # # Hello Worldを出力する # all: @echo Hello World! のように使います． また，makeは基本的に行指向です．見やすくするために改行したい場合はバックスラッシュ\を使って改行を無視させることができます．例えば，マクロの定義（後述）で object_files = \ foo.o \ bar.o \ baz.o と書けば，makeは改行を無視して次のように解釈します． object_files = foo.o bar.o baz.o ここで注意することは，f
Makefile での .PHONY と FORCE の違い
[以前](/2012/02/linuxmakefile-4.html)、 `.PHONY:` 指定と `: FORCE` 指定について触れたことがあるのですが、 明らかに両者を使い分けるべきケースがあることに最近気がついた。 まずは、 make の初歩ですが、 PHONY ターゲットからおさらいします。 次のような `clean` ターゲットがあったとする。 clean: $(RM) $(programs) $(objects) もし、カレントディレクトリにたまたま `clean` という名前のファイルが存在すると、 この `clean` は実行してくれません。 $ touch clean $ make clean make: `clean' is up to date. そこで、 .PHONY: clean clean: $(RM) $(programs) $(objects) としてお
喫煙者はお断り、IT企業の採用方針で波紋
あるIT企業が打ち出した「喫煙者は採用しない」という方針が波紋を呼んでいる。プログラミング教育サービス「TECH::CAMP」を提供するdivだ。 divの真子就有 代表取締役は2018年4月末に「喫煙者を一切採用しないことにしました」と題したブログエントリを公開した。「健康面のリスク」「生産性の低下」「周囲への悪影響」という三つの理由で、この方針に踏み切ったという。 このブログエントリに対しては1000件弱ものブックマークが集まった。ブックマークのコメントも「喫煙者を差別するな」という反対意見から「こんな会社なら入りたい」という賛成意見まで様々だ。まさに賛否両論である。 実は、同社以外にも喫煙者を採用しない企業はある。有名なのは星野リゾートだろう（同社の採用関連ページ）。岐阜セラツク製造所という化学品メーカーも喫煙者は採用していないという（同社の採用関連ページ）。また、「企業、募集要項、
喫煙者を一切採用しないことにしました。 | マコなりの社長室
Tweetしたところ反響があったのでブログにも簡単に書こうと思います。 今後、喫煙者は一切採用しないことを決めました。オフィス等の喫煙場所は撤去。現在の喫煙者の禁煙外来費用は会社が負担します。法の範囲で個人の生き方は自由ですが、①健康②生産性③周囲への影響という観点で会社にとって良いことが何もありません。喫煙者不採用の会社が増えることを願っています。 — まこなり (@mako_yukinari) 2018年4月27日 なぜ喫煙者を採用しないことを決めたのか Tweetに書いたように①健康②生産性③周囲への影響の面で会社にとって良いことが何もないと思ったからです。 健康面のリスク 健康面では、肺がんのリスクが５倍になります。本人だけではなく受動喫煙者もリスクが高まります。 別に自分で好きなことやって勝手に死ぬならいいだろという意見も出そうです。 ただ、実際に将来、肺がんになってしまった時に
モヒカン族は上司になれるか？
もうそろそろ、「モヒカン族」も管理職になって、部下を持っているような時代だと思いますが、きちんと「上司」できてるんですかね……？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
