Add references to Roads and Bridges
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Fred Pauchet 2022-06-09 20:40:42 +02:00
parent de1e298225
commit 81da4e3069
9 changed files with 58 additions and 9 deletions

View File

@ -1,4 +1,4 @@
\appendix{Snippets}
\chapter{Snippets}
\section{Nettoyage de chaînes de caractères}

View File

@ -1,2 +1,2 @@
\appendix{SonarQube}
\chapter{SonarQube}

View File

@ -624,7 +624,8 @@ Dans l'exemple ci-dessus, l'utilisation du module \texttt{is-odd} requière déj
Imaginez la suite.
Réduire le nombre de dépendances accélère également l'intégration d'une personne souhaitant participer au projet: n'ajoutez pas de nouvelles dépendances à moins que leur plus-value ne surpasse le temps qu'il sera nécessaire à vos développeurs actuels et futurs pour en appréhender toutes les fonctionnalités \cite[Simplicity]{django_for_startup_founders}.
Soyez intelligents et n'ajoutez pas systématiquement une nouvelle dépendance ou fonctionnalité uniquement parce qu'elle est disponible, et maintenez la documentation nécessaire à une utilisation cohérente d'une dépendance par rapport à vos objectifs et au reste de l'application.
Soyez intelligents et n'ajoutez pas systématiquement une nouvelle dépendance ou fonctionnalité uniquement parce qu'elle est disponible, et maintenez la documentation nécessaire à une utilisation cohérente d'une dépendance par rapport à vos objectifs et au reste de l'application \footnote{Ce syndrôme est connu sous le nom de \textit{Magpie developer} - ou \textit{Syndrôme de la pie, mais adapté aux développeurs} -, qui fait qu'un développeur est souvent attiré par tout ce qui est "nouveau et brillant", plutôt que les technologies qui fonctionnent bien pour eux et pour leurs utilisateurs \cite[p. 42]{roads_and_bridges}}.
Conserver des dépendances à jour peut facilement vous prendre 25\% de votre temps \cite[Upgradability]{django_for_startup_founders}: dès que vous arrêterez de les suivre, vous risquez de rencontrer des bugs mineurs, des failles de sécurité, voire qu'elles ne soient plus du tout compatibles avec d'autres morceaux de vos applications.
\subsection{Dependency Inversion}

View File

@ -1,5 +1,15 @@
\chapter{Docker-Compose}
\begin{quote}
Docker [\ldots] helps software applications run inside containers.
(Containers provide a clean, tidy environment for software applications that make them easier to run anywhere).
Docker started as an internal project within dotCloud, a platform-as-a-service, but became so popular that the founders decided to make Docker the main focus of the company.
The Docker project was open sourced in 2013.
Docker has raised \$180M with an estimated valuation of over \$1B.
Their business is based on support, private plans, and services.
Docker's 2014 revenue was less than \$10 million \cite[p. 48]{roads_and_bridges}
\end{quote}
(c/c Ced' - 2020-01-24)
Ça y est, j'ai fait un test sur mon portable avec docker et cookiecutter pour django.

View File

@ -6,7 +6,7 @@
--- Robert C. Martin
\end{quote}
Nous n'allons pas vous mentir: il existe énormément de tutoriaux très bien réalisés sur "\emph{Comment réaliser une application Django}" et autres "\emph{Déployer votre code en 2 minutes}".
Il existe énormément de tutoriaux très bien réalisés sur "\emph{Comment réaliser une application Django}" et autres "\emph{Déployer votre code en 2 minutes}".
Nous nous disions juste que ces tutoriaux restaient relativement haut-niveaux et se limitaient à un contexte donné, sans réellement préparer à la maintenance et au suivi de l'application nouvellement développée.
Les quelques idées ci-dessous de jeter les bases d'un bon développement, en
@ -19,7 +19,18 @@ Les quelques idées ci-dessous de jeter les bases d'un bon développement, en
\end{itemize}
Ces idées ne s'appliquent pas uniquement à Django et à son cadre de travail, ni même au langage Python en particulier.
Ces deux sujets sont cependant de bons candidats et leur utilisation et cadre de travail sont bien définis, documentés et flexibles.
Dans \href{http://blog.codinghorror.com/why-ruby/}{un article de blog}, Jeff Atwood, développeur .Net expérimenté, a décrit sa décision de développer Discourse en utilisant le language Ruby \cite[p. 27]{roads_and_bridges}.
La même réflexion s'applique sans effort à Python et Django:
\begin{quote}
Getting up and running with a Microsoft stack is just plain too hard for a developer in, say, Argentina, or Nepal, or Bulgaria.
Open source operating systems, languages, and tool chaines are the great equializer, the basis for the next great generation of programmers all over the world who are goind to help us change the world.
\end{quote}
L'organisation \textit{Django Girls} a par exemple formé plus de 2000 femmes dans le monde, réparties dans plus de 49 pays \footnote{https://djangogirls.com}.
Django n'a pas été développé par cette organisation elle-même, mais étant \textit{open source}, ce framework peut être téléchargé, utilisé et étudié gratuitement. \cite[p. 28]{roads_and_bridges}.
Si ces morceaux logiciels n'étaient pas libres et accessibles, ils ne pourraient pas être déconstruits, analysés, étudiés et publiés, ni aider certaines personnes à exercer leur propre métier. \footnote{Les termes \textit{free software} et \textit{open source} sont généralement accolés l'un à l'autre; ils ont cependant une conotation politique distincte: le premier est étroitement associé à l'éthique tandis que le second est plus pragmatique. \textit{Open source is a development methodology; free software is a social movement.}\cite{gnu}}
L'ouverture de ces langages et frameworks en fait également un modèle bien défini de documentation et de flexibilité.
Django se présente comme un \emph{Framework Web pour perfectionnistes ayant des deadlines} \cite{django} et suit ces quelques principes \cite{django_design_philosophies}:

View File

@ -697,9 +697,9 @@ Selon le principe du SRP \ref{SRP}, c'est le framework lui-même qui doit en ass
\section{Licence}
Choisissez une licence!
Si votre projet n'a aucune licence, vous pourriez être tenu responsable.
En cas de désastre médical ou financier, cela peut faire toute la différence.
Choisissez une licence.
Si votre projet n'en a pas, vous pourriez être tenu responsable de manquements ou de bugs collatéraux.
En cas de désastre médical ou financier, ce simple fichier peut faire toute la différence.
\section{Conclusions}

View File

@ -1,2 +1,4 @@
\chapter{Svelte}
\textit{React, for example, has an additional clause that could potentially cause patent claim conflicts with React users} \cite[p. 47]{roads_and_bridges}.
Cette issue a été adressée en 2017 \footnote{\url{hhttps://github.com/facebook/react/issues/7293}}.

View File

@ -98,3 +98,24 @@ Nous allons détailler ci-dessous trois méthodes de déploiement:
\item
Sur une \textbf{Plateforme en tant que Service} (ou plus simplement, \textbf{PaaSPaaS}), pour faire abstraction de toute la couche de configuration du serveur.
\end{itemize}
Vous noterez que l'ensemble des composants utilisés sont \textit{Open source}:
\begin{quote}
When I built my first company starting in 1999, it cost \$2.5 million in infrastructure just to get started and another \$2.5 million in team costs to code, launch, manage, market and sell our software [\ldots].
The first major change in our industry was imperceptible to us as an industry.
It was driven by the introduction of open-source software, most notably what was called the LAMP stack.
Linux (instead of UNIX), Apache (web server software), MySQL (instead of Oracle) and PHP.
Of course there were variants - we preferred PostGres to MySQL and many people used other programming languages than PHP.
Open source became a movement - a mentality: Suddenly infrastructure software was nearly free.
We paid 10\% of the normal costs for the software and that money was software support.
A 90\% disruption in cost spawns innovation - belive me.
-- Mark Suster
\end{quote}
Dans tous les cas, la disponibilité de logiciels et librairies \textit{open source}, ainsi que des plateformes d'hébergements (comme Amazon Web Services ou Heroku) plus accessibles signifient qu'une startup n'a plus besoin d'investir des millions pour démarrer \cite[p. 25]{roads_and_bridges} \footnote{Avant que les logiciels libres n'existent, les entreprises technologiques traitaient les logiciels comme n'importe quel produit payant: une équipe d'employés construisait les nouveaux logiciels en interne, puis les vendait au public.
Le développement logiciel avait donc un business-model très clair, mais ceci venait en contrepartie avec des coûts énormes.
Les logiciels propriétaires demandaient des équipes complètes pour supporter le développement, tandis qu'il fallait également des vendeurs, une équipe marketing et un troupeau d'avocats. \cite[p. 33]{roads_and_bridges}}.

View File

@ -60,7 +60,7 @@
isbn = {978-1-491-95452-2},
url = {http://shop.oreilly.com/product/0636920049555.do}
}
@book{roads_bridges,
@book{roads_and_bridges,
title = {Roads and Bridges},
booktitle = {The Unseen Labor Behind Our Digital Infrastructure},
author = {Nadia Eghbal},
@ -104,6 +104,10 @@
title = {The web framework for perfectionists with deadlines},
url = {https://www.djangoproject.com/}
}
@misc{gnu,
title = {Why Open Source Misses the Point of Free Software},
url = {http://www.gnu.org/philosophy/open-source-misses-the-point.en.html}
}
@misc{
django_design_philosophies,
title = {Design Philosophies},