Javascript Follies

This other day I’m coding and stuff – in javascript! I asked a co-worker who is a REAL javascript programmer for a quick review. Here’s how that went:

On Nov 2, 2012, at 12:40 PM, Jim S wrote:

I suppose you could use the ======= operator, just make sure you don’t use the ================ operator.  That checks to see if two values are equal, are of the same type, are at the same location in memory, were conceived of by the same developer, exist in the same time stream, and some other criteria I forget.  It’s a bit overkill, if you ask me.

     On Nov 2, 2012, at 12:20 PM, Val wrote:

     […] It just felt like there could be some neat js shortcut (something like a ======= operator?) 

Go Tesla!

Even though my views would generally fall in the moderate-conservative bucket, my standards for the idea of the government picking winners and losers is very low ever since the Bush administration’s era of war spending that benefited a small number of their friendly companies like Halliburton. By investing in electric cars instead of wars, there might be something in it for the rest of us this time.

There are many benefits to driving electric cars – more choices of energy sources, considerably less maintenance, longer engine life. The only slight hiccup is that electric car technology is not mainstream yet so it’s expensive and lacking in the usual conveniences of a mainstream technology. If we give it a hand though, we’re looking at:

  • More energy choices. When you have a gasoline car, you are at the mercy of your gas pump overlords, sometimes leading to hilarious attempts to ‘stick it’ to the man.Your gas-powered car doesn’t give you a whole lot of leverage against big oil so you just have to suck it up and shell out. An electric car on the other hand can run on electricity regardless of its origin – from renewables, coal, hydro, natural gas, even gasoline. You can even generate your own.
  • Low cost of maintenance.  An electric engine’s maintenance schedule is – eyeball it every 10,000 miles or so to make sure it’s still there. My 2006 Prius has 82,000 miles on it and, while its gas engine had all of its usual scheduled maintenance (oil changes, tune-ups, etc), its electric engine so far had exactly ZERO work done – and no issues whatsoever. Or, to put it another way – how much maintenance do you need to do on your washing machine?
  • Gasoline car transmission is clunky and expensive. A gasoline engine can only deliver reasonable torque between about 1000-4000 RPM. This means that regardless of your speed, you have to keep the engine in that narrow range. To achieve that, you need a complex transmission system that often turns into an expensive maintenance burden. Electric cars have no such issues – they can deliver consistent torque between 0-14000 RPM without a hitch, making it easy to build a simple, no-fuss transmission that’s far less likely to break down on you.

Mitt Romney takes every opportunity to bash Obama for supporting this awesome technology. Somehow Obama seems completely oblivious to these advantages and consistently fails to produce a coherent answer. Mr. Obama, stop being a dufus and get your sh!t together – this stuff is too good to let slide.

GO TESLA!

Mitt Romney the Engineer

To point out the drawbacks of using wind energy, Mitt Romney couldn’t help but notice that ‘You can’t drive a car with a windmill on it.’ That’s a very true, common-sense observation, and you can see his Harvard education put to good use there. The suggestion here is that, if here were an engineer, that’s how he would have designed an electric car powered by windmill-generated electricity.

So how would Mitt Romney the Engineer have designed the gasoline-powered car? He would presumably attach an oil drill to the car. Driving far from oil wells would be awkward because you’d need very long hoses to keep the car connected to the oil well. The rear seat would be all taken up by the mini-refinery you’d have to carry with you in order to convert crude from the well into gas. And at the end of each trip you’d be stuck with a lot of oil by-products.

Other things you can’t drive a car with: refrigerators, king-size beds, fully-assembled pinball machines, adult rhinos, space shuttles, Stonehenge blocks, other cars, Airbus 380’s, Airbus 330’s, Airbus 320’s, Airbus 319’s, and certain oversized kitchen sinks.

Can you think of other large objects you can’t have on top of your car while you drive?

Multithreaded elements of style in javascript

This other day I was just coding and stuff when it suddenly struck me – multithreaded programming! My general ideas about it always revolved around things like scalability, synchronization, and those philosophers who refuse to eat with their hands. What I completely missed was the human side of it – the way it helps developers express their thoughts in code with so much ease and elegance even when they’re not pursuing head-spinning performance. In fact, lots of multithreaded code out there has nothing to do with scaling up and is all about breaking down code into logical sections.

Core Javascript Multithreading

You’re probably thinking I’m way off here because everyone knows javascript is completely single-threaded. That’s right – those DOM events, AJAX, timed events – all executed by the same thread! (see John Resig’s article). The general idea is that javascript executes short-burst pieces of code and can afford to run all events in the same thread. By doing that, it avoids tricky synchronization issues and greatly simplifies the way we work with it.

AJAX and DOM events in javascript are a great example of using multithreaded paradigms (simulated multithreading that is) to simplify coding. The alternative would have been to write your own loop that does something like:

while(true){
runDOMEvents();
runScheduledEvents();
runAJAXRequests();
runEverythingElse();
}

Instead, the javascript runtime already does that for you, so all you need to do is supply the callbacks. In addition, it also runs each event with its appropriate call stack so the multithreaded illusion looks very real in firebug.

Dojo Promises

Building on the existing body of knowledge on futures and promises, Dojo defines the concept of a Deferred.You may have also seen this exact same concept in Python, or a very similar one in Java’s java.util.concurrent.Futures. Java Futures are literally running in a separate thread so getting the future value can afford to block. In Javascript otoh, no blocking is possible since there’s only one thread executing the whole shebang, so the alternative is to provide a callback to execute when the future value becomes available. This means the promised value always gets processed in a different call stack even though it’s all in the same physical thread. However, that’s not a big issue in Javascript since the concept of an execution context is extremely flexible thanks to functions like apply() and call() (or wrappers like dojo.hitch()).

You may have noticed that Java Futures already return an object of the expected type, so you can use the Future as a proxy for the concrete value. For example, we could invoke the process() method below using a String

process("abc");

or we can just as well give it a future String value:

Future<String> future = ...
process(future.get()); // blocks until String is ready

The interface therefore remains uniform whether we use a Future or a concrete value. Since this is not the case in Dojo, we have a solid workaround for it in the form of dojo.when(), which does the extra work of normalizing promises and concrete values for us.

Dojo.declare Vs Javascriptzilla

This other day I’m like coding and stuff when I suddenly gained a whole new level of appreciation for what dojo.declare does for humanity and especially javascript developers. It’s hard to describe… it’s just … wow!

Quick background. Javascript was apparently supposed to come off as a simplified version of Java. As part of that simplification, rather than use classes for defining object blueprints, it uses object prototypes. You know the prototype pattern, right? It’s when you create one model object and clone it each time you want to create a new object of that type (analogous to creating a class and instantiating the class each time you want a new object). That gets you rid of having to create classes at all so you only deal with objects. However, by itself that’s not sufficient – you still need a constructor, which is that piece of logic that initializes the object when you create it. In addition, you need inheritance, meaning if a property or method is not attached to this object, check its superclass, and then the superclass of that… all the way up.

We can certainly define the constructor as a function, but where should we keep it so that it remains connected to the prototype object? In what’s no doubt one of the biggest hacks of the century, javascript decided to have that constructor function masquerade as the class (a concept it apparently tried to avoid all along), and attach the prototype object to that function under the prototype property. Strangely enough, the prototype object itself has a constructor property that points back to the function. So now you can totally invoke the constructor function as a regular function (and expect the unexpected if you do that), but what you really want is invoke it using the new operator, which is the psychedelic way to tell the machine to clone the attached prototype object and initialize it by running the constructor function on it!

Sound confusing? Adding inheritance to the mix makes it about ten times worse. Inheritance needs a few things like:

  • Creating a class instance should invoke the superclass constructor first (all the way up)
  • Invoking an inherited method should work as expected
  • Changing a static value in a superclass should be reflected in all the subclasses that don’t override it

Javascript immediately fails the first one because it doesn’t chain constructors. It can be done, but you have to do it yourself. The last two have been a source of some confusion but generally can be resolved by using javascript’s prototypal inheritance. The confusion arises from simplistic implementations that mixed in properties of all super-prototypes into a single prototype object, thus creating a denormalized object prototype; the problem with such implementations is that they fail the last point – changing a static value in a super-prototype does not get automatically reflected onto the sub-prototypes. This last issue is really more of a documentation problem since it’s resolved by the correct usage of prototypal inheritance.

Dojo.declare solves the aforementioned problems without much fuss and does a whole lot more. While javascript’s native prototypal inheritance solves the problem of single inheritance (except for the constructor part), Dojo takes that whole concept further to implement multiple inheritance. The classic problem with multiple inheritance revolves around collisions – when the same method is present in both left and right superclass (as in the Diamond problem). Dojo utilizes a relatively recent concept known as C3 linearization (aka C3 Method Resolution Order) to correctly simulate multiple inheritance. It has to simulate it because each object can only have a single super-prototype, so that’s done through some creative use of mixins. Of course dojo users don’t need to worry about it because it JustWorks(TM).

The result of calling dojo.declare is very much the same as that of manually creating a function that masquerades as your constructor/class, assigning it a prototype object, establishing the prototype and constructor chain, etc. Dojo.declare returns a completely normal-looking function object, which we can call using new to create new instances. Even small details are taken care of, such as if it’s a named function, dojo adds it to the global scope for us, and if called without new disaster is averted. As if that’s not enough, the mixin mechanism allows taking bare-bones interfaces and mixing in existing partial implementations into them – all using a single call to dojo.declare!

A Total Communication Breakdown

This other day I was just minding my own business, you know, coding and stuff, when I suddenly felt the full wrath of a dissatisfied user. As it turned out, my last year’s project completely missed the mark for this user and he just casually dropped by to give me a piece of his mind. I’m guessing it’s a matter of time before he’s back again.

I’m not exactly troubled by the fact that there are dissatisfied users. It’s hard to build something that pleases everyone and I don’t think it’s realistic to work under such constraints. What really gets to me though is the fact that I completely failed to realize that there were such users while I was running the project. In fact, had I realized that, I would have definitely done something to make up for it – if nothing else, at least a pre-emptive PR campaign.

No, it’s not that I was slacking off. Even though I’m a developer, I typically also run a part-time product management shop out of my cubicle to verify and rectify the original requirements (trust me, I discover a lot of problems that way). In addition, by keeping people involved throughout the project, I can usually claim some pretty satisfied users.

But it still bugs the crap out of me that I didn’t detect these other users who expected something else.

Playing this back in my head, a few things come to mind. The satisfied users were:

  1. Easy to communicate with, which led to in-depth conversations that helped me understand what they want
  2. Proactive with feedback and eager to try out new features right out of the oven
  3. Equally obsessive about getting this done right

As for the dissatisfied users:

  1. Communication problems. For example, I had distributed beta builds in the hopes of getting some good criticism but didn’t get any. Case in point, the same person who came by to yell at me was given a copy of the said beta build. However, he somehow decided to hold his silence until it was too late. This turned out to be a widespread issue among dissatisfied users.
  2. Lack of mental connection. For example, I’ve had people express scepticism about Subversions’s ability to automatically merge concurrent changes. Since Subversion has been doing that really well for years (and before that we had CVS and others), I had to disregard such comments and take the person with a big grain of salt. Not to say that these people actually offered any constructive feedback on the beta build – the discussion never gained any depth. There were a number of such incidents and my course of action each time was to stick with the information from people I found reliable.

How to do better next time? First, you could say the dissatisfied users had their chance and blew it, so they fully deserved this. Well, yes, but I still can’t stand the idea of having dissatisfied users period so I’ll need something better than that.

Looking back at it, it’s a puzzle. I’m building something. I have to figure out what it is, sometimes while I’m building it. There are hidden clues everywhere, reliable and unreliable informants, some of whom withhold crucial information for irrational reasons (too shy, embarrassed, high…). The plot thickens with every conversation, every demo, every new realization. Put it together correctly and you’ll have a project that’s deliverable within specified constraints, and will have a reasonable number of satisfied users. Get it wrong and you might wind up doing it all over again in a couple of years.

When dealing with inarticulate users, remember to ask very specific questions. For example, asking “do you need a vehicle with off-road capabilities?” might give you some of the same blank stares and perhaps amusing answers like “I don’t think it’s possible for cars to operate off the asphalt”. However, ask “do you want acceleration right and brake left?” and you’ll be more successful at jogging the underpowered neurons on the other side, and maybe even have a decent conversation.

I think I’m gonna try that next time…

A Tough Call

This other day I’m like coding and stuff when a co-worker walks by and asks to have a word. It turns out he needed some advice after he got himself in a pickle by checking in slightly more code than was supposed to. Something about refactoring a bunch of code instead of just fixing the dozen or so bugs he was assigned, which resulted in some frowns.

At this point you’re probably wondering why he came to me, given that I have nothing to do with his project. To that I would say I sometimes play the role of the bartender among developers with the exception that I don’t serve drinks and expect no tips. Hopefully that make sense.

So it turns out this guy set out to fix those bugs when he realized he’s dealing with a bunch of spaghetti with a full can of past-expiration-date bolognese sauce ton top. Being a fearless engineer, he took matters in his own hands and decided to refactor the offending code. But there’s trouble in paradise – the refactorings didn’t go too well with the management.

As we talk about this, I can’t help remembering so many past instances when we had some prototypical loose cannon make frivolous changes all over the place and breaking a bunch of stuff. The worst part was when I got stuck cleaning up after them. But there were also times when that was the right thing to do and it brought about a lot of good. The question is – which is it this time?

I put on my metaphorical referee uniform and tried to reason through this. Refactoring can definitely be risky and its benefit must be weighed against the risk. However, after deliberating for about 10 minutes I called the move – legal. The deciding factors were:

  1. This engineer stands behind his work. He expressed the willingness to “work all night” to rectify any issues that may arise as a result of this.
  2. He knows his s*%t. He made a convincing case why that old code was no good (monolithic methods, incorrect abstractions, etc), and why his code is likely to be more maintainable.
  3. He has a history of good coding practices.

In addition I decided to give his superiors yellow cards for taking the short-sighted approach of “if it aint broke don’t fix it” because they don’t know enough about the code in question (or code in general IMO) to make that call. Surely there are cases when it’s better not to fool around with messy code when it’s fully contained and debugged, but this was not one of them.

As a result of my decision, nothing happened. This was in part because we didn’t tell anyone so in the end it was just two dudes talking about some work stuff. For what it’s worth, I remain very pleased with my decision.

The Agile Man-Month, Part III

Project Scope

Sometimes the management tends to see a project as a monolithic unit of work. The thing is either complete or it’s not. While this is often true for buildings and cars, most software can be easily broken down into pieces and prioritized in various ways. You sometimes achieve a big impact with just a small set of carefully chosen features. Other times you need more than that, but it’s very rare that you need all the features in order to have a usable product.

It turns out during man-month tennis matches between developers and the management this is rarely considered in its true glory. It does get some attention, of course – when the estimate comes out a bit more than desirable and something needs to get removed from the list. Once that’s done, however, the warm and fuzzy feeling of being somewhat in control can finally settle in.

But you’re too agile to get sucked into that and surely remember to expect a few surprises down the road.

A Pretty Specific Generics Problem

So today I’m like coding and stuff (but you already knew that) when I ran into this conundrum with generics. Can you see why this doesn’t compile? Assume Car is the superclass of Ford and Toyota.

List<? extends Car> list = new ArrayList<Car>();
list.add(new Ford());
...
Compile error: cannot find symbol method add(Ford)

What??? Regroup. I have a List of anything that extends Car and I can’t put a Ford in it?  To see why this is actually correct, let’s go back to the basics. Consider:

Car myCar = new Ford();

Here we have a Car reference to a specific Car implementation, namely Ford. We can use this Ford object with the Car reference according to Car’s exposed interface. However, we can’t use that reference to access Ford-specific functionality. Now take another look at the list reference:

List<? extends Car> list = ...;

What this means is that list is a reference to a List of something that extends Car (or is Car), but we don’t really know what that something is. In other words, it could be a reference to a List<Toyota>, List<Ford>, or List<Car>. The only functionality available through the List<? extends Car> reference is the lowest common denominator for all such List objects – basically little more than iterating. Hence when we tried to do

list.add(new Ford());

this had to blow up – the target list could just as well have been a List<Toyota>, which would have been really bad.

—–

Ok, two questions now. First, how do I declare a List that can store any type of Car? Second, how is this unknown type genericising even useful?

The first one is really easy. All you have to do is declare it as a List of Cars:

List<Car> list = new ArrayList<Car>();

Now the type is known – it’s Car, which includes all its subtypes like Toyota and Ford, and you can add a Ford instance to the list – that works!

The second question is a bit harder to answer because we first have to realize the limitations of the genericised List. Specifically, the following will not compile:

List<Car> list = new ArrayList<Ford>();
...
Compile error:
incompatible types found : java.util.ArrayList<Main.Ford> required: java.util.List<Main.Car>

Even though Car has the inheritance relationship with Ford and Toyota, List<Car> does not share that same relationship with List<Ford> and List<Toyota>. In other words, List<Car> is not a superclass of List<Ford> and List<Toyota> (d-uh) so it cannot reference them. If you want a generic reference to all of these lists, such as passing any of these lists to a method, you have to resort to the even more generic List<? extends Car> variant:

public void doStuffWithListOfSomeCars(List<? extends Car> theList) // accepts List<Car>, List<Toyota> and List<Ford> 

In other words, the “? extends …” construct introduces a new form of polymorphism that’s really specific to generics. A little funky but still much better than List<Object>.


									

A Memory Leak where you least expect it

The other day I got some heap dumps that made me rub my eyes in disbelief. There’s this Map that stores a few thousand small strings (about 30 characters each, never more than 50), which in theory should never take up more than a couple of megs of RAM. However, according to MAT (Memory Analysis Tool – you know, the Eclipse plugin), this Map was taking up about 2.5GB instead!

So I went through a bunch of those Strings thinking I’d find a few that were way bigger than 50 characters and call mystery solved. However, they all seemed correct! So what’s taking up the extra 2.49GB?

Here’s a neat little snippet that demonstrates the problem:

 List<String> list = new ArrayList();
  for(int i = 0; i < Integer.MAX_VALUE; ++i)
  {
      String substr = ONE_MB_STRING.toString().substring(0,1); // get first character
      list.add(substr); // keep track of the tiny substring
      System.out.println(i); // how far will we get before it blows up?
  }

We take in a 1MB StringBuilder, convert it to a String, and grab just the first character. The one-character String is stored in the list. This simulates the conditions surrounding the huge memory leak.

So how many iterations before we run out of a 128MB heap?

Answer:

It turns out by the end of the 59th iteration, my test blows up with a big fat OOM. All the memory is eaten up by the list even though all it contains is 59 one-character String objects, provably. What???

It’s actually an interesting Java optimization that just didn’t work too well for us. Java takes advantage of String’s immutability to avoid copying bytes around when it builds substrings. The String class has an inner char[] buffer, as you might expect, along with two integers: offset and count. Needless to say, when you call substring(), you don’t get a String with a brand new buffer but rather a new String that points to the internal buffer of the source String, with only offset and count adjusted to point to the location of the substring. The behavior of the resulting String is exactly as expected, except that it drags around the original buffer with it (technically this is what you might call the Flyweight pattern). In our case, each 1-character substring  was actually pointing to the 1 MB buffer of the original String. Give it a few dozen of those and your heap becomes crammed indeed.

Solution:

The solution is really simple – construct a new String based on the substring. While substring() and split() use the flyweight pattern, the String constructor creates a new buffer based on the toString() value of the original:

list.add(new String(substr)); // keep track of the tiny substring

Update:

I was just taking a nice bubble bath while reading some Java source code when I came across this String constructor:

public String(String original) {
    int size = original.count;
    char[] originalValue = original.value;
    char[] v;
      if (originalValue.length > size) {
         // The array representing the String is bigger than the new
         // String itself.  Perhaps this constructor is being called
         // in order to trim the baggage, so make a copy of the array.
            int off = original.offset;
            v = Arrays.copyOfRange(originalValue, off, off+size);
     } else {
         // The array representing the String is the same
         // size as the String, so no point in making a copy.
        v = originalValue;
     }
    this.offset = 0;
    this.count = size;
    this.value = v;
    }

Check out those comments – looks like someone ran into this problem before…