05 Nov 2019
Some days you attend a meeting that shakes your faith in understanding the problem space in which you work, enough so it calls into question grander plans you’ve been scheming about to improve everyone’s experiences. I’ve had it happen more often in places where everyone’s got a higher degree than I do in a domain that’s orthogonal to what I think about every day.
Breathe, and remember you’ve been around for a while. Even if you’re in a little over your head right now, you’ve been doing this successfully and you’ll figure out what you need.
Also, for any kind of developer working with domain experts, there’s always going to be a certain code monkey aspect to the work. At its most basic level, a lot of this work is “What fields do you need?” Start small, and work up.
Finally, remember everything else you’ve been doing, because one thing we’re really good at is discounting the kinds of things we do successfully every day.
21 Oct 2019
Writing this down for my own edification, even though everyone else probably knows it:
When you checkout a branch in a Windows git repository that matches a branch name on the GitHub remote, but the case in the branch name is different, Windows doesn’t care and will happily give you the correct branch.
However, the git client doesn’t automatically match that branch with the one on the remote, so you’ll likely get messages about needing to set up the remote.
When you do, check the case between your local and GitHub. There doesn’t appear to be any issues with doing another checkout with the correct case in Windows, and magically you will be linked to the GitHub branch again.
03 Oct 2019
That’s the first line of The Windows Update, a story in The Daily WTF. Punchline: Sometimes you can fix a user’s problem by doing something that seems useless.
As a developer, the article is funny. As a developer on legacy systems, the article is also profound. I don’t know how often we’ve fixed something that was obviously wrong for years and ended up with upset users because their workaround had become part of their workflow.
You can’t do much about the icons changing during a Windows upgrade, but you can familiarize yourself with how people use your applications and try to anticipate problem areas. Consider that no one wants to work with a bad interface or an inefficient workflow, but if they’ve been dealing with it for years you need to treat any improvements as seriously as you would any new feature. Possibly more.
At the end of the day, you can judge yourself by how elegant or efficient your systems are, but everyone else will judge you based on whether your work brings about positive emotions.
16 Aug 2019
Just a quick post to get a solution out there for a weird problem that apparently only I’ve had.
Over the weekend, I worked on the long-overdue production JIRA upgrade at my work. (Seriously, we were three major versions behind. By the time I became the admin, we were all afraid to touch it for fear of losing our precious workflows.) I had tested the upgrade process on another server, taking that one from 5.2.7 to 7.12 fairly smoothly, except for when it became apparent our test VM needed more than 2GB of RAM. So, forewarned about add-on incompatibilities and upgrade paths, I was reasonably confident I could handle any upgrade weirdness.
What I wasn’t expecting was for JIRA to refuse to recognize a step in the upgrade process, meaning the carefully planned 5.2.7 to 6.4 to 7.0 to 7.12 path left some pieces behind when the 6.4 upgrade didn’t register or run some of the upgrade steps, even though it appeared to be working when tested. Specifically, the Greenhopper/JIRA Agile/JIRA Software transition only about half worked.
The Symptom: We found our Agile boards had disappeared in 7.12.
The Cause: The JIRA Software application wasn’t starting up due to failed upgrades.
The Log Entry:
2019-08-11 10:55:54,059 JIRA-Bootstrap ERROR [c.a.s.core.upgrade.PluginUpgrader] Upgrade failed: This version of JIRA Agile requires a minimum build number of #45 in order to proceed. The latest upgrade task to have been successfully completed is #39. You must uninstall this version of JIRA Agile and attempt an upgrade via an intermediary version.
The Reason: Atlassian stopped providing cumulative updates from the beginning of time in Greenhopper plugin 7.1. The 7.12 version of Greenhopper could only start the upgrade process at step 45. We were at step 39.
Suggested Solution: Replace the Greenhopper plugin with the last version that had all cumulative updates, 7.0.11. Restart the server and watch the updates fly. Very reasonable. Easy to find on the Atlassian site.
Result: Failure.
The Symptom: No upgrades. No boards.
The Cause: JIRA Agile never starts up to try to upgrade anything.
The Log Entry:
'com.pyxis.greenhopper.jira' - 'JIRA Agile' failed to load.
Cannot start plugin: com.pyxis.greenhopper.jira
Unresolved constraint in bundle com.pyxis.greenhopper.jira [185]: Unable to resolve 185.0: missing requirement [185.0] osgi.wiring.package; (&(osgi.wiring.package=net.java.ao)(version>=0.9.0)(!(version>=2.0.0)))
Suggested Solution: None. That’s weird.
Desire: Not to roll back to the beginning and disrupt all of the users that don’t need the Agile Boards.
Next Step: Digging through documentation and muttering.
The Find: JIRA’s OSGI Browser
The Clue: The OSGI browser made one thing obvious. JIRA 7.12 uses net.java.ao 2.0.0, making that part of the log entry very meaningful.
The Question: What happens if I grab the last version of net.java.ao from the JIRA upgrade backups and temporarily replace the bundled plugin, while running Greenhopper 7.0.11? (Always say yes to backups.)
Result: Me watching the build number tick up one by one in the database. Yes!
Cleanup: Replace the replaced files with their correct versions, restart, and watch the build numbers hit 51. Reindex, and we’re golden.
Lessons Learned: Update JIRA often, and always pay attention to log files.
20 Apr 2019
Sad news today. Joe Armstrong, co-creator of the Erlang programming language, passed away.
I never met him, but I read his writings in books, Twitter, and his blog, and he always struck me as a person who knew how to be an older programmer. He was constantly teaching people and learning new things, behaving with grace, dignity, and humor, always curious…this is the model I want to follow.
It’s tempting to say the world got a little darker today, but instead we’ll remember how Joe Armstrong’s life made it a little brighter.
For the curious, a collection of links: