Incredible! This one word sums up Rafa's game in the Australian Open 2009 final. As Jim Courier put it "How is this guy even on his feet?". But on his feet he was and for more than 18 hours 54 minutes of playing time which included close to 10 hours in the last 48 hours of the Open.
Incredible athleticism combined with a die-hard must win attitude cracked Federer's normally impassive veneer to make him visibly nervous and suddenly the 14th major for the FedEx looked further away. Federer's first serve percentage kept dropping and the double faults crept up to hurt him at crucial junctures and when he hit one long after saving three championship points, he handed the Australian Open to Rafa.
While Rafa has been gracious enough to acknowledge Federer as the 'greatest ever', it now appears as if it will be Rafa who now has a realistic chance of completing a Grand Slam in 2009. Also, Rafa has now beaten Federer in their last five encounters. If Federer wants to confirm his place as the 'greatest ever' in history, he will have to break this wall down or stand by and witness Rafa's elevation to that epithet.
Monday, 2 February 2009
Sunday, 14 December 2008
In-Container testing with JUnit
Given the usefulness and success of a Test Driven Development(TDD) approach for developing (Java based) web applications, it is imperative that a developer chooses a good testing framework for writing unit tests. One such popular open-source test case framework is JUnit.
With JUnit 4.x, developer's can annotations to develop unit test cases. Annotations simplify the construction of test cases to a great extent leaving the developer to focus on writing the essential pieces of the testing logic. In an earlier post that included some test cases, I used the annotation @Test that took care of marking the method as a JUnit test case to be executed by the Test Runner. Thus, all that I needed to write was the assertion for testing the method. A short tutorial on learning the essential JUnit annotations is given here while a more detailed learner guide is available here and an excellent cheat sheat can be downloaded here.
While JUnit is basically a unit testing framework for stand alone Java applications, testing web applications is an entirely different cup of tea. Web applications run within an application server (such as JBOSS), while JUnit executes its test cases in a local JVM. Then how do you test thosein-containerMock Object based approach and the second is to use another testing framework that directly performs in-container testing.
For a Struts based web application, the MockObject approach can be implemented using StrutsTestCase class. Apart from the StrutsTestCase, there are several other available frameworks such as EasyMock that allow you to easily mock up objects. It should be noted that the Mock Object approach is not the same as in-container testing of components.
In-container testing can be carried out using one of the testing frameworks that extend JUnit and enable end-2-end testing of the web application. Cactus, HttpUnit and HtmlUnit are three such testing frameworks. It should be noted that Cactus and Http/HtmlUnit provide different facets to testing the server components. While Cactus focuses on testing server objects in the J2EE spec such as Servlets, EJBs and JSPs, Http/HtmlUnit frameworks emulate the browser behaviour. In other words these frameworks help you test the rendered view after an Http Request. The good news is that these frameworks can be integrated and working together can provide excellent test coverage.
For more reading on unit testing Struts based applications with these testing frameworks, check out this excellent book chapter.
With JUnit 4.x, developer's can annotations to develop unit test cases. Annotations simplify the construction of test cases to a great extent leaving the developer to focus on writing the essential pieces of the testing logic. In an earlier post that included some test cases, I used the annotation @Test that took care of marking the method as a JUnit test case to be executed by the Test Runner. Thus, all that I needed to write was the assertion for testing the method. A short tutorial on learning the essential JUnit annotations is given here while a more detailed learner guide is available here and an excellent cheat sheat can be downloaded here.
While JUnit is basically a unit testing framework for stand alone Java applications, testing web applications is an entirely different cup of tea. Web applications run within an application server (such as JBOSS), while JUnit executes its test cases in a local JVM. Then how do you test thosein-containerMock Object based approach and the second is to use another testing framework that directly performs in-container testing.
For a Struts based web application, the MockObject approach can be implemented using StrutsTestCase class. Apart from the StrutsTestCase, there are several other available frameworks such as EasyMock that allow you to easily mock up objects. It should be noted that the Mock Object approach is not the same as in-container testing of components.
In-container testing can be carried out using one of the testing frameworks that extend JUnit and enable end-2-end testing of the web application. Cactus, HttpUnit and HtmlUnit are three such testing frameworks. It should be noted that Cactus and Http/HtmlUnit provide different facets to testing the server components. While Cactus focuses on testing server objects in the J2EE spec such as Servlets, EJBs and JSPs, Http/HtmlUnit frameworks emulate the browser behaviour. In other words these frameworks help you test the rendered view after an Http Request. The good news is that these frameworks can be integrated and working together can provide excellent test coverage.
For more reading on unit testing Struts based applications with these testing frameworks, check out this excellent book chapter.
Saturday, 13 December 2008
Banishing the Vundo Trojan
If your browsers have started playing up and are opening up new tabs whenever you Google something and these new tabs in turn are redirecting themselves to random sites that you in your normal sense would never visit then chances are high that you are a host to the Vundo Trojan. While the infection appears to stem from a vulnerability in Java 1.5.0_7, I found the infection on a system that was running a much more advanced version (of Java) and so it is highly probable that a new loophole is being exploited.
On the infected machine, Vundo was able to infect and control the behaviour of Firefox, IE and Chrome. An annoying symptom of the infection was random popups and new windows that redirected themselves to mad-search.com(?) and forcibly tried to install AntiVirus 360 (what's that??) on the machine. The key diagnostic tool that was able to catch these infections was PC Tool's SpyDoctor but since the FREE version only performed a scan and required a paid version for the removal, I tried MalwareByte's Anti Malware version 1.31. This tool successfully located and removed the infections. So if you are facing the same problem, head down to MalwareByte and try out the tool but be aware that the tool only locates and fixes existing infections. To guard against getting infected, keep your SpyDoctor's IntelliGuard setting ON.
On the infected machine, Vundo was able to infect and control the behaviour of Firefox, IE and Chrome. An annoying symptom of the infection was random popups and new windows that redirected themselves to mad-search.com(?) and forcibly tried to install AntiVirus 360 (what's that??) on the machine. The key diagnostic tool that was able to catch these infections was PC Tool's SpyDoctor but since the FREE version only performed a scan and required a paid version for the removal, I tried MalwareByte's Anti Malware version 1.31. This tool successfully located and removed the infections. So if you are facing the same problem, head down to MalwareByte and try out the tool but be aware that the tool only locates and fixes existing infections. To guard against getting infected, keep your SpyDoctor's IntelliGuard setting ON.
Thursday, 27 November 2008
Open source systems that are not really OPEN
Recently while evaluating Concourse's CRM product, Concursive for a proposed implementation, we nearly got taken in with Concourse's claim of the product being open-source. According to them, the product was "An open source Java-based application.." but on downloading it, the accompanying license stipulates quite clearly "You may not redistribute the code". Fine!! If I cannot redistribute the code, how can I deliver a solution built around it. Also, if I could not deliver the solution why would I want to waste a month or so trawling through and understanding the million lines or so lines of code before I can modify it to meet my ends.
I can understand the company wanting to hang onto its IP and earning some revenue by "selling" the license but why term the product open-source? Just because I can view or modify the code for my internal use, its of no use to me.
According to the Open-Source Initiative , the Open-Source definition includes the right to freely-distribute the source code . This is the essential spirit of open-source software and should be adhered to when sticking the open-source label on a product. Misusing the term will only annoy developers and earn the product a 'do not use' label.
I can understand the company wanting to hang onto its IP and earning some revenue by "selling" the license but why term the product open-source? Just because I can view or modify the code for my internal use, its of no use to me.
According to the Open-Source Initiative , the Open-Source definition includes the right to freely-distribute the source code . This is the essential spirit of open-source software and should be adhered to when sticking the open-source label on a product. Misusing the term will only annoy developers and earn the product a 'do not use' label.
Subscribe to:
Posts (Atom)