Yozz

J'hallucine sur le nombre de fans de Kermit la grenouille qui s'amusent à troller le forum.

A quoi fais-tu référence?

A se débarrasser plus rapidement de cette tâche agaçante.

Bon, pour ceux que ca intéresse, je suis super content de mon 8820. Et Edge pour un usage moyen (mail/web, pas de streaming/gros download) est plus que décent.

Non, c'est ce que j'ai lu dans un test. Je n'ai pas d'avis sur la question, et suis d'accord avec toi pour la question plastique/métal. Le trackball, pareil, ça vient du test, et en comparant les deux en magasin, honnêtement, je suis sceptique sur leurs affirmations Les touches, c'est basé sur un test comparé des deux en magasin (je n'ai le 8820 que depuis hier soir…), grosso modo 3 minutes chacun. Je trouve de fait la saisie beaucoup plus facile et confortable sur le 8820, mais c'est sans doute une question de goûts (et de taille de doigts…). Pas d'habitude, pour la raison citée. En gros, je voulais surtout t'embêter Néanmoins, aie quand même ces éléments à l'esprit en achetant ton Bold et teste avant.

En fait, non. En y réfléchissant un peu plus, je crois même que tu as raison, et qu'il est vraisemblable que l'iPhone soit sorti avant le Touch aux US. Pas sûr, mais c'est bien possible. Au temps pour moi. Bah, pas si sûr que ça. Je veux dire par là que le tactile est dans l'air depuis un bout de temps et qu'on y bosse sérieusement depuis des années - suffit de voir l'annonce de MS Surface (dans un autre domaine) qui a suivi de peu celui de l'iPhone, et dont je doute qu'il fut une bonne idée piquée à Apple. Il était peu surprenant que ça s'applique aux portables en "full". Et hormis le tactile, le touch (qui incorpore d'ailleurs un stylet et me fait plus penser à un Palm qu'à un iPhone) n'a pas grand chose à voir avec l'iPhone. Bon, ben vraiment pas de regrets d'avoir acheté le 8820 alors C'est par contre horrible d'attendre qu'il charge avant de pouvoir jouer avec… Mais plus fragile, avec un moins bon trackball et des touches un peu pourries (exagérément molles). Fair enough.

L'apn c'est pour les gamins, le BB c'est pour les gens qui bossent . Bon, pas de 3G, c'est plus compréhensible, mais est-ce que le 3G ca vaut vraiment le coup pour le moment? (dit le gars qui hésite à s'acheter un BB 8820 parce que bon, le tactile, c'est rigolo, mais au final c'est cher pour ce que c'est).

Tiens, pourquoi pas le BB 8820?

C'est pas pour dire, mais HTC a sorti le touch avant l'iPhone.

Tchu, je suis déjà vachement expérimenté alors Et en plus je suis déjà un sage C'est clair que vu les trucs de base que je fais, je pompe essentiellement des classes existantes, et les applique juste à mon cas en les agençant comme il faut. Code vraiment écrit par moi dans ce que j'ai déjà fait en java, 3 lignes (et des lignes à la con évidemment). Mais c'est pas grave, mon but c'est surtout de comprendre la logique du truc, donc j'apprend quand même ce qui m'intéresse. Et puis je vais commander le bouquin qu'Etienne et AB conseillent.

Je ne sais pas, je n'ai jamais eu ce problème Oui, je pense que c'est ça. J'en arrive à la conclusion que quand on débute à partir de rien comme moi, il faut passer un peu de temps avec un papier et un crayon à modéliser un peu ce qu'on veut faire plutôt que de commencer à écrire n'importe quoi et à essayer de le réparer après (comme on peut très bien le faire dans un langage comme bash).

Ben la logique, ça je la vois, je pense que j'ai compris, mais bizarrement, quand je passe en mode code, ben j'ai du mal à me défaire d'une lecture très "itérative" du code, j'ai du mal à me mettre à écrire en OO. Mais bon, 2h d'essais sans maîtriser la syntaxe, faut pas demander des miracles non plus Cool, c'est un des moins chers en plus Ah ben évidemment, eh, j'ai pas passé 2 ans chez IBM pour rien Mieux encore en fait, j'utilise Rational Team Concert (ce qui dans le cas de moi tout seul dans mon coin pour bidouiller des conneries ne m'apporte rien de plus, mais bon, j'ai un copain qui le vend alors voilà )

Lire le code des autres, pour vérifier la qualité, ça peut être le rôle d'un tiers qui fait de la QA, pas de souci. Il rapporte au chef de projet et voilà. Pour les décisions importantes, soit elles sont de type fonctionnelle, et pas besoin d'être techos, soit elles sont de type architecturale ou d'implémentation, et il "suffit" que le PM se fasse expliquer les différentes implications et décide (éventuellement en prenant un avis extérieur - dont, presque toujours, celui du client). Evidemment, ca suppose les trois conditions que j'ai expliquées au-dessus, ça c'est vrai. Objectivement, c'est rare qu'un projet foire pour des raisons purement techniques. C'est le plus souvent mal vendu, ou mal géré (et souvent les deux) - surtout au niveau fonctionnel. Parce qu'une des idées trop répandues c'est de croire que gérer un projet c'est facile. Ben non. Et de ce fait, c'est clair, il y a beaucoup de mauvais chefs de projet. Gérer la productivité par contre, aucun besoin de compétences techniques - le status reporting sert à ça. Et des techniques de PM comme l'EVM par exemple.

Ben s'il est bon, je me le paierai bien, j'aime bien étoffer ma bibliothèque. Je sais que c'est une bonne collection - j'ai le Head First PMP qui arrive à rendre le PMBOK marrant, ce qui est un tour de force - mais je me demandais s'il ne serait pas trop axé pissage de code sans explication conceptuelle. Ton avis? Ehhh, mais ça a l'air très cool ça, merci! Pourquoi? Pas uniquement parce que c'est MS quand même,

Ca dépend, ça peut marcher sur un petit projet (disons, 6-7 personnes grand maximum) où on peut communiquer vite et bien entre PM et membres d'équipe (ce qui ne sera pas le cas par ex si les 6 personnes sont par ex trois groupes de 2 bossant sur des trucs très différents comme, par ex, BDD, Business Logic et GUI) . Mais il faut pour ça 1) que le PM soit suffisamment malin (et humble, talon d'achille de beaucoup de PM) pour demander qu'on lui explique quand il a besoin de comprendre un truc 2) que les techos soient suffisamment patients pour expliquer à un non-techos 3) que les uns et les autres puissent se rencontre à mi-chemin entre langage pur business et langage pur technique A défaut de ces 3 trucs là, oui, le PM doit être techos. Sur un projet plus gros, c'est mort, il faut des chefs d'équipe. Au passage, même si le PM est techos lui-même, parce que sinon il risque de passer trop longtemps à discuter avec tout le monde pour voir où tout va sans avoir le temps de faire autre chose. C'est clair, le souci, c'est que c'est très rare d'être au top dans les deux domaines. Chef de projet, c'est un métier, développeur (ou autre fonction technique) aussi, et un métier ça demande de se tenir à jour, de se former, et d'avoir de l'expérience. C'est le plus gros argument contre le PM pur techos: quand tu gères des projets pendant des annés, tu n'as matériellement pas le temps de te tenir assez à jour pour rester un super techos. Et pourtant, tout le monde est d'accord, les "vieux" PM (j'entends ceux qui ont de l'expérience) sont les meilleurs. Maintenant, c'est clair, au plus on peut marier les deux, au mieux. C'est pourquoi j'essaye d'investiguer la technique un minimum hein

D'accord avec la logique générale, mais si tu me dis que l'approche est très mathématique dans ces bouquins, ca risque d'être dur pour moi…

Oui, je me demandais si en fait les design patterns ne seraient pas intéressants à investiguer, mais un copain m'a dit hier que ce serait peut-être difficile sans avoir assez de connaissances en programmation (moi mon niveau, c'est shell scripting un peu de base, puis c'est tout).

Et moi cette position ne m'étonne pas de ta part; vu que tu démontres à longueur de temps ton incapacité à t'élever au-dessus de la technique pour comprendre les besoins business . Un chef de projet a pour but de s'assurer qu'un projet livre ce qui a été convenu dans les temps, dans le budget, et avec la qualité requise. Pour évaluer, comprendre, et maitriser tout ça, aucun besoin de comprendre le détail de la technique - il peut s'appuyer sur l'expertise de son équipe et de tiers pour ce qu'il a besoin là-dessus. Il suffit qu'il comprenne les choses de haut niveau. Les connaissances techniques sont un plus, mais certainement pas un pré-requis. Au contraire, je soutiens que les plus mauvais chefs de projets sont ceux qui viennent de la technique, parce qu'ils restent trop près de la technique, s'ingénient à résoudre les problèmes techniques en négligeant le reste, et passent à côté de l'essentiel du projet. Ils livrent un truc tout beau, bien torché techniquement, manque de bol, c'est pas ce que le client voulait, trop cher, et pas dans les temps. Mais ils s'en foutent, ils savent mieux que le client, qui n'est pas techos C'est d'autant plus vrai quand joue le halo effect, et que des techniciens sont promus PM sans en avoir les skills - ce qui est fréquent, ne fût-ce que parce que beaucoup de techos n'ont pas les people skills requis pour la gestion de projet. Bref, pas confondre PM et chef d'équipe, qui lui doit avoir les skills techniques évidemment.

Merci! Et pour répondre à ton MP, la marmotte aime la confiture, je répète, la marmotte aime la confiture.

Si tu trouves un bon smartphone qui me permettra de faire tourner mon script bash, je suis preneur! Non, mais Cata bien, et il est très cool, et je veux le même! HTC Touch au passage. Project Manager, aka Pretentious Monkey.

Ah, quand même Tu conseillerais quoi alors en oo, C++? Si je pense à Java, c'est parce que je pense à porter sous Java un petit script bash que j'utilise sous Linux pour mettre à jour ma to-do list. Le but étant de mettre l'appli sur un GSM sous Windows Mobile 6.

Tiens, je m'attendais à une vanne sur Java, mais non. Sérieusement, c'est vraiment juste par curiosité, et même en changeant de boîte, je reste PM. Mais bon, ça fait jamais de tort de savoir ce que font ceux qu'on dirige .

Bien que non informaticien, j'ai pour diverses raisons, envie de comprendre un peu mieux comment fonctionnent les langages orienté objet. Si tant qu'à faire, ça me permettait d'écrire l'une ou l'autre appli en java, ce serait un plus appréciable. Quelqu'un aurait une recommandation de bouquin sympa allant en ce sens? Je précise, le but n'est pas que je devienne un expert, loin de là, juste comprendre comment ça marche - une intro me convient mieux qu'une bible quoi. Et je n'ai pas un background informatique de folie. J'ai trouvé ces deux bouquins qui m'ont l'air sympas, mais suis ouvert à d'autres suggestions:

Ils veulent vous aider à mieux organiser votre manière de travailler, faire un plan de formation, et faciliter le travail entre départements.

Ben oui, au vu de la description de Gadrel, avec une voiture plus longue, il se faisait percuter.