Reprise du message précédent :

Ça change rien à ce que je dis.  
 
Et puis
 
Corsair:
 
https://i.imgur.com/tBCGm1X.png  
 
Air France:
 
https://i.imgur.com/Ey6cevp.png  
 
Excuse moi de ne pas voir de différence flagrante  

Bah excuse-moi mais une compagnie qui vend encore de la business moins bien qu'une premium selon tes mots, ça me semble pas très représentatif.
 
En long-courrier l'offre éco et premium est quand même très standardisée chez les compagnies non low-cost en Europe, Asie et Moyen-Orient (les américaines je connais moins bien mais sur les transcontinentaux il me semble que c'est à peu près pareil).

https://www.youtube.com/watch?v=I9EvHpf8jZg Juan Brown a fait une vidéo.

C'est pas ce que je dis, j'ai dit que la premium de Corsair est kifkif avec la (ancienne) business de Air Caraibes mais uniquement sur les 320, parce que les avions ces avions sont vieux, sur les avions récents AC a une business comme plus haut.

Ma remarque c'est qu'il faut faire gaffe à l'avion quand tu prends une classe autre que Eco parce que la gamme d'équipement peut changer selon le modèle et l'âge de l'avion.

La premium varie énormément entre les compagnies pour la simple raison que c'est un ajout "récent" dans l'offre et là où les contraintes place/intimité imposent un design de facto pour l'éco et la business (rentabilité d'un côté, qualité de service de l'autre), en premium tu auras un coup 6 places par ligne, un autre coup 4.

Faut voir au cas par cas, mais ça m'est arrivé de payer 30 euros de plus pour une place en Premium avec le fast-track/enregistrement+embarquement prioritaire/salon, à ce prix là la question ne se pose pas.

 
Merci , c’était exactement ma question
 

J'ai l'impression de voir l'un de mes anciens boss de startup (sorti de HEC avec un melon comme par permis), qui parce qu'il avait lu 3 blogs sur NodeJS c'était mis en tête que "le dev ça devait quand même pas être bien compliqué, je comprend pas pourquoi nos projets sont si longs" et que "tiens on devrait réécrire notre app Python en Node, on irait plus vite". "Ah et d'ailleurs j'ai codé un peu ces derniers week-end, j'ai fais un petit proto, je pense qu'on peut continuer dessus."

( le CTO co-fondateur était sur le départ, j'étais déjà en préavis aussi, autant dire que ça m'a surtout fait sourire )

Résultat: un an après, l'app NodeJS avait été réécrite 2 fois from scratch, l'app Python était toujours là (forcément, après plusieurs années de dev elle gérait pleins de trucs que son "proto" avait pas pensé), et le nouveau CTO lui a fait comprendre qu'il devrait plus trop l'ouvrir sur la tech.

NB: Ah bin si BenO était toujours sur ce forum, ça lui aurait peut-être rappelé des souvenirs

J'ai vu passer ça ce matin. À la première lecture c'est un peu bête ; mais quand on y réfléchit un peu plus c'est complètement con.

encore une preuve de la supercherie intellectuelle de cette sous merde

ça sent la connaissance superficielle. Peut-être que prendre un ticket et essayer de le résoudre est une manière de contrer ça, mais ça risque de se finir en "c'est trop compliqué, il faut tout ré-écrire en plus simple".
 
Y'a aussi l'effet inverse, où des gens ont conscience de la complexité actuelle du code ne laissent pas quelqu'un comme 0x90 ou moi mettre le premier coup de hache pour couper en 2. Alors qu'on en a la capacité parce qu'on est un peu particuliers.

Le nombre de fois où j'ai entendu ça "non mais votre truc on peut le refaire en 3 semaines"
 
Me souviens il y a encore quelques années, on m'a par exemple dit que Xen Orchestra c'était un simple thème bootstrap et voilà

Je pense qu'il d'un biais un poil différent, les gens sous-estiment la complexiter à fabriquer une UI, ils sont aveugles au détails spécifiques d'une UI.
Du style quand on clique sur "créer une VM" ça peut donner l'impression que ça ne fait que appeller XAPI derrière.

Ou mieux, avec la moitié du produit pêté, et la conclusion de "le bug est fixé je vous laisse finir" (le bug a juste été planqué sous le tapis pour le cas spécifique du ticket)

 
Ya l'UI mais déjà à l'époque il y avait du backup. D'ailleurs rétrospectivement, on a vraiment fait le bon choix avec l'aGPLv3, sinon on serait fait piller moult fois déjà...

"je vous laisse réparer les tests"

Ou bien tu supprimes les tests et "c'était pas des tests intelligents".

2024, l'année où je vais peut-être ajouter des tests unitaires sur mes projets PlamCorps.

"je vous laisse migrer les utilisateurs vers la nouvelle couche logicielle"
 
***rien n'est compatible et n'a été prévu pour pouvoir migrer les datas des utilisateurs***

 
clic droit -> sauvegarder cette VM

H2H0 CA VA HEIN

 
Tignes.
 

 
Envoyée vendredi, je voulais avoir mon directeur au téléphone pour fixer la date de fin de contrat.
 

 
https://newrepublic.com/article/154 [...] revolution
 
Cet article donne froid dans le dos

La reprise, allez une petite question dev :
 
J'ai une appli A (php/mysql) que j'envisage de décliner en appli B, 90% de code commun mais des différences (j'en ai déjà parlé il y a longtemps, imaginez une appli dédiée aux plombiers d'un côté, aux électriciens de l'autre).
Dans l'appli il y a trois tiers : 1:free / 2:payant pas cher / 3:plein pot
Entre A et B les restrictions entre les tiers pourront être identiques ou différentes. (Genre la fonction X sera dispo en A-3 (plombiers plein pot) mais en B ça sera seulement en 2 (électriciens pas cher) car la pertinence de telle ou telle fonction dépend de la profession).
 
Hormis foutre plein de if / case dégueu imbriqués dans tous les sens dans le code (si (plombier + plein pot) ou (élec + pas cher)... ) il y aurait moyen de faire quelque chose de plus propre ?
Des idées ?

Il fait 1°, il y a de grosses bourrasques de vent, des petits flocons qui tombent et... je dois aller courir ce midi

ici un on a une méthode checkAuthorization(feature_code) qui regarde par rapport à la licence, et un fichier de conf des différents code feature
et des
 

les zone de controles sont un peu éparpillées, mais changer la matrice d'autorisation est centralisé, et c'est ce qui est important à mon avis

Tu extrais les bouts en commun dans une librairie / un service séparé? Ç'est accédé que de A et B, à ceux ci de gérer les droits d'accès (et de billing) qui leur sont propres.

Alternativement tu utilises un système type capabilités, les capabilités sont définies par le bout commun mais configurée par les frontends, comme ça tu peux avoir A-3 qui donne la capabilité X, et B-2 qui la donne aussi. Dans ton check ACL, tu regardes juste si la cap est allouée.

masklinn : non, pour l'instant (en cours pour les "électriciens" ) le code est 100% commun hormis des var d'environnement dans l'hôte apache.
Ensuite en fonction d'un nom d'appli (plombier/elec) ça va inclure (par exemple) plombier.css ou elec.css
Mais ensuite le gros du truc c'est plutôt "si plombier tu me fais ça, sinon..."

Il faut qur tu ajoutes un niveau :

Chaque fonctionnalité doit être associée à un "truc" (rôle, resource, whatever en fonction de ton modèle d'autorisations/habilitations), et ensuite tu associes une liste de rôles (ou resources accessibles) à la licence de ton bonhomme.

Ca te permettra beaucoup plus de souplesse (genre : tu accordes tous les rôles pendant 10 jours après le premier login, puis rien, puis à nouveau des trucs en fonction de la licence choisie)

Et dans ton code, tu ne testes plus "si c'est un plombier", mais "si il a le rôle X / si il a acès à la resource X"

 
j'aime bien l'approche de Flo, tu dois gérer toute la combinatoire des fonctions / tiers d'accès, mais de toute façon tu peux pas y échaper, faut bien que ce soit configuré quelque part.
Les roles c'est une abstraction propre, mais faut etre super discipliné sur la liste des roles et son entretien, sinon ce truc grand de façon effroyable et dégueulasse, surtout si t'as des concepts genre grandfathering / latching (si t'as eu accès à la feature un jour et que tu l'as utilisée, tu la perds plus jamais)

comme l'on dit nos amis, ton code ne dois surtout pas être : Si plombier tu fais ça, mais plutôt : si tu as le droit de faire ça alors tu fais ça
 
Et cette gestion de droit tu la fais soit dans des fichiers/objects, et tu init un fichier objet/classe de features en fonction du type d'utilisateur et de son status, ainsi ses droits ressortironts.

Et toi tu rajoutes un 0 au feutre au CA de la boîte et tu finis avec un "Voila, problème résolu, c'était pas si difficile, hein ? Je vous laisse vous démerder pour le reste."

oui j'imagine bien une matrice, pourquoi pas une table mysql avec 1 ligne par fonction/rôle et 1 colonne par produit_tiers. Comme ça en cas d'ajout d'un nouveau rôle on sait qu'on a tous les tiers de tous les produits à remplir et dans le cas de l'ajout d'une produit ou nouveau tiers, on sait qu'on a tous les rôles/fonctions à renseigner.
 
Et en gros on va chercher la colonne qui va bien en fonction du produit utilisé (plombier/élec) et du tiers de l'abonnement (free/pas cher/...)
 
Accorder des rôles, notamment temporaires, ça me parait un peu casse-figure.

Je n'ai aucune honte mais je viens de passer la matinée avec GPT4 pour qu'il m'explique des trucs sur des scripts nodejs, l'interaction avec une base mongodb et qu'on avance ensemble sur la résolution d'un problème avec la création de scripts pour lister, modifier et résoudre les soucis.
Et bien c'est gagné Tous les scripts ont étés niquel seul bémol l'explication sur le pourquoi du comment qui était foireuse.
A sa décharge j'ai mal expliqué la première fois, j'ai corrigé mais il n'a pas vu une info important dans le code (un errorCount qui filtre le bouzin et ne le met pas dans la queue). Sans ça c'était pas possible d'avancer.

 
La notion de rôle dans ce contexte c'est juste de la terminologie.  
Il ne s'agit pas d'accorder des rôles temporaires, mais plutôt de dire :  
 
"J'ai une licence de type EssaiGratuit10j accordée le 1/01/2024" => la d'autorisation répond toujours vrai"
 
 
L'idée c'est bien de soumettre chaque action à une autorisation de réaliser l'action et pas à un type de personne.
 
Le coeur du truc ensuite, c'est la façon dont tu associes chaque utilisateur à une liste d'autorisations. Et pour faire ça il y a plein de modèles, plus ou moins complexes.

2 jours rouge de suite, l'hiver est vraiment là

Et à mon avis, ça ne va pas se limiter à 2 jours

 
Incoming : onousatousmenti, voyez le RC c'est pas vrai c'est pour instaurer une DIKTATURRR. Macron démition.  

Dites les bricoleurs, Est ce qu'il y a une solution pour limiter le bruit des descentes d'eau pluviale/WC qui passent dans l'appart ? Il y a 6 étages au dessus, et si je les coffre je dois le faire de manière démontable

Ce que mon bouquin en dit.

 
Moi pour ne plus générer de bruits d’eau dans mes canalisations, je vais chier chez mes voisins  

Là c’est plus quand les voisins chient le problème