Writing Fast Ruby を検証してみた - きにきじ
少し前に Writing Fast Rubyというスライドが良い | mah365 という記事が話題になっていました。内容は Writing Fast Ruby というスライドの紹介で、リーダビリティを維持しながらパフォーマンスを出せるよという話です。おもしろいなーと流してしまってもよかったのですが、どうせなら手元でも確かめてみようというのが今回のこの記事です。 使った Ruby のバージョン 最初は普段よく使っている Ruby 1.8.6-p369 でやってみたんですが（バージョンアップしたいですがなかなかリソースを確保できず……）、一部スライドと違う結果が出たので、バージョンの違いがあるのかもということで以下のバージョンで試してみました。 Ruby 1.8.7-p375 Ruby 1.9.3-p545 Ruby 2.1.2 便利メソッドを定義 毎回計測用のコードを書くのがだるいので、次
Writing Fast Rubyというスライドが良い | mah365
ちょっとしたコードの書き方でパフォーマンスが変わることがあります。リーダビリティを重視する向きからすれば小手先のテクニックに映るかも知れないのですが、リーダビリティを維持しながらちゃんとしたパフォーマンスを出すためにも、テクニックを知ることは大事なことだと思うのです。 結構違うもんですなー というわけで、そんなテクニックをまとめたスライドがWriting Fast Ruby。見ていて参考になったのでメモ。 たとえば引数に&blockをとってcallするよりも、yieldの方が5倍速い、とか、 def slow(&block) block.call end def fast yield end mapにブロックを渡すよりも、シンボルを渡す方が20%速い、とか (1..100).map {|i| i.to_s} (1..100).map(&:to_s) mapしてからflattenを呼び出すよ
Ruby 2.2.0 preview1: ついに来ました！恒等関数 Kernel#itself などなど | TECHSCORE BLOG | TECHSCORE BLOG
Ruby 2.2.0 preview1: ついに来ました！恒等関数 Kernel#itself などなど こんにちは、鈴木です。 先日（2014/9/18）に Ruby 2.2.0 preview1 が出ましたね！ Ruby 2.2.0-preview1 リリース いくつか新しい機能も増えていたので、気になったものをご紹介します！（詳細な変更内容はこのページで確認することができます。） ついに来ました！恒等関数: Kernel#itself いわゆる恒等関数と呼ばれる、自身 (self) をそのまま返すメソッド Kernel#itself が追加されました。 他の言語でも恒等関数が組み込みで存在する場合があり、id や identity などの名前で定義されていることが多いです。「名前重要！」の Ruby では恒等関数の導入案は以前からありましたが、名前がなかなか決まらなかったという経緯が
『パーフェクト Ruby on Rails』を読んだ - きにきじ
『パーフェクト Ruby on Rails』（すがわらまさのり, 前島真一, 近藤宇智朗, 橋立友宏）を読みました。「Rails 開発に慣れてきたかな」くらいの人にちょうどいい内容だったと思います。それくらいレベルの人が少し上を目指したり、より Rails らしい設計や開発の仕方を学んだりするのにいい書籍だと思いました。Ruby 2 や Rails 4 向けの説明になっているので、新しめの情報を得たいような場合にもお薦めです。逆に、最新の Ruby や Rails でバリバリ開発しているような人には既知のことばかりで物足りないんじゃないかなという印象です。 全体的に興味はあったのですが、購入の決め手となったのは第9章「より実践的なモデルの使い方」です。どう設計するか、どうリファクタリングするかの1つの指針として読んでみたいと思いました。実際に読んだ感想としては、学びも多く、読んでよかったと
tree-tips: MySQLで大量レコードのjoin | MySQL
大量レコードのjoinは遅い 遅くなるのはMySQLだけなの？ そんなことはありません。MySQLもPostgresもOracleもSQLServerも遅くなります。 Oracleのオプティマイザは賢いですが、基本的に大量レコードのjoinは避けるべきです。 何故遅くなるの？ データ量が多すぎてテンポラリ領域を使う（バッファに乗り気らない）から、です。 何件くらいからjoinが遅くなるの？ スキーマ構造によるので一概には言えませんが、大体1000件辺りから微妙に遅くなり、1万件を超えると一気に遅くなります。 1万件程度なら割と力技（マシンパワー）で何とかなるので、1万件を超えた辺りから注意してみて下さい。 よくある例では、ログを元にしたアクセスレポートの生成時に、大量レコードのjoinが必要になり易いかもしれませんね。 解決策 データ量を減らしてからjoinする。 データ量が多いならデータ
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
Google JavaScript Style Guide
Revision 2.2 Aaron Whyte Bob Jervis Dan Pupius Eric Arvidsson Fritz Schneider Robby Walker This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's a "toggle all" at
CI で稀に失敗してしまうテストへの対処方法 - クックパッド開発者ブログ
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
今更ながらシリーズ(2) StringInquirer - HWPS別館
Rails.env == 'production' という式は、 Rails.env.production? と書ける。これは Rails.env が単なる文字列ではなく、ActiveSupport::StringInquirer という String を継承したクラスに変換されているから。 https://github.com/rails/rails/blob/master/activesupport/lib/active_support/string_inquirer.rb ActiveSupport.StringInquirer.new("foo").foo? #=> true ちなみに、Rails 3.1 では、String#inquiry で String から StringInquirer を生成できる。 Rails.version # => "3.1.0.beta1" s =
What's new in Active Record [Rails 4 Countdown to 2013] | The Remarkable Labs Blog
This post is part of a series of 31 Rails 4 articles being released each day in December 2012. In today's Rails 4 countdown post, we are going to go over some of the changes being made to Active Record. While this list does not include every single change, it does summarize most of the non-specific database vendor changes. Null Object Pattern Being introduced in Rails 4 is ActiveRecord::QueryMetho
SEマネジャ教育が企業を成長させる
前回のブログで「SEマネジャはボックスである。嫌いなことでもはやるべきことはやらなければならないし，自分が好きなことでもボックスとしてやってはならないことはやってはならないのである」という主旨のことを書いた。 上司や先輩に恵まれないと成長は難しい これに対し読者の方からコメントをいただいた。要約すると次の通りだ。 「元SEマネジャであった小生には耳の痛い内容であった。だが，少しコメントさせていただくと，誰しもある日突然SEマネジャになるわけではない。それまで一緒に仕事した来た上司や先輩がきちっと仕事ができる人であれば自然とSEマネジャの正しい仕事の仕方や考え方が身についているはずである。しかし，上司や先輩に恵まれない場合はそうは行かない。部下が正しいやり方，考え方を身に付けるのはそう簡単なことではない。そう考えると，この類の問題は個人の問題としてではなく，組織としても考えるべきではないか」
マネジャはボックスである
「SEマネジャはボックスである」---この言葉は筆者の造語ではあるが，筆者がSEマネジャ時代に教訓としていた言葉の一つである。今回はこれについて述べる。 “四角い箱”が象徴する，組織の中で果たすべき役割 まず，この「SEマネジャはボックス」と言う意味だが，概略次の通りである。会社の組織図では「マネジャ（課長）」を金融システム第一課長，製造グループ担当マネジャなど四角の箱（BOX）で表現する。すなわちボックスである。その四角の箱（BOX）にはシステム開発や部下の育成・管理などなどやるべき職務がある。そして，この四角の箱（BOX）はその職務を遂行するためにあるのであって，決して特定の個人のためにあるのではない。 具体的には今，金融第一グループのマネジャを馬場史郎がやっていたとする。この馬場史郎は金融第一グループというボックスであって馬場史郎個人ではない。すなわち，仕事をしている時は，馬場史郎は
ＳＥにとって、あるべき教育の姿とは？ | システムエンジニアの晴耕雨読 - 楽天ブログ
ＳＥにとって、あるべき教育の姿とは？ ＳＥにとって、あるべき教育の姿とは？ エドワード・ヨードンの「プログラマーの復権」（凸版）の 中で、かなりラディカルな議論がされていたので、紹介します。 以下、ヨードンさん語る。 「私の雇用者は、私をどんな教育・訓練コースにも行かせようとしない。私のＣＯＢＯＬの職務経験はもはや役に立たなくなったが、彼らはＣ＋＋や新しい技術を私に教育しようという気がない」と言っている電子メールをひっきりなしに受け取った。 私の答えはこうだ。 「自分で学びなさい。」 常に高めていくべき専門職としての能力開発に必要な個人の時間とポケット・マネーは、ソフトウェア・ビジネスにとどまるためのコストの一部である。 あなたの雇用者は社会的契約破棄の一部として、こうした教育コストを今後補助しないことを決定したのだろう。 だが、もし誰かが払わなければ、あなたは早晩、世界のどこかにいる、速
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler氏によるリファクタリングのワークフロー
https://github.com/pauldix/domainatrix/blob/master/README.textile
https://github.com/weppos/publicsuffix-ruby/blob/master/README.md
domain_name | RubyGems.org | your community gem host
「if条件式の右辺と左辺」（1） Java Solution － ＠IT