LinLog

With the imminent demise of Google Reader, and FeedDemon consequently being end-of-lifed, my next task was clear: find a new RSS aggregator. This was not something I was looking forward to. However, as things turned out, I actually got to solve the problem in more or less the way I'd wanted to for years.

The thing is, I never really liked Google Reader. The only reason I started using it was because I liked FeedDemon and FeedDemon used Google Reader as it's back-end sync platform. (And if you've ever tried to use a desktop aggregator across multiple systems, you know that not being able to sync your read items across devices is just painful.) But I seldom used the Reader web app - I didn't think it was especially well done and I always regarded the "social" features as nothing but a waste of screen space. Granted, the "accessible anywhere" aspect of it was nice on occasion, but my overall impression was that the only reason it was so popular was because it was produced by Google.

The other issue with Reader is that I don't trust Google or hosted web services in general. Paranoia? Perhaps. But they remind me of the saying that "If you're not paying for the product, then you are the product." And while I know a lot of people aren't bothered by that, I think that Google knows far too much about me without handing them more information on a silver platter. Furthermore, you can't rely upon such services to always be available. Sure, Google is huge and has ridiculous amounts of money, but even the richest company has finite resources. And if a product isn't generating enough revenue, then the producer will eventually kill it, as evidenced by the case of reader.

What I'd really wanted to do for some time was to host my own RSS syncing service. Of course, there's not standard API for RSS syncing, so my favorite desktop clients wouldn't work. But with FeedDemon going away as well, and having no desktop replacement lined up, I no longer had to worry about that. So I decided to take a chance on a self-hosted web app and gave Tiny Tiny RSS a try. I was very pleasantly surprised.

The installation for TT-RSS is pretty simple. I use a shared hosting account, and though the documentation says that isn't supported, it actually works just fine. The install process for my host consisted of:

1. Copy the files to my host.
2. Create the database using my host's tool.
3. Import the database schema using using PHPMyAdmin.
4. Edit the config.php file to set the database connection information and a couple of other settings.
5. Use my host's tool to create a cron job to run the feed update script.
6. Log in to the administrator account and change the default password.
7. Create a new account for myself.
8. Import the OPML file that I exported from FeedDemon.

That's it. Note that half of those steps were in the TT-RSS UI. So the installation was pretty much dead-simple.

In the past, I wasn't a fan of web-based RSS readers. However, I have to say that Tiny Tiny RSS actually has a very nice UI. It's a traditional three-pane layout, much as you would find in a desktop app. It's all AJAX driven and works very much like a desktop client. It even has a rich set of keyboard shortcuts and contextual right-click menus.

As an added bonus, there's also a pretty nice mobile site. While the latest release (1.7.5) actually removed the built-in mobile clientweb site, there's a very nice third-party JavaScript client available. It uses the same API as the mobile clients, so the installation pretty much consists of enabling the API, copying the files to your host, and editing two settings in the config file to tell it the path to itself and to TT-RSS.

But who cares about the mobile site anyway? There are native Android clients! The official client is available as trial-ware in the Google Play store. And while it's good, I use a fork of it which is available for free through F-Droid. In addition to being free (as in both beer and speech), it has a few extra features which are nice. And while I may be a bit cheap, my main motivation to use the fork was not the price, but rather the fact that the official client isn't in the Amazon app store and I don't want to root my Kindle Fire HD. This was a big deal for me as I've found that lately my RSS-reading habits have changed - rather than using a desktop client, I've been spending most of my RSS reading time using the Google Reader app on my Kindle. The TT-RSS app isn't quite as good as the reader app, but it's still veyr good and more than adequate for my needs.

Overall, I'd definitely recommend Tiny Tiny RSS to anyone in need of an RSS reader. The main selling point for me was the self-hosted nature of it, but it's a very strong contender in any evaluation simply on its own merits. In my opinion, it's better than Google Reader and is competetive with NewsBlur, which I also looked at.

Last summer I learned a new acronym, courtesy of Chinmay. He asked for a developer to put some estimates on the outstanding technical tasks needed to make a demo production ready. So I fabricated a few numbers, slapped them on the wiki page, and dropped a note in the project chat room saying that I'd put up some grossly inaccurate estimates. Chinmay replied by thanking me for the SWAG - Sophisticated, Wild-Ass Guess.

The reason I like this acronym so much is that it pretty much sums up all the software estimates I've ever seen. I mean, it's not like there's no methodology to it - you look at the task, break it down into pieces, and apply some heuristic to attach a number of hours to each piece. But really, at the end of the day, it's all just guess work. The "heuristic" usually just comes down to a gut feeling of how long something ought to take based on your knowledge of the system. In other words, a guess.

And it's not like there aren't more organized ways of doing this. We could use COCOMO models to come up with our estimates, for example. The problem is, approaches like that require you to have actual data to use as a basis for comparison, and most teams don't have that. Or they do have it, but the data is useless - corrupt, fabricated, poorly defined, etc.

The reason it's hard to get good data on developer productivity is obvious to anyone who has ever worked in a pathological development shop - because it can be dangerous. In a good organization, such data would be used to estimate costs and schedule and to help make better decisions about what projects to do and where to allocate resources. In a pathological organization...not so much.

In a pathological shop, measurement is used against you. If the measurement is number of hours needed to complete a task, then you'll be judged to be incompetent or slacking off if a "simple" task takes you "too long" to complete - where what counts as "simple" and "too long" are determined by a non-technical manager who really has no idea what you actually do. Or perhaps you'll be required to account for all eight hours of your day, down to five-minute increments. Because heaven forbid you should "cheat" the company by taking a bathroom break.

When I think of pathological examples of measurement, I always think about my last job with an online advertising startup. At one staff meeting, our VP of Engineering announced that he new expectation was that engineering would deliver on its estimates with 90% accuracy based on 80% definition from the product manager. So we were required to be 90% sure how long a task was going to take, even though we were only 80% sure exactly what it was we were building. And based on previous experience with the product manager, calling the specs he gave us "80% definition" was really generous - I'd say it was more like 50%.

In that case, the productivity measurement was being used as a tool to force the VP of Engineering out of the company (and it worked - he put in his notice the next week), but the principle applies to anyone - if a measurement can be used against you - even if that use is unfair and out of context - assume it will be used against you. That's a very sad reaction to have, but it's natural if your experience is primarily with unhealthy shops. And while I don't endorese such a paranoid attitude, having been in such a shop more than once in the past I can certainly understand it.

One of these day, I'd really like to work in a shop where performace metrics were used as a real tool in project planning. Even in healthy shops, this sort of thing seems to be uncommon. That seems to be something of a comment on the state of "software engineering" as a discipline. The differentiator between quality and pathological shops seems to be the absence of bad practices as opposed to the precense of good ones. Even in good shops, building software seems to be less engineering and more art or black magic.

Personally, I'm not convinced that that is a necessary or desireable state of affairs. I'd just like some first-hand evidence to support that suspicion.

Two quick humorous items that came up in the last couple of days.

First, some animated GIFs describing moments in the life of a programmer. They're funny because they're true.

Second, a joke that evolved during a two-hour conference call I had on Tuesday:
VP of Engineering: "There are really only two problems in programming: cache invalidation and naming things."
CTO: "And off-by-one errors."
<Laughter slowly builds as people start to get the joke.>

I have a new side project. It wasn't one I was really planning on, but it's the fun kind - the kind that scratches an itch.

You see, I've become a big fan of the Roku set-top box. I have three of them in my house. And in addition to using them for Netflix and Amazon Instant Video, I also use them to stream video and audio from my desktop PC (which has become an ersatz home server). For this I use an application called Roksbox. It allows you to stream videos from any web server. So since I already had IIS running on my PC, all I needed to do was set up a new website, symlink my video directory into the document root, and I was ready to go.

The problem with Roksbox is that it's a bit basic and the configuration is a little clunky. For example, if you want to add thumbnail images and metadata to the video listings, you have two options:
1) Put all the information for every video in a single XML file.
2) Turn on directory listings for your server and use one XML file and thumbnail file per video.
The problem with the first option is that it's ludicrously slow. By which I mean the interface can freeze for upwards of 30 seconds while Roksbox parses the XML file. And the problem with the second method is that you end up littering your filesystem with extra files.

This was particularly the case when I looked at adding thumbnails for a TV series. All I wanted was for each episode to have the season's DVD cover art as a thumbnail image rather than the default image. Unfortunately for me, in order to do that Roksbox wants you to have one image file for each episode. So I either needed a bunch of redundant copies, or a bunch of symlinks, and neither of those options appealed to me.

So I decided to try something - faking the directory listing. That is, I wrote a couple of simple PHP scripts. The first read the contents of a directory and simulated the output of the IIS directory browsing page, but inserting thumbnail entries for each video. So, for example, if there was a video "Episode 1.mp4", the script would add an "Episode 1.jpg" to the listing. The second script worked in conjunction with a rewrite rule for non-existent files. So since the "Episode 1.jpg" didn't exist, the request would be sent to the second script, which would parse the request URL and then redirect to an actual, existing thumbnail image. The result was that I had my images for every episode in the season and I didn't have to create any pointless links or files.

This worked so well that, naturally, I took it to the next level. I started branching out and added more support for customizing listings, such as hiding and re-ordering directories. Then I started getting really crazy and wrote code to generate listings for entirely fictitious directories in order to create video playlists. I even started writing admin pages to provide a GUI for configuring this stuff, built an SQLite database to save the information, and created an ad hoc application framework to help manage it.

I think the reason this little project really caught my interest is that it's something that I actually use on a daily basis. I've been trying for a while now to find a side-project that I can use for picking up new languages or technologies, but nothing ever seems to stick. I'll play with something for a while, but them lose interest pretty quickly when some other obligation comes up. I think that's because those projects are just excuses - I'm doing them because I need a project in order to learn something new, but I have no particular interest in that particular project. But even though I'm not using anything new for this project, it grabs my attention because it's something that I want for myself. That's something I haven't had in a while, and I really like the feeling.

If anyone is curious, the current code is in my public mercurial repository here. I'm planning to put up a proper release of it when it's a bit more together. For now, I'm just having fun making it work.

This is just another "note to self" post, so that I have something to refer back to later when I forget this again. Nothing to see here - move along.

Without further ado, here's a link for how to configure ISC BIND on Windows. This should have roughly the important details, with the exception of file locations. Per the company guide, I have my BIND files in C:\Windows\System32\dns. Note that this is restricted to admin accounts, so it won't show up in explorer with my regular account. I lost 15 minutes figuring that out the other day. Also, here's a link on the managed-keys-zone error I was getting in the event log. That turned out to be the fix for my problem where BIND was starting, but DNS queries weren't working.

If you're not me and you're still reading this, the motivation for this post was configuring a new development VM for work on my home Windows box. Normally, we're a Mac shop, and the company provides MacBooks for anyone who requests a computer. However, mine broke down and is in the shop, so I had to set up my Windows box with the development environment.

There are just two problems here:
1) Our codebase, despite being PHP running on a Linux VM, is actively Windows-hostile.
2) We require wildcard DNS for subdomains.

The use of BIND is to address the second problem. For the occasions when someone tries to run the VM on Windows, BIND is used to send the DNS queries for our development domain to the VM. Of course, we could just set the Windows DNS server to the VM itself, but that has the down side that your DNS breaks when you shut off the VM.

And if you're curious about the first problem, all you need to know is that our codebase is full of directories named "v.", which is just fine on UNIX-based systems, but is an invalid directory name on Windows. There's a good reason for that - trust me - but it's too long to explain without the relevant context. (Of course, there's no reason that it has to be "v." - the guys who came up with that could have just used a different naming convention. But they didn't, and now we're stuck with it.)