Parfois par défi personnel, parfois par demande de la société qui vous emploie, cette certification est régulièrement demandée. Notre société moderne de plus en plus cloisonné par le besoin d’avoir des diplômes pour prouver ce qu’on est, ce qu’on vaut ne nous laisse pas le choix: vous devez passer votre certification PHP.
La question qui vient donc à l’esprit c’est comment la réussir pour la mettre définitivement derrière vous, pouvoir l’exhiber fièrement dans votre CV, linkedIn et autres.
Depuis peu je m’essaie à Ansible pour installer mes machines en production et les maintenir.
Une des fonctionnalités bien utile est la possibilité de tagguer des taches pour pouvoir exécuter seulement une partie des tâches du playbook sans devoir rejouer la totalité de ce dernier qui peut vite devenir gros, lourd et de facto lent à exécuter.
Évidemment ces tags il faut les écrire tâche par tâche et cela peut vite devenir lourd, surtout si vous n’avez pas fait ça progressivement. C’est la que mon parseur arrive: il lit les tags déjà placés et déduit ceux qui devraient exister selon la structure hiérarchique mise en place.
N’hésitez pas à remonter des bugs ou à commenter ce post si vous désirez des nouvelles fonctionnalités. Je sais c’est pas très testé et c’est pas bien, mais c’est sur les planches. Si ça se trouve le jour où vous lirez ce post il y aura des tests ^^
Posted in AdminSys at May 25th, 2015. Comments Off on Ansible tags parser.
Si vous voulez lire une remarque appréciative du bouquin voilà la seule chose que j’ai à vous conseiller: Foncez l’acheter
Mon idée pour ce post est juste de créer un petit mémo sur ce que j’ai appris, les “nouvelles” façon de faire. Mais également de relater les ressources à ne pas oublier.
Je n’ai aucunement l’envie de cannibaliser le travail de l’auteur, ce pourquoi je resterai volontairement évasif. De nouveau si vous voulez en savoir plus achetez le bouquin !
Les nouvelles fonctionnalités et des existantes inusitées:
Les traits
Les générateurs
filter_input REMPLACE l’accès aux superglobales $_GET, $_POST, $_COOKIE
filter_var & FILTER_VALIDATE_* est capable de valider série de chose sans devoir directement sortir les regexps.
l’API password_* (si vous utilisez une version PHP < 5.5 vous pouvez l’importer: ircmaxell/password-compat)
Les dates et leur gestion:
DateTime, DateInterval, DateTimeZone, DatePeriod (il existe également une librairie vous facilitant la gestion des dates nesbot/carbon)
Les non-classés:
Utilisation des PDO::PARAM_* pour spécifier les types des paramètres attachés dans une requête préparée PDO.
Les streams sont partout et très puissants (Il est possible de gunzipper un fichier à la volée pendant sa lecture)
Les exceptions et leur utilisation:
Les exceptions à utiliser (au lieu de tout baser sur Exception):
Les classiques: Exception, ErrorException,
LogicException et ses enfants: BadFunctionCallException, BadMethodCallException, DomainException, InvalidArgumentException, LengthException, OutOfRangeException,
RuntimeException et ses enfants: OutOfBoundsException, OverflowException, RangeException, UnderflowException, UnexpectedValueException
Le try catch finally existe aussi en php
Il n’est pas très dur (et est une bonne pratique) de transformer toute erreur en ErrorException avec set_error_handler
Les components:
Les components et composer sont le futur et tellement simples à utiliser que ça en deviendrait honteux de ne pas en manger.
Les frameworks ne sont pas une mauvaise chose en soit, mais ils doivent évoluer et devenir une agrégation de components plutôt que continuer à implémenter les leurs.
Toujours exposer des interfaces à la communauté.
Utilisation des PSR (1 & 2 pour le style, 3 pour la LoggerInterface, 4 pour le chargement des classes)
Tests:
phpunit évidemment
SpecBDD
StoryBDD (Behat)
XDebug pour le code coverage (utilisation de la balise whitelist pour définir le coverage)
TravisCI
Profiling:
XDebug
XHProf & XHGUI
Benchmarking:
Apache Bench
Siege
Les optimisations non relatives au code à proprement parler
Zend OPcache est dispo à partir de la version .5.5
Voilà, on a une config avec Varnish qui est capable d’encaisser la totalité du trafic sans broncher (ça me fait penser que je dois terminer la traduction d’un article qui explique comment bien optimiser Apache). Évidemment seul Varnish est censé pouvoir être accessible de l’extérieur et les backends doivent ne pouvoir être accédés que depuis Varnish lui même.
Dans mon cas, tout se trouve sur la même bécane et donc tout ce qui est backend doit écouter sur localhost/127.0.0.1 uniquement.
Si comme moi vous cherchiez un moyen d’afficher les logs d’une machine avec un script en php. Mais aussi d’effectuer un filtrage relativement simplement dedans et cela sans devoir s’imposer une base de données, j’ai la solution qu’il vous faut.
Alors j’ai piqué gracieusement la base d’un site mais refait au final de fond en comble. Mais merci à lui (sais plus qui c’est dsl :-$) pour l’idée.
On est bien d’accord c’est fait en 3 coups de cuillères à pot. Mais j’avais pas besoin d’un code plus soigné ;-) Vous pouvez tjrs forker et l’améliorer ;-)
Ah oui il est BIEN ENTENDU que ce script n’est pas fait pour se faire afficher sur un réseau public hein! Beaucoup d’infos potentiellement confidentielles passent dans un log!!! (cc jBleuzen)
Posted in Au quotidien at September 30th, 2011. Comments Off on Syslog PHP – Ajax.
