There are few things I dislike about "modern" instant messaging. I really do miss the days of old, when IM was text only and the most complicated thing we had to worry about was emoticon display and whether ICQ's or AIM's protocols were going to change while we slept. Yahoo was a joke, MSN was an afterthought, Pidgin was still known by its former name and still used GTK+ 1.2.x, and a few disgruntled people would decide to fork on occasion. Even emoticon display wasn't that important--the focus was communication by a faster method than e-mail.
I, like many of my generation, discovered "web mail" and then graduated into more advanced things that this magical "internet" had to offer. Quickly, I started using e-mail for communication purposes instead of random notifications that were overall meaningless. Thankfully, my school's internet service provider offered a way to have students and teachers each have their own e-mail address. When one of my classes required a school-sanctioned e-mail address, I was assigned the 354th e-mail address issued to my school. The ISP used an HP-UX machine for mail. With trusty old telnet and the MacOS Classic application BetterTelnet FAT as our new best friends, we would log into the mail host (omalp1; I'll let the obsessed among you see if you can figure out the rest of the hostname even though it doesn't exist anymore--good luck!) and be presented with a shell. None of us had any clue about UNIX in those days, so we knew of only two commands, pine and exit, and these were taught to us as the only "blessed" commands to use at the "dollar sign thingy."
My classmates and I started using e-mail to communicate both in and out of classes. At some point I finally got dialup internet access at home, albeit absolute trash, and joined in. We used this e-mail like it was IM--we would religiously check our e-mail and reply as soon as we received the other person's message. This worked pretty well until someone among us discovered ICQ. Soon we all used it. Ah, this brings back the memories. Mirabilis' official ICQ 98b client, as I recall, was my first ICQ client. I don't recall if emoticons worked at this stage or not; I don't believe I ever used them at that point. Some time later, an AOL user among us discovered that AIM and AOL's built-in messaging component could talk to each other. A few of us migrated to AIM, but most of us ran both AIM and ICQ together. All was still good with the world. AIM 3.x, with all the neat little back doors to get around AOL users being able to be invisible to AIM users, was the client of choice. Basic HTML formatting, emoticons, sounds that didn't drive us crazy when we got messages. Ah, these were the days. I miss it!
At some point later, IM started to go down hill. Someone decided that file transfer needed to be a first-class citizen in client features. Yahoo grew webcam support. MSN became a contender despite its stupid design (I'll come back to this). Third-party clients actually became useful and welcome, especially the multiprotocol variety. And the spiral continued.
Today, we have a disaster area of IM features that everyone demands of every client, even the ones without the resources to develop and provide such features. Yahoo has more file transfer methods than I care to count, and changes them about as frequently as necessary to irritate the crap out of third-party client developers. MSN has enough file transfer methods to make AIM's newly increased three-count look like a fledgling effort. I won't even speculate on how many methods other protocols have or bother to find out how many XEP's exist for file transfer over XMPP. The exact numbers here are all irrelevant--the point is that we have a landfill full of code to cope with these bajillion file transfer methods and scenarios.
Webcam support comes to mind next. Suddenly these USB camera devices exploded onto the market and now everyone had to be able to use them in their IM clients. Then came the wave of "You don't have a webcam? Why do you bother to be online?" from those so addicted to their webcams that textual communication seemed like the stone age. Every IM provider that implements this is hell-bent on world domination or something and decides to pick protocols that are completely different from the "competitors' products," eliminating any hope of sane interoperability between these features of the services. Some of these protocols provide features others don't. Users blindly used whatever was thrust in front of them. Pornographic use of the webcam appeared. Stupidity ensued, while valid uses of the webcam, such as family communication and distance learning, didn't become major factors until far later in the game.
As if webcam support wasn't bad enough, some morons in MSN's management and development ranks decided they needed to introduce custom emoticons, winks, and nudges. Custom emoticons, of course, allow any user to send any random image to replace any specified text. MSN being the world of frequent abuse (again I'll come back to the abomination that is MSN later), users quickly took advantage of this and soon we had users replacing literally all of their commonly-typed text with obscure, crappy multicolored flashing emoticon crap that should never have existed in the first place.
Enter the nudge, now. Nudge a user and cause whatever stupid effect in the official client. Suddenly it too was all the rage for no real reason. Somewhere along the line Yahoo introduced a similar feature called buzz that shakes the message window. This too was hotly demanded. And let's not forget about the winks. Flash objects, I believe they were. More crap that doesn't belong in IM. Seriously, take this stuff to poorly-designed personal web pages, or even MySpace, and keep it out of IM.
And MSN as a whole. What a wonderful disaster area. When MSNP2 was around, I suppose I could excuse the lack of a status message--after all, ICQ didn't have them for a good many years either. But I won't excuse it--AIM had user-definable away messages from the beginning of my recollection, although available messages and invisibility are relatively recent additions by comparison. To me this negates any valid reason for MSN not to have supported some sort of status message. Then we have the friendly name, which I swear was invented solely to give users something not to use, but to abuse in ways unimaginable to those who implemented it. The ability to have graphical emoticons render in the friendly name comes to mind. So does the use of the friendly name to compensate for the lack of status messages. By this point, the protocol's usage had devolved into a cesspool anyway, so who really cared about the addition of custom emoticons, winks, and nudges, right? Apparently someone thought so, because now we have all that crap on top of it.
Now it's too late in the game, but MSN decided to implement another new feature--Personal Status Messages. Wow, now MSN joins the ranks of sane IM protocols, right? Not quite. The PSM now gets abused almost as badly as the friendly name is. I submit that it's called a "personal status message" for a reason, and that the reason is not to provide another field for users to abuse. But, as I said, it's too late in the game now. Users don't change unless you force them to, and this feature-too-late-to-really-matter certainly doesn't give us any evidence with which to claim that users change.
If I haven't alienated everyone who would bother to read this post by now, those reading this far are probably wondering what relevance this has to Pidgin or the Purple Plugin Pack, given my repeated prior related postings about both. Well, it's relatively complicated.
A couple years ago, long before our renaming fiasco started, Pidgin had a contributor who was submitting pretty large chunks of code to our MSN support. I wasn't around much for this; I was mostly just a user at this point and hadn't even attempted to contribute yet. Somewhere along the line, communications broke down, frustrations came into play, like probably a million other things I don't know or care about right now did. The bottom line is that the patch sat and the contributor left.
Fast forward to now and look at Pidgin's MSN support. No one can look at it and say with any seriousness that we support MSN features well--granted, we do a decent job but we don't support status messages and still use MSNP9. After two Google Summer of Code projects, we have an MSNP14 protocol plugin, but it was merged into our main development line too soon and still isn't ready for general consumption. As a result of this, we still ship MSNP9 and disable MSNP14 by default. We have a new Crazy Patch Writer who has implemented some elements of MSNP15 support. If and when any of this new MSN code becomes release-ready is really anybody's guess. (Not trying to slight anyone here; stabilizing new protocol support is work.)
The same contributor I mentioned earlier has now returned with a fork of the MSN protocol plugin for libpurple. He implemented server-side alias storage and some parts of the MSN peer-to-peer file transfer methods. Near as I can tell from the mailing list discussions, this is all still our existing MSNP9 stuff with some modifications. All fine and well, I suppose, but really these patches should have been submitted to us for review before forking, in my opinion.
In the ensuing discussions over the forked protocol plugin, the Personal Status Message issue has come up again, and there seems to be a difference of opinion on what the intended use of such a status message is. One side of the debate insists that this message has nothing to do with status but is instead for advertisements that allegedly are completely unrelated to status. The other side, which I find myself firmly rooted in the ranks of, argue that this PSM is a status message and ought to be treated as such. It seems the battle lines are clearly drawn for a war over how to implement this stuff.
All in all, I come back to the simple statement--I hate "modern" IM with a passion. I want to return to the days when there were no graphical emoticons, no webcams, no nudges, nothing that caused this kind of crap to turn up. Amazingly, this comes from someone who still refuses to use a text-mode IM client for routine IM needs and instead runs Pidgin all the time; go figure.
In closing, why can't we all just use XMPP and forget about voice and video, nudges, winks, emoticons, etc. forever?
Friday, January 4, 2008
Tuesday, December 4, 2007
Long time...
So, I guess it's been ages since I made a blog post. A lot has happened in that time:
At any rate, time to go to work, I suppose. Maybe I'll post something later.
- We released Purple Plugin Pack 2.2.0 without the ignorance or smartear plugins being properly fixed and included. It's not looking particularly promising for 2.3.0 either.
- We adopted new plugins into the plugin pack:
- dewysiwygification - An old plugin written by Tim Ringenbach
- enhancedhist - A plugin written by Andrew Pangborn.
- timelog - A plugin written by Jon Oberheide.
- buddytime - A plugin written by Martijn van Oosterhout and Richard Laager.
- Sean Egan promoted me to Pidgin developer.
- I rewrote over half of the Pidgin man page to reflect the current features present in Pidgin.
- I've continued to slack off on the Guifications 3 project.
- I hatched a plan to remodel the living room in our house without letting my parents know. I'll probably be yelled at endlessly for this one.
At any rate, time to go to work, I suppose. Maybe I'll post something later.
Sunday, August 19, 2007
Purple Plugin Pack 2.1.0 and 2.1.1; Plans for 2.2.0
Well, last night I released two versions (yes, two!) of the Purple Plugin Pack. The initial release was 2.1.0, which included a new plugin and the completion of a plugin that's been in our tree for ages. However, what I did not catch in this initial release is the fact that there were files missing from the convbadger plugin that would prevent it from building on any platform. I didn't want a duplicate tag in our monotone database, so instead of trying to rerelease the same version, I just did a quick micro version increment, added the files, tested the new version, then tagged and released 2.1.1. As a result, I called 2.1.1 "The rekkanoryo is an idiot release" to indicate it was largely my stupidity that caused two releases in such close proximity.
That said, I'm sure I'm going to hear complaints because I signed the packages. With the 2.0.0 release, there was a complaint because I signed the package with my GPG key, which has no signatures. Because of that I'm reasonably sure I'm going to hear complaints again about my signature being worthless because there is no relation to the web of trust. To that I have one response--find me a key-signing party within a 45-minute drive of my home and I'll show up with all the identifying documents I need for someone to verify my identity and sign my key. Otherwise, shut up and don't ever complain to me about it. I live in an area where technology seems to be a foreign concept, and anyone having a clue about GPG or any other sort of useful technological tool just doesn't happen. People here have trouble determining whether a website is SSL-secured or not, let alone something more complex. I work a full-time job which does pay my bills but doesn't provide me with the luxury of enough money (or time off at the correct times!) to travel to random conferences where I would be presented with keysigning opportunities. Because I attended a local school for postsecondary education, I didn't exactly gain exposure to any keysigning opportunities there either.
With that out of the way, I'll get to my plans for Purple Plugin Pack 2.2.0. I have a few things in mind:
That said, I'm sure I'm going to hear complaints because I signed the packages. With the 2.0.0 release, there was a complaint because I signed the package with my GPG key, which has no signatures. Because of that I'm reasonably sure I'm going to hear complaints again about my signature being worthless because there is no relation to the web of trust. To that I have one response--find me a key-signing party within a 45-minute drive of my home and I'll show up with all the identifying documents I need for someone to verify my identity and sign my key. Otherwise, shut up and don't ever complain to me about it. I live in an area where technology seems to be a foreign concept, and anyone having a clue about GPG or any other sort of useful technological tool just doesn't happen. People here have trouble determining whether a website is SSL-secured or not, let alone something more complex. I work a full-time job which does pay my bills but doesn't provide me with the luxury of enough money (or time off at the correct times!) to travel to random conferences where I would be presented with keysigning opportunities. Because I attended a local school for postsecondary education, I didn't exactly gain exposure to any keysigning opportunities there either.
With that out of the way, I'll get to my plans for Purple Plugin Pack 2.2.0. I have a few things in mind:
- Merge autorejoin and irc-more. Autorejoin is IRC-specific, as is irc-more, so there is no need to have two plugins whose function is to enhance IRC.
- Add processing capabilities for libpurple's blist.xml file into the listhandler plugin so that users who have managed to destroy their server-side buddy lists can import their backed-up blist.xml file to restore the server-side list.
- Split the alias list support that was patched into listhandler into its own files.
- Hopefully finish the smartear plugin integration work I've had on the back burner for way too long.
Thursday, August 16, 2007
The downside to popularity
As many people reading Planet IM know, I am a developer on the Guifications project and the Purple Plugin Pack, and a "Crazy Patch Writer" for Pidgin. Over the course of my time with these projects, we've seen our fair share of...well, pretty much everything. New developers; departing developers; people stepping back due to frustrations, busy schedules, etc.; and the biggest of them all, spam.
Not too long ago, Guifications and the Plugin Pack were hosted at SourceForge. Back then, things were pretty good--our website was pretty well static, although it was done in PHP so we could do cool stuff like pull in our SourceForge project news feed to use as our home page and have extensible menus with XML and whatnot. We also operated under one project at SourceForge. Over time, we (Gary most of all) became displeased with and irritated by things that we saw happen and things we experienced while there, and we eventually decided to leave SourceForge for self-hosting.
When we began self-hosting, Gary started renting a virtual private server from Steadfast Networks while waiting for a dedicated server to become available. It was a bad time for us to have been VPS customers, though, as performance was bad due to overloading. We were finally able to move to a dedicated box and couldn't be happier with it. I personally rented a VPS from them as well, and initially had similar frustrations. In the 9+ months since we've had Guifications and the Plugin Pack hosted on the dedicated server, the VPS performance issues have been resolved. The VPS I have is fast enough that I can barely tell the difference between it and a real box.
With the move to self-hosting, we needed something that could replace SourceForge's trackers. The solution was simple--we'd heard quite a few good things about Trac and tried it out. We've been with it ever since, and Gary even went to the trouble to update the SourceForge to Trac migration script to migrate our tracker items into tickets.
Over time, we discovered issues on one of the two Trac environments we were running--spammers were attacking us. At first it was comment bombing, where the spammers would flood us with links in comments on tickets--primarily closed tickets, but any ticket was a target. After the third attack, we cracked down and locked our Tracs to the point that only developers could open tickets or edit the wiki. This caused some friction in our user community, because we had bugs that no one could report and no one could make feature requests. Our apache logs showed a continued series of attempts to attack, growing similarly to our popularity with Pidgin users.
Thankfully, several people pointed us toward the Spam Filter plugin. It's a great plugin because now we can have authenticated users making ticket submissions, comments, wiki changes, etc. but at the same time we have blacklisted regular expression filtering, IP throttling, evaluation via Akismet, and external links filtering. Since installing and configuring this plugin we've had a whopping three successful spams. The monitoring feature is useful for adding blacklisted regexes, as well.
The only problem with the spam filter is that it requires work. That is, it's not perfect. On occasion it will have false positives, although this has happened significantly less frequently since we moved to requiring new registered users supply a first name, a last name, and an email address at the time of registration. Also, on occasion, we have to teach it about new bad expressions by editing the BadContent wiki page. It is sometimes funny, though, to see the karma scores assigned to some of the spam attempts. The karma can go wildly negative, especially if multiple filters are invoked multiple times on the same message. Currently the record for our Tracs is -41, due mostly to external links subtracting 35 points from the post's initial karma.
And this, my friends, is the downside of popularity--the spammers are out and ready to strike, and we have to fight them at every step of the way. Thankfully, for every group of spammers that don't deserve the privilege of using a computer, much less the privilege of an internet connection, we also have at least one talented programmer creating a tool to help in the battle against spam. It does make you wonder at times, though, what the spammers can possibly gain from attacking us.
Not too long ago, Guifications and the Plugin Pack were hosted at SourceForge. Back then, things were pretty good--our website was pretty well static, although it was done in PHP so we could do cool stuff like pull in our SourceForge project news feed to use as our home page and have extensible menus with XML and whatnot. We also operated under one project at SourceForge. Over time, we (Gary most of all) became displeased with and irritated by things that we saw happen and things we experienced while there, and we eventually decided to leave SourceForge for self-hosting.
When we began self-hosting, Gary started renting a virtual private server from Steadfast Networks while waiting for a dedicated server to become available. It was a bad time for us to have been VPS customers, though, as performance was bad due to overloading. We were finally able to move to a dedicated box and couldn't be happier with it. I personally rented a VPS from them as well, and initially had similar frustrations. In the 9+ months since we've had Guifications and the Plugin Pack hosted on the dedicated server, the VPS performance issues have been resolved. The VPS I have is fast enough that I can barely tell the difference between it and a real box.
With the move to self-hosting, we needed something that could replace SourceForge's trackers. The solution was simple--we'd heard quite a few good things about Trac and tried it out. We've been with it ever since, and Gary even went to the trouble to update the SourceForge to Trac migration script to migrate our tracker items into tickets.
Over time, we discovered issues on one of the two Trac environments we were running--spammers were attacking us. At first it was comment bombing, where the spammers would flood us with links in comments on tickets--primarily closed tickets, but any ticket was a target. After the third attack, we cracked down and locked our Tracs to the point that only developers could open tickets or edit the wiki. This caused some friction in our user community, because we had bugs that no one could report and no one could make feature requests. Our apache logs showed a continued series of attempts to attack, growing similarly to our popularity with Pidgin users.
Thankfully, several people pointed us toward the Spam Filter plugin. It's a great plugin because now we can have authenticated users making ticket submissions, comments, wiki changes, etc. but at the same time we have blacklisted regular expression filtering, IP throttling, evaluation via Akismet, and external links filtering. Since installing and configuring this plugin we've had a whopping three successful spams. The monitoring feature is useful for adding blacklisted regexes, as well.
The only problem with the spam filter is that it requires work. That is, it's not perfect. On occasion it will have false positives, although this has happened significantly less frequently since we moved to requiring new registered users supply a first name, a last name, and an email address at the time of registration. Also, on occasion, we have to teach it about new bad expressions by editing the BadContent wiki page. It is sometimes funny, though, to see the karma scores assigned to some of the spam attempts. The karma can go wildly negative, especially if multiple filters are invoked multiple times on the same message. Currently the record for our Tracs is -41, due mostly to external links subtracting 35 points from the post's initial karma.
And this, my friends, is the downside of popularity--the spammers are out and ready to strike, and we have to fight them at every step of the way. Thankfully, for every group of spammers that don't deserve the privilege of using a computer, much less the privilege of an internet connection, we also have at least one talented programmer creating a tool to help in the battle against spam. It does make you wonder at times, though, what the spammers can possibly gain from attacking us.
Thursday, August 2, 2007
Random Ramblings
This blog post is going to be a bit of . . . well, quite literally, random rambling. I guess the title of the post should make this a dead giveaway, but I'm in a bit of a weird mood tonight so I'll just get to the topics I was thinking of.
I'll start off with music. My tastes in music are a bit eclectic in some respects, and usually downright unpopular. I was raised primarily on country and oldies. In the US this means late 80's and 90's country music, which isn't a whole lot different from pop, and music from the 50's and 60's that fit into pretty much any genre but country. My one older sister (I have two older sisters and no other siblings) has always liked music in general, and so growing up with her around I occasionally picked up on some other forms of music, including rock. I find myself now, at 25, to be a somewhat picky music lover. For example, I despise rap, although a few mainstream country songs that have introduced some rap elements fall within my range of acceptability. My usual fare (as is quite obvious from my Last.fm profile) is country, although I branch out into Bon Jovi, Kelly Clarkson, and others. There's even a bit of Japanese music in there for good measure.
There's nothing specific that I look for in music to make me say I like it or I don't. I usually disagree with the majority of critics, although exceptions to the rule have happened. For example, the Dixie Chicks released an album called Taking the Long Way, their first album since being shunned from the music world following their criticism of President Bush (who I was stupid enough to vote for in 2000 as an 18-year-old first-time voter because I thought Gore was too stupid). Several critics loved the album, giving it very high praise. I too enjoyed the album. It had a pretty solid pissed-off tone throughout, while still covering a diverse range of stylistic influences and topics. Wow, I sound like a critic myself now. I need to stop that.
At the same time as I agree with some critics on select albums, I often disagree with critics and find myself quite liking albums that the critics have written off as pathetic. Essentially my musical taste runs the gamut from Neal McCoy's fun "Billy's Got His Beer Goggles On" to Sophie B. Hawkins' "The Darkest Childe", hitting numerous high points on the way, such as Massive Attack's "Teardrop" (House fans will recognize this as the theme song) and the entire body of Martina McBride's recordings.
The real point I am getting at here is that while I may gravitate towards some artists or styles, my taste is not limited to such. Even so, I've taken quite a bit of flak over it. Coworkers, codevelopers, etc.; you name the person, I've gotten remarks from them ranging from well-meaning jabs to acid-infused comments. I don't really care what people think of my musical tastes; I don't ask them to pay for the music I listen to, nor do I force them to endure it. It's my life, my money, and my ears. It's a legal practice, so I will use them in the way I see fit. I also won't take any crap from anyone over it.
With the music topic pretty much resolved to my satisfaction, I'll move to the other topic that I had in mind when I started this post--development fatigue. Every developer at some point reaches the point of being fatigued from the process. Every developer has his or her own breaking point, so there's obviously no sure-fire way to tell when this is going to happen. The important thing here is that we realize our limitations, push them at the appropriate times, and step back to take a breath when needed. The point of fatigue is the most important time at which to step back and breathe. If we don't stop at that point, burnout will follow soon. Stepping back before burnout happens and taking the needed rest and relaxation time away from the world of computers and code is an important step for both our mental health and our continued productivity as developers.
If a developer allows him/herself to burn out, it will likely take longer to "recover" from the burnout and return to productivity. If development projects are taken too personally, that burnout can also spill over into other aspects of life quite easily and cause a whole host of problems. Furthermore, once you've burned yourself out once, it's easier to do it again.
This all seems pretty obvious, right? Really it is; it just isn't a thought that occurs to us frequently. These are all pretty easy things to overlook. They're important, though, so we should try to be a bit more aware of them. When we're feeling particularly stressed over our projects, it's time to step back and go read a book or take a walk or something else relaxing. Maybe even do some manual labor like mowing the lawn or doing a home repair/improvement project. Or kick back, watch TV, and be lazy for a while. There's nothing wrong with any of these, most especially if it helps you take your mind off the problems for a while so you can come back later with a clearer head and attack from a different angle.
Several people have noticed the C Plugin HowTo that I've been writing on the Pidgin wiki. It's far from complete--I'm less than halfway through the libpurple part, and I intend to give a brief overview of writing UI-specific plugins for Finch and Pidgin. This project, though, is an exhausting one for me. It takes a lot of thought to write a how-to document that I'm willing to publish, with or without my name on it, and I'm trying to strike a balance between people who are starting out like myself, with a basic understanding of the C syntax and concepts, and those who have a firm grasp on it all but just need to see the structure of a plugin and how to interact with the libraries and application. For the most part I'm striking this balance by focusing solely on the former class--the ones who started like me. The latter class is generally intelligent and/or experienced enough to read the API documentation, use existing code as examples, and come away with the necessary understanding of what needs to be done. This isn't to say that the inexperienced or beginning plugin developer is stupid; it often takes a bit of orientation for these less experienced developers to be capable of finding their way through the plugin API.
Being an exhausting project, this how-to series has gotten me to the fatigue point more quickly than I expected. I realized this, however, and have taken the appropriate steps backwards to try to catch my breath. I'm still poking and prodding here and there, but so far the mini-vacation from wiki editing is proving to be a good thing, and I think I'm ready to start attacking the wiki again. I hope to pound out the Request API how-to, which will likely be the hardest one for me to write, this weekend. If it's not done by Monday, I will finish it the following weekend.
On an unrelated note, I'm messing around with CentOS 5 on a test server at work for use as replacements for our public DNS servers running older versions of the OS. The installer impressed me by having more granular package-level control, although I'm still having to go through and rip out a ton of crap that a public DNS-only server with ssh for the only allowed remote access has no need for. Once I have it pared back to bare minimums, the real fun starts.
Now I think I'll go to bed, since I have to be awake in two hours to go to work.
I'll start off with music. My tastes in music are a bit eclectic in some respects, and usually downright unpopular. I was raised primarily on country and oldies. In the US this means late 80's and 90's country music, which isn't a whole lot different from pop, and music from the 50's and 60's that fit into pretty much any genre but country. My one older sister (I have two older sisters and no other siblings) has always liked music in general, and so growing up with her around I occasionally picked up on some other forms of music, including rock. I find myself now, at 25, to be a somewhat picky music lover. For example, I despise rap, although a few mainstream country songs that have introduced some rap elements fall within my range of acceptability. My usual fare (as is quite obvious from my Last.fm profile) is country, although I branch out into Bon Jovi, Kelly Clarkson, and others. There's even a bit of Japanese music in there for good measure.
There's nothing specific that I look for in music to make me say I like it or I don't. I usually disagree with the majority of critics, although exceptions to the rule have happened. For example, the Dixie Chicks released an album called Taking the Long Way, their first album since being shunned from the music world following their criticism of President Bush (who I was stupid enough to vote for in 2000 as an 18-year-old first-time voter because I thought Gore was too stupid). Several critics loved the album, giving it very high praise. I too enjoyed the album. It had a pretty solid pissed-off tone throughout, while still covering a diverse range of stylistic influences and topics. Wow, I sound like a critic myself now. I need to stop that.
At the same time as I agree with some critics on select albums, I often disagree with critics and find myself quite liking albums that the critics have written off as pathetic. Essentially my musical taste runs the gamut from Neal McCoy's fun "Billy's Got His Beer Goggles On" to Sophie B. Hawkins' "The Darkest Childe", hitting numerous high points on the way, such as Massive Attack's "Teardrop" (House fans will recognize this as the theme song) and the entire body of Martina McBride's recordings.
The real point I am getting at here is that while I may gravitate towards some artists or styles, my taste is not limited to such. Even so, I've taken quite a bit of flak over it. Coworkers, codevelopers, etc.; you name the person, I've gotten remarks from them ranging from well-meaning jabs to acid-infused comments. I don't really care what people think of my musical tastes; I don't ask them to pay for the music I listen to, nor do I force them to endure it. It's my life, my money, and my ears. It's a legal practice, so I will use them in the way I see fit. I also won't take any crap from anyone over it.
With the music topic pretty much resolved to my satisfaction, I'll move to the other topic that I had in mind when I started this post--development fatigue. Every developer at some point reaches the point of being fatigued from the process. Every developer has his or her own breaking point, so there's obviously no sure-fire way to tell when this is going to happen. The important thing here is that we realize our limitations, push them at the appropriate times, and step back to take a breath when needed. The point of fatigue is the most important time at which to step back and breathe. If we don't stop at that point, burnout will follow soon. Stepping back before burnout happens and taking the needed rest and relaxation time away from the world of computers and code is an important step for both our mental health and our continued productivity as developers.
If a developer allows him/herself to burn out, it will likely take longer to "recover" from the burnout and return to productivity. If development projects are taken too personally, that burnout can also spill over into other aspects of life quite easily and cause a whole host of problems. Furthermore, once you've burned yourself out once, it's easier to do it again.
This all seems pretty obvious, right? Really it is; it just isn't a thought that occurs to us frequently. These are all pretty easy things to overlook. They're important, though, so we should try to be a bit more aware of them. When we're feeling particularly stressed over our projects, it's time to step back and go read a book or take a walk or something else relaxing. Maybe even do some manual labor like mowing the lawn or doing a home repair/improvement project. Or kick back, watch TV, and be lazy for a while. There's nothing wrong with any of these, most especially if it helps you take your mind off the problems for a while so you can come back later with a clearer head and attack from a different angle.
Several people have noticed the C Plugin HowTo that I've been writing on the Pidgin wiki. It's far from complete--I'm less than halfway through the libpurple part, and I intend to give a brief overview of writing UI-specific plugins for Finch and Pidgin. This project, though, is an exhausting one for me. It takes a lot of thought to write a how-to document that I'm willing to publish, with or without my name on it, and I'm trying to strike a balance between people who are starting out like myself, with a basic understanding of the C syntax and concepts, and those who have a firm grasp on it all but just need to see the structure of a plugin and how to interact with the libraries and application. For the most part I'm striking this balance by focusing solely on the former class--the ones who started like me. The latter class is generally intelligent and/or experienced enough to read the API documentation, use existing code as examples, and come away with the necessary understanding of what needs to be done. This isn't to say that the inexperienced or beginning plugin developer is stupid; it often takes a bit of orientation for these less experienced developers to be capable of finding their way through the plugin API.
Being an exhausting project, this how-to series has gotten me to the fatigue point more quickly than I expected. I realized this, however, and have taken the appropriate steps backwards to try to catch my breath. I'm still poking and prodding here and there, but so far the mini-vacation from wiki editing is proving to be a good thing, and I think I'm ready to start attacking the wiki again. I hope to pound out the Request API how-to, which will likely be the hardest one for me to write, this weekend. If it's not done by Monday, I will finish it the following weekend.
On an unrelated note, I'm messing around with CentOS 5 on a test server at work for use as replacements for our public DNS servers running older versions of the OS. The installer impressed me by having more granular package-level control, although I'm still having to go through and rip out a ton of crap that a public DNS-only server with ssh for the only allowed remote access has no need for. Once I have it pared back to bare minimums, the real fun starts.
Now I think I'll go to bed, since I have to be awake in two hours to go to work.
Thursday, July 19, 2007
Everything Changes (a.k.a Pidgin-SNPP is dead; long live Purple Plugin Pack!)
Ok, I know the title of this post is a bit lame, but you'll have that. Deal. :-P
The title is supposed to be an obvious reference to the maintainer of the Pidgin-SNPP protocol plugin for the Simple Network Paging Protocol has accepted a long-standing invitation to bring his plugin to the Purple Plugin Pack.
rizzo, the maintainer of pidgin-snpp, had mentioned that he needed to set up a Windows Pidgin build environment and work on his plugin. I reextended the offer to join the Plugin Pack by saying that the plugin would already have been released, and rizzo accepted. We're working on making the plugin compatible with Pidgin 2.x.y now.
Hopefully we'll release again around the time Pidgin does, new plugin and all. :)
The title is supposed to be an obvious reference to the maintainer of the Pidgin-SNPP protocol plugin for the Simple Network Paging Protocol has accepted a long-standing invitation to bring his plugin to the Purple Plugin Pack.
rizzo, the maintainer of pidgin-snpp, had mentioned that he needed to set up a Windows Pidgin build environment and work on his plugin. I reextended the offer to join the Plugin Pack by saying that the plugin would already have been released, and rizzo accepted. We're working on making the plugin compatible with Pidgin 2.x.y now.
Hopefully we'll release again around the time Pidgin does, new plugin and all. :)
Tuesday, July 17, 2007
Projects, Progress, and Competition
In my last post, I mentioned that I was wanting to push a release of the Purple Plugin Pack. Hard to believe it's been over two weeks ago already. Friday night, just before midnight, I finally released Purple Plugin Pack version 2.0.0. We changed our versioning scheme in the process too. The biggest, and most important, thing to mention here is that our major version will always match libpurple's. The other numbers have their significance as well, but they're not all that important--users should always be using our most current release. This release was significant in a number of ways--we introduced a few new plugins, added new features to several plugins, and also fixed a number of bugs.
In other areas I'm involved with, progress continues, even if it is slower than anyone would like. Gary's work on Guifications 3 has had some progress, and Pidgin has had some progress toward a 2.1.0 release. I wouldn't call this progress significant yet, but hopefully things work out with both projects.
For Pidgin, I'm hoping the infopane Sean is implementing improves significantly before the release of 2.1.0. If it doesn't we're never going to hear the end of it, and a ton of people are going to demand plugins to fix the many deficiencies currently present. The issues are numerous:
Speaking of Pidgin, Luke Schierer made a blog post the other day mentioning forking. In it he specifically stated that I was correct in closing a ticket on the Pidgin Trac that was soliciting a fork. I would like to take this opportunity to thank Luke for his support on my actions. Thanks, Luke. I may have been condescending and/or rude to the user who opened the ticket, but I feel justified in my response, especially given that the user actually agreed with me on all but one of the points I made.
When I started this post (roughly 0110 US EDT), I had initially intended to complain about the complaints I see on the Pidgin Trac. However, I've proven that I'm not much better than the users complaining in the tickets. Instead, I'll comment on something that I wish a few more users understood.
Occasionally a user in a ticket will have a complaint that, while valid, the user tries to justify by comparing to so-called competing IM clients. I would like to note that Pidgin is not in competition with any other IM client. There is more than adequate room in the IM client space for the myriad of IM clients that exist. This is simply proof of a point that Luke Schierer made, which is that no single IM client's user interface can satisfy everyone. Yes, Pidgin lacks features other clients have, such as default keybindings for smileys (a triviality to begin with that can be resolved within the realm of reasonability with .gtkrc-2.0), voice and video conversations, or more configuration options than ten copies of the Linux kernel combined. If the user interface doesn't meet your needs or wants, you probably should be using another interface. Ideally we'd love to see many different clients using libpurple as the backend code, enabling libpurple to serve a much wider audience in a better way by providing the facilities for others to reinvent the UI without having to reinvent the entirety of the backend.
On another Pidgin-related note, we've recently had a number of complaints about the lack of documentation on plugin development. Apparently the insanely large body of existing documentation--the doxygen docs and all the existing plugins--is not sufficient to satisfy some would-be plugin developers. In an attempt to address this, I've started to write a basic how-to series on the Pidgin Trac's wiki. I started by taking Gary Kramlich's existing start to a C Plugin HowTo and migrating it to the wiki, and I am now adding additional "chapters" to it. I'm not necessarily following any fixed format, but I'm trying not to half-ass this thing. My hope is that when I'm finished, I'll have a solid set of documents and accompanying plugins that will silence this set of complaints.
I think I'm done ranting for now. I might have more later.
In other areas I'm involved with, progress continues, even if it is slower than anyone would like. Gary's work on Guifications 3 has had some progress, and Pidgin has had some progress toward a 2.1.0 release. I wouldn't call this progress significant yet, but hopefully things work out with both projects.
For Pidgin, I'm hoping the infopane Sean is implementing improves significantly before the release of 2.1.0. If it doesn't we're never going to hear the end of it, and a ton of people are going to demand plugins to fix the many deficiencies currently present. The issues are numerous:
- Infopane-as-single-tab introduces dancing UI. This is very bad. If I have one conversation open, the infopane takes the place of the tab that used to always be displayed. When a second tab opens, the notebook magically appears, shrinking the history area and throwing off the history pane's scrolling. Keeping a second tab open at all times to avoid this dancing UI is stupid at best and a pathetic hack at worst.
- There is still no tooltip for the infopane. The whole point of the infopane was to provide blistnode-like functionality in the conversation window. We don't have any of this functionality except a status icon and buddy icon yet. No tooltips, no context menus, nothing.
- It appears the infopane will be fixed at the top of the window. I disagree with this design decision, but a preference for this does seem overkill. I'm hoping a plugin will be able to change the widget order so that I can have a plugin to move the infopane below the history pane like Sadrul had in his screenshots of changes he had made.
- Window size history is constantly being screwed with. It seems to me that I was once able to have my chat and IM windows (since I had them separated via the tab placement options) have their own sizes be remembered correctly. Currently I find myself having to resize every window when one gets created, because the most-recently-resized window seems to win out with remembering size.
- Not strictly related, but the argument about the status icon on the tabs is somewhat flawed. The close button on each tab wastes just as much space on the tab as the status icon yet provides no useful information to the user. I still know several users who dislike the close buttons on the tabs, even after nearly three years living without them (the prefslash days of 0.78 or so killed the ability to turn this stuff off, as I recall). I strongly advocate a boolean preference labeled "Use simple tabs", which defaults to false. When set to true, both status icons and close buttons would not be shown on the tabs.
Speaking of Pidgin, Luke Schierer made a blog post the other day mentioning forking. In it he specifically stated that I was correct in closing a ticket on the Pidgin Trac that was soliciting a fork. I would like to take this opportunity to thank Luke for his support on my actions. Thanks, Luke. I may have been condescending and/or rude to the user who opened the ticket, but I feel justified in my response, especially given that the user actually agreed with me on all but one of the points I made.
When I started this post (roughly 0110 US EDT), I had initially intended to complain about the complaints I see on the Pidgin Trac. However, I've proven that I'm not much better than the users complaining in the tickets. Instead, I'll comment on something that I wish a few more users understood.
Occasionally a user in a ticket will have a complaint that, while valid, the user tries to justify by comparing to so-called competing IM clients. I would like to note that Pidgin is not in competition with any other IM client. There is more than adequate room in the IM client space for the myriad of IM clients that exist. This is simply proof of a point that Luke Schierer made, which is that no single IM client's user interface can satisfy everyone. Yes, Pidgin lacks features other clients have, such as default keybindings for smileys (a triviality to begin with that can be resolved within the realm of reasonability with .gtkrc-2.0), voice and video conversations, or more configuration options than ten copies of the Linux kernel combined. If the user interface doesn't meet your needs or wants, you probably should be using another interface. Ideally we'd love to see many different clients using libpurple as the backend code, enabling libpurple to serve a much wider audience in a better way by providing the facilities for others to reinvent the UI without having to reinvent the entirety of the backend.
On another Pidgin-related note, we've recently had a number of complaints about the lack of documentation on plugin development. Apparently the insanely large body of existing documentation--the doxygen docs and all the existing plugins--is not sufficient to satisfy some would-be plugin developers. In an attempt to address this, I've started to write a basic how-to series on the Pidgin Trac's wiki. I started by taking Gary Kramlich's existing start to a C Plugin HowTo and migrating it to the wiki, and I am now adding additional "chapters" to it. I'm not necessarily following any fixed format, but I'm trying not to half-ass this thing. My hope is that when I'm finished, I'll have a solid set of documents and accompanying plugins that will silence this set of complaints.
I think I'm done ranting for now. I might have more later.
Subscribe to:
Posts (Atom)