Tidying up after yourself when you screw things up in mercurial
Our source code management tool of choice is Mercurial; which is a python based DVCS. We switched back in 2009 once we’d gotten fed up with CVS. There are still a few internal projects using CVS, but these days almost all the developers are using mercurial. People always ask why we never moved to subversion and generally my answer has always been because it’s not *significantly* better than CVS. Yes it is better, it might even be CVS done right (not that this is a good advertisement for subversion); but ultimately, I need to use it on the plane or during a proof of concept with no external network access and collaborative development has to take place.
When you have a team of people actively maintaining a code base, someone somewhere is going to break something. It’s unavoidable, skill levels, and interest levels in SCM tools vary massively. We tend to trust the people working on the codebase so more often than not everyone has push access to our repositories. That means mercurial is going to break, at some point, sometime. Just this last week, we had 2 SCM breakages in 2 separate projects, one of which I fixed, and the other was manually merged by the team of devs.
The infrastructure team that we have at Adaptris is great; but sometimes when they setup a new vm image for me, there’s some things that are not quite right. I guess it’s because I’m a very particular kind of guy when it comes to how machines are setup. I thought that I’d write about how the development machines are setup. They’re setup just so which means that I can get working on them straight away1.
Our development machines are migrating to use CentOS 6 which is a source RPM rebuild of a prominent North American Enterprise Linux vendor; we still have quite a few machines that are based on Centos 5 but new machine deployments tend to be the latest stable release.
By the time I’ve finished all of this I’m happy that I can install java/ant/maven on the machine and it’ll work to my satisfaction. ↩︎
How to pass parameters into a stylesheet when you’re using an adapter
I’m never really been all that interested in data manipulation; one of my stock phrases is it’s just data1. From an integration perspective I might never understand the business semantics around each field in your data file. The critical part of our work is to make sure that your data gets out of System A, and gets to System B in the right format. For me, the interesting part is always understanding the esoteric limitations or complexities around the communications protocol rather than the data formatting itself. This probably goes back to messing around with protocol analyzers and gender benders (not that kind; the kind that you fit to an RS232 port) when I first started.
Anyway, the adapter has an EDI transformation engine which can turn XML into its appropriate EDI representation; one of requirements of EDI is that you need to have a document number for each document. Most of the time, this needs to be generated by us as the original data doesn’t have it. Previously someone; they shall remain nameless (you know who you are); wrote a simplistic java class that wasn’t threadsafe, relied on lots of java behaviour that was prone to errors, to increment a number in a hashmap and this ended up being used in a number of mappings which are now being reviewed. The extensions provided by Xalan that enable behaviour this within a stylesheet is yet another reason why the adapter hasn’t quite moved away from Xalan yet.
According to company lore there are quite a number of features and behaviours that are ascribed to my personality; like all things that other people say about you, I can’t quite see it myself. Still I have found myself saying It’s just data on more than one occasion. ↩︎
I setup an open proxy by mistake, and used iptables to filter out rogue connections
Once upon a time, a very long ago now, about last Friday, I was provisioning some new VM images kindly provided to me by our infrastructure team. Apparently I have my own dedicated ESX server (admittedly running on some old hardware they had lying around) with which to play around to my heart’s content. That environment is intended to be a replacement for this server; but truth be told I haven’t had time to migrate all the services running on this machine over. In fact I’m currently having trouble making hudson run the unit tests.
Anyway, I was in a rush and setup mod_ajp_proxy/tomcat on the box without really thinking about what I was doing. To cut a long story short, I missed off the most important line in the proxy configuration Deny From All which meant that effectively this box was operating as an open proxy.
Setting up the adapter to use both XSLT 1.0 and 2.0 in the same JVM
At the moment, for legacy reasons, the adapter ships with Xalan as the XSLT transformation engine. There are still a lot of stylesheets out that that won’t work with XSLT 2.0. If your environment is XSLT2.0 only then our recommendation has always been to switch the default transformer factory to something like Saxon using the appropriate JVM system property on the commandline : -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl but this makes all the transforms use saxon as the XSLT processing engine.
What if you wanted to use Saxon and it’s XSLT 2.0 engine on a per transform basis?