Just another web 3.0 blog :: prev - next

--- web development agencies thing ive seen ---

** Retour sur 10 années d'expérience d'agences et de développement web ** J'ai vu au long de nombreuses agences web dans lesquelles je suis intervenu : Des "leads développeurs" dont l'unique préoccupation était les single quotes pour la performance d'un site en ignorant tous les autres aspects. Des développeurs qui ne l'était pas, pratiquant le copier-coller et refusant des choses nouvelles, ou même ne connaissant pas le sql mais doctrine, oui, connaissant les emballages, mais pas le contenu .. Des développeurs refusant de faire du front ou inversement des développeurs refusant de faire du back .. Des chefs de projets ne se fiant qu'à leur avis, ne se remettant jamais en question et bluffant completement sur les temps de rendus, sans demander aux développeurs, mettant la pression à ces derniers jusqu'au point de rupture. Des "directeurs" qui ne savent pas du tout de quoi ils parlent, en même temps c'est normal, il ne s'agit que de simples titres attribué à des commerciaux afin de leur donner plus de crédit, de poids vis à vis des clients. Des projets cloisonés, non documentés, sur lequels 13 personnes on été successivement affectées sans que personnes n'ait de réelle vue d'ensemble. De réelles catastrophes et des gens en face, qui ne veulent pas en tirer des leçons, ne se remettant jamais en cause. Quelquefois, des gens brillants, osant se remettre eux-mêmes en question avant les autres, mais en général, hélàs, ces derniers ne font pas "vraiment" carrière, demeurent "indépendants", au final, car ces derniers ne vendent pas "assez bien" quand les choses sont posées, sans fausses-promesses, ni d'ambition à s'élever en écrasant / dévalorisant ses collègues. * Sous réserve d'avoir bien compris .. voilà comment on en parvient là .. pas assez de paroles pour les gens qui éxecutent, des chefs qui ignorent les alertes et avertissements ..

--- php 200 ok blank page bug ---

php 200 ok blank page bug : check for short array syntax (php5.4+) within your code, or place die(__FILE__.__LINE__) until you've found the file & line responsible for this

--- Website checklist ---

1) Has backups ( source, sql, medias, static files ) ? 2) Version Control ? 3) Portable ? Minimum dependencies ? Easy To Migrate settings ? 4) Mysql crash proof ? 5) Redis crash proof ? 6) Has a failsafe ? Failover ? 7) Has a developer logs && maintenance logs 8) Optimized queries, cache, 304, cdn 9) Elastic Ip adress or short TTL domain name ( in case main server has no failover and needs to be switched .. ) chown 33:33 -R .;#www-data ( apache or nginx user ) find . -type d -exec chmod 775 {} ; find . -type f -exec chmod 644 {} ; - Avoids spending 70% time switching files && environments - Avoids spending 25% time with phpmyadmin in prod environment - Avoids spending 15% time reviewing log files Using Frontcontroller : assume .php files can't be accessed directly by their respective urls ( frontcontroller defines FRONTCONTROLLER ), if(!defined('FRONTCONTROLLER'))die; Frontcontroller for 404 : send 200 headers if ressource matches a route

--- 9 layers php cache for high performance websites ---

The way of optimizing most PHP Websites are pretty simple & don't require any expensive webserver to run heavy load applications. ( quiet a long time since I haven't written anything here, becuz I've just never had the time at all ... ) The first places to look for any optimizations are obvioulsy within the mysql queries & php code : as for year 2008, this blog upon a collocation host, took more than 83 sec to generate a page as 4 users online .. First step : implement a timer & debug functions ( as registered shutdown functions ) within your code & log them !! Here is the 9 layers PHP cache I've setup this far : 1 : Mysql results cache & mysql inner cache & mysql indexes **** 2 : Full page html cache expires in future + binded with 304 handler ( with inner codes to invalidate data from separate block suppressed with grep upon cron ) ***** ( you won't see them performing better if you put them in ram .. as the page's output will take the more time here .. that's why 304 has to be implemented here ) 3 : Opcode cache ( newer php version are faster, indeed )** 4 : JSON serialized data arrays served with 304 headers whetever or not the data has been modified ( upon invalidation ) *** 5 : Array based file cache in Ram ( includes redis, memcache ) *** 6 : Individual static html files cache for individual blocks 7 : 304 headers using browser own cache **** 8 : Reverse-proxy : consider using a cdn is the same effect here 9 : Cdn : cloudflare Then I'll demystify some legends : - Well configured apache performs better than NGINX ( AllowOverride Off, logging static files .. ) - Amazon t2.micro instance aren't so expensive after all and are quite fast !

--- offre emploi développeur php genève ---

Vous maitrisez Zend Framework, Magento, Symfony && Drupal ? Le shell linux vous est très familier, et vous concevez régulièrement des applications Android ? Rejoignez dès aujourd'hui notre équipe

--- php : &reference bug ---

A connaitre car peu évident à identifier ... Bug de passage en référence non nettoyé $_GET=['a'=>'b']; foreach($_GET as &$v)$v='blabla'; #unset($v);#pour ne jamais risquer de ré-ecrire cette variable #plus loin .. $v='autre valeur'; echo $_GET['a'];#autre valeur En particulier lorsqu'il s'agit d'une application symfony avec plus de 3600 fichiers sources, ou d'une pré-injection "nettoyant" les tableaux d'entrée GET,POST etc.. à moins de mettre unset($v);# à la fin de la première boucle

--- php7 ---

Php7 : les "benchmarks" font état de 100% de perfs supplémentaires soit un x2 sur l'execution de n'importe quel code php. Mais il ne faut pas attendre que ce x2 augmente le temps de réponse I/O tels que sql etc .. bref ne pas l'attendre comme un saveur

Développeur php Genève - php - rando - trip - india - web - php - dev - eco - science - astro - shop - annecy - pro - avis - agence - w - bug - mea


0