I’ve been going through a pile of old bitquabit posts. While many of them hold up over time, the more technical ones frequently don’t: even when I was lucky and happened to get every technical detail right, and every technical recommendation I threw out held up over time (hint: this basically never happens), they were written for a time that, usually, has passed. Best practices for Mercurial in 2008 are very much not best practices now.
As I mentioned in a recent post, I manage my blog using a static site generator. While this is great to a point—static site generators can handle effectively infinite traffic, they’re stupidly cheap to run, and I can use whatever editor I feel like—the downside is that I lose tons of features I used to have with dynamic blog engines. For example, while it’s almost true that I can use any editor I want, I don’t have a web-hosted editor like I would in WordPress or MovableType, and I likewise can’t trivially add any sort of dynamic content.
Every couple of years months [checks wristwatch] weeks, we reinvent a file format for no particularly good reason. Don’t get me wrong; we come up with all kinds of reasons to justify what we’re doing—easier to read, better for the environment, It’s Got Electrolytes™—and sometimes, the new format does genuinely represent a meaningful or necessary improvement. But more often than not, we’re just reinventing things out of boredom and a nagging sense, deep down, that if we don’t keep changing everything constantly, normal people may grok that most of the reason programming is complicated and weird is because we put a lot of effort into making it that way.
When I was in high school, I used to do competitive speech.1 I didn’t really want to do competitive speech as such; what I wanted to do was competitive debate. After all, debate was way more fun: you got to argue, on purpose, about things with little actual consequence! And you got more points for being the best arguer! What’s not to love? Sadly, my school didn’t have enough people to do both debate and speech; we had to pick one, and since the overwhelming majority of my fellow classmates wanted to do speech, we did speech.
I really dislike MySQL. I haven’t used it in a long time, but I remember that it basically just stores all of its data in a flat text file. No transactions, no write-ahead log. In fact, there’s barely even any real data integrity. You have to run a repair process on boot to fix table corruption in the case of hard shutdown. There was an alternative thing you could do that fixed that, but it was an option, and no one had it enabled by default.
Yesterday, JetBrains announced new pricing for their line of developer tooling. Previously, you could buy their products for anything from $50 (for WebStorm) to $675 (for ReSharper Ultimate), with lower prices in most cases for yearly upgrades. Yesterday, JetBrains changed that and announced JetBrains Toolbox. For $12/month, you can get access to one of their products, or for less than double that, $20/month (discounted to $150/year for current customers), you can get access to all of their developer tools.
Hi. My name is Benjamin, and I’m a DVCS apologist. I’ve pretty much always been a DVCS apologist. I know quite a few people who’ve been using DVCSes since Mercurial and Git, and a few who go back to BitKeeper, but I can totally out-hipster you. I was there for Monotone. I actually remember struggling to grok tla, and being happy that someone took the time to write baz. I remember the promise and the failure that was Darcs.
Hello, world! A lot of you are on the last bits of your vacation this week. That is awesome. There is likely no better time you can take vacation. Your team has hopefully shipped all deliverables for 2014 Q4. You have likely planned out Q1. You almost certainly have no real bugs in production. Cthulhu willing, you have automatic regression and integration tests so that you can rest assured knowing that The Person Who Does Not Vacation can safely fix anything that does come up.
Welcome back to having fun with Elasticsearch and Python. In the first part of this series, we learned the basics of setting up and running with Elasticsearch, and wrote the very basics we needed to cover basic indexing and searching of Gmail metadata. In the second part, we extended the search and querying to cover the full text of the emails as well. That theoretically got us most of what we wanted, but there’s still work to be done.