Wednesday, July 17, 2013

Ship It Day #2

On Friday July 12, 2013 our team, held our second Ship It day with the judging taking place the following Monday, July 7/15.


At the previous ship it day we focused all the prizes on the demonstrations that were given. In both instances we asked a panel of judges to submit a score, based on their own criteria, from 0 to 10 for each team/demo.

Initially the judges wanted guidance on how to score the submissions. Several attributes were suggested but I resisted this because I felt that each judge already has a different viewpoint of what they like to see in a demo and what is important to them. The selection of a wide range of judge types was more important than giving them attributes to score on that might not make sense to each individual. The judges were Business Analysts, User Experience (UX) Engineers, Product Managers, and Senior Software Engineers.

At this Ship It Day we changed the focus to emphasize the importance on creating something that was actually shippable at the end of the exercise. Small prizes have been established around the demo but the biggest prizes are around who can ship in the week immediately after Ship It Day and then the prize size decreases for week two and week three. Given that we are in the middle of week one nothing has been given out yet but there are indications that at least one of the teams will ship in the two weeks immediately following Ship It Day. I'll update this blog post with more details in around three weeks.

In total we had fourteen self-organized teams at this event which is up six (+75%) from the eight we had at the last event. As usual we provided lunch for the team and snacks and drinks throughout the day and at the end of the day we had adult beverages for everyone.

Monday, July 8, 2013

TypeScript as a better JSLint

TypeScript, if you haven't heard of it, is Yet Another JavaScript Transpiler (YAJST). Their marketing pitch:
TypeScript is a language for application - scale JavaScript development. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Any browser. Any host. Any OS. Open Source.
Apart from using the language for its added benefits you can also use the TypeScript Compiler (tsc.exe) as a very powerful and better form of JSLint that can catch "compile time errors" in a language that isn't compiled, in this case JavaScript.


A compiled language like Java, C, C++, or C# benefit from a first round of implicit unit tests which is the compilation of the code. i.e. before deploying the code it's been validated by the compiler and we know that syntactically it is "clean." Of course it may still be very buggy.

JavaScript doesn't have this benefit. We can run unit tests against the JS we write and if not syntactically correct we can catch some of those syntactic errors. However, if we don't have exhaustive, comprehensive and high quality unit tests we won't catch everything. We also can't test for intent.

Here's a trivial JavaScript example that works and is valid but may be a bug:

function getDivisor() {
    return "5";
}

function myTest() {
    console.log(10 / getDivisor());
}


If you run this through the TypeScript Compiler then you'll get this error:

TypeScriptTest.ts(3,17): error TS2112: The right-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

JavaScript will execute this code correctly. It coerces the "5" in a string into an int and everything works as expected. However, TypeScript knows that the only type that can be returned by the getDivisor() function is string and by using implicit typing it knows that you can't (or shouldn't) try and divide by a string.

We can fix this by changing getDivisor() to look like this:

function getDivisor() {
    return parseInt("5");
}


Even if you don't use any of the features of TypeScript, your code quality can improve by inserting TypeScript as part of your build process. I'd suggest that you add this immediately after any other code in your system has been compiled and just before you run any unit tests.

As a note, TypeScript will not accept a .js file as an input, it will only accept .ts files. As such you will need to copy your .js files to a temporary location, renamed them to .ts files, run tsc.exe against them and capture the output.

Sunday, July 7, 2013

Scott Guthrie Event 2013

On 16 May 2013, Scott Guthrie along with Damian Edwards and Joshua Twist came the Valley of the Sun for Scott Gu's tenth annual technical presentation.

I was lucky enough to be on-stage at 4pm for a ten minute presentation. The event took place at the Scottsdale Center for the Performing Arts, 7380 E. 2nd Street, Scottsdale, AZ. There were around 800 attendees but I estimate that there were probably 400 left by that time.



Below is the content of my speech.

Good afternoon ladies and gentlemen. My name is Guy Ellis. I’m the director for software development for the presence and commerce team at Go Daddy. This is my sixth year as an employee at Go Daddy. I started off at Go Daddy as a .Net developer working with the internal tools team. I then moved to our SEO product called Search Engine Visibility which I managed before moving onto the Presence and Commerce team which is responsible for creating our Website Builder and Quick Shopping Cart products.

Over the years I’ve been to almost all the Scott Guthrie events and like this one they’ve all been fantastic and I’d like to thank Scott Cate and everyone else involved for making this available to us at no cost.

I’d like to share with you how I explain SSL to the layperson, or as I sometimes say "SSL for your grandmother."

As developers you most likely know how SSL works but how do you explain to a non-geek that Secure Sockets Layer uses asymmetric public key encryption to prevent a man-in-the-middle attack? How do you explain to them how their username, password and financial data that’s traveling over the ether when they’re accessing their bank account cannot be used if it’s intercepted. They see the green address bar in the browser and the S at the end of HTTP and they know they want it but don’t understand how it works.

To help us understand this I need to take you back in time. A very long time ago. Before the internet. Before television. Before phones where invented. I was a very young man. I lived in a small village on the banks of river. One day I was walking next to the river and on the other side I saw the most beautiful woman I’d ever seen. I couldn’t help myself, I waved and shouted across to her. She took one look at me and headed off. You may notice that men still try and use this technique today except they are usually hanging out of a car window but the impact is generally the same.

I had to get to know this woman so I rushed back to the village and asked around and found out that she lived in the village on the other side of the river. Unfortunately, back then I was afraid of water and unable to take the ferry across the river to meet her. My only choice was to write her a letter and win her over with my romantic prose.

I spent all night writing a letter and in the morning I gave it to the ferryman to deliver to her. I watched from the dock as he paddled across the river disappeared into a house. About an hour later a young man, about the same age as me, came out of the house and went off to her house with the letter and delivered it to her house. She opened the letter and read it and appeared very excited by it but then hugged and kissed the man who had delivered it.

I hired an investigator to find out what had happened and soon it became apparent that this other young man was the ferryman’s son and he had taken my letter and rewritten it from himself and was using my carefully crafted masterpiece to win her heart for himself.

I knew I had to work out a way to get my letters to her without the possibility of interception. I got myself a box, put my next letter in it, put a padlock on it and sent it across the river. I included instructions for her to attach her padlock and send it back to me. Once I received the box back I removed my padlock and then sent it back to her knowing full well that she was the only one that could open the box. My plan was infallible, or so I thought. I later discovered that the ferryman’s son had attached his padlock to the box and stolen my letter again.

I then recruited the help of a man who referred to himself as Mr. Authority. I sent the box with padlock and letter and it came back with an old rusty padlock on it in addition to mine. Mr. Authority took a look at the other padlock and shook his head. This isn’t her lock he said. I rejected the box and the next time it came back it had a beautiful pink padlock that smelled of roses. Mr. Authority confirmed that this was her lock and I removed mine and she finally started receiving my letters.

Several letters later she took the ferry across the river and we met and fell in love and she is now my wife and that, ladies and gentlemen, is how SSL works.



This is the view from the stag when the lights are not switch on. When the lights are on you can't see anybody or any of the seating. It's just a blazing glow.


Photos courtesy of Richard Kimbrough Photography.

Thursday, June 27, 2013

8 reasons you should become a JavaScript expert



As a developer you should always be looking at other languages and striving to be a polyglot programmer. Learning a second language will make you a better developer in your primary language. This seems like a strange statement but what happens is that you see a strange construct or pattern being applied in the second language you say "hey, that's not available in my primary language." On further investigation, something like that or a clever workaround is usually available and that then gets added to your arsenal of tricks in your primary language.

No computer language is more important to learn today that JavaScript. Becoming an expert at JavaScript paves your way for future success.

1. C-based

JavaScript's syntax is influenced by the language C. Most developers have used a C-based language in the past (Java, C, C++, C# etc.) so this immediately gives you a good chunk of the syntax and keywords used in JavaScript. Almost all developers who have worked with a C-based language and then look at JavaScript think that they know JavaScript. This is a mistake. Unlike traditional C-based languages JavaScript is prototype-base, dynamic, and weakly typed.

2. Programming styles

JavaScript supports object-oriented, imperative, and functional programming styles giving the developer the flexibility to experiment with different programming styles in the same language.

3. Full stack

With Node.js it is now possible to use one language to develop web applications on both the client and the server. If there's one language to rule them all then this is it.

4. They all compile to JavaScript

On the client side you have other options than JavaScript to develop in. For example, CoffeeScript, TypeScript, and Google's Dart. However, at the end of the day they all compile down to JavaScript. If they stop maintaining that transpiler then you need to get stuck into the JavaScript code.

In 2006 Google Web Toolkit (GWT) created a way to compile Java to JavaScript

In 2007 we had pyjamas to transpile Python into JavaScript.

List of languages that compile to JavaScript.

5. JavaScript is the only standards-based language that runs in all web browsers

There is no other language that will run in all browser and that has a committee defining and developing standards for it.

6. More JavaScript code is being created each day than any other language

Okay, I just made this one up. However, it might be true. I have no idea how you would measure this but I bet that if it's not true today it will be one day soon.

7. Expert JavaScript developers are tough to find

Want to bullet proof your prospects of finding a job? Then become an expert JavaScript developer. I've been interviewing developers for a number of years and most recently been looking for expert JavaScript developers and I can tell you that they are the hardest type of developer to find. (Drop me a note if you're an expert JavaScript developer and you want to work at Go Daddy.)

8. Legacy JavaScript is going to be with us for decades

Just like COBOL programmers make comebacks every now and then because there is so much legacy written in COBOL, JavaScript programmers will be in demand for a very long time because of the amount of JS that's being written today.

Wednesday, June 26, 2013

Changing the JSON object in an API



Interesting discussion with the development team today about a bug that recently surfaced. The JSON object that was being sent back and forth between the client (browser) and the server changed in structure. For a few hours after the deployment a bunch of exceptions showed up in the logs but as users of the site left and rotated out for new users the exceptions became fewer and finally disappeared.

What had happened was that Ajax calls pages on browsers that had been loaded before the deployment were still communicating with the server using the previous JSON structure while the server was expecting the new JSON object. The code to handle the old JSON object had been removed from the server and not knowing how to deserialize the old object the server was throwing and logging (thankfully) exceptions.

The lesson from this is that you should always provide backward compatibility for one version (iteration) of the code base and then remove that backward compatibility.

The best and easiest way to provide backward compatibility is to have a version key/value pair in your JSON object. Increment the version when you change the JSON structure and perform a switch on the server to handle the previous and current versions. This does, however, require that you thought about this ahead of time and your current live object has a version key/value pair in it.

If not, then you can inspect the object for the known change (e.g. new or removed key) and use an if/else to switch which deserializer you're going to use.

The reason that you want to remove the old code after one iteration is because you want to get rid of dead code as soon as it's dead because it becomes a maintenance nightmare. The longer the dead code is in the code base the more worried everyone is about removing it because nobody can remember if it does anything. While the memory of the previous version is still fresh in your head make sure that old code is killed off. Create a work item in the next project that includes the removal of this code.

Incidentally if you have code that you think is dead but can't be certain (e.g. some code uses reflection to call it or it's an entry point to the application like an API endpoint or web service) then I usually put a log statement in there. Then I put a reminder in my calendar, usually a month out, to search the logging database for that string to see if anything has called it and then I remove it.

Tuesday, June 18, 2013

Graffiti Redirect 404

This is an unusual blog post as it's the destination for unredirectable 404 pages for the old Graffiti CMS that used to host this blog.

A couple of blog posts back I wrote that I had migrated this blog from Graffiti CMS to Blogger. I changed the domain of the blog from a non-www version (guyellisrocks.com) to the www version (www.guyellisrocks.com) so that I could host a redirector on the non-www version.

The redirector receives a request for the original URL and then using a bunch of rules and pattern matches attempts to redirect to the new page on Blogger, this blog that you're reading now. However, before it redirects the visitor it checks to see if the blog page exists in this blog. If Blogger returns 404 then it logs this missing lookup and sends the user to this blog post.

At this point, you should type your query again in the search box above and to the left and it will search just this blog for the missing post.

If, in final desperation, you still can't find what you're looking for then feel free to reply to this post and I'll try and help you.