Book Review – Atomic Habits

I look at every day as an opportunity to improve myself not just on new years. If you’re into improving systems (Such as using DevOps) then why not improve the most important system you have…Yourself.

James Clear has written in my opinion a clear and practical way of changing your habits by working on a system of habits in his book Atomic Habits. Instead of having a resolutions such as “I will lose 500 pounds by the end of the year” or “I will make $1,000,000 a year” which are for the most part impossible goals since you don’t have the systems of habits needed to not only reach the goal but to support it in the long run.

Without the system, more than likely even if you reach your goal let’s say losing 50 pounds… without the systems of habits, months after you reached your goal you would have not only regained the 50 pounds you lost, you have gained another 25 pounds on top of that. The same thing that happens with the Lotto winners who won a million dollars, they end up spending it all and being worse off than they were in the beginning.

What are the Systems of Habits? Every system is made of smaller individual components or atomic habits. Instead of doing many individual tasks that require lots of conscious effort, why not build a collection of complementary habits. For instance, suppose you want to write a book, you start with a daily habit of writing 50 words a day in the morning. Writing not when you feel inspired but out of habit.

James Clear gives several examples of building habits that help you obtain long term goals. Marginal incremental gains will result in tremendous long term gains. Each habit has a long term cumulative effect on reaching your goals.

An example he gives is the British cycling team. In over a hundred year s they, only one gold medal in the Olympics in cycling and they never won The Tour de France championship. Enter David Brailsford, a specialist in marginal gains. He started changing little things such as the clothing that the riders would wear for wind resistance. Bicycle seats were more comfortable for the riders. Matresses and pillows were more comfortable to give the cyclist a better night’s sleep. They also changed the type of gels they used for muscle recovery. Painted the inside of the vans white so they can see if there was dust in the vans. Hundreds of small improvements. In less than five years, the British cycling team started winning gold medals. They dominated the cycling event in the Olympics in ChinaThree of their riders went on to win the coveted Tour de France multiple times (2012, 2013, 215,2016,2017,2018).

The idea is to work on small consistent habits that you learn to do without thinking and effort that complement other habits that help you achieve your long term goals. Those habits don’t stop after you reach your goal, they continue and allow you to achieve the next goals you have. Pushing you forward without much effort. Just getting started is the hard part.

I have already applied these principles to developing a system of habits of my own.

Here are a few examples of things I’ve done to be a better writer:

1 – Review daily a technical stack such as a framework, language, operating system, etc.

2 – Write at least 50 words a day in any form, such as an article, discovery journal, etc.

3 – Exercise every day at least one pushup.

Each one of these habits complements each other towards the goal of being a better writer. Reviewing the nuances of a framework or language helps me to keep my skills sharp on languages or frameworks I don’t use as often. Writing regularly not when I’m inspired or under a deadline keeps me consistent and disciplined in my writing. Exercise helps me keep fit and helps me manage my energy as I write.

I make it convenient to track my habit with a Goal Tracker app on my Android phone. I use an Anki App for my Android device to review things like IOS and Javascript.

What I notice I started to do after a certain point, that the daily checklist activities became automatic. They became habits I didn’t have to think of tracking at some point. All of these habits aid in reaching my long term goals.

I highly recommend this book not only to learn something about yourself but learn HOW to think strategically about developing habits that help you reach your long term goals.

Using Ansible to provision VMs on AWS

Using Ansible to provision VMs on AWS

I have been asked on several occasions to show how to use Ansible to provision VMs on Amazon Web Services (AWS). This is “commoditization virtualization” on demand just by running a single playbook, which is pretty cool.

Why automation in the first place?

If your reading this article and have any experience configuring A Unix/Linux/Windows server, whether it is a mail server, web server, whatever, you know how time consuming it is to:

  • Partition the disk
  • Create user accounts
  • Install software packages and updates
  • Configure the server application
  • etc…

You had to wait for the packages to install, configure and test the application to make sure it runs and that can take a few hours.

Now, that the servers are virtual and live in a cloud machine somewhere and you now have to configure more than a dozen of them… that’s a lot of time and you have better things to do. Tools like Ansible are the answer to configuring multiple machines.

Spining up VMs using AWS web console

AWS allows you to log into a web console, choose your VM image and bring them up one at a time. It will give you ssh credentials to allow you to login to the VMs you just made and from there, use Ansible to manage and configure them. Would it be nice if you could manage the provisioning of VM instances from Ansible? Yes you can…but there is a bit of work to make it work.

I will describe the way you can do it with several step script and (in another article) programmatically.

How do I know how many VMs I have in inventory?

The challenge of dynamic inventory is the program/playbook does not know what is in the inventory ahead of time. However, if we apply the cattle not pets approach and let Ansible take care of itempotents of the VMs (it won’t clobber the VMs or exceed the constraints of number of VMs that exist) then this can make our lives easier.

Without knowing the inventory, and checking it ahead of time, you are running blind.

Programmatically is the best way to manage and track dynamic inventory and use Ansibles modules to provision VMs in AWS.

Using a playbook to provision VMS.

In my opinion this is a clunky way to use Ansible.

The problem with this way is there is no clean way to see what is the current inventory that is on AWS, you have to run a separate program before running the playbook so you can see what is currently in inventory.

When this is done you end up writing three or four separate scripts to manage this process. In the long run, this becomes difficult to maintain since you have to look at other scripts to understand what is going on.
Writing maintainable code is a key principle.

Build the playbook to provision AWS cloud services.

Playbook is set to local host.

AWS keys are needed for AWS account access.

BOTO Python API libraries are installed.

Just in case you are not aware, BOTO is the API AWS uses for programmatically managing AWS services.

AWS cloud account

Log into AWS Management Console

Under user account, select “security credentials”

In the left hand column, select user

Select the security tab.

Look for security access key.

This is what you will need for boto/ansible.

Running Vagrant

I have created a Vagrant file with an Ansible playbook for managing AWS through a Linux VM created and managed by Vagrant.

First install VirtualBox then install Vagrant.

Download from Github the Vagrant Ansible AWS files.

Change into the vagrant file directory and type:

vagrant up

It will take a while for all the dependencies to be downloaded.

Once vagrant is fully up, type:

vagrant ssh

to access the shell of the vm.

Preparing for instances.

Change directory to the ansible playbook directory and modify the following files:


and add your AWS keys.

Provisioning AWS instances.

from the shell, type:

ansible-playbook AWS-provision.yml

to start provisioning instances in AWS.

You can watch from the AWS console the instances being provisioned.

Terminating instances

from the shell, type:

ansible-playbook AWS-terminate.yml

to terminate the ec2 instances that were provisioned in your account by the provisioning playbook.

You can watch the instances terminated from the AWS console.

This is only the beginning…

With these examples, we just created self contained machines just by running an Ansible playbook. However, we can setup a virtual container network that allows you to place in a private network such items as private networks where you have access to file servers database servers an “internal” and “external” network with a “firewall”. and more complex designs.

I may cover these examples in future articles.

In the meantime, have a great day.

The Triangle of Value

It seems like everyone wants everything these days. They want high quality products and services in the quickest amount of time at the lowest price possible. This is never the case.

I don’t recall people talking about this fundamental concept very often that is The triangle of value. It’s also known by many other names. This is a basic resource constraint when you are offering a product or service.

The triangle of value is this:

You have Time, Cost and Quality – Pick two.

You can have a low cost product very quickly but the quality suffers.

You can have a high quality product relatively quickly but it will be very expensive.

You can have a high quality product at a low cost but it will take lots of time to develop.

This is true of project management and DevOps as well. At the end of the day, these are the three elements you have to work with.

Open source products also work like this. You can have a low cost product (it’s free…so to speak) which is high quality with many features, but it gets done on donated time. It may take some time before a bug is corrected or a new features are added.

Other things that affect the “triangle of value”

Skill and Experience

Skill can reduce the amount of time it takes to make something and it can also affect quality of a product or service. Then again, you will pay more money for an individual with a higher skillset especially if you want to keep them around.


It can be something that decreases the amount of time you spend on producing a product or service. It can be in the form of automation or another catalytic process. At the end of the day, all advancements of technology are catalysts for getting more stuff out of a process. On the other hand, technology can take time and expertise to develop. This also can cost more money for better tech.

How does this understanding play into DevOps or anywhere else?

In an ideal world, you may be able to hire the brightest minds who are up to the task, have the best equipment, plenty of lead time for getting to market and an unlimited budget…but this is not the case.

It may be more like, you only could hire 2 of the 5 positions for experienced programmers (maybe your one of them) and they aren’t that bright (they just think they are), you have second hand equipment that is a few years old, your budget is a quarter of what you were promised and last week was when you had to get the project done.

That’s ok, these are the reality of the industry. You do with what you can the best you can, the same principles apply.

If you don’t have enough manpower, you make it up with overtime and finding leverage somewhere…maybe automation.

If you don’t have the latest equipment, let’s say it’s slow…you make it up by getting more of the older equipment and use them in parallel using some clever programming and networking.

If you have a short lead time, you loosen your “quality” regiment (as in hope your developers don’t make mistakes writing code by forgoing tests) to save on the time you spend in development.

DevOps CI/CD the “Holy Grail” may be a lofty goal to achieve if your resources are limited, but it is a worthwhile and doable. It may take some time to figure out how to do it and to build and train the resources to do this.

At the end of the day, what you most value is what you will get. You can’t have it all but you can choose what you can live with.

I am open to feedback and any suggestions you may have. Until then, have a good day.

Testing for DevOps – How to have 10 deploys a day versus 10 emergencies a day

Ten deploys a day was the tech talk that started DevOps as an integrated practice for software development. However, if they simply pushed out code without checking it, then the story would have been different. Without testing the code, it would be more like 10 or more Disasters a day… A down production site would result in some serious consequences such as:

  • Loss of customers
  • Loss of confidence in the company
  • Loss of employment for all who are involved

You get the pictures. Though the use of automation is a key principle of DevOps, automation is also an efficient way to multiply human error. Without efficient testing of code, CICD would be meaningless. If you write code quickly and deploy it, BUT it’s broken code, well you defeated the purpose of having software rapidly deployed and updated. Testing of code is one of the most fundamental part of DevOps there is.

But I’m a great coder and I don’t make mistakes…(or whatever is your excuse)

Well, that may be the case, however as your software product grows and more people are touching a code, the likelyhood some form of human error (that may not be yours) will be introduced into the code. It’s bad enough when you haven’t worked on the code let’s say in a couple of weeks, you don’t remember what you did. You don’t want to be called back into work on a Friday because your code changes you created bombs out on a production system… Test for it so you can sleep soundly knowing that you have a safety net in place.

Writing tests is a fundamental practice.

The fundamentals – Vince Lombarti, who is know as the winningest coaches in football once went to the lockerroom of his players after they had a major loss from a previous season and said .“..This is a football…” Part of writing good code is writing checks or tests for your code. Unfortunately, many programmers don’t write tests for their code, especially web developers who are use to just writing and fixing it as it breaks. It has been my experience that the reason many programmers don’t test code is quite simply, they don’t know how. We’ll get you pointed the right direction.

What are the various test you can do for code?

There are hundreds of different tests you can do on software, some are appropriate and some are not appropriate for testing your software. Here are a list of some of the more common tests. For the purpose of testing in a DevOps environment, there are basically two categories of test you can do for code. I’ll put particular emphasis on what are the must have tests. We’ll cover the must have tests. We’ll touch on the other tests.

Functional Tests

These are the most basic test we need to have in place for Continuous Integration.

  • Unit testing
  • Integration testing
  • Systems testing
  • Acceptance testing

Non Functional Tests

These are also important tests but are not functional test (testing key functions in software) to have AFTER you have the core functional test in place. Here are a few non functional tests.

  • Security testing – find security holes and exploits in your code.
  • Performance testing – find out how quickly your code runs.
  • Stress testing – find out how much load your application can take before it degrades or breaks.

Behavioral driven testing

This is influenced by BDD – Behavior driven development which is at the core TDD – Test driven development where development of software is defined by very specific test cases. In the case of BDD, the tests are defined in terms of a user story. This affects how you would write unit tests and acceptance tests. Testing frameworks like cucumber support this kind of writing of user stories.

Unit testing

Every bit of function you write should (must) be unit tested. It should be the most basic test that is used with any code that goes into production.

Basic principles of unit testing.

Test the smallest testable part of an application. That is a unittest.

Write your function to handle a particular error – i.e. division by zero.

test fixture – what’s needed to perform a test

Write a test case – 1/0

Write an assertion. Unit test assertion functions are very simple, they are functions that call your function and compares the returned result or state or value. For instance if you function returns a numeric value, you may use an assertion like

functionx > 0


assert.greater(functionx, 0)

This is dependent on your framework or library as far as if it supports different conditions for testing assertion.

These tests are best done with a testing frameworks or assertion libaries. For java, there’s JUnit, Python uses unittest, Javascript can use JestJS, MochaJS, Jasmine.

You can read more about unit testing here.

Integration testing

This is also very important. What if the guys who are responsible for writing the database interface makes a change that the busness logic guy didn’t know about or the frontend guys didn’t know about the change in the functions for business logic. Your code justs breaks and that’s not good for your mental health. You can read more about integration testing here.

Acceptance testing

This is what your customer sees and interacts with. This is probably the most time consuming part of writing tests for. Never the less, if the customer is not able to press the “pay” button, you and your company are going to lose money…and that’s not good. Your going to catch this with a good automated testing approach. These days if your testing a web app or website, use selenium or a framework that drive selenium to test the web interface with clicks and data input values. You can record your test using the Selenium IDE in Firefox or Chrome. It will take some massaging of your recording to make a good automated acceptance test.

Depending on your testing strategy, your approach and framework you will use will vary. Regardless of your approach, I’ll always recommend unit testing your code.

Tying it in to DevOps

Continuous integration is a strategy and software testing being both a strategy for instance Behavior driven development with various frameworks as tactics such as cucumber as a framework that supports Behavior driven testing.

Without software testing and a sound testing methodology, you couldn’t have Continuous integration. That is the Holy Grail of DevOps.

I am open to any comments or suggestions to this article. Until then have a good day.

Book Review: Start with Why – by Simon Sinek

What does this have to do with (fill in the blank)?

In the IT field and especially if you are a tech, it’s easy to get in the “weeds” of what you do, and you forget why you do it. It’s when you forget your why that you often have writers block, make bad decisions and you have a hard time getting your ideas and projects from being accomplished.

The book Start With Why was written from a ted talk Simon Sinek did Start with Why.

He outlined as an example how an average computer company would sell computers, I’ll paraphrase:

Average computer company:

We’re GreatComputers company. We do 6 Billion dollars in sales. We make state of the art computers, that are user friendly and powerful.
Buy our computers.

This sounds like every other company and is not very compelling.

Here’s what Apple computer markets itself:

We’re Apple, and we’re against the status quo. We believe in empowering the individual. That’s why we make user friendly computers which are both easy to use and powerful using cutting edge technology. Do you want one?

You may notice, that the content itself hasn’t changed much except for the reason behind the content. This makes the message more compelling.

He gives several examples of this in his book such as Martin Luther King, The Wright Brothers and examples of failures of why such as Tivo and Wallmart that lost it’s why.

The key principle he outlines is the golden circle where its:


This golden circle model is based on how the human mind works. The limbic primative brain is where the feeling that drive our actions come from. It is where our hunches and intuitions come from. When people say “It just doesn’t feel right” or wordings to that extent, How and what comes from the outer parts of the brain, the Neo-cortex. This is where our language and logic comes from.
We may have all the intellectual understanding to do something, however if your heart is not in your work or you don’t have any kind of passion to do the work, then things like burnout, anxiety and other stress related problems will creep in. It’s better to do what you believe in than not. Your feelings drive your logic and actions, not the other way around.

Without your why, then how and what become meaningless exercises and your actions and efforts just become a commodity.

How do I use Why in DevOps? (or anywhere else)

The why is what’s behind the strategies that guide your groups and organization. It guides your tactics and helps you build trust in your group. They “buy in” you need to make things work. It is also important for understanding individually why you do those things. For instance, you might get push back from a particular individual in operations for deploying a new software package. You go and talk with him and find out he’s the one who gets all the pages and ends up fixing the new package every weekend. If your able to address his why that is “I don’t get any piece of mind when a new package is deployed” then you remove that resistance and you will get buy-in from him.

Also with a good why, when they buy the why, they will help figure out the technical details. Shared intelligence is better than being the smartest man in the room. If your the smartest man in the room, you are doing all the work. You don’t want to be a micromanager.

Everyone is a leader – Start by leading yourself

Everyone is leading someone. At the end of the day, you are leading yourself. Start with your own why and communicate with yourself why your doing whatever your doing. Then communicate this with everyone else you are working with. It makes it easier for others to work with you and follow along.

This is what I found useful from Start With Why and my main takeaways are:

  • Why – remember why your doing it.
  • Look for peoples whys.
  • Communicate your whys to other people.

Your mileage may vary.

Feel free to give me your comments and suggestions.

Until then, have a good day.