[This is a post in my latest, probably long-ass, series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.
IMPORTANT NOTE! When I provide you links to code on GitHub, I’m giving you links to particular commits. This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post. Just be aware that the latest version of the code may be very different.]
Last time I babbled on for a while about my general plans, and finally came up with a name other than “my perfect date module.” This time we stop screwing around and finally write some code.
I decided to start out with the date class. In retrospect, I sort of wished I’d started with the datetime class, as that would’ve been a lot simpler. But the date class was more interesting, and more immediately useful, so that’s where I started, so that’s where we’ll start as well.
[This is a post in a new, probably long-ass, series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.]
Last time I went into more details about how I might go about creating a new date module, and what I would expect it to achieve. This time we clear out some housekeeping and try to nail down a design strategy.
Before I get into that, I should point out something fundamental: I’m still in the design process. I once read a story about Harlan Ellison1 in which he wrote a short story, in real time, with fans watching as he did so. As he finished each page, he posted it up on the wall (or wherever) for them to read. The point of the story, I believe, was about revision, and to illustrate an extreme situation which might be the only case in the world where you actually couldn’t go back and fix what you wrote at the beginning.
So this is a bit like that. Except that I won’t consider myself stuck with whatever I manage to produce at the beginning here; if I make a mistake or stumble across a better way later, I’ll go back and fix it. If someone points out something in the comments that makes better sense than what I had in mind, I may completely change direction. Hell, if someone comes along and says “hey, have you looked at Date:Dohickey?” and I go and look at Date::Dohickey, and it turns out that Date::Dohickey really does do everything I want, I may very well scrap the whole idea. So I wanted to give everyone fair warning that there may be sharp turns ahead. So hold on tight.
[This is a post in a new, probably long-ass, series. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.]
So, last time I laid out my dissatisfaction with existing date modules and described what I was looking for in a feature set out of a potential new module. Well, a feature set is a good thing to have, but it’s a lower-level view. Let’s take a step back and try to pin down exactly what need I want my date module to satisfy; that is, what niche am I hoping it it will fill? When you’re looking for a date module to solve a particular problem, which problems will lead you to this one?1
[This is the first post in a new, probably long-ass, series. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.]
The topic arose at
$work recently: what do the cool kids use for dates these days? Our sysadmin was looking for a simple way to get “tomorrow.” Of course, the cool kids are theoretically using DateTime, right? So, how do we get “tomorrow” out of DateTime? The answer came back in our chat room:
Well, okay ... that would work. But it’s not exactly what I’d call “easy.”
Last week I formulated an interesting problem in text processing while working on one of my hobbies. Since I was only able to devote an hour or two here and there, it took me a few days to get the solution up and running, which indicated to me that it wasn’t as simple as I’d thought it would be at first. And since “not simple” often means “interesting,” I thought I’d share it here with you. (Note that I don’t claim this is the best solution, or the most efficient, or the most elegant. I’m perfectly happy to receive suggestions for improvement if you’re so inclined.)
The exact application isn’t important, 1 so let’s just look at the general parameters. There’s a series of cards, and each card has one or more powers on it (where a “power” in this case just means a block of text). I have a file with all the powers in it, and a little script to help me search for patterns within and across the powers. Let’s assume the powers come in, one per line, like so:
Name of Card / Name of Power : Description text of power.
(They’re not actually formatted like that in the file, but I have another script that transforms them into this.) So my analyze script lets me search for a given regex (Perl-style, natch) and prints a nice summary of the results, like so:2