Mockery Blog

First off, keep in mind that I’ve never used Groovy, just skimmed a couple of language references, but people I know have used it and like it. In case anyone is not familiar, Groovy is a dynamic language implemented on the JavaVM. It’s commonly used for web development, especially with the Grails framework.

Anyway, having established that I don’t know much about Groovy, I do know that it has a feature that I really wish we had in JavaScript. It’s called the Safe Navigation Operator, and it’s represented as ?. in the code. Quoting the Groovy reference:

The Safe Navigation operator is used to avoid a NullPointerException. Typically when you have a reference to an object you might need to verify that it is not null before accessing methods or properties of the object. To avoid this, the safe navigation operator will simply return null instead of throwing an exception[.]

If it’s not clear from that, here’s a real-world example. Let’s say you have a customer object. That object has an optional attribute address, which is itself an object, and in turn has city, state, and postal code attributes, which are strings. In JavaScript, you could access the State like this:

var state = customer.state.address;

No problem, but what if the customer object doesn’t have an address? That line will throw an exception. We can work around it like this:

var customerState= customer.state ? customer.state.address : null;

But if we get deeply nested objects, the syntax gets really muddy. Using Groovy’s Safe Navigation Operator, we could just do this:

var customerState= customer?.state?.address;

Now, if customer is defined, and state is defined, and address is defined, then customerState has the customer’s state. Otherwise, it contains null. Either way, it never throws an exception, even if none of those objects are defined.

Cases where this could come in handy are data retrieved from deep XML hierarchies, complex nested JSON objects returned by web services, and unpredictable user-entered data.  I’m sure that if JavaScript supported a similar operator I would use it all the time. Kudos to Groovy’s designer, Guillaume Laforge.

I play guitar left-handed, which is kind of a pain in the ass when it comes down to it. I can’t play anyone else’s guitar and they can’t play mine. When I go to the guitar store, there are usually only a couple of lefties and they’re usually pretty unspectacular.

Most times when I mention this to people they ask me why I didn’t just learn to play right-handed. After all, it would be my left hand that would be doing the “hard” part. And, in fact, I tried it when I was first starting. Thing was, it just felt wrong. I didn’t enjoy it until I flipped the guitar over and played it the way it felt right. Years later, I’m still happily shredding.

The suggestion to “just play right-handed” is well-meaning but wrong. There is a reason that right-handed people (almost) universally play guitar right-handed. There is a real connection between plucking and strumming and the dominant hand. It just works that way for most people. Fighting to overcome that natural tendency is not fun, and when playing music is not fun people do not learn to play. I think you’d be doing a disservice to an aspiring guitarist if you told him or her to flip the guitar over and play it the other way because that’s just the way it’s done.

Software, I think, is a lot like that. You can force people to try to accommodate your interface. If your app is important enough to them, they may even fight their way through the pain and continue to use it. But if you continually tell people to do things in a way that is uncomfortable and unintuitive for them, people who are just getting started are going to bail out and give up on you because it’s not worth the pain to them. If I ever get tempted to cut a corner UI-wise, I’m going to try to remember how it felt to try to play that right-handed guitar 15-odd years ago when I was getting started.

I probably shouldn’t admit this, but I’m not any good at shell scripting. It’s one of a few things I’m not good at that mean I’m not a “real” programmer (the others being regular expressions and SQL queries…good thing I’m into UI). But I have hope that I will get good at shell scripting.

So I’m pretty psyched that StumbleUpon came through for me with a couple of useful links related to shell scripting. Here they are. Enjoy!

http://www.techinterviews.com/basic-shell-scripting-questions

http://blog.emson.co.uk/2009/06/18-useful-bash-scripts-for-web-developers/

I finally got an opportunity yesterday to do something I’ve always wanted to do: use bitwise arithmetic in JavaScript. Why would I want to do that? Mostly because it’s interesting and different, but also because bit-twiddling is something that programmers should just know how to do, whether or not we ever actually have to anymore.

The problem with bitwise arithmetic in JavaScript (and, for that matter, in most other languages) is that it’s almost always the wrong solution to the problem. It’s not 1972 anymore, and we can spare enough RAM to give each boolean value its own variable. Sure, it’s a tiny bit less efficient, but the efficiency cost is more than offset by the increased readability and maintainability of code with meaningful variable names.

So in all but the most performance-critical examples, using bitwise arithmetic smacks of premature optimization and over-cleverness. So imagine my delight when I was given the task of storing at least 2, possibly more, flags in a single database field. We weren’t going to get a second field under any circumstances. Arguments raged about whether to use comma-delimited strings, JSON-encoded objects, pre-defined constants, or something else.

What I arrived at was, I believe, the correct solution given the problem. I’m using an integer to store the booleans, and each bit position in the int corresponds with a single flag. Checking the flags is where the fun comes in. Folks with heavy CS backgrounds are not going to be impressed, but those of us who have honed our skills in interpreted languages will get a kick out of this:

// Check whether the second bit is set in the passed integer
function checkFlag(bitmap){
    var mask = 2; // since 2 in binary is 00000010, this will check the second bit.
    return bitmap & mask
}

The bitwise AND operator (&) takes the bitmap and the mask (which is 00000010 in binary) and returns a new number where bits are only set to 1 if they are 1 in both the bitmap and the mask. So if you pass in 3 (00000011 in binary) as your bitmap, only the bit in the second position appears in both. The operator returns 0000010. Since it’s non-zero, we know it passed the test. If you pass in 4 (00000100 in binary), no bit gets set since no bit is set in both numbers. The operation returns 0, and we know the test failed.

So, given a tricky problem (store multiple boolean values in a single variable), we have a tricky solution that’s a little bit of fun to implement and think about. I would love to hear examples of other legitimate uses for clever JavaScript.

Really cool and interesting post by Derek Powazek here:

http://powazek.com/posts/2090

The gist is that SEO is not a valid field in and of itself and that good content will rise to the top naturally. Google works all on its own, and part of Google working is not requiring (or allowing) gaming by SEO goons.

Also of note is that traffic is increasingly driven by social media, which I have to imagine is harder to game as it is driven by real people. So the advice is doubly valuable there.

Sometimes it occurs to me that I’m putting up with unreasonable pain from the software I use on a day-to-day basis. It’s really easy to get into habits and put up with some pretty big deficiencies.

I think it’s dangerous allowing users to put up with annoyances. You’re basically training them to dislike and resent your software and pushing them to find a replacement. Just getting the job done is not nearly good enough.

I will not allow this to happen with Mockery. I’ve got the UserVoice page set up. I’m on top of support emails. The rest of this is just a process of making sure that users communicate any issues to me and making sure there aren’t any annoyances just minor enough for people to work around them.

Tough day here in Red Sox Nation. I think just about everybody had the impression that this year’s team didn’t have what it was going to take, but most of us were hoping for more than this and a rematch with the Yankees in the ALCS would have been fun.

I am looking forward to having more time on my hands to work on some exciting new Mockery enhancements. The Celtics look great this year, and I’m going to enjoy following them. Nevertheless, it’s hard not to be a little melancholy after the long, tough baseball season just ends with a thud.

For what it’s worth, I’ve been saying that the Sox need to either make Papelbon a starter or trade him while he has peak value. Daniel Bard is my favorite player to watch right now and I’m confident that if he had been the closer we’d be getting ready for tomorrow night’s game. Maybe this will be the push that the front office needs.

One of the snags I run into most often when I talk to people about Mockery is the terminology involved in designing UIs. What one person calls a mockup (or a mock-up) another person may call a prototype or a wireframe. While they all amount to more or less the same thing, here’s some clarification on how I see the terms:

A mock-up is an image of a product used to flesh out ideas and solidify the design, done (ideally) before implementation begins. It isn’t intended to work at all; it is just a representation of what the finished product should look like.

Naturally, then, some confusion comes in when the term “prototype” is used to describe a mockup. A prototype is, to my mind, a functional (albeit crude) implementation of something used to prove it can be done and to test the technology involved. The key bit is that it should work. And that’s part of the problem with prototypes: the fact that they work means that all too often the prototype becomes the release. It’s happened to me before, and it’s reason enough to

Wireframe is a term I hear used synonymously with mockup a lot; it seems that a wireframe is a very light, fast mockup without much or any visual flair.

All in all it doesn’t really matter, but I do have to explain what a mockup is more often than I would expect. Hopefully getting the word out about Mockery will help.

Anybody have any thoughts on what we should call all of this stuff?

Update: http://www.melissabernais.com/blog/wireframes-v-mock-ups-v-prototypes/ describes Melissa Bernais’s take on this really well. I agree with her on all of these; our definitions of prototype are a little different but not incompatible.

This is not software related. Those of you who aren’t interested in baseball, my apologies. The playoffs are upon us, and I couldn’t be more excited. Last night’s barn-burner between the Twins and Tigers was a great appetizer, and tonight the postseason starts for real.

My predictions: Sox over Angels in 4, Yankees over Twins in 3, Cardinals over Dodgers in 5, Phillies over Rockies in 4. Sox over Yankees in 7, Phillies over Cardinals in 5, Sox over Phillies in 4.

Why yes, I am a Red Sox fan. But I think their starting pitching is the best of the playoff teams and that will be the difference.

The more I hear about Google Wave, the more I like the idea. It’s a collaborative environment that Google describes as equal parts conversation and document, which is interesting to me for a lot of reasons.

For one, I really love IM. I just really started using it for real this year, but I really prefer it to the phone. Wave expands upon IM with a lot more interactivity, but also with an API that can be used to build functionality on top of Wave.

What I’m hoping is that it will be possible embed the chat-like portions of Wave into existing app and use the “roll-back” and live updates to facilitate collaborative editing. I would love to add it to Mockery.