Design & Développement web - Le topic des canards qui mangent des cookies

[Orhin]

GET avec une id qui n'existe pas : 404 d'office. Je veux pas me faire chier à interpreter le putain de corps de la réponse si y'a rien à interpreter.

Sachant qu'en plus un retour 204 ne pète pas une erreur dans la majorité des framework/lib ce qui fait qu'on doit analyser ce retours hors du pipe d'erreur.
Et c'est du coup très moche.

Perso, c'est :
- 404 si ressources qui n'existe pas
- [] si liste vide

[Teocali]

Sachant qu'en plus un retour 204 ne pète pas une erreur dans la majorité des framework/lib ce qui fait qu'on doit analyser ce retours hors du pipe d'erreur.
Et c'est du coup très moche.

This.

Perso, c'est :
- 404 si ressources qui n'existe pas
- [] si liste vide

This, again.

[William Vaurien]

en C le pipe d'erreur c'est Segmentation Fault... du coup il faut que j'analyse le code de retour toute façon dans ce client
Heureusement qu'il y a des pointeur de fonction pour avoir un traitement générique dans un callback.

[Ashley TOUCRU]

https://fr.wordpress.org/plugins/backwpup/

Merci beaucoup, je vais tester ça.

[Whiskey]

Aloha

Dites j'ai une petite question sommaire, en ce moment je suis en train de me former à l'ASP.NET Core avec MVC, (non je viens pas pour du .net) et j'aimerais me former sur une librairie css/js pour la mise en place (ou en forme) de mes pages oueb, après plusieurs recherches, je tombe sur 2 choix possibles :

- Bootstrap ( https://getbootstrap.com/ )
- Foundation ( https://foundation.zurb.com/ )

J'ai déjà un peu tester Bootstrap, et c'est pas mal. Foundation je découvre actuellement. J'aurais aimer avoir votre avis sur les 2, lequel je dois prendre pour évoluer avec lui (aller plus loin quoi ^^ ), lequel est le mieux selon vous ?

Merci.

[Dross]

Bootstrap c'est le grand classique, c'est sans doutes le plus connu aujourd'hui. Tu peux pas te tromper avec lui.
Foundation, connais pas, mais je me tiens pas trop à jour sur les frameworks CSS, ça a l'air d'être bien aussi, fait quelques tests avec l'un et l'autre et choisi en fonction (le second semble proposer des petits outils sympa si tu utilise le SCSS, ça peut être un plus en sa faveur).

[Calys]

Alors pour avoir eu l'occasion d'utiliser les deux plusieurs fois, voilà mon avis :

- Bootstrap c'est une solution clé en main, facile à apprendre, tu trouve un tas de ressources dessus, c'est idéal pour les applications web, tu peux sortir une interface propre en peu de temps. Par contre c'est relativement limité en terme de personnalisation.
- Foundation (avec SCSS) c'est un formidable outil pour créer la structure de tes pages web. Par contre c'est assez moche de base (avis personnel ). Je l'ai uniquement utilisé pour des sites web, tu crée une structure responsive en un rien de temps, et tu l'habille avec ton design perso.

[ShotMaster]

Franchement, si t'es en formation, fais du Bootstrap. C'est plus facile, plus rapidement joli et en plus c'est connu en entreprise.

[Whiskey]

Franchement, si t'es en formation, fais du Bootstrap. C'est plus facile, plus rapidement joli et en plus c'est connu en entreprise.

Alors pour avoir eu l'occasion d'utiliser les deux plusieurs fois, voilà mon avis :

- Bootstrap c'est une solution clé en main, facile à apprendre, tu trouve un tas de ressources dessus, c'est idéal pour les applications web, tu peux sortir une interface propre en peu de temps. Par contre c'est relativement limité en terme de personnalisation.
- Foundation (avec SCSS) c'est un formidable outil pour créer la structure de tes pages web. Par contre c'est assez moche de base (avis personnel ). Je l'ai uniquement utilisé pour des sites web, tu crée une structure responsive en un rien de temps, et tu l'habille avec ton design perso.

Bootstrap c'est le grand classique, c'est sans doutes le plus connu aujourd'hui. Tu peux pas te tromper avec lui.
Foundation, connais pas, mais je me tiens pas trop à jour sur les frameworks CSS, ça a l'air d'être bien aussi, fait quelques tests avec l'un et l'autre et choisi en fonction (le second semble proposer des petits outils sympa si tu utilise le SCSS, ça peut être un plus en sa faveur).

Ok merci pour votre réponse, c'est vrai que bootstrap semble etre plus facile que foundation, vais voir de ce coté (sans laisser de coté foundation).

[Thomasorus]

Go bootstrap.
Après si la raison pour laquelle tu prends bootstrap c'est pour la grille, essaie plutôt de faire du CSS Grid, ça te sera utile.

[Fastela]

Perso j'aime beaucoup Bulma, c'est une alternative très intéressante à Bootstrap.

[ShotMaster]

Tiens je connaissais pas du tout Bulma, ça a l'air pas mal, je vais regarder ça.

[Orhin]

Semantic UI est pas trop mal aussi.

[Gillete]

Je rejoins les autres.
Forme toi sur Bootstrap, c'est simple à prendre en main, plein de tutoriels et de documentation à disposition, assez vendeur auprès des entreprises et tu as immédiatement quelque chose de relativement propre et joli (un point assez important quand tu débute je trouve). Tu pourras basculer sur d'autres frameworks plus tard, mais tu auras appris le vocabulaire de base bien plus facilement avec lui

[Thomasorus]

Et si tu bosses pour de grosses boites, installer bootstrap sera souvent la seule chose graphique que tu feras. Pour ce genre de clients BS c'est superbe parce qu'ils bossent sur des web app en html basique depuis 15 ans.

[Whiskey]

Je connaissais pas bulma non plus , je testerais a l'occasion, mais la je pense partir effectivement sur Bootstrap, je commence bien a comprendre son fonctionnement. Merci à tous

[yuushiro]

En restant dans le sujet des codes retours HTTP, selon vous, le 403 vous l'utiliseriez seulement dans le cas où les paramètres de requêtes sont invalides / mal formés, mais en aucun cas pour un problème au niveau du traitement fonctionnel ?

[Getz]

Ni l'un ni l'autre, 403 c'est forbidden...
Pour des requêtes mal formés c'est 400 ou 406.

[Gillete]

Pour simplifier la vie de mon équipe au taf, j'aimerai développer une petite application.

Dans mon cahier des charges imaginaire, je souhaite avoir un mini dashboard qui présente certaines informations. C'est du très classique, mais pour que la page soit pratique et utile au quotidien, j'aimerai qu'elle envoi des notifications et indique visuellement dans son onglet qu'il y a une action à réaliser, un peu comme peut le faire Slack ou GMail. Nous utilisons Azure (assez mal à mon avis) comme une base de données ou un espace de stockage déporté. Nous y recevons des fichiers sur un container qui sont ensuite traités par un batch sur notre serveur physique. De temps en temps, certains d'entre eux ne sont pas correctement traités et nous n'avons pas de mécanique automatisée pour nous alerter du problème. Le plus sage consisterai à refondre tous les process liés, ce qui est prévu, mais pas dans la roadmap à court terme.

Je ne sais trop comment m'y prendre pour gérer ces notifications.
Dans une version Quick&Dirty, c'est la page qui interroge toutes les x-minutes le container pour voir s'il y a des fichiers en erreurs et pop une notification. J'aimerai que cela soit fait de façon plus intelligente et que ce soit le container qui indique à la page qu'une erreur à eu lieu.

J'ai un background de dev back et j'ai un peu laissé passer les wagons des technos et possibilité offerte par le front. Je profite de ces mini sujets hors scope au boulot pour rattraper un petit mon retard. Je vais continuer sur le couple VueJS/C# qui fonctionne plutôt très bien je trouve. Est-ce que vous avez des mots clefs sur lesquels je peux me pencher ?

[Orhin]

Regarde du côté des Websocket et notamment de la librairie Socket.io.

En restant dans le sujet des codes retours HTTP, selon vous, le 403 vous l'utiliseriez seulement dans le cas où les paramètres de requêtes sont invalides / mal formés, mais en aucun cas pour un problème au niveau du traitement fonctionnel ?

Erreur 500 dans les 2 cas + code spécifique renvoyé.
On est dans des cas trop proches du métier pour pouvoir fournir une solution générique.

[yuushiro]

Ni l'un ni l'autre, 403 c'est forbidden...
Pour des requêtes mal formés c'est 400 ou 406.

En effet, je me suis pris les pieds dans le tapis des retours HTTP, c'était bien 400 (Bad Request) et pas 403 que je voulais dire (je pense que c'est à force d'en prendre que je fais une fixette dessus)

Erreur 500 dans les 2 cas + code spécifique renvoyé.
On est dans des cas trop proches du métier pour pouvoir fournir une solution générique.

Ok, merci

[Getz]

Regarde du côté des Websocket et notamment de la librairie Socket.io.


Erreur 500 dans les 2 cas + code spécifique renvoyé.
On est dans des cas trop proches du métier pour pouvoir fournir une solution générique.

Oui le mot clé magique c'est websocket

Pas trop d'accord sur ton utilisation de l'erreur 500. Pour moi, l'erreur 500 c'est vraiment une erreur serveur:

Les réponses de code d'état 5xx indiquent une situation dans laquelle le serveur sait qu'il est la cause de l'erreur, ou est incapable de fournir le service demandé, bien que la requête ait été correctement formulée.

La classe 4xx de codes d'état est définie pour répondre au cas où il semble que le client ait commis une erreur.

Ici, s'il s'agit de mauvais paramètres d'entrée, le fautif est le client et non pas le serveur.

[Teocali]

Ni l'un ni l'autre, 403 c'est forbidden...
Pour des requêtes mal formés c'est 400 ou 406.

This.

A noter qu'il ne faut pas confondre avec 401.

401, c'est unauthirazed, aka. "qui êtes vous monsieur ? Je ne vous connais pas"
403, c'est forbidden, aka. "Ca va pas être possible monsieur. Oui, je vous connais. Raison de plus"

- - - Mise à jour - - -

Regarde du côté des Websocket et notamment de la librairie Socket.io.


Erreur 500 dans les 2 cas + code spécifique renvoyé.
On est dans des cas trop proches du métier pour pouvoir fournir une solution générique.

Pas tout a fait d'accord : si la requête est mal formés, erreur 400.
Invalide est un terme trop générique.

Erreur 500, c'est uniquement si le serveur est responsable de l'erreur, typiquement une exception pas prévu. je ne pense pas que ce soit le cas ici.

[ShotMaster]

Dans mon précédent job, Spring Security te balançait une 401 quand tu tentais de rentrer en boite sans ton token, et Spring Rest une 403 quand tu tentais d’accéder au carré VIP en baskets.

Spring

[ShotMaster]

Bon après, t'avais un collègue qui se plantait sur un @Autowired et qui entraînait l'explosion du projet en plein de petits bouts de caca.

[Teocali]

Dans mon précédent job, Spring Security te balançait une 401 quand tu tentais de rentrer en boite sans ton token, et Spring Rest une 403 quand tu tentais d’accéder au carré VIP en baskets.

Spring

Si Spring rest te renvoyait une 403, c'était Spring security derrière
Et c'était logique : le token est ton authorization. Si t'en pas, boum, refus d'accès sur tout.
Si t'en as un mais que monsieur, franchement, le carré VIP en basket... boum, 403

Et j'aime Spring d'amour vrai.

Là, pour un petit client, j'ai passé son application codé avec les pieds par un unijambiste sous Spring Boot en mode rapide. Et je suis en train de lui greffer une API rest dessus, en mode CRUD-mais-pas-seulement, avec Spring Rest+Spring Rest data+Spring Security+Spring Security ACL... j'ai quasiment pas de code Java a écrire pour l'application en elle-même, juste celui de creation des ACL à la creaiton d'un nouvel objet/user.

Par contre, putain, la migration des données, quelle galère (le schema de base de donnée est aussi pourri que le code)... merci à Flyway et son intégration dans Spring Boot pour ça, ça m'évite de m'arracher tous les cheveux (seulement les deux tiers).

[ShotMaster]

une API rest dessus, en mode CRUD-mais-pas-seulement, avec Spring Rest+Spring Rest data+Spring Security+Spring Security ACL.

Owi, fais moi jouir

Sinon j'ai raccourci. Spring Security s'occupait de générer l'erreur de droits de l'utilisateur. Spring Rest s'occupait de récupérer l'erreur et d'en sortir une jolie 403. L'idée c'était que y'avait quelques erreurs de droits qui n'en étaient pas vraiment (à cause d'un serveur de jeton externe de Net Entreprise )

Alors que la 401 il faisait ça tout seul comme un grand.

[PaulPoy]

Regarde du côté des Websocket et notamment de la librairie Socket.io.

Et si la perf prime, peut être regarder du côté de https://github.com/uNetworking/uWebSockets

[Orhin]

Pas tout a fait d'accord : si la requête est mal formés, erreur 400.
Invalide est un terme trop générique.

Erreur 500, c'est uniquement si le serveur est responsable de l'erreur, typiquement une exception pas prévu. je ne pense pas que ce soit le cas ici.

Oui, faute de frappe de mon côté, je voulais dire 400 + code d'erreur qui explique le problème.

Et si la perf prime, peut être regarder du côté de https://github.com/uNetworking/uWebSockets

Ouais y'a beaucoup mieux que Socket.io maintenant, mais c'est un peu comme le débat sur Bootstrap au dessus.
C'est la plus connue et avec le plus de doc et de gens à même de répondre aux questions.

[Dross]

J'ai un background de dev back et j'ai un peu laissé passer les wagons des technos et possibilité offerte par le front. Je profite de ces mini sujets hors scope au boulot pour rattraper un petit mon retard. Je vais continuer sur le couple VueJS/C# qui fonctionne plutôt très bien je trouve. Est-ce que vous avez des mots clefs sur lesquels je peux me pencher ?

Comme les autres ont dit, Websocket.
Mais comme tu est dans la caverne de MS (comme moi d'ailleurs), je te dirai même : SignalR (y'a du websocket dedans mais aussi d'autres trucs)