Ashes sledges

Nanda pointed me to Tim de Lisle’s post on The top ten Ashes sledges. Amusing. My favourite:

Mark Waugh to Jimmy Ormond on his Test debut, 2001: “Mate, what are you doing out here? There’s no way you’re good enough to play for England.”
Ormond: “Maybe not, but at least I’m the best player in my own family.”

🙂

Baba Kalyani: Distrubing trend

Yesterday we went to watch a Malayalam movie called Baba Kalyani. The movie was of mediocre quality; the plot was ordinary, and the cast was largely Mohanlal with a huge list of guest artistes. But that is not what this post is about.

Shaji’s camera work for the movie was very bad. The camera was often positioned at odd angles, and used lots of tricks which looked good on Matrix, but made Baba Kalyani look like a video game rather than a feature film. Worse, it hurts the eye of the viewer – I am paying good money to be entertained, not to leave the movie hall with a headache (I am not exaggerating; I did have a headache yesterday and had to use an ice pack when I got back). If Shaji Kailas, the director, thinks that such tricks makes him ‘cool’, here is at-least one viewer that think otherwise. Shaji Kailas had tried similar stunts to a lesser extent in his last hit – Chinathamani Kolacase – also.

Mr. Shaji Kailas, please refrain from hurting the eyes of your viewers .. please! You can do a lot better than that.

Rant over! 🙂

Dealing with Overseas Employers 101

Yakov Fain writes about a presentation he heard titled “Dealing with Overseas Employers 101”.

1. America is rich, we are poor. It’s not fair, they have to share.
…
3. One of your major problems will be “what to write in status reports”. Never write “I could not do it ” there. Americans like positive statements. For example, let’s say you’ve got an assignment to create a reusable component that will identify the number of failed database requests. You do not even have a clue what are they asking for.
The first week you spend on Google in hopeless attempts to find such component. The status report for the first week should read “Comparing various approaches of creating reusable db-failures component to find the most efficient and effective way for its development”. During the second week invent something similar. Hopefully, on the third week something more urgent will come up and you’ll get another assignment.
…
6. In conversations with your overseas teammates, always require detailed written specifications for each small program modification. Ignore their statements “I’d fix it myself faster than writing detailed specs for you”. They have no choice and must work with you to show that your team is useful.
7. Use time difference to your advantage. For example, if you want to send an email asking for some clarifications, do not send it in the moring, because you may get an immediate answer. Do it in the evening (your time zone), before leaving the office – you’ll get the answer only next day.
…
11. Change your local employer every three months. You are gaining experience daily, and even if the new job offers just one percent of salary increase, go there. It’s a golden IT offshoring era – use it while it lasts! Or as they say, it’s time to make a quick buck!

Its funny. I really hope its a joke; its very scary otherwise.

James Brown

The Hardest Working Man in Show Business passed away at 73 – on Christmas day. Like everything else about the man, he made his exit also in grand style.

I haven’t heard much from James Brown besides his popular hits. I know his music mostly by the influence it had on later day musicians I admired – Micheal Jackson, Prince, David Bowie, Mick Jagger etc.

May his soul rest in peace.

Salary negotiations: the rolling stone gathers all moss?

Today I came across a post on negotiating salaries by Spurious Pundit from couple of years ago.

The perverse incentive is simply that salary negotiations set up a system that rewards people for not caring about their jobs. Negotiating 101: The most important factor in any negotiation is the willingness to walk away. You go to buy a house, and that’s the first thing anyone tells you. Don’t fall in love with it. If you aren’t willing to walk away from it, they can take you to the cleaners.

So the people who don’t really care about their jobs, the clock-watchers, the ones who can take it or leave it, who haven’t really bonded with their co-workers, who don’t really believe in the product or take pride in their work? They’re the ones who can walk away. The only thing keeping them there is the cash, so it’s going to cost you more. The ones who aren’t like that, who are emotionally invested in the company? You’re turning that against them.

Painful to realize – but likely true. Every time I talk to people who have worked in any industry for many years, they tell me that staying put at a job will pay up in the long run. But every time I look around and notice my colleagues, ex-colleagues and friends, I wonder how much truth there is to this age-old wisdom.

Another post on Spurious Pundit talks about the ‘value’ of software developers:

Let’s go through the basics here. You are working at a job. Your employers employ you. They pay you a salary. They pay you this salary because you do something that they consider useful. “Useful” generally means “makes money for them”. There may be a fairly indirect path to it, but what you do ultimately brings money in the door. Your usefulness to them is measured by how much money that is. Your perceived usefulness also depends on how visible the connection is between your work and money coming in.

This is why sales people make so much more than programmers. Their work is directly tied to money coming in. The sales guy can say, “I made X in sales this month.” You can argue that because you’re a really good programmer, it’s easy for the sales guys to sell your work. You can argue that the clever work you did six months ago has resulted in a better product, and increased sales now. But that’s very hand-wavey. It’s hard to put dollar figures on that.

Questions about ‘value’ are one the first things that a software developer comes across while going into a salary negotiation. But I suspect that there is a subtle point here, from the Indian software services industry perspective, that Spurious Pundit misses.

When a new project needs immediate staffing and the client is twisting their arm to get a team started with developers with a particular skill set, it is very easy for the management to realize the value of a software developer. At that point the management is in direct negotiations with the client, the project is on everyones radar, there is a looming threat of potential revenue lost and everyone knows the value of a good developer – by her absence.

If you happen to be the one chosen to fill that requirement, you are guaranteed to get a good starting salary. But once you settle down into the job, as the project progresses without incident (and the client is happy; the sales folks might have bagged new projects from the same client) – your value is a thing you would find hard to demonstrate. Furthermore, a new client and a new opportunity would be in focus. You? Well, you still are a “valued contributor”, but that usually ends up being lip service.

The best way to get into a situation where you don’t have to try too hard to demonstrate your value is to walk out again into the job market – and go find a place where they are looking for someone to fill an immediate staffing requirement. Thus developers who gets a steady stream of hikes and perks are the ones who change jobs very frequently.

Is IT an area where the ‘stay-at-a-job-for-years’ theory does not work? Or is it that it is too early to say, and we are being impatient? Let me know your thoughts.

Taking Screenshots with Selenium

I had written about using Selenium, TestNG, Cargo and Maven to write an automated smoke test suite. It would be useful if we could get a screenshot of the application under test at every stage of the test – the screenshots would be useful to diagnose test failures. In this post I describe a crude screenshotting mechanism that I have developed to take screenshots for tests running in Selenium.

Note: The code used for this post can be downloaded here. Due to WordPress restrictions, I had to rename it with extension .jpg. Kindly rename it to .tar.gz. Also, the code is a continuation from my previous post.

The basic idea is to extend com.thoughtworks.selenium.DefaultSelenium class such that it takes a screenshot after each significant step.

public class ScreenshottingSelenium extends DefaultSelenium {
    // ..

    @Override
    public void click(String locator) {
        super.click(locator);
        takeAScreenShotOfTheApp();
    }

    @Override
    public void open(String url) {
        super.open(url);
        takeAScreenShotOfTheApp();
    }

    @Override
    public void type(String locator, String value) {
        super.type(locator, value);
        takeAScreenShotOfTheApp();
    }

    // ..
}

To take a screenshot, we need to make sure that the application window is the in the foreground and is maximized, and then take a screen capture.

To take a screen capture, we use the java.awt.Robot class:

public void takeAScreenShotOfTheApp() {
    Dimension screenDim = Toolkit.getDefaultToolkit().getScreenSize();
    Rectangle screenBounds = new Rectangle(0, 0, screenDim.width, screenDim.height);

    Robot robot = new Robot();
    BufferedImage image =  robot.createScreenCapture(screenBounds);

    File screenshotFile = new File("target" + File.separator
                                   + "image" + System.currentTimeMillis() + ".png");
    ImageIO.write(image, "png", screenshotFile);
}

By default, Selenium shows the application under test in a browser frame. This frame, of course, cannot be maximized to occupy the entire screen. If Selenium Remote Control server is launched in multiWindow mode, the application under test is launched in a seperate browser window. To launch Selenium Remote Control server in multiWindow mode:

@BeforeSuite
public void startSeleniumServer() throws Exception {
    seleniumServer = new SeleniumServer(4444, false, true);
    seleniumServer.start();
}

To make sure that the application under test is shown in a maximized browser window:

public class ScreenshottingSelenium extends DefaultSelenium {
    // ..

    @Override
    public void start() {
        super.start();
        windowMaximize("");
    }

    // ...
}

To make sure that the application browser is on the foreground just before taking the
screenshot:

public class ScreenshottingSelenium extends DefaultSelenium {
    // ..

    @Override
    public void click(String locator) {
        windowFocus("");
        super.click(locator);
        takeAScreenShotOfTheApp();
    }

    // ...
}

Now, if we use ScreenshottingSelenium instead of DefaultSelenium, we would get screenshots of the application in the target directory. But we would like to go one step further – we want to generate a nice HTML report of the screenshots. For this we create a Reporter class:

public class Reporter {
    void startTest() {
        // Called when a test is started; creates the directory
        // for saving screenshot images of this test
    }

    void endTest() {
        // Called when a test ends; creates an HTML summary
        // of all screenshot images of this test
    }

    void recordStep(String description) {
        // Creates a screenshot and saves the image to a file
    }

    public void close() {
        // Called after all tests are run; creates an HTML summary
        // of all tests run
    }
}

The implementation of startTest(), endTest(), and close() are quite simple that I do not describe them here. recordStep is essentially the same as takeAScreenShotOfTheApp() earlier. The HTML reports are generated using couple of FreeMarker templates.

The ScreenshottingSelenium would be configured with a Reporter object; the ScreenshottingSelenium calls methods on the Reporter object at appropriate times. The startTest() method is called from the start() method. The start() method opens a browser window and this we assume signals the start of a test. The endTest() method is called from the stop() method. The stop() method closes the browser window, which we assume signals the end of a test. Method like click(), type(), open() etc call recordStep() method of the reporter object with a text description of the action just performed.

public class ScreenshottingSelenium extends DefaultSelenium {
    private Reporter reporter;

    public ScreenshottingSelenium(CommandProcessor processor, Reporter reporter) {
        super(processor);
        this.reporter = reporter;
    }

    public ScreenshottingSelenium(String serverHost, int serverPort,
            String browserStartCommand, String browserURL, Reporter reporter) {
        super(serverHost, serverPort, browserStartCommand, browserURL);
        this.reporter = reporter;
    }

    @Override
    public void start() {
        reporter.startTest();
        super.start();
        windowMaximize("");
    }

    @Override
    public void stop() {
        super.stop();
        reporter.endTest();
    }

    @Override
    public void click(String locator) {
        windowFocus("");
        super.click(locator);
        reporter.recordStep("Clicked");
    }

    @Override
    public void open(String url) {
        windowFocus("");
        super.open(url);
        reporter.recordStep("Opened " + url);
    }

    @Override
    public void type(String locator, String value) {
        windowFocus("");
        super.type(locator, value);
        reporter.recordStep("Typed '" + value + "'");
    }

    @Override
    public void waitForPageToLoad(String timeout) {
        windowFocus("");
        super.waitForPageToLoad(timeout);
        reporter.recordStep("Page loaded");
    }
}

The Reporter object needs to be created before the testsuite starts execution. Also, the close() method on the reporter object should be called after all tests in the suite are executed. We make use to @BeforeSuite and @AfterSuite TestNG annotations for this purpose:

public class SeleniumSetup {
    private static Reporter reporter;

    @BeforeSuite
    public void setupReporter() throws Exception {
    	reporter = new Reporter(new File("target" + File.separator + "screenshots"));
    }

    @AfterSuite
    public void cleanupReporter() throws Exception {
    	reporter.close();
    }

    public static Reporter getReporter() {
    	return reporter;
    }
}

//..

public class FirstTest {
    private Selenium selenium;

    @BeforeMethod
    @Parameters({ "browser" })
    public void openBrowser(String browser) {
        selenium = new ScreenshottingSelenium("localhost", 4444,
                                              "*"  + browser, "http://localhost:8080/",
                                              SeleniumSetup.getReporter());
        selenium.start();
    }

    // ..
}

To see these ideas in action:
1. Download this code bundle. Rename the .jpg file to selenium-screenshots.tar.gz.
2. The bundle contains a small web application and its smoke testsuite. Uncompress the archive to some place on your disk.
3. Install the web application on your local Maven repository.

> cd selenium-screenshots
selenium-screenshots> mvn install

4. Run the integration testsuite:

selenium-screenshots> cd functest
functest> mvn integration-test

This will download Tomcat from the web, install Tomcat server, deploy our web application onto the server, open Firefox and IE browsers and test drives the web application on the browsers. The screenshots from these would be generated in the functest/target/screenshots directory.

Acknowledgements: This technique was inspired by a forum post by Dan Fabulich.

Update: I fixed a small bug in the instructions given to run the code bundle – thanks to davidm for pointing it out in the comments. I have also updated the code bundle with the URL pointing to a newer version of Tomcat. Some versions of Selenium have trouble launching some versions of Firefox. Hence, I have commented out the FireFox tests; instead the tests run on IE.

Well bowled, Shane!

With two Tests to play England has already lost the Ashes, but this piece of news will leave many positive that they have a great chance regaining the urn. Shane Warne, after enthralling spectators world-wide for 15 years, is leaving the game.

The other day me and my good friend Nanda were talking about Warne, and Nanda said:

He is 37, but I don’t think he will quit; nor is there is any sign of waning form to indicate dropping him either.

When one looks back at Warne’s career there are numerous highs on the field, and numerous lows off it. Though he had stepped down from ODI cricket long ago, the semi finals of 1996 and 1999 world cups are the most memorable performances.

Here is wishing Shane a great life ahead outside of cricket! I can’t wait to hear him in the commentary box! 🙂

PS: England really have a great a chance regaining the urn – rumours are abound that McGrath might be quitting too.

Comments in code

Jeff Atwood has written a good blog post on comments.

Code can only tell you how the program works; comments can tell you why it works. Try not to shortchange your fellow developers in either area.

Practitioners would have noticed these principles long ago; but this post would be a good reading for someone starting programing. Most programing books emphasise the importance of comments, but do not do a good job of explaining how comments should be written. The Practice of Programming has some good advice, but I don’t remember seeing much elsewhere.
The best readable code is the one that does not need any comments. The most useful comments are the ones that explain why the code was written the way it is.

Sree:1, Nell: 0

If you were busy on Sunday and missed it, here is Sreesanths dance after hitting Nell for a six over long off. I did not particularly admire Sree’s shot selection when we were 9 down and looking to increase the lead past 400; but hey, it was fun! Nell being on the recieving end makes it especially sweet; Nell has gone surprisingly unnoticed by every Match Refree out there despite him getting under the skin of every batsman he had bowled to. Pat Symcox noted on ESPN-Star commentary that Sree might not make much money playing cricket, and Harsha Bhogle cheekily replied that Nell seems to hold on to the money he makes from cricket, and there doesn’t seem to be much for Sree to worry about. Perfect! 🙂

Well said, Dravid

Heard this from Harsha Bhogle on telly:

“When we do good, we aren’t as good as they we say we are; when we do poorly, we aren’t as bad as they say we are” – Rahul Dravid

I could not find a reference to the original quote, but kudos to Dravid for daring to say this.