Why I Blog

I’ve wanted to write about why I blog for a while, and I was recently encouraged to stop procrastinating by Mattias Geniar:

Much is said, and frequently, about why you should blog. As I find most such articles to be impersonal, I thought I might share the reasons and rewards that have driven me to blog and keep me going at it. So, why do I blog?

  • To express myself. Sometimes this means artistically – being creative and showing it off – but other times it simply means organizing my thoughts and presenting them to other human beings. This forces me to clarify my thoughts, construct an actual hypothesis, and begin to test it. The end result is a refined idea that can be actually be consumed by myself and others. This is especially helpful if I will be presenting the idea to my boss or coworkers, even when that is done in a different format or medium.
  • To improve at writing. Communication is vital in any relationship, personal or business, and the written word can be tricky to wield effectively. I write emails every day, but I had not written a long-form article since college (15+ years ago, at the time!) and not on deeply technical subjects. I like to think this has been paying off for me, even with non-written communication as I’ve become more methodical and self-aware of how I communicate in all forms.
  • For community. I consume a lot from a number of different communities – security, virtualization, automation, etc. – and I feel that a good citizen contributes back when possible. Maybe I only help one other person, but I hope that I enable or inspire that person to do something awesome – like get home an hour earlier to spend more time with their family that evening.
  • As a portfolio of work. We all need to keep a portfolio, resume, C.V., etc. A blog is part of that – even if I don’t view it as a portfolio, others may, so it’s in my best interest to treat it as such. I keep this in mind before hitting publish – is this something that I want other people to see? Is it of high enough quality? Does it say something worthwhile? Does it send a positive message? Will someone else want to read this, and would they be satisfied if they did? Set your bar high and make sure you’re hitting it every time you publish something.
  • For recognition. This isn’t a very altruistic reason, but it has contributed to my efforts. A desire to write well enough to have a popular blog used by people everyday isn’t a bad thing to aim for, is it? Page views also give feedback on who your audience actually is, not who you think they are, and helps you see how they react to various article types and formats. Stats drive my morale and motivation. I like seeing that my page views went up 10% for a week, it makes me more eager to blog again. If page views go down for a few weeks, I want to know why and do better. Use it as a healthy feedback loop for your writing.

The last two reasons may seem a bit selfish, but I think that blogging as an independent is in many ways inherently self-serving. Improving my writing probably benefits me even more than building a portfolio or gaining recognition. Regardless, we all have egos and by acknowledging how they drive us, we can harness our drive rather than be controlled by it.

However, the most rewarding reason I blog, by far, is:

  • For my future self. I’ve referenced my own blog numerous times and even it had it come up as a Google result when I forgot that I had already solved a problem.¬†Writing, reading, and applying my own article is a great feedback loop. Do something, write about it, do it again based on the article, rewrite the article, repeat until accurate. All the assumed knowledge is discovered and added to the article, bit by bit, so that anyone can follow the process. This is a practice you can apply to general documentation, as well. I also follow my own blog articles to replicate the results from my lab work, in my work environment (e.g. everything puppet related). This is critical to me, as I can prove to myself that I really have gained an understanding of the subject matter.

If you’re looking at blogging anytime soon, think about what it is you intend to get out of it. It can be extremely rewarding, but only if you go into it with some awareness. Have fun!

Customizing bash and vim for better git and puppet use

Welcome back to our Puppet series. I apologize for the extended hiatus and thank you for sticking around! As an added bonus, in addition to inlining files, I’m including links to the corresponding files and commits in my PuppetInABox project so you can easily review the files and browse around as needed. I hope this is helpful!

Today, we will look at improving our build server. The build role is a centralized server where we can do our software development, including work on our puppet code and creating packages with FPM. When we work with git, we have to run git branch to see what branch we’re in. If you’re like me, this has led to a few uses of git stash and in some cases having to redo the work entirely once you start committing on the long branch. To help, we’re going to add the currently-active branch name of any git directory we are in to the PS1 prompt. We also are doing a lot of edits of *.pp files and we don’t have any syntax highlighting or auto-indenting going on. We can fix that with a few modifications, and we’ll discuss where additional customizations can be made.

Continue reading

I’ll be presenting at #PuppetConf 2015 in October and I need your help!

In my 2015 Goals, I originally had a goal of submitting a talk to VMworld. As the year went on, it became clear that a Puppet-oriented talk was more fitting and I submitted an abstract to the PuppetConf Call For Papers. I’ve very proud to announce that my abstract was accepted and that I’ll be presenting at PuppetConf 2015 this October in Portland, OR! My talk is tentatively titled Puppetizing your Organization: Taking Puppet from a Proof of Concept to the Configuration Management Tool of Choice (PyO:TPfaPoCttCMToC will probably be shortened!) and aims to help you move from buy-off on your proof of concept toward buy-in from your entire organization.

PuppetConf’s call for papers works is similar to many other conferences: you present an abstract and if accepted, you have a few months to flesh the abstract out into a full presentation. One of the concepts in my abstract is to share with and learn from others, and this talk is no different. I need your help to make sure I include multiple perspectives and lessons, not just mine. Please take a look at the abstract and let me know both what you’d like to see me cover, and any tips you have to share with others. You can leave your comments here or on twitter. I’ll make sure to acknowledge you during my presentation, unless you let me know otherwise.

I’m eagerly looking forward to meeting everyone in the Puppet community this fall! Make your reservation now using this 35% off link and be sure to attend my presentation!

Visible Ops Phase Four: Enable Continual Improvement

The final phase of Visible Ops is Enable Continual Improvement. To really succeed with our efforts, we need to make sure that the resources we have are allocated optimally toward our business goals. With most of our fires put out and significant efforts into avoiding future fires, we have the time available to do this right. To determine where our resources should be allocated, we need to look at metrics.

Continue reading

Visible Ops Phase Three: Create A Repeatable Build Library

Phase three of Visible Ops is Create a Repeatable Build Library. This phase’s focus is to define build mechanisms, create system images, and establish documentation that together describe how to build our desired infrastructure from “bare metal” (I’ll continue to use “bare metal” throughout for consistency, but “bare VM” may be more appropriate in today’s virtualized IT). This allows us to treat our infrastructure like fuses. When a fuse pops, it is discarded instead of repaired and a new fuse is inserted in its place; likewise when a system fails, it is removed from service and a new system is provisioned in it’s place. All high-performing IT organizations, not just the unicorns of IT, use this technique. This chapter focuses on how to achieve that goal.

Continue reading

Visible Ops Phase Two: Catch And Release and Find Fragile Artifacts

In the second phase of Visible Ops implementation, our goal is to Catch & Release and Find Fragile Artifacts. This phase focuses on creating and maintaining an accurate inventory of assets and highlighting those that generate the most unplanned work. The various configurations in use are also collected in order to start reducing the unique configuration counts, the focus of Phase Three. This is the shortest chapter in the book at 6 pages, though it may take significant time to complete the work efforts.

The Issues and Indicators lays out the issues being tackled, including moving from “individual knowledge” to “tribal knowledge” (a shared knowledgebase the entire organization can access, rather than in people’s heads) and preventing the “special snowflake” syndrome where every node in the network, even those in clusters or farms, are similar but still unique.

Continue reading

Visible Ops Phase One: Stabilize The Patient and Modify First Response

The first phase of implementing Visible Ops is Stabilize The Patient and Modify First Response. This first order of business intends to reduce our amount of unplanned work significantly, to 25% or less, to allow our organization to focus on more than just firefighting. When the environment is stabilized, efforts can instead be spent on proactive work that stops fires before they start.

The chapter, like all chapters in Visible Ops, begins with an Issues and Indicators section, describing the issues with both a formal statement and a narrative example. The issues are familiar to anyone in IT, from how self-inflicting problems create unplanned work to the inconvenient, but predictable, timing of system failures during times of urgency. The narrative example provided helps to relate the formal statement to the experiences we all share.

Continue reading