Blogs
Blast Radius - Critical Context
Context is everything, and understanding Blast Radius is crucial for providing the necessary context when assessing risk as a DevSecOps professional.
Blast Radius - simply put - is how much of the infrastructure is touched when a change is made. The higher the blast radius the higher the risk. And in the world of IaC that usually means it is caused by a change in IaC code. So it would be natural to assume that a large change in blast radius would be caused by a large change in IaC, but that is often not the case. There is only an indirect relationship between IaC lines changes and infrastructure changes.
But how do you protect yourself?
June 15, 2025
RAG Pipeline
A Retrieval-Augmented Generation (RAG) pipeline is a technique for interfacing with LLMs that helps to:
- Add Context
- Improve Accuracy
- Check / Filter hallucinations
- Preserve Privacy
- Add Value
In this age where LLMs are becoming ubiquitous you will very likely need to create one of these sooner or later.
May 14, 2025
Kustomize Rollout
Kustomize is a tool built into kubectl which helps in the management of YAML. It does a lot of things, but one of the major ones is having overlays per deployment. It is not uncommon to have a single base and a rollout per deployments. However, this can cause issue when you need to fix your base, as it will happily update all your overlaid environments en mass; which is less then ideal. Here is how I have fixed that for my deployments.
April 18, 2025
Hugo Wikilinks
Wikilinks are a standard of many / most wiki software. However, Hugo does not have support for them. They have a simple form of [[Page Title]] or [[Page Title|Display Text]], which makes them very useful for quick linking. This is how I implemented something like them.
April 6, 2025
Code Does Rust
Fourteen years ago Joel Spolsky wrote an article entitled “Netscape Goes Bonkers”. In that article he states that “old software doesn’t rust”. The rest of the article is good, but that statement is “off”.
April 10, 2014
Software Hazard Pay
The military has a concept of “hazard pay” which is extra money because you are placing your life on the line. Software has something similar, though certainly not as permanent, where you are putting your socioeconomic well being on the line.
The following is a list of things that I think are software hazards that should require more pay.
September 8, 2011
Understand Capistrano Without Rails
I am working on a rails project and that rails project is distributed over several nodes in a cluster. However, each of those nodes is a standalone unit and the rails app is a small administrative frontend for that box only. For this reason the standard Capistrano deployment tasks will not work. So some hacking is in order.
July 11, 2011
Problems With Agile Implementation
I really like agile programming. It keeps me close to the action, and makes me have to think about my next moves. It also keeps me informed as to what is going on around me. But in my many years of using agile I realize that, though the process itself is very nice, its implementations can tend not to be.
Problem don’t arise from agile itself, but who and how it was implemented. If the implementer’s goals do not match the Agile Manifesto there is little chance of success.
January 10, 2011
What the Restaurant Industry Can Teach the Software Industry
I really like “Gordon Ramsey’s Kitchen Nightmares.” Not the American version because it is mostly drama. The British version is where the substance is. The basic idea is that Gordon has 7 days to turn a failing restaurant into a successful one. Also, four to six weeks later he returns to see how many of his ideas stuck and how the business is going.
Universally, if the restaurant follows his advise they do well. If they fight him they fail. His tactic in every episode are almost identical and I have taken them and applied them to the software industry. Nothing new here, just interesting how good ideas transcend industries.
January 4, 2011
Minimum Developement Enviornment
Every developer has their own opinions on what tools are needed. This is a very malleable list, in general, but in my ten years of experience I have found some key things are are needed. Sure, you can live without a lot of these, but they will make your life easier.
December 31, 2010
Deal With Email Overload
This isn’t strictly software related, but a lot of us have to deal with the horror that is email. Email is not a good solution to any problem, but it is ubiquitous so it is used for all things: personal correspondence, commit tracking, defect notification, task notification, etc… Email is all to often used as a mechanism to pass-the-buck.
The only way to deal with this email overload is to set boundaries on email usage. A lot of people will find these boundaries annoying, if not unworkable. Just stick with it and lead by example. Eventually, in a time of high stress, you will be able to get to important messages fast when other would have been will be left floundering. And at that point, folks will ignore the limits you put on email.
December 12, 2010
How to Be a Bad Boss
Being a boss is a complicated thing. It is your job to get people to do things, sometimes things they do not want to do. And it is especially complicated in the software industry, where it is like herding cats.
I see a lot of posts on how to be a good boss, but the problem there is that they often forget to mention the things that can and will immediately erode any success you might have had. I am going to assume that as a reader you strive to be a person who others are willing to follow.
Nobody is perfect, so you will probably have done at least one of these things in the past. Or you do then without even knowing. Now is your chance to stop, and be a constructive boss who people want to work for.
December 5, 2010
Git With SVN
Normally, I would just use GIT without a bridge to another control system, but many companies use SVN. There are just so many benefits to using GIT that, for me, I am going to use it if there is a bridge to repository type the company uses. I certainly don’t hate SVN or CVS or Perforce, but GIT allows me to work the way that I know I am most productive; which is commit early, commit often.
What I mean by commit early, commit often is that I commit even if I only have part of the solution. As I find the other parts of the solution I commit those as well. That way when I am 2 or 3 days into a fix I already have the commit messages saved in GIT, so I don’t have to remember what I did for those 2 or 3 days. When the solution is shippable only then do I push it up to the company’s repository.
December 4, 2010
Learning Selenium
My basic need is to find a platform where I can test FF, IE, and Safari on Windows, Linux, and OS X. I use OS X as my platform, and Safari or Webkit as my environment. I don’t like Windows or IE. Linux is OK, but I like OS X because it just works the way I want. And I find FF to be slow, and Firebug which is needed to debug we pages causes rendering changes and timing issues (most notably causing FF to crash).
November 18, 2010