Dernièrement, j’ai eu l’occasion de travailler sur PostgreSQL (J’ai plus l’habitude de travailler sur MySQL).
Dans un de mes développements, je devais utiliser une fonction permettant le regroupement de différentes valeurs en une chaîne de caractère. J’avais déjà utilisé group_concat dans MySQL, et je n’avais utiliser l’équivalent dans PostgreSQL.
Avec un peu de recherche, j’ai vu qu’il était possible de créer des fonctions spécifiques, et de les ajouter dans PostgreSQL. C’est ce que j’ai fait.
Pour cela, c’est très simple : il faut d’abord aller sur votre outil qui gère vos BDD (pgAdmin, …). Puis, il faut ajouter les lignes suivantes :
create aggregate array_accum (
sfunc = array_append,
basetype = anyelement,
stype = anyarray,
initcond = '{}'
);
CREATE OR REPLACE FUNCTION _group_concat(text, text)
RETURNS text AS $$
SELECT CASE
WHEN $2 IS NULL THEN $1
WHEN $1 IS NULL THEN $2
ELSE $1 operator(pg_catalog.||) ',' operator(pg_catalog.||) $2
END
$$ IMMUTABLE LANGUAGE SQL;
CREATE AGGREGATE group_concat (
BASETYPE = text,
SFUNC = _group_concat,
STYPE = text
);
A partir de maintenant, la fonction group_concat est utilisable dans PostgreSQL
Comme vous pouvez le voir, le script PHP utilise la classe DateTime, élément important de PHP pour manipuler les dates.
Nous pouvons voir aussi l’utilisation de la classe DateInterval, permettant la spécification de l’intervalle voulu. Pour le premier DateInterval, le paramètre P1Y signifie period 1 Year. Pour le second DateInterval, P1M signifie period 1 Month.
Il est possible de faire beaucoup plus avec cette fonction. Pour cela, je vous ai laissé le lien de cette classe du manuel PHP.
Parmi les fonctionnalités de DateTime, il existe sub() et add(), qui respectivement soustrait et ajoute les durées souhaité.
Pour l’article d’aujourd’hui, je ne savais si je devais le mettre ici, ou sur le blog 365 idées.
En effet, cet article est une idée de projet que l’on pourrai mettre en place, et qui est lié au CMS WordPress.
WordPress permet d’utiliser un certain nombre de concept qui ajoutent des fonctionnalités sur votre site : Shortcodes, Post Type, Meta Box, Taxonomy, etc…
Ce que je propose, c’est un site qui génére des fichiers de configuration WordPress en YAML nommé wp-cli.yml.
De quoi je parle ? qu’est ce qu’un fichier wp-cli.yml ?
Comme je disais, c’est un fichier de configuration au format YML, qui peut être lu à l’aide de WP-CLI, l’outil de ligne de commande de WordPress. Vous pourrez en savoir plus sur la documentation de WP, plus précisément sur la page de config de WP-CLI.
Globalement, WP-CLI récupère les paramètres globaux et les arguments qui existe dans le fichier de configuration. Pour moi, le seul cas d’utilisation de ce fichier est pour une installation de WordPress, plus rapide et plus propre.
Pour cette idée, je me suis inspiré du site generatewp, qui contient des outils pour les développeurs WordPress.
Avez-vous déjà entendu cette expression ou quelque chose dans le genre ? Bien sûr que oui ! Chaque développeur et étudiant a déjà probablement entendu de tels commentaires. Pourquoi ? Et pourquoi réinventer la roue est-il si mal vu ?
Parce que, le plus souvent, le code existant est un code fonctionnel. Il a déjà été soumis à une sorte de contrôle de la qualité et à des tests rigoureux, et est utilisé avec succès. De plus, le temps et les efforts investis dans la réinvention sont peu susceptibles de porter leurs fruits, de même que l’utilisation d’un produit ou d’une base de code existante. Si vous avez la peine de réinventer la roue ? Pourquoi ? Quand ?
Peut-être avez-vous déjà vu des publications sur les modèles de développement de logiciels ou des livres sur la conception de logiciels. Ces livres peuvent être endormant, quelle que soit la qualité de l’information qu’ils contiennent. De la même manière que regarder un film sur la voile est très différent de naviguer, utiliser le code existant, c’est aussi concevoir son propre logiciel à partir de zéro, le tester, le casser, le réparer et l’améliorer en cours de route.
Réinventer la roue n’est pas simplement un exercice pour placer des constructions de code: il s’agit de savoir acquérir une connaissance intime du fonctionnement interne de divers composants existants. Savez-vous comment fonctionnent les gestionnaires de mémoire? Les pagination virtuelle ? Pourriez-vous les mettre en œuvre vous-même ? Qu’en est-il des listes à double liaison ? Les Classes de tableau dynamique ? Les clients ODBC ?
Pourriez-vous écrire une interface utilisateur graphique qui fonctionne comme une interface populaire que vous connaissez et aimez ? Pouvez-vous créer vos propres widgets de navigateur Web ? Savez-vous quand écrire un système multiplexé par rapport à un système multi-thread ? Comment choisir entre une base de données ou une base de données en mémoire ?
La plupart des développeurs n’ont simplement jamais créé ces types d’implémentations logicielles principales et ne possèdent donc pas une connaissance intime de leur fonctionnement. La conséquence est que tous ces types de logiciels sont considérés comme de mystérieuses boîtes noires qui fonctionnent.
Comprendre uniquement la surface de l’eau ne suffit pas pour révéler les dangers cachés. Ne pas en savoir plus sur le développement de logiciels limitera votre capacité à créer un travail stellaire.
Réinventer la roue et se tromper est plus utile que de la clouer du premier coup. Il y a des leçons tirées d’essais et d’erreurs qui ont une composante émotionnelle, ce que la lecture d’un livre technique ne peut à elle-seule livrer !
Il est essentiel d’apprendre des faits et de maîtriser les livres, mais pour devenir un bon programmeur, il faut autant acquérir de l’expérience que recueillir des faits. Réinventer la roue est aussi important pour l’éducation du développeur que pour l’haltérophilie, pour le body-builder.
Voici une nouvelle règle que je vous propose, tiré du livre 97 Things every programmer should know. Aujourd’hui, c’est Yuriy Zubarev qui nous parle de la maintenance du code.
Vous pouvez demander à 97 personnes ce que chaque programmeur doit savoir et faire et vous pouvez obtenir 97 réponses distinctes. Cela pourrait être à la fois accablant et intimidant. Tous les conseils sont bons, tous les principes sont fondés et toutes les histoires sont convaincantes, mais par où commencer ? Plus important encore, une fois que vous avez commencé, comment suivez-vous toutes les meilleures pratiques que vous avez apprises et comment en faites-vous une partie intégrante de votre pratique de programmation ?
Je pense que la réponse réside dans votre état d’esprit ou, plus clairement, dans votre attitude. Si vous ne vous souciez pas de vos collègues développeurs, des testeurs, des responsables des ventes et du marketing et des utilisateurs finaux, vous ne serez pas amené à employer un développement piloté par les tests ou à écrire des commentaires clairs dans votre code, par exemple.
Je pense qu’il existe un moyen simple d’ajuster votre attitude et d’être toujours motivé pour fournir des produits de la meilleure qualité: écrivez un code comme si vous deviez le supporter pour le reste de votre vie.
C’est tout. Si vous acceptez cette notion, il se passera beaucoup de choses merveilleuses. Si vous deviez accepter que l’un de vos employeurs précédents ou actuels ait le droit de vous appeler au milieu de la nuit pour vous demander d’expliquer les choix que vous avez faits lors de l’écriture de la méthode fooBar, vous deviendriez progressivement un programmeur expert. Vous voudriez naturellement proposer de meilleurs noms de variables et de méthodes. Vous éviteriez des blocs de code comprenant des centaines de lignes. Vous feriez de la veille, à chercher, apprendre et utiliser des modèles de conception.
Vous pouvez écrire des commentaires, tester votre code et refactoriser continuellement. Soutenir tout le code que vous avez écrit pour le reste de votre vie devrait également être une entreprise évolutive. Vous n’auriez donc d’autre choix que de devenir meilleur, plus intelligent et plus efficace.
Si vous y réfléchissez, le code que vous avez écrit il y a de nombreuses années influence toujours votre carrière, que cela vous plaise ou non. Vous laissez une trace de vos connaissances, de votre attitude, de votre ténacité, de votre professionnalisme, de votre engagement et de votre plaisir avec chaque méthode, classe et module que vous concevez et écrivez. Les gens vont se faire une opinion sur vous en fonction du code qu’ils voient. Si ces opinions sont constamment négatives, votre carrière vous rapportera moins que vous ne l’espériez. Prenez soin de votre carrière, de vos clients et de vos utilisateurs avec chaque ligne de code. Écrivez du code comme si vous deviez le prendre en charge pour le reste de votre vie.
