Ruby

Rubyのカンファレンスは本当に素晴らしいものです。多くの参加者が豊富な知識を共有しており、ほぼすべてのトークから何かしら学びを得られます。さらに嬉しいことに、現地に参加できなくても、新しいカンファレンスが開催されるたびに、たくさんのトーク動画が公開されます。 ただし、ここで一つ問題があります。動画の視聴には時間がかかるのです。1.5倍速で再生しても、1本あたり20〜30分はかかります。しかも、こうした「集中して視聴する時間」は、思うようには確保できないものです。 一方で、ポッドキャストはすでに私の生活に深く根付いています。ほぼ毎日の通勤時間にはOvercastを起動して、いくつかのエピソ

なぜRailsはあれほど速く普及したのか？ Railsがなぜこれほど短期間で爆発的な人気を獲得したのか、不思議に思ったことはありませんか？ シンプルさは大きな要因でした。特にJavaとXMLにまみれた「エンタープライズ」の世界から移ってきた開発者にとって、その簡潔さは衝撃的だったはずです。また、マーケティングも見事に行われていました。しかし、それだけが理由ではありません。 Railsがスタートアップの世界で成功した最大の理由は、実にシンプルな事実にあります。ビジネスが抱える問題は、それほど特殊なものではないということです。RailsはCRUDサイトの構築に長けていながら、柔軟性も保っていました

本記事は、Soonsang Hong氏による韓国語版も公開されています。 スコープ（scope）は、データベースから条件に合ったオブジェクトを取り出すための、Railsの強力な機能です。 app/models/review.rb class Review < ActiveRecord::Base scope :most_recent, -> (limit) { order(created_at desc).limit(limit) } end このスコープは次のように呼び出します。 app/controllers/homepage_controller.rb @rece

奇妙で一見解決不能なバグに遭遇したとき、ロギングの改善こそが最善の一手となることがあります。優れたロギングは、さまざまな種類のバグを検出・修正するための最も手軽な手段です。十分な情報をログに出力すれば、リクエスト処理の中でデータがどのように変化していくかを目で追えますし、他サービスへの呼び出しとそのレスポンスも調査できます。実際、私自身もデバッガでは解決できなかった最難関のバグを、ロギングのおかげで修正できた経験があります。 しかし、ログを出しすぎると、ログファイルはたちまち読めない無意味なメッセージの山になってしまいます。膨大なデータの中から、本当に必要な情報だけをどう切り出せばよいのでし

文字列のエンコーディングを本気で考えるのは、たいてい問題が発生したときです。例外トラッカーを開いたら、次のようなエラーが出力されていた――そんな経験はないでしょうか。 Encoding::InvalidByteSequenceError: \xFE on UTF-8 あるいは、「theyre」と表示されるはずの文字列が「they’re」のように文字化けすることもあります。 では、エンコーディングが壊れてしまったとき、どこに原因があるのかをどう突き止めればよいのでしょうか?そして、それをどう直せばいいのでしょうか?本記事では、その具体的な手順を解説します。 エンコーディングとは何か

先週の記事では、ほとんどのエンコーディング問題を解決できるシンプルなプロセスを紹介しました。しかし、中には解決がはるかに難しいエンコーディング問題が存在します。 きっとあなたも見たことがあるはずです。カーリークォート（’）が「’」に、emダッシュ（—）が「—」に変わってしまう現象です。まるで自分がおかしくなったのかと疑いたくなりますが、本来ならそのまま動くはずのものです。 巨大な対応表を作り、壊れた文字を見つけては正しい文字に置き換えることもできます： [{broken: –, fixed: —} {broken: ‗, fixed: –} {broken: â

CSVファイルからアプリに大量のデータをインポートしたいと思ったことはありませんか?あるいは、顧客レビューの中の文字化けした文字を修正する必要があったり、Redisでのデータ保存方針が変わり、古い形式から新しい形式へ全データを移行しなければならなかった経験もあるかもしれません。 Avvoでは、こうしたタスクを「アドホックタスク」と呼んでいました。つまり、おそらく一度しか実行する必要がないタスクです。では、Railsでアドホックタスクを処理する最良の方法は何でしょうか? 1. データベースマイグレーションとして書く データベース内のデータ構造を変更する必要がある場合、マイグレーションはうまく機能

あなたのコードの中で、テストされていない部分はどこにあるでしょうか?スレッド、コマンド実行、git、ネットワーク通信、UIなど、自分では制御できない複雑な状況を扱うコードではないでしょうか?アプリが最も面白くなるのは、複雑になったときです。しかし同時に、最も危険でもあります。だからこそ、テストしにくいコードこそ、しっかりとテストされるべきコードなのです。ところが、現実にはそうならないことも多いものです。その代わり、そのコードに触れるたびに、おそるおそる慎重に手を加えることになります。手動でテストを試してみて、プルリクエストを出す頃には「テストが存在しないこと」にチームメイトが気づかないことを祈

先週開催された「RailsConf 2017」にて、Rails 5.1が正式リリースされました。 リリースのお知らせをチェックされた方なら、目玉機能はすでにご存じでしょう。モダンJavaScript(YarnやWebpack)との統合強化、暗号化されたsecrets、システムテストの導入などが挙げられます。そして個人的なお気に入りは、form_forとform_tagというやや紛らわしい2つのメソッドがついに統合され、新しいform_withに置き換えられたことです。早く試してみたいところです。 しかし、私がRailsを愛している理由は、こうした大きな新機能ではありません。日々積み重ねられ

前回の記事では、Rails 5.1の注目の新機能であるdelegate_missing_toを紹介しました。delegate_missing_toを使うと、あるオブジェクトに存在しないメソッドが呼び出された場合に、代わりに別のオブジェクトの同名メソッドが実行されます: class Player delegate_missing_to :@user def initialize(user) @user = user end def points Game.points_for_user(@user.id) end end Player.new(user

Railsのトピックの中に、どうしても意味が掴めないものはありませんか? 理解できているつもりでコードを書いたのに、まったく予想外の動作をしてしまった——そんな経験はないでしょうか。 あるいは、「本当はよく分かっていない」と自覚しながらも、その場しのぎで乗り切れてきた。ところがエッジケースとの格闘に膨大な時間を費やし、気づけば専門家になれるほどの時間を使っていた——そんなこともあるかもしれません。 しかし、そうならなくてもいいとしたらどうでしょう?目の前の問題について確かなメンタルモデルを持ち、正しい判断ができる。そして正しいコードが書ける。そんな状態を目指せるのです。 私自身の失敗談:セッシ

バグをひとつ直したら新たなバグが十個も出てきた——そんな経験はありませんか？あるいは、コードがあまりにも奇妙な壊れ方をするので、「自分は本当にこのコードを理解できているのだろうか」と不安になることもあるでしょう。そんなときこそ、テーマを根本から掘り下げる「ディープダイブ（deep dive）」の出番です。 しかし、深く学ぶ必要があると気づくこと自体は、ほんの第一歩にすぎません。実際にどうやってトピックを基礎から学べばいいのでしょうか？そして、知識が自然に引き出せるレベルまで到達するには、どうすればいいのでしょう？ どこから始めるべきか？ 学習の入り口はたくさんあります。私が短時間でトピックを広

大きなプロジェクトや新しい仕事に没頭していると、ふと顔を上げた瞬間に迷子になったような感覚に襲われることがあります。技術の世界が自分を置いて先へ進んでしまったように感じる——学習に費やせなかった時間が、ついに追いついてきたのか？と。そして、そのギャップはどうすれば埋められるのでしょうか？ 自宅で学ぶ？それとも仕事中に学ぶ？ 学習の時間を作ってこなかったなら、その時間はどこかから捻出するしかありません。 では、その時間はどこから？プライベートの時間を使うべきか、それとも仕事中に学ぶべきか。 これはひっかけ質問です。答えは「両方」です。 仕事以外の時間を見つけるのは簡単ではありません。私

前回のAppSignalアップデートでは、全画面にわたるインターフェースデザインの刷新が行われました。これに伴い、トップページに掲載しているすべてのスクリーンショットを最新のアプリの状態に合わせて更新する必要がありました。膨大な手作業を減らすため、私たちはこのプロセスの自動化を決断しました。Seleniumでのスクリーンショット自動化幸いなことに、Seleniumにはスクリーンショットを撮影する機能があることを思い出しました。私たちはもともと、フィーチャーテストにおいてCapybara経由でSeleniumを多用していたため、新たな仕組みを導入することなく、既存のスタックだけでこのタスクを自動

カスタムメトリックで、より深いインサイトをAppSignalのgemでは、以前からカスタム計測（インストゥルメンテーション）を利用して、アプリケーションパフォーマンスに関する詳細な情報を取得できました。しかし、パフォーマンス以外の指標も追跡したいケースは少なくありません。gemのバージョン1.0のリリースにより、AppSignalへカスタムメトリックを送信できるようになりました。新規アカウント数からデータベースのディスク使用量まで、アプリケーション内のあらゆるデータを追跡できます。カスタムメトリックはコード計測の代わりとなるものではなく、コード内の特定のデータをより扱いやすくし、時系列で測定可

並行処理のマスタリングあなたが開発したアプリには、同時に複数のユーザーがアクセスします。そして、誰もができるだけ速いレスポンスを求めています。そのためには、何らかの方法で並行性（コンカレンシー）に対応する必要があります。でも心配は無用です。多くのWebサーバーはデフォルトで並行処理に対応しています。ただし、アプリをスケールさせる段階になると、並行性を最も効率的な形で活用することが求められます。並行処理の主な方式並行処理を実現する方法は主に3つあります。マルチプロセス、マルチスレッド、イベント駆動です。それぞれに適した用途やメリット・デメリットがあります。この記事では、それぞれの違いと、どのよう

開発環境の設定Mongoid 5にアップグレードした後、Railsアプリを起動すると、最初にデータベース設定が不正であるというエラーに遭遇することになります。修正は簡単で、sessionsをclientsに変更するだけです。development: clients: default: database: appsignal_development hosts: - localhost:27017ドライバーの変更点私たちのコードベースでは、Mopedやmongo-ruby-driverに対して直接クエリを実行するために「ドライバーへ直接アクセス

パフォーマンス問題の根本原因を突き止めるには、標準の計測機能だけでは不十分な場合があります。そんなときに役立つのがカスタムメトリクスです。標準機能では捉えきれない「欠けたピース」を補完できます。AppSignalのパフォーマンスグラフを活用すれば、コードベースのどの部分がパフォーマンス問題を引き起こしているのかを正確に把握できます。以下のスクリーンショットでは、MongoDBが原因で深刻な速度低下が発生していた様子が確認できます。しかし、これだけでは、異なるReplicaSet上で稼働する数多くのデータベースのうち、どのデータベースがこの速度低下を引き起こしたのかまでは特定できません。そこでカ

コードを実行するとき、必ずメモリを使用します。Rubyのような言語でプログラムを書いていると、使えるメモリは無限にあるように感じられます。コードを実行しているシステムが持つ有限のメモリ量を意識することなく、どんどん書き進められるからです。今回のRuby Magicでは、この便利な仕組みがどのように実現されているのかを解説します。 少しの歴史 かつて、Rubyのようなスクリプト言語はまだ存在していませんでした。人々はCのような低水準プログラミング言語だけでコードを書いていました。これらの言語が「低水準」と呼ばれる理由の一つは、メモリの後片付けを自分自身で行わなければならない点にあります。たとえば

Ruby Magicの前回の記事では、なぜガベージコレクション（GC）が必要なのか、そしてその基本的な仕組みについて解説しました。今回はさらに踏み込んで、RubyにおけるGCの実装方法について詳しく見ていきます。 さまざまなRuby実装 Rubyには複数の実装が存在します。代表的なものとして、MRI（Matzs Ruby Interpreter）、Rubinius、JRubyの3つが挙げられます。それぞれの実装で採用されているGCの方式は異なります。本記事では、最も多くのRuby開発者が利用しているMRIに焦点を当てて解説します。 Rubyのヒープ コンピュータのメモリには「スタック」と「ヒー