totof2000 a écrit 9656 commentaires

=> les chiottes

Pour expliquer mon illustration : l'ingénieur en batiment n'a pas forcément à se soucier du "comment faire" : il a plus à se soucier de ce qu'il faut faire (tout en ayant des notions du comment faire bien sur). Ce n'est pas lui qui va aller faire le travail sur le terrain. Si on appliquait un peu cette façon de faire à l'informatique, je pense que certaines aberrations disparaitraient.

et puis ? télécharger de la musiques, c'est comme de voler une baguette de pain dans une boulangerie ?
calquer des raisonnements du monde physique dans un domaine intellectuel, ça marche pas bien.
c'est dingue. Vous êtes comiques. C'est vous qui avez à l'idée qu'un maçon n'a pas à réfléchir. Pas moi. Je voulais juste signaler que spécifier et coder étaient 2 métiers différents (avec je vous l'accorde une limite difficile parfois à établir).

Mon boulot consiste à m'appuyer sur des compétences techniques pour imaginer et implémenter des solutions aussi simples que possibles à des problèmes complexes que je rencontre pour la première fois. Après, t'appelles ça comme tu veux :)

Je pense que c'est surtout un manque de confiance (parfois justifié, parfois non) vis à vis des gens qui savent. Parce que toi, tu rencontres des problèmes pour la première fois, mais les codeurs ont peut être déjà rencontrés le même type de problème.

Dans mon expérience, la plupart du temps, les problématiques d'implémentation viennent aussi nourrir la réflexion. Si je ne devais qu'écrire des documents d'architecture ou des spécs techniques sans toucher une machine, les résultats seraient moins satisfaisants.
... ou pas, tout dépend de la confiance que tu as ou peux avoir vis à vis des équipes de codeurs.
Si tu arrives à écrire en amont tout la documentation technique décrivant une solution adaptée aux problèmes qu'on te présente, chapeau bas, je n'en suis pas encore là.
(mais c'est pas non plus dans cette direction que je vais :)
Ben si tu arrives à spécifier dans les grandes lignes la solution de ton problème et que tu la présentes à un codeur, il pourra te dire ce qui marche ou ne marche pas dans ta solution. Toi si tu n'as pas la même expérience du codage tu ne pourras pas forcément fournir une solution des plus adaptées au problème mais juste un truc qui marche.

Je pense que vous n'avez pas compris le sens de ma comparaison avec le maçon et l'ingénieur en batiment (ou alors je l'ai mal exprimée).

Si, dans cette opposition codeur/ingénieur, tu considères que le rôle du codeur c'est cracher du code sans réfléchir (et c'est ce que je comprends de ce que tu dis), alors il y a un problème, les tâches où on ne réfléchit pas, ce n'est pas pour l'homme.

Tu déformes mes propos (ou je n'ai pas été clair).
Je pense que l'ingénieur doit faire son boulot d'ingénieur et spécifier ce qu'il veut. Charge ensuite aui codeur de coder les spécifications. Ca ne veut pas dire ne pas réfléchir, ca veut juste dire deux réflexions différentes. Si l'ingénieur a besoin de mettre son nez dans le code c'est parce qu'il n'a pas confiance en son développeur.

Après, dire qu'un maçon pose des briques sans réfléchir .... c'est pas moi qui l'a dit. être maçon c'est un métier qui nécessite un minimum de réflexion, et ce n'est pas moi qui ai comparé le maçon à un compilateur.

Séparer les rôles, c'est aussi diluer les responsabilités et ça ne favorise pas l'investissement intellectuel dans les projets.

Tu vois beaucoup d'ingénieurs dans le batiment aller poser des briques ou couler du béton toi ? Chacun son travail.

En tant qu'ingénieur, ça me gaverait bien de pas pouvoir mettre les doigts dans le code.
Peut-être que tu t'es trompé de métier ? Ou alors tu as le titre d'ingénieur mais tu n'as pas le boulot d'un ingénieur (et on en revient à ce que je disais plus haut).

C'est vrai que la semaine dernière, deux hors, ça faisait froid dans le dos, mais trois, c'est inadmissible.

(je me demande si je dois être fier ou avoir honte).

Java est un langage objet, certes... Mais c'est pas pour autant qu'on voit partout fleurir du code propre, bien conçu, basé sur des design patterns éprouvés, ...
Ca aussi ça me fait rire : les design patterns : quand c'est bien utilisé, c'est efficace, par contre il y a des developpeurs qui veulent à tout prix caser leur design pattern là ou ça n'est pas adapté.

Sinon je suis d'avis que quand on rendra aux ingénieurs l'ingénierie, et aux codeurs le code, chacun fera son travail correctement.

En leur donnant une bonne fessée, et au lit sans dessert ?

J'ai eu un pb lorsque j'ai acheté de la RA chez eux : barrettes défectueuses. J'ai juste eu à leur renvoyer, et ils m'ont échangé les barrettes, avec bon d'achat offert pour les frais de port que j'ai du payer pour leur renvoyer les barrettes défectueuses

Tu as bien lu ce que j'ai écrit ? Je ne parle pas de logiciels microsoft, mais toute la ribambelle de trucs qui viennent avec une machine préinstallée (antivirus, spywares, pubs qui apparaissent régulièrement dans le navigateurs grâce à des modules Internett Explorer qui viennent de je ne sais ou et qu'il est difficile de désinstaller, etc ...). Rien à voir avec Microsoft, a moins que Microsoft paye pour faire installer des versions "à l'essai" de works par exemple.

Autre possibilité : les accords avec les softs pourris "à l'essai" qui plombent la machine à l'achat. LDLC ou Fujitsu ont peut-être des accords moins avantageux (il ne faut pas oublier que ces logiciels permettent de baisser le cout des machines).

j'ai donc verrouillé au max mon compte

... que tu crois.

Tu n'es pas à l'abri d'un changement de conditions d'utilisations, ou d'une "évolution technologique" qui rendra à néant tout tes efforts pour sécuriser ton compte.

Tu as supprimé un fichier qui est encore utilisé par un autre processus. Tant que le processus en question n'aura pas libéré le fichier, l'espace sera toujours pris.

Ce n'est peut-être pas nano qui pose problème mais le process qui utilise ce fichier log.

Pour info, si tu veux vider un fichier de logs utilisé par un autre processs, après avoir sauvegardé ce qui t'intéresse il vaut mieux faire :
> fichier_log.log

T'as raison, en ce moment c'est plutôt la saison de la dinde au whisky.

C'est à l'expéditur de choisir s'il veu utiliser une enveloppe ou une carte postale. Pas à la poste.

Et d'ailleurs, pour la 2.0 du iAïce, Apple promet de réduire l'épaisseur du bouzin et recherche les fournisseurs de crèmes glacées aptes à les fournir dans un format adapté aux 7.3 mm de la machine...

De la glace en poudre ?

Je ne dis pas que c'est une mauvaise idée, je dis juste qu'il faut le faire avec prudence.

A chaque fois que j'entend les admins Debian me dre que leur distrib est géniale, je suis toujours tenté de m'y remettre ..... jusqu'à ce que je (re)découvre ce genre de truc indigeste qui me font courir très vite le plus loin possible.

Il ne faut jamais désactivr le swap à la légère. Bien souvent racconter ce genre de cose sans avoir examiné de près ce que fait la machine est risqué.

Avant de désactiver le swap, je ferais des mesures de perf, et je le réduirais petit à petit.

C'est la que le truc s'emballe et te commande 3 tonnes de yaourt parce que le process de commande tourne en boucle ... Ca serait amusant :)

c'est triste ton avis sur le répétitif de ces avis tristes sur un certain comique.

C'est super, on pourra afficher ses recettes directement dans le frigo et les lire facilement.
Moi je préfère la lire hors du frigo. Je trouve quand même ça plus facile (pourquoi entrer dans le frigo pour lire une recette, sachant qu'une fois la porte fermée, la lumière s'éteint ? )

Pingoouin dans le frigo, l'été sera chaud.

C'est pas Moode mais Moose. Glissage de doigtss (le d est à côté du s sur mon clavier).

Sinon, tu es en train de me dire que tu préfères les langages qui ont plusieurs paradigmes pour faire de l'objet en fonction de ce que tu es en train de faire ?
Non, je dis simplement que pour faire de l'objet, et que de l'objet je préfère utiliser un langage qui fait ça nativement. Après si moose apporte quelque chose en plus de l'objet et que ça correspond à mon besoin, je veux bien, mais si ce n'est que pour faire de l'objet, je préfère m'en passer (car, par exemple, ça risque d'apporter un tas de choses qui ne servent à rien et qui potentiellement pourraient contenir des failles).

définir de façon précise ce que tu veux faire, avant de t'intéresser au comment.

Déjà premier point : quoi. Ensuite, quel matériel. Une fois que tu as défini ça le reste ira tout seul.