Netuality

Short sample from the rants of a software engineer temporarily converted into a lazy network administrator…

Should you ever need to install a forwarding DNS proxy on Debian, which also acts as DNS for the local network, don't even think about using Bind. This is a very powerful tool, but can be difficult to configure, definitely not for the faint at heart. The frequence of Bind vulnerabilities is sometimes worrying, and you'll have to dedicate more time to Bind administration than you dedicate to walking your dog at dawn. A dubious pleasure, especially when you don't have a dog.

Next contender is a stable, rock solid, simple to use tool : djbdns. Which might prove problematic on Debian, because djbdns and daemontools are not (yet ?) in the main distribution. A kind soul on the net offer some 'homemade' Debian packages, that you'll easily install. Then, you'll quickly remove it, since these packages do not have the slightest intention to work on the current Debian Sarge. My last choice was to compile from scratch and maintain djbdns by myself. With the fresh memories of administrating a bunch of Gentoo servers (perfectly comparable with walking a pack of 23 to 426 dogs, depending on how often you update your systems) – I decided to skip this option. Note to self : never ever maintain software packages built from source needing frequent manual updates.

Hopefully, there's dnsmasq to save the day. In my case, the night. An apt-get install dnsmasq later, I have a working DNS server, resolving internal names from /etc/hosts and forwarding all the other queries to my ISP DNS servers. As a bonus, it also makes for a nice DHCP server, which I don't need for the moment but might come handy later, who knows ?

Recently, an Indian poster on a Slashdot thread ('India Outsourcers Find Back Door in Canada') mentioned that:

Software Developers in India (including me) are paid 350 times the prevailing minimum wage in India.

I thought it would be interesting to make a comparison with the same data in Europe:

• in a country such as France, this makes 402.640EUR/month.
• in one of the countries wich has recently join EU, such as Hungary, this means almost 67.000EUR/month (Hungary does not have the biggest wages in the recent wave of new EU members).
• finally in a country such as Romania which is scheduled to join EU in 2007, 350 times the minimum wage is however close to 25.000EUR/month and rising with two figures percentage in the last couple of years, due to economic growth. Romania and Bulgaria are considered the poorest countries to join EU in the next years.

Outsourcing in India is more than just a temporary industry trend … and will touch all EU as strong as it does with US. Dear US developers, would you please let us join the club ? (we'd rather not, but you know …)

While the REST API is mentioned in the Top 10 Reasons to use Jira, I can hardly see any reference to such an external API in the documentation (I mean, besides XML-RPC and upcoming SOAP support) and even Google can't clear the issue. But I can confirm you, it is possible to fully(?) automate Jira using HTTP requests.

Recently, I was asked to programatically login a user into Jira and open a browser with the results of an advanced search. This is part of a really slick integration between one of my employer's products and a JIRA server – mainly helping our testers to avoid bug duplication and also providing insightful statistics for QA dept.

I've started doing it the hard way, trying to obtain and pass JSESSIONID and other useless stuff between my application and the browser, until I realized that Jira can be fully controlled through HTTP in a REST-like manner. Let me explain. Normally, if you are not logged into Jira and launch a browser with a carefully crafted search request (well, you know how to reverse enginner POSTs into GETs don't you ?) – then a graceful invitation to log in is everything you'll ever obtain. But, if you add at the end of your request “&os_username=” + USER + “&os_password=”+ PASS bang ! not only you obtain the desired search results, but you are automagically logged into Jira for the rest of the browsing session. Yes, yes yes : here I come, integration ! A couple of hours later, I am able to programatically insert bug reports, extract bug details, compute statistics and open customized advanced searches.

To quote a classic : Jira ! Jira ! Jira !. Docs would be nice, though.

PS I'm testing this on a Jira Professional 2.6.1-#65. YMMV.

This is the summary of a nice thread spotted on eclipse.platform.rcp. The initial question was I am constantly having to deal with resistance from my developers, which mostly boils down to resistance to SWT, and hesitance from peers in the company. There are compelling arguments to counter nearly every criticism that I've encounted. However, I'm having difficulty with one question, has anyone else based a non-IDE product on Eclipse?. A few answers later, boy do we have some nice eye candy to show !

	The XMF Mosaic Development Environment from Xantium provides “platform for engineering semantically rich languages and tools” (errr, whatever this means, just looks nice).
	Eclipse Trader is not quite a fully-fledged app, but a set of plugins for the Eclipse platform, dedicated to the building of an online stock trading system. This is an open-sourced, very recent project, with interesting features such as charts built with data extracted from Yahoo! Finance.
	EPIC from Incremental stands for a nice looking management software for the ship repair industry. You'll spot some gorgeous Eclipse Forms in the screenshots !

Being extremely busy lately, I arrive a bit late at the Junit destruction feast. While it is probably true that some guys with a certain gift for writing blog articles may “come up with something far more useful in a couple of days”, I think the discussion is missing an important point: there's a whole ecosystem living around Junit. We have Ant integration, we have the choice between code coverage tools (both commercial and open-source), plugins for mainstream IDEs and a certain number of useful or less-useful extensions. We have extensive documentation and a plethora of examples to feed the small fishes. Throwing Junit down the drain means throwing all these down the drain. Or, at least: write your own Ant integration, adapt a code coverage tool and rewrite the IDE integration, rewrite documentation and examples – this is not going to be done in “a couple of days”.

Another Junit advantage is that this little simplistic API is ubicuous. I mean, every developer heard about it and knows how to use it, unless of course he/she was living under a rock for the last few years. And I don't mean every Java developer, but just about every developer for a language under the xunit umbrella. Meaning : all the programming languages (unless you consider “languages” such as Whitespace, Brainfuck and INTERCAL).

Beck and Gamma have not only written some “crappy” classes and put the few “laughable” chunks of code on Sourceforge, they have done it first. Now, there is some well-founded criticism about the lack of evolution in Junit, but one thing is undeniable : it really did fill a niche, back then in 2000. The code may not be beautiful (and this is not good coming from XPers) but it serves its purpose : to provide a simple framework for unit testing.

Competition is the key here and smart newcomers on this “market” are good news for us programmers. But, it's gonna take some time and a lot of work to build a similar ecosystem, a similar mindshare and usurp Junit's kingdom. That would be of course more interesting to see than denial of four years of Junit influence in a few well-rounded, but futile phrases.