Here the notes I took during the Dutch PHP conference 2010 (#dpc10). They're not a representative summary of the event's highlights cause I could only attend 1 of 4 talks at any given time.

I also filtered out things that didn't interest me personally.

Conference Day 1 - June 11 2010

97 things every programmer should know - Kevlin Henney (@KevlinHenney)

  • Deliberately do non-productive work to improve your skills. Work outside your subset. You could have 6 years experience or, 12x 6 months if you do the same trick over & over.
  • Make tag-clouds of your project's code every build to see in which language domain you're coding. It's a good sign if you're seeing the subject of your project in the top list.
  • Compare technical debt to sprinting in a 10km run. Only do if you have time to recover afterwards.
  • Software really is soft and open to speculation. Tests are what ground it.

Designing for Reusability - Derick Rethans (@derickr)

  • Reusability is good, but you can over-abstract. The hammer-factory-factory-factory example.
  • Splitting out code in more methods makes it much easier to extend & test them. If you don't succeed, try test-driven development.
  • PHP 5.4(?) Traits is basically compiler assisted copy-pasting. You can "use Classname;" to base a class on multiple others.

Technical Debt - Elizabeth Naramore (@ElizabethN)

Why? sonar will show you the technical debt in $$. Great for managers to realize how important it is to refactor.

  • Visibility is key. Technical debt issues should go into your bug tracker / todo list
  • Kevlin Henney (@KevlinHenney) mentions: Put every debt issue up on a wall. There's a physical satisfaction in taking them down. Also, with software tools it's too easy to fold it away.

The art of Scalability - Lorenzo Alberton (@lorenzoalberton)

  • Always think of concepts instead of solutions, it will make it easier to switch in architecture.
  • Build monitoring into your app. Not just around it.
  • Common mistake in logging: Never log more than you can process in real time. Signal to Noise ratio.

Database version control without pain - Harrie Verveer (@harrieverveer)

You could use Patch-files (patch-001.sql) for shipping changes (deltas)

  • A good idea is to also UPDATE options SET value = 1 WHERE key = 'db_patch_level' This way, you know from which point your DB still needs patches.
  • Never modify a patch-file once it's under version control. When you commit a mistake in a patch. You'll need another one to fix it.
  • Use separate .sql files for content
  • Process by hand is tedious. Automate it: Tiny script that reads DB version, then iterates over necessary patches. Maybe run it right after every git pull.

Downsides of patching:

  • Branching can get hairy. What to do with 2 different files called: patch-004.sqls.
  • You can use date-stamps, but then you'd have to keep a log. And you still don't know if it will fit in between the other branch's patches
  • A false sense of security

So to really nail database versioning, you're better off using tools.

  • Dbdeploy: pear install phing (Phing comes with Dbdeploy)
  • Liquibase: Knows what's happening cause definitions are in XML not SQL. So no undo files needed. Massive DB support. Great docs. XML :(
  • Akrabat: If you use ZF, check it on github
  • Doctrine: Great migrations, but only if you already use Doctrine ORM (a layer between app & db. Update doctrine objects, and it will update your DB accordingly)
  • CakePHP Migrations: Not mentioned in the talk, but of course there is Cake Migrations by CakeDC

Testing untestable code - Stephan Hochdoerfer (@shochdoerfer)

3 factors to untestable code:

  • Hardcoded dependencies
  • Global state / variables. Also applies to singletons & registries
  • Communication with external sources

You'd want to refactor the legacy stuff, but without tests first you'll only introduce more bugs. So, we really need tests before refactoring and you'll have to defeat the the 3 factors that make code untestable. You could use UI testing with e.g. selenium but the UI won't expose all code. Desperate times call for desperate measures; Here are some dirty tricks that let you mock dependencies, fake filesystems, and override internal functions as to safely test untestable code.

  • Have the code load dependencies from ./custom/mock/ by overriding __autoload() or include_path
  • Even freakier: stream_wrapper_register() your own file stream and have it return mocked files
  • You can mock a filesystem with vfsStream
  • PHPUnit can setup & teardown any global state that's required
  • unload e.g. the mysql.so extension and write your own mysql_query() functions
  • Overriding internal PHP functions like mail() is harder but not impossible. Use classkit to runkit_function_redefine() it

Crash, Burn, Recover! - Cal Evans (@calevans)

Running late, I picked room by by speaker & title without having read the intro. Turned out to be a live session on Adobe Flex. Maybe not my first choice but I decided stay and keep an open mind.

Adobe did good to recruit Cal, his enthusiasm is contagious. Still: Flash, heavily namespaced XML, Eclipse. It's all a bit to closed, bloated & slow for my taste. The resulting program (a desktop recipe browser using a webservice) could have just as easily been built in Capucinno (yes, even as native app, checkout github issues) and then It'd just be HTML & JS.

So sorry Cal, but I won't be needing one of those free licenses you were handing out.

Conference Day 2 - June 12 2010

Security Centered Design - Chris Shiftlett (@shiftlett)

Chris is a great speaker and today was no different. Nothing too technical, but overall a very inspiring talk on shortcomings in the human mind, and how that can cause unforeseen security risks. Great start of the day.

  • Change blindness can happen when there's just a small (loading) gap between pages, caused by your brain continuously flushing a great deal of data. Ajax can help counter that.
  • Don't try to modify your users expectations and tendencies, meet them. Not because you're so nice, but because you're lazy. "Pave the cowpath".
  • Never be arrogant about security, you're only going to attract more & more people wanting to knock you down.

Real world dependency injection - Stephan Hochdoerfer (@shochdoerfer)

  • "new" is the new evil. Try not to instantiate classes from within classes
  • pass dependencies on construction
  • Use a Container class to inject Dependencies into the Consumer
  • Make injection configurable externally (like json/xml/php file). You don't have to touch the code to alter the behavior at all

Embracing Constraints with CouchDB - David Zuelke (@dzuelke)

Turned out to be more of an introduction than I was hoping for. Much like @jchris' talk at Kings of Code last year but with less Hovercrafts in the slides :) More 'your mom' jokes though. Some points that were made:

  • CouchDB is not always awesome. Any data that is tabular or relational is better of with a relational DB.
  • CAP is the triangle between Consistency, Availability, Partition tolerance. You can only have 2 and Couch offers: Availability & Partition tolerance. CouchDB isn't inconsistent, it's eventually consistent. However, your mom is inconsistent.
  • Tool: rlwrap http_console is a great way of talking to HTTP servers.
  • Couch works well with Lucene. Use it for complex querying.

One interesting use case was storing XML documents. Every sub-root-level tag would just be a json-key in your DB. It would allow you to link & search on XML tag contents without parsing the entire thing every time.

Iphone Apps in HTML5 - Thorsten Rinne

  • Webkit does HTML5 so we get things like: video tags, CSS3 text shadows, local storage.
  • We can style an iPhone app with jQuery: jqTouch
  • Phonegap packs HTML pages as apps. unlocks iPhone features like: geolocation, contacts, and vibrate with a simple JavaScript API.
  • Phonegap can be forked and they'll accept your patches
  • Phonegap already has approval from Apple; objective-c & javascript is allowed.
  • You need: xcode, iPhone SDK, $99 / year fee to AppStore
  • Titanium is an alternative to Phonegap. but with less platforms supported

PHP Code Review - Sebastian Bergmann (@s_bergmann)

  • It's better to have a tool tell you your code is bad, than a person
  • toolbased reviews: Review Board, Atlassion Crucible (commercial)
  • phploc analyzes code complexity and such
  • pdepend generates a pyramid png of metrics & dependencies
  • coderank is like pagerank but for code
  • phpcs now support more sniffs than just formatting: bug patterns, unintentional things, performance, patterns
  • phpcpd detects duplicate code
  • Read the Refactoring book by Martin Fowler!

The Future of PHP - Scott MacVicar (@scottmac), Sebastian Bergmann (@s_bergmann), Matthew Weier O'Phinney (@weierophinney)

  • Zend Framework 2 is going to be namespaced
  • Frameworks are starting to use the same standards: code conventions, namespaces, phpunit, making it much easier to exchange components.
  • No "PHP 7 Ultimate Edition", 5.3.999 contains all the nitty gritty now (scalar type hinting, traits, unicode safe string functions, dtrace). A new version name will be decided on later.
  • xhprof is performance profiling that's ok to run in production.
  • It takes hiphop 400 CPUs to compile Facebook's code in 16 minutes.
  • Find a good tutorial, and solve 1 real world problem in another language. Screw hello world.

Concluding

As far as best practices I didn't hear a lot of new stuff, but it's always good to hear more speakers command you to obey them :)

I was especially pleased with some tools I came to know (mostly in @s_bergmann's talk), and @shochdoerfer's sledgehammer approach to defeat untestable legacy code.

Thorsten Rinne's iPhone talk in the Unconference Room (@dpc_uncon) was refreshing & I definitely need to get my hands dirty with that.

All in all a pretty good conference and I look forward to reading up on all the talks I couldn't attend.

What's the coolest thing you picked up at the DPC, or another recent conference?