184 lines
9.3 KiB
TeX
184 lines
9.3 KiB
TeX
\chapter{Outils de développement}
|
|
|
|
\section{Environnement de développement}
|
|
|
|
Concrètement, nous pourrions tout à fait nous limiter à Notepad ou Notepad++.
|
|
Mais à moins d'aimer se fouetter avec un câble USB, nous apprécions la complétion du code, la coloration syntaxique, l'intégration des tests unitaires et d'un debugger, ainsi que deux-trois sucreries qui feront plaisir à n'importe quel développeur.
|
|
|
|
Si vous manquez d'idées ou si vous ne savez pas par où commencer:
|
|
|
|
\begin{itemize}
|
|
\item
|
|
\href{https://vscodium.com/}{VSCodium}, avec les plugins
|
|
\href{https://marketplace.visualstudio.com/items?itemName=ms-python.python}{Python}et
|
|
\href{https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens}{GitLens}
|
|
\item
|
|
\href{https://www.jetbrains.com/pycharm/}{PyCharm}
|
|
\item
|
|
\href{https://www.vim.org/}{Vim} avec les plugins
|
|
\href{https://github.com/davidhalter/jedi-vim}{Jedi-Vim} et
|
|
\href{https://github.com/preservim/nerdtree}{nerdtree}
|
|
\end{itemize}
|
|
|
|
Si vous hésitez, et même si Codium n'est pas le plus léger (la faute à
|
|
\href{https://www.electronjs.org/}{Electron}\ldots\hspace{0pt}), il fera
|
|
correctement son travail (à savoir: faciliter le vôtre), en intégrant
|
|
suffisament de fonctionnalités qui gâteront les papilles émoustillées du
|
|
développeur impatient.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics{images/environment/codium.png}
|
|
\caption{Codium en action}
|
|
\end{figure}
|
|
|
|
\section{Terminal}
|
|
|
|
\emph{A priori}, les IDE \footnote{Integrated Development Environment}
|
|
proposés ci-dessus fournissent par défaut ou \emph{via} des greffons un
|
|
terminal intégré. Ceci dit, disposer d'un terminal séparé facilite
|
|
parfois certaines tâches.
|
|
|
|
A nouveau, si vous manquez d'idées:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
Si vous êtes sous Windows, téléchargez une copie de
|
|
\href{https://cmder.net/}{Cmder}. Il n'est pas le plus rapide, mais
|
|
propose une intégration des outils Unix communs (\texttt{ls},
|
|
\texttt{pwd}, \texttt{grep}, \texttt{ssh}, \texttt{git},
|
|
\ldots\hspace{0pt}) sans trop se fouler.
|
|
\item
|
|
Pour tout autre système, vous devriez disposer en natif de ce qu'il faut.
|
|
\end{enumerate}
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics{images/environment/terminal.png}
|
|
\caption{Mise en abîme}
|
|
\end{figure}
|
|
|
|
\section{Un gestionnaire de base de données}
|
|
|
|
Django gère plusieurs moteurs de base de données.
|
|
Certains sont gérés nativement par Django (PostgreSQL, MariaDB, SQLite); \emph{a priori}, ces trois-là sont disponibles pour tous les systèmes d'exploitation.
|
|
D'autres moteurs nécessitent des librairies tierces (Oracle, Microsoft SQL Server).
|
|
|
|
Il n'est pas obligatoire de disposer d'une application de gestion pour ces moteurs: pour les cas d'utilisation simples, le shell Django pourra largement suffire (nous y reviendrons).
|
|
Mais pour faciliter la gestion des bases de données elles-même, et si vous n'êtes pas à l'aise avec la
|
|
ligne de commande, choisissez l'une des applications d'administration
|
|
ci-dessous en fonction du moteur de base de données que vous souhaitez
|
|
utiliser.
|
|
|
|
\begin{itemize}
|
|
\item
|
|
Pour \textbf{PostgreSQL}, il existe
|
|
\href{https://www.pgadmin.org/}{pgAdmin}
|
|
\item
|
|
Pour \textbf{MariaDB} ou \textbf{MySQL}, partez sur
|
|
\href{https://www.phpmyadmin.net/}{PHPMyAdmin}
|
|
\item
|
|
Pour \textbf{SQLite}, il existe
|
|
\href{https://sqlitebrowser.org/}{SQLiteBrowser} PHPMyAdmin ou
|
|
PgAdmin.
|
|
\end{itemize}
|
|
|
|
\section{Un gestionnaire de mots de passe}
|
|
|
|
Nous en auront besoin pour gé(né)rer des phrases secrètes pour nos applications.
|
|
Si vous n'en utilisez pas déjà un, partez sur \href{https://keepassxc.org/}{KeepassXC}: il est multi-plateformes, suivi et s'intègre correctement aux différents environnements, tout en restant accessible.
|
|
|
|
\includegraphics{images/environment/keepass.png}
|
|
|
|
\subsection{Un système de gestion de versions}
|
|
|
|
Il existe plusieurs systèmes de gestion de versions.
|
|
Le plus connu/utilisé à l'heure actuelle est \href{https://git-scm.com/}{Git}, notamment pour sa (très) grande flexibilité et sa rapidité d'exécution.
|
|
Il est une aide précieuse pour développer rapidement des preuves de concept, switcher vers une nouvelle fonctionnalité, un bogue à réparer ou une nouvelle release à proposer au téléchargement.
|
|
Ses deux plus gros défauts concernent sa courbe d'apprentissage pour les nouveaux venus et la complexité des actions qu'il permet de réaliser.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics{images/xkcd-1597-git.png}
|
|
\caption{\url{https://xkcd.com/1597/}}
|
|
\end{figure}
|
|
|
|
Même pour un développeur solitaire, un système de gestion de versions (quel qu'il soit) reste indispensable.
|
|
|
|
Chaque "\textbf{branche}" correspond à une tâche à réaliser: un bogue à corriger (\emph{Hotfix A}), une nouvelle fonctionnalité à ajouter ou un "\emph{truc à essayer}" \footnote{Oui, comme dans "Attends, j'essaie vite un truc, si ça marche, c'est beau."} (\emph{Feature A} et \emph{Feature B}).
|
|
|
|
Chaque "\textbf{commit}" correspond à une sauvegarde atomique d'un état ou d'un ensemble de modifications cohérentes entre elles.\footnote{Il convient donc de s'abstenir de modifier le CSS d'une application et la couche d'accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up.}
|
|
De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics{images/diagrams/git-workflow.png}
|
|
\caption{Git en action}
|
|
\end{figure}
|
|
|
|
Cas pratique: vous développez cette nouvelle fonctionnalité qui va révolutionner le monde de demain et d'après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux
|
|
normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.
|
|
Il suffit alors de:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
Sauver le travail en cours (\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ {[}WIP{]}})
|
|
\item
|
|
Revenir sur la branche principale (\texttt{git\ checkout\ main})
|
|
\item
|
|
Créer un "hotfix" (\texttt{git\ checkout\ -b\ hotfix/pci-compliance})
|
|
\item
|
|
Solutionner le problème (sans doute un \texttt{;} en trop ?)
|
|
\item
|
|
Sauver le correctif sur cette branche
|
|
(\texttt{git\ add\ .\ \&\&\ git\ commit\ -m\ "Did\ it!"})
|
|
\item
|
|
Récupérer ce correctif sur la branche principal
|
|
(\texttt{git\ checkout\ main\ \&\&\ git\ merge\ hotfix/pci-compliance})
|
|
\item
|
|
Et revenir tranquillou sur votre branche de développement pour fignoler ce générateur de noms de dinosaures rigolos que l'univers vous réclame à cor et à a cri (\texttt{git\ checkout\ features/dinolol})
|
|
\end{enumerate}
|
|
|
|
Finalement, sachez qu'il existe plusieurs manières de gérer ces flux d'informations.
|
|
Les plus connus sont \href{https://www.gitflow.com/}{Gitflow} et \href{https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/}{Threeflow}.
|
|
|
|
|
|
\subsection{Décrire ses changements}
|
|
|
|
La description d'un changement se fait \emph{via} la commande \texttt{git\ commit}.
|
|
Il est possible de lui passer directement le message associé à ce changement grâce à l'attribut \texttt{-m}, mais c'est une pratique relativement déconseillée: un \emph{commit} ne doit effectivement pas obligatoirement être décrit sur une seule ligne.
|
|
Une description plus complète, accompagnée des éventuels tickets ou références, sera plus complète, plus agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.
|
|
|
|
De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique. Par exemple:
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics{images/environment/gitea-commit-message.png}
|
|
\caption{Un exemple de commit affiché dans Gitea}
|
|
\end{figure}
|
|
|
|
La première ligne est reprise comme titre (normalement, sur 50 caractères maximum); le reste est repris comme de la description.
|
|
|
|
\section{Bases de données}
|
|
|
|
Parfois, SQLite peut être une bonne option:
|
|
|
|
\begin{quote}
|
|
Write througput is the area where SQLite struggles the most, but there's not a ton of compelling data online about how it fares, so I got some of my own: I spun up a Equinix m3.large.x86 instance, and ran a slightly modified1 version of the SQLite kvtest2 program on it.
|
|
Writing 512 byte blobs as separate transactions, in WAL mode with synchronous=normal3, temp\_store=memory, and mmap enabled, I got 13.78$\mu$s per write, or \textasciitilde72,568 writes per second. Going a bit larger, at 32kb writes, I got 303.74$\mu$s per write, or \textasciitilde3,292 writes per second.
|
|
That's not astronomical, but it's certainly way more than most websites being used by humans need.
|
|
If you had 10 million daily active users, each one could get more than 600 writes per day with that.
|
|
\end{quote}
|
|
|
|
\begin{quote}
|
|
Looking at read throughput, SQLite can go pretty far: with the same test above, I got a read throughput of \textasciitilde496,770 reads/sec (2.013$\mu$s/read) for the 512 byte blob.
|
|
Other people also report similar results
|
|
|
|
--- Expensify reports that you can get 4M QPS if you're willing to make some slightly more involved changes and use a beefier server.
|
|
Four million QPS is enough that every internet user in the world could make \textasciitilde70 queries per day, with a little headroom left over.
|
|
Most websites don't need that kind of throughput. \cite{consider_sqlite}
|
|
\end{quote}
|
|
|
|
|
|
|