Our code server now offers validation for LESS stylesheets. Here is its updated list of features:
Now that we’re re-building most of our user interface using jQuery UI, we’ve decided to adopt CoffeeScript for our entire codebase. We won’t use it just quite yet though. Instead, we will complete our codebase overhaul, then convert our JavaScript code to CoffeeScript. From there, our CoffeeScript code will be compiled into plain JavaScript on the fly by our code server.
Error reporting might not be the most exciting feature, but it has to be one of the most useful. Therefore, we decided to make it right. The first version deployed on our code server displayed errors in plain text on a web page. The second that was released just a minute ago turns it into a clean JSON file with hyperlinks highlighting faulty code lines directly on GitHub.
Superb!
After a busy afternoon, we fixed all 632 errors that were caught by JSHint. Our code server is turning into a super powerful tool, with the addition of automatic email notification when new code is pushed to GitHub with any error in it. What’s even better is that the email is only sent to the developer responsible for the faulty commit, so that other developers aren’t distracted.
To summarize, here is what we get at every commit, automatically:
Once we add some kind of mirroring, we should be good for Version 1.0.
We just added JSHint to our code server.
Now I know that I have 632 errors to fix in my code.
Is that a good thing or a bad thing?
Sometimes, ignorance is bliss…
Our code server is slowly but surely becoming a critical piece of our architecture. We started with simple redirection from GitHub, then added minification, and finally implemented documentation. Moving forward, we expect the following functions to be fulfilled by this component:
Lost productivity: 30 minutes
Lesson learned: priceless
This morning, our code server hosted by Heroku is unavailable. The problem seems to come from Heroku, since devcenter.heroku.com is down as well. This is yet another reminder of Murphy’s Law of Cloud, and that we must design our architecture accordingly.
As far as code serving is concerned, we could adopt one of these strategies:
Option #1 could create some security issues.
Option #2 is most likely the easiest to implement.
Option #3 would be an excellent addition to Option #2.
Consequently, we will most likely go for Option #2 first, then add Option #3 to make it bulletproof. Obviously, all this is adding quite a bit of complexity, but that’s the price to pay for fault-tolerant applications in the cloud.
