Tech Racho エンジニアの「?」を「!」に。
  • Ruby / Rails関連

週刊Railsウォッチ(20210420後編)ShopifyのJITコンパイラYJIT、PicoRuby、DynamoDBの3つの制約ほか

こんにちは、hachi8833です。

週刊Railsウォッチについて

  • 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
  • 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄
  • お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙇

TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます(例:週刊Railsウォッチタグ)

🔗Ruby

🔗 YJIT: もうひとつのJITコンパイラ(Ruby Weeklyより)


つっつきボイス:「YJITのYはyet another」「Shopifyがやっているそうです」「Shopifyは例のSorbet↓をはじめ、いろいろ手広くやってますね」

「Shopifyが自分たち向けにRubyをカスタマイズしている様子は、FacebookがPHPをカスタマイズしてHack言語を作ったのを思わせますね: ShopifyはRuby標準にこだわらないけどRuby関連イベントにも頻繁に登場していますし、いいものはRubyに還元しようというスタンスも感じられます」「たしかに」「Hackっていう言語名、もうちょっと何とかして欲しかった」

参考: Hack (プログラミング言語) - Wikipedia

「ちなみにRuby Weeklyに載っていたのは上の動画でしたが、リポジトリとしては以下のドキュメントとyjit-benchしか今のところ見つかりませんでした↓」「early stageとあるのでこれからかな」「MJITだけだと限界に突き当たるかもしれないので、YJITのようないろんなアプローチがあるのはいいと思います👍」

Shopify/yjit-bench - GitHub


「ところで、今のCRubyの構成だとJITは大変そうなので、今後は言語のエンジン(VM)もJITに適したものに仕様が変わっていくこともあり得るかなと思いました」「ふむふむ」「JRubyが速いのは、JVMの上で動いているからというのも大きいですよね」

「最近のRubyでは、従来C言語で書かれていたメソッドをRubyで書き直すことがちょくちょく行われていますけど、あれはJITを効きやすくするという側面もあると思います」「たしかに最近よくやってますよね」「Cより速くなることもあると何かで見ました」「CライブラリのままだとJITでのメモリ再配置が難しいと思うので、 C -> Rubyへの書き換えはそれはそれで進みつつ、今後どこかのタイミングでVM自体もJITが効きやすくなる変更を入れていこう、みたいな話になるのかもしれませんね」

🔗 PicoRuby: ワンチップマイコン向けRuby


つっつきボイス:「ピコルビー?」「ラズパイとかに乗っける用ですか?」「Raspberry Piよりもっともっと制約の大きいワンチップマイコン向けですね: ラズパイならピコどころかメガ・ギガの世界ですよ」「ホントだ、ROM 256KB以下、RAM 64KB以下とか書かれてる」

参考: Raspberry Pi - Wikipedia

「PicoRubyに近いのは、いわゆるmrubyではなくmruby/cの方でしょうね↓: PicoRubyはGPIOにも対応していますし、チップに焼き込む前提っぽい」

mrubyc/mrubyc - GitHub

参考: GPIO - Wikipedia

「記事ではキーボードファームウェアをRubyで作っていて、その中のkeymapなどのカスタマイズ部分について解説しているようですね」「自作キーボード勢の間でこうやってキーボードファームウェアを作るのが流行ってるみたいですよ」


同記事より

🔗 mechanize:クローラ作りに便利なgem(Ruby Weeklyより)

sparklemotion/mechanize - GitHub


つっつきボイス:「mechanize、久しぶりに見たな」「あ、これ有名なgemなんですか?」「mechanizeはまさにクローラ的なインターフェイスを持っているので、昔からRubyでクローラを作るのによく使われます」「へ〜!」「nokogiri gemはHTTPをパースするのによく使われますが、mechanizeはクローラ専用と言ってもいいぐらい特化しているのが特長です」

sparklemotion/nokogiri - GitHub

「mechanizeにあるこういうfield_withcheckbox_withみたいなメソッドは、クローラやE2E自動テストみたいなブラウザの挙動を模した操作ができるインターフェースですね↓」「お〜」

# https://docs.seattlerb.org/mechanize/Mechanize/Form.html#method-i-field_with-21-28criteria-29
form.field_with(:id => "exact_field_id").value = 'hello'
# https://docs.seattlerb.org/mechanize/Mechanize/Form.html#method-i-checkbox_with-28criteria-29
form.checkbox_with(:name => /woo/).check

「おそらくCapybaraなどでやるより速いんじゃないかな: Capybaraはもう少し上のレイヤの動きも模倣しますけど、mechanizeはクローラ的なこと以外はやらないのでその分速そう」「そういえば最近クローラ作ってないな、また作ろうかな」

teamcapybara/capybara - GitHub

🔗DB

🔗 知っておきたいDynamoDBの3つの制約(DB Weeklyより)

参考: Amazon DynamoDB(マネージド NoSQL データベース)| AWS

  1. The item size limit;
  2. The page size limit for Query and Scan operations
  3. The partition throughput limits
    同記事より

🔗 1. The item size limit

つっつきボイス:「最大400KB/行なのか」「これに引っかかるほど大きなデータは普通入れないと思いますけどね」「MongoDBの16MBより小さいですね」「MongoDBのつもりで使うとハマりそう」「巨大なJSON blobをツッコむなと記事にも書かれていますね」「そもそもDynomoDBはMongoDBみたいなネステッドなクエリをあまりサポートしていなかったと思うので、MongoDB的な使い方は普通しないんじゃないかな」

参考: BLOB(Binary Large OBject)とは - IT用語辞典 e-Words

🔗 2. The page size limit for Query and Scan operations

「2.にもクエリの制約の話があるように、DynamoDBにはあまりにも巨大なデータを入れない方がいいでしょうね」「小さいものをたくさん入れるのはいいけど、バカでかいものを入れるなよと」「それにDynamoDBは、レコード数があまりに多いときにインデックスにヒットしないクエリを投げてしまうとリソースを一瞬で使い切ってしまいます」「そうそう!」「記事で1リクエストあたり最大1MBとあるのが2.で言うクエリのpage size limitです」

「DynamoDBはread capacity unitの設定が難しいんですよ: 内部的にはHTTPリクエストを細かく分割したような感じでページングというかブロック転送的にデータを取ってくるんですけど、ヒットした結果が大きいと1リクエストに入れられるレコード数が減ってしまうんですよ」「ああなるほど!」「逆にヒットした結果が小さければ1リクエストに入れられるレコード数は増えます: read capacity unitは課金にも関連しますし、単純にレコード数だけで見積もれないので行サイズなども考慮しないといけないのが面倒」

参考: Managing Settings on DynamoDB Provisioned Capacity Tables - Amazon DynamoDB

「2.のスキャンはどのキーでも検索できるんですが、テーブルの全行をスキャンするのでテーブルサイズが巨大になるとすごいことになります」「へ〜」「2.のクエリは必要なものだけを取れますが、partition keyが設定されているものしか絞り込みができない」「なるほど」「このあたりはDynamoDBを一度使ってみるとわかります」

🔗 3. The partition throughput limits

「3.のpartition throughput limitは、記事によると1パーティションあたりのreadとwriteのcapacity unitにそれぞれ上限があるのか」

🔗 DynamoDBのモード

「DynamoDBにはオンデマンドキャパシティーモードとプロビジョニング済みキャパシティモード(デフォルト)という2種類の課金体系があって↓、後者は消費したユニット数が単位時間ごとに回復するんですが、完全に消費するとAPIエラーになるのがつらい」「本番で起きたら悲しいですね...」

参考: 料金 - Amazon DynamoDB | AWS

「一方前者のオンデマンドキャパシティーモードにはその制限はなく、完全に従量課金になります」「なるほど〜」「使い方に応じてどちらかを選ばないといけません」

「なお以下は2018年の記事↓なので現在の金額と違うと思いますが、料金のグラフの伸び方などは参考になると思います」「ふむふむ」

参考: Amazon DynamoDBをオンデマンド(従量課金)で利用した場合の料金体系まとめ #reinvent | DevelopersIO

「プロビジョニング済みキャパシティモードはlimit exceededエラーになる可能性がある点がつらいので、よほど余裕があるかエラーが起きても構わないものでもない限り、ユーザーリクエストベースのクエリに使うのは怖い」「ごもっともです」「TerraformやCloudFormationのログ置き場とか、バッチ処理のログ置き場に使うなら、プロビジョニング済みキャパシティモードでもまず制限は超えないと思います」

参考: AWS CloudFormation(テンプレートを使ったリソースのモデル化と管理)| AWS

「一般にDynamoDBは、productionに導入する前に自分である程度触っておくのがよいと思います」「そうですね」「いきなり使うと想定外の事態に出くわす可能性がありますし、DynamoDBのクエリ形式は特殊なので慣れないと使いにくいかもしれません」「DynamoDB、いろいろ懐かしいです」「DynamoDBはAWSの中でも歴史が相当長いサービスで、公開前にもAWS内部で相当使われていたはずですね」

🔗 その他DB


つっつきボイス:「遅れてきたエイプリルフールねたで恐縮ですが、SQLクエリにPLEASEを付けないと遅くなるというジョーク記事に、後から続々とそれを実装しましたという追記が伸びてました」「そうそう、SQLは問い合わせ(query)のための言語ですからポリティカルコレクトネスということにしておく感じで」

🔗 pleaseと英語のニュアンスよもやま話

「ところで上の記事では誰も触れていなかったんですが、実は英語のニュアンスとしては、命令形にpleaseを付けても丁寧になるわけではないんですよ」「えぇ!そうなんですか?」「たしかにplease付けても命令形であることは変わらない😆」「丁寧に言うときはWould you~とかCould you〜で始めたりしますよね」

参考: 【英語で依頼】丁寧さを使い分け!ネイティブがお願いに使う表現と、ビジネスメールの依頼文

「日本人としてはついpleaseを日本語の『〜してください』と同じように考えがちなんですけど、どちらかというと『お願いだからやって!』みたいな強調のニュアンスに近くて、結局命令には変わりないそうです」「やべぇ、気をつけようっと😅」「逆に英語の命令形だからといって必ずしもぞんざいとも限らなかったりするのがややこしい...」「しょうがないですよね、自然言語だから」「結局文脈次第ですね」


「それで思い出したんですが、以前ある技術書籍の翻訳許可をメールで出したときにすごく丁寧なお断りメールをもらったことがあって、文面で1箇所たりともnotが使われていないのに全体としてはちゃんとお断りになっていて、これがビジネス英語かと逆に感心した覚えがあります」「notを使わない、わかる!」「ご多幸をお祈りしますメールみたいな」「イギリス英語はそういう婉曲的表現が発達してる印象ありますよね」「イギリス英語はよくわかってないんですがそう思います」

参考: イギリス英語と京都弁の共通点(小野昌弘) - 個人 - Yahoo!ニュース

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

🔗 Lambda@Edgeの課金変更


つっつきボイス:「Lambda@Edgeの課金の時間が1msec単位になった!」「お〜」

「AWS CloudFrontでBASIC認証を使おうとするとLambda@Edgeに置くしかないんですけど、BASIC認証の処理は数行しかないので一瞬で終わるんですよ」「たしかに10msecもかからなさそう😆」「そんなふうに50msecもかからない処理って割とよくあるので、50msec分も課金されなくなったのはありがたい🙏」

参考: Basic認証 - Wikipedia

「Lambdaも少し前にミリ秒単位課金になったので、ごく短時間で終わる処理を書いたときの課金の違いは大きいですね」

参考: 料金 - AWS Lambda |AWS

🔗言語/ツール/OS/CPU

🔗 ジュニアと達人

SuperPaintman/the-evolution-of-a-go-programmer - GitHub

# 同リポジトリより: ジュニアの場合
package fac

func Factorial(n int) int {
    res := 1

    for i := 1; i <= n; i++ {
        res *= i
    }

    return res
}
# 同リポジトリより: シニアおよびRob Pikeの場合
package fac

// Factorial returns n!.
func Factorial(n int) int {
    res := 1

    for i := 1; i <= n; i++ {
        res *= i
    }

    return res
}

つっつきボイス:「Go言語で書かれた素朴な処理なんですが、ジュニアが書いたコードとGoの作者であるRob Pikeのコードがコメント以外まったく同じになっていてウケました」「なるほど、ジュニアの愚直なコードが、関数型やジェネリクスを覚えたりマルチスレッド化対応やasyncをやったりするうちにどんどん複雑になっていく、あるある」「これは面白い😆」「同じコードをRob Pikeが書くと何も言われないのに、ジュニアが書くとレビューで修正依頼が来たりして」「誰が書いたかで変わるのもあるあるですね」

「ちなみにこれは前からあるネタですね↓」「なるほど!これをGo言語でもじったのか」「高校生、大学生、新人と進んで、マスターになるとスゴいのを書いてる」「そしてグルはecho "Hello, world."だけでおしまい😆」

参考: The Evolution of a Programmer

「その下の管理職のコードをよく見ると、部下にやっといてメールを出してるだけじゃないですか」「最後のChief Executiveのコード↓が最高」「その辺も含めてもろもろネタですね」

# 同サイトより: 役員の場合
  % letter
  letter: Command not found.
  % mail
  To: ^X ^F ^C
  % help mail
  help: Command not found.
  % damn!
  !: Event unrecognized
  % logout

🔗 その他

🔗 くずし字を読み取るアプリ


つっつきボイス:「お〜、きれい✨」「くずし字を読み取るとふわっとタブレットに文字が浮かび上がるあたりが、Outer Wildsというゲームで古代種族が石版に記録した文字を古代文字スキャナーで読み取るシーンを思わせますね↓」「Outer Wildsもう終わったんですか?」「まだです: このゲームはネタバレされる前にやっとくのがおすすめ」「よ〜し」

参考: 22分後、太陽系は消滅する。宇宙を舞台にしたオープンワールド探索アドベンチャー『Outer Wilds』がNintendo Switchで2021年夏配信決定。 | トピックス | Nintendo

🔗 VSCodeで小説支援

ttrace/vscode-language-japanese-novel - GitHub


つっつきボイス:「VSCodeで小説!」「こんな拡張があるんですね」「青空文庫記法の対応とか便利そう」「こちらの@ttraceことSF作家の藤井太洋氏は、実は大学で3つ下ぐらいの後輩でして」「へ〜!」「デビュー作の『Gene Mapper』という小説は、たしか3.11をきっかけに通勤電車の行き帰りにiPhoneで書いたそうです」

参考: 藤井太洋 - Wikipedia

「しかも小説を書く前は、むしろShade↓という3Dモデリングソフトの専門家というかエバンジェリストとしてその道では有名だったそうです」「Shadeって今も使われてますよね」「そうそう」「大学の頃、彼がAppleの初代ノートパソコンのPowerbookを背中にしょったまま3Dレンダリングしながら学内を駆け回ってたのを思い出します」

参考: Shade3D 公式 | 3DCGソフトウェア
参考: PowerBook - Wikipedia


後編は以上です。

バックナンバー(2021年度第1四半期)

週刊Railsウォッチ(20210419前編)RailsのN+1クエリを定番以外の方法で修正する、GitLabのセキュリティ修正リリースほか

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

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

Ruby Weekly

DB Weekly

db_weekly_banner


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。