Yesterday evening as I was popping out to pick up some groceries, I found a $50 note in the courtyard of my apartment block. I felt a slight compunction in pocketing it, but finder's keepers, right?
Then, a few paces further on I found $270.
Damn!
A couple of months ago someone tweeted the following question:
If more did it would make a huge difference. RT @jb_au: Men: would you refuse to speak on an all male panel? theatlantic.com/technology/arc…
— Karen Pickering (@jevoislafemme) January 5, 2013
I responded with "yes", though in my case the point is moot - I don't get invited to speak at conferences, so its's easy for me to say yes.
At the time the controversy du jour was the male-dominated roster of speakers at a UK tech conference, as highlighted by this post by Matt Andrews. I know I'm coming in to this a bit late, and in the end it looks like they fielded 3 women out of 35 speakers, but there's a couple of observations I'd like to make.
Now and again I've had a need to split an array of strings into chunks divided by certain boundary patterns. Kind of like String.split, but for an array, and with multiple boundary patterns. The problem is something akin to splitting the different sections of a MIME multipart message. In the latest instance, I wrestled with Ruby's take_while and drop_while for a bit, before giving in and kludging together an ugly state machine solution, which I shipped. However, I wasn't happy with it, so I went back and built a better solution.
Recently I had to add a new property to an existing ActiveRecord model. The model represents periodic invoices issued to electricity customers and the new property described the time covered by the invoice in days. The new property is mandatory, but there is no sensible default that can be filled in for new records. However, for legacy records it was deemed acceptable to set a length of 31 days.
I know he means well, but every time my boss talks about future-proofing, I cringe. On the face of it, future-proofing your software, that is, building your code in such a way as to allow it to meet future requirements with minimal refactoring, sounds like a worthy ambition, but in my experience it's always disaster.
Post a Comment →