Spifftastic,

 

Spifftastic RSS Feed

Hey, turns out the RSS feed changery is unnecessary. The FeedBurner URL will continue to work, of course, but mod_rewrite appears to have taken care of most issues with the change-over (all permalinks still work and whatnot).

If you’re currently reading this via an RSS reader, you should probably update your feed URL to the new FeedBurner URL at http://feeds.feedburner.com/Spifftastic. Ordinarily, I would like to avoid changing the feed location, but I’ll be moving Spifftastic over to OakTree shortly, and given my infrequent updates, would at least like to give folks a chance to switch over before I pull the plug on the old feed (which will be replaced with a new feed that FeedBurner can automatically move you to).

There will be a few more changes to Spifftastic, including the addition of a Google +1 button (until I decide I hate them) and the removal of the site’s search function (because it’ll be static HTML). I hope these changes won’t affect anything drastically, as the button is fairly small and part of the post meta and the search function never really got any use anyway.

So, update your feeds and you’ll be good to go when I finally plant OakTree.

bork: Shell to Ruby

bork is my tiny file-tagging utility that essentially maps files to hashes and hashes to tags and so on using the filesystem. It could also probably use a regular db like sqlite, but it doesn’t. This post is mostly discussing one of the important changes that happened while building bork: the transition from shell script to Ruby.

bork initially started out as a series of shell scripts with a fairly simple structure inspired by git (whether git is actually structured this way, I do not know, I’m simply going off appearances): a main jumppad sort of script that calls into other scripts that actually do what I want. This ultimately led to a structure that basically looks like this:

|++ bin
    |- bork
    |++ bork-exec
        |- bork-add
        |- bork-relative-path-to
        |- bork-rm
        |- bork-station
        |- bork-update
        |- ... and so on

This sort of structure actually lends itself fairly well to the particular idea I was going for, where you can work with bork in two different ways:

  1. By using the jumppad script: bork add ...
  2. By using the scripts directly: bork-add ...

The reason this worked well is that each bork command depended on other bork commands. Most bork commands depended on bork-station to get an absolute path to the nearest bork station, the directory containing all hashed files and tags and so on that allow bork to work. It works in a fashion similar to git as well (and likely Subversion and other tools like them) in that it searches the current working directory (CWD) and all directories above the CWD for a station. Almost all commands required a bork station, so they’d run bork-station to get a path (if there was one) and do their thing. Some others depended on bork-update, such as bork-rm and bork-find, both of which modified the station and therefore depended on it being up-to-date.

A second upside is that this potentially allows me to replace various commands down the road with new implementations. Ideally, I should be able to pull out an old shell script, replace it with something written in C, and call it good. Shell script isn’t particularly fast, so I was expecting this to become an issue fairly quickly, and I was right.

What I was wrong about was the ease with which I can replace commands with new implementations. To do a new implementation that doesn’t simply go out, run a new process to do something, and return some results back to the calling command means rewriting most of bork in the new language. Having two separate implementations of a particular aspect of bork isn’t really the best idea, so the way I saw it was fairly simple: rewrite the whole thing and ditch the original structure or put up with the less than pleasant idea of dealing with reading/writing from pipes to other processes. Not too difficult, but also not fun. The latter is unpleasant enough to do a complete rewrite, so rewrite I did.1

I was more or less settled on using Ruby for the project, so that was the target language. bork’s predecessor, a series of Ruby scripts to do roughly the same thing,2 had proven that Ruby was good for the job, so it wasn’t about to change. Next step: gemification (this was the branch name). bork was originally a tool to generate Makefiles, so I had a gemspec sitting around for it and recycled that. The directory structure was mostly there already, though at the time you wouldn’t have known it by looking at the git repo.

I kept the jumppad script, which had always been written in Ruby for convenience (its Kernel#exec provided an easy way to jump from bork to the command script). It was heavily refactored, but for the most part you can see a lot of the same code in the same places. I moved command scripts into individual Ruby files under a Commands module, each registering itself with the default Bork::Hub instance, which collected command classes for the jumppad and allowed commands to run other commands (provided they’d been loaded).

The Bork::Station class ended up becoming the most important class, containing all methods for accessing data contained in any given station and manipulation those stations. I’d ordinarily feel bad about this, but stations are so small in their functionality that the class never becomes too big. If anything, some of the methods could use refactoring into smaller methods, but otherwise the conversion went fairly well. The important point of this, however, is that the Bork::Station class is effectively bork – everything that makes bork bork resides in it. The hub is only there for the jumppad’s sake and the command classes simply get to a station and do stuff with it.

So this means that there is an opportunity to build other projects around bork’s stations. It’s entirely possible that one could subclass a station and add new functionality to it, new metadata, and so on. So, there’s a lot of potential there, provided I refactor the hell out of some of the functions. Eventually, it would be nice to split up the station into the interface and a backend. Either that or simply define a base class for stations to implement and let them go from there. Who knows what maddening things I could do there.

So, that’s bork’s shell to Ruby conversion in short. I have to say, it was a lot of fun writing bork, so I’m glad Ruby makes this stuff so pleasant.


  1. There were probably other options I didn’t consider or ignored, but these were the biggest ones on the table. I treat the shell script version of bork as a prototype that got the idea working and the station structure set up, while the Ruby implementation is the current end goal (until Ruby is too slow). [return]
  2. Long lost to accidental deletion. This was when I didn’t use version control (git wasn’t terribly accessible yet and Subversion was a huge pain in the ass to set up) and keep all my neat toys in some project directory. These days, I’m a little more careful, though I admit to sometimes using rm -rf to wipe out entire directories without thinking. [return]

I Left Facebook

I expected I would close my Facebook account for a long time now, but I finally dropped it. Last night I deactivated my account. Once I’ve determined I have all the data I want out of it, I will permanently delete the account.

Why leave Facebook now? Mainly because they moved everyone’s email address over to an @facebook.com address.1 This by itself is a fairly benign change at face value, but it also creeps me out and violates my one rule of social networking: never modify the information a user provides.

By changing everyone’s visible e-mail address, Facebook likely hopes to route all communications through its servers. Access to user emails gains them further access to personal information in e-mails and such, and that information furthers their advertising goals. Google more or less does this with Gmail already – it’s not as though Facebook has committed themselves to some heretofore unseen evil. However, I trust Google more than Facebook. This level of trust is likely arbitrary, but it’s still there. As such, the one rule comes into play.

The assumption I make with a social network is that the data I give them is immutable on their end. They are then free to connect it to other data, do whatever creepy things they see fit to do in the background, and generally do the usual slimy things with my data. But for the profile I give them, I expect the data to remain as I set it. If the network changes my data, it has then violated the idea that I control my information. Facebook disagrees with this rule and believes they control my information. I’m obligated to condemn their actions, so I danced my worthless protest and closed my Facebook account.

For now I’ll reside mainly on Google+ and Twitter. Google still retains more of my trust than it perhaps deserves. That said, it’s not entirely misplaced: they’ve stored my emails in relative safety for years. Twitter seems benign enough that the information they have seems useful only in a union of all other social network data. Therefore both retain my membership for the time being.

Adiós, Facebook. I won’t miss you.


  1. See Ars Technica’s article for more on the subject. [return]

The End: Ascension

Over a year ago, I programmed, designed, and shipped Ascension. It made a small headway as a live wallpaper but never did particularly well. Live wallpapers occupy a niche of the Android Market, now Google Play, and serve no utility. They provide mild entertainment and pleasure, but developers give you little reason to purchase one. The best we can do is show a picture of it that looks pretty cool. Ascension looks pretty cool. I still think it looks pretty cool and represents a sort of higher-end in live wallpapers. Users customize it to suit their tastes, and customization sits as the most important feature of Ascension. Folks still wanted more, but I didn’t.

I privately declared Ascension a finished project some time ago, mostly around when I finally decided Android development depressed me. A few users have since contacted me and learned this as well. I’d never declared a project finished before, at least not a user-facing one. Sure, I’ve made libraries and they’re finished, but nothing sold directly to consumers. The decision came easy, though: I wanted nothing else out of Ascension, wanted nothing to do with Android, so I stopped. I prefer to work on what makes me happy. Working on Ascension brought only the opposite feeling. So I stopped.

Ascension became feature complete the day I released it, with bug fixes and small additions afterward as a sort of bonus while it continued to sell well enough to cover a cheap meal a day. But sales slowed down despite updates and I decided then that only bugs would get me to update it. Then I decided that only bugs that I could test would get me to update it. Turns out Ascension lacks many bugs, if any. I’d received a few bug reports of unusual foreign handsets failing to run it, but I honestly didn’t care. They appeared to fill the cheap phone role, and I had no interest in supporting those users. They were all Lite version users anyway.

The Lite version may have been my one big mistake. I released a feature-stripped version of Ascension for users to try, mostly as an experiment. If it resulted in increased sales, the free version would stay. If it hurt things, it would go. Unfortunately, results were mixed, and I let the Lite version be. Ultimately, it seems more likely that only people interested in getting a free app downloaded the Lite version. I pulled it from Google Play earlier this year.

In the end, Ascension pleased a good number of people. The e-mails users sent me seem to prove that. The comments on the app seem to prove that. The consistently high rating on the Market seems to prove that. I made something I wanted for my phone, sold it, and easily made back the cost of development. It was a worthwhile project. But it’s done, so I suppose I should get back to my current project. Back to the project that makes me happy.

Sublime Text 2 Theme — Nil

Today I released my Sublime Text 21 theme, Nil. It’s comprised mainly of solid colors and tries to communicate mostly through what I hope is a quick and obvious use of color rather than an attempt to be too flashy. Though it probably is slightly flashy just for being a dark theme. Have a screenshot:

The Nil Theme

Regarding colors, blue is the active buffer/selection, orange is a dirty buffer/selection in tabs and open files, and subdued orange is inactive and dirty in tabs and open files. Aside from that, everything is a shade of grey and keeps my eyes in a state of relative happiness. In particular, the tab colors are intended to communicate state better than something that might be easy to overlook, like a little dot.

Installing The Theme

The theme can currently be downloaded on Github. I’ve submitted it for inclusion in Sublime Package Control, though if and when that happens seems indeterminable right now. Installation is fairly simply, and the README covers it all. However, for the sake of simplicity, or in the event that you don’t want to visit Github, the instructions are as follows:

You can download or clone the repository into your Sublime Text 2 Packages directory. To do this, simply navigate to ~/Library/Application Support/Sublime Text 2/Packages (or wherever it is on your particular operating system) and run the following command:

$ git clone git://github.com/nilium/st2-nil-theme.git 'Theme - Nil'

It’s very important you clone the repository into the Theme - Nil directory otherwise the theme won’t locate its assets and will take on an eldritch appearance. You don’t want Shub-Niggurath crawling out of your screen, so remember, put it in the right directory.

So there you have it. If the theme appeals to you in any way, go right ahead and download it.

Acknowledgments

The theme itself is a fork of Raik Ilves’s Pseudo OSX theme, which is in turn a fork of Ian Hill’s Soda theme. So, we’ve got a bit of a chain going now. Additionally, I would not have done this at all had I overlooked Liam Cain’s Refresh theme, which is another nice alternative. Basically, if you don’t like the Nil theme, these three are all excellent alternatives. I wouldn’t have done this without the three of them. Check ‘em out.

Starting with The PlayBook

Back around the end of March, I posted on Twitter that I wouldn’t be able to develop for the BlackBerry PlayBook because I simply couldn’t afford a device. It interested me, much in the same way webOS interested me. The PlayBook is a 7-inch tablet that never gained traction in the market, but it’s still a device running an interesting operating system: QNX.1 Interesting means I want to code for it. But there’s the cost. So, following that tweet, two folks from RIM contacted me and asked for my address. Not long afterward, they shipped me a PlayBook, and since then I’ve fiddled with it and its developer tools.

The PlayBook itself is much nicer than I’d expected. RIM knew how to create a nice OS and a nice tablet, at least. In particular, it doesn’t feel cheap. My HP Touchpad suffered from creaky plastic, it felt cheap, but the PlayBook avoids this. The device has a back coated in some rubber-ish material which makes it pleasant to hold. The power button, despite what reviews have said about difficulty using it, seemed easy enough to press. Overall, it’s a very nice piece of hardware and remarkably comfortable in the hand.

The only complaint I have about the device itself is its bezel: RIM printed “BlackBerry” across the bezel. If I pick up the device and hold it at any orientation other than the text’s, it looks stupid. The iPad benefits here from having really no markings on its front aside from the home button, and that doesn’t demand a proper orientation. If I pick up my iPad and start to use it upside down, the screen will reorient itself. It doesn’t look stupid, it just works. It accommodates the user. I’m not sure why RIM feels it must remind the user they’re holding a BlackBerry device, but, again, it looks stupid.

The PlayBook ships with a number of apps and their quality varies, which I expect. Most apps are reasonably nice, but slow. I just expect scroll lag in non-iOS software now. webOS suffers from it, Android suffers from it, and QNX, the PlayBook’s OS, suffers from it. It’s especially noticeable, of all places, in App World, RIM’s app store. When I attempt to scroll through applications in App World, it stutters through a small list of applications, frustrating me. This is curious, but I assume it’s a side-effect of certain applications using either Adobe AIR or WebWorks (essentially HTML/JS apps). AIR apps all seem to suffer performance issues. I haven’t seen many WebWorks apps, but I assume they suffer the same – browser performance on these devices just isn’t there. The iOS can’t handle it, and my own little tests with WebWorks seem to show the PlayBook can’t either. Maybe future browsers and devices will make web apps appear equal to native apps, but until then it’s a bad idea.

This presented a problem for me when I decided to look at how a developer might make a fairly normal GUI app. Currently, you have two options: Adobe AIR and WebWorks. Again, these suffer from performance issues. The WebWorks route is simple, but RIM offers developers very little assistance. There is no usable GUI framework via JavaScript. You’re very much on your own there, which is fair enough for web apps, but makes it difficult to create apps that fit in with the rest of the OS.

AIR offers a GUI framework of sorts, but the performance issues are so frustrating that I can’t imagine subjecting a user to them (and yet RIM has done just that). In addition to that, I find the entire development process for AIR apps frustrating. While WebWorks keeps the process simple, AIR seems built only for developers using Adobe’s wonderfully overpriced software rather than command-line tools. So, if you’re not willing to pay anywhere from $250 the $700 USD, you might as well ignore AIR altogether.

Your third option2 for app development is the NDK: C and C++, not much else. You get your common libraries for these devices, including OpenGL, APIs for the OS and its windowing system, and other expected libraries. That’s about it. This should change with the next version of the OS, apparently BlackBerry 10, as RIM introduces Qt and Cascades, the latter a framework used by The Astonishing Tribe (TAT). To put into perspective how important that last bit is, let me just say that the applications that seem most apparently built by TAT are also those that never experience lag. Never. Their apps, however, are also about as useful as toys, so make of that what you will. Currently, however, Cascades and Qt are not exactly ready. You can demo them now, but I don’t imagine you’ll make a PlayBook app using either.

The NDK, despite its lack of a GUI framework, is actually the nicest of the three options for application development. Game developers in particular seem pretty well off here. RIM provides some utility code to create an EGL context, render text, handle orientation changes, and so on. It’s not much, but it reduces the amount of code one has to write. Additionally, one can inspect the code to see that it’s not doing anything funny and otherwise just learn how RIM expects developers to handle things. I think RIM knew what they were doing here, so it’s a shame that they didn’t put more into it. AIR and WebWorks are, by comparison, garbage. AIR in particular offers the most tortuous route to application development. WebWorks is nice but it’s too early to view HTML apps as competitive with native apps. For someone like me, the NDK is really the only good option for PlayBook development.


I’ll probably continue writing some posts about this, but this should serve as a sort of introductory post for future writing on the PlayBook. If there’s something in particular someone is curious about, I’ll be glad to divert some focus to that as well. Personally, I’d rather write about development, so now that my semester is over and I have a summer’s worth of time to do some work, I’ll try to offer some sort of commentary on development for the PlayBook and other devices.


  1. Officially, I believe RIM refers to the OS as “BlackBerry Tablet OS.” Not the marketing department’s finest work. Later, they’ll probably refer to it as “BlackBerry 10” when that’s released. That said, I prefer “QNX.” It’s simple. [return]
  2. There is a fourth option for application development, but I cannot in good faith ever recommend it to anyone: Android development. The PlayBook ships with some bits of Android, but the results are terrifyingly bad. All Android ports for the PlayBook feel cheap and look completely out-of-place on the device. This might appeal to developers who don’t care about the PlayBook, but otherwise you should avoid this option like the creepy doll in your attic. And trust me, that creepy doll lives in your attic. You just don’t want to remember. [return]

Zero

Count the number of new “social networks” focused on providing some equivalent to a “Like” button for something other than the web in general. Count the number that require you to take a picture of it and share said picture. Count the number that focus on food, especially. Particularly count those with a focus on mobile phones, often with their primary interface being through a phone. Count the number that actually claim to be a “Like” button for the rest of the world.

Now count the number that don’t suck.

OakTree, the Blog Tool Thing

Sometime after the new year, I began work on a small project to replace WordPress with my own blogging tool. The goal was to meet all of my needs and absolutely nothing more. The product of this work is OakTree, so named for the WordPress theme I designed for Spifftastic. Aside from that one mention, OakTree in this post refers to the OakTree gem and blogging tool thingamajig. So, let’s run down a few points that I’d like to ramble about, because OakTree is eventually replacing WordPress on this site.

This post is fairly out of date. Spifftastic now uses Hugo. You can see the last section of this post for the general reason behind that decision.

What Is OakTree?

I cover this in the README for OakTree, but it is essentially a tool to generate a static HTML blog. It takes in a series of posts and spits out the blog. It is very simple to use, seeing as there are a grand total of four commands you use to interact with the blog via the oak tool: init, newpost, sync, and rebuild. The last two are the same thing with a minor difference, so it’s actually much closer to three commands.

An OakTree blog is comprised of two things: templates and posts. Posts are stored in a source/ directory, templates in a templates/ directory under the blog’s root, and the generated content under public/. Posts are Markdown files with a bit of metadata at the top to store a post’s title and time (in case you want to, say, publish something with a future date). Templates are written using the wonderful Mustache, so it’s very simple and very easy to get things working.

To start a blog you run oak init in some folder or other and your blog is generated. This produces a blog_spec file with some data about the blog you’ll need to customize, as well as source/, public/, and template/ directories. The template directory comes with a basic blog.mustache template file that you can then customize to whatever ends you like. It’s actually not that bad of a starting template if you like barebones sites. After that, you create some posts and run oak sync (or oak rebuild, if you’ve modified templates or something looks off, to regenerate the entire site).

Like I said above, this is simple. OakTree is not trying to do everything, it’s just trying to do what I want in a way that’s easy for me to use. It’s slightly git-ish, though far less sophisticated and probably nowhere near as fast. The important thing to remember is that OakTree is made specifically to do one thing: generate a blog. It doesn’t run a preview server, it doesn’t monitor your filesystem, and it doesn’t do much of anything sophisticated. It’s dumb and predictable and I like it that way.

One minor note: OakTree is a Ruby gem. It is written entirely in Ruby because that seemed like the easiest way to get things running. Turns out I was right, Ruby is the easiest way to get things running. I don’t really want to focus on how OakTree is implemented or what language it uses because it doesn’t matter and nobody gives a shit. It might be important to anyone who attempts to use it for their own site and decides they want, say, post categories. They’ll have to dig through the Ruby and prod me with questions to do that, but it’s really not important.

What’s Wrong with WordPress?

Though there’s nothing particularly wrong with WordPress, it tends to lean on the overkill side of things. WordPress tries to be everything to everyone, it is the universal blogging tool of blogging tools. This is nice and it shows a great deal of care on Automattic’s part, but this also means I’m stuck customizing a tool to fit my needs.

Take link posts for an example of a feature not built into WordPress – these are currently a hack sitting on top of the OakTree theme and rely on custom fields in posts. Just getting them working was a pain in the neck, and they’re still not quite right. OakTree does them exactly how I need them, and doesn’t require using filter/action hooks to make things work.

After that, we have databases and gigantic amounts of code that I know nothing about. How long would it take to familiarize myself with WordPress’s source code? Probably longer than I care to spend. Additionally, working with a database means I have to keep backups of two separate parts of my site, and having done this a couple times already (switching hosts and whatnot), I know I don’t want to deal with restoring from a backup again. It’s not very fun. Overall, it just means there’s more I have to concern myself with, and I would much rather not think about how my site works (strange as that sounds).

OakTree as a result is static HTML. There’s no database, no admin page, no configuration files on the server, nothing other than site content. It’s very convenient. It’s not particularly clean, considering it makes a mess of the filesystem, but the way the resulting blog is structured works well enough that it’s not terrifying either. I imagine it’s very rsync-friendly.

What’s Wrong with <Other Tool>?

I looked at a few other tools before starting this. One was Octopress, which I believe I heard about by way of Matt Gemmell. It’s a pretty nice system, and I’d recommend folks check it out just because it’s quite neat. Problem is that it’s also very large, and I don’t quite know what’s going on in it, and customizing it looked like it was going to be more trouble than it’s worth. So I’m not using Octopress. I had a hard enough time installing it in the first place, so I just don’t want to work with something that I don’t fully understand. Further, Octopress uses Jekyll which in turn uses Liquid. Liquid is not fun. I’d much rather have a mustache than diarrhea, however that goes. That’s not an objective opinion, by the way – I just plain don’t like Liquid.

Movable Type is another nice tool1 that’s far too large and menacing for me to wrap my head around. It seems to require a database, but may not use it to provide content — just for working on the blog, so that’s a plus. It’s a nice trade-off. That said, it didn’t get rid of the database, so I’m not entirely comfortable using it. I’ll also reiterate the “far too large” comment: Movable Type is an old (sort of) tool, and that usually means there’s a lot under the hood. I’m not interested in figuring out how to work with it (which is obviously a failing on my part), so it’s off the list.

There are probably some other tools out there I looked at but dismissed just because they disagreed with me in some way or other. Overall, my needs were so simple that it made more sense to just write a quick tool to do this myself.

Does Spifftastic Use OakTree?

As of December 20th, 2015, Spifftastic now uses Hugo. This is largely because I don’t want to continue maintaining OakTree, but also that Hugo allows me to focus less on fixing things in OakTree when they go awry (and they often do, since the version I use is a private fork of my own code just so I don’t have to share certain things).

Besides that, OakTree’s obviously written in Ruby. Much as I love Ruby, this makes it that much harder for me to jump back into working on OakTree. It was the first gem I wrote, and it is undoubtedly poorly written. It was great for doing a bunch of string processing, and Kramdown remains my favorite dialect of Markdown, but maintaining that code is awful. Hugo, on the other hand, is written in Go, and after I’d made Go one of our primary languages at Kochava, I have a better appreciation for how easy it is to just dig around Go source code and figure out how it works. Besides that, it’s faster to work with. No fault of Ruby, in this case, just an issue with old code.

Yes, it does. As of August 9th, 2012, Spifftastic uses OakTree for rendering. Prior to this, the transition was mostly on hold while I took care of greater priorities, especially my education. Once free time came around, I went back to finishing off the few remaining points needed to move Spifftastic to OakTree: RSS feed generation, static pages, and increased stability. RSS feeds were my main concern, as they provide the main window into blogs for many users. Static pages could have been kludged, but were easily implemented thanks to the way OakTree handles blog modes, so to speak.

Prior to this, OakTree has been used for a couple other projects of mine. This includes .nil?, my GitHub personal page. It did, at one point, generate Spifftastic (as the striked out text above says), but no longer does.

Ha, no, of course not. See, there’s a problem: I have to move everything from the database to source files. In addition, I have to convert my WordPress theme over to OakTree (this is the best way I can think to word this other than “I have to port OakTree to OakTree”). OakTree isn’t finished either – it still needs support for RSS feed generation (which I imagine is fairly simple compared to the rest of the project). The process of moving Spifftastic from WordPress to OakTree will be very slow, but it’s inevitable.


  1. I call all these things tools because I view them as just that: tools. They’re things that should help me accomplish something. Others view them as blogging platforms or what have you, which seems a bit like overkill to me. Sometimes all you need is a hammer, not a pneumatic nail-pounder. I don’t know if a pneumatic nail-pounder exists, but it sounds cool. Might just be a fancy way of saying “nail gun.” [return]

Google, what were you thinking?

According to Mocality’s CEO,1 Stefan Magdalinski, Google has been trying to steal their business in a very bizarre way:

I did not expect to find a human-powered, systematic, months-long, fraudulent (falsely claiming to be collaborating with us, and worse) attempt to undermine our business, being perpetrated from call centres on 2 continents.

Stefan’s evidence is damning, to say the least, especially when the address accessing their databases comes directly from Google. I’m not sure that Google proper (as in Mountain View) would have approved this, but from their recent changes to search, it’s hard to say what they might be doing anymore. Perhaps they’ve just instated a new motto: “Do no good.”

Honestly, though, I don’t believe this is known within Google, at least not outside of some corrupt group.2  The lack of technical prowess (“human-powered”) about the operation is strange for Google, given its tendency to over-engineer its way out of all situations. Where’s the MapReduce or the AI callers with synthesized voices?3 As much as I would love to believe this goes all the way up through Google, this sounds like something a small group wanted kept under wraps - it’s still pretty damned awful, but no reason to break out the tin foil hats.


  1. Via beamso over on the Ars Technica IRC happy-land. [return]
  2. You are free to debate (since I like responding to comments) how corrupt Google is overall and what have you. Let’s just say that whatever the corruption status quo is, these guys are four times that. [return]
  3. Does Google use AI with synthesized voices to handle calls? That’d be neat, though I’m sure it would rapidly become just as frustrating as all other voice-recognizing call handlers. How many times have you been forced to shout and mash buttons (or the screen) on your phone due to those fun little things? [return]

vim-powerline

Powerline

Powerline is a Vim plugin by Kim Silkebækken “which allows you to create better-looking, more functional vim statuslines.” Basically, it makes your status line easier to read and look awesome. Installation is pretty simple if you use either Pathogen or Vundler (I prefer Pathogen), but it does require some custom fonts to get the full fanciness effect. Powerline comes with a patcher to patch existing fonts, but there are some pre-patched fonts kindly provided by Nick Quaranto over in a gist, including Menlo.