Today Ansible Engineeering kicked out another nice release of Ansible Tower.
Click the link above for release details from the company blog and stay tuned for shiny things coming in the future!
Reveal.js is a great way to make slide templates without resorting to traditional presentation software, and does particularly well for highlighting source code — a particular weakness of Keynote and Powerpoint.
A while back I posted to twitter about a small project I created to generate a Reveal.js slide template using YAML, in an attempt to make slide creation even faster. I’m sharing it here in case others find it useful.
As randomly referenced recently in a not-all-that-funny sitcom:
‘You see this goblet?’ asks Achaan Chaa, the Thai meditation master. ‘For me this glass is already broken. I enjoy it; I drink out of it. It holds my water admirably, sometimes even reflecting the sun in beautiful patterns. If I should tap it, it has a lovely ring to it. But when I put this glass on the shelf and the wind knocks it over or my elbow brushes it off the table and it falls to the ground and shatters, I say, “Of course.” When I understand that the glass is already broken, every moment with it is precious.’
I’ve long held (or tried to hold) that the quest for things does not make us happy. Perfect magic software that solves all the world’s problems is kind of a thing too.
But this above quote also rings true for many other reasons, and I’ve been thinking about how it applies to software development, and can make us happier in realizing it, as developers and testers and managers and people who work on software.
It is not uncommon for frustration to be expressed at receiving a bug report or when someone asks for a pony, or when one realizes one’s parents said we could go to the zoo, but it rained, or that you couldn’t afford have you wanted. But why should anyone need to feel this way? Let’s stick to the software.
For one, all software is always partially broken or at least never complete — the challenges of the developer who believes in producing the utmost quality must constantly endure trying to make sure his software never becomes broken, but while also managing his need to be creative in his work, and also wanting to implement as many cool things as possible — I think trying to achieve all of these things would be apparent to most philosophers as a source of unhappiness if you look at it wrong.
Would we be at more peace to realize software was always incomplete — that perfection and doneness are impossible — and to enjoy every minute of the process of creating it?
(Is the goal of raising a kid really just to result in adult? That would be kind of sad, wouldn’t it?)
There are plenty of books that talking about enjoying the nature of code — which often many developers enjoy more than the product the build sometimes — the thrill of a job well done, or a well crafted routine. Software is an innately creative effort, a strange marriage of poetry and math, that depending on who you ask might be craftsmanship or engineering or science — but it’s really all of those things and none. If software is art, it’s also often a work for hire. Yet Michaelangelo still comes through in the Sistine Chapel, because if he didn’t, he’d probably explode (or implode?). Thinking back to past gigs, often that was one of the hardest things for me — how many times do you get a spec so detailed there is no room to express your own creativity, or to do the design that you might love more than the implementation?
Further, creating a very successful or important component often means it keeps you from creating more things. Because you created something, you now have to care for it.
To make ourselves ok with this notion, we must resolve the idea that nothing will ever be finished, and new things will always replace the old things, and how to find happiness in working on anything — regardless of what it is.
One of my earlier jobs was at a cashier in a grocery store, and I had dreams about my line never ending — and in real life it never did either. What I grew to learn was that the line would not end, the real measure of success was really in interacting with the people along the way. Or maybe I didn’t learn that lesson then — maybe I got to tolerate it a bit more — but I did later.
It has not yet realized that it’s ok if the goblet is broken — or rather, that there is no destination or completion — and that it’s all about the interactions we have along the way — and we shouldn’t get attached to the nature of any one particular thing as it is now, or some conceptual concept of how it should be.
How do we balance the need to produce, to please everyone, to be perfect, to have every feature, to write a beautiful function, to make something robust and to make it move fast, to make it evolve but be conservative, to be agile but reliable, to embrace change but also stand the test of time, to be complete but also compact, to do what is required but also what is desired, to be aesthetic but also functional? All at once? Let’s be honest — we’d like to say we could, and we do. But we can’t — no one can — yet this is what we do every day.
We can’t have all of those things. We can have some. We can probably pick a few. But not completely. In degrees or percentages.
Then we should step back, and realize what we are undertaking is a journey, and it’s all about the people we meet along the way.
One of the lesser discussed things about Ansible is, strangely enough, how to classify it. It’s often referred to as a “configuration management” system, but is that an accurate-enough description?…
Here’s an article I wrote for ansibleworks.com describing why the divisions between configuration management and application deployment shouldn’t exist.