Aller au contenu principal

5 articles tagués avec « blog »

Voir tous les tags

· 7 minutes de lecture
Jonas Turbeaux
Glen Llaci
Mike Caron

Préambule

Dans la Coop', on pense que ça ne sert à rien de faire du logiciel libre si on explique pas pourquoi et comment. Donc premier effort à fournir : de la documentation et de la vulgarisation.

On commence par un chantier participatif ? Tous les lundi : cod' ensamb !

L'idée : Recoder tout le projet LaBoutik (Caisse enregistreuse, cashless, monnaie locale, etc... pour en savoir plus : https://tibillet.org).

Étape par étape, comme un grand tutoriel géant, nous allons détailler pourquoi et comment nous le construisons.

Le but avoué est d'encourager les contributions aux projets de la coopérative, de réduire le flou technologique, de vulgariser le code, mais surtout de s'engager dans une démarche de partage de savoir.

Koi fé ? (TLDR;)

Dans ce tuto, nous allons voir comment :

  • Préparer son environnement de développement python avec Poetry
  • Configurer l'IDE de Jetbrain, Pycharm, pour qu'il nous facilite la vie
  • Installer Django 4.2
  • Créer ses premiers objets en base de donnée
  • Créer une interface d'admin pour les créer et les manipuler

Codons le logiciel de caisse enregistreuse "LaBoutik" depuis zero

La "stack" :

Autrement dit, l'ensemble des librairies, framework (cadriciel) et outils divers pour construire notre solution.

  • Linux (ubuntu/debian) quoique, on pourrait installer la stack sur windows et mac, mais on va le faire paske faut bien choisir.
  • Python 3.10
  • Poetry (outil de gestion d'environement python qui sert à maintenir nos versions à jour et nous assurer que les librairies n'aient pas d'incompatibilité entre elles )
  • Django 4.2

Et bien sur notre IDE préféré qui nous facilite grandement la tache : Pycharm (https://www.jetbrains.com/fr-fr/pycharm/)

Le dépot GIT

Travaillons sur le dépot : https://github.com/CoopCodeCommun/LaBoutik-CodEnsamb

Installons Poetry

curl -sSL https://install.python-poetry.org | python3 -
git clone git@github.com:CoopCodeCommun/LaBoutik-CodEnsamb.git
### Sur Mac :
brew install poetry

Une fois le poetry installé et le repos git crée. On peut initialiser le poetry. A La racine du projet :

poetry init

Répondez aux questions en vérifiant
Compatible Python versions 3.10 : laissez par defaut . Pour les question concernant les dépendances , répondez No ( nous les installerons nous meme )

Vous avez maintenant un fichier pyproject.toml dans votre projet qui reprend tous les paramétres saisis . Ouvrez ce fichier , vous pouvez ici entrer les dépendances que vous sohaitez dans la section [tool.poetry.dependencies]:

Le ^ indique version minimun Nous allons ajouter Django en ligne de commande en figeant la version à l'aide de @ ( à ce jour Octobre 2023 la version stable est : 4.2) :

poetry add django@4.2

Ce qui à pour effet d'installer aussi les dépendances necessaires pour le projet et de créer le fichier poetry.lock qui est l'état actuel de notre projet .

Si vous avez cloné le projet , les 2 premières étapes poetry init et poetry add django@4.2ne seront pas necessaire .( elles le sont uniquement si vous partez de zéro * )

Maintenant entrons et travaillons dans l'environement virtuel qui nous permet d'avoir le meme environement de travail quelque soit l' OS utilisé :

poetry shell

Installons et configurons Django

Créons le projet (l'application)

    django-admin startproject laboutik .
// le point '.' est utilisé pour que la racine du project soit dans le dossier dont on est situé
./manage.py startapp labutik_core

idem( * ) les 2 premières commande ci dessus ne sont plus necessaires si vous avez cloné le projet .

Dans laboutik/settings.py on ajoute:

    INSTALLED_APPS = [
...,
'laboutik_core',
]

AUTH_USER_MODEL = 'laboutik_core.CustomUser'

Dajngo à besoin d'une BD, nous allons la créer :

./manage.py migrate

on voit une nouvelle base de données dans notre projet :

et dans le fichier settings :

Pour le moment nous laissons sqlite3, nous changerons plus tard en Production vers une DB plus adaptée .

Lançons le serveur :

./manage.py runserver

Maintenant en vous connectant à l'adresse : http://127.0.0.1:8000/ vous devriez avoir la page ci dessous :

Vous avez maintenant dans votre projet 2 nouveaux répertoires laboutik et laboutik_core et le fichier racine manage.py :

Configurons Pycharm

Pour l'instant nous n'avons pas indiqué à Pycharm notre environement . Il faut lui indiquer que nous travaillons avec Python3.10 , Poetry et Django . Configurons l'interpreteur , dans settings de Pycharm :

Add interpreter/Local/Poetry environement :

Dans "Poetry executable" indiquez le chemin d'installation de poetry installé precedemment .

Vérifions la configuration pour Django :

Du coup maintenant Pycharm va nous alerter en cas d'erreur de syntaxe , proposer de l'auto-complétion ... trop top 👍

Merci à JetBrains de nous supporter pour nos projets . Pour tester si notre IDE a bien compris notre environement de travail , allez dans le fichier urls.py placer le curseur sur "path" et faites F12 . Vous devriez etre redirigé vers le fichier conf.py .

Remarque pour Mac : le raccourcis clavier est "fn + F12" si cela ne fonctionne pas modifiez le model Keymap sur " sublime Text Copy"

Modele user

La création d'un model user custom est fortement conseillé dès le début du projet. Dans le futur il devient très compliqué de modifier le modele user une fois nos modeles sont lancés.

Dans le fichier models.py :

from django.db import models
from django.contrib.auth.models import AbstractUser
from uuid import uuid4

class CustomUser(AbstractUser):
"""
Modèle de base pour les utilisateurs
On utilise des uuid4 plutôt que des pk auto-incrementés
"""
uuid = models.UUIDField(primary_key=True, default=uuid4, editable=False, db_index=False)

Dans le fichier settings.py :

# Model user custom
AUTH_USER_MODEL = 'laboutik_core.CustomUser'

On applique les modifications en faisant une migration :

./manage.py makemigrations
./manage.py migrate

Architecture rapide du projet

Listons les "objects" dont nous allons avoir besoin.

  • Configuration
  • Point de vente
  • Catégories
    • Produit
      • TVAs
    • Prix
  • Users
    • droits
  • Moyens de paiement
  • Ventes

Codons nos objets :

Dans le fichier models.py :

TODO: Vidéo sur https://peertube.communecter.org

Le detail du codage en Live ici

Création du modèle de base de donnée et d'administration

Routage url

le fichier urls.py

il existe déja l'url de l'admin:

urlpatterns = [
path('admin/', admin.site.urls),
]

Lancement du serveur :

./manage.py runserver
-> Starting development server at http://127.0.0.1:8000/

Du coup, si je vais dans http://127.0.0.1:8000/admin/

Administration Django

Créons notre utilisateur admin.

# Création du super user "root"
./manage.py createsuperuser

Attention, createsuperuser fabrique des users avec is_staff = True ET is_superuser = True Seul is_staff est nécéssaire pour acceder à l'admin. is_superuser est comparable à un utilisateur "ROOT" qui a tout les droits sur l'admin.

Enregistrer les modèles dans l'admin :

# laboutik_core/admin.py
from django.contrib import admin
from laboutik_core.models import Product, Price, VAT, Category, PointOfSale

# Register your models here.

admin.site.register(Product)
admin.site.register(Price)
admin.site.register(VAT)
admin.site.register(Category)
admin.site.register(PointOfSale)

TODO: Uploader dans peertube La vidéo complete en detail ici

Conclusion

Nous avons maintenant notre environnement installé et nous pouvons créer des objets en base de donnée.

Dans les prochaines sessions, nous verrons comment créer notre "frontend" avec les templates Jinja, et comment rendre cette stack "MVT" moderne avec HTMX.

· Une minute de lecture
Jonas Turbeaux

https://framablog.org/wp-content/uploads/2023/10/hacker-bibel-ccc-p15.png

Le logiciel libre n’est pas exempt de causer [un] effet de domination ne serait-ce parce que les rapports aux technologies sont rarement équilibrés. On a beau postuler l’horizontalité entre concepteur et utilisateur, ce dernier sera toujours dépendant, au moins sur le plan cognitif. Dans une économie contributive idéale du Libre, concepteurs et utilisateurs devraient avoir les mêmes compétences et le même degré de connaissance. Mais ce n’est généralement pas le cas et comme disait Lawrence Lessig, « Code is law »

[...]

L’équilibre peut alors être trouvé en créant des chaînes de confiance, c’est-à-dire des efforts collectifs de création de communs de la connaissance (formations, entraide, vulgarisation) et des communs productifs : des organisations à tendances coopératives et associatives capables de proposer des formules d’émancipation pour tous. Créer du Libre sans proposer de solutions collectives d’émancipation revient à démontrer que la liberté existe à des esclaves enchaînés tout en les rendant responsables de leurs entraves.

· 2 minutes de lecture
Jonas Turbeaux
  • Auteur : Sam et Max, Bloggeur français à propos de Python, Django, Linux, Open Source, Free Software, etc.
  • Article original : Hacker News

/img/blog/hypermedia/original.png

Je suis heureux de constater que les approches minimalistes, comme svelte, htmx et alpine.js sont de plus en plus prisées.

J'ai eu l'impression de me battre seul pendant les années dorées de node, webpack et react où tout le monde créait des piles folles et ajoutait GraphQL et ainsi de suite, pour essentiellement obtenir ce que Django + jquery ont fait il y a 10 ans en un dixième du temps et du code.

Jusqu'à présent, j'ai également survécu [à ces déclarations ]:

  • xml est l'avenir
  • utilisons nosql pour toutes les choses
  • il faut utiliser le même langage pour le back comme pour le front
  • oui, votre site doit avoir une version AMP (ah, vous l'avez oubliée celle-là, n'est-ce pas ? C'était tellement important, et puis pouf, c'est parti comme une larme sous la pluie)
  • oui, votre page d'accueil doit être une SPA
  • vous ne pouvez rien coder sans async
  • vous ne pouvez pas vivre sans une file d'attente de messages
  • tout doit devenir un micro-service
  • bien sûr, vous avez besoin d'un conteneur pour cela
  • il faut bien sûr un orchestrateur pour organiser ces conteneurs
  • bien sûr, vous avez besoin du nuage, il serait insensé de s'occuper soi-même de ces conteneurs et de ces orchestrateurs
  • Hey, pourquoi as-tu un serveur ? Utilise un backend sans serveur !
  • Hey, pourquoi as-tu un backend ? Il suffit de l'appeller depuis une plateforme Saas !

Chaque année, une génération d'ingénieurs doit apprendre les concepts suivants : "il n'y a pas de solution miracle", " utilisez la bonne technologie pour le bon problème", "vous n'êtes pas Google", "réécrire une base de code tous les deux ans n'est pas une bonne décision commerciale", "les choses coûtent de l'argent".

· 8 minutes de lecture
Jonas Turbeaux

TLDR :

Libérez vous de la pression qu'apporte le Javascript partout. Lorsque vous utilisez une approche hypermédia pour votre application web, vous êtes libre de choisir la technologie côté serveur qui correspond le mieux à votre problème et à vos goûts techniques.

/img/blog/hypermedia/whowillwin.png

Préalable.

Nous souhaitons à travers ce blog partager des articles, des tips, des philosophies ou des idées qui ont un rapport de près ou de loin avec les projets de la coopérative.

Je vais donc commencer par un concept que je découvre récemment (depuis un an ou deux.) et dont j'aime discuter : la " pile HOWL".

HOWL est l'acronyme de Hypermedia On Whatever you'd Like.

La suite est une traduction de l'article de Carson Gross : HOWL: Hypermedia On Whatever You'd Like

Si le sujet vous intéresse, je vous invite vous balader sur les sites suivant, il y a plein de concepts intéressants à découvrir.

remarque

SPA : Single Page Application. Une application web qui ne charge qu'une seule page HTML et qui utilise JavaScript pour modifier le contenu de la page. Globalement, la philosophie de React, Vue et de tout les frameworks front-end Javascript modernes.

MPA : Multiple Page Application.

Hypermedia partout

Carson Gross May 23, 2023

Le seul grand avantage restant des MPAs est le choix du langage de programmation côté serveur. Si vous faites déjà partie de la résistance anti-JavaScript, alors rien de ce que je dirai dans le reste de cet exposé n'aura d'importance. Mais j'y reviendrai plus tard : ce bateau a peut-être coulé...

Rich Harris - Les SPA ont-ils ruiné le Web ?

Un concept dont nous aimons parler est celui de la "pile HOWL". HOWL est l'acronyme de Hypermedia On Whatever you'd Like.

En résumé, la pile HOWL est la suivante : lorsque vous utilisez une approche hypermédia pour votre application web, vous êtes libre de choisir la technologie côté serveur qui correspond le mieux à votre problème et à vos goûts techniques.er server-side technology best fits your problem and your own technical tastes.

La pression du JavaScript

Si vous décidez d'utiliser un framework SPA pour votre application web, vous aurez naturellement une large base de code front-end écrite en JavaScript.

Dans ces conditions, la question suivante se posera inévitablement :

"Pourquoi ne faisons-nous pas aussi le back-end en JavaScript ?"

C'est une question raisonnable et il y a beaucoup d'avantages à adopter le même langage de programmation des deux côtés du fil :

  • Vous pouvez partager la logique d'application entre les deux bases de code. La logique de validation en est un bon exemple.
  • Vous pouvez partager des structures de données entre les deux bases de code.
  • Vous pouvez acquérir une expertise dans un seul langage, JavaScript, ce qui permet aux développeurs de travailler plus facilement sur les différentes parties de votre application.
  • Vous pouvez réutiliser le système de construction et les connaissances en matière de gestion des dépendances que vous avez acquises pour la partie frontale.

Cette pression en faveur de l'adoption de JavaScript ne fera que croître au fur et à mesure que votre investissement dans l'écosystème JavaScript augmentera.

En outre, JavaScript s'est considérablement amélioré au cours des cinq dernières années et il existe aujourd'hui plusieurs excellents applications côté serveur pour l'exécuter. Bon nombre des anciens arguments concernant le désordre du langage peuvent être écartés car ils peuvent être évités grâce au linting, à la discipline des développeurs, etc.

JavaScript est le langage dominant parmi les leaders d'opinion en matière de développement web et il existe un grand nombre de tutoriels, de code camps, etc. qui mettent fortement l'accent sur ce langage. Rien ne réussit mieux que le succès, et JavaScript (ainsi que React) a réussi.

Appelons le résultat de cette situation la pression JavaScript et reconnaissons que presque tous les développeurs travaillant dans le web la ressentent au moins dans une certaine mesure.

/img/blog/hypermedia/htmlvsjson.png

Hypermedia : Notre seul espoir

Quel espoir les développeurs non-JavaScript ont-ils dans le développement web ?

Eh bien, il existe une technologie plus ancienne utilisé dans les navigateurs : l'hypermédia.

Les navigateurs offrent un excellent support HTML (et le Document Object Model, ou DOM). En fait, même si vous utilisez un framework SPA, vous travaillerez avec cette infrastructure hypermédia sous une forme ou une autre (via des modèles JSX, par exemple), ne serait-ce que pour créer des interfaces utilisateur qu'un navigateur peut comprendre.

Vous utiliserez donc HTML ou les API DOM connexes d'une manière ou d'une autre dans votre application web.

Et si nous faisions de HTML un hypermédia plus puissant ?

C'est l'idée de htmx, qui permet de mettre en œuvre des modèles d'application web modernes courants en utilisant l' approche hypermédia. Cela comble le fossé entre les MPA et les SPA traditionnelles, en rendant possible l'adoption de l' approche hypermédia pour un nombre beaucoup plus important d'applications web.

Une fois que vous avez adopté cette approche hypermédia (et rappelez-vous que vous allez de toute façon utiliser l'infrastructure hypermédia, alors pourquoi ne pas l'exploiter autant que possible ?), un effet secondaire surprenant se produit :

Soudain, l'avantage du choix du langage côté serveur que Harris attribuait aux MPAs est de nouveau d'actualité.

Si l'interface de votre application est principalement écrite en termes de HTML, avec peut-être un peu de script côté client, et sans grande base de code JavaScript, vous avez soudainement diminué de façon spectaculaire (ou entièrement éliminé) la pression JavaScript au niveau de l'interface.

Vous pouvez désormais choisir le langage (et le cadre) côté serveur en fonction d'autres considérations : techniques, esthétiques ou autres :

  • Peut-être travaillez-vous dans le domaine de l'IA et souhaitez-vous utiliser une variante Lisp pour votre projet ?
  • Peut-être travaillez-vous dans le domaine du big data et souhaitez-vous utiliser Python ?
  • Vous connaissez peut-être très bien Django et vous aimez l'approche "batteries-included" qu'il adopte.
  • Peut-être préférez-vous Flask et l'approche dépouillée qu'il adopte ?
  • Peut-être aimez-vous l'aspect brut et proche du HTML de PHP ?
  • Vous avez peut-être une base de code Java existante qui a besoin d'être améliorée.
  • Peut-être que vous apprenez Cobol, et que vous voulez utiliser htmx pour en faire une interface agréable.
  • Peut-être aimez-vous vraiment Rust, Ocaml, Kotlin, Haskell, .NET, Clojure, Ada, ColdFusion, Ruby... peu importe !

Il s'agit là de points de vue techniques, philosophiques et esthétiques tout à fait raisonnables.

Et, en adoptant l'hypermédia comme principale technologie front, vous poursuivez tous ces objectifs sans avoir recours à une double base de code. L'hypermédia ne se soucie pas de ce que vous utilisez pour le produire : vous pouvez utiliser l'hypermédia sur ce que vous voulez. HOWL !

Un Web ouvert à tous

Et quand nous disons "tout le monde", nous le pensons vraiment.

Voici une capture d'écran de la sous-section HOWL du discord htmx récemment. Notez qu'il ne s'agit que des canaux qui ont un trafic actif, il y en a beaucoup d'autres.

/img/blog/hypermedia/howl-channels.png

Vous pouvez voir que nous avons des conversations en cours dans un tas de langages de programmation et de frameworks différents : Java, Go, .NET, Rust, Clojure, PHP, Ruby, Python, Ocaml. Nous avons même des gens qui parlent de l'utilisation de htmx avec Bash et Cobol !

C'est exactement l'avenir que nous voulons voir : un Web riche et dynamique dans lequel chaque langage et cadre d'arrière-plan peut jouer le rôle d'une alternative intéressante. Chaque langage et framework possède ses propres forces et propres cultures et chacun peut contribuer au système hypermédia magique qu'est le Web.

Mais... S'agit-il d'une résistance anti-JavaScript ?

Avant de terminer cet essai, nous voulons aborder l'idée que la résistance à JavaScript partout est nécessairement anti-JavaScript.

Il est vrai que nous avons eu notre part de blagues sur JavaScript et que nous sommes allés jusqu'à créer un langage de script alternatif pour le web, l'hyperscript.

On pourrait donc penser que nous devrions être des anti-javascripteurs patentés.

Mais, au contraire, nous apprécions profondément JavaScript.

Après tout, htmx et hyperscript sont tous deux construits en JavaScript. Nous n'aurions pas pu créer ces bibliothèques sans JavaScript qui, quoi qu'on en dise, a le grand mérite d'être là.

Nous allons même jusqu'à recommander l'utilisation de JavaScript pour les besoins de scripts frontaux dans une application hypermédia, à condition que vous scriptiez d'une manière adaptée aux hypermédias.

De plus, nous ne déconseillons pas l'utilisation de JavaScript (ou TypeScript) côté serveur pour une application hypermédia, si ce langage est la meilleure option pour votre équipe. Comme nous l'avons dit précédemment, JavaScript dispose aujourd'hui de plusieurs excellents runtimes côté serveur et de nombreuses excellentes bibliothèques côté serveur.

C'est peut-être la meilleure option pour vous et votre équipe, et il n'y a aucune raison de ne pas l'utiliser.

Hypermedia On Whatever you'd Like signifie exactement cela : ce que vous voulez.

Mais JavaScript n'est pas, et ne devrait pas être, la seule option côté serveur pour votre équipe.

Le grand retournement

Avec la résurgence de l'intérêt pour les hypermédias (et leur amélioration), un avenir ouvert et diversifié pour le Web est désormais une possibilité réelle, voire une réalité émergente.

Le Web a été conçu pour être un système hypermédia ouvert, polyglotte et participatif.

Et ce rêve n'a pas encore pris fin, du moins pas encore !

Nous pouvons maintenir ce rêve en vie en réapprenant et en adoptant la technologie fondamentale du web : l'hypermédia.

· 3 minutes de lecture
Jonas Turbeaux

Tout l'équipe de la Coopérative Code Commun vous souhaite la bienvenue sur notre blog !

Aussi, nous migrons les articles du blog originalement postés sur https//tibillet.org/blog ici.

Note d'intention

Nous souhaitons à travers ce blog partager des articles, des tips, des philosophies ou des idées qui ont un rapport de près ou de loin avec les projets de la coopérative.

Vous trouverez donc dans ce blog des citations, des traductions d'articles, des notes personnelles, des tutoriels, des recettes de création de logiciel libre... Bref, tout ce qui peut encourager le partage de connaissances, la transmission de savoir, et la diffusion de la culture libre.

Et si tout ceci vous donne envie de venir contribuer à nos projets, voire même à ce blog, génial ! Venez discuter avec nous ( checkez les liens dans le bas de page ) !

/img/Graphical_codecommun540.png

Historique et origine

A l'origine du projet de la Coopérative, il y a TiBillet, le Manapany Festival et l'association organisatrice : Les 3Peaks. Nous étions une bande de joyeux.ses bidouilleur.ses.s et développeur.ses.s bénévoles. Nous avions décidé de créer nos propres outils numériques principalement pour une raison : nous avions envie d'apprendre à le faire nous même :)

En dehors du festival annuel, l'association hébergeait un café associatif ouvert régulièrement et organisait des évènements culturels mensuels avec une contrainte : si l'entrée était libre à tous et toutes, il nous fallait un outil pour gérer les adhésions associatives et les paiements des consommations. Pourquoi ne pas continuer à utiliser la carte NFC cashless du festival tout au long de l'année ?

En même temps, nous regardions comment les solutions existantes des professionnels du secteur fonctionnaient : Carte et bracelets NFC à usage unique, remboursement limité dans le temps, prix prohibitif pour l'organisateur et le public... Nous ne voulions vraiment pas reproduire un modèle qui semblait être juste un moyen de faire payer plus les festivaliers...

Voici que la carte d'adhésion 3Peask est née : Valide à vie, gratuite, rechargeable en ligne, remboursable à tout moment, utilisable au café associatif toute l'année comme au festival, elle permettait de gérer un point de vente et une caisse enregistreuse tout en s'assurant que le membre associatif était à jour de sa cotisation.

Et ça a cartonné ! Avoir plus de 800 membres à l'année fut une expérience très enrichissante. Nous développions TiBillet au fur et à mesure des besoins, des remarques et des idées de nos membres : nous codons un outil que nous utilisons au quotidien.

Aujourd'hui (Juin 2023), après 6 ans de développement, la carte TiBillet permet beaucoup de choses, et nous avons décidé de monter notre équipe en coopérative pour péréniser et rassembler autour de ce projet.

Et bien tout ceci, c'est ce que l'on va tenter de vous raconter dans ce blog. Nous allons essayer de vous expliquer ce que nous faisons, comment nous le faisons, pourquoi nous avons fait comme ça et tout ce qui nous motive !

A très vite !