Tag Archives: phparch

PHPArch CodeWorks 2012 – Boca Raton

Just as I did with the CakeFest I will be publishing this as we go.

Started bad, ok, not their fault but: no wifi + no outlets (there are, just far hehe) = geek torture ūüėõ

Building APIs with Silex – Cal Evans @calevans

– github: https://github.com/calevans/scanjobs

The MicroPHP Manifesto – funkatron.com/posts/the-microphp-manifesto.html
Рthe point is that at the moment you get a big framework you also assume the liability of all of the rest of the framework even when you only need pieces of it.

Silex is not a micro-framework and is good for prototyping (uses anonymous functions – ah ok … I dont mind)¬†and to construct apis.

Note: search for foxycart.com – interesting concept – the api will be built using silex

Silex is not good for if you need to build a full mvc application (view layer, etc) Рyou better off building things with Symphony 2 (go CakePHP 2.2 you better off)

Introduction to Composer

  • it is not PEAR
  • creating the composer.json
  • used to install your application and it’s dependencies
  • the best of it is that it uses psr-0 namespaces and with a small script you can deploy¬†a full application with all dependencies with little or no effort.
  • the json example displayed has no more than 100 lines of code
  • if you use git, add the vendor directory to your repo and the composer.json (for some open sources projects the composer.json is now required to be a part of it)

Sample Application Structure

  • better to be seen on the slides, but point is that silex¬†doesn’t¬†mind about the structure at all


  • He point’s out a copule of good things, but the best is still the point of using DRY (dont repeat yourself)
  • LOL – it is funny to see someone that remembers the good old PHP 3.2 and PHP 4 best¬†practices and how good those are not necessary anymore (replaced by bootstrap and autoloaders)

The CLI Dispatch Script

  • app/console.sh
  • where the bootstrap will be included
  • the db connection is registered in the dispatch script
  • Why the CLI
    • Code Reuse
    • Utility Scripts
    • Creating¬†commands

Work Command

  • app/applicationanme/Command/WorkCommand.php
  • it is a class that extends the Command parent class
  • has a main method that executes the process

The Example API

  • has only one route that does not returns a json
  • mostly backend
  • several ways to create an API in Silex
    • ->get(), ->post(), ->delete(), ->update() : the method is named as update, but fact the correct name for it is PUT
  • routes
    • $app->get(‘/info’, function () { phpinfo(); });
    • $app->post(‘/info’, function () { phpinfo(); });
    • $app->put(‘/info’, function () { phpinfo(); });
    • $app->delete(‘/info’, function () { phpinfo(); });
    • or you can do it as
    • $app->match(‘/info’, function() { phpinfo(); })
    • or you can do the above¬†specifying¬†different¬†functions to different methods. Regardless it keeps the code very dry.
  • route variables: very simple -> $app->match(‘/helloworld/{variableName}’)
  • The mount should be only for the ‘/’ and the controller handles the rest. @calevans is creating multiple mounts so he can group. In perspective is not so bad idea – follows a bit of the¬†concept¬†of PHPUnit, still is not the standard for Silex
  • A lot of code now that will be very hard to publish here on the fly, so get the slides or go to the github repo that I have posted above

Usability for Developers – Beth Tucker

It is kind of strange seeing things about design and usability but fact is at some point we will be a full stack developer for one reason or another so we might  as well learn. In my case I have been a full stack developer (with poor front end) so will be good to revisit.

  • Usability means structuring things so you don’t leave your users angry,¬†frustrated¬†and¬†complaining¬†about you on Facebook or Twitter (loved this)
  • If is hard, people will not stay on your side
  • you want to know where the users will go if the site is too hard
  • How to test
    • create a persona
    • create a list of the most common procedures or tasks on your site
    • identify the success criteria
    • talk with users and give them one task at time
  • What to test
    • old design
    • competitor websites
    • popular sites
    • proposed site
  • Design Stages
    • create
    • test on users
    • improve
    • test again
    • improve
    • more tests users
    • put all above in a while (1 == true) – ok bad joke ūüėõ
  • After ¬†you have a design, points to see and consider:
    • Learnability
    • Efficiency
    • Memorability
    • Errors (not a site errors, but users errors)
    • Satisfaction
  • Common problems
    • know your users and know that you are not the users
    • no overwhelm (who reads the terms and conditions – truly?)
    • consistency (users are creates of habit – use the same patterns all over the place so they dont need to think about too much)
    • minimize the need of memory (make the user know what problems to fix prior re-submitting¬†a form)
  • A good point, and this goes back to backend as well, is that the user should be able to have to power to control the system. If the user made a mistake and typed the username wrong, the user should, with the correct conditions to update the username or any other information that he believes is necessary.
  • This is actually giving me some ideas for changing my http://mcloide.com design ūüėÄ
  • LOL unicorn puke – bunch of color in links all over the places -> don’t use it (off course)
  • Add as much information as the user need to know and user their language to inform the user. Try to keep things simple. For example, if you are buying a pizza, the 1st info you would like to know is: how many people it feeds (along with the slice number)
  • Some example sites where all I can say is – OMG – and I believed that my site was bad (loved the blinking block of text – ROTFL)
  • A lot of audience input on this presentation
  • https://joind.in/7092
  • @e3betht


API’s for the REST of us (Engine Yard) – Davey Shafik – @dshafik

  • Legacy code – everybody did at some point maitened a crapy legacy code
  • 3 R’s of development
  • Frapi (www.getfrapi.com)
    • Super fast router with custom url parameters (/a/:collection/:resource_id)
    • action support 5 HTTP methods (get, post, put, delete, head)
    • Content negociation
      • respect a-values – if the queue value is application/json, Frapi will respond with application/json content
    • custom minetypes and you can also use custom params just as you would on a route
    • supports the standard minetype params
    • Abstracts input ($this->getParam(‘name’))
    • Abstracts output (PHP object, array or serialized, json, json-p, xml, CLI and html)
    • Admin inferface to manage actions, minetypes, outputs, etc (dont deploy the admin to production as a¬†recommendation)
  • Using Frapi
    • Add actions, routes, etc and the sync button will generate the classes for you
  • Documentation – pretty simple and generates a good overview of it from the info you added

Making the API’s work for you

Legacy code is painful to maintain but you can write API’s to expose new and current functionality to work for you and all together get rid of the legacy code with a better and new improved flexible code.

  • Model
  • Business Logic
  • Libraries
  • etc

Best practices

  • API’s should be like URI’s, permanent
  • Dont let bad legacy decision drive new development – pretend that your API is a re-write
  • Refactor your app to use your API and not the legacy code and then make the API’s better by refactor the underlying implementation of your APIs to migrate away from legacy code
  • Unit test and Integration tests. Frisby.js is a great BDD integration testing system (I liked this a lot, so far the simplest of the BDD’s I have seen so far)
  • Rewrite – have a separation of concerns via SOA so you can rewrite piecemeal. By this step, all your legacy code should be gone.
  • Testing – Unit and Integration testing (BDD) – a way to ensure that your API wont break the client and it conforms to your design

@lunch – my battery is dying so I will stop here and get back in the afternoon with the rest of the conference (and hopefully a full bat)

Building Rock Solid PHP Applications – Pablo Godel


It is a critical part of any application. Should be predictable and the more you do it, the better it goes (true). A good deployment also means more time for fun.

Goals for deployment

  • one click deploy
  • continuous¬†deploys
  • Deployment¬†has¬†different¬†perspectives on how to do it, but in general you should not be afraid of doing a deployment.
  • Should be done from anywhere and by anyone, not tied to a person or a group.
  • Reliable
  • Rollbacks easily with no pain (yeah sh**) happens
  • No downtime
  • Reusable
  • Scalable
  • -> interesting so far we are talking about deployments, but it really seems that we are talking about an APP

Deployment facts

  • Starts with development so the dev environment should be as close from production as possible so bugs and errors can be predicted (vagrant)
  • success is linked to the OS setup
  • monitoring uptime

Deployment Methodologies

Doesn’t matter how you do it, but you should be doing something that can be stable and scalable. Specialized tools is usually a good option. Tools like Fabric, Capistrano or Source Control tools like Git, SVN.

Deployment – 1st time

  • copy files
  • set server side config
  • load db fixtures
  • process and install assets
  • warm up cache
  • “enable” site

Deployment – subsequent times

  • copy files
  • apply db updates
  • process and install assets
  • etc

Hence they are about the same: automate.

Scalability is also a good point. Any deployment should be able to handle 1 to N servers.

Avoid Rollbacks as much as you can.

Finally, security – please don’t store passwords on source control and use SSH connections any time you can.

Quick end note: For static assets, like JS and CSS, using YUICompress, enabling server compression and adding versioning to your static assets, should be able to completely clear all issues with static assets. Testing the same process locally or on staging should give the same result as production, so test always.

Some tools

  • statsd and graphite
  • logstash
  • graylog
  • kibana
  • fpm

Clean application development – Adam Culp @adamculp

  • http://joind.in/7099
  • Learning anything takes time, requires training and nobody¬†succeeds¬†instantly
  • Books: Clean Code and Refactoring
  • The better the code, the less debugging needed
  • Writing bad code is easy (doesn’t matter the excuse) and fact is, no-one will get back to work a dirty code
  • Bad code is a developer fault – if there was no time to deliver it, he should say it cant be done (hmm where have I seen this before)
  • Bad code generates a domino effect and the worst, we will be judged by – other devs read’s your code (just think about code reviews)
  • The way to fix is: rewrite – get out of the defensive and stop the blaming, rewrite.
  • How to spot bad code – it stinks dont worry

In short a bad code, written for whatever reason, applies in a bigger time for fixing and more costs, so avoiding it is a better process all together. Apply the common sense rule: Mesure twice and code once.

I loved this quote from Adam Culp: “Our job is to defend the code. Our job is to say no!” Even more when the project cannot be delivered in a reasonable time.

Some guides / tools to help

  • coding standard
  • PHP Framework Interoperability Group (www.php-fig.org)
  • PSR’s
  • PHP Frameworks that can be used as a coding standard

Clear Architecture

  • Just like real life architecture you should be able to figure out what you are looking at with no problem or little or no ¬†effort
  • Current architecture – MVC – if you dont understand it, read about it – the cakephp framework shows a good “design” about how to structure the code for a good MVC or how the call it – good cake

Some guidelines

  • Comments usually are used for cover bad code
  • code should be self-documenting – by reading it you should know what it does
  • use code sniffer (oh yeah)
  • peer code review (not a pleasant thing but necessary)
  • unit testing (PHPUnit) – make it a habit ¬†(agreed)
  • if tests are goog there is very little for QA to find
  • adding to Adam presentation – also use BDD tests – jasmine is a good source
  • LOL one of the best images I have seen so far in any presentation (elephant end) – gonna see if I can get this presentation to share it
  • put QA at the¬†beginning¬†of the process instead of the end
  • remember that your code will be read more times that it will be written so keep it clear, simple and meaningful
  • off course, use Agile ¬†– even if you are a 1 developer team. Reason is you kill the hopes and start giving real expectations to your “clients”

Responsive Web Design – The Mobile web and you – Arbi Arzoumani – @arzoum

  • The goal is not making you a designer but giving you the tools to build a responsive web design
  • why responsive: 158.3 million smartphones shipped in 1st quarter of 2012 – by 2014 there will be more smartphones than desktops
  • responsive web design allows your users to quickly view the important parts .. (there is more, missed, will add it later)
  • 2 philosophies – responsive layout or adaptive layout (hybrid)
  • it is a philosophy and a development strategy (go Twitter Bootstrap!)
  • done right the same site can be seen in every device, from pc to mobile

Media queries

  • media types: all, print and screen – the ones that matters
  • 3 ways to implement – inline , style tag and link
  • but media types aren’t enough – what if you need to target a specific “handheld”?

Media query features

  • width / height – different from a desktop and mobile – on mobile use device-width and device-height
  • viewport is the window of the browser – it is not a standard but Apple supports it and is used on mobile devices. It is used to scale and render the web pages on smartphones. It creates a virtual screen to fit the webpage on a mobile screen.
  • there is a great slide with some math to show how the viewport is really calculated – in short all is scaled down including fonts.
  • an example of the viewport tag was shown and no need to say that all my apps are using it wrongly :S
  • The Boston Globe has a responsive website with 4 break points – great visualization.
  • Compatibility can be adjusted with (grump IE):
  • do not use a fixed layout – several small issues that can easily affect your users in different devices
  • Typical RWD layouts
    • fluid (%) => target √∑¬†content = result
    • column drop (bostom globe) =>
    • layout shifts
    • off canvas flyouts
  • Before of choosing a layout, define the site goal, audience, etc
  • ¬†The same math used on the fluid grid, can be used for typography
    • use EM instead of PX and PT
    • always use font size of 100% for body
    • before h1 { font-size: 50px; } -> after h1 { font-size: 3.125em } = 50px / 16px – this will automatically adjust to the users viewport / browser window
  • Flexible images / media
    • from desktop to mobile things can go wrong badly
    • quick fix – max-width (yeah, doesn’t work on IE)
    • for IE http://unstoppablerobotninja.com/entry/fluid-images/ – small shop
    • for bigger shops, a whole bunch of JQuery tools, but images should be cached with different sizes on backend
    • all in one solution – Twitter Bootstrap – you got love this tool
  • use @less for css
  • Quite fun to see the Twitter bootstrap being used as a live demo for responsive web design. Aslo very good to see that you might be using it wrongly. Take a look on the fluid math above and see if your current way to place the layout matches that.
  • Awesome examples of responsive websites
  • nice tool: Bootsnipp – can be used in conjunction with bootstrap
  • Testing:
  • SHIM (yeah, IE need’s it)
  • Some latest notes:
    • Content is everything – Information Architecture
    • Google “Mobile First”
    • Know your resolution break-points
  • RWD is not good for
    • e-commerce
    • custom app
    • context driven websites
  • Be Responsive be like Water – a quote from Bruce Lee was place at. Interesting how it matches the responsive design

All about mobile development

For everyone that is crazy about mobile development, the issue of March 2010 of the PHPArch Magazine, a great article holds great information about advanced development with WURFL, one of the best methods of mobile device detection that is available.

Excellent reading: http://www.phparch.com/magazine/2010/march/

PHPArch Free Webcast – new recordings released

PHPArch has released more webcasts recordings on their website and they are also offering a free edition of the PHP Architech magazine.

More @ PHPArch.com

Here is the list of the webcasts:

Date Speaker Title Signup
Jun 26 Matthew Turland New SPL Features in PHP 5.3 Recording
Jul 10 Sumit Chawla Connecting PHP to Microsoft Technologies Recording
Jul 24 M. Weier O’Phinney Play-doh: Towards Better Object Modeling Recording
Jul 31 Stefan Priebsch Migrating to PHP 5.3 Recording
Aug 14 Scott MacVicar The Future of PDO
Aug 21 Hank Janssen

Zach Owens

Running PHP on Windows
Aug 28 Derick Rethans PHP Date and Time Programming Recording
Sep 4 Cal Evans Zend Framework Piece by Piece Recording
Sep 11 Andrei Zmievski What’s New in PHP 6.0
Sep 18 Vijay Rajagopalan Running PHP on Azure Register

New resources

Happy Friday everybody ….

2 New resources for you to check out:

  1. Javascript Bookmarklets
  2. Zend Framework and Firebug – Log PHP warning, errors and exceptions

Don’t forget also of the PHPArch Free Webcast today about Running PHP on Windows with Hank Jansen and Zack Owens.

Have fun .. .

PHPArch Free 1st Webcast – Codeworks 2009 – Video

PHPArchitect released the video for the 1st free webcast – New SPL Features in PHP 5.3 and the link is bellow so you can check it out.


The video is pretty good and you will be able to check out some good benchmarks about the new SPL library from PHP 5.

The next webcast will be this next Friday, July 10th, so do your registration for the newcast with Sumit Chawla talking about Connecting PHP to Microsoft Technologies.

%d bloggers like this: