LinLog

I finally had a "new tech" adventure last week - I dabbled in Mozilla extensions for the first time.

I've been using ActiveState's Komodo Edit as my primary editor for PHP, Python, and JavaScript for the last few years. One of the extensions I always used was the TabSwitcher. I've found that I depend on that extension even more heavily now that I'm with deviantART simply because of the size of our code-base. While the Fast Open extension is great and has similar functionality, it simply doesn't fill the same role for me. Our code-base has thousands of file, many of which have similar names, which results in Fast Open slowing down and giving me too many results to be useful. Because TabSwitcher operates on a much smaller data set, it's much better for the common case where I have 20 or 30 tabs open and am actively switching back and forth between 8 or 10 of them.

The only problem is that TabSwitcher isn't compatible with Komodo 7. That's actually part of the reason I hadn't bothered to upgrade Komodo on my work computer yet. So I decided to remedy that by porting it to Komodo 7. While I was at it, I added a couple of small enhancements, such as updating the bookmark list when a bookmark is added.

You can download the extension here:
tabswitcher-1.0.0-ko.xpi
If you want to look at the source, it's in my Mercurial repository here:
http://hg.skepticats.com/tabswitcher/

This was my first exposure to XUL or Mozilla add-ons, so hopefully everything will work the way it should. I haven't seen any problems so far, at least.

Author's note: This one from the archives was written back in March 2008. This is something I've seen a couple of more times since then. A new developer, usually fairly young, comes in and wants to rewrite everything using whatever technology or method he's most familiar with. It seems to be not so much a problem with learning the new codebase as it is developer hubris. "My chosen way is obviously the right way, so clearly that's how we should be doing things." The people who do this don't seem to stop and think about whether their chosen method or tool might not be the best choice in the current situation, or whether implementing it might just be more trouble than it's worth. Perhaps it's just a lack of experience - they haven't had enough rewrites go south to realize that this isn't always a good idea. Either way, enjoy the rant!

Here's a little tid-bit for you young, aspiring developers out there: When you start a new job, it's usually a good idea to wait until your second week before you suggest rewriting the entire existing codebase.

I say this because we recently hired a new developer. He's obviously very bright and knows his stuff, but his first suggestion, on his first day, was that we should rewrite our entire codebase from a custom PHP framework to Symfony. After all, it would probably only take a couple of months.

Now, I don't know much about Symfony, but I have nothing against against it. And, in all fairness, our current framework is a bit of a mess. So I'm not dead-set against the very notion of switching. However, the current framework has been tailored to our needs and it is perfectly adequate. I'm sure that Symfony is very nice, but it's not immediately obvious what compelling advantages it would offer. After all, we already have an application framework that does what we need and which all three of the established developers are very familiar with. Given that we already have a full plate as far as projects go (hence hiring a new developer), it's hard to imagine how you could make a business case for spending 2 or 3 months learning Symfony and converting the whole site to use it. And if the new guy things that we're going to convert in parallel with adding features to the existing codebase (which he actually mentioned), he's out of his mind.

The thing that really bothers me about this, though, is that the new guy suggested this on his very first day. As far as I know, he hasn't even written a line of code yet and he's already writing up the business case for switching to Symfony. Even though he's barely looked at our codebase and so couldn't possibly have any idea what kind of effort this would entail.

So, to all the developers out there, next time you start a job on an established development team, at least take the time to learn what technology they're using and why before you suggest replacing it. Do a project or two with the current stack. Talk to the other developers about the history of the codebase and the company culture. Pushing to replace major technologies before you've even written a single line of code just makes you look like a tool.

Author's note: In yet another installment of "From the Archives", here is a little entry that I wrote up back in September of 2007, but never bothered to publish. It's a little dated, but sadly it still has the ring of truth to it. Of course, there has been some improvement. A lot of hardware doesn't come with a CD anymore - they just give you a pamphlet with a link to the crappy software instead. But anyway, I thought this entry was based on an interesting quote, so here it is.

On an episode of Hanselminutes a month ago, Scott and Carl spoke with Jeff Atwood of Coding Horror fame about the "ultimate developer rig" he built for Scott. During the course of discussion, Jeff uttered what is, undoubtedly, the best quote about software developers that I've ever heard.

Nobody hates software more than software developers.

Not only does it sum up the feeling of true software geeks everywhere, but it also offers a sad commentary on the state of the computer hardware business.

This quote was uttered in the context of a discussion about "mouse software," i.e. those useless CDs full of crap-ware that get thrown in the package with even fairly standard mice. They typically include drivers, a control panel applet, some kind of tool that runs in the system tray, and probably a few other things.

As Jeff and Carl rightly pointed out, the reason they, myself, and many other programmers hate such software is that it is, quite simply, useless. Nobody needs to install the software that comes with a standard wheel mouse because their operating system (no matter what it is) already supports it. In fact, Carl went so far as to say (half-kidding, I hope) that if he caught any of his employees installing "mouse software," they'd be fired on the spot. Any half-competent programmer or IT person should know better.

Sadly, this phenomenon isn't just limited to mice. USB media devices seem to be the worst offenders. Cameras and MP3 players in particular always seem to come with some kind of software that's supposed to help you move files onto or off of the device. Of course, as it's always third-rate crap-ware, as the vendor makes their money on the hardware and just throws in the software as an after-thought. But the worst part is that there's no reason you should even need it, because any decent MP3 player or camera really ought to "just work" as a USB mass storage device (with the notable exception being the iPod, which is decent, if overrated).

So really, it's not that software developers hate software, it's that we hate crappy, unnecessary software. That's probably because we know what we need and can easily judge the value of a program. We can tell when all a program does is the digital equivalent of busy-work. Being handed a CD of code that doesn't do anything useful feels like being condescended to. That angers us.

The other day, one of my co-workers posted a link to a semi-comprehensive list of everything that's wrong with PHP. This should be required reading for anyone who claims to like PHP.

The best thing about this article is that I actually learned a number of things from it. Apparently PHP has a lot of WTFs that I simply hadn't run into. Though it's relatively minor, my personal favorite is :

"gzgetss - Get line from gz-file pointer and strip HTML tags." I'm dying to know the
series of circumstances that led to this function's conception.

I would also love to know what motivated someone to include this function in the zlib extension. I mean, how many people have ever actually used that function? Like, three? It's ridiculously specialized and isn't part of the C API (I know because I checked) - there's no reason for it to exist. To me, that perfectly sums up the language's lack of any coherent design or sense of priority.

Of course, there were plenty of other nice little gems. For instance, the face that when $x is null, $x++ is 1, but $x-- is null. Or the notion that named parameters were rejected as a feature because they would "make for messier code". There's certainly lots of information and humor value there for anybody who is familiar with PHP.

Personally, after reading that, I think it's time for me to brush up on my C# and Python. I've been making my living writing PHP for five years now, and I fear it may be causing brain damage. After all, Edsger Dijkstra said that BASIC warps the mind, and PHP has been called "the Visual Basic of the web". And after reading this article, can there really be any doubt?

Author's note: This is another entry that's been sitting in my drafts folder for years and which, after three glasses of wine, I've now decided to publish. This one is from April 2007, about four months before I left the government IT world for the world of commercial product development. It's funny how my posts are much less humorous when I'm enjoying my job than they are when I'm frustrated. But, then again, working with non-technical end users generates a lot more funny stories than working with top-notch developers. Oh, well.

The corporate IT world can be frustrating at times. The IT department is often viewed as a cost center, a necessary liability, rather than a helpful resource. As a result, it often seems to the IT people like the entire organization is against them. This leads to frustration, apathy, hostility, and using a sniper rifle to pick off people walking in from the parking lot. Thus I present a few tips to keep your IT department on your good side.

1. Don't report a problem by just saying you're "getting error messages" on your computer. We're the IT department, not the Psychic Friends Network. You're going to have to be a little more specific if you want any help.
2. If you do call about "getting error messages," then at least have the decency to tell us what the messages say. I know fixing computer problems may seem like magic at times, but we do need something to go on. If you dismissed the error dialog, didn't take a screenshot, didn't write down the message, don't remember what it said, don't know what application raised it, and don't remember what you were doing when it came up, there's not a hell of a lot we can do for you.
3. Please realize that "computer people" don't automatically know everything there is to know about computers. I may work in the IT department, but that doesn't mean I can fix your computer myself. It also doesn't mean I can tell you how to do something in your CAD or GIS software. It's not like I practice drawing maps in my free time. We specialize too, you know.
4. When requesting custom software, don't expect me to read your mind. I understand that you might not think of some things until after you start using the software. I have no problem with adding things later. In fact, I expect it. However, I really don't appreciate getting attitude because the program doesn't do X when nobody ever mentioned to me that it needed to do X.
5. When you ask how to do something, pay attention to the answer. I don't mind showing you how to add a border to that cell in Excel. I do mind showing you how to do it once a week for a month. And the same goes for clearing out your deleted items in Outlook.