I just wanted to document this somewhere but whenever I work on a CakePHP project, there’s always the debug info that sits at the bottom of the page. It’s big and bulky and once I’m off the default CakePHP styles, it’s usually pretty ugly.

I’ve done various stylings but I finally took a moment to implement a really simple idea: Fixed position the table and then use hover styles to toggle the visibility. It’s still not a perfect solution but darn close and certainly good enough for my needs right now.

.cake-sql-log {
	position:fixed;
	top:99%;
	z-index:10;
	width:100%;
	background-color:#000;
	color:#FFF;
	border-collapse:collapse;
}

.cake-sql-log caption {
	background-color:#900;
	color:#FFF;
}

.cake-sql-log:hover {
	top:auto;
	bottom:0;
}

.cake-sql-log td {
	padding:3px;
	border:1px solid #999;
	background-color:#EEE;
	color:#000;
}

You’ll see a red sliver at the bottom of your page and as you move your mouse over it, voila, there’s your debug info. It’d be nice to actually have a Firebug plugin that could have CakePHP debug info pushed to it automatically. (Maybe one day I’ll work on that!)

So it seems that the old code I had didn’t work in debug mode, although on the current CakePHP 1.2 RC2, I’m not even sure it works at all. However, I decided to take some time to revisit the code. Last time, I simply hacked up the missingAction and missingController calls and it felt kludgy. It looked kludgy.

This time I took a closer look at how the dispatch was being handled. Daniel Hofstetter made mentioned how using the error handler seemed inappropriate since it’s for handling errors. Unfortunately, the Dispatcher looks for a missing action or controller and if it can’t find them, it sends it off to the AppError class well before anything else. As a result, it seems that overriding the AppError is really the approach that I want to take. I think you’ll see, though, that the new code is more straightforward.

It uses the constructor to capture what kind of error is being called. If it’s a missingAction or missingController then I look for the missing file. If the file doesn’t exist, the flow continues on to the parent error class and the missingAction and missingController calls happen as they normally would. The old code actually handled both scenarios creating bulky code.

If the page exists then the AppController is instantiated and the view is rendered. The only problem currently is that CakePHP doesn’t seem to load the custom AppController, if it exists. I’ve filed a ticket but I’m not entirely sure if this is by design, so this may not ultimately get resolved.

Without further ado, here’s my AppError:

class AppError extends ErrorHandler {

	function __construct($method, $messages) {

		$params = Router::getParams();

		if (($method == 'missingController' || $method == 'missingAction')
           && file_exists(VIEWS . DS . $params['controller'] . DS . $params['action'] . “.ctp”)) {
			$this->controller =& new AppController();
			$this->controller->_set(Router::getPaths());
			$this->controller->params = $params;
			$this->controller->constructClasses();
			$this->controller->viewPath = $params['controller'];
			$this->controller->render($params['action']);
			e($this->controller->output);
			exit;
		}

		parent::__construct($method, $messages);
		exit();
	}

}

…or why I think Mashable is wrong.

Mashable has an interesting article that places Twitter’s popularity purely on its simplicity. Even more bold, it believes that people haven’t left Twitter because of its simplicity. Its competitors are simply too complex.

I contend that Twitter has succeeded and continues to succeed because no other service matches its breadth of distribution.

Avenues of Distribution

Twitter has been smart by allowing multiple ways to interact with the service:

• There’s the web site, of course.
• There’s the mobile site.
• There’s instant messenger.
• There’s the well-documented API.
• And there’s SMS.

All of this combined has made Twitter a very compelling platform for barnacle application development. Having so many services that depend on it creates a great deal of resistence to move to other platforms.

Scaling

This breadth of distribution is also one of the major things that people miss when they talk about making the Twitter-killer or think they know how to scale Twitter. Ultimately, people miss or forget or ignore one of the avenues of distribution.

It’s a combination of push and pull technologies that have to work reliably together. The web site, the mobile site and the API are pull technologies that require requests from the end user. SMS and Instant Messenger are push technologies. Each technology you throw in the stack can cause issues in various ways if it goes down.

For example, one of the headaches that Twitter has to deal with every time their IM service goes down is bringing it back up. Suddenly, you receive a flood of status notices that a few thousand users are online. It’s enough to take the service back down just as soon as it comes online.

Consider SMS and the cost of having short codes for various countries. The cost alone enough of a barrier for competition to enter the market.

Competition

Inevitably, many services are trotted out as possible Twitter-killers. Here’s the more popular ones:

Pownce

Pownce is often referred to as a possible alternative to Twitter. It’s simple, well-designed, and has an API. But there’s no IM or SMS, nor do I think it’s practical for it to go that direction. It wasn’t designed to do that. The tagline is "send stuff to your friends" and the service does that. It serves a niche that is separate and complimentary to Twitter and not necessarily a competitor. Pownce may wish to look into providing Twitter support as an additional facet of their service creating more of a "one-stop shop" approach.

Plurk

Plurk is a relative newcomer to the marketplace and takes a very unique approach to how it displays information. With the lack of an official API (an unofficial but poorly documented API is available), no SMS, and an IM service that’s currently down, it’s a long ways away from taking down the likes of Twitter.

Jaiku

Finally, I wanted to mention Jaiku. It comes the closest to being the Twitter killer. Web site, check. Mobile site, check. SMS, check. IM, check. What about an API? Half check. They do offer up an API but it is limited and for the most part, read-only.

When you consider estimates that 10 times the Twitter traffic occurs over the API as it does on the web site, and you can see that the secret to building a competitor is building a compelling environment in which to do so.

Unfortunately, when Jaiku sold the service to Google, they shut off new signups. It has been 9 months since and they still haven’t opened things up. Behind the scenes, they’ve been porting things over to Google App Engine and no doubt continuing to work on the service.

However, if Twitter gets its service stabilized before Jaiku’s re-emergence, I hold out little hope for Jaiku to steal any major market share. I also find the Jaiku interface more complex than it needs to be.

The future of Twitter

My own interest in Twitter has been waning due to the unreliability of the service and API. I can only surmise that they are currently in the process of rearchitecting the entire application. Otherwise, they may be doomed to eternal failure.

This is my response to James Bennett’s post on the Designer vs Developer debate but I thought it worth sharing my view point here.

So it’s high time we all got over our little internecine feuds and started acting like the professionals we claim to be. That means learning to work with with our colleagues, no matter where they fall on the spectrum of specialized industry knowledge.

Honestly, it’s much ado about nothing. You’ve managed to find some quotes from people who may or may not have any relation to the web design industry and certainly have no impact on what you do and how you do it and who you do it with.

I’ve spent 10 years in the web design industry with teems of teams of designers and developers working together on projects and rarely have I heard this kind of harassment.

You can try and play referee but the hecklers in the stands aren’t the ones you should be trying to settle. The players in the game aren’t complaining.

So, rah rah, "can’t we all get along", "let’s buy the world a coke" and move on…

I know it’s been a couple weeks since @media but I did want to document my thoughts and, of course, point people to some resources.

First of all, I thoroughly enjoyed the conference. It’s certainly on a much smaller scale, probably closer to something like Web Directions North. What I’m finding is that the two track smaller conference seems to be a great size. It gives you plenty of content to absorb while still offering up plenty of opportunities to have meaningful conversations with people.

I enjoyed chatting again with PPK, Drew and Rachel, meeting Stuart Langridge for the first time, and seeing Sidebar colleague, Dan Rubin, again. (And I hate listing names because there were plenty more great people that I got the chance to talk to.)

It was also enjoyable to spend a little site-seeing time in London. It was my first time off the North American continent and I enjoyed the history and all the popular sights. My wife made the trip with me and she got the pleasure (or so she says) for the first time of getting to see me present.

Building on the Shoulders of Giants

My session was a general talk on the use of APIs, frameworks and mashups and how we, as developers, can take advantage of many of the tools already available to us. The feedback I’ve received on the presentation has been extremely positive which is just fantastic. It’s often difficult to know how technical or how high-level to frame a session. I went for something a little higher-level and it seems to have gone over well.

I’ve posted my slides which also includes links to the resources I mentioned in the slides and in the presentation.

I hope to have the pleasure to do it again next year!

If there’s ever a quintessential application to build when you first dive into a framework, it’s the blog. That’s what I did with Snook.ca when I first got into CakePHP.

Then for a recent client project, also built using CakePHP, I was asked to integrate a blog. I took this opportunity to take a chunk of the code I used to build my own site and break it out into its own blog plugin: Snogs.

Snogs is Snook’s Blogs and is a simple multi-blog engine for CakePHP. It’s hosted over at CakeForge where you can download the application, access the Subversion repository or supply feedback.

I’m releasing this as open source. If you’re interested in joining the project and enhancing Snogs then by all means let me know. Also of note, I’ve included the spam component I talked about previously.

While my own site doesn’t run off of it, it will. I’m intending to rebuild much of Snook.ca using Snogs to see how well everything integrates and it will no doubt inspire me to add some features I find useful.

(And let me know if you’re getting tired of all these Sn- prefixed projects. I think it’s fun but there’s always too much of a good thing.)

It’s been over a year since I’ve last talked about adding advertising to my site. It has come time to provide an update and fill you in on how things are changing.

Automation

Once again, my biggest downfall was the lack of automation. Campaigns would end and I’d fail to do a followup. In one particularly awkward case, I double booked a spot because I had forgotten that an advertiser had prepaid. It was unprofessional and not something that I’d like to repeat.

Statistics

I continued on without any statistics beyond what I track on my own site. That meant advertisers had no way to actually track their campaigns, to see how many impressions they got, or how many sales conversions it offered up. I know in a couple cases where the client did no referral tracking on their end either, so the campaign was mostly a shot in the dark. I can only assume that it paid off enough for those that chose to renew.

Stability

Over the past year, things have been pretty stable, with various advertisers coming and going and some staying for the long haul. It’s become somewhat of a routine now, checking for campaigns about to end, and getting any new advertisers set up.

The number of ad spots continued to shrink including dropping TextLinkAds from all inside pages. It was nice to be able to reduce the advertising footprint on the site while still able to maintain the level of revenue coming in. The footprint got reduced even more this week by going from the two ad spots in the sidebar to the single, new SidebarAds spot. Which leads me to…

Launching SidebarAds

However, after a year and a half of running my own ads, I’m switching things up. Last year I hinted at the idea of creating an ad network. After some discussion with the guys in Sidebar Creative, we decided to build and launch SidebarAds.

The network is currently a small collection of sites, including the four of us in Sidebar Creative, along with Roger Johansson at 456 Berea St and Paul Stamatiou. Despite the limited size of the network, we’re serving up approximately 20,000 page views a day, which is just fantastic.

Adding Member Sites

We soft-launched the site about a week ago to give member sites time to get the ad script in place and time for advertisers to get their campaigns started. However, we’ve already had a few people enquire about being added as member sites. It’s flattering that other people think this is a good idea and want to join in.

We have no intention right now to open it up to the masses but we do intend to bring on more sites one at a time as we balance the number of advertisers against the number of member sites we have to pay out to. The largest hurdle is always finding advertisers.

Learning from past mistakes

Of course, with SidebarAds, I wanted to learn from past mistakes. The biggest thing was automating the process. There’s a sign up application that allows advertisers to configure their ads, upload their image, add their ad copy, all without intervention. All I have to do is confirm payment and approve the ad.

I kept the simplicity of my current setup by using a flat fee per month regardless of clickthroughs and simplified it even more by setting campaigns to always start at the first of every month. That compared to my site where they could start on any day and simply end a month later.

I also made sure to add stats tracking. Advertisers can now view their impressions and clickthroughs per month (and per day, soon enough). And being a bit of a stats junkie that I am, it’s fun to see how all the campaigns are doing.

How it’s put together

This was a fun site to put together. Dan Rubin did the design, Bryan Veloso put together the HTML/CSS, and Steve Smith assisted with testing.

The backend is built with CakePHP and is mostly to power the advertiser’s administration section. The JavaScript embed does a quick and dirty document.write but I want to offer an alternate version that uses DOM methods that’s less likely to impact member sites if the SidebarAds site goes down.

Speaking of going down, after just a few short hours on Dreamhost, the SidebarAds site went down. I immediately decided to pay for a dedicated box at Hostway (whom I’ve used with a couple other clients and have been pleased with the reliability). After a bumpy start getting the server configured (due to some poor setup from the Hostway folks), things have been smooth sailing. The site hasn’t gone down since and I’m getting sub-half-second response times. I’ve added a ping service to the server to maintain uptime (so far, 100% with sub 500ms response time). As you can see, performance and reliabilty is important.

Finally

Finally, many thanks to MailChimp and JumpChart for hopping on board right from the ground floor. I’m excited to see where this goes and as always, I’ll be sure to report on its progress.

Sometimes inspiration strikes when you don’t even expect it. While at the @media conference, I was discussing the benefits of Adobe AIR and when it might be advantageous to use it. Certainly not every site or web application requires a desktop component. Sites that have a level of stickiness — sites that you never close the window for…like Muxtape.

*bing* goes the light bulb.

Why not make an AIR application for Muxtape? So here it is. This is a really basic prototype that simply allows you to type in a name of a muxtape and it’ll load it in an iframe. The name of a muxtape is the part before the muxtape.com domain. For example, with http://notasausage.muxtape.com/, you’d just type notasausage and then click load.

Don’t click on the links in the header as they’ll load in the main window. (This is a really rough prototype!)

Feel free to take the idea and build something truly cool — like grab the RSS feed and build a custom player.

And why Snape? It’s Snook’s Muxtape, of course!

Download Snape Basic AIR file.