Tech Racho エンジニアの「？」を「！」に。
  1. TOP
  2. Ruby / Rails関連
  3. 週刊Railsウォッチ: GitHub CopilotのAI補完、Pure Ruby実装のRuby JIT rhizome、PostgreSQLのPG-Strom拡張ほか（20210706後編）
  • Ruby / Rails関連

週刊Railsウォッチ: GitHub CopilotのAI補完、Pure Ruby実装のRuby JIT rhizome、PostgreSQLのPG-Strom拡張ほか（20210706後編）

こんにちは、hachi8833です。Kaigi on Rails 2021のプロポーザル募集中です。

週刊Railsウォッチについて

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

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

🔗Ruby

🔗 rhizome: Pure Rubyで実装されたRuby JIT（Ruby Weeklyより）

chrisseaton/rhizome - GitHub

つっつきボイス:「RubyのJITをPure Rubyで実装ですか」「すごいものを作る人がいるんですね」「rhizomeって生物学用語だったかな？」「植物の"地下茎"の意味で、哲学用語にもなってるみたい↓」

参考: リゾーム - Wikipedia

英語の発音だと「ライゾーム」が近いようです。

「READMEには"You're supposed to read it, not use it!"ってある」「使っちゃだめよ読むだけよ、ですね」「パーサーやバイトコードなど、JITに必要そうな要素のドキュメントはひととおりあるみたい」「ドキュメントそのものもかなりみっちり書かれてる感じですね、すごい👍」「壮大なプロジェクト」

🔗 Rails Girls Japan

つっつきボイス:「Rails Girlsは日本でもワールドワイドでも活躍していますね」「Rubyでこういうコミュニティ活動が盛んなのはいい👍」

参考: Rails Girls - Japanese

後で他の言語にも同じような活動があるかどうか少しだけ探してみました。

参考: Python Girls
参考: js-girls
参考: GoLang Girls (Pune, インド) | Meetup
参考: GTUG Girls - connpass -- さまざまな言語やフレームワークが対象

🔗 記法の名前

つっつきボイス:「そうそう、クラス名#インスタンスメソッド名やクラス名.クラスメソッド名みたいな記法に名前欲しい」「インスタンスメソッドのときは#で、クラスメソッドのときは.で書く記法、たしかに名前がありませんね」「レビューのときにこの記法を名前で呼びたくなることがよくあります」

「最初にRubyを学んだときに#は実際のコードに出てこないので不思議に思った覚えがあります」「Rubyの公式ドキュメント↓でこの記法が使われているので、そういうものだと思ってました」「Rubyを使っている人にとってはもう常識でしょうね」「知らないとドキュメントを読むのが大変」

参考: オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル (Ruby 3.0.0 リファレンスマニュアル)

# https://docs.ruby-lang.org/ja/3.0.0/class/IO.html より
IO.foreach
IO.readlines
IO#each_line
IO#gets
IO#getc
IO#ungetc
IO#read
IO#readchar
IO#readline
IO#readlines

🔗 その他Ruby

「Rubyベストブログ集だそうですけど、Evil Martiansのブログがエントリにないのが意外ですね」「そうなんですよ、TechRachoでは露出度高いのに（お世話になってます🙇）」

参考: Martian Chronicles, Evil Martians’ team blog

🔗DB

🔗 『決済システムの残高管理周りのDB設計と戦略』

つっつきボイス:「決済システムを含む、いわゆる口座系のシステムはこの記事のような設計にするのが一般的ですね」「なるほど」「応答速度を上げるために現在の残高を保存することもないわけではありませんが、基本的に口座系のシステムでは入金と出金を積み上げていく設計になります」「そうそう、履歴テーブル的に作りますよね」「そのように作っておかないと、たとえば特定日時の残高を求められなくなってしまいます」

「履歴テーブルだからUPDATEは禁止ですよね」「当然禁止: UPDATEしたらエビデンス改ざんになってしまいます」

「記事を見ていても、口座系システムの基本部分は昔からあまり変わりませんね: ポイントやソシャゲの"石"を扱うシステムだと現金と関連する"有償石"と"無償石"を分けて管理する必要があるとか、速度面や設計上の戦略は変わってくるところもありますが」「ふむふむ」

「こういう業務に寄り添ったDB設計記事をあまり見かけたことがなかったかも」「この種の記事は昔からいろいろありますよ: Web系をやっているとあまり見えてこないかもしれませんが」「あぁ、探すところが違ってたのか」「普段B2Cなシステムばかり触っているWeb系ソフトウェアエンジニアだと、こういうビジネストランザクションを扱うチャンスがなかなかないこともあるので、こうした「堅い」システムの設計も勉強しておくと学べることがあると思います」「そうですね」

「こういう定番のシステム設計を、より現代的な技術を使って改めて丁寧に説明してくれる記事はありがたい👍」「たしかに」

🔗 PG-Strom: GPUでPostgreSQLのSQLワークロードを高速化

heterodb/pg-strom - GitHub

Stormかと思ったらシュトローム（Strom）だそうです。

PG-StromはPostgreSQL v11および以降のバージョン向けに設計された拡張モジュールで、チップあたり数千個のコアを持つGPU(Graphic Processor Unit)デバイスを利用する事で、大規模なデータセットに対する集計・解析処理やバッチ処理向けのSQLワークロードを高速化するために設計されています。
同ドキュメントより

つっつきボイス:「ここに書かれている↓ようなSCANやJOINやGROUP BYは実行計画的にもパラレル処理しやすいので、PG-StromはそういうものをGPUで処理するようですね」

PG-Stromの中核となる機能は、SQL命令から自動的にGPUプログラムを生成するコードジェネレータと、SQLワークロードをGPU上で非同期かつ並列に実行する実行エンジンです。現バージョンではSCAN（WHERE句の評価）、JOINおよびGROUP BYのワークロードに対応しており、GPU処理にアドバンテージがある場合にはPostgreSQL標準の実装を置き換える事で、ユーザやアプリケーションからは透過的に動作します。
同ドキュメントより

「PG-StromはApache Arrow関連でググって見つけました」「なるほど、Apache Arrowとも相性よさそう」

参考: Apache Arrow - PG-Strom Manual
参考: Apache Arrow | Apache Arrow

「GPUダイレクトSQL実行という機能は、CPUバスを通さずにSSDからPCIe（PCI Express）バス経由でダイレクトにGPUに接続するんですね」「名前が強そう」「メモリにも読み込まずにGPUに転送するからメモリも節約できるのか: こういう構成だから、NVMe（NVM Express）経由で直接SSDを接続して、NVIDIAのGPUDirect Storageモジュールなどを使う必要があるのね」


同ドキュメントより

本機能は、内部的にNVIDIA GPUDirect Storageモジュール、またはHeteroDB社の独自Linux kernelモジュールであるNVME-Stromモジュール（RHEL7/CentOS7）を使用して、GPUデバイスメモリとNVMEストレージとの間でP2Pのデータ転送を行います。したがって、本機能を利用するには、PostgreSQLの拡張モジュールであるPG-Stromだけではなく、上記のどちらかのLinux kernel拡張モジュールが必要です。

また、本機能が対応しているのはNVME仕様のSSDや、NVME-oFで接続されたリモートデバイスのみです。SASやSATAといったインターフェースで接続された旧式のストレージには対応していません。今までに動作実績のあるNVME-SSDについては 002: HW Validation List が参考になるでしょう。
同ドキュメントより

参考: PCI Express - Wikipedia
参考: NVM Express - Wikipedia

「PG-Stromって何だかとてもハードウェア寄りのシステムですね」「ぽすぐれは昔からこういうハードウェアの性能を限界まで引き出すような機能を研究したり実現したりしていますね: いかにL1キャッシュに乗せるかとか」「お〜」

参考: キャッシュメモリ - Wikipedia

「こんなすごいシステムを実際に使うのかな？使うんでしょうね」「有効なクエリにはものすごくよく効くと思います」「なるほど」「一種のクエリ計算機的なものをたくさん生成して、GROUP BYなどのパラレル化しやすい処理を分散するといった処理は昔から行われていますね」

「こういうシステム構成なら、必ずしも最新のGPUでなくても速度を出せそう: たとえばビットコインを掘るにはもう力不足になった安いGPUをたくさん手に入れて、その上でぶん回すみたいなこともできるかも」「へ〜！」「今はGPUコア数も増えましたよね: 昔のGPUはコア数はあっても機能が少なかったんですが、最近のGPUはたいていのことができるようになっていますし、メモリもメインのものより高速だったりしますね」「PG-Strom、なかなか面白い👍」

参考: Graphics Processing Unit - Wikipedia

以下はつっつき後に見つけたツイートです。

🔗言語/ツール/OS/CPU

🔗 GitHub CopilotのAI補完機能

つっつきボイス:「ぼくのツイートが載ってる〜」「GitHub Copilot、早くもあちこちでネタにされていますね」「この間ウォッチで取り上げたAWS Copilot（ウォッチ20210601）ではない😆」

「GitHub Copilotってどうなんでしょうね？」「Copilot自体はいいと思いますよ: ツイートにも書きましたけど、AIで使われたコードのライセンス周りはしばらく問題になるかもしれませんが」「あ、GPLか」

参考: GNU General Public License - Wikipedia

「個人的にこれがウケました↓」「ベストテキストエディターはVim？」

「@mametterさんもその後クワインを補完だけで書くのに成功してますね」「当分遊べそう」

🔗 AI補完よもやま

「GitHub Copilotで思ったんですが、AI補完が使えれば、自分が書いたことのないプログラミング言語でも書けるようになるんじゃないかな」「あ、それいいですね！」「他の言語の経験者なら、たとえばRubyの構文を詳しく知らなくてもRubyを書けるかも」「正しい構文を補完してくれれば、関数の引数のおかしいところを自分でちょっと修正するぐらいはできそう」「夢が膨らみますね」

「GitHub CopilotのようなAI補完でプログラマーが職を失うかどうかについても、詳細設計書どおりにコーディングするだけのプログラマーならともかく、AIで補完したコードをちゃんと吟味して評価できるのは結局プログラマーなのであまり心配していませんし、便利なものなら使えばいいくらいの気持ちです」「ですよね」「機械翻訳と人間の翻訳者の関係にも似ていますね」

「AI補完が今後何か問題になるとすれば、プログラミングの授業で出す課題を採点するときとか、採用面接で成果物を評価するときなんかに、どこまで本人が作ったのかの判断が難しくなるかもしれない、とかかな（面接の場でコーディングするところを見せてもらうならいいんですが）」「たしかに」「論文のパクリチェッカーのようにはいかなさそうですね」「補完では書けないような問題を工夫する必要があるかもしれない」

🔗 TabNine: VSCodeのAI補完拡張

codota/TabNine - GitHub

つっつきボイス:「自分はまだGitHub Copilotが招待待ちですが、こちらのAI補完はVSCode拡張なのですぐ動かせます」「MicrosoftはVSCodeを持っているから、AI補完もVSCodeでやれる強みがある」「JetBrains IDEもAIまでは使っていないけどコード補完や表示の優先順位とかは相当賢くできてますね」

「ところで今使いたいのはむしろGitHub Codespacesかな: 自分もまだ招待待ち」「WebだけでできるIDEですね」「Codespacesが使えれば本当にブラウザだけで開発できるようになるのが大きい」「環境構築の手間から解放されたいですね」

参考: Codespaces

🔗 その他

🔗 howtheytest: 有名企業のテスト方法集

つっつきボイス:「これもぼくのツイート〜」「大手企業のソフトウェアテスト方法の記事や動画へのリンク集だそうです」「さっき眺めてたら、PayPalとかいくつかのエントリは中身が空でした😆」「軽くずっこけましたね」

「少し前ならAwesomeなんとかみたいな名前になりそうなリストですけど、使われすぎて陳腐化してきた気もするので違う名前にしたのかな」「いっときGitHubリポジトリで山ほど見かけましたけど、たしかにAwesomeは手垢ついちゃいましたね」

🔗 fishとzshとbash

つっつきボイス:「fishはまだ使っていないけど、そろそろシェルを変えてみてもいいかな: WSL2上のUbuntu 20.04の標準bashでコマンド補完がイマイチうまく動かなくて」「あ〜」

fish-shell/fish-shell - GitHub

「fishもよさそうだけど、zshもいいかも」「ぜひぜひ！ぜとしぇはいいですよ〜」「お、zshお使いなんですね」「基本zshです」「zshなら何でもリッチに動くし、凝ったコンフィグにしなければ基本的にbashと同じ挙動なんですよね」「そうそう」

zsh-users/zsh - GitHub

「今のbash環境だと、ハイフン抜きのdocker compose（Docker Compose CLI）で-fオプションの補完が効かないのがつらい」「あ〜なるほど」「従来のハイフンありdocker-composeなら補完が効くので、こっちで補完してからハイフンを消したりしているんですけど、さすがに何度もやっていると地球環境に優しくないなと」「ですよね」

docker/compose-cli - GitHub

「原因不明なんですが、ハイフンありのdocker-composeだとWSL2のUbuntu環境でたまにペアレントディレクトリを見失うことがあって、ハイフンなしのdocker composeなら問題なくやれるんですよ」「う〜む」

「そういえば最近ハイフンありのdocker-compose upを使っていると"docker compose upがありますよ"みたいなメッセージが出るようになりましたね」「へ〜、今後はDocker Compose CLIがメインになるのかな、既に使ってますけど」

参考: 新しい docker compose

後編は以上です。

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

週刊Railsウォッチ: DI的な書き方が必要なとき、脆弱性学習用アプリRailsGoat、brakemanは優秀ほか（20210705前編）

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

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

Ruby Weekly


タグ
この記事を書いた人

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版のコンテンツ監修、Railsガイドのコンテンツ作成を担当。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.comに移転。Amazonウィッシュリスト: https://bit.ly/32aAmiI

hachi8833の書いた記事一覧へ

本記事の内容へのお問い合せはTwitterで@techrachoへMentionまたはDMにてご連絡頂くか、運営会社であるBPS株式会社のお問い合せフォームよりお問い合せ下さい。

CONTACT

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