RubyKaigi 2017 でどんな発表をしたか 発表スライド 荷物とともに PC 送っちゃったのであとで貼ります ほぼ同内容のテキストはこちらの 4 記事です。 RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST 発表時の twitter での反応 togetter にまとめておきました。 API Development in 2017 - RubyKaigi 2017 #rubykaigi - Togetterまとめ Proposal 事前資料の公開が推奨されていたので、CFP に出した内容も置いておきます。 事後になってしまい申し訳ありません。 Title API Development in 2017 公開されてから思ったんだけど、RubyKaigi は ruby の API の話が多いので
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
Ruby には ?a で 1 文字のみの文字列を返す文字リテラルというものがあります。 Ruby を 1.9 以降から使い始めた人には 'a' などの文字列リテラルとの使い分けや String#chr の存在意義などがわからないと思ったので、知っている範囲で歴史的経緯を説明してみたいと思います。 Ruby 1.8 以前と Ruby 1.9 以降の違い マルチエンコーディング対応が入る前の文字リテラルは1バイト文字用のリテラルで、多バイト文字は使えませんでした。 コントロールやメタは昔から使えました。 以降の実行例も含めて、実行例は 2.0 以降も同じなので、省略しています。 1.8.6 以前は未確認ですが、1.8.7 とほぼ同じはずです。 $ rbenv each ruby -ve 'p ?a' ruby 1.8.7 (2013-12-22 patchlevel 375) [x86_64-
At Appaloosa, most of our tests are written with Rspec, but we still have a certain amount of legacy Test Unit tests. Our Rspec and Test-Unit suites take up to 10 minutes each, so a full test suite runs in around 20 minutes. That’s a lot. We recently decided to invest time on improving our tests to gain time when developing. Recurring problems and how to avoid thembuild vs build_stubbed vs createW
Posted by usa on 29 Aug 2017 There are multiple vulnerabilities in RubyGems bundled by Ruby. It is reported at the official blog of RubyGems. Details The following vulnerabilities have been reported. a DNS request hijacking vulnerability. (CVE-2017-0902) an ANSI escape sequence vulnerability. (CVE-2017-0899) a DoS vulnerability in the query command. (CVE-2017-0900) a vulnerability in the gem insta
Goby is an object-oriented interpreter language deeply inspired by Ruby as well as its core implementation by 100% pure Go. Moreover, it has standard libraries to provide several features such as the Plugin system. Note that we do not intend to reproduce whole of the honorable works of Ruby syntax/implementation/libraries. The expected use case for Goby would be backend development. With this goal
LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている
puma はメモリ食い puma にして喜んでたけど二時間後くらいに NewRelic で様子を見てみたらメモリ 90% 以上消費してて swap ファイルもめっちゃでかいのができてて暴発一歩手前になってた。 一旦 puma をシングルモードからクラスターモードに変えて puma_worker_killer を導入し、 worker を定期的に再起動するようにした。ただ restart 後のメモリ増加傾向は変わらない。 引き続き NewRelic で様子を見ていると Python2 が一番メモリを食っている。このブログは Syntax Highlighting に Python の Pygments を pygments.rb 越しに使っている。これまで unicorn の worker プロセス 2 個で動かしていたときには最大でも Python のプロセスは 2 個で事足りてたけど、
Alexander Dymo Alex is the co-author of the KDevelop IDE for Linux and Mac and was the founding engineer at Acunote. 1 Introduction I often hear that Rails is slow. This has become a common theme among the Ruby and Rails community. But it is actually a myth. It's easy to make your application up to 10x faster just by using Rails in the right way. Here's what you need to know to optimize your Rails
There’s an interesting pattern I’ve discovered recently in Ruby that is very powerful, yet apparently not widely known or appreciated.1 I call this pattern the Module Builder Pattern. I’ve used it heavily in designing Mobility, a pluggable translation framework I released a couple months ago, and it served me so well I thought I should share what I’ve learned. At its core, the Module Builder is an
Ruby の VM は giant lock の塊で、スレッドといっても実行できる Ruby VM のコンテクストはひとつだけで、それを時分割多重で動かすのがふるーい Ruby のスレッドだったらしい。なるほど Ruby のスレッドの性能が低いって言われていたのはこれのことだったのね。リンクするライブラリの都合上 CentOS 6 で作業を行っていたので、そのまま標準の Ruby 1.8 を使っている限りこれはどうにもならないんだけど、 Ruby 1.9 へアップグレードすると、 Ruby が管理しているオブジェクトを触らない前提で giant lock を解放できる仕組みがあるらしい。 Ruby のマニュアルには下記のように書いてある。 ネイティブスレッドを用いて実装されていますが、 現在の実装では Ruby VM は Giant VM lock (GVL) を有しており、同時に実行され
以前からずっと疑問に思っていた事があった。 ruby の後置 if/unless で条件が偽になった場合でも代入構文が実行されるのはどうしてだろう 例えば以下のコードを irb や pry で実行してみて欲しい。 a = 1 if false 続けて a をタイプする。すると nil が表示される。 僕のこれまでの理解だと後置if/unlessは、ステートメントに作用するのでそのステートメント自体が無効になる、つまり代入自体されなかった事になるという理解だった。ruby のパーサのソースコードを見ても後置ifはステートメントに作用している様だった。 | stmt modifier_if expr_value { /*%%%*/ $$ = new_if($3, remove_begin($1), 0); fixpos($$, $3); /*% $$ = dispatch2(if_mod, $
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く