The ORM in this case is phpActiveRecord. I had used this in other projects and had a generally positive experience, so I thought it would be a decent fit for this quick little user registration database I had to set up.

Of course, I had neglected to check whether or not phpActiveRecord worked with PostgreSQL. Silly me, when I looked at this page and saw ‘pgsql’ in a DSN, and when I read that PDO is used for the backend — which provides a decent API for the library to use — I assumed that I would be safe.

In short terms, no. In longer terms, fuck no.

There’s an error, apparently in all versions that I could find, in the pgsql adapter. I guess there were some attempts to fix it, but it remains uncommitted to the main branch, despite being a year old.

So good-bye to phpActiveRecord. It was fun, that one time when I used you and you worked correctly. You can now join the wall of shame with lack of PostgresQL support along with WordPress and Drupal. (Yes, I know Drupal core has at least partial support, but modules may not necessarily support pgsql — which could have been avoided with a decent ORM).

The saga continues… sigh…

Fast forward to a few weeks ago when I hear about circuits.web, part of the circuits framework. Event driven, modeled after CherryPy, asynchronous, web-socket support, and loosely coupled — which I need this time.

I’ve spent the better part of three weeks working with circuits.web, and I can say it’s been a resounding disappointment.

First of all, documentation is non-existent. And when I say non-existent, I mean non-existent. The core circuits framework is poorly documented at best. The circuits.web component isn’t documented at all. The closest thing to documentation is a collection of asinine examples that have almost no merit for real life applications, if they even work at all.

Second, I can’t exactly tell if the project is still being worked on. When I first started, I naively looked at the dates on the recent commits to the whole circuits project. The circuits.web portion hasn’t been committed to since August. WebSockets were made a candidate recommendation in December. Nothing in circuit.web’s implementation needs to be changed? That makes me suspicious.

Lastly, the Component architecture seemed like a good idea, but it seems to be thrown together in no logical way. Case in point?

Components handle events. Controllers inherit from Components. Controllers can’t handle events. Or if they can, I couldn’t figure out a way. Who knows why — there’s no documentation.

I was trying to create an Authentication component for an admin controller. There are of course, no examples of this. The authentication examples — that is the ACL, HTTP Auth, and HTTP Auth using /etc/passwd — all use an authentication scheme that is site wide.

What I needed was a way to pick specific actions that would require authorization. I figured out a way by accident, and within 3 seconds found a way around it due to the “channel” member of the Controller.

The channel in circuits.web, I assume, specifies the routing for the dispatcher to find the object. So your Admin Controller object might have a channel of “/admin”. The problem I found, using a Component for forcing authentication, I could bypass the Auth Component by going to, “http://localhost/admin/“. Note the trailing slash.

Change the channel to “/admin/” or “admin” and get a 404 on all admin actions — but the auth component works.

And that’s where I’m at. I should have went with CherryPy on this project, but no, I guess I felt like being disappointed by Python web frameworks again.

• I’ve been in 2 serious relationships with crazy (and I do mean crazy) girls — both ended crappily.
• I still hand wind my guitar strings.
• I’ve worked with PHP since version 3 and I’ve had a job doing it for 5 years. I actually gave up a job doing embedded systems with C to keep doing PHP work.
• I keep thinking I want to learn Erlang.
• Lastly, and I think this is the big one, despite the fact that I’ve worked on no less than 3 failed IRC clients — I started working on an IRC bot project.

If you didn’t know, IRC was invented in 1793 by the world-renouned horrible person, the Marquis De Sade. He was so horrible, in fact, that the term sadism comes from his name. The work I’m referring to is RFC1459 — arguably his most notorious and mind-boggling work. RFC1459 is part of the reason some people consider De Sade to be the devil incarnate.

RFC1459 was so bad that the IETF has refused to standardize it. An attempt was made in 2000 to update it with RFCs 2810, 2811, 2812, and 2813. After reading all of them, I can’t really tell what was updated. It’s more like someone took the original document of unholy sin and smeared it across 4 others. And even after this act of moral indecency, it’s still not standardized. It’s not helped by the fact that the “updates” weren’t even supposed to be considered a new standard and also pretty much every IRCd and client does whatever the hell they want.

Here are some things I really, really hate about IRC. I mean other than it being a complete total stab in the groin…

Ident
Does anyone actually have an actual ident daemon running? And does it actually help anything? It’s pretty much a useless addition — and why it’s mentioned in the IRC protocol (and by protocol, I mean random suggestions) I could only speculate.

Mode strings
This is probably the worst abomination of the entire spec (and by spec I mean loose collection of internet bowel movements).  So there are user modes and channels modes. A mode character can have parameters or not and a mode string can consist of any of the mode characters or a bunch of them. Because of that, you end up with this kind of crap:

MODE #liek :+om-v+b nick1 nick2 *.aol.com

Which sets nick1 as an operator, sets the channel to moderated, takes voice away from nick2, and bans aol users from the channel. Look at sections 3.1.5 and 3.2.3 in RFC2812 for some more awful ideas.  If you think parsing that is not so bad, then you should know that not every IRC-network is going to have the same modes. And to figure out what modes a channel might have…

005
RFC2812 says that numeric reply 005 is, “Sent by the server to a user to suggest an alternative server.” It’s just not true at all. In all my years of working with IRC, I’ve never seen 005 used in this capacity.

005 is used for relaying the server configuration to the client. This is a separate, 5-year old document that explains the ISUPPORT reply. Of course, it’s not official or anything. It’s not even really called ISUPPORT. The page I linked to at least tells you what IRCds are doing what. Keeping track of all that configuration info is unbelievably tedious.

NAMES
Channels on IRC are usually small, but on the off-chance that you find yourself in a warez channel, you’ll be in a sea of people. When you join in the chat, the server will send you the list of other chatters, which can take quite a while depending on the legality of the channel you’re in. The problem:

The names list can be too large to fit in to one packet, so the server will break it up. The problem is that if you’re in a big room, there’s bound to be lots of activity and the server will broadcast whatever messages it’s supposed to no matter what it’s doing. So rather than queuing a JOIN notification while it’s processing the names reply, it’ll just send the notice right in-between packets.

Yeah, me too. I also have no idea what order the names list might be in. I have no idea if it’s random, alphabetized, or predicted by Nostradamus — there’s nothing in the spec (and by spec, I mean not-spec) about it.

So how do you know what the NAMES reply is? Unlike JOIN or QUIT or KICK, when you request information from the server, chances are you’ll get a numeric reply.

Numeric Replies
By numeric, they mean a string of numbers — not actually binary numerics. There are a few things I don’t understand about numeric replies.

Why do some things have a numeric reply instead of just the text? Take NAMES for instance or WHOIS. I thought it had something to do with if the client sent the message requesting a reply. But then why is 005 considered a numeric reply? Or 001? Both are sent by the server after a connection.

Where the hell did these numbers come from? There’s some basic organization — 0xx are informative, 4xx are errors, 3xx are requested info… sometimes… 2xx are used for… uh…

Beyond that, I can’t figure out why the NAMES reply is 353 and the “End of NAMES” message is 366. MOTD Starting is 375, the actual MOTD packet is 372 and MOTD Ending is 376.

Additionally, when mentioning what reply is generated from what message, the spec (and by spec, I mean gelatinous blob of useless goo) refers to the numeric codes by a  name! Sending a WHOIS on a user generates a numeric reply of RPL_WHOISUSER — which is actually numeric 311. This makes things exceptionally hard to follow and you’re better off experimenting with viewing the raw output from the server.

Security
For a while, there seemed to be a trend in having SSL connections to servers. It makes sense for say, HTTP or FTP — *real* protocols I mean. But because SSL connections are not required  for every client, IT BASICALLY MAKES THE WHOLE THING POINTLESS!!! Yeah, now I’m yelling!

You know those popups that you get in your web browser that say, “This page contains both secure and non-secure items.” — You have the option to ignore the non-secure items. If you had that option on IRC, it would basically ignore 90% of the people on there.

Packet Length
It bothers me when connection oriented protocols (and by protocol in this case, I mean…. you get the idea…) reimplement stuff that TCP already does. Actually, I think the IRC protocol is the only one that does this.

TCP already breaks up things in to packets and lets you know when the stream terminates. Think about HTTP, you send the GET request, then stream everything down and then it terminates and you’re done. If you’re getting a 2MB html doc (god forbid), you don’t get it all at once — but no HTTP client on earth has to check for a line termination every 512 chars and then check to see if it sent the “End of HTTP Stream” message.

Unicode and I18N
The Marquis de Sade, being the awful, evil man that he was made no plans for IRC to ever be in anything but 8-bit ASCII. Which is weird because he said that hundreds of years before 8-bit ASCII encoding was invented. I have yet to find *any* information in 10 years, whether official or “official,” about how Unicode works with IRC. I’m sure non-ascii characters can be sent — but as for the server encoding, BOM, etc… it’s a mystery.

CTCP and DCC
At some point, some genius decided that instead of extending the protocol that extensions could be added by a hack in to an existing message.

There is, of course, yet another document about this “part.”

Trying to add support for these basically makes your handler for PRIVMSG 9000x bigger than it was. Also, you give yourself a massive headache and you start to think, “I must be a friggin’ masochist to be working on this.”

The biggest crap-sandwich that one must eat is that the Client-to-Client Protocol goes through the Server. I’m gonna start yelling again. How about a rule that says you can’t call it a protocol if all you do is wrap some capitalized letters with \001? I’m gonna make an HTTP variant called FATTP (Fucking Awesome Text Transfer Protocol) which takes regular HTTP verbs and wraps them with \001. Fuck you.

But DCC takes the cake. Not only is it ass-backwards and full of errors — once again, you must reimplement parts of TCP stream control in order for it to work right. DCC Send is the real culprit — and it was supposedly replaced by DCC XMIT in 1997, but good luck finding anything that uses it.

The CTCP-97 document intends to offer an official spec for formatting codes. The problem is…

mIRC
Currently the biggest piece of crap in IRC today is mIRC. For some reason, it is the standard for IRC clients. It uses a broken color formatting scheme, old DCC code, horrible scripting, a poor interface, and yet, you still have to pay for it. There were many, many times when during the development of Zephyr (the IRC client I was working on from 2002-2004), we came to a point and said, “We don’t really know what to do here… What does mIRC do?”

So, given all these reasons, why can’t I convince my friends to move to jabber or something? Don’t they know what kind of state it puts me in?

At least this time, I’m only writing a bot. And, aside from reading the IRC RFCs… *sigh* I’m enjoying it.

See? Masochism.

A possible switch to a different blog software may be in the works if they don’t get their act together.

See, every once in a while, I’ll get the urge to program something. Yesterday, I went to start up a new WPF project in C# Express. I wanted to code myself a little forecast/weather grabber from the NOAA NDFD Forecast Soap Service which I had experimented with before. So I added the service to the project and had Visual C# generate the code, as has been the way for a long time.

Lo’ and behold: it didn’t work.

Turns out that the service didn’t specify an encoding or didn’t encode properly. C#  wants everything to be UTF-8 or UTF-16, and dies thusly. It wasn’t dying or throwing a warning about the encoding while generating the code, or even instantiating the service, but only when data was recieved after the method call. Turns out, the way to handle encodings other than UTF-* is so unbelivably complicated that I don’t care to do it, especially when specifying the encoding could easily be an option when generating the code.

So while I’m debugging this project and trying to get it to work, a “Help Update” dialog pops up and prevents me from doing anything. I try to stop the debugger at least, so this update can complete and VS tells me that it’s waiting for the update to complete. Ok… so I wait. And wait…wait and wait and wait… nothing. According to Task Manager, this update is burning up 100% of my cpu, so I get mad and terminate the process. It takes me two or three times of terminating the process before I can actually get it to die and get control of VS back. As I stop the debugger and prepare to close the IDE, the update dialog comes back, continues to burn up my cpu and my patience.

“Something must be messed up,” I think. So I repair the MSDN install. It comes back. I repair C# Express. It comes back. I uninstall MSDN, effectively removing what needed the update (or so I thought), and it COMES BACK! I uninstall C# Express and the problem goes away :)

So I’m done with Visual C# Express for a while and my high opinion of the MS development tools is shattered. It’s a shame too — I had high hopes for XNA.

Oh yeah, my computer at home is kind of shot and I can’t afford to get a new one. So this site will probably go unmaintained for a bit.

I’ve been stuck with it for years. It is the language of choice for people who run servers and hate web developers. So yeah, 5 years of PHP and MySQL …and using so many different libs for database abstraction has given me some room to shoot my mouth off.

Anyway, this is going to be a long post and not for the faint of heart.  I’m going to start off at the beginning…

1. I was a mysql_* junkie

It’s true — I was. But hey, it was PHP4 man! Love was free! No one knew about SQL injection just yet. We didn’t need features…just some SQL knowledge and a while-loop. Oh, how innocent we all were.

I’m never using this again because: It’s an unbelievably monstrous pain-in-the-nuts to use these functions. They’re totally unsafe and take no advantage over any of the features in the versions of MySQL greater than 4.0. It has been removed from the default PHP5 install.

2. Then I discovered, PEAR::DB and my journey started

I can’t remember how I discovered PEAR or any of the packages in it. I do know that I wrote a TON of boilerplate code with the mysql_* functions, especially with insert and update statements. So I imagine I was searching for some way to cut back on this and also I had probably started getting wind of SQL injection.

Holy crap — I totally found what I was looking for. The autoPrepare and autoExecute functions! This was perfect. The prepare/execute methods also helped me a great deal. It was truly a great day to be me.

I’m never using this again because: IT’S SO SLOW! I’ve never, ever, ever before or since had a single, legitimate PHP script increase the load time on a project to 5 seconds. It was unbelievable. Never mind the fact that the entire package has been deprecated. I gave it up long before. Also, error handling created a large amount of repetitive code. I actually had keyboard shortcuts in Eclipse (yeah, I said Eclipse) to paste a snippet for a query with error handling.

3. Time to find something else… look deeper at PEAR… find PEAR::MDB2

From the PEAR::MDB2 documentation:

PEAR MDB2 is a merge of the PEAR DB and Metabase php database abstraction layers.

More on that briefly. In the meantime, HOLY DAMN THIS IS WAY FASTER! How did they manage to get this *that* much fast than DB? Anyway it doesn’t matter. The romance was short lived….

I’m never using this again because: While I could consider this *my* fault if present-day Matt did this, back-in-the-day Matt took “merge of the PEAR DB…” statement to mean, “compatible API.” Wrong. I had to change every single query I wrote with PEAR::DB. I should have seen this as an omen…

Read the changelog. I can’t remember when I started using it exactly, but I have a feeling it was around Beta-2 when I saw the statement,

The core of MDB2 is now fairly stable API-wise.

Now check later releases…go ahead…I’ll be here. Notice anything? They all start out with, “Warning: BC breaks.” That’s Backwards-Compatibility to those who don’t know. Do you know what’s more frustrating to a developer than relying on a library that breaks backwards compatibility with every release? Nothing. You could pour fire ants down my ass-crack and taunt me with an Epi-Pen as my throat closes from anaphalyctic shock and I wouldn’t be so annoyed.

At this point I stopped using MDB2, waited for the API to stabilize, upgraded and fixed that dozen or so sites that used it. Then I buried it inside the cemetery in my mind. Their release schedule probably made me start noticing how ridiculous the PHP community was when it came to Release Tags — but that’s a rant for another day.

4.  MySQLi am the Walrus

I tried MySQLi.

I’m never using this again because: The API is worse than Hitler.

5. PDO plz

Around 2006, I started hearing some buzz about ORMs and I thought PHP Data Objects was one. It’s not. It’s a DB abstraction API. That said, it was clearly the best attempt so far to some kind of standard. There are lots of goodies like prepared statements and parameter escaping. It tends to be a bit verbose, like any non-ORM DB layer.

I’m never using this again if I can help it because: Upgrading PHP becomes a hassle. PDO is built in (more or less) to the PHP stdlib. The problem is, none of the PDO db-drivers are — they’re all extensions. So when I upgrade PHP, I have to rebuild the database driver. Yeah, I’m lazy.

6. ADOdb FTW!

Now we come to my latest choice of library. I knew about ADOdb long ago, but for some reason, I didn’t use it. It wins for a bunch of reasons. I love it now though.

1. It’s fast. I’ve never felt a performance hit because of it.
2. It’s mature. I don’t know if the API has *ever* changed.
3. It supports PHP4. Yeah I know, not even PHP supports PHP4, but tell that to some of these hosting providers. Unfortunately, in the real world, we still have to deal with 4 from time to time. (I’m looking at you, Yahoo).
4. It doesn’t require PEAR. I’ve worked with a few hosts *cough*hostmysite*cough* :)  who insist that upgrading PEAR will break everything and the world will die, famine will spread, the dead will rise from the grave and they might have to stay 5 minutes late. Installing PEAR to a shared host is a pain and if I don’t have to do it — that’s a major selling point.
5. There’s another reason it wins that I will get in to shortly…

7. Release me from this tainted ORM

Ok, so even though ADOdb is the clear cut winner for me in the Abstraction Layer department, writing boilerplate-queries is still bothersome. I may have tried every single ORM for PHP that there is and there is only one that I can stand. So here, in no particular order are the crappy ones:

Zend_Db_Table

I don’t know who thought including this was better than making an ActiveRecord clone, but they need to experience Deep Hurting. I was using ZF since it’s pre-release days and I stopped using ZF before it’s actual release. They pulled the same, “Oh we said it was ok for production use, so we’ll change the API and give you absolutely no graceful deprecation.”

I’ve since looked at the Zend_Db_Table documents and man, it’s pure evil. The way to handle relationships is unbelievably verbose and it actually sickens me to think I wanted to contribute to this project.

CakePHP’s ORM

I have a fair amount of respect for CakePHP. The ORM *isn’t* the worst on this list, but what is up with using arrays for EVERYTHING? I can almost excuse using arrays for function parameters (things get messy very quickly), but for result sets? Objects in PHP exist for a reason, USE THEM!

Doctrine

In fairness, I’ve never gotten Doctrine to work. Why? Because the documents are written by The Riddler. I’ve installed Doctrine a few times and have never produced working models with it. I also don’t like defining the schema with YAML or whatever and using a command line tool to generate the code. You can generate models from an existing Schema, but defining the relations is manual and tedious.

Propel

There are things that bother me about the interface for retrieving data. ::retrieveByPK()? What’s wrong with retrieve(), select(), load()…do we really have to state ByPK? Why not go the full 10 yards and make it retrieveByPrimaryKey()?

The other thing — do*() methods? Really? I mean, great.

XML Schemas… come on.

On top of that, it requires Phing, which didn’t want to be installed when I was testing Propel. See ya.

ezPDO

I was almost ready to attempt to use ezPDO once, but then I remember how dumb of an idea it is to put code in the docstrings. Yeah, I didn’t make that up.  It used to bother me that PEAR standards stipulate that people put some kind of typing scheme in the docstrings for function parameters. *sigh* But ezPDO takes it to a sinister new level.

CodeIgniter

I haven’t used CodeIgniter’s ORM, but reading the documents has made me a little peeved that they call it an ActiveRecord implementation. ActiveRecord has methods attached to it, like save() etc. Without those, it’s just Record.

And the rest…

There are a bunch of other ones that I won’t bother downloading:

• dORM — Requires an XML schema and also uses getters and setters for data access.
• Rocks — Sucks :) No really though, their website kept dying while I was trying to read the documents. Max execution time exceeded. When I finally got to it, I had to register for most of it.
• Coughphp — More getters and setters. Java is like herpes. It just keeps spreading and you can’t get rid of it.

and on and on.

The clear cut winner, in my opinion, was right under my nose the whole time. That’s right, ADOdb_Active_Record. It has the simplest API — no schema definitions needed, no models needed to be created before hand, no getter-setter methods, no field name mangling, simple debugging…

It’s not without it’s problems though. No N:M relations, although 1:m and m:1 are breath-takingly simple. Development on it is a bit sluggish, but I’ve been using it successfully for a few projects now and I’ve had no problems.

As far as performance? I have no idea. It’s not PEAR::DB slow, so I don’t care.

8. In conclusion

I’m sticking with ADOdb for now, but I’ll always be on the look for something better. Maybe when PHP gets namespaces, SQLAlchemy can be ported?

1. Open a site with javascript that you’re presumably trying to debug or are otherwise involved in some time sensitive development.
2. Set a breakpoint in a script.
3. Get the breakpoint to be reached, thus halting execution of the script.
4. Find exactly what you’re looking for.
5. Fix it in the code file you’re working on
6. Refresh the page.
7. Notice that none of the Javascript seems to be working — if the page even displays
8. Remove the breakpoint and try again
9. Copy the URL because you know you’re going to have to restart the browser
10. Get a message about Firefox already running
11. Open up your process manager and see Firefox using up 100% cpu and an enormous amount of memory
12. End the process
13. Start Firefox again
14. Find out that your URL wasn’t copied
15. ARGGHH

Note that this can be avoided by resuming the javascript engine before step 6 — but I never remember to do that.