はじめに DockerにGolangの環境を閉じ込めたときデバッグどうするの?と思ってなかなか情報を集められなかったのでまとめます。 検証環境 ホスト側 Windows10 + Boot2Docker + VisualStudioCode Sierra + Docker for Mac + VisualStudioCode コンテナ側 golang:onbuildを使用(執筆時点ではgolang 1.7) Golangのデバッガについて VisualStudioCodeではDelveを使うようなので、Delveを使います。 ドキュメントやissuse見てるとリモートデバッグもサポートしていて、もしかしてDockerもいけるかもってところが発端。 Dockerのリモートデバッグについて リモートデバッグが可能なようで、こちらをベースにGolang用に書き換えます。 Live Debuggin
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
「汚く作ってやりなおせ」ってメイカー界隈の名言あったよなと思って調べるも見つからず。 あれれ?って思ったので、SNSで聞いてみた。 quick and dirty prototype のことでは? と教えてもらった。 それを勝手に脳内で「汚く作ってやりなおせ」って翻訳してたのかもしれない。 ともかく何かを創るときは、まずは「汚く作ってやりなおせ」が良い。 汚くてもいいので、まずは作ってみて、それからあれこれブラッシュアップするとよい。 たとえば「ゲームづくり」を教えている現場を見てると、これが案外できない。 すごいの作ろうとして、延々と議論して、準備して、はては、まず勉強してからじゃないと、とか言い出す。 経験則的に「まず勉強してから」と言う学生は、勉強しない。「それ、ただの先延ばしだよね?」と指摘して、そうだなと気づいても、パッと手を動かすことには抵抗があるみたいだ。 「汚く作る」以前に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く