In your search for achieving excellence in creating software you might have come across one of these statements that ‘code is an art’ or something in that fashion. Although these statements are very appealing, I believe it not to be true. I will explain why. First let’s start with the reasons why a computer programmer (or coder) is considered an artist and it’s product (code) art. Writing code is labour intensive and various attempts have been made to automise the coding process through the use of high-level visual languages or application-generator tools.
Development
One of the most overlooked aspects in any software project is the end-user (e.u.) documentation. Can you recall how many (web)applications you have encountered that had proper e.u. documentation in it? I for one cannot, even though the (web)applications are getting more sophisticated and more complex every day. And to be honest, the software projects I create often lack proper documentation as well. So why is this the case? There are a number of reasons that I can think of:
Ah, so finally Microsoft has also taken the road towards the Model-View- Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self- proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are ‘seperation of concerns’ and ‘designed for testability’. Let’s take a look at these two: Seperation of concerns.
A small wave has hit the developer community this weekend about a clash between two lead developers: Chris Wilson of Microsoft’s IE team and and Brendan Eich of the Mozilla foundation. The dispute is about the acceptance of ECMAScript 4; the proposed successor of Javascript. Wilson wrote public doubts about this standard, which let Eich to write a public letter in which Microsoft is being blamed for being reluctant and passive in the development of ECMA4.
I recently wrote an article about the concept and implementation of something which I call Role-Based Security in a Hierarchical Environment . It is a form of RBAC (Role-based access control). However, it also takes in account a context object (on which item is my function performing). And role permissions cascade down the context-tree. So having a permission on a certain context object means you also have permission for all underlying context objects (or not, depending on the role parameters).
