Lisa Homstad » PHP

Not A GoDaddy Girl

Lisa — Mon, 16 Aug 2010 03:58:29 +0000

GoDaddy.com seems to be pretty popular these days. Unfortunately, I can’t say I’m a fan. I find their assorted control panel interfaces chaotic and hard to navigate. I don’t like the spam they sent me all the time until I dug around 3-4 levels deep in navigation to find where to turn it off. And I really don’t like CEO Bob Parsons “How to be successful in business…plus a smoking HOT blonde!” video series.

In spite of all this, I explored the option of moving my friends’ sites to GoDaddy after some disappointing downtime with my current hosting company (Bluehost), because hey, if it’s better, go with it, right? Alas, their shared hosting environment was…icky.

My applications were using the $_SERVER['DOCUMENT_ROOT'] variable. Apparently if you set up a site as a subdomain, GoDaddy puts that variable’s value into a $_SERVER['SUBDOMAIN_DOCUMENT_ROOT'] variable (which I don’t think is particularly standard) and leaves the document root blank.
They also only gave me a public_html folder, whereas Bluehost gives me a level above that, allowing me to store my application code in a non-web folder making it slightly less exploitable.
They also only gave me two options for the database: accessible remotely with a user with full permissions or not, and no permissions to create my own users. Bluehost allows me to create my own users and restrict remote access by IP address, which is way more secure.

Anyway, I decided to give up, because that was just too much compromise for me…even if their pages do load 2-3 times faster. :( Sorry GoDaddy, I’m sticking with Bluehost…you’re not worth it.

Fun with CodeIgniter

Lisa — Fri, 12 Feb 2010 04:20:59 +0000

I’ve been working lately on setting up an admin with CodeIgniter, which I picked because a) it’s fast, b) it’s not huge and c) it’s popular enough to have good documentation and forums, etc. I was really pleased with how easy it was to just drop the files in place, change a few settings and it was working. Figuring out the “right” way to do things once it’s set up, however, is proving to be more challenging…but only because it’s unfamiliar. Once I learn the “right” way, I’m like “oh, yeah that makes sense.” I haven’t had to really learn a new framework since I spent a month figuring out the intricacies of Fusebox 4.0 (and learning MVC at the same time), but I guess once you’ve built stuff as MVC it’s all pretty much just syntax differences and learning where stuff is and what’s available. :)

I really like how CodeIgniter makes session management easy…you don’t have to worry about all the session_start()s and such, and setting up a basic authentication system took about 15 minutes with some help from a tutorial. Although I’d like to modify it to make it so the session expires if the browser window is closed… /makes note on TODO list. :D

Also, database stuff seems pretty easy too, and I like how simple it is to run a query with parameters…you basically just write your SQL with some ?’s, and pass that string with an array of values to the db object. No funkiness with escaping quotes, stripping stuff out for SQL injection, binding or anything…very clean and simple.

I like clean and simple. :)

The Magic of similar_text()

Lisa — Wed, 03 Feb 2010 21:13:06 +0000

So I had this dilemma the other day when I had a report that was displaying “event type”, “event name” and “event location.” Due to some wonky old data, the event name would frequently be the same as event type or event location (e.g. “Dentist Appt” as type, “Dentist Appointment” as name, and “Dentist’s Office” as location). It made sense to not show the event name if it only contained redundant information.

Unfortunately, as in the example above, “Dentist Appt” and “Dentist Appointment” are not exactly the same value, even though they have the same human meaning.

Luckily I discovered a handy little php function called similar_text(), which will compare two strings and either return the number of shared characters, or what percentage of the string is the same. So instead of saying “if event name is equal to event type, don’t show event name,” I now have something like “if event name is 85% similar to event type, don’t show it.” This seems to work pretty well, so yay! :)