もしOSに断絶があればRubyは死んでいた可能性が高い、まつもと氏がRuby25周年で講演
Post author:sider Post category:Uncategorized Reading time:4 mins read Post published:2018-02-26 もし過去のOSに断絶があったら、Rubyが絶命していた可能性はかなり高い。25年のRuby開発の歴史を振り返りつつ、そんな意外な見方を示したのはRubyの生みの親として知られる、まつもとゆきひろ氏だ。 日本生まれのプログラミング言語「Ruby」（ルビー）が25歳の誕生日を迎えた。Rubyが生まれたのは1993年2月24日のこと。それからちょうど25年目となる2018年2月24日に、Ruby25周年記念イベント「Ruby25（ルビー・トゥエンティーファイブ）」が、Rubyアソシエーションおよび日本Rubyの会の後援で東京の品川インターシティーで開催された。 基調講演を行ったまつもと氏は、25年を振り返
ブロックによるRuby内DSLの起源 - 世界線航跡蔵
時代とともにRubyの使われ方は変わってきましたが、いつの頃からか発生したDSLのホスト言語としての役割にはずっとお世話になってます。人に優しく、故にプログラマ以外にも優しく、これがとてもRubyらしくて好きな点です。 #ruby25th— Yuki Yugui Sonoda (@yugui) 2018年2月24日 僕にとってRubyはfluentdやchefのための言語ですが、プラガブルなOSSエコシステムであったり、強力なDSLを作りやすかったりするところにその魅力を感じます。特にfluentdは大好きなOSSで、Mackerel運営でもかなり参考にさせてもらっています。 #ruby25th おめでとうございます！— songmu (@songmu) 2018年2月24日 DSLは本当に感動したところなんだけど、DSL開発ツールとしてのRubyが「発見」されたものなのか意図されたものな
Ruby 2.5 の改善を自慢したい - クックパッド開発者ブログ
技術部でフルタイム Ruby コミッタをしている笹田です。最近ひさびさに Ruby のライブラリに pull request をしました（show valid break point lines #393）。 12/25 のクリスマスに、Ruby 2.5 が無事にリリースされました（Ruby 2.5.0 リリース）。関係各位の努力に感謝します。いろいろなバグ修正、いろいろな新機能、いろいろな性能改善があります（詳細は、上記リリースノート、もしくは Ruby のソースコードにある NEWS ファイルをご参照ください）ので、試して頂けると良いと思います。そういえば、私がクックパッドに入社して初めての Ruby リリースでした。 前回の techlife ブログ（ Ruby の NODE を GC から卒業させた ）で遠藤さんが クックパッドからの主な貢献としては、「trace 命令の削除による
CRuby向けのLLVMベースのJITコンパイラを書いている話 - k0kubun's blog
LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている
Rubyを2.0から2.3にバージョンアップした効果とか - トレタ開発者ブログ
インフラをチョメチョメしている佐野です。今日はRubyを現最新バージョンの2.3.1にアップデートしたのでその効果について書きます(2.0、とっくにEOLですしね...)。gemのバージョンアップはserizawaニキがやってくれました。結論から言いますと、 CPU使用率が劇的に下がり、メモリ使用率が少し上がった。 サーバ台数削減できる。 です。 CPU 9/6の昼過ぎくらいに2.3に切り替えたのですがそれ以降、CPUが下がっていることがわかります。 メモリ メモリについては使用率が上がっています。 2.3 2.0 何が使っているのかというと、Ruby2.3なプロセスのメモリ使用量が全体的に増えました。次のtopコマンドは左ペインが2.3、右ペインが2.0なのですが、rubyないしbundleとなっているものがunicorn, sidekiqになります。これら全般的に2.3の方がメモリ使用
Rubyが今のPythonの地位にいない理由
_ Rubyが今のPythonの地位にいない理由 歴史のことなんぞなんも知らんけど、「技術的には今のPythonの地位はRubyでもよかったのに、そうならなかった」のが何故か、その理由を書いてみよう。僕はRubyの歴史なんて知らないし、以下の文章は全部、まるで見てきたかのように書いてますが、適当に書いたくせに何故か断言口調になっている怪文書の類いです。 https://twitter.com/mametter/status/741950239662170112 まめさんの書いた理由リストはどれも関係ない。いやカスってるけど。難しいというのも関係ない。 僕がRubyを知ったころ…最初に書いた通りRubyの歴史なんて知らないので、別に早くもないわけだけど…Rubyというのは全く使われていない言語だった。どっかの好き者がPerlの替わりに単純な処理に使って、「ウフ、美しくかけた、グフッ」とかつぶ
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
Ruby標準のテスティングフレームワークで手軽にテストコードを書く方法 - Qiita
はじめに 僕が一番使い慣れているテスティングフレームワークはRSpecです。 普段の業務でも大半はRSpecでテストコードを書いています。 しかし、ごくごく簡単なRubyのコードを書く場合は「わざわざRSpecを書くのは大げさかな」と思うことがあります。 簡単なコードであれば、テストコードも簡単なものになるのでassert_equalが使えれば十分だったりします。 というわけで今回の記事ではgemを使わず、Ruby標準のテスティングフレームワークでテストコードを書く方法をまとめてみます。 やりたいこと 「素のRuby」でぱぱっとシンプルなテストを書きたい（assert_equalだけで十分なケースを想定） gemのインストールはしたくない、他の人にもさせたくない Ruby 2.0以降ならどのRubyでも動いてほしい つまり、 「いつでもどこでも動くテストコードを書きたい」 というのが今回の
投機実行とOut of Orderはつよいというはなし - なるせにっき
fluentdな人達と話していると定期的にRubyのオブジェクト生成が遅いとdisられます。 本質的にしょうがない部分もあるんですが、それにしても遅い部分も結構あるので、おもむろにperf statとperf recordを取ってみましょう。 % sudo perf stat -d ./miniruby -e'GC.disable;i=1000000;while (i-=1)>0;Hash.new;end' Performance counter stats for './miniruby -eGC.disable;i=1000000;while (i-=1)>0;Hash.new;end': 467.629812 task-clock (msec) # 0.993 CPUs utilized 19 context-switches # 0.041 K/sec 2 cpu-migratio
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Matzにっき(2007-09-13)
<< 2007/09/ 1 1. U20プロコン最終審査会 2. 死なないために 3. [Ruby] davidflanagan.com: Nifty Ruby Unicode codepoints utility 2 1. [教会] 第一日曜日 3 1. [Ruby] RubyアソシエーションがRuby言語公式ロゴのデザイン募集：ITpro 2. [OSS] Open Tech Press | GNU GPLv3 日本語訳 3. [言語] retlang - Google Code 4 1. Full Disclosure: World's most powerful supercomputer goes online (fwd) 2. [知財] 元麻布春男の週刊PCホットライン - DRMどころかEPNも嫌いだ 3. 取材 5 1. 取材 2. [Ruby] Ruby needs a
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
CRubyとLink Time Optimizationについて - なるせにっき
最近、夜寝る前にRubyのベンチマークを眺めたり、仕事の障害時のログを眺めるっていう悪趣味極まりない習慣がついてしまった。まぁ、草木も眠る丑三つ時にこの世の真理を求めて何かを読みふけるって言うのは、この業界にいる人間なら誰しもがやることなんじゃ無いかと思う。それと同じで現場百遍とも言うとおり、何度もprofileやログを眺めれば何か気付くこともあるんじゃないかと思って読んでいる……というわけではなくて、ふと見たくなる衝動に従っているだけだけど。 さて、Rubyのprofileを取るときに便利なのがRubyKaigi 2015でこさきさんも紹介していたperf。あまりに便利なせいで、プライベートでLinuxを触る時間が何千倍にも増えたくらい。あの発表はもっぱらperf-topの紹介だったけど、perfの使い方とかを見ると他にも色々な機能があることがわかる。例えば、昨日話題になったひたすらbl
Parse
The most amazing feature of Parse Server is that it’s accessible for developers of all skill levels. Personally, I started playing around with Objective-C in 2012. Parse was a way for me to build a complete online app, without having the in-depth knowledge of how to build networking, storage, user systems, etc. The more I built with Parse, the more I learnt JavaScript, which has fortunately allowe
小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 | gihyo.jp
RubyKaigi 2015レポート 小崎資広さん「人に依存しないデバッグのために、道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目 12月11日～13日、ベルサール汐留にて「RubyKaigi 2015」が開催されました。今年も基調講演が毎日一つずつ行われました。その模様をレポートします。 RubyKaigi 2015 2日目の基調講演は、世界で唯一の、LinuxのコミッタでありRubyのコミッタでもある小崎資広さんです。今回、小崎さんは「Linux loves Ruby. Ruby Loves Linux - How to debug your linux box」と題して、発表しました。 Linux portメンテナのお仕事 小崎さんは、Ruby Core Teamでの自分の役割を「Linux Portメンテナ」と称し、これまでの仕事の内容を紹介しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LLVM-Based JIT Compiler for CRuby
Ruby で高速なプログラムを書く
Running Ruby on Solaris (RubyKaigi 2015, 12/Dec/2015)
Ruby meets Go
Rhebok, High Performance Rack Handler / Rubykaigi 2015
