In the modern web, API-based projects are becoming the norm. Why? For one thing, APIs are necessary to serve Single Page Applications, which are all the rage right now. From a business standpoint, APIs give companies a new way to charge others for access to their data. If you are part of a company that offers such a service, a great way to generate interest in your API is to offer a Ruby gem that makes fetching and consuming your data easy for Ruby developers.
In this article, we'll take a look at how to wrap an imaginary API in a new Ruby gem and share it with the world.
Attending and speaking at RubyConf Uruguay was my first time visiting South America and turned out to be a great experience all around.
The conference was run very well by the organizers/volunteers. It was the first time I experienced a conference that was primarily conducted in a foreign language. Aside from the conference, I had a lot of great experiences, most notably a bus ride that gave me new awareness of the hidden treasures of foreign adventure motor sports.
Every day when I'm programming, I invariably come to a point where I'm looking for a certain line of code in my project. I could just use my editor's "find in files" feature and look for it, but sometimes I need more fine grained control. What if I want to find all the lines of code that don't contain a certain phrase? What if I want to search on a Regular Expression? What if I want to easily save the search results to a file?
When I need MOAR POWER in finding something, I turn my favorite command line search tool:
ack. In this blog post, we'll explore the ins and outs of this fantastic application.
Modeling large, complex domains "the Rails way” can cause some serious pain. Ruby and Rails are supposed to make developers happy. Let's not allow “the Rails way” and complex domains to take the “happy" out of ruby development.
Repetition often creeps into our views, and having a way to simplify them makes them easier to update. Enter Domain Specific Languages (DSL's); using a specific set of context-aware methods allows us to focus on the specifics of our domain. This becomes critical if our domain becomes large or complex. Even when this happens, we try to avoid having too many fields on any particular model. Sometimes, however, the simplest solution is to allow models to grow. At the same time it is important that your code remain manageable. In order to prevent our model's views from becoming unreadably large we're only going to display fields that aren't blank. We'll have to manage formatting requirements for dates and such, so our system needs to be flexible enough that we can customize the output. You'll probably have to be working with this code again at some point, so let's see how much better we can do. Eliminate verbose cluttered code so that your views are easy to work with.