sunaot

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

設営資材

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

ノベルティ

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

sunaot

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

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

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

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

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

sunaot

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

sunaot

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

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

の順で説明をしていく。

sunaot

# 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)

sunaot

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')