週刊Railsウォッチ（20200901後編）RubyKaigi 2020 Takeout登壇者発表、Ruby開発版が2.8から3.0へ、マイクロサービス分割ほか

こんにちは、hachi8833です。RubyKaigi Takeout 2020開催を目前にして、Rubyの開発バージョンが仮の2.8から3.0に変わりましたね。

Ruby 3.0.0 だ https://t.co/z1kNBv1sJN

— みょうが (@mrkn) August 31, 2020

各記事冒頭にはでパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ

「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です

夏のTechRachoフェア2020もどうぞよろしく。

Ruby

RubyKaigi 2020 Takeoutの登壇者が発表

Speakers – RubyKaigi Takeout 2020 https://t.co/UXa85C6t3H

— Yukihiro Matsumoto (@yukihiro_matz) August 27, 2020

つっつきボイス:「お、いよいよ揃った」「ざっと見てみましょうか」「トップはもちろんMatzのキーノート」

「@tenderloveさんの『Don’t @ me!』っていいタイトル」「インスタンス変数のパフォーマンスについてですね」

なお以下は5月にYouTubeにアップされていた@tenderloveさんの同タイトル動画です。

「『Ruby to C Translator』も気になる」「しかもby AIですか！」

「『Road to RuboCop 1.0』か」「今年も@ko1さんの「Ractor（旧Guild）の話があるし」

そういえばGuildは数か月前に名前がRactorに変わったのですが（ウォッチ20200519）、今回のレジュメにはRactorという言葉が見当たらない…と思ったらついさっきRactorに更新されていました！

参考: ruby/ractor.ja.md at ractor · ko1/ruby

actor という名前に振ったので channel を消してみた

— _ko1 (@_ko1) March 24, 2020

「『Rinda in the real-world embedded systems』も気になる」「リアルワールドの埋め込みシステムですか」

参考: Rinda (Ruby programming language) - Wikipedia
参考: library rinda/rinda (Ruby 2.7.0 リファレンスマニュアル)

「今回もOpalの話がありますね」「Asynchronous Opalとはアツい」「OpalはRuby to JSトランスパイラで、どのぐらい使われてるかは知らないんですが熱心にメンテされてるみたいですね」

「mrubyでドリキャスアプリですか！」「これはビックリ」

「mrubyをWebAssemblyで動かす話もある」「誰かやってた人が他にもいた気がしますね」

mrubyをWebAssemblyで動かす（翻訳）

「リモートイベントになっても、いつものRubyKaigiらしいコアな発表が目白押しですね」「Rails要素が少ないところもいつものRubyKaigiらしいですし」「もう来週（つっつき時点で）の週末ですか」「早いな〜、カレンダーに入れておこうっと」

「RubyKaigiの発表はどれも濃厚なので、聞く方も全力で聞かないと理解が追いつかないんですよね」「カロリーめっちゃ使いますし」「ブドウ糖が音を立てて減っていきますし」「発表後の録画配信はどうなるんでしょうね？」「こういうイベントの発表は盛り上がった場で一気に見るからいいんですよね: 録画されててもよほど興味がないと結局あとで見なかったりしがちですし」「それはあります」「気合入れてイベントに参加する心意気でないとですね」

Rubyで選択ソートを理解する

元記事: Understanding Selection Sort with Ruby - Honeybadger Developer Blog

同記事より

# 同記事より
def selection_sort(array)
  n = array.length - 1
  n.times do |i|
    min_index = i
    for j in (i + 1)..n
      min_index = j if array[j] < array[min_index]
    end
    array[i], array[min_index] = array[min_index], array[i] if min_index != i
  end
  puts array
end

array = [10, 30, 27, 7, 33, 15, 40, 50]

selection_sort(array)

つっつきボイス:「Rubyでアルゴリズムを勉強するというのはひとつの方法ではありますね: パフォーマンスも測定しようとすると破綻することも多いでしょうけど、動作を学ぶにはいいと思います」「パフォーマンスで破綻することがあるんですか？」「メソッドが特定のユースケースに対して極端にチューニングされていることがあったりするんですよね」「ああなるほど」「アルゴリズムに忠実に書くより既存の特異メソッドを使う方が速いなんてこともあるので、アルゴリズムのパフォーマンスも知りたければ愚直にC言語とかで書く方が向いているでしょうね」「なるほど理解です」

「Rubyは組み込みメソッドの多くがC言語で書かれていて、サボって書いても速くなるようになってたりするので、アルゴリズムの速度を学ぶには不向きな面もあると思います」「つまりRubyだと魔法のような機能でうまくやってくれると」「そういうことですね、その分パフォーマンスが予想と違ってきたりすることもままありますし」「そういう目的ならCとかで勉強する方がよさそう」「コードとしてはRubyの方が読みやすいですし、アルゴリズムを学ぶためだけにCを学ぶというのも、ね」

参考: 選択ソート - Wikipedia

telephone_number: 電話番号バリデーター（Ruby Weeklyより）

デモサイト: Numberjack

# 同記事より
phone_object = TelephoneNumber.parse("3175082237", :us) ==>

#<TelephoneNumber::Number:0x007fe3bc146cf0
  @country=:US,
  @e164_number="13175083348",
  @national_number="3175083348",
  @original_number="3175083348">

つっつきボイス:「電話番号バリデーターはGoogleが提供しているもの↓もあって、この間JSでやらないといけない案件で使いました」

「電話番号のバリデーションって国によって違ってたりしますし、めちゃめちゃ難しいですよね」「そうそうっ」「Googleのは複数の国に対応してますし、Googleがやっているという安心感もありますし、何かあっても『Googleではこうなってます』って説明できますし」「権威付け大事」

その他Ruby

連載「Rubyのウラガワ」の今回のテーマは「【第8回】Rubyの文字列エンコーディング」で、笹田耕一さん（@koichisasada）執筆です。前回、Rubyでは各文字列に別々のエンコーディングを指定できる、と紹介しました。今回は、その実装について見ていきます。#wdpress

— WEB+DB PRESS編集部 (@wdpress) August 24, 2020

つっつきボイス:「WEB+DB PRESSは紙の雑誌として結構頑張ってますよね」「昔はSoftware DesignとかWEB+DB PRESSあんなに読んでたのに最近読んでない…」「WEB+DB PRESSは扱う範囲を広げつつマニアックにしすぎない編集方針がなかなかうまくやってると思いますね」「PythonもRubyもJSも扱うし、nginxみたいなインフラ寄りのものも扱うとか」「マニアックすぎないけど初心者エンジニアが手こずるぐらいの歯ごたえがありますし、比較的中級レベルをターゲットにしつつ読者層をうまくマスに広げている感ありますね」「そーだいさんのSQL本↓みたいに雑誌の特集記事を単行本化したものにもいいものが多いですし」

最高では
続・るりまの開発環境をDockerで作ってみた – ゲームリンクスの徒然なる日常https://t.co/wiSl59Wcy2

— makicamel (@makicamel) August 25, 2020

つっつきボイス:「るりまの開発環境がDocker化！」「こうやって運用を近代化していくのが大事」「ちなみにTechRachoのWordPressもリニューアル後はDockerで動くようになりました」

クラウド/コンテナ/インフラ/Serverless

Microservicesの分割（WIP）

元記事: Microservices分割大全 - kawasima

つっつきボイス:「はてブに上がってたので」「マイクロサービス設計の指針がベンダごとにいろいろ違っているのを見ると、ベストプラクティスはまだ固まってないんだなという印象」

マイクロサービスよもやま話

「マイクロサービス化は、1つ1つのマイクロサービスのバウンダリ（境界）がはっきりするところがメリットのひとつでしょうね: そうするとリソース制御も分離されてくるので個別のマイクロサービスの構築にそれほど高いスキルを要求しなくなってくるというのはあると思います」「ふむふむ」「その分システム全体を設計するアーキテクトの責務や負担は大きくなりますけど」「個別のマイクロサービスを開発する人は自分が担当するドメインだけに注目すればいいので責任分担しやすくなりますね」

「そうなると個別のマイクロサービスだけを作る人たちの今後のスキルはどうなっていくのかなというのはちょっと気になりますけど」「個別に開発しているとシステム全体への視野は持ちにくそう」「Javaでの開発がまさにそういうふうに個別の部品の開発をいろんなところに発注するようになっていますけど、それと似たようなことがもしかするとマイクロサービス化によって今後Webにもやってくるのかなと思ったり」「まだ今は方法がいろいろあったりで過渡期感はありますけど、IstioやKubernetesを使うみたいな大きなところの方法論はだんだんまとまりつつありますし」

サイト: Istio
サイト: Kubernetes

SRE

「そうなったときに、システム全体を見るアーキテクトの道を選ぶか、それともマイクロサービスの部品づくりの道を選ぶかということになってくるのかもしれませんね」「それこそバックエンド全体を統括するIstioのようなものを管理する部門は今後いわゆるSRE（Site Reliability Engineering）的な部門になっていくだろうなと思います」「SREですか」「システム全体のパフォーマンスなどの面倒を見るのがアプリケーションエンジニアからSRE部門に移っていくでしょうし、そうなると運用の姿も変わってくるでしょうし」

参考: SREって何？これまでのシステム運用やDevOpsとは何が違うの？ (1/3)：CodeZine（コードジン）

「SREはちょっと前にバズワード的に流行った面はありますけど、いわゆるインフラエンジニアと呼ばれていた人たちがDevOpsの文脈でCI/CDやデプロイなどもやるようになって、今度はその先にSREという考えが生まれてアプリケーションメトリクスも取ったりするようになったという感じの流れですね: まあその言葉通りにSREをきっちり回しているところはまだ少ないと思いますけど」「ふむふむ」「SREを正しくやろうとするとアプリケーションメトリクスをきちんと取っていかないといけないので」

「アクセス数とかリクエスト数みたいな項目はどちらかというとインフラエンジニアの範疇なんですけど、本当に取らないといけないのはもっとユーザー寄りでビジネスに直結する注文数とか注文単価とか離脱数のような項目で、そういったものを可視化したりするのが本当のSREだと自分は思ってますし、実際SREはもともとそういう文脈で生まれていますし」「なるほど」

「SREを真面目にやろうとすると権限移譲なども含めて相当大変になるので、トップに立つ人のスキルが相当高くないとなかなか成り立たないと思います」「そうですよね」「そしてスキルの高い人ほどすぐ転職したりするので、初期構築はよくてもその後の運用が回らなくなるみたいなことがもう少し経つといろいろ起きてくるかも」「まあまあ」

「Javaみたいに枠組みが完全に確立していれば人が入れ替わっても回りますけど、今のマイクロサービスはまだ設計者のノウハウやスキルに左右される部分が大きいので」「そういう人が抜けちゃったら大混乱ですよね」「それに構築のうまい人と、構築後の運用がうまい人はまた別なんてこともよくありますし」

「そんなこんなでマイクロサービス方面はまだしばらく賑やかになるかなと予測してます」「よくあるナントカ曲線みたいに、最初はうんと期待されてその後失望して、それから持ち直して安定するみたいなヤツの途中にいる感じでしょうか」「それそれ、マイクロサービスはまだ下に落ちきってない印象がありますね」「自分もです」

「でもマイクロサービスでうまく回せている大きな組織があるのもたしかですし、一方でうまく回せていないところの話もちらほら聞きますけど、マイクロサービスという方法論自体は悪いものではないと思います」

たぶんこの曲線かなと思います↓。なおGartnerの以下のツイートはマイクロサービスとは無関係です。

参考: ハイプ・サイクル - Wikipedia

Gartner analyst Matthew Cain identifies 6 #trends on the 2020 Gartner Hype Cycle for the #DigitalWorkplace. Read more: https://t.co/qBMK11MrDz #GartnerSYM pic.twitter.com/LyvnV3ScxV

— Gartner (@Gartner_inc) August 30, 2020

その他インフラ

元記事: Docker Hubがコンテナイメージの保存期間に加えてPull回数にも上限を設定すると発表 - GIGAZINE

別にdockerに$5/mo課金したら回避できるならそんな金額くらい突っ込めばいいと思う、が、GitHub Actionsからどうやって課金すればいいんだ？

— 7594591200220899443 (@shyouhei) August 25, 2020

つっつきボイス:「このpull数の制限は厳しいですよね」「6時間あたり100回までって、CI止まりそう…」「開発者が個人で使う場合はDocker Hubにログインすればいいでしょうけど、CIはいちいちDocker Hubにログインしないし」「自分でミラー立てるとかしないといけなくなるんだろうか？」

JavaScript

Linter

vim-jp の slack でとある TypeScript の eslint がまともに動かないって話を皆で解析してたら、ts 内の <any> が HTML タグに間違われてエラーになってるだけだった話とても好き。

— mattn (@mattn_jp) August 26, 2020

つっつきボイス:「これあるある」「アノテーション付ける言語だとありがちですね: 言語の中に別の言語があるといろいろつらい」「そんな中でRubyMineなどのJetBrains IDEはこういう処理をかなり頑張ってますね」「へ〜？」「たとえば文字列リテラルの中にSQLが書かれているとすると、そのSQLがたとえばMySQLのものだと指定すればちゃんとシンタックスハイライトしてくれるんですよ」「それ見てみたいです」（しばらくJetBrains IDEでデモ）

以下のツイートは上の内容と直接の関係はありません。

We've prepared a short summary of all the 2020.2 versions of tools that have been released in JetBrains Toolbox so you can be sure not to miss any of the major features of your favorite tool. Check it out! https://t.co/2hkzp0v9mC

— JetBrains (@jetbrains) August 21, 2020

その他

「スレッドが同じでも送信者が同じとは限らない」SMS

元記事: 慣れた人ほど詐欺メッセージにだまされる、SMSの恐ろしい仕様に気をつけろ | 日経クロステック（xTECH）

つっつきボイス:「SMSのメッセージって、機能としては1通1通が完全に分割されていて、ある程度以上の長さになるとメッセージを結合したりするんですけど、実はその結合方法って割とよしなにやってるだけだったりするんですよ」「ありゃ」「記事にも書いてますけどSender IDを自称できてしまいますし」「コワい…」

参考: ショートメッセージサービス - Wikipedia

「SMSは元が電話網なんですけど、たしかこの辺はSMSのキャリアによっても違っていて、インターネットみたいに統一的なルールが決まってないんですよ」「ははぁ」「たとえばこの間使ったTwilioはSMSメッセージを送信するAPIを持ってるんですけど、以下↓を見るとわかるようにメッセージにAlphanumeric Sender IDを付けられるかどうかが国によって違ってます」「ホントだ」「そして日本は基本的にそれができないんですけど、ホワイトリストオプションがあるのでお問い合わせして審査を受けて通るとできちゃったりします」「へぇ〜！」

参考: アルファニューメリック送信者IDとは？ - Twilio

「なので日本から送信するときはAlphanumeric Sender IDを付けることはあんまりできないんですけど、Sender IDを送信できる国からSender IDを付けて日本に送っちゃえばできますね」「あ〜なるほど」「当然送信元は日本になりませんけどSender IDは通る」

「という具合にSMSは国ごとに事情が違ってなかなか大変」「う〜む」

後で多少関連のありそうなTwilio公式ツイートを拾ってみました。

From @TwilioDevs: Build an SMS Reminder Service using Python and Twilio. https://t.co/eVsHcnmFS0

— twilio (@twilio) August 19, 2020

番外

テラ

元記事: 「驚異の178Tbps」世界最速のインターネット速度が樹立される！100GBのゲームも1秒未満でダウンロード可能 | ナゾロジー

つっつきボイス:「ネットワーク帯域でこのスピードを出せても、取ったデータを置くところがあるのかと」「10GBイーサネットが出たときにも思いましたけど、これってSSDに入り切らないのでは？って」「それそれ、ストレージが追いつかない」

参考: 10ギガビット・イーサネット - Wikipedia

「こういう高速なインフラって、途上国の方が後から新しい機材を入れて速くなったりしますよね」「そうそう、先進国は投資を回収するまで次のを入れられなかったり」「5Gも日本だとなかなか進んでない感」「現状にはそんなに不満はないんですけどね」「速くなればNetflixをスマホで見るようになりますよきっと」（以下延々）

参考: 第5世代移動通信システム - Wikipedia

後編は以上です。

バックナンバー（2020年度第3四半期）

週刊Railsウォッチ（20200831前編）GitHubがRuby 2.7にアップグレード、Durationに変換メソッドが追加、hair_triggerでデータベーストリガほか

今週の主なニュースソース

ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSやruby-jp SlackやRedditなど）です。