こんにちは、hachi8833です。
![🔗]()
Ruby
![🔗]()
RubyとOpenSSL 3とUbuntu 22.04
つっつきボイス:「昼のBPS社内勉強会でUbuntu 22.04とOpenSSL 3の話題が出たので、Rubyのビルドはどうなっているんだろうと思って見つけた記事です」「記事にもあるように、OpenSSL 1.1をインストールしてビルド時に--with-openssl-dirでディレクトリを指定すればUbuntu 22.04でも古いRubyをビルド可能です」「できるけどたしかに面倒ですね」
「これは自分もそれでいいんだろうかという気持ちになった↓」「ちょっと大胆な感じですね」「今年リリースされたのにRuby 3.1ではなくてRuby 3.0なのか」「ちなみにJammy JellyfishはUbuntu 22.04 LTSのコードネームですね」
なお、Jammy では Ruby 3.0 に Ruby 3.1 に同梱されている openssl gem がほぼほぼバックポートされて放り込まれてます(これやっていいんだ)。
同記事より
参考: Ubuntu 22.04 LTS (Jammy Jellyfish)
参考: Support OpenSSL 3.0 · Issue #369 · ruby/openssl
![🔗]()
最近のRubyコア動向: ６月号（Hacklinesより）
つっつきボイス:「例のRubyコア動向記事の6月号が出ていました」「議論中の話題を扱っているので今後変わる可能性はありますね」「そこ注意ですね」
![🔗]()
Array#undigits
「お、Array#undigitsを加えようという話」「Integer#digitsというメソッドが既にあるんですね」「既存のdigitsは整数を桁ごとに配列に分解するメソッドで、このundigitsは逆に配列の桁を組み立てて整数にするのね」
# 18762より
42.digits.undigits
#=> 42
参考: Integer#digits (Ruby 3.1 リファレンスマニュアル)
# docs.ruby-lang.orgより
16.digits # => [6, 1]
16.digits(16) # => [0, 1]
![🔗]()
Kernel#thenが引数を取れるようにする
参考: Feature #18690: Allow Kernel#then to take arguments – Ruby master – Ruby Issue Tracking System
「Kernel#thenで引数を取れるようにする？」「今のthenは1.5.then{|x| Math.atan(x)}のようにブロックを渡せるけど、それを3.then(4){|x, y| Math.hypot(x, y)}のようにも書けるようにするとありますね」「むむ、この4がyに入るということかな？」「あ〜、そういうことか」「一度わかればいいけど最初は戸惑いそう…」
# 18690より
honyarara.then(fugafugafuga, hogehogehoge){|x, y, z|
foo(x)
bar(y)
baz(x)
qux(x, y, z)
}
「今まではthenに外から新しい値を差し込めなかったけど、これができれば今まで2行で書いていたものを1行で書いたりできそう」「なるほど〜」「でも、この書き方を許すと何でもthenで書く人が出てきてカオスになるかも」「自分は今もthenで書くこと多いですけど、言われてみればカオスになる可能性はあるかもしれませんね」
「よくこんな機能を思い付きましたよね」「議論中なので先のことはわかりませんけどね」「通常のthenは比較的単純な使い方しかできないので特に心配はしないけど、引数を許すようになったらドキドキするような使い方が続出するんじゃないかという気はちょっとする」「それわかります」
「ところで、thenは最初登場したときはyield_selfという名前でしたよね」「そうそう、たしかRubyKaigi 2018の会場でthenがあっさりエイリアスとして追加されてましたね」「以下の記事でzverokさんが『yield_selfという名前だけはやめて〜』と言ってたのを思い出しました↓」
![🔗]()
ppの拡張
参考: Enhance prettyprint by kddnewton · Pull Request #3 · ruby/prettyprint
「prettyprint（pp）が強化されるのは嬉しい
」「みんな大好きpp」「つい消し忘れがちですけど
」「ppやruby/debugが強化されると、それだけでRubyをアップグレードするモチベーションが高まりますよね」「ホントそう」
参考: library pp (Ruby 3.1 リファレンスマニュアル)
![🔗]()
Numeric#ceildiv
参考: Feature #18809: Add Numeric#ceildiv – Ruby master – Ruby Issue Tracking System
「最後はNumeric#ceildivか」「切り上げと割り算を一度に行う」「よく書く処理だけどメソッドチェインだと重くなりがちなので、高速な専用メソッドが欲しいのもわかる」
# #18809より
# notice that b > 0 is assumed
def rounding_up_division(a, b)
(a + b - 1) / b
end
「他の言語だとどんなメソッド名なのかな？
」「他の言語は特定処理に特化したメソッドをあまり増やさない印象がありますけどね」「そうそう、でもそうすると同じような処理をみんなが独自に書き始めてしまうので、Rubyではみんなが使うならと専用メソッドにすることが多いですよね」
# #18809より
123.ceildiv(10) # => 13
「スレッドでもa.fdiv(b).ceilではなぜダメなの？と聞いている人がいて、その回答も書かれている↓」「割ってから切り上げると桁数が多い場合にうまくいかないケースがあるんですね」
# #18809より
a = 99999999999999999
b = 1
(a + b - 1) / b # => 99999999999999999
a.fdiv(b).ceil # => 100000000000000000
個人的には、CRubyでのオブジェクトシェイプの実装が議論され始めているのも気になりました。
参考: Feature #18776: Object Shapes – Ruby master – Ruby Issue Tracking System
![🔗]()
MongoDBがJRubyのサポート継続を決定
Link: A Plan for MongoDB and JRuby | MongoDB
https://t.co/7MRjqTnTpI— Yukihiro Matz (@yukihiro_matz) June 29, 2022
つっつきボイス:「MongoDBが一時期JRubyをサポートから外すことを検討していたのが、コミュニティのリクエストを受けて引き続きサポートすることにしたそうです」「JRubyのユーザーはエンタープライズ系が多いだろうから、サポートがなくなるとつらいでしょうね」「MongoDBは一時期ずいぶん流行りましたね: もちろん要件に合うならMongoDBを使うのは全然ありです」
![🔗]()
kconv
letter_openerっていうgemの今年リリースされたバージョンから新規にkconvへの依存が増えているのを発見して震えている…
— 7594591200220899443 (@shyouhei) June 23, 2022
つっつきボイス:「letter_openerがkconvに依存するのか」「どの辺が気になりますか？」「letter_openerは非常によく使われていますけど、kconvは日本語でしか使わない機能なので、日本語を使わないユーザーが影響を気にするかもしれませんね」「なるほど」
参考: library kconv (Ruby 3.1 リファレンスマニュアル)
「なお、kconvはRubyのdefault gemなので依存自体は問題ないはず: 問題が起きるとすれば、kconv gemのバージョンが固定されているとRubyのバージョンアップでkconvのバージョンも上がったときに不整合が起きてbundlerがエラーになる、みたいなことはあるかもしれませんが」「そうかも」
「ちなみにletter_openerを見てみるとkconvをrequireしているだけですね↓: 日本語でしか使わないkconvを常にrequireしていいのかは気にならなくもないけど、letter_openerは開発環境でしか使わないので問題にならないという考え方なのかもしれませんね」
# lib/letter_opener/message.rb
require "cgi"
require "erb"
require "fileutils"
require "uri"
+require "kconv"
「kconvはメールのSubjectのエンコード/デコードなんかでよく使われます↓」「おっと、久しぶりにiso-2022-jpエンコーディングを見た」「なつかしい」
# spec/letter_opener/message_spec.rb#38
describe '#subject' do
it 'handles UTF-8 charset subject' do
mail = mail(:subject => 'test_mail')
message = described_class.new(mail, location: location)
expect(message.subject).to eq('test_mail')
end
it 'handles encode ISO-2022-JP charset subject' do
mail = mail(:subject => '=?iso-2022-jp?B?GyRCJUYlOSVIJWEhPCVrGyhC?=')
message = described_class.new(mail, location: location)
expect(message.subject).to eq('テストメール')
end
end
「今のメールのSubjectは絵文字も使えるので、UTF-8エンコーディングは使えるはず」「そういえば昔はUTF-8でSubjectをエンコードできませんでしたね」「たしか当時はUTF-8だとSubjectが複数行になったときにうまく処理できない処理系がちょくちょくありましたね: Quoted-printableは1行の文字数に上限があって、それでSubjectの文字数が決まるんですが、UTF-8エンコーディングだと文字数が増えるので改行が発生して一部のガラケーメールで文字化けすることがあった、というような経緯でiso-2022-jpエンコーディングを使った経験があります」「なるほど」
参考: Quoted-printable – Wikipedia
参考: メールのデコード処理の流れ – Qiita
![🔗]()
DB
![🔗]()
AWS AuroraとCloud Spanner関連情報（Postgres Weeklyより）
- 元記事: Amazon Aurora が PostgreSQL 14 に対応
- 元記事: Access Spanner’s global scale and high availability from familiar PostgreSQL | Google Cloud Blog
つっつきボイス:「そうそう、AuroraのPostgreSQLのメジャーバージョンが上がった」「SpannerのPostgreSQL互換インターフェイスは以前も扱ったと思いますが（ウォッチ20211019）、こうやってコンパチブルであると宣言されるのはいいこと」
![🔗]()
クラウド/コンテナ/インフラ/Serverless
![🔗]()
Linuxカーネルのライブパッチ
つっつきボイス:「今日のBPS社内勉強会でLinuxカーネルのライブパッチの話題があったので取り上げてみました」「自分はライブパッチを使っていませんが、利用可能になったのはLinuxカーネル 4.0からなので随分前から機能はあるわけですよね」
「ところでライブパッチ機能使ってます？」「まだです」「ざっと調べたところ、Ubuntuの場合はデフォルトではライブパッチをサポートしていないんですが、Canonicalに登録するとAdvantageのプランでライブパッチを使えます↓」「こんなのあったんですね」「個人だと物理サーバーやVMやデスクトップで3台まで無料」「お〜」
参考: Ubuntu Advantage for Infrastructure | Ubuntu
「そしてAmazon Linuxはライブパッチを公式にサポートしている↓」「追加料金なしと書かれているからAWSを使っていれば利用できる感じですか」「Amazon Linuxは元々AWS上で使う前提で無償サポートされていますね」
参考: Amazon Linux 2 のカーネルライブパッチ – Amazon Elastic Compute Cloud
「ライブパッチでやれればもちろん楽ですが、機能によってはライブパッチで更新できないものもあるはずなので、そこは要注意」「たしかに」
![🔗]()
GitHub Copilot学習データのライセンス
Copilotのライセンス不明問題、企業だけじゃなくてオープンソースプロジェクトでも使えないよなあ。ライセンス不明のコードは混ぜられないでしょ。そしたら何に使えるんだろう。 https://t.co/10LQaGRbFM
— Shiro Kawai (@anohana) June 30, 2022
つっつきボイス:「新山さんのツイートのリンクから、弁護士兼プログラマーによるGitHub Copilotのライセンス問題の考察ブログを見られます」
ブログ記事冒頭には「筆者はあなたの弁護士でもなければ誰の弁護士でもありません。本記事の内容を法的なアドバイスとして利用しないこと」と注意書きがあります。
「GitHub Copilotのライセンス問題は難しいですね: 使う側の設定ではpublic codeに一致する内容をサジェスチョンに出してよいかを指定できる↓のでそれはいいんですが、問題なのはGitHub側の学習データに使われたコードのライセンスが大丈夫かどうかが1件1件確認されたのかという点」「そこですよね」
参考: Configuring GitHub Copilot in Visual Studio Code – GitHub Docs
「学習に使ったリポジトリのリストをGitHubが公開して精査可能にならない限り、厳密な意味でライセンスが安全であるという確証を得ることは難しいだろうなとは思います」「安全というのは法的にということでしょうか？」「それもありますけど、そもそも現時点では学習モデルに使われるデータのライセンスに関する法的な解釈が確定していないんですよ」「あ〜そうか」「学習モデルには元データは入っていないけど、その学習モデルを配布するのは法的にOKなのか、というようなことも含めて未だに答えが出ていない」
「AIと学習モデルといえば、少し前にLegalForceの契約自動審査サービスが問題視されましたね↓」「そうそう」「たとえばLegalForceがAI審査機能のしくみだけを提供して運用は顧客が行うならともかく、少なくともクラウド上のサービスとして契約書をレビューするのは非弁行為に当たると指摘されても仕方がない気はします」「弁護士資格を持っていない者が弁護士行為を行ってはいけないというヤツですね」
参考: AI契約審査サービスに法務省「違法の可能性」リーガルフォースの見解は | ツギノジダイ
参考: 非弁活動 – Wikipedia
「話を戻すと、GitHub Copilotの場合は学習データにライセンス違反のコードが混じっていないかどうかを検証する手段がないことがさしあたって問題でしょうね」「混じってないかもしれないし混じってるかもしれない」「AIだと学習したコードがそのまま出てくるわけではないから余計ややこしい…」「使う側としては、GitHub Copilotがサジェストしたコードをそのまま使わないようにするなどの対策も取れますが、使う側が注意を強いられるのが悩ましい」
![🔗]()
CSS/HTML/フロントエンド/テスト/デザイン
![🔗]()
周期律表風のモーショングラフィック基本要素リスト
@cx20 さん情報で知った「モーション周期表」、これは素敵な！
●motiontable
https://t.co/09Wb0TVgJn
●About
https://t.co/wU6lMWkilt基本的な要素を、実際の動作込みで一覧で見られるのがすごくいいな。
— you (@youtoy) June 29, 2022
つっつきボイス:「周期律表っぽく見えますが、クリックするとモーショングラフィック要素の解説が表示されます」「へ〜」「何で作ってるんでしょうね？」「Aftereffectsだそうです」
参考: Adobe After Effects | VFXとモーショングラフィックスソフトウェア
「ところで要素の並びや軸に何か意味がありそうな気がする」「Aboutを見ると、類似した要素を縦に並べて、重要な要素を上に配置してるとありますね」「デザインの意図を説明するの大事」「中身わからないけど見ているだけでも楽しい」「辞書的に参照できる資料があるのはいいですね」
![🔗]()
Flexboxでルビを振る（Hacklinesより）
[Blog Post] Flexbox Furigana https://t.co/jYI5lRt0iw #Japanese #HTML #CSS #日本語 #振り仮名
— Paul Fioravanti (@paulfioravanti) June 25, 2022
つっつきボイス:「この記事はHacklinesというサイトでRuby関連の記事をクロールしていて見つけたんですが、たぶんルビ（Ruby）で引っ掛けたんだと思います」「そういえばスペル同じなのか」「イタリア人のようですが、日本語のルビを頑張って追求している感じですね」
参考: ルビ – Wikipedia
<!-- 同記事より -->
<ruby lang="ja" style="display: inline-flex; flex-direction: column;">
<span style="display: inline-flex;">
<ruby lang="ja">
乗
<rp>(</rp>
<rt>の</rt>
<rp>)</rp>
り
</ruby>
<ruby lang="ja">
込
<rp>(</rp>
<rt>こ</rt>
<rp>)</rp>
む
</ruby>
</span>
<rt>norikomu</rt>
</ruby>
「EPUBをやっていると一度はこのあたりを追いかけることになりますね: このW3Cの日本語組版要件↓はEPUB関係者必読のドキュメントで、自分も興味本位で読んでみたことがあります」「お〜」
参考: 日本語組版処理の要件（日本語版）
「グループルビとかモノルビとか知らない言葉がいっぱいありますね」「こういう用語を調べるのには便利ですよ」「利用許諾と書いてライセンスと読む」「本気と書いてマジと読む」「敵と書いて”とも”と読む」「中二病御用達の機能」
www.w3.orgより
「圏点とか割注処理なんかもめちゃくちゃ詳しく記述されている」「こういう資料を一度読んでみると日本語組版がどれだけ大変かがよくわかりますね」
「このW3Cの仕様にない機能をEPUBで必要とする出版社は多いんですよ: だからこそBPSがやっている超教科書などの超シリーズが求められたりするわけです↓」
![🔗]()
言語/ツール/OS/CPU
![🔗]()
2022年度Stack Overflow開発者アンケート結果が発表
つっつきボイス:「今年もStack Overflowのアンケート結果が発表されていました」「流し見た感じでは、業務で使っている人が多そうかな」
「その他フレームワークで.NETの人気が高いですね」「Windows系の言語やツールは、使っている人はものすごく多い割に出てくる情報が少なくて、質問する人が圧倒的に多い印象があるかも」「業務絡みで出せない情報も多そうですけど、情報公開にあまり熱心でない感じなのかな？」
「ZoomとMicrosoft Teamsが競り合っているのも面白い」
「OSはWindowsが多いのはわかるけど、Linuxベースが仕事でも個人利用でもかなり多いのが不思議」「自分みたいに仕事とプライベートの区別があんまりない人が多いだけだったりして」「macOSは以前よりも割高になったせいかLinuxベースより少なくなってる」
「言語ではRustが人気ですけど、もしかすると他人の書いたRustのコードをメンテナンスする機会がまだ少ないだけなのかなという気もしています」「それあるかも」「長く使われているメジャーな言語ほど他人のコードをメンテする方が多くなりますよね」「新規で書くよりメンテの方がつらいですもんね」「個人的にはDelphiがかなり上位につけているのが驚き」
「DBはPostgreSQLが人気か」「MySQLの低さ…」「自分もそうでしたけど、大規模なシステムを作るようになるとMySQLでできなくてPostgreSQLでできることが多いことに気づくようになりますね」「まあたしかに」「あとMySQLはセットアップが楽な点がアピールしましたけど、今はDockerでやるからPostgreSQLでもセットアップの手間は変わらなくなったのもあるかも」
「ついでに以下も似たような感じの言語比較記事ですが、こちらは最近の求人情報ベースだそうです↓」「C++がエントリーしているのは、単に求人側の利用経験言語の中に実際に使う言語とセットでとりあえず書いておく的な立ち位置でよく登場するからというだけじゃないかなぁ」「C++を書く仕事ってそこまで多くなさそうな気もしますよね」「最後のグラフを見ると1年の間でも意外に言語の上がり下がりが大きいですね」
I scraped 7M dev jobs for 8 months and these are the most demanded languages https://t.co/A1NNfxylmb (https://t.co/9Er64TNxzU)
— Hacker News 20 (@betterhn20) June 29, 2022
後編は以上です。
バックナンバー（2022年度第3四半期）
今週の主なニュースソース
ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSやruby-jp SlackやRedditなど）です。
Ruby Weekly
Hacklines
Postgres Weekly
The post 週刊Railsウォッチ: 6月のRubyコア動向、Stack Overflowアンケート結果ほか（20220705後編） first appeared on TechRacho.
週刊Railsウォッチについて
TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ）