Things we should add to our build process

I want to try some of these and see what happens:

1. Use Sonar for tracking various metrics (it uses all well-known Open Source tools like PMD, Checkstyle, etc. and compatible with Hudson, which we already use in our projects);
2. Use Cirr to document public API changes (to know when something really important has changed);
3. Use Macker (btw, its' FAQ is really informative, thanks!) to keep dependencies between different modules under control. It first requires some modeling, after which it can break builds in case someone breaks convention;

Also, what I want to do in the nearest future is some kind of retrospective metrics analysis tool. It will consist of (maybe) set of shell scripts checking out revisions from Subversion repository, compiling code, running JDepend and others against it, applying some XSLTs to its results to combine it altogether into single big XML, putting it then into some kind of 3D storage (Revision * Metric * Module), like OLAP cube in order to analyse it. Theoretically, such tool can generate a great amount of information, and what's interesting is how useful it could actually be.

The idea was inspired by one of the reports on Software Engineering Forum 2009 (link in Russian).

TeamCity by JetBrains: yet another great CI solution

After some excitement about Rational Team Concert features, here comes another one about TeamCity, by JetBrains, the same company which gave us IntelliJ IDEA and ReShaper.

So, TeamCity is an all-included solution supporting tons of really advanced features, among which there are:

• Remote Run and Pre-tested commit
• Build Grid (just awesome!)
• Code Coverage, Inspections and Duplicates Search
• Build Progress and Estimation
• Notifications (of all kinds)

You can try and actually use it for free until your project is huge enough. It takes just 225 Mb to download and 3 minutes to install.

Nice short article about IBM Rational Team Concert

Here it is. Seems that RTC is even better than I thought... Among cool things mentioned, there are:

• Support for Agile methodology out of the box
• Original approach to SCM, based on the concept of "streams" (which are essentially branches)
• Advanced build system, automatically collecting all supporting artifacts, such as change sets, fixed defects, etc.
• A lot of great documentation (like Getting Started with Jazz Source Control)
  

What I can add from my personal experience, is that the Major Huge Advantage of RTC is that you get all these features integrated altogether out of the box. Installed it today on Windows 2003 Server - it took just 15 minutes (!) to install and configure a complete team collaboration solution. It normally takes few days to configure something like Trac + Subversion + Hudson, and even longer if you'd like to replace Trac with Redmine or Bugzilla on Linux, etc.

Client JavaScript data storage

Cross-browser data storage made easy using PersistJS. It supports a lot of different ways of storing data on client browser, falling back to plain old cookies, when necessary. The library itself is really minimalistic and standalone (opposed to Dojo Storage, for example). Also, it can be integrated with another lightweight runtime storage solution called "Taffy DB", which will enable almost SQL-like queries in JavaScript. Looks very nice to store some user-related info, session data, etc.

Ultimate Pomodoro?

What is the major problem of using the Pomodoro Technique? I think it's a sharing one. You see, when you're "in the middle of a pomodoro", no one really cares - your team mates will go on interrupting you anyway!

So, you need to synchronize it somehow. Setting a single timer per team is a bad idea, for the obvious reasons. What I suggest to do is to invent some kind of a Pomodoro Server and track your current status there (team-wise or project-wise). Of course, the policy should be invented for all team members to check this status before interrupting another person.

Sample feature list:

• Notification when required person's pomodoro has finished
• Integration with your corporate favourite IM client as a plugin
• Integration with popular issue tracking systems via plugins
• Speach recognition to simplify items entry
• Flexible hotkeys for all frequent actions to make things even easier
• Statistics gathering to analyze and boost personal productivity

Hope to find some time to figure it out in a further detail... Frankly speaking, already tried some of the most popular open source voice recognition tools. It seems that either my microphone, or my English, or these tools, or its' settings, or alltogether are too bad to recognize anything but "one [pause] two". With 25% accuracy. Sigh...

About coding

I want to separate two different kinds of coding.

First is handwriting code from scratch, which is a good old not-reusable-bad-to-support approach. It gives me a great pleasure, because I know what to expect and when I solve a Task, it's clear what I've done to complete it. I mean, it's all so clear and predictable, that nothing can spoil your pleasure of getting things done. I used to code this way somewhere about seven years ago writting C++ utils in MS Visual Studio 7.

Nowadays, things are different. I'm developing Important Enterprise Java Applications, and the coding development sequence looks like this:

1. Find an appropriate Library or Framework.
2. Choose the one which either the trendiest one (in this case all your further actions will be more painful), or the wider used one (of course, in this case everyone will think that you're starting to lose your grip on modern hi-tech).
3. Try it on some sample application (though, this stage will not give you any useful information at all).
4. Try to plug it to your existing application, consisting of Frameworks, Libraries and running on Servers. Configure it (that's where you start hating both XML and lazy developers who suddenly appear not being able to write any meaningful documentation at all). That's where the vast majority of time gets spent.
5. Fix all bugs and side effects brought by that all-new yet-another Framework. You won't be able to spot all of them fast enough of course, so this stage virtually never ends.

So, in this world the pleasure of getting things done is usually comes at step 4, when you finally manage to squeeze your brand new part into the puzzle. But that's not it - it has nothing in common with the first Predictable Big Pleasure, and this makes a huge problem for me. Somehow, programming (which is such an interesting and exciting thing in fact!) doesn't make me happy anymore - it became just a job.

And exactly that's why I'm really looking forward to start coding in Ruby, to see if it's that good, as they say.

web.xml security limitations

It appears that web.xml security is kinda useless in the real world - it has few severe limitations:

• This will not work at all (several wildcards):
  <url-pattern>/stations/*/departure/*</url-pattern>
  
  
• This will not work as expected, because only one security constraint will be checked (both constraints work separately):
  
<security-constraint>
<display-name>Station 14 constraint</display-name>
<web-resource-collection>
<web-resource-name>All station 14'th resources</web-resource-name>
<url-pattern>/stations/14/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>STATION_14</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<display-name>View arrival constraint</display-name>
<web-resource-collection>
<web-resource-name>View arrival page</web-resource-name>
<url-pattern>/stations/14/arrival/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>VIEW_ARRIVAL</role-name>
</auth-constraint>
</security-constraint>


Had to spend three days to figure it out :( Now I'm going to investigate Spring Security (AKA Acegi Security).