One of the constant challenges I have as a Java developer is keeping up with the numerous good FOSS dev tools. I no sooner start testing one tool and adapting my project to it, when a new one comes along. Being an analyst and naturally curious, this new product (or new release) represents a constant temptation. Is it better than what I am using? How much effort is required to try it out? What does it do better? On and on.
I can put a lot of those concerns to rest now. I just received a copy of Java Power Tools
from O'Reilly and it's exactly what I've been looking for. It contains deep explanations of the principal FOSS dev tools in 10 major categories. These explanations are not two- or four-page summaries, but in-depth expositions that provide crucial info on the strengths and weaknesses of the product. The author, John Smart, then provides detailed tutorial on using the product. It's clear he's spent lots of time exploring the dark corners of each tool. And he makes good use of that knowledge in his comparisons and comments on the products.If you want to spend an hour or so coming up to speed on what a product is about before installing it (and without having to work through the usually limited docs), this book will get you there faster and enable you get an overview of a whole lot of tools quickly and with the assurance you have a clear understanding. Here are the tools that are covered, followed by the number of pages for each one in parentheses:
BUILD TOOLS: Ant (55), Maven (60)
SCM: CVS (20), Subversion (78)
CI: Continuum (24p) Cruise Control (19) LuntBuild (32) Hudson (19)
IM: Openfire (12)
UNIT TESTING: JUnit (20) TestNG (25) Cobertura (17)
OTHER TESTING: StrutsTestCase (10) DbUnit (44p) JUnitPerf (10) JMeter (20) SoapUI (22) Selenium (30( Fest (9)
PROFILING: with Sun tools (16) with Eclipse (15)
DEFECT MANAGEMENT: Bugzilla (20) Trac (35)
QUALITY: Checkstyle (20) PMD (18p) FindBugs (12) Jupiter (18) Mylyn (14p)
All told, 856 pages of crisp, well-written explanations. A must-have reference for the bookshelf.
Hi Andrew: Thanks for the roundup on the Powertools book.
ReplyDeleteI thought you and your readers might like to know of a free Open Source Test Workshop that I will be giving next week.
I will be showing how to leverage open-source testing tools (Selenium, soapUI, PushToTest, TestGen4Web, HTMLUnit) for functional testing, load and performance testing, and business service monitoring, with more flexibility than traditional solutions provide.
The Workshop is free. Details are at http://workshop.pushtotest.com
-Frank
Hi Andrew
ReplyDeleteThis comment is not about the current posting and is not meant to open any heated discussion.
I am a frustrated old timer who's got his training on IBM/360 Assembler (yes, I know how to program in machine language and am very good at it), moved to the beasty PL/I and COBOL, and then to C, SQL and Perl (and I am pretty good in those as well.) However fast I move, paradigms are shifting underneath my feet posing a shaky ground. But this is not my complaint. I moved to Structured Programming and love it, I understand some of the benefits of OO programming, I may see the benefits of Unit Testing as you describe it even though it would be extreemely hard on me to adopt it (so I'd stick with Perl :-)
There are two issues that I do see:
one is the agile programming that seems to encourage coding before thinking... oh, we'll correct everything by refactoring. One cannot be serious encouraging that stupidity. One of the solutions I've heard that the extreme programming crowd is suggesting is that of pair programming... two expensive programmers would do a job that one cheap programmer in Bangaladesh may do for a fraction of the money. There are, of course two problems with that stuff, the first is obvious (money) and the second is encompassed in the question, you have two programmers sitting in the same cubicle for 8 hours, kibitzing each other, would you leave a kitchen knife in that cubicle?
The second issue that I have is the fanaticism of the OO crowd. Lately I had to create a UDF in SQL Server that would do some pattern matching, so I had to do these actions in VB.Net (but it would be the same in all OO languages):
Dim regexStr As String
..
regexStr = "\.[G]\d{4}V\d{2}$"
..
Dim reg_exp As New Regex(regexStr)
..
'and then, at long last -
If reg_exp.IsMatch(DSNAME) Then
'do something
This code would run any time I had to get into the UDF, some 4 million times of constructing and destroying an object. I know that there could be ways to persist (sic.) the object between calls if I create a container for my SQL and pass the object as parameter, adding yet another layer of complexity, but let me quote myself asking my OO mentor after comparing this to the Perl equivalent:
if (DSNAME =~ /\.[G]\d{4}V\d{2}$/
{
'do something
I asked: and your code is better then mine, how?!?
The proglem with fanatic OO is that it blures the line between compiled language vs. interpreted languag. I know in compile time that my pattern would be one and only, never changed, but there is no way in any OO language that I know to generate the object in compile time and never instatiate it in run time. Thus the compiled language (C++, C#, Java, Rubi at al) all become interpreted languages, while the interpreted Perl is far better compiled then thos.
If you want to make anythig and everything into an object as you preach, then you must allow for the option of instantiating unchanged objects in compile time.
ZA
Nice blog. Can I add your blog in my blog feed please? Thanks
ReplyDeletehttp://softwares-addiction.blogspot.com/