Last week, the magic smoke escaped from the 3D graphics card of my trusty desktop machine. Last night, the magic came back with a new card. Notes, I thought to myself. I need notes, so it’s dead easy to do again.
Because… let’s face it Linds…. you LIKE messing around with the software too much to let something as trivial as the threat of Operating System permadeath stop you. And you like getting it up again fast, because OS reinstalls ain’t where the action is.
So the following is for you future Linds, and possibly you, reader with the google-fu fingers, and a good working knowledge of Linux systems…
Alright. This is the very last time I figure out how to get gource producing visualisations of my development activities from scratch. Today’s post is me leaving notes on this for next time, so I can cut straight to the chase.
A couple of times now, I’ve had occasion to want to give the people I write software for some insight into what I’ve been doing. This project last completed was one such example. A lot of work was done under the hood to enable the code-base to have a replaceable user-interface, and possibly also spatial database. The user-interface had a few new features, but the lion’s-share of it ‘looks’ exactly the same as it was when I started.
I can guarantee you though, that the source looks absolutely nothing like how it started out. Most of my time was spent in taking a code-base “designed” to be a single-user desktop application, and turn it into something that would be relatively easy to make multi-user (it is, now) and optionally, web-enabled (one particular large data-set stops this from progressing just yet).
How then, do I convince the people paying me to tear up their code-base that even though the user-interface is the same, things are now radically different under the hood? Enter gource, and some discussion on how it visualises the git repository as the source-code evolves through the project.
Forgive me for I have softwared.
I’m on the tail-end, or possibly tale-end, of a project that was pretty rough as such things go. Not the toughest gig I’ve done, but no cake-walk either.
Anyone who’s professionally played in this space knows that Murphy’s law is drawn to tight-deadline software development projects like a wunch of salivating, button-eyed bankers racing to the reading of the last will and testament of Marley & Marley. Continue reading
Last night, I was Minecrafting with my daughter, and one of “those” thoughts smacked me between the eyes.
“I wonder if anyone has ever tried cooking a LaTeX document with gradle?” bubbled up from some nether-region that is obviously still obsessing over my recent gradle play.
Recently I learned that I couldn’t easily merge the encryption library I settled on into my main one without pain. As this is a sporadically visited hobby, I don’t have the free time to get to the bottom of it. As we’re dealing with a signed jar around security, it’s possible I’d be pushing s**t uphill anyway.
You might be aware by now that I like to solve the trusting of 3rd-party library problem by simply glueing those libraries into the final executable. If I can’t have that ideal, I want a model that’s as close as I can get to it. I decided I’d get gradle to merge those dependency jars that are easy to merge, and ship the ones with issues as external dependencies.
Existential, no? Don’t worry. I’m participating in a blogging challenge to see what new things I can learn about this hobby. Regular subscribers be warned, this probably means I’m going to be more post-happy-chatty over the period of the challenge.
Today’s challenge encourages me to (re-)introduce myself and give you a feel for why this blog exists.
So calming. I’ve missed you.
It’s been too many years. Well, until the weekend just past, that is. I’ve rediscovered you, and mashed you up with clipart, which is another hobby I’ve been tooling with in your absence, and I am well pleased with your love-child!
Come then gentle reader, on a retrograde temporal shift with me, back to Friday, 31st January, 2014.