Month: August 2018

Often to save money or for convenience people will buy a multitool or generalized tool instead of a specialized tool. Depending on the use case there might be a specialized tool that is only useful for that one thing. One example is the fingertip bandage, it is shaped like a butterfly which makes the bandage less useful for most scrapes. But if you have an injury on your fingertip its hard to beat a fingertip bandage. They stay on very nicely and fit well. 

This concept extends to specialist engineers if your project can support it you want to hire specialists that focus precisely on subsets of your project. You want to hire a frontend engineer, a backend engineer and a data base expert. The issue is that you often cannot find specialists for every component, or there are many small areas that are too small to hire a single specialist for. This is when most companies turn to generalists. 

Specialists are expensive and only want to work on one sort of problem. Generalists are cheaper and will work on anything you want them to. As a result many companies slowly become staffed by generalists except for a few areas where the company itself is specialized. After a while, your company may consist almost entirely of generalists who are used to working on things that they do not know a lot about. The issue is that this effects your company culture and the ideas your company has on how software engineering works. 

A specialist will be working at 100% on day one of a project in their specialty. A generalist replacing a specialist you didn’t want to hire will take months to get to 80% of the productivity that specialist would have had on day one. If your company consists of mainly generalists, most companies do, you may not realize how much efficiency you are giving up by not having specialists. 

In our latest set of Sledgecasts I work through the problem of merging k sorted lists. I eventually converged on the optimal solution except I did not perform it in place. Merging linked lists can be done in place without any allocation which can make a big difference if you are allocating an entirely new list each time you merge.

 

 

Jenkins has been a stalwart aid in all of the CI/CD projects I have worked on. Jenkins’ ease of use and plethora of plugins make it useful for almost any project and situation. From a build tool to a job scheduler Jenkins can solve your problem. But as with any good tool Jenkins has its drawbacks. For Jenkins the issue that gets me is that configuration is not stored in a git compatible format.  If I change a job configuration there is no way to rollback the change or even determine what the previous state was. If multiple teams have access to Jenkins your build server could go down with no means of rolling back a change on the whim of another team’s wannabe system administrator. 

Jenkins Pipelines are the Jenkins solution to storing job configuration in source control, but that is only for job configuration. Plugin configuration is still updated manually and easy to lose. It does make me wonder if we could make the /var/jenkins folder a git repository and just ignore the job history directories. 

While Jenkins pipelines are nice, I don’t want to code my entire build. I just want my changes stored in a git compatible format so I can easily roll them back. 

I also want to be able to mix and match pipeline stages with a standard stage interface for artifacts. Jenkins Pipelines allow me to mix and match ‘functions’ from a shared library, but not stages. Spinnaker purports to handle pipelines well, but it require me to run 10 different micro-services just to get started. That is not a replacement for Jenkins, maybe if Spinnaker was hosted by a 3rd party, it would be convenient enough, but Jenkins is free to setup. 

I will be using Jenkins today, but tomorrow I will have to start looking at alternatives.