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.