| 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 |
名前は使われる場面で使い方を指示したり制約したりするような意味合いを名前で表現できるとよい名前になります。
表現しているクラスだったり変数の実装を見ながらつけると名前をつけるもの自体を中心においてそれを説明する名前になります。良い名前にしたいなら、そのオブジェクトやメソッド、変数が使われる場面で、どのように使うと読みやすいか、ミスしやすい部分をミスしないように導けるかを気にしながら、使う人へメッセージとなるような名前をつけます。
これを実装ではなく意図に名前をつけると呼んでいます。CODE COMPLETE 上巻の 11.1.2 に『問題指向の名前』という半ページくらいの文章があり、 How でなく What に名前をつけるという主旨のことが書いてあるのが元ネタ (の一つ) です[^1]。
意図 というすばらしい語彙は Kent Beck が Smalltalk Best Practice Patterns というこれまたすばらしい本に Intention Revealing Names という話を書いているということを以前一緒に働いた Java エンジニアに教えてもらって以来、気に入って大事に使っています[^2]。
何が起こっているのでしょうか？ それはコミュニケーションです。最も重要なのは、一行だけのメソッドでも、意図を伝えるために存在する価値があるということです。
@threetreeslight にスポンサーブースってどんなかんじで出してます？って聞かれたのでスポンサーブース出展のノウハウを書いてみた。 ブースが強い会社は一人ノウハウを持った状態で転職した人がいてこなれたかんじでやっているという印象。
パネルとテーブルクロスとバナースタンドはつくりました。遠くから見たときに存在に気付いてもらえるように。
前回の RubyKaigi ではどら焼きつくって持っていきました。7社くらいとかぶりました。知合いスポンサー間で事前にすり合わせておけばよかった...
(実施告知の文章から抜粋)
ええと、みなさんAWS移行の準備も大詰めでリハですね。リハーサルってなぜやるかわかってる人もわかっていない人もいると思うので書いておきます。結論を先に書くと、本番当日もそのまま手順を踏襲するとそれで移行が終わる詳細な手順が書かれた移行手順書を書いてリハをしてください。リハの中で手順どおりには行かなかったところはその時にすべて手順書に反映して、本番のときは手順どおりでやれるようにしてください。
本番一発勝負というのは難しいもので、人間どんなに考えていても失敗します。でも失敗を糧に二度目をすると一度目にやった失敗は回避できます (できるようにします)。システム開発というのは一般的に大体予測不能なところで失敗するものなので、一度本番同様に動かしてみるというのが非常に重要になってます (アジャイルが繰り返し開発するのも動くソフトウェアを信じるからですね)。
性質として事実上そういうものなのですが、私達の気持ちとしては当然失敗はしたくありません。そこで、失敗をするはずの一度目としてリハーサルという疑似本番をやるわけです。そうすることで、失敗の予行演習ができます。本番に向けて失敗の予防ができます。ここを人手でやると再現性が落ちるのでベストは自動化され、何度やっても繰り返し同じことが実現できる状態です。でも、それはしやすいものとむずかしいものもあるので人間がそのとおりに実行をしたら同じ結果になるという手順書というのが大事になってきます。
どこの層まで Thor であることを意識させるかというのはポイントになりそうな気がします。 database は Thor 以外からはけして呼ばれないでしょうか？ たとえば、Web インターフェイスをかぶせた場合。bot を呼出し元として使い始めた場合。 実際にそれらを作り始めて不都合が出てから変えてもいいのですが、今の時点で
+--------------+ +-----------+
| dispatcher | | view |
+--------------+ +-----------+
+----------------------------+