Never, ever update on a Friday. GitHub: Automattic/jetpack #284: use content, attribute 0 -or- ‘id’ le sigh

Just a little snippet. This should be pretty obvious to those familiar with how sudo functions, but it’s easy to run docker commands with sudo without being prompted for your password by configuring sudo to not ask for it. Note that the normal warnings and red flags apply here. If you install the above as /etc/sudoers.d/docker, then the user rsrchboy (line 1) and any user in the docker group (line 2) will not be asked for a password when running “sudo docker …”.

Sometimes it’s necessary to – for one’s sanity, if nothing else – to establish a set of generally non-controversial, sane, system-wide git configuration defaults. This is largely helpful when multiple people are using the same system who may not have a standard ~/.gitconfig they carry around with them. To do this, we can leverage the little-used system-wide git config file at /etc/gitconfig. Remember that by default git looks at three files to determine its configuration (in ascending order of priority):

I use screen with vim. One of the things I like about vim is that, much like unix itself, I’m always discovering useful new features, even after years of use. Recently, I’ve been using tabs in vim to complement window regions. I’ve found it pretty useful, as there are times I’d want to keep certain tasks on one tab but not another. e.g. different source files open in windows on one tab; a test file + vim-pipe buffer showing the rest.

I’m in lovely Madison, WI right now, and will be headed over to my first YAPC::NA tomorrow. The first couple days are the hackathon, at which I think I’m going to work on a Dist::Zilla::Role::Stash to hold repository related information. There are a bunch of Git related plugins for Dist::Zilla, a couple that I maintain, and a lot of code is duplicated between them; a stash should resolve that. I hope to meet you all there!

I’ve seen a couple references lately to using lazy attributes as a form of caching. This is a great approach to thinking about lazy attributes, as they share a number of characteristics with traditional caching: you only have to build a (potentially) expensive value once, and then only when you actually need it. But what about when that lazily generated value is too old to trust? A lazy attribute isn’t going to help you much then, as your instance is quite happy to keep on returning the same value forever once it has been built, unless you clear or change it manually.