Music At Work

This slashdot entry contains some very anger-inspiring content. Especially if you are a developer. Even more especially if you are a developer that listens to music while you work, which I would think most do. The obvious exceptions are the ones who work for the lunatic boss mentioned in the entry who came up with the brilliant policy of banning music at work for developers.

Personally, I would be devastated if I had no music to listen to while writing code. Forget about blocking out office noise. What about the rhythmic productivity music adds to the though process? Is that of no value? I sometimes here a song and almost instantly, I can visualize the code I was writing while listening to it years ago. I wonder if that means the music was distracting me while I was writing it.

Don't take away the right to listen to music at work where it isn't necessary. People just resent you for it and you aren't helping anyone by doing it. You may think you are helping your ego, but all you're really doing is giving yourself false hope as a leader.

The New Javascript

It appears that the ECMA organization has approved the new ECMAScript 5, otherwise known as javascript, standard. It has been ten years since an adopted change to the standard has been made. However, this hasn't stopped web applications from evolving to something that resembles the desktop more and more with each passing year.

The ECMA plans to submit the newly adopted javascript standard as an ISO standard. I think this would be a very good move, especially if web browser vendors decide to stick to the standard.

Aside from the javascript standardization front, there have also been some new features introduced. For instance, javascript objects, or JSON objects, will be able to operate in an immutable mode if chosen to do so. This is could prove useful for working with javascript objects that are returned from an API and aren't intended to be manipulated. Also, the javascript interpreter itself will be able to operate in a strict more that is less forgiving toward malformed-syntax. This will be a blessing for developers that don't feel at ease with deployed javascript that may or may not be well-formed; it may or may not work in some browsers.

Chrome OS

There is a lot of hype around the new Google Chrome OS as of late as the source code has been released. There should be lots of hype around this new operating system because it is a new concept. Sure, there are net-books you can use for your light-weight web browsing purposes. But that doesn't really cut it if you have stuff to do.

The approach behind the Chrome OS is that it is a web browser that grew up into a light-weight operating system. The OS isn't concerned with running local desktop applications and can optimize for the web. I find this concept both interesting and frightening.

The idea of having a computer that I cannot use, in the conventional sense will most likely turn many people off. It is a little scary that none of your data is in your hands. With a conventional laptop, you can at least store whatever you want and carry it around with you. I wonder what Google will do if people don't like that idea of all their data being out of their hands. Not likely to happen.

Software Maintenance

This entry talks about some of the problems faced by current software maintenance practices. It highlights some of the various maintenance methods used to maintain deployed software. Of course, not many seem to do it right.

Problems arise mainly because of incompatibility between software versions. Typically, the entire software package has a version assigned to it. This includes all the constituent parts of the application such as modules and data structures. What if this individual components were giving a version instead of the whole? Well, there are systems out there in existence that do just that according to the entry.

What about taking this atomic version schema idea to the URIs of RESTful APIs. Indeed, this idea isn't anything new as many APIs support this feature. The main problem faced by web applications when performing server-side upgrades is the cached clients. Javascript that interacts with the URIs on the client's behalf may be stuck using an old API version. This is fine if the API version number is part of the URI. But backward compatibility can only be maintained so far back. This can be dealt with much easier if the expected version is part of the URI. If an unexpected version is requested, a message can be displayed to the client telling them to download a newer client. Alternatively, the new client code could be transparently delivered to the client as a response to using an incorrect version number.

Ugly Comments

This entry over at IT world talks about ugly comments in code and what that means about the code itself. Well, the basic assumption made is that if the comments in the code are ugly, so is the code. This assumption is derived from the principle of attention to detail. This attention to detail required by the programmers who write the code are not exempt from focusing attention to comments.

The problem is that the functional code and the non-functional comments really aren't all that different. I would argue that the comments are as much a part of the running program as the functional code is. They live in the same source files and are one in the same.

Writing great code doesn't really solve the problem of crappy comments either. In fact, the better the code, the more the sub-par comments will stick out. This doesn't mean going into great depths in annotating a piece of functionality. That will often add to the confusion. Go into depth explaining things outside of the source file. Make your comments in the source files concise but complete. Correct spelling doesn't hurt either.