Step Ahead Software

This is why I love Wicket Java Web UI framework. It provides all the power of the latest JavaScript and browser capabilities without ever having to write any code in that crazy, non type safe, interpreted JavaScript language ;) Wicket components have all of the required JavaScript embedded within them meaning a Java developer of any skill level can simply instantiate a few components, add them to a page and bang! - too easy. So about asynchronous notifications... The 'status update' problem Often within a web app the user will invoke some operation that can take some time. The page or part of it needs to be updated to reflect the new status after the operation has completed. To do this developers, traditionally, have had to do one of these: Make a request to the server which the server delays responding to until the operation has completed. This is inviting bad karma to your web server because it ties up a connection and the number of connections in a web/app

The other day I added a new, rather complex feature to our Filegroove product. I did the normal planning and then analyzed the pros and cons of a few different design implementations. I then went ahead and implemented the chosen design and ... ... it was a bit of an anticlimax when it basically worked as designed, first go 🙂 Normally I have the excitement of hunting down some tricky bug that needs super detective skills because of some incorrect assumption I had made or due to some oversight but no ... the damn thing just worked! My reaction made me ponder: I think I've become addicted to the dopamine hit I get when I solve a tricky bug. I miss that when everything just works - need to get my dopamine hit from somewhere else - maybe some FB pings? LoL! Here's my official admission: I'm a bug addict. I've been using bugs for many year now. I tried to get off the bugs but its just too hard. After a few days without bugs I can't sleep at night and go

One of the fundamental differences between Git and Subversion that I didn't understand at first and, IMHO, doesn't really get much coverage in the documentation is the way the 'working directory' is treated. Git is all about branching and it is indeed very good at that but what happens when you switch branches in Git is completely different to when you switch branches in Subversion. You could say that you never really "switch" branches in Subversion. You can create branches and checkout a branch in subversion: In subversion if you want to use a branch you typically 'check it out' to a new clean 'working directory'. This directory is a new place in your filesystem and you perform work on that branch in this new working directory. You can't easily 'switch' a working directory from one branch to another branch. With subversion if you are working on a number of different branches then you would typically have a number of different

Oh, the humanity! If we were not in the software engineering game but, rather, in the civil engineering game then the equivalent of this article would be called 'Classic Civil Engineering Mistakes' and contain graphic videos of buildings and bridges collapsing and thousands of people running for their lives. It's hard to get emotional about something you can't see Unfortunately software is a rather intangible asset that doesn't lend itself to dramatic and emotional visualizations. When it comes down to it the life work of a software engineer, when reduced to it's lowest conceptual level, is the specific arrangement of sequences of 1's and 0's on one or more hard disks (or some form of solid state storage) residing on a server or desktop computer. How those 1's and 0's get there and 'which' sequences work and which don't is not really a black art but it definitely requires some intelligence but surprisingly a lot more common sens

Everybody knows that Wicket rocks as the best Java UI framework available. Sure there's people out there still using JSP (with/without struts), Spring MVC (Huh?), JSF, even raw servlets and a host of many other Java frameworks but let me repeat; "Everybody knows that Wicket rocks as the best Java UI framework available". I suppose I should clarify that a bit.... everyone who has ever used Wicket knows that it rocks.... You see, if you're a Java programmer who "gets" the whole Object Oriented paradigm and loves the reusability that comes from plug and play component architectures and from clever use of inheritance then you simply won't find ANY other framework that satisfies your need for such architectural candy at the UI level but that still allows the visual candy that expert web designers can create when they have full control over HTML and CSS. All I can say is "Get into it already". Get started. Read up on it. We've been using W

When it comes to conventions regarding how to structure your packages in Java (or any other language in fact) there is a wide variety of opinion. Making the right decision can promote productivity, understandability, quality, flexibility and the construction of reusable frameworks. I've seen some people promote 'package by feature' over 'package by layer' but I've used quite a few approaches and found 'package by layer' much better than 'package by feature' but further from that I have found that a hybrid: 'package by layer then feature' strategy works extremely well in practice and here's why I think that's so. Package by layer then feature The 'package by feature' people tend to want to put all user interface, model classes, persistence classes (eg., DAO - if you're into self torture ;]) for a particular feature into the same package and according to many examples, the same directory. i.e. they don't us

We have recently released a new version of the open source Modal window extension framework for Wicket called ModalX. We have also added an getting started guide, a live demo and an example application that demonstrates its main features. Feel free to leave any comments about the library here. Take a look at the ModalX home page here: ModalX Home Page See the live demo here: ModalX Live Demo