コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Kaigi on Rails 2024 で 「入門『状態』」という内容で登壇してきました。

登壇

Kaigi on Rails 2024 で登壇してきました。

発表したスライド

speakerdeck.com

伝えたかったこと

テーマとしては大きく2つありました。

  • 状態は極力持たないほうがいい、もたせるなら最小限かつ管理したいものを明確にする。
  • 変数の再代入というのは変数に状態変化を生んでしまう。そのため可能であればしないようにする。

補遺編

今回のプロポーザルの動機

今回の起源としては「変数への再代入はやめよう」が一番最初にありました。そのためプロトタイプ的な記事は以下になります。

変数代入を複数回行うと何が良くないのか、どうするといいのか - コード日進月歩

特にRailsではControllerのインスタンス変数設定に関しては改修を繰り返すと再代入をするコードの登場が増えがちです。そのためその「再代入の何が悪いのか」というところを突き詰めて行くと変数の状態に関して移り変わるところの弱みについて説明をしないと納得感を持ってもらえないので、そのあたりに焦点を当てる話をしました。

今回の発表で苦心したところ

どうしても「変数の中身が何度も切り替わると何が悪いのか」ということを出発点にしているので、状態という話のブレイクダウンと合わせて話の作り方はだいぶ苦心しました。

また、つらみが軽減されていく様をわかってもらうには実コードで体感してもらう他ないかなと思ったので結局以下のような感想の資料に落ち着いたのでした。

盛り込めなかったもの

当初は状態を扱う上でのつらさを一通り話したあとに、状態のいなしかたで色々紹介するところまでいきたかったのですがかなり削りました。以下が削ったようなトピックです。

  • オブジェクト生成を純粋関数化して、状態を決定づけるものを引数化する
  • 完全コンストラクタ化し、オブジェクトそのものを変化させない
  • どうしても状態を持つ必要がある場合のステートマシン（状態遷移図）
  • 発展話題としてのFluxやReduxの状態遷移の考え方

案外に状態を語っている資料は少ない

自分自身、歴史的なところを抑えつつ資料に盛り込むスタイルをよくやるので今回もそれをやろうとしてみたのですが、わかりやすく変数と状態に語っているものが少なく、オブジェクト指向の文脈ではいくつかあったのですが織り交ぜるとややこしくなりそうなのであまり深くは掘ることをやめました。その結果としてかなり自分の経験色が強めの話として整理されました。

地続きの話としての過去スライド

いままでの登壇につながるものがあるなというのを２つ感じました。まず1つは去年、脳プログラマーに感銘を覚えてLTをしたのですが、結局状態を増やしすぎないとというところは脳の効率化にもつながるなと感じたところがひとつ。もうひとつはbefore_actionでインスタンス変数セットしていると再代入が乱発するので、before_actionの使いかたを再考すると状態を減らす方向に行くなと感じました。

なお、過去の話は以下リンク参照のこと

今回の発表タイトルのインスパイア元

今回のタイトル、実は5年前に見たスライドが元ネタとなっております。

https://speakerdeck.com/fujimura/ru-men-ming-qian

登壇後記

  • もともとは「純粋関数」を主題において話すといいのではと思っていたのですが、このあたりを社内で話したところ別の切り口の示唆を得たのでありがたかったです。
  • 苦心したところのパートでもあるんですが、資料の構成は何度か見直したりしました。そのためChatGPTに色々投げたりしてやっていたのですが、肯定的な返ししかしてくれなかったので資料が迷走する瞬間などがありました。
    • ただブレスト相手としては優秀だったので、うまく活用していきたいと思いました。
  • 健康的な生活を送ることに重きをおいていたので、前日に徹夜…などはなかったのですが、かなりギリギリまで表現の調整などはしていました。もう少しこのあたりうまくできるように練度を上げたいですね…
  • 今回もいままでどうように初学者向けトピックを扱っていたので手応えとしてはなかったのですが、感想ブログなどを見ると取り上げてくださっている方がいるのでいくらかは届けた意味があったようでした。書いている皆様全員に感謝。

RailsでRESTらしい設計とは何かということに迷ったときに見たいスライド『Simplicity on Rails -- RDB, REST and Ruby』

スライド・記事回顧録

モノ主体のDB設計やURL設計になりがちなので、そのあたりに関して見直したいときのためのメモ

資料スライド

speakerdeck.com

動画は以下

Simplicity on Rails - RDB, REST and Ruby by MOROHASHI Kyosuke - Kaigi on Rails 2023

みどころ

Railsを書いていると、一般的に語られるRESTの考え方とマッチしないのではないか、と感じる瞬間が起こります。特にWebAPIとして外部に使われるようなものを作るときには顕著で、ActiveRecordに準拠したリソースでURLを切っていくと「なんだか細かくなってしまって使いにくいな」というようなことが起きたりします。そのようなときの指針となるのがこの資料です。

ありがちな「モノ」主体の設計になりがちな部分に関して、「コト」の内容を見出すというところに関してRailsらしいアプローチが紹介されているので、何か複雑になりかけたときは見直したい資料でした。

関連リンク

簡単なCSVのデータの重複削除であればスプレッドシートで簡単にできる

Tips

知らなかったのでメモがてら

公式ヘルプ

テキストの分割、重複の削除、空白の削除 - パソコン - Google ドキュメント エディタ ヘルプ

やり方

  • CSVをスプレッドシートで開く
  • 範囲を選択して、メニューの「データ」 から表示される中のデータクリーンアップ>重複を削除の順に選択する。

わかりにくいので雑なアニメgifで説明すると以下の通り。

実際にスプレッドシート上で作業する例

関連リンク

Rubyはif文を使って代入する値を分岐した記述ができる

Ruby

再代入を回避させ、1回の記述で代入をさせるための記述を整理として

環境

検証したバージョン

$ ruby -v
ruby 3.0.5p211 (2022-11-24 revision ba5cf0f7c5) [arm64-darwin22]

リファレンスマニュアルより

if 式は、条件が成立した節(あるいは else 節)の最後に評価した式の結果を返します。else 節がなくいずれの条件も成り立たなければ nil を返します。 - 制御構造 (Ruby 3.3 リファレンスマニュアル)

と記載されているので以下のように記述ができる。

gender = if is_male then "male" else "female" end
pp gender
# "male"

また、ドキュメントの記載どおり、いずれにも合致しないとnilになる。

is_male = false
is_famale = false
gender = if is_male == "male" then "male" elsif is_famale then  "female" end
pp gender
# nil

改行も可能

下記のような記述も可能。下記の場合は then を省略して記述している。

is_on = true
message = if is_on
            "スイッチオンです"
          else
            "スイッチオフです"
          end
pp message
# "スイッチオンです"

関連リンク

定期的に自身の動き方のために見直したいスライド『仕事を前に進めるためのコツ - 判断と決断と共有』

スライド・記事回顧録

かなりしみたのでメモとして

資料スライド

speakerdeck.com

みどころ

問題を解くためにはという話をうまく仕事での物事の話に当て込まれてかかれており、綺麗に言語化されている。自分自身がやれている部分、やれていない部分の点検のチェックリストとしても使えるので、時折々で見返すと良さそうな資料でした。

関連リンク

JSONと名のつく仕様に関して、観測できる範疇でざっくり表にしてみる

ざっくりまとめ

種類がいくつかあるので書き出してみる。

ざっくりまとめ

大きくは

  • JSONに仕様を機能拡張したもの (json5,jsonc)
  • JSONのオブジェクトを1行単位で処理できるようにしたい仕様追加(jsonl,ndjson)
  • JSONをつかって違うことを表現するための仕様(json-ld,geojson)

というようなカテゴライズになる。

名前 どういうものか 仕様など 拡張子の例
json 基本となるJSONの仕様。 RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format .json
json5 JSONから拡張されたもの。 JSON5 – JSON for Humans | JSON5 .json5
jsonc(JSON with Comments) JSONからコメントをかけるようにしたもの。VSCode用のものが主流と思われる。 GitHub - microsoft/node-jsonc-parser: Scanner and parser for JSON with comments. (明確な拡張子の記載がない)
jsonl(JSON Lines) 1行1オブジェクトで構成されるJSON JSON Lines .jsonl
ndjson jsonlの派生、オブジェクトを1行で書きたい。 GitHub - ndjson/ndjson-spec: Specification .ndjson.
json-ld(JSON for Linking Data) Linked dataをJSON形式で記述するための仕様 JSON-LD - JSON for Linking Data .jsonld
GeoJSON 地理データ（GISデータ）をJSONで表現するためのフォーマット RFC 7946 - The GeoJSON Format ,json , .geojson

関連サイト

イベントストーミングに関してざっくりまとめる

ざっくりまとめ

とりあえず王道の流れをさまざまな資料からざっくりまとめる

原典

EventStorming

起源

2013年頃にAlberto Brandolini氏が下記ブログで提唱した考え方

Ziobrando's Lair: Introducing Event Storming

概要

付箋の色ごとに意味を持たせて張り出して、業務に詳しい人（いわゆるドメインエキスパート）とコミュニケーションしながら情報を整理するワークショップ形式の手法。 付箋の色と意味は以下の通り。

付箋の意味とリスト

ざっくりとしたやり方

主に以下の3ステップで作業を行う。

STEP1. ドメインイベントの収集（BigPicture) STEP2. プロセスモデリング STEP3. ソフトウェアモデリング

STEP1. ドメインイベントの収集

DomainEventの付箋（オレンジ色）を業務に詳しい人と貼っていく。イベントが発生する順序に貼っていきイベントの流れを貼り出していくプロセス。すべて貼り出したら書いている内容に関して時系列が正しいか、それぞれの付箋内の言葉に揺れがないかなどを見て整理していく。

STEP2. プロセスモデリング

イベントがどこ起因で発生するのかを整理していく。ユーザが起因となるもの（Commandとそこに関連数ActorとView）、外部システム、時間軸で発生するようなもの（Policy）、別のDomainEventなどを貼り出して起因となる要素を洗い出す。

STEP3. ソフトウェアモデリング

最後にDomainEventをグルーピングしてコンテキストを整理します。これによりDomainEventがどのような塊にって、どのような境界があるのかが明らかする。これでDomainEventをどの粒度で扱うべきか、どのようなイベントが全体的に起きるのかが可視化されお互いの共通認識を得ることができるようになる。

参考リンク