今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は322回だった。その後にショートサーブ30回、フットワーク10分の練習をした。リフティングは連続回数よりもラケットコントロールの質を求める練習に変えていく。昨日と同様、みなとのもり公園をジョギングで4週走った。fitbit によると 1.8km 走ったそうな。
プロジェクトマネージャーが手を動かすことの功罪
朝からお手伝い先の社内インフラサーバーが落ちていて待ち時間があったのでふと思い返してつらつら考えごとをしていた。
お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する
私はもっと仕組みを作るところに注力すべきだった。私自身がコンサル嫌いの、実務をやっている姿勢をみせてメンバーが参考にしてほしいという意識が強過ぎた。また開発は楽しいことから必要以上に手を動かし過ぎてコアな開発に入り過ぎたことで、自分がやらないと他のメンバーが担当しにくい体制になってしまった。「任せる」はずが「任される」ことになってしまった。バックエンドの品質は大事だから責任感もあった。もしかしたらお客さんが求める以上の過剰品質なモノづくりをしてしまったのかもしれない。そして、仕組みづくりの後はメンバーへ委譲すべきだった。いまメンバーへマネージャーを委譲しているが、マネージャーという業務はもともと得意でもなくこだわりもなかったがためにすんなりと委譲できた。
しかし、開発の方は得意分野、且つ好きであるために品質にこだわってしまう傾向があることを認識できた。そのことが裏目に出てしまった。これが自社プロダクトの開発ならばすべて自社の資産になるためにそれでもよかったかもしれないが、他社プロダクトでやってしまうと、自分の時間を必要以上に注ぎ込むことになってしまった。その結果、お客さんの信頼を得られてはいるものの、自社プロダクトの開発に着手できず、クロージングの時期が遅れて微妙な状況になってしまった。もしかしたら、お客さんもうちの会社との契約を終了できなくなってしまって困っているという考え方もできる。
rabbitmq の autoAck (noAck) の振る舞い
先週の続き 。id 連携のリクエストをし続けながら compose サービスを down させたときの振る舞いを検証する。理想的にはそれぞれのモジュールのサービスが graceful に振る舞って、それぞれの永続化する場所でデータが溜まってくれることを期待している。その1つがメッセージキューでもある。Persistence Configuration によると、rabbitmq のメッセージを永続化するには queue に対して durable の設定を行い、producer が送信するメッセージに対しても persistent の属性を付与すればよい。しかし、実際に検証してみると、サービスの再起動時にメッセージキューからメッセージが消失していることがわかった。consume メソッドに渡す仮引数に autoAck というパラメーターがある。コメントにもそれっぽいことが書いてある。
When autoAck (also known as noAck) is true, the server will acknowledge deliveries to this consumer prior to writing the delivery to the network. When autoAck is true, the consumer should not call Delivery.Ack. Automatically acknowledging deliveries means that some deliveries may get lost if the consumer is unable to process them after the server delivers them. See http://www.rabbitmq.com/confirms.html for more details.
autoAck という名前からメッセージを取得したら自動的にそのメッセージに対して ack を返すようなイメージで私は考えていた。しかし、どうやら consumer が subscribe して接続した時点で consume 扱いとなり、consumer がメッセージを実際に取得したかどうかに関係なく consumer の終了時にそのときに溜まっているすべてのメッセージが消失しているようにみえる。余談だが、rabbitmq のドキュメントにも noAck と autoAck という2つの用語が存在する。どうやらもともと noAck という名前だったのを autoAck という用語に変更したようにみえる。メッセージを永続化するには autoAck=false にしてメッセージに対する処理を完了した後に consumer が必ず ack を返すという実装にしないといけないことがわかった。このパラメーターは2年前から同じ設定だったので私がいま検証するまで誰もこの振る舞いに気付かなかったんやと驚いた。
部屋の掃除
19時に閉まる業務スーパーへ買いものへ行くために18時過ぎにお仕事を終えて、移動して買いものをして、炊飯開始して、ジョギングして、戻って晩ごはんを食べて、バドミントン練習をして、お風呂に入って、ストレッチして、なんとなくベッドに入って休もうとした。ここで22時半ぐらい。まったく眠れなくて寝室の掃除を始めたら、これが捗ってやる気が出てきて、部屋のレイアウト変更したりして少し片付けもできた。引っ越してからまったく進めていなかった部屋づくりが突発的に急に少しできた。これまでも時間がなかったわけではないが、まったくやる気がなくて手をつけられていなかった。それがなぜできたのかはわからないが、手をつけられていなかったことに手を入れられたことで心理的に楽になった気がした。明日も帰ったら少しだけ部屋づくりの作業をしようと思う。
