"rails" entries

Reddish-Greenish-Refactor

Variations in Test-Driven Development

london_traffic_lights“Red-Green-Refactor” is a familiar slogan from test-driven development (TDD), describing a popular approach to writing software. It’s been both popular and controversial since the 2000’s (see the recent heated discussions between David Hansson, Bob Martin, and others). I find that it’s useful but limiting. Here I’ll describe some interesting exceptions to the rule, which have expanded the way I think about tests.

The standard three-step cycle goes like this. After choosing a small improvement, which can be either a feature or a bug fix, you add a failing test which shows that the improvement is missing (“Red”); add production code to make the test pass (“Green”); and clean up the production code while making sure the tests still pass (“Refactor”). It’s a tight loop with minimal changes at each step, so you’re never far from code that runs and has good test coverage.

By the way, to simplify things, I’ll just say “tests” and be vague about whether they’re technically “unit tests”, “specs,” “integration tests,” or “functional tests”; the main thing is that they’re written in code and they run automatically.

Red-Green-Refactor is a very satisfying rhythm when it works. Starting from the test keeps the focus on adding value, and writing a test forces you to clarify where you want to go. Many people say it promotes clean design: it’s just easier to write tests when you have well-separated modules with reasonable interfaces between them. My personal favorite part, though, is not the Red but the Refactor: the support from tests allows you to clean things up with confidence, and worry less about regressions.

Now for the exceptions. Read more…

More than enough Arel

When ActiveRecord just isn’t enough

In Just Enough Arel, we explored a bit into how the Arel library transforms our Ruby code into SQL to be executed by the database. To do so, we discovered that Arel abstracts database tables and the fields therein as objects, which in turn receive messages not normally available in ActiveRecord queries. Wrapping up the article, we also looked at arguments for using Arel over falling back to SQL.

As alluded at the end of the previous article, Arel can do much more than merely provide a handful of comparison operators. In this post, we’ll look at how we can call native database functions, construct unions and intersects, and we’ll wrap things up by explicitly building joins with Arel.

Read more…

Make magic with Ruby DSLs

Demystifying your favorite libraries' domain-specific languages

For better or worse, I believe you can develop basic, yet useful, applications in Ruby on Rails with just a minimum amount of Ruby knowledge. Rails tucks away details behind object-to-table mapping, routing, database preparation, and other necessities for web applications to function. So, is Rails magic? It may seem like something shady’s going on behind the scenes at first, but all of these examples are really just instances of well-designed domain-specific languages within the Rails framework.

A domain-specific language, or DSL, focuses on a particular problem set, or domain, instead of trying to be all things to all people. By contrast, typical programming languages like Ruby are general-purpose languages–they offer a large, varied set of tools to accomplish any number of tasks. Ruby itself is a great example of a general purpose language: You can use it to perform system maintenance tasks, retrieve data from external services, calculate statistics–not to mention, develop complex web applications. But what if you need to focus on a specific task, like running system backups, test-driving software development, or defining database migrations in a Rails application? This is where DSLs come into play.

There are two types of domain-specific language, as defined by Martin Fowler. An external DSL requires its own parser to process commands passed to it. The result is a language that will likely not look at all like the language it was implemented in. SQL, for example, is an external DSL. You interact with a database via a language developed specifically for creating queries–not in the language your database itself was written in.

Read more…

Just Enough Arel

Replacing hand-coded SQL with object oriented programming

If you were a web developer prior to ActiveRecord, you probably remember rolling your own SQL and being specific about which fields you retrieved, writing multiple queries to handle “upserts” (update or insert), and getting frustrated with how difficult it was to generate SQL dynamically.

Then Ruby on Rails came along with its ActiveRecord API, and all of that pain seemed to melt away into distant memory. Now we no longer have to worry about which fields to retrieve, “upserts” can be handled with a single method, and scopes allow us to be as dynamic as we want.

Unfortunately, ActiveRecord introduced new pains: the “WHERE” clause (i.e. the predicate) only allows connecting conditions with “AND”s, and the only comparisons allowed are “=” and “in”. To get around this, we often concede ActiveRecord’s shortcomings and revert back to raw SQL. But in Rails 3.0, we were introduced to another way.

Arel

The Arel relational algebra library is an abstract syntax tree (AST) manager and has the goals of “1) Simplif[ying] the generation of complex SQL queries; and 2) Adapt to various RDBMSes”. It’s the “engine” ActiveRecord uses to change method calls into actual SQL. To be clear, Arel only generates SQL, it doesn’t access the database and retrieve data.

With Arel, we are now capable of fully utilizing the power of SQL, without the mess of hand-coding it. ActiveRecord uses Arel to transform queries like this:

Post.joins(:comments).
  where(:published => true).
  where(:comments => {:flagged => true})

Into SQL like this:

SELECT "posts".*
  FROM "posts" INNER JOIN "comments" ON "posts"."id" = "comments"."post_id"
 WHERE "posts"."published" = true
   AND "comments"."flagged" = true

Read more…

How Setting Aside Rails and Picking Up Padrino Might Make You a Better Ruby Developer

Learning languages through frameworks

I love frameworks. I love that frameworks like Rails and Bootstrap, in particular, make me more productive: People smarter than I have taken care of several decisions that distract from the typical goals of my web applications. I spend most of my time developing within the friendly confines of such frameworks, in part because I enjoy building—and delivering—applications I can show off to non-programmer friends (or clients, for that matter). They’re just not as impressed when I show them a Hello World app or a completed kata, for some reason.

Of course, there’s a danger here. With out-of-the-box, “omakase” Rails, it’s increasingly possible to create powerful applications with a rich understanding of Rails, but a so-so (or worse) understanding of Ruby itself. A well-done framework hides much of the complexity of a language, so the developer can focus more on the problem domain. But if and when an application’s requirements deviate from those for which a stock Rails installation is suited, a couple of things might happen for the developer who’s not sufficiently grounded in the language. At best, programmer productivity slows considerably. At worst, dirty hacks and kludges start appearing in the code base, and technical debt mounts quickly.

Read more…

Four short links: 12 November 2009

Four short links: 12 November 2009

CRM on Rails, Data Mining on Hadoop, Disappointing Keynotes, The Teapot Effect

  1. Fat Free CRM — open source (Affero GPL) Ruby on Rails CRM system.
  2. Bixo — open source data mining toolkit that runs as a series of pipes on top of Hadoop. Built on Cascading workflow system for Hadoop that hides MapReduce. (via kdnuggets)
  3. Andy Kessler’s Keynote at Defrag Stank (Pete Warden) — I’m sorry to hear it, because I loved Andy’s book How We Got Here about the intersecting histories of economics, finance, and technology. Read the book instead of reading about the disappointing keynote.
  4. The Teapot Effect — the thing I love about geeks is how their passion causes them to explore, ruthlessly and quantitatively, the everyday phenomena that the rest of us take for granted. Such as dribbling teapots: “Previous studies have shown that dribbling is the result of flow separation where the layer of fluid closest to the boundary becomes detached from it. When that happens, the fluid flows smoothly over the lip. But as the flow rate decreases, the boundary layer re-attaches to the surface causing dribbling.” Read the post and the research it talks about to learn how to prevent Dribbling Teapot Syndrome ….

You ain't gonna need what?

One of the defining characteristics of the Rails movement has been its willingness to throw out the rules by which software developers and consultants have typically worked. Those rules typically produce big, overblown projects laden with features that no one ever uses–but which sounded good during the project specification phase. Build the simplest thing that could possibly work, and…

Github: Making Code More Social

Github launched less than a year ago, but it's already making an impact on how open-source software is being created. Rails was there from day one, kick-starting the social software repository's traffic. It has taken off though it still doesn't compare to Sourceforge's traffic. Github combines "standard" features of social networking sites with distributed source-control Git. You can follow…

Four short links: 21 Jan 2009

Four short links: 21 Jan 2009

In today’s edition: the spread of fake news, keeping track of your real power use, a Javascript library
and a less-than-impressed take on mobile location apps.

  1. Echo Chamber – the British tabloid The Sun posted a story that turned out to be fabricated. This site tracked that story’s spread and uncritical acceptance by other news outlets and web sites.
  2. Real Time Web-Based Power Charting – build the software and hardware to get a live chart in a web page that updates every 10 seconds with the instantaneous power usage for your entire house.
  3. ActiveRecordJS – just what it sounds like, ActiveRecord for Javascript. AR is a complex subsystem of Rails, and it’s interesting to see the functionality ported to Javascript.
  4. I Am Here: One Man’s Experiment with the Location-Aware Lifestyle – a reporter tries all the location apps, and discovers the future isn’t all here yet. Interesting: only three paragraphs of this long story are about the good bits of location services, the rest question its implementation, privacy, and utility.

RailsConf Europe Early Registration

The schedule for RailsConf Europe just went up last week. It's shaping up to be another great conference. A few sessions and tutorials that particularly catch my eye are David Heinemeier Hansson's keynote on Wednesday morning, "Meta-programming Ruby for Fun & Profit" by Neal Ford, "Offline Rails Applications with Google Gears and Adobe AIR" by Till Vollmer, "From Rails Security…