Older blog entries for Rich (starting at number 5)

Day 5 of training class. This is perhaps the best student I have ever had. He asks the right questions, wants to experiment with what he has learned, and is very aware of what he needs to know, and what he does not, in order to do his job when he gets back. I need more students like this. Day 5 usually ends up being "let's get through this as fast as possible and get out early", but this guy wants to use the available time to the best benefit, and really learn this stuff.

Additionally, he's helped me improve my course, by pointing out all the places where examples would be useful, and he really wants to work through the examples.

Unfortunately, I have only one student this time around, so we really done even break even. But it's been a valuable class for me, and, I hope, for him. In fact, I've even learned some things in this process.

Meanwhile, I'm almost ready to send in my presentation for the OReilly conference. I'm sure I'll end up modifying it futher before I actually get there and give the talk, but I have to have them in by the 10th, which is Monday. Which gives me just a few more hours to work on this.

In the process of writing my presentation for the OReilly Open Source convention - Migrating from Apache 1.3 to 2.0 - I am learning so much about 2.0 it is a little alarming.

I'm reminded of when I wrote my first book - Apache Server Unleashed - and learned so much about Apache while writing the book. It was clear to me then that I was probably not the right person to be writing the book. However, during the process, I had to do a lot of work with the documentation, found a number of problems with the documentation, and ended up doing all I could to improve the docs through that process.

Although this won't turn into a book - I hope - I see some of the same thing happening in this process. In reading the 2.0 docs more thoroughally than I had done before, I am finding places that are either inaccurate or are incomplete and/or misleading, and more than a few typos and gramatical problems.

At the moment, I am working to arrive at a better understanding of the MPMs, and, in particular, the Perchild MPM, which promised wonderful things, but is still just a little incomplete. In particular, I'm trying to understand the whole thing of assigning a particular child process to a particular virtual host, which sounds pretty cool when you first hear about it, but seems to have a number of problems, even at the conceptual stage.

If a connection segfaults, it takes out the entire virtual host?

And in the case of the ChildPerUserId directive, if it really means that you are just assigning a user ID to a particular child process, what is to guarantee that all connections to that child will be for the desired virtual host. There's clearly a lot missing from this particular doc, and this is where the investigative documentation comes in - hassling the developers until I can get enough information to clarify the docs for normal people.

It's a special type of person that can develop these programs, but often they are unable to clearly articulate their ideas to mere mortals.

Released Date::ICal 1.61 last night. It is pretty cool, with things like overloading on - so that you can do

$duration = $date1 - $date2;

And there are some much more efficient internal algorithms, and a new class, Date::ICal::Duration, written by srl.

Get a new copy as soon as your CPAN mirror replicates.

In other news, I'm *almost* done with my book (http://www.apacheadmin.com/) which will be a happy happy day.

My publisher firmly believes that I spent the weekend writing a book, and I did in fact spend some of the weekend doing that. I even got some things done.

But most of the geek-time this weekend was spent working on Date:: Perl modules. I've submitted a story to use.perl about the new modules, and I don't feel like retyping it here.

The short form is that I wrote Date::Passover, Date::GoldenNumber, Date::Chinese, Date::SundayLetter, and updated several of my other Date:: modules. I think I also updated Apache::Htgroup, but that might have been on Friday.

I should have my copy of Calendrical Calculations any day now, and I really want to stake my claim to certain Date:: namespaces that look particularly fun. I almost wrote Date::Bahai this weekend (I might call it Date::Baha'i just for fun) but did the Chinese one instead because it is altogether more fascinating.

The Chinese calendar is *way* more interesting than the cycle of 12 animals that you've seen on your placemat at the Peking Moon. It is a cycle of 19 years, superimposed on a cycle of 10 years, superimposed on a cycle of 12 years. This is going to be a lot of fun.

Today I got out a new version of Date::Leapyear and a new version of Apache::Htgroup.

Randal Schwartz emailed me and asked why Date::Leapyear requires Perl 5.6. The real reason is that I lazily used h2xs to generate the module, and then never changed it. The new h2xs makes your module require 5.6, for no apparent reason. So I stripped that out and released 1.04

Someone asked me what license Apache::Htgroup was under. I've been meaning to attach a license to all of my modules, and had just not gotten around to it yet. So I stuck a LICENSE file in with the distribution and put up a new version, along with some other minor edits.

At TPC, we got a new version of Date::ICal out. Actually, about 3 of them. This was a complete rewrite of Date::ICal, in order to change the internals around and make it easier to work with.

The internals were icky, contained a lot of redundant code, and stored the date in several formats at the same time. So if you changed one, you had to make sure to go around and change all the others also.

Now there's just one authoritative internal format, and the other attributes are calculated from that.

Two changes that are still under consideration are:

1) Use Memoize to make sure that we are not recalculating the same stuff over and over. For example, when you call $obj->ical, it calls $obj->year, $obj->month, and $obj->day. Each of those, in turn, calls parsedays to get that attribute frome the julian date. That's just silly, since you end up parsing the date three times to get the ical string. Using Memoize will remove that, and speed things up by 3 in a lot of places.

2) Split the date/time floating point number into a date integer, and a time integer. We're getting round-off errors of a second, and that's just not acceptable. Splitting into two values will remove the roundoff, and be accurate for another 100,000 years or so. Should be sufficient.

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!