Articles

Reliable Ruby timeouts with SystemTimer: Do not trust timeout.rb too blindly... Rails, Ruby, Unix

timeout.rb, the library used by Ruby to ensure timeouts, is not 100% reliable. In particular, it is guaranteed to not work when you are issuing synchronous system calls that can cause your Ruby process to sleep for a period of time that is longer than your timeout.

In this article you will learn why that is, and how to use the System Timer gem to guarantee reliable Ruby timeouts when you are crossing-boundaries.

Effortless Thread Dump for Ruby: Dump the stack trace of all the threads in your Ruby VM with `caller_for_all_threads` (M.R.I. 1.8) Rails, Ruby, Unix

By default, the Ruby VM only gives you access to the stack trace of the current thread (Kernel#caller in M.R.I. 1.8). Under these conditions, troubleshooting exactly what is going on when a Ruby process is unresponsive during production can end up being quite challenging. What if the thread you want to inspect is not the current one (as is often the case in a Ruby on Rails environment when you run into a “jammed” Mongrel server)?

With caller_for_all_threads, just send a signal to your Ruby VM to dump a stack trace for all the threads. Who said troubleshooting production problems in Ruby was difficult?

Getting Started with DTrace Rails, Ruby, Unix

DTrace is a revolutionary dynamic tracing tool available on Mac OS X (Leopard), (Open)Solaris, and BSD.

This document assembles a collection of pointers and material to get started with DTrace, from a Ruby perspective.

In UNIX Everything is a File Unix

The UNIX operating system crystallizes a couple of unifying ideas and concepts that shaped its design, user interface, culture and evolution. One of the most important of these is probably the mantra: “everything is a file”, widely regarded as one of the defining points of UNIX. This article provides extensive background on this fundamental UNIX metaphor.

Introduction to UNIX Signals and System Calls Unix

When using a computer it is always good to have some kind of understanding of the software stack that you are using. Otherwise when the system does not behave as expected you are lacking the appropriate mental model and metaphor that will help you come up with a way to resolve the problem. In particular it is important to get a good understanding of your operating system’s fundamental mechanisms, even if you concentrate on a higher level of the stack (e.g. developing web applications).

So whether you are creating applications for Mac OS X, Linux, BSD or Solaris, I would recommend that you develop a good mental model of UNIX signals and system calls. This can be challenging as most material on this topic is way too in-depth and specific to capture casual readers whose objective is not to become system programmers or UNIX gurus, but rather to get more familiar with the platform that they are using. These casual readers are the main audience for this article: keep reading if you want to get a good overall understanding of signals and system calls without diving too deeply into UNIX internals and operating system theory.

Getting started with Autotest - Continuous Testing Rails, Ruby, Agile

Why manually run your tests, when the computer can do it for you! Autotest is a great tool to speed up test-driven development with Ruby or Ruby on Rails.

Autotest makes your coding session even more productive as it automatically runs a subset of your test suite each time you change a file. Autotest is smart – it figures out which subset to run based on the files you’ve changed. Think of it as Continuous Testing.

Autotest source code is well-documented (rdoc) but finding a high level overview online is a little more challenging. This article will get you up and running in no time, so that you may concentrate on writing code. Let’s get Started!