I’ve got a confession to make - I don’t do Photoshop very well.
In spite of my best intentions, I can’t seem to wrap my head around all the stuff expert designers take for granted. I guess I’ve got the mind of a coder. The fact that I can take a finished graphic and convert it into lovely XHTML and CSS code but would rather be coding PHP, Perl, Ruby, (insert new flavour of the month here) seems to attest to this.

Fireworks is another story. This absolutely simple-to-use application is where I spend most of my time when I need to work with graphics. The learning curve is a lot easier and for the 10% of stuff I need to do that it can’t handle, I’ve got friendly designer, Photoshop-expert friends.

That said, Fireworks related information on the web a little thin. The following tutorials and resources have been really helpful and hopefully they will be useful to you too (if you’re the Fireworks type).

Tutorials

• Glossy Button in Fireworks
• Fireworks Web 2.0 Styles
• Web 2.0 Styles (Fireworks CS3 only)
• Web 2.0 Style Text With Fireworks
• Creating Web 2.0 elements in Fireworks
• Creating an icon in Fireworks
• Creating user interface mockups with Fireworks

Resources

• Tutsbuzz.com - Adobe Fireworks Tutorials
• Firetuts.com - Adobe Fireworks Tutorials
• Tutcity - Adobe Fireworks Tutorials
• Various Articles, tips and extensions
• Adobe Fireworks Tutorials and Downloads
• qrayg.com - Adobe Fireworks Tutorials
• Tutorials, text effects and image effects

The 2008 Formula 1 season has started and the first race was absolutely smashing. For real.

Brit Lewis Hamilton qualified at pole position and went ahead to win the race but that’s not the best part of this year’s first race.
In my view, the highlight is the introduction of rules designed to make the races less dependent on electronics aids. The consensus then is “out with technology”.

• Traction control is gone (a system which helps limit rear wheel spin or loss of traction when excessive throttle or steering is applied by the driver).
• Engine assisted braking is also out (in the simplest terms, a form of anti-lock braking - but not quite).
• Goodbye Launch Control (a system that allows the driver at the start of the race and at pit stops achieve optimal getaway without spinning the wheels).

The results? Out the 22 cars at the beginning of the Australian Grand Prix, only 7 finished the race. No more safety nets when the driver overcooked it.
Watching the drivers battle to hold the cars when the rear-end threatened to step out of line was a real joy to watch. Now that’s what I call racing.

These changes have a strong parallel with the current emphasis on designers and developers knowing how to hand-code rather than relying on Dreamweaver and friends to do the ‘dirty’ work.

Can’t wait for the Malysian race next weekend. Meanwhile, I’ll go have a drink on Lewis.

As an aside, these technologies have been making their way from Formula 1 cars into production cars. I wonder if that’s going to stop.

The Rails vs PHP debate has been on for ages with the standard answer being “You can’t compare Rails to PHP - Rails is a framework and PHP is a language. Compare it to CakePHP… or CodeIgniter… or Prado… or Symphony… or…”.
There are now so many PHP frameworks available it’s becoming increasingly difficult choosing one and sticking to it.

Rails has been the preferred Ruby framework for a while now and just until recently the other available frameworks were not mainstream. Moving from another language to Ruby invariably meant moving to Rails. Apparently, all that is changing.

Doing a search for Ruby frameworks brings up the following:

• Rails - The grand-daddy
• Merb
• Camping
• Sinatra
• Ramaze
• Nitro
• Vintage
• Wuby

Obviously Ruby’s fast catching up with PHP.
The positive side is the debates will now become “Ruby vs PHP” like they should have been in the first place.

CodeIgniter has been my PHP framework of choice for a while now. I’ve churned out numerous sites based on the framework and even have my own CMS built on CodeIgniter.

I have tried out other frameworks (CakePHP, Symphony, Solar) but still came back to CodeIgniter due to its flexibility, extensive documentation and portability. Everything was fine and dandy until I decided to convert one of my (non-critical) internal apps to Rails just to try out the framework. I went from zero Rails experience (bar all the screencasts) to a fully working (small) app in three days.

Granted, my knowledge of CodeIgniter came in handy (in the end all MVC frameworks are the same at heart) but Rails has got so much convenience built-in that development is a breeze. Also, ActiveRecord (a true ORM implementation and radically different from the CodeIgniter flavour) is an absolute dream.

Fast forward a couple of weeks and back “in the real world of shared hosting accounts” here I am back to coding with CodeIgniter and it’s a real drag. The issues:

• CodeIgniter validation is long-winded and after using the Rails one-liners in the models for validation this is becoming a chore.
• ActiveRecord in CodeIgniter is really nice to use but after my experience with a true ORM and the ease of manipulating data with it I’m sold.
• CodeIgniter requires some code which (in retrospect) is actually redundant. Having to assign views manually for every controller method is a case in point.

However, I’m pleased to say my preference for CodeIgniter is back and stronger after a couple of tweaks to try and solve some of these issues. The launch of version 1.6.0 of codeigniter also came at the right time as some of the tweaks depend on features previously absent from CI.

The changes:

• Ditched OBSession: I have been using OBSession as the session library instead of that built into the CI core. I had a lot of issues prior to the switch. However the new version has some new features built-in (notably flash variables) and after a couple of days testing the applications seem to be working fine.
• Extended the Validation Class: I ran into this post and the included library was really helpful in cutting down the number of steps involved in validation.
• ActiveRecord: There’s an ORM implementation of ActiveRecord in the CodeIgniter Wiki and it basically suited my needs but its performance was not consistent. It did work on my Slicehost VPS but not on the MediaTemple GridServer or a WHM dedicated box. However, I didn’t bother to troubleshoot this after seeing the size of the objects being loaded.
  I then decided to check out CakePHP but this post pointed out that the cakePHP ORM does not use objects entirely, like Rails (and the CI mod) do.
  So I made a version of the CakePHP ORM for CI and it’s working fine for me. Problem solved.
• Helpers: I also added a couple of custom helpers (like the h helper in rails for escaping data).
• Views: My view folder is organized like the Rails view folder with a folder for each controller and a view file for each method named the same as the method. I extended the controller (created a library called MY_Controller) and all the application controllers extend this. If a view file exists, it is loaded into the main application layout (just like in Rails). However a view file is not required for every controller.
  I still have to call a render() method at the end of every controller though.

I am still tweaking this and as soon as all the bugs are ironed out I’ll show some code.

So in a nutshell, Rails made my PHP better! Ironical?

Update: I just tried out CakePHP again (for the first time after coming back from Rails) and it’s the closest PHP could come to Rails. I should use it on an actual project to get a real feel for it.