Reprise du message précédent :

 
Si je devais acheter un laptop aujourd'hui, sans besoin gamer, c'est sans aucun doute ce que je prendrais. En plus j'adore le principe des extensions de batteries et de la possibilité d'avoir un laptop VRAIMENT autonome.

I saw what you did there

 
Touché
 

 
Si j'etais sur la route (genre PC de techicien qui va dépaner des install), je prendrais un T480 : avec la plus grosse extension de batterie, tu dois tenir 15h, ça le fait).
Par contre en usage quotidien, le T480s m'a paru plus sympa (presque aussi léger qu'un Carbon, mais moins cher)

Y'a des alternatives non-cloud à des produits comme Netatmo (je pense au capteur bruit/temp/humidité/co²) ou aux capteurs qui mesurent la pollution intérieure ?

Kwechtieune : imaginons une méthode qui effectue un test de validité d'une donnée. Si la donnée est invalide, la méthode doit elle renvoyer un booléen à false, ou lancer une exception ?
Personnellement, j'ai toujours renvoyé un booléen pour ce genre de méthode, car je pense que les exceptions doivent être réservées dans le cas où la méthode ne peut pas accomplir la tâche demandée, ce qui n'est pas le cas ici.
Mais j'ai du code sous les yeux qui visiblement préfère lancer une exception personnalisée si la donnée est invalide.

Je ramasse dans 2 heures

 
bool, sans hésitation.

ça dépend de comment tu traite le problème, est-ce que tu récupère d'une façon précise pour continuer le traitement autant que possible, est-ce que tu as un message d'erreur précis à donner, ou est-ce que tout termine dans un message générique "une donnée n'a pas le bon format".

Parce qu'avec une exception tu peux avoir une fonction de validation qui fait un traitement complexe avec plusieurs petits points de sortie qui ont chacun leur marqueur qu'on peut récupérer derrière.

après, bool ou exception, on s'en fout un peu quand même.

Bool sans discussion possible.

 
Si je suis en train de tester un input non vérifié et qui a de bonnes chances d'être invalide, je n'utilise pas les exceptions. Je m'en sers vraiment pour l'inattendu et généralement je pense que la validation des données d'entrée n'en fait pas exactement partie.
Si j'ai juste besoin de savoir si la donnée est valide : booléen.
Si j'ai besoin d'avoir un diagnostic plus précis (qui puisse servir à construire un message d'erreur, surtout si la donnée est complexe), je renvoie un objet contenant mon résultat de validation, objet qui peut se composer avec d'autres résultats, pour savoir si j'ai une erreur ou non.

ça m'intéresse aussi, meme si en cloud. C'est assez cool de pouvoir savoir la température chez soi (ou dehors) depuis ailleurs. Mais Netatmo ça commence à accuser son age, le wifi est antédiluvien et fout le merde dans mon réseau.
 

Bordel, la capacité qu'à Étienne Klein à expliquer des trucs complexes c'est vraiment quelque chose

Dépend du langage, regarde ce qui est généralement fait. En Python la tendance serait à renvoyer une exception (ValueError, AssertionError), en Rust ce serait probablement un Result<(), ValidationError>. En C# j’ai l’impression que t’as souvent les deux genre Validate qui raise et TryValidate qui renvoie un bool.  
 
Un booléen c’est ok si les données sont souvent invalides (moins cher que balancer une exception) mais ça veut dire aucun contexte (maintenant ou dans le futur), et aucune garantie que ce soit checké donc une donnée invalide pourrait passer à travers si on fait pas gaffe.

Question con, j'ai un câble éthernet et je veux y brancher à la fois ma box ET un autre appareil, je dois acheter quoi (si possible un truc qui ne nécessite pas une alimentation électrique)

Ouais enfin si c'est pour bosser avec des cons j'avais tout ce qu'il fallait à disposition à l'Université ! Ça va là je suis assez googley pour toi ?

Un switch, et sauf si t'as du PoE t'es marron pour l'alim.

Il y a des splitters, mais ça sert à faire passer 2x100BASET à travers un seul Cat5e (et il est pas dit que t'aies même du 100baseT), faut un splitter de chaque côté de ton cable unique.

C'est bien ce que je craignais, tabernacle.

Je récris tout en Idris.
 
Sérieusement, Either ou Validated monadique pour les raisons invoquées par masklinn plus haut.
 

Tiens sinon vous faites du sharing ad-hoc de repos git? Vous utilisez quoi pour le partage? Genre vous voulez bosser entre deux machines et pas nécessairement passer par un repo central pour bouger du code de l'un à l'autre.

J'ai regardé git daemon mais je connection refused chez moi, apparemment il fonctionne en SSH donc faut impérativement que l'host ait un serveur SSH et que le client ait accès SSH.

git-send-email  

hihi, j'ai toujours pensé que la gestion de version distribuée ça va être compliqué vu la merde que c'est de faire des rendez-vous entre machines.
 
est-ce que y'a de l'espoir avec mDNS, ip broadcast ou ARP ?

Hello,  
 
Question existentielle à la con de mapping ORM.
 
J'ai une table Canal_contact  avec plein de canaux de contacts dedans. Chaque canal a un type (email, téléphone..) et une origine, et appartient à une personne.
 
Parmi ces canaux, pour ceux d'origine CLIENT, je veux pouvoir distinguer un canal préférentiel par type. Et il ne doit y en avoir qu'un!  
 
La contrainte d'unicité du canal préférentiel est assez galère à écrire, du coup (ça passe par un index avec du case .. when, le truc chiant,n mais côté Oracle on s'en sort)
 
Dans le code, on est sensé être en DDD. Donc l'ajout d'un canal se fait via une classe métier qui vérifie les règles métier (dont l'unicité)
 
Par contre, la modélisation de la contrainte d'unicité en Hibernate est super chiante. Et ça marche pas : comme Hibernate fait les insert / updates avant  les delete, la contrainte est violée dès qu'on remplace le canal préféré par un nouveau canal préféré (et dans plein d'autres cas aussi)
 
 
On peut s'en sortir en faisant un flush() de l'EntityManager au bon moment, mais ça ne met pas à l'abri du cas où on chope une entité en DB, qu'on modifie les canaux, et qu'on persiste la personne, sans psser par le service qui gère proprement l'ordre des opérations et le flush (et puis j'aime pas l'idée de me faire chier à faire le boulot d'Hibernate)
 
 
J'ai une autre modélisation qui marche, à base d'une table canal_principal, dans lequel j'ai 4 colonnes : idPersonne, Type, Origine, id_canal (l'origine est là juste pour avoir  une FK vers les canaux de contacts. Là, les contraintes d'unicité sont triviales à écrire (personneId+type est la PK de la table, ça aide)
 
Le code est pas nettement plus complexe, on a juste une nouvelle entité qui est pas visible au niveau du domaine.
 
 
 
Les volumétries en jeu sont assez importantes (~90 millions de personnes, potentiellement qques centaines de millions de canaux de contact, ~150 millions de canaux préférés), donc je me pose la question de mettre en place la nouvelle modélisation, au prix de jointures entre 2 grosses tables, ou garder ma première modélisation et simplement virer  la contrainte côté Oracle
 
Vous suggérez quoi?  

J'en ai aucune idée, là j'essaie juste de partager entre une machine et elle même et j'ai rien de mieux que "connection refused".

dans la table personne, une colonne "canal préférentiel", FK de canal contact

Et voilà, ta contrainte d'unicité est géré

pourquoi ajouter une table de plus ?

 
J4ai pas une cardinalité 1:1 entre personne et canal préférentiel : il y a un canal préférentiel par type.
 
Et l'ajout d'une colonne supplémentaire par type dans la table ruine un peu les efforts qu'on a fait pour rendre le modèle résistant à l'ajout d'un type de canal.

Oui c'est bien la

https://arstechnica.com/tech-policy [...] aker-says/

Ok, je n'avais pas compris le type
Alors table intermédiaire

Le gorafi doit être désespéré

mon pauvre interne. Il vient ici pour faire du big data, du aws, du ML.
 premiere tache: faire un cgi
 
 il est tellement jeune, il savait pas ce que c'etait

L'école va la réalité.
Moche, mais ça lui tannera un peu le cul

Mais vous en faites au moins du big data, aws et ML
 
Parce que ca peut être le second suppo "Ah non mais ici on fait rien de toussa"

"c'est notre SSI qui fait tout ça, nous on fait des specs"

 
En Perl au moins

voila un peu . Enfin ca reste un truc facile très pratique pour les utilisateurs. On passera aux choses sérieuses apres

ah non, on est pas des menteurs non plus. C'est juste que le reste de l'appli utilise deja des cgi donc c'est plus simple.  
Il aura quand meme du ML, il a deja du aws et du big data.  

Python
 ce qui est marrant c'est de devoir expliquer ce qu'est un serveur http et le principe client-serveur. Ils sont doues, ils connaissent pleins de trucs pointus mais il y a des trucs fondamentaux qu'ils ont jamais eu a comprendre.
 
 et ca donne aussi un sacre coup de vieux aussi

Donc ma banque pro aux US a refusé un wire de Plamcorp, et je peux pas transférer d'argent vers mon compte perso. Y'a $8k bloqués sur le compte

paye ton armée mexicaine

Pour info, c'est du Java

Ce sont différentes méthodes, chacune fait une vérif de validité d'une donnée. Si une seule de ces vérifs échoue, alors le batch s'arrête (Spring Batch).

Perso, comme je le disais plus haut, je préfère le booléen qui me parait sémantiquement plus juste qu'une exception, et qui est moins couteux. Le seul inconvénient à cette méthode concerne les tests unitaires. Si j'ai un truc genre

if (isValide1 && isValide2 && isValide3) {
   // continue l'exécution
}

Je dois tester tous les cas possibles ce qui peut vite devenir chiant (mon cher client m'impose une  couverture de code de minimum 80%)

ça me rappelle ici...une bonne 20aine de "managers" à la base pour une centaine de personnes en tout...ça s'est calmé un petit peu depuis mais pas énorme...

(cela dit à 80% on a des postes qui sont censés être des niveaux de "cadre"...)

Ils invoquent quelle raison ?

Ça dépend comment est calculé le taux de couverture  

Pour le transfer sortant, j’étais sur la mauvaise page
(J’étais sur transfer between my accounts at BoA au lieu de transfer to someone else at BoA, peut-être que le vocabulaire n’était pas très approprié pour un compte pro)

Couverture directe avec dépliage des if. Bon courage.

Je savais que les banques US c’était de l’amende, mais c’est quand même impressionnant à voir.