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

レビューコメントから

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

Clean Code より。

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

sunaot

今後何度も書くことになるだろうから repo へコミットする .gitignore の使い方について書いておく。まあ、ゆるーく使って余分に ignore 書きまくってもいいんですが覚えておくと、はかどります。なお、man に書いているというつっこみを受けた。

以下の方針で運用すると扱いやすくなります。

• プロジェクトで使う .gitignore ファイルへはプロジェクト固有でバージョン管理から外したいものを書く
  • 例： そのプロジェクトでできる中間成果物、スナップショットで残したいだけでバージョン管理する必要のない成果物 (テスト結果とか) など
• プロジェクト固有ではなく発生し、バージョン管理から外したいものはグローバルな gitignore ファイルへ書いておく
  • ~/.config/git/ignore
  • 例： OS が勝手につくるファイルやフォルダ、エディタの作るバックアップファイルなど
  • 自分で育てなくてもグローバルな gitignore のための雛形があるので自分が関わるものを追記していけば OK.

sunaot

話しをしたいポイントは３つ。

• 条件分岐を避けましょう
• 一時変数の使い方に注意しましょう
• 状態の使い方に気を使いましょう

これを徹底することで、バグの入り込む余地を最小限に保つプログラミングをしましょう。

条件分岐を避けましょう

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

条件分岐とのつきあい方

プログラムが複雑になる一番の理由は条件分岐 (if 文など) です。

条件分岐がなければ、一本道で読み下していけばいいのでバグが入り込む余地は大変少なくなります。

ということで、

• 条件分岐を書かなくていいように書く
• 条件分岐を書くなら、わかりやすく局所化して書く

sunaot

Ruby のコードを読んでいると

class Hoge
  class << self
    def hello
      puts 'hello'
    end
  end
end

sunaot

SQL 講座

SQL

• SELECT 句
• FROM 句
• WHERE 句
• GROUP BY 句
• HAVING 句
• WINDOW 句

sunaot

Subversion を Git へ移行したい (そして共有方法として GitHub を使いたい) 場合に考える観点をあげてみます。

人

• チームに Git にくわしい人がいるか？　いない場合、聞く先があるか？
  • チャットに git ルームをつくるなど
• 習熟度に不安があったら、やってはいけないことリストとこうすべきリストの整備が初期の混乱を防ぎます
  • force push 禁止
• ブランチはリモート追跡ブランチからきる

sunaot

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

心得

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

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

大切なこと