Antichesse (o ^ω^ o)
Via https://chezsoi.org/shaarli/?sud-5Q (merci pour le lien)
Des bonnes pratiques PHP mises à jour à cette date (2019-07-01).
Via Brihx.
Des tips & tricks que je retiens :
- Toujours mettre ses noms de tables et colonnes en minuscules (parce que Postgre convertie les majuscules en minuscule au run)
- Ne jamais utiliser
psql -Woupsql --passwordcar Postgre vous demandera un mot de passe même s'il n'y en a pas. - L'héritage c'est mal en programmation, c'est mal dans une base de données (et pour les mêmes raisons).
- Toujours utiliser
timestamptzà la place detimestampafin de gérer les time-zones en plus. - Utiliser VARCHAR tout court à la place de VARCHAR(N).
Je cite la meilleure réponse :
I cannot point you to a tutorial, but can mention some things based on experience with writing RESTful services using Spring MVC.
split the Controllers from the business logic. Concerns to have in the Controllers: most of all error handling, also potentially authorization. The Controller methods might be quite thin initially, and just dispatch to corresponding business logic methods. That's not a bad thing, soon your Controllers will grow with issues of interfacing clients.
speaking of error handling, it is quite hard to get it right in a RESTful service. You definitely need to have a way to nicely inform the clients of errors, via structured data. That should be a part of all your responses, I guess. You will need to decide which errors you send back info about, which ones you are silent about and just log, etc.
most probably you will have some data objects for the requests you are getting, and the responses you are sending. Package them in a separate jar. Add to this jar interfaces, implemented by your Controllers. Add also a simple second implementation of these interfaces, that makes calls to your service. Here you go, you have a client lib. Distribute it, make your Java clients happy.
Even though now you have a nice Java client lib, do not forget to also test your service with curl, and document how to use it this way, with simple calls. Make your non-Java users happy.
There are all kinds of libs for "unit" testing Controllers, by mocking up more or less of the internals of a web server. These are very useful, but do not limit yourself to them. Have a qa env, where you fully deploy your service, and have a qa app which sends real fully fledged requests to the instance of your service on the qa env, and analyses their responses.
Try to keep things simple and consistent across the different calls. For example every response can contain the same "error" part with the same fields giving information in a structured programatically usable form about what went wrong.
REST is a nice abstraction, but has its limitation: in practice, /delete.json?id=3 can have very different effects on different services. Do not expect your clients to be able to guess what "add" and "delete" will mean in your particular case, as they will probably guess differently from what you expected. Instead, provide in your documentation some information about what your service will be doing under the hood. We are not yet at a stage where we are able to have components communicating via the knowledge of just a very thin interface, staying agnostic of their internals, unfortunately.
C'est très bien dit je trouve.
Pour @Animal et @Lenny.
Simple layout and design tips to help you create a stunning webpage.
Je commence a identifier les canons du genre 😃.
Let's build the future of the web. With actionable guidance and analysis, web.dev helps developers like you learn and apply the web's modern capabilities to your own sites and apps.
Google avait lancé un site reprenant des bonnes pratiques des applis-web, de leur front à leur back.
Avant toute chose, SMACSS n'est pas un framework CSS, c'est un ensemble de pratiques CSS/SCSS permettant d'écrire des feuilles de styles clean code.
Rien que sur les deux premières pages, j'y ai choppé des astuces.
@Lenny @Doudou @Chlouchloutte, c'est pour vous !
Edit :
Pour faire gagner du temps à tout le monde, je tente ici d'établir un résumé des concepts.
1. Les CSS se divisent en 5 catégories :
-
Base : ce sont les CSS des éléments HTML. Typiquement, le body, le html, la couleur par défaut des liens, des inputs. Bref, les balises HTML, sans classes ni ID.
-
Layout : votre page se découpe en général par grands blocs (d'ailleurs presque toujours les mêmes lorsque l'on respecte les canons du milieu). En général, ils portent un ID, se trouvent directement dans le
<body>et vous y trouverez les sectionsheader,footer,content,side-content,article,side-bar... -
Module : il s'agit de la même chose que les Layouts, à la différence qu'ils se trouvent soit dans un Layout, soit dans un Module eux-mêmes. Ils sont conçus pour être auto-porteurs et nous pouvons les comparer aux JPanels de Swing (ça me fait mal d'écrire ça). En général, ils ne sont pas forcément unique, ne portent pas d'ID, et leurs contenus sont skinés via une classe héritée, typiquement :
.mon-module span {...}
.mon-module a {...}
- **State :** ce sont les CSS qui vont changer l'interface en fonction des actions de l’utilisateur. Ils sont forcément liés à du JS de part leur aspect dynamique. Par exemple, vous cliquez sur un bouton et une zone passe de _is-visible_ à _is-hidden_. En général, ils commencent par `is-...` ou `has-...` et ne sont constitués que de classes.
- **Theme :** il s'agit de tout ce qui touche à l'apparence mais pas l'orientation et la forme cf. (modules) ni la structure de la page (cf. layouts). Ils comprennent donc les couleurs (texte & background), l'épaisseur des traits et bordures, la police de caractères, les images de fond, les logos, etc.
### 2. L'usage de SCSS ou SASS
Pour thématiser des CSS, il faut les variabiliser et pour ce faire nous avons deux outils :
- SASS (et sa variante que je lui préfère SCSS car plus proche de CSS pour les néophytes).
- Les variables CSS.
À cela s'ajoute un autre point, il faut générer plusieurs fichiers CSS (un principale contenant les 4 premières catégories de CSS, et un par thème afin de pouvoir changer dynamiquement de thème pendant l'exécution).
### 3. Les bonnes pratiques
J'en utilisais déjà pas mal sans y avoir forcément réfléchi, mais de façon formelle :
- Limiter la profondeur d'imbrication des balises HTML quand vous le pouvez.
- Limiter la profondeur d'imbrication des CSS (mieux vaut préférer l'imbriquation du HTML à l'imbriquation des CSS).
- Utiliser le moins d'ID possible puisqu'ils sont spécifiques à votre PWA et rendront difficile le portage de votre design vers une autre PWA.
- Changer de thème ne consiste pas à modifier toutes les balises HTML, non. Il faut supprimer du DOM le CSS contenant le fichier de l'ancien thème pour y ajouter un `<link>` vers celui du nouveau thème.
- Si vous n'utilisez pas des polices comme Fontisto ou Fontawesome, utilisez des sprites CSS avec des images, vous aurez moins de requêtes HTTP et moins de data à transférer.
- Éviter de faire du balisage HTML spécifique à votre contenu.Tuto très sympa. @Lenny, si tu as le temps, essaie de lire ce post. Il y a quelques idées à prendre 😃.
La structure de commit que je propose (en reprenant ce que dit l'article) :
Summarize changes in around 80 characters or less
More detailed explanatory text, if necessary. Wrap it to about 120 characters or so. In some contexts, the first line is
treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from
the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get
confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code
explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain
them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank
lines in between, but conventions vary here
If you use an issue tracker, put references to them at the bottom, like this:
Resolves: #123
See also: #456, #789L'objectif de ce guide à la programmation est de vous apprendre à écrire des lignes de code de manière claire et concise.
Pour @Doudou qui me l'avait demandé.
Je cite :
Ça c'est l'un des gros gros points noirs de Linux: Les myriades de fichiers cachés (commençant par un point) que les applications utilisent pour stocker leurs données (configuration, etc.) dans chaque répertoire utilisateur.
Même si les fichiers ne sont pas visibles, c'est un énorme bordel.
En tant que développeur, il y a pourtant des règles à suivre pour limiter ce chantier ($XDG_DATA_HOME/$XDG_CONFIG_HOME/$XDG_CACHE_HOME...).
Plein de bonnes pratiques PHP adaptablent à d'autres langages. #Kotlin 😍
Pour Doudou, plutôt orienté PHP mais très bien à découvrir.
Quelques bonnes pratiques de sécurité
Évidemment sans prendre tout le contenu du $JENKINS_HOME histoire de limiter la consommation disque et le temps de backup.
Un bon résumé des éléments pratiques dans le langage Kotlin. Je vous invite à en juger par vous-même.
Pour toi Chlouchloutte qui est en train de concevoir une API
Comment sécuriser son serveur avec SSL et TLS (surtout TLS 1.2)
Ce qu'il faut faire et ne pas faire en PHP
Un ensemble de bonnes pratiques sur PHP