Donc tu as des points de passage obligés à une côte donnée… Le routage est trivial en rando. L'échelle des distances est petite, le maillage du réseau est faible, tu n'enmagasines pas d'ennergie, les frotements sont toujours les mêmes et il faut que ca monte méchament pour que ca commence à faire une différence. Tu ne vas pas faire 2km de plus pour éviter une légère côte ca n'a pas de sens.
Bref ca peut éventuellement valoir le coup de faire quelques kilomètres de plus pour épargner quelques centaines de mettre de D+/-. Mais dans la vraie ce genre de config ca n'existe que peu et c'est trivial à détecter en regardant la carte.
Plutôt qu'un soft, pour ce genre d'activité j'ai envie de dire que c'est plus sur d'apprendre à réellement lire les cartes.
Déjà que le benchmark ne semble pas particulièrement révélateur
Bha c'est un truc à la steckdenis… Ca n'empêche pas d'avoir des échanges intéressant et en ne cherchant par trop le pourquoi du comment de la question originale ;)
Quel intérêt donc hormis t'écouter parler ? Si tu n'as rien ou ne veut rien montrer, il suffit de ne rien dire.
Poser des questions sur des micro-optimisations (soit dit au passage très certainement inutiles par ce que sur une workload réelle ce sont les caches miss qui vont rapidement te couter cher et le reste qui ne suivra pas) sans publier du code concret, le bench et la méthodologie c'est prendre son temps. Soit tu montres ton code, soit tu sors des exemples auto-contenus. Mais sans ca, c'est un peu pisser dans un violon.
clock_gettime() est la bonne fonction à appeler en effet. Avec l'option CLOCK_REALTIME si je me souviens bien.
La seule différente entre clock_gettime(CLOCK_REALTIME) et gettimeofday c'est la perte de précision entre le timespec qui est en nsec et le timeval qui est en msec et fais un: tv->tv_usec /= 1000;
Faut faire pas mal gaffe en descendant à ces précisions car ca devient difficile de mesurer quelque chose.
Le coup du taskset est en effet une bonne idée pour les benchs mais aussi pour dispatcher manuellement le code métier. Le scheduler reste mauvais sur l'affinité, et c'est pas rare de gratter 10-30% de perf la dessus plutôt que laisser les threads se balader…
Le point que tu donnes on s'en balance dans un cas comme ca. On est en train de faire des benchs à vie courte !
Maintenant si tu regardes le code qui est exécuté pour gettimeofday, ou clock_gettime, je ne vois des masses que je pourrais faire mieux en écrivant mon propre code sauf besoin extrêment spécifique qui mérite qu'on prenne le risque de faire n'importe quoi. Maintenant puisque tu insistes sur le monotonic, si je compare do_monotonic avec do_realtime je ne vois pas en quoi ca change quoi que ce soit pour notre problème actuel. La différence c'est juste un offset appliqué par update_vsyscall quand les valeurs de base de vsyscall_gtod_data sont mises à jour.
Rappelons que ces fonctions sont mappées dans la page vdso par le kernel dans l'espace utilisateur de chaque process et donc que le coût d'appel à ces syscall à exactement le même qu'a une fonction userspace normale.
Je peux me tromper, je ne suis qu'un oeil naïf. Mais en réfléchissant au problème et à l'implémentation actuelle je ne vois pas de raison d'aller voir ailleurs.
Concernant le mesure du temps, il vaut mieux utiliser l'instruction rdtsc qui rend un nombre de cycles d'horloge
Il y a une raison particulière part rapport à un gettimeofday moderne qui s'occupe de gérer tout le bordel TSC/HPET pour pas cher avec une résolution exportée assez correcte ? On peut arriver aux limites de la résolution si on veut mesurer quelque chose d'extrêmement précis, mais là à priori il suffit de faire durer le bench le temps qu'il faut.
quand je code, je suis connecté. Je veux être notifié instantanément des commits.
J'en vois de moins en moins l'intêret. Fais ton taff. Au pire si ca dure longtemps, tu updates ta branche de référence de temps en temps pour voir les différences. Tu as exactement les mêmes informations et tu les as quand elles t'intéressent.
Avoir un truc à surveillé, ou tu peux louper des trucs, et qui interrompt ton travail n'apporte pas de plus value. Si je veux savoir si ca à changé il suffit de puller… De toute facon je devrais le faire. Il y avait un interet du temps de subversion, mais avec un VCS moderne je vois plus.
Je ne crois pas tu veux pouvoir voir si le quelqu'un fait une modif' sur une partie du code qui peu potentiellement impacter celui sur le quel tu es entrain de travailler.
Et si le mec commit pendant la nuit on retourne à la case départ.
Sur des petites fenêtre de temps de toute facon tu ne peux rien y faire et tu devras te tapper le merge, donc tu perds ton temps à te faire spamer en IM. Sur des "grandes" fenêtre de temps et pour suivre ce qu'il se passe avoir une UX plus adaptée et moins temps réel me semble un meilleur choix.
Les flux RSS c'est statefull ? C'est nouveau ça.
Strictement parlant tu as raison.
Pratiquement tu configures ton flux pour qu'il contienne suffisement d'entrées pour que tu puisses le considérer comme tel même avec un client basique (pas besoin de 5 ans d'historique).
Moi je crois que si tu veux suivre un flux de donnée, utiliser un truc stateless comme IRC est étrange. Si t'es pas connecté tu perds les notifications, ca veut dire qu'elle n'étaient pas si importantes que ca…
Du coup soit j'ai une raison d'avoir les notifications et j'utilise un support adapté (code review, mail, flux RSS ou autre). Soit j'ai pas de raison, et il me suffit de regarder l'historique de mon DVCS .
Si tu regardes le genre de code que tu écris dans les tests, c'est typiquement le genre de chose que tu veux pas écrire en C par ce que tu vas passer ton temps à réécrire des centaines de méthodes qui sont built-in ou qui demandent 3 lignes de glue dans beaucoup d'autre environnements.
De l'autre côté, effectivement plus tu rajoutes de couches plus c'est le bordel.
C'était tout le sens de ma question, savoir où en était le compromis actuellement et qu'elles étaient les pistes et techniques qui avaient été, ou sont, explorées.
Pas réellement fais de C depuis presque 10 ans, mais y'a pas un framework de test pour C qui s'est développé ? Voir dans un langage de plus haut niveau histoire de pouvoir coder rapidement et pas avoir des millions de lignes de tests.
On retrouve ca dans certains langages. Par exemple écrire les tests en Groovy pour tester du Java. Vu la facilité de faire des bindings C je serais étonné que personne n'ait poussé le truc.
Tu peux aussi te sortir les doigts. Si tu bloques la dessus avec des arguments comme ca, tu peux te réorienter tant qu'il est encore temps.
J'aime bien comprendre précisément ce que je fais,
Ca se combine pas très bien avec le fait que tu restes comme un gros bênet ne faisant même pas un man javac mais qui préfère ecrire 4 messages pour bien étaler son avis.
et en plus je trouve rien sur le net.
Dans ce cas consulte un livre fait de bois mort.
Si on ne peux plus troller sur DLFP…
C'est un poil gavant à la longue les boulets qui trollent dans le vide.
Mais ouais le Java ça me gave […]
Bien tes arguments montre que tu as fait un hello world
mais ça montre que l'apprentissage des choses par l'IDE est pas forcément une bonne chose
Non ca montre que tu restes dans ta crasse. L'IDE n'y est pour rien. Si il n'était pas la, tu ferais quoi ? Tu resterais assis à attendre ? La démarche pour javac et jar n'est pas plus compliquée, et même beaucoup plus simple que gcc & co. L'IDE te facilite la vie, ne pas apprendre ce que tu dois apprendre, c'est toi qui le décide. Tout comme mal l'utiliser.
Déconnes pas les mecs de Jetbrains se sont fait chier pour collecter les types à runtime pour pouvoir proposer une completion correcte. Tu vas les faire se pendre…
Cela dit rigolo c'est tendance de vouloir faire un faux typage statique dans les langages dynamique (python, js) après s'être rendu compte qu'on devait de toute facon spécifier les types dans la documentation… C'est cool tu spécifies tout mais ca ne sert à rien !
Tu ne comprends visiblement pas le problème qui n'est pas une histoire de . mais qu'il faut avoir compilé le code pour être capable de déterminer le type d'une variable.
Quel est le type de foo.createSession() ? Comment gères tu le polymorphisme entre foo.createSession(varInt) et foo.createSession(varLong) ? Comment gères l'héritage pour aller chercher la doc d'une méthode non surchargée ?
Et oui encore une fois le boulot d'un IDE c'est de manipuler l'AST (et souvent un AST complétement invalide vu qu'en cours de dev).
Ce ne sont que les problèmes les plus triviaux. Après tu as aussi ceux sur l'environement. Comment vas tu automatiquement chercher la bonne doc pour toutes tes deps (il faut parser le pom et aller tapper dans le repo m2 local).
Dans tout les cas ton affirmation est mauvaise. Ce que tu dis implique que si tu utilises la programmtion par contrat alors tu n'as plus de bug. Ca serait la nouvelle du siècle…
Maintenant dès que ton code commence à faire quelque chose, des erreurs dans la logique métier, dans l'implémentation, dans la spécification des méthodes, des invariants, dans l'utilisation de code tierce, des corruptions, des erreurs provoquées par la compatibilité ca va arriver.
Une exception qui remonte par contre en général c'est juste un travail de porc ou la fin du monde.
Pourquoi est ce que ce genre de bug serait plus rare qu'une exception qui remonte ? Au contraire un exception qui remonte signale très souvent une erreur grossière.
ceux qui s'en passent le font souvent par mauvaise paresse, le bon paresseux étant capable d'investir du temps à l'apprentissage si ça peut lui permettre de moins bosser ensuite.
Exactement. Si tu sais te servir de ton IDE et de ton debuger, tu vas plus vite à mettre un point d'arret et inspecter les variables qu'à écrire ton printf avec toutes les infos utiles dedans… Et quand tu te rends compte qu'il manque un truc dans ton printf bha tu as pas à recommencer.
Ensuite, avec un IDE on comprend pas forcément ce qu’on fait.
Franchement le problème c'est toi et uniquement toi, pas l'IDE. Tes questions montrent que tu ne maitrises même pas les concepts que l'on doit apprendre vers le deuxième cours de Java. Et tu oses expliquer ce qui est bien ou non…
Bref avant de juger les outils, ou de dire " bon tu me diras je fais du Java donc je suis pas à ça prêt " tu ferais mieux d'ouvrir quelques livres sur le langage et sur l'IDE pour ne pas passer pour un charlot. Tout ce dont tu as parlé est trivial et tes lacunes ne te permettent même pas de comprendre à quoi peut bien servir un IDE.
Ca fait un bail que personne que je ne connais n'a postulé chez eux. Mais tu sérais étonné du sérieux du recrutement dans les boîtes où tu as envie d'aller bosser, même les grosses. Si ton profil est un poil crédible en général tu as un retour et mini un screening téléphonique.
Après passer c'est une autre histoire. Premièrement le niveau est haut et pas forcément dans ton "vrai" métier. Coder au tableau, designer des solutions en 1h, les puzzles à la con et plaire aux interviewers c'est un sport à part entière. Deuxièment tu as forcément un taux de faux négatif élevé, qui est assumé.
Mais arriver à l'étape d'avoir ta chance, le taux est franchement bon et incomparable aux handicapés des RH de France.
Mince tu voudrais dire qu'il y a une raison pour laquelle en général on paie moulte billets d'avion et semaines d'hôtel aux gens en remote (ou aux équipes) pour pouvoir se voir ?
Et je rejoins groumly sur l'aspect minoritaire des gens vraiment exceptionnels. Sur ton volume de recrutement ca pèse pas lourd. Des très bons il y en a et il y en aura. Donc soit le mec est juste très rès loin devant les autres A players, soit il a grave d'XP dans le domaine dont tu as besoin et tu considères que ca vaut le coup. Et pour revenir au sujet de base, on parle de quelqu'un qui n'a jamais trouvé un boulot "correct", qui ne semble avoir aucune contribution, compétence ou connaissance hors du commun, et qui se demande même si il veut continuer l'info. Justifier le remote sur un profil comme ca j'ai un peu des doutes…
Sur un point personnel, remote ca veut aussi dire ne pas profiter pleinement de toute sorte de personnes excellentes. Perso c'est ce qui me pose le plus problème. J'aime bosser et discuter avec des gens bons. J'aime pairer. Je considère que le plus enrichissant ce sont les discussions dans le vide dans le bureau, au tableau, à la machine à café. J'aime écouter au détour d'un couloir ce qu'il se dit dans une autre équipe pour apprendre et parfois donner un avis. Tout seul dans ton coin tu râtes plein de trucs. Et si tu commences à ajouter des forts décallages horraires, alors ca ralenti aussi les discussions intra-équipe. Pas génant si les intéractions sont très limités, beaucoup plus pour la plupart des tâches.
[^] # Re: Ai-je bien compris ?
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 8. Dernière modification le 15 mai 2013 à 12:55.
Donc si on arrête d'utiliser pleins de mots pour ne rien dire. Ton machin c'est une matrice bi-dimensionnelle dont les valeurs sont des entiers…
Aller encore un effort et tu vas réussir à expliquer les deux contraintes que tu as dessus !
[^] # Re: Excellent !
Posté par ckyl . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 4.
Donc tu as des points de passage obligés à une côte donnée… Le routage est trivial en rando. L'échelle des distances est petite, le maillage du réseau est faible, tu n'enmagasines pas d'ennergie, les frotements sont toujours les mêmes et il faut que ca monte méchament pour que ca commence à faire une différence. Tu ne vas pas faire 2km de plus pour éviter une légère côte ca n'a pas de sens.
Bref ca peut éventuellement valoir le coup de faire quelques kilomètres de plus pour épargner quelques centaines de mettre de D+/-. Mais dans la vraie ce genre de config ca n'existe que peu et c'est trivial à détecter en regardant la carte.
Plutôt qu'un soft, pour ce genre d'activité j'ai envie de dire que c'est plus sur d'apprendre à réellement lire les cartes.
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 6.
Bha c'est un truc à la steckdenis… Ca n'empêche pas d'avoir des échanges intéressant et en ne cherchant par trop le pourquoi du comment de la question originale ;)
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Quel intérêt donc hormis t'écouter parler ? Si tu n'as rien ou ne veut rien montrer, il suffit de ne rien dire.
Poser des questions sur des micro-optimisations (soit dit au passage très certainement inutiles par ce que sur une workload réelle ce sont les caches miss qui vont rapidement te couter cher et le reste qui ne suivra pas) sans publier du code concret, le bench et la méthodologie c'est prendre son temps. Soit tu montres ton code, soit tu sors des exemples auto-contenus. Mais sans ca, c'est un peu pisser dans un violon.
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
La seule différente entre
clock_gettime(CLOCK_REALTIME)etgettimeofdayc'est la perte de précision entre letimespecqui est en nsec et letimevalqui est en msec et fais un:tv->tv_usec /= 1000;Faut faire pas mal gaffe en descendant à ces précisions car ca devient difficile de mesurer quelque chose.
Le coup du taskset est en effet une bonne idée pour les benchs mais aussi pour dispatcher manuellement le code métier. Le scheduler reste mauvais sur l'affinité, et c'est pas rare de gratter 10-30% de perf la dessus plutôt que laisser les threads se balader…
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4. Dernière modification le 14 mai 2013 à 19:03.
Le point que tu donnes on s'en balance dans un cas comme ca. On est en train de faire des benchs à vie courte !
Maintenant si tu regardes le code qui est exécuté pour
gettimeofday, ouclock_gettime, je ne vois des masses que je pourrais faire mieux en écrivant mon propre code sauf besoin extrêment spécifique qui mérite qu'on prenne le risque de faire n'importe quoi. Maintenant puisque tu insistes sur le monotonic, si je compare do_monotonic avec do_realtime je ne vois pas en quoi ca change quoi que ce soit pour notre problème actuel. La différence c'est juste un offset appliqué par update_vsyscall quand les valeurs de base devsyscall_gtod_datasont mises à jour.Rappelons que ces fonctions sont mappées dans la page
vdsopar le kernel dans l'espace utilisateur de chaque process et donc que le coût d'appel à ces syscall à exactement le même qu'a une fonction userspace normale.Je peux me tromper, je ne suis qu'un oeil naïf. Mais en réfléchissant au problème et à l'implémentation actuelle je ne vois pas de raison d'aller voir ailleurs.
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4. Dernière modification le 14 mai 2013 à 18:42.
Il y a une raison particulière part rapport à un
gettimeofdaymoderne qui s'occupe de gérer tout le bordel TSC/HPET pour pas cher avec une résolution exportée assez correcte ? On peut arriver aux limites de la résolution si on veut mesurer quelque chose d'extrêmement précis, mais là à priori il suffit de faire durer le bench le temps qu'il faut.[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par ckyl . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 10.
Idem. Trop de blabla et de moussage, pas assez de code.
[^] # Re: Non, mais ...
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 3.
Soit dit au passage, la Scaladoc a dépassé le maitre. Y'a pleins de petits détails à backporter dans la Javadoc
[^] # Re: Github+IRC
Posté par ckyl . En réponse au journal R.I.P CIA.vc , et maintenant quoi?. Évalué à 4. Dernière modification le 13 mai 2013 à 19:39.
J'en vois de moins en moins l'intêret. Fais ton taff. Au pire si ca dure longtemps, tu updates ta branche de référence de temps en temps pour voir les différences. Tu as exactement les mêmes informations et tu les as quand elles t'intéressent.
Avoir un truc à surveillé, ou tu peux louper des trucs, et qui interrompt ton travail n'apporte pas de plus value. Si je veux savoir si ca à changé il suffit de puller… De toute facon je devrais le faire. Il y avait un interet du temps de subversion, mais avec un VCS moderne je vois plus.
[^] # Re: Github+IRC
Posté par ckyl . En réponse au journal R.I.P CIA.vc , et maintenant quoi?. Évalué à 3.
Et si le mec commit pendant la nuit on retourne à la case départ.
Sur des petites fenêtre de temps de toute facon tu ne peux rien y faire et tu devras te tapper le merge, donc tu perds ton temps à te faire spamer en IM. Sur des "grandes" fenêtre de temps et pour suivre ce qu'il se passe avoir une UX plus adaptée et moins temps réel me semble un meilleur choix.
Strictement parlant tu as raison.
Pratiquement tu configures ton flux pour qu'il contienne suffisement d'entrées pour que tu puisses le considérer comme tel même avec un client basique (pas besoin de 5 ans d'historique).
[^] # Re: Github+IRC
Posté par ckyl . En réponse au journal R.I.P CIA.vc , et maintenant quoi?. Évalué à 4.
Moi je crois que si tu veux suivre un flux de donnée, utiliser un truc stateless comme IRC est étrange. Si t'es pas connecté tu perds les notifications, ca veut dire qu'elle n'étaient pas si importantes que ca…
Du coup soit j'ai une raison d'avoir les notifications et j'utilise un support adapté (code review, mail, flux RSS ou autre). Soit j'ai pas de raison, et il me suffit de regarder l'historique de mon DVCS .
[^] # Re: Super workflow
Posté par ckyl . En réponse au journal Un debugger est-il indispensable ?. Évalué à 2.
Si tu regardes le genre de code que tu écris dans les tests, c'est typiquement le genre de chose que tu veux pas écrire en C par ce que tu vas passer ton temps à réécrire des centaines de méthodes qui sont built-in ou qui demandent 3 lignes de glue dans beaucoup d'autre environnements.
De l'autre côté, effectivement plus tu rajoutes de couches plus c'est le bordel.
C'était tout le sens de ma question, savoir où en était le compromis actuellement et qu'elles étaient les pistes et techniques qui avaient été, ou sont, explorées.
[^] # Re: Super workflow
Posté par ckyl . En réponse au journal Un debugger est-il indispensable ?. Évalué à 2.
Pas réellement fais de C depuis presque 10 ans, mais y'a pas un framework de test pour C qui s'est développé ? Voir dans un langage de plus haut niveau histoire de pouvoir coder rapidement et pas avoir des millions de lignes de tests.
On retrouve ca dans certains langages. Par exemple écrire les tests en Groovy pour tester du Java. Vu la facilité de faire des bindings C je serais étonné que personne n'ait poussé le truc.
# Interet
Posté par ckyl . En réponse au journal Du bidouillage sur un ancien EEEpc 1005pe (solaire ?). Évalué à 3.
Je vois pas à quoi ca sert. Par ce que:
C'était pour le coté terre à terre et rationnel.
[^] # Re: Les IDE, c’est chiant
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 2.
J'imagine qu'il suffit de lire la doc
Tu peux aussi te sortir les doigts. Si tu bloques la dessus avec des arguments comme ca, tu peux te réorienter tant qu'il est encore temps.
Ca se combine pas très bien avec le fait que tu restes comme un gros bênet ne faisant même pas un
man javacmais qui préfère ecrire 4 messages pour bien étaler son avis.Dans ce cas consulte un livre fait de bois mort.
C'est un poil gavant à la longue les boulets qui trollent dans le vide.
Bien tes arguments montre que tu as fait un hello world
Non ca montre que tu restes dans ta crasse. L'IDE n'y est pour rien. Si il n'était pas la, tu ferais quoi ? Tu resterais assis à attendre ? La démarche pour javac et jar n'est pas plus compliquée, et même beaucoup plus simple que gcc & co. L'IDE te facilite la vie, ne pas apprendre ce que tu dois apprendre, c'est toi qui le décide. Tout comme mal l'utiliser.
[^] # Re: IDE python
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 5.
Déconnes pas les mecs de Jetbrains se sont fait chier pour collecter les types à runtime pour pouvoir proposer une completion correcte. Tu vas les faire se pendre…
http://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-type-inference-in-pycharm-2-7/
Cela dit rigolo c'est tendance de vouloir faire un faux typage statique dans les langages dynamique (python, js) après s'être rendu compte qu'on devait de toute facon spécifier les types dans la documentation… C'est cool tu spécifies tout mais ca ne sert à rien !
[^] # Re: On peut toujours creuser un trou à mains nues...
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 5.
Tu ne comprends visiblement pas le problème qui n'est pas une histoire de
.mais qu'il faut avoir compilé le code pour être capable de déterminer le type d'une variable.Quel est le type de
foo.createSession()? Comment gères tu le polymorphisme entrefoo.createSession(varInt)etfoo.createSession(varLong)? Comment gères l'héritage pour aller chercher la doc d'une méthode non surchargée ?Et oui encore une fois le boulot d'un IDE c'est de manipuler l'AST (et souvent un AST complétement invalide vu qu'en cours de dev).
Ce ne sont que les problèmes les plus triviaux. Après tu as aussi ceux sur l'environement. Comment vas tu automatiquement chercher la bonne doc pour toutes tes deps (il faut parser le pom et aller tapper dans le repo m2 local).
[^] # Re: Pas si on est un grand ponte apparemment.
Posté par ckyl . En réponse au journal Un debugger est-il indispensable ?. Évalué à 4.
Dans tout les cas ton affirmation est mauvaise. Ce que tu dis implique que si tu utilises la programmtion par contrat alors tu n'as plus de bug. Ca serait la nouvelle du siècle…
Maintenant dès que ton code commence à faire quelque chose, des erreurs dans la logique métier, dans l'implémentation, dans la spécification des méthodes, des invariants, dans l'utilisation de code tierce, des corruptions, des erreurs provoquées par la compatibilité ca va arriver.
Une exception qui remonte par contre en général c'est juste un travail de porc ou la fin du monde.
[^] # Re: Pas si on est un grand ponte apparemment.
Posté par ckyl . En réponse au journal Un debugger est-il indispensable ?. Évalué à 4.
Pourquoi est ce que ce genre de bug serait plus rare qu'une exception qui remonte ? Au contraire un exception qui remonte signale très souvent une erreur grossière.
[^] # Re: il y a le bon paresseux et le mauvais paresseux
Posté par ckyl . En réponse au journal Un debugger est-il indispensable ?. Évalué à 5.
Exactement. Si tu sais te servir de ton IDE et de ton debuger, tu vas plus vite à mettre un point d'arret et inspecter les variables qu'à écrire ton printf avec toutes les infos utiles dedans… Et quand tu te rends compte qu'il manque un truc dans ton printf bha tu as pas à recommencer.
[^] # Re: Les IDE, c’est chiant
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 7.
Franchement le problème c'est toi et uniquement toi, pas l'IDE. Tes questions montrent que tu ne maitrises même pas les concepts que l'on doit apprendre vers le deuxième cours de Java. Et tu oses expliquer ce qui est bien ou non…
Bref avant de juger les outils, ou de dire " bon tu me diras je fais du Java donc je suis pas à ça prêt " tu ferais mieux d'ouvrir quelques livres sur le langage et sur l'IDE pour ne pas passer pour un charlot. Tout ce dont tu as parlé est trivial et tes lacunes ne te permettent même pas de comprendre à quoi peut bien servir un IDE.
[^] # Re: On peut toujours creuser un trou à mains nues...
Posté par ckyl . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 2.
On peut rajouter entre autre:
Les mans c'est très bien pour le système ou la lib C mais pour le reste ce n'est pas adapté
Une fois que tu as résolu le problème des mans, on peut réfléchir à comment on accède facilement au code tiers, ce qui est dispo dans tout éditeur.
[^] # Re: On engage
Posté par ckyl . En réponse au journal Et si on faisait un "Who's hiring" à la linuxFr ?. Évalué à 7.
Ca fait un bail que personne que je ne connais n'a postulé chez eux. Mais tu sérais étonné du sérieux du recrutement dans les boîtes où tu as envie d'aller bosser, même les grosses. Si ton profil est un poil crédible en général tu as un retour et mini un screening téléphonique.
Après passer c'est une autre histoire. Premièrement le niveau est haut et pas forcément dans ton "vrai" métier. Coder au tableau, designer des solutions en 1h, les puzzles à la con et plaire aux interviewers c'est un sport à part entière. Deuxièment tu as forcément un taux de faux négatif élevé, qui est assumé.
Mais arriver à l'étape d'avoir ta chance, le taux est franchement bon et incomparable aux handicapés des RH de France.
[^] # Re: Demenage aux USA
Posté par ckyl . En réponse au journal [HS] Développeur un peu perdu… ou pas… Que faire maintenant ? Changer de vie ?. Évalué à 5.
Mince tu voudrais dire qu'il y a une raison pour laquelle en général on paie moulte billets d'avion et semaines d'hôtel aux gens en remote (ou aux équipes) pour pouvoir se voir ?
Et je rejoins groumly sur l'aspect minoritaire des gens vraiment exceptionnels. Sur ton volume de recrutement ca pèse pas lourd. Des très bons il y en a et il y en aura. Donc soit le mec est juste très rès loin devant les autres A players, soit il a grave d'XP dans le domaine dont tu as besoin et tu considères que ca vaut le coup. Et pour revenir au sujet de base, on parle de quelqu'un qui n'a jamais trouvé un boulot "correct", qui ne semble avoir aucune contribution, compétence ou connaissance hors du commun, et qui se demande même si il veut continuer l'info. Justifier le remote sur un profil comme ca j'ai un peu des doutes…
Sur un point personnel, remote ca veut aussi dire ne pas profiter pleinement de toute sorte de personnes excellentes. Perso c'est ce qui me pose le plus problème. J'aime bosser et discuter avec des gens bons. J'aime pairer. Je considère que le plus enrichissant ce sont les discussions dans le vide dans le bureau, au tableau, à la machine à café. J'aime écouter au détour d'un couloir ce qu'il se dit dans une autre équipe pour apprendre et parfois donner un avis. Tout seul dans ton coin tu râtes plein de trucs. Et si tu commences à ajouter des forts décallages horraires, alors ca ralenti aussi les discussions intra-équipe. Pas génant si les intéractions sont très limités, beaucoup plus pour la plupart des tâches.