June Issue of NFJS, the Magazine published.

Here’s what is in this month’s NFJS, the Magazine

Kenneth Kousen – Spock: I Have Been, & Always Shall Be, Your Friendly Testing Framework

The Spock testing framework is clean, elegant, and very easy to use. In this article, many of the capabilities of the Spock framework are demonstrated, from basic tests to mock objects.

Johnny Wey – WebSockets: Bidirectional Communication Over TCP

Ever wanted to send push messages directly from a server to a client? Support real-time messages between multiple clients? Create fast-paced games running in a browser? With WebSockets, these things are not only possible but surprisingly easy.

James Carr – High Powered Messaging with RabbitMQ

In the May,2011 issue, Mark Richards explained the differences between JMS and AMQP and why we should be excited about AMQP. In this article I am going to follow up by taking a very in depth look at one of the popular AMQP broker implementations, RabbitMQ. I’ll cover setting it up, describe some of the interesting plugins, briefly cover some common messaging patterns that are useful to implement and finally setup a simple publish-and-subscribe channel between two different applications

Dave Klein – GORM: Object Persistence Done Right

Object persistence has always been a thorn in the side of developers of object-oriented software. Our software works with objects but our data is stored in records. There is, thus, an impedance mismatch that our industry has spent enormous resources trying to overcome. Some have been driven to such depths of desperation that they have come up with things like EJB Entity Beans. Tools such as Hibernate bring improvements, but persistence is still one of the most difficult layers of an application –unless you are using Grails. Grails’ Object Relational Mapping makes developing the persistence layer of a web application simple, straightforward, and fun.

I’m very proud of the work we do on this new magazine. The staff and I have worked hard to produce a top-notch magazine that is unique in the realm of software development magazines. The magazine costs $50 per year, which includes 10 issues. Each issue has at least four articles. You can download in a print-quality PDF and two mobile formats: EPUB (for the Nook and iPad) and MOBI (for the Kindle). The articles are professionally edited and are written by top experts in their field, so the content is worth well more than the $50 you pay.

The June issue just published this morning and you can subscribe here: http://bit.ly/fETp6d. As always, if you have questions just comment on this post and I’ll respond quickly.

COJUG Presentation: Unit Testing Case Study

On May 11th, 2010 I presented at the lunch and dinner Columbus Java Users Group meetings.  The talk was a case study of how the development team I’m on at Ohio Mutual Insurance Group got started with unit testing our legacy JEE system.  The main idea behind the presentation was to illustrate the hurdles the team had after deciding to write unit tests against our existing code base.  Using code, both live and test, I demonstrated some of the conundrums that gave us excuses to not write tests.  For each stumbling block I showed the technique that we used to finally just write the tests.  I started with some basic examples and finished with a more complex example that required mock objects to resolve.

Thanks to the attendees at the presentations.  There were many great questions, comments, and suggestions.  I thoroughly enjoyed myself and learned from everyone I interacted with.

From the reaction I received at the COJUG meetings I realize that my team is not alone in our experience.  Over the next few weeks I will be blogging on the “excuses” we had for not testing right away.  I’ll explore the issue more thoroughly than I was able to in the COJUG presentation by walking through one problem at a time.  Stay tuned and leave comments!

Programming under the Scientific Method?

Just as a good blog should be, here are some loose thoughts on programming that I’ve had lately.  I have spent some time thinking about my process for writing code.  In fact, I’ve been thinking about what I have been able to glean so far about the process that the mass of programmers in the world go through to write software.  The impression that I have is that writing software is not scientific enough.

The germ of this idea is that I’ve never felt that I could quantitatively prove that the way I write code actually produces a working, correct result.  This was before I really understood the idea of unit testing.  I started going to conferences and working on a Masters Degree in Computer Science and began to learn about the idea of unit testing.  Only at first, I thought that unit testing was the answer to qualitatively proving that my code was working and correct.  Unit testing certainly appears to be the answer because of its emphasis on incrementally proving that the code is correct as per the rigor of each test.  Yet, after about a year of actually working with unit testing I’m starting to question the true strength that unit testing provides.

There is no doubt that unit testing provides rigor around the software development process — theoretically.  At any software development conference there is no shortage of unit testing pundits who espouse the benefits of the practice and explain the process for incorporating testing into your development process.  And attending these conferences is largely a group of people whom have no doubt that unit testing is an honorable practice.  Practically though, the test is usually only as strong as the will of the programmer to write a good test.  The example being that I can write very poor unit tests for every unit either because I misunderstand the process or because I don’t care enough to write good tests.  Neither is helpful in providing evidence of working and correct code.  Further, even though the discipline of good unit testing can provide some proof that code is working and correct, there is almost no proof (I have only heard anectdotes) that starting the practice of unit testing actually changes the quality of software.

The failed panacea of unit testing for providing quantitative proof of working and correct code lead me to think about why it didn’t really solve the problem.  Eventually the Scientific Method came to mind.  When that happened I wondered why we don’t talk about the software development process in the context of such a solid framework?  The Scientific Method works for all other sciences, why shouldn’t it apply to Computer Science?

So, finally, here is the main thought in this post.  I believe that at least understanding the Scientific Method may improve the process of software development .  In this post I won’t explain the Scientific Method or talk about how it applies to software engineering in a practical sense, instead, I’ll only mention that thought and leave it for you to ponder.

I think that the reality is that writing working and correct software is a grand challenge and requires rigor if it’s ever to become a standard.  Great ideas such as unit testing (and its accompanying process Test Driven Development) undeniably add to the rigor or software development but fail to make a complete process for developing working and correct software.  I’m curious to know if thinking about software development in terms of the Scientific Method would help bridge the gap between writing code and unit testing to make a cohesive process that can be analyzed and proven quantitatively.

…

There are a lot of scattered thoughts here that are either leaving gaping holes or need expansive exploration to fully explain.  I understand that and I hope that myself or others can fill in those gaps.  I’m immensely interested in exploring this idea and discovering where it leads.