Rubyのobject_idを入口にして、Rubyの実装詳細について学びます。
今年もRubyKaigiに協賛させていただきました! Flatt Security 執行役員CCO / プロフェッショナルサービス事業部長の @toyojuni です。先日沖縄県那覇市で開催されたRubyKaigi 2024の振り返りと皆様への感謝の気持ちを込めて本記事を執筆します。 昨年に引き続いて、Flatt SecurityはRubyKaigiにPlatinum Sponsorとして協賛し、ブースを出展させていただきました。ありがたいことに、3日間でのブース訪問の延べ人数は500人を超え、様々なRubyistの方との接点を持てたと感じています。 そんな今回のブース出展の軸と言える企画が「YAMLパース占い」でした。 Flat Securityは明日から始まる #RubyKaigi 2024に協賛させていただきます!ブースでは新企画「YAMLパース占い」を実施します🔮 与えられたYA
こんにちは!ファインディでTeam+開発チームのEMをしている浜田です。 以前公開した記事「ファインディはRubyKaigi 2024 にPlatinum Sponsorsとして協賛します!」で紹介した通り、ファインディはRubyKaigi 2024に協賛しており、現地で参加してきました! tech.findy.co.jp 今週(5/20〜25)はRubyKaigi 2024の振り返りも兼ねてRubyKaigiに関連した記事を投稿していきます! この記事では、私が聞いたセッションの中の1つ「Unlocking Potential of Property Based Testing with Ractor 」で紹介されたGem「PBT」を試してみたので共有します。 Unlocking Potential of Property Based Testing with Ractor 「Unloc
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Performance impact of the memoization idiom on modern Ruby | Rails at Scale 原文公開日: 2024/02/14 原著者: Jean Boussier(byroot) CC BY-NC-SA 4.0 Deed | 表示 - 非営利 - 継承 4.0 国際 | Creative Commons Ruby 3.2における主要な内部変更のひとつに、オブジェクトシェイプ(object shape)の導入があります。 本記事では、オブジェクトシェイプが導入された理由、仕組み、制限事項について解説します。 🔗 オブジェクトのインスタンス変数はどのように保存されるのか Rubyは非常に動的な言語なので、インスタンス変数へのアクセスという単純な操作でも多くの作業を伴います
Ruby 3.3がリリースされた。YJITには非常に多くの改善が含まれたリリースだったが、 NEWS解説記事やリリースパーティーでは 2点しか触れられなかったので、この記事ではRuby 3.3でYJITがどう改善されたかについて解説する。 YJITは既に実用段階 YJITはRuby 3.1で導入されたが、Ruby 3.2の時点でexperimentalのマークが外れ、実用段階となった。 Ruby 3.2では、以下のような企業で性能改善が報告された。 DeNA: 40% 高速化 GMOペバボ: 18% 高速化 STORES: 6.5-7.5% 高速化 Timee: 10% 高速化 メドピア: 2.8% 高速化 BOOK☆WALKER: 20-30% 高速化 Discourse: 15.8-19.6% 高速化 Lobsters: 26% 高速化 CompanyCam: 20-40% 高速化 弊
Ruby 3.3.0 が公開されました。Ruby 3.3ではPrismという新しいパーサーの追加、新しいパーサージェネレーターであるLramaによるBisonの置き換え、RJITという新たなJITの仕組みを追加、YJITの高速化など様々な改善が行われています。 Prism default gemとしてPrismパーサを導入しました。 Prismは、Ruby言語のためのポータブルで、エラートレラントで、保守可能な再帰下降パーサです。 Prismは本番環境で使用する準備が整っており、積極的にメンテナンスされています。Ripperの代わりに使用することができます。 Prismの使用方法については、詳細なドキュメンテーションがあります。 Prismは、CRubyに内部的に使用されるCライブラリと、Rubyコードを解析する必要がある任意のツールに使用できるRuby gemの2つのコンポーネントを持っ
これはRubyアドベントカレンダーとSmartHRアドベントカレンダーの17日目の記事です。 qiita.com qiita.com 12/9 に nagano.rb で文字について発表して、同じのを 12/15 に SmartHR 社内で LT しました。 スライドはこちら speakerdeck.com 同じ文字? この2つの文字は同じものに見えますか? 実はこれは同じ文字を異なるフォントで表示したものです。 ゴシック体と明朝体で字体が異なって見えるのと同じことなので、同じ文字と言えるでしょう。 コンピュータで扱う文字は文字ごとに番号(コードポイント)が振られていて、プログラムから見たときには同じコードポイントであれば同じ文字として扱われます。 Ruby で文字のコードポイントを得るには String#ord を使用できます。 '直'.ord.to_s(16) #=> "76f4" '
こんにちはかねこです。私はCRuby(ruby/ruby)のコミッタをやっているのですが、最近はCRubyをメインのターゲットとしてLALR parser generator Lramaの開発をしています。 現役のLALR parser generator開発者として、日頃私以上にLR parserのことを考えている人はそうはいないでしょう。 この記事を読んでいる皆さんは構文解析、なかでも特にLR parserを理解するためにいろいろな教科書や記事を読んできたと思います。 一方でどんなに調べてもどこか腑に落ちない部分が残っているのではないでしょうか。 LR構文解析を勉強すると構文解析表に出会うとおもいます。 構文解析表を作る方法そのものは教科書に説明が載っており、その通りに手を動かせばこのような表を作ることはできるでしょう。 また出来上がった構文解析表をもとに実際に構文解析する手順も理解で
シングルスレッドやマルチプロセスなどの並行処理の話について、 すぐに忘れてしまいます。 どうしたらもっと知識が定着すると思いますか? 色んなライブラリーでAPIサーバーを立ててパフォーマンスの差などを見てみたりするのですが、結局よくわかりませんでした。 フレームワークに頼って実装していると、そのフレームワークが内部でどの様な仕組みで並列または並行処理しているのかが理解できず、ただ使っているだけの状態になり得ます。 フレームワークの設計者からすると、プログラマがそれらを気にしなくても利用できるというのがプロジェクトのゴールでもあるので、それはそれで正しいのですが「並列処理」や「並行処理」を理解したいというモチベーションでは逆にそれが邪魔をしてしまうかもしれません。 並行処理や並列処理を学ぶのであれば、API サーバ等といった物ではなく、コード片で学び始めるのが良いと思います。 例えば Rub
年月の範囲をDateクラスで扱うのがダルい... 2023年1月、2023年2月...と月単位のラベルを持つグラフを作る 2023年1月号、2023年2月号...と月単位で提供される雑誌を扱う といった、年月を扱うケースでは、ただのDateクラスではちょっと役不足ですよね。例えば以下のようなコードを考えてみます。 require 'date' start_year_month = Date.new(2023, 9, 1) today = Date.today latest_year_month = Date.new(today.year, today.month, 1) # # 期間でループしたいとき # tmp_month = start_year_month while tmp_month <= latest_year_month pp tmp_month.strftime('%Y%m
「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。 「読める」になるために 言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。 Ginza Rails27 igaiga - Speaker Deck 著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。 たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。 できることを知る るりま (Ruby リファレンスマニュアル) の Enumerable、String Rails Guides の Active Support Core Extensions 日本語
参加しているプロジェクトで、RailsアプリのCIの高速化を行った。 まだ進行中の部分も幾つかあるが、結果から言うと、元々8分前後だったテストが3分半程度に短縮された。行った作業を幾つかの観点に分け、どのように高速化を行ったか、どの程度高速化されたか等を記述する。 プロセス数とマシン性能の調整 元々は2コア1プロセス4マシンで8分程度掛かっていたが、8コア8プロセス1マシンに変更することで5分程度に短縮された。 このプロジェクトではCIにGitHub Actionsを利用している。GitHub Actionsではデフォルトで2コアのマシンが利用されるが、Large runnerを利用して8コアに変更した。費用は変わらない。 また同時に、8プロセスで並列実行するためにparallel_testsを導入した。このプロジェクトではMySQLとElasticsearchを利用しており、またファイル
Ruby on Railsの作者として知られるDavid Heinemeier Hansson氏は、コンテナ・デプロイ・ツール「Kamal 1.0」を9月19日(現地時間)に公開した。同氏は開発したWebサービスをクラウド・プロバイダーから自前のサーバーに移行する手続きを進めており、Kamalはその手続きの中で生まれたという。KamalはMITライセンスで公開しているオープンソース・ソフトウェア。 Kamalは、Dockerでコンテナ化したアプリケーションを配備するツール。設定ファイルに外部の公開IPアドレスを記入して起動すれば、Linuxが動作するコンテナが動き出す。このコンテナにはSSHで接続することも可能だ。 Hansson氏はKamalをWebアプリケーションをクラウドから自前のサーバーに移す目的で使用しているが、クラウド間での移動など、ほかの目的にも利用できる。Kamalを利用す
Ruby 3.2 YJIT is Battle-Tested Shopify deploys YJIT on business-critical services in production, such as Storefront Renderer, the software that powers all online storefronts on Shopify’s platform, and Shopify’s Monolith. As of the Ruby 3.2 release, YJIT sped up our Storefront Renderer by 10% on average. Storefront Renderer is a complex application. Your more reasonable-sized app might get better/w
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
技術部の笹田です。今日で退職するので、バタバタと返却などの準備をしています。 本記事では、Rubyの並行並列処理の改善についての私の取り組みについて、おもに RubyKaigi 2022 と 2023 で発表した内容をもとにご紹介します。 並行と並列はよく似た言葉ですが、本記事では次のような意味で使います。 並行処理(concurrent processing)は、「複数の独立した実行単位が、待っていればいつか終わる(もしくは、処理が進む)」という論理的な概念で、古典的にはタイムシェアリングシステムなどが挙げられます。 並列処理(parallel processing)は、「複数の独立した実行単位のうちのいくつかが、あるタイミングで同時に動いている」という物理的な概念で、古典的には複数のCPU上で同時に実行させる、というものです。最近では、1つのCPU上で複数コアが同時に動いている、という
先日、携わっているサービスで一番大きいRailsアプリをRuby 3.2にアップデートし、YJITを有効化できました。 方針を検討した結果、今回はRails 6.1およびPsych 3系のままRuby 3.2にアップデートする戦略をとったため、その手順をまとめます。 先週にメインのサービスをRuby 3.2にしてYJITを有効にできました! 実際に速くなったし嬉しい大YJIT記念日だ🎉 https://t.co/Wkhc6fDfj9 — Hiroshi Shimoju (@shimoju_) July 19, 2023前提#今回のRailsアプリはサービスの機能がほぼすべて詰まっているモノリスで、歴史も8年と比較的長いです。 アップデート前のバージョンはRuby 3.0、Rails 6.1で、Psychは3系。 正攻法では、おおむね以下の手順でアップデートを進めていくことになります。 R
RubyのJITコンパイラYJITを開発している弊社Shopifyでは、社内で最もトラフィックが多いストアフロントのアプリにRuby 3.3 (master) をデプロイして平均レスポンスタイムが16%高速化、社内で最も大きなアプリであるモノリスにRuby 3.2をデプロイして平均レスポンスタイムが9%高速化している。他の会社でも、YJITを本番で有効にしたら高速化したという事例をちらほら目にした。 一方で必ずしも良い報告ばかりではなく、YJITを有効化したらメモリを使い切ってしまったりだとか、遅くなったみたいな報告も目に入ることがある。こういった問題は我々も多かれ少なかれ経験しており、それぞれ適切に対処することで解決できたため、その知見を共有する。*1 メモリを使い切ってしまった時 zenn.dev YJITを有効化すると、YJITが生成する機械語に加えて、それに関するメタデータもメモリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く