Car has difficulty starting — Trying something new

Here is a story how using a little bit of knowledge and trying something new probably saved me hundreds of dollars in car repairs.

We are a frugal family and drive cars that are over 15 years old. I work from home and besides the trips to see Grandpa and Grandma, and going to Disneyland occasionaly we don’t put very many miles on our vehicles. This is somewhat related but not what I was posting about today.

Our “white bunny,” what we call our Toyota Camery, started being sluggish when starting the car. My first thought was that it was the battery I probably needed a new one. It was time for an oil change and tire rotation anyway so I took it to Les Schwab and had them do the maintenance and check the battery that I bought from them two years ago. The result of the battery test was that the battery was fine. They said they could tell it had a difficulty starting so something else must be drawing the power. I have a trickle charger so I put that on the battery hoping it just needed a good charge. Many hours later, after the battery was fully charged, I tried starting the car and it was as bad as every. In fact I tried starting it again later and it wouldn’t start at all!

There wasn’t anything drawing the power that I could think of so I thought it must be the starter that was having problems. I was hoping the starter would be something easy to replace but feared that belts were involved, the starter would not be easily accessible, or otherwise it would be over my head. I decided to google it and found that there are no belts involved, it is relatively easily accessible, and I could do it! The next day I headed off to AutoZone and bought a rebuilt starter they had a life time warrenty on and went back to home to get my hands dirty. Getting to the bolts of the starter required that I remove the air filter unit. I probaby removed more than I needed but it definetly made it easier to get to the old starter. I loosened a couple of the wrong bolts at one point, which would have allowed me to remove the starter housing instead of removing the whole unit from engine. I quickly tightened them and removed the correct bolts and had the old starter removed from the engine. I had to get back to my day job at that point. A few hours later I had time to put the new starter in and put the air filter unit back into place. My daughter did the honors of trying to see if my hunch that the starter was the issue, and it turns out I was!

The new starter unit was $125, and with a little bit of time to go pick up the new starter and getting my hands a bit dirty I probably saved myself $100. As a side bonus I saw my air filter was filthy so I bought a new on and replaced it as well.

I have changed my oil and tires before but have never thought I could do something like this before. I am glad I did a little bit of research and tried to fix it myself. It is very gratifiying!

Two Basic DevOps Tools – Git and Docker

There are a few tools that seem to be used in most DevOps organizations. Git and Docker. There are some competing technologies but these two tools seem to be the gold standards for what they do.

According to the official Git website, “Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.” I learned relatively recently that Git was created by Linus Torvalds. I’m not sure why I didn’t know that before given his reputation. There is no need for me to expand on Git here. It is well documented and easy to learn with the existing tutorials out there. Of course there are books written on the subject which are easily found with simple Internet searches.

According to the site summary given after a link to www.docker.com in a Google search result, “Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications, whether on laptops, data center VMs, or the cloud.” It seems to me that recently Docker (the company) is trying to monetize the Docker platform more. That might just be my personal impressions, but it doesn’t take away from the value that Docker or “containerzation” provides to DevOps.

Git and Docker are parts of a DevOps tools foundation. Other tools, like Kubernetes, are used to build off of them and become part of the foundation in their own rights.

Agree or disagree? Let me know in the comments!

Book Review: Continuous Delivery and DevOps: A Quickstart Guide (3 of 3)

In finishing up the book review and notes I took, the topics of CD and DevOps culture and behaviors, hurdles to look out for, and measuring success are covered.

I took almost twice as many notes in this section as I did in the previous sections. I haven’t looked at the actual page breakdown for how I broke down the book for my three reviews. This last section did have another chapter but I think it could be that these topics are the ones I least expected to see in a DevOps book so I took the most notes about them. Having said that, I am just giving highlights from the book and my notes, instead of mostly just typing my notes like the last post.

Implementing and transitioning to a CD and DevOps  is as much about the culture and behaviors of the individuals and organization as it is about the tools, processes, and procedures used. Some of the sub topics covered previously in the book are reiterated in this section. The sub topics include “Open, honest, and courageous dialogue,” “Encouraging and embracing collaboration,” “Innovation and accountability,” “the blame culture,” “building trust,” “rewarding good behaviors and success,” and “Embracing Change and reducing risk.”

Having big screens with key metrics and information is again stressed. All of this helps with the “human side” of implementing CD and DevOps.

There are some common hurdles to look out for with any CD and DevOps implementation. Some of these were mentioned earlier in the book as well. There are individuals who find change difficult and will resist any change, including accepting the CD and DevOps ways of working. Some people will think that change is not happening quick enough. Corporate processes and red tape may get in the way. You might not have the right people and need to recruit new employees.

The “hurdles to look out for” section describes three groups of people– Innovators, Followers, and Laggards. The majority of the people will be in the first two groups and most of your attention should be focused on them. The Laggards will eventually join or get out of the way as they see the positive effects of CD and DevOps. Other hurdles to look out for is the affect of “Outsiders” who you don’t have influence over, geographically different teams or individuals, making sure automation is repeatable and consistent so the process is trusted, and like the previous section mentions, recruitment of those with a CD and DevOps mindset.

The transition from a “Legacy” way of doing things to a CD and DevOps organization started with a goal and vision. Being able to state how far along you are to reaching that goal and vision is important, as well as knowing when you have reached it. Measuring effective engineering best practices is encouraged. This means measuring code quality, code complexity and unit test coverage analysis. Looking at comments vs. code and commit rates is also effective measuring strategies. It is important to start this upfront and tweak as you go.

The platform needs to be measured, as well as the overall effectiveness of CD and DevOps. “Environment issues” might be blamed for code or delivery problems without proof. Running automated tests and monitoring, including health checks, gives the platform some credibility to the developers and engineers. Measuring improvements in efficiency and throughput could be done by reporting the following metrics–
– number of deployments completed
– time taken to get from release candidate to production
– Number of release candidates built
– A league table of software components which are released
– A list of the unique software components going through the CD pipeline
– cost of each release (if calculable)
– additional revenue due to each release (if calculable)

The last section before the summary is “Inspect, adapt, and drive forward.” The dedicated implementation team doesn’t need to remain dedicated once the goal and vision has been achieved. That does not mean the process is complete. CD and DevOps needs continuous improvements, so the dedicated implementation team moves more into an advisory role as the larger team takes over day to day improvements and enhancements.

I won’t write out my notes for the summary. I find it interesting that that last point is to “have fun” and “don’t give up.” Good advice for anything worth while.

Book Review: Continuous Delivery and DevOps: A Quickstart Guide (2 of 3)

In the first post of my review and some notes about the book “Continuous Delivery and DevOps: A Quickstart Guide,” the topics of how an organizational transforms itself from a “Legacy Code” organization into a DevOps organization was covered. This post is about the tools used and I found to be more notes than review of the content.

CD and DevOps is about removing waste and inefficiency.  “It is based on the premise that quality software can be developed, built, tested, and shipped very quickly, many times in quick succession — ideally in hours or days at the most.”

Good software engineering fundamentals are needed. Some fundamentals outlined in the book are–
– Always use source control
– Commit small code changes frequently
– Do not make code overly complex and keep it documented
– If you have automated tests, run them frequently
– Run continuous integration (CI) frequently, if you have it
– Use regular code review
– Do not be afraid of having tests that fail or other finding fault in your code.

Some strategies and goals included– “Never break your consumer,” Open and honest peer working practices, Fail Fast and often, Automated build and testing, and CI. Almost all of these topics can be directly applied to Ops practices.

Component based architecture is where code and services are broken down into discrete modules or components that are loosely coupled. Using component based architecture reduces the pain and overhead of releases.

Use Layers of abstraction to reduce dependencies which require two components to be deployed together. This also simplifies processes and reduces downtime.

Getting the right amount of environments is also important. The fewer the better, meaning if you can get away with just two then do it. For larger organizations the following number of environments is suggested–
– Dev
– CI
– Pre-production (UAT/Spot Check/[load testing, something not stated in the book])
– Production

Later the book also talks about using a “Like Live” environment to develop against. This environment might be a virtual copy on your desktop, but is essentially what is currently running in production.

The same binary should be used across all environments. This might mean you will need to load configurations specific to the environment at deploy time or package time. A repository should be used to version and store the binaries.

There is a long section about CD tooling. What it should do and how it should do it. The book mentions there is not a lot of commercial tools out there, but that might not be so true now. It suggested building your own. The CD tool seems to be what orchestrates everything. Being able to access source code and build binaries, do deployments, record every action taken, be able display how much it is used, etc.

Automated provisioning is being able to programmatically create the infrastructure or platform for deployments, IaaS and PaaS, with all the needed configurations. This is helpful for no-downtime deployments. This is something that should be included in the CD tooling.

No-downtime deployments are critical for real time systems that customers count on. Downtime could be very impactful on the business and the companies reputation.

Everything should be monitored and everyone should have access to the monitoring information. It will get used more if it is all in one place and easy to get to.

This section also talks about simple manual processes. Not everything has to be solved by software. Some electronic solution might be overkill and counter productive.

Since the tooling was the area I was most interested in I was hoping for more examples of the tools that are actually used and how to implement them. The 10,000 foot view is also helpful for the amount of time I took to consume it.

My next post will cover the last few chapters of the book that covers culture and behaviors, hurdles to look out for, and measuring success.

Pet Rabbit

My family has loved our pet rabbit, George. (I used to be able to say pet rabbits but we are down to one for the moment.) With some family members being allergic to animals George has been the perfect outside pet, which we allow inside occasionally. George is a Himalayan. They are known to be very docile and kid friendly. He digs some, but isn’t able to make the same tunnels and doesn’t have the same digging capacity as some of our former pet rabbits did. We love seeing him outside eating grass and trying to dig through weed barrier. George isn’t perfect but has made our family happier just by being around. (Isn’t that how every family member should be?)

Jealous God

During Sunday School yesterday a side topic of the difference of “Jealousy and Envy” came up. Though we didn’t talk much about the difference, we mostly talked about dealing with jealous feelings, I did a quick Internet search on what the difference was. While doing the search I remember reading that God was a jealous God. That bothered me when I read it in years past because I thought it is not good to be jealous. I didn’t find a good answer for it at the time but did better understand it after I read the meaning of Jealousy in one of the search results.

The sentence I read was, “Jealousy occurs when something we already possess (usually a special relationship) is threatened by a third person.” (https://www.psychologytoday.com/blog/joy-and-pain/201401/what-is-the-difference-between-envy-and-jealousy)

I didn’t read the whole page because that alone helped me understand the meaning of a Jealous God. God has a special relationship with us and when something threatens that relationship he is jealous. As we discussed during Sunday School, when we have our own feelings of jealousy or envy, we must understand where those feelings are coming from. Are those feelings healthy, and if they are then what must we do to maintain or obtain the relationship (or item, or blessing) we desire?

Great neighbors!

It is awesome to live in a neighborhood where we look out for each other, support each other, and are so generous. I was looking for some old computers so I could setup a home computer lab. Two families responded to a Facebook post my wife made for me, (yeah I should probably get my own account,) and one of them had just what I needed! On top of that they wouldn’t accept any money for them when I came to pick them up! Thanks to the family that will remain anonymous for now.

Book Review: Continuous Deliver and DevOps: A Quickstart Guide (1 of 3)

To further my DevOps knowledge and abilities I have been reading Continuous Deliver and DevOps: A Quickstart Guide by Paul Swartout. I’m about half way through it and wanted to get some thoughts down about the content and the book itself.

I actually started reading this book before I read the whole title. I was just looking for a DevOps book and this was the first one that popped up in the online library I was searching in. The further along I get the more I understand why it is called “A Quickstart Guide.” That doesn’t mean it can’t be valuable. It is just lacking some depth that I was looking for.

The book introduces a fictional company called Acme, and goes through the growth of a small start-up the eventually gets acquired by a larger company. Using the fictional company does serve an effective purpose to illustrate the growth and transition a company could make to Continuous Delivery (CD) and DevOps. Before reading the book I didn’t think of what it took to transition from “Legacy” development to CD and DevOps. I was just under the impression a company was one way or the other and never thought of what it took to make the transition. I’m grateful for reading the book for that reason alone. I also saw the impact DevOps has on the whole company. Sales and marketing teams have to adjust their practice and proceeds to match what DevOps is doing.

Managing a typical transition could look like this, with points to consider along the way (from pg 68 of the book)–

  1. Define a goal and vision
  2. Communicate, communicate, communicate
  3. It will change the business so make sure it has the recognition
  4. Form a dedicated team
  5. Evangelism is good PR
  6. It’s not all free
  7. You are not alone (in a good way)

What I got out of the first half of the book is that there is a distinct contrast between a small and nimble company and a potentially clunky large enterprise. Each has its strengths and weaknesses, and the purpose of CD and DevOps is to create an environment that draws on the strengths of both worlds.

So the first part of the book illustrates the transition of using development and operations practices for developing “legacy” code, (code that is large, all packaged together, and released together,) to that of agile code development (utilizing CD and DevOps principles.) In previewing the second part of the book it seems to be covering how CD and DevOps is delivering code, outlines the software engineering fundamentals and best practices, and the tools used to reach your end goal. I’ll create another post in the new few days on that.

I am interested in learning the furthering my knowledge on the tools side of DevOps but now I know I need to broaden my vision and understand how the tools fit in and affect the rest of the process and company.