Posted by ShriKant Vashishtha in the early morning: July 31st, 2009
Recently I got a chance to attend a 2 days architecture conference in Bangalore organized by iCMG. Some very experienced and renowned figures in software world took sessions on architecture and software development. It sounded like a conference on just software architecture but it catered various other topics which could be grouped under Software development in general. If we leave the question of whether the conference should have focused on architecture only, other topics were also quite good and relevant to software development.
Posted by Erwin van der Koogh mid-morning: July 27th, 2009
Over the years I have seen many attempts to increase software quality. Most of our clients try to increase software quality by introducing a quality process. It usually involves a combination of strict coding guidelines, code reviews, checklists, acceptance criteria based on things like PMD, Checkstyle and Findbugs and audits by external parties amongst others.
But what struck me a couple of weeks ago is that we, as Xebia, have little extensive formal quality process. That is, while we have do have a lot of best practices and we test and measure quality a lot, we never have to resort to ‘enforcing’ quality.
(more…)
Posted by Age Mooij in the late evening: July 25th, 2009
Earlier this week I ran into a missing feature in the Scala xml library and I ended up adding this feature myself, which turned out to be pretty simple.
I was trying to extract the text contents of an element in a piece of XML using the handy \ and \\ methods on scala.xml.NodeSeq. These methods allow you to extract sub-elements from an XML node in a way very similar to XPath, something like this:
val xml = <a><b><c>text</c></b></a> val c1 = xml \ "b" \ "c" val c2 = xml \\ "c" val text = c2.text
The problem I ran into occurred when I tried to use these methods to extract an element when one of its attributes had a certain value.
Posted by Arjan Blokzijl just before lunchtime: July 25th, 2009
I have read about implementing the bowling game XP-style many years ago in Robert Martin’s book ‘Agile Software Development’. The episode can be found online as well.
Recently he has recently been learning Clojure and attempted to implement the bowling game in Clojure.
It is a nice exercise, and although I like Clojure, I do not regard myself capable in any way to repeat such an attempt. Apart from that Stuart Halloway, author of the excellent ‘Programming in Clojure’ book, has already done this in a much better way than I ever could. I’m slightly more familiar with Scala, so I thought it would be a nice exercise to try some functional bowling using that. My Scala knowledge is in a deplorable state, stuck at pre-beginner level, so I run the risk of making a complete fool of myself. However I’ll take the chance and at least try to learn from the experience.
Posted by Jeroen Borgers at around evening time: July 22nd, 2009
Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.
Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.
At a popular web shop I had the following challenge: (more…)
Posted by Andrew Phillips in the early evening: July 21st, 2009
Recently, I was writing an Annotation Processor for the @Composite project. In good TDD fashion, that first and foremost meant writing some tests.
Although I in the end come across something that was fairly workable, it was trickier than one might have hoped for.
Posted by Arjan Blokzijl in the early afternoon: July 19th, 2009
The path on the road to learning Scala usually involves using the REPL. this is a very handy way of trying out functions you write easily and quickly, without having to set up an entire IDE environment. Scala’s latests stable release Scala 2.7.5. Scala 2.8 will be out in a couple of months, as things stand now. This new release will contain a number of enhancements and new features, and if you can’t wait to try this out, you should check out and use the trunk. I’ve previously blogged about starting with Scala, and also hinted at trying this out. In this blog, I’ll show some more concrete examples of the and a few neat things that you can do if you’re willing to take this step.
(more…)
Posted by Ravan Naidoo in the early morning: July 14th, 2009
Recently I had to get JAX-WS based webservices running on Weblogic 10.3. However instead of using the default Weblogic 10.3 stack (Metro), the Apache CXF stack had to be used. Why? We required SOAP over JMS capabilities and that is possible with CXF without much effort.
(more…)
Posted by Vincent Partington in the early evening: July 13th, 2009
The previous blog in the JPA implementation patterns series discussed different ways to test your JPA code. Figuring out how to test DAO’s and then being frustrated because the existing literature on JPA seemed to say very little on this subject, was actually the trigger for me to write these blogs. I have now come full circle, which means it’s time to wrap up the series. There’s lots more to write about, so keep following this blog! 
After discovering that there was a lack of documentation on how to use JPA in real-life scenario’s, I have written a series of blogs about the JPA implementation patterns I discovered while writing JPA code. To wrap up the series, I have made an overview of all the patterns that have been discussed for easy reference. The list is mostly in chronological order. I only changed the order slightly to make a distinction between the basic patterns and the advanced patterns.
(more…)
Posted by Vincent Partington around lunchtime: July 11th, 2009
In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.
What to test?
The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO’s). In theory your domain objects are not tied to JPA (they’re POJO’s, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting…
(more…)