Ramblings of Narc

Well, it’s that time again, kids. That’s right, I can’t sleep. So… I figure since I’m up anyway, and I’ve rested my eyes somewhat, I should try to do something constructive. And try not to hate myself in a few hours. I tried to sleep.

On a completely random note, the subject of one of the pieces of spam I got recently read: “Sassy brunnete strips on stairs”. I totally mis-parsed that as “sassy brunette trips on stairs” the first time, and I wondered what kind of porn that was supposed to be.

Looks like Starfleet stopped forwarding port 25 at some point very recently. I wish I could say what went wrong, but I have no clue. The other forwards (like port 80) still worked, so everything was nice and accessible… except for SMTP. Except for *my e-mail*!

I noticed it had been up for 27 days. So I rebooted it. Let’s see if that solved the issue…

Update: Okay, now I’m pissed. That didn’t solve anything. Let’s try rebooting Hermes…

Update 2: Well, at this point, I’ve rebooted everything, and I’m pretty sure the problem’s not on my end. I guess I’m gonna have to ask around later. Or, you know, it might actually be working, heck if I know. It’s times like these I wish I had a host outside my immediate network to use for a nice telnet. Not too far outside my network, though. For far outside my network I have the Canadian folks’ servers (though I probably shouldn’t be using them).

Update 3: It started working again after about 24 hours. No explanation for what went wrong. *shrug*

One more for the notebook: HTTP Content Negotiation (wiki, spec).

Implement this for CMBlog3, to let it switch between application/xhtml+xml and text/html at will. Then code in some exceptions.

To start with, add a function to ua.inc to parse the Accept: header and return an array of accepted items, with their relative weights. And then maybe one more function to take that array, and an array of possible implementations, and return the most desirable one. Finally, implement in CMBlog3 a quick check of that last function and feed it array(“application/xhtml+xml”,”text/html”), and then output (via header()) the resulting Content-Type.

Inaugurating the notebook: some things I still need to do:

1. Give the ext_maker an interface; the new_ext and pack_ext functions (and their dependencies) definitely work sufficiently well
2. Also for ext_maker: make the update URLs actually work — probably will involve some DB messing-around. But that’s no surprise, item 1 above also requires the DB.
3. Speaking of which, again for ext_maker — I need a database! It has to hold all the contents of an $ext array, and to be able to rebuild said array as needed. Don’t forget the auto_incrementing build number, and make sure you never have a situation where you could be overwriting an existing package (obviously, the build number should ensure uniqueness)!
4. CMBlog3 needs some more advanced DB design, though for now the existing database will do as a minimal implementation. I’m very proud of how the install page turned out, it’s working beautifully.
5. As a more immediate requirement for CMBlog3, there is a definite need for a good implementation of the URL scheme we’re using. It should be formalized somewhere, to some extent. Heck, we might even be able to make a sitemap! *laughs*
6. Gazelle needs some love — it’s been stuck where it is for a while now. In particular, I’d like some more development of the article paradigm (how? Note to self: research what makes articles so special).
7. Existing and future projects, but especially the three already mentioned, could stand to standardize the whole application design a bit better. There’s a battle in my head between providing a NeoFWApplication class (which could be subclassed), or just a number of application_ (or site_ ?) functions (which could be extended in a fashion similar to how subclassing really works)
8. Speaking of object-oriented development, how about some more OO stuff? How about a fully OO version of NeoFW? Idle question: would that then be called NeOOFW, then?
9. It’s been forever since I’ve read up on RSS, Atom and all that stuff in detail. I’ve been reading up (mostly via Dive Into Mark) on some discussions about the relative merits of these syndication formats — and I’ve become convinced I not only need to implement both (well… all ten — RSS is actually 9 formats), but I also need to support some HTTP specialties, such as ETag and If-Modified-Since. After all, my bandwidth may not be free forever, yeah?
10. I sincerely hope WP is smart enough to do trackbacks right. And that I’m not misusing the code. I wish I knew more about Trackbacks. One more thing I need to start learning about.
11. Hm, up to 11 already and still counting. Well, let’s see… I mildly dislike Python, and I’ve decided that at least part of that dislike is from lack of understanding. Therefore, I intend to start reading up from Dive Into Python, and see if that gives me any kind of happiness.
12. On the personal front: need to pay more attention to what I’m saying. I tend to hurt the ones I love far too often for my (or their!) own good.
13. Also on the personal front, I wonder if I could afford a decent LCD or two. My eyes would really appreciate the investment, I’m sure.
14. Music: Nitin Sawhney is amazing! Find more like him.
15. Backups: Need to do some more backups. I’ve signed up to box.net for my off-site storage (1GB is about enough for the stuff I really care about. Heck, I could probably fit all my PHP code and DB dumps since 2004 in 20 MB if I had to (but I don’t, so there). But on-site backups are good, too… Plus, I’d die if I had to download all my music all over again. Granted, the best backup solution right now might just be to stick a small-ish hard-drive in Eris and backing up to it. Home-made NAS, anyone? Also, I’m starting to like SMB — it’s been working pretty flawlessly here for a few years now. On a similar note, Windows isn’t that bad, either: with uptime dictated more by power outages than actual reboot needs (and keeping in mind I’m also using it as a (secondary) workstation), Hermes is a pretty decent web, db, and mail server. But only for the low usage I give it, I’m sure.
16. Which reminds me: Sirimi needs to be reinstated, and all the stuff from Hermes moved to it (preferably after a whole reinstall of the latest LFS — personal preference).
17. Some more Perl-play might be in order. I’m not satisfied with the way I have to keep referring to the reference every time I need to do something simple (like read a file!).

Going to cut this short now (ha, it’s anything but short!) and continue later, as I have more ideas.

Oh, one last little bit of wisdom (some PHP code):
// Swap $a and $b in place (with "hidden" temp variable):
list($a,$b) = array($b,$a);
Some ampersands might be in order in there, I dunno.

Anyway, toodles!

So here’s a new project, inspired by this C2 wiki page: my programmer’s notebook.

I’m going to keep the notebook in here, under category “Notebook“, and it shall contain all the things I think about doing but don’t really have time for. Since I have more ideas nowadays than I have time (or immediate desire) for, I expect this category to very soon contain the most posts, even if many will be one-liners.

In other, related news, it looks like WordPress is winning out against MovableType by a huge advance. I think what I like most about WP is that if I don’t like something, I can just poke around the source code and find what its problem is. MT kinda offers that, sure, but I dislike Perl (look out for a rant on that topic later), especially when compared to PHP. Also, MT is much more like a black box, configuration-wise. I don’t know why (I suspect the two pieces of software have similar capabilities), but WP’s config just feels more open.

Well, I don’t know…

I’ve noticed lately a need for some nettiquette regarding the use of applications capable of both text (IM) and voice chats. This need revolves specifically around resolving who should call who, as well as both parties’ availability for voice chat.

Therefore, I am proposing the following four acronyms:

CYC?

(mnemonic: “Can You Call?”) — a question about availability and, simultaneously, an invitation for the remote party to start voice chat. Implies the local party’s availability for voice chat (duh?).

CIC?

(mnemonic: “Can I Call?”) — solely a question about the availability of the remote party for voice chat. Implies that, in case of a positive response, the local party will initiate the call.

YCC

(mnemonic: “You Can Call”) — a possible reply to “CIC?” which signals that the local party is in a position to accept voice chat, but would prefer to continue in text.

ICC

(mnemonic: “I Can Call”) — an equivalent to “YCC” (see above), implying the local party is in a position to start a voice chat session, but would prefer to continue in text.

Comments? Suggestions? Post below (note: comments are moderated).

For the longest time, I’ve been a person willing — rather, excited about — writing my own renditions of various interesting applications. When I started writing PHP, this tendency didn’t change — only the projects did.

One of the first Web applications I wrote was a very simplistic blogging app. There was an “add post” page, there were posts on the main page, and some simple login screens, and that was more or less it (oh, I think it had comments, too. I’m not sure anymore). However, because I didn’t save any database dumps, or anything similar, the project doesn’t exist anymore – I still have the PHP, but going through it to rip out the SQL, and using that SQL to figure out the table structures, would be amazingly boring — and, I daresay, useless.

My next big project on the same note, building on the experience learned in the previous one, was CMBlog v1. It featured multiple users, and multiple blogs, and various other nice things inspired, to some extent, by LiveJournal, Blogger, and whatever other projects like those might exist. CMBlog has served me well, but two years, and a lack of general interest, have taken their toll. A few weeks after CMBlog had grown to a state where it was no longer a simple application, and was actually doing most of what I wanted it to do, I realized it really wasn’t anywhere near what I thought it would be. Sure, it was fast. Sure, it was simple, and clean. But that was only on the surface. The code behind it was a muddled mess, and making sense of it in order to add features (or fix the existing ones) was getting more and more taxing.

So I declared CMBlog finished and started work on its successor, learning from the failings of the past — as I always seem to do in these things. CMBlog2 never really took off. At some point down the line, I realized the architecture I had chosen was really unfit for building something like what I wanted. I let it get as far as being a read-only version of CMBlog before locking it, always thinking “Well, I’ll come back to it when I have a better design, or a better way to keep the code clean”. That day never came, and other projects (not all of which are featured at that URL) came and went, and I learned more and more about how to do things right.

In PHP, one of the best architectures you can choose when, like me, you have a lot of related websites, is one where most parts are stored in one central location, and included as needed in each project. Thus, NeoFW was born, and has now become the repository of all my useful and semi-useful functions that I’ve written over the years. NeoFW is my codebase.

However, since I got a job (and for quite a while before that), these projects have been advancing at a glacial pace, and at one point, I stopped working on most of them, maybe writing a quick little hack-job, but never something that took longer than a few hours to write, and usually just copy/pasting the base skeleton from a previous little project, and maybe making a modification or two. The latest such mini-project was JGH, which stands for “Just Got Home”, and which is a relatively simple personal email gateway, designed to keep me and my girlfriend in touch by serving as a simple way to write each other long long emails and then send them without worrying too much about losing our progress during the day.

These mini-projects have all had one great advantage: they have, through every iteration of the same basic design, taught me how to make it work just right, and I’m now reasonably confident I can make it work for another iteration of the blogging application.

And so, after that long and somewhat rambly introduction, I come, finally, to what I announced in the title: CMBlog3.

CMBlog3 will be taking NeoFW to its first stable format, as during the project I suspect I will be requiring a large number of things to be working properly, which will stabilize the design on those parts I haven’t had cause to lock down yet. Such things as application-specific preferences, and the like.

But, to start the whole thing off, CMBlog3 needs a database — because I don’t want to reuse the old one. The old one really is kinda crappy.

The original design used five tables, namely blog_acl, blogs, comments, posts, and prefs. blog_acl was for the access control lists: who had access to what blogs. blogs, posts, and comments are self-explanatory. Finally, prefs was a special table, holding each user’s preferences, albeit in a very ugly fashion. The user tables (along with the entire user-handling substructure) were handled by EPRU — a user database and set of API functions.

The new design will probably keep the blogs, posts, and comments tables — it’s pretty much a requirement — though I do expect the structure to change. NeoFW will handle the user API, including user preferences. Finally, the access control list will have to change dramatically, as I wish to provide a lot more granularity in the preferences — down to the comment level.

This post was initially only meant to help me design the database, though I suppose along the way it turned into a bit of a history lesson. Either way, here’s what I’ve got so far:

• CREATE TABLE blogs (
  • id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  • name VARCHAR(255) NOT NULL DEFAULT “”,
  • tagline VARCHAR(255) NULL DEFAULT NULL,
  • user_id BIGINT UNSIGNED NOT NULL DEFAULT 0,
  • created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • deleted TINYINT(1) NOT NULL DEFAULT 0,
  • deleted_at TIMESTAMP NULL DEFAULT NULL

  )

• CREATE TABLE posts (
  • id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  • blog_id INT UNSIGNED NOT NULL DEFAULT 0,
  • user_id BIGINT UNSIGNED NOT NULL DEFAULT 0,
  • title VARCHAR(255) NOT NULL DEFAULT “”,
  • content LONGTEXT NOT NULL DEFAULT “”,
  • created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • deleted TINYINT(1) NOT NULL DEFAULT 0,
  • deleted_at TIMESTAMP NULL DEFAULT NULL

  )

• CREATE TABLE comments (
  • id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  • parent_id BIGINT UNSIGNED NOT NULL DEFAULT 0,
  • post_id BIGINT UNSIGNED NOT NULL DEFAULT 0,
  • user_id BIGINT UNSIGNED NOT NULL DEFAULT 0,
  • content LONGTEXT NOT NULL DEFAULT “”,
  • created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  • deleted TINYINT(1) NOT NULL DEFAULT 0,
  • deleted_at TIMESTAMP NULL DEFAULT NULL

  )

That all should cover the first parts, with the minimum of metadata. You’ll note comments include a parent_id, which allows for threaded comments.

With these basics in place, I can begin work on the engine itself. The metadata, such as access control and the like, will be included in separate tables I can create later. Hopefully, there should be good stuff to link from here later.

Update: I forgot to mention — these tables, when in MySQL, should be TYPE=InnoDB, to take advantage of that storage engine’s transaction support. Since it is very likely that multiple tables will be updated at the same time (consider the fact blogs have an updated_at timestamp, and that it should reflect when a post was last added to them), this particular bit of magic is very desirable.

Welcome. Welcome to City 17…

Hm… then again, maybe not.

Hi, I’m your host, Narc. I run this website on my very own computer sitting in my very own home, using my very own Internet connection, and an array of magic that keeps everything running smoothly for as long as I have power and bandwidth.

I’m also not that interesting.

This blog is here so I can test WordPress against MovableType, to see which one I like more (if any), or if I wouldn’t really prefer to just write my own blogging engine. Somehow, I sincerely believe it will be the latter, but even so this will be useful by giving me ideas of features to add and such.

I don’t know how you found this place, but whatever the magic, you’re welcome to stick around as much as you like. But remember you’re in my home, so behave. My bandwidth may be unlimited but my patience is not.

Be safe!