Interesting conversation at lunch yesterday. Elias and I had a different take on what it means for a dev team to be “efficient” (I’ll have to make a special post when the two of us find ourselves in total agreement on something ;-). I’m going to caricature what we were saying a bit, because I think it captures two things developers strive for:
Efficiency Definition 1: developers spend as little time as possible not coding (meaning, as few meetings as possible, as little interaction with ticket systems as possible, etc).
Efficiency Definition 2: developers spend as little time as possible coding features which no one needs
Those two aren’t exactly in direct conflict, but they do imply different tradeoffs. If you go for 2, you’re willing to hit a few meetings, jump through some ticket system hoops, because you live in abject fear of writing the wrong code. That’s where I find myself, at this point in my career. That’s part of why I don’t trust dev teams that romanticize overwork — it’s almost impossible to avoid writing the wrong code when you’re pulling 60 hour weeks, and working in constant low-grade fear.
-Dan M
Nifty post from Adam Lindberg on the Erlang-Questions mailing list, about how he structures his eunit tests:
In myapp/src/foo.erl I put a small header file inclusion:
-ifdef(TEST).
-include("foo_test.hrl").
-endif.
And myapp/test/foo_tests.hrl looks like this:
-include_lib("eunit/include/eunit.hrl").
foo_test_() ->
[?_assertEqual(ok, public_function())].
bar_test_() ->
[?_assertEqual(ok, private_function())].
With the right compile options, you get tests only built into the code during dev, and you get to keep your tests in a separate file (but still have full access to the internal functions, which I find absolutely necessary).
-Dan M
Elias and I figured out how to write a shell script which starts up a (locally) distributed erlang node, then makes a series of rpc:call()’s to get code:purge() and code:load_file() called in another, existing erlang node.
Why is this cool? Well, now we can specify a list of modules on the command line, and get those hot upgraded in a running server, with no downtime.
But, wait, there’s more: today, I figured out how to get fabric to sync the .beam files to our set of servers, and then run the module upgrade remotely on each of them.
Is it possible I’ve taken the first foolish steps towards reimplementing the whole OTP release process? Sure! But, for now, this is a pretty good simple/useful sweet spot:
fab prod upgrade:rotator_web,rotator_utils
-Dan M
… where everything you do seems to throw up some mysterious configuration error, and no sooner do you fix one, than you get caught up in another, and you find yourself saying things like “Holy f#%ing god why does rsync have so many goddamn options”, and you realize that people in the next cube (or, if, like me, you work from home, your blameless wife, sitting in the kitchen), may be disturbed by the loud obscenities.
Here’s what I’ve learned from today’s version of that show:
- Erlang cares very much who you start it as, if you’re starting it in distributed mode
Because it needs to read/write a cookie in $HOME. Otherwise it crashes, cryptically.
This interacts… interestingly with monit, which wants to start things as root, and then change the uid to something else. Finally got that working, but my god, it was an ugly morning.
-Dan M
