Blog (php) - Fred Wu's Tech

PHP Devs: Have You Started Playing with More Toys?

2012-06-29T19:03:00.000000Z

TL;DR - PHP is still a useful tool, but as a PHP developer, have you started playing with other useful tools? Here’s my story.

Today Jeff Atwood’s new piece “The PHP Singularity“ and Marco Arment’s “PHP Addiction“ have started another round of heated discussion on PHP.

As someone who started his career as a PHP developer, I feel like sharing my thoughts from a different perspective.

I began my career as a freelancer - since JavaScript and PHP were the two programming languages I learnt at school, they naturally became my weapon of choice for freelancing work.

At that time I knew very little about software development. My desire was simple: I liked making websites, therefore I decided I was going to do it for a living.

Over the years I came across many people who shared a similar background - people who do not have a strong (or any) computer science / software engineering background, were making websites.

Compared to most software developers, the intention of doing programming for me was different. I had no intention (or awareness) to create maintainable software , instead I simply wanted to create an end product that works.

Was I wrong? According to the market, no. There are many clients who want affordable websites, just like there are many people who want affordable Android phones. On one end you have Android phones that compete with the iPhone and take time to get released, on the other end you have Android phones that use readily available, often less desirable components and are quick to market. Each serves its purpose and fulfils customer demands.

As I kept developing websites and educating myself, I became more and more interested in software development. That’s when I started reading books like “PHP Objects, Patterns, and Practice“. But even then, my knowledge was still extremely limited, and my desire at that time was to increase my PHP knowledge and become a better developer.

For the first desire I made it happen by reading more books and articles, but for the second desire - I thought I made it happen, but in reality I didn’t because I did not correctly identify my weakness. It wasn’t just about the depth of knowledge, but also the breadth.

Spending most of my time writing PHP made me too comfortable in a little corner. The discovery of tools such as CodeIgniter made me feel good about being a competent web developer. After all, I was doing quite a fine job churning out websites.

In 2006 I discovered Ruby on Rails, but that did not have too much impact on me, because I was not yet capable to tell the differences it has compared to PHP (frameworks).

In my mind, PHP and Ruby are both scripting languages that can be used for developing websites and web applications. Although the statement is true, not knowing the specifics made me very ignorant. It is almost like not knowing the difference between travelling from one continent to another by an airplane and by a ship - either will get you to the destination, right?

And this is exactly why my first ruby program looked just like a PHP program.

It was (and still is) an interesting and rewarding journey to slowly discover why my Ruby code sucked.

So I started reading on design patterns, software craftsmanship and other programming languages. And I was lucky enough to be surrounded by many brilliant developers who taught me how to write better code.

At that point, my intention for learning more about software development had shifted from simply making an end product, to making an end product that can be maintained.

And that changed everything. From a PHP developer who just wanted to churn out websites quickly, to a developer who wanted to use software development to create value - in the sense of both business value and technical value.

An important thing to remember is though, it’s not about Ruby , and it certainly is not about looking down on PHP. Rather, the point is to see whether or not there’s something out there that might enable you to look at things differently, and do things differently, for better or for worse.

PHP for some is a double-clawed hammer, but there is no doubt in my mind that for some others it is a near perfect tool, for now at least. Having said that, many other kids have started playing with all sorts of toys, why haven’t you? :)

]]>

Zend Framework - From Extreme Simplicity to Enterprise!

2012-03-25T12:09:00.000000Z

Today an interesting blog post on Zend Framework has made to the Hacker News front page. I have to agree with the author - Zend Framework is an over-engineered piece of software.

A few years ago I was working full time as a PHP developer. Naturally, I had experimented with lots of frameworks, including CakePHP, CodeIgniter, Kohana, Yii, Symfony and obviously, Zend Framework.

Over the years, I had developed many projects primarily using CodeIgniter and later on, Kohana. There was one project that was larger in scale compared to an average PHP project (whatever that means), so I decided to use Zend Framework to take advantage of its component-based structure.

The result? It was dreadful.

At that time there wasn’t any built-in or quick n’ easy way of bootstrapping a Zend Framework project, so we had to cook up our own. The documentation was absolutely horrible despite its completeness viewed from a distance - to find anything useful, Google is more likely to provide you with the answer, even from the results on the documentation site. And of course, the framework felt so heavy and long-winded. It, felt, Java.

In terms of the code structure, Zend Framework is almost the complete opposite of CakePHP - no offense to the CakePHP developers and users, but if you take a look at each framework’s source code, you’ll know what I mean.

Having layers and layers of structures might appeal to certain users (Enterprise baby!), but does anyone still remember back in the day, how Zend was announcing/marketing the Zend Framework?

Extreme simplicity!

That’s right, Zend Framework was marketed as an extremely simple to use web framework. In fact, we can still read Andi Gutsmans’ post on this topic. Let me quote the relevant part (emphasis mine):

As some know, our ultimate goal for the framework is what we call “ Extreme Simplicity “. Some might have heard me use that term in some of the talks regarding PHP, and I’d like to bring this concept over to the framework. I believe this is what the PHP spirit is all about and the idea behind it is that it’s possible to create very simple & easy-to-use languages&frameworks which still remain powerful and flexible.

Can anyone, including the Zend Framework developers, honestly say that Zend Framework is an extremely easy to use framework?

I guess at the end of the day, in order to market PHP and Zend Framework as ‘enterprise-ready’ with trainings and certifications, something has to give.

]]>

[PHP] Releasing KThrottler, A Kohana Module for Throttling Actions

2010-07-28T13:29:00.000000Z

Similarly to Action Throttler for Rails, KThrottler is an easy to use Kohana module to quickly throttle application actions based on configurable duration and limit.

Go check out the code now! :)

]]>

Wuit.com Now Runs on Padrino

2010-07-01T21:59:28.000000Z

A few days ago I discovered Padrino, an excellent ruby framework built on top of Sinatra. What can be a better than experimenting with it? Build an actual website with it!

So last night I ported Wuit.com from using vanilla PHP + Flourish to using Padrino + DataMapper + Haml.

The entire porting experience was positive, albeit the website only has two pages.

I did encounter a strange problem with Capistrano though - both current_release and latest_release were giving me strange results. In the end I had to modify my deployment recipe to overcome this.

For building small to medium sized projects, I think Padrino is an excellent choice, as it offers a more complete foundation than Sinatra, and is not as heavy as Rails.

]]>

[PHP] Releasing PHamlP Module for Kohana, Use Haml and Sass with Kohana 3.0!

2010-06-27T14:42:52.000000Z

Haml and Sass are two extremely useful template engines. They are very popular amongst the Ruby and Rails community.

I am happy to release a module for Kohana v3 that uses the PHamlP library to offer Haml/Sass support for Kohana.

Right now the module only supports Haml but I will be adding Sass support in the very near future.

Head over to GitHub to check out the source code. :)

]]>

Deploy PHP Websites Using Capistrano (and Git)

2010-06-21T04:45:00.000000Z

The Rails deployment flow is really smooth thanks to the powerful (and easy to use) Capistrano.

Capistrano not only works with Rails and other Ruby code bases, but also code bases in any programming languages, such as PHP!

Here is an overview of what I did to get one of our PHP production sites up and running with Capistrano.

If you don’t already have Ruby and Rubygems installed, install them!

After you got ruby and rubygems, install Capistrano and its related gems -

gem install capistrano-ext railsless-deploy

Now, navigate to your application’s directory and run capify ., this will generate some necessary files for Capistrano to recognise your app.

Open up the generated Capfile file and replace the content of the file with:

require 'rubygems'
require 'railsless-deploy'
load 'config/deploy'

Okay, now we need to set up the actual deployment recipe in the config/deploy.rb file. But before doing so, we need to set up our deployment server with proper user and deployment permission.

We chose to set up a new user called deploy specifically for deployment purpose, for example -

useradd deploy

Then of course, we need the SSH keys for this deployment user, so switch to this user (su deploy) and -

ssh-keygen

We use GitHub, so simply copy the content of the public key (~/.ssh/id_rsa.pub) and add it to the deploy keys section of the Github repository.

Don’t forget to also add GitHub to the .ssh/known_hosts file, you can do this by manually cloning your repository on the deployment server.

Great! Now let’s do the last step - create the actual deployment recipe!

Open up config/deploy.rb file and you will see some default deployment tasks. Everyone has different needs, so I’m going to paste our deploy.rb file (masked with added comments) for your reference.

set :user, "deploy"
set :application, "YOUR_APPLICATION_NAME"
set :domain, "YOUR_APPLICATION_DOMAIN_NAME"
set :repository, "THE_ADDRESS_OF_THE_APPLICATION_REPOSITORY"
set :deploy_to, "/var/www/#{domain}"
set :shared_path, "#{deploy_to}/shared"
set :use_sudo, false

set :scm, :git
set :branch, 'master'
set :deploy_via, :remote_cache

role :web, "ADDRESS_OF_YOUR_WEB_SERVER"
role :app, "ADDRESS_OF_YOUR_APP_SERVER" # this can be the same as the web server
role :db, "ADDRESS_OF_YOUR_DB_SERVER", :primary => true # this can be the same as the web server

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
  run "#{try_sudo} /etc/init.d/lsws reload" # we use LiteSpeed Web Server
  end
end

# The task below serves the purpose of creating symlinks for asset files.
# Large asset files like user uploaded contents and images should not be checked into the repository anyway, so you should move them to a shared location.

task :create_symlinks, :roles => :web do
  run "ln -s #{shared_path}/uploads #{current_release}/uploads"
  run "ln -s #{shared_path}/zb #{current_release}/zb"
end

# Let's run the task immediately after the deployment is finalised.

after "deploy:finalize_update", :create_symlinks

That’s it! Now you should be able to deploy your application by -

cap deploy:setup
cap deploy

]]>