Older blog entries for Cardinal (starting at number 5)

17 Feb 2001 (updated 17 Feb 2001 at 06:30 UTC) »

Got the announcement from RoUS that registration for ApacheCon 2001 was online. So I popped open the registration page, only to see.. the price. My God, was it that much last year? Of course, I don't remember last year's full price, because I went as a student then. $1300. That is a great deal of money for a relatively poor coder. (As it turns out, it was cheaper last year)

So, despite all the fun I had last year in Orlando, I think I'll have to pass on this one. Maybe next year I'll be a student again. Or, maybe the O'Reilly Open Source one will be cheaper. Who knows.


It's nice to get feedback on your projects. I've gotten a dozen or so pats on the back for php_imlib over the last few months, but January saw two people package RPMs for me, one of whom sent a patch against one of the PHP classes today. So that was pretty cool. Still need to look over the RPMs, then I'll put some links on the website. I also noticed, by way of referer logs, that the Apache Toolbox had added php_imlib to their todo list. It was later downgraded to 'doubtful'. Alas. :)


Submitted a short (1388 byte, 15 line) patch to raph to add the <proj> tag to advogato. It turned out to be a very simple thing to add, given the way the custom tag parsing is done.

Released php_imlib 0.3 today. Now that that's out of the way for a little bit, I can relax, fill up my time with other endeavors, and plan what to add to it next. (Image filters, probably. If I can figure out how they work.)

Of course, one minor problem with php_imlib is that it has a highly limited lifespan due to Imlib2's lack of thread saftey. Since php_imlib can't be thread safe, it will become fairly obsolete when Apache 2 becomes more commonplace, and offers threading. As far as I know, GD is also not thread safe, so PHP needs an alternative. One suggestion I've heard is that the Gimp folks are moving their graphics handling code into a library that might prove useful. Another option would be to just write a new one from scratch, though I have a hard time stomaching that one.

The Boss wants me to start learning/coding MS SQL Server. Hrm. Not sure if this would be a good thing to learn or not. At the very least, it'd help when I find myself having to talk to SQL Server from PHP, I suppose.

Well, we'll see how that goes.

7 Jan 2001 (updated 7 Jan 2001 at 06:35 UTC) »
dto: Thankfully as Trek dies off, Babylon 5 has been running on Sci-fi. If you're curious about shows with good endings, I'd say that one qualifies. JMS did B5 right. He had a story to tell, and stories have endings. He knew that. Didn't try to make it an open-ended adventure, just a good one. My only regret about the series is that it's difficult to show it to people who haven't seen it before, because I'm always compelled to show them the whole series, start to finish. Or at the very least, about 2/3rds of it. Without that bare minimum of background about what happens, a newcomer to the show would just miss so much good stuff, and I hate to ruin that for them. Well, who knows. God, G'Quan, or Valen willing, the series will be released as a set of DVD's in a year or two. :)

robhudson: If echoing html with escaped quotes is what drove you to use a template system in PHP, I can't help but be concerned. There are certainly better ways to use PHP than to echo out a lot of html and escape all those quotes. Breaking out of PHP for moderate sized blocks, echoing with single quotes and using concatenation for shorter blocks, using template files (Not to be confused with template systems. Template flles that fill themselves in when you provide them with an array, for example). The use of template systems in PHP comes up on #php on OPN now and then, and I just find the whole idea redundant, in that I'm yet to see a template system actually save somebody a noteworthy amount of time in the long run.. Anyway, that's my rant on that topic.


Bram's bad habits article was interesting. The last point was where I got to thinking about my project manager, who isn't a dumb manager. Looking back over how much crap the project itself dealt me, I wonder if I would've stuck around (The company is more or less a dot com) if he was a dumb manager.

He's not a dumb manager for a couple reasons. First, he's not a developer. He knows he's not a developer, and he doesn't aspire to pose as one. This defines our relationship well. He's also an english major, so he's no idiot. I don't have to speak to him like a child who only understands buzzwords and marketspeak. And lastly, I do keep him up on my progress. It works out. When we scoped the project, I gave him realistic and frank estimates of the work involved and how difficult or boring it may be. He takes that and presents the client with a completion date that's been padded a bit, and time added for QA to do their thing. If only QA didn't suck as much as they do, but that's a rant for a later date. I feel fortunate to have a project manager who I don't feel compelled to avoid or shut out of the development cycle, even if the clients have been nothing but a headache about feature creep and the client's corporate parent office can't properly manage their nationwide servers (Which I swear is a conspiracy to make my life harder).

Oh well, it's not like I plan on keeping this job for much longer. It's a dot com, it's transitory. Time to figure out what a good choice for a college degree is. You know, one that won't be a complete waste of four years. Now if only there were better options out there.

dirtyrat: Hmm. It'd be handy if advogato had a <lit> tag that you could use to enclose a block of code like that, and have it auto-translate the <'s and >'s to &lt;'s and &gt;'s

nooks: I have some issues with WinCVS. In my somewhat biased opinion, it's a usability nightmare, which is highly unfortunate. It seems to be the only widespread Windows CVS app, yet it looks like something a kid made in VB's IDE.

I'm particularly disappointed becuase a lack of a solid, relatively intuitive CVS app for Windows is about the only thing preventing CVS from being adopted at my place of employment. We're pretty much an NT/CF shop, unfortunately. I'm the sole PHP coder, and do XML work with another guy when issues of integrating apps comes up. So here's this company firmly within MS's grip, and it's hindering their productivity. They don't use SourceSafe, so the CF developers have to make sure they're not stepping on each others toes. SourceSafe is a disaster waiting to happen, imho, so I'd love to be able to say "Here, have CVS. It will solve all your problems, once you understand the basics, which I can explain to you in an hour."

It worked with Bugzilla, after all. They were using some MS Access form/database for their bug tracking. Naturally, it was terrible. Only one person could be editing the database at a time, it incurred the overhead of running Access, and didn't have nearly as many features as it needed. For my project, I set up Bugzilla and taught it to the QA people. They loved it, the testing phase for my project went smoother than anything they'd done before, and when we were done we had a complete, detailed history of all the bugs. So now Bugzilla will be replacing the Access form for the rest of the projects. See how easy it is?

Maybe there are other CVS apps out there for Windows. It'd be nice if the other developers would be cool with using the command-line tools, but that's somewhat unlikely. These are firmly GUI-dependent people. What about jCVS, has anybody messed with that?

deekayen: Yeah, the "RedHat is Linux" misconception bugs a lot of us, but it's a fact of life. After all, Linux broke quite a few rules and preconceptions when it entered the mainstream. One of the rules accepted by the general public is that an operating system is a product of a single company. Apple makes MacOS, IBM makes OS/2, Be makes BeOS, and so on. So when Linux started appearing, it was inevitable that a single distro would arise as the one people knew about. That distro would become "Linux" to many people. And, as most things in the States, the distro that won was the one that appeared the most polished and/or commercial (Quality is irrelevant to this process). We all know it's wrong, but being wrong never stopped anyone before. :)


So I was looking at XMLBoard a couple days ago, and since I'd taken an interest in XML earlier, I pondered if a PHP forum based on XMLBoard's DTD would be worthwhile. Sharing the DTD wouldn't really gain anything beyond the ability to migrate a forum from one platform to another. Sharing a forum between two otherwise unrelated sites would be an interesting option, though.

XML for a forum certainly has advantages. The first obvious one that beats SQL hands down is that the relationship between messages, regardless of how deep a thread goes, are represented automatically. I like that. Another good benefit is the ease of searching. There are, of course, downsides. Random access isn't the easiest thing to do. And how do you lock the file when writing posts? Well, there's a small project to look into some time.

30 Nov 2000 (updated 2 Dec 2000 at 07:26 UTC) »

Well, what the hell. Let's try something new and write a diary entry.

Since I'm not worthy of posting replies to the articles (Probably with good reason), I'll reflect on my own meandering experience here instead.

The modest proposal certainly sparked a good amount of discussion, the vast majority of which is of good quality, as lilo observed in a comment towards the bottom (at the time of writing. 'The bottom' was comment #29') A refreshing improvement over the usual Slashdot fare, to be sure. My initial thoughts after reading RyanMuldoon's article were agreeable as far as GLib, more or less agreeable regarding gconf and Bonobo, but uncertain where gnome-vfs is concerned.

The benefits of integrating all of the above libraries are plain, it's simply a matter of if those benefits justify introducing the libraries into a standard GNU environment. With GLib, this is pretty simple. It's a useful library that adds valuable features to any libc environment, so long as it is being put to use. Obviously any system running the Gnome desktop is using it, but at present the use of GLib, afaik, ends there. Would introducing Glib into all GNU environments as a standard library expand that use? Perhaps.

As I see it, there are two ways a library becomes 'standard'. The environment declares "This is standard," or the people declare "We want this to be the standard." Which method is responsible for more standard libraries, or which method yields more successful standards? Personally I would lean towards the latter. If GLib truly belongs in a standard environment, that should become evident naturally as programs beyond the Gnome sphere of influence make use of it.

My familiarity with gconf is virtually nonexistant, so I won't spend too much time blowing smoke. Unix, in its long life, has acquired a rather substantial inertia in many respects to how it works, not the least of which is how configuration is done. This exact issue was discussed at length some time ago on debian-devel, when the suggestion was brought up to move all Debian config files to an XML structure (IIRC, gconf hadn't been written at the time). The idea raises a series of important questions. How do you do that at a distro level without the upstream maintainers adopting the structure? Would they adopt such a structure? Would it become a peculiar feature limited to Debian packages, forcing Debian package maintainers to work that much more? And so on. So, as we ponder gconf, would a 'standard' configuration library be accepted by application writers beyond Gnome's influence? As with GLib (Moreso, actually) I think the best way to determine this is to see if it's being used, rather than push its adoption. I can already hear an argument against this. "But if people aren't aware of gconf or its benefits, how would they know to use it?" Well, that's an education issue. Get the word out. Tutorials, presentations at conventions, articles, and all that good stuff.

And speaking of good stuff, we come to Bonobo. Iain's pipes-for-GUIs comments were right on, I'd say. What I wonder about is if standardizing it in the GNU environment is even necessary, since its usefuless is focused on GUI-type apps. I think wider adoption of Bonobo would serve to benefit applications, though I wonder about apps that, for whatever reason, find themselves wanting to communicate with KDE's component system and Gnome's at the same time. For some reason that seems like it could get hairy. Anyway, I think Bonobo can stand, and thrive, on its own merits without being declared a standard library.

This leaves gnome-vfs. Whatever fate it may bring me, I can at least understand aaronl's reservations about seeing this sort of utility enter a standard environment, but my reasons are somewhat different. Where he sees unnecessary 'over thinking' (for lack of a better term) on the part of the Unix system, I simply see overhead. This is possibly because I'm quite fond of Debian's almost anal habit of breaking packages down into their smallest logical components. This has, for the last five years, consistently yielded a more efficient system that occupies, on average, half as much space as a comporable RedHat-based installation. I like that. So when I imagine a (potentially large) vfs being tied to my system at a relatively low level, I can't help but worry. As egnor quickly pointed out, wget | wc -w works just fine. :) Would it be cool to grep a web page without a pipe? Sure. I could think of countless uses for my standard Unix commands to take URLs as parameters, but is it the right thing to do? Well, that's certainly not my call.

Back to work.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!