A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.
One of the main reasons for having coding standards is to keep your code readable by everyone. By enforcing standards and formatting, the code base becomes consistent, and anyone can easily understand the structure of the code because he will be more familiar with what to expect. It is also very useful when a new developer joins the team because once he is familiar with the patterns, he will be able to easily read the existing code, which results in a more pleasant experience.
As science and software advances, we have the ability to fuse the two together to discover and treat diseases in the hopes of prolonging life. Tasks like sequencing the human genome, isolating genetic markers, and handling large amounts of data are now all possible through a scientific field called Bioinformatics – the study and process of biological data through software, engineering, and mathematics.
This is Part II of my series on writing awesome CLI (command line interface) tools using ruby (Part I). In the first part I described how to create your project layout, add an executable binary, and get started. In this next part I will cover:
- How to structure your code to be usable as both a tool and a library
- Building your CLI frontend to your library.
I am always writing small tools to help me out on a daily basis. Sometimes shell scripts, but
other times I want something a bit more complex. When I need more than a simple shell script, I like to leverage ruby for its vast library of gems which can greatly accelerate and simplify the task of building these helpful tools.
This post will give an introduction to writing your own CLI tools in ruby and packaging them
as a gem.
A few weeks ago I had to deal with setting up a cron job that periodically updated some db tables of a Ruby on Rails application running on Heroku. Here’s a brief step-by-step tutorial to make your life easier in case you were approaching the same task.
One of the most raging debates within the web developer community is LAMP vs. Ruby on Rails (RoR), with countless posts all over the Internet that debate the merits of one versus the other… but this blog entry isn’t going to be one of them. You see, I’m new to RoR and hesitate to call myself an LAMP expert. So I’ll just discuss my own experience going from working on PHP-based sites to working on RoR-based sites.
In addition to outputting lots of useful information, the Rails logger can be a useful debugging tool. But debugging with the log file can become frustrating as it will be cluttered with default content. The solution to this problem is to create a custom logger and log file for such output.
The easiest way to do this is to create a global log function, enable it in your development environment, and make sure that calls to it don’t do anything in other environments.