Dockerと付き合っていく上で考えるべきことのメモ
# Extend into a hash to provide sparse and unsparse methods. | |
# | |
# {'foo'=>{'bar'=>'bingo'}}.sparse #=> {'foo.bar'=>'bingo'} | |
# {'foo.bar'=>'bingo'}.unsparse => {'foo'=>{'bar'=>'bingo'}} | |
# | |
# options: | |
module Sparsify | |
def sparse(options={}) | |
self.map do |k,v| | |
prefix = (options.fetch(:prefix,[])+[k]) |
ここに書かれているのは、「主目的」であって、プログラマーもしくはテストエンジニアが「他のことを考慮していない」という意味ではありません。あと、僕の解釈なので一般論というわけではないないです。
プログラマーは基本的に「テストを書く」というと思います。実際に書いているんですけど。これ、手動テストしかなかった時代は、どうやって言っていたのかわかりませんけど、これは非常に的を得ていると思うのです。プログラマーの主眼は「要求を設計し実装すること」にあります。そしてその意志はプロダクトコードとなって表現されます。そう、プロダクトコードというのは、表現手段なんです。なので、彼らにとってテストコードというのはあくまで「要求を設計し実装すること」のある表現手段であり、それがプロダクトコード以外であるということにすぎないのではないでしょうか。
プログラマーはあふれるその思いをコードに表現する事が楽しみです。主目的である「要求を設計し実装すること」をテストというフィールドにおいて実施するというのは若干の矛盾をはらんでいて、やっていることは、「要求を設計し実装すること」をしながら確認がとれるものとして、テストコードという手段をとった。くらいのイメージです。
diff --git a/screen-write.c b/screen-write.c | |
index 15f8d07..8a175a6 100644 | |
--- a/screen-write.c | |
+++ b/screen-write.c | |
@@ -1334,6 +1334,7 @@ screen_write_cell(struct screen_write_ctx *ctx, const struct grid_cell *gc) | |
ctx->cells++; | |
/* If the width is zero, combine onto the previous character. */ | |
+ /* | |
if (width == 0) { |
最近、社内で私が「何者で何をしているのか見えないので可視化して欲しい」という案件が出ているらしいので、ヘコヘコと徒然なるままに書いていきたいと思うのであります。
社内向けというだけでなく社外の人にも発信出来る内容に、との仕様も要求され、社外向けには出来るだけ旬なネタで、かつ、社内向けにはそれを理解する上で必要な関連する技術を個々に触れながら基礎知識が無くても理解出来るように、との追加仕様も提示されております。
で、何をネタにしてどのように書けばいいのか迷った訳ですが、自分が実際にやって来た内容である CoreOS であればそこそこ旬であるし、それをおさらいしつつ、関連技術も Docker、Omaha、systemd、BtrFS、Golang、etcd、Kubernetes 等々多岐にわたるので、それらに関して私見も含めてわかりやすく書ければいいかなぁと、とりあえず書き始めようとしている次第であります。