If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
This past week I’ve spent some time evaluating CakePHP and trying to compare it to the things I’ve learned in Ruby on Rails. I checked out CakePHP over a year ago, and I admit I didn’t get into it as much as I had hoped. Having dealt with Struts while using Java, I felt at home with both in terms of their MVC nature and I have no desire to go back to life without a framework. Because CakePHP started out as a Rails Clone, they share many advantages:
- Convention over Configuration - Each framework tries to follow a set of standards in filenames, controller names, and so on so on. When I work on a site someone else designed using a framework, I know where things go and I can familiarize myself with that application much more quickly.
- Don’t Repeat Yourself - Specifying code in one place means that you only have to change it once should it need updating.
- MVC and a focus on “Fat Models” - Separate models, views, and controllers make life easier down the road when it comes time to switch to a new system that has a new database or when you want to make a fancy interface for an iPhone or the next new thing.
There are many other advantages to each, but let’s move on to the differences and disadvantages of these frameworks (keep in mind that this is from a somewhat unexperienced perspective, please let me know if these don’t convey the whole truth):
- CakePHP isn’t as mature as Ruby on Rails. Migrations aren’t fully integrated and the feature set seems to be a few steps behind Rails.
- CakePHP isn’t as easy to deploy as Ruby on Rails. This might matter more for larger applications, but I haven’t seen anything like Capistrano in Rails.
- Documentation is somewhat lacking in both. I had a hard time getting going using only tutorials that I found online. Rails has some great books, but I haven’t found any for CakePHP (although the tutorials and my familiarity with PHP made things easier).
- Ruby is new to me. In my opinion, it has a higher learning curve than PHP (possibly because I already knew Java before learning PHP).
- There are far fewer hosting solutions that provide good Ruby on Rails support. Although it’s pretty easy to get both up and running (especially for the lucky users of Mac OS 10.5), good hosting is pricier for Rails applications.
With all that said, there’s no way I’d like to go back to plain old PHP for developing a website. Things have come a long way even in just the past year for both of these frameworks, so I hope to keep learning them both. In the meantime, though, I’m devoting more of my time to Ruby on Rails, simply because I’m actually finding it fun to code in Ruby (and the Ruby Quiz is something I wish my programming classes had been) while PHP never had me quite as excited.
I just had a few weeks off from school and work, so I thought I’d take a look at Ruby on Rails, which has been the “next big thing” in web programming for over a year now. Two books and over a month later, I can say that I’ve been impressed with that test drive and I think I’ll devote some more time to learning more about how to use it. As a test project, I’m working on re-writing Quotational using Ruby on Rails to get some experience beyond just typing in some example code from books.
I enjoy the structure that Rails offers, and that way it has of making web programming fun again. I’ve used PHP for several years now, and I find myself rewriting things continuously just to make things better. While this has certainly made me a better programmer, the steeper learning curve of Rails lets me do more in a shorter period of time although the degree of difficulty is higher. Rails brings a common framework with it, and one that seems to be more accepted in my experience than any PHP framework that I’ve worked with.
So far, the major drawback has been the availability of free resources for the Rails newbie, although this is a problem that is increasingly getting smaller. My initial impetus to take that first step toward learning Ruby on Rails was an offer for a free PDF book from Sitepoint, a deal that has since expired but is still definitely worth paying money for. That book was a great resource for me, and I’ve since gone on to buy a similar book, Agile Web Development with Rails. Those two books provide a lot of the same information, but reading through them both helped me pick up on things that I would have missed otherwise. From here I may not have a lot of time to devote to learning Ruby on Rails, but I definitely plan on continuing that effort.
In a world so full of noise, sometimes it’s great to retreat to a place of simplicity. One of my recent web retreats is getting back into Joe’s Goals, where I’m digging the new 2.0 interface that keeps everything on one page. It’s pretty simple - every time I complete a goal, I click to put a check mark on the box for that goal. I can add another check mark by clicking on the box again, or click directly on a check mark to remove it. It’s pretty simple to use, but the great part is that I’m the one to choose what a check mark means. I’m not affiliated with the site in any way, but I am a daily user.
Joe’s Goals is a simple way to track productivity chains - I can set it to show me how long I’ve kept up my daily scripture reading or my exercise (and I can even exclude Sundays for that goal). It’s simple, free, and easy. Thanks, Joe!
Seth Godin struck a chord with me when he discussed reorganizing for profit. He basically says that retailers should organize their stores according to the tasks that buyers will perform. Home Depot should put screwdrivers next to their saws, because a person working with wood would likely need both. I’ve done this a million times at stores like this, finding myself walking through nearly every aisle before I can find what I want. Apparently, there are many people that don’t like this idea, thinking that I’ll find something I didn’t remember I was looking for. They seem to forget that if I can’t find what I’m looking for in the first place, I’m likely to leave.
We all have customers, whether they go by that name or not. Those we’re trying to sell our services to should be the ones we think about first. I’ve met many brilliant computer programmers who sometimes add feature upon feature to their programs that end up being totally unusable because they don’t think about their customers. Hotmail and Yahoo! Mail did this to me recently when they thought I wanted my web-based email client to be more like my desktop email (like say, Outlook or Eudora). Sure, Yahoo and Hotmail felt more like desktop mail clients, but Gmail is a million times faster and easier to use.
Who are your customers? Try putting yourself in their shoes, or better yet, asking them how they think something should be done. If you get yourself into their mode of thinking, then you can try to sell them on the stuff they didn’t know they always wanted.
When learning how to do things on a computer, I tend to learn best by example. I remember borrowing library books and entering BASIC code into our Tandy 1000 computer when I was younger, later tweaking the code so that I could make my own games. Programming is the same for me today; I like to find a good example, use it, and then tweak it and make it my own. With the ever-changing state of the Internet, however, it’s not easy or practical to find a library book with examples for website design. Instead, a good resource to learn CSS by example is at Dynamic Drive. The CSS section of their site is well designed as has many good examples. Give it a look!
