What HTTP Status Code to return

A colleague shared a link to http://racksburg.com/choosing-an-http-status-code/ with me today. It contains a nice rundown of when to have your API return certain status code values.

End to End testing takedown

Google's Testing Blog has a post, Just Say No to More End-to-End Tests, which does a nice job of articulating my experience with automated testing. Specifically I've found unit testing to be more beneficial than integration testing and integration testing more beneficial than end to end testing (E2E).

The immediate feedback provided by unit tests, which run significantly faster than the other two, helps me as a developer. Using a TDD approach, and frequently invoking my unit tests, the design is refined and failing code is identified quickly. At my current employer we've tied the unit tests into the continuous integration process so that if code coverage drops by 1% or more the build fails. That's a nice defense against having the code atrophy. I also like the closing statement from Martin Fowler's post, Test Pyramid:

In particular I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing unit test. Thus whenever you fix a failing end-to-end test, you should be adding unit tests too.

Integration and E2E tests have value, and I'm not arguing they be skipped, but I've found the greatest ROI comes with unit tests.

Bookmarking future reading

A co-worker was passing around a link to a Mozilla document that provides A re-introduction to JavaScript and I don't want to lose the link. It looks to be a thorough article - which requires more time than I can currently dedicate to it, hence the bookmark post.

Nothing to read here, citizen. Move along.

On the heels of our recent WTF.JS session

Our most recent meeting at the VT .NET user group was a series of lightening talks covering different JavaScript frameworks. Today I was directed to TodoMvc which is a site where the same application has been implemented multiple times using different MV* JavaScript frameworks. It allows developers who are considering the various (and numerous) options to "kick the tires" and see which approach might work best for them.

Neat!

Javascript Patterns Collection

A co-worker shared this link to a collection of Javascript patterns that is marvelous.  Had to share: http://shichuan.github.io/javascript-patterns/

Which came first, the variable or the literal?

Today I received the feedback from a code review one of my peers did of my code and they asked a question about a particular coding style technique I use.  Specifically they asked why when comparing a variable to a literal value I always put the literal value on the left side of the operator?  Put another way, why do I do this:
if(null == someVariable)
instead of this:
if(someVariable == null)

After all, this person pointed out, the second method is more easily read as "someVariable equals null" as opposed to "null is equal to the value of someVariable."  I think that's a fair point and while I'm a big proponent of increasing the readability of code this is an instance where I'll take the hit.

My habit of putting the literal value before the variable comes from dealing with Javascript.  When coding Javascript I might check to see if a value is set to zero, like this:
if(someVariable = 0)

Maybe that looks good to me because I haven't had my third espresso of the day - but it introduces a bug in my code.  I fat-fingered the operator and put = instead of ==.  So now the statement isn't doing an evaluation, it's doing an assignment.  I'm not going to catch that as part of a compile because Javascript is not compiled.  And it's not going to raise a run-time error because it's syntactically valid.

But it's not going to do what I want it to do.

Because I've been burned by this in the past I got in the habit of putting the literal on the left side of the operator.  Because while I still won't get any compile-time love I will get a run-time error when the code says:
if(0 = someVariable)

Yes, the code review was being done against some of my C# code so the same risk isn't there.  But I don't feel like changing this habit from language to language.  Especially where I'm doing ASP.NET and am jumping between C# and Javascript all day anyway.

Making tiny things big - no, not Viagra

Today I got an email from a friend who was taking over a web site from someone else. Apparently he hadn't been given all the original files and is picking up based on what exists on the web server. He was contacting me because there was a JS file which was formatted to all be on one line. He was looking for a way to reformat the file to something he could read.

This is one of those rare occasions when I'm actually able to help someone.

One of the things I've learned since starting at the current gig has been the importance of minifying (sometimes called "packing") the CSS and JS files our application delivers to the browser. If you're not familiar with minifying CSS and JS files, it's when you take your file which is formatted nicely for humans with stuff like comments, indentation, vertical white space, meaningful variable names and etc. and you run it through a program that removes all the stuff that humans like, but which the browser doesn't need. By removing all that stuff, the file can be made significantly smaller - which reduces download time and improves the performance of the web site.

The file he was dealing with had clearly been run through a minifier. The trick now would be to unminify the file. I've never had to do that because we're always starting with the source code. But a quick search on Google lead me to http://jsbeautifier.org/. The tool on this site can reintroduce white-space, such as vertical white-space and indentation, to make the code easier on the eyes. Obviously, it cannot restore comments or meaningful variable names, but if you're going to have to dig in and figure out the code it's a good way to start.

Snippets for HTML, JavaScript and ASP.NET in VS2010? Seriously Cool!

http://weblogs.asp.net/scottgu/archive/2009/09/04/asp-net-html-javascript-snippet-support-vs-2010-and-net-4-0-series.aspx

Update: Whoops... forgot to make it a link.

WebKit border radius and cascading styles don't always mix

Since starting the new job in January I've had to learn more about developing for the web than I ever have. One of the fascinating (and frustrating) aspects has been the way different browsers render the same code. The only web content I've written prior to this job was a very basic set of static pages for the Burlington Irish Heritage Festival and for an intranet web application where the company dictated which browser was to be used. But with the new gig I'm in the real world. That means every change I make needs to test against 4 or 5 browsers. And that's just on my development box, once it goes into QA the application is tested against over 20 different browser and OS combinations.

So I've started to familiarize myself with the various rendering engines used by the major browsers. One of the big ones is the WebKit open source engine. It serves as the rendering engine for some of the browsers I need to support; Safari on Windows and Google's Chrome. Recently we encountered a little WebKit specific gotcha that I wouldn't have expected. It has to do with a WebKit specific CSS attribute, -webkit-border-radius. It's a wonderful attribute that when set instructs the WebKit browsers to round the corners of an element. This post has a very good summary of the -webkit-border-radius attribute (and it's Mozilla equivilent, -moz-border-radius). The important point for this discussion is -webkit-border-radius is a shortcut declaration.

The problem we encountered had to do with how the -webkit-border-radius attribute behaved when used in a cascading style. The application on which I work has one style sheet defined for application wide default styles and then uses additional files to adjust the styles as needed. So, for example, the application default stylesheet may define a class like this:

.someRoundedThing { -webkit-border-radius: 4px; }

which will will cause a WebKit browser to round the corners of an element decorated with that class. Another style sheet could then declares following:

.someRoundedThing { -webkit-border-radius: 8px; }

If a page pulls in the application style sheet and then the alternate style sheet what should happen is the elements on that page which are decorated with the "someRoundedThing" class should be twice as rounded (again, only in WebKit browsers) than on a page where only the application default styles are included. But this wasn't working as expected.

In order for the page defined style to work we had to declare the alternate -webkit-border-radius value using the more verbose, four value declaration. Like this:

.someRoundedThing { -webkit-border-radius: 8px 8px 8px 8px; }

Declaring each corner's radius individually also worked:
.someRoundedThing {
-webkit-border-top-left-radius: 8px;
-webkit-border-top-right-radius: 8px;
-webkit-border-top-bottom-radius: 8px;
-webkit-border-top-bottom-radius: 8px;
}

While I'm not certain why this is going on, I assume it is related to the differences in implementation outlined in this post.

So while I like using the shortcut declarations for their terseness it appears they can lead to problems if your not careful.

Free is my favorite four letter word

Free times 40 is a really lucky number, too!

http://speckyboy.com/2009/07/06/40-free-and-essential-web-design-and-development-books-from-google/

Browser differences and jQuery, (oh, yes... they exist)

I've been doing more with jQuery lately and I can't say how much I'm enjoying it. The other day I was able to take an old JavaScript function that was over 20 lines long and refactor it down to 4 lines... sweet! And one of the nice benefits of using jQuery has been not having to worry about coding to specific browser variations. I did come across something recently, though, that is inconsistent between the browsers which I thought I would share.

It has to do with the way CSS attributes are retrieved for an element. Sometimes the .css() method will return different values for the same style definition (or no value at all) depending on the browser. I'm probably expecting too much of jQuery in terms of it's browser agnostic implementation - but I was honestly surprised. Consider the following HTML page:

<html>
<head>
  <style type="text/css">
    .ugly
    {
      background-color: #3A9F0E;
      border: solid 1px #FFD800;
      color: #fff;
      -moz-border-radius: 10px;
      blur: 1;
    }
  </style>
</head>
<body>
  <h1 class="ugly">test</h1>
  <div id="dvDisplay" />
</body>
</html>

A very basic but easy to grasp example. Ugly, but easy to grasp. There is a H1 tag which has the "ugly" class applied. The ugly class has some style definitions (some valid/some not... more on that shortly). There's an empty DIV tag, too. We're going to use that - just watch.

Now let's add a little JavaScript to illustrate my jQuery concerns. It's going in the head section and looks like this:

<script src="js/jquery-1.3.2.min.js" type="text/javascript"></script>
<script type="text/javascript">
  $(function() {
    var message = "";
    var property = ["border-color",
      "border-bottom-color",
      "-moz-border-radius",
      "-moz-border-radius-bottomleft",
      "background-color",
      "font-weight",
      "blur"];
    property.sort();

    for (var i = 0; i < property.length; i++) {
      message += property[i];
      message += " = '";
      message += $(".ugly").css(property[i]);
      message += "' <br />";
    }

    $("#dvDisplay").html(message);
  });
</script>

The script is going to run when document.ready event fires, build an array of some CSS properties, sort them (because I'm too lazy to put them in the right order) and then loop over those properties to see how the jQuery .css method returns them. Note that the first and second pair of properties (border-color | border-bottom-color and -moz-border-radius | -moz-border-radius-bottomleft) are going after similar values - it's just one is more specific. Note, also, how the style declarations for the ugly class define each of these. Anyway, each property is appended to the output message which is then displayed in that DIV we left open (see, I told you we would use it).

So what does the output look like? Well, despite the browser agnostic behavior of jQuery it depends which browser you're in. Here are the results I saw (all browsers running on XP professional):

Firefox (3.0.11)
-moz-border-radius = ''
-moz-border-radius-bottomleft = '10px'
background-color = 'rgb(58, 159, 14)'
blur = ''
border-bottom-color = 'rgb(255, 216, 0)'
border-color = ''
font-weight = 'bold'

Internet Explorer 8 (both browser modes and all document modes)
-moz-border-radius = '10px'
-moz-border-radius-bottomleft = 'undefined'
background-color = '#3a9f0e'
blur = '1'
border-bottom-color = '#ffd800'
border-color = '#ffd800'
font-weight = '700'

Google Chrome (2.0.172.33)
-moz-border-radius = 'null'
-moz-border-radius-bottomleft = 'null'
background-color = 'rgb(58, 159, 14)'
blur = 'null'
border-bottom-color = 'rgb(255, 216, 0)'
border-color = ''
font-weight = 'bold'

Safari (3.2.2)
-moz-border-radius = 'null'
-moz-border-radius-bottomleft = 'null'
background-color = 'rgb(58, 159, 14)'
blur = 'null'
border-bottom-color = 'rgb(255, 216, 0)'
border-color = ''
font-weight = 'bold'

So, where are the differences? What strikes me is that even though the -moz-border-radius property is a Mozilla specific style, the output in Firefox is an empty string. Only the specific corner (-moz-border-radius-bottomleft) has the value now. I can only assume the style definition I'm using is a shortcut like the border definition. That would explain why Firefox, Chrome and Safari all return an empty string when checking border-color but can return border-bottom-color. IE will give me either.

The other interesting thing is that while IE8 doesn't know squat about the -moz-border-radius property can tell me what I wanted the value to be (but unsurprisingly, can't provide the specific corner value). So IE8 seems to be able to access the style declarations even if it doesn't do anything with them. This brings me to the declaration of the blur property. I wanted to know if it was possible to use CSS styles to store values to be retrieved later by jQuery to be applied to a drop shadow effect (rather than hard coding in the script). And it appears that this approach would work with IE8 but not the others. Which is how I identified the different behaviors of the browsers in jQuery.

So time for one last assumption: I really believe jQuery is doing its best to get the style attributes but the browsers must be preventing it from doing that. This does not dimish my appreciation of jQuery, but makes me recognize different browsers continue to plague web development.

CT Code Camp Recap: Part 2

jQuery – Why You Want It & How to Use it in ASP.NET - Dave Bush

With the release we're currently developing at work we've been using jQuery more and more. Put me down in the fan column. I really, really like it - but I'm still a newbie to it in so many ways. So when I saw there was going to be two sessions about using it I figured attending one would be a good idea. I'm glad I made Dave's talk. It was chock full of demos. I'll admit that even being a relative newbie it took a few samples before we got to examples I hadn't seen, though.

The best parts were some of the best practices he provided. For example, Dave suggested linking to the jQuery library hosted on Google's servers rather than serving it up on our own machines. Many sites do this and it leverages the browser's caching to improve performance.

An interesting point Dave made was to point out there is a difference between jQuery's document.ready event and the document.onLoad event. The document.ready fires as soon as the page is parsed enough where all JavaScript can be executed while the document.onLoad fires when the page is done rendering. Knowing the difference between the two can be instructive when trying to decide which event should be referenced when code needs to run.

Dave suggested making sure we apply VS2008 SP2 so we can have Intellisense when coding jQuery statements. Step by step instructions on how to do this are available on Scott Guthrie's blog here.

Another revelation, and one which I will surely be sharing with my peers at work, was a throw away line Dave had talking about a JavaScript library that forces IE6 to behave like IE7. I wrote that down with the intention to research it because of our requirement for continued support of IE6. Anyway, a quick Google search resulted in this blog post talking about the IE7.js library. It's still just a lead at this point... but I intend to follow up on this soon.

Dave's blog is http://blog.dmbcllc.com

An Excellent Post About JQuery Selectors and ASP.NET

I had to share this blog post by Dave Ward about optimizing performance when trying to get jQuery to select the correct element as you work with ASP.NET.

Small reminder for JavaScript development

Sometimes we need reminders about the basics. In reviewing some JavaScript code this morning I came across a function that builds some html on the fly by concatenating values together. What people have to remember is the smaller the JS file is the faster it will download. So rather than doing this:

scratch = scratch + "<a href....";

you need to use the built in += operator, thusly:

scratch += "<a href....";

The function in question had the first approach 12 times. Using the built in += operator I was able to reduce each statement by 9 characters. That reduces the function by 108 characters overall.

So the lesson is use built in functionality because little things can add up.