Closed SirMishaa closed 3 years ago
Bien sûr, le processus serait complètement itératif, donc on ne va pas réaliser le site complètement. L'idée est de savoir si ça pourrait plaire aux gens et de connaître ce qu'on peut ajouter par la suite.
Mais pour moi, ressources et devblog, ça peut être très cool.
Juste du point de vue technique, Github Pages ne va pas être limitant pour certaines évolutions futures?
Juste du point de vue technique, Github Pages ne va pas être limitant pour certaines évolutions futures?
Je ne pense pas, sachant que Github Page semble proposer une API, donc en termes de limitation, même si on doit coder un petit daemon qui tourne, on peut facilement mettre à jour le Github via des comportements automatisés.
Aussi, vu que c'est du web, on peut tout à fait avoir une pipeline de build, ce qui fait qu'on peut utiliser des frameworks fontend léger comme Vue ou Svelte pour simplifier énormément le développement de certains composants, pour pouvoir trier / rechercher par exemple.
Et pour les informations, on peut tout à fait avoir les articles du devblog par exemple sous forme de yaml ou de json afin d'éviter un backend. Donc je ne pense pas que nous sommes limités pour ce que nous souhaitons faire.
Carrément, si. GitHub Pages va beaucoup nous limiter si nous souhaitons avoir plus de choses qu'un simple blog et quelques pages, genre... les annonces de recrutement... sauf s'ils doivent être faites via des PR, mais dans ce cas c'est un bot qui doit les relayer sur Discord... même si un simple webhook résout ceci (et ce serait valable pour d'autres fonctionnalités).
Je ne pense pas, sachant que Github Page semble proposer une API, donc en termes de limitation, même si on doit coder un petit daemon qui tourne, on peut facilement mettre à jour le Github via des comportements automatisés.
Cette API ne permet pas ce que tu penses.
Sans parler d'API pour l'OAuth2 et Discord, comment ça se passerait ? J'ai peut-être pas compris (signales le moi si c'est le cas)
En dehors de ça, le projet me semble intéressent. Déjà avant plusieurs d'entre nous ont eu l'idée de faire "Not a Hub", pour héberger nos ressources.
J'aime beaucoup Not a Hub, ça sonne vraiment bien.
Pour la partie technique, je vous propose qu'on en parle dans un ticket dédié, si le projet intéresse et qu'il est accepté. Un petit backend sera peut-être, en effet, plus pertinent pour simplifier les choses, au moins, il ne faudra que faire des appels api.
Le fil pour en parler est sur NaN, dans # Not a Hub
Peut-être plutot dans un thread dans #discussion ? Histoire que tout le monde puisse le voir.
Je suis surtout intéressé par l'aspect blogging, càd pas uniquement des pages type "awesome" qui aggrègent des liens mais vraiment un endroit propice à la rédaction d'articles techniques.
Je publie ici un message que j'avais laissé dans l'ambassade:
[+] Le nom NaH -> Ce n'est pas un composé chimique valide, il manque 6 électrons, il faut trouver un moyen d'inclure de l'oxygène :upside_down:
[+] publier des billets techniques -> mettre l'accent sur la contextualisation du billet, date, version du langage ciblé, ras-le-cul de tomber sur de la doc outdated en ligne
[+] publier des billets d'actu
[+] centralisation des différents blogs
[?] présentation projets de la commu -> nécessaire ?
[?] modèle d'administration -> que le site soit un mirroir de discord, banni de NaN = banni (=readonly) d'hydrure de sodium -> avons-nous besoin de rentrer (si tôt) dans ce qui concerne la modération de la plateforme ?
[-] système de commentaire -> il y a un risque d'éparpiller les conversations, discord devrait rester la principale plateforme pour discuter autours des billets -> peut-être "épingler" sur le billet certains messages de discord ou l'inverse, notifier le bon salon sur discord lorsqu'un commentaire est publié sur le blog (si on ne retient pas la 1e proposition)
=====
-> Avoir un système pour que la communauté puisse valider un article avant sa publication
Alors avant tout, je suis convaincu qu'utiliser git sera une bonne chose, ça nous permettra de proposer des révisions à des articles existants, de documenter les changements et surtout garder une trace de toutes les modifications ce qui est très important pour se donner une rigueur académiques.
D'un autre côté, je constate que les échanges sous les pull requests et les issues sur cette orga ne sont pas forcément très fructueux. Nous sommes très (trop) habitués à échanger entre nous avec des messages courts dans un flux continu d'instant messaging alors que l'utilisation classique de github est plutôt d'envoyer des longs messages où on a toute la largesse d'exprimer ses idées jusqu'au bout (comme je fais ici).
Si je pense qu'on doit garder le mécanisme de pull-request pour proposer des changements, je serais d'avis d'utiliser les nouveaux threads de discord pour les discussions (et même les reviews) et empêcher d’interagir sur l'interface de github. On peut utiliser les webhooks pour ça :)
J'aime beaucoup la proposition d'utiliser les github pages par contre j'ai très peur de subir l'élan technologique des développeurs Javascript. Si on doit faire un blog j'aimerais vraiment réduire toute la technique au stricte minimum : pas de preprocesseur css, pas de javascript inutile, pas de framework css (bootstrap/foundation), pas de syntaxe abusivement complexe pour le texte (I'm looking at you reStructuredText). Vraiment, gardons le bon vieux html5/css3/markdown que tout le monde peut comprendre, mettons juste un post-commit-hook capable de run un script de rendu markdown -> html.
Dans mon idée, proposer un article (ou une révision) devrait se résumer à écrire (ou modifier) un fichier markdown et proposer une pull-request. Les métadata (data/auteur) peuvent être sorties des commits. Comme le mécanisme des :pushpin: sur discord, à partir du moment où l'ambassadeur du salon/un membre du staff/10 membres sont d'accords avec une PR, elle pourrait être mergée.
Qu'en pensez-vous ?
Up, en suivant les messages dans le thread sur discord, les points suivants ont en plus été abordé:
On aurait notre thème perso concocté par les devs html/css du serveur, on aurait les métadata en préamble de chaque fichier markdown, pour classifier/catégoriser les articles on placerait chaque fichier markdown dans un dossier lui allant bien (on a proposé de reprendre la structure des salons de discord).
Petite précision, peu importe la techno qu'on va choisir, on aura une documentation adaptée au débutant pour pouvoir y contribuer. Néanmoins, il est quand même temps de parler de nos choix au niveau technologiques. Nos besoins sont donc de mettre en place un site communautaire, avec une partie devblog, ressources, recrutements, vidéo & streaming, partie vos projets et d'obtenir les données via le serveur discord, le tout via une interface à minimum propre. On aura besoin de filtering, de recherche, de listing et d'une facilité pour la modification des données.
Si on part sur PHP, on a lumen, un petit framework par ceux derrière Laravel qui est franchement hyper sympa et simple pour les débutants : https://lumen.laravel.com Avantages : Très très bonne lib de parsing markdown, facile d'approche Inconvénients : Environnement de dev php un peu chiant à mettre en place (sauf avec Docker)
Si on part sur Javascript, on a Fastify, un framework très simple et sympa , il est également facile d'approche pour les débutants https://www.fastify.io Avantages : Beaucoup de gens connaissent le Javascript, langage assez simple, environnement léger, juste besoin de Node Inconvénients : Nécessite d'écrire un peu de code en plus, vu que le framework est minimal Alternative, on peut aussi un framework un peu plus lourd pour Javascript mais avec lequel il sera très simple et plus rapide de développer le site, comme Adonis https://adonisjs.com
Si on part sur Ruby, on a Jekyll, un générateur de site statique vraiment simple https://jekyllrb.com Avantages : Très très simple, encore plus pour les débutants, permet de mettre en place très rapidement, fonctionne out the box Inconvénients : Environnement Ruby, pas trop flexible, risque de poser un assez gros problème concernant le deisgn du site (vu qu'on est bloqué dans des thèmes) et d'éventuellement nous demander de changer de techo par la suite
Si on part sur Rust, on a Warp, un framework très simple et assez complet : https://github.com/seanmonstar/warp Avantages : Le meilleur langage, clairement, perf dingue pour le parsing markdown :kappa: Inconvénients : Incroyablement difficile pour les débutants, environnement chiant (=lourd) à mettre en place
Donc certe c'est important d'avoir un truc léger et facile d'approche pour les débutants, mais pensez quand même qu'il va falloir le développer le site ainsi que le maintenir et être flexible pour y ajouter des éventuelles fonctionnalités. Et aussi, c'est du Web, donc si on ajoute certaines features comme la possibilité d'avoir une recherche et de filtrer pour les recrutements par exemple, bah quoi qu'il arrive, on aura besoin de Javascript, ou du filtering côté serveur (donc d'un backend).
Je préfère préciser car mon objectif, notre objectif je pense, est de développeur un site cool pour la communauté, qui fonctionne bien et ou l'on peut ajouter des fonctionnalités sans être une purge à maintenir. Donc de ce fait, il y aura forcément des prérequis quant au développement du site en lui-même, néanmoins, pour les ressources, il est néanmoins une très bonne idée d'avoir du Markdown et de laisser le serveur faire le serveur de son côté afin de garder la facilité pour ajouter des articles ou modifier certaines parties du site.
Donc si je dois mon avis de développeur web, en prenant en compte les facteurs suivants :
Je pense franchement que Javascript l'emporte, c'est un langage qui est vraiment simple (en plus on fera une doc sur le repo), qui ne nécessite que NodeJS qui est plutôt léger, qui est quand même très populaire.
Certe, ça fait un peu chier, (moi je voulais faire du Rust 😒) mais objectivement parlant, il sera très simple et rapide de développer le site et ça restera noob-friendly.
Il y a aussi d'autres points, comme le fait que Visual Studio Code le supporte nativement avec de la bonne autocomplétion, que l'écosystème derrière est très big. Qu'on peut arriver à garder les choses très simples et complet en même temps, etc...
Dernière petite précision, mais les données des articles et diverses petites choses vont rester en format markdown, afin de rester très simple. Keep it simple.
@Julien00859 Je n'oublie pas ton commentaire concernant l'élan technologique des développeurs Javascript et c'es vrai que tu as raison, mais le fait est que, pour le site qu'on souhaite réaliser (donc un peu plus qu'un blog) il est quand même très difficile de garder juste de l'HTML & CSS, sans aucun backend ni rien.
Donc pour moi, on va devoir surtout faire en sorte que tout reste vraiment simple, via de la doc, des règles, etc... Mais je ne pense pas qu'on y échappera à un minimum de complexité.
Avant de vouloir choisir une techno, il pourrais être intéressant de faire un cahier des charges détaillés, ainsi que voir comment serait réalisé ce site.
Je lis les deux messages de MIshaa et je constate qu'on est en plein dedans, l'élan technologique des développeurs JS.
Concernant spécifiquement le point sur le recrutement, honnêtement je suis assez opposé à accueillir sur un site de NaN des articles relatif au recrutement. Les gens qui viennent faire du recrutement sont essentiellement des HR qui n'apportent intrinsèquement rien à NaN si ce n'est un nouveau message qui apparait de temps à autre dans #offre. Je suis assez opposé à leur donner encore plus de visibilité au travers d'une section qui leur serait dédié sur le site.
Bon du coup, on est revenu en arrière côté techno suite à une discussion avec @Julien00859 On va garder les choses extrêmement simples avec Github Pages
Et s’il y a éventuellement des petites parties JS à écrire, elles seront écrites à la main, au plus simple possible. Donc absolument tout le monde peut y contribuer.
Bonsoir !
On a de plus en plus de ressources, de conseils, de deblog, de membres qui partagent lerus magnifiques projets, la nécessité d'un site se fait ressentir et serait franchement agréable et pertinent.
C'est pourquoi je propose cette issue. L'idée est donc d'avoir un site internet accessible à tous, qui serait communautaire et open source et qui contiendrait différents sujets comme :
Les éventuels lives des membres (dev)
Mais, attention, il faudrait le faire de la bonne façon. En effet, NaN est avant tout un discord, il est donc nécessaire que, par exemple, les messages de recrutement soit automatiquement ajouté sur le site (ou l'inverse) ce que je veux dire par là, c’est que le site est uniquement une extension du discord, et pas l'inverse.
Maintenant, comment faire en sorte que cela ne soit pas chiant en termes de mise à jour ?
Concrètement, la partie live est déjà postée dans un canal, donc c'est facile. La partie devblog, mais il s'agit juste de pouvoir se connecter via de l'OAuth 2 et de pouvoir poster un article, ou de faire une pull request sur le Github (encore mieux). Pour la partie liens / ressources, via Github également, ça serait automatiquement mis en forme. Recrutement, c'est un canal, de même pour screenshot...
Mais, pourquoi créer un site ? L'idée est de pouvoir avoir une extension du discord, avec une interface, une ambiance et des fonctionnalités qui sont différentes. D'encourager les développeurs qui souhaitent écrire du contenu qualitatif (comme un article, une explication détaillée sur un sujet, ...) en leur donnant une "plateforme" qui met à disposition un hébergement et un éditeur. Aussi, qu'ils puissent échanger autour de ce contenu, via un fil sur le discord par exemple.
Pour la partie recrutement, avoir la possibilité de trier, de rechercher et de potentiellement trouver une offre intéressante. Aussi, on peut imaginer encourager les petits streamers membre du discord à réaliser des lives sur Twitch, et avoir la possibilité de voir les membres qui stream sur une page dédiée.
C'est encore assez difficile d'avoir une idée exacte de comment serait le site, je pense que moi et beaucoup de membre a des idées et qu'on peut arriver à proposer quelque chose d'agréable en quelques pages. Et surtout, pour moi, il est nécessaire que ça reste juste une extension du discord, quelque chose de simple. C'est pour cette raison que je n'ai pas proposé de forum par exemple.
Maintenant, comment serait développé le site ? Déjà, il serait open source sur ce Github dans un répo dédié. Au niveau des technologies, je pense que Github pages est une excellente idée, cela permettrait de très facilement mettre à jour le site et de n'avoir pratiquement aucune maintenance. Le boulot n'est franchement pas énorme, avec quelques membres et l'implémentation de quelques pages, cela peut être réalisé assez rapidement.
Pour ma part, la partie que je souhaiterais réaliser avec une belle interface et quelque chose de simple, c'est la partie des ressources, pour que les développeurs recherchant des bons cours / ressources puissent voir rapidement toutes les ressources qu'on recommande.
Vous en pensez quoi ? C'est une bonne chose, une mauvaise chose ? Une idée de fonctionnalité ?