La programmation en binôme, plus connue sous le nom de pair programming est une méthode agile de développement logiciel où deux développeurs ou développeuses travaillent ensemble sur un même poste. Cette collaboration permet de partager les connaissances, et de surmonter les obstacles plus rapidement qu’en solo. Certaines organisations sont toutefois encore bien sceptiques quant au pair programming, considéré comme une utilisation inefficiente des ressources… Alors, bon plan ou perte de temps la programmation à deux ?

(indice : la réponse est dans le titre !)

Qu’est-ce que le pair programming ?

La programmation en binôme, qu’on appelle aussi parfois binômage ou programmation par pairs a été popularisée dans les années 90 grâce à l’eXtreme Programming. Issue des bonnes pratiques XP, elle consiste donc à faire collaborer deux devs sur un même PC. L’un rédige le code, c’est le conducteur (ou driver), tandis que l’autre observe et effectue une revue de code en direct, c’est le navigateur.

C’est un peu le même principe qu’un rallye automobile, avec un pilote et un copilote : le driver tient le clavier et la souris (le volant et les pédales), pendant que le navigateur lui donne des indications pour franchir les difficultés du parcours. En pair programming en revanche, les rôles sont inversés régulièrement, selon un rythme déterminé à l’avance.

A noter que le rôle de navigateur n’est pas passif. Au contraire, il ou elle aide le conducteur à chaque étape, à voix haute, et propose des améliorations ou des approches différentes quant au problème à résoudre. L’idée n’est pas de développer tour à tour ou d’être le scribe d’un collègue, mais bien de réfléchir à deux sur un même problème de programmation, pour que la solution finale arrive plus vite.

Il existe différentes manières de faire du pair programming.

Le couple conducteur-navigateur, avec un ou plusieurs PC

La façon la plus classique de mettre en place cette pratique est tout simplement de s’asseoir côte à côte devant un écran d’ordinateur. Les deux développeurs ou développeuses prennent le clavier et la souris à tour de rôle, d’un côté pour écrire du code, et de l’autre pour relire, corriger et proposer des améliorations.

Il est aussi possible que chacun utilise son propre PC, le navigateur ou la navigatrice peut alors faire des recherches pour orienter son partenaire, ou même réaliser des maquettes en direct. La personne qui ne code pas peut également utiliser papier et crayon pour réaliser ces maquettes, notamment lorsqu’une portion importante du travail a trait au design architectural ou d’interfaces utilisateur.

Quoiqu’il en soit, les deux pair programmeurs travaillent de concert, discutent sur la meilleure manière d’aborder un problème, et n’implémentent une solution que lorsque celle-ci est doublement validée.

Le Ping-Pong pair programming

Cette forme de pair programming est mise en œuvre dans un contexte de développement piloté par les tests (TDD). Une personne écrit un test, et l’autre écrit le code pour que le test passe. Une méthode efficace, surtout que les changements de rôles se font tout naturellement.

Attention toutefois à bien interchanger les positions et à ne pas faire écrire ou passer les tests par la même personne à chaque fois. Typiquement, le développeur le moins expérimenté ou le moins confiant aura tendance à toujours écrire les tests, pour qu’un développeur plus aguerri s’occupe d’écrire le code qui validera le test.

C’est une méthode plutôt sympa, où les deux personnes impliquées se lancent tour à tour des défis de programmation. Les échanges de rôles plus fréquents peuvent toutefois induire un temps total de développement plus long que les autres méthodes.

Le couplage fort, ou strong-style pairing

Cette méthode consiste à obliger celui qui rédige le code à ne rien faire tant que le navigateur ne lui a pas communiqué de tâches. Le conducteur doit toujours demander l’avis de la personne qui l’accompagne avant de faire quoique ce soit. Les échanges de place se font dès que l’un des deux développeurs a une idée : c’est à l’autre de la transcrire en code ! Llewellyn Falco, coach Agile spécialiste du code legacy et du TDD, justifie cette approche ainsi :

Pour qu’une idée aille de votre tête à l’ordinateur, il faut qu’elle passe par les mains de quelqu’un d’autre.

En mettant en place cette pratique de strong style pair programming, chaque programmeur est impliqué dans le processus de développement (en particulier le navigateur qui peut parfois avoir tendance à prendre son rôle à la légère avec les autres méthodes).

Pair programming n’est pas mentoring

Finalement, attention à ne pas confondre pair programming et mentoring, ce sont deux choses bien distinctes. Une relation professeur-élève est bien différente de deux professionnels collaborant sans aucune considération hiérarchique, même s’il y en a généralement un plus expérimenté que l’autre. L’idée n’est pas pour le navigateur de diriger le travail du conducteur mais bien de suggérer des manières d’avancer : la collaboration est la clé du pair programming !

Avantages et inconvénients de la programmation à deux

Quand on pair programme, l’ensemble du code envoyé en production est donc créé par deux personnes qui travaillent de concert. Découvrons ensemble quels en sont les bénéfices et inconvénients (oui, il y en a… si on cherche bien).

Une meilleure qualité du code, sans augmentation des délais de livraison

A première vue, on pourrait penser que le pair programming augmente les temps de livraison de 100%, car on a deux personnes qui travaillent sur le même morceau de code. Sauf que deux têtes valent mieux qu’une plus une, et que la réalité est plutôt autour des 15%. Ok, mais c’est toujours 15% de plus, donc 15% de trop…

En réalité, lorsqu’un programme est codé par deux personnes, les retours d’expérience montrent que la qualité du code est largement supérieure. Les deux développeurs ou développeuses discutent des meilleures façons de résoudre les problèmes rencontrés, ce qui permet d’avoir un code plus propre, plus facile à lire et à retravailler dans le futur.

Les développements réalisés en pair programming contiennent ainsi 15% de bugs en moins en moyenne. Si l’on considère qu’un seul bug peut occuper plusieurs personnes pendant plusieurs heures, et que les larges projets peuvent en contenir des centaines, le calcul est vite fait.

Une collaboration saine et efficace

Lorsqu’on débute en pair programming, on entend souvent des remarques du genre « Je suis quelqu’un de très introverti. Je déteste devoir interagir avec d’autres personnes, et l’idée de le faire constamment ne me plaît pas du tout ». Formulées à voix haute ou non, ces remarques sont tout à fait justifiées, mais une fois la timidité dépassée peu sont ceux qui ne veulent plus entendre parler de pair programming.

Au-delà des gains en termes de productivité et de qualité induits par la revue de code en continu, développer à plusieurs (à deux en l’occurrence) peut en effet s’avérer bien plus exaltant que d’évoluer seul dans son coin, et ce pour différentes raisons :

• Partager ses connaissances et meilleures pratiques. S’associer avec un développeur ou une développeuse senior est le meilleur moyen pour quelqu’un de moins expérimenté d’améliorer ses pratiques. Mais les devs plus expérimentés peuvent également apprendre des plus jeunes, que ce soit en découvrant une commande Linux inconnue, en utilisant un nouvel IDE ou le dernier framework Front-end à la mode, chacun peut apporter à l’autre.

• Moins d’interruptions. Si l’un des deux pair-programmeurs doit s’absenter pour assister à une quelconque réunion, l’autre peut rester concentré sur la tâche en cours sans perdre le fil.

• Une coordination d’ensemble plus simple. Vu qu’il y a deux fois moins de postes à gérer, coordonner le projet dans son ensemble nécessite moins d’efforts.

• Le renforcement de l’esprit d’équipe et des liens entre développeurs. Quelques bonnes sessions de pair programming sont tout aussi efficaces qu’un long week-end de team building en Ardèche.

• Moins de procrastination. Développer à deux permet d’éviter de se déconcentrer en allant checker ses mails, son Slack, WhatsApp ou autre. Cela peut paraître insignifiant mais les distractions sont aujourd’hui partout, et le temps passé à faire autre chose que du code est parfois très conséquent.

Certaines sociétés, qui placent la collaboration au centre de leurs pratiques, interdisent même à leurs développeurs de faire partir du code en production s’ils ont travaillé seul dessus !

Des intégrations facilitées

Le transfert de connaissances est très fluide en pair programming. De fait, au lieu de passer par des heures d’auto-formation, l’intégration d’un nouveau collaborateur peut se faire en lui assignant un partenaire de programmation. Il ou elle plongera directement dans le code source, avec quelqu’un à ses côtés qui le connaît déjà, produisant ainsi de la valeur bien plus rapidement pour l’entreprise.

Programmer à deux en vue d’une embauche peut également être un très bon moyen pour évaluer la qualité d’un candidat ou d’une candidate, et se faire une idée de sa future intégration avec l’équipe de développement en place.

Cela dit, le pair programming n’est pas non plus sans inconvénient.

Compliquer les tâches simples

Au vu des succès et de l’engouement que le pair programming peut susciter dans une équipe de développement, ses membres peuvent avoir tendance à trop en faire. Certains problèmes de programmation ne nécessitent absolument pas que deux personnes se penchent dessus : une correction de bug toute bête ou une fonctionnalité facile à implémenter ne sont pas propices au pair programming.

Attention donc à ne pas recourir à la programmation à deux à tout va, surtout pour des tâches plutôt simples, où un deuxième cerveau ne sera pas forcément utile.

Surcharger mentalement les développeurs et développeuses

Quand deux pair programmeurs travaillent de concert, il est beaucoup plus difficile de se déconcentrer et de prendre des petites pauses mentales, pourtant bénéfiques pour la productivité. Les développeurs qui travaillent en binôme évoquent parfois des journées de code éprouvantes mentalement, car la concentration est à son maximum pendant toute la session de pair programming.

Comment commencer à pair programmer dans votre entreprise ?

Alors, convaincu·e ? Voici pour finir quelques conseils et bonnes pratiques pour débuter la programmation en binôme au sein de votre organisation.

Y aller doucement, mais sur des développements complexes

Le pair programming est très facile à implémenter, dans le sens où ce n’est pas tout ou rien. Il est tout à fait possible de programmer à deux seulement de temps en temps. Dans un contexte de développement agile, cela peut aussi être mis en place le temps d’une itération.

Vous pouvez ainsi tenter l’expérience du pair programming sans remettre en cause toute l’organisation et les habitudes de votre entreprise. Cela permettra de surcroît à tout le monde de comparer les performances avec la programmation en solo.

Pour débuter, il est conseillé de coder en binôme sur des tâches complexes et plutôt longues, plutôt que sur des développements simples et rapides. Les avantages du pair programming n’en seront que plus visibles.

Parler, beaucoup parler

On ne fait jamais de programmation à deux sans causer. Si un binôme est silencieux, c’est qu’il n’y a pas de partage, pas assez en tous cas. Que vous soyez côte à côte ou à distance (on y revient juste en-dessous), échangez, pensez à voix haute, c’est ce qui fera l’efficacité de votre session de pair programming.

Quelques outils pour pair programmer à distance

Si la plupart des sessions de programmation en binôme se font derrière un seul et même écran, il est tout à fait possible de faire du pair programming à distance. Les outils informatiques favorisant la collaboration sont aujourd’hui légion, et le temps des chaînes d’emails, appels Skype ou transferts interminables de .zip semble révolu.

Vous trouverez ci-dessous une liste d’outils de développeurs destinés à celles et ceux qui travaillent dans une équipe dispatchée ou qui sont régulièrement amenés à collaborer sur des bouts de code :

• Visual Studio Live Share : la solution Microsoft pour le développement collaboratif, basée sur son IDE bien connu.
• Teletype for Atom : le nouvel entrant sur le créneau, gratuit et open source.
• RemoteCollab : un plugin SublimeText pour permettre à plusieurs développeurs de travailler sur le même projet en temps réel.
• CodeSandbox : avec sa fonctionnalité Live, cet outil permet de collaborer sur vos différents sandboxs.
• Codeanywhere : comme son nom l’indique, cette solution basée sur votre navigateur vous permet de « coder partout », ou en tous cas depuis n’importe quel appareil.
• CodePen : moyennant une souscription à l’abonnement Pro, le mode Collab offre finalement un environnement sur lequel plusieurs développeurs peuvent travailler simultanément.

Sachez finalement qu’il faut du temps pour s’habituer au pair programming, cela risque de vous paraître bizarre au début, mais pas d’inquiétude, l’habitude vient en codant !

Pour accélérer les choses, nous vous proposons une formation pour mettre en application les meilleures pratiques de pair programming. 2 jours de code-retreat durant lesquels les apprenants abordent également le TDD, clean code, l’architecture émergente ou encore les principes SOLID.

Le pair programming, vu par CommitStrip :

Cet article Pair programming : coder en binôme, bonne ou très bonne idée ? est apparu en premier sur Apollo Formation.

Les générateurs de sites statiques (SSG) gagnent en popularité depuis plusieurs années, plus particulièrement auprès des développeurs. Réputés pour offrir des sites web plus rapides et plus sécurisés, ils bénéficient d’un écosystème et d’une communauté en pleine croissance.

Progressivement, ils deviennent une réelle alternative aux CMS dynamiques. Mais les générateurs de sites statiques, est-ce une bonne ou une mauvaise idée ?

Générateur de sites statiques : définition

Un générateur de sites statiques, ou Static Sites Generator en anglais (SSG), génère, comme son nom l’indique, des fichiers statiques pour un site web. Pour cela, il sépare contenu et mise en page, qu’il rassemble ensuite pour générer les pages statiques correspondantes.

Concrètement, nombre de ces générateurs utilisent le Markdown pour les contenus, qu’ils associent à des structures de code préfabriquées, à savoir des thèmes et templates.

Le résultat est donc sous formes de fichiers statiques à publier sur un serveur ou sur un cloud, contrairement aux CMS classiques et dynamiques qui construisent les pages à la demande de l’utilisateur. Ici, pas de contenu stocké dans les bases de données : le serveur a seulement pour mission de servir les pages demandées et non de les « construire » sur le tas.

Néanmoins, la popularité des générateurs de sites statiques spécifiquement auprès des développeurs n’est pas anodine : l’installation et les opérations d’un SSG se réalisent le plus généralement via une interface de commandes.

Il paraît aussi difficile d’imposer Markdown à ses clients, qui préfèreront sûrement les éditeurs WYSIWYG proposés par les CMS classiques.

Heureusement, les SSG disposent aujourd’hui de nombreuses solutions pour faciliter leur utilisation comme l’architecture web JAMstack (JavaScript, APIs, Markup) qui permet de rendre le site dynamique, tout en sachant qu’ils permettent l’utilisation d’headless CMS.

Générateur de site statiques vs CMS dynamiques

Les CMS classiques se sont largement imposés au fil du temps, à l’image de WordPress qui est aujourd’hui utilisé par un peu plus d’un tiers des sites web. Faciles à prendre en main, régulièrement mis à jour, personnalisables, flexibles, optimisés, populaires (certains plus que d’autres) … ils permettent de créer un site aisément et de gérer du contenu sans connaissances spécifiques (HTML, CSS, …).

Finalement, ils sont aujourd’hui la solution de facilité, connue à la fois des développeurs et du grand public.

Sauf que ces « usines à gaz » offrent parfois bien plus que ce dont on a besoin ! Si nous prenons l’exemple d’un site vitrine, les contenus sont peu nombreux, tout comme les pages qui le composent, et il ne risque pas d’être mis à jour très souvent.

Dans ce cas, est-il réellement utile de stocker les contenus dans une base de données, de les faire afficher de manière dynamique ou encore de disposer d’une tonne de fichiers qui tendent à allonger les temps de traitement ? Pas vraiment… De plus, les sites réalisés via des CMS classiques sont souvent lourds et sensibles au niveau sécurité.

Bref, la morale de l’histoire, c’est que les sites statiques sont souvent plus adaptés et offrent globalement plus de contrôle.

Le problème c’est que ces générateurs nécessitent des compétences spécifiques (bien que cela puisse s’apprendre) et qu’ils manquent d’un back-office, qui se révèle bien pratique pour la gestion du site et des contenus, imposant ainsi la gestion de chaque fichier de manière individuelle.

C’est donc là qu’interviennent les générateurs de sites statiques !

Avec les SSG, il suffit de commencer par créer les contenus, qui sont ensuite mis en forme en local ou via le cloud grâce à un compilateur pour finalement créer des pages statiques. Et voilà !

Bon, c’est évidemment un peu plus compliqué que cela mais l’intérêt, c’est que les temps de chargement sont globalement plus rapides (moins de ressources à charger/afficher) et que les risques de piratage sont diminués (pas de base de données). Équipés d’un headless CMS avec une architecture JAMstack, les contenus deviennent même plus simples à gérer pour les non-développeurs.

Les générateurs de sites statiques c’est alors un compromis entre le site statique from scratch et les CMS dynamiques plutôt surchargés.

Générateur de sites statiques, JAMstack…comment ça marche ?

Avec les générateurs de sites statiques, les contenus sont rédigés en langage léger tel que Markdown. Ils sont ensuite assemblés, à l’aide du générateur, à des fichiers template pour produire les fichiers HTML. Ces derniers se modifient d’ailleurs d’eux-mêmes dès que le fichier markdown associé ou le template est modifié. Ils sont ensuite à publier via un serveur web.

JAMstack…qu’est-ce que c’est ?

La JAMstack est une architecture web dont l’abréviation « JAM » provient de JavaScript, APIs et Markup, qui permet d’apporter du dynamisme à des sites statiques.

Ces fonctionnalités dynamiques sont donc gérées par JavaScript uniquement. On peut d’ailleurs utiliser la bibliothèque ou le « >framework JS que l’on souhaite. Côté serveur, les opérations sont abstraites sous forme d’APIs réutilisables, dont l’accès se fait en HTTPS avec JavaScript. Enfin, les fichiers du site web sont sous forme statique, en HTML, et peuvent être générés via des fichiers en Markdown, par exemple.

En termes de bénéfices, la JAMstack apporterait :

• Performance : grâce à un CDN
• Sécurité : notamment car pas de base de données avec un site statique
• Économies financières : car l’hébergement de fichiers statique est souvent moins cher
• Bonne Developer Experience (DX) : puisque l’on se focalise sur la partie client.
• Adaptabilité : le CDN permet, entre autres, de mieux s’adapter aux hausse importantes de trafic.

Pour en savoir plus, vous pouvez vous rendre sur jamstack.wtf, un site donnant une vue d’ensemble de la JAMstack, ainsi que sa version traduite en français jamstatic.fr.

Headless CMS (CMS Statiques)

Un des inconvénients des générateurs de sites statiques, c’est que l’édition d’une page ou d’un article (dans le cas d’un blog), force l’accès au fichier original, souvent en Markdown. Pour pallier à ce manque de confort, il existe donc des headless CMS, aussi appelés CMS statiques.

Ces outils ressemblent aux CMS dynamiques que l’on connaît tous mais en version plus restreinte. Ici, l’importance est clairement à la gestion de contenu, notamment l’édition qui devient plus simple grâce à des interfaces visuelles. Il est également possible de gérer les utilisateurs et leurs permissions comme tout CMS. Finalement, ces solutions permettent de découpler le back-end du front-end.

Pour relier un CMS statique à son site web, il convient d’utiliser une REST API au travers d’une architecture web type JAMstack.

La plupart de ces CMS statiques peuvent s’utiliser peu importe la technologie front-end utilisée. Néanmoins, certains sont aussi conçu pour fonctionner avec des outils spécifiques en priorité.

Utiliser les API pour plus de dynamisme

Aujourd’hui, les sites web créés avec la JAMstack sont souvent bien plus dynamiques que statiques. Il se trouve que le marché des API est plutôt très florissant, offrant de nombreuses possibilités que l’on peut combiner selon ses besoins.

Accessibles via HTTPS avec JavaScript, les API permettent réellement d’enrichir le site statique de base de fonctionnalités, à la fois pour l’internaute et le développeur/client.

Voici une liste non exhaustive de ce qu’il est possible d’ajouter :

• Envoi de formulaires
• Systèmes d’authentification
• Outils back-end + headless CMS
• Fonctionnalités e-commerce (panier, paiement, …)
• Ajout de commentaires et avis
• Fonctionnalité de recherche.

Pourquoi passer à un générateur de site statique ?

Si vous n’étiez pas encore convaincu, voici les principaux avantages des générateurs de sites statiques.

Vitesse

Puisque le contenu est statique, pas besoin d’aller le chercher dynamiquement dans une base de données, tout ce que le serveur a à faire est retourner le fichier correspondant. Ceci permet d’améliorer la vitesse de chargement, et même davantage si l’on utilise un CDN. A noter que la vitesse de chargement est un bon point en matière de SEO.

Contrôle de version de contenu

Les SSG peuvent s’utiliser avec un dépôt de fichiers versionnés tel que GIT ou Subversion qui permettent de gérer les différentes versions, de faciliter la correction d’erreurs ou encore d’aider au développement.

Sécurité

Avec des pages statiques, il n’y a pas d’interactions avec des bases de données ce qui réduit les risques de piratages (injections SQL, …). A ajouter que les SSG permettent d’éviter les attaques fréquentes que connaissent les CMS classiques.

Bonne gestion du trafic

Les sites dynamiques ont souvent du mal à gérer les pics de trafic car avec un grand nombre de requêtes vers la base de données, le serveur peut vite saturer, même avec des processus de mise en cache. Parce qu’ils n’ont pas ce genre de requêtes, les sites statiques peuvent donc généralement supporter plus de trafic. Bien sûr, cette capacité se réduit selon le nombre d’éléments dynamiques ajoutés à un site statique de base.

Ils peuvent être associés à des CMS

Comme nous l’avons mentionné dans la partie fonctionnement, il n’y pas de craintes à avoir pour l’utilisateur final du site. Les headless CMS propose les fonctionnalités permettant d’éditer les rôles et contenus de manière simplifiée.

Un écosystème qui grandit

JAMstack, APIs, headless CMS, nouveaux SSG… les solutions existantes pour améliorer l’expérience SSG se développent, en partie grâce à une communauté qui grandit elle aussi.

Meilleur contrôle sur les options du client

Une fois le site livré, le client peut souvent opérer certains changements « ruinant » votre beau travail avec les CMS classiques. Les sites statiques permettent de garder le contrôle sur divers éléments tels que le design ou l’installation de plugins, comme il est possible de le faire avec un CMS classique, mais aussi le changement de polices, l’ajout de couleur, etc.

Quels sont les inconvénients des générateurs de sites statiques ?

Parce que rien n’est jamais parfait, voici quelques inconvénients des générateurs de sites statiques.

Compétences techniques exigées

Un SSG demande un minimum de compétences en développement, d’autant plus que les ressources officielles ou en provenance de communautés sont moins courantes. Aussi, contrairement à un certain nombre de CMS dynamiques, un utilisateur sans compétences techniques ne pourra pas installer de thèmes ou plugins ce qui, une fois le site installé, pourra créer une certaine dépendance avec le développeur ou l’agence qui l’a réalisé.

Complexité du choix

Il existe beaucoup de générateurs de sites statiques, mais même les outils les plus populaires sont utilisés par une infime proportion de la communauté web. Vous aurez besoin de temps pour rechercher et évaluer les options. Le champion incontestable est aujourd’hui Jekyll mais, bien que vous n’ayez pas forcément besoin d’une expertise en Ruby, cela sera plus simple si vous avez déjà utilisé le langageauparavant.

Gérer des gros sites

Entre la grande quantité de pages, la haute fréquence de publication, le nombre important d’auteurs, la publication en temps réel… l’utilisation d’un générateur de sites statiques peut s’avérer bien plus complexe qu’un CMS classique car ces utilisations ne sont pas disponibles nativement et donc peuvent nécessiter de nombreux ajouts ou modifications.

Installation et mise en place légèrement longues et complexes

Si WordPress propose une installation en 5 minutes accessibles aux non-initiés, il en est tout autre pour les générateurs de sites statiques. En effet, il faut pour cela un minimum de compétences techniques et les étapes sont plutôt nombreuses : rien que l’ajout d’un headless CMS peut rallonger et complexifier ce temps d’installation.

Contenu dynamique en option

Un site statique de base n’est pas supposé contenir des éléments dynamiques, pourtant, il est courant de devoir y rajouter ne serait-ce qu’un formulaire de contact. Par conséquent, c’est encore du temps supplémentaire à y consacrer, comprenant la recherche d’une solution à implémenter ou à réaliser soi-même.

Quand utiliser un générateur de sites statiques ?

Les générateurs de sites statiques peuvent s’utiliser dans de nombreux cas, néanmoins certains nécessiteront plus ou moins d’ajustements, parfois conséquents, pour passer du statique pur à plus dynamique.

Voici quelques exemples d’utilisations possibles :

• Sites peu fréquemment mis à jours : site vitrine, portfolio, site concours ou campagne spécifique (lié à une action marketing)
• Documentation
• FAQs
• Blogs.

On aura plutôt tendance à préférer les CMS dynamiques ou frameworks si le contenu est révisé régulièrement, si l’utilisateur final doit avoir la main entière sur le site ou encore s’il s’agit d’un gros site, comme mentionné plus tôt.

Le tout est de savoir de quelles ressources vous disposez en termes de compétences, de temps ainsi que de moyens humains et financiers. Les générateurs de sites statiques sont souvent une bonne base pouvant être complétée mais à un certain coût (pas seulement financier), qui n’est parfois pas nécessaire voire non envisageable.

A savoir que la cible première est avant tout les développeurs, notamment pour leurs sites personnels. Mais avec l’évolution qu’ils connaissent, il se pourrait bien que les choses changent à l’avenir. Des sites d’entreprises sont d’ailleurs déjà réalisés via un SSG, comme Spotify for Developers, Twitch Developers ou encore Netflix Devices.

Les générateurs de sites web statiques les plus populaires en 2019

Le nombre de générateurs de sites statiques augmentent grandement depuis ces dernières années et ceux existants ne cessent de grandir. GitHub est d’ailleurs une ressource importante si vous en cherchez.

Pour faire votre choix, vous pouvez vous diriger vers Staticgen.com, qui offre une vue d’ensemble des SSG les plus populaires, notés et filtrable selon divers critères (langage de programmation utilisé, licence, moteur template).

Retrouvez les 10 générateurs de sites statiques les plus populaires en 2019 (sur staticgen.com) :

Conclusion

Il est vrai que les générateurs de sites statiques possèdent de bons arguments, particulièrement au niveau des performances. Ce point est d’ailleurs en enjeu majeur aujourd’hui puisque l’utilisateur souhaite pouvoir accéder rapidement au contenus en ligne. Il semble également que les grandes entreprises s’en préoccupent de plus en plus avec l’apparition d’applications lite ou même la création d’un moteur React Native permettant un affichage plus rapide sur des smartphones d’entrée de gamme.

S’ils sont encore méconnus du grand public, il semble que les SSG aient de plus en plus la côte auprès des développeurs. L’évolution de ces solutions ne risque donc pas de s’arrêter de sitôt ! Dans un avenir pas si lointain, les générateurs de sites statiques pourraient même s’inviter progressivement dans la création de sites web pour les entreprises.

Cet article Générateurs de sites statiques : bonne ou mauvaise idée ? est apparu en premier sur Apollo Formation.

C’est une des grandes annonces de la Chain React Conference de cette année : Facebook sort en open source un nouveau moteur JavaScript baptisé Hermes. Déjà adopté par le réseau social, il cible les applications Android développées sous React Native, le framework cross-platform destiné au développement mobile.

Hermes, qu’est-ce que c’est ?

Hermes, c’est le nouveau moteur JavaScript optimisé pour les applications Android développées sous React Native. Rendu open source par Facebook ce mois-ci, il arrive avec une belle promesse : améliorer les performances des applications React Native Android et les rendre plus accessibles pour les smartphones d’entrée de gamme.

Nouvel outil pour les développeurs, il améliore les performances des applications en travaillant trois points clés :

• Réduire le Time to Interaction (TTI), soit le temps qui s’écoule entre le lancement de l’application et le moment où l’on peut réellement l’utiliser ;
• Diminuer la taille de l’application, plus précisément de l’APK sous Android, à savoir le fichier téléchargé puis installé via le store d’applications ;
• Réduire l’utilisation de la mémoire du smartphone.

Il est surtout dédié aux grosses applications notamment très populaires comme Spotify, Uber ou encore Facebook lui-même. De plus en plus conséquentes, celles-ci peuvent parfois poser problème, particulièrement pour les smartphones dont la capacité de stockage et/ou les performances sont limitées.

Si les versions lite semblent se démocratiser, ce moteur JS est aussi un moyen de s’adapter aux smartphones d’entrée de gamme, pourtant bien présents chez les utilisateurs.

Hermes possède son propre compte Twitter ainsi qu’un site web officiel. Son code source est quant à lui disponible sous licence MIT sur le GitHub de Facebook/hermes.

Une annonce à la Chain React Conference & une release le jour-même

Hermes a été dévoilé lors de la Chain React 2019, la conférence consacrée à React Native à Portland (Oregon, USA).

Lors de cette présentation, Marc Horowitz, un ingénieur logiciel de chez Facebook, a notamment montré une vidéo présentant, de manière concrète, l’apport de ce nouveau moteur.

On y constate facilement la différence de temps d’ouverture entre une application utilisant Hermes et un autre moteur classique, soit environ moitié moins de temps (3s contre 6s).

Pour cet exemple (voir ci-dessous), l’application utilisée était Mattermost en version beta, ouverte sur un Google Pixel de 2016. Hermes est utilisé sur la gauche.

Dans le même temps, la nouvelle se rependait sur les réseaux sociaux, notamment Twitter sur la page de React Native :
 

Traduction : Facebook sort aujourd’hui en open source Hermes, un moteur JavaScript petit et léger, optimisé pour exécuter React Native sur Android. Nous sommes actuellement en train de publier un nouveau patch pour React Native qui contiendra Hermes comme opt-in.

Quelques instants plus tard, React Native sortait en version 0.60.2, incluant le moteur Hermes en tant qu’opt-in. Une documentation fut également mise à disposition pour l’utiliser.

Pourquoi Hermes ?

En analysant les données de performance de ses applications, Facebook s’est rendu compte que le moteur JavaScript utilisé pouvait jouer un rôle important, notamment au niveau du lancement de l’application et de la taille de l’application.

Il se trouve qu’Addy Osmni, un ingénieur manager de chez Google, avait lui aussi fait des observations, sur le moteur JavaScript V8. Selon lui, le V8 passe beaucoup de temps à parser et à compiler le code JavaScript avant de l’exécuter, ce qui aurait tendance à augmenter la durée de lancement des applications mobiles. Il a évalué que ces phases qui précèdent l’exécution d’instructions d’architectures pouvaient être 2,5 fois plus longues sur mobile que sur desktop.

Hermes veut donc pallier à ce problème de lenteur sur mobile, d’autant plus flagrant sur les smartphones d’entrée de gamme, probablement la principale cible du moteur.

 « En tant que développeurs, nous avons tendance à avoir les derniers appareils phares. Ce n’est pas le cas pour la plupart des utilisateurs à travers le monde. Les appareils Android les plus couramment utilisés possèdent moins de mémoire et de stockage que les smartphones les plus récents et encore moins qu’un ordinateur. »

– Marc Horowitz, Chain React Conference 2019.

Comment fonctionne Hermes ?

Habituellement, les moteurs JavaScript parsent la source JavaScript après qu’elle soit chargée, générant ainsi du bytecode, ce qui se traduit souvent par un délai dans l’exécution du code JavaScript.

Hermes quant à lui, utilise un compilateur anticipé lors du processus de création de l’application. Ceci permet notamment de gagner du temps lors de l’ouverture de l’application mais aussi de pouvoir obtenir un bytecode plus optimisé en terme de taille et d‘efficacité.

Un autre élément important dans le fonctionnement d’Hermes, c’est qu’il n’utilise pas de compilateur juste-à-temps (JIT), bien qu’ils soient souvent utilisés par les autres moteurs JavaScript. Dans son annonce, Facebook dit avoir fait quelques tests qu’il serait difficile d’obtenir de réel améliorations au niveau de la vitesse sans porter atteinte aux 3 principaux aspects qu’ils ont choisi de travailler (voir les « points clés » dans Hermes, Qu’est-ce que c’est ?).

Enfin, Facebook a choisi de mettre en place un Garbage Collector (ou ramasse-miettes) pour réduire la mémoire et l’adresse virtuelle utilisées par le moteur, qui, si trop importants, peuvent enclencher la fermeture de l’application par le système d’exploitation.

Vous possédez des bases en JavaScript et envisagez de débuter le développement mobile : nous proposons une formation React Native de 4 jours où vous pourrez apprendre à développer des applications mobile avec le framework de Facebook !

Les choix réalisés par Facebook pour construire ce moteur JavaScript semblent effectivement améliorer les performances de l’application, au moins sur son lancement. C’est aussi ce que semblent dire les données communiquées par Facebook sur l’exemple de l’application Mattermost sur un Google Pixel.

Il permettrait dans cet exemple de diminuer le TTI de 2,29s, de réduire la taille de l’application de 19 Mo et enfin d’utiliser 49 Mo de mémoire en moins.

Pour en savoir plus sur la manière de fonctionner de ce moteur, n’hésitez pas à vous rendre sur l’article rédigé par Marc Horowitz ou de consulter directement le code source sur GitHub.

Hermes : Migration et compatibilité

Hermes est disponible pour React Native à partir de la version 0.60.2.

Pour l’activer, il suffit de l’activer via le fichier build.gradle. Pour en savoir plus, rendez-vous sur la documentation officielle (extrait ci-dessous).

Hermes est globalement compatible avec JavaScript ES6 mais pas entièrement : pour que ce moteur reste léger, Facebook a fait le choix de ne pas inclure toutes les fonctionnalités, retirant celles qui ne semblaient pas être communément utilisés dans les applications React Native.

Ainsi, une liste des éléments non supportés et des incompatibilités connus est accessible sur GitHub. Les développeurs sont également sollicités à communiquer toute anomalie ou bug qu’ils pourraient rencontrer.

L’avenir d’Hermes

Afin d’améliorer Hermes, Facebook a déjà annoncé souhaiter intégrer Visual Studio Code, lui permettant de proposer davantage d’outils aux développeur. Egalement dans cette optique, le moteur devrait s’accompagner d’outils de profilage, facilitant ainsi la compréhension et l’amélioration des applications.

Il semblerait cependant qu’Hermes reste dédié aux applications React Native seulement : aucune intégration n’est prévue pour les navigateurs web ou les infrastructures serveurs comme Node.js. Néanmoins, il ne serait pas impossible de voir le moteur évoluer pour s’intégrer aussi sous iOS. Cela viendrait finalement dans la continuité de React Native qui se veut cross-platform.

Pour conclure…

Le moteur JavaScript Hermes est encore très récent mais semble plutôt convaincre ceux l’ayant utilisé. Le projet a pour l’instant réuni plus de 3 000 étoiles sur GitHub et se classait 17^ème des dépôts JS à la mi-juillet selon Syndicode.

Néanmoins, ces cas d’utilisation sont plutôt restreints : son succès sera donc étroitement lié à celui de React Native, même si son arrivé pourrait justement encourager à l’utilisation du framework.

Seul l’avenir pourra finalement nous dire si Hermes sera réellement adopté au sein de la communauté. Facebook en est dans tous les cas le premier utilisateur, ce qui pourrait l’amener à évoluer assez régulièrement compte tenu des enjeux de l’entreprise.

Regardez ci-dessous la présentation du moteur JavaScript Hermes à la Chain React Conference (2019) :

Cet article Hermes : le moteur React Native léger et open source de Facebook est apparu en premier sur Apollo Formation.

Comment continuer à apprendre et s’améliorer tout au long de sa carrière de développeur ou développeuse ? Au-delà de la formation professionnelle et continue, certaines bonnes pratiques peuvent vous permettre d’avancer plus vite ou simplement de travailler plus sereinement. Ces conseils s’adressent à la fois aux débutants et développeurs aguerris, qui pourront y trouver quelques pistes pour gagner en performance et efficacité. Rien ne remplace l’expérience, mais il y a parfois des raccourcis. Voici donc, en vrac, 50 trucs et astuces pour faciliter la vie des professionnels du développement logiciel.

1. Maîtriser la recherche Google

Faire de la programmation, c’est apprendre à trouver les réponses à ses questions. Utiliser Google à bon escient vous fera gagner un temps précieux dans vos développements. Une commande qui peut être utile : pour effectuer une recherche sur un site en particulier, tapez « site:lesitequivousinteresse.com » suivi de vos mots-clés pour limiter la recherche à un seul domaine.

2. Analyser avant de coder

Une erreur souvent commise est d’écrire du code trop rapidement. Prenez le temps d’analyser le problème à résoudre avant de coder ne serait-ce qu’une seule ligne. Une bonne pratique consiste à écrire votre code sur une feuille de papier, cela permet de mieux réfléchir en amont et de ne pas vous lancer la fleur au clavier.

3. Faire de la veille…

La veille consiste à se tenir au courant des innovations et meilleures pratiques dans un certain domaine. La vitesse à laquelle les technologies informatiques évoluent rend la chose indispensable en développement : nouveaux langages, frameworks et autres outils de développement, se tenir au courant des nouveautés peut grandement aider. Même si vous ne comprenez pas tout ou ne mettez pas directement en pratique ce que vous lisez, cela peut aider de simplement savoir que telle ou telle chose est possible, ou que des outils existent pour le jour où vous rencontrerez un certain problème.
 
Vous pouvez consulter notre article de blog et obtenirdes conseils pour réaliser une bonne veille technologique.

4. …sans chercher à tout connaître

Pour autant, il n’est pas nécessaire voire contre-productif de vouloir tout apprendre et tout savoir. La quantité d’information disponible croît de manière exponentielle, il vous faudrait plusieurs vies pour maîtriser l’ensemble du domaine infiniment vaste dans lequel vous évoluez. Heureusement, Internet est là, et d’autres personnes plus spécialisées peuvent vous aider à résoudre un problème, ne vous en privez pas !

5. Utiliser Git

Autrement dit, versionnez votre code. Git est simplement le logiciel de versionning le plus utilisé à ce jour, et ce n’est pas pour rien : fonctionnelle, performante, sécurisée et flexible, la solution est idéale pour bon nombre d’équipes de développement.

6. Nettoyer les branches de ses projets

Une fois que vous utilisez un logiciel de gestion de versions, faîtes-le de manière appropriée et ne partez pas dans tous les sens. Nettoyer vos dépôts et branches comme si vos beaux-parents devaient leur rendre visite. Vous n’en avez plus besoin, supprimez-les, ne les mettez pas dans un coin de placard.

7. Refactorer son code

Vous trouvez votre code « sale » ou incompréhensible ? Une nouvelle fonctionnalité doit être ajoutée, une nouvelle architecture pour votre application est prévue ? Les raisons pour refactorer son code sont multiples. Les bénéfices tout autant. Au-delà d’un code propre (ce à quoi le client n’accorde en général que peu d’importance), cela fait partie de l’hygiène de vie de votre application, de sa bonne santé. Le travail futur n’en sera que facilité, pour un gain de temps certain, pour vous comme pour celui ou celle qui passera derrière.

8. Pratiquer le pair-programming, ou programmation en binôme

 

 
En jouant le rôle du driver ou du navigateur, le pair-programming est une très bonne pratique pour améliorer la qualité des développements et diffuser les connaissances au sein d’une équipe.

9. Toujours penser à commenter son code

Alors oui, c’est sûrement quelque chose que vous avez entendu 36’000 fois depuis vos débuts en programmation. Mais l’intérêt d’ajouter des commentaires lorsqu’on code n’est pas simplement d’aider à la compréhension, c’est aussi un moyen de réfléchir à l’utilité et à la fonction des prochaines lignes à écrire. Définir un but est la clé, un seul but : on évite de créer la superfonctionmultitacheduturfu() ! Commenter chaque bout de code permet d’isoler les différents éléments de votre application, pour les réutiliser ou débuguer plus facilement.

10. Accepter des tâches qui font peur

Sortir de sa zone de confort, pour mieux grandir. Si ce que vous faîtes au jour le jour ne vous challenge pas plus que ça, c’est que vous n’apprenez pas grand-chose…

11. Promettre moins, livrer plus

Il est préférable de dire à votre équipe qu’une certaine tâche vous prendra 3 semaines et de la finir en 2 que l’inverse. Gagnez la confiance de vos pairs en évitant de promettre monts et merveilles sans être sûr de pouvoir tenir vos engagements.

12. Avoir une boîte à outils fonctionnelle

Ayez un ensemble d’outils de développement que vous aimez et que vous maîtrisez. IDE, outils de build, de packaging, gestionnaire de code ou serveur d’intégration continue, l’âge de pierre du développement logiciel est terminé et il existe aujourd’hui une batterie de programmes pouvant vous aider à travailler plus efficacement. Testez-les, adoptez-les, essayez-en de nouveaux, partagez-les… ces outils vous rendront la vie bien plus facile. Pensez également aux outils de productivité et de collaboration tels que Trello, Slack ou Asana.

13. Sortir des sentiers battus

Ne cherchez pas par tous les moyens à résoudre votre problème avec les outils ou techniques que vous maîtrisez. Si votre stack favorite vous permet souvent d’arriver à vos fins, cela ne veut pas dire que c’était le meilleur moyen d’y parvenir. Fondamentalement, votre métier consiste plus à trouver des solutions qu’à écrire du code : comprendre quand utiliser quelle technologie ou méthode, quelle est la plus efficace et pourquoi fera de vous un meilleur développeur. Faîtes grandir votre équipe en proposant des solutions innovantes et peut-être plus efficaces que celles que vous utilisez d’habitude.

14. Participer à la vie d’une communauté

En ligne ou dans la vie réelle, entourez-vous de personnes ayant les mêmes centres d’intérêt que vous (que ce soit dans le domaine du développement logiciel ou pas d’ailleurs). Prendre part à la vie d’un groupe peut s’avérer très enrichissant et c’est souvent une excellente source de motivation. C’est un très bon moyen pour faire vivre sa passion, échanger des bonnes pratiques, trouver de l’aide ou simplement rencontrer de nouvelles personnes.
Le site Stack Overflow par exemple est plein de solutions et conseils de développeurs et développeuses, pour vous aider à prendre un problème par le bon bout.

15. Ecrire des mails précis et utiles

Apprenez à captiver vos lecteurs en étant clair et succinct dans vos mails. Un projet informatique réussi implique une communication saine et productive. Personne n’a envie de lire un mail à rallonge et bourré de fautes d’orthographe. Soignez vos écrits comme vous soignez votre code !

16. Comprendre les user stories avant de démarrer

Cela vous fera gagner un temps précieux. Ne vous lancez pas sans avoir réellement compris quelle est l’utilité finale de la fonctionnalité à développer. Dans une démarche agile, la formalisation des critères d’acceptation (qui découlent des user stories) est d’ailleurs indispensable sous peine de passer à côté d’un quelconque bénéfice.

17. Ne jamais perdre de vue les besoins du métier

Plus généralement, tâchez de toujours garder en tête que la solution que vous développez servira un ou plusieurs métiers spécifiques. Au sein d’une entreprise ou même chez un client, la collaboration avec des personnes du marketing, des ressources humaines ou encore avec la direction est donc essentielle. Cela vous permettra d’avoir de nouveaux points de vue sur votre activité et de développer vos compétences transverses.

18. Jouer collectif

 

 
Le développement n’est pas un métier individuel. Vous travaillez ou serez amené à travailler en équipe, même en tant que freelance (Rome ne s’est pas construite avec une seule paire de bras). Que ce soit sur un centre de services, en visioconférence ou dans une équipe projet, les personnes qui vous entourent vous apporteront toujours : un regard neuf sur un problème, un encouragement, un nouvel outil, une bonne pratique… Allez vers les autres, échangez avec eux, tout le monde en ressortira grandi.

19. Communiquer de manière claire, précise et professionnelle

Et pour évoluer en équipe, le plus important est sûrement de communiquer efficacement. La communication, écrite comme orale, est au cœur des méthodes modernes de développement logiciel : mêlées quotidiennes, réunions de lancement de projet, brainstorming ou encore clôture de phase, les occasions de prendre la parole et d’échanger avec les collègues ne manquent pas. Renseignez-vous sur les meilleures pratiques de communication, et mettez les en application dès que possible.

20. Pratiquer, pratiquer et pratiquer encore

On ne le dira jamais assez, mais la meilleure alliée dans votre progression est votre propre expérience. Faîtes des essais, échouez, recommencez, réussissez, ou pas, l’important est de mettre les mains dans le cambouis ! Si l’expérience est partout valorisée, ce n’est pas pour rien : pratiquer permet de connaître les réelles difficultés du métier, d’apprendre à résoudre les problèmes (algorithmiques ou autres) et de se constituer un bagage professionnel.

21. Se lancer dans un projet personnel

Un point relatif au précédent : un projet personnel vous permettra de mettre en pratique vos connaissances sur quelque chose d’amusant pour vous et qui vous intéresse. Vous pouvez cloner une application existante, un site web ou encore inventer votre propre programme. L’important étant de diversifier vos pratiques, en travaillant sur un projet qui vous tient à cœur et que vous ne percevrez pas comme une contrainte.

22. S’auto-former

Dans le domaine du développement logiciel, acquérir de nouvelles compétences en apprenant par soi-même permet d’évoluer plus rapidement. Obtenir de bonnes notes lors de ses études ne suffit pas, puisque 5 ans plus tard beaucoup de ce que vous aurez appris sera dépassé ou sur le point de l’être. Faîtes vos propres recherches, suivez des formations en ligne et mettez le tout en pratique sur des projets réels. Soyez acteur de votre propre développement !

23. Contribuer à des projets open source

Cela vous permettra d’améliorer grandement vos pratiques et connaissances en tant que développeur ou développeuse. Trouvez un projet qui vous passionne, corrigez le code, envoyez un patch. C’est aussi simple que cela. Pas besoin d’avoir des années d’expérience : de nombreux projets de développement ont des bugs marqués comme mineurs, faciles ou encore « junior jobs » (« boulots pour débutant »).
 
Et pour celles et ceux qui ont du mal à se lancer : ce témoignage d’une débutante dans le monde de l’open source peut vous aider à dépasser votre appréhension.

24. Trouver un mentor

Rapprochez-vous d’une personne plus expérimentée, dans le milieu professionnel depuis quelques temps. Il ou elle pourra vous donner de précieux conseils, tant au niveau de votre carrière que sur le plan technique. Rendez-vous à des meetings, conférences, afterworks, demandez conseil à un collègue, parcourez les réseaux sociaux ou bien des sites comme Coding Coach pour trouver la personne qui vous guidera pendant une partie de votre parcours.

25. Être un mentor

A l’inverse, si vous êtes dans le développement logiciel depuis plusieurs mois voire années, il peut être très bénéfique pour vous d’accompagner quelqu’un de moins expérimenté. Soyez celui ou celle auprès de qui on peut apprendre et échanger des idées.

26. Partir à la chasse aux bugs

Il est certainement plus intéressant de se lancer dans la création de nouvelles fonctionnalités, mais ce n’est pas forcément le meilleur moyen pour se familiariser avec un nouveau code source. Parcourir le code en cherchant les bugs vous forcera à plonger dans une application, ce qui vous aidera à mieux appréhender son architecture. Plus vous serez familier avec celle-ci et plus vous serez productif par la suite. Ne fuyez pas les bugs, sautez plutôt dessus dès que vous en avez l’occasion.
 

27. Prendre des notes

Il n’y a pas de question bête. Mais si vous l’avez déjà posée, elle le devient la deuxième fois… Au cours de votre carrière, vous allez apprendre tellement de choses qu’il sera impossible de tout retenir. Et sur un même projet, vous pouvez également vous demandez deux fois la même chose. Les gens sont souvent enclins à vous aider, mais il faut éviter de poser les mêmes questions à répétition : pensez à écrire la solution à un problème susceptible de se représenter.

28. Bien nommer ses variables et fonctions

Nommer les choses peut s’avérer particulièrement difficile. C’est encore plus vrai en informatique : des noms de variables ou fonctions qui ont du sens sont parfois durs à trouver, surtout pour les langages dynamiques où vous n’avez pas de types définis pour vous aider à comprendre les variables. Pensez donc toujours à trouver des noms qui indiquent avec précision le but de votre variable ou fonction, et évitez maVariableTropBien…
 

29. Accepter de ne pas savoir

N’ayez pas honte d’admettre quand vous ne savez pas quelque chose. En tant que dev, vous êtes constamment en train de résoudre de nouveaux problèmes et on ne peut pas attendre de vous que vous sachiez tout tout de suite. Chercher à cacher son ignorance ne fait que ralentir l’apprentissage.

30. Prendre du recul et se concentrer sur la résolution de problèmes

Apprendre un langage de programmation et apprendre à programmer sont deux choses bien distinctes. Préférez étudier les techniques de programmation, travailler la résolution de problèmes ou vos capacités d’analyses plutôt que d’essayer d’apprendre le plus de langages possibles.

31. Partager ses connaissances

Lorsque vous partagez vos connaissances, vous en acquérez souvent de nouvelles. Cela permet aussi de prendre du recul et de mettre à plat tout ce que vous savez. Peu importe que ce soit via un blog, une chaîne YouTube, un cours sur Udemy ou un article Medium, Internet offre une infinité de possibilités.

32. Être ouvert d’esprit

La technologie évolue, et elle évolue rapidement. Ne soyez pas réticent ou fermé aux nouveautés du monde du développement et préférez apprendre à les découvrir avant de vous faire une opinion.

33. Se constituer un portfolio convaincant

Lorsque vous postulez à un nouveau job, un portfolio contenant vos plus belles réalisations peut être un très bon atout pour vous distinguer des autres candidats. Cela permettra à votre futur employeur de se faire une idée concrète de ce que vous êtes en capacité de réaliser. Outre un joli CV et une lettre de motivation bien rédigée, pensez donc à avoir sous la main un portfolio à jour pour mettre en avant vos compétences et les projets sur lesquels vous avez travaillé.

34. Apprendre à faire des présentations

 

 
Pour vendre votre expertise ou votre produit, en rendez-vous client ou pour votre direction, il arrivera un moment où vous aurez besoin de présenter votre travail à quelqu’un. Réaliser une bonne présentation, au bon moment, peut vous ouvrir des portes ou au moins faire valoir vos compétences. Sachez vous adresser à une audience en étant à l’aise, adaptez votre discours à vos interlocuteurs et transmettez des informations de manière concise et pertinente, c’est un formidable atout !

35. Apprendre à gérer son stress

Travailler sous la pression des délais est monnaie courante dans un projet informatique. Dépasser ces délais peut engendrer une mobilisation de ressources supplémentaires et influera sur les budgets alloués. La pression qui s’exerce alors sur les individus est souvent source d’un stress pesant et parfois synonyme d’une baisse de la productivité. Apprendre à bien gérer cette pression, en identifiant les facteurs de tension et en les adressant de manière sereine vous permettra de ne plus en subir les effets négatifs.
 

36. Avoir des plages horaires dédiées au code

Dans un environnement de travail, il est très courant d’être distrait, interrompu ou dérangé par des réunions, mails et autres demandes diverses de collègues. Ayez des temps dédiés au code et juste au code pendant votre journée. Le temps total passé à coder n’a que peu d’importance s’il est constamment entrecoupé ne serait-ce qu’une ou deux minutes.

37. Se spécialiser

Il y a tellement de sous-domaines en informatique qu’il peut être tentant de vouloir apprendre à faire plein de choses différentes. Mais les entreprises recherchent et paient mieux quelqu’un qui excelle dans un certain domaine. Il vaut donc mieux être expert sur une technologie en particulier que de toucher à tout.

38. Rester positif

 

 
La réussite est constituée de plusieurs étapes. Vous ne pouvez pas devenir un expert ou une experte de la programmation en une journée. Ni en une semaine, un mois ou même un an. C’est un long chemin, très sympa à parcourir mais parsemé d’embûches. Votre carrière dans le développement logiciel vous mènera de stagiaire à mentor, vous passerez par des phases de doute, d’exaltation, d’agitation, d’énervement, d’enthousiasme… L’important est de toujours croire en vos capacités, c’est ainsi que vous continuerez à progresser.

39. Automatiser

L’automatisation logicielle est devenue un outil essentiel dans l’industrie IT. Avec l’évolution rapide des architectures informatiques, les entreprises ont un besoin accru de flexibilité. Même constat à l’échelle individuelle : utiliser des technologies pour effectuer certaines tâches répétitives vous permettra d’être plus agile, et de gagner un temps précieux. Automatiser le pipeline de build, certains développements ou tests logiciels vous libérera du temps pour vous concentrer sur des tâches plus intéressantes, et surtout plus gratifiantes.

40. Développer des connaissances sur son domaine d’activité

Vos compétences techniques sont votre fer de lance. Mais vous ne deviendrez pas meilleur programmeur ou programmeuse en vous contentant de programmer. Connaître votre secteur et ses spécificités peut vous permettre de progresser : quels sont les différents métiers qui le composent ? Comment utilisent-ils les solutions logicielles ? Dans quel but ? Quelles sont les entreprises qui dominent le marché ? Pourquoi ? Plus vous vous intéressez à l’industrie dans laquelle vous évoluez plus votre travail sera pertinent.

41. Se fixer des objectifs

Que ce soit en équipe ou individuellement, la mise en place d’un processus de développement qui tient la route est fondamentale. En particulier, définir des objectifs clairs permettra de ne pas s’égarer et d’atteindre plus rapidement le but recherché. Vous pouvez pour cela utiliser la technique des objectifs SMART, qui vise à mieux comprendre et appréhender le résultat escompté. Ecrire une simple liste de choses à faire pendant la journée peut déjà se révéler très efficace !

42. Varier les paradigmes de programmation

Programmation orientée objet, fonctionnelle, concurrentielle, déclarative… chaque paradigme de programmation amène sa propre philosophie. En pratiquant différentes approches, vous acquerrez une meilleure compréhension de l’ensemble : étudier un certain paradigme améliorera votre façon de programmer avec un autre.

43. Apprendre à déchiffrer le code des autres

Cela peut paraître trivial, mais lire le code d’un autre développeur ou d’une autre développeuse ne va pas forcément de soi. Surtout s’il est écrit dans un langage sur lequel vous n’avez pas l’habitude de travailler. Chacun a sa propre manière de programmer, son propre style et tout le monde ne code pas de la manière la plus efficace possible. Apprenez à analyser du code et sachez déterminer si la façon dont un problème a été résolu est la meilleure.

44. Ne pas réinventer la roue

C’est un peu une règle d’or en informatique. A force d’être confrontés à des problèmes récurrents, les informaticiens et informaticiennes ont mis au point des méthodes et outils dédiées à leur résolution. Que vous ayez des difficultés à designer un bout de votre application, ou à écrire une requête pour fouiller dans une base de données, tachez d’appliquer ce principe : partir d’une solution existante et construire la vôtre par-dessus. Un framework est quelque part une roue inventée par quelqu’un et qui permet à d’autres de ne pas tout recommencer.
 

45. Prendre des pauses

En programmation, lorsqu’on bloque sur un certain problème, la meilleure chose à faire est parfois de se lever un coup, s’étirer, boire un verre d’eau et faire autre chose pendant 5 minutes avant de se remettre au travail. Fixer son écran pendant de longues minutes ne permet que très rarement d’arriver à une solution…

46. Respecter les conventions de codage

Il existe bon nombre de documents recensant les conventions de codage, ou bonnes pratiques pour l’écriture du code dans un langage donné. Le Style Guide pour Python, celui pour le langage Ruby ou encore les recommandations standards PHP sont des exemples parmi d’autres. Ces conventions peuvent paraître effrayantes mais une fois maîtrisées (dans les grandes lignes), elles garantissent au sein d’une équipe de développement une certaine cohérence et facilité de relecture du code.

47. Faire de l’exercice physique

Votre métier, comme beaucoup d’autres d’ailleurs, vous oblige à rester en position assise généralement jusqu’à 7 à 8 heures par jour. Sur le long terme, cela peut être très mauvais pour votre santé (mal de dos, posture avachie…) : trouvez un sport que vous aimez et qui vous permette de compenser cela, votre corps et votre esprit vous diront merci !

48. Se reposer les yeux

7 à 8 heures assis, c’est aussi 7 à 8 heures devant un écran… C’est déjà bien assez (trop !), évitez de rentrer à la maison et de vous asseoir devant votre PC ou votre télé. Si la tentation est trop forte, il existe des filtres à installer sous forme de logiciels, pour ménager vos yeux et éviter une surexposition à la lumière bleue.

49. Se tromper, et se tromper encore

On ne réussit jamais du premier coup. Encore moins en programmation. Mais si quelque chose plante, bug, ça ne veut pas dire que tout est à jeter. Les plus grands accomplissements ont été précédé de multiples échecs. Les voir comme une avancée vers votre objectif vous permettra de toujours continuer à apprendre, et de les utiliser pour ne pas commettre les mêmes erreurs plusieurs fois.

50. Aimer son travail !

Gagner sa vie en programmant n’est pas donné à tout le monde. N’importe qui peut coder, mais en faire une carrière c’est autre chose. Il faut de la passion et une continuelle soif d’apprendre : la technologie avance vite et si vous n’aimez pas découvrir de nouvelles choses vous serez vite dépassé. Il est donc important d’apprécier ce que vous faîtes au quotidien : apprendre à coder pour gagner de l’argent est incohérent et ne durera pas très longtemps…

Disclaimer : ces conseils et bonnes pratiques sont principalement issus de recherches sur le net, et non de l’expertise technique (largement contestable) de leur auteur. Merci d’être arrivé jusqu’ici et bonne chance à toutes et à tous pour ce sinueux mais passionnant parcours qui vous attend !

Cet article 50 conseils pratiques pour les développeurs et développeuses d’aujourd’hui est apparu en premier sur Apollo Formation.

Le petit nouveau du développement mobile commence à faire grand bruit. Flutter, framework signé Google et dédié à la création d’applications Android et iOS (avec un code commun !) est proposé en version stable depuis décembre 2018. Les premiers retours des développeurs sont élogieux, pour un outil qui s’annonce comme une révolution. Après Xamarin, Cordova ou React Native, découvrons ensemble la nouvelle star du développement cross-platform.

Petite histoire du développement mobile

Depuis le début des années 2010 et l’avènement des terminaux mobiles, le marché des applications dédiées en est pleine expansion. Pour répondre à la demande croissante des entreprises et utilisateurs finaux, les développeurs ont besoin de technologies robustes, efficaces et qui limitent les coûts de développement.

Parmi les nombreuses manières de développer des applications mobiles, le développement en natif est jusqu’alors le plus répandu. Appréciées pour leur facilité d’intégration au système d’exploitation et de bonnes performances, les applications natives ont toutefois un inconvénient intrinsèque majeur : elles ne fonctionnent que sur la plateforme à laquelle elles sont destinées.

Sur un marché coupé en deux (Android et iOS), beaucoup de développeurs se sont donc tournés vers les outils de développement multiplateforme comme Xamarin, Cordova, Ionic et plus récemment React Native. Pour les entreprises, c’est un excellent moyen de réduire les coûts et délais de développement : l’application est codée une seule fois et tourne aussi bien sur Android que sur iOS.

Pas mal, mais loin d’être suffisant : l’UX est certes convenable, les coûts et durées de développement réduits, mais le bât blesse côté performances. On est encore loin du natif. C’est là qu’entre en jeu Flutter, framework propulsé par Google et qui pourrait bien changer la donne.

Pour celles et ceux d’entre vous qui sont déjà convaincus et souhaitent acquérir des compétences concrètes dans l’utilisation du framework de Google : nous proposons une formation Flutter de 3 jours pour apprendre à développer des applications ultra-modernes !

Qu’est-ce que Flutter ? Particularités et atouts pour le développement mobile

Flutter est donc un framework open source conçu par Google et destiné au développement d’applications multiplateformes. Jusque-là rien de révolutionnaire, mais nous verrons que côté programmation, certaines fonctionnalités peuvent s’avérer très intéressantes.

De la programmation réactive, mais sans bridge JavaScript

Les frameworks de développement multiplateforme comme PhoneGap, Cordova ou Ionic utilisent le langage JavaScript et les WebViews. Pour faire simple, les applications conçues avec ces outils sont basées sur les technologies web bien connues (HTML, CSS et JavaScript), mais nécessitent un « pont » pour faire le lien avec le code natif.

Ce bridge JavaScript n’était au départ pas si gênant que ça, jusqu’à l’apparition des vues réactives. Celles-ci simplifient la création des WebViews, via des patterns de développement empruntés à la programmation réactive. En 2015, React Native est lancé par Facebook et apporte au monde mobile tous les bénéfices de ces vues réactives : via du code JavaScript, il devient possible de concevoir des apps à l’UI quasi-native.

Problème, ce paradigme de programmation implique un passage par le pont JavaScript bien plus fréquent : jusqu’à 60 fois par seconde. Les performances en pâtissent, et les développeurs React Native doivent architecturer leurs applications de façon à réduire ces transitions entre JavaScript et natif au minimum.

A l’instar de React Native, Flutter fournit des vues réactives. Mais grâce à l’utilisation d’un langage compilé, Dart, plus besoin de passer par le pont. Flutter est aujourd’hui le seul SDK mobile qui fournit des vues réactives sans code interprété, et côté performances il n’y a pas photo !

Également développé par Google, Dart commençait à tomber dans l’oubli, mais le langage de programmation connaît un regain de popularité avec l’arrivée de Flutter. Il est en fait l’une des principales raisons du succès de Flutter auprès des développeurs.

Le langage Dart, véritable atout pour Flutter

Contrairement à JavaScript, Dart est un langage statiquement typé, basé sur des classes et dont les fonctionnalités en font un outil très puissant pour Flutter :

• Dart peut fonctionner en mode AOT (Ahead Of Time), c’est-à-dire que le langage est compilé en un code natif, optimisé pour la plateforme visée. Cela rend non seulement Flutter ultra-rapide, mais quasiment tout au sein du framework (notamment les widgets) peut être personnalisé.
• Dart peut également être compilé JIT (Just In Time). Une compilation à la volée, qui se fait lors de l’exécution d’un programme et qui permet des cycles de développement bien plus rapides et des workflows optimisés (cf. le fameux Hot Reload, abordé un peu plus bas).
• La création d’animations et de transitions à 60fps est également facilitée grâce à Dart. Le langage est en effet très performant pour l’allocation d’objets et son garbage collector à générations (qui élimine les objets en mémoire non utilisés) particulièrement efficace.
• Dart permet également à Flutter d’éviter le recours à un langage de balisage comme JSX ou XML. Pas besoin non plus d’un outil spécial pour la création d’interfaces, qui se fait entièrement via du code Dart.

Finalement, notons qu’apprendre à programmer en Dart est plutôt aisé. Pour les développeurs ayant l’habitude de langages comme C#, Java ou même JavaScript, la syntaxe de Dart devrait paraître familière. Le DartPad est à ce propos un outil bien utile pour s’entraîner.

En soi, les particularités du langage Dart font déjà de Flutter un outil intéressant et qui vaut le coup d’être testé. Mais il y a mieux : la manière dont le framework implémente les widgets.

Des widgets, encore des widgets et toujours des widgets

L’un des principes fondamentaux de Flutter est que tout est un widget. Vraiment tout. La classe de l’application est un widget, la structure de l’interface est un widget, le texte affiché est un widget, les images sont des widgets, les boutons, le padding… bref, vous avez compris l’idée.

Chaque widget a une tâche bien particulière et affecte une petite partie de l’UI. Créer une interface utilisateur en Flutter revient alors à assembler des widgets. Et c’est aussi simple que ça en a l’air. D’autant plus que le SDK contient une large variété de widgets intégrés, et déjà stylisés Android ou iOS.

Imaginez que vous démarriez un projet React, Vue ou React Native avec à disposition des centaines de composants tout prêts et qui respectent le design habituel de la plateforme visée. C’est ce qu’apportent les deux ensembles de widgets Material Design (pour Android) et Cupertino (iOS), qui permettent d’implémenter très facilement à peu près n’importe quel élément. Créer des applications mobiles aussi jolies qu’intuitives n’a jamais été aussi simple, surtout qu’il est également possible d’étendre et de personnaliser les widgets à volonté.

Contrairement à d’autres frameworks qui séparent les vues, contrôleurs, layouts et autres propriétés, Flutter fonctionne donc selon un modèle cohérent et unifié.

Hot Reload mon amour

Autre fonctionnalité très appréciée dans Flutter, le Hot Reload. Très utile lors du développement, il permet d’apporter des modifications dans le code d’une application pendant son exécution, puis de recharger ce bout de code modifié presque instantanément afin de visualiser les changements dans l’UI. Le voici en action :

Typiquement, si votre application comporte une erreur, vous pouvez la corriger puis continuer à travailler comme si de rien n’était, sans avoir à la recharger toute entière pour tester vos modifications.

Voilà ce que déclare un développeur mobile à propos de cette fonctionnalité :

Je voulais tester le hot reloading, du coup j’ai changé une couleur, sauvegardé ma modification et… je suis tombé amoureux !

Cette fonctionnalité est vraiment géniale. Moi qui pensais que le Edit & Continue de Visual Studio était bien, là c’est tout simplement incroyable. Rien qu’avec ça, je pense qu’un développeur mobile peut être deux fois plus productif.

Ça change vraiment la donne pour moi. Quand je déploie mon code et que cela prend du temps, je perds ma concentration, fais autre chose et quand je reviens sur mon appareil/simulateur j’ai oublié ce que je voulais tester. Quoi de plus frustrant que de perdre 5 minutes pour bouger un élément de 2 pixels ? Avec Flutter s’en est fini de tout ça.

Toutes ces fonctionnalités (et bien d’autres !) font donc de Flutter un sérieux candidat pour devenir la référence en matière de développement multiplateforme. Fluture is now !

Des exemples d’applications Flutter

Avant de vous laisser, et pour que vous puissiez vous faire une idée de ce qu’il est possible de faire avec le framework, voici quelques exemples d’applications made in Flutter :

Le site itsallwidgets.com recense également de nombreuses applications développées par la communauté.

Et pour finir, la vidéo de présentation de la dernière mise à jour du framework, Flutter 1.5 :

Cet article Flutter : un framework pour les gouverner tous est apparu en premier sur Apollo Formation.

Il fut un temps où JavaScript n’était dédié qu’au front-end… et puis Node.js est arrivé ! Depuis, sa popularité n’a cessé d’augmenter auprès de la communauté de développeurs. Ses possibilités et son succès grandissants sont tels que la Node.js et la JS Foundation ont décidé de s’associer pour créer l’OpenJS Foundation. Pour autant, Node.js n’est pas seul sur le marché….Qu’en est-il alors de Java, un des leaders dans le développement back-end ? Lequel faut-il choisir pour quel type de projet ? C’est ce que nous allons tenter de savoir.

Java et node.js

Java est un langage de programmation orienté objet qui existe depuis plus de 20 ans. Malgré son grand âge, il s’impose, encore aujourd’hui, comme une référence pour le développement côté serveur.

Node.js n’est quant à lui pas un langage mais plutôt un environnement d’exécution permettant d’utiliser du JavaScript côté serveur. Il utilise pour cela le moteur JS V8 (Google Chrome). Si JavaScript est un langage presque aussi ancien que Java, Node.js est beaucoup plus récent : il fut créé en 2009 seulement.

Nous avons donc deux solutions pouvant s’utiliser côté serveur, qui possèdent chacune ses avantages et inconvénients. Différents facteurs vont permettre de mieux choisir la technologie à utiliser, au-delà, bien sûr, des contraintes liées à l’entreprise par exemple.

Performance et rapidité

Avec son serveur multi-thread, Java est un langage qui s’adapte très bien aux applications avec une forte consommation de ressources CPU (streaming vidéo, édition d’image, etc.). Si une requête demande beaucoup de calculs, par exemple, les autres threads prennent le relais, permettant, en général, un impact réduit sur la vitesse et la performance.

Avec son single-thread, Node.js dévoile plutôt son potentiel pour les applications effectuant de nombreuses requêtes IO (entrées/sorties). En effet, les opérations IO sont non-bloquantes, contrairement à Java, retirant ainsi la nécessité d’attente pour chaque opération. C’est bien simple, plus il y a de requêtes IO, plus Node.js s’affirme face à Java. En termes d’applications, on peut inclure toutes celles qui incluent des opérations massives de lecture et d’écriture comme la connexion, l’acquisition de données, les sauvegardes (backups), le processus de transaction et des applications en temps réel (RTA).

Indépendance et compatibilité

L’un des principaux atouts de Java par rapport à Node.js, c’est son indépendance. Il peut s’exécuter sur n’importe quelle plateforme peu importe sa plateforme d’origine grâce à la JVM. Node.js, quant à lui, possède des modules qui sont liés à l’OS, ce qui nécessite une adaptation pour être exécuté sur un OS différent.

Un des avantages de Node.js serait plutôt le langage qu’il utilise : le JavaScript. Celui-ci est également utilisé en front-end ce qui favorise les migrations de code, la logique utilisée sur le navigateur pouvant fonctionner sur le serveur avec une adaptation minime.

Rapidité d’écriture

Le développement d’une application avec Node.js est plus rapide qu’avec Java. Il demande généralement moins de lignes de code et moins de fichiers. En 2013, PayPal a décidé de construire une même application avec Java puis Node.js. Le constat fut sans appel : l’application en Node.js fut réalisée presque 2 fois plus vite avec moins de développeurs, contenait 33% de lignes de code en moins et 40% de fichiers en moins.

Néanmoins, la rapidité d’écriture ne peut être le seul argument, ce qui permet tout à fait Java de rester dans la course.

Ecosystème

Java, notamment par son ancienneté, dispose de très nombreuses bibliothèques. Celles-ci sont majoritairement open-sources et gérées par des développeurs Java confirmés, appartenant à une large communauté.

Node.js s’articule plutôt autour de modules, disponibles en grande quantité malgré son jeune âge. Et pour cause, sa communauté est composée de passionnés très dynamiques, en faisant l’une des plus actives sur GitHub. Ces modules sont le plus souvent consacrés pour des utilisations très spécifiques et facilement installables via le gestionnaire NPM (Node Package Manager). Ceci participe finalement à sa particularité d’être très extensible.

Côté frameworks, c’est Node.js qui en propose le plus avec express.js ou encore meteor.js, pour citer les plus connus. Java de son côté est plutôt orienté sur les bibliothèques.

Quelles utilisations de Java et node.js ?

Le tableau ci-dessous compile les utilisations les plus courantes pour ces deux solutions :

Finalement, Java ou Node.js ?

Avec la popularité croissante de Node.js, on pourrait être tenté de l’utiliser pour suivre la tendance. Pourtant, c’est bien les caractéristiques finales de l’application qui doivent déterminer la technologie back-end à utiliser. On ne le dira jamais assez mais une réflexion en amont orientée besoins/solutions reste la meilleure manière d’aborder un projet.

Vous souhaitez en savoir plus ?
Découvrez nos formations :

Formations Java

Formation Node.js

Cet article Node.js vs Java : Que choisir pour votre projet ? est apparu en premier sur Apollo Formation.

Nommée « Jaco », la version 5.2 de WordPress est sortie le 7 mai 2019. Fruit du travail de 327 contributeurs, cette version est, comme toujours, disponible au téléchargement sur le site officiel et la mise à jour est réalisable directement dans l’administration. Cet article vous présentera à la fois les apports généraux et les apports techniques.

« WordPress 5.2 vous apporte toujours plus d’outils robustes pour identifier et corriger les problèmes de configuration et les erreurs fatales. Si vous êtes une développeuse ou un développeur aidant des clients ou si vous gérez votre site en solo, ces outils peuvent vous aider à obtenir les bonnes informations lorsque vous en avez besoin. »

• Santé du site
• Mode de récupération (correction des erreurs fatales PHP)
• Gutenberg version 5.6
• Accessibilité
• Politique de confidentialité
• Export des données utilisateurs
• Autres changements
• Liens utiles

Santé du site (Site Health Check)

« Santé du site » est une nouvelle fonctionnalité qui permet d’obtenir des informations utiles pour la configuration d’un site. On y accède via « Outils » dans le menu d’administration.

Cette page propose deux écrans :

Etat : Affiche le bilan de santé général du site, effectué grâce à un panel de points de contrôles, lancés de façon automatiques. Les résultats des tests sont catégorisés en « critique« , « recommandé » et « bon« .

 
Info : donne la configuration du site WordPress. Il sera possible de mettre des informations en privé ou non-privée. Un bouton permet ensuite de copier les informations non-privées dans le presse-papiers.

Note : le fait d’afficher un pourcentage semble déranger. Notamment pour des clients novices qui souhaiteraient atteindre les 100% à n’importe quel prix.

Côté développement

Les thèmes et plugins pourront insérer leurs propres points de contrôle, ainsi que modifier/supprimer certains existant en utilisant le filtre site_status_tests.

Deux types de tests seront disponibles : direct et async. La fonction du test devra obligatoirement retourner un array.

Le filtre debug_information permettra d’ajouter ses propres informations dans le deuxième écran.

Plus d’informations et exemples sur make.wordpress.org.

Mode de récupération (correction des erreurs fatales PHP)

Habituellement, quand une erreur « fatale » se produit, un écran blanc, aussi appelé White Screen of Death (WSoD), remplace le contenu du site. Ainsi, pour aider développeurs et utilisateurs novices à résoudre ces problèmes de WSoD, WordPress 5.2 introduit un nouveau mode de récupération.

Lors d’une erreur fatale, le plugin défaillant est détecté et désactivé de manière automatique. Le WSoD est, lui, remplacé par une notification de « difficultés techniques » pour un utilisateur lambda. L’administrateur est ensuite informé par email de la situation. Celui-ci contient notamment un lien vers le nouveau mode de récupération, d’où il est le seul à pouvoir se connecter.

Une fois sur l’interface d’administration, l’activation du mode de récupération est indiquée en haut de l’écran. L’utilisateur est informé des thèmes/plugins qui sont mis en pause à cause d’erreurs fatales. Plusieurs options sont ensuite possibles pour traiter le problème :

• Désactiver complètement le plugin si garder le site en ligne est plus important que les fonctionnalités du plugin, en attendant d’avoir une vrai résolution du problème ;
• Résoudre soi-même le problème à condition de disposer des compétences ou ressources techniques puis réactiver le plugin/thème ;
• Créer un ticket support ou contacter un développeur avec l’erreur exacte.

L’administrateur peut ensuite quitter le mode à tout moment grâce à un bouton dans la barre admin. A noter que si l’extension défaillante n’a pas été désactivée ou réparée avant de quitter le mode, l’erreur sera toujours présente et le site bloqué.

Côté développement

• La fonction wp_is_recovery_mode() permet de savoir si le mode de récupération est actif.
• Le template utilisé pour la page indiquant l’erreur fatale pourra être personnalisé en créant un fichier php-error.php (sur le même principe que db-error.php).
• La classe décrivant la gestion des erreurs fatales est WP_Fatal_Error_Handler. La manière dont sont gérées ces erreurs peut être modifiée en créant une classe personnalisée. Celle-ci doit être étendue de la classe par défaut et s’insérer dans n nouveau fichier à nommer fatal-error-handler.php.
• Pour désactiver la gestion d’erreurs fatales et le mode de récupération, il faut définir la constante WP_DISABLE_FATAL_ERROR_HANDLER dans wp-config.php ou utiliser le filtre wp_fatal_error_handler_enabled. Il faut alors vérifier que le gestionnaire est activé en utilisant la nouvelle fonction wp_is_fatal_error_handler_enabled() .
• L’adresse e-mail utilisée pour prévenir de l’activation du mode de récupération peut également être modifiée, tout comme le contenu envoyé. Pour cela, il faut utiliser le filtre recovery_mode_email puis définir les éléments à modifier avec $email_data[‘subject’], $email_data[‘message’] et $email_data[‘header’].

Plus d’informations sur make.wordpress.org.

Gutenberg en version 5.6

Au programme de cette version 5.6 de Gutenberg, améliorations, correction de bugs et nouveautés.

De nouveaux types de blocs font tout d’abord leur apparition :

• Flux (rss)
• Amazon Kindle
• Barre de recherche
• Calendrier
• Nuage de mots (étiquettes ou catégories)

Les blocs « Tableau » et « Bannière » furent également améliorés.

Une des nouveautés est le gestionnaire de blocs. Il permet de réduire le nombre de blocs proposés lors de la création d’un nouveau bloc. Ainsi vous pouvez afficher seulement ceux dont que vous allez utiliser.

Côté développement

Jusqu’ici, l’éditeur de bloc n’était disponible que pour les articles et pages. Pour afficher le rendu en mode WYSIWYG, l’éditeur utilisait le script wp-editor, qui récupérait le post édité pour afficher le rendu correspondant. Dans cette nouvelle version de Gutenberg, cet éditeur sera également disponible hors des posts, par exemple dans l’écran Widgets. Pour cela, des parties du script wp-editor furent déplacés dans un nouveau script wp-block-editor (voir les modifications sur make.wordpress.org).

Concrètement, le module editor sera utile pour aller chercher et actualiser des objets post, ainsi que d’afficher des éléments spécifiques de l’interface utilisateur pour les posts. Quant au block-editor, il permettra d’afficher l’interface utilisateur de l’éditeur, d’actualiser les blocs et de fournir des composants réutilisables pour des blocs tiers.

WordPress recommande fortement l’utilisation de block-editor plutôt qu’editor. Si vous continuez à utiliser editor plutôt que block-editor pour afficher un éditeur dans les widgets par exemple, vous risquez de charger le mode complet de l’éditeur ce qui ne sera probablement pas utile dans ce cas précis.

Il n’existe pas réellement de rétrocompatibilité pour les versions antérieures à WordPress 5.2. Cependant, wp-editor dispose de proxies : vous pouvez donc continuer à l’utiliser dans vos plugins. Vous pouvez également vérifier l’existence de wp.blockEditor et dans le cas contraire, continuer avec wp.editor.

Plus d’informations sur make.wordpress.org et dans le Block Editor Handbook.

Accessibilité

Souvent oubliée lors de la conception de sites web, l’accessibilité prend pourtant une place importante dans la réalisation du CMS WordPress.

Onglets dans les pages admin

Certains onglets en <h2> dans la partie admin passent en <nav>, puisqu’ils sont en réalité des éléments permettant la navigation. Ces <nav> ont également été agrémentés d’aria-label afin d’être distingué par les outils de navigation assistée. Pour les plugins et thèmes, il faudra donc adapter la même mise en page pour éviter des problèmes de compatibilité CSS.

En savoir plus sur make.wordpress.org et sur core.trac.wordpress.org.

Formats de publication dans la liste des articles dans l’admin

Dans la liste des publications de blog, une icône s’affichait dans la ligne, représentant le format de la publication (« En passant », « Image », « Vidéo », etc.). Cette icône permettait de filtrer la liste des articles selon leur type. Ces icônes seront finalement supprimées en faveur d’une liste déroulante filtrante au-dessus du tableau.

Cette liste déroulante peut être désactivée via le filtre disable_formats_dropdown.

En savoir plus sur core.trac.wordpress.org.

Cacher les icônes dans les sous-menus de la barre admin

Les icônes générées en CSS présentes dans les sous-menus de la barre admin (flèches) seront désormais cachées pour les technologies d’assistance type lecteur d’écran. Pour cela, elles sont insérées dans un élément conteneur avec en propriété aria-hidden= »true ».

En savoir plus sur core.trac.wordpress.org.

Nouvel affichage pour l’ajout de médias

Des titres ont été ajoutés au sein de la fenêtre d’ajout de médias afin de faciliter la navigation au sein de la page avec des lecteurs d’écran. Ces titres et sous-titres possèdent la classe CSS screen-readers-text, ce qui les rend invisibles à l’écran mais accessibles pour les lecteurs d’écran.

En savoir plus sur core.trac.wordpress.org.

L’ordre des champs à remplir lors de l’ajout d’une image a également été modifié.

Le champ « Texte alternatif » apparaît désormais en premier, avec une explication permettant de mieux comprendre pourquoi et comment utiliser cette balise sur les images.

En savoir plus sur core.trac.wordpress.org.

Politique de confidentialité

Un nouveau template privacy-policy.php  est désormais disponible pour modifier la mise en page.

Deux classes CSS furent également ajoutées :

• .privacy-policy : sur l’élément <body> de la page de politique de confidentialité
• .menu-item-privacy-policy : sur l’élément de menu <li> pointant vers la page de politique de confidentialité.

Plusieurs fonctions furent ajoutées :

• is_privacy_policy() : permet d’identifier la page de politique de confidentialité identifiée comme telle, de la même manière que is_front_page() ou is_home(). Niveau rétrocompatibilité, il faudra d’abord chercher si la fonction existe (voir exemple de fonction).
• get_privacy_policy_template() : retourne le chemin vers le fichier template.

Les filtres {$type}_template_hierarchy et {$type}_template fonctionnent tous deux en remplaçant {type} par privacypolicy.

En savoir plus sur core.trac.wordpress.org

Amélioration dans l’export des données utilisateurs

L’export de données utilisateurs n’utilise plus seulement une liste définie de balises autorisées limitée à <a> et <br>. La liste utilisée est désormais celle par défaut, acceptant notamment <i>, <strong>, <em>, etc. Celle-ci pourra d’ailleurs être modifiée spécifiquement pour l’export de données utilisateurs grâce au filtre wp_kses_allowed_html et le contexte personal_data_export.

En savoir plus sur core.trac.wordpress.org

Autres changements

Comme pour chaque mise à jour, les nouveaux éléments ne manquent pas. Retrouvez ci-dessous d’avantage de nouveautés.

 
Dashicons

13 nouvelles icônes furent créées puis ajoutées. 18 icônes qui étaient intégrées aux fichiers mais sans déclaration CSS ont également été ajoutées.

Voir les icônes et leur code

Dans la même lignée, Twemoji profite aussi d’une mise à jour vers la version 12.0.1.

 
Nouveau processus d’ajout des icônes

Désormais, il suffit d’ajouter les fichiers SVG dans Dashicons GitHub repository et elles seront automatiquement incluses dans les font et fichiers CSS. Ce changement ne sera cependant pas visible dans la base de ressources de WordPress Core.

Nouveau format de fichier de police : WOFF 2.0

Le format de police utilisé pour les icônes passe de WOFF 1.0 à 2.0. Cette nouvelle version offre une meilleure compression ce qui permet de consommer moins de ressources. Il est cependant important de noter que le WOFF 2.0 n’est pas supporté par Internet Explorer.

Trois autres formats de fichiers vous permettront d’accéder aux icônes :

• woff : En WOFF 1.0, il permet d’assurer la rétrocompatibilité pour les thème et plugins chargeant déjà ce fichier. Il ne contient cependant pas les 13 nouvelles icônes.
• dashicons.css : où WOFF 1.0 est compilé et inclus. Les 13 nouvelles icônes y furent ajoutées pour la mise à jour.
• eot : le format eot inclut bien les nouvelles icônes et est supporté par toutes les versions d’IE (mais pas des autres navigateurs).

Nouveaux filtres sites et réseaux de sites (multisite)

Arrivée de deux nouveaux filtres : sites_pre_query et network_pre_query.

Ces filtres permettent aux plugins d’utiliser des bases de données alternatives pour des requêtes, qui s’exécutent alors avant celles vers la base de données WordPress.

Plus d’informations et exemples sur make.wordpress.org.

Nouveau filtre de contenu pour l’action de suppression d’utilisateur

Quand un utilisateur est supprimé, WordPress vérifie s’ils ont des publications (post) ou liens lui étant associé. Cependant, dans certains cas, des extensions peuvent avoir des contenus lui étant associé hors des relations post_author ou link_owner.

Le nouveau filtre users_have_additional_content permet alors à l’extension de vérifier des relations de contenus personnalisées. Il ne permet cependant que de vérifier et non de supprimer ou réaffecter. Pour cela, il faut utiliser les actions de delete_user ou deleted_user avec l’ID de l’utilisateur à supprimer et celui de l’utilisateur à qui le contenu doit être réaffecté.

Plus d’informations et exemples sur make.wordpress.org.

Nouveau hook wp_body_open

La nouvelle fonction wp_body_open() permet aux développeurs d’injecter du code, comme des scripts par exemple, directement après l’ouverture de <body>. Cette fonction est à placer juste après l’ouverture de la balise body. Pour la rétrocompatibilité, il faut d’abord vérifier si la fonction existe.

En savoir plus sur make.wordpress.org.

Changements dans la configuration et l’utilisation des variables globales de publication dans get_the_content() et aux autres fonctions associées

Les fonctions comme get_the_excerpt(), get_the_content() et wp_trim_excerpt() utiliseront moins les variables globales liées aux publications (post). Quand cela est possible, ces fonctions utiliseront plutôt la valeur $post passée en argument de la fonction.

Il peut y avoir un problème en termes de rétrocompatibilité : le filtre content_pagination s’exécute maintenant avec que les globales de publications ne soient renseignées. Pour les callbacks de content_pagination, il est alors suggéré de passer $post en paramètre du filtre plutôt que d’utiliser les variables globales.

Détails et exemples sur make.wordpress.org.

 
 
En plus

WordPress 5.2 inclut désormais la librairie sodium_compact.

Côté Gutenberg, les configurations webpack et babel furent intégrées dans le pack @wordpress/scripts. La mise à jour globale du pack permet notamment de faciliter la mise en place d’un environnement de développement pour la création de blocs.

En savoir plus sur make.wordpress.org.

Liens utiles

GitHub WordPress

Codex WordPress

Base WordPress Developer

Toutes les classes, fonctions, hooks et methodes ajoutés dans 5.2

Vous souhaitez vous perfectionner sur WordPress ?
Découvrez notre formation dédiée !

Apollo/Sparks est un organisme dédié à la formation des professionnels de l’informatique.
Consultez dès à présent notre catalogue de formations !

Cet article WordPress 5.2 : Quelles-sont les nouveautés ? (fonctionnalités, filtres, fonctions, …) est apparu en premier sur Apollo Formation.

Le site d’entraide pour développeurs Stack Overflow mène chaque année l’enquête auprès de sa communauté, afin d’identifier les grandes tendances du monde du développement logiciel. Pour l’édition 2019, près de 90’000 programmeurs et programmeuses du monde entier ont répondu aux questions posées par la plateforme. Langages de programmation, frameworks ou bases de données, découvrons ensemble quels sont les outils favoris des développeurs en 2019.

Python dépasse Java et continue son ascension

La grosse bête qui monte, qui monte. Au classement des langages de programmation les plus populaires, Python continue son ascension avec près de 42% des personnes interrogées qui déclarent l’utiliser. Si JavaScript est indétrônable depuis maintenant 7 ans, Python progresse encore et vient de dépasser Java. L’année dernière il surpassait C#, après être passé devant PHP la précédente.

Pourquoi Python est-il si populaire ?

Une progression constante qui peut s’expliquer par la simplicité du langage, une prise en main rapide et ce même pour les débutants en programmation. Universel, Python peut par ailleurs répondre à un large spectre de besoins en développement et trouve des applications dans bien des domaines : gestion des systèmes, développement web, outils d’administration, déploiement, modélisation scientifique, etc, etc.

Notons également que Google, géant parmi les géants, a massivement adopté Python en interne depuis 2006, pour nombre de ses plateformes et applications. Un soutien de poids pour le langage, surtout que le géant américain participe activement au développement de la documentation et a mis à disposition de tout un chacun divers guides et tutoriels Python. C# a Microsoft, Java bénéficie du soutien d’Oracle et PHP est utilisé par Facebook : chacun son poulain, et avec Google, Python a peut-être trouvé le meilleur des cochers.

Finalement, l’utilisation de solutions Big Data et Cloud en entreprise a également favorisé l’ascension de Python. C’est un des langages les plus utilisés pour la Data Science, tout juste devancé par R, le spécialiste de la statistique.

Si on ajoute à cela des bibliothèques ultra-performantes, de NumPy et SciPy dans le domaine scientifique à Django pour le développement web, tout est réuni pour faire de Python un langage des plus populaires, aujourd’hui et sans doute également dans les années à venir.

Envie d’une formation sur le langage du moment ? Découvrez nos sessions Python et Python Perfectionnement, pour acquérir les compétences professionnelles qui feront de vous un·e parfait·e charmeur·se de serpent !

Les langages de programmation que les développeurs adorent, redoutent et désirent

Au-delà de l’utilisation concrète des technologies, Stack Overflow demande aux développeurs d’exprimer leur opinion personnelle : quelles sont celles qu’ils préfèrent, celles sur lesquelles ils souhaiteraient ne plus jamais travailler ou encore celles qui les tentent le plus. Voici les conclusions de l’enquête, toujours concernant les langages de programmation.
 

Toujours plus haut, toujours plus Rust

Pour la quatrième année consécutive, c’est Rust qui trône à la première place du classement. Le langage développé par Mozilla devance Python et TypeScript dans le cœur des développeurs. Les pourcentages indiqués correspondent aux répondants travaillant sur ces langages et ayant exprimé l’envie de continuer à le faire.

Et les pires langages de programmation sont…

A l’inverse, les langages de programmation sur lesquels plus personne (ou presque) ne veut travailler :

VBA arrive en tête, suivi par Objective-C et Assembly. A noter les progressions de PHP et du C, qui font leur entrée dans le top 5 cette année.

Python Most Wanted

Sans surprise et conformément aux résultats précédents, Python se hisse à la première place du classement des langages que les développeurs ont le plus envie d’apprendre.

Frameworks Web et bases de données

Outre les langages de programmation, Stack Overflow a interrogé sa communauté de développeurs sur les frameworks, bibliothèques et outils qu’ils utilisaient (et appréciaient) le plus.

React passe devant Angular

Concernant les frameworks web, on retiendra que si jQuery conserve la tête du classement en termes de popularité, React arrive en deuxième position et devance pour la première fois le célèbre Angular.

Si le framework de Google a connu une très forte croissance entre 2014 et 2016, ses concurrents sont dernièrement venus lui grappiller quelques adeptes, React en tête. A noter qu’à l’instar de jQuery, React est en fait une bibliothèque et non un framework à proprement parler. Cette différence offre aux développeurs une plus grande flexibilité, qui pourrait expliquer cet attrait pour la technologie signée Facebook.

Une tendance confirmée par le classement des frameworks les plus appréciés :

Cette année les frameworks web ont été séparés des autres frameworks et bibliothèques. Parmi ceux-ci, Node.js tient la dragée haute et est le plus utilisé, devant .NET et .NET Core.

Vous souhaitez en savoir plus sur le développement d’applications avec React ? Suivez nos 3 jours de formation intensive, pour en maîtriser les principales fonctionnalités !

Bases de données : MySQL la plus utilisée, Redis la plus appréciée

Côté bases de données, les technologies open source confirment leur popularité : comme l’année dernière, MySQL est en tête du classement, devant PostgreSQL qui prend la deuxième place en dépassant SQL Server de Microsoft. MongoDB reste la base de données SQL la plus populaire :

Un dernier classement pour la route, celui des bases de données les plus appréciées. Pour la troisième année consécutive, c’est Redis de la mouvance SQL qui prend la première place :

Pour encore plus de chiffres et de classements, vous pouvez consulter l’intégralité de l’enquête Stack Overflow. Vous y retrouverez d’autres statistiques concernant les technologies et outils les plus populaires du marché, mais également des données sur les profils types des développeurs d’aujourd’hui, ou encore leurs habitudes de travail.

Cet article Les langages de programmation, frameworks et bases de données préférés des développeurs en 2019 est apparu en premier sur Apollo Formation.

Java et JavaScript : Leurs origines

Java est un langage de programmation créé en 1991 par Sun Microsystems (racheté par Oracle en 2009). Principalement dédié au développement d’applications informatiques (logiciels), il devint populaire à partir de 1995 grâce à ses applets destinées au web. Peu de temps après, en 1996, Netscape dévoile au grand jour le langage JavaScript, permettant d’ajouter des interactions aux pages web et de les dynamiser, pour devenir aujourd’hui le langage le plus utilisé par les développeurs.

Java et JavaScript : Quelques similitudes

Outre leur nom, il existe bien quelques similitudes entre Java et JavaScript. Ce sont, tout d’abord, tous les deux des langages de programmation, créés, de surcroît, dans les années 1990. On retrouve également des ressemblances au niveau de leur syntaxe, le JavaScript ayant notamment emprunté les opérateurs de comparaison Java (==, !=, <, >, <=, >=). Techniquement, les deux langages peuvent être utilisés pour le web. Enfin, ils sont tous deux très utilisés et pour diverses finalités.

Java et JavaScript : Deux langages distincts

Sans rentrer dans les détails, Java et JavaScript sont deux langages qui vont être écrits, interprétés et utilisés de manières différentes. Au niveau de l’écriture, nous dirions assez facilement que le Java est très normé et complexe, là où le JavaScript est plus souple et aisé en terme de compréhension. Une fois le code rédigé, le Java nécessite une Machine Virtuelle spécifique pour être interprété. Dans une page web, cela se traduisait sous la forme de ce que l’on appelle « applets », que l’on utilise plus aujourd’hui. Le JavaScript est, lui, directement inséré dans le site web car il est interprété de base par la plupart des navigateurs. Enfin, ce qui les différencie, ce sont leurs utilisations. Java va pouvoir être utilisé pour : des applications Android, des applications logiciels, des systèmes d’entreprise (dédiés au traitement de gros volumes de données), des systèmes embarqués ou encore du côté back-end d’un site web. Quant à JavaScript, il est presque exclusivement dédié aux sites web, mais peut aussi créer des applications web (ex : messagerie instantanée) et mobiles.

Note : JavaScript fut créé par Brendan Eich (Netscape) en 10 jours seulement.

Java et JavaScript : Pourquoi des noms si proches ?

A la base, JavaScript devait s’appeler LiveScript mais fut finalement renommé afin de surfer sur la popularité de Java. Néanmoins, JavaScript devait bien venir en complément de Java dans les pages web, mais en proposant un langage plus simple à maîtriser dans une période où Internet explose (Internet était pour la première fois au centre de Windows 95).

En résumé…

En conclusion, bien que Java et JavaScript possèdent quelques petites similitudes, ce sont globalement des langages différents, tant au niveau de leur complexité que de leurs applications. Pour ne plus les confondre, il n’y a donc pas de secret : il faut posséder quelques informations basiques. Afin d’éviter la confusion, un conseil serait d’appeler le JavaScript « JS » (ses initiales donc…), surnom souvent utilisé car plus court à prononcer et compris par toute la communauté de développeurs.

Cet article Java et JavaScript : ne plus les confondre est apparu en premier sur Apollo Formation.

Le DevOps est relatif aux approches d’accélération des processus selon lesquels une idée (exemple : une nouvelle fonctionnalité logicielle) passe de la phase de développement à celle du déploiement dans un environnement entraînant un apport à l’utilisateur. La collaboration entre les équipes de développement et les équipes d’exploitation est indispensable dans ce cadre, et en adaptant sa stratégie de gestion car la méthode de gestion traditionnelle est inadaptée.

Atouts de la culture DevOps

Collaboration en entreprise

L’instauration d’une culture de la responsabilité partagée, de la transparence et du feedback accéléré est un gage de réussite pour chaque équipe DevOps.

Avec DevOps, la « pensée systémique » est de rigueur. Le mouvement DevOps impose aux équipes un changement d’état d’esprit, visant à observer le processus de développement dans sa globalité et à décloisonner les « frontières » entre les équipes de développement et opérationnelles.

Travailler en bonne intelligence

L’adoption de la culture DevOps en entreprise implique davantage de qualité et de stabilité dans le processus organisationnel.

La culture DevOps s’oppose à l’absence de tests automatisés et de cycles de revue pouvant être un frein à la mise en production, en s’appuyant sur des concepts de vélocité et de confiance. A l’appui du principe d’automatisation, les équipes peuvent accroître leur productivité et être plus réactives.

Une gestion des tâches non planifiées plus efficace

La culture DevOps est un outil permettant de lutter efficacement contre les tâches non planifiées, une réalité nuisant à la productivité. Les équipes DevOps peuvent gérer les tâches non planifiées, en se concentrant en parallèle sur celles qui le sont.

Le transfert et la priorisation des tâches non planifiées entre les différents systèmes et équipes s’avèrent inefficaces et nuisent à la productivité du travail à faire. Une forte visibilité et une rétrospection proactive sont primordiaux dans une logique d’anticipation.

La culture DevOps est vecteur de réduction de la durée de résolution. La transparence totale et la fluidité communicationnelle des équipes DevOps peuvent réduire les temps d’arrêt. La communication ouverte permet une meilleure gestion au niveau des tickets importants.

Culture DevOps : le framework CALMS

Culture

Le processus d’automatisation dans la gestion en entreprise ne présente aucun intérêt, sans la réelle volonté de collaboration entre les équipes de développement et opérationnelles. La méthode DevOps est une réponse à des problématiques humaines. Le meilleur moyen afin de développer la collaboration entre les équipes est le fait de partager un objectif commun et réaliser un plan pour l’atteindre collectivement.

Selon le contexte de l’entreprise, la transition vers la culture DevOps peut être mise en œuvre progressivement. Les équipes de développement peuvent inviter les membres de l’équipe opérationnelle à participer aux sessions de planification des sprints, aux stand-ups quotidiens et aux démos de sprint.

Cette méthode permet de suivre les projets, les idées et de prendre un temps de partage et d’écoute en lien avec le savoir-faire de chacun, ce qui rend au final la livraison plus efficace.

Automatisation

L’automatisation permet la suppression de tâches manuelles, dans une logique d’amélioration continue des systèmes.

L’automatisation peut s’effectuer progressivement en commençant par le développement, les divers tests, le déploiement et les tâches de provisionnement Les équipes sont motivées par une collaboration résultant sur le développement de systèmes utiles à tous.

Le processus d’automatisation commence généralement par la livraison continue, qui nécessite du temps pour une mise en œuvre adéquate : chaque changement de code est soumis à une batterie de tests automatisés. Les ordinateurs exécutent des tests de façon plus fiable que les êtres humains, à travers la détection des bugs et des failles de sécurité au plus tôt, ce qui réduit voire élimine les surprises au moment de la livraison.

Lean

Ce concept « Lean » correspond, dans le contexte des logiciels, à l’agilité, l’amélioration continue et la reconnaissance des échecs, d’autant plus pertinents pour la culture DevOps.

Le développement Agile a permis de populariser l’amélioration continue. Cette approche a démontré qu’un simple produit mis entre les mains d’un client dès maintenant a plus de valeur qu’un produit parfait qui sera livré aux clients dans six mois. La fidélisation du client passe par l’amélioration continue.

Le « Lean » motive les équipes à travers la planification d’objectifs ambitieux et l’assimilation aux inévitables échecs afin d’en tirer des leçons. Dans le contexte de DevOps, l’échec n’est pas une infraction mais est anticipé. Les équipes mettent tout en œuvre pour détecter rapidement les bugs et les résoudre : l’amélioration continue est étroitement liée aux défaillances.

Mesure

De nombreux outils et technologies permettent de mesurer les performances de la culture DevOps et de l’amélioration en continu : durée d’utilisation de votre produit par les utilisateurs, ventes générées par un billet de blog, etc.

En amont, dans le cadre d’un projet de développement Agile, certaines questions peuvent se poser :

• Quel est le temps requis pour passer du développement au déploiement ?
• Quelle est la fréquence de reproduction des bugs ?
• Quel est le temps dont a besoin l’entreprise pour reprendre ses activités après une panne système ?
• Combien de personnes utilisent-elles le produit à cet instant ?
• Combien d’utilisateurs ont été gagnés/perdus cette semaine ?

Toutes ces données facilitent la prise de décision des équipes et ont davantage d’impact lorsqu’elles sont partagées avec d’autres équipes.

Partage

La partage des responsabilités et des réussites est un facteur de succès, dans la culture DevOps.

Un des principes fondamentaux de DevOps est le fait que le développeur d’une application doit également participer à sa livraison et à son exécution. La collaboration est de mise entre les équipes de développement et opérationnelles, à chaque phase du cycle de vie de l’application. Le fait d’être confronté ensemble aux mêmes problématiques renforce la cohésion de groupe et permet d’éprouver davantage de plaisirs lors de réussites.

Un feedback positif de ses pairs, suite par exemple à la résolution d’un mauvais bug, est très motivant et renforce la culture DevOps en entreprise.

Nos formations DevOps chez Apollo Formation

Cet article Culture DevOps : mieux comprendre cette approche est apparu en premier sur Apollo Formation.