Outils du web

Bonjour le petit peuple,

Je souhaiterais quérir votre aide pour obtenir de plus amples informations sur les différents outils permettant un travail plus évolué pour le monde du web. Actuellement, je développe énormément en PHP mais je dois avouer que mes méthodes et mon matériel est peut-être un peu vieillo (github est encore inconnu de moi même, il faudrait pourtant que je commence à m'en servir un jour).

Je souhaiterais donc obtenir de plus amples informations sur différents outils, ce que vous utilisez au quotidien, ce qui permet réellement d'augmenter la productivité etc. J'ai entendu parler de ces differentes choses mais je ne sais pas trop m'en servir.

• Vagrant (pour la création de VM rapidement et en ligne de commande ?)
• Grunt (?)
• Composer

En sachant que je commence doucement à me servir de SASS, est-ce que des choses seraient mieux ? Je tourne sous Windows 8 et je développe via ST3 (si au passage vous avez des extensions qui sortent de l'ordinaire et sont vraiment sympathique, je prends aussi !)

Voilà c'est tout, merci <3

Vagrant c'est pas pour le web, par contre si tu as besoin de générer rapidement un environnement de test ou de preprod, ça peut aider.

Grunt, c'est un outil front qui permet de gerer tout le workflow css et js. Il te permet de compiler les préprocesseurs CSS (SASS, SCSS…) et JS (coffeescript, typescript…) et de les minifier pour augmenter les performances.

Composer est un outil pour PHP qui te permet d'importer des modules et d'en gérer les versions. Cela facilite grandement le partage des projets (pas la peine de partager toutes les lib, juste le composer.json et tout fonctionne).

github est un réseau social du code. Il permet d'accéder à des dépôts versionnés par git. Tu peux utiliser git sans github. L'avantage de github c'est que si ton projet intéresse quelqu'un, il peut recevoir des bugfix.

J'aurais pas dit mieux !

Je n'ai pas encore vraiment utilisé Composer (à part pour suive le tuto sur le site de Zend), mais la gestion de dépendances façon Node, ça me plait bien.

Concernant Git, j'ai tendance à l'utiliser de plus en plus (même pour pas grand chose). Sur GitHub pour les projets publics, sur BitBucket pour ce qui est privé (comment ça je suis radin ?). Je dois avouer que GitHub me plait beaucoup plus que ses concurrents pour tout un tas de raisons : plus ergonomique, applications officielles (Windows, Mac, Android…) qui facilitent beaucoup de choses, wikis intégrés, gestion des tickets, etc.

Concernant Grunt et ce genre d'outils, j'ai encore un peu de mal à voir l'intérêt sur mes projets étant donné que j'aime bien tout maîtriser, que j'aime pas trop la ligne de commande et que j'ai rarement des dizaines de fichiers CSS/JS (ou alors je fais en sorte de gérer la minification/concaténation côté serveur pour être tranquille).

Pour sass, je conseille Scout, c'est une interface qui permet de changer son sass/scss en css, en direct, et avec des options (compresser, etc).

Sinon, je développe avec Sublime Text 3 en Full Screen sur mon plus gros écran, et sur mon second, Firefox (bien que j'utilise Chrome pour le surf) parce que FF a un plugin qui permet d'actualiser sa page quand un/des fichier(s) est/sont modifié(s).

parce que FF a un plugin qui permet d'actualiser sa page quand un/des fichier(s) est/sont modifié(s).

Livereload ?

Sinon, j'ai fait un article sur les outils que j'utilise pour le front-end. Ca peut éventuellement t'intéresser.

Sur ZdS, on utilise Gulp et non Grunt. Globalement, c'est plus simple et ça suffit dans 99% des cas.

Ou sinon il y a Prepros (qui existe une version payante mais la gratuite est largement suffisante) qui compile le SASS, LESS, Haml, Jade, Coffeescript, etc…

Je tiens à préciser qu'il existe un module Nodejs qui se nomme Browsersync et qui permet de synchroniser et de rafraîchir des pages sur tous les devices connectés. Il peut aussi fonctionner avec un serveur déjà existant, ou alors servir les fichiers de façons statique. Il s’intègre très bien avec des taskrunner telles que Gulp (mon préféré) où Grunt.

Hello !

[…] (si au passage vous avez des extensions qui sortent de l'ordinaire et sont vraiment sympathique, je prends aussi !)

J'utilise Sublime Text 2 pour coder avec les package suivants :

• BracketHighlighter
• Color Highlighter
• CSSLint
• Emmet
• Emmet Css Snippets
• Markdown Preview

Il y en a sûrement beaucoup d'autres d'intéressants et d'utiles. Après, ça dépend de tes besoins.

Ah ! j'y pense, un article intéressant d'un ami développeur à propos de différents outils pour les développeurs web : Useful Web Developer Tools

Bonjours à tous !

Je profite de ce topic pour poser une petite question aux devs de ZdS (et aux autres évidemment), j'ai vu que sur toutes les Pull Request il y a un message de coveralls affichant un "coverage x%", après quelques recherches j'ai vu que c'était un système d'intégration continue comme Jenkins ou Travis mais j'avoue que j'ai du mal à réellement saisir l'utilité de ces outils et surtout ce qu'ils font.

Ils testent le code entièrement à chaque commit et indique les bugs ? Si oui il est nécessaire de faire un développement dirigé par les tests non ?

Merci pour ceux qui éclaireront ma lanterne

Je ne connais pas coveralls spécifiquement mais je peux éclairer ta lanterne quant aux outils d'intégration continue.

L'idée est d'automatiser un maximum de procédures, pas forcément sur chaque commit, mais au moins à chaque build de ton projet.

On va raisonner sur un projet perso (et sans pré-prod) pour simplifier.

Tu modifies ton application / site web / ou autre, en local sur ta machine. Tu es satisfait de ton résultat, tu vas balancer les modifications en prod, i.e. balancer ça sur internet ou créer l'exécutable/le fichier distribuable (jar) de ton programme, etc.

L'outil d'intégration continue peut se charger dans ce cas de plusieurs choses :

• récupérer tes sources modifiées (sur un repository, en lisant le système de fichier local, …)

• construire ton application (phase de build ). Par exemple minifier les fichiers JS ou CSS, ou nettoyer des sources dans d'autres cas. Construire un fichier WAR ou EAR dans le cas d'un projet JEE

• tester ton application (cf. plus bas) afin de vérifier que les dernières modifications effectuées n'ont pas affecté le comportement de l'application tel que tu l'as décrit dans les tests d'intégration

• si les tests n'échouent pas : déployer l'application. Par exemple éteindre le serveur d'application, envoyer le résultat du build , puis redémarrer le serveur d'application

En ce qui concerne la phase de tests plus spécifiquement, l'idée est de décrire le comportement attendu fonctionnellement. Tu dois connaître les tests unitaires. Ceux-là ont du être lancés auparavant (même si ça ne fait pas de mal d'en remettre une couche) par le développeur, pour s'assurer qu'il n'a rien cassé dans les classes qu'il a modifiées. Par contre, les tests d'intégration s'occupent de vérifier que, sur le plan des fonctionnalités offertes par l'application (rédaction d'un message, +1/-1, création d'un tutoriel, ajout d'un chapitre, …) rien n'a été cassé. En conjonction de ces tests, on utilise parfois un outil de couverture de code qui, en gros, te dit : "lors de l'exécution des tests d'intégration, on est passé dans 87% du code, donc il se pourrait bien que y'ait des cas qui existe dans le code (des else, des switch) dans lequel les tests ne passent pas. Si y'a un bug là-dedans, on ne le teste pas : attention".

Oui, ça vient en quelque sorte en conjonction de l'approche TDD, même si c'est pas tout à fait cela.

En gros le TDD c'est l'idée que tu vas décrire le comportement attendu de ton code avant même (ou en même temps) que tu écris le code. Et tu le décris en codant des tests du style "quand un tutoriel est publié, il doit être renvoyé au contrôleur qui s'occupe d'afficher la liste des tutoriels".

Réponse parfaite, merci Javier !

Tu peux remplacer GruntJS par GulpJS, voir l'article sur mon blog.

Ainsi que d'autres ressources.

Les trucs qui ont juste changé ma vie en dev php ces dernières années:

• Depuis 5.4, le serveur de dev intégré au langage, c'est juste beaucoup plus confortable que de se taper l'installation d'un virtualhost Apache et on a le log des erreurs en live. J'ai une idée de script, en moins de 10 secondes j'ai déjà le truc en place. C'est dingue le nombre de trucs que j'expérimente depuis.
• Composer: gestionnaire de dépendances de PHP, il est super facile d'utilisation et d'installation et il fournit un autoloader qui charge aussi nos propres classes. C'esr vraiment devenu le standard PHP et il n'a rien à envier à ses contreparties d'autres langages type npm ou pip, au contraire.
• Atoum: c'est comme phpunit mais plus sympa et plus simple utilisation
• Travis CI: j'utilise depuis quelques mois et c'est très bien pour mes projets qui ont quelques contributeurs
• Github: je peux juste plus vivre sans
• Sinon, côté éditeur j'utilise Sublime Text 3, il est cool et me suffit largement.

Mes trucs à moi, ça serait :

• Vagrant pour avoir un environnement de dév simplement.
• PuPHPet qui va de pair avec mon 1^er point, histoire faire mes configs Vagrant très rapidement.
• PHP5.5 & Apache/Nginx & Symfony2
• MariaDB mais je compte me pencher vers PostgreSQL par la suite. (base de données)
• Niveau IDE j'utilise PHPStorm et aussi Sublime Text pour de plus petites choses
• Github pour versionner mes projets

• PHP-CLI, plus rapide que les serveurs web, même intégrés, et ce depuis 2002.
• Je préfère PECL/PEAR à Composer. C'est plus "standard". Je me demande d'ailleurs pourquoi Composer à été inventé quand je vois PEAR.
• Je ne connaissais pas, j'essayerais bien, mais bon dans la doc d'atoum je trouve rien par rapport à la dépendance de tests entre eux, et c'est un truc qui pourrait être bloquant.

Moi les outils que j'utilise sont principallement lié au projet aquuel je contribue, à savoir phpBB. Du coup j'utilise

• composer
• phpunit
• différents composants de Symfony2
• de nombreuses bdd (postgres, mysql, oracle, sqlite3)
• Github
• Travis CI
• et niveau IDE j'utilise PhpStorm
• La question de la mise au point d'une VM vagrant s'est aussi posée et certains y travail. Mais configurer une telle VM pour qu'elle soit en mesure de faire tourner tous nos tests sur divers environnements et légèrement complexe et prend du temps.

Sinon, concernant PECL/PEAR versus composer, voici un article de Fabien Potencier (le fondateur de Symfony) qui explique comment est né composer, les différences vis à vis de PECL/PEAR et pourquoi c'est mieux (par contre, bien que l'auteur soit français, l'article est en anglais ^^) http://fabien.potencier.org/article/72/the-rise-of-composer-and-the-fall-of-pear

EDIT: Il faut savoir aussi que composer permet de définir d'utiliser un canal PEAR pour fournir tout ou partie des dépendances.

• Je préfère PECL/PEAR à Composer. C'est plus "standard". Je me demande d'ailleurs pourquoi Composer à été inventé quand je vois PEAR.

Salut,

Il y a plus de 35.000 paquets pour composer, tous récents et suivant largement les recommandations PSR. Il n'y a que quelques centaines de paquets via PEAR, la plupart écrit à l'époque de PHP4, abandonnés et/ou obsolètes. PEAR n'est plus le standard depuis longtemps, il n'existe encore que pour des raisons historiques. Tu as un article qui date d'il y a deux ans à ce sujet qui dit les choses crûment mais clairement http://philsturgeon.uk/blog/2012/03/packages-the-way-forward-for-php

Il y a encore une petite dépendance dans le code de PHP à PEAR pour PECL, mais c'est en cours de remplacement par les core devs PHP par Pickle qui est créé en collaboration avec l'équipe de Composer : https://wiki.php.net/rfc/pickle

J'avoue que je vois pas trop ce qui peut faire utiliser PEAR que Composer à part le cas très particulier d'une librairie qui n'est disponible que via PEAR parce qu'elle a été abandonnée et que le dev ne la mettra donc pas sur Packagist. Tu as des utilisations spécifiques de PEAR qui ne sont pas couvertes par Composer ?

A+ Pascal

Je viens de regarder un peu et j'ai réussi à faire tourner Vagrant via PuPHPet, et c'est franchement pas mal !

PEAR est de moins en moins utilisé¹. Ce n'est par contre pas vrai pour PECL.

Perso je reste sur PHPUnit, même si je pense migrer vers du PHPSpec et Prophet pour les mocks. Je trouve le projet Atoum maintenu de façon trop infâme pour l'utiliser. Après, c'est ptet du au fait que j'ai tendance à adhérer un peu trop aux PSR, qui sont elles pas forcément un standard général "de facto" (comme les PEP de python par exemple), mais plus un standard entre certains des projets les plus populaires.

Sinon, pour ma part, un peu en vrac :

• Github / Gists pour héberger mes projets, privés comme publics. Et aussi consulter le code des différentes dépendances que j'ai, ou contribuer à gauche à droite.
• La console pour manipuler git. En fait, la console tout court avec un framework zsh (oh my zsh)
• vim avec qqs modules, avec une config que j'étoffe régulièrement
• PHP 5.5 (bientôt 5.6 :-°)
• Apache2… Après m'être sacrément cogné les dents sur des 502 bad gateway sur nginx y'a deux ans.
• Mysql, la flemme de passer à autre chose, et pour ce que j'en fais…

En amélioration, je pensais me mettre à Docker (avec Vagrant et PuPHet), mais faut encore que j'étudie bien le truc.

Je crois avoir fait le tour.

Moi aussi j'utilise PHPUnit perso. Après, moi je ne suis pas forcément toutes les PSR, notamment la PSR-2 (j'utilise des tabs, pas des espaces, je retourne à la ligne pour mon accolade ouvrante, etc.).