Developing With Style

So Codaset is being written in Ruby on Rails and not CakePHP. A bold decision I think, but a decision backed up by years of sitting on the fence when it came to Ruby and Rails, but also a little controversial, since I have been working with PHP and Cake for a long time now. So I wanted to lay out my reasons for going with Rails for the development of Codaset.

CakePHP is and probably always will be, the best PHP framework out there. I like to think that it has its head screwed on. Of course, that is all about the heads of the core team leading it, but as long as they stay focused on what Cake is there for, then it should stay like that. I continue to use Cake extensively with my day job at ShermansTravel, and will do so for while to come. But, ever since I discovered Ruby on Rails a few years ago, I’ve been constantly teased by it’s power - due largely in part by the Ruby language it is written in. A power that PHP simply does not have, and probably never will. Cake is severely limited by PHP, and makes the most of a language that is probably a little inadaquet at times. Unfortunately PHP has bad design decisions written all over it.

In fact, there is not a day goes by, that PHP does not frustrate me with its design. A task completed in PHP, is - most of the time - completed so much more elegantly if done in Ruby. Ruby is just so damn expressive, and actually, very, very natural. PHP is not! I mean, why the hell should I have to write curly braces around every single expression, or wrap things in parenthesis? In Ruby, parentheses are optional in method calls, except to clarify which parameters go to which method calls.

This is PHP:

And this is Ruby:

Now isn’t that so much nicer?

Yes, I know that’s all about aesthetics, but I like my code to look good. It makes looking at it and working with it, much more pleasant. But also this is just one of the hundreds of reasons why I chose Ruby and Rails. I suppose you could name this post “Why I chose Rails instead of Cake: Reason #1“.

The bottom line, is that I have played around with Rails for years now, but never took the plunge and wrote an entire - completed - application with it. I started a few times, but then went back to using Cake. But this was because I didn’t know Ruby well enough, and because of that, it was taking a long time to do something that I could have done much quicker in PHP. But because of all that tinkering, I can confidently say that I now know the basics of Ruby and can quite easily write a Ruby script, or a full Rails app.

So writing Codaset in Rails was the right decision. Every time I open it up in Textmate, I’m excited by what I see. Everytime I see another Rails plugin or Ruby gem, I want to install it. The thought of developing the next feature of Codaset exites me in ways that PHP almost never has. And because of all that, I’m learning a new programming language at an incredible rate. Once you get past the learning curve, you really start zooming through any app.

I’m even considering open sourcing Codaset! I want the world to see what I’ve done, and how I did it.

Lovin’ it!

Ever since I began working for ShermansTravel, and in particular, since I became more involved with CakePHP and open source software, I’ve spent a LOT of time using Trac and Github. Trac is somewhat of a defacto standard for managing software projects, and is what we use at work. Github is what I use for my personal and open source projects; and is also what I wish I could use at work. Both are great at what they do, but in most cases, each does something better than the other.

Trac has a kickass issue tracking system, which is very customisable, and integrates very neatly with Subversion. Unfortunately it’s not especially user friendly, and doesn’t support Git. (there is a git plugin, but it’s alpha code). It’s also self hosted and written in Python, which means it’s not the easiest to get up and running.

Github is so hot right now! And for good reason too. It’s built entirely around the excellent Git, and implements it’s features all around the ideal’s of Git. But that’s about all it does. Only up until recently has it been given an issue tracking system, and to be honest… that sucks!

So basically, both Trac and Github have their strengths and their weaknesses. But each is missing a part or parts of the other.

So that is why I am creating Codaset. Codaset aims to be all that Trac and Github are good at, in one nice, neat package. It will be based on Git, allowing it to offer great social features, but it will also have a kickass issue tracking

system that will integrate perfectly with your source control.

But I don’t intend to make this a Github/Trac clone. It’s gonna be sooo much more… eventually! Things that you cannot find on any other web based software project management system.

So this was just a little teaser, and an invite for you all to join in the private beta, which I hope to start soon. Take a look over at Codaset.com, and signup now. I’ll be posting more about what to expect as and when I can. In the meantime, here’s a quick screen shot to wet your appetite.

Oh and don’t forget to follow me on Twitter.

I had this idea a while ago, and actually implemented it into a Cake project, but it was a bit hacky and required hacking the core. So I didn’t like it. But today, I had a need for this same functionality, so I had a little think about how I could implement it without hacking the core, and thus was born the Callback plugin for CakePHP.

If any of you have ever used Ruby on Rails, you should be familiar with its callback system. Well, it was this system that I needed.  I just started fleshing out a new Cake app, and needed to run a beforeFilter callback on a couple of specific controller actions. Of course, I could do this:

But that’s just not very elegant, and will get pretty messy the more you do it. So I came up with the Callback plugin, which is basically a simple component that provides some sweetly fine grained control over your callbacks. So now I can do this instead:

and I can even call several callbacks, each with their own methods:

Now the above is lovely and all, but it doesn’t really provide any extra functionality above what Cake already provides. So far, my code just looks cleaner. What I really want to do is only run the anotherCallback when calling the index action. So I change the $beforeFilter param:

Much better! I can also specify to run a callback on all actions, except the ‘delete’ action:

Even better! But still I wanted more!

I wanted to be able to add even more control, and only run a callback if a certain condition is/not met:

So the anotherCallback callback will now only run if the _ifTrue method returns true. Lovely!

Right now it supports the three main controller callbacks: beforeFilter, beforeRender and afterFilter. The plan is to provide the same functionality to Models.

You can checkout the code from Github repo at http://github.com/joelmoss/cakephp-callback. Feel free to fork away!

It’s been too long, but here’s another handful of nibbles for your CakePHP applications and development.

Plugin Server

After some great improved support for re-usable plugins in Cake 1.2, and Gwoo’s announcement mention at last years CakeFest in Florida; we are now starting to see some evidence of a fabled plugin server. The idea, is that after installing a small Cake shell in your vendors directory, you would be able to install a selection of official and unoffical Cake plugins into your application via the command line. So no need to manually download, unzip and copy files into your plugins directory, as the shell would do it for you. The actual server code is also planning on becoming publicly available, so that we can all host our own CakePHP plugin server.

You can test the first release at http://plugins.thoughtglade.com

I gotta say, that I love this idea, and would really help in spreading the word. Not to mention, make it easier to use Cake and its increasing selection of plugins. I just wish that there would be a similar way to install Cake. There are some great things to be said about systems such as Pear, which would allow you to install the Cake core in a central place on your machine. Then create apps anywhere else on the same machine.

CakePHP 1.2.1

Hot on the heals on the final release of CakePHP 1.2, comes a bug fix and security release. 1.2.1 includes a few bug fixes, but most importantly, fixes a nasty security risk in 1.2. So please upgrade as soon as you can.

API Viewer

Up until now, the Cake API left a lot to be desired. But after some frustrations with Doxygen, Core developer Mark Story led the charge to create a Cake based API generator. And man did he do a great job. Check out the new API viewer now at http://api.cakephp.org, or check out and use the code at http://thechaw.com/api_generator

DebugKit Moves home

And just a quick reminder that the excellent DebugKit plugin has moved to a new home at The Chaw: http://thechaw.com/debug_kit - Don’t leave home without it!

CakePHP Twitter Timeline

This just in, you can now see all the buzz and twitterrings about Cake in a very pleasing way: http://cakealot.com/cakephp-timeline.html

BedPosted

And this is just great. A web app which you can use to keep track of your sex life. Haven’t you always wondered how often you scored this past month, or would like to see a rolling sex history of your life? Well worry no more, coz some bright spark has done just that, and it’s all done with CakePHP. Check out BedPost.

Just a quick one, as I am sure that you have already read, but I am extremely pleased to tell you all that CakePHP has been released as a final and stable release. This means no more alpha’s, beta’s or release candidates. Get it while it is hot, as it is very HOT!

Big congrats go to Nate, Gwoo and all the core team. Well done guys! On to 1.3…