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.

Tuesday, May 28, 2013

Stream ended unexpectedly (got X bytes, expected Y)

I was trying to clone the nopCommerce repository from codeplex (https://hg.codeplex.com/nopcommerce) to my local drive and the first two attempts failed with stream ended unexpectedly (got X bytes, expected Y)



The definition of stupidity is trying the same thing twice and expecting a different result right? In this case I was running it a second time to see if it failed at exactly the same point. If that happened then it was most likely a corrupt source/repo on the server. If the values were different (which they were in this case) then it indicated that it could have something to do with the network.

By checking the "Do not verify host certificate" option in TortoiseHG's close function to I managed to complete the download successfully.


Thursday, May 23, 2013

Migrating from Graffiti CMS to Blogger


I set this blog up in 2008 and have blogged on and off for the last 5 or so years on technology. I selected Graffiti CMS after Rob Howard from Telligent, its creator, gave a talk at our local AZ Groups .Net user group and he gave out a bunch of licenses to a this product which was then going to be sold at $150. It has since become open source.

Graffiti CMS has treated me very well and is a remarkably good product. However, these were the drawbacks that made me decide to move my blog off Graffiti:
  • Very small number of users and one very kind and competent developer maintaining it.
  • I hosted it on my dedicated server. This meant that it was eating up resources that other web apps needed.
  • I had to upgrade it and maintain it and patch it myself and a security vulnerability might impact other applications on the server.
I moved it to Blogger because I already have a blog on Blogger and as such I'm familiar with the tools but I'm sure that other blogging platforms like Wordpress would have had as much as I needed as well.

The migration process went like this:
  • Found some code that someone had written to export the blog into BlogML and tried it out. This failed as Blogger couldn't read it in.
  • Spent a few hours modifying the code to get the export format I wanted but was unsuccessful. Knowing that I don't have much time on my hands to do this type of thing I threw some money at it and asked the Graffiti developer to create an export for me.
  • He kindly did this and here I am, 300 or so migrated posts in Blogger.
The original blog ran off http://guyellisrocks.com/ (no www) and I've migrated it to http://www.guyellisrocks.com/ so that I can redirect to the new url pattern. I've written a web app which is now sitting at the non-www version and when it gets a request it then reaches into the database and pulls out the date for that post and generates the new url. This is then used for redirection to the new (this) site.

What's still to be done?
  • Some of the URLs did not migrate in the predictive fashion I'd expected. I'm logging those and will make changes to the redirection code as I go along.
  • Images have not come across so I'll do that manually as I find time.
  • There are references to the non-www version in the new www version and even though they will redirect correctly they should be fixed as eventually I'd like to get rid of the redirector. I'll do this by checking the referrer header and if it's from the www version I'll log this so that I can find the posts with those links.