こんにちは、hachi8833です。BPS Webチームリーダーのmorimorihogeさんが、BPS社内勉強会向けの試みとして、先月（2018年10月）の週刊Railsウォッチの中から、主にWeb系エンジニアの初心者〜中級者層を対象に、業務開発とのつながりが深いトピックをスライドにまとめていただきました。本記事はその発表とスライドを元に作成いたしました。
普段の週刊Railsウォッチが拡散気味かつボリュームが多いので、業務開発にすぐ役立てたい方はどうぞ🙇。
- スライド発表&コメント: morimorihoge
- 書き起こし&構成: hachi8833
⚓週刊Railsウォッチ（20181001）
⚓Railsアップグレード周りについて
- Shopifyの「deprecation_toolkit」gem
- ShopifyのRails 5へのアップグレード
- スライド「ここ10年間のRailsアップグレード対応を振り返る」ともうひとつのアップグレード支援ツール
Railsのアップグレード作業は、バージョンの差分が開けば開くほど一般につらくなります。
社内でしか使われないイントラ上のアプリで、機能追加がほぼないのであれば、アップグレードせずにそのバージョンでフリーズするという選択肢もないわけではありません。しかしオープンなWebアプリをアップグレードしないままだと、将来のアプリ機能追加・変更に明らかに支障が生じます。
参考: Rails アップグレードガイド | Rails ガイド
理想は、アプリの運用コストで継続的なアップグレードを賄えることです。
Railsアップグレードのコストを開発・保守に含められない事情がある場合は、アップグレードしないことによる技術的負債が生じることを関係者全員で共有し、重大なセキュリティアップデートの適用コストと所要期間が増加するなどのリスクをコントロールする必要があります。
Railsのバージョンアップでつらいのは、上スライドの矢印の部分、特に3.0から3.1へのアップグレードです。3.1でアセットパイプラインが導入されたことでディレクトリ構成が大きく変わるのが大きな要因と言えます。
RailsのアップグレードネタはRails業務エンジニアあるあるな話で、懇親会スベらない話トップ3に入るのではないかと思います。
ある程度顧客が付き始めた自社サービス系スタートアップなどであれば流石に更新されているかと思いますが、時間内に多くの球数を打つ方が大事なフェーズのベンチャーや、そもそも開発予算がついていないこっそり作られた社内システムなんかではアップグレードにリソースを避けないケースはどうしてもあります。
というわけで、今後もRailsアップグレード関連の話というのは中堅以上のRailsエンジニアは辛いけど付き合っていく必要のある話題になっていくのではないでしょうか。
⚓astah* Community配布終了
astah.change-vision.comより
astah*といえばUMLモデリングツールの最大手であり、海外はともかく日本国内でUMLを書く人なら誰もが知っていておかしくないレベルの製品です。draw.ioなどの無償ツールにもUML図作成機能はありますが、こと使いやすさにおいてastah*のUMLツールの完成度は高いと考えます。
こうしたツールはプロジェクト内および外部メンバーや顧客と確実にファイルを開いて共有できることが重要なので、astah*製品を使うかどうかにかかわらず、プロジェクト内ではUMLなどのツールを揃えておくことをおすすめします。
そのastah* communityエディションの無償提供が終了しましたので、チームで改めていくつかライセンスを購入しました。
無償提供終了に伴いastah* Viewer↓が用意されたので、UMLの外部配布や共有用にはこれを利用します。Viewerは「印刷」「エクスポート」「編集・保存」はできませんのでご注意ください。
astah.change-vision.comより
UMLといえばPlantUMLいいよ！という方もいるのですが、僕はこの手のマークアップ言語でUMLを描くのは懐疑的な派閥です。
単純な図であればPlantUMLの生成する自動整形図で問題ないのですが、通常開発現場でわざわざUMLを書こうと思うのは命名や文章の解説だけではわかりにくい程度に複雑なケースであり、文章やコードでわかりにくいくらい複雑だから図にするわけです。
そんなとき、PlantUMLのようなツールでは視覚的に置きたいところに置きたい要素を任意に設置したり、色つけ・注釈を書き込むのがうまくいかないため、せっかくUMLをわざわざ描くのに表現力が落ちてしまっているんじゃないかなと考えてしまいます（書き方があるのかもしれませんが、その書き方を覚えるくらいならホワイトボードに書いて画像を添付したほうが早いと思う）。
単純なUML図はきれいに出せるので、一見の印象はいいんですけどね。デザインパターンの解説みたいな教材には良さそうです。
⚓ワンライナーの話
シェルプロンプトである程度まとまった処理を行う1行コマンドは「ワンライナー」と呼ばれています。1行だけでプログラミングするのはパズル的な楽しさがあるので、ネット上でも盛んに発表されています。
マニアックなワンライナーはお遊び・趣味の色が濃くなりますが、上で紹介されているワンライナーのように、業務でちょっとした作業をするときに役に立つものもありますので、有用そうなものを普段から集めておくと何かと便利です。
よくできたワンライナーなら、数分の作業を数秒に短縮できることもあります。特にローカル環境やLinuxサーバー上でシェル作業をする機会のある方におすすめします。
ただしRubyでワンライナーを書くことについては、Linuxサーバーに必ずしもRuby環境があるとは限らないので、普遍性の高いシェルスクリプトでのワンライナーをおすすめしたいと思います。PerlもLinuxサーバーで使える率が高い方なので、シェルスクリプトの次ぐらいに検討してもよいでしょう。もちろん自分のローカル環境であれば、Rubyでも何でも好きなものを使えばよいと思います。
ワンライナーは、最低限でもいいので知ってるのと知らないのではとても差が出ます。特に、障害対応などは一分一秒を争う対応が求められるので、それなりに経験のあるインフラエンジニアな人たちは、各自トラブルシューティング時の障害調査に便利なワンライナーを脳内に持っていたりします。
普段の運用でちょっとしたデータ加工や検索をする際にも便利なので、早めに抑えておいて損はない技術ですね。
⚓週刊Railsウォッチ（20181009）
⚓Rails 6でAction Textが導入される
Rails 6でAction TextというWYSIWYG機能が導入されることが決まりました。評価については使ってみないと何とも言えませんが、たとえば画像をブラウザのテキストエリアにドラッグアンドドロップしてアップロードするといった機能が簡単に実現できるので、機会があればユーザー数の少ない管理画面あたりで使い始めてみるとよいかもしれません。
なおAction Textは、Basecamp（Railsの作者であるDHHが所属する会社）が作ったTrixというWYSIWYGライブラリを基にしています。
⚓Rails 6で複数DB接続対応
- モデル生成に
--migrations-pathsオプションを追加 - ActiveRecordに
connects_toとconnected_toを実装 - マルチDB対応を強化
- スライド:「The Future of Rails 6 — Scalable by Default」 -- まとまった情報をスライドで見られます
- 他多数
Rails 6の大きな目玉のひとつとして、標準で複数データベースへの接続をサポートする機能があります。Railsウォッチでもこれに伴う改修や情報が頻繁に出ています。
これに伴い、database.ymlの書式が変わることが予定されているので注意しておきましょう。
これまでのRailsでは1アプリケーションに1データベースを前提としており、複数DBサポートにはgemの力を借りるか自力でconnectionをやりくりする必要がありました。Rails 6ではRails標準機能として複数DB接続をサポートするため、database.ymlにデータベースを複数記述できるように現在改修が進められています。
Rails 6での複数データベース接続のサポートは現時点では試行錯誤の段階なので、仕様は今後も変わる可能性があります。Rails 6のRC（Release Candidate）がリリースされた頃にチェックするぐらいでよいでしょう。
なお、Rails 5以前の既存プロジェクトで複数データベース接続を行う場合は、たとえば以下のgemで対応できます。
- switch_point
- ただしマイグレーションには対応していないので、その場合はridgepoleなどを検討する
- 参考: switch_point: master/slaveデータベース接続で負荷分散
- octopus
- シャーディングを行うgem（シャーディングはソシャゲ方面でよく行われている）
- ただしoctopusはRails 6がリリースされたらメンテナンスモードに移行します（参考）
複数DB接続は地味に待ち望んでいた人も多いのではないでしょうか。よくあるパターンとしては、別システムのDBをSELECTする権限を分けてもらい、read onlyで参照しつつRails側のシステムで独自データを持つような使い方かと思います。
DBレベルで接続するアーキテクチャは昨今流行りのマイクロサービスアーキテクチャ的な思考とは逆行しますが、いちいちAPI定義せずにSQLがぶん投げられるというのは開発上とても柔軟かつ便利なので、社内システム連携なんかでは今でも十分考慮して良いアーキテクチャだと思っています。
※マイクロサービスアーキテクチャは元々疎結合な設計で作られたシステムではうまくいきますが、そもそもビジネスロジックがドメインを跨いで複雑な処理をしまくるような密結合を前提としシステムでは後から導入するのは辛すぎるんじゃないかなと思います
⚓ES2015以降のJavaScript
上で紹介されている「TypeScript入門以前ガイド」は、TypeScriptに限らずES2015までの流れや今どきのJavaScriptの書き方を押さえられるおすすめ記事です。
昨今のJavaScriptは、ES2015が登場して以来もはやES2015を普通に使っても問題ないレベルにまで成熟したと考えられます。メジャーなブラウザはいずれもES2015に対応しています。
それに伴い、従来のようにjQueryを「取りあえず」入れることにも待ったがかかるようになってきました。少なくとも、RailsでDOM操作のためだけにjQueryを入れることはそろそろ思いとどまってもよいかもしれません。
RailsでもWebpack（Webpacker gem）が標準となりつつありますし、select2のような有名なjQueryライブラリなどもvanilla JS（素のJavaScript）版が入手できるようになりつつあるので不自由はしないでしょう。Bootstrap JSのvanilla版やVue.js版も登場しています。
なお、RailsにTypeScriptを導入する事例はまだそれほどなさそうです。あるとすれば、TypeScriptをRailsでコンパイルせず、フロントエンジニアとバックエンドエンジニアの仕事を分離した形かもしれません。今後RailsにTypeScriptを導入する事例が増えてくるかもしれませんが、現時点ではまだ予見できない感じです。
個人的にフロントエンド界隈はあまり得意ではないので、この辺り詳しい方に突っ込み頂けると助かります。
個人的にはjQueryがそんなに嫌いなわけでもないのですが、10年前くらいのやたら古いバージョン依存のプラグインを導入してくるケースも未だに目にするので、争いが起こるくらいならみんな仲良くES2015使うのもありかなと思ったりする今日このごろです。
＃ え？CoffeeScript？何でしょうそれは・・・（RJSの墓を見つめながら
⚓週刊Railsウォッチ（20181015）
⚓Rails 5.2のActive Storage関連
Active StorageはRails 5.2から標準搭載された機能で、添付ファイルの管理やサムネイル生成などを行えます。後発の機能だけあって、#createでバリデーションエラーになったときにも元ファイルを残せるなど、自力で実装すると面倒だけど欲しい機能はひととおりあるようです。
ただ、Railsウォッチの「今週の改修」でActive Storageの改修を追っていると基本的な部分での機能追加やバグ修正などが月に1、2度はあるので、現時点では細かな部分で改良の余地がありそうに見えます。なので、Active Storageを使うならRailsのアップグレードに追随できる案件が望ましいでしょう。Railsバージョンを固定しないといけない場合、バグ持ちのバージョンを使い続けることになるかもしれません。
なお、以下はActive Storage同等の機能を実現するgemです。
- carrierwave: 歴史も長く、よく使われている
- shrine: ストリームにも対応した比較的新しいgem（参考）
- paperclip: 現在は開発終了
Railsに限らず新しい（枯れてない）機能を使う場合はstableがどんどん更新されていくので、不用意にversionをフリーズしないプロジェクトでやるのが安全だと思います。
⚓週刊Railsウォッチ（20181022）
⚓Ruby/Railsのクラス探索の話
RubyやRailsでは、時としてクラス探索で大ハマリすることがあります。詳しくは上の記事をご覧ください。
この問題は、「RAILS_ENVがdevelopmentとproductionの場合で挙動が違ってしまう」といった現象の原因となることがあります。このとき、Railsのキャッシュ周りのconfigが絡んでくることもあります。
⚓その他役に立ちそうな情報
⚓週刊Railsウォッチ（20181029）
⚓ActiveRecordの肥大化どうする問題
- 特集「肥大化したActiveRecordモデルをリファクタリングする7つの方法」今ならどうなる？
- 特集「肥大化したActiveRecordモデルをリファクタリングする7つの方法」今ならどうなる？続編 -- （11/05）
これらは設計に関するトピックで、これまでBPS社内勉強会で12回に渡って行われたMartin Fowler『エンタープライズアプリケーションアーキテクチャパターン』を読むシリーズで話した内容に通じます。
このあたりはRailsで大規模なアプリを開発するうえであちこちでホットな話題になっていますので、Railsの設計に興味のある方はご一読ください。
PoEAA（エンタープライズアプリケーションアーキテクチャパターン）の勉強会は一通り完走したのですが、TechRacho記事化は気力が足りず追いついてません💦
そのうち意識が高まったときに上げていきます（たぶん
⚓Railsのマルチページフォームのvalidation
ActiveRecord::Baseを継承するクラスにvalidates ifなどで条件付きバリデーションを行うと、思わぬときにバリデーションが発動するという危険を伴う可能性があるという話をしました。条件付きバリデーションは、ActiveModelを継承するForm Object的なクラスで行う方が安全だと思います。
なおマルチページフォームとは、「ステップ1」の画面、「ステップ2」の画面...というふうに複数画面から構成されるフォームです。
⚓その他役に立ちそうな情報
こんな感じの月間サマリ、好評なら続けていこうと思いますのでもし需要ありましたらTwitter等でfeedback頂けると嬉しいです。TechRachoとかの単語が入っていれば適当に拾いますので。
Railsウォッチを毎週やっている中では、時によっては半分以上がマニアックな話題に終始してしまうことがあり、普段のWeb開発に直接役立つ知識を追いかけている人にとってはノイズに思えてしまう部分も多いと思います（ノイズの中にも面白いネタが転がっているので意図的にやってるのですが）。
「面白さ」を追求する週刊Railsウォッチに対して「実用性」を追求した月刊サマリーとでもご理解下さい😉。
※なお、ピックアップしているトピックや内容の重要度については多分に僕個人の価値観が含まれるため、業務でのご利用の際は皆様一次ソースをご確認の上自己責任でご利用下さい。