Ruby’s open classes are great for adding behavior to existing objects. Though it’s a language feature, there to be used, I’d argue that the majority of times it is used, Open classes weren’t the most appropriate tool. First of all, you may be setting yourself (and other developers) up for confusion. Not knowing where methods come from or why a method behaves oddly can be a problem. In the majority of cases, I find you’ve got an instance of some object, and you just want to add behavior to it.

Fake S3 is a gem designed to run a small server on localhost that will correctly handle AWS/S3 GETs and PUTs (among others) while using the local filesystem as the storage backend. This has a number of benefits for anyone working on an application with AWS integration. Probably the biggest benefit is offline development. There’s also a lower configuration burden as there’s no longer special bucket names or keys the manage, the development environment just expects localhost to work. Finally, there’s a very real cost savings. Originally, we paid for two buckets per developer just to support the sample data for dev and test. Now we need none.

Update This post describes compiling a Yesod application locally using a VM to achieve the compilation on a Heroku-like machine, then pushing the binary up to Heroku to be run. This is an annoying route which is no longer necessary (as mentioned in the comments), so don’t follow it. Instead follow [this][] guide. The following are the steps I followed to get a non-trivial Yesod application running on Heroku. This guide assumes you know what Heroku is, you’ve got the Toolbelt installed, and your ssh keys are set up. The wiki I followed can be found [here][wiki]. The Heroku “Getting started” guides were also very useful. Setup 🔗Create an app for your project:

Regardless of what editor you choose or how deeply you decide to extend or configure it, the most important thing for a professional programmer regarding her tool set is awareness. You need to be acutely aware of situations where you do something repeatedly or slowly that you should automate or speed up. Quality editors like vim or emacs expose powerful constructs for doing tasks incredibly quickly. Ensuring you know all of these built-in constructs is the most common area where I see programmers (myself included) failing at this. It’s too easy to fall into the habit of always using the slow way that might’ve been easiest to guess the first time you had to do something, or to install (or even write) some large plugin to give you a workaround to do the same thing the editor already provides (albeit by some obscure combination of constructs).

I’m a big fan of Avdi Grimm’s thoughts about writing confident ruby. I think it’s important to not clutter things with a bunch of nil-checks or exception handling. When you’re focused in at the method level you should trust that your objects are valid and the methods you’re calling behave. In this post I use the term “assertive” to mean much the same thing as Avdi’s “confident”. I think I like this better because the definition of assertive contains both “confident” and “forceful”.

tl;dr: it’s just like aurget but more stable and faster Developing aurget was getting cumbersome. Whenever something went wrong, it was very difficult to track down or figure out. The lack of standard tools for things like uri escaping or json parsing was getting a bit annoying, and the structure of the code just annoyed me. There was also a lack of confidence when changes were made, I could only haphazardly test a handful of scenarios so I was never sure if I’d introduced a regression.

Despite the enormous increase in popularity lately, it seems some people still don’t know about this project or how it can improve your development work-flow. So, what is it and why should you care? Vagrant is a convenience tool for doing Virtual Machine based development. The obvious benefits that you get by using VMs for development are: Isolation - don’t bloat up your personal machine Consistency - no more “it works on my machine” issues Disposability - rebuild from scratch any time Of course, working primarily in VMs can also be a hassle. Here’s where vagrant comes in…

If you write console based applications in ruby, chances are you’re going to want to get some test coverage on that eventually. StringIO is a great class to use when you want to assert that your application outputs the correct stuff to the screen. We can modify the global variable $stdout to be an instance of StringIO for the duration of our tests. Any method that outputs text on stdout (like puts and print) will be sending their text to this object. After we’re done, we can ask it what it’s got and make assertions on it.

Keter is Michael Snoyman’s answer to the Yesod deployment “problem”. This is something I’ve been looking for a good solution to for some time now and keter does a really great job. Keter is meant to run as a service. It sets up its own workspace and watches for keter “bundles” to be dropped into an incoming/ directory. A keter bundle is just a gzipped tarball of your app’s executable, any support files and directories it might expect to have in its current working directory, and a configuration file to tell keter a few simple things about how to manage it.

Sometimes it’s fun to do something completely useless. Recently, I wrote a post about how awesome the Maybe type is in Haskell. In the post, I talked about Functors and Monads and how Maybe can help us understand them. Shortly thereafter, I was bored on the train one day and decided to implement Maybe and its functor instance in ruby. In this post I’ll be relying on the fact that obj.(args) is translated to obj.call(args) in newer rubies. I find it makes the example read better. Maybe 🔗So we need an object that can represent “Just something” or “Nothing”. Ruby already has the concept of nil, so we’ll piggy back on that and just wrap it all in some sugar.