I'm not sure what I was expecting, but what I got was pretty amazing. Slicehost works by offering virtual servers for each account - that is, for each account they offer, you get your own box.

They don't give you a whole lot to start with. The box is a clean, basic installation of your chosen operating system (they offer Ubuntu Hardy or Intrepid, Gentoo, Fedora, Debian, CentOS, and Arch). You're responsible for putting anything on it you want.

And that's where the fun starts: you really can put anything you want on it.

Need a database server? No problem. Want a web server? Go for it. You can build a full LAMP stack or create a load-balanced full server setup yourself, from scrach, with whatever settings you want. You can create a VPN server, a file server, an Subversion server...if it runs on Linux you can run it on Slicehost. Period.

And it all starts at $20 a month.

I've got four slices under management for a number of clients, as well as for BrandonSavage.net and I've got to say I've never been happier. Upgrades happen when I want, I have full root access, and I get to decide how to build my server.

Sure, it's not for everyone. You've got to enjoy managing a server, and be willing to shell out some money for some of the higher-end options (a 512 MB server runs you $38/mo and a 1GB server is $70/mo). But, given the other options out there, Slicehost has served me well, and it will serve you well too.

Tell 'em I sent you.

Note: I am not an employee nor do I get a kickback from Slicehost of any kind for my review. Though they offer an affiliate program, it only applies if you provide a contact's email address.

1. Try caching. If you have something that doesn't change a whole lot, or data that can be stale for a period of time, consider caching it. This can be as simple as writing a function that writes it to a file. For example:

This function would check for a file's last modification date, and if the data is stale, it would replace it with new data. Since a file read is almost always faster than a database hit, this is a great solution.

2. Reduce the number of queries that run. For every query that you run, your database takes a hit. By reducing those queries, you improve the speed.

3. Use indexes. Learn how to use the EXPLAIN command, and then implement indexes to optimize your database. Do NOT index everything; index only where it is appropriate.

4. Optimize data usage. Ensure that data is kept once; make sure that you have frequently used data separate from infrequently used data or large data (read TEXT, LONGTEXT, BLOB). For example, you might consider keeping a blog's metadata separate from the entries and linking them through a foreign key; you could also consider having the entry text as a text file that is read from disk (up to you).

5. Avoid functions in WHERE statements. For example, this will cause problems:

SELECT * FROM MEMBER WHERE TO_DAYS(expiration) 
- TO_DAYS(CURDATE()) < 30

The optimizer cannot use an index on the 'expiration' column because it has to apply the function TO_DAYS() first; this negates the positives on the index.

A better SQL query would be this:

SELECT * FROM MEMBER WHERE expiration < 
DATE_ADD(CURDATE(), INTERVAL 30 DAY)

In this case, the optimizer can use the 'expiration' column index to help find our data faster. (Credit to Paul Dubois for these queries)

These are easy but important tips. The more they're written down, the more people will use them. Use them, and your life will be easier.

Ning has allowed our client, The Pickens Plan, to create their network called Push on Ning, at a reasonable cost (for the premium services), with some awesome features built in. Now that Ning is moving towards the OpenSocial model, developers will be able to create some great applications that can be distributed to the more than 500,000 social networks on Ning. And, since Ning is designed to let you create your own social network (rather than a group or a page like Facebook and Myspace), you can add a whole level of functionality and draw for a client's visitors without having to even write a single line of code.

So check Ning out. I think you'll be surprised and happy that you did.

Lucky for us, XDebug has a built-in tool that helps us evaluate code and figure out some of what is going on without spending all week reading the documentation or the code itself. It's called "function profiling."

Continue Reading...

Both Matthew Turland and Ben Ramsey wrote that they were less than excited about their personal ratings. Having heard both of them speak, I think the ratings are, shall we say, overrated.

It's certain that some individuals will get higher ratings, especially those who have a natural knack for speaking, or those who teach every day. There's nothing wrong with that. But the point of a conference is for those who speak to improve the body of knowledge for everyone else.

For those who got less than fantastic results, you still rock. And for those who got great results, we knew you rocked already. Thanks to everyone who spoke, enlightened, and contributed to ZendCon. It's what made it great.

XDebug allows you to do a number of things: first, it provides styling to your stack traces and stack traces every error. Second, it allows for profiling. Third, it provides some variable output tools that are just necessary when working with PHP.

XDebug is an extension for PHP, and before you do anything you should probably download and install it from the XDebug website. Don't worry...I'll wait...

Continue Reading...

Today we will discuss tools that ought to be in your bug-fixing toolkit already. There are three tools that everyone should already have:

• var_dump();
• print_r();
• var_export();

Continue Reading...

We had great presentations by some of the best names in PHP, including Ben Ramsey, Brian DeShong, Matthew Turland, and lots of others. The evening ended with a RambleCast recording, and a viewing of The Goonies, a low-key end to a great weekend.

Elizabeth Naramore deserves the majority of the credit for a great event, since she spent most of the time and effort putting it on. Keith Casey receives honorable mention for his participation and planning as well.

For new friends and old companions, I'll miss you until next time. Four days wasn't nearly enough, but sadly real life must continue on. Thanks to everyone who came out, participated, and made it a great time. I'll never forget Cal Evans jumping in front of an angry Chris Shiflett (not really...just stepped on broken glass), or Elizabeth Naramore scaring the haunted house guy by screaming "TERRY CHAY! TERRY CHAY!" over and over again. Those memories can't be bought for any price.

Thanks PHP Appalachia. Until next time...

Saturday was mostly a traveling day for the majority of people, but everyone was pretty much together by 9 pm on Saturday. Traffic through Pigeon Forge is terrible; it took almost an hour to go the eight or nine miles off the highway to the cabin.

With the group assembled, the festivities began with a cross-regional meeting of the PHP Beverage Subgroup, organized by Keith Casey. The event was live-streamed until the evening moved down to the hot tub, where most people congregated and the party continued.

Unfortunately, we did have one injury: Cal Evans received a gash on his foot from broken glass that required thirteen stitches from the local hospital.

Sunday morning we had a great talk from Chris Shiflett on how to be a morning person...ok, that was a joke. But we did have a fantastic presentation by Ben Ramsey on RESTful web applications, followed by a great talk by Brian DeShong on presenting for the mobile web.

The evening ended with PHP Trivia, with the Haystack team winning by four points over my own team, the Pretty Hot Programmers. This was immediately followed by more hot tub, poker, and some of the best gumbo around.

We still have one full day remaining, and on Tuesday we head back to our homes with our memories. The internet connection is spotty here so I will try to update as soon as possible; full wrap up from Washington on Tuesday or Wednesday night.

That's bad. Really bad. It's frustrating. Particularly to a developer who comes after you, and wants to deal with the output themselves, for any number of reasons.

Please, when you write functions, return something, anything, kind of like this:

Why is this useful? By returning the string instead of outputting it, you give another developer who might interface with your function the ability to muck with the string themselves. Having played with Wordpress all day, I can say from experience that having the output thrust upon me by default is a bad way of doing things. Bad, bad developers.

So please, return things. It provides the most flexibility for everybody, and makes it easier to use the code.

That's not to say that the package is perfect: far from it, in fact. The documentation is the most disappointing facet, something I may help resolve through contributing to the manual. Also, most programs don't yet recognize the SVN functions as part of PHP, so syntax highlighting is not available. This is a small inconvenience, however, and certainly no reason to NOT use it.

The package documentation can be found here and it's worth a look for anyone thinking about doing anything SVN-related with PHP. This beats using exec() to execute SVN commands, as it ensures that the commands are executed properly.

I see the most immediate use of this tool in building a Trac-like PHP application. I'm sure someone has thought of it, but with Trac being popular, supported, and already finished, no one has yet dealt with this issue. Still, I'd like to see someone build that at some point.

But one thing that became very important was the benchmark test. Using ApacheBench, we identified the blind spots, weak spots, and bottlenecks in our web server (Wordpress...duh) and worked to address them.

Running ApacheBench is so absolutely easy. Everyone should do it. The command is simple:

ab -n 1000 http://www.example.com/

That's it. This calls ApacheBench to do 1,000 hits to your website. It produces a report, showing you important stats like the number of hits per second processed by the web server. It's also fun to do things like disable APC and re-enable it, and see the difference - here on BrandonSavage.net there is a 480% improvement with APC turned on.

And the best part about ApacheBench is that it comes standard with Apache. No need to install a separate package. It's fun, fast, easy, and important. If there are bottlenecks in your website, you need to know it...before the load takes it down.

Continue Reading...

If that were an isolated incident, I'd say this was just an example of Comcast doing something innovative and new. But it's not an isolated incident. Recently, I had a bad experience on Southwest Airlines, and I did what any Twitter-loving technophile would do: I contacted @SouthwestAir.

@SouthwestAir is by no means intended for customer service inquiries. As Christine (the woman who is @SouthwestAir) put it, "this is not usually how we handle complaints." She's actually in communications, not customer relations. But she felt bad about my story and wanted to see if she could help.

Regardless of her role, she was able to arrange a refund of my money, which was really what I wanted. And @SouthwestAir was able to solve the problem - a problem that phone calls to "traditional" outlets had not solved.

I'd be interested to see if other companies put specialists on Twitter with the goal of helping customers resolve their issues, much like Comcast has done. It's a great medium - it's personal, it's individual, and it's terribly effective. But it doesn't scale well, as @ComcastCares will likely tell you (he's worked with me at midnight on occasion, which can't be good for his marriage).

But for now, Twitter, you have saved me. And for that, you have my gratitude.

Zend did a fantastic job, and it showed in the organization and execution of the event. ZendCon was one of the best organized conferences I've been to in a while. As a presenter I was given (most of) the things I needed, the food was higher quality than I had anticipated, and I really enjoyed the speakers. Some of the best included Chris Shiflett, Eli White, Elizabeth M. Smith and many others.

There were a number of great receptions, including the ZCE reception, the welcome reception and the vendors reception. The only exception was the Yahoo! party, which did not live up to expectations. However, a lot of people seemed to enjoy it, which was great.

I'll certainly be back at ZendCon. My hope is to make it an annual event; either way, it's a great time to spend with friends and the PHP community.