About a year after the launch of the first app started the work on the second one. This one was tested with the users from day 0. In fact, it was created because users told us that they want it. It was so focused on the main feature, that it even had no signup form. It was quickly packed and delivered to the users with only it's core functionality.

Of both apps today, the first one is on hold, the second is growing everyday; exponentially!

I'm not advocating against test driven development, incremental development (it's what we are doing for both apps) but I'm advocating to the use of this methods when they are really needed.

When developing applications I try to guide by these rules:

• if a feature it's not controlling life support of a person (or it's money) do only a basic set of tests (smoke testing and click testing give you the best results)
• don't write behavioral tests.  The behavior of your application is very likely to change in the initial iteration, so don't write a bunch of useless tests and is the behavior. You will end up refactoring tests instead of code
• DON'T write logins (use openid, facebook connect, oka) you name it and skip the fuss of managing login information
• when the concept is ready throw the app into the web
• make the developers use the application. Since I use the application I'm working on, i feel my karma glowing; and that's a good thing; also I have a clue about what the f*(#$ this application do beside AJAX requests and SQL queries

And a good illustration of all these things by Geek and Poke

The idea behind the event, was to create free software for community (be it local or worldwide) and put together some geeks to have fun coding; and we did. Regarding the app, we plan to release the functional version in the next few days and see it growing and helping people share their stuff.

Overall, was a cool weekend, with a lot of geeky jokes, pizza, kfc, cola and all those stuff that make developers happy.

It looks like WP SpamFree is blocking some legitimate trackbacks and pingbacks. Reaching this conclusion wasn't easy until I found that you can enable XML-RPC logging by setting $xmlrpc_logging true in xmlrpc.php.

Right now I'm trying to track SpamFree problems. Keep you posted.

Later edit: looks like I was wrong about spam free. The pingback broblem was related to the fact that wp-cron.php wasn't called.

I have a background developing web applications using PHP. There are other 3 big languages/frameworks widely used right now and those are Ruby (on Rails), Python and Java. Although I've looked over them I would stick with PHP, but that's more a matter of taste than for other reason.

On the other hand I would change the traditional MySQL database with a new kid in the spotligths, redis. It offers a great performance for both read and write, scales well, has cluster management on the way and you can make it work for almost any relational structure that goes through your head; you just have to be creative. Large data that nowdyas stays in the database, I'll do it in the filesystem.

Regarding the web server I would definitely go for nginx. Fast, light, can do very neat tricks and can handle a big bunch of concurrent connections.

Maybe it's time to switch from LAMP

It's more than a year since all the servers I work with were switched from apache to nginx. One of the common problem I came across after setting up nginx was figuring out how to do the rewrites. Translating a rewrite rule from apache to nginx is not that hard. The single difference between apache and nginx regarding the regular expression is that apache doesn't take into account the leading slash of the path, so nginx will match ^/the/nice/url for http://example.com/the/nice/url while apache won't.

Next are some common rewrites I came across while working with nginx.

1. Redirect www domain to non-www

if ($host ~* "www.calindon.net") {
	rewrite ^/(.*) $scheme://calindon.net/$1 permanent;
}

This redirects with 301 Moved Permanently

2. Redirect to a front controller (eg. WordPress)

if (!-e $request_filename) {
	rewrite ^ /index.php last;
}

This will redirect any url that doesn't have a corresponding file to /index.php internally, not affecting the url.

3. Multiple conditions rewrite

One of the problem is that nginx conditional clause (if) doesn't support multiple boolean expressions and neither nested ifs. One can overcome this by using a series of conditions and some boolean rules.

So for example for adding a tailing slash to path of the url you'll have something like:

set $fix_trailing_slash 'yes';
if ($host !~ "^calindon.net$") {
	set $fix_trailing_slash 'no';
}
if (-e $request_filename) {
	set $fix_trailing_slash 'no';
}
if ($fix_trailing_slash ~* '^yes$') {
	rewrite ^/((.*)[^/])$ $scheme://$host/$1/ permanent;
}

4. Mirroring resources, eg. RSS to FeedBurner

set $feed_redirect '';
if ($uri ~ "^/feed/$") {
	set $feed_redirect 'http://feeds.feedburner.com/calind';
}
if ($http_user_agent ~* "FeedBurner") {
		set $feed_redirect '';
}
if ($feed_redirect ~* "^(.+)$") {
		rewrite ^ $feed_redirect? permanent;
}

This will redirect http://calindon.net/feed/ to FeedBurner, but will allow FeedBurner to get the content out of the url and mirror it.

More about this topic can be found on nginx's rewrite documentation page.

I've worked with WordPress, CakePHP, Drupal, Magento and I found that if you want a very quick way from .psd / .png to a working website, with editable content than WordPress gives the best results.

2. Taxonomies included

Lately WordPress gave developers the ability to use custom taxonomies. This way you can group posts in a very creative combinations; for example I used them to group episodes of a webcomic into seasons.

A good article on custom taxonomies can be found at http://justintadlock.com/archives/2009/06/04/using-custom-taxonomies-to-create-a-movie-database.

3. Already optimized

Given the fact that there is a very large community around WordPress, the tables are already optimized. If I can use wp for a website / application usually I cannot come with a better solution for table optimizations in a custom framework.

To take advantage of further optimization, I try to follow a simple rule when developing for WordPress not a single extra table. Lately WordPress included the ability to have custom metadata associated with posts (and pages, attachments, etc.), users and comments. Theoretically this would be sufficient for every site which can be powered by WordPress. If it needs an extra table, then WordPress is not the answer.

4. Actions and filters

This is the part I like the most about WordPress. Almost every imaginable interaction can be altered trough actions and almost any imaginable output can be passed to filters.

This gives you the power to not touch the core, power I abuse on a regular basis. If I have to touch the core, than it's almost certain that I found a bug .

5. Widgets everywhere

With the introduction of the Widgets API in WordPress 2.8 good widgets can be easily written. Also i try to make sidebars, header and footer widget ready areas, because widgets give just enough customization for the end user. If the customer needs to be able to manage website beyond using and customizing widgets, than WordPress is not the answer.

If I didn't convinced you, the try WordPress.