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

週刊Railsウォッチ(20201111後編)RubyConf 2020が11/17〜19オンライン開催、GitHub Container Registryベータ開始、スマートロックほか

こんにちは、hachi8833です。

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

Ruby

RubyConf 2020が11/17〜11/19にオンライン開催


つっつきボイス:「今年のRubyConf 2020はオンライン開催かつチケット制なのか」「チケットは有料なんですね」「今回のスケジュールは3日間の開催で、スロットは最大で3つになってます」「英語が基本になりますけどオンラインなら多少追いやすいかも」

RubyConf 2020のセッション

スケジュールの時間帯はCentral Time(CST: 米国中部標準時)だそうです。

スケジュールを見ると興味深そうなセッションがいろいろ並んでいますね。タグで色分けされているのでつっつき後に少し追ってみました。通常のカンファレンスに近づけるためにいろいろ工夫をこらしているように思えました。

  • RubyConf 2020タグ(紫)は全体企画、Keynote(黄)はキーノート。


rubyconf.orgより

  • Talkタグ(赤)は通常のセッション。


rubyconf.orgより

  • Sponsorsタグ(緑)を見ると、詳しくはわかりませんが、Q&AをSlackでやりとりするスポンサーセッションもいくつかあるようです。


rubyconf.orgより

  • スポンサー企業と話ができる「Sponsor Job Fair」という時間も設けられていて、従来のスポンサーブースに相当するようです。


rubyconf.orgより


  1. Does RubyConf have a jobs fair or list?
    Yes, we will be conducting a virtual job fair on the second day of RubyConf 2020 and will also be featuring an official jobs list.
    FAQより
  • Hallway(青)タグのセッションは、おそらく会場の廊下(hallway)に集まってコードを書いたり立ち話や会食をしたりという雰囲気の再現を目指しているように思いました。


rubyconf.orgより

  • Hallwayとは別に1日目と3日目にWorkshop(灰)タグのセッションもあり、その時間帯だけスロットが最大で3つになっています。



rubyconf.orgより


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

「RubyにSTM(Software Transaction Memory)を追加する提案」を吟味する(Ruby Weeklyより)


つっつきボイス:「Rubyにソフトウェアトランザクショナルメモリを入れようという話があるとは知りませんでした」「STMがわからない😅」「RubyのSTMはどこかで見かけたような気がする(注: 後述の笹田さん資料を参照)」「詳しい人に教わりたいです」

参考: ソフトウェアトランザクショナルメモリ - Wikipedia

計算機科学において、ソフトウェアトランザクショナルメモリ(英: software transactional memory, STM)は、データベーストランザクションに似た並行性制御機構であり、並列計算を行う際の共有メモリへのアクセス法である。この機構はロックベースの同期を用いた並行性制御の代替手段として機能し、ノンブロッキングな方法で実装される物もある。ここでいうトランザクションとは、共有メモリに対する一連の読み出しと書き込みを実行するコードを意味する。論理的にはこれらの読み出しと書き込みは、時間的なある一点で行われ、他のトランザクションからはその間の状態は見えない。
Wikipediaより

「記事では回路を生成するコードでみっちりデモをやってる↓」「STMとデモプログラムの結びつきが今ひとつよく分からなかったので、時間かけて記事読まないといけなさそう」

chrisseaton/ruby-stm-lee-demo - GitHub

生成にはリーのアルゴリズムを使っているそうです。


同リポジトリより


後で調べると、@_ko1さんによる2018年の「第120回プログラミング研究発表会(SWoPP2018)」発表資料PDFにSTMについて言及がありました。

アクセス時にトランザクション制御を用いる、いわゆる、ソフトウェアトランザクショナルメモリ(STM)を用いるオブジェクトについても検討している。
(中略)
例えば、共有データが複数あるとき、データをまたがって一貫性が求められるような場合、トランザクションを適切に制御することが必要になるが、それを誤らずに制御可能に誘導するインターフェースが重要である。すべての共有コンテナオブジェクトを STM にすることで、複数の共有データにまたがったトランザクションを、ロックの順番によるデッドロックの心配なく実現することができるので、STM は有力な手法である。しかし、一貫しなければならない処理に対して、複数トランザクションを実行してしまうようなプログラムミスを検出できない。
同PDF p4(笹田)より

LibSassが非推奨に

なおruby-sassは既に非推奨となってアーカイブされています。

sass/ruby-sass - GitHub


つっつきボイス:「C++で書かれたLibSassが非推奨になったそうです」「SassはDart製のDart Sass↓に統合されるという話が前からあって移行パスも用意されていましたけど、ついにLibSassも正式に非推奨になったのか」「あ、前から決まってたんですね」

参考: sass/dart-sass - GitHub

参考: Dart Sass、使ってる?Preprosを使えばコンパイルも楽勝! | Webクリエイターボックス


以下のsass/sassc-rubyはLibSassを使っているので影響を受けることになりますね。

sass/sassc-ruby - GitHub

その他Ruby

つっつきボイス:「Ruby biz Grand prixといえば、BPSも『入退くん』という入退出管理Webサービスをエントリーしたことありますよ↓」

参考: [2]Ruby biz Grand prixで受賞した企業の声:さまざまなビジネスに拡がるRubyの活用事例から大賞が決定!『Ruby biz Grand prix 2018』|gihyo.jp … 技術評論社


gihyo.jpより

入退くんをはじめとする自社サービス「くんシリーズ」の運用方針を紹介します。


つっつきボイス:「たしかにReactorとThreadはどちらもスレッドの制御を行うので、一方だけを使うならともかく両方を組み合わせて使うのは大変そうですね」

DB

Percona Toolkitとpt-online-schema-changeの危険なエッジケース


つっつきボイス:「前回取り上げようと思って忘れてた記事です」「CREATE TABLE文とかを書き換えたりするツールだから、危険なエッジケースがあったというのもわかる気がする」「これはバグですね」「たしかにPercona Toolkitの3.0.10以下が該当する問題って書かれてる」

「記事によるとpt-online-schema-changeの基本動作は、内部でtest_not_nullテーブルをtest_nullに変えるときに、まず_test_not_null_newというアンダースコア付きのテーブルを作り、次にINSERT LOW_PRIORITYを使って既存テーブルからデータを入れている」「ふむふむ」「pt_osc_test_test_null_delのようにDELETEとUPDATEとINSERTのトリガーも作るので、INSERT LOW_PRIORITYの実行中に整合性を保てるようになってる、そして最後にトリガーや_test_not_null_newテーブルをDROPする↓」

# 同記事より
$ ./pt-online-schema-change-3.0.10 u=msandbox,p=msandbox,h=localhost,S=/tmp/mysql_sandbox5735.sock,D=test,t=test_not_null --print --alter "engine=InnoDB" --execute
(...)
Altering `test`.`test_not_null`...
Creating new table...
CREATE TABLE `test`.`_test_not_null_new` (
`id` int(11) NOT NULL,
`add_id` int(11) NOT NULL COMMENT 'my generated test case',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
Created new table test._test_not_null_new OK.
Altering new table...
ALTER TABLE `test`.`_test_not_null_new` engine=InnoDB
Altered `test`.`_test_not_null_new` OK.
2020-09-30T21:25:22 Creating triggers...
2020-09-30T21:25:22 Created triggers OK.
2020-09-30T21:25:22 Copying approximately 3 rows...
INSERT LOW_PRIORITY IGNORE INTO `test`.`_test_not_null_new` (`id`) SELECT `id` FROM `test`.`test_not_null` LOCK IN SHARE MODE /*pt-online-schema-change 1438 copy table*/
2020-09-30T21:25:22 Dropping triggers...
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_test_not_null_del`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_test_not_null_upd`
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_test_not_null_ins`
2020-09-30T21:25:22 Dropped triggers OK.
2020-09-30T21:25:22 Dropping new table...
DROP TABLE IF EXISTS `test`.`_test_not_null_new`;
2020-09-30T21:25:22 Dropped new table OK.
`test`.`test_not_null` was not altered.
2020-09-30T21:25:22 Error copying rows from `test`.`test_not_null` to `test`.`_test_not_null_new`: 2020-09-30T21:25:22 <strong>Copying rows caused a MySQL error 1364:</strong>
Level: Warning
Code: 1364
Message: Field 'add_id' doesn't have a default value
Query: INSERT LOW_PRIORITY IGNORE INTO `test`.`_test_not_null_new` (`id`) SELECT `id` FROM `test`.`test_not_null` LOCK IN SHARE MODE /*pt-online-schema-change 1438 copy table*/

「でもDEFAULT NULL COMMENTを指定したカラムがあると移行後にそのカラムがNULLになってしまったのか」「このバグを知らずに踏んだらキツい」「実行後の確認は欠かせませんね」「バグが直ってよかった😂」

# 同記事より
mysql [localhost:5735] {msandbox} (test) > select * from test_null;
+----+--------+
| id | add_id |
+----+--------+
|  1 |   NULL |
|  2 |   NULL |
|  3 |   NULL |
+----+--------+
3 rows in set (0.00 sec)

リモートワーク

ZoomがEnd-to-End暗号化機能のtechnical preview版をリリース


つっつきボイス:「ついにZoomがEnd-to-End暗号化(E2EE)をできるようになる」「E2EEだとクラウド録画ができなくなって手元でしか録画できなくなるなどの制約が付きそうですけど」「Zoomサーバー側で生成する暗号化鍵ではなくて、ミーティング参加者の生成した鍵でE2EEするんですね」「Zoomが生成した(Zoomが知り得る)鍵を使いたくないユーザーにとっては嬉しいのかも」

「ミーティング参加者の鍵はどうやって配布するんだろう?」「誰かが作った鍵を公開鍵暗号とかを使って共有するのかな?」

ビデオ会議でE2EEが要求されそうな用途

「ところでビデオ会議がE2EEかどうかって気にしてますか?」「自分が気にするかどうかというよりは、ビデオ会議でやりとりする顧客側が気にするかどうか次第でしょうね」「そうなんですね」「極端に言えば、クライアントにマルウェアが入ってしまったらE2EEがあっても同じだと思います」「あ、たしかに」「Zoomは現在でも通信路は暗号化されていますし、E2EEにするかどうかは最終的にZoomを信頼するかどうかという話だと思っています」「なるほど」

「たぶん今度の機能追加で、Zoomに全面的な信頼をおくわけにいかない事情のあるユーザーが、E2EEがあることで自分の組織にZoomの利用を認めてもらいやすくなるというメリットはあるでしょうね: たとえば米国の検閲を受ける可能性のある会社とか、国や軍事関連のような特殊な業種のユーザー」「そういう業界はあまりZoomを使わなさそうな気もしますけど、E2EEがあれば急にZoomを使う必要が生じたときでも組織から利用許可が出やすそうですね」「もちろん一般ユーザーにとっても、よりセキュアな方法でビデオ会議ができる選択肢が増えるのはいいことだと思います👍」

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

joker1007さんの「1000万件オーバーのレコードのデータをカジュアルに扱うための心構え」


つっつきボイス:「はてブで大バズりしていた記事です」「joker1007さんのこの記事はもうおっしゃるとおりだと思います👍」「社内の現場向け教育資料を元にしているというのもよいですね」「現場で得た具体的な知見のエッセンスがまとめられているのが嬉しい」

「『既存のコードを信用するな』『手癖で書くな』は、まさにそのとおり」「ちゃんと理解して把握してから構築を開始しようねという基本的な話ですね」「自分でコードを書く部分が増えるほどそこがバグの温床になる可能性も増えるので、可能ならなるべくクラウドにある機能を活用すべきだと思います」

Docker Hub関連記事(続報あり)


つっつきボイス:「AWSから50GBまで無料でプルできるのはいい👍」「外からプルできるんですね」「BPSのGitLabもAWSに乗っているんですけど、GitLab CIでDocker Hubからの転送容量制限に引っかかったときにこれでやれたらありがたい」

「どちらかというとAWSのコンテナレジストリよりは、Docker Hubからのプルをミラーしてくれるサービスの方が欲しいかな: コンテナレジストリが増えてあちこちに分散するのは望ましくないので、いわゆるディストリビューションのパッケージリポジトリでやっているような感じでコンテナレジストリのミラーサーバーがある方が嬉しいかも」「たしかに」

「同じAWS記事に、Docker Hubが6か月以上使われなかったコンテナイメージを削除するという方針が保留になったとありますね」「使うものはDocker Hubからプルしてるでしょうから、使わないのは削除でもいいのかとちょっと思いましたけど」「でもCIでキャッシュに乗っていたらプルされませんよ」「あ、そうか」「改めてプルするまでは手元のキャッシュにあるものが使われます」「それである日突然コンテナイメージが消えたら困っちゃいますね」「しかもコンテナイメージが消えたときにはわからなくて、サーバーを新たに再構築したときなどに初めて気づくヤツでしょうね😆」「それは惨事...」


「もうひとつの記事はDocker Hubの無料プラン!」「承認されたオープンソースの名前空間からイメージを取得する場合は制限なしということか」「オープンソースプロジェクトとして認められるための条件が付いてますね↓」

  • パブリックかつ非商用であること
  • Open Source Initiative (OSI)の定義(無償配布、ソースコード、派生物、ソースコードの統合、差別を許容しないことなどの定義を含む)を満たすこと
  • OSIが承認するオープンソースライセンスのもとでイメージを配布すること
  • アプリケーションの実行に使われるDockerイメージを作成すること

「多くのコンテナイメージはUbuntuやAlpineなどのオープンソースOSをベースにしていますけど、ビルドでそれらをプルするときには制限がなくなるということなんでしょうね」「オープンソースの作者はDocker Hubでこれ使っていいよと連絡しないといけないということですか?」「そういう申請は必要そうですね」「もしオープンソースソフトウェアの作者が申請しないままだとリジェクトされるということに...?」

参考: Expanded Support for Open Source Software Projects - Docker Blog

元記事で参照している上の英語記事によると、オープンソースコミュニティ向けの以下のフォームで申請が必要になるそうです。

参考: Open Source Community Application | Docker

続報: GitHub Container Registryでやれる

以下のツイートはつっつき後に見つけました。

JavaScript

yarn whyコマンド


つっつきボイス:「yarn whyなんてコマンドができたのか」「そういえば少し前からGitHubにセキュリティアラートができましたね↓」「そうそう、久々にGitHubにログインしたら使えるようになったのでオンにしてみました」

参考: Security | GitHub

「セキュリティアラートへの対応は基本的にソフトウェアをアップデートすることになりますね」「元記事によると、自分のpackage.jsonに書かれていないけど間接的に依存しているパッケージがアップデート対象の場合にもGitHubセキュリティアラートがチェックしてくれるそうです」「yarn whyでそういう間接的な依存パッケージを調べられるということですね」「Rubyのbundlerにも似たような機能があった↓」

[Ruby] Bundler 1.15の全コマンド

「なおyarn whyは以下の記事で知りました」「ここが定期的に更新されるようになってうれしいです😋」

参考: 週刊気になったITニュース(2020/10/25号) - masa寿司の日記

CSS/HTML/フロントエンド/テスト/デザイン

HTML5のblock-levelとinline-level


つっつきボイス:「はい、HTML5ではブロックレベル要素とインライン要素という概念はなくなっています」「しまった、自分まだHTML4脳だったか😅」

「HTMLやCSSの仕様については弊社のbabaさんが詳しいんですけど、以前はブロックレベル要素とインライン要素があったのが、MDNにもあるようにHTML5ではそれらが定義されなくなって↓displayプロパティでいくらでも変更できるようになっています(CSSには引き続き同じような概念はありますが)」「あ〜なるほど」「HTML5の世界からはそういう概念が外されたんですね」

参考: インライン要素 - HTML: HyperText Markup Language | MDN

以下の要素は既定でインラインです (ただし、ブロック要素とインライン要素は HTML5 では定義されなくなり、代わりにコンテンツカテゴリが使用されます)。
developer.mozilla.orgより

「HTML4以前だと、たとえばインライン要素の中にはブロック要素が書けないといった制約がありましたけど、そういうのがなくなったということだと思います」「HTML5脳にならなきゃ😅」

「ただ、概念はなくなりましたけど、現場レベルでは今もそういう概念がまだあるかのようにHTMLを書いていることは多いでしょうね」「手癖で今までどおり書いちゃうのはありそう」「自分も意識せずにそう書いているかも」「ツイートにもあるように、HTML5では便宜的にそういうものが残っていて実務上もあまり問題ないと理解しておけばよいと思います」「それに<div>なのにdisplay: inlineとかになってたら気持ち悪いですよね」「あ〜それ無理です😆」

「現場レベルのHTML5の書き方は基本的に変わらないと思いますが、今はHTMLを手書きすることが減って、さまざまなフロントエンドフレームワークで自動生成することが増えてきているので、HTML4のような制約があると何かの拍子で自動生成HTMLが仕様に違反してしまう可能性があるかもしれませんね: その意味ではHTML5のように柔軟に定義できる方がフレームワーク側でHTMLを生成しやすいかもしれないと思いました」「そうかも」

「考えてみればブロック要素はインライン要素はデザインやレイアウトに関連するものだから、それもあってHTML5から切り出したのかもしれない」「たしかに文書構造ではありませんね」「より純粋なマークアップ言語を目指したのかも」

その他フロントエンド


つっつきボイス:「いらすとや以外の選択肢としてよさそうかなと思って拾いました」「たしかに、いらすとやの絵はあまりに普及していますよね」「このサイトのイラスト、色をブラウザ上で変更できますよ!」

「ところで利用規約を見ると『商用・非商用問わず自由にwebサイトや印刷物等に利用頂けます』『利用規約範囲内のイラストに対する編集や加工は可能ですがそれに伴う著作権の譲渡や移動はありません』などとなってるのか🤔」「加工して使うのはOKそう」

「この利用規約については、既に確立しているライセンスが使われていたらなおよかったかなという気持ちがあります」「あ、クリエイティブ・コモンズのような既存のライセンスですね」「たとえば『その他著作権を侵害する行為は禁止です』の『その他著作権』の部分に解釈の余地が考えられますし、利用規約が将来変更されて使えなくなったりする可能性などについても一応使う前に考慮が必要でしょうね」

参考: クリエイティブ・コモンズ・ジャパン

言語/ツール/OS/CPU

ExcelでVBAを使わずにドラクエを作る


つっつきボイス:「これ見た見た」「これはスゴい」「VBAなしでよくぞここまで」「しかも1か月以上もかけて」「Excelでどえらく頑張ってる」「F9キーだったかな、一箇所どうにもできない部分があったのも面白かった😋」「こういう縛りプレイ的なコーディングを愛する分野ってありますよね」

「元記事に『最後まで見た方が面白いですよ』ってあったので動画の最後を見たらあのイルカが登場してました🐬」「あのイルカ」「あのイルカだ」「あのイルカ、見かける機会が既になくなりましたよね」「若い世代だとほとんど知らないんじゃないかしら」「インターネットミームの一種か何かと思われてたりして😆」

後でイルカの名前をこちらで見つけました↓。

参考: 正式名称アーカイブス|ワードやエクセルのイルカの名前

参考: インターネット・ミーム - Wikipedia

その他

スマートロック


つっつきボイス:「TechRachoにも記事を書いていただいているWingdoorさん↓のメンバーが執筆中の記事でスマートロックというものを知りました」「スマートロックは何年も前から使われてますね」

詳しくは今後公開するWingdoorさんの記事でどうぞ。

「スマートロックは鍵を時間制限付きで渡すこともできたりするので、民泊と相性がいいですよね」「民泊なら何かあったら持ち主が見に行けばいいや、みたいな感じで使えそう」「でも自宅をスマートロックにしたらトラブったときに家に入れなくなったりするのかな?」「たいていのスマートロックは既存の鍵にかぶせる形で取り付けるから、普通の鍵でも開けられますよ」「なら大丈夫そうですね」「つまり物理鍵は結局持ち歩かないといけなくなる?」「そうなりますね」

参考: 民泊 - Wikipedia

「ちなみにスマートロックって、マンションの管理組合によっては認められないこともあるんですよ(エントランスロック式のマンションなどでは、入居者の誰かひとりのスマホが脆弱な管理になるだけで侵入される問題も考えられるので)」「あ、たしかに」

「ちょうど見つけたツイートでもこんな事例がありました↓」「やっぱり物理鍵要るのかな...」「スマートロックデバイスの電池が切れる可能性も考えられますね」

参考: SwitchBot(スイッチボット)カーテン | 太陽の光で朝スッキリ!ワンタッチで自動化&楽々操作

「私はスマート何とかみたいなデバイスは大好きで、カーテンを自動で開閉するデバイス↑とかなら自宅に入れてますし楽しいですけど、自宅の鍵をスマートロックにするのはまだためらいがありますね」「自宅をスマートロックにすると、たとえば鍵を家の中に置いたまま家から閉め出されたときに代替手段がないのが心配」「ホテルや自動車でよくあるインキー(インロック)ですね」「そうなったらもう鍵屋さんを呼ぶしかない🗝」「あれを一度でも経験すると身に沁みます」

スマートロックはオフィスで便利

「ところで、スマートロックをオフィスで使うのはありかなと思います」「あ、それいいですね!」「たとえば仕事が終わって帰ろうとしたら物理鍵を誰かが持って帰ってしまって戸締まりできないときとか、朝イチで出社したらまだ鍵を持ってる人が出社していなくてオフィスに入れないときでも、管理権限持っている人に連絡して鍵をスマホに送ってもらって開ける、といったことができるのがいいですよね😋」「たしかに!」

「そもそも物理鍵を他人に渡すのって多少なりともリスクがあるじゃないですか」「合鍵を作られる可能性があるからですね😆」「スマートロックなら鍵を時間限定で送信できるので、物理鍵を渡すのがためらわれるような状況、たとえば入社間もない社員やアルバイトの人にも鍵を渡せるのがメリット」「たしかにユースケースとしてとても現実的!」「Webカメラと組み合わせれば解錠施錠する人の顔もチェックできますね」「アルバイトの人に安心して鍵を渡せるという意味では、店舗などでも有用そう」「物理鍵持っている人がシャッターを開けるためだけに出向かなくてもよくなるのはありがたい」


後編は以上です。

バックナンバー(2020年度第4四半期)

週刊Railsウォッチ(20201110前編)Rails 6.1 RC1がリリース、Railsアプリに最適なEC2インスタンスタイプ、n_plus_one_control gemほか

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

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

Ruby Weekly

Publickey

publickey_banner_captured


CONTACT

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