すがブロ

sugamasaoのhatenablogだよ

DRY原則とDRYさせない方法

SmartHR Advent Calendar 2024 シリーズ1 の3日目です。

前日はalpaca-tcさんのRailsで任意のキャッシュストアを移行する - alpaca-tcでした。

さて、12月ですね。皆さん乾燥していますか？私は冬場の寒さに耐えられずエアコンを使いまくってしまうので当然のように乾燥しまくっています。

少し前まで空気清浄機兼加湿器を使っていたのですが、タンクの形状が複雑で汚れがちだったり加湿が十分なのかわからん、という状態でした。

そんなわけで2023年に象印のいわゆる魔法瓶的な加湿器を買って利用するようになったのですが、かなり潤ってる感じがしていて、なんなら加湿器に近い部分の布団は若干湿ってるような勢いなので乾燥対策はできていると考えて良さそう。

ちなみに、買った機種はこれです。 www.zojirushi.co.jp

給水のためには本体ごと持って行かないといけないので少々重かったり、デカいので風呂場でシャワーヘッドを使って給水することになっていますが、部品を外す手間などもないので楽と言えば楽です。シンプルな分取り扱いしやすいしオススメです。

これがDRYさせない方法ってｺﾄ!? ーーそうだよ！

というわけで閑話休題

DRY原則

良くも悪くもDRY原則、よく聞きますよね。「DRYにする」といって同じ仕様ではなく同じコードをまとめちゃってPRでやり取りをする、なんていうのは一生に一度は経験しているものかもしれません。

でも待ってください。そもそも、ぼくらはDRY原則について何を知っているのでしょうか？よく言及される原則ではありますし、大筋はわかると思うのですが原典ではどのように書かれていたのでしょう？

我々は原典を探すため、Amazonの奥地へと向かった

DRY原則の原典

Wikipediaによると、達人プログラマーが出典と書いてあります。

www.ohmsha.co.jp

おお、俺たちの達人プログラマーが原典だったのか。大昔に読んだ気がするけど全く覚えていない。

改めて読んでみても良いかもしれない……と考えたところで思い当たったのですが、達人プログラマーは初版と第二版が出版されています。

初版と、およそ20年の歳月を経て出版された第二版で内容を見比べてみると、当時と現代で気をつけているポイントが異なるかもしれないし、この二つを見比べてみると面白いかもしれない。

というわけで見比べてみました、というのが本エントリーの趣旨です*1。

DRY原則に関する初版と第二版の違い

まず、目次のタイトルからして違います。なんと初版ではDRY原則という名前がついてない（本文中に出てくる）。

初版 第二版
1章 7 二重化の過ち 1章 9 DRY原則 - 二重化の過ち

この時点で、20年の時を経てDRY原則が概念として確立した気配を感じますね。

ではもう少し見てみましょう。

流石に本文を丸々載せるわけにはいかないので、ざっと見出しを抜き出してみます。

初版

  • どのように二重化が発生するのか？
  • やむを得ない二重化
  • 不慮の二重化
  • 手抜きによる二重化
  • 開発者間の二重化

第二版

  • DRY原則はコード以外にも適用される
  • コードの二重化
  • コードの二重化すべてが知識の二重化というわけではない
  • ドキュメントに二重化
  • データにおけるDRY原則の違反
  • 表面上の二重化
  • 内部APIの間での二重化
  • 外部APIの間での二重化
  • データソースの二重化
  • 開発者間の二重化

比べてみて

シンプルな話ですが、第二版になって分量が増えています。それはなぜかというと、第二版にこのような記述があるのです。

「まず最初に述べておきたいことがあります。本書の初版では、「 DRY原則」が意味することについて書き足りない部分がありました。多くの人々はこれがコードの話だと受け取ってしまったのです。つまり、 DRYを「ソースコードのコピー＆ペーストをしてはいけない」と解釈してしまったのです。これも DRY原則の一部ですが、ほんの些細な一部でしかありません。 DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異なった場所（おそらくはまったく異なった場所）に同じことを表現するという問題を避けるための原則です。」

—『達人プログラマー ―熟達に向けたあなたの旅― 第2版』David Thomas, Andrew Hunt著 https://a.co/bGDC7rE

こうして見ると、当時の後悔だったのかそれ以降の時勢を読み取ったのかは分かりませんが、第二版で丁寧な解説になっているように見えます。 ソースコードの例も増えていて、わりとイメージつきやすくなっている印象もあります。

ただ、「データソースの二重化」に関しては趣旨はわかるけれども、あまり自分の好みじゃないかもしれねえ……。

それはさておき、第二版では「DRY原則」が指していることが詳細化され、言いたいことが誤解なく伝わるような構成になっていることと合わせて、内部APIや外部APIなどに言及されている点は現代っぽいなと感じました（とはいえ、API関連の話はそこまで記述が厚くなくて無念）。他にも、コミュニケーション面での話ではデイリースクラムやslackが例として挙げられるなど、本当にモダナイズされています。

詳しくは本書を買って君の目で確かめてくれ！という話なんですが、改めて読んでみた感想としては初版・第二版それぞれ良さがあるものの、DRY原則については「プログラマが知るべき97のこと」のDRY原則のエッセイを見るでも十分かもしれませんね……。

xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

それはそれとして、改めて達人プログラマーに目を通してみて再確認したのですが、ぼくは達人プログラマーの「まえがき」と「第一章」が好きすぎるかもしれない。自分のプログラマーとしての考え方の原型はここにあるなと再確認しました*2。 特に「まえがき」で書かれている "「単なる石を切り出すのが我々の仕事であったとしても、常に心に聖堂を思い描かなければならない」" が本当に好きすぎるんですよね

あなたの石切工はどこから？と聞かれたら「達人プログラマー！」と答えるくらい好きなので……

最終的にDRY原則というよりは達人プログラマー好きすぎるという話なんですが、読んでない人はみんな読んで！！！！１

www.ohmsha.co.jp

*1:偶然にも、初版と第二版を所持していた

*2:正確には、この本と「My Job Went To India」で作られたと言っても過言ではない

Kaigi on Rails 2024への参加とプロポーザルを出した結果得られたもの

1ヶ月経ってしまいましたが、ようやっとこの文章を書いています

Kaigi on Rails 2024、大変楽しめましたし普段会わないRubyistな皆さんとも交流できてとても楽しめました

Kaigi on Rails 2024

ちなみに、これは会場へのルート選択を誤ってビッグサイトに着いてしまった事例です

Kaigi on Rails で得たソフトウェアとの向き合い方

自分がそういうトークを見にいったから、ということもありますが……

以下のトークを見て、改めて感じたのはソフトウェア開発をどこまで深いレベルに潜って設計・開発できるかだな〜〜〜と思いました。表層的に解決しようとすると痛い目を見るのは経験しているものの、それを高いレベルで解決するためには練度が必要

Railsの思想やRailsが提供しているものを理解して上手に使おうというものがベースにありつつも、モデリングやRailsの拡張を通じて、どう破綻しないように事業成長を止めることなくソフトウェア開発を続けられるか。質とスピードの両方を維持していけるか、というのはやはりWebアプリケーションエンジニアとしての腕の見せ所だし、そこを深く考えられる人は尊敬してしまいますね……

speakerdeck.com speakerdeck.com speakerdeck.com

今回はプロポーザルを出した

それはそれとして、今回はKaigi on Railsにプロポーザルを出しました。事の成り行きは↓の同僚氏が書いたブログを見ていただくとして

はじめてのKaigi on Rails 2024 ── 初プロポーザルから登壇までの道のり - SmartHR Tech Blog

自身でプロポーザルを出したのは（たぶん）人生で2回目。今のところプロポーザル→登壇という流れは経験したことがないのでいつかは達成したいものですね

今回は「良いコードの書き方」的なかなり抽象度の高いテーマで応募したため、「それRailsと関係あるんか」という問いに対して芯を食った打ち返しができなくて落選したのかなと思っています

テーマ的にそれはそう、という話ではあるものの見せ方、伝え方次第であろうとも思っていて、もっとRailsでこういうコードあるよね！という文脈をセットで書ければもうちょっと良い線行けたんじゃないかとも想像しており、「この場（Kaigi on Rails）で、あなたが話すべき理由は何ですか？」という観点をもっと強くプロポーザルに乗せられるようにすべきだったなと反省しています

とはいえ、プロポーザルを出すということで自身がボンヤリ考えていたことを体系的に伝えるにはどうしたら良いか？など考えるきっかけにもなったし、プロポーザルを出す際の観点も（結果から考えれば当たり前の話ではあるけれど）しっかり受け止められたので良かったなと思います。

ちなみに、登壇できた暁にはJoel Spolsky氏の「間違ったコードは間違って見えるようにする」をフックにして話す予定でした。コード自体というよりはコメントなども含めた少し幅広いテーマではありますが 😆 （プロポーザル提出前の仮タイトルは「令和最新 間違ったコードは間違って見えるようにする」でした）

間違ったコードは間違って見えるようにする - The Joel on Software Translation Project

Kaigi on Railsの企画・運営していただいたスタッフの皆さんや登壇者、スポンサーなど関わった全ての皆さんのおかげで楽しく過ごせました。ありがと〜〜〜〜！

知識の探求と喜び #RubyKaigi 2024

（タイトルはAIに考えてもらいました。確かにそうだな！？と思ったので採用しました）

rubykaigi.org

沖縄開催

元来出不精でとにかく家に居たいパーソンなのですが、なんとか一念発起して沖縄に行くことにしました

そして、せっかく行くのであればある程度観光も、ということで妻と一緒に前乗りして5/11-5/13は家族旅行、5/14-5/18(day0からday3の翌日まで)はRubyKaigiというスケジュールにしました

RubyKaigi - はじまりはじまり

ここ数年は会社のお金で参加させていただいており、今年はドリンクアップスポンサー

SmartHR Drink Up at RubyKaigi 2024 Day2 (5/16) - connpass

をやったり貢献できる幅が増えてきているのは嬉しいです

これは単なる社内事情ですが、DevRelの立ち上げを起点として社内でのスポンサー時の体制がしっかりしたものになってきて、社内でのモチベーションや熱量がうまく企画に昇華させられたことにより事前勉強会・事後勉強会・ドリンクアップの実施などいい感じに企画・運営ができていて組織力の高まりを感じます

day0 - すでに疲労

前乗りの旅行ですでに疲弊していたので、day2に行われるドリンクアップの下見で少し飲んで終了

沖縄の台所ぱいかじ｜国際通り店

ちなみに、「ぱいかじ」とは「南風」を沖縄の方言で読む言葉だそうです。勉強になりますね

day1 - 初手からわからん

Writing Weird Code

PEN sanのキーノートは本当に「わけわからない（褒め言葉です）」を無限に浴びせてくるのですがその中で他のセッションを紹介していく流れが美しすぎて本当に練度の高いトークでした。TRICKとか全くできる気はしないものの、だんだん興味が湧いてきました……

The grand strategy of Ruby Parser

実質parserのキーノートだなと思いました。parser.yについては過去のRubyKaigiなどを通じてなんとなく知っているものの、取り巻く環境などはまったくわかっていなかったので、関連技術要素がマッピングされて説明されてFF3の飛空艇を手に入れてからのような感覚*1*2を得ました

それはそれとして話しているkaneko sanがとても楽しそうだったのが印象的です

Namespace, What and Why

Namespace、ぜんぜん実現できるイメージが湧いてなかったのですが本当に動いてる……!!という感動がありました

Namespaceで解決する話ではないような気もするけどRubyでは require したタイミングでrequire先の定数などがグローバルに展開されてしまうのは制御できるオプションがあると嬉しいなあというのはずっと思っています

Ruby 3.1から load の第二引数にモジュールを渡せるようになったやつがrequire でもできたり事前にモジュールを定義するのではなく何らかのシンタックスシュガーでシュッとかけると嬉しいと言いますか……

update: ↑で書いた内容はMatzの話していたpackageに相当するとのことです

夜の部

夜はRubyKaigi 2024 Official Partyへ行き、BBQを楽しみながら本当にさまざまなお久しぶりの人と話せてよかった。お互いの近況であるとか、若者にドリームキャストってなんですか？と聞かれるなど時間を感じる一日でしたね😌

day2 - 話を聞くと興奮してくる

Leveraging Falcon and Rails for Real-Time Interactivity

リアルタイム通信（というのか？）の歴史とFalconでFlappy Birdを作るデモ

サーバーサイドで計算して、その結果を描画しているんだと思うけどあんなに滑らかに動かせるものなんだなあ、というのとああいうインタラクティブな操作とかは昔にFlashでやっていたのを思い起こされる

Embedding it into Ruby code

soutaro sanのRBSをコメントに埋め込めるようにする話。現在のIDEやGitHubなどの状況だとやはりrbsファイルが別にある状態でのメンテナンスが難しいのはそうなので、コメントに埋め込むというのは良さそう〜〜〜〜と思いました

Reducing Implicit Allocations During Method Calling

メソッド呼び出し時に余計なオブジェクトを生成しないようにしていく話。メモリのアロケート状況を見ながらチューニングしていく流れは参考（何のだろう）になりました

このセッションを見ていなかった同僚に話たところ、研鑽Rubyに書いてある内容が近いっぽいですね。研鑽Rubyを積読しているのがバレてしまった……

Good first issues of TypeProf

毎年、TypeProfのトークは楽しみにしているのですが、今年はコントリビュートしやすくするためのチュートリアル的な話でした

TypeProfは毎年「期待しています！」という気持ちを持っているのですが、今回のトークで「1人で開発してるの大変ス」という話を聞いて自分も何らかのお手伝いができれば、、という気持ちになっています（なっているだけじゃダメなの手を動かしましょう）

夜の部

day 2は会社のドリンクアップ準備のためLTの途中で抜けて事前準備へ

ドリンクアップでは入口の案内パーソンとして階段を上がったところでお出迎えする役をやりました。来場していただいたみなさん本当にありがとうございます

ドリンクアップ後は適当なお店で会社の人と飲みつつ、@kwappa san / @tagomoris san / @tompng san / @gachacomplete san へ近況やトークの感想などお伝えできてよかったです。ガチャピン先生はmalloc動画のころからのファンだったのでちゃんとお話できたのがめちゃくちゃ嬉しかったです😌

沖縄の締めはステーキ、と聞いていたので一日の最後にステーキを食べに行ったのも良い経験でした。さすがに40歳過ぎ & 24時過ぎにステーキを食べるのはためらいがあったのですが、赤身のステーキだと意外とシュッと行けて新しい概念を獲得してしまいました……

day3 - 来年のRubyKaigiも楽しみすぎる

前日、IVRy社さんからもらった酒豪伝説を飲んでいたおかげか、わりと元気に起床。酒豪伝説しゅごい……

Ruby Committers and the World

例年、英語でのフリートークになると20%くらいしか理解できなくて「楽しいけどわからね〜〜」という感じになりがちだったのですが、今年はトークテーマなどをいい感じに整理してもらえたおかげかだいぶ理解できた気がします。コミッター陣の中でも意見が分かれたりしていたのは側から聞いていて面白かったです

soutaro sanがコメントに記載するRBSの記法について来場者に聞いていて、自分が手を挙げたほうがめちゃ少数派だったりして「うおお」となったりしました

これはコメントに記載する云々という話ではないと思うんですが、型によるサポートが強くなればなるほど、class（あるいはDataなど）でのオブジェクトの定義が重要になってくるかなあと思ったりしています。例えば Integer であるだけではなく、「1〜10までのIntegerである」などが表現できて型情報で事前条件（と表現するのが正しいかわからないけど）が明示できるようになると嬉しい……。というかこれは単にunionで型を定義したいという話な気がしてきました。忘れてください……（？）

Speeding up Instance Variables with Red-Black Trees

ちょっと事情があってトークに遅れてしまったのですが、赤黒木の説明をしつつそれをRubyで活用している実例に展開する流れはめちゃくちゃ面白かったです。Object Shapes、毎年話を聞いていてちょっとずつわかり具合が高くなっている気がします

ERB, ancient and future

関さんファンなので今年も聴きました。ERBの話を聞いていて「これはCGI!!」と興奮していたら「CGIだよ」という展開になって楽しかったです

自分が本当に文字通り駆け出しエンジニアだった頃は print であらゆるものを出力していたものですが、その時代にERBのアーキテクチャを検討できたのって本当にすごいなあ。今見ると「それはそう」となるかもしれないですが……

Matz Keynote

Ruby2（2.0ではない）の構想と現在実現されている機能の話や、Namespaceが入ってRuby2時代の構想が一通り実装できたらRuby 4にしようかなという内容

Namespaceの仕様などはこれからより詰めていく段階だと思いますが、めちゃくちゃ夢のある話でよかった。毎年、RubyKaigiでMatzの話を聞くと未来に対してワクワクさせられてすごいなあと思います（小並感）

夜の部

RubyKaigiの最後はmov社さんのAfter Partyへ

@kamipo sanと人生について話したり、@masaya_dev san と久しぶりにお話したり、LeSS について話したりといろいろな話をできて満足です。会場の導線などオペレーションがしっかりしていてとても過ごしやすい空間でした

day4 - また来年

飛行機の搭乗時間まで時間があったので、うわさの千日でぜんざいを食べたり、波の上ビーチで海を感じたりして解散

もはや方々で言われているので言語化されつつある話ではありますが、RubyKaigiって「明日使える便利テクニックを得ました！」とかではなく「なるほどわからん」を積み重ねて各トークの関連やRubyという言語のアレコレ*3を知っていくことで繋がりが生まれてくる快感や高揚がすごいんですよね（(自分の性格として"物事を知る"ということが好きっぽい)）。そしてまたわからないことが増えていく。無限か？

さらにさらに、それを作っている・トークしていた人が目の前にいる、なんなら隣で酒を飲んでる的なことが普通に発生する。

この"良さ"を未経験の人に伝えるのは難しいのですが、私は今年もRubyKaigiを十二分に楽しめました！RubyKaigiのSpeakerのみなさん、RubyKaigiスタッフのみなさん、スポンサーブースの皆さん、お久しぶりに/はじめましてでお話できたみなさん、あらゆる人のお陰で今年も素晴らしい体験をすることができました！

また来年、松山で会いましょう〜〜〜☺️

*1:例えが古い

*2:今なら暗黒大陸と言ったほうが良いですか？？？

*3:パーサーの概念とかメモリの考え方を押さえておいて他の言語を触るとより特色が理解しやすくなってとてもお得なんですよね。それを日本語で聞けちゃうの便利すぎるね

認知負荷の種類と対策と組織文化について

このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。

これは何

当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。

ツールの関係性については↓のエントリをご覧ください

Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ

閑話休題

認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、「認知負荷」という言葉をふわふわな認識のまま「なんか大変」という言葉の言い換えにしておくのはせっかくの気づきをフワッとさせたままになってしまうので、正しく概念を理解して、立ち向かえる単位に分割できるとより成果に繋げられると思いませんか？思いますよね。思ってください。

さて、そんな話題については 【増枠！】Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 - connpass というイベントで登壇してお話しさせていただきました。

一方で、タイトルがへちょすぎて内容が想像できないという意見も想像に難くないためこちらで少し補足プラスアルファを書いていこうと思います。

認知負荷 is なに

認知負荷とは記憶に関するモデルのうち「ワーキングメモリ」と呼ばれる、何らかの作業おこなっているときに使用する記憶に関する負荷です。 認知負荷という言葉が位置するもの

そして、その「負荷」にはいくつかの種類があり、それを包括したものが認知負荷と呼ばれるものです。

認知負荷の種類

認知負荷理論として教育心理学者、ジョン・スウェラー氏によって確立された理論で、3つあります

  • 課題内在性負荷
  • 課題外在性負荷
  • 学習関連負荷

それぞれは以下のスライドを見てください

課題内在性負荷の説明 取り組むタスクの難しさによって発生する負荷 課題外在性負荷の説明 取り組むタスクの外側にあり、本質的ではない難しさによる負荷 学習関連負荷 学習するための負荷なので、これが十分に高い状態が望ましいとされる

世の中には私が調べたことより丁寧な資料もあるので、ぜひ併せてご覧くださいませ

www.ipii.co.jp

で、これがわかるとどうなるんだってばよ

ここに書いてあることは認知負荷に私の独自解釈であるため、諸説ある可能性があります。有識者のご意見があればぜひ教えてください🙏

課題内在性負荷 であれば本質的な難しさを減らすことはできないけれど、取り扱うサイズを小さくすることで理解しやすくすることができます。 複雑なロジックを小さなメソッド名に切り出し命名していく、変数名を適切なものに変える、（DDD的な文脈で）ユビキタス言語を利用する、などが挙げられるでしょう。

課題外在性負荷 であれば継ぎ足しで複雑になってしまったif文やループ処理をリファクタリングする、Why Notが正しくコメント化されている、ADRなどによりコードの設計方針を記録として残すなどして、コードを読んでいて「アレ？」となる部分を解消できるようにしていくと良いでしょう。

認知負荷とコードの話は、「プログラマー脳」という書籍がめちゃくちゃ参考になるので、ぜひ読んでみてください

www.shuwasystem.co.jp

これらを推進するには組織文化が重要

ここまで書いてあることは、一般的なエンジニアであれば「まあ個別には気になったら対応するよな」というものも多いでしょう。しかし、これらを「気になった個人」駆動でプロダクト全体に一定の規律をもたらすのはとても難しい*1ため、チームや組織の望ましい振る舞いとして浸透・後押ししている必要があるんですよね。

さらに、組織文化だけではなくプロダクトに対してオーナーシップを持てているか？ということも重要な観点になります。 今この瞬間はちょっと妥協できても、半年後、一年後にこのコードが耐えうるかは考慮できる状態になっていてほしいし、既に難しくなってしまったコードにもきちんと立ち向かえる環境である必要があります。

そういった観点で、こういった文化をより強固にしていくための取り組みは社のテックブログに書きました チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog

さて、ここまで書いた負荷を減らすという話と似た概念として技術的負債（の解消）というワードがあるかと思いますが、これに関してはさいきん目にした↓の資料が良すぎて血の涙が流れました。

このエントリではどちらかと言えば個人がどのように認知負荷を捉えるか？という話題を書いたのですが、例えば「チームトポロジー」のような組織構造と認知負荷の話もありますし、個人としても組織としても両方で立ち向かっていかないといけないんですよね。つまり、ハサミ討ちの形になるな…

認知負荷の詳細を把握してから問題を見ると、フワフワな課題の輪郭を捉えやすくなる

ここまで書いてきたことは、身も蓋もないことを言うと何らかの課題を分割するためにどのような尺度を使って捉えるかという話でした。 もちろん、「認知負荷」で全ての課題を分類できるわけではないと思いますが、成長していくソフトウェアや組織に携わっていると有用なシーンも多いと感じます。

引き続き頑張っていきましょう。

*1:もちろん、十分スキルフルで少人数なチームであれば労せず達成できる可能性はあります

rustでgemパッケージ内のコードを書く方法のメモ

Ruby 3.2に同梱されるBundlerでは、 bundle gem に --ext=rust とすることでrustでgemのコードを書けるようになります。

新しいものはとりあえず触ってみたいので、試してみましょう（完全にn番煎じなのですが、自分用の備忘録です）

事前準備

  • rustのビルド環境
  • Ruby 3.2.0（正確にはBubdler 2.4.0以上）

やってみる

rust_gem_sample という名前のライブラリを作ってみるとしましょう。

$ bundle gem rust_gem_sample --ext=rust
 : # 場合によってはさまざまな質問があるので適当に答える

これで雛形ができる。 作成された rust_gem_sample ディレクトリへ移動し、コードをさらっと眺めてみましょう。

rustのコードはC言語の場合と同じように ext ディレクトリ内に生成される。

$ tree ext
ext
└── rust_gem_sample
    ├── Cargo.toml
    ├── extconf.rb
    └── src
        └── lib.rs

ちなみに、生成されるサンプルコードはこんな感じ

# ext/rust_gem_sample/src/lib.rs
use magnus::{define_module, function, prelude::*, Error};

fn hello(subject: String) -> String {
    format!("Hello from Rust, {}!", subject)
}

#[magnus::init]
fn init() -> Result<(), Error> {
    let module = define_module("RustGemSample")?;
    module.define_singleton_method("hello", function!(hello, 1))?;
    Ok(())
}

define_singleton_method でメソッドが定義されているということは、RustGemSample.hello で呼び出せて、1つの引数を受け取るコードってことですね。

さて、ビルドするためには事前準備が必要なので、以下を修正します（これはrust関係なく、bundle gemした時に必要な一般的なもの）。

  • rust_gem_sample.gemspec
    • TODOã‚’URLっぽい値に書き換えておく（これをしないとビルド時にエラーになる）
  • testを生成している場合、自動生成された test コード
    • デフォルトのコードは失敗するようなコードになっているので、修正するなり消すなりする必要がある

これは余談ですが、久しぶりにgemspecの中身を見て source_code_uri や changelog_uri というのが設定できるということを知りました。RubyGemsのドキュメントを見るに、設定しておくとrubygems.orgのサイドバーにいい感じに表示してくれるっぽいですね……？

$ ./bin/setup
$ bundle exec rake

これで無事にビルドできるはずです。

ではお試しで実行してみましょう。

$ ./bin/console
Ignoring rust_gem_sample-0.1.0 because its extensions are not built. Try: gem pristine rust_gem_sample --version 0.1.0
irb(main):001:0> RustGemSample.hello("hoge")
=> "Hello from Rust, hoge!"
irb(main):002:0>

おー、うごいた！

せっかくなのでブログにしてみよーと思って書き始めたのですが、なんか、思ったより何もせず動いてしまった……（いい話）。

2021年に読んだ本

2021年は比較的本を読んだ気がします。

よく考えると、ゲームチェンジが起こったことが影響しているかもしれませんね。

読み切った本

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか

アーサー王とかエクスカリバーとか、小さい頃から慣れ親しんでいたけれど、それが日本でどのように受容されてきたかの話。どのように編纂されてきたかも含めて読み物としてめちゃ面白い。それと、「いかにして〇〇は〇〇したか」構文はアーサー王伝説を編纂した「アーサー王の死」の章タイトルに由来しているということを知れたのは結構なアハ体験。

あと、コラムとして本文の途中に差し込まれている侘助さんという方のコラムが完全にオタク特有の早口文体なんだけど読みやすくて、なんというか筆力を感じてすごい。

残念ながらkindle版はないのですが、amazonでも物理本は購入できます。kindle版があればな〜〜と思いつつも、この本は装丁もめちゃくちゃ凝っているので本で購入する方が良い体験を得られると思います。

07-9いかアサ〈ガウェイン〉 | みずき書林

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

  • みずき書林
Amazon

眼の誕生

進化の過程でどのように生物が眼という器官を発生させたかという話。推理小説のような書きっぷりで、表題に到達するまではそれなりに読み進めなくてはいけないけれど、光と生物の関係についてじっくり説明していくので、それはそれで読み物として面白い。

眼が発生するのは光を検知して外敵を発見するなどする光受容体をより発達させていったものという内容が段階を経て理解できる構成になっていて良かったのと、三葉虫が目を獲得していった話とかは読み応えありました。

これも物理本しかなかった。

眼の誕生――カンブリア紀大進化の謎を解く

眼の誕生――カンブリア紀大進化の謎を解く

Amazon

ユニコーン企業のひみつ

いわゆるスクラムのような1チームで成果を出す規模を超えてしまったときに、Spotifyはどういうアプローチでスケールさせていったか？ということが書いてある。LeSSのようなスクラムチームをスケールさせる手法をとっている場合、おそらくアプローチは異なるけど目指す方向は似てるはずなので、Spotifyがどういう取り組みをしていたかは解像度を高めるための参考になりそうな気がしています。

詳しくはこっちに書いた。

🦄ユニコーン企業のひみつを読んだ🦄 - すがブロ

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

Amazon

OKR

OKR、雰囲気でしかわかってなかったので参考になった。とはいえ、エンジニアの評価軸に合わせるの難しいな〜〜とか、今週の目標確認やウィンセッションなどのイベントごともスクラムを取り入れた組織だとコンフリクトしそうだよな〜〜などの感想を得た。杓子定規なOKRとスクラムの併用は難しいだろうなあ（導入するならそれなりに強い意志でアレンジしていかなといけなさそう）というのはググるとチラホラ見かけました。

OKR（オーケーアール）

OKR（オーケーアール）

Amazon

エラスティックリーダーシップ

以前読んでいたのを再読した。

エラスティックリーダーシップを読んだ - すがブロ

感想としてはあまり大きく変わらないけれど、当時よりは解像度が高い状態で読めて良かった。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Amazon

つまみ食いで読んでるシリーズ

手を動かしながら学ぶTypeScript

同僚が執筆したTypeScriptの本。 #手TypeScriptというハッシュタグ流行らせたいんですが、全く流行っていません😭

まだ読み進めている途中ですが、個人的には数年前、当時在籍していた会社でJS -> TSへのコンバートをやったときにこの本があれば……!! という気持ちがあります。

手を動かしながら学ぶ TypeScript

手を動かしながら学ぶ TypeScript

Amazon

達人プログラマー 第2版

いまさら語ることは無い良本ですが、最近になって読み直したけどやっぱり良いこと書いてありますね。

最初は数々の引っ越しイベントを経て手元に残していた初版を読んでいたのですが、圧があったので2版を買いました（のちに気が付いたんですが、kindle版ではなくどこかのPDF版を購入済みだった）。

達人プログラマー ―熟達に向けたあなたの旅― 第2版

達人プログラマー ―熟達に向けたあなたの旅― 第2版

Amazon

アジャイルな見積もりと計画作り

自社ではスクラムをベースとした開発をしており、「これ、どう考えたら良いんだっけ？」というときに見直しています。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Amazon

Clean Agile

こっちの本はほぼ読んだと思うけど、アジャイルな見積もりと計画作りと同じく、考え方を参考にしたいときに読み直しています。

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Amazon

エンジニアリング組織論への招待

これはまだ読んでいる途中なのですが、2021年の後半はチーム内のチーフというロールをやることになったので1on1をやる機会もあり、メンタリングについて興味があって読んでいます。 これは1on1をやり始めてすぐ読むべきだったな〜〜〜というくらい良い本でした。まだ読みきれてないけど……。

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

Amazon

エンジニアのためのマネジメントキャリアパス

どういう内容かはそのっつさんの感想を読むとわかりやすいですが、ひとまず自分の目の前にあるチームのマネジメント文脈ほしさで5章まで読んだ。

自社のチーフというロールはプレイングマネージャーなので、参考や目標に。

これはkindle版が無いのが惜しい

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

Amazon

おわりに

読んだマンガとかも書こうと思ったけど分量がめちゃ多くなりそうなのでここで終わります。

といいつつ、いま一番良いなと思っているのを書いておくと、ハイパーインフレーションです（最初はイロモノ的なマンガかなと思ったけど、完全にシリアスな笑いを狙ってきていて引き込まれる良さがある）。 shonenjumpplus.com

RubyMineでよく使ってる機能

この記事は SmartHR AdventCalendar の2日目です。

20代の頃はVimを使っていたのですが、膝に矢を受けてしまいIDEを使うようになってしまいました。

さて、そんなこんなで普段使いしているRubyMineですが、この中でよく使う機能について少し書いてみようかなと思います。

というわけで書いていきますが、ファイルを開くとか検索するとかはメジャーだと思うのでそれ以外について書いていきます。

コードを見ているときに便利なやつ

キャプチャを取得する際のサンプルとしてrubygems.orgのコードをRubyMineで開いています。

cmd + clickで関数ジャンプをした後、cmd + [で戻る

メソッドを探索していて、「今見ているメソッドを呼び出していた部分を読みたい」というときに戻れて便利。

さらに、cmd + ]で戻った状態から進むことができるらしいのですが、何らかのアプリにショートカットが吸われていて使えた試し無し😇

開いているファイルを「Project」タブ内で選択状態にする

読み進めているファイルと同じ階層の別ファイルを開く場合などに、シュッと周辺ファイルを探すことができて便利。

f:id:seiunsky:20211202002036p:plain

「Structure」で概要を見る

単純にメソッド一覧が表示されるだけでも便利なのですが、RSpecなど、テストを書いているときにどのようなテストケースが書かれているか把握するのに便利（RSpecだと階層構造も把握しないとテストの全体像が把握できなかったりするので）。

RSpecに関しては--dry-runを実行するという手もありますが、編集しながら横に表示できるのが便利なんですよね〜〜〜。

f:id:seiunsky:20211202002943p:plain

With Coverageでコードカバレッジを見る

テストを実行するときに、「'With Coverage'」を選択するとテスト実行後にカバレッジを表示できます。 網羅率がどうこうというより、テスト対象としたいコードに対して正しくテストが通っているかを確認するのに便利。

f:id:seiunsky:20211202003130p:plain

便利Plugin

ゴテゴテ入れるのは好きでないので、あまり入れてませんが……。

GitLink

Open in GitHubのショートカットを追加するやつ。カーソルがある行に対応するGitHubのパーマリンクが取得できるので便利。

https://plugins.jetbrains.com/plugin/8183-gitlink

Find Pull Request

該当行を変更したであろうPRを探してくれるくん。システム考古学してるとき便利。

https://plugins.jetbrains.com/plugin/8262-find-pull-request

Railways

rails routeをシュッと見る用です。絞り込みもできるので便利。

https://plugins.jetbrains.com/plugin/7110-railways/