Sunao Tanabe sunaot

問題解決のしかたを本で読んで、実際にやっていくときにどう使っていくのかのイメージがつかない人が多そうなので書いてみる。理解が深いほどある程度解決のための型があって、フレームワークの評価から実行へ移したくなったりもするけれど、過程で関わる人の理解がそろっていくのも大切なのでそこをどんなスピードとプロセスで進めていけるかが実地の問題解決者としてのアートな部分でもある。

なにはなくとも現地現物。一次情報を聞きに行く
解決志向的な質問を立てる
分析をして確度を上げていく
解決をしていく

の順で説明をしていく。

名前は使われる場面で使い方を指示したり制約したりするような意味合いを名前で表現できるとよい名前になります。

表現しているクラスだったり変数の実装を見ながらつけると名前をつけるもの自体を中心においてそれを説明する名前になります。良い名前にしたいなら、そのオブジェクトやメソッド、変数が使われる場面で、どのように使うと読みやすいか、ミスしやすい部分をミスしないように導けるかを気にしながら、使う人へメッセージとなるような名前をつけます。

これを実装ではなく意図に名前をつけると呼んでいます。CODE COMPLETE 上巻の 11.1.2 に『問題指向の名前』という半ページくらいの文章があり、 How でなく What に名前をつけるという主旨のことが書いてあるのが元ネタ (の一つ) です[^1]。

意図 というすばらしい語彙は Kent Beck が Smalltalk Best Practice Patterns というこれまたすばらしい本に Intention Revealing Names という話を書いているということを以前一緒に働いた Java エンジニアに教えてもらって以来、気に入って大事に使っています[^2]。

何が起こっているのでしょうか？それはコミュニケーションです。最も重要なのは、一行だけのメソッドでも、意図を伝えるために存在する価値があるということです。

@threetreeslight にスポンサーブースってどんなかんじで出してます？って聞かれたのでスポンサーブース出展のノウハウを書いてみた。ブースが強い会社は一人ノウハウを持った状態で転職した人がいてこなれたかんじでやっているという印象。

設営資材

パネルとテーブルクロスとバナースタンドはつくりました。遠くから見たときに存在に気付いてもらえるように。

ノベルティ

前回の RubyKaigi ではどら焼きつくって持っていきました。7社くらいとかぶりました。知合いスポンサー間で事前にすり合わせておけばよかった...

レビューコメントから

「問合せている」のは手段で、目的として得たいものは別ですよね。名前は実装や手段ではなく、意味や意図、結果、目的に対して付けます。
実装じゃなくて意味に付けようって話はコードコンプリートに書いていて、たぶんリーダブルコードにも書いていて、超基本的なんですが最重要なので、すべての名前で今自分はなにに対して名前を付けたのかを自問自答する癖をつけるのをおすすめです。

Clean Code より。

意図を表現した名前をつける (Use intention revealing names)

リハーサルはなぜ重要か

(実施告知の文章から抜粋)

ええと、みなさんAWS移行の準備も大詰めでリハですね。リハーサルってなぜやるかわかってる人もわかっていない人もいると思うので書いておきます。結論を先に書くと、本番当日もそのまま手順を踏襲するとそれで移行が終わる詳細な手順が書かれた移行手順書を書いてリハをしてください。リハの中で手順どおりには行かなかったところはその時にすべて手順書に反映して、本番のときは手順どおりでやれるようにしてください。

本番一発勝負というのは難しいもので、人間どんなに考えていても失敗します。でも失敗を糧に二度目をすると一度目にやった失敗は回避できます (できるようにします)。システム開発というのは一般的に大体予測不能なところで失敗するものなので、一度本番同様に動かしてみるというのが非常に重要になってます (アジャイルが繰り返し開発するのも動くソフトウェアを信じるからですね)。

性質として事実上そういうものなのですが、私達の気持ちとしては当然失敗はしたくありません。そこで、失敗をするはずの一度目としてリハーサルという疑似本番をやるわけです。そうすることで、失敗の予行演習ができます。本番に向けて失敗の予防ができます。ここを人手でやると再現性が落ちるのでベストは自動化され、何度やっても繰り返し同じことが実現できる状態です。でも、それはしやすいものとむずかしいものもあるので人間がそのとおりに実行をしたら同じ結果になるという手順書というのが大事になってきます。

自動化をしていくときに大切なこと

心得

作業を自動化しようと思う者であれば、定型作業はすべて悪だと思い、人がやる以上は必ずその作業に判断とそれによる付加価値が発生することを求める。付加価値があるときも、時間と費やす集中力に見合う付加価値があるのか、他のことに時間を使えばもっと価値があるんじゃないかと徹底的にこだわる。

自動化できない作業をせざるをえないときに同じ心持ちだとただただ消耗するので、そこはそれと切り替えよう。思考を停止し自分は機械だと思いこなそう。現実は厳しく、"Done is better than perfect." だ。

大切なこと

どこの層まで Thor であることを意識させるかというのはポイントになりそうな気がします。 database は Thor 以外からはけして呼ばれないでしょうか？たとえば、Web インターフェイスをかぶせた場合。bot を呼出し元として使い始めた場合。実際にそれらを作り始めて不都合が出てから変えてもいいのですが、今の時点で

+--------------+ +-----------+
|  dispatcher  | |   view    |
+--------------+ +-----------+
+----------------------------+

	require 'digest/sha1'

	def room_id(name)
	digest = Digest::SHA1.new
	digest.update(name)
	digest.hexdigest.slice(0,20)
	end

	def encryption_key(seed)
	alphabets = ('a'..'z')

	# frozen_string_literal: true

	require_relative "ractor_stream/version"

	# [1,2,3,4].parallel.filter {\|n\| n.even?}.map {\|n\| n * 2}.each {\|item\| puts item}

	class Enumerator
	class RactorParallelStream
	Consumer = Struct.new(:message, :processor, :args, :keyword_args)

	def fold(init, list, &block)
	case list
	in []
	init
	in [x, *xs]
	fold(block.call(init, x), xs, &block)
	else
	raise ArgumentError.new("Array is expected but #{list.inspect} is given")
	end
	end