quoi comme formation cloud ? surtout en java, je suis super intéressé par le sujet.

hohun a écrit
Pourquoi tu prends sur ton weekend alors que cest de leur faute ?

Le client a toujours raison... (même quand il a tort...)

Et tu peux pas prétexter un truc ? Genre réunion de famille ou un truc comme ça ?

1) Je prends sur mon week-end, pour pas me retrouver comme un con à devoir improviser pendant 1 semaine devant un groupe de 12 personnes... c'est déjà assez compliqué comme ça!

2) Formation "cloud" financée par l'agence Pôle Emploi du coin, en java (ça c'est moi qui ait choisit, et c'est parce que c'est de loin le langage que je maîtrise le mieux). Mon objectif: leur faire concevoir et développer en java une application en mode Saas de pilotage d'instances virtuelles (gérées sur 3 serveurs proxmox). L'objectif de Paul (Emploi): leur faire retrouver du boulot, et le cloud c'est à la mode. L'objectif de mon employeur: gagner du pognon. Pédagogiquement, les étapes vont être: remettre tout le monde à niveau en Java, puis donner des bases d'architecture logicielle standard (UML, Design Patterns, archi 2-tiers, 3-tiers, n-tiers), ensuite les web-services et tout le toutim, puis appliquer tout ça dans un projet concret pour pas rester au stade de la théorie, d'abord en local, avec un serveur de persistence JPA sur une base NoSQL (j'hésite encore, sans doute MongoDB), un serveur d'application en Java (probablement Wildfly, le dernier JBoss, puisqu'apparement Glassfish ne va plus être maintenu). Ensuite on va passer à l'aspect Iaas avec introduction des serveurs Proxmox, virtualisation d'instances, pilotage des serveurs via API HTTP... Et y a encore un peu de flou pour la fin, donc je te dirais quand je saurais. Mais d'avance: non, les supports de cours ne sont pas dispos, il y a propriété intellectuelle de mon employeur

3) Hélas oui, surtout que si des gens quittes la formation, ma rémunération diminue d'autant (même si le travail à fournir est le même pour moi et que je suis pas responsable des erreurs de casting). Même chose s'ils trouvent du boulot avant la fin d'ailleurs... oui, c'est encore plus bête: je suis censé les aider à trouver du taf, mais s'ils en trouvent "trop" vite, je perds de l'argent. Merci Paul, tu sais toujours trouver les mots pour motiver tout le monde.

4) Je peux, mais comme dit au 1, ce sera de toutes façons à moi d'assumer face à mon "publique" lundi matin.

Monde de merde...

Ce qui me frappe le plus, c'est qu'on pense vraiment en faire des experts opérationnels en une semaine sur un truc aussi complexe.

Un truc pareil, soit c'est 4 à 6 mois de formation et là tu trouves du taf direct après, soit c'est juste cramer de l'argent (public) pour rien si ce n'est donner le formulaire B358 au gars pour qu'il puisse continuer à toucher ses droits.

« avec un serveur de persistence JPA sur une base NoSQL (j'hésite encore, sans doute MongoDB), un serveur d'application en Java (probablement Wildfly, le dernier JBoss, puisqu'apparement Glassfish ne va plus être maintenu). »

Perso j'aurais proposé Spring-boot + spring-data + MongoDB : tu dois pouvoir être près à déployer un service REST en une journée pour un type qui connait déjà Java.

Tout à fait, je me demande même s'il n'y a pas plus optimal, genre un Bubble-boot + PND Roots flDB v9 + Virtual Krisprolls.
En faisant ça, non seulement tu déploies l'intégralité de tes services HUMPH-beta, mais en plus tu peux monitorer via EshkimoZomg (la version flashée en 2.5.6.99, les plus récentes foutent la merde)

Hey, t'as pas un Uplay à faire marcher toi ? ou un bug ACU à corriger.

Donc en gros ta mission cest de faire de mecs qui ont autant de compétences en prog que moi des admins web?

Change de taf.

la terminologie est devops cloud. 1/3 dev, 1/3 installation et déploiement, 1/3 support. enfin en terme de travail c'est plutôt 50%, 50% et 50%.

Akshell a écrit
enfin en terme de travail c'est plutôt 50%, 50% et 50%.

Ha, toi non plus on ne te paye pas les heures supp' ?

kaplan a écrit

Akshell a écrit
enfin en terme de travail c'est plutôt 50%, 50% et 50%.

Ha, toi non plus on ne te paye pas les heures supp' ?

SAI TRAVAILLAIENT PLUS POUR GAGNAIENT PLUSSE OKAIENT ?

- Nicolu Sarkuzo

Ca me gave les mecs qui ramènent leur ordinateur portable le matin dans le RER A pour taffer genre je suis concentré tavu. J'aimerai leur faire bouffer.

Dario98 a écrit
Ca me gave les mecs qui ramènent leur ordinateur portable le matin dans le RER A pour taffer genre je suis concentré tavu. J'aimerai leur faire bouffer.

/cache sa tablette...

Dario98 a écrit
Ca me gave les mecs qui ramènent leur ordinateur portable le matin dans le RER A pour taffer genre je suis concentré tavu. J'aimerai leur faire bouffer.

Ouais ben heureusement qu'IL YA ENCOIRE DES VRAIS FRANCAIS QUI TRAVAILLENT PÄS COME CES FENEANTS AUX 35 H SARKOZY VITE /§

Ça m'énerve…quand tu trouves un appart' en Espagne, mais que tu ne peux pas obtenir de compte bancaire en Espagne parce que tu n'as pas de travail en Espagne. Du coup je peux peux ni payer mes charges, ni contracter Internet. LOL.
Ah et mon statut de travailleur indépendent est absolument légal, il y a une putain de convention entre la France et l'Espagne à ce sujet. Mais non, BANQUES LOL. Ces fils de putes créent des crises internationales et sont pas foutues de connaître la loi.

Summon Eric Cantona.

Ya pas un banquier ici, que je le e-tabasse pour la forme ?

Il faut que tu en parles à Gad Elmaleh

et ce genre de truc ça marcherait pas ? url : http://www.lepetitjournal.com/barcelone/actu-barcelone/87691-credit-mutuel-cic-associe-a-banco-popular-la-banque-francaise-sinstalle-en-espagne.html
url : https://www.cic-iberbanco.com/fr/index.html

Je vais voir, mais ils n'ont que des agences en France (???)

edit : ahah ok, faut avoir un compte CIC en France pour ensuite pouvoir créer un compte en Espagne.

Le meilleur de la surbureaucratie des deux pays, enfin bon merci quand même.

Dernière modification le 02/12/14 à 14:42 par hohun

Gingembre a écrit
Ce qui me frappe le plus, c'est qu'on pense vraiment en faire des experts opérationnels en une semaine sur un truc aussi complexe.

Un truc pareil, soit c'est 4 à 6 mois de formation et là tu trouves du taf direct après, soit c'est juste cramer de l'argent (public) pour rien si ce n'est donner le formulaire B358 au gars pour qu'il puisse continuer à toucher ses droits.

Ah non mais la subtilité, c'est que la formation dure pas une seule semaine hein! Ca va durer presque 2 mois, suivi d'un stage d'un mois. Mais par habitude (grosse variation de rythme et de niveau de compréhension d'un groupe à l'autre) je prépare pas plus d'une semaine de slide à l'avance. Mais même comme ça, je vois pas comment je vais transformer des putains d'ex-chefs de projets et ex-directeurs de projet de mes couilles en experts Cloud, alors qu'ils sont pas FOUTUS DE COMPRENDRE CE QUE C'EST QUE LE PUTAIN DE POLYMORPHISME EN 2H D'EXPLICATIONS!!! Et ils leurs aura fallu presque 3 heures pour écrire un programme en Java (mode console sous Eclipse hein) qui test si une chaîne tapée par l'utilisateur est un putain de palindrome...

Bordel, c'est mes slides d'intro ça, normalement. 60 slides "de bases" avec quelques petits exo simples et rigolo pour faire interlude et mettre en confiance avec Eclipse, que je passe habituellement en 1 seule journée... Là on vient péniblement de faire 30 slides en 2 jours!!!!!

Et en plus, 4 des ces connards ont eu le culot de venir me demander à la pause de midi "ça va être tout le long comme ça la formation? non mais je remets pas vos compétences en cause hein (ben voyons mon con, prends moi pour une buse), mais parce qu'à mon âge moi je vais pas redevenir codeur hein?", ben alors pourquoi tu t'es engagé ducon!! Putain, la première question qui leur a été posé à l'entretien de sélection (oui parce qu'en plus il y avait du monde intéressé, il y a eu des entretiens de sélection et tout) c'était "quel est votre niveau en tant que programmeur?" et il était REQUIS d'avoir des connaissances de bases en Programmation Objet... BORDEL DE MERDE, ils ont foutu quoi à pôle emploi là?

En fait, tout ce que cette bande de cons à entendu, c'est "cloud" et ils ont levé l'oreille (trop vieux pour lever la queue) comme de bons toutous en se disant "chouette, c'est marketing, c'est buzz, je vais (re-)devenir consultant/décideur grâce à ça".

Comme il est fort à propos, je me permet de citer le Dilbert du jour:
Le chef à son ingénieur: "- Veux-tu des critiques constructives?"
L'ingénieur (Dilbert) : "- Non, mais je serais ravi d'avoir des opinions sous-informéés à propos de choses que vous ne comprenez pas ."
Le chef (en pensée, retournant dans son bureau) : "- ça a gâché une bonne partie de mon amusement."

Ces blaireaux pensaient sans doute que j'allais faire d'eux ce chef qui prend des décisions critiques en ayant vaguement compris les principes sans jamais avoir pratiqué la technique elle-même.

Pour la fine bouche et l'esprit joyeux, je vous laisse imaginer leurs réactions, quand j'ai commencé à expliquer qu'on allait travailler sur un "projet" (comment? un vrai projet? non connard, un projet pédagogique, parce qu'on a que 2 mois, pas 3 ans et que vous êtes des buses... mais on va le concevoir? le planifier? non pouffiasse, on va le FAIRE. Programming, Mother Fucker, do you speak it? Je sais, je vois bien à vos visages déjà cireux et à vos yeux presque morts que la simple notion de FAIRE quelque chose vous-même vous donne la nausée, mais vous êtes officiellement des chômeurs, ça me donne le droit de vous traiter comme de la merde il va bien falloir y remédier) et qu'on allait travailler (et oui, vous n'êtes pas payés par pôle emploi juste pour regarder au tableau en hochant la tête doucement, je sais, ça vous change de vos habituelles réunions) en suivant les méthodes de travail Agile (en l'occurrence SCRUM) parce que le management à la papa des années 80 en mode "directeur de projet omniscient, tout puissant et tyrannique, seul détenteur de la vision d'ensemble, et ses vils esclaves codeurs suivant à la lettre les cahiers des charges qu'IL émet" avait produit plus d'échecs coûteux que des réussites flamboyantes... COMMEENNT? MAAAIIISSS PAS DU TOOUUUUUT!! Moi mes projets ont TOUS été des succès (ben alors pourquoi t'es là, hein blaireau?), et puis seul le chef de projet a besoin d'avoir une vision d'ensemble pour prendre des décisions éclairées, les "codeurs" (allez-y, rajoutez encore 2 tons de mépris dans votre tête en lisant ce mot, et vous serez encore un cran en dessous de la vérité) n'ont besoin que d'un de suivre le cahier des charges. YA MEIN FÜHRER, Nous z'allons zuivre fos ordres, fers la kloire et la fictoireuh!!!! La citation (sur le chef de projet ayant seul la vision, prenant des décisions éclairées, et les codeurs n'ayant comme seul besoin qu'un cahier des charges, avec moult mépris pour cette engeance inférieure dans la voix) est hélas véridique. J'ai du prendre sur moi pour pas la traiter de connasse devant tout le monde (oui, c'était une femme, ex-directrice de projet pour Bouygues [télécom? ceux qui ont trop bien su anticiper l'arrivée de Free sur le marché?], au chômage depuis 2 ans).

Ca va être long, très très long, pour eux peut-être, pour moi sans aucun doute... Je peux même pas les virer ou leur dire de se barrer (ni même souhaiter qu'ils le fassent), j'y perdrais de l'argent (plus que ce que je peux me permettre). Ca sent l'ulcère comme cadeau de Noël...

@Akshell: j'ai jamais touché à Spring, j'aime pas spécialement le XML (ça se débug pas, ça se compile pas, donc ça cause de problème de merde à résoudre), donc on va éviter. Mais merci de la proposition! :) Et ta définition de devops cloud est excellente, je la ressortirais (en fin de formation, si on va jusque là).

Haha ! M. Plant, vous avez toute ma compassion.

Je te donne pas trois jours avant d'en incendier un.

Ouais enfin Scrum, ça reste beaucoup de blabla pour pas grand chose, rien de plus qu'une dérive du management participatif, ouais y a plus de chef de projet, plus de codeurs, juste un scrum master qui fait de l'animation et chacun à le droit à la parole. ça va jusqu'à la première tache un peu merdique : - « hey elle est pas INVEST ta demande ! », - « Oui mais c'est moi qui décide ».
j'ai eu un entretien avec un chef de projet, pardon team leader, - « il n'y a pas de cador dans mon équipe » aka je suis le chef et tout le monde obéis. ça a pas durée plus deux mois avant que je l'envoie chier.
Et il n'y a plus non plus de client, ce sont maintenant des « product owner », 'tain il possède le projet le mec ! ouais enfin comme il a toujours pas de compétences techniques, et qu'il n'y a plus de cahier des charges, il fait ses demandes sur des post-it. rigoler pas, c'est réellement dans la méthode, et ensuite il les colle sur un tableau appelé kanban, avec des colonnes, et les gentils dev, bougent les post-it dans le tableau. Quand tous les post-it atteignent la dernière colonne on a fini un sprint. Ca c'est la théorie, ça veut dire que la durée de chaque tâche a bien été estimé et que personne n'est venu en rajouter entre temps, ni passer en force en allant voir un dev directement. C'est à ce moment qu'on a droit à la réunion en deux parties : sprint review aka fait ton autocritique, sprint planning aka on fait des plans sur la comète.
Évidement si le client est trop teubé, soit tout le temps, ou que la demande est complexe et implique plusieurs personnes, on utilise un proxy owner, qui n'est en fait qu'un MOA à qui on a donné une nouvelle casquette, mais à l'envers avec écris NYC dessus, qui de toute façon fixera les tâches avec le Team Leader, pour ensuite les imposer pendant le sprint planning.
Pour estimer la durée des tâches ça se fait avec un jeu de carte, mais ça je l'ai jamais fait, je crois qu'à un moment on a eu un sursaut de dignité, ou de faignantise, je ne suis plus très sur.
Oh et comme c'est pas encore assez, il y a aussi les "daily", qui ne sont pas des réunions d'équipe, non, non, d'ailleurs ça ne doit pas durer plus de 5 min, debout, et chacun fait son autocritique face au kanban et doit justifier pourquoi il n'a pas fait avancer son post-it dans la colonne suivante, les excuses du type l'équipe admin-sys est débordé et le serveur a pas été réinstallé ne sont bien sur pas recevable, mais tu as le droit de mettre ton post-it dans la colonne blocked et passé au suivant.

pour ceux qui veulent rire, en scrum chaque demande doit être Invest aka:

I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
donc tu fais pas une liste de course avec tous ce que tu as envie, tu te limites à l'essentiel et tu fixes des priorités. j'ai jamais vu quelqu'un le faire, résultat backlog avec 300 tâches de priorité 1. Ne parlons pas des dépendances, quand le client n'a aucune idée de la technique lui expliqué que pour chercher des documents faut déjà avoir réussi à les indexer, c'est peine perdu. De toute façon si les tâches sont dans le même projet elles sont forcement dépendantes. Ne serait ce que pour merger le code et le déployer. d'ailleurs ces tâches indispensable n'ayant pas de valeur business, elles n'ont pas de valeurs, et ne sont donc pas compté. La correction de bug non plus.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
Donc pas de caprice, « NAN C'EST PAS CE QUE J'AI DEMANDE !!!! » tu t'adaptes. Donc si tu veux téléchargé un fichier texte de 15 Go avec 15 M de lignes, l'intégré dans un système complexe et l'indexé, tu oublies le temps réel. Ou tu achètes plus de machines.
V Valuable A user story must deliver value to the end user.
« Je veux un bouton en bas et en haut du formulaire » ???? « Je veux trier par nombre de lignes et par dates, en même temps » les critères sont exclusifs.
E Estimatable You must always be able to estimate the size of a user story.
« oh bah ça doit être simple, ça doit vous prendre 5 min » Recherche multicritères avec opérateurs booléens et jokers.
S Scalable (small sized) User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
On en revient à la liste des courses et les tâches magiques « je veux que le traitement soit instantané et dispo la semaine prochaine ».
T Testable The user story or its related description must provide the necessary information to make test development possible.
Donc, « parfois c'est lent, mais j'ai pas d'exemple précis » ouais, parfois mon café est trop chaud, parfois il est froid, et sinon les enfants ça va ?

Spring a évolué, la conf xml c'est dépassé, depuis la 3.4 ?? ... depuis la 4 c'est un mix de conf automatique avec des annotations et pour les cas plus complexe avec une classe de configuration. par exemple pour mongodb : url : http://spring.io/guides/gs/accessing-data-mongodb/
un pojo, quelques annotations, moins qu'avec JPA, une interface, et hop.
Le problème est que beaucoup de choses sont implicites, donc obscures, par exemple l'exemple ici marche si tu as un mongodb local sur le port par défaut, sinon tu ajoutes une classe de @Configuration (annotation) qui dérive de AbstractMongoConfiguration avec une propriété qui te renverra un @Bean Mongo mais qui devra être dans le même package que l'interface pour que Spring puisse le détecté et crée l'objet repository... niveau pédagogie zéro, mais quand tu maitrises ton code devient simple et lisible, tu ne gères plus que les cas exceptionnelles.
faire un service REST: url : http://spring.io/guides/gs/spring-boot/ bon j'en suis pas encore là, je préfère utilisé CXF, au moins je comprends ce que j'expose.

Merci pour l'info sur sprint, j'y avais jeté un oeil très (très) rapide il y a un moment de ça, ravit de voir qu'ils ont abandonné l'XML. Du coup je jetterais un nouveau coup d'oeil, mais pas maintenant!

Pour SCRUM: d'une part tu mélanges au moins 2 voire 3 méthodologies différentes (pocker planning, scrum et Kanban), ce qui est complètement con en plus d'être contre-productif.

D'autre part je l'utilise (en entreprise) depuis un moment maintenant, et ça marche pas si mal. Le truc c'est que c'est moins simple que ça en à l'air, faut: connaître VRAIMENT la TOTALITE de la méthodologie, pas juste le panneau à post-it, et avoir un patron pas trop con ("boss, ça te dirait de gagner de l'argent plutôt que d'en perdre sur les prochain contrats ET que tes clients et tes dévs soient un peu plus contents?"). Connaitre la totalité de la méthodo, essentiellement pour savoir quelles parties tu fais sauter quand sans tout foutre par terre.
Après je dit pas que c'est 100% bullet-proof, qu'il y a pas des moments où ça foire total, etc. Mais le management "traditionnel" non plus hein. Et là au moins les dévs ont pas l'impression d'être des enfants de 4 ans incapables de prendre une décision et d'en être responsables (au vrai sens du terme: tu poses tes couilles sur la table, si ta décision était bonne on doit les couvrir de femelles en chaleur, si ta décision était mauvaise le client à le droit de taper dessus, voir de partir avec selon la gravité de l'erreur). Et le client suis le produit au fur et à mesure, donc à la fin il a interdiction de dire "mais en fait c'est pas ça que j'avais dit, vous aviez mal compris le cahier des charges, je vais payer que 25% du prix convenu et vous refaites tout en 1 mois et je paierais peut-être le reste". Mother Fucker!
Et INVEST c'est pour cadrer un peu, et pas avoir au même niveau "faudrait refaire tout l'interface graphique en Qt" et "le bouton save est moche, changer l'icône".

Et pour rire rapidement: en management "tradi", t'as rigoureusement les problèmes inverses de ce que tu décris:
- pas de réunion d'équipes régulières, et tu découvres au bout de 3 semaines que le mec qui doit bosser sur la tâche qui te bloque a en fait changé de sujet en cours de route sans te prévenir
- pas d'estimation des charges d'une tâche par l'équipe, c'est le chef de projet qui estime tout seul comme un grand, c'est bien connu qu'il est expert technique de chaque domaine couvert par son équipe, et peut donc magiquement deviner chaque charge précise et anticiper tous les problèmes (on se demande vraiment pourquoi certains prennent la peine de se spécialiser)
- si la demande est trop teubé, ou le client trop complexe, ben c'est pareil, vous avez qu'à faire avec le cahiers de charges, de toutes façons c'est ça qui sera recetté à la fin, on s'en fout si c'est débile, infaisable, que ça ne veut carrément rien dire, ou que manifestement ça ne servira jamais à rien en l'état: c'est dans le cahier des charges donc on le fait pour pouvoir cocher la case à la fin et facturer le client, qui sera pas du tout dégouté et reviendra sûrement signer pour le projet suivant.
- toutes les tâches seront bien effectuées, et dans le bon ordre, vu qu'on a fait un beau diagramme de Gantt (remplacez par la méthode de planification à long terme de votre choix)... dans lequel bien sûr, on a pris en compte les vacances, les arrêts maladies, la démission de JeanJaques pourtant prévue depuis 6 mois mais qu'on ne remplacera qu'un mois après son départ, l'arrivée des 2 nouveaux stagiaires, le séminaire "bien programmer: comment mon entreprise m'a rendu riche" décidé au dernier moment par le big boss, la réorganisation des services, l'incendie du datacenter et la fièvre du petit dernier du chef de projet pile le jour du commité de suivi, tiens ben t'as qu'à y aller à ma place, le client sera ravi de te voir.

J'utilise les 2 types de méthodologies projet (SCRUM et classique), et en fait les règles de base pour que ça marche sont exactement les mêmes dans les 2 cas. Je te cite Plantmann :

- Faut connaître VRAIMENT la TOTALITE de la méthodologie, et
- Avoir un patron pas trop con, et
- Connaître la totalité de la méthodo, essentiellement pour savoir quelles parties tu fais sauter quand, sans tout foutre par terre.

Après quelle méthodo utiliser dépend plutôt du type de projet, sachant que certains projets sont bien plus efficaces en méthodo AGILE (notamment les applications pas trop lourdes, celles nécessitant essentiellement du développement, et celles réalisées en petite équipe), et d'autres bien mieux menés en méthodo classique (projets très complexes, beaucoup d'intervenants, progiciels, ...).

Sachant par ailleurs que les 2 types ne sont pas exclusifs....

Je suis dans une boite qui a choisis de passer à la méthode agile en faisant du SCRUM + Kanban, parce que c'est super graphique. bon on a très vite arrêter les post-it pour passer à Jira (gestionnaire de tickets) + plugin. Mais le problème est effectivement hiérarchique, on est toujours confronté à des demandes exotiques à n'importe quel moment. Du coup le calcul de vélocité, chiffrage est toujours resté très théorique. ça reste à « ouais je devrais pouvoir faire ça et ça avant qu'on vienne me faire chier avec un truc urgent tombé du ciel. »
Ou quand tu te lances dans une nouvelle techno que tu ne connais pas, genre le truc bien lourd hadood/hbase/mapreduce chiffrer pour mettre dans un sprint n'a plus de sens. t'es parti pour 3 mois avant d'avoir un premier prototype. « ouais mais dans le planning le dev devait être terminé au bout de 6 mois ».
Enfin, avant on était en méthode à l'arrache. Quoi qu'au final quand un « team leader » refuse qu'un ticket soit traité parce que ça a pas de « business value » pour son égo, bah la méthode scrum tu peux te la mettre au cul et aller pleurer au directeur informatique en espérant qu'il accepte d'aller faire pression sur le génie incompris.

Après moult projets très diverses (taille, objectifs, ambitions, moyens...), perso je pense qu'il n'y a pas de process meilleur ou plus adapté qu'un autre (waterfall, scrum, kanban...).

Ce sont les gens qui font la différence. D'ailleurs certains projets que j'ai suivi n'utilisaient ces méthodes que très très partiellement (pour dire poliment que c'était parfois sacrément bordelique) et s'en sont parfaitement sortis. Rien ne remplace une bonne mentalité, la maturité et le pragmatisme. J'ai vu des projets balaises bien se passer avec zero process, juste des feuilles excel pour gérer un planning tout con, et d'autres super carré avec pleins d'outils et de méthodes se crasher lamentablement.

Alors bien sur c'est Captain Obvious, mais c'est tellement le seul truc important qu'on peut disserter 1000 ans sur le reste ça ne fera pas avancer le machin

Dernière modification le 04/12/14 à 09:29 par Gingembre

D'accord avec la racine. Si tu as des boulets dans la hiérarchie, c'est galère. Si tu as des gens motivés et un minimum organisé y'a pas de soucis.
(bon, je ne bosse pas à la NASA non plus...)

Ma mission est de refaire la présentation du site ...

Donc le big boss m'a filé un torchon et je dois me démerder avec. Pour lui, le plus moche des sites de e-commerce du moment est materiel.net (on ne doit pas avoir la même vision de la "mocheté").
Le but est de s'inspirer de sites comme grosbill : grosses polices baveuses, couleurs criardes avec des effets très web 1.0 ...

J'en ai vraiment, mais vraiment marre ...