Shibuya.rb[:20221128] に参加した

shibuyarb.connpass.com

会場がすぐそこだったので参加した。前半は朝に素振りしてたTurboについて調べてたり、RubyRailsのドキュメントサイトについてしゃべってた。

みたいなことをしゃべっていたと思う。

Railsのドキュメントサイトの生成方法

結論、rails/railsbundle install したあとに rake rdoc を実行すると doc/rdoc に静的サイトが出力されるので、 doc/rdoc/index.html を眺めると良い。

$ rake --tasks
(in /Users/ikaruga/src/github.com/rails/rails)
rake build            # Build gem files for all projects
rake default          # Run all tests by default
rake gem              # Run gem task for all projects
rake install          # Install gems for all projects
rake package          # Run package task for all projects
rake prep_release     # Prepare the release
rake publish_docs     # Publishes docs, run this AFTER a new stable tag has been pushed
rake rdoc             # Generate documentation for the Rails framework
rake release          # Release all gems to rubygems and create a tag
rake smoke            # Smoke-test all projects
rake test             # Run test task for all projects
rake test:isolated    # Run test:isolated task for all projects
rake update_versions  # Bump all versions to match RAILS_VERSION
rake verify           # Build, install and verify the gem files in a generated Rails app

コードとしては以下のあたり。Rakefilerdoc なんてタスク無いじゃん、と思ってたら、 Rails::API::EdgeTask.new("rdoc") の引数がタスクの名前だった。 Rails::API::EdgeTaskRails::API::RepoTask を継承していて、 最終的に RDoc::Task#initialize に引数が渡る。 RDoc::Task までくるとそれはRubyの標準ライブラリである。

github.com

desc "Generate documentation for the Rails framework"
if ENV["EDGE"]
  Rails::API::EdgeTask.new("rdoc")
else
  Rails::API::StableTask.new("rdoc")
end

class Rake::RDocTask (Ruby 3.1 リファレンスマニュアル)

後半はPHP勉強会@東京との合同LT合戦を聞いていた。

  • irbedit コマンドでREPLの中にいながらエディタを開ける
  • bundler/inline の中で binding.irb を書いておくと事前処理を行った上でREPLが動いて便利
  • gh pr list | fzf | awk '{print $1}' | xargs gh pr checkout

あたりが自分の中で刺さった。

現場参加の勉強会はかなり久々だったけど、発表の空気感やオフでの挨拶自己紹介周りについては圧倒的にオンラインより快適。これから現地参加できる勉強会が増えるのであれば積極的に参加していきたいなあと思った。

beatmania IIDX29 CastHour まとめ

きまぐれでこっちに書くか。

ステ

少なくとも前作よりはやってる。今作はずっとSPやっててDPあまり触っていなかったのでだいぶ地力が落ちた。おかげさまでDPは中伝のFlashes超えられなくて十段です。

行脚

近年にしては外出てた方だと思う。三重行く機会はあったけどラウワン行けなかったのが心残り。松本はアピナに行こう。

SPマイベスト

Verfluchtは呼吸として、クリアランプ狙いでやってたのがだいたい。リザルトスキップしまくってるから1位以外はこれの3倍くらい挑戦してそう。

タワー

感謝の376万打鍵。

いい曲

IIDX知らない人がこれ読んでるかわからんけど、いい曲って言いながらここでいい感じに紹介できないのがあれなので現場に行くかインターネットするかサントラの購入をご検討ください。

  • 月とミルク
  • Ventriloquist
  • ALTERNATOR
  • 青の洞窟
  • 天邪鬼

☆12

AAA鳥は107曲らしい。だいぶ少ないほうだと思うので180以下の精度上げていくのが次。

リアランプは未難1(黒イカ)、未エクハ56くらい、やってないの数曲。今作はアルマゲとかグングニルとかTHE F∀USTとか今まで苦戦してた12のエクハが付いてよかったと思う。あとはn/aとかRAGEとか今作出てきたゲテモノたちに全部ハード付けれたのも大きい。エクハランプだいぶ煮詰まってきている感があるので次はフルコンかなあ。鳥増やすのとフルコンつけるの相反するのでむずいけど。

嬉しかった

今作はファーフルダリアエクハとクロペン鳥が大物だった。流石にちょっと自信ついた(ってことにしとく)。BPI眺めてると、そこまで苦労せずに付けたつもりのONIGOROSHI鳥とスチニー†鳥がやたらと数値高く出てて本当に〜?となる。

最後に

次回作でもお会いしましょう。 4214-8644 です。ライバル登録はいつでもお待ちしております。

RubyKaigi 2022に参加した

参加した。以下記録。

rubykaigi.org

RubyKaigi 2022 - RubyKaigi 2022

2019年に行われた福岡ぶりのオフライン開催。オンライン開催のTakeoutも2020,2021と聴いていたけど、家で作業しながら聴いていて正直あまり印象に残っていない。福岡のときの自分の様子は以下のとおり。内容がほぼ無で、当時のtwilogもみかえしてたけど本当に面白くないムーブしていて悲しくなった。

前日準備

社のランチタイムに参加者をターゲットにしてスケジュールを流し読みしながら発表する人の話やその内容についてしゃべる会を開いた。参加するのであれば予習しておいたほうがお得なのは前回参加したときにわかっていたので。( RubyKaigi 2019のセッションメモ )

ちなみに、お昼の1時間じゃ全部伝えきれないので、2時間用意して余った時間で雑談や現地行くときのあれこれの質問時間にすると良さそう。という感触。特に今年は3年ぶりのオフラインで初めて行く人が多くてどうやって移動すると良い?みたいな相談がそこそこあった気がする。

荷物

4泊の荷物をスーツケースに入れるかデカメッセンジャーに詰めるか迷ったんだけど、今年はメッセンジャーに全部詰めることにした。代わりに会期中の移動はトートバッグにして一眼のカメラを持っていくのを諦めることにした。2015年のYAPCのトートバッグ持っていく異常者になってたけど、ある程度話のネタになってこれはこれで良かった。

ノベルティのことを頭に入れてなかったんだけど、一応全部詰めて運べたのでありがとうMETROPOLISの気持ち。

Kaigiの話

印象に残った発表

Rubyのしくみ」を読んでいたおかげである程度理解できました。という話が結構多くて本読んどいてよかった〜と思った。Ruby meets WebAssembly やYJIT関連の発表がまさにそれ。Stories from developing YJITはさすがにCPUの話まで出てきて、勉強不足を感じたけど…。コンピュータアーキテクチャについてもっと掘り下げる必要があった。

紹介したい話

TRICK 2022 (Returns) 最高だった。これを生で聴きに来たまである。「誤り訂正符号の実装をこの中でやってるんですよね」と言われて驚愕したりいい刺激になった。

ruby/debug - The best investment for your productivity はdebug gemの中身ではなく、連携できるデバッガの紹介に突き抜けていてこんな感じでデバッグできるんですよね、という紹介をするときに便利な発表だと思った。

Why is building the Ruby environment hard? もいい話で、環境構築でこけるんですよね。というときに見返すと良さそうだった。

String Meets EncodingRubyの処理の速度を上げるためにソースをビルドして検証していく話。丁寧に検証やソースコードを追っていく様子が素敵だった。

スポンサーブースの話

発表ずっと聴くのもつかれるので、スポンサーブースの千本引きのお手伝いをしたり。英語での対応が全然できなくてちょっと凹んだ。

ごはん

会期中のお昼に出た松阪牛のお弁当が最高に美味しかった。外だと津駅前のいせもん本店とBAR LIGHTのスイカソルティードッグが印象に残っている。

伊勢駅前だと酒蔵森下と、カフェ ビアンカの雰囲気が最高。ビアンカ、外見の看板の主張がラッキーピエロに近くて勝手に親近感湧かせていた。

あと食べチョクのツイート抽選に当選したので松阪牛が届いた。ありがとうございますありがとうございます美味しくいただきます。

人々

久しぶりに社外のRubyistとはじめましてした気がする。あとは基本ペパボの人と喋ったりご飯行ったり。もう少し積極的に社外の人たちに首突っ込んでいっても良かった気はする。3日目のmix inは行きたかったけど、別の予定があったので断念。

津の町並み

津の駅前の地図をみて妙なカーブがあることに気がついて調べてた。ブラタモリみてるとこういうの気になる。五叉路?といっているのは地図中央から右上にかけて斜めに家が建ってたりするから。調べたら近鉄伊勢線の廃線跡だった。

駅前のAPOAホテルを取ってたんだけど、窓全開にできたり(怖い)向かいのシーシャバーからハリーポッターのメインテーマが一生流れてきてなかなか愉快だった。

アフターカイギ

day3の夜に伊勢に移動してday4の午前中に伊勢神宮にお参り。午後はレンタカーで関宿の様子を眺めに行ったり。関宿落ち着いていて結構良かった。

来年

松本、すでに行く気は満々でいるので気持ちを高めていく。民泊は取った。松本に住んでいた知り合いからご飯や情報は仕入れたので別に書くことにする。駅前にやたらとバーが多くて超期待。


オフラインでないと得ることのできない熱を得ることができたので久々にモチベが上がっている。オーガナイザー、スタッフ、参加者の皆さん本当にありがとうございました。

ツクモでWindows PC買い替え

グラボの値段が落ち着いてきたので、ピッと買い換えるか〜と思って買ったのが7月の話。

前回買ったのは2017年の末。今回も自作するぞ!って意気込んで結局自作せずツクモの掘り出し物を見つけて買ったという話でございます。 uvb-76.hatenablog.com

自作案

前回同様Mini-ITXは変えないつもりでいたので、MasterBox NR200P MAX のケースに Mini-ITX + i5 + GTX3600 で考えてたんだけど、マザーボードのUSB-C等USBの数を増やそうとするとチップセットのランクが上がってマザーボードの値段が跳ね上がってしまい、コストが割に合わないことに気がついた。そこで、NR200P とそこまで幅奥行きが変わらない XPG VALOR AIR JPATXマザーボードを使って拡張を取る構成も考えた。けど、どちらの構成も20万前後で落ち着いて、前回の買い替え時に比べると値段上がったな…と思ってなかなか手が出せずにいた。

整備品を見つけた

そんで、前回同様掘り出し物がないかツクモの本店に足を運んだら、そこにあったのはNZXT H1 のケースを使ったBTOの整備品。調べてみると GS5A-A204Tの整備品ぽかった。詳しく話を聞いてみると、「画面が表示されないという不具合で初期不良扱いの返品されたんだけど、しらべてみたらGPUとMBのライザーケーブルが外れてただけだったわテヘペロ」という感じだったらしく、動作に全く影響はなさそうな雰囲気。マザーボードのUSB-Cの数は気持ち足りない気がしたけど、このスペックのPCが20万切って売られていたので流石に買ってしまった。パーツの価格たちを電卓で弾いた合計よりも安いのですが…3070積んで20万は安いでしょう。ちなみに元値はGPUが高騰していた時期というのもあるけど、29万くらい。

  • AMD Ryzen™ 5 5600X
  • NVIDIA® GeForce RTX™ 3070 / 8GB (GDDR6)
  • 16GB DDR4 SDRAM (PC4-25600 / DDR4-3200 センチュリーマイクロ製、8GBx2)
  • 1TB SSD (M.2規格 / NVMe接続)
  • Windows 10 Home
  • NZXT H1

WSLを使えるようにする

UEFIで仮想化を有効にしたかったんだけどAMDの設定項目がわかっていなかったので備忘録。以下の設定を切り替えると良い。 IntelはVT-xだけどAMDSVM modeという名前なのね。

Advanced > CPU Configuration > SVM > [Enabled]


という感じで、前回に引き続きツクモに置かれていたPCを買うシリーズでした。今はWindows11に上げて平和に動いている。Lightroomのカタログを前のPCから拾って来ていないので回収する必要があるんだけど、めんどくさい…。今まで使っていたPC自体はまだ使えるので、リビングのテレビでゲームやる用に残しておこうと思う。

SUUMOのオウンドメディアに寄稿した

つまるところ

www.suumocounter.jp

↑書いた。

経緯

uvb-76.hatenablog.com

はてなの編集さんからメールで「エンジニア、家を建てる」シリーズの執筆依頼が来たのが始まり。去年書いた自分の記事を読んでくれたらしい。「エンジニア、家を建てる」シリーズは自分も読んでいて、前に書いている方の記事を読んでやべ〜〜って尻込みしたんだけど、文章書いてお金をもらうという経験になるならいいか〜と思って乗った。乗った後はインタビューやら執筆の後に編集さんの校正、文章調整等や写真の差し込みを行って無事掲載された感じ。インタビューから編集、校正まで色々とお世話になりました。

感想とか

自分が書いた文がメディアの文体に校正されていくのを見て、説明文章とメディアの記事は違うものだなあと思った。あと、最近体言止めを使わなくなったと気付かされた。

写真もそこそこ気を使った。実は写真に写っている範囲の外でぬいやアクスタやフィギュアがまあまあ並んでいたりする。主張強すぎるのもどうかと思うのでできるだけ写さないようにした。あと編集さんから「許諾不要そうなところで川崎っぽい写真お願いできますか?」って頼まれたときは頭抱えたけどぱっと撮れそうな多摩川を選んで難を逃れた。

社Slackの #マンションクエスト チャンネルでも報告したってのもあるけど、オフィスですれ違う人から「読みました〜」って言われて意外と読まれてんのねって気が付かされた。ありがとうございます。ちょっとでも参考になればうれしみ。

おまけ

記事の下のプロフィールに個人サイトの ikaruga.org を載せていたので、Analyticsで流入を計測した。ユーザ100弱くらいの流入はあったぽい。記事自体のPVはわからないので比率として多いか少ないかはわからない。自サイトのPVなぞそもそも対して興味ないので気にしていないのだけれども。

2022年上期に読んだ本たち

下書きに溜まっていたものを出すシリーズ第二弾。本読んだ系は下書きに無限に溜まっていく。

読んだ本

人間とかチームのことにフォーカスした本が中心だった。

エンジニアのための時間管理術

www.oreilly.co.jp

日々の生活で時間管理というものを常に破滅させながら辛うじて生きている自分が割込が入り続けるチームに所属することになった。流石にこれ以上破滅させるわけにはいかないと考え、ひとまず守破離の守となりうる基準を作るためにこの本を手にとった。

初版は2006年!!古い本だけど、今でも通じる話が沢山あってよかった。ちょっと昔のシステム管理者のための本ではあるが、特に職種を問わず役に立つ話が書いてあると思った。

特に2章の「集中と割り込み」にか書かれている割り込みへの対象方法の言語化と13章の「自動化」のための作業手順は何度でも読み返したくなる。 自動化するためにはまず手で頑張って運用して手順を定める。手順を定めて初めてその手順を自動化できる。それはそう。

あとは9.2の「休暇」が秀逸。全部いいこと書いてる。

自分でやった方が早い病

www.seikaisha.co.jp

社で主に見ている開発者は自分だけ、というサービスがあって、それをチームメンバーに移譲していこうかというところで 『自分でやった方が早い病』を読んだ - ravelll の日記 を以前読んだのを思い出し、自分も読んでみることにした。

良くも悪くも自己啓発本で、最初は前半の「こんなにいいことがありますよ」が宝くじにあたり肌が整い…の類の話に感じてしまって身構えたけど、3章あたりから具体的な自分でやらないようにするためのアドバイスが出てきてそこそこためになる。「仕事を任せられないのは相手を信じていないか相手が自分を信じていないか」でぐさっと来た。任せる覚悟を持って一緒に進めて行きましょう。

チーム・ジャーニー

www.shoeisha.co.jp

社内で読書会が開催されているのを観測して、自分も積んでいたのを思い出して並行して読んでいた(スケジュールの都合とかあって参加しなかった)。ちょうどチームのタスクの進め方とか他チームとの協業あたりで思うところもあったのでちょうどよかった。ちなみに前作のカイゼン・ジャーニーは読了済み。

それぞれの章がストーリー仕立てになっていて読みやすかった。課題が発生して、それを解決するというストーリーに加えてさらに後述して解説が入るのがとても親切。まとめとして各章で発生した課題とそれを解決するための手札(手段)をまとめたページが用意されているのも素敵に感じた。総じて親切。

どの章も「これは私達のことですか?」みたいな課題が並んでいて面白いのだけれども、特に4章の中で説明されている「チームの構造をデザインする」、11章の「チームの間の境界を正す」、15章の「自分たちの視野と視座を自在にする」、あとはカイゼン・ジャーニーでもあったハンガーフライトの話が自分に刺さった。

ちなみに同じ事業部のディレクターやデザイナーにも口コミで広めているので多分流行る(ほんとに?)。読みやすいのでオススメはできる。

理論と実例でわかる自己肯定感

techbookfest.org

昔買った本の読み直し。技術書典で見つけたやつ。「自分でやったほうが早い病」で「自尊心」という言葉が出てきてこの本を思いだし、もう一度読み直してた。

自己肯定感という言葉には「とても良い」と「これでよい」の2つの気持ちが含まれていて、それらを区別してコントロールする必要がある。ってのが超概要。

自分も今の会社に入った直後は知らないことについて「これでよい」のハードルを無限に高いハードルを設定して「なにもわからん。なんもできん。超頑張らんと破滅する」みたいな気持ちで結構落ち込んでたけど、 @kenchan (多分) の「一つでもわかったことあるのだったらなにもわかってないこと無いじゃないですか。それでいいじゃないですか。」(要約)って言葉をもらってから「これでよい」のハードルが下がって結構落ち着いた気がする。

二寺に関してはここらへんについて上手く付き合ってると思うんだよな。この曲はAAA(評価区分上の最高)出せなくてもよい。けど、この曲はどんなに体調悪い時でもAAA安定させておきたい。とか。日々の生活や仕事でもいい感じにコントロールしたいのだけども。

経験談含めて64ページの短い書籍なので、ぱっと読めてオススメ。

次読む

ここに書いて次に繋げる。

エンジニア組織論の招待の後半

前半は読んでて、後半の章ちょっと退屈で読み飛ばしてたんだけど、チーム・ジャーニー読んだあとならもう少し理解できそうな気がする。

システム運用アンチパターン

どちらかというとシステムを運用する仕事をやっているので。これはみんなでがっと読みたいな〜。


ちなみに買った技術書とかはscrapboxにまとめているので、「この本読んでるならこれもいいよ」「これ読んでないなら一緒に読みませんか」とかあったらお気軽にお声がけください。

scrapbox.io

statesmanの状態遷移の定義からmermaidのstateDiagramを書き出す

下書きに入ってたから掘り起こすシリーズ。

github.com

statesmanを使った状態遷移を伴うコードを読む機会があって、眺めてたら図に書き出したくなったのでコードを書いた。

書き出したいStatesmanの状態定義

サンプルとしてStatesmanのREADMEにあった状態定義をそのまま持ってくる。

# order_state_machine.rb
class OrderStateMachine
  include Statesman::Machine

  state :pending, initial: true
  state :checking_out
  state :purchased
  state :shipped
  state :cancelled
  state :failed
  state :refunded

  transition from: :pending,      to: [:checking_out, :cancelled]
  transition from: :checking_out, to: [:purchased, :cancelled]
  transition from: :purchased,    to: [:shipped, :failed]
  transition from: :shipped,      to: :refunded
end

statesmanのメソッド郡が使えるようになるしくみ

statesman を使ってリソースの状態遷移を扱うためには使いたいクラスで Statesman::Machine を include する必要がある。includeすると、そのクラスにクラスメソッドが定義される。

github.com

仕組みをシンプルに書くと以下のとおりとなる。

irb(main):001:1* module Foo
irb(main):002:2*   module Bar
irb(main):003:3*     def self.included(base)
irb(main):004:3*       base.extend(ClassMethod)
irb(main):005:2*     end
irb(main):006:2*
irb(main):007:3*     module ClassMethod
irb(main):008:4*       def baz
irb(main):009:4*         puts "Hello!"
irb(main):010:3*       end
irb(main):011:2*     end
irb(main):012:1*   end
irb(main):013:0> end
=> :baz
irb(main):014:1* class A
irb(main):015:1*   include Foo::Bar
irb(main):016:0> end
=> A
irb(main):017:0> A.baz
Hello!
=> nil

self.included で module Barinclude されたときの処理を記述できる。引数はインクルードしたオブジェクトである。 docs.ruby-lang.org

base.extend(ClassMethod) はつまるところ A.extend(ClassMethod) となる。extendObject#extend で、Object に対して特異メソッドとして引数に渡したモジュールのインスタンスメソッドを定義できる。ここでは ClassMethod#baz が Aクラスの特異メソッドとして定義される。 docs.ruby-lang.org

クラスの特異メソッドということはクラスメソッドとおおよそ同義として扱って良い。 docs.ruby-lang.org

mermaid の状態遷移図を出力する

実装方法がわかったので、 Statesman::Machine をいい感じに再実装することで状態の宣言と状態遷移のルールの記述に対して好きなことができる。あとはその再実装が適用される状態で直接statemachineのファイルをrubyで実行すればよい。ということで、mermaidのstateDiagramを書き出すコードを以下のgistに結果も含めてまとめた。

mermaidjsのstateDiagram

今回はRubyの実装の再定義だったので、中身を調べて上書きすればよかったのだけれども、なんらかのDSLに対してRubyのメソッドを実装して読み込ませてなんかするってのはbuildersconでやってたLTが自分の中で印象に残っている。今回のstatemachineのクラスを眺めてなんかできそうと思ったのもこのLTを思い出したことがきっかけだった。

www.slideshare.net