Author: nsledgianowski

Jenkins is showing its age

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.

Software Estimation

I have been reading ‘Software Estimation’ by Steve McConnell which is about estimating software projects. I got interested in the subject a few months ago, because my interns were asking questions about how to estimate stories in Agile ceremonies. The company I work at does not have any estimating theory. Its a shoot from the hip, ‘wild ass guess’ environment. I didn’t really have a good answer for the interns. 

A couple surprises are that research has shown software engineers typically underestimate tasks to the tune of about 30% of the actual time and that the range of estimation accuracy is around 1.2-16x. 

The Cone of Uncertainty

Prettier: Automatic code formatting for the Javascript ecosystem

I do most of my work in the Go ecosystem and rely heavily on the go fmt tool to maintain style consistency across the team. But the javascript language does not have a formatter built in so we have been relying on jslint to enforce consistent styles.  I found a auto-formatter for javascript prettier, which could make frontend formatting much easier you can find it at https://prettier.io. Prettier supports JSX which is key for us since we work on a single page application with a react.js frontend. I have added prettier to my crypto-exchange application https://github.com/Sevii/pepper-exchange to evaluate how well it works.

I dislike using linters to address code formatting and style questions because they basically nag developers into formatting things correctly.  Code formatting is low value work, I would much rather have a machine do it in 250ms  than have a developer spend 60 seconds addressing linter issues. 

Prettier should let us eliminate formatting nagware, and limit our use of jslint to semantic and correctness issues.

You can use prettier as follows. 

yarn add prettier --dev --exact

# or globally

yarn global add prettier


prettier --write "src/**/*.js"    # This command will format any .js files in your src folder.