Legacy

PHP LIBS

Listen development teams working for companies that provide code LIBs to make implementation easier for your clients: DON’T USE AUTOLOAD. What if your client uses that shit too? Should we have to modify your poorly coded LIB broken up across 60 files? If you are going to use autoload, how about you use some sort of naming convention for your files? How about instead of using autoload to crawl entire directories (60 files!) looking for files that match a string you pass autoload, you just require the files the old way?

Also, let’s not leave white space after your closing ‘?>’ tags. They rape my sessions. How about instead you just don’t use ‘?>’ in your ‘all PHP’ scripts? It isn’t required you know.

I hate you guys. Seriously.

I love character encoding!

marco:

Tonight’s goal: Make a simple PHP class.

• Input: a URL pointing to an HTML document.
• Output: a UTF-8 version, regardless of what encoding it’s really in.

Sounds easy, right?

Nope. Because some pages specify encoding via HTTP header, some specify via meta tag, some specify both but they disagree, and some don’t specify at all. Sometimes, the encoding is specified with an unusual variant of its name (e.g. X-GBK, MS939). And often, the specified encoding is wrong.

But I think I got it, finally.

This is so useful, albeit to a relatively narrow range of programmers, that I feel bad not releasing it to the world, except that I assume that someone else has already done this and I just didn’t bother looking for it. (My experiences with PHP-community code are not good, so I almost always roll my own.) Any interest?

I’d like to check it out. I haven’t had to mess with converting character encoding in a long time. I believe I got aggrivated with PHP the last time and just did it with Ruby.