Quick Hit: Taming Notepad++’s Language Menu

W00t! Notepad++’s language support is awesome. It supports so many languages that navigating the languages list (e.g., if the file extension doesn’t match the registered extension) is a bit of a pain. Fortunately its contents are editable!

image

Now to remove the ones we don’t use here…

The Task Machine Gun

It happens all the time. The hallway discussion. The quick chat at lunch. The regularly scheduled meeting. Upon reflection you realize it happens pretty much every time you talk to this person. Every encounter results in a new list of tasks for you to work on.

You've been hit by a Task Machine Gun. It's reason for existence is to spray task bullets all over the place in hopes that a few hit the mark. The Task Machine Gun doesn't feel like it's being productive unless task bullets have flown.

There are many circumstances where the Task Machine Gun is exactly what you need. Take a production line. Each station in the line has been simplified as much as possible. To meet the goal of producing X widgets per hour you basically need a Task Machine Gun to make sure that the simple procedure is executed frequently. These days most of these jobs are done by machine.

Delivering an always available, outrageously scalable set of software services is pretty much the opposite of a production line. The Task Machine Gun in this circumstance can do quite a bit of harm because each task takes on a life of its own that lives long after its reason for being is even remembered.

What do you do when you realize there's a Task Machine Gun loose?

Duck! Figuratively of course.


GMail's Categories

GMail's new category system* has definitely grown on me. There are a lot of things I miss from Outlook but auto-categorization is awesome. There is a small learning curve which can be shortened by reading the 1 sentence description of the new categories (from the desktop website - hover over them and +5 for simple discoverability in the User Interface!).

The more I think about it, the more it strikes me that this system has a very real advantage over the fixed rules approach. The problem with those rules is having to maintain them as they inevitably become out of date (distribution list name changes, email address changes, etc...). 

The built in categories are great: Priority, Updates, Social and Promotions (aka spam-lite). For example: my apartment complex sends out a "delivery for you" email whenever a package arrives. I want to know about that immediately so I've dragged those into the Priority inbox. I've only had to do this 2 or 3 times before the system learned to automatically put them there. It somehow figured out that I don't really care too much about the "buy stuff from this vendor we sold ad space to" type messages (they go in Promotions). 

When it miscategorizes an email it's easy enough to correct by moving it to the right category. This can be done on phone but I've found that it's faster for me to recategorize a bunch of messages at once on desktop.

I expect mass mail campaigns to optimize for (or against) gmail's new system. Given that it learns from me dragging and dropping stuff into the right category it should be harder to game the system for long.

Since I've given up on manually categorizing** high frequency information streams I kind of appreciate the balance they struck between broad applicability without overwhelming granularity. Once a list has 7 or more elements in it IMHO it becomes unmanageable for most and has to be generalized/massaged/abstracted back into some set of 7 or fewer buckets so that humans can manage it without too much overhead. Kudos for cutting that magic number in half (due to User Interface concerns I'd guess).

While it takes some manual categorization before to get the system from a totally anecdotal guesstimate of 67% accuracy up way above 95%+ accuracy the up-front work is easy enough and infrequently required enough to not outweigh the substantial benefit of having a personal software agent helping me sift the wheat from the chaff.

Editing a Wiki from a smartphone

I recently listened to a podcast about a model of consciousness that relies on quantum mechanics. The theory, called Orchestrated Objective Reduction, posits (not uncontroversially) that consciousness arises when the wave function collapses in the apolar hydrophobic regions of microtubules in the brain.

That's a mouthful but, being a digital citizen, I figured I'd weigh in on the wikipedia page. As usual I'm on my smartphone. Coincidentally almost all of my listening and news reading is done on my phone. As was this post.

First problem: How do I get to the talk page? This is traditionally where you start before making edits to a page. I couldn't find a link to it on the mobile site.

Manually inserting Talk: before the last part of the URL does the trick. Seems like there should be a "talk" or "discuss" link somewhere...

Second problem: How do you take part in the discussion?

It looks like the convention is to pick a section, edit it then add your comments to the bottom. Followed by some moniker to delimit the end of your comment. Egads, somebody introduce these guys to the year 2000. Even phpboard would be a better discussion system...

Bridges to Somewhere: Design Patterns wikis

So there's a bit of infrastructure that's critical but somewhat neglected because of more pressing problems. As the list of more pressing problems gets shorter (that's successful engineering - happy dance!) tending to this piece of infrastructure becomes more pressing.
 
Let's call this piece of infrastructure AbInitoWidget (AIW).
 
The grand vision is to get rid of AIW. Fold its functionality into a different piece of infrastructure. Let's call this other piece of infrastructure InitioWidget (IW). IW has had heapings of engineering cycles dedicated to it and is in much better shape.
 
Alas, the path to the grand vision of folding AIW into IW is long and fraught with peril. The kind of peril that requires the expertise you'd really only find in the original authors/devs. Without that kind of expertise each break/fix cycle will take much longer as the current devs reverse engineer the intent of whatever code path they're tasked with fixing.
 
Don't get me wrong, I too am seduced by the idea that IW could operate ex-nihilo. It's a self-referential beauty that any Computer Science geek would love. But the costs are so high that it's wise to adopt a fallback strategy (or 3) in the event that the grand vision does not come to pass.
 
While discussing one fallback strategy, moving the care and feeding of AIW from BadErrorProneHardToDiagnoseAIWCareAndFeeder (BadCareAndFeeder for short) to the care and feeder responsible for IW (GoodCareAndFeeder), I found myself thinking through design patterns that might help.
 
The first that came to mind was the Bridge pattern. Since we'd like to change AIW from being maintained by BadCareAndFeeder to GoodCareAndFeeder this struck me as being visually like a bridge. This is incorrect. The bridge pattern decouples abstraction from implementation so that both can evolve independently. While it may be involved in the the Bad-to-Good-CareAndFeeder migration project it doesn't actually capture what I was looking for - a higher level abstraction than the classical Gang-of-Four Design Patterns.

Fortunately Wikipedia has wonderful sections on design patterns. Two of my favorites are:
  1. The wiki for the foundational Gang-of-Four book "Design Patterns: Elements of Reusable Object-Oriented Software"
  2. The "Computer Science Design Patterns" wikibook.
    1. Not quite as polished as GoF.