Posts Tagged ‘java development’

What Makes a Good Developer?

What Makes A Developer from Here at Unidev we pride ourselves on the diverse skills and years of experience our development teams bring to their projects. Whether it’s custom software design or mobile application development, our developers have what it takes to provide innovative and elegant solutions to our clients.

But what exactly makes a great developer? Are there certain traits, skills or habits a successful developer needs? Well, we asked the talented members of the Java, .Net, and mobile development teams at Unidev to find out.


Of course, a great developer tests her code thoroughly to ensure it performs just as the client expects. Christine of the Unidev West development team in Las Vegas submitted the mantra, “testing, testing, testing” to highlight its importance. This element is essential in delivering high-quality code with confidence.

But testing isn’t simply a phase at the end of a project; it’s a mentality integral to the entire development process. We couldn’t say it any better than one of Unidev’s talented developers, Teresa:

“Besides having some test cases before he starts coding, [a great developer] is also thinking of test cases as he goes, so he can try to break his code in the testing phase. Oh yeah, and he tests his stuff- thoroughly.”


This development skill may not seem as obvious as technical skills or problem solving abilities, but it is extremely important nonetheless. Great code cannot simply exist in a vacuum, it needs to comply with client needs and function properly with code from other developers.

Strong communication skills reduce errors and can catch minor problems and miscommunications before they become major headaches. Kevin from our development team in St. Louis puts it best:

“A good developer must be a good communicator. He must be able to understand a client’s needs and then be able to respond with useful solutions. He must also be able to explain his development strategy to co-workers.”


Another intangible skill a great developer must possess is teamwork. Successful development may rely heavily on individual abilities, but without positive interactions between other team members, things can fall apart quickly. Brian, another member of our development team in St. Louis, shares his thoughts:

“Although development is largely an individual activity, ultimately the efforts of all the individuals on the team are combined to make the final program, product, or website. If a developer cannot handle the teamwork aspect, he/she will likely be limited to projects where his or her efforts will not adversely affect the larger team.”

These are just a few aspects that the Unidev team thought distinguished a “competent developer” from a “great developer”. Do you agree or disagree? Tell us what you think makes a great developer in the comments below!


Wicket Ramblings

Several months ago, I was assigned the task of developing a web application for a Fortune 500 company.  The specific purpose of the application was to allow certain transportation providers to submit claims directly, something they had previously been doing though e-mail.  Once submitted, a provider would then be notified with regards to status changes in their claim as it made its way through the company’s revenue system.  A provider could then re-log back into the web application to review the particulars of that change.

What made the assignment notable from others was the fact this company had recently set architectural guidelines restricting new web application development to use only the Wicket framework.  As some of you already know, Wicket is component based framework competing in the same space as JavaServer Faces (JSF) and Tapestry.  Having never worked with Tapestry before, I did have prior experience with JSF.  I had been on two previous projects using Apache’s MyFaces, and by the end of my second project, I had some real reservations about recommending JSF as a web application framework.  If I had to sum it up at the time, JSF just seemed inconsistent when predicting how you would think it would behave.  There were occasions where if you did two similar things in different parts of your application, they wouldn’t necessarily behave similarly. One would be slightly off kilter, requiring you to make tweaks to your code that weren’t required in the other spot to get the same sort of operation.  I’ll be first to admit, this might have been in large part due to the third-party JSF components that were purchased for the latter project.  So it was with some apprehension that I started this project with yet another component based framework.

Now that I’m near the completion of that project, I’m happy to say that Wicket as a component based framework pretty much flat out works.  It may not be perfect, and I believe there aren’t any, but compared to some other offerings, it works.  So I thought I share a few top level concepts that I think are core to evaluating and understanding this framework.

But before I begin, learning a component based framework can be daunting, especially if your background is only one of the classical request-response frameworks, like Struts or Spring MVC.  It can represent a significant paradigm shift in how you solve the problems at hand.  So to help you in that process, I recommend reading the Manning’s publication ‘Wicket in Action’.  It’s authored by two of the framework’s committers, so without doubt you can consider them to be experts on the subject.  The material they present is done in such a manner so as to keep building on previous concepts, such that you never have the feeling you missed a turn somewhere.  By the end of the book you should have a reasonably good understanding of the framework to tackle a moderately complex web application, assuming of course you have previous experience.  I say moderately complex, because the book won’t explain how to use some of the more advanced Wicket components, like data grids and accordions that so many web applications are now expected to have.  That unfortunately, you’ll have to do that on your own – but hey, you gotta start somewhere.

Now on to some key observations.  When learning Wicket, the first thing you’re going to have to understand is models. Without understanding models, you’re never going to get anywhere.  Models are the glue between the components and the objects containing the information your app is expected to use.  Simply put, they are placeholders that you share with the component.  It allows you, the developer, to even change the data object with a different instance while keeping the component completely oblivious.  Wicket has several different models, but of all of them, knowing when to use the LoadableDetachableModel is important.  Here’s why.

One of Wicket’s key features is its solution to one of the ‘Holy Grails’ of web applications – built-in support for the back button.  It does so by serializing each and every page, which basically means the components and the models they reference, to a Wicket abstraction called a PageMap. PageMaps themselves can be written to disk, so as to limit the amount of HTTP session being used.  When you hit the back button all that you’re really doing is restoring that page’s state as previously captured in the PageMap.  Sounds expensive, but it’s not nearly as bad as it could be if you are using a LoadableDetachableModel.  What a LoadableDetachableModel will allow you to do is control what gets serialized.  So what if your model references an entity, which is typically a row in a database.  Then it makes sense that all you would want to do is serialize the primary key.  Why?  Well like most component based frameworks, Wicket has several distinct phases it goes through with each request – response cycle.  At the end of a response, Wicket will call the detach method on all components using a LoadableDetachableModel.  This will set your entity object in the model to null before things get serialized.  Then at the start of the next request, when the component requests the entity, it will get restored.  How?  Well the LoadableDetachableModel sees that the entity is still null, so it calls a method that you supplied called ‘load’.  Of course by now the primary key you had previously stored is already deserialized.  All you have to do is get the entity back from the database before Wicket does anything to it, like binding new values posted from the browser.  Pretty slick!

All web applications are expected to do Ajax these days, and Wicket does not disappoint.  It has a well integrated Ajax framework that’s easy to use and easy to control.  It’s as simple as using an ‘Ajaxified’ component, or adding an Ajax behavior to a component that isn’t to initiate an Ajax request.   Then all you have to do is decide what components should be updated as a result of receiving the request.  Let me give an example.  In the web app I built for my client, there was need to allow the user to search for current and previous claims.  The business owners wanted to supply two distinct methods of searching, by allowing the user to either fill out one set of fields and search, or fill out the other set and search.  To make the user interface less confusing, I decided to use a dropdown with a simple description of each of the search methods.  I also encapsulated the fields associated with each of the searches into a Panel. A Panel is nothing more than a component that can act as a container for other components.  But more important is that you can also associate with the panel its own html fragment for displaying what’s in it, the search fields in this case.   And a Panel can also provide the necessary validation and business logic that may be required for those fields.  This really makes it nice when you want to reuse them throughout your application. But here’s how the rest of the design unfolds.

I used a DropDownChoice component, and as you can probably already guess, it was used to represent my dropdown.  Because this component isn’t inherently ‘Ajaxified’, some are and some aren’t, I had to add an AaxFormComponentUpdatingBehavior to instruct the component to make an Ajax request with each ‘onchange’ event of the dropdown.  Behaviors, like models, is something else you will need to know.  They are often used to add new capabilities to a component – like Ajax.  Anyway when the search page is initially displayed, only one search panel is shown.  When the user doesn’t want that one, he makes a new selection in the dropdown.  This creates an Ajax request where it will be received back at the behavior’s handler on the server.  All I had to do at this point inside the handler was determine the new state of the dropdown, select the appropriate panel to be shown, and tell Wicket to render this one and not the other.  When it was all said and done, the panel swapping amounted to just a few lines of code.  All of the nitty-gritty update details and Ajax plumbing was handled by the framework.  Sweet!!

I have just one last thing I’d like to mention about Wicket, and that’s its excellent templating and page layout features.  What makes Wicket different is how you associate your page’s HTML with the java code.  It’s through the class hierarchy.  So wherever you create a class to be used as the code for the page, you also create an HTML file in the same package with the same class name, but instead with a ‘html’ file extension.  So whenever your class gets instantiated by the framework, it also knows if there is an html file with same class name, then this is the HTML to be used.

Big deal, right?  Well read on a little further.  What the Wicket folks have cleverly done is not only load the html with this class, but any html associated with any of the classes up the hierarchy, basically allowing you to nest the html that is lower in the hierarchy into the html that is higher.  All through the use of the Wicket tags <wicket:extend> and <wicket:child>.  So how do you use this to your advantage?

Well like working with other web frameworks, you generally create a base class that serves as an extension point for the rest of your classes, and with Wicket WebPage it is no different.  But what you’ll want to do with this base class is also create an html file with the same name that defines the overall look and feel of your web pages.  It may display the application’s title at the top, maybe a place to put menus to the left, etc.  This page will basically act as your application’s template.  Any class that extends this base class and provides its own html can place it inside of this template.  Cool!  Gone are the days of all those nasty Tiles’ definitions.  As a matter of fact, throughout the entire development of my app did I ever once have to create a single XML file for Wicket!  I just followed the conventions and things worked.

If your thinking about venturing into the realm of component based frameworks and you have been searching around, please give Wicket some serious consideration.  It may not be easy at first, but I think once you get over the hump you’ll learn to appreciate what it can do for you.

By: Mark Raterman

Bind XML message to Java objects using JiBX – JiBX binding tutorial

JiBX binding tutorial

 Companies are moving more and more towards service oriented architecture (SOA) and SOA services communicate with well formatted XML message. If you are working in an SOA Java environment one of your development goal is to bind XML message to Java objects. Jibx is a great open source tool for binding XML data to Java objects. Two main components of Jibx are Binding compiler and Binding runtime. Binding Compiler use binding definition document to specify how Java objects are converted to or from XML. Binding compiler can be linked to your Ant build script and executing the build script does bytecode enhancements on already compiled java classes. Enhanced class files generated by Binding Compiler user Binding Runtime to build objects from XML document and vice versa.

 This is a code block from my ant build script that executes jibx binding compiler on complied java classes. Order-Request.xml and Order-Reply.xml are the binding definition documents  i have used for XML messages of a request reply messaging pattern.


<pathelement location=”${basedir}/lib/lib/jibx-run.jar”/>

<pathelement location=”${basedir}/lib/jibx-bind.jar”/>


<target depends=”compile” description=”Run Binding Compiler on compiled java class”>

<echo message=”Running binding compiler…”/>

<java classname=”org.jibx.binding.Compile” fork=”yes” classpathref=”binding-classpath” failonerror=”true”>


<pathelement location=”${project.classes.dir}”/>


<arg value=”${project.classes.dir}/com/dj/bookorder/Order-Request.xml”/>

<arg value=”${project.classes.dir}/com/dj/bookorder/Order-Reply.xml”/>      



Runtime uses Jibx BindngFactory to construct Marshalling and Unmarshalling contexts , which can be used to convert XML message to Java object or vice versa. Jibx BindingFactory is obtained by passing any of the classes defined by the mapping in your binding definition document using methods defined in the Jibx BindingDirectory class.

 Unmarshalling example:

 public BookOrder getUnMarshalledBookOrderRequest(String xmlMsg)throws Exception{

        BookOrder bookOrder = null;

        IBindingFactory bfact = BindingDirectory.getFactory(BookOrder.class);

        IUnmarshallingContext uctx = bfact.createUnmarshallingContext();

        Object obj = uctx.unmarshalDocument( new ByteArrayInputStream(xmlMsg.getBytes()), null);

        if(obj instanceof BookOrder)bookOrder =(BookOrder)obj;

        return bookOrder;


Marshalling example:

 public String getMarshalledBookOrderReply(Object obj)throws Exception{

        IBindingFactory bfact = BindingDirectory.getFactory(BookOrderReply.class);

        IMarshallingContext mctx = bfact.createMarshallingContext();

        StringWriter writer = new StringWriter();



        return writer.toString();


 Jibx Binding Definition: Jibx Binding definition document is the core part of using Jibx and let’s see how do we write binding definition document for the following XML.

 <?xml version=”1.0″ encoding=”UTF-8″?>





            <book-name>Cooking for Dummies</book-name>











                        <address>200 Links Dr</address>

                <city>Dardenne Prairie</city>








            <book-name>Art for Dummies</book-name>










                        <address>200 Links Dr</address>

                <city>Dardenne Prairie</city>








 Following is the binding definition I am using for the above XML. We will come to the elements in a while.

 <binding package=””>


            <collection field=”bookList” usage=”optional”>

                        <structure  flexible=”true” ordered=”false”>

                                                <value field=”isbn”/>

                                                <value field=”bookName”/>

                                                <value field=”orderDate” deserializer=””/>

                                                <value field=”orderAmount”/>

                                                <value field=”shippingDate” deserializer=””/>

                                                <structure field=”paymentType”/>

                                                <structure field=”billingAddress”/>




 <mapping choice=”true” ordered=”false”>

            <structure field=”cardPayment”  usage=”optional”/>

            <structure field=”checkPayment”  usage=”optional”/>



<value field=”authCode” />

<value field=”expireDate”  deserializer=””/>



<value field=”checkNumber” />



<value field=”address” />

 <value field=”city” />

 <value field=”state” />

<value field=”zipCode” /

<value field=”country” />



Given below is the reply xml message and binding definition

 Reply xml message:


Binding definition for reply message:

<binding package=””>


<value  field=”orderProcessDate” serializer=””/>



 Jibx binding definition  elements:

<binding> element: This element is the root of a binding definition document and defines characteristics of the whole definition document.

<mapping> element: Mapping element defines the binding used for every objects within the context.

<collection> element: Collection element defines binding for a Java collection. In the example XML <book-order> can have any number of <book> elements inside a <books> element. In the binding definition document <books> element is bound to a java collection bookList.

<structure> element: This element can take various forms. One is where the structure is an xml element which is linked to an object property of a containing  object. In the example binding definition document , structure billing Address is mapped to <billing-address> element which is bound to BillingAddress property of containing object Book. Another variation is where <structure> element is linked to an object of a  collection. In the example book structure is linked to Book object of books collection.

 Custom serializer and deserializer:

For more control over JiBX binding behavior you can write custom serializer and deserializer code for conversion. Given below code gives you flexibility of converting a date to any date format you like public class JibxHelper.

{ public static Date deserializeDate (String value) throws ParseException

{  return new SimpleDateFormat(“yyyyMMdd”).parse(value);  


public static String serializeDate(Date value) throws ParseException { 

return new SimpleDateFormat(“yyyyMMdd”).format(value);  



 Here is an example implementation of Jibx marshalling and unmarshalling

  // getBookRequest() get xml String message – This can be from the SOAP request , JMS message or from a file in your hard disk

                String xmlMsg = getBookRequest();

            MessageUtil util = new MessageUtil();

                //      getUnMarshalledBookOrderRequest method defenition is given at the section titled ‘Unmarshalling example:’ in this blog.

            BookOrder order = util.getUnMarshalledBookOrderRequest(xmlMsg);

            for(Iterator it=order.getBookList().iterator();it.hasNext();){



            BookOrderReply orderReply = new BookOrderReply();

            orderReply.setOrderProcessDate(new Date());

                //      getMarshalledBookOrderReply method defenition is given at the section titled ‘Marshalling example:’ in this blog.

            System.out.println(“Reply Message :”+util.getMarshalledBookOrderReply(orderReply));

 Above example parse an XML string , convert to Java object , iterate through a collection and print Book name. Also convertes object to an XML string as well, which can be passed as the reply to incoming request message. Example generates the given below out put.

Cooking for Dummies

Art for Dummies

Reply Message :<book-order-reply><process-date>20090917</process-date></book-order-reply>

Given below is Java object defenition of BookOrder and Book classes used in this example.

public class BookOrder implements


private ArrayList bookList = new ArrayList();

    // To Do – Add setter and getter methods


 public class Book implements


 private String isbn;

private String bookName;

private BillingAddress billingAddress;

private Date orderDate;

 private BigDecimal orderAmount;

private Date shippingDate;

private PaymentType paymentType;

// To Do – Add setter and getter methods


 Please refer for more information on Jibx.