damaki a écrit 389 commentaires

Dans le genre pseudo Lego et rétro, pour 35€ frais de port inclu il y a le NesPI.

--checksum avec rsync

Absolument. Go 1 ne part pas du tout de la recherche en langages mais du vécu des langages existants. Go 1 part du principe que continuer à faire tout ce qu'on fait actuellement en C, c'est douloureux, c'est complexe et qu'on a souvent aucune autre bonne raison que "le compilateur est dispo partout". Un autre principe est que la programmation orientée objet ajoute de la complexité et de l'imprévisibilité. Et pour finir, il y a des outils pour la concurrence de processus, prévus de base, parce que c'est toujours pénible à gérer à la main.

En vrai c'est un peu un mix des deux dans le document. Ce qui n'est pas idiot, puisque trouver les stacks clientes n'est pas toujours évident.

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.