More builds
Those guys at Atlassian sure crank out the builds. Half of me is impressed that new fixes come in bite sized chunks, but the down side is having to manage that change, repeatedly. Take Confluence for example, our corporate system has oh 60 or so third party plugins giving it that extra whiz-bang, but every release I have to go through a time consuming verification process for each. What would be great in the future-vapourware tense is a way to script or otherwise define behaviour, almost like runtime JUnit tests.
Anyway back to the update cycle. Being a little behind the curve is a useful thing, sure as god made little green apples there will be bugs. Being behind lets other people fix find them first, sometimes I feel like a rampant RC tester, not just limited to Atlassian, but I seem to be gifted to find those ridiculously obscure bugs/problems that no-one else does, like X windows mouse acceleration being bust and having to do a manual xset, but I digress.
Upgrade/degrade
With the ever increasing visibility of Confluence in our company yours truly wants it all running nicely with as little foobar as possible. The use of 3rd party libs is both a benefit and a curse. With 2.8x and the new hover-menus I found that the MailformNG email integration I'd just spent a week or so fixing to get issues into Jira via a nice Form (and fixing Jira email handler to deal with multiple aliases for the same 'id'). Classic scenario, do I upgrade and void the work or upgrade to gain platform whiz-bang. In this scenario I went for the update/degrade, and am patiently sitting on the side waiting for a fix to FMNG-44. I suppose this could be my queue to get the source and figure out what needs to be done. Gah, another project, more email :/
MailformNG 'client' for Jira issue entry
Speaking of the Jira mail handler, I hear that Jira 3.13 is coming along nicely. I should probably create another project for this particular beast, which is a modified create or comment handler. The driver for me is that depending on where a user is and what email client they use, their email address may be different that their registered email address in ldap. Jira currently insists on a direct match, I needed an 'indirect match' which I posted under JRA-14973 including an implementation for our Active Directory server. I did hear that Jira4 may have improved email management, but I have no clue as to whether or not this will be API breaking. To create another project, more email :/
NTLM and LDAPutil
I'm still chugging away on the Confluence NTLM, recent fixes included extending the LDAP library code to parse multiple nodes in either atlassian-user.xml or osuser.xml, doing this enables the NTLM hash 'token' that a client offers to a Confluence instance with the NTLM authenticator to be passed around to all the configured Domain Controllers to see if its valid. For a single domain this seems to work well, and should work for multiple domains, but perhaps not. I don't know if there is some weird stuff going on when mulitple DC's are defined with duplicate content, time will tell. The current approach isn't terribly scalable, as each server config is tested in turn (my only get out for this approach is that if it actually works properly I can go and fix it, honest, one day.
LDAP filters
I have great fun with LDAP filters, as Im limited to working with Active Directory I've had enough time to come up with some funky filters. Whilst going into the NTLM side of things and figuring out I didn't have enough Domain Controllers defined I wanted to get a list of Domain Controllers.... Where to find... it dawned on me that I could create an LDAP filter to list the 'machine' entries in AD itself. It all revolves around the UAC (User Access Control) value, which has a bitwise representation for various magic properties including SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION. Using a filter: (userAccountControl:1.2.840.113556.1.4.803:=532480) its possible to list the underlying machines, and to categorically list all DC's that are in a replicated cluster.
Jira wishlist
I've just come back from another branch office after doing a tripple demo of Jira,Confluence and Bamboo. One of the main features asked for from Jira was the ability to create Sub-Projects in a Project. Some things are just hard to do.
Twiki -> Confluence ?
One of our offices has a Twiki instance, consisting of some 3600 pages. I started looking at the Universal Wiki Converter but ran into an annoying infinite loop bug but actually chewed through all pages. My mileage, as the saying goes, varied. Twiki has an awsome feature that as yet Confluence cannot match. Forms. Twiki forms allow live form value modification, typed fields etc, but the power comes from being able to refer to those values and to perform queries over those values. Today you can accomplish bits of this with MetaData but for typed values the only thing that comes in close is Scaffolding. Documentation is scant on scaffolding, and there are bugs (yet another victim of aggressive product releases I think).
Where does the time go
Its funny, in today's climate of that administrative utility device, the timesheet, its sometimes difficult to chalk up a few days to investigate really promising work like the plugins or just go fix the mailformNg plugin for 2.8.x, If only there were jobs doing good Samaritan open source development :) But then again, many projects, much email :/
Did I say I get too much email?
Its funny, after a couple of years of using Linux as a development environment by default (finally kicking the dualboot must-have-word habit) the only thing that keeps me meddling with 'Doze is email. In theory yes, Evolution, in practice, no. damn thing keeps dying on me. I was using VMwareServerfor a while but had a nasty experience when lo, my beta version expireth. Greaaaat. Would the new beta beta+1 build on my machine, would it heck. Feet.getInstance().march(); I saw OpenBox and finally plucked up the courage to commit time to setting it up. It works a treat and as an added bonus and at the click of CTRL-L (I think) I get native window integration (I forgive the authors for the occasional 'Doze background blit bleedthrough). Outlook running native-ish. Until that is, the Evolution connector manages to really get hooked up with Exchange.
I must go, there is a life out there just waiting for me to find it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment