ENTRIES TAGGED "Ruby"

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…

Comment |

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:

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…

Comment |

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.

All of Ohai’s attribute collection behavior is defined in a collection of plugins, which are shipped with Ohai out of the box. These plugins allow it to collect information including:

  • The name and version of the operating system being used
  • The hostname of the server
  • The installed version of various programming languages

The flexibility of Ohai however lies in the fact that it also allows us to define our own plugins to extend the rich collection of attributes we collect about our systems. For example at Etsy, we use an Ohai plugin to collect information on the datacenter a particular server is situated in to allow our Chef cookbooks to configure the correct DNS and LDAP server for it to use.

To our cookbooks, this data is visible as the node[:datacenter] attribute, while under the hood the Ohai plugin queries our asset management system to locate and store this information – it allows us to easily capture this information to use in our recipes, without having to worry about how to collect it once we had created the plugin.

These plugins are written using a subset of Ruby known as a Domain Specific Language, or DSL, in which Ohai defines the necessary syntax and behavior of its plugins. Since early 2011, Ohai has shipped with version 6 of its plugin DSL – here’s an example of a plugin written using v6:

As we see here, our plugin class we see here is a single monolithic Ruby file which contains no method definitions, which adds a new attribute Mash called “awesome” and creates two new keys called “sauce” and “level”. The v6 DSL we see in the above plugin is simple, works perfectly well, and has served Ohai well for over 3 years now – however it also has a number of weaknesses:
Read more…

Comment |

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:

Into SQL like this:

Read more…

Comment |

Six Degrees of Kevin Bacon in six languages

20 years of efficiently computing Bacon numbers

apollo1

The Oracle at Delphi spoke just one language, a cryptic one that priests “compiled” into ancient Greek. The Oracle of Bacon—the website that plays the Six Degrees of Kevin Bacon game for you—has, in its 20-year existence, been written in six languages. Read on for the history and the reasons why.

1995-1999: C

The original version of the Oracle of Bacon, written by Brett Tjaden in 1995, was all C. The current version, my stewardship of it, and my revision control history only go back to 1999, so that’s where I’ll start. In 1999, I rewrote the Oracle… still entirely in C. Expensive shortest-path and spell-check algorithms? Definitely in C. String processing to build the database? Also C! Presentation layer to parse CGI parameters and generate HTML? C here, too!

Why C? The rationale for the algorithmic component was straightforward: the Oracle of Bacon ran on a slow, shared Unix machine that other people were using to get actual work done. Minimizing CPU and memory resource requirements was the polite thing to do. I needed a compiled language that let me optimize time and space extensively. The loops all counted down, not up, because comparing against zero was fractionally faster on SPARC. It had to be C.

But why were the offline string processing and the CGIs in C? Mostly, I think, to reuse code from the other parts of the code base and from previous projects I’d written when C was the only language I knew.

2004-2005: Perl

As the site added features, I got tired of writing code to generate HTML in C. I wrote new CGIs, then rewrote existing CGIs, in Perl. Simply put, writing the CGIs in an interpreted language made me more productive. I had hash tables and vectors built into the language and CGI support a simple “use” statement away. I didn’t have to compile on one server and then deploy to another—I could edit the CGIs right there on the web server. Good deployment practices it wasn’t, but it made me more productive as a programmer, and the performance of the CGIs didn’t matter all that much.

Read more…

Comments: 3 |

Why Ruby blocks exist, part II

Putting return values to work

Last time, we showed you how to use Ruby’s each method with blocks to process the elements of an array, and how it can save you a lot of repetitive looping code. That was just an introduction, though.

In our previous examples, the block was a final destination. We passed data into blocks, but it never came back out (unless we printed it to the screen). Today we’re going to look at block return values, and how your methods can use them to manipulate your data in even more powerful ways.

Before we move on…

We should mention that there are two syntaxes for blocks in Ruby. In the earlier post, we used the do ... end syntax:

With blocks that fit on one code line, it’s often preferred (though not required) to use the alternate curly-brace syntax for blocks:

We’ll be using the curly-brace style of blocks today.

Read more…

Comment |

Javascript without the this

Using closures in a different way

One of JavaScript’s many wrinkles is the way that this works. It can be quite confusing, since the semantics are quite different from the purely lexical scoping rules which apply for regular variables in JavaScript. What this references can often be totally unrelated to the lexical scope of a function. To work around that we often see tricks like:

Anyone who’s done much JavaScript development has felt this pain. Imagine if that was never needed. How could we get there? Well, one way would be to just never use this. Sounds crazy? Let’s see.

Read more…

Comments: 24 |

Delegation patterns in Ruby

Reducing object bloat begins with doing less

In almost every project there are those objects which seemingly get involved in every aspect of the application. These are the so-called “god objects”: they can do everything (omnipotent), they know everything (omniscient), and they are everywhere in the application (omnipresent). Most often these are objects which are at the intersections of business logic: User or Account, Project, and Order are all usual suspects.

One of the core tenants of object-oriented programming is that large problems are made up of many smaller problems, and as such, can be solved by providing solutions to those smaller problems in the form of objects. God objects violate this core tenet by trying to be one solution for too many problems.

A typical example of a god object is the User model of many Rails applications. Here, User might be responsible for user specific information as well as knowing about phone numbers, emails, profile information, preferences, and handling authentication. It’s too much and it results in User being coupled to every aspect of the application.

Although there are many tactics a developer can employ to limit the influence of these “god objects”, one of the simplest is just reassigning some of their responsibility, and using a delegation pattern may be the simplest way to do just that.

Let’s look at four different ways we can use delegation in Ruby.

Read more…

Comment: 1 |

How to (semi-)automate JavaScript refactoring

Disposable robot assassins and spreadsheets

Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Giles Bowkett demonstrated a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gave ‘disposable robot assassin at large’ as his title, but it fit better with the code he was demonstrating.

Bowkett explored many options and iterations of his automation ideas,

  • The roots: Martin Fowler’s classic Refactoring. [at 00:50]
  • “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
  • Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
  • “More complex information… surfacing an implicit object model.” [at 7:45]
  • Filter scripts and text streams [at 14:45]
  • “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
  • Building on JSLint [at 20:10]
  • Switching to a Ruby parser for JavaScript to calculate differences [at 21:49]
  • JavaScript parsers: Esprima [at 27:26]
  • “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
  • Grepping through git history [at 32:53]
  • “Automatic refactoring will let you get to better code much faster.” [at 36:25]

It’s an amazing mix of capabilities that let you build your own robot (code) assassins.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment |

Why Ruby blocks exist

Exploring Ruby's "each" method

It seems like more and more languages these days are getting support for closures in one form or another. (Even Java is getting in on the game, finally.) Ruby has had closure-like structures called blocks since its early days, though, and they’re central to the language. Used properly, they can reduce repetition and even make coding less error-prone. Understanding blocks can give you some great ideas to take home to your language of choice. (Or, who knows? Maybe you’ll decide you like coding in Ruby better!)

Today, we’re going to show you just one of the many Ruby methods that use blocks: each. We’ll show you some repetitive code that, in most languages, would be hard to refactor. But using each, we’ll quickly wring that repetition out.

Read more…

Comments: 3 |