Build, Test and Deploy are Developer Concerns

All too often our repos here do not (actually, none) contain the definition of what code compilation and build look like. They exist in separate scripts hosted somewhere on the “Integration Team”’s servers and are very inflexible! Travis CI and services like it, have shown us that the steps to build/test/deploy code should also exist in the code repo. I’m gonna try to find some time to explore the possibility of having a Travis CI style service for in-house repositories. I want to mandate the existance of a Dockerfile in every repository so we can at least tell Jenkins to go do a docker build . in every repo in the list. But this is only temporary. The long-term goal is to definitely be able to hook into Jenkins CI from the Github web interface (like Travis CI in the open source world.)

October 1, 2018 · 1 min · 143 words

Right after I joined this new job..

Do I scrum-master (is that a verb?) automagically agile? Many people talk about cross-functional teams, developers getting hit by buses (poor us!) and CI/CD. I am not one to disagree here but I think these other tools are important as well as using the tools available to best effect. Git I am having to use Gerrit with a Gitweb frontend all maintained by a local team on servers somewhere upstairs. You want a new repo? Please write an email to this guy.. Private repository? No. ...

October 1, 2018 · 3 min · 521 words

An intro from containers!

I recently got the chance to explain what containers are to colleagues of mine. I could’ve chosen the normal path of showing off docker run commands, how to create a Dockerfile and then go about creating a Docker container. I understand that this was the common intro to containers for most people but for me, it makes Linux containers somewhat holy. I instead did a session on writing some golang code to explain what containers really are. I used asciinema to record the whole session and replay it at a fast speed which I screen-recorded using Kazam on Ubuntu. The presentation on the bottom-right of the screen was done using mdp ...

September 27, 2018 · 2 min · 241 words

Unidirectional Dataflow

Unidirectional dataflow is a pattern in which data flows only in one direction. Unidirectional dataflow was introduced by Facebook in Flux architecture. Although flux is meant for client-side UI apps, such an architecture is also very interesting for constrained embedded firmware systems. This is why the Flux architecture intrigues me: a restriction (one-way data flow) liberates you from a world of spaghetti. The coder is forced (or at least, strongly tempted) to create abstractions, dispatchers, stores and queues so that he can meet this criteria. Uni-directional dataflow also has the advantage of inherently suggesting the developer that he should make abstractions based on functionality. ...

1 min · 152 words