So … where is the PHP equivalent of Django Admin? Or the multitude of Rails Admin plugins?
I don’t care what framework it sits on as long as the out-of-the-box functionality is awesome.
Archive for the ‘PHP’ Category
PHP equivalent of Django Admin?
Wednesday, August 20th, 2008CodeIgniter: I Don’t Hate It
Thursday, February 14th, 2008The unfortunate tragedy of my life is that I don’t get to develop in Ruby on Rails all the time. No, unfortunately for me, a large number of my clients need work done in PHP.
Which, as already indicated in several previous nuanced discussions, I hate.
I mean, really really HATE.
But that’s not the point of this post.
After being seriously burnt by the twin miseries of CakePHP’s poor documentation and desperately misguided attempt to mimic Rails I went looking for a new PHP MVC framework for a recent project.
Crucial requirements:
- lack of opinion
- simplicity
- good documentation
- understands PHP is not Ruby
I really wanted something that was pure VC, leaving out the M.
Views, Controllers and Models can go to hell.
PHP’s complete lack of dynamicism (and yes, I know PHP 5 has a crack at it, but whatever) means any attempt at Hibernate or Rails-style ORM is doomed to failure. And after screaming at CakePHP every time a finder returns an array of nested hashes of arrays of hashes and you can never work out how to just iterate through the records I’ve gone back to ADODB. You run a query and are returned a Record Set. I know this just reveals how long I spent in the late 90s hacking ASP, but if any language was still living in the late 90s, it’s PHP. And it’s actually quite good at it.
Where was I?
Right. Clean View/Controller mechanism. No Models.
Enter CodeIgniter.
It’s incredibly simple, the only assumption it makes is that you may never need most of the stuff it includes, so everything is an option, and it has great documentation.
CodeIgniter: I Don’t Hate It.
If you really have to use PHP, it’s worth a look.
Dear PHP and CakePHP
Friday, January 11th, 2008I hate you.
That is all.
Facebook Page and App Launch: Gillette Venus Beach Vote
Thursday, January 10th, 2008I’ve just completed development of another Facebook Application for a major promotional campaign for Gillette.
The Venus Beach Vote application manages a voting competition inside Facebook and is tightly integrated with the Gillette Venus Beach Facebook Page. It was developed in CakePHP with PHP 5, MySQL 5 and uses FBML for the presentation layer.
The new Facebook Page functionality expands the possibilites for marketing inside Facebook considerably - brands can create a page and then allow applications to interact with both the page and user profiles.
Venus Beach Vote is my largest Facebook Development Project to date and developed in a very short time frame to hit a hard deadline. I am even going to take a day off this weekend, I think I’ve earned it.
Converting a FaceBook App to use Amazon S3
Friday, November 16th, 2007I’ve just completed work on another Facebook application: Songbook.
This was a relatively straight forward conversion of the existing application to use S3 for data storage. Songbook allows users to upload and display a song in their Facebook Profile. The original development stored the files on disk and hit limits really fast … hosting large numbers of files becomes very expensive very quickly, not to mention performance issues.
I converted the whole thing to S3 very quickly - it’s actually easier in some respects to handle storing files in S3 than to disk. The application now has essentially limitless and very cost-effective storage capacity.
S3 really is incredible.
Everything you know about scaling is wrong
Friday, August 3rd, 2007Scalability of the favourite argument topics of the technically inclined. Having developed some fantastic, all-singing, all-dancing, user-generated social networking Web 2.0 platform*, someone will invariably ask:
“Oh, you used {LANGUAGE X}”
“Will it scale?”
You have to imagine the slightly derisive tone for yourself.
Trouble is, languages don’t scale, systems do.
Assessing scalability on the basis of a particular programming language is like saying to someone who is writing an Encyclopedia: “English won’t scale”.
Systems scale.
If you wrote your Encyclopedia the same way you wrote your product brochure, it wouldn’t scale - small page format, lots of pictures, minimal text with plenty of whitespace. If you write an Encyclopedia, you need to develop a system for handling the information - table of contents, indexing, cross referencing, multiple volumes, alphabetical organisation, thin paper, multiple columns of text, readable fonts.
The language used to write the Encyclopedia or Brochure is secondary to the system that delivers it.
The same is true of Web Applications.
Languages are irrelevant to scale and frameworks (being very close to languages and essentially an extension) only have a minimal impact.
I moved to Ruby on Rails from PHP. The standard argument against Rails from PHP developers is that “Rails won’t scale”**. However, this focus misses the point entirely. I have seen arguments from PHP developers who suggest using single quote for strings ‘ rather than double quotes “, because single quotes parse faster in PHP. This thinking is radically broken.
Scalability has nothing to do with processing performance at the language level.
Scalability is about the system as a whole.
At some point as an application scales, it will invariably require multiple servers and multiple databases, and there is very little any language or framework can do to mitigate this requirement. These requirements are system level, not language level - your only real option is to be ready to build your system out accordingly as it grows. The only trouble you find is when you have made decisions early on that limit the way your application can grow out.
As a corrolary to the scaling issue, my final point is this:
You aren’t going to scale
Call me cynical, call me pessimistic, but lots of people build for scale prematurely.
The focus should always be on creating great user experience.
Unless you have the load to warrant a particular system decision you should not be creating that system (but always within the framework of sensible architectural decisions). Scaling issues are often unpredictable (you don’t know your load profile until you hit it, or are hit by it) but worrying about them before you have to wastes valuable developer resources on infrastructure rather than the interface.
In the Web 2.0 world, scaling problems are a sign of success, but the focus should be on the user, not the system.
* We don’t develop applications or, god forbid, sites anymore, we develop platforms.
** I am aware the argument is a bit confused here, because PHP is compared to Rails, when Rail is a framework based on the Ruby Language and should be compared to a PHP framework like CakePHP.
Note to self: server date and Amazon S3
Tuesday, July 24th, 2007Just lost an hour of my life trying to work out why the test server received 403 errors when attempting to store an image using Amazon S3.
The server date was a day out and S3 uses the date as part of its authentication scheme.
Note to self: check server date when seeing inexplicable errors in Amazon S3.
Wrong Language
Monday, July 2nd, 2007Don’t you hate it when you spend ages wondering why your code won’t work:
$queryString += $value;
And then realise that in PHP you use “.” to join strings:
$queryString .= $value;
Stupid PHP.
My favourite Ruby Gem is Magic
Tuesday, June 19th, 2007On Ruby asks in June’s Blogging Contest:
“Other than Rails, what is your favorite Ruby Gem, and why?”
My favourite Ruby Gem is Dr Nics Magic Models.
Magic Models weaves a dark spell on your code that makes your ActiveRecord Models just disappear. It’s glorious for demonstrating to the skeptical the possibilites affored by Ruby, and it makes prototyping and development even more efficient. As Dr Nic says:
In a way, MM works like scaffolding does at the controller level - it lets you get your application “working” faster even though you’ll probably rewrite it in the end anyway.
Starting with Magic Models is a matter of installing the Gem and requiring it in your application:
gem install dr_nic_magic_models
require 'dr_nic_magic_models'
Now you have Models that appear based on your defined database tables, no other code required. So if you have a People Table, you automagically have a Person Model with attributes matching the columns defined in the table.
If you crack open the gem, you find the Magic isn’t so magic after all. The crucial action occurs in const_missing.
def const_missing(class_id) begin return normal_const_missing(class_id) rescue end @magic_schema ||= DrNicMagicModels::Schema.new self unless table_name = @magic_schema.models[class_id] raise NameError.new("uninitialized constant #{class_id}") if @magic_schema.models.enquired? class_id end superklass = @magic_schema.superklass || ActiveRecord::Base klass = create_class(class_id, superklass) do set_table_name table_name # include DrNicMagicModels::MagicModel # extend DrNicMagicModels::Validations end klass.generate_validations @magic_schema.inflector.post_class_creation klass klass end
const_missing is called when the Ruby Interpreter cannot find a constant. In the example above, if we call the Person model (using Person.find, for example), const_missing is called and Magic Models goes into action - checking the database for a corresponding table and creating a class with the appropriate attributes and validations. The rest writes itself.
Magic Models looks like magic to those uninitiated in the wonders of a truly dynamic language.
I use them to get a leg-up on new development. I have also used them to demonstrate to some colleagues the things that are possible with Rails - scaffolding for free, testing baked-in, easy AJAX and code that isn’t there but works anyway.
It’s worth learning, just to see the expression on the PHP and Java guy’s faces.
If you’re looking for more:
- Dr Nic has some slides on Meta-Programming
- Why’s (Poignant) Guide.