dasman’s World

I’ve recently started trialling JIRA – the issue tracking system from Atlassian. Fantastic looking product so far – I’ve done a lot of work with Bugzilla in the past, but it doesn’t compare when it comes to the sizzle that JIRA offers.

The installation documentation is incredibly extensive. Alas, I work in IT which means Murphy’s Law guarantees that the environment I’m given to work in will be unique, complex, and a million miles from a “Standard” setup. Consequently, I was dealing with reverse proxies, apache front-ends, https issues and more besides!

One issue that I did spend a while on was this one: http://jira.atlassian.com/browse/JRA-19051. Basically, JIRA has problems when installing on Tomcat 6 if you want to use a Context that is multi-level. So, something like “/servlets/JIRA” rather than “/JIRA”.

The fault is actually with Sitemesh that JIRA makes use of. Tomcat 6 uses a naming standard based on hashes as separators to specify a multi-level context. So, in the example above, the context XML and exploded WAR file is stored as “servlets#JIRA”. Unfortunately, this confuses Sitemesh who tries to drill into the expected Context directory structure and complains that directory “servlets” does not exist.

The issue linked to above is still unresolved and was raised in September 2009, so I suspect it’s probably a pretty low priority. I was able to work around it however by inserting the “<context>” stanza for JIRA in the main server.xml file rather than in a file of its own.

While this isn’t the preferred Tomcat way of doing things (any changes I make will require a Tomcat restart), doing the Context entry this way allows you to use the path attribute, where you specify the full Context path. Using a standalone Context file, you can’t use this attribute – it is inferred from the (special, hash-separated) file name.

I also used the docBase attribute to point to the exploded WAR file. I placed the exploded WAR file under the standard webapps directory, but nested to match the multi-level context path (so, something like …/webapps/servlets/jira, rather than the more Tomcat-6-normal /webapps/servlets#jira).

This was enough to get me up and running. I suspect it might also be possible to do something using an Apache proxy, whereby Tomcat thinks it is running single level contexts (/jira) and Apache proxies the requests to those single levels (so it converts requests for /servlet/jira to simply /jira). Unfortunately this wasn’t possible in the environment I was running in, so I haven’t pursued it any further.

Hopefully this run-down is helpful to anyone else who hits this issue!

I can only take so many mysterious disappearances of my wireless network. It turns out, exactly 146 disappearances! So, when my Vista laptop decided for the 147th time that I was connected to my wireless network “kind of”, I decided enough was enough!

There was a time when I was a Linux guy through-and-through. I moved back to Windows on the desktop when I got a new machine (although my servers stayed Linux…of course!). So, its fair to say I’ve been out of the scene for a while and didn’t really know where the state of the Linux art was at.

But thinking about it, 95% of my time on the laptop is spent surfing the web, doing email, and writing the odd document – Linux can do all those with ease. So, with nothing to lose, I used the new Vista functionality to shrink my C: drive, and went about installing Ubuntu Linux on the newly created space.

Wow!

So straightforward! I downloaded the ISO image, burnt a CD, and booted off it. 30 seconds or so later, I was looking at a Gnome desktop with a fairly full complement of available applications, and an “Install Ubuntu” icon. Great way to do things – you can try out the OS, see if your machine has any incompatible hardware, and if not, proceed with actually installing it to your hard drive.

Seeing no obvious problems, I hit install, and 20 minutes or so later I had a laptop which let you choose Vista or Linux at bootup, and proceeded from there.

The experience has been fantastic. From the get-go, my Dell Inspiron 6400 laptop could see all the surrounding wireless networks, handle sound (even the custom volume up/down buttons work a treat!) and had all the software installed to surf the web, read email, and write documents and spreadsheets.

Thats not to say it was all smooth sailing – getting the laptop to actually talk to my WPA-protected wireless LAN took a bit of work – the built in graphical client didn’t want to connect, but once I put the appropriate details in /etc/network/interfaces it was all good. That’s pretty much been the only hiccup!

I’ve installed a few more things now – Google Earth is up and running (way to go Google, for supporting Linux!), the latest JDK is in, and my one indispensable piece of software – the Eclipse IDE – is up and running (pictured). This is one of the joys of doing Java development – the Operating System I choose to use is almost irrelevant – I don’t necessarily need to be running a system identical to my clients.

Since I’ve installed Ubuntu, there has yet to be a single reason to boot into Windows. Ubuntu even lets me read my Vista NTFS-formatted partition, so I can still get to all my music and documents. I suspect that what I may end up doing is setting up the laptop as a pure Linux system, with a VMWare image if I do come across something which absolutely requires Windows.

After playing around with writing Sudoku Solvers in the past, I was interested to see this page which details a number of tiny sudoku solvers in a variety of languages such as Perl, Ruby, etc.

They have a few basic rules – no line over 80 bytes, etc, etc. And the examples take their input as a string of 81 digits, which represents the 9 rows of 9 digits, with “0″ being a blank square.

As I apparently have way too much time on my hands , I got up the motivation to convert one of these examples into Java. The results?

• The end program is around twice as many lines as the Perl original, and
• Yup – you can make Java programs as unreadable as anything else out there!

There may well be shorter possibilities out there – I didn’t put in a great deal of effort past converting the Perl original. But, for the record:

import java.util.*;public class S{static char[] A;static void R(){int i,j;for(i=
0;i<81;i++){if(A[i]!='0')continue;HashMap h=new HashMap();for(j=0;j<81;j++){h.
put(j/9==i/9||j%9==i%9||(j/27==i/27)&&((j%9/3)==(i%9/3))?""+A[j]:"0","1");}for(j
=1;j<=9;j++){if(h.get(""+j)==null){A[i]=(char)('0'+j);R();}}A[i]='0';return;}for
(i=0;i<81;i++){System.out.print(A[i]);}System.out.println();System.exit(0);}
public static void main(String[] a){A=a[0].toCharArray();R();}}

Assuming you have an appropriate classpath, you can run it with a line like:

java S 006070800000000000078601520030405010400000002090302060052103690000000000003020100

This code was converted from the excellent Perl example at:

http://www.ecclestoad.co.uk/blog/2005/06/02/sudoku_solver_in_three_lines_explained.html