Red Yellow » Code

Mobile CakePHP Apps

Rich Gubby — Tue, 22 Sep 2009 19:22:23 +0000

It feels like an age ago that I wrote a component and helper for CakePHP that could mobilize an app. Since then, things in the WAPL and Wapple world have moved on at a rate of knots and it’s time to re-write, re-factor and re-engineer the mobile cake code to keep it up to date.

The first version had a pretty basic component, used SOAP to communicate and had no in-built schema check to always produce valid WAPL code.

PHP Package as a Vendor

But now there is a PHP package available that handles the schema check and communication can be done by either REST or SOAP (the preferred method would now seem to be REST seeing as it has better error handling and doesn’t trigger a fatal error if a soap client can’t be created).

Plugging that package in as a vendor should be dead easy (although it does need a few little mods and upgrades of its own first) and then it’ll be just a case of writing a component and helper to make use of it.

Hopefully I’ll have something ready this week so you’ll be able to mobilize your real world cake apps!

Let me know if you have any ideas for how it should be built – as a component & helper? Maybe a plugin? Or just keep it as a vendor.. or maybe all of the above!

WordPress on Load Balanced Servers

Rich Gubby — Thu, 03 Sep 2009 17:49:06 +0000

Picture the scene, you’ve had a great idea for a blog and have decided to use WordPress as your blogging software of choice. And as you’re going to be getting an insane amount of visitors (after all, you’ve got a great idea, right?) you’ve decided to buy some decent hardware to cope with the traffic.

The setup you’d probably go for is some sort of load balanced setup, with multiple web servers and possibly a couple of database servers behind the scenes. You should also be thinking about the wonders of virtualization and all the benefits that brings but that’s for another day.

Having multiple web servers brings about its own set of issues. Your blog code needs to be deployed to all web servers (preferably at the same time) so that if you get visitors that happen to hit different machines, you give them the same experience.

Deployments and Uploads

But that’s not so much of a problem – you could deploy code to all servers with Ant or Capistrano, or even write your own system to do it exactly to your requirements.

However, in this kind of setup, you’re going to come unstuck with plugins, themes and uploads. WordPress has an awesome upload utility, but the file you select from your local computer will get uploaded to a location on a single machine in your server farm. When a visitor lands on a different machine, they won’t see the upload. If you’re using the automatic add plugin or theme wizard built into the newer version of WordPress then it’s the same situation.

Link to NFS locations

But the situation is not nearly as dire as you may think though. There are loads of ways to combat it – and it’s a piece of cake if you’re using Linux! The easiest way is to create an NFS share on web server 1 and link to it on web server 2 so that the “/plugins” directory on 2 actually points to the location on 1. Easy!

If you’ve got a file server, even better – create your NFS on there and link to that location instead so that content really is separate from your code!

With windows it’s just as easy with shared directories – same principle, just a different terminology.

The only issue you’ve got left is that some plugins may have the paths to their files built slightly oddly so that they load the wrong files. But then, if you’ve got errors with the plugins, it may be time to look for alternatives!

Have you had any problems with WordPress on load balanced servers? How did you solve it or did you choose another setup?

When is a bug not a bug?

Rich Gubby — Tue, 25 Aug 2009 19:59:21 +0000

I used to work with someone who said that most bugs in software didn’t exist.

His reckoning was down to the fact that most specifications for functionality aren’t tight enough. For example, if the spec for an adding function was to add two numbers together, adding 5 and 9 together and returning a value of 162 was acceptable. Even returning nothing, or null, or a gazillion was also ok. The specification should have said that the function had to add two numbers and return the correct mathematical result.

For a developer, this is great news. You don’t have bugs anymore, you have “undocumented features”. Feature specifications get better and it’s easier to write code that satisfies the requirements.

It’s a bug!

But I personally think blaming bugs, and they are bugs, on the specification writers is lazy. Bug reporters, whether they are developers or not can get quickly hacked off with being told that an error they’ve found isn’t actually a bug, but it’s the fact that it’s actually been implemented exactly to spec.

A bit of common sense in all of this is definitely required. If you need an adding function, it’s obvious to anyone that it should return the result. If the spec doesn’t say so, just do it and move on.

And if you need a function to return the results of whether a visitor is a mobile device or not, it’s probably wise to actually return the value rather than store it in a cookie. Oops!

No related posts.