Chris Weyl published on 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?
Chris Weyl published on One thing that that had been particularly annoying me lately, was the
ridiculously long package names called for in a certain project of mine. The
package names themselves weren’t the problem, it was writing them out. With
filenames like
lib/App/MediaTracker/TemplateFor/Browser/PrivatePath/libraries/things/document.pm,
the corresponding package names become very long and very painful very
quickly.
Fortunately, I use vim as my editor of choice. Along with the fantastic snipmate vim plugin vim plugin it is possible to create a snippet that runs a little vim code as part of it:
Chris Weyl published on Lazy attributes are wonderful. They allow us to postpone generating attribute values for any number of reasons: it’s expensive and we don’t want to do it unless we need it, it should be initialized after instantiation because it depends on other attributes, etc. And it does this without our having to worry about the value being around: if we need it, it’ll be generated on the fly without any extra effort on our part.
A while back, I wrote about
“useful git defaults”. This is a tricky subject, as a sufficiently aged
~/.gitconfig is much like a vimrc or Chief O’Brien’s rank: a very
religious topic.
Nonetheless, it’s one of those things where a few small adjustments to
the system-wide git configuration (a la /etc/gitconfig) can make things
much, much easier — particularly in the case where there are multiple systems
to manage, and multiple people using them.