Category Archives: IDEs

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 http://dartlang.org 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");
  button.onClick.listen(addResult);
}

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() {
  query("#theButton")
    .onClick.listen(
        (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.”