Behind schedule

I know, I tend to live faster than my blog updates. So there are a number of things I haven’t posted about. For example I read several books, I had some interesting experiences with shell script programming and I found some clever sites I’d like to share with you.Moreover the whole site needs some freshening and I discovered that the gallery page of Naxos island is not correctly displayed.
Don’t worry, I am here to get back on track. One of the blog I’m reading this day is Coding Horror. I found it very insightful and worth. You can have it served via RSS feed. I feel really attuned with the writer, at a point that I myself could have written something like this. So today he wrote about how defining a sustainable schedule and attaining to it is a key factor for success (and, more specifically for a successful blog).
Well my schedule is something like – fill the slack time, and I precisely attain to it. Maybe that’s why I have a few selected high quality readers that keep reading my rants. Thank you.
So here is a list of books I should write the review: Yourdon’s Death March, Rowling’s Harry Potter and the Deathly Hollows, Pratchett’s Good Omens: The Nice and Accurate Prophecies of Agnes Nutter, Witch, Zattoni Gillini’s Paquito’s story, Chistolini’s School and Adoption.
If you are involved on a understaffed, under budget project with tight deadlines, just don’t wait for my review of Death March, grab your copy now. Although most of it could be considered just common sense, it is nonetheless a well organized, well written common sense. And when you are under the pressure of a Death March kind of project, common sense has been usually left behind.

Out of the way

It is a few day I have this thought in and out my head. There is no particular fact that triggered this off, I think it’s just some random observations.We programmers like computers and software. That’s obvious – we find them entertaining, funny, sometimes even a sort of lifestyle. Wouldn’t it be the case we would have chosen something different, more economical rewarding (such as the plumber), more socially oriented (e.g. the plumber) or even more funny (water’n’pipes are fun, aren’t they?).
I find than more than often our programs have features and behaviors just to amuse the other programmers or even ourselves, forgetting that real users, those who will use our program to do some actual work, aren’t so fond of computers beside having some actual work to do.
I think we should enforce a new paradigm for program development: the computer is actually an obstacle, a barrier between the user and her goal. The software has to clean the road and keep off the way.
Just ask yourself if that “Error Blah blah” dialog box you are coding is something that helps the user to reach his goal and perform his task, or is just something that will annoy him. Is really a user fault if the file has the wrong name? Are we really sure that the user has to know what a file is?
For another example consider the need of a user to deliver an amount of data (files) to another user. The obvious choice, since everyone has an email account, is to use it. That is the need for the user and the clear, logical solution she sees.
So, the size limit for attachments is just an obstacle to the activity she has to perform. But the real solution is not to grow the limit, but to take the limit off. If the mail protocol is not suitable for bulk transfers, then the software has to use other means. Why can’t it arrange an ftp transfer? Sure it’s not as easy as I put it, but it definitively can be done.
On the same issue, there are users that fall in love with technology and forget any other sensible way of doing things. So their activities could become extremely time wasting. I needed a reference on how to attach cables to an electronic board for testing. I looked in the usual repository just to find every kind of documentation but the one I was looking for. I asked the guy who was supposed to provide that kind of information and he told me that he was unable to provide the board layout because the software is not yet able to do it and that we need another module for … and so on. I took paper and pen and sketched the layout on a sheet of paper, then scanned it and put on-line on the server. It took me about 20 minutes because I had to look up the schematics. The document I produced is not polished, but… who cares?

Some Links

I’d like to bring the links below to your attention.First I found Steve McConnell’s blog. Steve wrote a bunch of very interesting stuff for programmers and project managers. I really enjoyed his Code Complete and Software Project Survival Guide, I read his very insightful slides on the matter he dealt with in Rapid Development. His Software Estimation: Demystifying the Black Art is in my reading queue, I’ll get to it, soon or later. A quick glimpse at amazon revealed the other two books: After the Gold Rush: Creating a True Profession of Software Engineering and Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. That’s to say that you can find his thoughts very interesting. Just take for example:
“[[…] people often have an oversimplified view of other engineering disciplines when they make comparisons to software. I talked about that back in June in my post about “Rumors of Software Engineering’s Death are Greatly Exaggerated”

The other blog is the one that pointed me to McConnell’s is Coding Horror. It is a low traffic (2-3 post a day), collective blog about bad programmer experiences or braindead code behavior, sometimes funny, sometimes insightful.

Last, but not least, I found Artima blog, another low traffic and collective blog that deals with software technology from the programmers point of view. The last post, for example, explores the question why most of the largest websites are not written in Java.

Hope you find something useful there.

Putting captcha to work

Quite a long ago, an unfriendly Mr. Spam exploited my blog system to put his (maybe her) unwanted advertising into my website. I resorted to a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), but also found that the test was harmless for the clever and determined spammer.In fact such a guy could forward the CAPTCHA test to another website so that clueless users could put their brainpower to unlock the test. Let’s rephrase that. A clever spammer could set up an high traffic website (such as something with pictures… you guess which) where users are requested to solve the CAPTCHA in order to access the content. This website doesn’t forge CAPTCHA tests, rather it forwards the tests from a target site that the spammer want to access. Once the CAPTCHA is solved by the unaware gif-watcher, the spammer’s system is able to spam the target site.
Fortunately this solution is limited by the number of people willing to solve CAPTCHA to access a content that has as a stringent requirement to be cheaply collectible. I guess that that constraint limits the application of this solution just to a few, high traffic, blogs or websites.
I read today on slashdot that not only spammers are that clever. At Carnegie Mellon University researchers have found a way to exploit CAPTCHA to data-entry large volume of ancient manuscripts. The CAPTCHA proposes two handwritten words. The first is already decoded and is the real locking system, the second is a word to decode. The result, if confirmed by other users of the system, is then turned into the manuscript digital translation.