Sundarrajk's Weblog

Archive for the ‘Technology’ Category

How to Stop Sucking and Be Awesome InsteadHow to Stop Sucking and Be Awesome Instead by Jeff Atwood
My rating: 4 of 5 stars

Another nice book of blog entries from Jeff Atwood.

First few blogs are about how one should determine at a very early age if one can program or not and should drop out of a programming career if one is not. He speaks about “sheep that can program and goats that cannot program” should be separated out early in the career so that software can become better.

Some of the key observations that I liked are “You have to truly believe, as a company, and as peers, that crucial innovations and improvements can come from everyone at the company at any time, in bottom-up fashion – they aren’t delivered from on high at scheduled release intervals in the almighty master plan.

In another blog he speaks about how important it is to persuade others to do something. He refers to a set of dialog from the movie based on Idi Amin. Idi Amin is speaking to his trusted aide a Scottish Doctor.
Idi Amin: I want you to tell me what to do!
Garrigan: “You want me to tell you what to do?
Amin: Yes You are my advisor. You are the only one I can trust here. You should have told me not to throw the Asians out in the first place!
Garrigan: I did!
Amit: But you did not persuade me, Nicholas. You did not persuade me!

Not a very atypical dialog one is likely to have with either one’s manager or client. 🙂

Another important advice with which I cannot agree more since I have given the same advice to many others who have asked me for my opinion. “Whatever project you are working on, consider it an opportunity to learn and practice your craft. It is worth doing because, well it is worth doing. The journey of the project should be its own reward regardless of whatever happens to lie at the end of that journey.”
The corollary is another thing that I keep stressing on; “Never get attached to a project. Execute the project to the best of the abilities, learn along the way and if for some reason beyond your control the project fails or does not see the light of the day, so be it.”

Speaking on merit based growth in an organization Jeff has to say the following “Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means [among other things] abolishment of annual or merit rating and management by objectives. “Even people who think of themselves as Deming-ites have trouble with this one. They are left gasping. What the hell are we supposed to do instead? Deming’s point is that MBO and its ilk are copouts. By using simplistic extrinsic motivators to goad performance, managers excuse themselves from harder matters such as investment, direct personal motivation, thoughtful team formation, staff retention, and ongoing analysis and redesign of work procedures. Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect.

In one blog Jeff compares F-86 and MIG-15s. The latter was far more superior to the former, but the fighter pilots preferred the former. The difference was that F-86 had Hydraulic flight controller compared to the manual flight controller of MIG-15. This meant that each maneuver increased the fatigue of the MIG-15 pilot even though he might have out-maneuvered the F-86 pilot. The F-86 could maneuver quicker as compare to the MIG-15 as he was less fatigued and this tilted the pilots to favour F-86 despite its limited abilities. Jeff calls this the Boyd’s Law of Iteration which states “Speed of iteration beats quality of iteration”. Jeff argues the same is true for software development. Although he says in other places that quality cannot be sacrificed beyond a point.

There is a whole set of blogs in User Interface and Usability. One book the author highly recommends is Don’t make me think by Steve Krug… and another one is Rocket Surgery made easy again by Steve Krug….
He speaks about the Fitts law which states “Put all commonly accessed UI elements on the edges of screen. Because the cursor automatically stops at the edges, they will be easier to click on. Make clickable areas as large as you can. Larger targets are easier to click on”. One should not ignore the corollary of rule which would read “Make all the clicks that the user must be kept safe from as difficult as possible”. Jeff refers to this principle as the “seat ejector” button. This button should be easy to find in an emergency, but should not be place such that the pilot ends up turning this on instead of the navigation lights. Buttons like delete all my mails and such should be available, but should be placed such that the no user would click it by mistake.

Speaking on importance of saying not to demands, Jeff says “It is easy to dismiss Just say No as a negative mindset, but I think it is a healthy and natural reaction to observation that optimism is an occupational hazard of programming”. Cannot agree with him more as I have been pulled up for saying no many a time in my career.

Speaking about usability Jeff argues that most users of the applications do not progress beyond the intermediary stage. He argues that most move from the novice to Intermediary stage quite quickly or drop off as an user of the system if they find it too difficult to use. Once they reach this stage they remain in this stage for a long time and only a very few move to the expert level. Given this he argues that software should be targeted towards these users rather than at the novices or the experts. He states that most marketing people would advocate making software for the novice as these would be the ones that the marketing people would encounter most of the times, while the software developer would want to address the experts as it is likely that they would be geeks themselves and would want maximum flexibility and most features.

Writing on security and hacking the author says that today to hack into a site one needs social skills and not technical skills. Technology has advanced to a level where hacking into a website has been made difficult enough, but people are not inure to social engineering and that it is much easier way of hacking into a system.

On the whole a very good read.

View all my reviews

In the following code

package com.tcs.ngps.htmlparsers

import org.jsoup.Jsoup
import org.jsoup.nodes.Document

class JSoupParser {

    public JSoupParser() {


    static main(args) {
        String lString = (new File(args[0])).getText()
        Document lDocument = Jsoup.parse(lString)
        //(new File(“D:/Temp/AWRJSoupParsed.html”)).newWriter().write(lDocument.toString())
        def lBufferedWriter = new BufferedWriter(new FileWriter(new File(“D:/Temp/AWRJSoupParsed.html”)))
}The above code reads an HTML file and converts it to a XML file using JSoup parser. It then writes the XML to a file.
Now if the code 
(new File(“D:/Temp/AWRJSoupParsed.html”)).newWriter().write(lDocument.toString())
is used to write the file to the output the output file is always smaller than the total length of the string (when the String is large). Only when one uses the following code
def lBufferedWriter = new BufferedWriter(new FileWriter(new File(“D:/Temp/AWRJSoupParsed.html”)))

Is the whole file written. Unable to figure out why.

The article suggests that Chrome will overtake Mozilla as the second most used browser after Internet Explorer. It will be a sad day for me who has been a Mozilla fan for the last 6 – 7 years. In the last two months I too have become a Chrome user due to certain circumstances. In probably another month or so I should be back using Mozilla. What I saw of Mozilla 6 did impress me, and hoping that Mozilla 7 should be better based on the reviews it has got so far. Chrome takes too much of my memory in any case.
Martin Fowler in the Book Refactoring has to say the following:

“Any fool can write code that a computer can understand. Good Programmers write code that humans can understand”

Wonderful statement. I wish this is made part of our academics (in India specifically) and this fact should be drilled into the heads ot students who are expected to write programs in their careers.

“Computer Science is a discipline that believes all problems can be solved with one more layer of indirection”. This statement was made by Dennis De Bruier.

The problem with flexible solutions is that flexibility costs. Flexible solutions are more complex than simple ones. The resulting software is more difficult to maintain in general, although it is easier to flex in the direction I had in mind. Even there, however you have to understand how to flex the system.

How right and and one hopes that one’s clients understand this fact.

In the book the authors talk about presence of bad code to bad smells and give details of how to identify bad code equating to bad smell. One statement that they make stands out. “Watch out for comments”. It is not that the authors are against comments, it is just that presence of comments indicates a high possibility of bad code. This is what the authors have to say about comments in code.

 “We are not saying that people should not write comments. In our olfactory analogy , comments are not bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant. Its surprising how often when you look at a thickly commented code and notice that comments are there because the code is bad.

Comments lead us to bad code that has all the rotten whiffs we’ve discovered. If we refactor the comments will most likely become redundant.

If you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted and you still need a comment to explain what it does, use Rename Method. If you need to state some rules about the require state of the system use Introduce Assertion.

A good time to use Comment is when you do not know what to do. In addition to describing what is going on, comments can indicate areas in which you are not sure. A comment is good place to say why you did something. This kind of information helps future modifiers, especially the forgetful ones.”

Absolutely brilliant summary about comments.

Read the book