damaki a écrit 385 commentaires

Si vous êtes dans une boîte avec une majorité de développeurs java, ça a totalement du sens. Mais comme tous mes points dans mon message, ça non plus ça n'est pas une contrainte clairement exprimée dans le document.

Bonjour,
J'ai beaucoup de mal à comprendre le but d'une analyse unique. Le terme IoT regroupe une foule d'objets connectés avec des utilisations totalement hétérogènes et parler de plateforme, c'est déjà discriminer suivant un ou plusieurs cas d'utilisation, ce qui reviendrait à faire une analyse par cas d'utilisation et un document sur les plateformes qui correspondent aux besoins.

Je me vois difficilement traiter de la même manière des microcontrôleurs sous Arduino avec une stack ultra-légère faisant juste des appels à un service pour y déverser de la télémétrie et un service actif, par exemple pour piloter la domotique de ma maison, qui aura de toute façon une architecture différente (un nœud de regroupement des relevés des sondes et qui les enverra au serveur et recevra des ordres). A l'opposé de tout ça, on pourrait avoir une cafetière connectée étant juste capable de recevoir l'ordre de faire du café, sans état à publier, ou encore un appareil avec Alexa d'Amazon qui pourra faire bien plus de chose de tout ce qui a été listé ci-avant. Quid de l'industriel et du contrôle d'appareil à distance, entrant aussi dans ces cases ?

Bref, ça serait bien d'expliquer votre besoin spécifique côté client et serveur, et donc le pourquoi de cette analyse, parce qu'en survolant le document, je ne vois pas en quoi ces frameworks font gagner plus de temps que de développer un serveur tout simple et un client simple embarqué ni à quels besoins ils répondent.
De la même manière, le besoin est flou sur les contraintes de sécurité côté client et serveur. Est-ce que le client valide le serveur avec son certificat et vice versa, par exemple ? (bonnes pratiques standard, en somme).
Et pas de mention de mise à jour OTA des clients. Est-ce qu'on considère qu'on remplace les appareils tous les ans sans mise à jour possible ? Est-ce qu'il est acceptable d'aller sur site et de mettre à jour les appareils un par un, régulièrement ?

Désolé, mais je n'ai pas du tout la même expérience. Skype consomme beaucoup de bande passante et dans des scénarios à faible bande passante ou débit instable c'est un désastre. La vidéo devient rapidement incompréhensible et le son distordu. J'ai du monter un serveur Mumble pour bosser avec un collègue qui est en télétravail depuis un DOM pour quand Skype cesse de marcher.
Et aussi dans ma boîte, on a une télé pour la visio dédiée à l'outsourcing nearshore et il est down les 3/4 du temps parce que Skype. Un vrai désastre.

Alors je dis pas que pour une conversation de 20 minutes ça tient pas le coup, mais pour une visio permanente 8 heures par jours ou de la voix permanente, avec une contrainte de fiabilité, c'est à fuir. Skype c'est un jouet, pas un vrai outil.

La réalité est autre : les grosses boîtes comme Apple et Google n'ont absolument aucun intérêt commercial à fournir une messagerie instantanée interopérable. Google a probablement utilisé le XMPP pour racoler les nerds et récupérer du code existant avant de fermer le service quand ils ont atteint la masse critique. Pour facebook c'était pour récupérer une solution sur l'étagère, avant d'imposer leur branding, leur app et leurs pubs partout.
C'est du vendor lock-in à l'état pur, comme ça a quasiment toujours été le cas dans le cas de la messagerie instantanée. Caramail, AIM, ICQ, MSN Messenger, Facebook Messenger, Google Talk, Hangouts, Apple bidule, Whatapp sont les exemples qui me viennent à l'esprit et c'est toujours un peu le même principe qui finit en vendor lock in, quitte à ce que le service crève à cause d'un manque d'utilisateurs.
Les solutions durablement ouvertes voire fédérées (XMPP et ICQ) ont plutôt tendance à atteindre qu'un public technicien, faute de grosse entreprise pour les promouvoir, un peu comme Diaspora face à Facebook ou Mastodon face à Tweeter.

Ça n'est pas plus compliqué que la gestion de numéros de téléphones multiples (fixe, mobile, pro) pour un contact, dispo en standard sur Android et j'imagine aussi sur IOS.

Le CDI tel qu'on le connait va énormément changer. Déjà, changement numéro 1 : le CDI de chantier. C'est un CDI à durée déterminée, qui suit la durée dudit chantier et qui n'implique pas de verser une prime de précarité. C'est un premier changement majeur.
Un extrait du dossier de mediapart

[…] la montée en puissance du CDI de chantier, qui selon le syndicat des avocats « est en réalité un CDD déguisé », mais dépourvu de « la protection légale du CDD ». Les branches auront en effet la possibilité d'activer ce nouveau dispositif, dont nous avons déjà détaillé les risques. Ce type de CDI n’est à durée indéterminée que sur le papier, puisqu’il permet de se séparer d’un salarié dès que le chantier ou le dossier qui lui aura été confié sera achevé.
Et il est d’autant plus intéressant pour l’employeur qu’il lui permet d’économiser la prime de précarité, obligatoirement versée en fin de CDD, qui équivaut à 10 % du montant de tous les salaires versés pendant le contrat. Le SAF donne l’exemple d’un salarié qui perdrait son emploi après un an dans l’entreprise, et dont le salaire brut serait de 2 000 euros brut par mois. Si le salarié quitte un CDD, l’entreprise devra lui verser 2 400 euros brut (environ 1 800 euros net). Mais si son contrat était un CDI de chantier, l’entreprise n’aurait à lui verser que les indemnités légales de licenciement, c’est-à-dire un quart de mois de salaire par année d’ancienneté… soit 500 euros net. Le calcul risque d’être vite fait.

Au sujet de la rupture et du motif sérieux, ça aussi ça saute. L'employeur ne sera désormais plus tenu dans la lettre de licenciement de mentionner les motifs. En effet, il a le droit à l'erreur et c'est au salarié de réclamer la complétude de la lettre, au risque de ne jamais l'obtenir.

Les ordonnances modifient aussi les règles gouvernant la rédaction de la lettre de licenciement, que l’employeur doit adresser à son salarié. Il est fréquent que les prud’hommes condamnent une entreprise pour avoir mal rédigé ou motivé cette lettre. Le gouvernement, toujours dans une logique de « sécurisation », revient largement sur ces règles. Jusqu’à présent, l’employeur devait impérativement préciser pour quels motifs il licenciait, et ne pouvait plus avancer d’autres motifs ensuite. C’est terminé. L’employeur pourra désormais « préciser ou compléter » les griefs mentionnés dans la lettre, après qu’elle a été reçue. Étonnant… « Les griefs de licenciement pourraient relever d’une litanie sans fin, au fur et à mesure que le salarié se défendrait et ferait tomber, comme dans un jeu de dominos, les reproches qui lui sont imputés », s’inquiète le SAF.

Le CDI risque aussi de se faire plus rare maintenant que la limitation de renouvellement des CDD passera à 5 ans

La seule règle qui s’applique désormais est fixée par la jurisprudence européenne : un CDD ne peut pas durer plus de 5 ans. Et dans cette période extrêmement longue, il pourra en théorie être renouvelé aussi souvent que l’employeur le jugera nécessaire, pour peu que les négociations au sein de la branche professionnelle l’autorisent.

Alors oui, on pourra arguer que le marcher va se réguler et que les contrats précaires évoqués ci-avant n'arriveront que dans les franges du travail qui en ont vraiment besoin. Ce n'est pas entièrement faux, en effet, quel développeur logiciel qui butine d'une entreprise à une autre préfèrera un contrat risqué à durée non maîtrisée à un vrai CDI à l'ancienne à durée vraiment indéterminée ? Seulement si le salaire est plus élevé pour compenser le risque, clairement. Mais inversement, quel salarié actuellement au chômage pourra refuser un CDD de 5 ans, qui pourtant l'empêchera d'avoir les garanties suffisantes pour obtenir un appartement en banlieue parisienne ?
Imaginez-vous ce que peuvent devenir les entreprise de services du numérique (ESN, ex SSII) si on ne propose plus aux nouveaux diplômés que des CDDs ?
J'ai l'intuition que la fluidité souhaitée du marché va se finir par une fixation des salariés à des vrais CDIs, et qui ne changeront de job que s'ils trouvent un poste à conditions équivalentes, qui risquent de se réduire en peau de chagrin.

360 000 €, ça fait grosso modo 10 salaires de 3000 net € pendant 1 an. Sachant qu'un salaire de fonctionnaire européen ou que le taux de facturation d'un employé d'un cabinet d'analyse n'est sûrement pas 3000€ mais nettement plus, c'est cher mais logique.
En plus vous pouvez imaginer que vu la conclusion, ils ont du perdre du temps à essayer de redresser les chiffres pour obtenir des résultats plus acceptables, mais échouer misérablement.

Je trouve surtout triste de voir implémentée une solution qui pour faire économiser de la mémoire aux pays anglophones va faire perdre de la mémoire à tous les pays qui n'ont pas leur alphabet entier dans Latin-1. Les compagnies de haute technologie ont beau être majoritairement américaine, je trouve tout ça très regrettable. Alors oui, ça n'est qu'un flag par chaîne de caractères, mais sur des milliards de chaînes de caractères, ça fait beaucoup de gâchis.
Désolé, votre alphabet est un alphabet de seconde zone, revenez plus tard.

Quand je dis en utilisant un VPN ou un proxy, c'est en passant par le port 443, beaucoup plus difficile à différencier du HTTPS. Le VPN ou proxy moyen risque effectivement de se faire repérer immédiatement. Golden frog est le premier qui me vienne à l'esprit, dans ceux payants, mais sinon le proxy socks fourni d'office par une connexion ssh sur le port 443 fait l'affaire.

On appelle ça de la segmentation de marché. Le but est de transformer ce service offert par défaut en service facturé avec un tarif différencié, pour mieux cibler les clients. Et puis on peut le vendre en bundle avec le déblocage des ports réseau à usage professionnel, style exchange, imap, pop, ssh, etc…
La bonne nouvelle, c'est que depuis longtemps c'est contournable avec des proxies, des VPN, en falsifiant l'identité des navigateurs sur le système. J'me souviens avoir déjà contourné ces merdes en 2009 en étant chez SFR. Et quand on échouait, on tombait sur le service surfacturé.

Mes deux premiers critères de choix d'opérateur sont désormais : pas de blocage de ports et pas de restriction des usages modem. Mine de rien, c'est loin d'être présent dans les offres de la majorité des MNO et MVNO.

Oui. S'il n'y a pas de numéro de téléphone, c'est impossible de mettre à jour la carte sim par OTA et il n'y a pas encore à ma connaissance de mode OTA autre que par SMS (même si j'avoue que j'ai pas ingurgité les dernières briques de la 3GPP). En plus c'est hyper facile de désactiver les usages voix et/ou envoi de sms au niveau de la sim ou au niveau du cœur de réseau.

j'ai déplacé le commentaire à un endroit plus pertinent
à effacer

J'aurais plutôt tendance à faire confiance à Kinesis pour la qualité du matos, sa durée de vie et les drivers.

Pas sûr, il y a plein de trucs dans les 144 repos de leur github et malgré l'absence de doc, il y a plusieurs trucs de type serveur mis à disposition.

A effacer, je l'ai déplacé

Ce genre de soucis est supposé être repéré par les tests unitaires et/ou les participants aux revues de code. Honnêtement, ce genre de cas se produit très rarement en java parce qu'il n'y a pas un pan énorme du langage et des libs qui permette de faire des choses stupides dans ce genre, les effacements de types et autres joyeusetés.

Effectivement, un merge git peut donner des incohérences vu que git gère les conflits fichier par fichier. Ça ne veut aucunement dire que l'ensemble est fonctionnel, seuls des tests peuvent le prouver.
Sur le côté cohérence de git, git n'oblige pas à être cohérent sur le repo, car on considère que ce n'est pas son travail. Les commits et les branches, c'est le travail des développeurs et intégrateurs. Git ne force pas de workflow spécial ou de logique, d'où la prolifération des workflows d'utilisation de git. Si le graphe des commits ne ressemble à rien sous git, faut disputer les devs qui n'y prêtent pas attention. Exemple concret : l'équivalent d'un svn update est un git pull --rebase et il faut donc éduquer les devs sur la bonne commande à utiliser pour ne pas pourrir l'historique.

Pour en revenir à pijul, malgré leurs bonnes idées, j'ai du mal à lui trouver des atouts suffisants. C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).

Les raccourcis bash sont par défaut réglés sur des raccourcis façon emacs, d'où la touche Ctrl à tout va. En cas de troubles troubles musculo-squelettiques, autrement dit de douleurs aux doigts ou poignets, passez plutôt aux binding type vi, ça évite de forcer sur l'auriculaire gauche.

set -o vi

L'autre solution classique (que j'utilise) est de remapper votre clavier pour inverser maj lock et control, voire supprimer maj lock. Comment faire ça varie suivant l'OS et le modèle de clavier, mais une horde de gens sur les internets a déjà fait une tonne de tutos là dessus. A noter qu'il y a aussi des gens qui utilisent des pédaliers pour maj et ctrl.

En tous cas, merci pour le guide parce les guides en français ne sont pas légion.

C'est lent des accès à un lecteur hébergé sur disque dur, par exemple lors d'une compilation ou d'une transpilation avec aucune autre activité sur le disque. Même en dédiant un disque à ça exclusivement, c'est lent. J'ai pas fait de bench mais ça a l'air endémique.

J'ai testé sous Windows 10 pro, dans le désordre :
- subsystem linux
- une vm graphique sous virtualbox
- vagrant sous virtualbox
- vagrant sous hyperv
- vmware sous windows

Le pire parce que y'a des trucs qui marchent pas au pif et sont obscurs à débugger :
- subsystem Linux pour Windows

Le meilleur en version graphique :
- vmware, de très loin pour les perfs

Le meilleur équilibre prix/fonctionnalité graphique :
- virtualbox parce qu'hyperv est une purge en mode bureau graphique

Meilleures perfs en console :
- vagrant sous hyperv mais c'est pas pratique parce qu'il faut démarrer la VM avec les droits d'admin

Pour usage pro et perso, au final, j'utilise virtualbox quand j'ai besoin d'applis graphiques et vagrant avec hyperv pour le reste, parce que les perfs déboîtent et parce que tout fonctionne correctement. Le seul souci de vagrant sous Windows c'est qu'il fonctionne pas très bien avec ConEmu, la meilleure console pour Windows.
A noter que virtualbox est incompatible avec hyperv, on ne peut pas lancer les deux en même temps. Mais on peut bricoler des options de boot windows pour lancer l'un ou l'autre.

J'ai passé des entretiens chez Sun Microsystem en 2008, pour une place de junior, sachant que j'avais un master. On m'a demandé de modéliser en problème ultra basique avec un MCD et deux trois questions sur du java. Ça m'a fait tout bizarre avec un master et deux ans d'expérience de refaire un truc qui date de ma première année. Le gars m'a sorti comme justification que les formations de dev étaient désastreuses dans les universités américaines.

Dans ma boîte de stage fin d'étude, on a du se former à la certif java JAVA SE programmer pendant le stage. Officiellement c'était pour passer la certif java la plus basse, officieusement c'était pour séparer le bon grain de l'ivraie et fallait la réussir pour avoir un CDI après le stage. Comme toute certif de base, les questions sont pas très intéressantes et c'est pas en mémorisant la spec du langage et de la JVM qu'on devient bon codeur…
J'me souviens d'une question au sujet de l'unité de code la plus petite qui permet de déclencher la garbage collection d'un objet méthode. C'était écrit que c'était au niveau bloc de code (ensemble de lignes entourées par des accolades). En vrai, c'est la sortie du scope d'une fonction qui marque les objets comme étant éligibles à la garbage collection.

Sinon, dans ma boîte on a eu un drama sur qui voulait se coltinait la rédaction d'un tests technique de recrutement. Les devs trouvaient ça évidemment débile, parce que ça ne prouve rien et qu'on peut en plus le faire faire par quelqu'un autre, mais le manager l'a mal pris. Au final, il a quand même trouvé quelques exercices. On les envoie au candidat le jour avant l'entretien, il a une soirée pour les faire. Y'a des candidats qui laissent tomber le recrutement juste parce que ça les saoule de le faire (on est une PME, donc pas très attractifs).
On lui a remonté que c'était stupide et dissuasif mais le process est toujours en place, même après la démission dudit manager.

C'est un peu comme tous les langages et frameworks, non ? C'est plus facile de trouver des tutos débutant que des réponses à d'obscures question techniques.
Python a pas à ma connaissance assez de défauts ou complexités de design pour mériter un livre Python, the good parts comme ce qu'on pourrait trouver pour Javascript/Ecmascript, C++, C# ou le langage usine à gaz de votre choix. J'ai pas fait de trucs de fous avec, mais j'ai pas de souvenirs de pièges dans le langage, c'était plutôt les libs, le souci.

J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement

Oups, c'est pas clair non plus. Ce que je voulais dire c'est que je ne copie que les fichiers de la sauvegarde courante, pas la structure de la partition btrfs avec les subvolumes des précédentes.

est-ce que ton NAS ne te sert que de support de sauvegarde ? Autrement il te faudra aussi sauvegarder les données qui ne sont que sur ton NAS (c'était la principale difficulté de mon journal).

Non, mais les autres données présentes dessus sont considérées comme sacrifiables. Et en plus elles sont sur des disques différents de ceux dédiés aux sauvegardes.
Je sauvegarde le /etc du NAS, mais je saurais honnêtement le reconstruire, ça prendrait quelques heures.

si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés

Non, mais j'en suis conscient et c'est prévu comme évolution imminente. Le NAS étant un PC de récup moche et vieux de 10 ans (+ d'autres facteurs), ça n'est encore pas une inquiétude majeure.

tu sauvegardes une partition Btrfs sur une partition NTFS, du coup si je comprends bien tu perds tout le bénéfice de la déduplication des données (2 snapshots incrémentaux seront sauvegardés comme 2 ensembles indépendants).

J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement. Je ne sauvegarde pas les snapshots pour des raisons de budget disque, mais ça va sans doute changer sous peu, dès que j'aurais le budget. Tout comme le nombre de disques de sauvegarde offline que je vais augmenter progressivement.
Je considère aussi comme acceptable de perdre un mois de données en cas de désastre combiné "source de données cassée"/"raid 1 du NAS cassé".

tu fais énormément confiance à ton RAID1 si je comprends bien ? Si jamais il y a un problème qui n'est pas détecté/corrigé par ton RAID1, le problème sera recopié sur ton disque externe ?

C'est un gros point faible, en effet. Il manque un système pour valider que le contenu du current du NAS est identique aux sources de données des sauvegardes. Ça résoudrait en partie le problème, même si rien ne garantit que la source n'a pas été corrompue entre temps (déjà subi :( ).
Pour les sauvegardes faites avec du rsync, je pourrais forcer une fois par mois (voire à chaque fois) le mode --checksum. Pour les autres sources de données, c'est du cas par cas.

L'autre point qui manque, c'est régulièrement de faire des tests de scénarios de désastre pour découvrir des faiblesses et documenter les restaurations, ça reste le meilleur moyen.
J'ai récemment écrasé partiellement (involontairement, c'était génial) le début d'un des disques du raid et ça a été très formateur.

Tous les process de sauvegarde du monde ne valent rien tant qu'on a pas validé rigoureusement que toutes les pièces du mécanisme fonctionnent avec des tests.

Comme tout désastre possible, il faut analyser la probabilité que ça se produise, et l'impact si ça se produit. Dans mon cas, c'est hautement improbable (je ne détaillerai pas pourquoi ici) qu'on soit cambriolés et qu'on vole un PC moche vieux de 10 ans/NAS
L'analyse de l'impact, je ne détaillerai pas non plus ici, mais c'est fait aussi.

Malgré tout, oui, chiffrer la sauvegarde locale online est en cours de réflexion malgré tout. J'ai surtout mis la priorité à court terme sur le chiffrement des PC portables, les mobiles, les sauvegardes offline hors site, les clés USB et puis les rares données sur mon nextcloud.

J'améliore graduellement la sécurité de mes données ; ça prend du temps.

Ok, merci !