Yesterday I installed the Oblique Strategies Linux screenlet on my laptop. A small black rectangle in the corner of the screen shows me one of these cards. Today, it says:

“Into the Impossible”

Huh… Ok, well, applying that to my current project, of course there is something that rings a bell. Across the board, software projects have a very low chance of success (only 32% of are considered successful according to the 2009 CHAOS report). Aside from the overall success rate, the project has some additional factors that make it hard: a fixed deadline, unknown and wildly varying scope, no clear handle on the architecture yet and the software developers to work on it still have to be found.

But it still isn’t impossible to successfully deliver software by the deadline, that contains features useful to the customer. I like to think of it as improbable. Now that’s something else altogether. If something is impossible, it can’t be done, no matter how hard you try. But if it’s merely improbable, then there is room for success.

Another way to look at it is to accept the premise that what you are trying to do really is impossible and list the reasons why. My project is impossible, because the deadline is completely unrealistic. Well, what if we have an extra month? What if we deliver a small increment first? What if we scale up another team? This may lead to ideas that can turn your project from impossible into merely improbable.

It’ll be interesting to see what other oblique strategies come up and whether they’ll be helpful.

The simplest way to customize the user experience is to put conditional behaviour in the web pages. This can be done using tags and EL. Seam helps in this respect because it makes all sorts of objects, including the current logged in use, available via EL. An example could be:

<c:if test="#{loggedInUser.userType eq 'C1'}" >
  <h1>Welcome, C1 user!</h1>
</c:if>

Of course, this does mean that one page that has a lot of user-dependent variations will become riddled with these statements. If this is the case, a page-based approach is better. Using EL in Seam’s navigation configuration can do this. For example, the following fragment shows how to conditionally render a different version of a page:

	<page view-id="*">
		<navigation from-action="#{searchAction.findCompanies(companySearchCriteria)}">
			<rule if="#{loggedInUser.userType eq 'C1'}">
				<redirect view-id="/pages/search/SearchResultsC1.xhtml"/>
			</rule>
			<redirect view-id="/pages/search/searchResults.xhtml"/>
		</navigation>
	</page>

Finally, different users may require different implementations of backend services. For example, a particular class of user may only be allowed to see a subset of search results as compared to another class of user. One way to do this is to use EL to drive dependency injection. Given the dependency below:

	@In(value="#{serviceInjector.injectService('companyService')}")
	private CompanyService companyService;

a ServiceInjector class containing the following functionality:

@Name("serviceInjector")
public class ServiceInjector {
    @In
    private User loggedInUser;
    @In
    private WebAppContextService webAppContextService;
    public Object injectService(String param) {
    	Object result = webAppContextService.lookupBeanOrComponent(param + loggedInUser.getUserType());
    	if (result == null) {
    		result = webAppContextService.lookupBeanOrComponent(param);
    	}
    	return result;
    }
}

would attempt to inject a user-class specific service instance, falling back to the regular instance if one didn’t exist.

The attribute to base this choice on is not restricted to a simple enumeration. Since these are Java methods being invoked, all sorts of logic is possible, such as giving a user a preview of a particular piece of functionality but requiring him to subscribe after 10 uses or a temporary promotional campaign.

Looking through the code now, there are a lot of problems:

• no good separation of concerns (presentation logic is mixed with business logic)
• the Action classes contain basically all code in the system, except where delegated to a Helper or Util class
• lots of duplication of functionality, across JSP pages as well as Actions
• the JSP pages are 1000+ line beasts, equal parts markup and JavaScript code.

With a major functional change coming down the line, the time has come to re-imagine this application with today’s technology. I was asked to see what the application would look like when rebuilt using JSF and Seam. This blog post describes my experiences so far.

The application allows users to browse information in a highly configurable way — users can add widgets, place them where they like, configure which information is shown and how. In the current application, the pages with user-specific, highly variable data were built using standard JSP pages containing the framework of the page and JavaScript calls to fetch the user-specific parts. Seam and JSF support these concerns very well. Using JSF, the user-specific parts look like this:


<c:forEach var="widget" items="#{userPreferences.getWidgets()}">
<ui:include src="#{widget.pageName}"/>
</c:forEach>


By being able to use ui:include and provide it with an EL expression that resolves to the view to be included, the page becomes extremely dynamic.

The above piece of code does contain one tricky bit: the use of c:forEach instead of ui:repeat. It took me a while to figure this out, but there is a good explanation in this blog post.
Even knowing that I needed to use the JSTL core tag library instead of the JSF one was a puzzle. JSF apparently comes with support for this, but you have to be aware that you need to use a special namespace declaration in the view page to make it work. Instead of the normal xmlns:c="http://java.sun.com/jstl/jsp/core" you need to use xmlns:c="http://java.sun.com/jstl/core".

The above code neatly includes the proper widgets in a page. Ideally these widgets would be reusable on other pages. In the Struts application this is not necessarily the case — before a JSP is rendered, the Action class is responsible for putting all the required data on the request. If I move a widget to another page, the data to display will not be there and I have to move the code to fetch the data as well. This is where a lot of the code duplication begins.

In Seam, the widget is responsible for fetching it’s own data by invoking Seam components using EL. For instance, the included widget might contain this code:


The company's annual sales total #{metricService.calculateAnnualSalesTotal(company)}.


If the company is available somewhere in the Seam contexts, the above fragment will invoke a service using the company to fetch the required data, independent of the request context and makes the widget reusable on any page.

Working with Seam gives you a lot of flexibility, but that also has it’s downsides. What is needed is, to quote a well-known movie, is structure and discipline. Even though Seam doesn’t require a lot of layering, it still makes sense to separate the different concerns in the application. For the prototype, I chose to implement the traditional view / action / service / DAO layers to give the application more structure. Similarly, with all the options Seam provides for configuration and state management, it is important to pick one and stick with it.

One thing I did find surprising when developing with Seam is how lenient it is when it comes to errors. I’ve had pages referring to non-existent components or ui:include statements trying to include a missing view page, but Seam didn’t complain, just rendered an empty piece of HTML. If Seam would have thrown an error, at least I would have known what was wrong, saving me some time.

That said, so far I am impressed with the framework and the style of building websites with Seam. I have the feeling I have yet to tap into the true power of the framework.

For a few years now, November has been the month of QCon San Francisco for me. So far it has proven an excellent conference with lots of thought-provoking presentations and conversations. This year was no exception. Read on for my personal high- and lowlights.

The Conference

If you’ve never heard of QCon before, the conference bills itself as a conference for and by software developers and architects of any “denomination”. Walking the hallways you are equally likely to encounter a Rubyist, Javaan or .NET afficionado. This refreshing diversity leads to interesting presentations and coffee-corner conversations. For me as a Java developer, it also meant that the news about Java 7′s closures by and large passed me by.

Given it’s target audience of predominantly teamleads and architects, QCon has less technical depth than, for instance, the Devoxx conference. But with entire tracks dedicated to Ruby and emerging languages (including some C#/F# sessions), it certainly has more breadth. For me personally this is one of the key reasons to attend.

Keynotes

The keynotes this year were a bit of a mixed bag. On Wednesday, two venture capitalists spoke about what they looked for in startups when deciding where to invest. The process they described resembled the Lean Startup ideas of iterating as fast as possible with direct customer involvement. Interestingly, they mentioned Scala and Groovy as developments that they as VCs keep a close eye on.

Don Box experimented with Twitter during his keynote. Not saying a word, he wrote tweets on his laptop for the first 20 minutes. An interesting experiment, but it didn’t manage to hold the attendees’ attention. When the subsequent code demos either failed or proved unable to bring the audience back, Don himself also ran out of steam and brought the keynote to an abrupt and disappointing close. Still good of him to try something new.

The last keynote of the conference was by David Chappel of Oracle who presented and then demonstrated Oracle’s cloud tooling. Way too Oracle-centric for my money.

For next year, I really hope QCon will do away with the vendor keynotes, even if this means going back to 2 keynotes like the last few years. Someone like Kent Beck or Uncle Bob has much more interesting things to say.

Highlights

Dan North’s presentation about a challenging agile project was great. It was filled with lessons about transitional architecture and agile adoption and plenty of humor to boot.

In Lessons learned from Architecture Reviews Rebecca Wirfs-Brock discussed not only how to perform an architecture review, but also how to effectively present an architecture depending on your audience and the political environment.

Eric Evans talked about incorporating modeling and design into the agile development process and presented an early draft of his model exploration process. Eric uses this process when doing DDD consulting for clients and is useful for anyone applying the technique.

There was a lot of interest in lean software development and kanban as well. I attended presentations by Jeff Patton and David Laribee which provided useful practical tips and real-world experience. Though I didn’t attend it myself, I heard a lot of good things about Henrik Kniberg’s talk as well.

One of the most impressive tracks at QCon is Architectures you’ve always wondered about. I’m always inspired by seeing how sites such as eBay or LinkedIn handle their scaling requirements. This year’s session about Amazon S3 was equally impressive, describing design patterns for building applications that can guarantee uptime in the face of hard drive, network or machine failures. To test their service, Amazon regularly holds unannounced “game days” where they take an entire datacenter offline to see if their architecture can handle it. That is some serious testing.

Trends

During the conference, I noticed a lot of interest in:

• teaching people the craft of agile software development. Presentations discussing personal traits required for programming and software apprenticeship were the result.
• JVM-based languages like Scala and Clojure. This is hardly news, but what surprised me was the level of interest there was from non-Java developers. Several people I talked to told me that they were experimenting with these languages in their spare time while working .NET at their dayjob.
• Continuous deployment (meaning continuous deployment to production).

Bucking the trend I’ve been hearing about at other conferences, the wifi at QCon actually worked without a hitch for me.

Conclusion

For me, QCon was about re-discovering the agile software development craft this year. Talking with practitioners and hearing their experiences gave me lots of new ideas and inspiration to bring to my own projects. That said, most of the tracks and topics feel like they’ve been around for a while. Next year I’m hoping to hear about the “next big thing”.

The Essence of Networking is a Dutch book (“De essentie van netwerken”) about networking in the social, non-TCP/IP sense. It describes what networking is, how and why it works and gives practical tips on how to go about it. If nothing else, it’s a good reminder — I’ve re-connected with several old friends and coworkers since reading the book.

Often, people associate networking with smooth-talking salesmen, playing 18 holes with some golf buddies to try to secure a job or sell a product. If you’re not one of these types, networking is not for you. Not so, according to this book. Networking is not the sole domain of any one personality type. It is not done to sell things or score projects. Networking is about creating and maintaining meaningful relationships with people. Through these relationships, you will help other people and they, in turn, help you.

Sounds like a lot of work? It doesn’t have to be, once your conscious of it, it can become second nature. Receive an invitation to a seminar but can’t go — who in your network would be interested? Hear about a job opening up in your department — know any good graphic designers? Your colleague planning a weekend in Paris — recommend that great little hotel you stayed at a few months ago. And don’t forget — even if you can’t help directly, someone else in your network might.

For people to help you, they will need to know you, know what you want to achieve and what you need. Try this — answer the question “So what do you do?” in 10 seconds. Instead of naming a job title, describe what product or service you provide, how it helps your customers and what value it adds. An answer like this will mean something to your conversation partner, get people thinking and invite further conversation.

To start out on the road to networking bliss, start by mapping out your network. Classmates, co-workers, friends, people you met at the squash club, all of these are part of your network. List them, their contact information and some basics like job, birthday, family situation, etc. Next, you need to know what their goals and dreams are. Does he want to start his own company, open a B&B? Are they passionate about running a marathon, seeing the latest cult movies or playing Guitar Hero? Helping people realize their dreams, even in a small way, adds value to both your lives.

Cultivating your network is a matter of keeping their needs and wants in the back of your head. Whenever something comes up that someone might be interested in, forward it to him. Keep in touch, too, calling or emailing your contacts to check in. If you do this, you can also call on your network when you need something. Ask for help, an opinion, an introduction or a recommendation. Be as clear and concise as possible, but don’t demand anything and don’t be insulted if the other doesn’t respond as you would hope. The act of asking in itself is useful — if nothing else, you’ve planted a seed that someone can respond to in time.

I found the book enjoyable to read and have learned a thing or two about how you can approach networking. It’s not like I’ll be applying these lessons instantly, but I have started to become more conscious of my network and how to maintain or grow it. That in itself is worthwhile.

My home storage setup consists of one NSLU2 with 2 USB harddisks attached (200GB and 500GB). This is where I store all my media content, such as photos, music and movies to be served on my old 1st generation XBox and XBMC. The only other data I care about (documents, spreadsheets, tax forms, etc.) is either on my home laptop (basically a desktop replacement) or my work laptop.

At the moment, my backup scheme (if you can call it that ) consists of burning DVDs with my photos on them at irregular intervals (adding new images when returning from a trip might prompt another backup). Music is backed up from one USB disk to the other while movies are not backed up at all (the movies I really care about I own on DVD). The important documents on the laptops are also backed up haphazardly.

This setup suffers from several problems:

• backups done at irregular intervals
• the DVDs used will eventually become unreadable
• backing up to USB disks in my apartment runs the risk of losing all data at once

So, I started to look for options.

The first thing I decided was to look for online backups since these will survive even if my house catches fire or is flooded (hey, it’s Holland! ). The following were hard requirements:

• Both a Windows and a Linux client since these are the platforms I use
• Ability to backup NAS drives
• Encryption with a key of my choosing
• Efficient use of bandwidth

Other than that, convenience and of course price are further considerations.

After some searching I found that some of the more popular options (BackBlaze, Carbonite and Mozy) do not have a Linux client. The ones I did consider were:

• Dropbox
• JungleDisk
• SpiderOak

One thing I noticed is that these three services all require payment for the amount of storage used. This in contrast to the non-Linux options which offer unlimited storage. BackBlaze and Carbonite require a fee per machine backed up and hence disallow backing up of NAS drives.

I expect to be using between 50GB to 100GB of storage, so decided to compare the services based on 50GB, 100GB and 150GB:

Dropbox
Pricing: fixed per storage usage
50GB: $120 per year
100GB: $240 per year
150GB: not possible

JungleDisk
Pricing: $0.15 per GB per month (when using Rackspace Cloud Files)
50GB: $90 per year
100GB: $180 per year
150GB: $270 per year

SpiderOak
Pricing: $10 per month per 100GB (or $100 per year per 100GB)
50GB: $100 per year
100GB: $100 per year
150GB: $200 per year

SpiderOak also provides some nice-to-haves, such as syncing, sharing and a commandline client. The only major feature missing is the ability to upload changed data when the computer is idle, but this is already on the map for a feature release.

Given all this, I decided to give SpiderOak a try. So far things have not been easy (install on FC10 failed, initialization of Windows client through the company NTLM HTTP proxy failed) but I’m not going to let that get in the way. At least, not yet.

You could argue that someone with this attitude can not be convinced and I would agree with you. But it doesn’t hurt to think about how you can best go about convincing someone that agile is the best way to run a project., even if that doesn’t work for some people.

Recently I was writing a software development plan for a project. The project manager was open as far as development methodology goes, so I decided to try to convince him to go agile. I started the plan by listing a number of principles that the plan was based on. They were:

• risk-driven development (do the most risky items first)
• prioritizing (order functionality by business value delivered)
• flexibility (be flexible for scope or priority changes)
• transparancy (openly show your progress and delivered software)

Pretty reasonable-sounding principles, right?

My next paragraph declared that, if you value these principles, an agile software development methodology is the way to go. Then I listed the features of an agile methodology (Scrum in this case) and for each feature I described I referred back to which principle guided this feature. For instance:

• start validating assumptions with working software from the first iteration (risk-driven development)
• work in short iterations, allowing for new priorities (flexibility)
• demonstrate working software at the end of an iteration (transparancy)
• update the planning at the end of each iteration (transparancy)
• do the most highly valued functionality first (prioritizing)

When reading this document, the project manager said: “You know, this agile really makes a lot of sense in our context.” Done!

Of course there is nothing really specific in our context that makes agile such a good fit. Rather, by starting from a set of principles that everyone agrees are a good idea and showing how agile realizes those, it makes it a lot easier to sell the approach.

One of my colleagues read the book Flawless Consulting and was blown away by it. In his opinion, every consultant should read this book at least once. Usually, I’m skeptical when someone claims that everyone in the profession should read a particular book. Even though the book may be useful to the person making the statement, it is often because of a combination of time, place and work situation. Such conditions are unique to the person reading the book and do not easily transfer to someone else.

On the other hand, Flawless Consulting looked like a nice change of pace from my normal reading, so I put it on my book list. After having read the book I found myself repeating the statement my colleague made before: every consultant should read this book! In this post I’ll try to summarize why I think this is the case and what to me are the most important things I learned.

Flawless Consulting describes the process of consulting or professionally giving advice. The book divides this process into a number of phases, each of which has it’s particular goals and format. To consult flawlessy (perfectly), the book asserts, you have to do two things: be authentic and completing the business of the phase in the consulting process. Following these rules does not mean all your consulting engagements are going to be successful, but at least you will have done everything in your power to make it so.

The emphasis on being authentic surprised me. Why is the consultant’s attitude a critical success factor in consulting? Being authentic means being honest and open about the feelings you experience in your relationship with the client and expressing these feelings, directly and openly. For instance, if the client asks you to perform your engagement in a short timeframe because everyone is really busy, an authentic response would be to say: You are treating the assignment as if it is an afterthought. I would like you to give it the attention it deserves. instead of a more standard response like The problem you mention can have far-reaching consequences and cause a lot of harm if not addressed appropriately.. Being authentic is crucial because it brings issues and assumptions out into the open where they can be discussed and dealt with. This, in turn, will build trust between the client and the consultant, improving the chances of a successful project.

One of the key points that is fundamental to consulting is the distinction between a consultant and a manager. As a consultant, I often feel strongly about the subjects I give advice about. If a client chooses not to follow my advice, this can be frustrating. However, the consultant is not, in the end, responsible for the use of his recommendations and expertise. Even if the result of your work is never implemented, you may still have done a good job of consulting. The only thing the consultant can do is to work with clients in a way that increases the probability of your work being used.

The chapters about dealing with resistance are particularly relevant. The author sees resistance as a predictable, natural, emotional reaction against the process of facing up to difficult problems. Any resistance the client is feeling is not aimed at you, the consultant, but at the problems he is facing. This can take many forms, such as asking for unnecessary detail, silence or, surprisingly, extreme compliance with the consultant’s suggestions. To deal with resistance, the book describes three steps: identify in your own mind what form the resistance is taking; state, in a neutral, non-judging way, the form the resistance is taking; then be quiet and let the manager respond. Often, this is all that is needed to deal with the resistance. Simply naming it and discussing it openly causes these feelings to change or pass.

So, why is this a book every consultant should read? Flawless Consulting describes the process of consulting and the numerous signs indicating that something may be wrong, including how to avoid or fix these situations. Since I read the book I found that parts of it are applicable to every consulting engagement I’ve done. Of course it is possible to discover all of the book’s lessons by yourself, but why not get a headstart when you can? I am sure I will often refer back to this book in my future engagements.

At my current project, the company’s security policy does not allow anyone to put external computers on the network, preventing me and my development team from working on our laptops. The desktops that we can use are locked up so tightly (not to mention underpowered) that they can’t be used for development either. To fix this (and do nothing illegal) I asked my company for a Vodafone Mobile Connect USB modem and installed it on my Fedora Linux laptop.

The USB modem I received already contained a SIM card, so I attached it to my laptop. According to /var/log/messages, Linux recognized the card at once:


May 18 22:34:44 localhost kernel: usb 4-2: new full speed USB device using uhci_hcd and address 8
May 18 22:34:44 localhost kernel: usb 4-2: configuration #1 chosen from 1 choice
May 18 22:34:44 localhost kernel: scsi15 : SCSI emulation for USB Mass Storage devices
May 18 22:34:44 localhost kernel: usb 4-2: New USB device found, idVendor=12d1, idProduct=1003
May 18 22:34:44 localhost kernel: usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 18 22:34:44 localhost kernel: usb 4-2: Product: HUAWEI Mobile
May 18 22:34:44 localhost kernel: usb 4-2: Manufacturer: HUAWEI Technologies
May 18 22:34:44 localhost kernel: usb 4-2: USB disconnect, address 8


Some Googling revealed I needed to download the Vodafone Mobile Connect Card Driver for Linux. Even though my laptop runs Fedora 9, I downloaded the Fedora 8 RPM. Attempting an install indicated I was missing some dependencies: python-twisted, pytz, wvdial (all part of the Fedora repository), but some other ones that I needed to download separately: [libgksu] and [gksu]. There were no Fedora versions of the software, so I downloaded and installed the Red Hat Linux el5 versions. Now the Vodafone driver software also installed successfully.

Booting the driver, I was prompted for a PIN code. Trying the default ’0000′ worked like a charm. The program recognized that it needed the Vodafone NL settings and put them in:


Network operator: Vodafone
Username: vodafone
Password: vodafone,
APN: live.vodafone.com


This allowed me to successfully make a connection and send an SMS message.

Accessing the internet proved to be more of a problem. Apparently, the driver software received incorrect DNS settings, or so the program informed me. Pinging an IP address worked, but browsing the internet was impossible. The solution turned out to be to configure static DNS servers in the Mobile Connect software. After having tried lots of different IP addresses, the following ones worked:


nameserver 10.206.65.68
nameserver 158.43.240.4


Works perfectly. Now I’ll have to figure out how to share my UMTS connection with my team mates and we’ll have a mobile development team ready to go!

Update: sometimes pppd doesn’t correctly update the routing tables and hence no network connectivity:


May 20 06:51:48 localhost pppd[25311]: not replacing existing default route via 10.0.0.138


For now, the only solution I’ve found is to manually add the correct route:


# route del default
# route add default gw 10.64.64.64


Usually this is a temporary condition. By crunching knowledge, identifying patterns and addressing the other difficulties of your project, you’ll be able to find your way out of this pit. It’s not unusual to overcompensate and reach a new level of optimism. My current assignment is following much the same, cosine-like course. I’ve charted the first iteration for my current project below.

Of course, a cosine is a periodic function, so having gotten to the end of your particular curve, you’re likely to start a new one. I’ve found that being aware of this process makes it somewhat easier to deal with. It also helps if you and your team mates are in different places in this cycle.