OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。

OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
僕は以下の3つのツールを複数プラットフォーム向けにクロスコンパイルしてバイナリ配布しており、以下のように全て異なる言語で開発している。 Go: sqldef Rust: xremap mruby: mitamae クロスコンパイルに苦労している話をするとZigを使ってみたらいいんじゃないかと言われることがあり、周りでもZigが何となく流行り始めた気がするので、これらのツールに実際自分で使ってみてどうだったかという事例を紹介したい。 Zigとは Zigはそもそもプログラミング言語なのだが、C/C++とのinteropがやりやすい言語なようで、おそらくそれに必要でLLVMベースのC/C++ツールチェインが同梱されていて、しかもそれをDrop-In Replacement for GCC/Clangとして売りにしている。 僕はZig言語そのものにはそれほど興味はないのだが、クロスコンパイラとして
distrolessは、Googleが提供している、本当に必要な依存のみが含まれているcontainer imageです。そこにはaptはおろかshellも含まれておらず、非常にサイズの小さいimageとなっています。余計なプログラムが含まれていないことは attack surfaceの縮小にも繋がり、コンテナのセキュリティについての事業を展開しているSysdig社が公開しているDockerfileのベストプラクティスとしてもdistroless imageを使うことが推奨されています。 Dockerfileのベストプラクティス Top 20 | Sysdig 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor’s blog また先日、inductorさんがこのようなブログ記事を書き話題になりました。この記事からdistroless ima
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
TL;DR 『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』 でRailsを高速化させる素晴らしいハックが紹介されましたが。いまや有効なハックではなくなりました。 TZハックさん、ながい間(2日間)おつかれさまでした。 はじめに アカツキさまで技術顧問をさせていただいている小崎です。 このエントリは『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』をRubyコミッタが読んだらこうなったというアンサーソングになっています。合わせてお読みください TZ環境変数でTime.newが10倍近く速くなるのは素晴らしい発見ですが、コミッタとしてはTZなしでも速くなって欲しいなと思いました。だってめんどうだし。 現状分析 まず問題のテストプログラムを軽く分析してみましょう % strace -c ruby .
Rubyコミッター・笹田耕一に世代別インクリメンタルGCを発想したプロセスを聞いてみた Rubyのフルタイムコミッターである笹田耕一さんに、Rubyの処理性能を向上させるいくつかのブレイクスルーをどのように解決し、どのような困難があったのかを聞きました。 直感的な文法や生産性の高さから、世界中の人々に愛されるオブジェクト指向スクリプト言語Ruby。その黎明期から現在に至るまで、大きな変化を遂げてきた要素があります。“処理速度”です。数々の最適化が行われた結果、Rubyの処理性能はかつてとは比べものにならないほど向上しました。 その改善を支えたのは、世界中のRubyコミッターたち。中でも、性能向上において多くの成果を残してきたのが、クックパッド株式会社でフルタイムRubyコミッターとして働く笹田耕一(ささだ・こういち/ @koichisasada )さんです。本稿では、彼がいかなる設計方針に
Ruby Core Development 2019というタイトルでRubyKaigiのCFPにプロポーザルを書いたのだが、 もう一つ書いた方の話が採択されたのでその話はしなかった。 さて、今日はRubyコア*1の開発がSubversionからGitに移った節目でもあったので、そっちのトークで言いたかったことの一部を記事にしておこうと思う。 Subversion → Git 移行 [Misc #14632] 去年くらいから @hsbt さんが cgit というGitフロントエンドを使ってGitリポジトリの準備を始め Misc #14632、ついに今日正式にcgitの方がupstreamになった。平成の時代でSubversionでのtrunkのRubyコア開発は幕を閉じた。 この辺を進めているのは主に @hsbt さんな中、僕がこれを偉そうに書いたり今回のRubyKaigiで壇上でアナウンス
Ruby1.8.5、1.8.6、1.8.7のリリースマネージャを務め、現在は株式会社マネーフォワードでフルタイムのRubyコミッター職として働く卜部昌平(うらべ・しょうへい/@shyouhei)さんは、deoptimizationと呼ばれるアプローチを用いてRubyの高速化に取り組んでいます。 本稿ではその足跡から、いかなる思想のもとでデザインや実装を行っているかを、卜部さん本人が解説します。 Deoptimizationの着想に至るまで デザインとは、やらないことを決めること 「最適化が間違っていたら、戻す」をどう実装するか? インストラクションを消し、跡地をnopで埋める 「メソッド呼び出しが省略可能であること」を判定するために 省略可能な呼び出され方を増やす 大き過ぎる問題ではなく、実現できる規模の問題に取り組む Deoptimizationの着想に至るまで 言語を高速化するときに、
RubyKaigi の後夜祭で、akr さんが「327 種類の Ruby をビルドする方法 〜0.49 から 2.6.0-preview2 まで〜」という発表をされていました。 RubyKaigi 2018 After Party で話したスライドです: 「327 種類の Ruby をビルドする方法 ~0.49 から 2.6.0-preview2 まで ~」https://t.co/J5MXgM2PNN— Tanaka Akira (@tanaka_akr) 2018年6月4日 その中で、ruby-0.62.tar.gz と ruby-0.63.tar.gz のファイルは「gzip 形式じゃないといわれて展開できない」ということで、ビルド対象から外されていました。 いろいろやって、めでたくこの 2 ファイルを復活させることに成功しました。そのプロセスを書きます。 なお、壊れていたファイルも
Koichi Sasada さん、まつもとゆきひろさんをゲストに迎えて、Guild, Ruby 3 などについて話しました。(9/10 RubyKaigi 2016 にて収録) Show Notes RubyKaigi 2016 A proposal of new concurrency model for Ruby 3 Koichi Sasada: A proposal of new concurrency model for Ruby 3 (RubyKaigi2016) Global interpreter lock Ruby creator floats new concurrency model ギルド verse | RubyGems.org Rust: Ownership and Lifetimes Erlang -- Processes Racket: Places Soft
■ Ruby 2.4.0 で導入予定の Integer Unification まとめ Ruby 2.4.0 で導入が予定されている Integer Unification が与えるであろう Ruby アプリケーションへの影響をまとめておく。 率直には rb_cFixnum や rb_cBignum が 2.4 からは見えなくなるので、それらを参照しているような native gem が対応していなければビルドできないためアプリケーションが動かなくなる。じゃあ、対応したバージョンに全てバージョンアップすればいいじゃん、という話なのだけど bundler が解決してくれる dependency 沼と絡み合って、単純には解決できずに 8 月現在は厳しい状態になっている。 json は Ruby が bundle している�バージョンですでに Integer Unification 対応がなされ
はじめまして、技術基盤部の相原(kaihar4)です! 今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能 をmrubyで書き直してAWSに移行した話をしていきたいと思います。 この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRuby
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
Ruby 2.2 の新機能にシンボル GC というものがあります。 正直、「え、シンボルって GC されないから速いんじゃないの?なのにシンボル GC で Rails が速くなるとか話聞くけど、いったいどういうことなの?」という感じでサッパリ理解できてなかったのですが、その辺りの疑問に対してまとめられている記事がありました。 Symbol GC in Ruby 2.2 とても分かりやすく素晴らしい記事だと感じたので、許可をもらって以下に日本語訳を公開します。 Symbol GC in Ruby 2.2 シンボル GC ってなに?それって気にしなくちゃいけないことなの? リリースされたばかりの Ruby 2.2 の大きな新機能として「インクリメンタル GC」が挙げられますが、もう1つの注目すべき新機能が、この「シンボル GC」 です。 もしあなたがこれまで Ruby の世界で過ごしてきたのな
gistfile1.md if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか? @ajiyoshi.gist twitterからながれてきたこの話題。昔のCコンパイラは、if文の条件節で代入を書いても文句を言わなかったので、このようなコードに何の警告も出なかった。 #include<stdio.h> int main() { int x = 0; /* おそらく意図と違う。 x == 1 と書くべきであった これでは常に実行されてしまう */ if ( x = 1 ) { puts("残念"); } } 「これをこのように書けば、コンパイルエラーになり、ある種の誤りをコンパイラに見つけさせることができる」というのが、「老害」とされる人の主張である。 /* これはコンパイルエラーになる */ if ( 1 = x ) { puts("残念"); } もし使っている環境が「コンパ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
2013年2月23日に東京・品川でRuby20周年記念パーティーが開催されました。Rubyアソシエーションと日本Rubyの会が合同で企画したものです。祝辞(というよりも、むしろ講演)が7本ほど続き、会場はずっと拍手と笑いに包まれ、和やかなムードでした。 私は、Rubyの生みの親、まつもとゆきひろ氏のインタビュワーを務めさせて頂きましたので動画を公開します。 インタビューは20分の予定でしたが、会場からたくさん質問が出て盛り上がったので延長していたようです。動画は38分ほどあります。 以下、いくつかまつもと氏の発言を箇条書きでご紹介します。 20年前のRuby登場時、「ふつうのプログラマはオブジェクト指向は知らなかった。縁のないものだったと思う」。C++でCADを作るような人とか、アカデミックな世界以外ではオブジェクト指向は普及していなかった。 Rubyの仕様について検討する「Rubyコミッ
1. The document describes how the author's experience with Emacs as a student taught him about software freedom and how to read and modify source code. This led him to create his own Emacs-based tools and influenced the design of Ruby. 2. Emacs taught the author the power of Lisp and how to implement a programming language and garbage collection. Using Emacs to write code, documents and email made
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く