Bonjour Nal,
Si tu suis mes aventures, tu sais que je développe réguliÚrement des tribunes. Que ce soit pour tester un concept, enrichir un produit existant ou tester des technos.
C'était le cas avec jb3, la tribune la plus friturée du marché mais aussi la plus bloated: Java, Spring Boot, Mongodb et maintenant Node-Red parce que c'est rigolo.
J'avais parfois des envies de minimalisme, mais quand c'est trop rikiki, ça manque de sensation.
Aujourd'hui je t'écris, car j'ai eu un nouveau prétexte (tester Golang) pour écrire une nouvelle suite logicielle de moulage: gb3.
- La démo.
- Les sources (licence MIT)
Architecture: TOGAF ready
gb3 se compose de trois composants:
- gc2, un coincoin en vanilla.js ;
- gb0, un bouchot sans IHM en Golang qui utilise le systÚme de fichier comme base de données;
- gb2c, un agrégateur des meilleures tribunes du web en Golang. Il sert de dauphin à gc2.
architecture
Cette architecture d'applications Ă douze facteurs respecte peut ĂȘtre la philosophie Unix, le modĂšle C4, le design en microservices, ainsi que toutes les bonnes pratiques connues ou inconnues de devoups Ă ce jour, notamment la couverture de 100% de tests unitaires sur la prod grĂące la mĂ©thode Production Unit Testing Enhancement (PUTE).
Avec cette méthode, on teste les fonctionnalités une par une en production en attendant que les utilisateurs se plaignent pour corriger les bugs. Le logiciel en production est donc toujours au top sauf quand il ne marche pas.
Fritures: less is less
Ma précédente solution moulesque avait beaucoup de fritures, au prix d'une certaine complexitude. Cette fois j'ai décidé de n'implémenter que des fonctionnalités que j'utilise au quotidien (moulage multi tribune, totoz, emoji, images jointes) et d'abandonner les rigolotes mais peu utiles (bots, trollomÚtre) et les problématiques pour la privacité des moules (présence en ligne, archivage de longue durée).
J'ai aussi réduit le nombre de paramétrage (on ne peut plus créer de tribune perso, la liste des tribunes est fixe). Bref un processus de gnomisation qui permets d'avoir un logiciel maintenable et sain pour les utilisateurs puisque le développeur sait toujours mieux qu'eux ce dont ils n'ont pas besoin.
Go goal?
Le but de ce projet était d'évaluer Go. Pendant tout le développement je me suis répété c'est nul à chier ce langage en plus les libs sont pas top et puis à la fin le résultat est simple à maintenir et fiable.
Et puis ça consomme un poil moins de RAM:
rame (NdM: récupérée via webarchive)
Bref je suis mitigé<.
Et si je recommençais en Rust cette fois?
# Go with Rust
PostĂ© par Glandos . ĂvaluĂ© Ă 5.
Je plussoie. Attention, il mettre de l'inox A4 en métallique, parce que le milieu marin, ça fait vraiment rouiller.
# Pourquoi pas Ada ?
PostĂ© par Ysabeau đ§¶ (site web personnel, Mastodon) . ĂvaluĂ© Ă 4.
J'ai cru comprendre que la taille des strings dans Ada n'était pas super élastique ce qui t'oblige à garder la ligne. Parfait pour la plage non ? Et là , je sens que tu vas me dire que c'est un truc utilisé pour faire des gros avions et que ça va pas le faire.
(en fait, tu fais bien ce que tu veux).
Je nâai aucun avis sur systemd
[^] # Re: Pourquoi pas Ada ?
PostĂ© par devnewton đș (site web personnel) . ĂvaluĂ© Ă 10. DerniĂšre modification le 11 juin 2021 Ă 17:53.
Le problÚme d'Ada (ou Object Pascal ou Eiffel et plein d'autres), c'est que c'est un bon langage mais pas trÚs vivant sur le marché de l'emploi :(
Alors mĂȘme avec de bons strings, on risque de se retrouver Ă poil.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Ysabeau đ§¶ (site web personnel, Mastodon) . ĂvaluĂ© Ă 3.
En fait, si j'en crois LinuxFr (en admettant que ça soit représentatif de quelque chose), les langages les plus populaires actuellement seraient C+++ et Python avec le petit nouveau Rust qui fait tout pour monter.
C'est l'impression que cela me donne en tout cas. Elle est peut-ĂȘtre erronĂ©e (dĂ©solĂ©e pour les AdaĂŻstes).
Je nâai aucun avis sur systemd
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Blackknight (site web personnel, Mastodon) . ĂvaluĂ© Ă 4.
C'est un indice comme un autre :)
MĂȘme pas grave, ça fait partie des constatations chez Ada-France Ă la derniĂšre AG.
Le dĂ©veloppement en Ada n'est pas aussi rapide et aussi simple que peut l'ĂȘtre un dĂ©veloppement en Python notamment. Du coup, c'est moins fun.
En fait, de mon point de vue, c'est surtout aprÚs qu'on y gagne, en temps de maintenance, car le refactoring est trÚs guidé par le compilo.
Ceci dit, le dernier index PYPL montre une grosse progression, jamais connue pour le langage sur cet index :)
Peut-ĂȘtre est-ce dĂ» Ă la meilleure intĂ©gration de Spark Ada dans le langage ou au fait que les plateformes embarquĂ©es ont plus de cote en ce moment.
En apartĂ©, s'il y en a que ça intĂ©resse, un dĂ©veloppeur a enregistrĂ©, Ă l'occasion de l'Advent of code, deux sĂ©ances de programmation Ada (lĂ et lĂ ) oĂč il "dĂ©couvrait" le langage. Bon, faut avoir 8h Ă tuer... :D
Je vais mettre ça dans la rubrique liens
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Ysabeau đ§¶ (site web personnel, Mastodon) . ĂvaluĂ© Ă 3.
Vu qu'il est basĂ© sur le nombre de recherches google de tutoriels sur les langages; on peut peut-ĂȘtre corrĂ©ler ça avec l'activitĂ© informatique des industries qui utilisent ce langage (notamment aĂ©ronautique si j'ai bien compris) ? Du genre un gros dĂ©veloppement qui pousse les gens Ă chercher des tutoriels pour l'ancien et le nouveau ?
Je nâai aucun avis sur systemd
[^] # Re: Pourquoi pas Ada ?
PostĂ© par claudex . ĂvaluĂ© Ă 4.
Ou une vague de départ à la retraite et du coup, plus personne à qui poser les questions en interne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Blackknight (site web personnel, Mastodon) . ĂvaluĂ© Ă 2.
Oui, c'est tout Ă fait possible mais on peut aussi rĂȘver quand on voit arriver quelques nouveaux sur StackOverflow.
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Blackknight (site web personnel, Mastodon) . ĂvaluĂ© Ă 2.
Pour avoir bossĂ© quelques annĂ©es dans le secteur, je n'y ai vu que trois ou quatre projets en Ada. En mĂȘme temps, c'est chiant, les trucs fonctionnent pendant des lustres, difficile de vendre de la maintenance :D
Alors dans ce cas, on peut se trouver dans le cas de portage vers d'autres langages mais le bon indicateur, c'est le nombre d'offres d'emploi et de ce cÎté-là , c'est pas forcément le feu d'artifice.
Ceci dit, apprendre Ada est largement à la portée du développeur C/C++ ou Java donc au final, c'est pas bien compliqué de recycler un dev... Mais ça, je ne crois pas que grand monde le fasse.
[^] # Re: Pourquoi pas Ada ?
PostĂ© par devnewton đș (site web personnel) . ĂvaluĂ© Ă 8.
Il faut distinguer la popularité (les devs aiment bien) et la popularité (les projets sont codés avec).
En entreprise, on voit beaucoup plus de Java et de Go que du Python et du Rust.
Il y aussi des langages impopulaires ou peu à la mode mais trÚs trÚs trÚs utilisés (PHP, Cobol).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Blackknight (site web personnel, Mastodon) . ĂvaluĂ© Ă 2. DerniĂšre modification le 12 juin 2021 Ă 19:03.
Ca dépend, dans ma boite, c'est Java, C#, PHP et du Python surtout cÎté data science .
On a un seul projet en Go mais parce que c'est un ajout de fonctionnalités à Mattermost et effectivement, pas de Rust.
[^] # Re: Pourquoi pas Ada ?
PostĂ© par Blackknight (site web personnel, Mastodon) . ĂvaluĂ© Ă 5.
Ca peut le faire, en Ada, y en a pour tous les goûts.
La preuve, les Strings sont au nombre de trois:
- les Strings de taille fixe. Idéal pour obliger à garder la ligne pour la plage
- les bounded strings , un peu plus souples qu'on pourrait assimiler au surfer (le maillot pas le contenu)
- les unbounded strings totalement libres, une sorte de naturisme de la chaĂźne de caractĂšres
En plus, ça existe aussi en grande taille et trÚs grande taille :)
Finalement, c'est de la string qui ne te lĂąche jamais
Suivre le flux des commentaires
Note : les commentaires appartiennent Ă celles et ceux qui les ont postĂ©s. Nous nâen sommes pas responsables.