Bastes a écrit 403 commentaires

Je n'argumente plus avec pbpg, ça ne sert pas à grand chose puisqu'il a forcément raison.

C'est que je t'ai bien observé avant de te connaître...

Il y a un prix décerné aux auteurs d'acronymes récursifs ?

En même temps, sur un CD à 20 €, il y a 20% de TVA, soit 4 € quand même.

Dans un état démocratique, la culture ça devrait être comme la nourriture : taxé au minimum (déjà que la TVA c'est l'impôt le plus injuste de notre système...). Donner un droit de vote égal à tous les citoyens c'est noble, mais si on les abrutis en même temps c'est un peu comme donner un révolver chargé à un singe. Si tu as de la chance, il va s'en lasser très vite, sinon...

Ca dépend, est-ce qu'un système d'exploitation peut être considéré comme un IDE ?...

Eh oui, la bureaucratie, les états n'en ont pas le monopole, et l'inefficacité non plus.

Enfin, ça dépend ce qu'on appelle inefficace, si l'objectif est d'en foutre plein les fouilles à un petit nombre, alors le modèle économique ultra-libéral est très bien fait. Si bien fait qu'il permet aux gagnants de provoquer des crises, les faire payer par la collectivité sans rien donner en échange, même pas de vagues promesses de mieux se conduire, et de continuer à dire du mal de l'état et des services publiques.

Ah mais c'est une bonne nouvelle ça. Ca veut dire que tu vas pouvoir faire passer ta propagande sur ton propre prototype à base de C#/.Net où tu seras à l'abris de toutes les personnes qui ne pensent pas comme toi, c'est formidable.

Et puis, il y aurait un petit avantage secondaire, tu n'aurais pas à déployer toute cette belle énergie juste pour pourrir les discussions où tu prends part.

C'est pour ça que je me suis cassé de ma dernière SSII. Je m'y plaisait niveau ambiance, collègues, mais j'arrivais pas à supporter de me voir devenir "that bad a coder" à cause de la pression du groupe et de la bureaucratie. Je n'avais pas envie de rester le mec qui "n'en est pas à ça près" et qui faisait "la merde qu'on lui demande".

Après chacun ses envies, il y en a qui tolèrent très bien ça s'il y a un gros chèque à la fin du mois...

Ouais. Mais : en SSII, je n'ai jamais rencontré de manager / chef d'équipe / chef d'entreprise assez éclairé ou assez courageux pour prendre sur lui d'autoriser l'équipe à travailler par prototypage. Ils préfèrent passer beaucoup de temps sur des specs abstraites et mal comprises par le client, mais qui génèrent une paperasse bien indigeste qui "prouve" qu'ils ont bien fait le boulot, et donne l'impression au client qu'il y aura beaucoup de temps à passer sur le code pour que ça fonctionne, alors que l'approche par prototype ça donne souvent ça :
"Ah, ben vous l'avez déjà presque terminé en fait, c'est bien, vous avez un peu vu gros pour le devis initial mais me voilà rassuré, vous allez nous développer ça moitié prix *wink*wink* *nudge*nudge*".

Pour que l'utilisation du prototypage fonctionne, il faut alors que les deux équipes client et développeur soient proches pour discuter du bidule fréquemment (sinon c'est difficile de prototyper correctement sans se viander en cours) et pour que le client réalise que le prototype ne peut pas être le machin final ni servir directement de squelette ou de base et réduir le temps de travail prévu (cf plus haut).

Ou alors, si ça bloque, il reste la technique de bâtard (mais elle a déjà fonctionnée) :
- on fait un prototype "dans son garage" sans en avertir le client
- on fait rapidement une spec. fonctionnelle bourrée de captures d'écran du prototype, et on dit que c'est juste une maquette
- on laisse le client faire "ouaou" à la réunion de validation, et on est quand même mieux préparé pour mettre en production

...Mais bon, il va falloir encore en mettre quelques-uns derrière (arrêter de crypter le firmware du matos par exemple).

Mais quand même un bon petit pas.

Le problème avec les buzzwords, c'est qu'il y a une manière perverse de les employer non pas pour populariser et répandre les idées qu'ils désignent, mais comme argument conclusif de discussion pour convaincre un décideur ou un groupe d'adhérer à quelque chose de tout à fait différent. Par exemple :

"Mes chers amis, en tant que chef de projet j'ai une bonne nouvelle : Nous allons pratiquer la nouvelle méthode Agile de développement.

Je n'ai pas besoin de vous expliquer Agile, il y a la wikipedia pour ça.

Bien entendu, dans un premier temps et pour respecter les deadlines, nous allons nous contenter de certaines pratiques et exclure les choses qui font perdre du temps inutilement comme le codage par pair (pas besoin de mettre 2 personnes sur un même code) et les tests automatisés (on ne va pas perdre du temps à installer et écrire une suite de test, je vous fais confiance pour faire du bon code qui marche du premier coup n'est-ce pas ?) et plutôt que de faire du refactoring, on va bien concevoir notre architecture de classe dès les début pour prévoir tous les cas.

Oh, et aussi, toutes les communications avec le client passent par moi, et le cahier des charge, les specs fonctionnelles et les specs techniques ont été établies préalablement par un cabinet de consultant.

Messieurs, au travail."

Ben va pas falloir bosser en SSII alors...

Après avoir travaillé dans plusieurs SSII différents, je ne trouve pas ça si foutaisite que ça. Je trouve même que c'est très proche de la réalité par certains aspects.

Oh que je suis content de ne plus être en SSII...

C'est pas que c'est presque ça, c'est que c'est tout à fait ça. Et c'est pas tellement une question de Java, j'ai vu des trucs pire en SSII en PHP (ok, pas codé par des experts PHP mais plutôt des dérivants Java ou carrément des pas codeux). C'est plutôt le format SSII qui mène à ça en fait, même s'il y a moyen de faire des trucs efficacement en SSII, la bureaucratie plombe tout et tire vers le bas niveau outils :
- tu dois utiliser windows parce que sinon tes petits camarades te regardent d'un drôle d'air
- tu dois utiliser ms office parce que sinon ton chef de projet n'aime pas que tu blaste involontairement ses outils avancé de productivisation positronique qui lui gagnent le temps qu'il perd à les utiliser
- comme tout le monde est sous Eclipse on va utiliser SVN plutôt que GIT pour gérer les versions même si c'est moins bien
- le temps qui devrait être alloué à la rédaction de tests est offert en cadeau au client, mais on pressurise l'équipe pour faire le travail dans le temps vendu, donc pas de tests unitaires

"Bureaucracy expands to meet the needs of the expanding bureaucracy." Oscar Wilde
Quand on en est là, ça fait ça que le projet soit en Java, en PHP, en Ruby on Rails ou en C, ça sera la même chose partout. Mais c'est vrai que Java facilite quand même beaucoup l'arrivée à ce stade au sein même des équipes de développement.

En même temps, ça va coïncider pile poil avec la sortie d'IE9...

Parce que Ruby on Rails c'est :
- plus beau
- plus pratique
- plus maintenable
- plus orienté-objet et comportement

Alors que PHP c'est comme le côté obscur, c'est juste plus "rapide" et plus "séduisant".

Ah, non, mince, Ruby est aussi plus rapide et plus séduisant.

Lefebvre c'est pas exactement le type que je considèrerai le mieux élevé question économie numérique. Pour rappel, c'est le monsieur qui défend avec beaucoup de finesse et de nuances un internet tout plein de libertés :
http://www.marianne2.fr/Frederic-Lefebvre-violeurs,-drogues,(...)

Et comme je te le redis, s'il faut qu'il arrête de poster pour qu'il arrête d'insulter les gens, ça me va. Et dans tous les cas, si tu peux arrêter de le provoquer inutilement et encore moins poliment que lui, ça nous fait deux malpolis d'arrêtés pour le prix d'un.

Moi je l'appelle Poly, mais en même temps on est intimes...

Quelles que soient ses raisons pour avoir arrêté d'insulter tout le monde, merci d'arrêter de l'insulter.

On ne va pas demander aux gens d'être polis et être soi-même impoli quand même.

Bon, un peu de calme.

Ici il n'y a pas de freetard ni de gaspillage de foutre. Notre ami thedude se l'est fermé, merci de ne pas essayer de le relancer dans l'insulte.

Disons, le jour où tu dois changer de SGBD, tu es très content d'avoir une couche d'abstraction blindée.

Par exemple : le jour où tu passe de la version de dev sous SQLite (pourquoi faire de la configuration et de la sécurité en monoposte ?) vers la version de pré-prod ou prod.

Packaging d'Ubuntu, ça ne doit pas être à jour j'ai le même bug. A poster sur le bug-tracker.

Exactement. Le JS, il vaut mieux le donner à la personne la plus propre et la plus rigoureuse, certainement pas au petit génie brouillon qui déborde d'idées mais laisse des trucs crados sur son passage. Les trucs crados, on peut "facilement" faire passer dessus un expert pour corriger en métier ou en contrôleur, mais en JS / CSS / HTML c'est très difficile une fois que l'appli à a peine de bouteille.

Un intégrateur, c'est quelqu'un qui prends un design et qui le traduit en code. C'est donc un codeur, pas juste un gars qui sait cliquer sur une fenêtre dreamweaver. Et oui, on est d'accord, l'intégration mérite d'être une spécialité à elle toute seule, mais un bon codeur avec un bon intégrateur derrière peut faire du bon boulot.

Par contre, pas d'accord, pour être un bon intégrateur il faut avoir des bonnes notions de dynamique, donc de PHP (ou Ruby, ou Python, ou Pearl, ou Java, ou quelque langage server-side que ce soit). En plus il vaut mieux à l'heure actuelle être à l'aise en JavaScript et avec le(s) framework(s) utilisé(s). Ensuite, le HTML c'est pas du code mais c'est un langage quand même, et s'il y a du JS derrière il vaut mieux qu'il soit clean. Enfin, les CSS c'est aussi un langage, qui a des subtilités chiantes et qui est intérprété différemment sur les différents navigateurs, donc complexe, surtout avec du JS.

Ok, un intégrateur doit aussi savoir faire des bidouilles avec les images et même avec du flash (beurk) mais c'est marginal. Ce qu'on lui demande, c'est de faire en sorte que les vues marchent, restent le plus propre possible, et présentent bien. Dans ces 3 critères, les deux premiers sont très majoritairement du code, alors que le troisième seulement est de la présentation (et si les 2 premiers sont pourris, le 3° sera beaucoup plus difficile).

Donc, pour être un bon intégrateur il faut être un bon codeur, mais pas forcément en C ou en Java je te l'accorde.