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.

Testing

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.”

Communication

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.”

Teamwork

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!

Undefined behavior means that anything can happen, because the compiler is under no constraints.   The traditional formulation is that undefined behavior can make demons fly out your nose.  In practice the consequences are usually less dramatic.

If demons ever fly out your nose, you’ll know you have a bug.  You can track it down and fix it.  More insidious is undefined behavior that happens to be exactly what you want.

I ran across an example as I was preparing to port some code from HP-UX to Linux.  The program was freeing a linked list, using code similar to the following:

Node * curr_node = first_node;

while( curr_node )

{

free( curr_node );

curr_node = curr_node->next;

}

To a long-time C coder, this code immediately looks fishy, because the loop has only two statements in it.  Look a little closer.  The second statement in the loop tries to access memory through a pointer that has already been freed.  It invokes undefined behavior.

This program has been running for years with no obvious ill effects from this bug.  Apparently HP-UX isn’t very persnickety about accessing previously freed memory.  That’s legal.  “Anything can happen” includes “what you want.”

When I first saw this code, I wasn’t ready to port the entire program to Linux yet, but I could experiment.  I dashed off a little test program that built a linked list and then freed it, using the logic shown above.  Under HP-UX this program ran to completion without incident.  Under Linux, the same program stopped abruptly in the first iteration.  It didn’t issue any messages, dump core, or even leave a non-zero condition code; it just stopped cold.  That’s legal too.  Anything can happen.

I don’t know whether this difference is attributable to the operating systems, the compilers, the libraries, or the machine architectures.  I don’t care.  What matters is that I can’t run this program under Linux without fixing the loop:

Node * curr_node = first_node;

while( curr_node )

{

Node * temp = curr_node->next;

free( curr_node );

curr_node = temp;

}

A few days later, another example of undefined behavior popped up, in the form of a buffer overflow.  Under HP-UX the overflow had no visible effect, at least not until I started poking around with printf statements.  Under Linux the code just didn’t work.  Probably the variables are arranged differently in memory.  In HP-UX the overflow didn’t damage anything that mattered, and in Linux it did.

These examples are just things that I stumbled across.  There will be more, and I won’t catch them all so painlessly.  Fancy code analyzers may help catch things in advance, but there is no substitute for vigilance.

It’s tempting to conclude that HP-UX is more forgiving of blunders than Linux is, since some things work in HP-UX but don’t work in Linux.  That conclusion is premature.  Maybe the two platforms are just forgiving about different things.  If the bugs had done obvious damage under HP-UX they would have been fixed already.

There’s a Darwinian process at work here.  Bugs survive when they’re well adapted to the environment.  When the environment changes, some of those bugs will go extinct.  Unfortunately, new species will probably replace them.

    <script type="text/javascript">
        $(document).ready(function() {
            //
            // Moves the debug window to the left instead of the right.
            //
            // Needs to use setTimeout so that the wicket-ajax-debug.js
            // script has a chance to create the link
            //
            if(wicketAjaxDebugEnable)
            {
                setTimeout(function() {
                    $("#wicketDebugLink").css('left', '10px');
                }, 1000);
            }
        });
    </script>

Unidevannounces its search for Microsoft Partners in North America, Asia and Europe to implement their global web content management (CMS) system, Auctori™. As a 16 year Certified Microsoft Partner, we are looking to leverage the Microsoft Partner Channel Builder to deepen our services and solutions to more complex business opportunities, to provide a broader range of client services and to create business relationships with other partners whose skills complement our own.

“The Microsoft Partner Channel Builder is one of the key sales enablement benefits of our Microsoft relationship, and is an excellent way to combine our expertise and resources. We are looking forward to connecting with industry partners to form new alliances and deliver the end-to-end solutions that address customers’ business needs,” said Greg Alexander, CEO, Unidev. “This tool, with its two-way model, is making Microsoft Partner communications much easier.”

Auctori, a .Net SaaS CMS Platform, was developed by Unidev for multi-national companies, and currently supports a number of European, North American and Asian sites. This system supports multi-lingual site management and site deployment. Auctori was built from the ground up in conjunction with a team of search engine optimization (SEO) specialist to implement best SEO practices. The next release of Auctori is scheduled for the first quarter of 2010, and will feature European and Asian hosting in addition to its current North American hosting, with all sites and platforms managed from a single console.

For further information on Unidev or Auctori, contact Steve Thomas at 636-532-4424 or steve.thomas@unidev.com.

Read the full press release

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

Auctori:law Provides Turn-Key Web Solution for the Legal Industry

Unidev® is proud to announce Auctori:law™, a Microsoft Certified Web Content Management System (WCMS), designed specifically for law firms, will launch on October 15, 2009. Unidev designed the WCMS in association with several law firms to give attorneys and legal professionals an easy to use, but powerful system to update and maintain their professionally designed website.
�
Web-based Auctori:law gives attorneys the power to dynamically update their site from anywhere in the world, at anytime.  With Auctori:law, it is simple to build and edit website content without the help of a professional or having had previous experience or knowledge in HTML. By simply logging into a site through a secure, password-protected portal, site administrators can update content, change images, add keywords and make other instantaneous changes to their websites.

Auctori:law is a Software as a Service (SaaS) solution providing all of the benefits of cloud computing. Unidev’s solution provides firms with the opportunity to strengthen their Internet presence and their overall brand reputation by giving lawyers a professionally designed site and the power to maintain their content in real time. In addition to standard content management features, Auctori:law is equipped with an attorney biographies module, news and articles module, and an images module. Auctori:law adheres to all Search Engine Optimization best practices in order to maximize website traffic and usability.

“While I have worked in database driven content management programs in the past, I continue to be impressed by the level of sophistication and ease of use of the WCMS as built by Unidev for our law firm. Through Unidev’s WCMS I am not only able to freely edit content throughout our site, I am now in charge of navigation items and graphics, previously outside the realm of my editing parameters,” said Kelly Annis, Client Relations Manager for The Stolar Partnership, LLP.
 

A Few Unique features of Auctori:Law  include:
• Attorney and professional biography builder with profile photos, dynamic V-card generation, customizable fields, and professional PDF printing functionality
• Flexible content pages and navigation structure for creating practice areas and industry sections
• News and articles module to create and archive publications, resources and events.
• Multi-lingual
• Print-ready PDF documents
• Secured document libraries

-To see two excellent examples of Auctori:law in action, please visit The Stolar Partnership, LLP at http://www.stolarlaw.com and Paul J. Passanante, PC & Associates at http://www.passanantelaw.com.

“We are very excited about the launch of Auctori:law,” said Greg Alexander, CEO of Unidev. “Our team is very experienced in developing customized legal websites.  We developed this WCMS designed specifically for the legal industry based upon this experience.  Auctori:law presented itself as an excellent opportunity for our clients to really take control of their websites with an application that truly answers the needs of a legal firm.  I am confident that Auctori:law is a complete solution for any law firm’s online needs.”

Put the Power into Your Hands Today …

Contact Auctori:Law  for further information and for a free Auctori:Law™ demonstration!  Call us at: 888.629.4672 or email us at: demo@Auctori.com.

• The Web Service Extension needs to point to %WINDIR%\SysWOW64\inetsrv\fcgiext.dll.
• The .php extension on the website also needs to point to %WINDIR%\SysWOW64\inetsrv\fcgiext.dll.
• The fcgiext.ini file must also be located in %WINDIR%\SysWOW64\inetsrv.  Otherwise you will get a 500 error from FastCGI saying it cannot find the configuration file.

Note that the fcgiconfig.js script is only installed in %WINDIR%\system32\inetsrv.  I was able to create a fcgiconfigwow64.js file that points to the correct files.  The script needs to have at least an ini file with the “[Types]” section in the %WINDIR%\SysWOW64\inetsrv directory.  It also needs to be located under %WINDIR%\system32 as it doesn’t support running under Wow64.  You just need to change the following 2 lines near the top of the script.

From:

var g_iniPath       = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\system32\\inetsrv\\fcgiext.ini" );
var g_extensionPath = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\system32\\inetsrv\\fcgiext.dll" );

To:

var g_iniPath       = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\SysWOW64\\inetsrv\\fcgiext.ini" );
var g_extensionPath = g_Shell.ExpandEnvironmentStrings( "%WinDir%\\SysWOW64\\inetsrv\\fcgiext.dll" );

In most cases, a web design or software development company will have some standard code libraries that they utilize for each project. This is a good thing in that it allows you to get more function usually at a lower cost and faster than developing everything just for you. These libraries could have been developed over a long time across a large number of customers. To replicate them from scratch could cost more than your entire project. The potential issue that you need to resolve in your contract is how do those common libraries affect your ability to upgrade long term. Web server platforms, operating systems and technologies are constantly changing. Are those libraries continually updated to the latest versions? What happens if the vendor goes out of business or decides to no longer support those libraries? What happens if you want to change vendors? At a minimum, you should consider software escrow with a trusted third party from whom you will be able to get the source code if your current vendor goes out of business or no longer supports the software.

Also, you should consult your lawyer about the ownership of the code and content being developed for your site. If you are having work done overseas, then you should understand that any enforcement of your intellectual property rights or ownership of the source code is going to be difficult at best. Trying to prevent a foreign entity from divulging or reusing your proprietary information would be an expensive and difficult effort.

If you are have enhancements or modifications done to your software, make sure you have the very latest source code when it is complete. The software developer may or may not keep good track of small modifications made to your programs. It is critical that you or your vendor have the ability to rebuild your site at any time from scratch and that you have some legal recourse to obtain all of the source code if the vendor ceases business. I would also try to get the source code if the business unit you worked with is sold. The new owner may have different ideas about how/if you are supported.

In summary, you need to really understand exactly what you are buying and consider what options you have going forward. Without source code (and/or the legal right to it), you will have limited options if your vendor goes out of business, he decides to abandon the software, you have a falling out with the vendor or you wish to change vendors.