I recently upgraded this blog to Octopress 3, as part of rebuilding (and Docker-ifying) my blog Jekyll build environment. This post is a guide of my upgrade experience and to talk about various workarounds I needed to make to get everything working.
After 8 years on the job, Google Reader is retiring on July 1st. Thank you for being there for us all this time!
Thanks for being a great friend, Google Reader. And I'm happy to see that there will be plenty of worthy alternatives to fill your absence.
So, Google is killing Google Reader.
When I saw that headline on Wednesday evening, I felt a mixture of emotions: anger, sadness, and worry. Anger that Google could shut-down a service that was so personally-valuable to me; sadness that a web-service I've depending upon for years was going away; worry that there might not be an alternative service out there that could fill the same role in all the same ways that the Google Reader ecosystem has.
Ack is a fantastic (and portable!) replacement
grep. It's aimed at programmers and by default will only search a
white-list of known file-extensions so that it will only search the "code" in a
ack looks at your
~/.ackrc file to get any customized "default" settings
you want. I use my (user-level)
~/.ackrc to enable some personalized default options,
e.g. color-ize output, always use a
$PAGER, sort the output by filename, etc.
But sometimes I want to have directory-level (or project-level) additional settings, namely to always exclude/ignore certain directories when searching at the project-level.
For the past two and a half years, I've been rocking my iPhone 4. It's held-up well over the years. My previous phone, an iPhone 3G, was pretty darn sluggish by the end of its two year tenure and I eagerly awaited the point where I was eligible for a phone-upgrade so that I could upgrade to the (at that time) brand-new iPhone 4. I just always assumed that was the "way it worked": sign-up for a new two-year contract, get a subsidized price on a nice shiny-new piece of phone-hardware, and don't really think twice about the recurring $80+/month phone-bill.
But I didn't realize there were other alternatives…
A few months ago, one of my friends introduced me to this blog: Mr. Money Mustache: Early Retirement through Badassity. (The blog title is sheer awesome-ness!) I quickly fell in-love with nearly everything he was writing about. Lots of great financial and lifestyle advice there.
He's been able to put to clear words what I've been starting to realize lately:
The bottom line is this: by focusing on happiness itself, you can lead a much better life than those who focus on convenience, luxury, and following the lead of the financially illiterate herd that is the TV-ad-absorbing Middle Class of the United States today (and most of the other rich countries). Happiness comes from many sources, but none of these sources involve car or purse upgrades. No matter what the herd or the TV set tells you, this is the truth.
Living within your means and cutting-back on needless spending means lower monthly expenses. By cutting those recurring expenses, you're able to save more money. The more money you save, the more compounding interest and investing works in your favor. By learning to live more frugally, you're changing your lifestyle and mindset and you end-up not needing as much money for your post-retirement lifestyle. It becomes this snowball effect and you may even be able to retire a lot earlier than you expected.
On my Windows machines at both work and home, I like to run Cygwin
to get a UNIX-like environment on Windows:
I use SSH's public key authentication
pretty extensively to get password-less authentication to make it dead-easy
(and quick!) to SSH around to different machines.
On some of the non-UNIX machines at work, I couldn't get SSH public-key auth working, but those machines do support Kerberos auth (binding to Active Directory). Based on my Google searches, all I could find were articles talking about compiling OpenSSH from source to get a working Kerberos-enabled version of OpenSSH on Cygwin. So, that made it sound like it would be a pain to get this working. But, after doing some more playing around, I found this was actually easy to setup once you understand the various pieces. Since I couldn't find any helpful information online when I first tried to get this working, I figured I'd write up what worked for me in case that helps other people.
Just over a year ago, I built a new home file-server since I was quickly outgrowing my existing storage capacity. Rather than just dropping more HDD's into the existing hardware I had running, I succumbed to geek techno-lust and opted to explore new technologies: ZFS and VMWare ESXi.
I've found myself in a (potentially unique) situation where we have a
gi-normous Subversion repository at work and
we've been exploring ways on how to trim off some of the fat but still keep all
the logical history so that we could still use things like
svn blame to
drill-down into code-history. Our central SVN repository is some 4-5 years old
and a whopping 300GB+ on-disk. (Yowza!) What we'd really like to do is dump
/trunk history out to a new repo and roll forward with that, ditching
any historical baggage from old topic branches (
/branches). The trouble is,
I haven't been able to find any tools to do this.
So, I ended-up writing my own tool to do this. But, first, some back-story…
About a year and a half ago, I stumbled upon Ryan Tomayko's "dotfiles"
repository on Github. The moment I saw it, I thought it was a great idea:
the idea of managing all your
$HOME directory "dot-files" in a Git repository.
That single idea led me on a personal crusade to better understand all the
different configuration files that live in your UNIX (Linux, Mac OSX, etc.)
home directory, and the end-result was creating my own "dotfiles"
Git repository for synchronizing/tracking/deploying my dot-files between the
various machines I work upon.
I learned a lot of neat stuff along the way, including some config options which I never knew were there and some tricks which really optimized my command-line shell experience.