intention_reveiling_names.md名前は使われる場面で使い方を指示したり制約したりするような意味合いを名前で表現できるとよい名前になります。表現しているクラスだったり変数の実装を見ながらつけると名前をつけるもの自体を中心においてそれを説明する名前になります。良い名前にしたいなら、そのオブジェクトやメソッド、変数が使われる場面で、どのように使うと読みやすいか、ミスしやすい部分をミスしないように導けるかを気にしながら、使う人へメッセージとなるような名前をつけます。これを実装ではなく意図に名前をつけると呼んでいます。エンジニアに教えてもらって以来、気に入って大事に使っています[^2]。それはコミュニケーションです。重要なのは、一行だけのメソッドでも、意図を伝えるために存在する価値があるということです。2019スポンサーブースを出展するよ。スポンサーブースってどんなかんじで出してます?って聞かれたのでスポンサーブース出展のノウハウを書いてみた。ブースが強い会社は一人ノウハウを持った状態で転職した人がいてこなれたかんじでやっているという印象。設営資材パネルとテーブルクロスとバナースタンドはつくりました。遠くから見たときに存在に気付いてもらえるように。どら焼きつくって持っていきました。7社くらいとかぶりました。naming.mdレビューコメントから「問合せている」のは手段で、目的として得たいものは別ですよね。名前は実装や手段ではなく、意味や意図、結果、目的に対して付けます。実装じゃなくて意味に付けようって話はコードコンプリートに書いていて、たぶんリーダブルコードにも書いていて、超基本的なんですが最重要なので、すべての名前で今自分はなにに対して名前を付けたのかを自問自答する癖をつけるのをおすすめです。what_is_rehearsal.mdリハーサルはなぜ重要か(実施告知の文章から抜粋)ええと、みなさんAWS移行の準備も大詰めでリハですね。リハーサルってなぜやるかわかってる人もわかっていない人もいると思うので書いておきます。結論を先に書くと、本番当日もそのまま手順を踏襲するとそれで移行が終わる詳細な手順が書かれた移行手順書を書いてリハをしてください。リハの中で手順どおりには行かなかったところはその時にすべて手順書に反映して、本番のときは手順どおりでやれるようにしてください。本番一発勝負というのは難しいもので、人間どんなに考えていても失敗します。(できるようにします)。(アジャイルが繰り返し開発するのも動くソフトウェアを信じるからですね)。性質として事実上そういうものなのですが、私達の気持ちとしては当然失敗はしたくありません。そこで、失敗をするはずの一度目としてリハーサルという疑似本番をやるわけです。することで、失敗の予行演習ができます。本番に向けて失敗の予防ができます。ここを人手でやると再現性が落ちるのでベストは自動化され、何度やっても繰り返し同じことが実現できる状態です。それはしやすいものとむずかしいものもあるので人間がそのとおりに実行をしたら同じ結果になるという手順書というのが大事になってきます。作業を自動化しようと思う者であれば、定型作業はすべて悪だと思い、人がやる以上は必ずその作業に判断とそれによる付加価値が発生することを求める。付加価値があるときも、時間と費やす集中力に見合う付加価値があるのか、他のことに時間を使えばもっと価値があるんじゃないかと徹底的にこだわる。自動化できない作業をせざるをえないときに同じ心持ちだとただただ消耗するので、そこはそれと切り替えよう。思考を停止し自分は機械だと思いこなそう。あることを意識させるかというのはポイントになりそうな気がします。インターフェイスをかぶせた場合。呼出し元として使い始めた場合。2015こんなかんじの作りたい。ときで対応変える必要ありそうな気がする。利用へ移っていくためのノウハウあれこれ。場合に考える観点をあげてみます。