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!)

• 0 Comments

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();
	}

}

• 0 Comments

…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.

• 0 Comments

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…

• 0 Comments

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!

• 0 Comments