Même chez les particuliers d'ailleurs : sysadmin de particulier est un métier d'avenir !
Y'aurait bien que chez les particulier et TPE que sysadmin est un métier d'avenir.
Partout ailleurs on cherche à les tuer remplacer depuis un bon moment. Les ronchons caractériels asociaux mais surtout le coût d'exploitation qui scale linéairement avec la taille, ou nombre, du service ça a fait son temps.
Non, je veux juste déployer un max de trucs que j'aime bien (ou que je crée), dépenser le moins d'argent, me casser le moins la tête
Pour 55€ / an d’électricité tu te paies un hébergement correct. Ce qui te permet d'arrêter les "bidouilles idiotes" et donc de re-gagner ~600h de ta vie par an. Ce qui te permet de te raser, de réaliser que le pragmatisme paie, ce qui te permet de trouver un travail qui paie une blinde et donc enfin de t'héberger correctement et de faire plein d'autres trucs puisque maintenant tu as du temps et de l'argent.
La plupart de ce que tu dis semble se raccrocher à l'argent. Ce n'est pas en passant des heures à bidouiller de l'auto-hebergement que tu résous ce problème.
Tu maîtrises le end-point donc si tu veux tu peux.
Je n'ai pas regardé en détail pour whatapps mais si tu chiffres, tu deviens le seul à pouvoir fournir des chiffres de type volume de conso, qui appelle qui etc.
Je ne te dis pas que c'est le/un critère motivant, mais que c'est au minimum un effet de bord intéressant pour le business.
Tu prends facebook instant articles + HTTPS + pinning et tu deviens diffuseur de contenu et régie pub en empêchant tout mesureur tier. Joie. Tu retrouves un peu le même alignement d'intérêt sur le renforcement de la sécurité des os mobiles. Sûrement pas un raison déclenchante mais on va pas cracher dessus non plus.
Tu protèges tes utilisateurs. C'est bon pour eux et pour ton image de marque
Tu deviens de fait le seul capable d'exploiter les données de tes utilisateurs
C'est pas flagrant pour WhatApps, mais le point 2 est très intéressant dans beaucoup de domaines ou tu court-circuite tous les acteurs tiers qui pourraient avoir intérêt à mesurer ou exploiter ces données. C'est un peu ce qu'il est en train de se passer sur le web et les applis ou le combo https & certificate pinning met au tapis la plupart des acteurs de mesure. Tu deviens le seul a pouvoir fournir les données ce qui est assez intéressant.
Bref l’intérêt des utilisateurs rejoins celui du fournisseur de service et les gens qui se trouvaient au milieu meurent ou génèrent du CA supplémentaire à partir de données que l'on maitrise :)
Après libre a chacun de définir ce qui convient à son besoin (d'un gtld internationalisé à un "sous domaine" offert gracieusement par un petit suffixe publique). Comme dit dans le commentaire précédant, techniquement tout est un domaine c'est juste une question de convention
Un peu de respect, d'empathie et de soft skills ne fait jamais de mal… surtout si on cherche a faire passer un message plutôt que simplement s'écouter parler avec satisfaction.
Seulement si tu fais le con… si tu ecoutes ton comptable et que tu n'essayes pas de tricher, un controle fiscal passe comme une lettre a la poste.
Et quand bien même. Il suffit de prévoir une marge de sécurité qui est de toute façon requise.
Oui tu feras des erreurs (ou ton comptable, ou un organisme quelconque). Oui ça te coutera genre 5-20% de cotisation en plus auprès d'un organisme sur un trimestre ou une année. Ça s'arrête là, le monde continue de tourner et on ne t'as pas fait payer 10x ton CA en pénalité qui va impliquer que tu es a la rue…
À choisir, il vaut mieux faire des erreurs sur des petits CA quand tu débutes que des gros. En plus pour les petits montant et de bonne fois les pénalités passent souvent à la trappe (typiquement avec les impôts).
Après si tu mélanges CA et bénéfice oui il vaut mieux confier ça a quelqu'un d'autre ou te former illico presto.
Cela s'appelle un Expert Comptable, il va te fournir les bons chiffres à partir des éléments que tu vas lui donner. C'est son travail. Il effectue aussi un travail de vérification, et de conseils.
Prends un comptable, c'est pas si cher, surtout en province.
Bon conseil par défaut.
Mais si tu n'es pas complétement à l'ouest avec les chiffres et l'organisation c'est généralement pas très compliqué non plus. On parle d'AE là quand même ! L'adhésion à une AGA peut être un bon compromis pour avoir des formations à pas cher et des gens pour te confirmer que tu fais pas de conneries mais sans vrai conseil.
Après c'est comme tout. Un compromis entre ce qu'il vaut mieux que tu fasses (car tu sais faire ou que ça coute rien sauf du temps que tu as de toute façon), ce qu'il vaut mieux déléguer (car tu sais pas faire ou que tu peux facturer ton temps plus cher que ça te coûte) et la capacité à trouver quelqu'un de compétent et en qui tu as confiance (si c'est pour avoir un charlot qui te pompe quelques K€, comme souvent…)
Il me semble que c'est équivalent au Option/Optional que l'on trouve un peu partout.
Non. Option/Optional peut aussi être vu comme une monade mais son but est de représenter la présence ou l'absence de quelque chose. Pas quelque chose ou une erreur. Dans ce cas ça serait plutôt Either.
Si tu veux une très bonne introduction aux principes sans la tartine de pedantrie fonctionnelle (quoi tu sais même pas ce qu'est un groupe abélien ?!?) tu as "Introduction to railway oriented programming". Tu n'as besoin d'aucune connaissance fonctionnelle et c'est très pratique et applicable dans plein de langages (même si les langages fonctionnels sont très adaptés à ça). Tu as une version article et une version conférence.
Bin heu en fait si quand même… C'est pas par ce que y'a un appel de méthode qui masque le caca que le caca existe pas :)
En fait les vrais questions sont:
Est-ce que quelqu'un a déjà résolu ce problème qui n'est pas mon cœur de métier de matière satisfaisante pour mon besoin ? Si oui je prends et je passe à autre chose. (Attention à ne pas croire que tout ce qui est dispo sur le web fait l'affaire et le fait correctement, syndrome dit de stackoverflow ou de npm)
Sinon, je vais lire la RFC pour trouver la grammaire du truc et possiblement les validations à ajouter au dessus de la grammaire. Je lis aussi la partie où on m'explique la façon la plus facile de valider la grammaire (beaucoup de RFC contiennent les regex correspondante à la grammaire BNF) et dans ce cas j'applique bêtement. Autrement je buche la grammaire pour voir comment on implémente au mieux la grammaire. Selon les cas des regexp, un bête parser basé sur une machine à état fait a la mano, ou un flex/bison/antlr autre seront plus adaptés.
En fait ce qui est compliqué dans la vie c'est que y'a rarement une réponse binaire qui découle d'un raisonnement simple et correct ! Ça semble causer beaucoup de tourment aux informaticiens :)
celle qui semble insinuer qu'un autodidacte ne saurait fournir du code de qualité. Et je ne vais pas m'embarquer dans ce débat.
Non. J'ai dit que autodidacte et travailler seul sont un sérieux handicap à la progression. Pas que c'est impossible.
Tous les deux pour la même raison. Il n'y a personne qui te pousse de savoir extérieur, qui confronte ses opinions aux tiennes, qui te force à t’expliquer, articuler tes pensées, à faire des compromis et donc faire la même chose de différentes façons etc.
Travailler avec des gens, et encore plus avec des gens extrêmement compétents et d'opinions diverses, est un accélérateur incroyable de connaissance et maturité.
Après tu trouveras toujours des gens excellent venant de tout horizon.
Je sais que c'est sacré et que cela ne ce fait pas d'en dire du mal
Absolument pas. Dire des choses dogmatiques et idiotes est plus gênant par contre.
Les regexps sont parfaitement adaptées d'un point de vue fonctionnel et non-fonctionnel à une grande classe de problèmes. Ne pas les utiliser dans ce cas est parfaitement idiot.
Je suis parfaitement capable de me coder n'importe quelle machine a état / lexer / parser pour analyser du texte lorsque c'est nécessaire. Maintenant est ce qu'une regexp est plus adaptée lorsqu'elle fait le même job ? Oui. Je suis juste en train d'écrire une spécialisation de la conversion d'un langage régulier vers un DFA/NFA.
Avec l'inverse ils existent aussi beaucoup de situations où les regexp sont inadaptées, non souhaitables, overkill, piégeuses etc.
En fait je faisais allusion au fait que c'est l'un des trucs les plus compliqués qui soit quand on code. Et que j'ai vu trop de code ou visiblement ce travail saoulait le dev et était bâclé.
Pour moi un code très très moyen, c'est un code qui juste marche et que l'on ose plus toucher car ça ferai boom. Je pense pas que ce soit mon cas ici.
Si je pouvais te conseiller de retirer un seul truc de ce que je dis, c'est que tu émet un avis sur le code d’autrui avec un œil extérieur mais juge ton propre travail.
Que tu sois satisfait de ton travail très bien, que tu t'y retrouves très bien, que ca réponde à ton besoin aussi. Mais ça ne juge en rien que tu fais un bon boulot d'archi, d'écrire du code lisible ou autre qui est le sujet du journal. Ça prouve juste que tu te comprends toi même. Et plus on travail tout seul et plus on est auto-didacte, plus on risque s'enfermer dans "son style" qui devient une partie de sa personnalité. Parfaitement limpide pour soit mais uniquement pour soit.
Les vrais avis viennent toujours d'autrui. Personne n'en a rien a faire que je pense avoir écrit le meilleur code du monde. Si mes deux code reviewer me disent qu'ils ne comprennent pas quelque chose, j'ai forcément tord. Ils peuvent avoir tord aussi, mais même dans ce cas j'ai tord: ils n'ont pas réussi a me comprendre ou n'ont pas confiance dans le fait qu'ils voudront maintenir ce code. S'en suivent les discussions intéressante qui permettent à chacun de progresser.
Comme la plupart des outils, il y a des cas ou c'est adapté et d'autres non.
En l'occurrence les regex peuvent effectivement être extrêmement piegieuses d'un point de vue performance. J'ai déjà vu des regex en ** mettre plusieurs minutes à répondre en matchant une url. La réponse est de comprendre comment marchent les regex NFA vs DFA, quand comment fonctionne le backtracking pour décider de quand et comment les d'utiliser. Dire simplement c'est pas bien est juste idiot. Tout est potentiellement trop lent et piégeur pour quelque chose.
Mais ça c'était juste un point précis qui met la puce à l'oreille. J'ai été rapidement voir le code (Log2 et MyADM) et s'est malheureusement très très très moyen.
le code semble peut-être très lisible et bien nommé à son auteur. Il y bien pire mais c'est pas la joie non plus. Les noms sont longs mais c'est pas pour ça qu'ils sont bons
Le design ressemble aux débutants java du début des années 2000. Du static partout fortement couplé, du synchronized partout etc.
La gestion d'erreur est pourrie du type j'attrape une exception dans un catch qui log et je continue comme si de rien était alors que la db vient de m'envoyer chier.
etc.
Bref un discours entoushiaste et plaisant n'est pas forcément suivi de faits. C'est exactement pour ça que demander aux gens de parler de leurs projets en interview ne marche pas. Tu peux être impressionné pendant 30mn avec ce genre de discours avant de découvrir qu'en fait le mec optimise du trading haute fréquence pour avoir un jitter max < ms avec des printf et un timer qui a une résolution inférieur à l'objectif… La tu backtrack sur tout ce qu'il a dit et tout s'ecroule.
On peut voir l'article comme intéressant ou pas selon comment on le prend. Il contient plein de choses avec lesquelles on ne peut pas être en désaccord (ie. "il est important de bien nommer et moi je nomme bien").
Maintenant je passe mon temps à rencontrer des gens avec le même discours qui pondent des horreurs sans nom. Tout le monde est persuadé de bien faire. Tu utilises d'ailleurs l'expression "un bon développeur". Les développeurs c'est comme les conducteurs, ça se divise entre les bons et les mauvais. Les bons développeurs étant ceux qui font comme moi (enfin comme le moi de maintenant pas le moi d'il y a quelques mois).
Ce biais est encore renforcé pour les gens qui reçoivent peu de feedback, comme les auto-didactes, et qui s'enferment petit à petit dans leur façon de faire (idée développées par Kevlin Henney dans Individuals and Interactions over Processes and Tools.
Je serais donc très intéressé de voir à quoi correspond une base de code écrite par quelqu'un comme toi: amateur, visiblement passionné, qui dit pas mal de choses censées, mais souvent suffisamment vague pour qu'on ne puisse être en désaccord de toute façon, et qui en même temps laissent quelques indices sur le fait que tu pourrais t'être bâti ton propre monde (les tests me servent à rien, j'ai eu un problème de perf avec les regexp que je n'explique pas mais j'en généralise que "les regex c'est mal", "fabriquer ses propres générics" etc.).
Si j'ai un peu de temps j'irai jeter un œil à ton dépôt. Je n'ai aucune idée d’à quoi m'attendre entre le meilleur ou le pire.
La réalité immuable du business c'est qu'il est très difficile de savoir quels produits marcheront et la plupart des produits sont des échecs commerciaux.
Lancer une idée à moindre coût, quitte a faire des sacrifices sur une vision purement technique / ingénierie n'est donc pas forcément complétement stupide. On balance tout si jamais ça ne prend pas, et on itère / améliore / paie la dette sinon.
C'est risqué si on ne maitrise rien du tout et tout est un gros tas boue. Mais vu que l'immense majorité des produits sont des échecs ça peut aussi de minimiser le cout de tout ce qui foire.
Architecturalement, on a donc tout intérêt a mettre des jolies barrières entre ce qui fait actuellement parti de son "core domain" et tout ce qui gravite autour. Les processus et niveau de qualité attendu n'étant très certainement pas du tout les mêmes.
Comprendre la réalité de son business est donc primordiale pour chercher des solutions en adéquation avec les besoins.
On aimerait tous utiliser le dernier truc à la mode…
Heu non.
Vouloir "utiliser le dernier truc à la mode" rappelle beaucoup trop l'incapacité de notre industrie à apprendre quoi que ce soit.
Chercher à résoudre des problèmes de manière simple et fiable devrait finir par mener à chercher à écrire du code ennuyeux (lire sans surprise) avec des technologies ennuyeuses (lire maitrisées).
On peut parfaitement appliquer un processus d'ingénierie classique en informatique, d'ailleurs certains domaines le font.
Mais en dehors de l'inculture crasse du secteur IT que tu décris à raison, la réalité reste qu'effectivement la majorité des produits ne sont jamais défini et ne le seront jamais. Pour de bonnes, ex: "throw again the wall, see if it stick", et beaucoup de mauvaises raisons.
Si un jour ça a été défini et que tu as fait le truc "correctement" au début, de toute façon la vision figée d'un produit ne tiendra pas longtemps. Pour tout ce qui est non life-critical, tout change constamment de manière organique. Les specs & fonctionnalités changent plus vite qu'il ne faut de temps pour simplement les écrire. Le TTM et les fonctionnalités sont un plus grand levier que la correction.
Bref, oui la majorité de l'IT est du grand n'importe quoi. Maintenant croire que ton modèle marche partout c'est aussi n'importe quoi. Il existe une grande variété d'approches pour limiter le désastre inhérent à un monde qui change constamment, on est juste assez mauvais dans toutes.
Posté par ckyl .
En réponse au journal Google Stop.
Évalué à 2.
Je n'ai AUCUNE publicité en rapport avec mes recherches.
Si tu as coché la case de ne pas te proposer de pubs personnalisées c'est assez normal ;)
En fouillant dans les options des différents services y'a pleins d'option du genre qui permettent de désactiver les historiques, l'envoi d'informations vers les serveurs ou les recos personnalisées. Bon bien sur faut pas espérer avoir goolge now ou autres en décochant tout.
Dans les secteurs ou les employeurs se sont regroupés (genre 3) et en position de force (entente plus ou moins tacite et pas de problème de mtaain d'œuvre). Tu as des gens qui ont le droit entre le smic et le smic et des contrats à plein temps ou partiels. C'est pas génial mais ça permet de vivre.
Si tu passes ces gens là en indep. Ils vont se retrouver payé à la minute pour la même compensation horaire. Je fais pas de CA tu vas en salle de pause. Tu reviendras dans la minute ou j'ai besoin de toi. Bref de vrais précaires, corvéables, remplacables à volonté (non leur rémunération ne permettra jamais d'assurer un risque maladie ou autre). Similaire à la magie des contrats 0h en Angleterre.
Alors oui on peut dire qu'ils suffit qu'ils aillent faire autre chose ou l'herbe est plus verte. Mais je me permet quand même de pouvoir douter de l'impact global de ce genre de changements. Surtout sur les 'faibles'
Signé un indep qui profite très largement d'un marché ou il est en position de force, qui peut effectivement faire marcher la concurrence, gérer ses risques et faire autre chose au cas où.
Te faire prendre XX% pour un service pourri (facturation + commercial de merde) mais que tu ne peux pas éviter par ce que les clients ne dealent qu'avec une SSII j'appelle pas ça intéressant mais du racket :)
Tu prélèves ta dime sur la durée totale d'un contrat pour un acte ponctuel. Calcule le prix que facture un cabinet de recrutement (ils offrent pas les mêmes presta hein et surtout pas à toi). Calcule combien rapporte ~XX% sur un CA d'indep et voit l'arnaque.
Note: XX semble être vers 20 mais jamais essayé perso.
Bref, stop à la peur "indé = précaire", c'est juste être responsable (savoir gérer un budget).
La seule limite que j'appliquerai c'est qu'on a tendance à voir le monde en extrapolant notre situation personnelle.
Pour notre marché effectivement tu as parfaitement raison. La concurrence existe, les prix sont hauts et la demande forte.
Par contre partir de ce constat local pour dire que c'est une bonne solution pour la société dans son ensemble, je suis plus circonspect. Basculer globalement vers un monde d'indépendant, ça veut dire que tous ceux qui ne sont pas en position de force ou dans un marché équilibré se font rincer et deviennent corvéables (ce qui n'est pas le cas de l'informatique ou c'est plus la ruée vers l'or).
Heu… Les clients rencontrent et choisissent le consultant. Il est egalement possible de faire passer des tests techniques.
Évidement. (Le possible me choque par contre :))
Je parle de la qualité de ce qu'on te propose en CV, et à l'entretient.
Ce qui détermine ce que tu peux signer et le temps que tu y passes (pour un service que tu as décider de déléguer hein).
Bref, comme pour un entretien d'embauche classique.
Oui et non. Quand je recrute pour ma boite par ma boite. Je peux maitriser le canal d'alimentation des gens qui viennent en entretient. Je peux:
décrire précisément le poste, la boîte etc.
où je veux (aller taper dans les milieux compétent du coin type user group etc.)
annoncer des fourchettes de prix
faire travailler les compétences internes pour récupérer leur réseau (une prime de cooptation à quelques milliers d'euros coute beaucoup moins cher qu'un recruteur)
travailler ma vitrine pour les gens compétents viennent à moi
Quand c'est une SSII qui m'alimente:
La description de la boite et du poste a été donnée par un mec, qui la donnée a mec, qui l'a réécrit à sa sauce et qui a masqué toutes les informations qui font qu'un mec compétent (par ce qu'il est en situation de choix) pourrait se sentir intéressé. Tu as donc peu de chances que le bon type tape à la porte de la SSII.
Les SSII sont majoritairement incapables d'évaluer la compétence des gens et leur adéquation avec le poste. La plupart font confiance aveuglément pour les nouveaux recrutements. Aucun tests ni utilisation des compétences internes pour faire le boulot de filtrage / aiguillage). Entendre "J'ai un super candidat avec un profil parfait pour vous, je lui ai pas encore parlé mais dès que c'est fait je vous l'envoie" ne m'étonne même plus. Quand il y a des filtres, ils sont généralement très mauvais. Pour les gens en inter-contrat ils coutent quelques centaines d'euros par jour. ça vaut bien le cout de les présenter au cas ou ça passerait. Au pire ça aura faire prendre quelques heures au client, et les clients ils s’énervent pas souvent pour ça…
Je n'ai donc plus aucun levier pour faire en sorte de maximiser le signal dans ce qui arrive en entretien. Du coup, statistiquement les gens intéressants (ie. "Trouver le meilleur") sont moins fréquent dans ce qui m'arrive que dans la population totale et c'est beaucoup plus difficile d'arriver à l'objectif que tu énonces.
Maintenant le problème se complexifie encore quand tu prends en compte que tu es maqué avec 1/2/3 boites et que tu as des clauses de "remplacement". En pratique le mec bon il se tire dans 12 à 24 mois. Statistiquement c'est quoi les chances que la même SSII ait un mec aussi compétent dispo à ce moment là ou quelle soit capable d'en recruter un deuxième ?
mais de là à dire qu'il s'est fait "refourgue" quelqu'un… À vrai dire c'est assez faux, il sait très bien avec qui il signe.
Tu as raison.
Je te donne l'avis d'un mec qui a fait passer des entretiens pour ses équipes et qui n'est intéressé qu'à avoir des gens compétents pour le job.
SSII, ça veut dire de devoir accepter de baisser ses exigences ou de ne pas signer. Et de savoir que les mecs vont se casser quoi qu'il arrive.
Et accepter de pas avoir tous les mois un salaire. Faut avoir envie d'être précaire.
C'est effectivement simplement un calcul.
Question, combien de temps tu tiens en inter-contrat sans avoir à faire un truc qui va te faire démissionner de toute façon ?
Après c'est sur, après quelques années de consulting, tu as suffisamment de réseau pour tourner tout seul, mais faut quand même s'accrocher.
Sans passer dans le consulting pur et dur qui est un métier assez différent de ce que font la plupart des gens. On peut réfléchir à la plus value réelle d'une SSII pour soit. En quoi je profite de:
La partie commerciale qu'elle facture
La partie overhead (compta, management, actionnaires) qu'elle facture
La partie sécuritée qu'elle facture (inter-contrat payé)
Si tu n'en profites pas, ou que tu facturerais ces mêmes postes moins cher, alors le perdant c'est toi.
Après ça veut aussi de continuer à bosser pour les mêmes boites.
Si on veut du salarié, viser du côté des boites qui voient encore leurs compétences humaines comme importantes est souvent un bon choix pour faire des choses intéressantes dans de bonnes conditions avec des gens intéressants. Si une boite tourne à coup de presta tu sais à quoi t'attendre (ie. c'est clairement pour avoir les "meilleurs mecs" à chaque poste)
[^] # Re: Debugger
Posté par ckyl . En réponse au journal L'informatique de papa. Évalué à 1.
Y'aurait bien que chez les particulier et TPE que sysadmin est un métier d'avenir.
Partout ailleurs on cherche à les
tuerremplacer depuis un bon moment. Les ronchons caractériels asociaux mais surtout le coût d'exploitation qui scale linéairement avec la taille, ou nombre, du service ça a fait son temps.https://landing.google.com/sre/book.html
[^] # Re: Nom de domaine .netlib.re
Posté par ckyl . En réponse au journal Hébergement mutualisé pas cher. Évalué à 4.
Pour 55€ / an d’électricité tu te paies un hébergement correct. Ce qui te permet d'arrêter les "bidouilles idiotes" et donc de re-gagner ~600h de ta vie par an. Ce qui te permet de te raser, de réaliser que le pragmatisme paie, ce qui te permet de trouver un travail qui paie une blinde et donc enfin de t'héberger correctement et de faire plein d'autres trucs puisque maintenant tu as du temps et de l'argent.
La plupart de ce que tu dis semble se raccrocher à l'argent. Ce n'est pas en passant des heures à bidouiller de l'auto-hebergement que tu résous ce problème.
Fail
Fail
[^] # Re: Intérêt
Posté par ckyl . En réponse au journal WhatsApp active le chiffrement de bout en bout. Évalué à 6.
Tu maîtrises le end-point donc si tu veux tu peux.
Je n'ai pas regardé en détail pour whatapps mais si tu chiffres, tu deviens le seul à pouvoir fournir des chiffres de type volume de conso, qui appelle qui etc.
Je ne te dis pas que c'est le/un critère motivant, mais que c'est au minimum un effet de bord intéressant pour le business.
Tu prends facebook instant articles + HTTPS + pinning et tu deviens diffuseur de contenu et régie pub en empêchant tout mesureur tier. Joie. Tu retrouves un peu le même alignement d'intérêt sur le renforcement de la sécurité des os mobiles. Sûrement pas un raison déclenchante mais on va pas cracher dessus non plus.
[^] # Re: Intérêt
Posté par ckyl . En réponse au journal WhatsApp active le chiffrement de bout en bout. Évalué à 3.
Absolument, tu fais d'une pierre deux coups:
C'est pas flagrant pour WhatApps, mais le point 2 est très intéressant dans beaucoup de domaines ou tu court-circuite tous les acteurs tiers qui pourraient avoir intérêt à mesurer ou exploiter ces données. C'est un peu ce qu'il est en train de se passer sur le web et les applis ou le combo https & certificate pinning met au tapis la plupart des acteurs de mesure. Tu deviens le seul a pouvoir fournir les données ce qui est assez intéressant.
Bref l’intérêt des utilisateurs rejoins celui du fournisseur de service et les gens qui se trouvaient au milieu meurent ou génèrent du CA supplémentaire à partir de données que l'on maitrise :)
[^] # Re: Nom de domaine .netlib.re
Posté par ckyl . En réponse au journal Hébergement mutualisé pas cher. Évalué à 3. Dernière modification le 05 avril 2016 à 21:14.
Le concept que tu cherches peut se nommer public suffix
Une liste est maintenu par Mozilla:
- https://publicsuffix.org/
- https://publicsuffix.org/learn/
Après libre a chacun de définir ce qui convient à son besoin (d'un gtld internationalisé à un "sous domaine" offert gracieusement par un petit suffixe publique). Comme dit dans le commentaire précédant, techniquement tout est un domaine c'est juste une question de convention
[^] # Re: Karma négatif et comptes multiples
Posté par ckyl . En réponse au journal Tableur de calcul pour auto-entrepreneur 2016. Évalué à 7. Dernière modification le 30 mars 2016 à 17:57.
Pour toute personne doutant de la chose et trouvant normal ou acceptable la façon de s'exprimer de Zenitram, une lecture de How to Win Friends & Influence People est hautement recommandée. Ensuite What Did You Say? The Art of Giving and Receiving Feedback peut aussi être intéressant.
Un peu de respect, d'empathie et de soft skills ne fait jamais de mal… surtout si on cherche a faire passer un message plutôt que simplement s'écouter parler avec satisfaction.
[^] # Re: Mauvais tableau
Posté par ckyl . En réponse au journal Tableur de calcul pour auto-entrepreneur 2016. Évalué à 3.
Et quand bien même. Il suffit de prévoir une marge de sécurité qui est de toute façon requise.
Oui tu feras des erreurs (ou ton comptable, ou un organisme quelconque). Oui ça te coutera genre 5-20% de cotisation en plus auprès d'un organisme sur un trimestre ou une année. Ça s'arrête là, le monde continue de tourner et on ne t'as pas fait payer 10x ton CA en pénalité qui va impliquer que tu es a la rue…
À choisir, il vaut mieux faire des erreurs sur des petits CA quand tu débutes que des gros. En plus pour les petits montant et de bonne fois les pénalités passent souvent à la trappe (typiquement avec les impôts).
Après si tu mélanges CA et bénéfice oui il vaut mieux confier ça a quelqu'un d'autre ou te former illico presto.
[^] # Re: Mauvais tableau
Posté par ckyl . En réponse au journal Tableur de calcul pour auto-entrepreneur 2016. Évalué à 8.
Bon conseil par défaut.
Mais si tu n'es pas complétement à l'ouest avec les chiffres et l'organisation c'est généralement pas très compliqué non plus. On parle d'AE là quand même ! L'adhésion à une AGA peut être un bon compromis pour avoir des formations à pas cher et des gens pour te confirmer que tu fais pas de conneries mais sans vrai conseil.
Après c'est comme tout. Un compromis entre ce qu'il vaut mieux que tu fasses (car tu sais faire ou que ça coute rien sauf du temps que tu as de toute façon), ce qu'il vaut mieux déléguer (car tu sais pas faire ou que tu peux facturer ton temps plus cher que ça te coûte) et la capacité à trouver quelqu'un de compétent et en qui tu as confiance (si c'est pour avoir un charlot qui te pompe quelques K€, comme souvent…)
[^] # Re: ouai
Posté par ckyl . En réponse au journal Données vs Code. Évalué à 3.
Non. Option/Optional peut aussi être vu comme une monade mais son but est de représenter la présence ou l'absence de quelque chose. Pas quelque chose ou une erreur. Dans ce cas ça serait plutôt Either.
Si tu veux une très bonne introduction aux principes sans la tartine de pedantrie fonctionnelle (quoi tu sais même pas ce qu'est un groupe abélien ?!?) tu as "Introduction to railway oriented programming". Tu n'as besoin d'aucune connaissance fonctionnelle et c'est très pratique et applicable dans plein de langages (même si les langages fonctionnels sont très adaptés à ça). Tu as une version article et une version conférence.
http://fsharpforfunandprofit.com/rop/
http://fsharpforfunandprofit.com/posts/recipe-part2/
Après si tu veux aller plus loin tu peux regarder Either en Scala ou Haskell et creuser les concepts.
Et tu peux regarder aussi quelque chose comme https://github.com/kittinunf/Result qui implémente le truc dans un langage OO (Kotlin)
[^] # Re: ouai
Posté par ckyl . En réponse au journal Données vs Code. Évalué à 3.
L'article n'est plus sur son blog mais est toujours dispo sur gamasutra: http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php
Si ma mémoire ne me trahie pas c'est bien le même.
[^] # Re: Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 3. Dernière modification le 25 mars 2016 à 13:25.
https://github.com/apache/commons-validator/blob/trunk/src/main/java/org/apache/commons/validator/routines/EmailValidator.java#L40
Bin heu en fait si quand même… C'est pas par ce que y'a un appel de méthode qui masque le caca que le caca existe pas :)
En fait les vrais questions sont:
En fait ce qui est compliqué dans la vie c'est que y'a rarement une réponse binaire qui découle d'un raisonnement simple et correct ! Ça semble causer beaucoup de tourment aux informaticiens :)
[^] # Re: Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 3.
Non. J'ai dit que autodidacte et travailler seul sont un sérieux handicap à la progression. Pas que c'est impossible.
Tous les deux pour la même raison. Il n'y a personne qui te pousse de savoir extérieur, qui confronte ses opinions aux tiennes, qui te force à t’expliquer, articuler tes pensées, à faire des compromis et donc faire la même chose de différentes façons etc.
Travailler avec des gens, et encore plus avec des gens extrêmement compétents et d'opinions diverses, est un accélérateur incroyable de connaissance et maturité.
Après tu trouveras toujours des gens excellent venant de tout horizon.
[^] # Re: Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 4.
Absolument pas. Dire des choses dogmatiques et idiotes est plus gênant par contre.
Les regexps sont parfaitement adaptées d'un point de vue fonctionnel et non-fonctionnel à une grande classe de problèmes. Ne pas les utiliser dans ce cas est parfaitement idiot.
Je suis parfaitement capable de me coder n'importe quelle machine a état / lexer / parser pour analyser du texte lorsque c'est nécessaire. Maintenant est ce qu'une regexp est plus adaptée lorsqu'elle fait le même job ? Oui. Je suis juste en train d'écrire une spécialisation de la conversion d'un langage régulier vers un DFA/NFA.
Avec l'inverse ils existent aussi beaucoup de situations où les regexp sont inadaptées, non souhaitables, overkill, piégeuses etc.
[^] # Re: Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 8.
Si je pouvais te conseiller de retirer un seul truc de ce que je dis, c'est que tu émet un avis sur le code d’autrui avec un œil extérieur mais juge ton propre travail.
Que tu sois satisfait de ton travail très bien, que tu t'y retrouves très bien, que ca réponde à ton besoin aussi. Mais ça ne juge en rien que tu fais un bon boulot d'archi, d'écrire du code lisible ou autre qui est le sujet du journal. Ça prouve juste que tu te comprends toi même. Et plus on travail tout seul et plus on est auto-didacte, plus on risque s'enfermer dans "son style" qui devient une partie de sa personnalité. Parfaitement limpide pour soit mais uniquement pour soit.
Les vrais avis viennent toujours d'autrui. Personne n'en a rien a faire que je pense avoir écrit le meilleur code du monde. Si mes deux code reviewer me disent qu'ils ne comprennent pas quelque chose, j'ai forcément tord. Ils peuvent avoir tord aussi, mais même dans ce cas j'ai tord: ils n'ont pas réussi a me comprendre ou n'ont pas confiance dans le fait qu'ils voudront maintenir ce code. S'en suivent les discussions intéressante qui permettent à chacun de progresser.
[^] # Re: Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 10.
Comme la plupart des outils, il y a des cas ou c'est adapté et d'autres non.
En l'occurrence les regex peuvent effectivement être extrêmement piegieuses d'un point de vue performance. J'ai déjà vu des regex en
**mettre plusieurs minutes à répondre en matchant une url. La réponse est de comprendre comment marchent les regex NFA vs DFA, quand comment fonctionne le backtracking pour décider de quand et comment les d'utiliser. Dire simplement c'est pas bien est juste idiot. Tout est potentiellement trop lent et piégeur pour quelque chose.Mais ça c'était juste un point précis qui met la puce à l'oreille. J'ai été rapidement voir le code (Log2 et MyADM) et s'est malheureusement très très très moyen.
Bref un discours entoushiaste et plaisant n'est pas forcément suivi de faits. C'est exactement pour ça que demander aux gens de parler de leurs projets en interview ne marche pas. Tu peux être impressionné pendant 30mn avec ce genre de discours avant de découvrir qu'en fait le mec optimise du trading haute fréquence pour avoir un jitter max < ms avec des printf et un timer qui a une résolution inférieur à l'objectif… La tu backtrack sur tout ce qu'il a dit et tout s'ecroule.
# Show me the code
Posté par ckyl . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 10.
On peut voir l'article comme intéressant ou pas selon comment on le prend. Il contient plein de choses avec lesquelles on ne peut pas être en désaccord (ie. "il est important de bien nommer et moi je nomme bien").
Maintenant je passe mon temps à rencontrer des gens avec le même discours qui pondent des horreurs sans nom. Tout le monde est persuadé de bien faire. Tu utilises d'ailleurs l'expression "un bon développeur". Les développeurs c'est comme les conducteurs, ça se divise entre les bons et les mauvais. Les bons développeurs étant ceux qui font comme moi (enfin comme le moi de maintenant pas le moi d'il y a quelques mois).
Ce biais est encore renforcé pour les gens qui reçoivent peu de feedback, comme les auto-didactes, et qui s'enferment petit à petit dans leur façon de faire (idée développées par Kevlin Henney dans Individuals and Interactions over Processes and Tools.
Je serais donc très intéressé de voir à quoi correspond une base de code écrite par quelqu'un comme toi: amateur, visiblement passionné, qui dit pas mal de choses censées, mais souvent suffisamment vague pour qu'on ne puisse être en désaccord de toute façon, et qui en même temps laissent quelques indices sur le fait que tu pourrais t'être bâti ton propre monde (les tests me servent à rien, j'ai eu un problème de perf avec les regexp que je n'explique pas mais j'en généralise que "les regex c'est mal", "fabriquer ses propres générics" etc.).
Si j'ai un peu de temps j'irai jeter un œil à ton dépôt. Je n'ai aucune idée d’à quoi m'attendre entre le meilleur ou le pire.
[^] # Re: Méthodes de conception
Posté par ckyl . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 4.
https://en.wikipedia.org/wiki/Run_it_up_the_flagpole
La réalité immuable du business c'est qu'il est très difficile de savoir quels produits marcheront et la plupart des produits sont des échecs commerciaux.
Lancer une idée à moindre coût, quitte a faire des sacrifices sur une vision purement technique / ingénierie n'est donc pas forcément complétement stupide. On balance tout si jamais ça ne prend pas, et on itère / améliore / paie la dette sinon.
C'est risqué si on ne maitrise rien du tout et tout est un gros tas boue. Mais vu que l'immense majorité des produits sont des échecs ça peut aussi de minimiser le cout de tout ce qui foire.
Architecturalement, on a donc tout intérêt a mettre des jolies barrières entre ce qui fait actuellement parti de son "core domain" et tout ce qui gravite autour. Les processus et niveau de qualité attendu n'étant très certainement pas du tout les mêmes.
Comprendre la réalité de son business est donc primordiale pour chercher des solutions en adéquation avec les besoins.
[^] # Re: Méthodes de conception
Posté par ckyl . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 2.
Je te rejoins sur le fait que les prérequis de ton approche et ceux de déléguer à une SSII sont assez proches.
Mais mon modeste avis est que sous traité à une SSII est globalement un non sens. Inadaptées au gros des besoins et incapables sur le reste.
# Hacker news driven development
Posté par ckyl . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 4. Dernière modification le 06 mars 2016 à 21:23.
Heu non.
Vouloir "utiliser le dernier truc à la mode" rappelle beaucoup trop l'incapacité de notre industrie à apprendre quoi que ce soit.
Chercher à résoudre des problèmes de manière simple et fiable devrait finir par mener à chercher à écrire du code ennuyeux (lire sans surprise) avec des technologies ennuyeuses (lire maitrisées).
[^] # Re: Méthodes de conception
Posté par ckyl . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 5.
On peut parfaitement appliquer un processus d'ingénierie classique en informatique, d'ailleurs certains domaines le font.
Mais en dehors de l'inculture crasse du secteur IT que tu décris à raison, la réalité reste qu'effectivement la majorité des produits ne sont jamais défini et ne le seront jamais. Pour de bonnes, ex: "throw again the wall, see if it stick", et beaucoup de mauvaises raisons.
Si un jour ça a été défini et que tu as fait le truc "correctement" au début, de toute façon la vision figée d'un produit ne tiendra pas longtemps. Pour tout ce qui est non life-critical, tout change constamment de manière organique. Les specs & fonctionnalités changent plus vite qu'il ne faut de temps pour simplement les écrire. Le TTM et les fonctionnalités sont un plus grand levier que la correction.
Bref, oui la majorité de l'IT est du grand n'importe quoi. Maintenant croire que ton modèle marche partout c'est aussi n'importe quoi. Il existe une grande variété d'approches pour limiter le désastre inhérent à un monde qui change constamment, on est juste assez mauvais dans toutes.
[^] # Re: Faux problème ?
Posté par ckyl . En réponse au journal Google Stop. Évalué à 2.
Si tu as coché la case de ne pas te proposer de pubs personnalisées c'est assez normal ;)
En fouillant dans les options des différents services y'a pleins d'option du genre qui permettent de désactiver les historiques, l'envoi d'informations vers les serveurs ou les recos personnalisées. Bon bien sur faut pas espérer avoir goolge now ou autres en décochant tout.
[^] # Re: Régression ?
Posté par ckyl . En réponse au journal Rapport Badinter sur le droit du travail..... Évalué à 8.
La différence c'est les bornes legales.
Dans les secteurs ou les employeurs se sont regroupés (genre 3) et en position de force (entente plus ou moins tacite et pas de problème de mtaain d'œuvre). Tu as des gens qui ont le droit entre le smic et le smic et des contrats à plein temps ou partiels. C'est pas génial mais ça permet de vivre.
Si tu passes ces gens là en indep. Ils vont se retrouver payé à la minute pour la même compensation horaire. Je fais pas de CA tu vas en salle de pause. Tu reviendras dans la minute ou j'ai besoin de toi. Bref de vrais précaires, corvéables, remplacables à volonté (non leur rémunération ne permettra jamais d'assurer un risque maladie ou autre). Similaire à la magie des contrats 0h en Angleterre.
Alors oui on peut dire qu'ils suffit qu'ils aillent faire autre chose ou l'herbe est plus verte. Mais je me permet quand même de pouvoir douter de l'impact global de ce genre de changements. Surtout sur les 'faibles'
Signé un indep qui profite très largement d'un marché ou il est en position de force, qui peut effectivement faire marcher la concurrence, gérer ses risques et faire autre chose au cas où.
[^] # Re: Régression ?
Posté par ckyl . En réponse au journal Rapport Badinter sur le droit du travail..... Évalué à 3. Dernière modification le 27 janvier 2016 à 13:23.
Te faire prendre XX% pour un service pourri (facturation + commercial de merde) mais que tu ne peux pas éviter par ce que les clients ne dealent qu'avec une SSII j'appelle pas ça intéressant mais du racket :)
Tu prélèves ta dime sur la durée totale d'un contrat pour un acte ponctuel. Calcule le prix que facture un cabinet de recrutement (ils offrent pas les mêmes presta hein et surtout pas à toi). Calcule combien rapporte ~XX% sur un CA d'indep et voit l'arnaque.
Note: XX semble être vers 20 mais jamais essayé perso.
[^] # Re: Régression ?
Posté par ckyl . En réponse au journal Rapport Badinter sur le droit du travail..... Évalué à 7.
La seule limite que j'appliquerai c'est qu'on a tendance à voir le monde en extrapolant notre situation personnelle.
Pour notre marché effectivement tu as parfaitement raison. La concurrence existe, les prix sont hauts et la demande forte.
Par contre partir de ce constat local pour dire que c'est une bonne solution pour la société dans son ensemble, je suis plus circonspect. Basculer globalement vers un monde d'indépendant, ça veut dire que tous ceux qui ne sont pas en position de force ou dans un marché équilibré se font rincer et deviennent corvéables (ce qui n'est pas le cas de l'informatique ou c'est plus la ruée vers l'or).
[^] # Re: Régression ?
Posté par ckyl . En réponse au journal Rapport Badinter sur le droit du travail..... Évalué à 4.
Évidement. (Le possible me choque par contre :))
Je parle de la qualité de ce qu'on te propose en CV, et à l'entretient.
Ce qui détermine ce que tu peux signer et le temps que tu y passes (pour un service que tu as décider de déléguer hein).
Oui et non. Quand je recrute pour ma boite par ma boite. Je peux maitriser le canal d'alimentation des gens qui viennent en entretient. Je peux:
Quand c'est une SSII qui m'alimente:
Je n'ai donc plus aucun levier pour faire en sorte de maximiser le signal dans ce qui arrive en entretien. Du coup, statistiquement les gens intéressants (ie. "Trouver le meilleur") sont moins fréquent dans ce qui m'arrive que dans la population totale et c'est beaucoup plus difficile d'arriver à l'objectif que tu énonces.
Maintenant le problème se complexifie encore quand tu prends en compte que tu es maqué avec 1/2/3 boites et que tu as des clauses de "remplacement". En pratique le mec bon il se tire dans 12 à 24 mois. Statistiquement c'est quoi les chances que la même SSII ait un mec aussi compétent dispo à ce moment là ou quelle soit capable d'en recruter un deuxième ?
Tu as raison.
Je te donne l'avis d'un mec qui a fait passer des entretiens pour ses équipes et qui n'est intéressé qu'à avoir des gens compétents pour le job.
SSII, ça veut dire de devoir accepter de baisser ses exigences ou de ne pas signer. Et de savoir que les mecs vont se casser quoi qu'il arrive.
C'est effectivement simplement un calcul.
Question, combien de temps tu tiens en inter-contrat sans avoir à faire un truc qui va te faire démissionner de toute façon ?
Sans passer dans le consulting pur et dur qui est un métier assez différent de ce que font la plupart des gens. On peut réfléchir à la plus value réelle d'une SSII pour soit. En quoi je profite de:
Si tu n'en profites pas, ou que tu facturerais ces mêmes postes moins cher, alors le perdant c'est toi.
Après ça veut aussi de continuer à bosser pour les mêmes boites.
Si on veut du salarié, viser du côté des boites qui voient encore leurs compétences humaines comme importantes est souvent un bon choix pour faire des choses intéressantes dans de bonnes conditions avec des gens intéressants. Si une boite tourne à coup de presta tu sais à quoi t'attendre (ie. c'est clairement pour avoir les "meilleurs mecs" à chaque poste)