So that’s the update. Articles and blog posts have been merged since they’re pretty much exactly the same as far as storage goes…but now they are categorized. Yay.

So, welcome to the new killtheradio.

Some planned features include integration with social networks (a must these days) AND a super SECRET feature that has yet to be announced but will spring us to #1 in a matter of hours. It has yet to be unleashed though.

Anyway, check it out. Jeff and I put a ton of work into getting this ready for John Q Public, and you must swear on the eyes of your children that you will sign up for an account and post events and tell everyone you know RIGHT NOW. Thx lol.

Now granted I didn’t run into any memory leaks, but I’m not going to bet for something that is consistently failing all around me. Then I heard of Nginx. Keep in mind this all happened at least a month ago…I just haven’t had time to blog at all. Anyway, it’s supposedly faster than lighty, it’s actually stable and doesn’t need rebooting every night, and it’s russian.

So being the tinkerer at hear that I am, I decided to install it on the beeets.com server. Well, the syntax in in the config file was a bit of a learning curve. It’s sort of like C but not as friendly. A space in the wrong place will make it fail. Needless to say, I got it all configured though. FastCGI, PHP, URL rewriting, client-side caching, and if I need it later on, a kickass reverse proxy.

So I guess this is me saying a few months later than nginx totally kicks ass. It benchmarks so much better than Apache, and it’s russian.

I think the next think I’ll be tinkering with (fucking up) will be MySQL replication. From what I read, it’s better than clustering for a few reasons. You can do things with replication you can’t do with a cluster. The problem is there will definitely be some gnarly code tweaks because nothing supports it by default, at least not that I know of. Oh yeah, plus there’s like, no documentation on writing a PHP app for a replicated database. I know, read from the slave, write to the master, but if you write to the master and immediately need to read a generated value (last id) then you have to read from the master since you can’t rely on the slaves to be kept instantly up to date. That’s a fun code change.

/css/css.php/file.css …which rewrites

url(/images/…) to

url(http://images.beeets.com/images/…)

And guess what, it all works. I had some bad experiences with the S3Fox firefox plugin in the past, but it’s since been updated and I’ve been using it regularly.

Also, using S3.php, all profile images now go directly onto images.beeets.com. Wicked.

So what does this mean? A few things:

1. Less bandwidth & work – beeets will spend more time serving HTML, CSS, and JS than images.

2. Safer – We were backing up profile images to S3 indirectly before, but the chances of S3 going down VS our hosting are slim.

3. Worse image caching – Before, I had .htaccess controlling all the caching for static files. I liked it that way. S3 doesn’t do this very well at all. Apparently it’s configurable, but I don’t know how…any ideas?

All in all, it should be better for beeets. Maybe we’ll actually let users have images bigger than 10×10 now ;)

Thumbs up to S3 (and probably all other Amazon web services).

Seems like once we went official, all this great stuff started happening. We’re going to be doing some big projects. Jeffrey is going to be in school full time and can’t devote much time, so that leaves me. I’ll be doing lots of work and making lots of money. Sounds good to me.

In all the glory, we forgot about our baby, beeets, which is still closed beta and waiting for love. We’re planning on opening the doors and doing a marketing boom hopefully sometime this week. Exciting stuff.