Reprise du message précédent :

La plupart sont juste les topics initiaux banni ou fermés par les admins, avec la liberté de parole et le contenu qui ont justement fait leur fermeture, rien de plus
 
Mais j'avoue que voir tous les gens qui shitstorm des deux côtés (ceux qui y ont accès, et ceux qui imaginent l'antre du diable), c'était assez marrant.

Whirlpool ici, la première à fait 2001/2014, la seconde est toujours en place.

 
Ouch.
 
On était full office 365, donc Skype for business (une messe dans nom, surtout quand ton équipe réseau chie la gestion du WAN), yammer (admettons, le rapport signal / bruit est pas bon), et donc trans, qui est jamais qu'un hybrid slack / SharePoint.
Pour l'avoir pas mal utilisé ces 6 derniers mois, l'ux est pourrie (switcher entre ses teams est lourd, voir ce qui a généré un badge de notification est pas trivial parce que cliquer sur le badge renvoie vers la team mais pas forcément le message en question), et par défaut le truc te spamme de mails comme une bourrique.
 
Je présume que c'est pas cher si t'as des licences O365, mais vous allez le regretter.
 

 
Hé ho, je recommande que de la qualité germanique (ils ont fait leurs preuves )
Miele, V-Zug  
C'est en effet hors de prix, en ce moment Samsung semble avoir un bon rapport qualité prix
 

 
C'est en cours de migration, ils l'ont annoncé des deux côtés.
Sinon mon blog sous Github pages a son DNS chez Gandi, t'en déduis quoi ?

J’ai un ptit projet qui arrive en dehors du taff (40 jours de dev). Rien de bien compliqué, hormis se plugger à quelques services externes. Mais je sais pas quelles technos choisir.  
 
Ça fait un ptit moment que j’ai fais du back sur un vrai projet (hors poc ou mvp donc).  
 
Le front sera en React.
BDD Mysql.  
Back API REST.  
 
Mais quelle techno back...    
Symfony je me sens rouillé (plus d’un an et demi que j’ai pas touché). J’ai surtout fait du 2.7 quoi. Puis avec VScode c’est pas ouf d’en faire. Et j’ai plus de licence intellij/phstorm et la flemme de ressortir ce bordel.  
 
ExpressJS est cool mais ça me parait « léger ». Enfin SF vient avec tout plein d’outils pour la sécurité ou même gestions admin / users via quelques bundles. Ou encore validator. Et y’a pas d’ORM par défaut.  
 
TypeORM est hyper cool à utiliser, mais sans Typescript c’est chiant car pas de doc. Et ExpressJS en Typescript C’est chiant à utiliser. moindre truc qui pète et tu perds 1h sur stackoverflow.  
 
Me reste Sails JS. Je connais pas du tout mais pour avoir vu la doc ça a l’air cool.

 
sigh  
 
Effectivement, c’est inclus dans Office365 donc il est difficile de justifier Slack quand c’est utilisé par une petite partie des utilisateurs (IT).  
Surtout que les intégrations Slack avec tout ce qui est Atlassian ou Jenkins est pas mal utilisé. On fait nos stand ups avec des bots, donc on va peut être réussir à justifier nos besoins uniques  

https://theamphour.com/394-jeri-ell [...] of-castar/  
 
'tain c'est trop excellent !

 
Qui va la maintenir ?
T'as des contraintes techniques ?

Aujourd'hui je vais voir Erik Meijer
https://icresearchday.epfl.ch/#speakers

par curiosité c'est quoi qui a lâché ?

Il a pas mis Calgon

 
Moi normalement. Sauf si le projet me saoule et que j'arrête de le faire une fois livré.
 
Aucune, je suis libre.

REST-REST ou RPC-over-HTTP-REST?

Si c'est le premier, je te crois pas une seule seconde, si c'est le second fais du graphql à la place.

actix-web

 
 
Bah explique moi la diff. Car jamais entendu le deuxième.    
 
Et déjà que j'sais pas quoi choisir, tu me rajoutes une techno en plus.

 
Haier bas de gamme ici.
Le capteur de fermeture de la porte déconne un peu, le panneau de commandes déconne aussi un peu suite à une double intervention pour remplacer un composant qui prenait feu.
Mais ça lave le linge depuis 10 ans

Le 2e c'est ~100% du "REST" que tu trouves sur l'internet: tu documentes un tas de paires (verbe, URL) qui sont en fait des méthodes RPC. Le premier, c'est REST comme initialement décrit (de ce que font les navigateurs), parfois appelé HATEOAS: tu documentes une seule URL et un tas de types de contenu, et le client est censé naviguer de lien en lien à partir de l'URL racine jusqu'à trouver la page ou l'action dont il a besoin.

Fondamentalement c'est pas une grosse techno, c'est surtout que le client peut décrire ses besoins en profondeur (récursivement), et ça se paire bien avec les composants react parce-que tu peux avoir tes composants qui fournissent des fragments graphql, composés en une seule grosse requête (comme ça le machin au sommet peut demander toutes les données en une fois).

Si t'as un repo github, joue avec https://developer.github.com/v4/explorer/

Tout est pas idéal (les indirections via Connection/node|edge pour pouvoir faire de la pagination c'est un peu moisi), mais globalement c'est vraiment pratique. Genre j'ai un bout de graphql (github v4) qui donné un nom de repo va aller récupérer toutes les PRs (par pages de 100) incluant tous les champs de base, le login du créateur, le repo/branche source, le nombre de commits dans la PR, les statuses de la tête de la PR et les commentaires sur la PR.

C'est juste une requête graphql, via l'API v3 (RPC) il faut 2~3 requêtes par PR pour toper toutes les infos dont j'ai besoin, sachant que $KANGOLGORP a pas loin de 15000 PRs et que github a un ratelimit de genre 5000 requêtes/heure, il m'aurait fallu une journée complète pour synchroniser le repo

 
Arthur martin, le mien a duré 16 ans... jeté car les caoutchoucs commençaient à avoir une moisissure que dont on arrivait pas à se débarrasser (faute de lavages périodiques à plus de 40°). Mécanique et électronique nickel.. dommage...
Faure : celui qui l'a remplacé, choisi en fonction des retours sur les marques les plus solide du moment. Rien à dire depuis 2 ans.
 
Après, garde à l'esprit que quasiment tous les lave-linge toutes marques confondues sortent des même usines en Pologne.. Un mot d'ordre : il y a de la flotte, il y a de la chaleur... -> Le moins d’électronique possible (pas d'écran à la con, pas de lancement à la con par Wifi), le seul truc utile, c'est le démarrage différé, le reste, c'est de la merde inutile qui ne demande qu'à tomber en panne

Pour les moisissures, un lavage à vide à froid avec une bonne dose d'eau de javel est assez radical.

 
on a tenu comme ça pendant 1 an, mais à la fin, c'était trop piqué... il n'y avait plus rien à faire...
 
Après... 16 ans, c'est honnête. Si tout l'electro ménager avait cette durée de vie ce serait formidable

Merci beaucoup pour ces explications.
Alors effectivement, je ferais le deuxième. Par contre à mon taff, on fait le premier, REST-REST où on me renvoie les routes suivantes dans la première réponse etc.

Merci encore pour ces explications. Justement GraphQL on est plusieurs au taff à forcer pour l'utiliser, j'ai vu pas mal de conf dessus, notamment à Devoxx.
Mais je t'avoue que ma stack back est déjà pas très sur en NodeJS, donc jveux pas me planter même si j'ai chiffré large, d'où l'interet de limiter le nombre de technos que je maîtrise moins bien.

Pour le coup, je suis entièrement libre, le client s'en fou. Il veut son produit, m'a expliqué le besoin et me fait confiance pour tous les choix. Il sera juste casse couille sur l'UX en gros.

Et oui j'ai plusieurs repos github, je vais check ça.

EDIT : Effectivement les trucs paginations sont chiants, mais putain de pratique.

Je ne m'emmerde plus, si le lavelinge est dans un espace pas bruyant, je prends le moins cher, ça dure aussi longtemps qu'un machin à 500 euros, parce qu'on ne sait pas quand ça va péter, plus il y a d'électronique et de gadgets, plus chiant à réparer et cher.  
Ca doit juste laver, pourquoi prendre un truc qui coute une couille ?
même pour un sèche-linge, une fois qu'on a choisi l'un des 3 types dispo dans le commerce en fonction de son environnement et on prends pas le plus technologique, le plus basique suffira.

 
J'ai pas creusé en détail mais ça pourrait remplir ton besoin https://github.com/Siecje/nginx-auth-proxy (l'implémentation ou le principe) ?
Je ne dis pas que c'est la façon idéale ni la plus simple.
 
Une autre façon qui m'a l'air plus simple à mettre en place : https://www.nginx.com/resources/wik [...] s/x-accel/ ou l'équivalent X-SENDFILE sur apache.

 
Je vois à priori plusieurs soucis :
* ces options (si j'ai bien compris en survolant 30 secondes) généreraient une surcouche d'auth, ils ne feraient pas disparaitre  pour les utilisateurs les pages qui demandent le login/mdp non secure. J'aurais donc des gens authentifiés, mais qui peuvent toujours prendre dans l'appli qu'il y a derrière l'identité d'un autre utilisateur sans trop de difficultés.
* en vrai j'ai simplifié - il y a plusieurs applis concernées derrières, et plusieurs modes d'auth différents à brancher dessus en fonction du type d'utilisateur.
* il faudrait que je migre les frontaux impliqués sous nginx

...j'avais peut-être mal expliqué ce que je dois faire à la base...un exemple de test que j'ai fait pour valider que c'est faisable, ça peut aider à comprendre éventuellement :

<?php
 
$root = "https://machin.fr/";
$endpoint = "bidule";
 
$login= 'toto';
$lolmdp= '123456';
 
$ch = curl_init($root.$endpoint."/authentificationMoisie.jsp?login=".$login."&lolmdp=".$lolmdp); //accès à $root.$endpoint."/authentificationMoisie.jsp restreint à l'ip du serveur qui héberge $root - et ce script.
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_COOKIESESSION, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_COOKIEFILE, "" );
 
$result = curl_exec($ch);
preg_match_all('/^Set-Cookie:\s*([^;]*)/mi', $result, $matches);
$cookies = array();
foreach($matches[1] as $item) {
    parse_str($item, $cookie);
    $cookies = array_merge($cookies, $cookie);
}
 
foreach($cookies as $id=>$value) {
    setcookie($id, $value, 0, '/' . $endpoint, '', true, true);
}
 
$header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
$body = substr($result, $header_size);
$header = substr($result, 0, $header_size);
 
echo $body;

...et ça fait a priori ce que je veux, reste à implémenter ce qui va en amont pour authentifier l'utilisateur correctement et récupérer $login et $lolmdp...

Tu peux faire du graphql sans impliquer nodejs où que ce soit. Ya des libs pour implémenter l'endpoint en Python, Ruby, PHP, java, C#, …

Et les requêtes c'est juste une grosse chaîne dans un appel HTTP, avec du JSON en retour.

 
Oui ça je sais bien. Ce que je voulais dire, c’est que je me fais vieux en SF, donc je vais partir sur du Node mais je maîtrise pas entièrement Express et pas Sails par exemple. Donc si j’ajoute Typescript ou encore GraphQL, ça me fait beaucoup de truc d’un coup que je maîtrise pas pour un projet client.
 
Mais je suis chaud quand même. J’ai chiffré assez large donc je peux en profiter pour monter en compétence dessus.

https://www.newyorker.com/culture/c [...] -an-empire oh wow

ça pique

je cherche une liste des erreurs de conception (design mistake) du langage Rust et des choses gênante ou désagréables à l'utilisation du langage.
 
Un point de vue objectif si possible.

 
Vu que le langage est relativement neuf, c'est plutot de choix de design que d'erreurs de design dont on peut parler amha.
Les seules chose désagréables sont amha la relative lenteur du compilateur et la courbe d'apprentissage.

ca resoud tellement de caca qu'on faisait avant. (merci fb pour cette contribution... )

Choses gênantes/désagréable c'est surtout que… c'est pas que la courbe d'apprentissage est pentue (même si elle l'est) c'est qu'il est pas nécessairement facile d'intégrer les limitations que le borrow checker met sur tes possibilités, donc après avoir "appris" le langage le compilo continue à te latter les couilles pendant pas mal de temps. Entre autres que développer tout ce qui est cyclique c'est la merde (genre une liste doublement liée c'est chiant à monter), http://cglab.ca/~abeinges/blah/too [...] EADME.html peut t'intéresser.

Fondamentalement, les trucs les plus désagréables ce sont les choses que les gens attendent mais qui ne sont pas encore là/finies (ou même qui doivent être redéveloppées) genre allocateurs custom, placement new et const generics.

Le plus gros truc que j'ai vu comme erreur de design (et encore ça se débat) c'est l'existence de String::as_mut_vec, qui implique que String est nécessairement un wrapper de Vec, et rend l'implémentation de SSO plus ou moins impossible.

Et il y a des trucs qui sont parfois utiles ou même nécessaires mais vraiment bizarres, genre {x}

edit: sinon, je pense que c'est une question qui pourrait être populaire sur /r/rust.

edit2: et comme as_mut_vec il y a des décisions qui peuvent subjectivement être considérées comme des erreurs, genre le formattage par défaut des flottants: les chiffres non-significants sont remplacés par des 0. Donc si tu crées 12345678912345678973f32 et que tu mets pas une précision explicite ça va pas imprimer 12345679395506094080 (l'approximation stockée) mais 12345679000000000000. Ça a du sens, mais la première fois que tu vois ça c'est surprenant.

https://api-platform.com ?

TIL:

if (auto foo = bar()) {
    // foo existe ici
} else {
    // foo existe aussi ici lolsob
}

 
Roulement, unedemi cuve, et la porte.

Et sinon, pour les gens qui font/parlent du graphql.. Une question comme ça : il n'y a pas un risque d'exposer un peu trop son modèle et de se retrouver coincé par une necessité de compatibilité ascendante?
 

Le système standard c'est qu'à chaque "étage" correspond un resolver, que tu écrits, et qui renvoie des types prédéfinis. C'est fait très expressément pour abstraire du système de stockage qui est en dessous, et même pour agréger plusieurs systèmes de stockage disparates.

Ya pas plus de risque d'exposer son modèle qu'avec un autre style d'API.

Non mais ca j'imagine

Par contre la tentation doit être super forte  pour ceux qui réfléchissent pas de faire une API directement calquée sur le modèle BDD, de la meme manière que les mecs qui font des DTO exactement identiques a leurs entités, parce qu'ils ont la flemme de réfléchir a leur modèle métier et que c'est plus simple de mapper avec dozer.

ça a du faire "un peu" de bruit ça

Bof... Enfin en ne faisait du bruit, quoi...  Mais on l'a utilisé un moment avant de l'amener a réparer
C'était probablement une erreur d'ailleurs.

Much, c'est pour toi :
https://blog.google/topics/ai/ai-principles/

Sûrement mais encore une fois il n'y a pas de différence avec les autres méthodes de créer des APIs, je vois pas en quoi tu craindrais graphql plus que SOAP ou json-rpc ou bien un rpc-over-http ad-hoc.