The Twelve-Factor App

I first heard about the twelve-factor app a couple of years ago, in Berlin, during the International PHP conference.  It was the basis for David Zulke (of Heroku fame) talk on the best practices for the modern day PHP applications.

The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

Here are the 12 factors, each one covered in detail on the site:

  1. Codebase: one codebase tracked in revision control, many deploys.
  2. Dependencies: explicitly declare and isolate dependencies.
  3. Config: store config in the environment.
  4. Backing services: treat backing services as attached resources.
  5. Build, release, run: strictly separate build and run stages.
  6. Processes: execute the app as one or more stateless processes.
  7. Port binding: export services via port binding.
  8. Concurrency: scale out via the process model.
  9. Disposability: maximize robustness with fast startup and graceful shutdown.
  10. Dev/prod parity: keep development, staging, and production as similar as possible.
  11. Logs: treat logs as event streams.
  12. Admin processes: run admin/management tasks as one-off processes.

These seem simple and straightforward, but in reality not always as easy to follow.  Regardless, these are a good goal to aim at.

How Do I Write Good Code?

Eric Dietrich, over at DaedTech, explains how he writes good code.  It’s a post worth a read in full, but here is a summary:

  • Make it easy to change
  • Make it really readable
  • Make it work
  • Make it elegant
  • Learn from accomplished practitioners

He is also listing a few books to learn from (the Amazon links are those of Eric – I have no idea if they are affiliated or not, but if they are, he’ll get the credit, like he deserves):

How to Age Gracefully

Found this video in Jason Kottke’s blog:

Good advice all around.  The best one is from the 93 year old:

Don’t listen to other people’s advice.  Nobody knows what the hell they are doing.

Which I’ve heard before in Joe Rogan’s stand up comedy:

You know as much about what life is all about as anybody who’s ever lived ever.

PHP tags – once and for all. Yet again.

For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:

If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

And from the comment on the same page:

Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.

For me personally, closing PHP tags are a part of muscle memory.  I’ll have to unlearn that, I guess.  And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>).  Apparently, I was wrong.  They are here to stay.  Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.