Category Archives: IDEs

Getting Started With Meteor Tutorial (In the Cloud)

In this Meteor tutorial, I am going to show you how to quickly get started with the JavaScript Framework, Meteor, to develop a Meteor application completely from the cloud.

I’ve been pretty excited about Meteor since I first saw a demo of it, but it can be a little daunting to get started, so I thought I’d create a simple tutorial that can get you running in about 30 minutes or less.

I’ve included a YouTube video along with this blog post to help you get up-to-speed quickly.

What is Meteor?

Before we get started we should talk about exactly what Meteor is.

Meteor, or Meteor JS, is really more of a JavaScript platform than a framework. It’s built on top of Node.js and is based on the idea of creating a high-quality, reactive, web application very quickly.

Meteor is purely JavaScript. That means that the entire application is built using JavaScript. Part of it runs on Node.js on the server, and part of it runs on JavaScript in your browser.

Meteor basically provides all the plumbing for you to build a Single Page Application or SPA, without you having to wire everything up and worry about syncing data and updating templates.

What is a cloud IDE?

When I first heard of a cloud IDE, I didn’t really understand what it was–rather, I didn’t grasp how valuable a cloud IDE was. A cloud IDE will let you develop and run an application completely in the cloud with your browser.

This means that you can log into your IDE from any web browser and start developing your application.

For Meteor, this is really neat because you don’t have to install and run Meteor locally. You can utilize a Cloud IDE to run and develop a Meteor application completely on a Linux box in the cloud. You don’t even have to know much about Linux.

digital ocean   Cloud9   Google Chrome 2014 10 12 14 41 17 Getting Started With Meteor Tutorial (In the Cloud)

Now, I found that most of the Cloud IDEs out there were a bit sluggish when trying to run a Meteor application on them. I had almost given up, until I discovered that I could hook up the Cloud9 IDE with my own more powerful Linux virtual machine that is hosted at Digital Ocean.

This setup was so fast and impressive that it is completely worth setting up, so in this tutorial, that is where were are going to start.

Getting set up

The first thing you’ll need to do to get set up is to create a Digital Ocean account. Digital Ocean provides extremely cheap Linux virtual machines in the cloud. In fact, this website is hosted on a Digital Ocean machine that I pay $20 a month for (and it gets over 100k hits a month.)

Like I said before, you can just use the Cloud9 IDE by itself for running your Meteor app, but if you instead utilize a $10 / month Digital Ocean box, you’ll find everything to run about 3-to-4 times as fast–no joke.

The other alternative is to download and install Meteor on your own Linux box or Mac, but I like how easy it is to develop in the cloud–especially since you can do real-time collaboration with another developer.

If you want to use your own machine and don’t want to use a cloud IDE, just skip down to the section where we install Meteor and you can follow the same instructions, just on your own machine.

(By the way, the above link is an affiliate link–just wanted to let you know–so thanks if you sign up through it.)

Creating a Cloud9 account

Next, you’ll need to create a Cloud9 account. You can just sign up for the free account for now, but if you want more private workspaces, you’ll need to sign up for a paid account. I find the prices to be pretty reasonable though.

(By the way, the link for Cloud9 is not an affiliate link. They don’t have an affiliate program, but I still recommend them, because they are awesome–especially when hooked up to a Digital Ocean box.)

Connecting Cloud9 with Digital Ocean

The next step is to create a new Digital Ocean box that we are going to use SSH to connect to from the Cloud9 IDE. Don’t worry though, this is easier than it sounds.

Rather than repeating all the steps here, you can watch this excellent video that a Cloud9 developer put together that shows you exactly how to do it:

Installing Meteor

Now that we are all set up, we need to get Meteor installed. Fortunately, this is pretty easy. In fact, you can do it with a single command.

Just execute the following command at a terminal window:

curl | /bin/sh

This command will pull down and execute a shell script which will install Meteor in your environment.

Yes, it really is that simple.

If you want to test out your Meteor install, execute the following command to create an example application that you can play around with:

meteor create –example leaderboard

This will create an example Meteor application called “Leaderboard.” Now, execute the following commands to switch to the Leaderboard project’s directory and start the application:

cd leaderboard


If all is well, you should see Meteor start a MongoDB instance as well as itself. You can connect to your Leaderboard app by going to the IP address of your machine and port 3000.

If you are using a Digital Ocean box, just use the same IP address you used when you set up the SSH connection to Cloud 9.

Go ahead and play around with the Leaderboard example app and take a look at the code. To really see the power of Meteor, you’ll want to open up two browser windows, each pointing at the app and see what happens when you make a change in one.

The Meteor tutorial app we are going to create

Ok, now we are ready to move on to creating our own Meteor application.

The application we are going to create is going to be a very simple TODO list application that we’ll call “Spartan TODO.”

The application will have a very simple UI and have the following basic features:

  • Show a list of items to be done
  • Add a new item to the list
  • Click an item to toggle it to and from a “done” state
  • Double click an item to delete a done item (I’ll leave this one for an exercise for you to do on your own.)

A pretty simple application, but it will take us through a pretty good cross-section of what Meteor can do. So, let’s get started.

Creating the project

The first thing we need to do is to create a new Meteor project.

In order to do that we just need to go back a directory from the Leaderboard project and create our TODO list app project. In order to do that execute the following commands:

cd ..

meteor create spartan-todo

This will create a default “Hello World” project for us in Meteor that we can modify to create our own project. Let’s go ahead and start it up with:

cd spartan-todo


Ok, so here is something pretty cool about Meteor: The whole time we are developing our application we can just leave it running. We can make changes to our application and–without having to recompile or restart the application–those changes will be applied live. We don’t even have to refresh the web browser. This is pretty cool.

Point your browser to the address of your machine and port 3000 to see the application.

Go ahead and try changing some text in the HTML to see it update live.

What’s in the Meteor tutorial project?

Before we move on, let’s take a quick moment to talk about what is in the Meteor project we created.

If you look in the spartan-todo directory, you should see 3 files:

  • spartan-todo.css – the style sheet file for our entire application
  • spartan-todo.html – the main HTML file that will be displayed
  • spartan-todo.js – the JavaScript code that will execute on both the client and the server

Meteor is pretty flexible in how you structure your project. The default app template is a very simple project structure, which we’ll stick with for this Meteor tutorial.

With this structure, you can expect the HTML file to be rendered using Meteor’s templating language, Spacebars (very similar to Handlebars.js) You can define any templates you want your application to use inside this HTML file, or you could create additional HTML files that this main HTML file references. The name of the file doesn’t matter, Meteor will just look for all the HTML files in your project and will actually create a single HTML document to be transferred to the client. But, for the purposes of this Meteor tutorial, you can ignore that. We are just going to use one HTML file.

Another important thing to point out is that by default all the JavaScript files are run on both the client and the server. So, again, it doesn’t matter what your JavaScript files are named, all the code will be executed. You can see in the spartan-todo-.js file that there is some code that says:




We can use those functions to have code only run in the client or the server, if we need.

There is also a folder convention we can use that controls whether code runs on the client or server or both, but for now we’ll ignore that and keep everything in these three files.

You can find the exact details on how this works in the Structuring your application section in the official Meteor documentation.

Creating the user interface

Now that we have a running Meteor tutorial application, the first thing we are going to do is create a hard-coded version of the UI that we’ll be using in our application.

I always find it is best to start by just hard-coding all the HTML for a screen in an application, before going and adding real functionality. It makes things less confusing and you don’t waste time trying to change layouts and code at the same time.

Open up your spartan-todo.html file and replace its contents with the following code:

This will create our basic user interface for our application. If you switch to your browser, it should auto-update and you should see something that looks like this:

hardcoded ui Getting Started With Meteor Tutorial (In the Cloud)  

Using templates

The next step will be to go from having a completely hard-coded HTML page to an HTML page that uses hard-coded Spacebars templates. In Meteor, we can define templates in our HTML files in order to break up and abstract away parts of our application as well as allow for our HTML to be generated based on data from our application. For now, we are going to keep things pretty simple. We are just going to break apart our HTML into a couple of templates. Replace the contents of your spartan-todo.html file with the following code:

When you go back to your browser, you shouldn’t see anything different, but now we are utilizing templates–just not very well.

Populating data with templates

The next step is to make it so the templates are actually being populated with data from our application. We are going to start off by hard-coding the data, in the application, but making it so the templates use that data to render the HTML.

Again, I like doing this baby-step approach–especially when starting out.

What we really want to do is make it so that the <li> elements we have in the HTML are not hard-coded, but are generated by some data that defines the items in our list.

We can do that in Meteor by utilizing the #each syntax in the Spacebars template.

Replace the content of your spartan-todo.html file with the following code:

What we’ve done here is replace the hard-coded list items with some templatized code that tells Meteor to loop through some collection of things called items and for each thing in that collection to write out a list item and a field from that item called “description.”

So, in order to get this template to work, we need to provide the template with a collection named “items” and the items in that collection need to have a field named “description” that has the description of the TODO list item we want.

In Meteor, the simplest way to do this is to utilize what are called template helpers. We can create a template helper in our JavaScript file that will define the data that will be returned when the template looks for “items.”

Replace your spartan-todo.js file with the following code:

This code defines a helper for the template named “list” called “items”. That “items” helper contains a function that returns a hard-coded list of items in the form of a JavaScript array. Each of the items has a description field.

When Meteor renders the template, it will utilize the helper method to fill in the data the template needs.

After you’ve made this change and saved the file, your browser should automatically reload the changes, and you should see the new TODO list items we created.

Now, the data is still hard-coded, but it is coming from the actual application itself.

Populating data with collection

We still are hard-coding data and we have no way to add new items to our TODO list, but before we can fix that problem, we need to move the data down just one more layer and introduce an important concept in Meteor called “collections.”

Remember how I said Meteor uses a MongoDB as a document database for your application? Well, that is where we ideally would like to store our TODO list items.

In order to do that, we need to define a collection in our Meteor app, which we can use to populate our MongoDB and query it later to get TODO list items back out of it.

In Meteor, by default any collections we define on the server are also available on the client. What this means is that in your browser, you can actually interact with the application’s MongoDB instance as if you were writing server code.

Meteor does this by creating a MongoDB proxy on the client side that forwards data down to the server. This MongoDB proxy is also kept in sync with the server instance by default. So, that means any data that exists on the server, can be accessed directly from the browser. (This is the default behavior, which you’ll want to eventually turn off in your application and specify manually which data to sync, but for the purposes of this Meteor tutorial, we’ll take advantage of this.)

Replace the contents of your spartan-todo.js with the following code:

There are two things we did here. First, take a look at line 1. Here we declared a new Meteor collection called items. Since this code is outside of the client and server blocks, it will be run on both the client and the server. We don’t have to write the same code twice. This code will define a MongoDB collection we can use in our application. With a document database, like MongoDB, we don’t have to declare what fields are on the collection or anything else.

Next, take a look at lines 13 through 22. What we are doing here is populating some default data if the MongoDB collection is empty. This will just give us some seed-data to work with. We could leave this code out, but if we did we wouldn’t be able to tell if everything was working.

Finally, take a look at line 6. Here, we have updated our helper function for items to cal Find() on the Items collection to get its data instead of using the hard-coded values we had before. If you switch over to your browser, you should see the TODO list with the default items we added to the collection. Now that our application is being driven by real data in a database, we can add some actual real functionality to our Meteor application.


Adding items

The first real bit of functionality we are going to implement will be to add new items to our list. In order to do this, we just need to add new items to our Items collection and Meteor will take care of the rest for us.

We’ll need to utilize template events to execute some code when someone clicks the add button to add a new item to our list. In Meteor, we can define events on a template, just like we can define helpers. You can really think of these as event handlers, since we’ll be writing code to handle different events that occur inside the template.

What we want to do is to define an event on the controls template that will be triggered when the form is submitting. This could happen when someone clicks add, or when they hit enter on the keyboard. In our event handling code, we’ll want to cancel the default action of submitting the form to the server, since we’ll handle everything in our client code.

Then, we’ll want to get the description of the item from our text input and insert a new item into our Items collection. Meteor will know that there is a change in our collection and will respond by rerendering the affected part of the DOM in the browser. Meteor templates are by default “reactive” in this way and constantly watch for changes that would affect the HTML they rendered.

Replace the contents of your spartan-todo.js file with the following code:

Take a look at lines 10 through 17.

What we are doing here is adding an event handler for the “submit form” event. Whenever the form is submitted on the page, this code will be executed.

In this code, we are first canceling the default action, which is to post the form to the server.

Them, we use some JQuery to grab the value of the newItem text input and store it in a variable.

Finally, we insert a new object into the Items collection with the proper description.

After you save this code, you can go ahead and try it out. Add a few items to the list. You can also try opening a second browser and watching how the data is synced between both clients.

Marking items done

The last step we want to do in this Meteor tutorial is to make it so that we can mark items as done by clicking on them and unmark them by clicking a second time.

Again, we will need to use events to do this.

The basic idea will be to create an event handler that will respond to a list item being clicked in the list template that will toggle a “done” field on the item to indicate whether or not the item should be marked as done.

We’ll use a CSS class that will apply a line-through to the list items marked as done.

Let’s start with the CSS class. Just add the following line to your spartan-todo.css file:

.done {
text-decoration: line-through;

Next, replace the contents of your spartan-todo.js file with:

Let’s start by looking at lines 25 through 30.

What we’ve done here is created a new event handler for the list template that will trigger when a list item is clicked. This event handler will simply update the item in the Items collection by setting a “done” field on it to the opposite of what it was. This will result in the done field being set to true the first time it is clicked and from then on toggle between the two values.

How do specify which item we want to update?

Every object in our collection automatically gets a special field named “_id.” We can use this field to uniquely identify each item. But, how do we get a reference to the item?

You may have noticed the “this” keyword being used in this code. Whenever we are executing event handling code in a template, the this variable always points to the data that triggered the event. We automatically get the correct context, so when we refer to “this._id,” we get the ID of the object that represents the list item that was clicked on.

Notice also the special syntax we have to use to update an item and set a new field value in MongoDB. It might seem a little bit strange, but that is how it is done in MongoDB.

Next, take a look at lines 8 through 13.

Here we are defining a helper function called “doneClass” that will either return the string “done” or an empty string, depending on whether or not the item being evaluated when this helper is invoked in the template.

We can use this code to make it so the list template can assign our “done” class only to items that are marked as done.

In order to do this, simply replace line 15 in your spartan-todo.html file with the following code:

<li class=”{{doneClass}}”>{{description}}</li>

Save everything and open your browser and you’ll find that you can now click on items to mark them as done and click on them again to mark them as undone.

The template calls our helper function “doneClass” to determine what text to insert into our class statement on each li element.

Deleting items

Ok, now it’s your job to implement deleting items in our Meteor application.

I’ll give you a bit of a hint. You can utilize the “dblclick li” event to make it so that whenever someone double clicks a list item it is deleted. See if you can figure out how to implement that functionality in the Meteor app.

Meteor tutorial wrap up

So, there you have it: a very simple TODO list application in Meteor. I’ve actually created a screencast you can watch to follow along, if you’d like. You can find it below:

If you happen to be in the Copenhagen area or are planning on attending the At the Frontend conference on Nov 4th 2014, I’ll be there doing a “Getting Started With Meteor” session where I’ll be creating this TODO list application and going over a little more about Meteor.

If you found this tutorial helpful, please share it with anyone who you think might be interested.

Also, join over 5,000 other developers who are part of the Simple Programmer community by signing up here. You’ll get weekly emails with career tips, tutorials and other practical advice for software developers and special discounts on Simple Programmer products.

Some additional resources

Also, if you are looking to dive a little deeper into Meteor, I’d recommend starting out with this excellent book that you can get for just 99 cents, “Your First Meteor Application: A Complete Beginner’s Guide to the Meteor JavaScript Framework.”

And, I have created a Pluralsight course called “Meteor.js Fundamentals for Single Page Applications” that covers Meteor much more in-depth.

Getting Started With Google’s Dart Language

I was a little skeptical of the Dart language when Google first announced it.

When I looked at the syntax of the language I thought that it didn’t really seem to offer anything new.

Why create another language that is not very different than what we already have?

How is this actually much better than JavaScript?

But after having worked with Dart now for quite awhile and producing a Pluralsight course on Dart, I’ve completely changed my mind.

The Dart language is awesome!

What makes the Dart language so awesome is all the little subtleties the language designers added to the language, not any major new concepts or ideas.

When I started writing Dart code it felt exactly right.  It felt like all the little annoyances that I had with languages like C#, Java and JavaScript were removed by the Dart language.

In fact, the real beauty of Dart is that if you already know C# or Java and JavaScript, you’ll probably be able to learn enough about the Dart language to be productive in Dart in less than an hour.

Before I show you just how easy it is to get started, let me briefly tell you what the Dart language is:

  • Object oriented.  Everything is an object including primitives and nulls
  • Optionally typed.  You can add type annotations which static checking tools can use to help you find errors in your code, but you don’t have to use them.
  • Interpreted.  Dart is run in a VM, but it is not compiled first.  Round-trip time for making changes is very short.
  • Compatible with JavaScript.  You can compile your Dart code to JavaScript and run Dart applications in any modern browser.
  • FAST!  Dart is very fast, much faster than JavaScript in just about every test.

Some cool language features that I like about the Dart language:

  • Mixins.  Instead of using inheritance, you can use a mixin to add functionality to a class without directly inheriting from another class.
  • Isolates.  Instead of threads, the Dart language uses isolates for concurrency.  Isolates can’t actually share any memory, they pass information though messages.  It is very hard to shoot yourself in the foot.
  • Simplified built-in types.  Numbers can be either int or double, and you can just use num, if you don’t care.  Lists and maps can be declared as literals.  An array is just a special case of a list.
  • Functions are first-class objects.  You can pass them around just like any other object.  There is even a lambda-like short-hand for creating a one-liner function.
  • Top level functions and variables.  Don’t want to put a function or variable in a class?  Good, you don’t have to.  In the Dart language, you can declare them anywhere you want.
  • Simplified classes.  There is short-hand for declaring constructors that assign parameters to class members.  Class members don’t have protected, private, public.  Member variables are automatically properties.
  • String interpolation.  No more string format methods, just use the $variableName in a string to have its value expanded.

Getting setup with the Dart language

Ready to get running in 5 minutes?

Ok, read on.

Step 1: Go to and click “Get started.”

2013 06 16 11 12 28 thumb Getting Started With Google’s Dart Language

Step 2: Download Dart (64-bit or 32-bit.)  Unzip the file and copy the “dart” folder to where you want Dart installed.

This folder will contain the Dart Editor, the Dart SDK and the Chromium web browser which has a built-in Dart VM.

Step 3: Run DartEditor.exe

Dart Editor 2013 06 16 11 18 01 thumb Getting Started With Google’s Dart Language

That is it, now you are ready to rock some Dart code!

Creating your first Dart language App

The Dart language can actually be used outside of a browser, just like you can use JavaScript with Node.js.  But, most developers will probably want to use Dart the same way we use JavaScript in a web application today.

I’m going to walk you through a real simple example that will show you how to create a basic Dart application that is able to respond to a button click and manipulate some DOM data.  For more advanced examples, you can check out my recently released Pluralsight course on Creating Web Applications with Dart. (I will plug this one more time before this post is over… wait for it…)

Step 1:

Go to File –> New Application.

Fill in your application name.  I’ll call mine HelloWorldDartWeb.

Leave “Generate sample content” checked.

Select “Web application.”

2013 06 16 11 24 03 thumb Getting Started With Google’s Dart Language

Step 2:

Open the helloworlddartweb.html file and clear out everything in the body element except for the two script tags at the bottom.

The first script tag imports our actual Dart file, just like you would use to add JavaScript to a page.

The second script adds Dart support to the browser.

Step 3:

Add the following HTML to the body tag in the helloworlddartweb.html file:

 <button id="theButton" >Press Me!</button>
 <div id="resultDiv"></div>

This will just create a button and a div.  We are going to add some Dart code to respond to a button click and populate the div with some text.

Step 4:

Open the helloworlddartweb.dart file and clear out everything in main() and delete the reverseText function.

Notice that there are only two things we really will need in our .dart file.  Just an import ‘dart:html’, to import that html library for Dart, and the main function, which executes as soon the DOM content is loaded on the page.

Step 5:

Edit the helloworldweb.dart file to make it look like this:

import 'dart:html';

void main() {
  var button = query("#theButton");

void addResult(Event e) {
  var resultDiv = query("#resultDiv");
  resultDiv.text = "You clicked the button";

This code simply gets the button using a CSS selector.  It uses the query function to do this.

Then we register the addResult function as an event handler for the onClick event for the button.

In the addResult function, we simply query for the resultDiv and change its text.

After you run this example, you should see a result like this:

HelloWorldDartWeb   Chromium 2013 06 16 11 47 56 thumb Getting Started With Google’s Dart Language

Step 6:

Now change the Dart code to look like this:

import 'dart:html';

void main() {
        (e) => query("#resultDiv").text = "You clicked the button!"

Try running the code again and you should see it works exactly as before.  Here we just shortened the code to a single line by using the short-hand function syntax.

Going further with the Dart language

So, that is just the basics of Dart.  I wanted to show you how to get started really quickly, but I am sure there is more you will want to learn about Dart.

We can of course do much more with Dart, especially when building web applications.  There is a Dart Web UI library which can be used to do templating and data binding so we can simplify our Dart code even further.

The language itself is pretty simple.  Most C# and Java developers, as well as JavaScript developers, should be able to read and understand Dart code without any assistance.  But here is a link to an overview of the language.

If you are looking for a more in-depth coverage of the Dart language and want to see how to build a real application with Dart, check out my Introduction To Building Web Applications With Dart course on Pluralsight, where I go over the entire language and guide you through building a real application, as well as cover some of the more advanced features like mixins and isolates.

Also, I could only find two books on the Dart Language.

I don’t know if Dart will end up replacing JavaScript, but I do think Dart has the potential.  It really is an awesome language that is fun to develop in.

That is strong praise coming from me, since I really tend to dislike dynamic languages.  The creators of Dart have really done a good job of creating a language that is succinct, fast, easy to work with and has the best advantages of strongly typed languages with all the flexibility of dynamic languages like JavaScript.

Get Up and CODE and YouTube Videos

For those of you who frequent my blog and are looking for my latest Get Up and CODE podcast episode and YouTube video for the week, I have a bit of an announcement.

I am going to start posting these blog posts every Monday.

The YouTube videos will be going up every Wednesday.

The Get Up and CODE podcast will be coming on every Friday.

When my new website design is done, you’ll be able to find the latest episodes of each on the side bar, so I’ll stop including them in each weekly post.

But here is last week Get Up and CODE, where Iris and I talk about basic weight training.

Get Up And Code 006: Basic Weight Training

play audio Getting Started With Google’s Dart Language

Living Dangerously: Refactoring without a Safety Net

It’s usually a good idea to have unit tests in place before refactoring some code.

I’m going to go against the grain here today though and tell you that it is not always required.

Many times code that should be refactored doesn’t get refactored due to the myth that you must always have unit tests in place before refactoring.

In many cases the same code stays unimproved over many revisions because the effort of creating the unit tests needed to refactor it is too high.

I think this is a shame because it is not always necessary to have unit tests in place before refactoring.

manonwire3 thumb Living Dangerously: Refactoring without a Safety Net

Forgoing the safety net

If you go to the circus, you will notice that some acts always have a safety net below because the stunt is so dangerous that there is always a chance of failure.

You’ll also notice that some acts don’t have a safety net because even though there is risk of danger, it is extremely small, because of the training of the performers.

Today I’m going to talk about some of the instances where you don’t necessarily need to have a safety net in place before doing the refactor.

Automatic refactoring

This is an easy one that should be fairly obvious.  If you use a modern IDE like Visual Studio, Eclipse, or IntelliJ, you will no doubt have seen what I call “right-click refactor” options.

Any of these automatic refactors are pretty much safe to do anytime without any worry of changing functionality.  These kinds of automated refactors simply apply an algorithm to the code to produce the desired result and in almost all cases do not change functionality.

These refactoring tools you can trust because there is not a chance for human error.

Any time you have the option of using an automatic refactoring, do it!  It just makes sense, even if you have unit tests.  I am always surprised when I pair up with someone and they are manually refactoring things like “extract method” or “rename.”

Most of the time everything you want to do to some code can be found in one of the automatic refactoring menus.

Small step refactors

While not as safe as automatic refactors, if you have a refactor that is a very small step, there is a much higher chance your brain can understand it and prevent any side effects.

A good example of this would be my post on refactoring the removal of conditions.

The general idea is that if you can make very simple small steps that are so trivial that there is almost no chance of mistake, then you can end up making a big refactor as the net effect of those little changes.

This one is a judgment call.  It is up to you to decide if what you are doing is a small step or not.

I do find that if I want to do a refactor that isn’t a small step refactor, I can usually break it down into a series of small steps that I can feel pretty confident in.  (Most of the time these will be automated refactors anyway.)

Turning methods into classes

I hate huge classes.  Many times everyone is afraid to take stuff out of a huge class because it is likely to break and it would take years to write unit tests for that class.

One simple step, which greatly improves the architecture and lets you eventually create unit tests, is to take a big ol’ chunk of that class, move it to a new class, and keep all the logic in there exactly how it is.

It’s not always totally clean, you might have to pass in some dependencies to the new method or new class constructor, but if you can do it, it can be an easy and safe refactor that will allow you to write unit tests for the new class.

Obviously this one is slightly more dangerous than the other two I have mentioned before, but it also is one that has a huge “bang for your buck.”

Unit tests, or test code themselves

Another obvious one.  Unless you are going to write meta-unit tests, you are going to have to live a little dangerously on this one.  You really have no choice.

I think everyone will agree that refactoring unit tests is important though.   So, how come no one is afraid to refactor unit tests?

I only include this example to make the point that you shouldn’t be so scared to refactor code without unit tests.  You probably do it pretty frequently with your unit tests.

I’m not advocating recklessness here

I know some of you are freaking out right now.

Be assured, my message is not to haphazardly refactor code without unit tests.  My message is simply to use temperance when considering a refactor.

Don’t forgo a refactor just because you are following a hard and fast rule that you need unit tests first.

Instead, I am suggesting that some refactorings are so trivial and safe that if it comes between the choice of leaving the code as it is because unit testing will take too long, or to refactor code without a safety net, don’t be a… umm… pu… wimp.  Use your brain!

Things that will bite you hard

There are a few things to watch out for, even with the automatic refactoring.  Even those can fail and cause all kinds of problems for you.

Most of these issues won’t exist in your code base unless you are doing some crazy funky stuff.

  • If you’re using dynamic in C#, or some kind of PInvoke, unsafe (pointer manipulation) or COM interop, all bets are off on things like rename.
  • Reflection.  Watch out for this one.  This can really kick you in the gonads.  If you are using reflection, changing a method name or a type could cause a failure that is only going to be seen at runtime.
  • Code generation.  Watch out for this one also.  If generated code is depending on a particular implementation of some functionality in your system, refactoring tools won’t have any idea.
  • External published interfaces.  This goes without saying, but it is so important that I will mention it here.  Watch out for other people using your published APIs.  Whether you have unit tests or not, refactoring published APIs can cause you a whole bunch of nightmares.

This list isn’t to scare you off from refactoring, but if you know any of the things in this list are in your code base, check before you do the refactor.  Make sure that the code you are refactoring won’t be affected by these kinds of things.

Why The IDE Has Failed Us

There is so much talk lately about using VI instead of Visual Studio, or VI in general instead of whatever IDE you normally use.

If you never had the fortune of being introduced to VI, it is basically a bare bones text editor designed to be used without a mouse and focused more on manipulating text than creating it.  VI is on just about every platform you can think of and will be for the foreseeable future.

It is not my point today to bash VI.  VI is a great text editing tool that can make you a wiz at slinging lines and words around your files.  VI is the evolution of text editing because when you are using VI you are actually programming your text.

microsoft visual basic for msdos professional edition version1 00 thumb Why The IDE Has Failed Us

The problem with IDEs

Basically there are two problems with IDEs.  One I think is a valid complaint, the other appeals to engineers wanton desire to be simple, pure and take things apart.

The Bloat

The first problem with modern IDEs is the bloat.  The IDEs are big beasts that take up lots of memory, are fairly slow to load, and tend to have so many bells and whistles that they feel messy and clunky.

As I write this part of me thinks “what’s the big deal?”  I’ve got a pretty fast machine, it can run VS2010 pretty well.  But, there is something that doesn’t sit right for me and I am sure for other developers.  The IDE should feel clean, but it doesn’t.

I’m not sure if I can completely identify why IDEs have suddenly gone sour in our mouths.  Perhaps part of the bloat problem is that the IDE has kind of become a swiss army knife instead of a focused tool.

Strangely enough, I think part of the problem might be tools like Resharper, that are helping us a little too much.  The tool is so good that sometimes you wonder what life would be like without all those little hints and the IDE doing so many things for you.  Perhaps sometimes you feel like you are “cheating.”

The Imagined

Then there are the imagined problems with IDEs.  The ones that don’t really have any justification, but some of the “cool kids” like to talk about on their blogs.

If I can summarize what I gleaned from the argument here, I would say it basically is… IDEs that give me auto-complete, intellisense, and visual designers rot my brain.  To really program I should be able to write code without the help of an IDE.

I couldn’t agree more with that statement.

As a matter of fact, for that reason I don’t use electric toothbrushes, because it is not really brushing my teeth.

I also abhor graphing calculators; it’s not really calculus unless you are cranking it out by hand.

Email? Psha, everyone knows the pure way to communicate is by registered mail typed from a typewriter.

Oh, and don’t get me started on those GPS things.  You are not really navigating if you aren’t using a map and a compass, seriously.

Sorry for all the sarcasm, but I hope you get my point.

What is the solution then?

Is it to abandon the IDE and jump over to VI and notepad to edit our files so we don’t “rot our brain?”

I know that is the popular stance among the best and brightest right now, but sometimes the best and brightest are wrong.  Sometimes they are so bestest and so brightest that they can navigate with a map and a compass better than you or I can with a GPS.

I think the solution is to bring more VI-ness to IDEs.  The good thing about jumping to VI is that you can sling text around like nobody’s business.  The bad thing about jumping to VI is that you are forgoing some of the most useful productivity tools in dealing with APIs and libraries.

Why can’t we take the good VI-ness and put it into Visual Studio?  Looks like someone already has (ViEmu.)

The other part of the problem is the bloat.  Honestly, I think Eclipse deals with this fairly well, by making everything modular.  Unfortunately, some of the modules look plain ugly and don’t integrate well into Eclipse, but with Visual Studio you have to pull out a swiss army knife with 50 gadgets on it when you are just trying to eat some beans with a fork.

The answer is modularization and perhaps some competition for Visual Studio and some of the other IDEs that are a bit bloaty.  Perhaps we need an IDE that is built up from a VI or Emacs heritage?

I know for sure the solution is not to throw the baby out with the bathwater.  IDEs have made some truly amazing advancements that help bring the level of abstraction of software development to a much higher level.

Features like intellisense have made it easier then ever to hit the ground running with a new API like never before.

Automatic refactoring tools built into IDEs, and with add-ons like Resharper, have made refactoring code so much easier and so much more accessible.

Ctrl+Click goto definition and backwards / forwards navigation to jump to parts of the code greatly increase productivity.

I don’t need to go into all of the features of modern IDEs to make the point that there is value there and a large amount of it.

So before you abandon the IDE, consider strongly why exactly the IDE has failed us, and consider whether jumping to VI is really the best solution to the problem.  If you don’t know what problem you are trying to solve by jumping to VI, you might just be following the “cool kids” and drinking their “cool aid.”