Ce que je dis c'est que je n'ai pas besoin d'une équipe projet constituée à 100% d'experts techniques. C'est overkill, ça coute un bras et en plus ils vont se taper dessus parce leur framework/algo est meilleur/plus performant que celui du voisin (ce que j'appelle le syndrome de l'expert technique).
Premièrement, ca dépend effectivement de ce que tu fais.
Deuxièmement, en pratique le coup des experts qui se battent sur des conneries ca arrive dans les boîtes ou tu utilises les experts comme tu le dis, que ca fait 10 ans qu'ils se tripottent la nouille dans des "cellules" plutôt que de livrer, et ou la gestion de projet est "rigolotte".
Autrement mon expérience quand les bons sont habitué à faire plutôt qu'à coacher; on discute pendant les X heures attribuées au design, estimations, ce qui est une très bonne chose et après on bosse basta.
Je préfère un mix de niveaux d'expertise, qui permet à l'expert de coacher le développeur qui lui même explique au débutant comment faire un commit.
Mouarf c'est ce que tu vois dans les boîtes Francaises. Du coup le bon il passe 0% de son temps à faire son job, régresse, et attrape le "syndrome de l'expert technique".
Quand tu embauches un débutant c'est pour que dans 1/2/3/4 ans il soit "expert" comme les autres de ton équipe. Par par ce que tu prévois que tu as actuellement du taff de merde à lui donner et qu'il ne faut surtout pas voir plus loin.
On entend souvent les gens se plaindre qu'ils sont super bon mais que leur taff c'est de la merde à cause des méchants client/SSII/autre. Mais le nivellement par le bas affiché un peu partout me fait assez peur. Martin Fowler disait dans Who needs an architect ?:
Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We
have met the enemy, and he is us.”
Je trouve cela très juste. Quand tu fais la comparaison entre la différence de salaire à embaucher des gens compétents et ce qu'ils sont capable de produire par rapport aux autres. Le calcul est assez vite fait. Nous sommes sur un marché où la compétition est mondiale et l'informatique est un moyen de faire la différence, de pousser de l'innovation, de gagner des marcher, de se doter d'outils performants qu'on aurait pas forcément imaginé etc.
Exemple: d'un côté tu as l'approche des journaux Français à chouiner pour des subvention incapables d'avoir la moindre idée nouvelle, de l'autre le New York Times qui se bouge…
et ce sans même s'enquérir d'éventuelles particularités dans ma manière de développer, dans ma façon d'utiliser certains outils, ou dans que sais-je quoi d'autre encore, qui eussent pu justifier leur non-utilisation.
Sauf cas extrême (Linux en est un), si tu as trouvé une manière de développer, une facon d'utiliser certains outils, ou que sais-je quoi d'autre qui permet d'avoir la même qualité à long terme en ce passant de une partie importante du cout de développement d'un logiciel, écrit un bouquin tu es riche, très riche… Autrement c'est pipo.
A chaque fois qu'une équipe m'a sorti le refrain "Non mais tu comprends pour ce type de produit ca sert à rien c'est trop difficile" ils livraient de la merde et avancaient comme des tortues… Ou c'était un mec qui faisait des trucs tout seul dans son coin comme un gros goret.
Par contre pour les test, je bosse dans le service depuis 22 ans et j'ai vu très peu de client prêt à payer pour ça, ce qui l'intéresse c'est que ça marche et il y à la recette pour ça.
Au bout d'un moment on constate que la recette est contre productive et qu'il est beaucoup plus efficace de bosser en amont et de manière continue.
La recette, c'est beaucoup trop tard pour trouver les problèmes. C'est ta dernière phase avant la livraison. Tu fais quoi quand il y a un vrai problème ? Tu fais quoi quand il y a un truc à modifier ? Tu fais quoi quand tu te rends compte 6 mois après le début du dev que ca passe pas ?
Pour avoir vécu la migration de phase de recette qui durent 6/8 semaines vers des techniques de notre époque le client est au contraire très content pour ce que ca lui coûte moins cher pour avoir un meilleur produit… Avant les devs se tournaient les pouces pendant ce temps. Le produit était inévitablement plus mauvais par ce que l'assemblage, les tests, la détection des regressions et la validation par le client arrivaient beaucoup trop tard qu'on puisse y faire quoi que ce soit d'utile. Maintenant ca bosse de manière fluide, on livre à la demande des choses de qualité constante avec une vélocité constante et bien supérieure.
Le client il est pas con. Si c'est mieux pour moins cher il achète… Si en plus il peut comparer les résultats de différentes équipes ca devient vite flagrant pour lui. Si le coût à long terme augmente en faisant les choses correctement il y a un soucis quelque part…
Mais même en appliquant à la lettre ce que tu dis, vraiment, j'en connais qui ont "réussi" tout de même. Ils ont juste recu une proposition 20K en dessous de leur salaire actuel (en étant au courant)…
Non sérieusement tu peux pas échouer dans le sens ou le seul truc qui intéresse c'est le différentiel prix de placement/salaire et que techniquement ils pigent rien, c'est juste des, plus ou moins mauvais, RH. Au pire t'as une proposition irréaliste.
C'est du re-targetting. C'est effectué par des prestataires externes, notre champion national étant criteo. Les régies récupèrent les infos de différents services pour les balancer à l'ad server qui va alors choisir la pub à afficher.
La réponse à ta question est donc non, ce n'est de tout facon pas des infos fournies par Google ou autres. Quand à la pertinence de la technique tout court…
Pourtant, je pense que j'échouerai dans la plupart des entretiens 'standards' de recrutement, d'autant plus si ces derniers sont réalisés par des SSII.
C'est possible d'échouer à un entretien de SSII ? Pour de vrai ?
Non c'est un choix. Tu peux le trouver stupide. Mais contrairement à toutes les conneries qu'il dit souvent, cela à un sens.
Partager leurs modifications sur n'importe quel serveur git avec des noms de commiteurs obfusqués, ré-écrits ou tous les changements rebasés c'est vraiment pas difficile.
C'est ce que je dis. Le problème n'est pas Github mais de trouver l'orga qui permet de bosser efficacement dans les limites que l'on se pose et de manière réfléchie.
Après ca ne veut pas dire que je suis d'accord avec lui, tout au contraire. Si tu ne veux pas faire fuire ce genre d'info tu es obligé camoufler tellement d'infos que c'est vite stupide de vouloir publier ses changements et decontribuer. Tu bosses en interne dans ton coin, tu demandes à tout le monde de n'avoir aucune activité publique et quand ca n'a plus de valeur tu publies/upstream. Ca à un coût certain mais il faut savoir être cohérent. Entre les deux, c'est nawak.
Maintenant si le but c'est de retenir tes mecs, tu as intêret à avoir de très bonnes raisons de faire ça. Si tu leur interdit toute façade publique ils risquent d'avoir envie d'aller voir ailleurs rapidement.
Et j'oubliai pour le leak d'info internes sur l'orga etc. Déjà tu jettes un oeil sur leur site web, ca donne énormement d'infos.
Ensuite t'as déjà fait le test d'appeler tes mecs (facile à identifier via linked in ou un moteur de recherche) en te faisant passer pour un recruteur ? Et ce que tu apprends ? C'est vachement plus général que Github comme problème non ?
Je sais que cette gymnastique intellectuelle n'est pas facile à faire pour nous, mais essayons quand même d'avoir le minimum d'hygiène intellectuelle pour reconnaître que l'open source n'est pas le but premier de certaines boîtes qui font du profit.
Bha justement la gymnastique est très simple. Son problème est très facile à comprendre, et il est justifié: Chercher à ne pas trop exposer ce qu'ils font en interne et qui fait quoi. On peut juger ca surperflu ou pas, mais ca se tient à 100%.
Maintenant si tu as un cerveau en état de marche, tu percutes que la solution interdire l'utilisation de Github est débile par rapport au problème. La seule spécificité de Github c'est de centraliser pas mal de projets. Mais niveau leak d'info internes c'est exactement la même chose que n'importe quoi d'autre:
- Que tu pousses des commits sur github, ou sur un autre serveur, si tes commits finissent par arriver upstream l'info elle est là et publique
- Que tu soumettes un patch ou fasse une pull request, l'info est la même
- Que tu discutes sur n'importe quel bugtracker, l'info est la même et ca leak énormement sur ce que tu fais et qui fait quoi
- Idem pour les gist
Bref la réponse est totalement incohérente soit trop soit trop peu. Si tu ne veux pas que ces infos leaks, dans un premier temps tu interdits toute contribution visible et identifiable. Tu poses un gros diff régulièrement quelque part et basta, contributions identifiables sur les BT interdites. Soit ma proposition. Après tu réfléchis à comment t'organiser pour anonymiser le tout en externe tout en ayant les infos en interne, synchroniser les version, comment tu fais contribuer tes équipes avec les projets etc.
Interdire Github ca ne règle absoluement aucun problème en soit puisque Github n'a rien de spécifique. Même si Github faisait de l'analytics et revendait les données on s'en foutrait grâve puisque d'autres service font la même chose en aggrégant toutes les sources dispos (type Olhoh). Et il faut vraiment être à côte de la plaque pour croire que Google a attendu Github pour détecter les contributeurs à certains projets ils font ca depuis le début… Tout comme si tu dois recruter quelqu'un dans une équipe, tu proposeras certainement à quelques mecs que tu juges bons via leurs contributions sur des projets interressant.
Je m'excuse d'essayer de comprendre en quoi sa solution ne règle absolument aucun problème qu'il expose. Ca ne te semble pas profondément stupide d'interdire Github mais le le gerrit d'openstack c'est ok ? Ils créés un projet sur un gittorious interne, ils exposent les branches et laissent les maintainers merger leur branche c'est ok ?
Interdire Github est une solution cohérente ? Sérieusement ?
Bon maintenant va aussi falloir interdire:
- De poser des questions sur les ML
- D'ouvrir des bug report
- Les patch/commit upstream par ce que les cabinets vont utiliser Ohloh ou regarder les logs
L'Open Source par OVH: Poser un gros tarball bien sâle sur un ftp et interdire aux devs de dire leur employeur.
Ca va être pratique pour les projets de bosser avec eux !
Même expérience pour moi. J'ai aussi eu ca sur des boîtes à Londres. Où il y a une communauté de très très bons et de boîtes qui poussent forts.
J'ai l'impression que depuis quelques années on est revenu du tout algorithmique/puzzle type CS bot. Maintenant ca commence plus avec des problèmes assez larges/ouverts/vagues pour finir par pousser très loin selon ce que tu maîtrises, où tu vas et ce qu'ils veulent tester. Ou avec des sessions de pair-programming. Du coup c'est super intéressant.
En France jamais eu un entretient intéressant ou utile pour le moment :(
Qu’est ce qui est demandé à un développeur aujourd’hui : maitriser un langage et son API sur le bout des doigts ; ou bien maitriser ce qu’il y a autour du code ?
Le deuxième si tu fais de la "plomberie".
Les deux si tu fais de la plomberie un peu plus smart.
Les deux, plus des connaissances honnêtes en réseau/algo/hardware/OS si tu fais des "vraies" applis non plomberies qui font des trucs un peu chaud/marrant/gros.
Faut pas voir les choses de facon aussi binaire ;)
Maintenant tu as cité les compétences de base. En dessous c'est compagnie créole pas dev. Tu cherches des mecs qui se distinguent de différentes facon au dessus de ca. Tu places les exigences plus ou moins haut selon ce que tu cherches.
Si tu penses que tes critères de selection sont les bons, bonne nouvelle tu es très riche…
Je ne comprends pas très bien le problème que tu soulève.
Je ne soulève aucun problème à la base sur ce sujet.
Je réponds sur une réponse erronée, et souligne le pourquoi du comment. C'est un problème très classique découlant de choix très discutables fait il y a des années par la JVM/Java 5 et que tu ne peux pas ignorer si tu fais autre chose que lancer du code.
Ne cherche pas a rattacher cela à la discussion initiale sauf par le fait que manipuler des types primitifs en grand nombre c'est fréquent. Un jour tu as certainement recodé pleins de structures de données à la main par ce que y'a zob par défaut.
Après y'a des centaines d'autres raisons d'aller "bas niveau". Tout comme tu vas forcément finir par aller te frotter aux problèmes courants de la JVM et du langage "tout le monde" à les mêmes problèmes.
Plus sérieusement si tu en es à ce niveau d'optimisation, c'est que tu n'as plus grand chose d'autre à optimiser, voire que tu as du temps à perdre…
Oui, on me paie par ce que c'est cool de perdre du temps sur des trucs totalement inutiles pas par ce que mon boulot à un sens !
sauf bien sur si tu te balades avec des tableaux de dizaines/centaines de milliers d'entiers
Tu es sur la bonne piste.
Quand tu sors de la "webapp lambda" ou du script, tu as souvent ce genre de contraintes:
- SLA type X rêquetes/s ou jitter < 40ms
- Besoins business qui poussent très fort la technique
- Ne pas gacher XXXK€ de matos quand ca coûte moins cher à fixer en soft
- Etc.
C'était bien le sens de mon message à la base sur "yatoudanlélib". Finalement ayant bossé dans quelques secteurs/technos différents, j'ai toujours eu à me sortir les doigts sur l'algorithmique et l'implémentation à un moment ou l'autre. C'est aussi ca qui fait la différence entre une bouse et un truc qui marche ou qui coute 100x plus cher en ops. Notre métier c'est de comprendre ce qu'on attend et de proposer ce qui semble le meilleur choix, c'est un équilibre entre:
- Penser "hors de la boîte" pour prendre le problème de la manière la plus intelligentes ou enlever les contraintes non dures.
- Du design de haut niveau
- Du design de bas niveau
- Savoir coder
- Savoir ne pas coder et acheter du matos
Si la solution simple fait le job, on fait la solution simple et on passe à la suite.
Pour mon métier actuel ca veut aussi dire: Est ce qu'on optimise du code séquentiel par ce qu'en grattant un ou deux ordres de grandeurs ca va passer ou est ce qu'on distribue le tout sur X machines (le coût en engineering se pose la aussi) ? Un footprint mémoire x4 ou x9 ca peut aussi vouloir dire passer d'une machine à XXX, tu te mets à taper du disque et du réseau alors que c'était CPU bound et le coût en matos est pas linéaire du tout. Ou simplement ne plus être capable de livrer ce qu'on te demande.
sauf bien sur si tu te balades avec des tableaux de dizaines/centaines de milliers d'entiers, mais là le problème est peut être en amont
Oh tu recommences à me prendre pour un âne ;) Tu veux jouer ?
Il y a des cas où ça te fait vraiment ch** ok, mais rien ne t'empêche de le coder à la main.
Bien sur. Si tu remontes la discussion, tu verras que c'est ce que je fais et que tu me proposais une juste solution impossible à un exemple particulier ;)
Maintenant si je ne codais qu'un sort par ce que y'a pas dans la lib standard je me ferais bien chier…
Encore une porte ouverte enfoncée ! J'aime bien la propension de prendre les autres pour des brêles sur ce fil ;)
C'est ce que tu finis par faire et ca à ses propres problèmes:
Tu ne libs pas des trucs sans usage massif et vérifié. Autrement tu rentres dans un autre problème qui est la gestion de la compatibilité et du design. Une fois que tu as des clients ta bouse tu ne la modifies plus. Ca coûte pas du tout la même chose à concevoir et maintenir que du code planqué quelque part à côté du métier.
Que tu te retrouves avec 100 libs. Chacune fait des trucs aucune tout. La gestion des versions dans le produit final est l'enfer. Et quand tu rajoutes les évolutions du langage ca devient vraiment très marrant (Java 8 + Guava est un plaisir…). Au niveau "macro" Guava + Commons est l'exemple type. En micro, chaque équipe/projet fait ses libs et en 2 ans c'est très rigolo (autrement retour au premier point).
Mais je te supporte dans la démarche d'utiliser un exemple précis sans voir large pour pouvoir dire des généralités ;)
Ca serait intelligent comme règle, histoire de bien flinguer le ratio signal/bruit de tout poste disponible et dissuader d'embaucher ! Déjà qu'une bonne partie des boîtes pas débiles fuient les annonceurs mainstream ou généralistes par ce que ça fait perdre du temps pour rien.
A ma connaissance il n'y a aucune obligation, et au pire tu fais un blackhole et basta.
Les échos que j'ai eu dans d'autres domaines correspondent aux constat que j'ai fais. Ce genre d'annonceur c'est perdant-perdant. Chaque métier/secteur à ses filières qui permettent aux gens qui ne sont pas la par hasard de se trouver.
Tu me prends pour un âne ou tu tiens à entretenir la réputation qui va avec ton pseudo ? ;)
trier une liste d'entiers selon un comparateur adhoc en Java
Typiquement tu utilises un type primitif pour faire du packing de plusieurs valeurs. Tu mets ce type primitif dans un tableau, puis tu veux le trier ou faire une dichotomie selon une valeur packée.
Comme souvent, tu ne peux spécifier un Comparator que pour des objets par ce qu'ils ne veulent pas livrer X implémentations copier/coller pour les types primitifs (merci la VM/autoboxing de merde !).
Utiliser l'autoboxing pour ca, ca veut dire payer 12 bytes d'overhead mémoire pour 4 bytes de données pour chaque élément, plus le coût CPU, plus faire exploser la génération de garbage. C'est vite risible.
En Java c'est game over tu le fais à la main et tu réécris le même code pour la millième fois. D'autres langages de la JVM sont capables de prendre en charge la génération de ce code pourri pour te le rendre transparent (y'a pas de magie non plus).
En fait c'est juste Github qu'il aime pas, par ce que c'est rien que des méchants qui font du big data et permettent aux chasseurs de tête de trouver les gens… Et aussi qu'openstack c'est rien que la mafia qui nous aime pas pour pousser nos patchs…
T'auras leurs joyaux là par ce que c'est grave sécure anti data mining.
Donc on arrête de faire sa chouineuse et on cherche pourquoi le mec à objectivement préféré aller chez Google ou de généraliser sur un exemple si il n'y a pas de raisons…
Si j'ai bien compris la référence à github c'est juste risible.
Posté par ckyl .
En réponse au journal L'Open Source chez OVH.
Évalué à 8.
Dernière modification le 18 juillet 2013 à 13:44.
Trop souvent les boites "oublient" que c'est aussi à elles de s'arranger pour que les employés n'aient pas envie de partir.
C'est ce que je disais avec humour ;)
Avant il fallait payer mieux ou de donner des projets plus marrants etc. pour leur prendre un mec. Maintenant il suffit de les laisser bosser upstream, tout le reste étant égal, pour que les mecs se tirent. Simplement par ça vaut de l'or pour leur carrière plutôt que de s'enterrer derrière un mur de béton. (Au passage ca profite aussi à l'entreprise mais bon…)
Et oui faut être teubé pour penser que github est le fautif. Les patchs sont toujours signés par quelqu'un et les communautés petites, github ou non…
Et oui, bis, vu les commentaires du mec, comme ca, ca donne envie d'aller bosser chez lui :p
Posté par ckyl .
En réponse au journal L'Open Source chez OVH.
Évalué à 10.
Dernière modification le 18 juillet 2013 à 12:37.
Avant ils se sont fait débaucher un gars. Maintenant ils n'arriveront plus à recruter ce type de gars ou les feront partir vers des boîtes où ils peuvent faire la même chose, contribuer aux projets upstream et améliorer leur carrière et visibilité.
Ce que tu dis c'est que Martin Fowler, Martin Thomson, Trisha Gee, Michael Barker & les autres sont des cons incapables de choisir la techno ou le design qui répond à leur besoin ? Mince avec un peu de recul ca me parait pourtant être des gens extrêmement censés et compétents… Ou alors c'est plus général tu dis que tous les gens qui traitent de gros volume de données sont des crétins incapables ? Ca va autrement ?
Oui enfin je vois toujours pas pourquoi on parle d'optimisation en fait…
Construire un truc qui marche vite c'est à la conception, à la réalisation puis à l'optimisation. Tes choix de design/structures/algo tu les fais pas après une fois que tu te rends compte benoitement que tu vas être deux ordres de grandeur en dessous des objectifs.
Regarde pourquoi les softs qui vont vite vont vite et tu as la réponse.
Quand PHK "invente" le B-Heap pour Varnish, c'est pas 10 ans après. C'est qu'il sait ce qui va coûter cher pour son soft, il sait comment fonctionne un OS et la VMM et il design en conséquence pour en tirer parti.
Quand Martin Thomson et ses potes concoivent le disruptor disruptor, ils connaissent très bien les problèmes qu'ont les autres approches. Ils concoivent dès le départ l'outil dont ils ont besoin pour créer leur archi.
Quand Linus créé Git, il design le truc pour que ca réponde à son besoin de perf.
Etc.
Je trouve qu'ily'a une grosse part d'expérience là dedans. Tu commences par te faire niquer à rattraper ce que tu n'as pas prévu à la base à coup de profiling et micro-optim, puis petit à petit tu arrives de plus en plus à discerner les points clés de tes produits, les ordres de grandeurs, les piègres techniques de tes environnements, et à concevoir autour d'eux. Si en plus tu sais comment fonctionne une machine, un OS et ton runtime tu es le roi du monde.
Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
Oui ca c'est enfoncer des portes ouverte ;)
D'ailleurs il m'a fallu attendre près de 10 ans pour en avoir besoin.
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
Personne n'a dit de faire de la micro-optimisation au doigt mouillé il me semble… Choisir une représentation mémoire, une structure de donnée ou un algorithme en fonction des besoins et non de ce que te files la lib standard (tant mieux si ca correspond) ce n'est pas ca en tout cas.
Il me semble que les discussions se sont croisés.
L'exemple était donné pour répondre à un commentaire qui disait pour caricaturer "y'a tout de dispo en plus rapide que tu ne peux l'écrire dans les libs, réfléchit pas trop et utilise". Ce a quoi je répondais que de mon expérience ce n'est pas vrai. Tu te retrouves fréquemment a réécrire ou implémenter toutes sortes de choses pour des raisons objectives. À aucun moment je n'ai évoqué l'idée de recoder un split au pif.
Le coup de savoir estimer le coût de quelque chose, c'est ce que toi tu appelles "choisir l'archi". Je ne pense pas qu'on soit fondamentalement en désaccord.
"Choisir l'archi" c'est par exemple implémenter un Hyperloglog++ par ce que tu as besoin de faire des dizaines de milliers d'estimations de cardinnalité d'ensemble de millions/milliards d'éléments. C'est ne pas utiliser une collection standard quand tu sais que ca te fait 4x en empreinte mémoire et que ca va te poser problème pour ces objets en particulier. Bref se focaliser sur ce qui est important pour répondre à un besoin donné.
Après on profile et on gratte ce qu'il reste à gratter.
[^] # Re: Les deux mon général
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Premièrement, ca dépend effectivement de ce que tu fais.
Deuxièmement, en pratique le coup des experts qui se battent sur des conneries ca arrive dans les boîtes ou tu utilises les experts comme tu le dis, que ca fait 10 ans qu'ils se tripottent la nouille dans des "cellules" plutôt que de livrer, et ou la gestion de projet est "rigolotte".
Autrement mon expérience quand les bons sont habitué à faire plutôt qu'à coacher; on discute pendant les X heures attribuées au design, estimations, ce qui est une très bonne chose et après on bosse basta.
Mouarf c'est ce que tu vois dans les boîtes Francaises. Du coup le bon il passe 0% de son temps à faire son job, régresse, et attrape le "syndrome de l'expert technique".
Quand tu embauches un débutant c'est pour que dans 1/2/3/4 ans il soit "expert" comme les autres de ton équipe. Par par ce que tu prévois que tu as actuellement du taff de merde à lui donner et qu'il ne faut surtout pas voir plus loin.
On entend souvent les gens se plaindre qu'ils sont super bon mais que leur taff c'est de la merde à cause des méchants client/SSII/autre. Mais le nivellement par le bas affiché un peu partout me fait assez peur. Martin Fowler disait dans Who needs an architect ?:
Je trouve cela très juste. Quand tu fais la comparaison entre la différence de salaire à embaucher des gens compétents et ce qu'ils sont capable de produire par rapport aux autres. Le calcul est assez vite fait. Nous sommes sur un marché où la compétition est mondiale et l'informatique est un moyen de faire la différence, de pousser de l'innovation, de gagner des marcher, de se doter d'outils performants qu'on aurait pas forcément imaginé etc.
Exemple: d'un côté tu as l'approche des journaux Français à chouiner pour des subvention incapables d'avoir la moindre idée nouvelle, de l'autre le New York Times qui se bouge…
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4. Dernière modification le 22 juillet 2013 à 17:49.
Sauf cas extrême (Linux en est un), si tu as trouvé une manière de développer, une facon d'utiliser certains outils, ou que sais-je quoi d'autre qui permet d'avoir la même qualité à long terme en ce passant de une partie importante du cout de développement d'un logiciel, écrit un bouquin tu es riche, très riche… Autrement c'est pipo.
A chaque fois qu'une équipe m'a sorti le refrain "Non mais tu comprends pour ce type de produit ca sert à rien c'est trop difficile" ils livraient de la merde et avancaient comme des tortues… Ou c'était un mec qui faisait des trucs tout seul dans son coin comme un gros goret.
[^] # Re: qu'est-ce qu'il dit ?
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 6.
Au bout d'un moment on constate que la recette est contre productive et qu'il est beaucoup plus efficace de bosser en amont et de manière continue.
La recette, c'est beaucoup trop tard pour trouver les problèmes. C'est ta dernière phase avant la livraison. Tu fais quoi quand il y a un vrai problème ? Tu fais quoi quand il y a un truc à modifier ? Tu fais quoi quand tu te rends compte 6 mois après le début du dev que ca passe pas ?
Pour avoir vécu la migration de phase de recette qui durent 6/8 semaines vers des techniques de notre époque le client est au contraire très content pour ce que ca lui coûte moins cher pour avoir un meilleur produit… Avant les devs se tournaient les pouces pendant ce temps. Le produit était inévitablement plus mauvais par ce que l'assemblage, les tests, la détection des regressions et la validation par le client arrivaient beaucoup trop tard qu'on puisse y faire quoi que ce soit d'utile. Maintenant ca bosse de manière fluide, on livre à la demande des choses de qualité constante avec une vélocité constante et bien supérieure.
Le client il est pas con. Si c'est mieux pour moins cher il achète… Si en plus il peut comparer les résultats de différentes équipes ca devient vite flagrant pour lui. Si le coût à long terme augmente en faisant les choses correctement il y a un soucis quelque part…
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Ca ne compte pas comme échouer ;)
Mais même en appliquant à la lettre ce que tu dis, vraiment, j'en connais qui ont "réussi" tout de même. Ils ont juste recu une proposition 20K en dessous de leur salaire actuel (en étant au courant)…
Non sérieusement tu peux pas échouer dans le sens ou le seul truc qui intéresse c'est le différentiel prix de placement/salaire et que techniquement ils pigent rien, c'est juste des, plus ou moins mauvais, RH. Au pire t'as une proposition irréaliste.
[^] # Re: TrackMeNot
Posté par ckyl . En réponse au journal Un Firefox qui respecte votre vie privée. Évalué à 6.
C'est du re-targetting. C'est effectué par des prestataires externes, notre champion national étant criteo. Les régies récupèrent les infos de différents services pour les balancer à l'ad server qui va alors choisir la pub à afficher.
La réponse à ta question est donc non, ce n'est de tout facon pas des infos fournies par Google ou autres. Quand à la pertinence de la technique tout court…
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
C'est possible d'échouer à un entretien de SSII ? Pour de vrai ?
[^] # Re: suite : les précisions ...
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 3.
Non c'est un choix. Tu peux le trouver stupide. Mais contrairement à toutes les conneries qu'il dit souvent, cela à un sens.
C'est ce que je dis. Le problème n'est pas Github mais de trouver l'orga qui permet de bosser efficacement dans les limites que l'on se pose et de manière réfléchie.
Après ca ne veut pas dire que je suis d'accord avec lui, tout au contraire. Si tu ne veux pas faire fuire ce genre d'info tu es obligé camoufler tellement d'infos que c'est vite stupide de vouloir publier ses changements et decontribuer. Tu bosses en interne dans ton coin, tu demandes à tout le monde de n'avoir aucune activité publique et quand ca n'a plus de valeur tu publies/upstream. Ca à un coût certain mais il faut savoir être cohérent. Entre les deux, c'est nawak.
Maintenant si le but c'est de retenir tes mecs, tu as intêret à avoir de très bonnes raisons de faire ça. Si tu leur interdit toute façade publique ils risquent d'avoir envie d'aller voir ailleurs rapidement.
[^] # Re: suite : les précisions ...
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 3.
Et j'oubliai pour le leak d'info internes sur l'orga etc. Déjà tu jettes un oeil sur leur site web, ca donne énormement d'infos.
Ensuite t'as déjà fait le test d'appeler tes mecs (facile à identifier via linked in ou un moteur de recherche) en te faisant passer pour un recruteur ? Et ce que tu apprends ? C'est vachement plus général que Github comme problème non ?
[^] # Re: suite : les précisions ...
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 4.
Bha justement la gymnastique est très simple. Son problème est très facile à comprendre, et il est justifié: Chercher à ne pas trop exposer ce qu'ils font en interne et qui fait quoi. On peut juger ca surperflu ou pas, mais ca se tient à 100%.
Maintenant si tu as un cerveau en état de marche, tu percutes que la solution interdire l'utilisation de Github est débile par rapport au problème. La seule spécificité de Github c'est de centraliser pas mal de projets. Mais niveau leak d'info internes c'est exactement la même chose que n'importe quoi d'autre:
- Que tu pousses des commits sur github, ou sur un autre serveur, si tes commits finissent par arriver upstream l'info elle est là et publique
- Que tu soumettes un patch ou fasse une pull request, l'info est la même
- Que tu discutes sur n'importe quel bugtracker, l'info est la même et ca leak énormement sur ce que tu fais et qui fait quoi
- Idem pour les gist
Bref la réponse est totalement incohérente soit trop soit trop peu. Si tu ne veux pas que ces infos leaks, dans un premier temps tu interdits toute contribution visible et identifiable. Tu poses un gros diff régulièrement quelque part et basta, contributions identifiables sur les BT interdites. Soit ma proposition. Après tu réfléchis à comment t'organiser pour anonymiser le tout en externe tout en ayant les infos en interne, synchroniser les version, comment tu fais contribuer tes équipes avec les projets etc.
Interdire Github ca ne règle absoluement aucun problème en soit puisque Github n'a rien de spécifique. Même si Github faisait de l'analytics et revendait les données on s'en foutrait grâve puisque d'autres service font la même chose en aggrégant toutes les sources dispos (type Olhoh). Et il faut vraiment être à côte de la plaque pour croire que Google a attendu Github pour détecter les contributeurs à certains projets ils font ca depuis le début… Tout comme si tu dois recruter quelqu'un dans une équipe, tu proposeras certainement à quelques mecs que tu juges bons via leurs contributions sur des projets interressant.
Je m'excuse d'essayer de comprendre en quoi sa solution ne règle absolument aucun problème qu'il expose. Ca ne te semble pas profondément stupide d'interdire Github mais le le gerrit d'openstack c'est ok ? Ils créés un projet sur un gittorious interne, ils exposent les branches et laissent les maintainers merger leur branche c'est ok ?
Interdire Github est une solution cohérente ? Sérieusement ?
[^] # Re: suite : les précisions ...
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 4.
Bon maintenant va aussi falloir interdire:
- De poser des questions sur les ML
- D'ouvrir des bug report
- Les patch/commit upstream par ce que les cabinets vont utiliser Ohloh ou regarder les logs
L'Open Source par OVH: Poser un gros tarball bien sâle sur un ftp et interdire aux devs de dire leur employeur.
Ca va être pratique pour les projets de bosser avec eux !
[^] # Re: Algorithmique
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Même expérience pour moi. J'ai aussi eu ca sur des boîtes à Londres. Où il y a une communauté de très très bons et de boîtes qui poussent forts.
J'ai l'impression que depuis quelques années on est revenu du tout algorithmique/puzzle type CS bot. Maintenant ca commence plus avec des problèmes assez larges/ouverts/vagues pour finir par pousser très loin selon ce que tu maîtrises, où tu vas et ce qu'ils veulent tester. Ou avec des sessions de pair-programming. Du coup c'est super intéressant.
En France jamais eu un entretient intéressant ou utile pour le moment :(
# Les deux mon général
Posté par ckyl . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 7.
Le deuxième si tu fais de la "plomberie".
Les deux si tu fais de la plomberie un peu plus smart.
Les deux, plus des connaissances honnêtes en réseau/algo/hardware/OS si tu fais des "vraies" applis non plomberies qui font des trucs un peu chaud/marrant/gros.
Faut pas voir les choses de facon aussi binaire ;)
Maintenant tu as cité les compétences de base. En dessous c'est compagnie créole pas dev. Tu cherches des mecs qui se distinguent de différentes facon au dessus de ca. Tu places les exigences plus ou moins haut selon ce que tu cherches.
Si tu penses que tes critères de selection sont les bons, bonne nouvelle tu es très riche…
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Je ne soulève aucun problème à la base sur ce sujet.
Je réponds sur une réponse erronée, et souligne le pourquoi du comment. C'est un problème très classique découlant de choix très discutables fait il y a des années par la JVM/Java 5 et que tu ne peux pas ignorer si tu fais autre chose que lancer du code.
Ne cherche pas a rattacher cela à la discussion initiale sauf par le fait que manipuler des types primitifs en grand nombre c'est fréquent. Un jour tu as certainement recodé pleins de structures de données à la main par ce que y'a zob par défaut.
Après y'a des centaines d'autres raisons d'aller "bas niveau". Tout comme tu vas forcément finir par aller te frotter aux problèmes courants de la JVM et du langage "tout le monde" à les mêmes problèmes.
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Oui, on me paie par ce que c'est cool de perdre du temps sur des trucs totalement inutiles pas par ce que mon boulot à un sens !
Tu es sur la bonne piste.
Quand tu sors de la "webapp lambda" ou du script, tu as souvent ce genre de contraintes:
- SLA type X rêquetes/s ou jitter < 40ms
- Besoins business qui poussent très fort la technique
- Ne pas gacher XXXK€ de matos quand ca coûte moins cher à fixer en soft
- Etc.
C'était bien le sens de mon message à la base sur "yatoudanlélib". Finalement ayant bossé dans quelques secteurs/technos différents, j'ai toujours eu à me sortir les doigts sur l'algorithmique et l'implémentation à un moment ou l'autre. C'est aussi ca qui fait la différence entre une bouse et un truc qui marche ou qui coute 100x plus cher en ops. Notre métier c'est de comprendre ce qu'on attend et de proposer ce qui semble le meilleur choix, c'est un équilibre entre:
- Penser "hors de la boîte" pour prendre le problème de la manière la plus intelligentes ou enlever les contraintes non dures.
- Du design de haut niveau
- Du design de bas niveau
- Savoir coder
- Savoir ne pas coder et acheter du matos
Si la solution simple fait le job, on fait la solution simple et on passe à la suite.
Pour mon métier actuel ca veut aussi dire: Est ce qu'on optimise du code séquentiel par ce qu'en grattant un ou deux ordres de grandeurs ca va passer ou est ce qu'on distribue le tout sur X machines (le coût en engineering se pose la aussi) ? Un footprint mémoire x4 ou x9 ca peut aussi vouloir dire passer d'une machine à XXX, tu te mets à taper du disque et du réseau alors que c'était CPU bound et le coût en matos est pas linéaire du tout. Ou simplement ne plus être capable de livrer ce qu'on te demande.
Oh tu recommences à me prendre pour un âne ;) Tu veux jouer ?
Bien sur. Si tu remontes la discussion, tu verras que c'est ce que je fais et que tu me proposais une juste solution impossible à un exemple particulier ;)
Maintenant si je ne codais qu'un sort par ce que y'a pas dans la lib standard je me ferais bien chier…
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Encore une porte ouverte enfoncée ! J'aime bien la propension de prendre les autres pour des brêles sur ce fil ;)
C'est ce que tu finis par faire et ca à ses propres problèmes:
Tu ne libs pas des trucs sans usage massif et vérifié. Autrement tu rentres dans un autre problème qui est la gestion de la compatibilité et du design. Une fois que tu as des clients ta bouse tu ne la modifies plus. Ca coûte pas du tout la même chose à concevoir et maintenir que du code planqué quelque part à côté du métier.
Que tu te retrouves avec 100 libs. Chacune fait des trucs aucune tout. La gestion des versions dans le produit final est l'enfer. Et quand tu rajoutes les évolutions du langage ca devient vraiment très marrant (Java 8 + Guava est un plaisir…). Au niveau "macro" Guava + Commons est l'exemple type. En micro, chaque équipe/projet fait ses libs et en 2 ans c'est très rigolo (autrement retour au premier point).
Mais je te supporte dans la démarche d'utiliser un exemple précis sans voir large pour pouvoir dire des généralités ;)
[^] # Re: Euh ... faudrait savoir !
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 4.
Ca serait intelligent comme règle, histoire de bien flinguer le ratio signal/bruit de tout poste disponible et dissuader d'embaucher ! Déjà qu'une bonne partie des boîtes pas débiles fuient les annonceurs mainstream ou généralistes par ce que ça fait perdre du temps pour rien.
A ma connaissance il n'y a aucune obligation, et au pire tu fais un blackhole et basta.
Les échos que j'ai eu dans d'autres domaines correspondent aux constat que j'ai fais. Ce genre d'annonceur c'est perdant-perdant. Chaque métier/secteur à ses filières qui permettent aux gens qui ne sont pas la par hasard de se trouver.
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2. Dernière modification le 19 juillet 2013 à 12:38.
Tu me prends pour un âne ou tu tiens à entretenir la réputation qui va avec ton pseudo ? ;)
Typiquement tu utilises un type primitif pour faire du packing de plusieurs valeurs. Tu mets ce type primitif dans un tableau, puis tu veux le trier ou faire une dichotomie selon une valeur packée.
Comme souvent, tu ne peux spécifier un
Comparatorque pour des objets par ce qu'ils ne veulent pas livrer X implémentations copier/coller pour les types primitifs (merci la VM/autoboxing de merde !).Utiliser l'autoboxing pour ca, ca veut dire payer 12 bytes d'overhead mémoire pour 4 bytes de données pour chaque élément, plus le coût CPU, plus faire exploser la génération de garbage. C'est vite risible.
En Java c'est game over tu le fais à la main et tu réécris le même code pour la millième fois. D'autres langages de la JVM sont capables de prendre en charge la génération de ce code pourri pour te le rendre transparent (y'a pas de magie non plus).
[^] # Re: Euh ... faudrait savoir !
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 6.
Y'a vraiment des gens qui consultent les annonces de pôle emploi ? Pour des métiers qualifiés ?
C'est bien le dernier endroit où j'irai en tant que recruteur ou candidat. Y'a des domaines où ca à le moindre sens ?
[^] # Re: Euh ... faudrait savoir !
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 5.
En fait c'est juste Github qu'il aime pas, par ce que c'est rien que des méchants qui font du big data et permettent aux chasseurs de tête de trouver les gens… Et aussi qu'openstack c'est rien que la mafia qui nous aime pas pour pousser nos patchs…
T'auras leurs joyaux là par ce que c'est grave sécure anti data mining.
:)
[^] # Re: Logique
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 10.
Donc on arrête de faire sa chouineuse et on cherche pourquoi le mec à objectivement préféré aller chez Google ou de généraliser sur un exemple si il n'y a pas de raisons…
Si j'ai bien compris la référence à github c'est juste risible.
[^] # Re: Logique
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 8. Dernière modification le 18 juillet 2013 à 13:44.
C'est ce que je disais avec humour ;)
Avant il fallait payer mieux ou de donner des projets plus marrants etc. pour leur prendre un mec. Maintenant il suffit de les laisser bosser upstream, tout le reste étant égal, pour que les mecs se tirent. Simplement par ça vaut de l'or pour leur carrière plutôt que de s'enterrer derrière un mur de béton. (Au passage ca profite aussi à l'entreprise mais bon…)
Et oui faut être teubé pour penser que github est le fautif. Les patchs sont toujours signés par quelqu'un et les communautés petites, github ou non…
Et oui, bis, vu les commentaires du mec, comme ca, ca donne envie d'aller bosser chez lui :p
# Logique
Posté par ckyl . En réponse au journal L'Open Source chez OVH. Évalué à 10. Dernière modification le 18 juillet 2013 à 12:37.
Avant ils se sont fait débaucher un gars. Maintenant ils n'arriveront plus à recruter ce type de gars ou les feront partir vers des boîtes où ils peuvent faire la même chose, contribuer aux projets upstream et améliorer leur carrière et visibilité.
Ca me semble une bonne idée ;)
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3. Dernière modification le 18 juillet 2013 à 12:29.
Quel rapport avec la choucroute ?
Ce que tu dis c'est que Martin Fowler, Martin Thomson, Trisha Gee, Michael Barker & les autres sont des cons incapables de choisir la techno ou le design qui répond à leur besoin ? Mince avec un peu de recul ca me parait pourtant être des gens extrêmement censés et compétents… Ou alors c'est plus général tu dis que tous les gens qui traitent de gros volume de données sont des crétins incapables ? Ca va autrement ?
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 8.
Oui enfin je vois toujours pas pourquoi on parle d'optimisation en fait…
Construire un truc qui marche vite c'est à la conception, à la réalisation puis à l'optimisation. Tes choix de design/structures/algo tu les fais pas après une fois que tu te rends compte benoitement que tu vas être deux ordres de grandeur en dessous des objectifs.
Regarde pourquoi les softs qui vont vite vont vite et tu as la réponse.
Quand PHK "invente" le B-Heap pour Varnish, c'est pas 10 ans après. C'est qu'il sait ce qui va coûter cher pour son soft, il sait comment fonctionne un OS et la VMM et il design en conséquence pour en tirer parti.
Quand Martin Thomson et ses potes concoivent le disruptor disruptor, ils connaissent très bien les problèmes qu'ont les autres approches. Ils concoivent dès le départ l'outil dont ils ont besoin pour créer leur archi.
Quand Linus créé Git, il design le truc pour que ca réponde à son besoin de perf.
Etc.
Je trouve qu'ily'a une grosse part d'expérience là dedans. Tu commences par te faire niquer à rattraper ce que tu n'as pas prévu à la base à coup de profiling et micro-optim, puis petit à petit tu arrives de plus en plus à discerner les points clés de tes produits, les ordres de grandeurs, les piègres techniques de tes environnements, et à concevoir autour d'eux. Si en plus tu sais comment fonctionne une machine, un OS et ton runtime tu es le roi du monde.
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Oui ca c'est enfoncer des portes ouverte ;)
D'ailleurs il m'a fallu attendre près de 10 ans pour en avoir besoin.
Personne n'a dit de faire de la micro-optimisation au doigt mouillé il me semble… Choisir une représentation mémoire, une structure de donnée ou un algorithme en fonction des besoins et non de ce que te files la lib standard (tant mieux si ca correspond) ce n'est pas ca en tout cas.
Il me semble que les discussions se sont croisés.
L'exemple était donné pour répondre à un commentaire qui disait pour caricaturer "y'a tout de dispo en plus rapide que tu ne peux l'écrire dans les libs, réfléchit pas trop et utilise". Ce a quoi je répondais que de mon expérience ce n'est pas vrai. Tu te retrouves fréquemment a réécrire ou implémenter toutes sortes de choses pour des raisons objectives. À aucun moment je n'ai évoqué l'idée de recoder un split au pif.
Le coup de savoir estimer le coût de quelque chose, c'est ce que toi tu appelles "choisir l'archi". Je ne pense pas qu'on soit fondamentalement en désaccord.
"Choisir l'archi" c'est par exemple implémenter un Hyperloglog++ par ce que tu as besoin de faire des dizaines de milliers d'estimations de cardinnalité d'ensemble de millions/milliards d'éléments. C'est ne pas utiliser une collection standard quand tu sais que ca te fait 4x en empreinte mémoire et que ca va te poser problème pour ces objets en particulier. Bref se focaliser sur ce qui est important pour répondre à un besoin donné.
Après on profile et on gratte ce qu'il reste à gratter.