The conference is over, the hangover has subsided, so it's time to review my notes, resurrect the desire to write and apply that to a summary of what I thought about this years experience.
I probably won't manage to do this for every conference/event I attend, but it's a perfect excuse to write something which doesn't begin with <?php.
The venue is a great location for such an event - although it's understandable why there were problems getting late tickets as it was clearly close to or at capacity.
Below you'll find a brief summary for each of the presentations I attended from the conference schedule.
If you notice a gap - that's probably because I arrived late or was too busy socializing :).
I look forward to attending next year, assuming I'm still writing PHP code, but not necessarily because I enjoyed this year so much .
I did enjoy myself, and of particular interest the coffee this year was the right colour and did have some flavour :).
However mic. problems, low contrast slides (Fabien!) low voices and speaking quickly made for a strained experience in some of the presentations even before considering the content.
The presentations were varied in terms of topics but also quality; that said I applaud anyone willing to stand up and offer their work or ideas up for the scrutiny of others, and if you missed out this year plan ahead so you have the opportunity to attend next year.
PHP for Android: Scripting PHP en Android
Intrigued by the idea of how you can use PHP scripts with android, the conference got off to an excellent start for me with this introduction to the PHP for Android (PFA) project.
During the presentation I installed the project to my phone and had a play around - if you're familiar with PHP it really does look like you can whip up an app using the language you know in no time flat.
The downside is that to run it you or your intended users need to enable "Unknown Sources" and install, not via the market, the PHP For Android and the Android Scripting Environment (SL4A) apk-s.
Therefore, unless someone writes a tool to translate your PHP android scripts to native code - there doesn't seem to be much scope for building a userbase.
However, cool to play with nonetheless.
A new approach to object persistence in PHP
Tackling persistence is something I've investigated in the past, in various ways meaning e.g. the use of persistent models in CakePHP, multi-page processes which comprise a single database/financial transaction, and of course almost anything you can think of whereby you use the session, a cookie or the database to store some reference to state.
Stefan's presentation was quite interesting, but only seemed to hint at object persistent and simply focussed on some of the benefits of using MongoDB.
As someone who's quite familiar with using MongoDB I came away from this presentation entertained, but not enlightened.
Design patterns ... Revisited for PHP 5.3
PHP 5.3 grants, if you don't know already, a whole host of features which are not only cool, but actually useful.
Late static binding (LSB) is one of those things and something which you probably won't know what it'll do for you until you find yourself in a situation when you're the victim of PHP 5.2 and earlier not having it.
If you attended PHP Barcelona 2009 however, I think most of the content was covered in Fabien's presentation from that year (although that was a different topic, the content was iirc about the same).
PHP in Enterprise - Develop and Deploy Mission Critical Applications
Author: Kuassi Mensah
I quite liked this presentation, though I suspect most did not and the probability I will actually use Oracle for any web app in the foreseeable future is practically 0.
The highlights of the presentation were using database schema-and-data "editions" such that with a large scale rolling update you can upgrade your application with the confidence that users landing on a server running the old app see the right database structure and data, and those arriving at the newly updated code see the updated database structure and data - with the possibility for 2 way sync between database "editions" such that there is literally no downtime at all.
Possibly the most interesting features demonstrated to me, in part because emulating this with a behaviour would be not much effort, is that oracle gives you the opportunity to assign a client id (e.g. the logged in user id) to the current request and this is used in the sql query log - it's therefore possible to see exactly who is launching what queries.
Trying to figure out which of your users and their weird habits is managing to take down your server for minutes at a time? Oracles query logging is only an expensive bill away from telling you the answer.
Architecture and testability
Author: Giorgio Sironi
If your code is too hard or even impossible to test, change it.
The best way to avoid arriving at untestable code is to write with testing in mind, and write simple atomic code - These were the sentiments I agreed with from this presentation.
It's always a bit difficult to know from a presentation if the code examples given are intended to be taken literally or they are dumbed down to the point of being wrong for brevity; but some of the principles presented of what makes unstable code simply doesn't fit reality.
For example singletons are bad, avoid them because you can't test them - well, I beg to differ, in your testing environment you simply replace the singleton instance with something that fits your need.
Someone asked regarding the example of using the constructor for dependency injection what to do if you've got more than one dependency (the example was a car with an engine), I think the person asking was expecting to hear something like use a unified constructor, but that wasn't offered suggesting that if you've got 10 dependencies you've got a constructor with 10 args - can I think of a realistic PHP example of a class with 10 dependencies? No, before you ask ;).
Real time Communication Techniques with PHP
Short-polling is lame, long-polling is a necessary evil in the not-html5 world and websockets rule.
Scott did a great job of very quietly explaining the difference and that you need websockets if you want to really achieve anything online which is supposed to be realtime.
There's a handy demo on the waterspout server site demonstrating that websockets are not only awesome, but suck up like 1% of the bandwidth of traditional long polling techniques.
9 out of 10 sysadmins agree that web sockets are the way forward, and 9 out of 10 internet explorer and firefox users still don't know what they're missing out on.
APC & Memcached: the high performance duo
If you're not using APC, or some equivalent, you don't care about performance.
That, or you use plesk and curse your needlessly inefficient and insecure server on a daily basis - but that's another story.
As you probably know, APC has 2 main uses in PHP code - opcode caching and arbritary data caching.
Opcode caching is really a nobrainer, even in development I always run APC; I mean, why not - the worst that can happen is that it gives you no benefit, which would only be the case if you changed every file in your app on every page request.
One of the tips to pop up during the question and answer session, is that if you concatenate all of your file includes such that you're only including one file on can further increase the performance gains; good advice although not specific to APC and all the cool projects do this or should be.
One thing that surprised me regarding APC opcode caching is that Ilia advised against turning off the stat option stating that there's a possible 10% gain in performance and the OS is pretty good at caching the file access, and the cost/risk of the source files changing is quite high.
On this I don't necessarily agree - it makes sense to ensure the stat option is turned on if you're in development or your app files change regularly; however if you aren't or they don't or you have a sane deployment strategy (such as you copy/upload a complete app folder each time you deploy and http://example.com is a symlink pointing to the latest version's webroot folder) then you don't have the concern that the opcode cache can differ from your source file's contents.
Therefore even if the gain is marginal, 10% is 10% - I say flip that switch, at least to find out if you can.
The other use for APC has never really interested me much, that of an arbitrary data store.
Part of the reason for my disinterest were the reasons for caution presented by Ilia, the two most relevant being that if you're mixing in your data with your opcode cache - there's the possibility you'll end up constantly purging some of your opcode cache to make space for whatever data it is you're trying to add to the cache, and, if APC fails for some reason you've no caching at all as all the eggs are in one basket.
The second half of Ilia's presentation covered using memcached, not to be confused with the earlier version memcache.
I don't remember at what point it was mentioned but: Caching is easy, expiration is hard - and part of the changes-to-think-about I took away from this presentation was to review the expiration policy I use in MiCache class.
Adding things to a cache store is really easy, but quite often looking for things thereafter to delete them is (relatively) slow and inefficient.
It's therefore often a better idea to rely on you're cached data expiring or drop the whole cache store.
Typically I do the latter - something changes drop all data under a main data key, but this can cause several issues such as deleting data you've only just written and/or creating a run on the cache where parallel processes clamour to read and then write the same data to your empty cache store.
Some cool tips were presented on how to make efficient use of memcached which I'm sure most other people are already aware of such as using an atomic counter in the cache key so that you only ever insert into the cache, never update and therefore achieve faster writes.
Mondongo, un ODM para PHP y MongoDB
Mongo seems to feature in a lot of the presentations either directly or as an example of a schemaless data store.
Taken for the project website, MondonGO is a simple, poweful and ultra fast Object Document Mapper (ODM) for PHP and MongoDB.
Mondongo certainly seems to have a lot of functionality built in, but one of the things it most certainly is not is light - The MondonGO source, excluding tests etc weighs in at 300Kb, by contrast the CakePHP mongo datasource is about 50K.
If you're 100% certain your project is going to use mongo and mongo only for the rest of it's days - then I guess mondongo is an option you might consider, and if all else fails you can always watch the Rails envy guys from years ago and chukkle at your misfortune for choosing a db access class which will mean you need to change most of your code if you change db, instead of just changing a config option.
The other factor to consider, I guess, is that mondongo is almost a framework of its own, therefore if you're going to use it you're either choosing to use 2 frameworks, or not using a framework/structure in the first place - either way you're not likely to end up (IMO) with code you'll be happy to work with in the future.
In conclusion: The source code seems pretty well written, but IMO it's misdirected effort, either you build an ORM solution you can extend to a different datasource, or you write an adapter for an existing ORM/ODM to use mongodb.
Lemur framework for PHP
Authors: Javier Linares and Paulo Oliveira
For me this was one of the shortest presentations as at the start of the presentation, I downloaded the framework source skimmed the 10 or so files it contains and saw the word "global", which was enough for me - so I went to see if the Tuenti guys had survived the previous evening's "networking", they had - which was nice :).
Service Oriented Architecture: a good thing to do
I wasn't too sure what to make out of this presentation, Jan presented a few examples which eventually turned into examples of SOA, and also including a promotional video for his company NOS - the relevance of which escapes me.
Obviously NOS have some high traffic sites/services, and beyond coming away with the principle that SOA means, more or less, apply KISS to your overall application(s) architecture, and ensure they're loosely coupled so they can operate (and, more importantly from my perspective) be tested independently; I didn't come away with anything new.
The bottom line
Conferences are always beneficial, even if you don't necessarily agree with what you see/hear, it's an opportunity to see different ideas, provoke though, state opinions and make contacts.
Last year I really enjoyed the conference, in particular most of the presentations which were given by tuenti.com and covered scaling and performance issues most of us will only ever dream of actually achieving.
This year, the presentations seemed mostly to be pitched at a lower level - which was less interesting to see but perhaps more beneficial for your average attendee.
Organizing any kind of event isn't easy - I should know as I've done it before although not for a PHP audience.
It takes a lot of time and dedication to pull of a slick conference, and aside from a few hiccups - bravo to the organizers, they did a pretty cool job.
That said, of course there are things that can be improved such as announcing before tickets close when there are only a few tickets left and or having a fixed date for closing.
When the event has already started - to avoid problems with audio and presentation equipment (which was almost the norm, not the exception), when you sit in to check things are running OK I'd suggest sitting at the back where such simple problems are more obvious and can possibly be addressed.
Also, putting the most interesting talk (obviously that's subjective but standing-room-only is a bit of an indicator) in one of the 2 smaller rooms instead of the larger auditorium doesn't seem like such a good idea - although I expect the sponsors have something to say about which room they want to present in for their generous support :).
For the presenters it's a bit easier - because you've only got to think about the hour or so you're presenting - however a little prep work goes a long way.
Check your slides in the room you're presenting in before you present :), that'll prevent those "Oh no, it's not readable" errors which you could have corrected in 10 minutes from meaning only you can read the slides you're presenting.
If you rely on an internet connection - don't rely on the wifi in a busy conference if you can help it - I suspect the citilab wifi was running out of connections/IP addresses as for 15 minutes or more at a time it wasn't possible to connect to the wifi despite having a perfect signal.
Also, and I find it almost amusing that this isn't obvious, speak up and speak slowly - especially at an international (bilingual) conference - most of the presentations were in English but of course, being in Spain most of the attendees have English as their second or third language.
The same goes the other way around of course, if you're presenting in Spanish - don't assume the audience can read your slides at the same speed you can etc.
Checking that your presentation actually addresses whatever the title of your talk is is also another no brainer - some of the presentations on closer inspection didn't seem to have that much to do with their title.
So there you have it, bit ranty in places perhaps but my opinion of the 2010 Barcelona PHP conference in a few thousand words ;).