This Matrix Reloaded review gets me all hot and bothered whenever I read it. I'm just reading the excerpts, not the original review, because I don't want to get spoiled, but I'm psyched.
The StructuredText parser I've been working on over the past few days simply kicks ass. I'm actually pretty proud of the code. I've whipped it out fast and it's designed really well, IMO.
One part of it, though, has been giving me a lot of problems. The inline parser, which parses the structure of an individual line, separate from the main parser which parses main blocks like paragraphs, blockquotes, and lists, has been a lot more difficult to write than the rest of the code.
Hmm... I entered the above into w.bloggar last night and saved it. I had planned on elaborating on why the inline parser has been difficult, and on describing the design of it, but I have no time now.
However, one of the decisions I'm going to have to make is a weird one.... I'm writing the thing in Python, because whenever I try to write anything big or complicated in PHP I wind up cursing PHP out every few minutes. Largely, I think, because I'm never sure that I'm not making copies everywhere because of PHP's broken OO. Whatever the reason, Python is just far more comfortable to work in, and I think my productivity has been much better with it than if I had written my code in PHP.
With that said, I'm only prototyping the code in Python. The "real" implementation is still going to be in PHP, since I want to use the code on my website, and well, my website is written in PHP. However, the Python code is much awesomer than the PHP code will wind up being. To give one example, in Python you get to say nice things like line = line[beginning:end] to suck out part of a line you're interested in. In PHP I'm going to have to say $line = substr($line, $beginning, $length-$end). After looking at that, I'm beginning to think that dollar sign variables aren't so hot.
So this leaves me with the prospect of wanting to maintain both the Python and the PHP versions of the code. The difficulty is exacerbated because the code is much more than just the base parser. It's "pluggable", so you can add new content types (like, in addition to paragraph, blockquote, etc., you can add "code block", "note", "user-entered text", etc.), parser components (for instance, a different list syntax or a different table syntax, and a parser for "note", "code block", etc.), and for each content type, you have to add a "generator" for your destination language, it being HTML, LaTeX, etc. And, realistically, I'd much rather maintain and use the Python version, especially for anything but HTML generation, since it integrates better with my computer than PHP does, rather than my web server, which is what PHP specializes in.
So, I guess I've made my decision. This is why I write things like this out sometimes 
I think the primary version will be the Python version, and the PHP version will always be a simple translation of the Python version. I'll make both available for download. At the very least it'll serve as an interesting language comparison Unfortunately, it's not going to get finished until I get that line parser thing figured out, and that's not going to happen until after finals, and until after my road trip (yeah baby) after that.
This is horrible, and very disturbing.
On the front of the file folio is a strip of computer stickers, the kind used to track inventory, bearing the number 507989493; they seem to be file locators. "Look how big that number is. It was indescribable what they did. There are millions of files, millions."
Joe at BitWorking.org has implemented what sounds like a great scheme for user-editable comments -- without forcing user registration.
Basically, when you leave a comment, the system spits out a URL with a unique key in it. If you visit that URL again, the system can be sure it's you, and you can edit that comment.
On the one hand, this solves the problem, but I like this about as much as I like RSS feeds for comments. It involves having to manually keep track of (ie. bookmark) each comment you make, which, come to think of it, is even more of a pain in the ass than having to subscribe to an RSS comment feed, because at least there's only one feed for each post.
There are two other solutions I can think of. First, keep shit in cookies. A hash for security along with a post id isn't too much data. And to limit the amount of data, you could always keep only the last N posts around, so at least it won't grow indefinitely. And, my cookie framework already automatically keeps a hash of the entire cookie for security, so I probably wouldn't have to keep a separate hash around for each comment id. That's awesome. I can just send a simple comment id in plain text and you can't do a damn thing about it, since you don't know how to generate my hash
The second solution is, as part of a subscription plan, to allow someone to access a list of posts they can edit. There are a few ways to do this, but the point is that someone's e-mail address is a pretty good source of identity, so if you give them a unique ID to keep track of which they spit back to your site, you can be pretty sure it's them. Again, that's "push", not "pull", as having to bookmark pages would be.
However, I'm not sure if letting people edit comments on a weblog is a good idea in the first place. It's one thing if you're a member of a forum... there's some accountability there. But I'm reticent to allow essentially anonymous people to muck with a conversation that's in progress, potentially changing what they've said. And I'm not about to implement a weblog comment revision scheme so that there's sure to be accountability... so... best I'll do is put a comment preview back as soon as I get around to it 
Sunday, May 11, 2003
Permalink
new⇒Free image hosting sites
Well, TinyPic has this in itsFAQ:
> Images and videos is inyour accoun...
Keith: Dec 1, 1:13am