Bunk and Rambling Comic: Episode 0
Wednesday, May 31st, 2006

Integrated Development Environments are constantly evolving, but I have noticed that many are reaching a level of maturity that signifies a need for them to begin introducing questionable features to enable them to continue to display long term viability. For this reason, I think it is time that IDE’s such as Netbeans, Eclipse and IntelliJ look to introduce a variation on Clippy the Microsoft Office Assistant to help developers to write better code.
While pair programming helps you to write high quality code in an efficient manner there are times that a pair of programmers will end up going off on a tangent and working on something that ultimately ends up not being necessary. To counter the unbridled enthusiasm that usually causes this to occur I give you Yagni, the Development Assistant.
Yagni’s role within the IDE is to monitor a developer’s work and provide warnings and advice about bad practices and code smells. As seen below, Yagni pops up when a class is being written before the corresponding unit test.

Yagni can also step in when it thinks that you have gone off track for too long working on a development spike and try to convince you to move back on the task of writing production code.

The code intelligence of Yagni is extensive to ensure that you don’t go off track and start writing code for framework, one of the most common time wasters in software development. Here Yagni steps up and reminds you in no uncertain terms that:

Sadly, Yagni is still a work in progress so please feel free to provide some comments as to what Yagni should do to make your coding experience more fruitful. Alternatively, there might be other IDE assistants that you can think of; one example that I can think of is Microsoft Development Mentor. In the case of Microsoft Development Mentor, maybe he could sit around waiting for you to write application logic in standard code and suggest that you write it in a stored procedure instead, with a goal of helping you to keep your code difficult to understand and maintain. There is no doubt that the opportunities are endless…
When you invoke ANT from the command line, you can specify -projecthelp or -p as part of your ANT call. By adding one of these options to the command line, you will receive a list of all targets that have a description attribute defined. Often, these types of targets are referred to as top level targets. These are targets that have all of their dependencies defined and can typically be run without any issues.
Top level targets can depend upon other top level targets, but typically they will depend upon lower level targets that do not have a description or their dependencies properly defined. These low level targets do not normally define their dependencies as this creates to much of a burden on the author of the build script when adding and removing new/old targets.
When creating a new build script, I find it beneficial to define all top level targets in the same section of the file. To increase readability of the build script and to keep the intention of the build clearly defined, all top level targets should have no nested tasks within their body instead relying on the element’s depends attribute to define the implementation for each target. For example:
<target name="build" depends="init-build, build-compile" description="Target to compiles all production source."/>
By following this strategy consistently it is possible to change the way a build works quickly and easily without getting bogged down in implementation details.
A common exception to this strategy is the implementation of a clean top level target. As the clean target usually has a simple implementation, I will often define a clean target at the end of my top level targets like the one below:
<target name="clean" description="removes the build and dist temporary directories and any files found within."> <delete dir="${build.dir}"/> <delete dir="${dist.dir}"/> </target>
After missing an important meeting on Friday I have come to the realisation that maintaining multiple calendars on multiple machines may be problematic. Come to think of it, this issue has been lurking in the dark recesses of my mind for a while now. The root of this problem is tied to my work as a development consultant and the need to maintain ThoughtWorks, customer and personal schedule items in multiple systems. The development consultant aspect of my job affects me as I am not guaranteed to be working in front of any of my machines to receive meeting reminders in a timely fashion, if at all. The only thing that seems to be always near by is my mobile phone. So I am turning to it to solve my meeting notification needs.
While I look to my mobile for notifications of meetings, I realise that this is not the right tool to manage my calendar items. This is simply due to the screen size and speed of data entry that the device permits me. For a while now I have been maintaining my contacts in Outlook and synchronising with the phone regularly on my home computer. This gets around the input issues on the device, as I obviously have a full keyboard hooked up to my desktop PC. Unfortunately, I have limited access to updating this information while I am at work, meaning that this is not the ideal solution for my maintaining my calendar.
To that end, I need an Internet-accessible calendar for managing its content from multiple locations. For this I am planning on using Google Calendar. After having moved across some appointments I can understand why it is getting so many good reviews. Being able to extract calendar information in iCalendar format is also a great feature.
Now I have a tool to manage my calendar from multiple locations, another tool to remind me of meetings while I am on the go, but there is still a missing link, some way of getting the data from Google Calendar to my Samsung D600. While I initially looked at SyncML support on the D600 (which is supported) I was unable to get this working in the hour or so that I was willing to spend on it. In the interim I have opted to go with the RemoteCalendars plug-in for Outlook. What this allows me to do is to download my iCalendar data from Google and have it added to my Outlook calendar at home. From here I can synchronise it with my phone, which has proven successful to this point. My next project will be to remove Outlook as the middle man in the synchronisation process if possible.
For the time being this appears to solve my immediate problems of not being notified of meetings in a timely fashion. I know I still have to maintain multiple calendars (in fact I now have one more to edit). If it doesn’t turn out to be a silver bullet in this instance, I think I will just write my daily appointments on index cards and discard my Google Calendar.