@odysseus is now mayor of Shiny Wooden Horse Disco Everybody Come Check It Out! on #foursquare!
@agamemnon just checked in from Shiny Wooden Horse Disco Everybody Come Check It Out! via gowalla
@cassandra IT’S A TRAP!
@priam @cassandra SHUT UP ADMIRAL AKBAR THIS HORSE IS AWESOME
@agamemnon is now mayor of Sacked Ruin of Troy BOOYEAH! on #foursquare!
PHP is easy… as programming languages go, that is. You can build sites in a real hurry.
With frameworks like Symfony, you can build them faster still, and follow modern programming practices at the same time.
And Apostrophe strips away yet another layer of effort if your site calls for a content management system.
Yes, Java has more raw speed, all else being equal (which it never is). But as the LISP programmers used to say, “a moment of regret, a lifetime of convenience.”
Still, sooner or later success catches up with you and you want your site to cope with Serious Traffic… or cope with moderate traffic on a cheap virtual machine… or at the very least, not be dog-slow with just a handful of users on the system.
There’s a lot of advice out there about optimizing PHP code, some of it well worth your while. And there’s excitement about HipHop, Facebook’s new native code compiler for PHP. But these are drastic steps that require you to rewrite your code or adopt less proven and more awkward ways of delivering your code.
Justified? Sure, sometimes, on the biggest projects in the world (like Facebook) (*). But as Donald Knuth says, “premature optimization is the root of all evil.” That’s because tweaking your code for speed’s sake usually makes it harder to maintain and less adaptable to new requirements.
What most developers don’t realize is that there are three major factors that typically slow down PHP projects based on frameworks (like Symfony or, sigh, Drupal) so much that code profiling and database query redesign don’t even have a chance to become relevant factors. Fix these things first before you worry about other issues:
1. Compiling code over and over and over. Would you wait for your Mac to recompile MacOS X from source code every time you boot it up? Of course not. How about every time you fill out a dialog box? That’s pretty much what you’re doing every time you access a PHP-driven website that doesn’t use a bytecode cache.
2. Waiting and waiting and waiting for web browsers to make another request, pinning down web server processes that your other users need. By default Apache usually lets browsers hold on to a connection for up to 15 seconds just in case they ask for more. This is a good thing in many ways, but 15 seconds is far too long. Which leads us to #3:
3. Tying up a “fat” web server process with PHP on board for every request, even requests for the zillions of little static PNGs that probably make up your page design. (**) A typical Apache web server configuration with mod_php suffers from this flaw, fatally limiting the number of simultaneous users you can handle.
So what can we do about these problems? Quite a bit as it turns out. I’ll start with the low-hanging fruit and move on to the tougher stuff. The fascinating common thread with all of these suggestions: no changes at all to your PHP code.
Just a quick note in response to Lukas Kahwe Smith’s recent comments about the “problem” of multiple CMSes for Symfony. This note began as a comment of mine on Lukas’ blog.
We developed Apostrophe to scratch our own itch: we needed a CMS that our clients could use to add content to their sites in a variety of ways without inadvertently breaking the site design. So our CMS concentrates on the admin’s user experience, extending metaphors already present in the page. It’s about design even more than it’s about software architecture.
We also wanted to make sure it supported Symfony coding practices we were already having good success with. Therefore slots and engines implemented as Symfony modules, not new abstractions, and a clear lineage back to ideas from sfSimpleCMS.
We open sourced Apostrophe because we saw a win-win situation: other developers are in the same boat (their clients are also frustrated with Drupal administration, and they need a good solution today).
More eyes on our code, more bug reports, more suggestions equals a better system for everyone in the Apostrophe community.
Right now this is working for us in a big way, and it’s running in production on a number of client sites. Others on the apostrophenow google group are also happy with it (although they have valid criticisms that we are addressing), and they are building client sites that work. There’s no business case for us to screech to a stop and start doing something radically different.
Right now we have a team of seven people doing great work with Apostrophe and no interest in stopping that. Evolving it to be better, eventually rewriting it extensively in the Symfony 2.0 timeframe… sure! But unless the marketplace tells us otherwise, we’re going to keep doing good business, writing good code and sharing our work with those who like our approach.
Joomla, Wordpress and Drupal are all thought of as CMSes for PHP, but no one is telling them that they must merge. Why? People pick the project that works best for their needs. That’s as it should be. Software architecture isn’t the only differentiating factor between content management systems.
If you like Diem or Sympal’s approach better, heck, go ahead and use ‘em. A “there can be only one” approach leads to design by committee, and that is not always a good thing.
I am liveblogging Fabien Potencier’s Symfony 2.0 presentation. Bear with me and my editorial errors, simplifications and bare-faced libels.
My own opinions are in parentheses.
They are setting up now.
“Symfony 2.0 Reloaded” Preview Release
“I’ve decided to do the session in French” heh
In 10 minutes you will discover the shiny new version of Symfony, Symfony 2.0. Symfony 2 is just awesome. But first a bit of history.
Symfony 1.0 released in January 2007. Started as glue between existing libraries: Mojavi, Propel, Pardo i18n, …
“How many of you are still using 1.0?” [Some hands go up] “Ohhhhh!” [Hey, I raised my hand too, I have to support existing projects after all, heh. Our new stuff is all 1.4]
With Symfony 1.2 in November 2008, decoupled but cohesive components wre rolled out: forms, routing cache, YAML, ORMs… but still the same core.
Symfony 1.4 – November 2009. Added polish on existing features. Removed the support for deprecated features. Current LTS released, maintained until late 2012.
What is Symfony 2.0? The next version of course… except Symfony now takes an ‘S’ instead of an ’s’. That’s the big difference!
Talk about Symfony 2 with a capital S please! Symfony 1 (uppercase) does not make any sense, symfony 2 does not make sense! It’s all about Symfony 2. “I’m quite picky.”
“Same philosophy, just better.” We’ve learned a lot from our mistakes. We’ve learned a lot… we have problems with Symfony 1, but not all are fixable. It requires breaking backwards compatibility. So we need to go forward.
Symfony 2 is still an MVC framework.
It’s probably more of a Fabien-style framework than anything else (his words not mine (: ).
MTV: Model, Template and View?
Highly configurable and extensible. Same Symfony Components (DI, events, request, etc), same great developer tools, full featured.
Everything is upgraded to PHP 5.3. (Great, I hope they debug PHP 5.3 by the time Symfony 2.0 is complete!)
OK, but why a major version # change then?
(more…)
I’m attending Symfony Live. Below are my notes from Jon Wage’s presentation on the upcoming Doctrine 2.0. My more opinionated, less explanatory comments tend to be in parentheses. Everything paraphrased brutally to keep up.
“Not the same old PHP ORM”
100% re-written codebase for PHP 5.3
“Are you scared? You shouldn’t be! Change is a good thing!”
5,000 records hydrate in 1.4 seconds. Whee!
10,000 records in 3.5 seconds.
Twice the data and still faster than Doctrine 1.
% improvement over Doctrine 2 is big. PHP 5.3 is a big win with a heavily OO framework. Better optimized hydration algorithm. New query and result caching implementations. All around more explicit and less magical code. Killed the magical aspect of Doctrine 1.
“The only valid measurement of code quality: WTFs/minute”
Good code: “WTF….. WTF”
Bad code: “WTF WTF WTF WTF WTF WTF”
I’m attending the Symfony Live conference. Below are my notes from Geoffrey Bachelet’s presentation on Symfony Internals. Geoffrey Bachelet wrote the “Symfony Internals” chapter of the Symfony book.
He wrote the Symfony Internals chapter
Customizable, flexible, extensible
Extensible through plugins, events, and overriding entire framework classes
The bootstrap retrieves application configuration, then instantiates sfContext and calls the frontend controller
sfContext implements the Singleton design pattern. Has pros and cons: mostly cons. Testability issues. Responsible for loading factories.
Application configuration: frontendConfiguration extends ProjectConfiguration, shares methods and constructors. Most customization happens in ProjectConfiguration.
ProjectConfiguration crewates an event dispatcher, then loads plugins.
sfEventDispatcher is available as a separate component. Implements the Observer design pattern. An object can register interest in events.
autoload.filter_config event allows you to customize the autoloader configuration.
There are more than 900 plugins in the repository today.
settings.yml holds all framework leve settings, there are a lot of them. Actions, security strategies, I18N, debug bar, etc.
app.yml is for your use. config/app.yml is a project wide app.yml, we rarely use that.
Environments allow you to specify different behavior for different environments. Different database, mailer strategy, etc.
John Cleveley @jcleveley on the Symfony admin generator
@jcleveley gave an excellent talk on the Symfony admin generator at #sflive2010. Here are my notes.
He’s using Zend Framework at the moment but has done a lot of good Symfony work in the past
“Backend development” photo of a zoopeeper holding up a trash can to an elephant’s rump very nice.
John worked with the NHS for a while, they were using Excel spreadsheets for complex workflows, web apps were a big change for the better
A big fan of the admin generator: “it’s super awesome”
Provides most common admin requirements out of the box (CRUD: Create, Retrieve, Update, Delete actions to manage more or less any type of information)
Can be extended to meet bespoke needs
What’s new since 1.0? “Completely re-written for the form framework”
Hi folks, I’m attending Symfony Live 2010. These are my notes from Thomas Rabaix’s talk on internationalization in Symfony, with a few offhand remarks of my own.
Thomas Rabaix talk on internationalization
URL: routingModel: doctrine + propel
Form: sfForm
Most of the 18n is based on Prado framework
ICU data updated in sf1.3/sf1.4
You need
all:
.settings:
i18n: true
default_culture: en
Culture detection
HTTP request -> culture in URL
If no culture in URL, culture in session
What about culture in the header?
Updates sfRouting, sf18n, executes controller
We’re not big on culture in URL in apostrophe since the session can do it but it’s nice to be able to bookmark.
sfContext::getInstance()->getUser()->setCulture('fr')
Notify the user.change_culture event (this doesn’t do the changing, it just notifies other things that care; why doesn’t setCulture do this for us?)
recipe_esarch: url: /:sf_culture/recipe/view
Example: /en/recipes/search => sf_culture = en
After exceeding its 90-day mission by SEVEN. FREAKING. YEARS, the Spirit Mars rover is permanently stuck. So sad!
Yes, they plan to do some stationary science work with it when the winter is over, but let’s face it… this is the end.
Philadelphians, please join me tonight at 7pm at National Mechanics (*) to pour out a drop for our fallen robot homie!
To be followed, no doubt, by watching the State of the Union address. Which might even touch on space policy for once.
Let’s give Spirit a Viking funeral! (**)
(*) 3rd between Chestnut and Market if anybody doesn’t already know.
(**) Failure to get this joke is punishable by deportment to the Phobos reeducation camp.
Using svn for version control? Have lots of repositories you’re interested in? Maybe some of them aren’t under your control, so you can’t set up postcommit hooks?
Check out svncampfire (literally… haha, see what I did there). svncampfire pastes svn commit notices into your Campfire chatroom.
We’ve just released version 1.1, which supports the new official 37signals API for campfire. It’s a great API, much more fun than screenscraping; I chose the JSON flavor because it’s so darn easy. Version 1.1 also adds friendly labels for commits from each distinct repository so it’s easier to see what is going on.
Right now svncampfire is monitoring over half a dozen repositories for us, all thanks to the magic of svn log --xml.
Welcome to the P'unk Avenue Window, a blog with a view.
P'unk Avenue is Geoff DiMasi, Alex Gilbert, Rick Banister, Johnny Benson, Tom Boutell, Jake Hiller, and Dan Ordille.
