Christopher
Stoll

Colorado

Colorado

A poem for Veterans Day (née Armistice Day)

Vorm Sterben mache ich noch mein Gedicht.
Still, Kameraden, stört mich nicht.
(Prior to death my poem still is to be.)
(Quiet, my comrades, do not disturb me.)

Wir ziehn zum Krieg. Der Tod ist unser Kitt.
O, heulte mir doch die Geliebte nit.
(We are off to war, where death is our tie.)
(Oh that my sweetheart would no longer cry.)

Was liegt an mir. Ich gehe gerne ein.
Die Mutter weint. Man muss aus Eisen sein.
(I will happily go, what is it to me.)
(Mothers cry, so of iron one must be.)

Die Sonne fällt zum Horizont hinab.
Bald wirft man mich ins milde Massengrab.
(The sun crashes down on the horizon like a wave.)
(I soon will be tossed, in a peaceful mass grave.)

Am Himmel brennt das brave Abendrot.
Vielleicht bin ich in dreizehn Tagen tot.
(The heavens are burning a valorous red.)
(In thirteen days I will likely be dead.)

– Alfred Lichtenstein (interpreted by Christopher Stoll)


Python Min/Max Methods Compared

I wanted to know if it would be more efficient, when searching for both a minimum and a maximum value in a list, to perform both tests in a single loop rather than making calls to both the min function and the the max function. The basis for this question was that if the min and max functions ran in O(n) time then, all else being equal, combining them into a single step should cut processing time in half. Apparently, all else is not equal; running both the min and max functions is faster than looping over all of the values once. The detailed results are listed below.


Test then Deploy an Ember App from Jenkins

Here is a quick example of how to configure Jenkins to test an Ember application and then deploy it to AWS S3 if all of the tests pass.

Testing

The first step is to create a project within Jenkins to test the app. To execute the tests the following shell commands will be executed:

npm install > test_results_npm.txt
bower cache clean > test_results_bower.txt
rm -rf bower_components >> test_results_bower.txt
bower install >> test_results_bower.txt
ember test | tee test_results.tap

The important part it to build other projects, but only if this build is stable (i.e. the tests pass).

Here is the Jenkins configuration for the test project:


Docker Build in Jenkins from AWS CodePipeline

I know the title has a high buzzword quotient, but I assure you it is a real thing. The use case is this: there is code stored on GitHub which, after it passes all tests, will be deployed to Elastic Beanstalk inside of Docker container. For this project CodePipeline will get the source from GitHub and send it to Jenkins for testing. If the tests pass then CodePipeline will publish the app to Elastic Beanstalk. Below are the steps required to get this up and running.


Installing Jenkins and Docker in an AWS EC2 Instance

In order to do efficient, modern software development, especially for web applications, it is absolutely necessary to have a system for continuous integration (CI) and continuous delivery (CD). The idea with CI is to continuously integrate working code to the repository so that it can continuously be checked for errors. So, a prerequisite is to be using some sort of test driven development (TDD) method or at least some unit test framework; otherwise there is chance to automatically test for errors when the code is committed to the repository. The best CI systems automate everything after the commit. A developer pushes her code, then the CI systems notices the change and automatically runs the tests. When the application passes all of its test, a continuous delivery system should then automatically put the code into the QA, staging, or testing environment. There can be a lot of steps required to get a decent CI/CD system working, and it can be especially daunting when there is no dedicated DevOps team. So, I created a cheat-sheet for quickly setting up a simple Jenkins CI/CD system on an AWS EC2 instance.

Before proceeding you must have an Amazon Web Services account and be somewhat familiar with AWS.


Ncurses based System Performance Monitor for Mac

Ncurses based System Performance Monitor for Mac

Nmond is a Ncurses based system performance monitor for Darwin (Mac OS X terminal) written in pure C. It was “forked” from nmon. The original nmon gathered system statistics by looking at /proc, which is not available on Darwin, so system calls had to be implemented for all the statistics. The original program was monolithic and used global state a lot; it was modularized during the rewrite. It’s still a work in progress.


Position Paper: Tabs Versus Spaces

Most people would not understand why anyone would even have a preference on how many spaces a text file should be indented, but for people who interact with text files all day this can be a big deal. Seriously. People like to feel comfortable in their work places, and for software developers, or coders, their work place is their source files. Consider this analogy. It should not matter which side of my desk the phone is on, yet I prefer to have my phone on the left. The reason for my preference is that I often need to use my mouse while I am on the phone, so it is more convinient for me to reach over with my left hand and pick up the phone while leaving my right had free. I would expect a leftie to have the exact opposite preference.