週刊Railsウォッチ(20190415-1/2前編)Railsバージョンアップに便利なstill_life gem、Zeitwerkの改修進む、named_capture追加ほか

こんにちは、hachi8833です。RubyKaigi 2019はもう目前ですね。


つっつきボイス:「(つっつき時点→)RubyKaigiもう来週ですか!」「早いな〜📅」「改めて説明すると、RubyKaigiはRubyのコアな話を3日間にわたって聞ける年1回開催のカンファレンスです」「ここ数年は日本の地方都市を巡回していて、今年は博多で開催されます」「今回は参加しませんが、もし行ってたらコアな話についていけるかしら😅」「そこも楽しさのひとつだと思います❤️: 『ここまでやる人がいるんだ』みたいな驚きがありますし」「個人の感想ですが😆、参加するたびにモチベが急上昇しました📈: 自分も何かやれるんじゃないかという気持ちが沸々とわいてくるというか」

RejectKaigi2019も東京博多の同時開催で盛り上がったようです。

  • 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
  • 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄
  • 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください

Rails: 先週の改修(Rails公式ニュースより)

今回はコミットログから見繕いました。

モデルJOINのbelongs_toのautosave: trueで無効なレコードが保存される問題を修正

  • autosave: trueの循環を修正

インスタンス変数ではなく、activerecord/lib/active_record/autosave_association.rbsave_collection_associationメソッドでローカルな変数を使うようにする。

以前は、autosave: trueがいくつも循環していた場合に、has_many関連付けのコールバックが、同じ関連付けの同じコールバックの別のインスタンスが実行完了していないにもかかわらず、実行されてしまっていた。
コールバックの最初のインスタンスに制御が戻った時点でインスタンス変数が改変され、以後、関連するレコードが正しく保存されなかった。特に、has_manyに対応するbelongs_toのIDフィールドがnilになる。
同PRより大意


つっつきボイス:「autosave: trueってやったことない😅」「↓ここがポイントのようです」

# activerecord/lib/active_record/autosave_association.rb#L385
+         # インスタンス変数をローカル変数に保存することで
+         # コールバック全体をリエントラントにして#28080を修正する
+         new_record_before_save = @new_record_before_save
...
-         if records = associated_records_to_validate_or_save(association, @new_record_before_save, autosave)
+         if records = associated_records_to_validate_or_save(association, new_record_before_save, autosave)

「インスタンス変数をいったんローカル変数に入れる…?パッと見あまり意味がなさそうに見えるけど、マルチスレッドの文脈でインスタンス変数が共有されておかしくなってたのを修正したとかそんな感じかな?🤔」「インスタンス変数が他から変更されてたのに保存できちゃってたとか」「そういう感じですね」「その割にはdupしてないしな〜: インスタンス変数を引き回さないという意味でこの書き方は正しいんだけど、これでバグが直るのかどうかまだピンとこない😅」「とりあえず次行きましょう〜」

よく見たら2017年2月にオープンしたプルリクなので長い旅でしたね。久しぶりにy-yagiさんブログを覗いてみました。

参考: rails commit log流し読み(2019/04/10) - なるようになるブログ

autosave: trueが指定されている、かつ、参照が循環しているassociationがあった場合に、idの指定が無い不正なjoin recordが生成されてしまうバグがあったのを修正しています。
同ブログより

==とハッシュメソッドのアロケーションを削減

# 同PRより
Warming up --------------------------------------
          Orginal ==    66.978k i/100ms
       Orginal #hash    38.182k i/100ms
              New ==   165.441k i/100ms
           New #hash   145.549k i/100ms
Calculating -------------------------------------
          Orginal ==    846.966k (± 4.4%) i/s -      4.287M in   5.073426s
       Orginal #hash    457.440k (± 7.2%) i/s -      2.291M in   5.038573s
              New ==      2.877M (± 7.3%) i/s -     14.393M in   5.032400s
           New #hash      2.366M (± 8.1%) i/s -     11.789M in   5.018887s

つっつきボイス:「3倍から5倍ぐらい速度改善してますね🚅」「ダブルイコール!」「改善前はattributes_for_hashでいっぱいオブジェクトが作られてたということかな?」

# activerecord/lib/active_record/connection_adapters/column.rb#L64
      def ==(other)
        other.is_a?(Column) &&
-         attributes_for_hash == other.attributes_for_hash
+         name == other.name &&
+         default == other.default &&
+         sql_type_metadata == other.sql_type_metadata &&
+         null == other.null &&
+         default_function == other.default_function &&
+         collation == other.collation
      end
      alias :eql? :==

      def hash
-       attributes_for_hash.hash
+       Column.hash ^
+         name.hash ^
+         default.hash ^
+         sql_type_metadata.hash ^
+         null.hash ^
+         default_function.hash ^
+         collation.hash
      end

+     protected
+
+       def attributes_for_hash
+         [self.class, name, default, sql_type_metadata, null, default_function, collation, comment]
+       end
    end

#==の修正後は&&で結んでますね」「個人的にはここで&&で結ぶのはあまり好きじゃなくて、attributes_for_hashで書きたい方ではある: 項目がどんどん増えたらここに足すのってあまり見た目が麗しくないというか」「それもそうですね」「これ以上項目が変わらないならともかくですが☺️」

#hashの方は^でつないでますね」「^ってなんだっけ…論理演算か」「XOR!」「attributes_for_hash.hashの右の#hashは、ハッシュ値のハッシュですね: 左はRubyのデータ構造としてのハッシュ」「右と左でhashの意味が違うってややこしい〜😭」「こわ〜い😅」

参考: ハッシュ関数 - Wikipedia

attributes_for_hashが削られたということはコストが高かったんかな〜: attributes_for_hashって配列を返してたから、配列のコストが高かった?」「あーそうか!変更後みたいに直に比較しちゃえばアロケーションが発生しないと」「個人的にはmapでやってもいいんじゃね?と思ったりもするけどっ😆」

「項目が固定しているから直接比較しようという、絵に描いたようなチューニングですね: 業務コードとかだとこう書きたくはない気持ち☺️」「どうやらここではメモ化も効かなさそうか」

「これまで話を聞いてきてだんだん見えてきたんですけど、最初から最適化でやろうとしないのが大事なんですね」「そうそう😋: 最初から変に速度出そうとすると、ぴよコード🐣が量産されちゃって読むのも直すのもつらくなるから、最初は素直に書こうね💯」

ルーティングに named_captureを追加

# actionpack/lib/action_dispatch/journey/path/pattern.rb#L139
+         def named_captures
+           @names.zip(captures).to_h
+         end

つっつきボイス:「ビーバー大好きな@baweaverさんが足した、名前付きキャプチャだけ取り出す機能みたいです」「名前付きキャプチャって何だっけ😆」「正規表現でたまに使う、かっこ()内のマッチを$1とか\1みたいに登場順序の数字で参照する代わりに、たとえば(?<名前>正規表現)と書くと\k名前みたいに名前で参照できるヤツですね」「それか!」「名前付きキャプチャは使いすぎると読みづらくなるし、正規表現ごとに方言があってめんどくさいんで自分はあまり使いませんが😭」

# actionpack/test/journey/path/pattern_test.rb#L284
+       def test_named_captures
+         path = Path::Pattern.from_string "/books(/:action(.:format))"
+
+         uri = "/books/list.rss"
+         match = path =~ uri
+         named_captures = { "action" => "list", "format" => "rss" }
+         assert_equal named_captures, match.named_captures
+       end

参考: 正規表現で名前付きキャプチャを使う - Qiita

「それを、正規表現の方で名前さえ付けておけばいきなりハッシュで取れるということね😋」「名前付きキャプチャをいちいち正規表現で取り出さなくても、最初からハッシュの形で取れるのがよさそう😍」「ショートハンド増やした感」「zipは引数を配列の配列に変換するのか」「それをto_hしてるだけ」

参考: instance method Array#zip (Ruby 2.6.0)

自身と引数に渡した配列の各要素からなる配列の配列を生成して返します。 生成される配列の要素数は self の要素数と同じです。
ブロック付きで呼び出した場合は、 self と引数に渡した配列の各要素を順番にブロックに渡します。
ruby-lang.orgより

# ruby-lang.orgより
p [1,2,3].zip([4,5,6], [7,8,9])
    # => [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

Zeitwerkの互換用ActiveSupport::Dependenciesでのautoloaded_constantsautoloaded?の実装をやめた

ZeitwerkのActiveSupport::Dependenciesの互換性インターフェイスでautoloaded_constantsautoloaded?を実装しなくなった(元々ドキュメントないし)。実験したところ、introspectionのユースケースはさして多くないし、トラブルシュートはログで行われる。この設計上のトレードオフにより、どの環境でもメモリ使用量が削減される。
Xavier Noria

# activesupport/lib/active_support/dependencies/zeitwerk_integration.rb#L24
-       def autoloaded_constants
-         cpaths = []
-         Rails.autoloaders.each do |autoloader|
-           cpaths.concat(autoloader.loaded_cpaths.to_a)
-         end
-         cpaths
-       end
-
-       def autoloaded?(object)
-         cpath = object.is_a?(Module) ? object.name : object.to_s
-         Rails.autoloaders.any? { |autoloader| autoloader.loaded?(cpath) }
+       def to_unload?(cpath)
+         Rails.autoloaders.main.to_unload?(cpath)
        end

つっつきボイス:「こういう改修するにはいいタイミングかも😋」「ZeitwerkはRails 6で新しく入るオートローダーです↓」「と週刊Railsウォッチに書いてあった😆」

Rails 6 Beta2時点のZeitwerk情報(要訳)

「morimorihogeさんの説明を記憶ベースで再現すると、現在のRailsでは名前空間とか定数読み込み順序で、たまにとてもわかりにくいバグが発生することがあって↓、Zeitwerkはそのあたりを解決するためのものだそうです」

週刊Railsウォッチ(20181022)Railsの名前空間地獄とrequire_dependency、PostgreSQL 11がリリース、clean-rails.orgほか

「Zeitwerk(ツァイトヴェルク)という名前はスイスの時計メーカーから取ったようで、日本的な感覚で言うとセイコーみたいな感じでしょうか😆」「それ以前に文字から発音がわからないです😆」「ドイツ語のZ(ツェット)って英語のZ(ズィー、ゼット)よりずっと軽くて、逆にSの方がズみたいに濁る感じですね」「逆さま感🙃」「あとドイツ語のWは英語のVに近い感じで、Wolfもドイツ語っぽく言うとヴォルフみたいな音になりますね: そういう変換をかけるとドイツ語っぽくなるといえばなります😆」

参考: Z -ツェット- - Wikipedia
参考: 誤用戦士ガンダム・荒野を走るニセドイツの列! | ドイツ情報満載 − Young Germany Japan by ドイツ大使館 — 名エッセイです❤️

カラムオブジェクトからtable_nameを削除して身軽に

# activerecord/lib/active_record/connection_adapters/column.rb#L5
  module ConnectionAdapters
    # An abstract definition of a column in a table.
    class Column
-     attr_reader :name, :default, :sql_type_metadata, :null, :table_name, :default_function, :collation, :comment
+     attr_reader :name, :default, :sql_type_metadata, :null, :default_function, :collation, :comment

つっつきボイス:「kamipoさんのconnection_adapter修正です」「リファクタリング?」「table_nameを削ってるから違うっぽい」「オブジェクトひとつ削ったけど他でできるからいいよね、みたいな」

「カラムはテーブル名と依存関係が元々あるから、カラムにいちいちtable_name置かなくてもわかるでしょというのはワカル」「たしかに〜」「カラムはテーブルに紐づくんだからカラム単独で何かするというのも考えにくいし、単独で使ったとしてもそこでtable_nameが欲しいとも考えにくいし」「今までカラムの数だけtable_name持ってたとしたら冗長ですね」「設計上はカラムでtable_name持つ可能性がないわけではないけど、実用上いらないんじゃね?という感じ☺️」

Doc: t.integert.bigintに修正

# guides/source/association_basics.md#L394
    create_table :accounts do |t|
-     t.integer :supplier_id
+     t.bigint  :supplier_id
      t.string  :account_number
      t.timestamps
    end

つっつきボイス:「ドキュメントのt.integert.bigintに書き換えるという修正です: これ、ある時期に変わってましたよね?」「そうそう、変わってた↓」「うっかり真似されないようにしないと☺️」

そういえばこんなツイート↓を昔のウォッチに貼りました。

「integerだと基本的に桁数が足りなくなる可能性があるんですよ」「IDとかはbigintにしておかないと、最初のうちはよくても忘れた頃に足りなくなるみたいな」「なのでデータベースのIDでintegerは割とマズいですね🧐」

「その意味で、UUIDって型できないかな〜🥺って思うし」「それ欲しいかも!」「特にRailsだとURLに出てくることが多いから、UUIDの方が適切な場合ってあるんですよね」「記事のページぐらいだったらURLに数字出てもいいけど、ユーザーIDとか生で出したくないし」

参考: PostgreSQL 10.5文書 8.12. UUID型
参考: UUID() — MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.18 その他の関数
参考: Rails の UUIDプライマリキーを試す - Qiita

RailsのモデルIDにUUIDを使う(翻訳)

Rails

マイグレーションで本番データに触る方法(Ruby Weeklyより)

# 同記事より
class AddSlugsToPosts < ActiveRecord::Migration[5.2]
  # 最初に、データのマイグレーションに使うモデルを定義
  class Post < ActiveRecord::Base
    belongs_to :user
  end

  class User < ActiveRecord::Base
    has_many :posts
  end

  def up
    # 次にカラムを追加してNULL許容にする
    add_column :posts, :slug, :string, null: true

    # 次に新しいカラムがモデルに拾われるようにする
    Post.reset_column_information!

    Post.includes(:user).find_each do |post|
      # 次にslugをセットしてpostをsave
      post.slug = post_slug(post)
      post.save!
    end

    # 次にカラムをNull非許容にする
    change_colum_null :posts, :slug, false
  end

  def down
    remove_column :posts, :slug
  end

  def post_slug(post)
    # 重要: productionのモデルから、マイグレーションの書き込みに使った
    #      title-to-slugアルゴリズムをコピーすること
  end
end

つっつきボイス:「この記事の人は、マイグレーションの中でActive Recordモデルを作るというやり方をしてるみたいです」「あ〜こういうのをマイグレーションの中で使ってるのか: 何だかよくない気はするけど、やりたい気持ちはワカル気がする」

「記事の中でreset_column_information!ってのやってる😳: こんなのあったのね↓」

参考: migration の中で model を触ったら必ず reset_column_information する - onk.ninja

「どうやらこの人がやりたいのはデータマニピュレーションなのね」「スキーマではなく、ということなのでそうみたいです」「う〜ん、これはマイグレーションでやることと違う気がするな〜: 自分はRailsのマイグレーションにはDDL(データ定義言語)を書くべきであって、DML(データ操作言語)は別のところに書くべきだと思ってるし」「DDLやDMLって、データベーススペシャリストの試験問題に出てきましたね」「そうそう、SELECTやINSERTやUPDATEやDELETEがDMLに相当します🧐」

参考: SQLの種類(DDL、DML、DCL) | 酒と涙とRubyとRailsと

「記事の人はpost_slug(post)を書いてるからマニピュレーションしたいんだと思うんですが、マイグレーションでこれをやるのはアブナイ気がする🤢」「こういう操作はやっぱりバッチを書くべきですか?」「自分だったらバッチ書くな〜: まあそういう運用のシステムがないとも言えませんけど😆」

babaさんの以前の記事↓にも『Active Recordのモデルをマイグレーションで使わない方がいい』と書かれていたのを思い出しました。

[Rails 3] 失敗しないmigrationを書こう

「そうそう、記事にもあるけど、テーブルにカラムを追加したときってたいてい値が入ってて欲しいんですよ〜: こうやってみたい気持ちはワカル」「デフォルト値とか?」「でもデフォルト値では間に合わないこともあったりするんで、そういうときは2回マイグレーションしたりするんですよ」「あー、以前のウォッチ↓で、巨大なテーブルへのマイグレーションでいきなりデフォルト値とかの制約を付けると本番でその間テーブルがロックされるから作業を分割しよう、みたいな話がありましたけど、それですね」「そうそう☺️」

週刊Railsウォッチ(20190121)Rails 6.0.0 beta1リリース、Railsは2019年も「あり」か、Jetsでサーバーレス、ES2018の新機能、RSpecの心ほか

「たとえば最初はNOT NULL制約なしでカラムを追加して、別途バッチで値を入れて、それからNOT NULL制約を付ける、みたいにやるのが安全」「ですよね」「それをやりたくないとたぶんこの記事みたいなやり方になる😆」「😆」「いい悪いということじゃないんだけど、自分は作業を分割しないとコワい😆」

🌟still_life: テストの画面HTMLをRailsバージョンごとに保存(Ruby Weeklyより)🌟

@amatsudaさんがheavens_doorに続いてまた新しいgemを作りました。


つっつきボイス:「amatsudaさんの新作です: これヒットじゃないかと思うんですがどうでしょう?」「おぉ?」「Railsをバージョンアップするときにこれでテストを走らせて、そのバージョンで吐き出されるHTMLをバージョン名を付けて保存しておくというもののようです」「お〜なるほど!これはワカル〜😍」

# 同リポジトリより
% STILL_LIFE=rails52 rails test:system test
% tree tmp/html
tmp/html
└── rails52
    └── test
        ├── controllers
        │   ├── users_controller_test.rb-14.html
        │   ├── users_controller_test.rb-20.html
        │   ├── users_controller_test.rb-27.html
        │   ├── users_controller_test.rb-32.html
        │   ├── users_controller_test.rb-37.html
        │   ├── users_controller_test.rb-43.html
        │   └── users_controller_test.rb-9.html
        └── system
            ├── users_test.rb-14.html
            ├── users_test.rb-18.html
            ├── users_test.rb-21.html
            ├── users_test.rb-25.html
            ├── users_test.rb-26.html
            ├── users_test.rb-29.html
            ├── users_test.rb-32.html
            ├── users_test.rb-36.html
            ├── users_test.rb-37.html
            └── users_test.rb-9.html

4 directories, 17 files

「たとえばRails 5.1のとき、Rails 5.2のとき、とこうやって画面HTMLが保存されていれば、差分がないかどうかをチェックすることで無事バージョンアップされたかどうかを確認できるということですね」「テストがあればの話だろうけどっ😆」

「これならローカルでも気軽に動かせるし、結果が勝手にたまっていってくれるし、うん、これはいいですね~👍」「今までこれがなかったのが不思議」「画面出してくれるテストがあれば、それ以上みっちり書かれてなくてもやれますしね」「やってみたらバージョンアップでやんなるほど差分が出て目を覆いたくなったりして😆」「これは有能🥰」「標準で入っててもいいぐらいかも」

久しぶりに🌟を進呈いたします。ありがとうございます。

Beyond Compare↓とかWinMergeとかを使えばディレクトリごと差分をさっとビジュアルチェックできますね😋。

もうひとつのGUI diffツール「Beyond Compare 4」

Rolling Stonesの昔のライブ盤のタイトルが「Still Life」(平穏な生活)でしたね。

「前回のheavens_doorという名前も音楽ネタっぽかったんですが、今回のももしかしてそうかなと思って: amatsudaさんの音楽の趣味についてはまったく知らないので憶測です😅」「heavens_doorはアニメ系でちょくちょく見るような気も😆: JOJOにもヘブンズドアー出てくるし」「あーそっちかも!」「でもJOJOの元ネタがだいたいもろその時代のロックだったりするし😆」「ですよね: 今やキングクリムゾンってJOJOの方が知られてますし😆」

参考: 岸辺露伴のスタンド「ベブンズ・ドアー」は最強なのか!?能力考察まとめ
参考: キングクリムゾンのスタンド能力って結局なに?【ジョジョ5部ラスボスが強すぎる】 │ NazeNani JillTone

少し前に、本家King Crimsonのツイート↓にJOJOのそれが出てきて軽く話題になったのを思い出しました。

react-rails: RailsでReactをスマートに使う(React Statusより)

gem 'webpacker'
gem 'react-rails'

つっつきボイス:「react-railsって初めて見たんですが、WebpackerにもSprokectsにも対応してて、TypeScriptやES6やCoffeeScriptやJSXとも共存できると言ってます」「マジか!じゃ今やってるヤツにこれ入れればReactさっと使える?😆」「今更gemかというのは置いといても😆、★5000超えてるし」

リポジトリをよく見ると、reactjs公式なんですね。最も古いコミットは2013年でした。

「後はどこまで使えるかですね☺️」「どうなってもいいようなアプリで誰か試してみないかな😆」「どっかで使ってみよ」「React自体がアップグレードしたときにどうなるかも気になります😆」「それはある😆」

参考: ReactをRailsと共に使う方法 - Qiita

「ところでJSXって何でしたっけ?😆」「MSXではない(キリッ」「前にウォッチでJSXを取り上げたとき、JSXが2つあることに当時気づかなかったのを思い出しました😅」「どっちだったか忘れたけど、ちょっとキモい書き方だった気がする👻(ウォッチ)」「あ〜、タグの中にコード…イヤな予感😅」「ヤな予感しかしない😅」「ちっちゃく作る前提ならいいんでしょうけど☺️」

参考: Introducing JSX – React — ReactのJSX
参考: JSX - a faster, safer, easier JavaScript — DeNAが開発したJSX言語

よく見るRails APIは?


追いかけボイス:「このエントリをつっつくのを忘れてました💦」「そうだったかも☺️」「api.rubyonrails.orgでよく見るAPIって何かあります?」「そうねぇ、APIでというわけじゃないけどHashWithIndifferentAccessあたりはよくググるかも」「どもですっ♪」

参考: ActiveSupport::HashWithIndifferentAccess

その他Rails

 group :test do
-  gem 'selenium-webdriver'
-  gem 'chromedriver-helper'
+  gem 'webdrivers'
   # other test-only dependencies ...
 end

つっつきボイス:「chromedriver-helperwebdriversに置き換わるというアナウンスが正式に出ました」「ドライバ周りは幸いあまりかかわりなかったし😆」

Ruby

Rubyコードフォーマッター対決(Ruby Weeklyより)


つっつきボイス:「RuFoとplugin-rubyとrubyfmtあたりのフォーマッタを比較しています」「rubyfmtが2種類あるし」


つっつきボイス:「RuboCopやRipperの話なんかも混じえて…で結果は『ものによる』🤣」「結論じゃないし🤣」「判定を避ける🤣」「『個人的にはRuboCopかRuFo』だそうです😆」

「rubyfmtはgemですらないスクリプトファイル、RuFoはもう少し洗練されてて、pritter-rubyは最近JSで人気のprettierで動くみたいです」

Rubyにパッチを当ててテストを高速化(Ruby Weeklyより)

// https://bugs.ruby-lang.org/attachments/download/7717/ruby_gc_malloc_trim.patchより
diff --git a/configure.ac b/configure.ac
index d251da9915..5e2a67db1b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1825,6 +1825,7 @@ AC_CHECK_FUNCS(lstat)
 AC_CHECK_FUNCS(lutimes)
 AC_CHECK_FUNCS(malloc_usable_size)
 AC_CHECK_FUNCS(malloc_size)
+AC_CHECK_FUNCS(malloc_trim)
 AC_CHECK_FUNCS(mblen)
 AC_CHECK_FUNCS(memalign)
 AC_CHECK_FUNCS(memset_s)
diff --git a/gc.c b/gc.c
index 1331ef21dc..12caa162e7 100644
--- a/gc.c
+++ b/gc.c
@@ -6660,7 +6660,15 @@ gc_start(rb_objspace_t *objspace, int reason)

     gc_prof_timer_start(objspace);
     {
-   gc_marks(objspace, do_full_mark);
+        gc_marks(objspace, do_full_mark);
+#ifdef HAVE_MALLOC_TRIM
+        /* [Experimental] Explicitly free all eligible pages to the kernel.  See:
+         *
+         * - https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html
+         * - https://bugs.ruby-lang.org/issues/15667
+         */
+        if (do_full_mark) malloc_trim(0);
+#endif
     }
     gc_prof_timer_stop(objspace);


つっつきボイス:「テスト高速化のためにRubyにパッチ当ててみたそうです」「いかにもメモリをゴニョゴニョしてる感」「malloc_trim()とか何だかコワいもの持ち出してるし😆」「テストだからと割り切ってザクザク切り刻んでるんでしょうね🍴」「わかる〜」「普段はこれでテストちっちゃく回して週一くらいは普通のを回すとか」「どのぐらい信頼できるんでしょう😅」「記事を見ると、メモリ方面の強い人たちといっぱい議論したっぽいです💣」

参考: Man page of MALLOC_TRIM
参考: Cables vs. malloc_trim, or yet another Ruby memory usage benchmark - DEV Community 👩‍💻👨‍💻

その他Ruby


つっつきボイス:「mrubyバイトコードハンドブックは技術書典に出る本らしいです」

参考: [DL版]mrubyバイトコードハンドブック - Kishima Craft Works - BOOTH



つっつきボイス:「いい先生ですよね🥰」

Ruby trunkより

Rustのビルダーが欲しい


つっつきボイス:「RubyのC拡張みたいにRust拡張をビルドしたいということみたいです」「そのうち出てくるかも?」

Unicode 12.1.0がfinalに


つっつきボイス:「Unicode 12.1.0は、Unicode Consorciumが令和年号のためだけにわざわざリリースすることになってたヤツですね」「お世話かけてます!」「お疲れさまです!」「さーせん!」「😆」

参考: Unicode 12.1.0 — 現時点ではDRAFTです

「ちなみに年号はeraですね(Japanese era name)」「era知らないとリリースノート意味わからないし😆」

番外

ブラックホールの撮影に世界で初めて成功

参考: First Image of a Black Hole — GoogleのDoodleにも早速取り入れられています


つっつきボイス:「ニュースでも話題になってましたが、撮影そのものは2年ぐらい前で、それをビジュアライズするための数式に2年かかってたどり着いたということだそうです」「おぉ〜なるほど♪」

「あと、一般相対性理論を外宇宙で確認できたという意義もあったみたいです」「相対性理論を覆すのはなかなか大変😆」


今回は以上です。

おたより発掘

バックナンバー(2019年度第2四半期)

週刊Railsウォッチ(20190408-1/2前編)RubyKaigiの予習資料、Rails「今年ベストのプルリク」、numbered parametersの議論ほか

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

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

Rails公式ニュース

Ruby Weekly

React Status

react_status_banner

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

夏のTechRachoフェア2019

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ