Building from the Ground Up


Published on

A discussion about PHP Frameworks. A look at some common frameworks and considerations you need to take into consideration when building your own from scratch.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building from the Ground Up

  1. 1. BUILDING  FROM  THE  GROUND  UP  (can  has  framewerk?)  
  2. 2. Thanks  for  coming.  It  makes  me  happy.  •  Bob  Majdak  Jr,  24  •  Developing  using  PHP   since  1998ish.  •  C,  PHP,  lots  of  Lme   spent  on  PHP-­‐GTK.  •  KateOS  •  That  is  my  cat.   –  her  name  is  Sally.  
  3. 3. PresentaLon  Overview  •  Why  do  we  use  frameworks?  •  Cover  some  popular  frameworks  quickly.  •  Ponder  project  development  requirements.  •  Contemplate  the  implicaLons  of  building  our   own  framework.  •  Look  at  applicaLon  aspects  criLcal  to  reusable   frameworks.  
  4. 4. WHY  FRAMEWORKS?  (the  answer  is  not  “because”  but  i  find  your  guess  acceptable)  
  5. 5. Good  JusLficaLon  of  Frameworks  •  Prototype  applicaLons  •  Jumpstart  applicaLon   development  •  Consistent  applicaLon   structure  •  Repeatable  applicaLon   deployment  •  Shareable  without  much   addiLonal  documentaLon   required  
  6. 6. Not  Good  JusLficaLons...  •  Just  to  say  “Built  with   _________”  •  Just  to  sLck  a  logo  on   your  page  •  Just  to  add  a  buzz  word  to   your  résumé   –  any  other  excuses  to  try  to   sound  cool  •  To  get  around  having  to   think  for  yourself   –  does  not  work  well,  tried   that  
  7. 7. THE  POPULAR  GUYS  OF  MVC  (MVC  as  far  as  I  can  see...)  
  8. 8. Models  Views  and  Controllers,  Oh  My.  
  9. 9. Some  Popular  MVC  Frameworks  Finite  list  of  Infinity   Model  View  Controller  •  CodeIgniter  •  CakePHP  •  Zend  Framework  •  Yii  •  Solar  •  Symfony  •  ...  and  more!   -­‐  image  from  Wikipedia  on  MVC  •  ...  yarly.  
  10. 10. THE  OTHER  GUYS  (MVC  minus  one  or  two  of  the  lecers,  or  random  one  of  your  choice)  
  11. 11. Some  Popular  Standing  Frameworks  Hard  to  build  list  of  Rares   Random  Process  •  Smarty  •  Seagull  •  Qcodo  •  Wordpress  •  zenthis   -­‐  image  also  from  Wikipedia  on  Flowcharts  
  12. 12. SO  WHAT  SHOULD  WE  DO?  (all  senior  officers  to  the  observaLon  lounge)  
  13. 13. Ponderings  of  a  Project  Lead  •  Deadlines?  •  Project  Goals?  •  Survivability!  •  Performance...  •  Security.  
  14. 14. Choosing  a  Framework  •  Does  it  do  what  we   need?   –  Libraries   –  Engines   –  CompaLble  with  current   codebase?  •  DocumentaLon  would   be  nice...  
  15. 15. hey  bob,  GO  AND  SHOW  THE  DEMOS  NOW  
  16. 16. Should  we  build  our  own  system?  •  ExisLng  systems  may  not  do  what  we  want.   –  Template  Engine?   –  Database  Management?   –  File  upload  management?   –  Plahorm  detecLon?  •  ExisLng  systems  may  not  do  it  how  we  want.   –  Some  crazy  implementaLon  of  a  feature  only  a  manager   would  design?   –  “Just  dont  like  it”  •  Other  systems  exist,  but  the  only  person  who  knows   how  to  use  it  is  the  kid  who  built  it  for  a  class  project   three  years  ago.  
  17. 17. SLll  thinking  about  it...  •  EvaluaLon  Lme.   – Do  I  have  Lme  to  test  10  frameworks  for   requirements?  •  Development  Lme,  do  we  have  that  too?  •  LEARNING  TIME,  just  incase  we  don’t  know  how?   – Learning  the  Framework  codebase.   •  pro  with  one  already,  or  no?   •  Rapid  ApplicaLon  Development  is  a  joke  if  you  do  not  know   anything  about  the  codebase  you  are  about  to  dive  into.   – Learning  what  we  would  have  to  do  if  we  did  it   ourselves.  
  18. 18. Alright...  lets  do  it.  
  19. 19. HARD  MODE  ENGAGED  (moar  dots!  moar  dots  or  50  dkp  minus!)  
  20. 20. Quick  notes  about  fresh  builds  •  Does  not  mean  you  have  to  write  every  line  of   code  yourself.   – Examples:   •  Need  RSS?  Grab  a  library  like  SimplePie.   •  Need  a  newslecer  manager?  Things  like  Mailchimp  and   Constant  Contact  have  APIs  and  libraries.   •  Need  a  blog?  Grab  Wordpress.   – (lol  joke)   – (unless  you  really  need  a  blog  oriented  site,  I  can  do  a   Wordpress  hax  talk  at  a  later  date)  
  21. 21. SuggesLons  for  the  Modern  Age  •  Drop  legacy  support.   –  For  reals.   –  Bloat?   –  Held  back?  •  Shoot  for  modern   standards.   –  I  heard  namespaces  are   precy  neat-­‐o   –  Lower  development   costs  overall?  Perhaps.  
  22. 22. Lets  go,  this  way...  •  What  am  I  building?  •  Why  am  I  building  it?  •  What  is  already  done  for   me?  •  How  much  do  I  care   about  supporLng   plahorms  different  than   mine?  •  Do  I  plan  to  release  this   for  others  to  use?   –  DocumentaLon?   –  License?  
  23. 23. ...  and  then  that  way.  •  Structure  and  Style  •  Input  Handling  •  Databases  •  TemplaLng  •  ULliLes  •  Plahorm  DetecLon  •  CLI/Cron  support  •  AddiLonal  PHP  module   support   –  APC   –  Memcached   –  etc.  •  Third  party  library  support.   –  Use  them,  they  save  you  Lme   too.  
  24. 24. Thinking  about  Structure/Style  •  Think  long  and  hard  about  the  programming  styles  you   wish  to  use.   –  procedural  straight  (quick  apps)   –  object  oriented  (large  thought-­‐out  apps)   –  that  half/half  style  where  classes  get  used  as  namespaces  more   than  defining  instances.   •  outdated  thanks  to  namespaces  in  PHP  5.3  •  Don’t  be  afraid  to  change  things  later.   –  Refactoring  a  custom  library  and  then  updaLng  4  projects  using   it  in  the  end  will  feel  a  lot  becer  than  dealing  with  a  bad  library   for  eternity.   –  Defeats  part  of  the  purpose  of  building  your  own  framework  if   you  just  deal  with  something  you  do  not  like  rather  than  fixing   it.  
  25. 25. Thinking  about  Input  Handling  •  Init  Intercept?   –  Wordpress  does  this.  Kind  of   annoying.   –  But  saves  you  from  the  new   guy  in  the  accounLng   department  from  leaving  an   SQL  injecLon  opportunity   open  for  you.  •  MulLple  input  management   class?   –  Makes  code  precy  fun   someLmes.  •  Database  class  level  last-­‐ minute-­‐huzzah.   –  Details  about  that  later.  
  26. 26. Example  of  Input  Management  Class  •  $get  =  new  input(‘get’);  •  $name  =  $get-­‐>name;   – what  makes  an  idea  like  this  magical:   •  __get(),  __set(),  literally  the  magic  methods  of  classes.   •  Care  must  be  taken  for  invalid  characters  (if  doing  the  object   approach)   •  The  __get()  method  can  automaLcally  saniLze  your  data  for   you  right  there.     •  The  __get()  can  also  do  your  array_key_exists()  for  you  and   return  a  default  value,  like  if  you  want  all  missing  data  to  be   an  actual  null,  or  boolean  false.   – Want  to  see  an  example  of  one  I  was  working  on?   •  It  is  an  idea  I  had  and  also  have  been  pondering  the  uLlity  of.  
  27. 27. Thinking  about  Databases  •  Database  plahorms.   –  MySQL   –  PostgreSQL   –  SQLite   –  many  more...  •  PDO?   –  Yes  no  maybe  so...  •  Global  Instances?  Local   Instances?  Smart   Instances?    
  28. 28. Database  Instances  •  Global  Instances   –  Manages  a  single  database  connecLon  alright,  mulLples  can  become   tricky,  but  it  is  easily  accessible  throughout  any  scope.  Generally  auto   connecLng  at  script  init.   –  $result  =  database::query(‘SELECT  ...’);  •  Local  Instances   –  Manages  single  and  mulLple  database  connecLons  with  ease,   inefficient  with  connecLons/disconnecLons  mulLple  Lmes  in  scripts.   –  $db  =  new  database;   –  $result  =  $db-­‐>query(‘SELECT  ...’);  •  Smart  Instances   –  Work  like  local  instances,  but  they  have  a  global  class  scope  managing   DB  connecLon  instances  so  if  you  ask  for  the  same  DB  again  it  uses  the   exisLng  connecLon  instead  of  making  a  fresh  one  for  each  “new   database()”  call   –  Not  talking  about  persistent  connecLons  in  this  case.  
  29. 29. That  dirty  old  problem  that  sLll  exists...  •  Protect  yourself  from  SQL  InjecLon  in  your   database  library.  •  It  is  your  last  line  of  defense  against  the  dumb.   – Never  assume  your  data  was  saniLzed  before  your   query.  KNOW  it  was,  or  raise  shields  to  maximum.   There  really  are  klingons  on  the  starboard  bow.  •  $db-­‐>queryf(‘INSERT  INTO  table  (id,name)   VALUES  %d,”%s”;’,  $id,  $name);   – Our  DB  object  will  then  use  the  string  escape  method   of  our  DB  of  choice  automagically  on  each  argument   passed  in.  
  30. 30. Thinking  about  TemplaLng  •  Is  the  disconnecLon   between  designer  and   programmer  such  a  huge   gap  that  pseudo  markup  is   required?  Because...  •  The  best  template  engine  is   PHP  itself.  •  Managing  SEO  features  of   pages.  •  Leverage  template   customizaLon  with  CSS   when  possible.  •  Template  engines  can  get   bulky  really  fast.  
  31. 31. TemplaLng  Types  •  Pseudo  markup  vs.  PHP   – <h1>{arLcle_Ltle}</h1>   •  Requires  two  more  more  “passes”:  Regular  expression   matching  and  string  subsLtuLon.  Think  about  internal   memory  management  that  is  being  done  automaLcally   for  you.   •  Advantage,  PHPless  people  can  make  your  templates.   – <h1><?php  echo  $arLcle_Ltle  ?></h1>   •  Single  pass:  evaluaLon.   •  Advantage,  PHP  is  doing  its  job  for  once.  Tee  Hee.  
  32. 32. Managing  SEO  in  Template  Engines  •  Special  fields  in  template  class:   – page  Ltle   – keywords/tags  describing  the  page   – textual  descripLon  of  the  page  •  Then  have  your  template  engine  insert  these  in   the  template  for  you.   – default  to  sitewide  values  if  specific  page  has  no   specific  values   – auto  append  site  name  to  page  Ltle  in  the  address  bar  
  33. 33. Thinking  about  ULliLes  •  ULlity  libraries  are  what   make  Frameworks  go.   Well,  they  help  at  least.  •  These  do  your  silly  things   like  convert  date  formats,   chop  strings  and  add   ellipsis  at  the  ends,  etc.  •  Stupid  things  you  do  ten   Lmes  every  file,  but  yet   just  do  not  fit  into  a  class   or  object  reference  makes   no  sense  with.  
  34. 34. Thinking  about  Plahorm  DetecLon  •  Generally  means   HTTP_USER_AGENT   detecLng.  •  But  I  am  thinking  more   along  the  lines  of  devices   not  singling  out  PC   browsers.   –  However  the  same     detecLon  rules  apply.  •  Smart  phones  are  not   going  away.  They  are   important  to  consider.  
  35. 35. Thinking  about  CLI  support  •  Gives  you  the  full  power  of  your   framework  from  the  place  you  do   all  your  “oh  crap”  fixes  from  –  the   terminal.  •  It  is  handy  to  have  CLI  support   someLmes.   –  Not  talking  about  your  index.php   or  actual  webapp  files.   –  The  extra  effort  prevents  you  from   ge|ng  E_NOTICE  spam  about   things  like  HTTP_USER_AGENT   being  undefined  when  using  your   framework  from  the  CLI.  •  Allows  you  to  Cron  things  easy,   like  updaLng  a  staLc  cache  table   with  your  database  configuraLon   handy,  or  removing  temp  files   with  your  filepath  configuraLon   already  there.  
  36. 36. AddiLonal  PHP  Module  Support  •  You  can  add  features  to  your   framework  using  modules  PHP   already  has.   –  Need  HTML  cleaned?  Tidy   extension.   –  Image  manipulaLon?  Imagick   extension.   –  WriLng  a  spellcheck  API?  Pspell   extension.   –  List  goes  on  and  on,  check  the   PHP  manual  before  wriLng  a   full  library  from  scratch  or   going  hardcore  with  system()   calls.  •  If  you  write  a  library  using  a   module,  do  you  want  the   library  to  be  opLonally  loaded   when  needed?  
  37. 37. SLll  thinking  about  Third  Party  Libs  •  Already  menLoned  this,   but  it  is  a  strong  point.  •  Everyone  does  it,  even   Wordpress.  •  We  are  already   reinvenLng  the  wheel,   we  do  not  need  to   reinvent  gasoline.  
  38. 38. Design  Overload?  •  Build  your  system  one  part  at  a  Lme.   –  Hmm.  Separate  your  concerns?   –  First  thing  you  need  is  a  template   engine?  Hammer  that  out  solid.   –  Most  important  part  is  your  database   connecLon?  Make  sure  your  DB  kung   foo  is  good.  •  Take  a  moment  (or  several)  to  plan   your  next  lines  of  code  rather  than   hammer  them  out  quickly  just  to   have  it  done.  •  When  you  finish  one  library,  look   back  to  make  sure  it  interfaces  the   way  you  want  with  your  code.  •  Make  all  your  libraries  similar  in  the   way  they  operate,  and  your  codebase   will  feel  more  like  an  organized  team   than  a  bunch  of  crap  duct  taped   together.  
  39. 39. Quick  last  minute  notes  to  recap.  •  Plan  Plan  Plan.  Your  framework  is  an  extension  of   you.  The  Lme  you  spend  on  your  framework,  the   faster  your  next  project  using  it  will  go  up.  •  But  do  not  be  afraid  to  change  later  if  it  is  for  the   becer.  •  Feel  free  to  reuse  solid  projects  that  will  help  you.  •  Oh,  and  do  not  forget  to  document  your  code  if   you  plan  to  release  it  for  others  to  use.   – The  joke  was  this  comment  was  as  last  minute  as  most   developers  write  their  documentaLon.  
  40. 40. Cheers!   QuesLons?  Comments?  Bob  Majdak  Jr  <>   bob  in  #dallasphp  on  Freenode  Twicer,  Facebook:  bobmajdakjr