Beyond Coding

Just to be clear, this is NOT a fanboyism post nor do I encourage the debate between which language is superior. My personal belief is to use the appropriate tool for appropriate projects.

PHP Pros

• Widely available libraries (including PEAR and PECL)
• An absolutely outstanding online manual
• Relatively easy to learn (can hack together some code without deep understanding of the language)
• Widely used (easy to find clients, etc)
• Most if not all control panels have PHP integration
• Development packages (XAMPP, WAMP, MAMP, LAMP, etc)
• C style syntax (easier transition for people with C/C++/Java background)
• Powerful array feature (Ruby’s equivalent to PHP’s associative array is Hash, which is not interchangeable with array)
• PhpDoc is better than RDoc (this might be because I am too used to PhpDoc)

Ruby Pros

• Fully object oriented
• Rake (Ruby’s Make)
• RubyGem (Ruby’s apt/yum)
• Code blocks
• ‘Ghost’ classes
• Modules (aka namespace/package, PHP 5.3 will have namespace too, but with much uglier syntax)
• lambda functions (PHP 5.3 will have this too, but not as powerful)
• Children-aware parent classes (’inherited’ hook)
• Multi-inheritance through Mixins (PHP is single-inheritance)
• Ruby 1.9 is unicode friendly (PHP 6 will be)
• For what I do, Ruby on Rails > all PHP frameworks combined
• Regular Expression built into the language core

I am pretty sure there’s heaps of pros for both PHP and Ruby missing from the list, but at least it gives you a rough idea on what to look for if you are not very familiar with them.

Please share your experience with us too (and I will update this post accordingly). :)

Related posts

• Ruby on Rails, Passenger (ModRails) vs CodeIgniter and Kohana (13)
• Release: [Kohana Module] Authlite, for User Authentication (10)
• PHP Namespace – $this->sux (1)
• CodeIgniter – Loading Models and Database in One Hit (4)
• Benchmark: LiteSpeed vs Apache (PHP and Plain HTML) (10)

Since my previous post on this topic, Kohana has evolved and changed quite a bit, to the point that the instructions provided are no longer applicable.

So here are the updated instructions for those who would like to integrate Zend Framework into Kohana.

1) Put the ‘Zend’ folder in your application’s ‘vendors’ directory.

2) Put the following code into an appropriate place in your application, it could be in the base controller.

if ($path = Kohana::find_file('vendors', 'Zend/Exception'))
{
	ini_set('include_path',
	ini_get('include_path').PATH_SEPARATOR.dirname(dirname($path)));
}

3) Instanciate the Zend library with the following code:

require_once 'Zend/Mail.php';
$mail = new Zend_Mail;

That’s it! How simple is that? :)

Related posts

• Yii Kohana Bridge updated: full Kohana flavour now added! (1)
• Using Zend Framework with CodeIgniter (30)
• Release: [Yii Extension] Yii Kohana Bridge, use Kohana helpers in Yii! (0)
• Notes on Choosing a PHP Framework: A Quick Comparison of CodeIgniter and Kohana (45)
• Layerful Framework Performance in Kohana (1)

Had a beauty today. There I was ready to deploy some nicely polished code to the server. After some thorough local testing it looked like it’d be a smooth process. So the code went up, but all my funky AJAX stuff stopped working on the server. How could that be? It was perfect locally… :)

It took a little while but in the end I realised what was going on – json_encode wasn’t working. The server was running PHP 5.1.6 and json_encode only became “standard” with PHP 5.2.0 onward.

I needed a solution fast. No time to recompile a newer version of PHP, add libraries or anything fancy like that. I just needed the function json_encode to work right now. Thankfully, the solution was as easy as adding replacement a function a user kindly submitted from the PHP site itself:

http://au.php.net/manual/en/function.json-encode.php#82904

I blindly assumed PHP 5 was PHP 5. I wasn’t using any extremely fancy commands or anything, but I still came unstuck. So the moral of today is check your server specification right down to every last decimal point! ;)

Related posts

• Release: [jQuery Plugin] Endless Scroll (17)
• Oh, where did my theme go? (1)
• jQuery problems in IE? It could be SWFObjects. (3)

Federico makes an interesting point about the PHP Namespaces Controversy on his PHP::Impact blog. I never thought about the mess that is PHP until I saw his comparison table:

Java:
Attribute/Method access: foo.bar
Static method access:    Foo.bar
Package access:          foo.bar.baz

C#:
Attribute/Method access: foo.bar
Static method access:    Foo.bar
Namespace access:        foo.bar.baz

Python:
Attribute/Method access: foo.bar
Static method access:    Foo.bar
Module access:           foo.bar.baz

PHP:
Attribute/Method access: $foo->bar
Static method access:    Foo::bar
Namespace access:        C:\foo\bar\baz

I guess I can’t complain though as the syntax of PHP is still a lot closer to more “traditional” languages than something like Ruby (not talking about the namespace, just the language in general)… :)

Related posts

• Ruby on Rails, Passenger (ModRails) vs CodeIgniter and Kohana (13)
• Release: [Kohana Module] Authlite, for User Authentication (10)
• Comparison: Ruby vs PHP, the Pros (4)
• CodeIgniter – Loading Models and Database in One Hit (4)
• Benchmark: LiteSpeed vs Apache (PHP and Plain HTML) (10)

Two weeks ago I started working with Zend Framework at work. I chose to use Zend Framework for one primary reason: Zend. Even though I have plenty of experience with CodeIgniter and Kohana, I simply could not take any risks using them for a rather large project at a company I had just joined.

My experience so far is mixed. Probably because I am so used to the way CodeIgniter and Kohana do things, Zend Framework just appears utterly complicated and difficult to work with (at the beginning).

(more…)

Related posts

• Zend Framework 1.5 Released (3)
• Using Zend Framework with Kohana (5)
• Using Zend Framework with CodeIgniter (30)
• Notes on Choosing a PHP Framework: A Quick Comparison of CodeIgniter and Kohana (45)
• Magento 1.0 is out (0)

Yeah I am a lame PHP guy who hasn’t gotten too deeply into Ruby yet. ;)

In PHP I often use variable methods, for example:

$foo = new Foo();

$funcname = 'dynamic_method';
$foo->$funcname();
// Same as calling $foo->dynamic_method();

$varname = 'dynamic_accessor';
$foo->$varname = 'some value';
// Same as calling $foo->dynamic_accessor = 'some value';

Now, because Ruby does not prefix $ in front of variables, it is impossible to use variable methods the way we do in PHP.

I am sure for Ruby gurus it’s pretty obvious but for me, I just spent more than 30 minutes searching for an alternative other than evil eval, and I finally found one.

We use the PHP call_user_func and call_user_func_array equivalent in Ruby: send or __send__.

Luckily accessors in Ruby are methods, so we are able to use the send method for both methods and accessors.

For example we can set a variable accessor like this:

foo = Foo.new

funcname = 'dynamic_method'
foo.send "#{funcname}"
# same as calling foo.dynamic_method

varname = 'dynamic_accessor'
foo.send "#{varname}=", 'some value'
# same as calling foo.dynamic_accessor = 'some value'

I wish in future versions of Ruby, we can somehow assign accessor values the way we do in PHP. :)

Related posts

• No related posts.