Running as Root

How I waste my free time

In between trying to get a simple Arduino project thrown together and farting around with the Yahoo! UI Library, I took a timeout to play around with Firefox add-on (back in my day they were extensions) named Stylish.

The subject came up on Jyte that black text on a white background wasn't the friendliest design for some people. Unfortunately, most sites don't support user specific skins so if the site's design causes you problems, from a vision related impairment for instance, then you're just shit out of luck. That's where Stylish comes in. It lets you create custom CSS overrides on a per site basis.

Can you see me now?

Yet another thing to do when you're bored: see if you can completely change the color scheme of a site to make it hideously ugly for no good reason. It took a little work, but I managed to make a really nasty looking blue and purple on black style for Jyte.

Most of the work was just finding all the nasty little inherited background colors, background images, etc. One interesting problem came up because Jyte has a set of menus that are images of text. They have a white highlight built into them and look like complete crap on the new black background. I thought it wouldn't be a problem to turn links with images into links with the image alt attribute as the link text and then hide the image.

Let the CSS fun begin

I thought maybe some sweet CSS action like this would work:

.nav_item a img:before {
  content:attr(alt);
}

.nav_item a img {
  visibility:hidden;
  width:0;
}

Oh, how lovely that would be. Apparently it'll work in some builds of Firefox but got turned off in later versions. I think it was a feature request specifically to make my life more difficult. :before and :after pseudo elements for other elements work fine, just not images.

So, with a lot of trial and error I wound up with the less than ideal:

.nav_item a[href="/home"]:before {
  content:"Home";
}

.nav_item a[href="/home"] img {
  visibility:hidden;
  width:0;
}

Since I no longer had access to the alt attribute on the image I had to manually insert the correct link text for each menu item. I did this for each menu by using an attribute selector to find each link by its href attribute, then hard coded the content to the correct text and finally hid the image.

You nasty, nasty boy

Oh, it's nasty all right, but it works. The only problem is I was trying to make the CSS overrides generic and there's a dynamic menu that includes the user name. Luckily there's only one such dynamic menu so I just made an entry to handle all such menus as the dynamic one and let the more specific rules clean up after the fact. Ta da! A custom, site specific CSS override that no one will ever use because it looks like it was beaten with a bag of hammers and makes your eyes hurt to read.

The interesting thing is that there are now ways for users to make the sites they frequent more appealing and possibly more accessible via add-ons like Stylish and Greasemonkey. It's not ideal for non-technical users, but sites like Userscripts and Userstyles can help by acting as repositories with aids created by the more technical members of the community.

Someone asked for a Blockbuster version of the Netflix Greasemonkey script I wrote. I signed up for the free two week trial and got it working, I think. It's not very different from the original Netflix version, just some stripping of extra characters like "|WS|" or "|Unrated|" that Blockbuster adds to the title. Feel free to download it from here.

Update: BlockBuster made some minor changes that broke that version of the script. I've made some minor changes to fix things. I updated the link in the post to point to the new one. If you can't be bothered to find that link, you can get it here.

Update: I updated URLs to which the script applies and added quotes around the search title to get more exact matches. As always, you can get it here.

Update: Blockbuster started including the year of the disc in parentheses which would throw off the search so I stripped that information out before hitting the TiVo search site. I also changed the link to the TiVo site so that it would open in a new window/tab. I found myself always shift clicking the link so I just put it in the script.

I wasn't very satisfied with my last attempt at merging Netflix and Tivo. I'm sure it can be done using just Pipes eventually but I think it'll take a while for Pipes to mature enough.

Barring that, I got curious this weekend and decided to see if I could do the same kind of thing directly on the Netflix queue page via a Greasemonkey script. So I wrote a quick little script over the weekend:

The quick overview is that the script takes each movie title in your queue and searches for the text on TiVo's site. If it finds a match it puts a link after the movie to TiVo's search page. I used a link so you can open the matches in other tabs. This is especially handy since it takes a while to search TiVo for all the movies in your queue. I also tried to make the link stand out a little so it would be easy to spot while scrolling through the page. Besides being a slow loader, the other downside is that any match will cause the link to appear. This is a little bit annoying but seems bearable. In theory you would then schedule the recording online via TiVo's site.

If you're interested, go install Greasemonkey followed by this script. Feel free to modify the hell out of it if you like. I realize it's still not a perfect solution, but seems a bit useful for now. Also, please excuse the crudity of the code. Like I said, it was a quickie and Javascript is not my forte.

Update: Here's a Blockbuster version.

Update: I added the quotes to the embedded search. I no longer have a Netflix account, so it's not the easiest thing for me to test out. Let me know if there are any problems. The script is now hosted at userscripts.org.

Brandon had another cool idea which he posted on his blog. In short, he thought it'd be cool to be able to automatically schedule recordings on your DVR for the titles in your Netflix queue. I've been playing around with Yahoo! Pipes recently and this seemed like an ideal candidate project. Pipes is a GUI scripting tool for doing things with RSS feeds, like mashups.

After many false starts I finally arrived at the following:

1. Grab personalized Netflix queue RSS
2. Loop through each feed item
3. Construct a TiVo search URL
4. Grab the results via Feedity, which will make it an RSS feed (Pipes needs that)
5. Display the unique results, which should have been a link to upcoming showings in TiVo's guide for each matching title from your Netflix queue

Sounds good in theory. Unfortunately my final stumbling block was that Netflix currently includes the queue position in your queue RSS and Pipes provides no way to parse out the substring of the DVD title. This title gets sent to TiVo which finds no results. Feedity then includes the "Guru Guide FAQ" in the result set (which it seems to do whenever your search returned no results). Filtering that out would be trivial, by the way.

There seems to be some interest on the Pipes discussion boards for adding additional scripting power to the interface so I may revisit this in the future. Of course you could do this some other way, but I felt like playing with Pipes. In the meantime, here's a view of my final non-working composite pipe:

Update:

I decided to play around with this idea a little more (still using Pipes). If I use a feed that doesn't have numbered items, such as the Netflix recommendations or new releases, then the problem just moves a little upstream. Feedity isn't very good at extracting the relevant information from the TiVo search page. On top of that, most of the other free HTML to RSS hosted solutions have equal problems. So, I'm still thinking about it.

Train the New Guy

At the new job we have an integrated hardware and software solution for access control (badge access on doors, elevators, etc). We offer a four day class that covers, among other things, how to install the hardware and setup and use the software. This class is directed at the builders / installers, not the end user of the software (though the installer does everything an end user would do and more). We also send our internal people to the class so they can become familiar with the product in a shorter period of time.

Though I dreaded it going in, I attended the course a week or two ago. I must say it was an amazingly valuable experience. One of the problems I have with virtually every company I've ever worked for is that getting up to speed on the ins and outs of the product proves extremely difficult. The developer training is always extremely informal. It meanders and leaves out a lot of things. As a new employee you feel like you're playing catch up for far too long.

Although this training didn't teach me anything about how our software is written, it gave me a customer level familiarity with the hardware and the software. I feel like I understand the product and can start being useful much more quickly than I would have otherwise. I immediately saw opportunities for feature and usability improvements because I was using the product in an environment that closely simulated how the installer and end users would use it.

You Should Offer Some Training, Too

If you have any kind of training available for your product for certification, sales people, end users, support people, etc then you really need to send your employees (especially developers, QA, and support) to these classes. Assuming they will just "pick things up" is robbing them and you of the quality and speed of the contributions they could be making. Not every company has a product that requires such a training program to be offered. For those, I'd seriously recommend carving out some time for coming up with some sort of formal internal training for people. It doesn't have to be overly polished or professional, but having a formal curriculum available to internal employees will prove amazingly useful.

If this seems like a no-brainer, consider that I've never worked for another company that managed to do it and that lack of training was one of the major complaints I had about my last job. I was told flat out that they'd rather hire a domain expert and train them to program than the other way around. I digress.

Pretending I'm a Customer

As I mentioned, we have a hardware component to our product. In one of our front offices we have a training lab set up with multiple hardware stations, which you can see here:

At the end of the class we used all of the stations (including an elevator controller not shown here) to simulate a seven story building with multiple tenants and access restrictions, including NVR security camera stuff and building automation integration (woot!). It's exactly the kind of thing a customer would do with the product and now I've done it too. Without this training class I think I would always have a partial view of the product at best. Fantastic stuff. Very exciting.

More Tales of the Expert User

Another thing I noticed during the expert user presentation was how he used the information in the application. He leaned heavily toward using the charts and graphs in the application rather than the tables. From his viewpoint, the tables were useless. He didn't care about 99% of the individual incidents in the tables. He just wanted to see the overall trends. Multiple pieces of information were presented as different components of a single graph with a vertical line cursor that allowed him to compare the timing of different events from different mini-graphs. When he found something out of the ordinary he could click and drag to view a table version of a point in time. This is vastly superior to what I normally see–disconnected table and chart views with the tabular format being the kitchen sink view of things.

The point is that I normally witness user interface design happening in a complete vacuum. UI features are thrown in just like product features, just put everything in there because some of this is going to be useful to someone. Hopefully. Maybe. Now I haven't been here long enough to know how that UI was conceived, but this is certainly another example of the importance of mining your users for information. It's not only important to know what they need, but how they intend to use it.

Hey, Look at Me! I Read a Book

A case in point, I'm reading Things That Make Us Smart and the author uses several really good examples of the representation of information affecting the ease with which certain tasks can be performed. One example from the book is the case of Roman numerals, ticks, and Arabic numerals.

Supposedly it is easier to perform addition with Roman numerals than the other two systems. Read the Wikipedia explanation to see it in action. This is apparently easier to learn. Fortunately I'm too heavily indoctrinated into our current system to tell if it really is. A good thing since multiplication and division would obviously make my wiener hurt.

Ticks are superior for counting or tallying things. This is because their representation of larger numbers is additive. You just add another tick. With Arabic numerals you have to completely change the symbol you're using. This means erase and redraw. Not very efficient for the use case of counting.

And Arabic pretty much kicks the ass of the other two in everything else. But the point is that each of these representations are superior to the others depending on what you are using them for (although I will never use Roman numerals even if I'm only doing addition).

Give Them What They Didn't Even Know They Wanted

Apparently the king of information and interface design is Edward Tufte. I've only seen a few examples of his stuff, but it is very sweet. On top of this there are courses available to learn to improve your presentation of information. Everyone I've talked to that has attended raves about their sheer brilliance. I've decided I'm attending the very next chance I get. It's a step toward the final piece of the puzzle which is knowing how to not just get the information the user wants but to know how to present it to them in a manner that greatly facilitates their understanding and usage of it.

Now that's something that should impress customers and make you stand out from the competition…

I finally had something useful happen at work. We had a consultant that uses one of our products during the course of his job come in and give a quick presentation on how he uses the tool. Unfortunately, it's not the product I work on, but it was still interesting for a number of other reasons. As quick background, the tool demo'ed is a storage monitoring tool.

Three Users of Enterprise Software

Nothing new here, but Enterprise software users typically fall into three categories: experts in a domain using the software to make their tasks easier, users largely ignorant of the domain that want an expert in a box to tell them what to do, and executives that want some charts to determine if things are running smoothly: the infamous "dashboard."

The person we had in was definitely an expert in the domain. Listening to how he uses the software to determine if a customer's installation is running smoothly was very educational. Often, features seem to get added to a product by people that don't really understand how those features are going to be used. It's put in just in case someone might find it useful or, worse yet, a customer demanded it without explaining why the wanted it.

This part interested me because, through his demo, he identified a ton of information that the "expert in a box" customer would drool over. Apparently the way he used different pieces of information wasn't just news to me, it was news to the current development team as well. They furiously scribbled while he showed how he used combinations of charts to find configuration errors, determine the need for new equipment, and a number of other things. He also suggested some features that would make his life easier and explained why he didn't use certain parts of the system at all.

Hired Guns

I, like most people, really value the input of a customer or, if that's not available, a customer advocate. The problem is that most product owners in a typical company don't seem to really understand what a customer needs. They pay more attention to what the competition is doing or at most what the squeakier wheels in their customer base say they want.

As early as possible you should post a position on one of the online job sites looking for an expert in whatever problem domain you're working. Throw them a few thousand dollars or so to just come in and show you what it is they do. Do all the standard information mining stuff on the poor bastard. Make sure the developers are involved. Try and build a tool that is useful to him and at the same time captures some of his knowledge for the EIAB (expert in a box) user. After you build a few iterations of the product, ask another one in to evaluate the product. Repeat, get the EIAB user to check it out, etc etc. Did I mention that you should make sure the developers are involved?

Ship your product, sell your product, host a message board for customers of your product, make the developers participate on the board. Keep that interaction with the customer going. At some point, throw a few extra grand at an expert that uses your product and record a demo session to include in your product. Something to orient the expert customer and maybe teach the EIAB user to be more effective. It's not like anyone reads the manual. That training video can double as sales literature, too.

No Shit

Yeah, it's pretty obvious. A veritable no-brainer. I'm ashamed for even suggesting such an obvious idea. Now why, if it's so obvious, is it that I've never seen this done at any organization at which I've worked?

We Can Rebuild It

The dream of most of the software developers I know is to get the opportunity to rewrite a system they work on from scratch. I think as things move more toward test driven development (TDD) this desire may fade a bit, but never entirely disappear. TDD should allow developers to aggressively refactor an existing product rather than starting from scratch. There will be less fear of hopelessly breaking the system if you've got solid tests and good test coverage. Of course, even getting the opportunity to refactor may be rare in many cases. The product owners don't always care how dirty the implementation is if there are no visible effects in the final product (at least not right now anyway). The customer won't buy the product because it has pretty source code behind it. A damn shame.

The incessant desire of software developers to rewrite all code they encounter is perfectly natural in my opinion. It's the plight of the knowledge worker. Each day you collect new information and techniques. When you look at someone else's code (maybe even your own from 6 months ago) you can't help but feel that there is a better way of doing it. If you have to write new code within the constraints laid down by this less than ideal solution, you're eventually going to come to the conclusion that you should just rewrite the whole thing. You just don't like having to work with / around whatever it is you've been given. Maintaining someone else's software is like putting someone else's sweaty clothes on. That opportunity to refactor is crucial.

From Hacks to Good Software

I was talking with another of the developers on my team a few days ago about how we should fix a problem we're having. We're working under a deadline and may not have time to implement the more ideal solution. I proposed a couple of different stopgap solutions that would get us to our release date. Most of the ideas were met with the infamous developer credo, "but that's a hack." I definitely understand the sentiment, but unfortunately we have to ship some software. And in my experience, most good solutions started as a hack. If you properly encapsulate everything you can go back and improve that hack into a decent solution with minimal impact. But again, willingness to accept the less than ideal solution is much easier if you know you will be able / allowed to refactor it later.

Now, does the world work this way? Hell no. So far, for me anyway, TDD is hard. I seem to always find myself smack dab in the middle of a container or a framework that makes effective testing extremely difficult to do. That inevitably gets coupled with a product development cycle that allows no time to retro-fit tests and test harnesses into the existing product. On top of that, the product managers often don't see the value of refactoring unless they get a ton of new features with it.

Usually in a simple situation you just start doing TDD for all features moving forward and write a test for every bug you find. The idea is that eventually you'll get there. For cases where you can't do the initial work in small chunks I guess you're just screwed. Eventually you'll have to bite the bullet and do whatever big tasks are necessary to start you down the whole TDD road. If you can't do that, it's probably time to move on and try to make sure that the next place doesn't suffer from the same problems.

Any Questions?

In the back of my mind I keep filing away little tidbits like this for later use so that I can come up with a decent set of questions to ask any potential employers. In a typical interview I forget the importance of grilling the employer. I need a set of questions like the Joel Test. I think the first one I need to add is: Can I see a copy of your code coverage reports, preferably over the last 3 months?

Update

Matt Kinman rocks!

I'm farting around with CruiseControl at work to kick off a Maven build script. CruiseControl is a pretty handy tool, although I still manage to hit my head on its limitations whenever I want to do something odd. Like associate a publisher specifically with one of the builds within the schedule. Or make only one of the builds in the schedule ignore the need for modifications in the source repository before kicking off. Whatever. It's still well worth the money.

A couple of weeks ago I'm doing some stuff and things with the Perl guy I work with. We'll call him John because that's his name. Well old John checks in a change in the maven.xml that breaks the build. We know it broke the build because CruiseControl sent us a hateful email. We just fixed the problem and checked in the file. CruiseControl should pick up the change and send out a "build fixed" email. Well, it never did.

After looking at the build box we found out that the changes weren't being picked up from our Subversion server. We were in a bit of a hurry so we just did a manual svn up on the CruiseControl box (a virtual machine actually ;). Well, today I finally got my dumb ass to figure out what was wrong. The source control update within CruiseControl happens like this: maven scm:update

Meaning, if you broke the build so badly that it won't even run, you'll never get the changes that fix the problem–because they happen through the build. Get it? They happen through the build. (crickets) I guess you had to be there.

At work, I have a separate test machine I use to deploy the software on which I'm working. The demands the container(s) and framework make on the host machine are borderline too high to run on my laptop comfortably so the test machine is a very good solution. As I mentioned before we use a lot of virtual machines here. My test server is running Debian but the environment I'm deploying to is actually a VM running Windows via an instance of VMware Player. I run the player by ssh'ing to the test machine and then do some X11 port forwarding to my local Cygwin X server just so I can futz around with the instance of Windows if need be…

I'm planning on working from home this afternoon and some of this weekend. In order to test my changes I need somewhere to deploy the application. Unfortunately, I haven't set up our VPN client yet (plus I hear our VPN is dog ass slow). Well, thanks to those handy-dandy VMs, I can pick up a copy of my server and take it with me. Then I can either run it on my laptop (and temporarily suffer through the somewhat acceptable performance degradation) or I can drop it on any of the machines I have at home. Oh, daddy likes.