The Ugly American Programmer: Bill Burke

I originally tried to post this as a comment on Bill Burke's Polyglotism is the worst idea I ever heard, but as far as I know, my comment is still awaiting moderation. So I'll go ahead and dissect it here. Burke starts with an alleged tongue-in-cheek:

Let me first start off with some tongue in cheek…I’m an American. I have no need to speak another language because well, I speak English. 99% of the civilized world speaks English so WTF should I ever learn another language? Case in point, I minored in German in college. For two semesters I went over to Munich and worked at Deutsche Aerospace so that I could learn German better. The thing is, besides the fact that my coworkers spoke damn good English to begin with, all the documentation they put out was in English, the units used were feet, pounds, miles. When the French came over to work with us, we also spoke English. So what is the freakin point of learning German? I was pretty damn disappointed that I wasted all this time in college learning German when in reality it was just a freakin useless exercise…

So we've taken the ugly American attitude and are now applying it to software development. Now, if he was trying to make the point that there is a lot of benefit to learning another language, his tongue-in-cheek disclaimer would make sense. But instead the above ignorant statement is followed by more ignorant rambling about using multiple languages in a project. He seems to think tongue-in-cheek means "I can say something ignorant and not be criticized for it".

Which brings me to the point of this blog. Polyglotism in software has to be the worst idea I ever heard. The idea of it is that you use the language that is best fits the job. Some say this is a huge boon for the developer as they will become more productive. In practice though, I think this is just a big excuse so the developer can learn and play with a new language, or for a language zealot/missionary to figure out a way to weasel in his pet language into a company. Plus, you’d probably end up being average or good at many languages but a master of none….But lets pretend that it is a benefit to the developer. Developers need to realize that there are implications to being polyglot.

Notice his focus on the single developer who is out to ruin things through his own selfishness (he must hate America!) No consideration is given to the benefits that a team and organization can derive from using multiple languages (which we will get to). His next point, maintenance:

So, you’ve added a Ruby module to that big flagship Java application or product your company is so proud of. You did it fast. It works. And management loves you for it. They love you so much for it, they’ve promoted you to software lead and now you are running a brand new project. Now that you’ve left your polyglot project, somebody needs to take over your work. Unfortunately, your group is a bunch of Java developers. For any bug that needs to be fixed, these developers need to be retrained in Ruby, a new Ruby developer needs to be hired, and/or a Ruby consultant/contractor needs to be brought it. Multiply this by each language you’ve introduced to your project.

Oh no, a Java programmer has to learn some Ruby! If you have any talented developers, they'll probably jump at the chance to escape Java hell and learn something new, assuming they haven't already learned Ruby on their own. "Multiply this by each language" is meaningless scare language. This assumes that skills are not transferable between programming languages. It's not at all difficult to be proficient in multiple languages. Many Java/PHP developers are also well versed in JavaScript (if you discount JavaScript at this point, I hope you have a career path that doesn't involve any programming for the web). Knowing multiple languages demonstrates mental flexibility and teaches a developer to think about problems in different ways. I would never hire a programmer that was only proficient in a single language.

The JVM is pretty cool now. We can run Ruby on it, Python on it, and even PHP on it. Your JRuby apps can work with Java APIs. Same with Jython and JPHP. Great. So now your developers can use any one of these language to build out extensions to your Java app. But what happens when you want to refactor one of your re-used Java libraries? OOPS!!!

Groovy and Scala are conspicuously absent from Mr. Burke's list. Could that be because they both compile to bytecode, and the resulting classes can therefore be used by any JVM language? So you could use Java, Scala and Groovy together in the same project in a completely interchangeable way, right now.

Ah, so you’ve weathered through the maintenance and refactoring nightmares and you’ve finally shipped your product. Hmm, but you’ve just added the complexity of installing multiple runtimes on your user base. Its not hugely bad if you’ve used the JVM as your base virtual machine. But you still need to package and install all the appropriate Java libraries, Ruby gems, and Python libraries on the appropriate places of your user’s machine. You also need to hope that all the desparate environments don’t conflict with anything the user has already installed on his machine. And that’s just with languages running in the JVM. Imagine if you used vanilla Ruby, Python and Java all as separate silos!

These new languages are used to reduce maintenance by dramatically reducing the size of the codebase, and simplifying application setup and ramp up times. Give me a domain model and I can have a functional Grails or Rails application running in less than an hour. And the code base will be a fraction of the size of the equivalent Java project. As for packaging, Maven handles Groovy and JRuby quite well. I'm sure PHP and Jython will have support soon enough, if they don't already (I don't know).

A support call comes in for your product or application. Its obviously a bug, but where is the problem? Is it your application code? Your JVM? Your Ruby VM? Your Java library? Your Ruby gem?

What an absurd statement. Where is the bug? I don't know, how do you normally find the bug in a "pure" application? Lets see, the date is parsed incorrectly and we're using some Ruby code to parse dates... Where could the bug be? Is it in the PHP templates? Only if you're an idiot. You could make the same argument about the MVC pattern and Hibernate. 3 layers? How will I know where the bug is? What if the bug is in a library? I better write it all myself in C. (Note that this is the correct way to make a tongue-in-cheek statement).

All and all, let me put it this way. We all work in multi-national environments. What if each developer documented their projects in their own native language, because lets face it, they are most productive in that language. Where would we be? Doing what’s best for oneself isn’t always best for the big picture

This last point about documentation doesn't even make sense. You write for your target audience. The compiler/interpreter is the intended audience of a programming language. You write Ruby code for the Ruby interpreter, Java for the Java compiler, etc.

The whole thing is absurd. You might as well say that SQL is a waste of time. The simple fact is that modern programmers use multiple languages in the same project with regularity, and the only ones who have trouble are the poorly trained & ignorant (who can hardly be called master of even the single language they know), and the old fogies, like Burke, who consider learning something new a waste of time.

When to go dynamic

The most typical complaint I hear from Java developers about Groovy is, "I spent X hours trying to figure out this problem that would've been a compile time error in Java." And they're right. Very little compile time checking is done in Groovy. It can't be done because methods may be available at runtime that aren't resolvable at compile time. That's part of what it means to be a dynamic language.

Some developers seem to think using the optional types will save them. e.g.,

int foo (String bar) {
 return bar.size()
}

Looks good, right? Try running this script:

int foo (String bar) {
 return bar.size()
}
if(false) {
 String s = foo(123)
 println s
}
println "Done"

Go ahead. Run that script. No error. Types aren't checked at compile time. If we change false to true, we get a groovy.lang.MissingMethodException at runtime, but that's it. Your compiler can't save you here. Good unit tests will catch some errors if you use the optional types, but you have to know what the error is before you can test for it, so you've already spent the X hours trying to track it down.

What makes Java so good for enterprise work is the static types. Static types enforce a contract. Static types make it possible for Eclipse to take you to the exact method that will be invoked by a particular line in the source. If the method is on an interface, Eclipse can tell you all types that implement that interface method and take you to any implementation you choose immediately. This is extremely useful when you're trying to navigate a complex, unfamiliar system. While a human may be able to easily figure out what file to open, having a tool that can do it for you automatically allows your concentration to remain on what the code does and lets you work at a higher mental level of abstraction.

If I have to learn a new framework that someone has written, I'll get through it 10x faster if it's in Java. No/bad documentation? Not a problem, I'll just look at the code for that method. Whereas if I come upon an undocumented Groovy method, what do I do? Ugh, I have to grep through all of the source to figure out where it's defined, how it's used, yada yada. Not quick. Breaks my concentration.

Java is very good at making large systems manageable. However, the trade off is that
any system that has been under active development for more than 2 weeks quickly becomes a large system. There is nothing concise about Java. There are very few shortcuts. The simplicity of the language and the rigidity of types means you have to write more code and produce more classes to get things done and God help you if you want anything remotely flexible. Code that needs to do something even slightly dynamic can quickly become unreadable and strewn with all kinds of reflection objects, odd exceptions and other nastiness. Or worse. You could end up in XML hell.

Enter Groovy. Dynamic languages do best when there are conventions and consistent ways of doing things. Grails is proof of this. Controllers are in the controllers folder, services in the services folder, etc. Each class follows a certain arechtype and there are good idioms in place that imply what is going on. However, when you start writing plugins, or doing things outside of the normal scope of Grails, things can get messy fast.

Anytime you're coding in uncharted territory, consider going back to Java. Writing a plugin? Implement as much of it as you can in Java. Only go back to Groovy if the equivalent Java code gets too ugly or would be many times longer. Most of your plugin/framework/new invention's plumbing should be in Java. The plumbing is where you connect everything together, and it's important to verify that thingDoer is of type ThingDoer, and that all interceptors properly implement the ThingDoerInterceptor interface. You want your API to fail fast so your users don't end up with a NPE exception deep in your code that they have no hope of debugging.

Keep Groovy at the fringes, handling the nasty implementation details, and protected by static types and good assertions. Make sure your Groovy class implements an interface, or better yet, have a Java class implement the interface and wrap the Groovy implementation so you can jump to it in Eclipse. Use Java to provide enforce the type contracts and provide a well defined framework. Use Groovy to make the implementation readable.

Mock object are making your tests stupid

Mock objects were created because when you're writing unit tests (especially in a statically typed language), it can be a pain to create a subclass/implementations to use for your tests. You need a mock whenever the class you are testing depends on another class. You want to guarantee that changes to the other class don't break your tests for this class, because that would defeat one of the purposes of unit testing: isolation of the failure to a particular class/method. So you want an object that, whenever getTemperatureOutside is called, returns 32 degrees.

Sometimes you also want to make sure that the method you are testing causes some side effect. e.g., if the temperature outside is less than 32 degrees, it should call deployIceScraperNarwhals(). So, you want a method that records that deployIceScraperNarwhals() was called (but doesn't actually deploy the Narwhals) and something that checks that it actually was called, failing the test if it wasn't. Thus, the idea of verifying method calls was inextricably bound to the idea of providing fake methods to isolate behavior and every genius-pants writing a mock object framework decided that the verification was the most important part, to be emphasized throughout the documentation.

Then you came along, read the mock object documentation and proceed to go and write unit tests like this (mock object syntax is made up):

class UnderTest {
 int calculate(Foo foo,Bar bar) {
    int a = foo.getA()
    int b = bar.getB()
    return a + b
 }
}

class UnderTestTest {
  void testCalculate() {
     Foo foo = createMock(Foo).getA().andReturn(3)
     Bar bar = createMock(Bar).getB().andReturn(2)
     assertEquals(5,instance.calculate(foo,bar))
  }
}

Honestly, I'm looking for the stupid thing you did here, and I can't find it. The test passes, you didn't have to write MockFoo and MockBar classes, and all is right with the world. Until you decide to make an optimization:

class UnderTest {
 int calculate(Foo foo,Bar bar) {
    if(foo.getA() == bar.getB()) {
      return foo.getA() << 1 // a+b = a*2 = a left shifted 1 bit     
    }     
    int a = foo.getA()     
    int b = bar.getB()
     return a + b
 }
}

Ignoring the fact that this probably hurts performance instead of helping, lets rerun the test and see what we get (error message made up because I'm lazy): "Unexpected call to getA." That's right, you only told it to expect one call to getA, not two. You didn't change the result, you didn't remove an important side effect, in short, you did nothing that should break a test. Everything is still working perfectly. But it broke the test.

This is the part where I get to tell you you're an idiot. Instead of realizing that what you really want is a stub object, you decided that you must have written the test wrong so you rewrite it to expect between 1 and 2 calls to getA(). Because these mock object things can be tricky, you proceed to write all of your unit tests from then on by examining the source of the method you are testing, creating a mock for each dependency, adding a method call for each method call in the source, and basically rewriting the method in mock form. You idiot. You just wrote a test that confirms that the method was coded a particular way, not that the method behaves correctly.

Here's an example:

class OtherUnderTest {
 /**
  * @return a Map with a result entry, which is a message to the user.
  */
 Map deployNarhwals(Foo foo,Bar bar,Narwhals narwhals) {
    if( underTest.calculate(foo,bar) < 32 ) {
       narwhals.deploy()
       return [result: narwhals.getStatus()+' narwhals deployed']
    }
    return [result:'ok']
 }
}

class OtherUnderTestTest {
  void testDeployNarwhals() {
     Foo foo = createMock(Foo).getA().andReturn(3)
     Bar bar = createMock(Bar).getB().andReturn(2)
     Narwhals narwhals = createMock(Narwhals).getStatus().andReturn('Deadly')
     narwhals.deploy()
     Map result = instance.deployNarwhals(foo,bar,narwhals)
     assertEquals([result:'Deadly narwhals deployed'],result)
  }
}

You did so many things wrong here I'm going to have to make a list:

• You mocked the parameters, but didn't stub the internal dependency. See that instance of UnderTest in there? You're not testing it's calculate method, you're testing deployNarwhals, so you need to replace it with an instance that returns something like 31 so that you'll always be testing the condition (which should be a part of your API documentation) "if the temperature outside is less than 32 degrees, the narwhals will be deployed." Stupid.


• You verify that the side effect occurs, but you also couple your test to your implementation.What if I decide that the user doesn't need to know the Narwhal's status, I change the wording of the message, or make an extra call to getStatus()? Broken test. But the test shouldn't break just because your marketing department decided that 'released' was a more green term than 'deployed', or you cleaned up your code and change the number or order of non-side-effect-causing method calls.


• You check for equality on a MapDo you really care if there are extra keys in the Map? Probably not. Instead, check that all the key value pairs you expect are there.

This is how you should have written your test:

class OtherUnderTestTest {
  void testDeployNarwhals() {
     boolean deployed = false
     Narwhals narwhals = [
        getStatus: { return "Deadly" },
        deployNarwhals: {
          deployed = true
        }
     ] as Narwhals
     instance.setUnderTest([calculate:{ return 31 }] as UnderTest)
     Map result = instance.deployNarwhals(new Foo(),new Bar(),narwhals)
     assertTrue(deployed)
     assertNotNull(result.result)
  }
}

You could use a mock object framework for the Narwhals object, but you should configure it to only require the call to deployNarwhals, and not to fail when other methods are called. The above test will not fail unless the API contract is broken. I only assert that the expected side effect occurred, and that a non-null message was returned.

The problem is that you morons seem to think that more assertions == better test. That's simply not true. A good test covers as many cases as possible, but only asserts what is defined in the API contract. If you start asserting things that are not part of the API, like getA() is called, you make the test brittle. Even worse, someone could come along and see your assertion and think that getA() being called is part of the API and code accordingly! Now you've introduced a bug somewhere else in the code that your tests wont catch and could become a complete mess if it isn't caught quickly. The reality is you should assert only what you have to to catch a bug. Sometimes tests don't even need assertions, or it's not worth the effort to write them. It's enough that they show that the code under test ran without error, which is no small matter. Knowing that retrieveNarwhals(null,null,null) doesn't throw an exception can be very important.

Now, get back to work and try to stop writing brain dead tests. You thick ninny.

EDIT: Here's a good alternative: Mockito.

Kill the Singletons. (And those things you thought were Singletons too)

You guys think you're so smart. You read something about design patterns once, and now you can justify any code you write by showing the pattern it implements. Except you only remember the Singleton, and a few others. You probably remember the Factory, because you usually implement it as a Singleton. Maybe you remember the Facade and/or the Adapter pattern. You may even have some code somewhere that implements the Visitor pattern, probably where it was not at all appropriate. But Singleton is the one that everyone knows. Even those of you who never even read a poorly written article on design patterns. And you use it everywhere.

Or you think that you do. Probably you're using it as a Factory or a Locator. Or you have a class with static methods that you use to load resources or something like that. Those are singletons right? No, but you thought they were. There are even some clever and occasionally useful Singletonish things implemented using ThreadLocals, but that's for later. The point is, you've used Singletons as an excuse for what amounts to a bunch of global variables and methods. Bad programmer! No copy and paste for you!

The real problem is in how you're using them. Singletons can't (easily or at all) be proxied, decorated, replaced or mocked. You're losing all kinds of flexibility, without gaining any sort of benefit. This is your code:

public void doSomething() {
MyConfig config = MyConfig.getConfiguration();
config.doSomething();
// etc....
}

This is your code on inversion of control:

private MyConfig config;

public void doSomething() {
config.doSomething();
// etc....
}

public void setConfig(MyConfig config) {
this.config = config;
}

Of course, somewhere else you need to myClassThatDoSomething.setConfig(configInstance);, or have your container do it. This pattern is also called dependency injection, but unlike the Singleton, it's easy to get right. Don't call static lookup methods (or any lookup methods if you can avoid it) and make everything you need an object property. It's a simple change, but it gives you tons of flexibility. The only downside is that you have to learn how to use an IoC container. Fortunately, they're getting more idiot proof by the day, so with a little work, you can probably figure it out.

Now, before you go and delete every last one of your singletons, there are a few situations where IoC wont work. For IoC to work, you have to have control of the creation of the object, or at least be able to get a reference to it before it's used. A good example is logging. Logging has to be available before the container even initalizes, so you can't dependency inject logging components (easily). And sometimes, the thing you need to inject can't be managed by the container. For example, suppose you need access to the current HTTP request object, or the session object? Ignore for a second that your container can usually mange to inject special objects like these and recognize that what makes these object special is that, in a particular scope, there is only one of them at a time. By their very definition, there can only be one HTTP Request and one Session at a time. To have two requests, or two session doesn't make any sense. That means you actually have a good candidate for a singleton. A filter like this can be very helpful (some types & casts omitted for brevity):

private static ThreadLocal request = new ThreadLocal();

public static HttpRequest getRequest() {
return request.get();
}

public void doFilter(request,response,chain) {
request.set(request);
try {
 chain.doFilter(request,response);
} finally {
 request.clear();
}
}

That lets anything that's executed inside the filter call MyFilter.getRequest() to get the current HTTP request object, regardless of whether the framework was kind enough to pass it in. Even this should only be a last resort. There may be a legitimate case where someone needs to wrap, replace or mock the request, but your singleton code gets in the way. How will you unit test code that accesses the request in this way? There is no real HTTP request when you're running unit tests. Dependency injection solves a lot of problems.

Sometimes you can't avoid the Singleton, but considering the mess that you've made of things so far, maybe you should ask someone smarter than you next time you think you really need a Singleton. You probably don't. Now get back to work, and when you have some time, get the original (and best) design patterns book, read it, and stop abusing them. Design patterns are meant to describe good code, not magical pixie dust that you sprinkle on to make your crappy code suddenly good. Alas, that is another post.

Quit being lazy. lern2javascript noob

[Note: This is a blog post from a year ago, but I'm reviving it because I'm seeing developers and companies lose work because they don't have JavaScript experience. If you work on web applications, you need to learn JavaScript. In addition to this post, which targets Java developers, I've added links to good getting started resources at the end.]

Prologue: Why you need to learn JavaScript

For the foreseeable future (probably the next 5-10 years), the majority of software development will be done on web applications. Many of these will be ports of existing desktop applications or designed to replace such applications. Developing desktop-like applications on the web is going to require that Ajax thing you've been hearing about, something called DHTML, DOM, etc. That means you'll be using JavaScript.

We Java developers have been conditioned to flee at the first mention of JavaScript which has meant that it has long been the job of the 'creatives' to do the JavaScript work. That's not going to cut it anymore. While the work UX experts do is crucial to developing any application, they have different training, priorities and experiences. RIAs need solid technical developers who understand best practices, patterns, unit testing, etc. and can apply them to JavaScript.

One way Java developers try to avoid having to deal with JavaScript is through frameworks like JSF or GWT. There are certainly advantages to using a framework, but they are no substitute for being comfortable with JavaScript. Developing RIAs through a framework without knowing JavaScript is like using Hibernate without a solid understanding of SQL and relational databases. You may get by, but it wont be easy and it wont be pretty.

Hopefully you're now convinced that JavaScript is in your future. I want you to know that you don't have to be dragged into it kicking and screaming. It will be fun. You know those closure things that they're talking about putting in Java 7? JavaScript has always had them. Ever get tired of writing the same Java code over and over? JavaScript code is far shorter and less repetitive.

Differences: The Good, The Bad, and The Ugly

I'm going to focus on the immediately important differences for now. We'll pick up the more subtle ones as we go.

• JavaScript, like Java, has a C like syntax so you should feel pretty much at home. It has fewer keywords than Java, but adds a few new ones. The most important one is function, which we'll talk about more in the next chapter, but there's also var(declares a variable), with (to generally be avoided), and in (multiple uses).


• JavaScript is loosely (weak) typed. For a UI, that's a good thing, because most of the data you're working with is string data, so you don't have to declare String everywhere and if you need a string to occasionally be a number, it happens automatically. Every object has a boolean value of true except 0,the empty string and false. An undefined or null variable also evaluates to false, so you can check to see if an object has the method/property that you want like so:
  

  if(!foo.bar) {
   throw "foo must have bar";
   // you can throw anything to raise an error
  }
  

  Of course, you can do whatever you like if the object you were passed doesn't have a particular method.


• There are only Numbers in JavaScript. There is no distinction between int,float, double and long. Math.round, Math.floor and Math.ceil are there if you need them. The maximum value is 1.7976931348623157e+308 so don't worry too much about overflowing. You shouldn't be doing any heavy computation on the client anyways. If you try to do arithmetic with something that isn't a number, the result will be NaN (not a number). NaN and anything is NaN. That includes undefined variables:

  var foo = 1;
  foo + bar; // == NaN, since bar is undefined

• There is no char type. You can use either single or double quotes to delimit a string. 'f' is always the string "f". charCodeAt(index) on strings will give you the character code as a number.
  


• In addition to functions, objects and arrays are first class citizens (technically functions and arrays are also objects). You can define array literals using the [] syntax: var myArray = [1,2,3];. For objects you use {} and provide a list of name:value pairs: var myObj = { foo: "bar", baz: [1,2,3] }. Both array and object literals can span multiple lines. It's generally good form to break lines after a comma (if you must break lines):
  

  var foo = {
   bar: "baz", qux: 123,
   quxx: { a: 1, b: 2, c: 3}
  };

• Perhaps the most important JavaScript data type is the function. We wont get into it now, but you need to know that you can treat functions like any other variable. e.g.,
  

  var foo = function(a,b) {
   return a + b;
  };
  
  foo(1,2); // == 3

• When a function is called as a property of an object, it gets access to this. e.g.,

  var foo = new Object();
  foo.bar = function(a) {
   return a + this.b;
  };
  foo.b = 2;
  foo.bar(1); // == 3
  foo.bar(2); // == 4



• Note that while you can get put a reference to foo's bar function in a variable, it will no longer have access to foo via this.

  var bar = foo.bar;
  bar(2); // == NaN (not a number)

  Since this.b is undefined, 2 + undefined is NaN. You might be wondering why this.bar doesn't result in an error. Well, it's because this is always defined. Since JavaScript executes in the context of the browser window, the default this is the window. This is where all global variables live. Incidentally, you can reference the window explicitly with the window object.
  


• There is a difference in scoping in JavaScript as well. You're used to having block local variables. Well, in JavaScript variables are either global or function local. Blocks share their enclosing scope, so
  

  var foo;
  if(true) {
   foo = 1;
  }

  is the same as

  if(true) {
   var foo = 1;
  }

  foo will still be visible after the else block. If you fail to define a var inside a function, a global variable is created (or if it exists it is overwritten). e.g.,

  
  function() {
   foo = 1; // sets window.foo = 1
  }

  So, think carefully about scope when you declare and use variables.
  


• JavaScript is interpreted, which means that you don't even know 100% if a line of your script is valid until it actually runs. That makes unit testing crucial. Fortunately tools like JUnit, Javadoc, etc. all have JavaScript equivalents that will seem very familiar. There are also a host of development tools including Eclipse plugins, Aptana, IntelliJ support, etc. to help you along.
  


• Lastly, you should know that JavaScript inheritance is prototypal. It is fully possible to achieve class based inheritance, which we will do with the help of a library called Prototype, but the prototypal nature of JavaScript gives us some interesting options which we will explore later.

Your Environment

We're Java developers, so we know the power of a good IDE. Eclipse, NetBeans and IntelliJ all have decent JavaScript support. There are a variety of plug-ins for Eclipse (I use JSEclipse), but I'm going to tell you right now that none of them will give you the code completion that you're used to. It's simply not possible with a dynamic, weakly typed language. You'll have to learn APIs the old fashioned way, by reading the docs and using them.

Fortunately, JavaScript gives you an amazing debugging and exploratory tool that you have never had and likely will never have with Java. Its name is Firebug. Go ahead and install it. Done? You need to restart Firefox. OK. Good. Now see in the bottom right corner? Click it. This is Firebug. It does a lot of things, but for now we're just going to mess around with the 'command line'. Do the following:

1. Click the in the bottom right corner of Firebug.
2. Paste this into the command line and press Ctrl+Enter or click 'Run':
   

   $('demoSteps').childElements().each(function(item,i) {
    item.insert("("+i+")");
   });
   

OK, it's not the most impressive example, but you did just execute code without having to reload the page or anything. Here we're making use of a library called Prototype. Bookmark the API immediately. What the above code does is call a function named '$' (yes, that's a valid variable name in JavaScript) with the argument 'demoSteps'. When $ is given a string, it looks for the element in the HTML with id="demoSteps". We get the child elements and iterate over them, calling the anonymous function we defined there on each element, along with it's index. We then append the index in parentheses to the body of each element.

The equivalent JavaScript without Prototype is a lot longer. You could start learning JavaScript without any libraries, but then you'd quickly get caught up in fixing bugs and writing the same code over an over. Fixing bugs doesn't give you a good appreciation for a language, nor does clunky repetitive code. In any serious web project you will use Prototype or a similar library, so it doesn't hurt to know it. After you're comfortable, we will delve deeper into the JavaScript language and you'll learn what Prototype hides from you.

Before we go, drag this onto your bookmarks toolbar: Insert Prototype. Now you can go to any web page, click that bookmarklet, pop open the console and start using Prototype to play. For homework, explore the Prototype API, especially the utility functions and the Enumerable methods. Try to write as many snippets using the API as you can.

Resources

• http://javascript.crockford.com/ Read these essays. They're all pretty short, but they are essential. Also, get a copy of Crockford's book.
  
• http://jquery.com/ jQuery is very popular. It has tons of plug-ins, with new ones popping up everyday. You will need it.
  

One liners for readability

(For clarity, when I say one liner, I mean single statement. For various reasons, including readability, it may be desirable to split statements across multiple lines)

Which is easier to read? Is it this multi-statement snippet:

def params = request.params
def config = whatever.getMyConfig()
def request = MyLongTypeNameRequestTransformer.toMyRequest(params, config)
def result = myLongNamedServiceThatDoesSomethingCool.execute(request)

or this single statement:

def result = myLongNamedServiceThatDoesSomethingCool.execute(
  MyLongTypeNameRequestTransformer.toMyRequest(
      request.params, whatever.getMyConfig ) )
// line breaks added to protect the page-width. 80 columns

Now your answer to that question probably depends on how you interpreted 'easier to read'. Most of you probably thought that I meant "Which format makes it easier to understand what this snippet does?" Typically people are going to say that the first one is more clear in that respect. However, I want to consider a different question, "Which format makes it easier to understand/follow/debug/grok/refactor the overall codebase?"

I would argue that the second form is better in that respect, and that overall manageability of a codebase is generally more important than a small readability improvement for a section of code. I see one liners as an implied abstraction. It hints to the reader that, despite the complexity involved, we are really only interested in one result (either a return value or a side effect), so they can mentally collapse all that code into "get X" or "do Y". It says, "Skim over me, the details are not important."

There are two alternatives to one liners. The first is to use a bunch of local variables. While this can certainly make an algorithm more readable, each one adds one more thing that I have to keep track of when I'm reading your code. I have to remember that config came from whatever.getMyConfig(), and I have to consider that it may be used later in the method. If config is inlined, I don't even have to mentally register its existence unless I'm trying to parse the one liner.

The second alternative is to encapsulate the snippet as a function. This gets rid of the mental scope pollution from stray variables, but it introduces two new problems. Firstly, if I want to know what the function does, I have to go to another place in the file (or another file), which breaks the continuity. Often times one liners also need several of the variables in the current scope, so you end up with a lot of parameters, which adds even more clutter. Secondly, you end up poluting the scope of the class or script with yet another function that is only used in one place. You've just moved the clutter up a level.

Now, there are certainly times and places where you don't want to inline everything all willy nilly. If an expression appear multiple times in a function (e.g., whatever.getConfig()), don't repeat yourself, use a local variable. If you can extract a function that can be used in more than one place, go right ahead. If you have code that is several indentation levels deep, first consider a redesign and/or refactoring that simplifies, but if that doesn't work, extract a function to make it more readable. However, declaring variables and functions should be things that you do out of a clear need, not just because you think you'll need it, or because your CS professor always told you to (CS professors are concerned with algorithms and minutia, not codebase managability). Remember, premature optimization is the devil.

Most modern languages offer syntax that can assist in creating readable one-liners. If your language has map/has and/or list literals, you should avoid building those constructs procedurally. e.g., in JavaScript:

var array = new Array();
array[0] = 'foo';
array.push('bar');
myMethod(array);

is lame. Write that as

myMethod(['foo','bar']);

Groovy's map literal:

myMethod([foo:'bar',baz:'quxx']);

Even Java can be slightly improved thanks to anonymous inner classes and initializer blocks:

myMethod(new HashMap() {
{
 put("foo","bar");
 put("baz","qux");
}
});

Hopefully you have the idea by now.

Java Fun Continued - Groovy FTW

Here's the equivalent Groovy for my previous Java abomination that prints the Java wrapper methods for me:

new File("src/main/java/Foo.java").text.
    replaceAll(/(?sm)\s*public\s+(\S+)\s+(\S+)\((.*?)\)\s*\{/) { 
       s,ret,name,params ->
  print """
    public ${ret} ${name}(${params}) {
        """
  if("void" != ret) {
    print "return "
  }
  print "foo.${name}("
  // -1 hack avoids index out of bounds when params is ''
  print params.trim().split(/\s*,\s*/).collect { 
    it.split(/\s+/)[-1] 
  }.join(',')
  print """);
    }
"""
}

I could change the prints to concatenation and reformat the whole thing as a single line, so it only counts as one statement. Technically I cheated a little because this version doesn't look up the methods by reflection, but it doesn't make a difference in the result, and wouldn't significantly shorten the Java code. Definitely more readable than the Java. The JavaScript is a little messier since you don't have multi-line string literals, GStrings, and closures are function(it){ return it.foo; } instead of { it.foo }.

Java Fun: When all you have is a hammer...

I ought to be ashamed, but I was bored and lazy, so I thought I'd test my somewhat dormant Java skills. Can you tell me (without running it) what this code does?

  Method[] methods = Foo.class.getMethods();
  String source = FileUtils.readFully(new FileReader(
    "src/main/java/"
      + Foo.class.getCanonicalName().replaceAll(
        "\\.", "/") + ".java"));
  PrintStream out = System.out;
  for (Method method : methods) {
   Matcher matcher = Pattern.compile(
     "public (\\S+?) " + method.getName() + "\\((.*?)\\)",
     Pattern.DOTALL | Pattern.MULTILINE).matcher(source);
   if (matcher.find()) {
    String ret = matcher.group(1);
    String params = matcher.group(2);
    out.printf(" public %s %s(", ret, method.getName());
    out.print(params);
    out.print(") {\n  ");
    if (!"void".equals(ret)) {
     out.print("return ");
    }
    out.print("foo.");
    out.print(method.getName());
    out.print('(');
    if (!StringUtils.isEmpty(params)) {
     out.print(StringUtils.join(CollectionUtils.collect(
       Arrays.asList(params.split(",\\s*")),
       new Transformer() {
        public Object transform(Object input) {
         return ((String) input).split(" ")[1];
        }
       }), ','));
    }
    out.println(");\n }\n");
   }
  }

I'll post the equivalent Groovy (and maybe JavaScript) later. I imagine I can do it in a single statement function. I don't miss Java very much.

I'm a nerd. Or do I mean geek?... Hi, my name is Noah.

Aaaand it's Thanksgiving. I'm up late because I just got my slice and I can't stop tinkering.

I think my master's project is dead meat. Yes, JSF component creation is woefully painful and slow. Yes, a framework helps tremendously. Yes, my framework was good, and let you choose your Ajax implementation, and so on.

The problem with all that is that the JSF Ajax implementations suck. And the learning curve for JSF (much less components) sucks. It's just too quirky. Hopefully JSF 2.0 will make component creation easy, enable RESTful services, and will make it easier for newbies and old hands to just get things done. I'd like to hope all of that, but the only positive things I tend to hear about 2.0 are from Ed Burns, who seems like a very nice guy, but whose rhetoric reeks of corporate "gotta toe the line/I think my company is the best ever, is not a dinosaur who is slowly and inconsistently embracing open source, and is a bit too bureaucratic to be able to save Java." JavaScript is it, ya know.

Which brings us to my next topic. Kevin at work is the new Grails evangelist. I have to admit, Groovy is a cool language. If not for the fact that JavaScript is the NBL, I think Groovy would be the weapon of choice. Optional static types, intuitive C like syntax, closures everywhere, functional programming, etc. It's a readable LISP, IMHO. Since we'll probably be using Ext for my next project, (in wonderful freezing cold Pittsburgh, no less...) I thought that I'd take the opportunity to get familiar with it by working up a sample project. It's going quite well, so I must remember to get a few entries out of it (yes the separate tech blog is pretty much dead).

Groovy is a great complement to JavaScript/Ajax programming primarily because the thought processes are the same. There are some more syntactic niceties in Groovy, and there is sadly no Prototype for Groovy, but switching is completely effortless. And if I need to, I can always turn the static types back on and write some Java code. If you are a JEE developer and haven't looked at Grails yet, you need to.

More bulletins as events warrant. Cheers.