About admin

programmer

cobbling together code

A while back I wrote an implementation of SHA256 in Dart using generators and byte buffer views. Going back and looking at the implementation I can’t really make sense of it. It is not obvious why I index and shuffle the byte buffers one way instead of some other way.

So what is the lesson here? Writing code is always easier than understanding it. If after putting it aside for a while I can’t figure out why I made certain decisions then what hope is there of someone else figuring it out?

software engineering principles to live by

  1. There are three ways to solve problems: bring the problem closer to an existing solution, bring an existing solution closer to the problem, invalidate the problem by changing all your underlying assumptions.
  2. It is impossible to maintain large codebases in dynamic languages. Anyone that thinks otherwise hasn’t yet written enough dynamic code.
  3. Be proud of your work but do not be your work. Be critical of the code but not the person that wrote the code.
  4. The tools must always be subordinate to human intentions and not the other way around.
  5. Capabilities are always better than features. Capabilities can be composed. Features can only be contextualized.

encrypt and check your secrets into git

When it comes to managing secret tokens whatever you do someone will come out and say you’re doing it wrong and propose an alternate solution that on the surface seems to be better but upon closer scrutiny is susceptible to the same attack vectors. The secure solutions is always some kind of custom solution for storing secrets that provides an audit trail. The audit trail means whenever a secret is accessed you have a log entry of it somewhere. Which is nice because when stuff leaks you can in theory trace it back to some specific person. Unless that person was hacked and they were used as a patsy. So today let’s compare storing encrypted secrets in git or some custom solution that is not git. Continue reading

ruby dsl tricks: reifying references

Ruby is great for writing DSLs because it has first class support for two of the most important ingredients of DSLs, contexts and code blocks. With the proper use of instance_eval the same block of code can be evaluated in various contexts to have different kinds of effects but most often what we want to do is evaluate the code block in the “freest” possible context to create an AST (abstract syntax tree). I’m almost certain there is a connection here with initial and terminal algebras in category theory but someone smarter than me will have to chase that analogy. Today I’m just going to demonstrate how to reify references so that we can support cyclic structures in our DSL. Continue reading

stuff for 2017

Be kinder to your fellow human beings. If you’re a nerd then like Joscha Bach you probably have an extra degree of freedom when it comes to normative belief systems and the signals regular people use to gauge how good/bad they are is probably lost on you. I know it is lost on me because the hyper-parameters in my neural nets are configured slightly differently. My empathy networks are more subdued than the average. Fortunately if you’re not a psychopath there is plenty of time to re-adjust those parameters.

Godspeed friends.

P.S.: I’m an atheist. I just think “godpseed” sounds cool.

war story: caching

There was that one time I used strace and a Ruby script to bypass a really long step in a build pipeline. The trick was figuring out the inputs and outputs by running the process under strace and utilizing the output from strace to compute some hashes. The core of the script was a utility class and some convenience methods for computing hashes by shelling out to find, tar, and shasum Continue reading