making chroots

Recently I had to build a chroot for CentOS 6.4 and I kept getting RPM DB errors. The errors were because I was building the chroot on a CentOS 7 box. After banging my head against the wall for a while I discovered that once yum is installed in the chroot it is much better to change into the chroot, rebuild the RPM DB to fix the errors, and then install all further packages from within the chroot. The finished chroot can be used as-is or imported into Docker.

broken by design

So it turns out making “broken things” and then “fixing” them by heeding the opinion of some person higher up in the social/corporate hierarchy is nothing new

According to Vasari Pier Soderini (the Mayor of Florence) was standing beneath the statue as it was put into place. The Mayor complained to Michelangelo that the nose was too thick. Michelangelo tricked Soderini by climbing the statue with a chisel and some marble dust concealed in his hand, pretending to work on the nose and sending down a shower of dust, he asked Soderini if it was improved, the Mayor replied “I like it better, you have given it life”.

I wish I could say that this kind of trickery is unnecessary in software but I would be lying.

low level languages

What are the characteristics of a low level language? Some people consider bit twiddling and managing memory to be low level issues and C by that definition is a low level language. Others say the more declarative the language the more high level it is. Again, by that definition C is a low level language and languages like Java, Scala, Prolog, and Haskell are not. I disagree. Continue reading

interview questions (merging hashes)

The motivation for this one is that configuration for various development and production environments is often expressed in some kind of key/value format. Yaml and Json are the popular choices. You can also imagine at some point thinking that you can provide some kind of override mechanism for taking a development configuration and turning it into a production configuration by providing overrides for the keys you want to change in production. I’m not convinced this is a good way of doing things but let’s follow along anyway. Continue reading

beholden to dumb and static things

What is a compiler? It’s many things but the one thing it’s not is a dynamically extensible structure transformer. The reason you write code is because the compiler can only understand certain structures and you have to specify everything in terms of those structures. Static type systems are an excellent example of those fixed and rigid structures. A type system baked into a language is forever and can only be extended by modifying the compiler code directly. Now think about that a little bit: all the code you write is to teach the compiler how to perform new structure transformation in terms of the ones the compiler already understands. What if your compiler could be extended to work with those structures directly? Wouldn’t that be something? In that world all abstractions would be zero-cost instead of the ones the compiler writers thought should be zero-cost.

kill the technical interview

Update: Patrick McKenzie, Erin Ptacek, and Thomas Ptacek actually have a pretty good way of hacking the problem. I recommend heading their way and signing up for whatever it is they have in the works because there is no way it will be as bad as the usual technical interview process.

I’ve been trying to hack around the technical interview process but so far I’ve been unsuccessful. That’s not to say the experience has not been worthwhile. My ability to discriminate between professional software shops and amateur ones has increased a little bit. Here are the criteria I’ve settled on. Continue reading

not rocket science (bundled chef cookbooks)

It is possible to do configuration management right but it is also possible to do it wrong. One way to do it wrong is to combine the provisioning and deployment logic into various cookbooks and isolate them from the applications that depend on them. The reason this is wrong is because to understand how the application works in production you now have to chase down dependencies somewhere else and once you get there the cookbooks will not make much sense because they will make assumptions about the application. This is all a long-winded way of saying you are keeping track of two contexts when in reality there is really just one context, the application and its associated infrastructure logic. Continue reading

i’m a full-stack developer unless…

You need someone that understands how to design extensible database schemas both for SQL and NoSQL databases, optimize kernel settings like process limits and TCP socket settings for your application and proxy servers, debug network issues, design secure APIs and mitigate any damage caused by the inevitable security exploit, manage hybrid on-premise/cloud clusters and networks, work with your favorite MVC framework both on the front-end and the back-end, have expertise in Ruby, Python, JavaScript, Java, AtScript, OCaml, F#, etc. and be equally proficient in all those languages, set up a hadoop cluster so that you can use machine learning on all the data that is being collected, implement machine learning algorithms on top of previously mentioned hadoop cluster, track down performance regressions by figuring out what is going on with CPU cache lines, codify infrastructure configuration with your favorite configuration management tool, implement a robust and efficient build and deployment pipeline, and so on and so forth.

Please stop using the phrase “full-stack developer”. The phrase “full-stack developer” is completely devoid of any meaning because as you can see above no one can be a full-stack developer given the complexity of the modern stack. In fact hearing the phrase makes me think that the place putting out the job advert is full of amateurs. Instead just spell out exactly what your stack looks like and specify you want people that have a certain level of expertise with that stack.