自転車とプログラミング

自転車メーカーに勤める会社員がプログラミングを学ぶ中で感じたことを書きます。最近サービス作りました。

技術記事をコンパクトに書きたい。〇〇のスコープを意識する

こんにちは、Watanabeです。

先日のRails appの記事は結構長くて書くのが大変で、途中でRubyのバージョンアップに失敗したからそちらの記事を書き始めたりと、何日かにわたる大作になってしまいました。

「大作志向だといつか記事を書ききれなくてお蔵入りになるよなー、というか現職ではそういうことがちょくちょくあるなー」と思いまして技術記事をコンパクトにかけないかなと思案しています。

技術記事には何が必要なのか

結局、技術記事には何がコアとして必要で、なにが不要なのかっていうのは深く考えたことがなかった気がする。

プログラミング中につまったことであったり、課題的なところをビフォーアフターで示す。

↓

技術的な理屈を解説する

ぐらいに考えていましたが、調べてみるといい線いってるみたいですね。

qiita.com

ミノ駆動さんが書かれた技術記事の書き方の記事に行き着きました。

タイトル

概要

この記事で伝えたいこと　←★重要★

解決したい課題　←★重要★

課題の原因

課題を解決する技術、手法

技術、手法の概要

技術、手法の効果

課題がどう解決されるか

応用事例のカタログ化

留意点、デメリット

記事から引っ張ってきましたが、おおよそ私が考えていた方向性で肉付けがされている印象です。

解決したい課題を重要視するのは、業務でライティングしていたので共感がありますね。記事のコアがここになると思います。

ここの課題感が広く沢山の人が悩んでいるもので、記事がうまいことその課題を解決するなら、よく見られる記事になるんでしょう。

コンパクトな技術記事を書くには

記事内容の方向性に問題がなかったので、あとは「記事に取り上げる課題のスコープ」が広いか狭いかの問題でしょう。

この前のRails app のアップグレードは

  1. gemのアップグレード
  2. Rubyのアップグレード
  3. Railsのアップグレード

これら3点を中心に周辺情報がいろいろあってスコープがかなり広かったように思います。

これを「gemのアップグレード」に絞れば記事はコンパクトに書けそうです。

作業の範囲ではなくて「課題のスコープ」を意識するのが重要ですね。

Rails appをアップグレードしました

MAAKS プログラミング Ruby Ruby on Rails

こんにちは、Watanabeです。

自作のRails appでアップグレードが溜まっていたので対応したことを記事にしました。

環境

サービスページはこちら

作業前に考えておくこと

前提条件

(Rails アップグレードガイド)https://railsguides.jp/upgrading_ruby_on_rails.htmlによるとアップグレードに着手する前に確認しておいたほうがいい事項がある。

  • アップグレードする目的
  • アップグレードによって改修が必要になる既存コードの量
  • アップグレード作業とコード改修に割けるリソース

目的はともかく、2〜3個目は個人開発では明白なので考える必要はあまりない。業務で規模が大きいアプリを触る場合に検討が必要な事項といえる。

目的に関しては今回は「定期的なアップグレード、将来的なトラブル回避」あたりになるだろうか。

テストカバレッジを十分な状態にする

アップグレード前後できちんと動作するかのチェックのためにカバレッジを十分な状態にしておく必要がある。

私の場合はsimplecov gemを使用してカバレッジを確認するようにしている。

github.com

gem test groupeにsimplecoveを追加

test_helper.rbの先頭に定型文追加するだけでセットアップが完了する。

# frozen_string_literal: true

require 'simplecov'
SimpleCov.start

テストを走らせたあとに専用画面を開くとカバレッジを確認することができる。 これで動作検証に十分かどうかを事前に確認するようにした。

$ bin/rails test:all
$ open coverage/index.html

RubyとRailsの対応バージョンを確認する

どちらかのメジャーバージョンがあると対応していないこともあるので事前チェックはしておいたほうがよい。

アップグレード

Rails以外のgemのアップグレード

bundle outdated で最新版とのバージョン差をチェックする。

Gem                  Current  Latest   Requested  Groups
actioncable          7.1.2    7.1.3
actionmailbox        7.1.2    7.1.3
actionmailer         7.1.2    7.1.3
actionpack           7.1.2    7.1.3
actiontext           7.1.2    7.1.3
actionview           7.1.2    7.1.3
activejob            7.1.2    7.1.3
activemodel          7.1.2    7.1.3
activerecord         7.1.2    7.1.3
activestorage        7.1.2    7.1.3
activesupport        7.1.2    7.1.3

<< 中略 >>

tailwindcss-rails    2.0.32   2.3.0    >= 0       default
turbo-rails          1.5.0    2.0.3    >= 0       default
zeitwerk             2.6.12   2.6.13

今回は2ヶ月ぶりぐらいになってしまったので結構バージョンに差分が生じていた。

つづいて、dev / testグループのgemに絞ってアップグレードする

bundle update -g development -g test

伊藤さんのアップグレード手順を参考にしているが、トラブルが発生した際の原因の切り分けが用意になるように段階を経てアップグレードしている印象だ。

テスト実行→通過。やったぜ。

つづいてトラブルが起こりそうなgemを1個ずつアップグレードしていく。

$ bundle outdated
<<中略>>

pagy               6.2.0    7.0.2    >= 0       default

<<中略>>

pagyがメジャーバージョンアップしていて不穏そうなのでこれだけアップグレードしてみる。

こちらもテスト通過。やったぜ。

不安なgemがなくなった段階でRails以外をアップデートする。Gemfile.lockでRailsにバージョン固定をセットしておいて、$ bundle updateを実行する。

テストと手動の動作確認をしてみて問題なければOK。

Rubyのバージョンをアップグレードする

今回の主目的の一つ。 Rubyのバージョンが昨年末に3.3に上がっているのでその対応をしていく。

brewからrbenvのバージョンアップをして最新版のRubyを取得して、rbenvからRubyをアップグレードの手順で進める。

$ rbenv versions
$ brew upgrade rbenv
$ rbenv install --list

Rubyのアップグレードが完了したらGemfileに反映させる。

# Gemfile

ruby '3.3.0'

最新版のRubyに対応させるため、ここで$ bundle updateを再度実行する。 ここでもテスト。テストが通ったら一旦プルリクにする。

アップグレードをGitHub Actionsに反映させる

CICDを入れている場合はそちらで使用しているRubyのバージョンを反映させないと動作しなくなってしまう。

自分の場合はGitHub Actionsを使っていたので設定ファイルを修正しました。

Railsをアップグレードする

ついにRailsをアップグレードする段階までやってきました。

GemfileのRailsのバージョンを最新版(今回は7.1.3)に指定してbundle updateします。

# Gemfile

gem 'rails', '7.1.3'

$ bundle update rails

続いてアプリにRailsのバージョンアップを反映させます。

$ rails app:update
      force  config/environments/development.rb
   identical  config/environments/production.rb
   identical  config/environments/test.rb
       exist  config/initializers
   identical  config/initializers/assets.rb
   identical  config/initializers/content_security_policy.rb
      create  config/initializers/cors.rb
   identical  config/initializers/filter_parameter_logging.rb
   identical  config/initializers/inflections.rb
   identical  config/initializers/new_framework_defaults_7_1.rb
   identical  config/initializers/permissions_policy.rb
      remove  config/initializers/cors.rb
       exist  bin
   identical  bin/rails
   identical  bin/rake
   identical  bin/setup
       rails  active_storage:update

対話式にファイルをバージョンのデフォルト状態に修正するかを選択できます。dでdiff、差分を確認できるので確認してy or nで回答していきます。 私の場合は参考にしている伊藤さんが「rails app:updateコマンドのdiffでざっと確認してy、そのあと改めて確認して適宜修正」という流れで作業しているとのことで参考にしています。

https://railsdiff.org/ で旧バージョンと新バージョンの差分をチェック。 特にgemは新しく入るが、rails app:updateではインストールされないので追加する。

動作確認

アップグレード後に動作するかを確認します。

コンソール(rails c)→サーバー(rails s)→テスト の順番で動作するかどうかを見ていきます。

今回はRubyのバージョンアップ時にローカルにforemangemが欠落したようでサーバーが起動しない状態になりました。$ gem install foremanで解消しています。

手動チェック

機械的な確認だけでなく開発サーバーを立ち上げて手動と目視のチェックを行います。

私のサービスの場合は、ユーザー登録や地点登録ができるかどうかをチェックしました。

プルリク→デプロイ

ここまで完了して問題がなければ再度リモートリポジトリにプッシュして、本番環境にデプロイします。

すんなりいくわけもなく、GitHub Actionsのデプロイ側でエラーが出てしまいました。

デプロイでRubyバージョンエラー

ログを読んでみるとRuby3.2.2で動作している部分があり、Gemfileに記述したバージョンとミスマッチが生じていることが問題のようです。

今回はGitHub Actions上で動作するDockerの設定に修正が入ってなかったことが要因でした。

修正して再デプロイ、Fly.ioの仕様で数回デプロイにチャレンジする形になりましたが、最終的にデプロイできました🙌

終わりに

Fly.ioでデプロイが数回落ちるのは初めてでしたが、原因が読み取れないログだった上に「クラッシュした」と出力されていたのでメモリ不足と予想して繰り返しチャレンジしてみました。

個別で環境が異なるためエラーが出た場合の対応が大変ですが、アップグレード対応を溜め込むのもあとが面倒なのでぜひチャレンジしてください。 お手元でTryする際には、参考記事も見てチャレンジしてみてください。この記事を書くときも以前のアップグレードでも大変お世話になりました。

参考記事

Ruby3.3.0のインストールでやったこと【RUBY_FUNCTION_NAME_STRING / BUILD FAILED エラー】

プログラミング Ruby

こんにちは、Watanabeです。

環境

brewから最新版のRubyが取得できない

$ brew upgrade rbenv ruby-build

Ruby最新版を取得しようとしてもできない状態になったが、rbenvとruby-buildを再インストールしたら解決した。

$ brew uninstall rbenv ruby-build
$ brew install rbenv ruby-build

BUILD FAILEDエラー

$ rbenv install 3.3.0
ruby-build: using openssl@3 from homebrew
==> Downloading ruby-3.3.0.tar.gz...
-> curl -q -fL -o ruby-3.3.0.tar.gz https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21.0M  100 21.0M    0     0  17.2M      0  0:00:01  0:00:01 --:--:-- 17.5M
==> Installing ruby-3.3.0...
ruby-build: using libyaml from homebrew
ruby-build: using gmp from homebrew
-> ./configure "--prefix=$HOME/.rbenv/versions/3.3.0" --with-openssl-dir=/usr/local/opt/openssl@3 --enable-shared --with-libyaml-dir=/usr/local/opt/libyaml --with-gmp-dir=/usr/local/opt/gmp --with-ext=openssl,psych,+
-> make -j 8

BUILD FAILED (macOS 14.1.2 on x86_64 using ruby-build 20240119)

You can inspect the build directory at /var/folders/2p/jld6b7mn5n74dp5r5ydkx3_40000gn/T/ruby-build.20240220010937.52845.wnLlSZ
See the full build log at /var/folders/2p/jld6b7mn5n74dp5r5ydkx3_40000gn/T/ruby-build.20240220010937.52845.log

Rubyのインストールで躓くのが初めてだったのですこし困惑。ログを出してくれているので見に行く。

2 errors generated.
make: *** [debug.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from compile.c:40:
./vm_callinfo.h:179:9: error: use of undeclared identifier 'RUBY_FUNCTION_NAME_STRING'
        rp(ci);
        ^
./internal.h:93:72: note: expanded from macro 'rp'
#define rp(obj) rb_obj_info_dump_loc((VALUE)(obj), __FILE__, __LINE__, RUBY_FUNCTION_NAME_STRING)
                                                                       ^
In file included from compile.c:40:
./vm_callinfo.h:221:16: error: use of undeclared identifier 'RUBY_FUNCTION_NAME_STRING'
    if (debug) rp(ci);
               ^
./internal.h:93:72: note: expanded from macro 'rp'
#define rp(obj) rb_obj_info_dump_loc((VALUE)(obj), __FILE__, __LINE__, RUBY_FUNCTION_NAME_STRING)
                                                                       ^
2 errors generated.
make: *** [compile.o] Error 1
external command failed with status 2

2箇所でエラーが出ているらしい。 error: use of undeclared identifier 'RUBY_FUNCTION_NAME_STRING'とrpあたりがヒントになりそう。

とはいえログとにらめっこしても原因はわからないのでググります。

rbenvとruby-buildのうち、ruby-buildが個別のRubyの管理を担っているのでこちらに原因がありそう。 wikiを確認します。

github.com

ruby-buildを使用する際にほかにも必要なライブラリがあるとのことです。このあたりが原因かも？

# install Xcode Command Line Tools
xcode-select --install
# install dependencies with Homebrew
brew install openssl@3 readline libyaml gmp

ここで再度ググってみたところXcode由来のBuild Errorに対応した記事に行き着きました。

Xcode最新版をインストールしてみる。

$ xcode-select --install

再度、Ruby3.3.0のインストールにチャレンジ。

$ rbenv install 3.3.0
ruby-build: using openssl@3 from homebrew
==> Downloading ruby-3.3.0.tar.gz...
-> curl -q -fL -o ruby-3.3.0.tar.gz https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21.0M  100 21.0M    0     0  25.2M      0 --:--:-- --:--:-- --:--:-- 25.4M
==> Installing ruby-3.3.0...
ruby-build: using libyaml from homebrew
ruby-build: using gmp from homebrew
-> ./configure "--prefix=$HOME/.rbenv/versions/3.3.0" --with-openssl-dir=/usr/local/opt/openssl@3 --enable-shared --with-libyaml-dir=/usr/local/opt/libyaml --with-gmp-dir=/usr/local/opt/gmp --with-ext=openssl,psych,+
-> make -j 8
-> make install
==> Installed ruby-3.3.0 to /Users/nabeyu/.rbenv/versions/3.3.0

成功しました🙌

補足 Xcodeとは

Xcodeは、Appleが開発した統合開発環境（IDE）で、macOSやiOS、iPadOS、watchOS、tvOSなどのアプリケーションやソフトウェアの開発に使用される。

xcode-selectは、コマンドラインツールのインストールと管理を行うためのコマンドラインツール。Xcodeをインストールすると、一部のコマンドラインツールも同時にインストールされるが、場合によっては追加のツールが必要になることがあります。xcode-selectコマンドは、特定のバージョンのXcodeを選択したり、コマンドラインツールをインストールしたりするために使用されます。

参考

高速レポートを書いたおかげで書籍をいただいた話

プログラミング テクニック

こんにちは、Watanabeです。

先日、Findyさん主催のセミナー「成瀬さん直伝！2024年最新アーキテクチャトレンドとユースケースを徹底解説」に参加した際にアンケートに回答すると書籍が当たるキャンペーンがやってたので、キャンペーンにも参加してみました。

その結果、景品の書籍をいただきました。

Findy(ファインディ)さんからいただいた書籍

900人弱参加してたので発送通知が届いたときに「まじか」って本当に声がでました。

Findyさん、成瀬さんありがとうございます！！！ アーキテクチャをすこしでも知りたい！と思って参加したのでめちゃくちゃ嬉しいです。

セミナーに参加した話は別の記事にまとめているのでよかったらそちらもぜひ。

yukiwatanabe.hatenablog.com

なぜ書籍が当たったのか

書籍が当たったのは偶然の可能性はもちろんあるのですが、前々から気になっていたタイトルだったのでぜひ欲しいなーと思って当たる確率が上がりそうなことに取り組んでみました。

「できるなら〇〇な人にあげたい」がある

私も仕事での経験上の私見となりますが、こういったキャンペーンを行うときに景品の当選者を決める作業というのは完全に抽選で運任せというのはあまりないです。

全くの抽選でアンチの方などに当たってしまうとネガティブな話をリアクションをされてしまうこともあります。 どちらかというと盛り上げに寄与してくれる、してくれた人に当選させたいところです(私見です)。

また、こういったセミナーはコミュニティの裾野を広げるとか、知識を高めるという意図とセットで主催者、セミナーの認知向上を目的にしていることが多いです。そういう部分からも「新規さん且つ盛り上げてくれる人」が当たりやすくなります。

取り組んだこと

なので、僕が今回取り組んだのは「当日のうちにブログを書いて、公式ハッシュタグをつけてつぶやく」ということです。

そのブログ記事が↑に貼った記事になります。なんとかその日のうちにアップできました。 それを今回であれば「#アーキテクチャ_findy」と公式タグがあったので、それを含めてつぶやきました。

公式の方に見つけていただいたのも運が良かったですね。

あとブログタイトルにセミナータイトルを全文いれる、はてなブログデフォルトのアイキャッチを使うことで「ブログにして発信した」ということが拾われやすい状況が作れたんだと思います。

おわりに

これ書いちゃうと競争率上がりそうですけど、参加した人の感想や意見を知れるのはいいことですし、アウトプットされれば界隈が盛り上がるし、理解は深まるしで良いことずくめじゃないでしょうか。

皆さんもぜひブログ書いていきましょう。

初めてLT会に参加したまとめ。登壇して得られたもの

登壇 プログラミング

こんにちは、Watanabeです。

2024年2/17にFJORD BOOT CAMP（フィヨルドブートキャンプ）内で実施された「初めてのLT会 Vol.14」にて登壇したので、その話をまとめます。 当日使用したスライドはこちらです。

www.docswell.com

リンク先の内容はどれも同じです。 スライド共有サービスを初めて使ってみたんですが、これってサービス一つがおすすめされてなかったので代表的な3サービスをしばらく併用してみることにしました。いずれその比較情報を記事にしようと思います。

登壇した理由

FJORD BOOT CAMP（フィヨルドブートキャンプ）を昨年12月に卒業したんですが、在学中は学習に専念して、卒業したらアウトプットに専念することにしてました。 このブログと同様にアウトプット活動の一環というのが登壇に手を挙げた理由です。

また、同時期にFJORD BOOT CAMP（フィヨルドブートキャンプ）を卒業したriraさんがオーガナイザーを務めるということで「いっちょ盛り上げたるぜ！」といの一番に登壇を申し込みました。

当日までにやったこと

申込みして2月の頭に登壇が決定しました。その後にやったことは以下のとおりです。

  1. 話す内容のネタ出し
  2. スライドづくり
  3. 練習
  4. リハーサル
  5. 当日

ネタ出し

今回のテーマが「私のおすすめ！」だったので、まずは僕がおすすめできるものはなんだろうな〜？とメモ書きの要領で書き出していきました。

メモ書きはあるテーマに対する自分の考えを60秒で書けるだけ紙に書き出す、というものです。 赤羽雄二氏が考案したアプローチで数年前に知ってから愛用しています。

紙のノートに書き出したメモ書き

FJORD BOOT CAMP（フィヨルドブートキャンプ）を卒業したけど特に何ができるわけでもないし、学習中に考えてたこととして「振り返り学習がいいよね」みたいな内容か、直近にRubySilverを取得したので資格試験に関する話をしようかと考えました。

前者はフィヨルドブートキャンプでの経験をもとに「プラクティスをなんとか終了することに主眼をおいてしまって理解度が置き去りになると後で苦労するパターンを数度経験したのできちんと振り返って理解して進んだほうがいいぞ」って内容で考えてました。

リハの日までその内容でスライドも作っていたのですが、ベースの話が抽象的かつ具体的な経験が結構昔のことだったので「時間は長いが、話はふわふわ」になってしまって「①聞き苦しい②尺に収まらない③話していて面白くない」ので、RubySilverの話に切り替えました。

RubySilverの話は直近かつ具体的な経験ベースの話なのでわりとすぐに出来上がってリハに臨むことができました。

スライドづくり

出来上がったスライドが味気ないぐらいなんですが、スライドはシンプルでわかりやすいものでいこう、とはじめから考えてました。よくデザインに凝る、タイトルに凝ると時間が消えると聞いていたので。

LT会のスライドづくりでざっとググって出た情報で「スライドにアニメーションをつけるとSpeakerDeckにアップした際にすべて消える」みたいな話があったのでこれには気をつけて作りました。

いらすとやみたいな素材も組み込もうかと思いましたが、あってもなくても受け手の印象はかわらなさそうだと思ったので全く入れませんでした。シンプルイズベスト。

リハ

リハでマイクとイヤホンが通じなくなるトラブルが発生し、それに気づかないまま発表してしまい「5分強無音でスライドだけが進んでいく」のをやらかしてしまいました。

原因はマルチ接続のイヤホンマイクを使用してリハに臨んだ際に、スマホ側で録音を開始したところPC側の接続よりもスマホ側が優先されてしまい、双方の声が全く伝わらない状態になってしまいました。

リハだったので笑い話ですみましたが本番で起こっていたら怖かったと思います。こういうことがあるので初めてのLT会は意味があるなと改めて思いました👍

登壇当日

登壇当日は一番バッターで特に緊張はそれほどせずに話をすることができました。

こういう会は一番最初が一番ハードルが低い割に、聞いてる側は一番集中力が高いので一番美味しい順番だと思います。申込順とのことだったのでサクッと申し込んでよかったと思いました。

登壇してみて思ったこと、得られたこと

  • シンプルに「資格試験を受けてみて良かったこと」をまとめてみて、それがきちんと聞いてくれた人に届いていたようで安心でした。
  • 「受験日を選べるようで意外と選択肢が少なかったこと」が自分でも「罠だ！」と思ったので重点をおいて伝えたところリアクションをもらえた。内容の重み付けに沿ってリアクションをもらえると嬉しい。
  • 登壇後に司会のriraさんから内容に踏まえた話を振ってもらえてちょっとLTを深堀りできたのが良かった。司会力高かった。
  • 得られたこと
    • ハード側のトラブルの経験。まじで本番で起こったら焦るのでこういう機会に経験できて良かった。当日も音声が通じているか数回確認してしまった。
    • 発表できる持ちネタを意外と持ってないことに気づいた。「申込み駆動」であとから何を話すか考えていたのだがきちんとまとめられる話を持ってなかった。このあたりは普段から考えて行動してないと難しいと思った。

おわり

今回登壇してみて普段からネタを持つことが課題だと思いましたね。

フィヨルドブートキャンプでの発表ということで、自分と同レベルの人がたくさんいるんだと思うと中々話せることがないなーと痛感しました。みんな知ってるでしょ、みたいに考えてしまって話を作りづらかったです。

自分と同系統の属性が揃う中でも特異な(聞いて楽しんでもらえるような)話ができるようにネタ集め、ネタ作りに勤しみたいと思います。

「Hotwire.love meetup Vol.28 / Turbo 8.0と戯れる会」に参加してTurbo 8.0にちょっと詳しくなりました

プログラミング Ruby on Rails

こんにちは、Watanabeです。

Ruby on Railsに標準採用されているフロントエンドライブラリ？のHotwireを自作のサービスに採用して以来、Railsと並んで好きなライブラリとして君臨しています。

Hotwireをご存じないという方には、解説記事を出してますのでよかったらどうぞ。

yukiwatanabe.hatenablog.com

国内でHotwireを専門に扱うコミュニティ「Hotwire.love」というのがあるのですが、フィヨルドブートキャンプのメンターさんでもある伊藤淳一さんが主催の一人として運営されている縁もあって参加しています。

hotwire-love.connpass.com

2月中旬に開催されたVol.28ではついにバージョンアップを迎えたTurbo 8.0を触って戯れるとのことで参加してきました。

Turbo 8.0

モーフィング

Turbo 8.0 の目玉機能の一つ。

インクリメンタルなDOM更新を行うものです。 ページの更新を行ったときに変更が生じたDOMのみ更新することでユーザーの体験を向上させてくれます。

Hotwire.loveだとモブプロ形式でHotwireを試していくスタイルなんだけれどもモーフィングは私が見てる間には実現せず…。

今度、サンプルアプリでも作って記事にしようかと思います。

インスタントクリック

こちらはリンク先をプリロードすることで体感の読み込み速度を向上させる機能です。

こっちはHotwire.loveで実装できていました。

実装された感じを見るにmetaタグつけるだけでページ全体に機能してくれるので、めちゃくちゃ楽だし速かったですね。 ただ、カーソルが合うと自動で読み込んで、キャッシュはしてくれないっぽいのでそこは改善の余地あり、みたいに話に上がってました。

ぜひ皆さんもご参加を

Railsはフロントエンドとバックエンドに分断されたアプリでなくて、少数でアプリ構築できるフルスタックフレームワークを目指すとしています。

Turboもその流れに沿った進化ですよね。

今後、Rails周辺さらにもりあがってくるんじゃないかなーって思います。 Hotwire.loveに参加して最新情報をゲットしましょう(宣伝

Turbo 8.0の参考とか

すでにHotwireのリファレンスにも追加されてますね。要チェックです。

「成瀬さん直伝！2024年最新アーキテクチャトレンドとユースケースを徹底解説」に参加しました

プログラミング

Findyさんプレゼンツのセミナー「成瀬さん直伝！2024年最新アーキテクチャトレンドとユースケースを徹底解説」に参加しました。

findy.connpass.com

ランチタイムに開催される勉強会ということで参加しやすくて助かりますね。感謝です。

なぜ参加したのか

エンジニア関連の情報を集める際に「マイクロサービス」とか「モノリス」なんて言葉が行き交っているもんですから、言葉の意味ぐらい知れないかなーというレベルの興味でした。 イベントページを見てみたら「ドメイン駆動設計入門」著者の成瀬さんがスピーカーでもありますし、未経験〜ジュニアレベルでざっくりとしたお話が出てくるんじゃないかと期待してました。

セミナーの内容、メモしたことを中心に

バックエンドのアーキテクチャ。 「ヘキサゴナルアーキテクチャ」はアプリのサービス層？とDBや入出力との間にアダプターを噛ませることでIOの仕様を問わずにアプリと外部の処理を構築できるアーキテクチャ。

この「処理の分離」はあとのアーキテクチャの話でもたびたび出ていたので重要な概念っぽい。

レイヤードアーキテクチャは階層型のアーキテクチャで、上流から下流に情報やデータが進む。逆方向はない。階層で分けることで処理を分離できる。

ヘキサゴナルアーキテクチャとレイヤードアーキテクチャは似ている、というよりもほぼ同様の概念と化している。

その後、クリーンアーキテクチャの話が出てきた。暇プロで聞いた「ボブおじさん」のやつ。成瀬さんもボブおじさんと言っていた。 この辺で一時離脱。

GUIサイドのアーキテクチャ。 「GUIのアーキテクチャ」としてMVVMとかMVCなんかの見知った言葉が出てきたけど「GUIのアーキテクチャ」という概念がよくわからなかった。Viewが絡むから、というだけなのかしら。 MVCはModel、View、ControllerのRailsでおなじみのやつ。起源はSmalltalkが使われていた1970年代あたりらしく、現在のMVCは当時よりも進んだ概念になっているらしい。名前失念(MVC2だったはず)。

MVVMはフロントエンドのフレームワークでよく使われてるやつ。ViewModelとViewのデータバインディングすることが特徴。

最終的にはMVW(Model View Whatever)ですよ、と成瀬さん。 MとVを以下にやり取りするかに腐心しているので、その2つがきちんと分離しつつやり取りができる構造になっていればいいんじゃねって概念がMVW。

サービスアーキテクチャ。 モノリスは一つのアプリにサービス(処理のまとまり？)が混在した状態。立ち上げ直後みたいな状態。

マイクロサービスはサービスで分離させて構築する。ユーザーからは一つのアプリに見えるけどサービス間ではHTTPでやり取りをする。

モジュラモノリスは一つのアプリの中にサービスを分離させて構築していく。一つのアプリケーションではあるので、データのやり取りにHTTPではく不要だけど、開発者が安易な依存関係を作り出さないようにコントロールする必要が生じる。

この辺で再離脱。終了。

参加した感想

目的通りの内容で非常に良かったです。アーキテクチャって何を指す言葉なんだろうってレベルで参加したので、ちょうど大枠で色々と知ることができました。

アーキテクチャってのはアプリの構造の話であり、その構造を目指していく開発方針的なニュアンスだと理解しましたが、これは開発者の理解が追いついてないとコードがその通りに作られないよな、と思いました。なんだかんだ必須の知識なんでしょうね。

あと、成瀬さんがやられているYouTubeチャンネル「なるセミ」が紹介されてたのでチャンネル登録しました。こちらも見て勉強していきます💪

www.youtube.com