Running as Root

I was checking my meager blog stats over on StatCounter (which I recommend) trying to figure out how the 2 people that read my site today arrived there. As a quick aside, if you ever want to get more people coming to your blog you should write a lot about cell phones (like this guy). Just over half of my search engine hits are the result of a quick post on making a Ms. Pacman ringtone. The breakdown by search engine wasn't what I expected either: 66% Yahoo!, 23% MSN, 9% Google.

Anyway, I'm off subject. I eventually wound up at my Google AdSense account wondering about my inability to get good clickthrough. I'm sure pathetic traffic is a part of that. Well, I went to my site and noticed that the ads didn't show up. I went through a few minutes of "debugging" before realizing that my AdBlock extension (with FilterSet.G thanks to Matt Ray) was doing its job very well. Long story short, my ads show up–my clickthrough and traffic just suck.

That brings me to my final stupid point: in the land of integration, the debugging man is king. With SOA (sorry to re-use the over-used, ill-understood acronym, but at least I didn't say Web 2.0), various plug-in architectures, and numerous open source data/communication standards out there it is clear that integration is in your face to the extreme. With that being the case, all of this unforeseen integration is going to lead to bugs (as all things do). The problem will be with 50 unrelated parties molding the final data at 50 different integration points you had better have an architecture made for debugging, a set of tools that give you full control of the chain of events leading to the final data and allow your support staff to do it remotely, and a person that doesn't have their head up their ass. So, if the little children were to ask me today what skill I thought would be most valuable in the economy of the future (as they so often do), I would say, "It's hacking and debugging." They of course would point out that that could be considered two skills and they only asked for one. And that's where the violence comes in…

I was catching up on my blog reading this morning and found a nice little post by Hugh Macleod at Gaping Void about creating your own personal brand–Brand You. It's "a personal brand that transcends your organisation or job description." Well, goddamn I like the sound of that.

The more I think about how low the barrier for entry has gotten for not only small businesses, but also for recording artists / film makers / whatever, the more excited I get. Not only are the tools getting cheaper all the time (when they're not free outright), but the means to publicize your product, your ideas, or just you yourself are everywhere. And as he alludes to in the post, the infrastructure required to allow you to work anywhere in the world with anyone anywhere else in the world is in place (and getting better all the time).

Now, what are you doing to put yourself in a position to take advantage of this coming revolution in the way we work, think, collaborate, publicize, etc? Currently, I'm on corporate cog auto-pilot waiting for opportunities to fall in my lap. Somehow, I think it's not going to work…

I caught up on some of my blog reading this weekend and found that a lot of it was tag related. If you watch the feed for this blog at all, you probably saw me bookmarking a bunch of tag related content. It started with a Clay Shirky's response to Gene Smith's critique of Shirky's original Ontology is Overrated. And finally I end up on a pretty nice paper from HP talking about collaborative tagging systems. If you're hungry for tag related content (and who isn't really?) I highly recommend reading over all of these posts.

I definitely agree with Shirky that most (if not all) of the rigid hierarchical categorization of information we are used to is ripe for replacement. It's a mental limitation built around the constraints of pre- or early computer era inadequacies. The only clarification I would add to Shirky's points is that most of his assumptions and conclusions are based on a massive collaborative tagging system. Without tens of thousands of users contributing and refining the data, some of his points are less powerful.

In particular I think he doesn't emphasize the role of automated tagging enough. In a system without a huge user base it is especially useful for the system to add whatever full text searching or metadata it can in a manner that is accessed in the same way as tags (to prevent multiple or overcomplicated search interfaces). Of course as Cory Doctorow points out in his Metacrap article there are issues and problems with metadata in general, but I think these can be overcome to a sufficient degree to make this information extremely useful to the user.

For example, in a system organizing music it would be useful for the system to not only allow the user to tag individual songs but also add things like song length or sample rate. Why should the users have to tag songs with information that the system can already give us? This also brings up a slightly stickier point for me of comparisons and the category or type of information being communicated. Let's say I want to use a system that tracks computers in an organization to find all systems that are running Oracle 9 (or earlier) on Windows 2000 machines that have service pack 2 or earlier installed? Automatically tagging the machines with each of these individual pieces of information is relatively easy. But how do you get to the information in a system where tags are nothing but keywords? There is no less than / greater than relationship inherent in tags that pertain to Oracle version numbers.

Adding too much type or category information is dangerous as it leads us right back to the strict classification of information that requires a group to agree on the "correct" priority and granularity of the information being tracked. Do we add a tag group or category and allow compound tagging like "application:oracle" or "os:windows" either by the system or by users? That still doesn't really address the idea of numerical comparisons. Is this a situation where the desired simplicity of tagging and searching leads to an acceptable level of imprecision where humans will have to fill in the gaps? Am I trying to overburden the elegant idea of "stream of consciousness, tell me everything you know about an object" tagging with my caveman-like addiction to strict hierarchies? There's also the subject of the system making educated guesses at keyword synonyms.

I'm still working on the answers to these things and trying to find the correct balance of simplicity, power, and elegance in tagging systems (especially non-massive and/or non-collaborative systems).

I played around some tonight with the Gimp's Script-Fu functionality. Script-Fu and Scheme can be used with the Gimp to script different graphics operations. A great example of this in action is the web front end for graphics / logo generation at Cool Text. I'm sure it took too long for me to stumble my way through creating my script, but I think the result speaks for itself:

Now I can create "activate" logos to my heart's content, instantly. An evening well spent. Booya!

Update:

Skinner: Whoever did this is in very deep trouble.
Martin: And a sloppy speller, too. The preferred spelling of wiener' is W-I-E-N-E-R, although E-I is an acceptable ethnic variant.
Skinner: Good point.

I finally got around to installing and playing with Konfabulator a little this weekend. From what I've seen, Apple's new dashboards are very similar. Both somewhat similar to, though much better than, Microsoft's active desktop. Both of them allow you to run little desktop widgets that provide additional information (battery life, WIFI strength, weather, etc) or functionality (time trackers, search bars, etc). The Konfabulator engine is available for both Windows and Mac, is owned by Yahoo!, and is completely free.

I really like the functionality provided as well as how easy and open the API for creating these widgets is. Of course, most of the available widgets suck though there are a handful of useful ones.

One of the reasons I started looking at this is because I think it provides an excellent platform and opportunity to make information from enterprise systems more readily available. Let's say you have a product that, I don't know, monitors servers. If that product makes minimal information available about the status of those servers via RSS or some sort of service oriented architecture (SOA, SOAP, REST, web services in general–pick a buzzword) then you could easily write a widget that displays the status of the servers a particular user cares about right on their desktop, without logging into the application. Wouldn't that be cool? Hell, the endless variety of functionality made possible by things like SOA and RSS are just plain cool. The sooner the producers of enterprise software in particular realize this, the better off they and their customers will be.

As I've mentioned previously, I'm really liking the agile methodologies when it comes to building software. We're currently doing two week iterations with a planning meeting on the front, daily short standup status meetings, and a demo on the end. I'm not a big fan of recurring meetings (I want to meet because we need to discuss something, not because it's Wednesday at 3pm), but I can accept the need and the minimal imposition of the our daily status meeting.

The current problem I'm having (because I've always got a problem with something) is the demo meeting. The problem is not just with my current place of employment, it's everywhere I've ever been. During any kind of demo/prototyping meeting, some moron always has to assume that you're an idiot and have taken nothing into account and/or the version you're showing will be the complete polished version of a shipping commercial product.

Developer: Ok. So here are some screenshots of what we're planning…
Sales Person: I have a comment. I think it would be nice to be able to click the buttons rather than just having a screenshot.
Developer: Yes, we've thought of that. This will eventually be a running application.
Manager: I have a question. Are these screenshots going to be localized in the final product?
Developer: Again, the final product will not just be screenshot, but yes–as we've discussed in the actual planning meetings, this is a demo remember, we will be localizing the screens.
Developer from another team: So will this screenshot framework provide an area in your screenshot for me to insert screenshots of my product into?

…And so on. I just want to know, why can't people hold their questions until the end of the demo and, for the love of god, assume other people are intelligent until proven otherwise. "Oh, you've thought about this feature for a minute and a half and have some suggestions? Ok. My team has only been batting this around for six months, but I'm sure you've probably got something we've missed. I won't waste your time suggesting you check all of the product specs and planned features in upcoming iterations. You're much too important for that. Just give me a stream of consciousness of all the stuff you think we should be doing. I'll wait."

I read an interesting blog entry today about defects as they relate to a shaken can of soda. The short version is, don't pass defects onto the next unsuspecting person. Either deal with it yourself (preferable) or document it so the next guy knows what to expect.

That's it. You can stop reading. The rest is just my mental diarrhea raging out of control.

I think that sounds great down here at ground level. Unfortunately, I've chosen to work at places that tend to not do things that way. I've been on many teams that were encouraged to fib about how feature complete and bug free they were. This was done so we could call the product "code complete." Then, we spend half the schedule in the QA phase. QA finds and reports all of the defects (many of which we already knew about), we fix them, rinse and repeat. While this flies in the face of the notion that it is cheaper to fix (or at least identify) your defects early, it has often been what management wanted. I've never been entirely sure of why that is. It somehow fit together with their notion of how software is made. It seems to most often occur in combination with a waterfall methodology.

In the last few months, the place I work has transitioned to a more agile methodology. I have to say that on the whole, I'm much happier with it. It beats the hell out of working on an outdated spec with no feedback only to find out (6 months later) that that isn't what they wanted (even if it is what they said). I like the nice, short cycle of requirements, implementation, demo, feedback. It's amazing how peoples' requirements and priorities change when they get more timely delivery of what they've asked for.

That's the upside. The downside has been trying to squeeze architectural ramp-up and infrastructure tasks into two week chunks. Especially when there is an unwavering emphasis on demonstrable features at the end of every iteration–you watching my build script run isn't going be "much better than 'Cats'". Also, there are usually inefficiencies in breaking things up into smaller pieces. That bothers me on some level, but I think it ranks right below "why do they put white rice in salt shakers?" I can live with it. The part that has been harder to deal with is that agile, in combination with weak product management and strong sales people (and pushy customers, I guess) has made it easier to get customer specific features into the product.

These features are of course worthless steaming piles of functionality. No one else wants it and it doesn't make any sense–but someone is willing to pay for it, so let's get their money. After the smoke clears, we've got to maintain it. Then, some "normal" customer finds it and tries to use it. Usually, they don't know how to use it (because the feature doesn't make any sense) or it's not what they think it should do. So, they call support. This just adds to the cost of having that crap-ass "customer of one" feature.

I'm not fond of this way of doing business. I don't want your customization in my code base. I'd rather do the open API/SOA/whatever thing and let you worry about how your custom workflow integrates with our product. Hire some other programmer to customize the hell out of all of your third party products. Hell, you can even hire someone from the company I work for. If your idea kicks ass, sell it as an add-on suite to our product. If it really kicks ass, maybe we'll buy it and integrate it into the next release (ironic, isn't it). But more than likely, if you have to pay for it, you'll come to your senses and realize your idea / requirement is stupid. Either way, I don't particularly care. As for the lost revenue, I don't know…Sell developer level support or some shit. Or open up a side business customizing your own goddamn software. Just stop putting this crap in the core product.

Despite the hype, I think this is the direction everything is heading. Call it open API, SOA, REST-ful, web services, or whatever. Stop thinking that you're going to lose your competitive advantage by opening up your data and your product. Stop thinking that by having one decent product in one area you can "end to end" (if you know what I mean) your customers into buying all your other shitty offerings. Everything you make better be able to integrate easily and stand on its own two feet. Open up and say, "ah." That's an API type of joke, son…It's totally win-win. I get to stop working on and maintaining worthless, disparate features. The customers get to have access to their data and the glue that links all of these third party products together into their quaint little workflow.

And scene…That's the end of the promised diarrhea. From appetizer to dessert (and everything in between).

The phrase "rich UI" has been flying around a lot at work lately, so I was interested in the thoughts expressed in Mark Finkle's post on the subject (which is in response to another such post by someone else). I think it is interesting that he mentions that he prefers the web application version of some of the tools he uses. I would tend to agree. Although a lot of people see web interfaces as severely limited (and they usually are), sometimes that is quite nice. The lack of richness in early web applications was due to limitations in the tools of the time (namely the browser), but that limitation led to some very clean and simple UI design.

Rich web UI (either browser or plugin based) is rearing its ugly head again in the form of Flex, Laszlo, SVG, etc. (I actually like most of the Ajax stuff so I tend to put it in another category). Some of the "new" technology does in fact make some of the traditional web apps much more usable–specifically things like populating controls with server side information without a page load or the sweet, sweet nectar of Google Maps (again, all Ajax). That sort of thing is a step in the right direction. However, I think this shit gets out of control really fast. I fear that soon the consistent and simple interfaces will be gone only to be replaced by some "usability expert's" fantasy of flying, fiery dropdowns that make cute noises when I click them. Flashier (no pun intended) is not inherently more usable.

"If less is more, think how much more MORE would be." Dr. Frazier Crane

If you haven't seen/heard of it (and you're using Firefox) you should install the GreaseMonkey plugin. As stated on the plugin's home page:

Greasemonkey is a Firefox extension which lets you to add bits of DHTML ("user scripts") to any webpage to change it's behavior.

Pretty useful stuff. While perusing a collection of user scripts for GreaseMonkey, I ran across one named AmazonA which will rewrite Amazon links to include whatever Amazon Associate ID you specify in the script. Now, you'd be violating your agreement with Amazon if you inserted your own ID in there, but what if you did as Cory Doctorow suggested in a recent podcast and insert the ID of some charity in there? Or what if social networks finally proved themselves useful and you rewrote the script to connect to a server and pull the least recently used ID from a group of your contacts (who would presumably do the same)? Then everyone gets a little cheese.

The P-word has been getting thrown around a lot where I work lately. While poking around the different discussions available on the web I ran into this example of how insanely easy it is to violate many obscure patents in the routine development of an application (particularly a web application). A couple of the crazier examples of the patents pointed out are 1) ordering by cell phone, 2) payment using a credit card on the internet, 3) tabbed palettes, and 4) the use of TV as metaphor for selecting different video fragments. Holy shit those are ridiculous.

You can also view the entire presentation, if you wish.