Ansible is a great tool. We’ve been using it at my job with a fair amount of success. When it was chosen, we didn’t have a requirement for supporting Auto scaling groups in AWS. This offers a unique problem – we need machines to be able to essentially provision themselves when AWS brings them up. This has interesting implications outside of AWS as well. This article covers using the Ansible API to build just enough of a custom playbook runner to target a single machine at a time, and discusses how to wire it up to knockd, a “port knocking” server and client, and finally how to use user data in AWS to execute this at boot – or any reboot.
I’m developing some automation around DNS. Its imperative that I don’t break anything that might impact any users. This post documents the process I went through to build a DNS sandbox, and serves as a crash-course in DNS, which is, like most technology that’s been around since the dawn of time, a lot simpler than it seems at first glance.
Prompted by a discussion on a LinkedIn group, I was reminded of a presentation deck I put together a couple of years ago to capture what my cohorts and I were doing for project management at the time.
I’ve procured a new HP Chromebook 14. Chrome OS is nice, but I can’t code with it in any useful way. So I’ve opted to put Linux on it, the LXCE variant of Ubuntu (Lubuntu). And try a few other OSes while I’m at it. This post covers what I did, and my initial findings.
Python developers: Do you call your team or business a “python shop”? If so, what do you mean? If not, why not?
At my job, I had an API problem: I had a object property that could contain one or more strings. I assumed it would be a list, some of my users felt that
['value',] was harder to write than
'value'. I found myself making the same mistake. So, I solved the problem, then I took the rough class I wrote and polished it. It’s up on my github, at https://github.com/jjmojojjmojo/stringlist
I’ve been thinking a lot about the backlog grooming and design process in Agile approaches like Scrum.
Something occurred to me recently: what I really want during this phase is true driving out of assumptions. I want to discuss and record implementation plans and discuss how we’re going to accomplish a given user story so that when we do estimation, it’s realistic.
A big part of that is the intermediate products, or project assets as I call them in the diagram – mockups, use cases, workflow (and other) diagrams, and prototypes. Proof of concept at various levels coupled with documenting the how of what we’ll do in the next sprint.
This diagram hopes to put this process, as I see it, into focus more directly than I think I could do through prose.
This is a mini-experiment of sorts – how much can I convey in a diagram without a lot of verbiage to accompany it?
As such, thoughts and comments are welcome.