Chocolat: An alternative to Sublime Text on OS X

Ever since I started using OS X, I've been using Sublime Text 2 as my text editor. I've had nothing but good things to say about it - it's gotten to the point where I'm not sure if I could live without it. However, I've recently stumbled upon a text editor called Chocolat. It's a fantastic editor that rivals Sublime Text in terms of features, and has a beautiful native OS X look and feel. If you like Sublime Text and haven't paid for a license yet, you should seriously consider trying Chocolat and seeing if you like it more.

Chocolat is priced cheaper at $49, while Sublime Text is $70 for a license. Chocolat has a 14 day free trial while Sublime Text 2's trial doesn't seem to have a limit. The look and feel for both editors is very nice, but Chocolat has an edge over Sublime Text since it is a native OS X, while Sublime Text is multi-platform, and you can tell the difference. Both editors however are very customizable when it comes to look and feel.

Both Chocolat and Sublime Text have a ton of features, pretty much everything you need. Chocolat has a "vim mode" and built in documentation, while Sublime Text is extremely customizable. For one editor to beat another in terms of features, you'd have to be looking for something specific.

It's hard to say which editor is better - I don't think you can make an argument for either editor without being subjective. Chocolat might be more bang for your buck, but Sublime Text might have more support in the OS X community. Almost everyone I know uses either Sublime or Textmate, I don't actually know anyone that uses Chocolat over either of those editors. But it's not like I actually know a lot of people, so Chocolat should definitely be in the conversation.

Better Errors gem breaking RSpec

I recently installed the fantastic Better Errors gem in a Rails app I'm working on, and I have to say it's fantastic. It obviously makes Rails errors easier to look at and debug, but my favorite feature is easily the shell that's included on the error page. I'm convinced I'm going to include the Better Errors gem in all my Rails apps from now on.

That being said, after I installed it I noticed that I was not able to run my RSpec tests anymore. Whenever I tried to run my tests I ended up getting a segmentation fault. To solve this, I needed to upgrade my Ruby version to 2.0.0 using the Ruby Version Manager. After I upgraded to 2.0.0, I stopped getting the error.

Check out the issue filed here for more details.

RSpec: let vs let! with Rails associations

With FactoryGirl and RSpec, testing with Rails associations is pretty simple. Let's say you have a home inventory application with a User model that has a has_many association with a Home model, and that the Home model belongs_to the User model, and you have factories defined in your factories.rb file for each model:

Let's say we have tests for a show action for the User model. We want to show some user information plus a list of all the homes associated with it:

These tests will fail. The reason is that the let method is lazy - it won't create the home objects because they are never referenced, therefore their information won't be rendered on the show page and the tests will fail. To get around this you need to use the let! (let bang) method - this will create the home instances immediately:

This will result in passing tests.

TDD, RSpec, and To-Do lists

If you have a terrible memory like me you need to-do lists. Due to my reliance on them to keep my thoughts and goals organized, I'm a big fan of task management - so much so that I plan on making my own task management software someday. Some people can just turn on their computer and start writing code and keep track of what they've accomplished and what they have to do, however I am not one of those people. Writing down my tasks and todos before I actually do them is so ingrained as part of my development process that I barely even realize I'm doing it. While maintaining to-do lists is great, there is one obvious problem with them: any time you are creating or updating a to-do list is time you're not spending developing code or tests. It's possible that to-do lists help productivity in the long run, but it'd be great if there were a way to combine the act of creating a to-do list with some sort of development activity. I believe test-driven development (TDD) is the answer to this problem.

As you know (I hope), tests are vital in software. Any good software application should have decent test coverage, whether it's JUnit test suites for a Java application or Test::Unit or RSpec for Ruby/Rails. With TDD, failing tests are written first, then the implementation is written to make the tests pass. This is a weird concept to grasp at first, but writing the tests first really makes a developer think about what the code really should do, and in my experience generally leads to better code. You probably already see where I'm going with this.

Since in TDD the tests are written before the implementation code, why not use the failures generated by your tests as your to-do list? Think of what features and behaviors need to be implemented, then instead of writing a to-do list, write the tests for them. Using this method, you won't forget what you were supposed to do (because you'll have failing tests!) and you will have already created tests that you can continue to use during the life of your application for test coverage. With the other benefits of TDD (better code, test coverage, etc), I believe this is a win-win situation.

Let's look at an example using Rails and RSpec. In this example I've generated an Item model with its corresponding RSpec file. I need to enforce some validations on the attributes of my Item model; instead of writing a to-do list of what I need to do, let's write some tests instead:

If you run these tests they won't pass, they'll generate the following failures:


There it is. There is your to-do list. You can go through the failures one by one and implement the code to fix them. When you think of more feature you need to implement, simply write the tests for them so you don't forget. Using TDD you can use the time you normally spend meticulously writing to-do lists writing tests instead.

RSpec or Cucumber?

Since I'm trying to get more experience writing Rails apps lately, I'm making an effort to get to know some of the testing methods associated with Rails. The two frameworks that come up time and time again are RSpec and Cucumber, so I decided to focus on these. They're both considered behavior driven development (BDD) test frameworks and can both be used to accomplish the same goal. When it comes to deciding which one to use, I honestly think there's no reason for anyone to use Cucumber(unless under certain circumstances).

As I mentioned, RSpec and Cucumber are both BDD frameworks and theoretically can be used to accomplish the same goal. They can even both use Capybara for making the syntax very easy to read. The main difference between the two is that Cucumber is more suited for acceptance testing while RSpec is great for integration and unit testing. The problem with Cucumber is most developers try to use it for integration and/or unit testing, which is not what it's made for; Cucumber's plain English syntax is tailor made for acceptance testing. Let's take a look at an example of RSpec syntax with Capybara (taken from the excellent Rails tutorial by Michael Hartl):

And for comparison, take a look at a similar test in Cucumber (also from Hartl's tutorial):

If this Cucumber test seems like magic, that's because it sort of is - you need to define a step definition for each step of the test or else it won't do anything, which reveals one of the downsides of Cucumber, which is that it's not really attached to the code. When using Cucumber you have to not only write the Cucumber test, but you have to also write the step definition file that actually runs the code. As a developer, I have no reason to do this; simply use RSpec and be done with it. I don't need a more plain English way to perform testing, I understand RSpec just fine. This also explains why it's incorrect to use Cucumber for integration testing in the first place - the actual Cucumber tests aren't integration tests at all, they're simply acceptance tests.

It's apparent that RSpec is the better choice for testing, but I also mentioned earlier the possibility of using Cucumber under certain circumstances. The reason I think that's a possibility is when a project actually needs acceptance testing. This is probably only the case if you're working for a very large project or if your customer asks for acceptance tests (in my experience, most customers don't want or care about acceptance testing, they just want the product). You could even use both Cucumber and RSpec (acceptance testing for customers and integration testing for developers), but it's probably not worth keeping up with two separate test environments. If your project is a Rails app and you have a customer that requests acceptance testing, then Cucumber would be a good option; otherwise it's better to stick with RSpec or use another integration/unit testing framework.

For the final say in the matter, I recommend reading this article by Jack Kinsella. He says how I feel about the matter much more eloquently than I can.

Installing a Rails environment on OS X with Postgresql, Github, and Heroku

Recently I've been getting really into web development with Ruby on Rails. Most of my professional experience is with Java or C++, but I'm working on building up my portfolio with some Rails (and possibly Django) applications. For the last several months I've been learning to develop Rails apps on an Ubuntu virtual machine running on Windows 7. However, I had been in the market for a new laptop and decided to go with a Macbook Air. While setting up my Rails environment became routine on Ubuntu, it's a little different setting it up on OS X. It's not hard, but the information is scattered among several different sources and articles, so this post is meant to consolidate some of that information.

The first thing you'll want to do is to go through this tutorial by Moncef Belyamani. Going through this tutorial step by step will get you up and running with Rails on OS X, for the most part. By the time you get done with it, you'll have XCode, Homebrew, Git, RVM, and Rails installed on your system. I also include Postgresql, Github, and Heroku as part of my development stack; if you're not interested in any of that you can stop after this article and enjoy your OS X Rails experience. However, if you're new to Rails I encourage you to keep reading and at least include Github and Heroku as part of your environment (by default, Rails comes with SQLite so Postgresql is optional, but there are benefits to using it as explained below).

The next step is to install Postgresql, and Moncef Belyamani has another excellent article on how to get it up and running. This article walks you through how to install Postgresql on OS X (you can obviously skip the steps to install homebrew since you just did that in the last article). The article also tells you how to install lunchy, which is a gem for starting/stopping your postgres server. After installing, you'll want to create a username and database for your Rails app. You can find steps to do that here (skip to the section titled 'Create a user and database'). Make sure you use the postgres shell to verify your database was successfully created. Remember the name of the database you create, because you'll be using it in the next step.

At this point there is just a little bit more configuration to do to get Rails up and running with Postgresql, mainly with the database.yml file. If you have an existing rails app that you're migrating to Postgresql, you need to update the database.yml file's 'database' and 'adapter'. For example:

Make sure the name in your development database entry matches the name of the database you created (remove the db/ path if it's there; that's a holdover from sqlite). Also, change the adapter from sqlite to postgresql.

If you're creating a new rails app, make sure you run the rails new command with the flag for postgresql:

You have git already installed, but chances are if you want to use Github you're going to need to generate a new SSH key and register it at Github. You can find steps to do that here. Once you are able to push to Github, the last step is to be able to push to Heroku. You will need to download the Heroku Toolbelt and register for a Heroku account if you haven't already. You also need to register your SSH with Heroku (similar to Github) in order to push to it. You can accomplish that with the following command:

Now you can push your git repository to Github and then push it to Heroku to view your Rails application in production. Heroku uses the Postgresql database for deployment and it is strongly recommended that you develop with the same database as you deploy for production, hence why I have Postgresql on my OS X machine for development.

Now that you've completed these steps, you should be ready to go with Rails, Postgresql, Github, and Heroku. I highly recommend the Ruby on Rails Tutorial by Michael Hartl. It's a free online resource and goes through the steps of creating a non-trivial Rails application and uses the same environment you just installed on your machine. In my opinion, it's the best resource to learn Rails.

I hope this post helped with your OS X Rails setup (or at least pointed you in the right direction). If you have any comments or suggestions, please post them in the comments section.

Pointers for Java Programmers

I find myself in a situation where I need to refresh my C++ skills. This is one of a series of posts where I’ll cover some basics of C++.

If you’re decent at Java, chances are you understand pointers just fine, you just may or may not realize it. A common misconception I see in a wide range of Java developers, from students to even some professionals, is that Java passes primitive types by value and arrays, class, and interface types (reference types) by reference into methods. While it’s true that primitive types are passed into methods by value, the latter half of the previous sentence is not necessarily true. What happens is that when you pass in a reference type into a method, the reference itself is passed by value. What this means is that if you pass in an reference type into a method in Java, you can modify the object because the argument is a reference to that object. Since the reference is passed by value though, if you assign it to a new object (a new address), the original reference type will not be assigned to that new address. When the program exits out of that method, the old reference type (the object you passed in) will still be pointing to the original location in memory. Take a moment to let that sink in. Here’s some Java code to illustrate what I’m talking about.

public class PointerFun 
{
	public void manipulatePrimitiveValue(int x)
	{
		x = 10;
	}
	
	public void manipulateReferenceValue(StringBuilder s)
	{
		s.append(" World!");
		s = new StringBuilder("How are you?");
	}
	
	public static void main(String[] args) 
	{
		PointerFun p = new PointerFun();
		
		int y = 5;
		p.manipulatePrimitiveValue(y);
		
		StringBuilder hello = new StringBuilder("Hello");
		p.manipulateReferenceValue(hello);
		
		System.out.println(y);
		System.out.println(hello);
	}
}

Since we know primitive values are passed into methods by value, we already know the first line printed out will be 5. What will the second line print? If reference types were passed by value, then it would be “Hello”, if they were passed by reference, then it would be “How are you?”. However, since the references themselves are passed by value, the second line will output “Hello World!”. The method takes in a copy of the reference to the object - now we have two references pointing to the same location in memory: the instance of StringBuilder we named “hello” in the main method, and the instance of StringBuilder named “s” in the manipulateReferenceValue method. Since s points to the same address as hello, we can use s to manipulate that object all we want. As soon as you assign s to a new StringBuilder object, it is no longer pointing towards the same address as hello. So changing s won’t do anything to the object pointed to by hello. Therefore, when we print out hello, it prints out the original object, which now has a value of “Hello World!”.

So, in Java you have already been exposed to a lot of the basics of pointer. So a healthy attitude to take is not to think that C++ is harder than Java in terms of pointers, but instead it is much more flexible. The only thing you really need to do is memorize the syntax. For instance:

#include <iostream>

void manipulateByValue(int x)
{
	x = 10;
}

void manipulateByReference(int* x)
{
	*x = 10;
}

int main()
{
	int y = 5;
	int z = 5;

	manipulateByValue(y);
	manipulateByReference(&z);

	std::cout << y << std::endl;
	std::cout << z << std::endl;

	return 0;
}

Using pointer syntax you can pass any value by reference or by value. See? More flexible. I also recommend this tutorial for pointers. It’s one of the better tutorials out there.