"Ruby" entries

Blocks in Ruby

A fundamental Ruby idiom explained.

When we talk about blocks in Ruby, we’re not usually talking about code blocks — or blocks of statements — as we might with other languages. We’re talking about a special syntax in Ruby, and one of its idioms. I’ll be discussing blocks in this article, plus a little about procs and lambdas.

Ruby’s blocks are always associated with methods, which are sets of recallable procedures. Blocks can’t get along very well by themselves. They are dependent on methods, which normally feed data to them. Without that data, a block can’t do anything useful. It needs a parent to look after it.

Blocks are anonymous and are sometimes referred to as nameless functions. Blocks are like methods within another method that grab data from an enclosing method. If all this is unfamiliar to you, it may not make sense. Keep reading and I’ll do my best to clear things up for you.

Read more…

Learn a C-style language

Improve your odds with the lingua franca of computing.

tools
You have a lot of choices when you’re picking a programming language to learn. If you look around the web development world, you’ll see a lot of JavaScript. At universities and high schools, you’ll often find Python used as a teaching language. If you go to conferences with language theorists, like Strange Loop, you’ll hear a lot about functional languages, such as Haskell, Scala, and Erlang. This level of choice is good: many languages mean that the overall state of the field is continually evolving, and coming up with new solutions. That choice also leads to a certain amount of confusion regarding what you should learn. It’s not possible to learn every language out there, even if you wanted to. Depending on the area you’re in, the choice of language may be made for you. For the overall health of your career, and to provide you the widest range of future opportunities, the single most useful language-related thing you can do is learn a C-style language.

A boring old C-style language just like millions of developers learned before you, going back to the 1980s and earlier. It’s not flashy, it’s usually not cutting edge, but it is smart. Even if you don’t stick with it, or program in it on a daily basis, having a C-style language in your repertoire is a no-brainer if you want to be taken seriously as a developer.
Read more…

Where apps end and the system begins

Exploring the system calls and control flow that underpin high-level languages.

Editor’s note: Sometimes we can forget how important it is to truly understand how a system works, and how the nuts and bolts affect our everyday activities. Marty Kalin asks us to dive a little deeper and strengthen our computational thinking abilities.

It’s clear that applications need system resources to execute: a processor, memory, and usually I/O devices such as the keyboard and screen. It’s less clear how applications gain access to these shared resources, which are under operating system (OS) control. The OS, like any good manager, is efficient and unobtrusive as it handles resource requests from applications. Let’s take a look at how applications interact with the OS, in both routine and dramatic fashion.

Consider what happens when a print statement executes. Here’s a Ruby example:

puts 'Hello, world!'

The Ruby puts statement wraps a call to a high-level I/O function in the standard C library (in this case, printf), which acts as the interface between resource-requesting applications and resource-granting OS routines. In this example, the screen is the requested resource. The standard library interacts seamlessly with the OS, which also is written in C with some assembly language. The library function printf is high-level because, as the f in the name indicates, the function can format the bytes to be written as integers, floating-point values, and character strings such as Hello, world!. In systems-speak, the Ruby application and the C library function execute in user space, which does not bestow the rights and privileges needed to control system resources such as the screen.

Read more…

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…

Why Ruby blocks exist, part III

Never forget to clean up again!

Previous posts in this series used Ruby blocks to iterate over the items in a collection. We’re going to wrap up by showing a very different side of blocks – resource allocation and cleanup.

Close the door!

Here we have a Ruby class representing a refrigerator. Prior to accessing a refrigerator object’s contents via its `contents` method, you have to call its `open` method to open the door. (Sensible enough.) 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…

5 ways developers win with PaaS

Powering your app with open source and OpenShift

Getting Started with OpenShift As a software developer, you are no doubt familiar with the process of abstracting away unnecessary detail in code — imagine if that same principle were applied to application hosting. Say hello to Platform as a Service (PaaS), which enables you to host your applications in the cloud without having to worry about the logistics, leaving you to focus on your code. This post will discuss five ways in which PaaS benefits software developers, using the open source OpenShift PaaS by Red Hat as an example.

No More Tedious Config Tasks

Most of us don’t become developers to do system administration, but when you are running your own infrastructure you end up doing exactly that. A PaaS can take that pain away by handling pesky config and important security updates for you. As a bonus, it makes your sys admin happy too by allowing you to provision your own environment for that killer new app idea you want to tinker with, rather than nagging them for root access on a new VM.

On OpenShift, it goes like this: let’s say you decide you want to test an idea for a Java app, using Tomcat and PostgreSQL (yes, we could argue about the merits of those choices, but work with me here). You can spin that up with a one-line terminal command:

rhc app create myawesomeapp tomcat-7 postgresql-9.2 -s

That -s on the end is telling the platform to make the app auto-scaling, which I will elaborate on later; yes, that’s all it takes. RHC (Red Hat Cloud) is just a Ruby Gem wrapping calls to the OpenShift REST API. You could also use the OpenShift web console or an IDE plugin to do this, or call the API directly if that’s how you roll. The key technologies in play here are just plain old Git and SSH — there’s nothing proprietary.

Read more…

Ohai, new Ohai plugins!

Extending Chef

When you start to use the Chef configuration management system, you will quickly encounter a tool it ships with called Ohai which collects information about the underlying system to expose to the Chef Client as attributes during its run. These attributes allows you to easily incorporate system-specific behavior into your Chef cookbooks, for example allowing you to create a single “package” resource in your cookbook which automatically detects whether to install packages from Yum when running on a Redhat based Linux distribution or from Apt when running on a Debian based distribution. 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…