Si vous n’êtes pas convaincu, allez lire ça http://www.skorks.com/2010/05/why-i-love-reading-other-peoples-code-and-you-should-too/

A mes débuts, je “singeais” les autres, je copiais/collais du code trouvé sur le Net, sans forcement comprendre tout ce qu’il faisait.
En général, je trouvais ce code sur des forums comme developpez.com, codes-sources ou The code project.
J’avoue qu’aujourd’hui, je consulte rarement les forums (à part celui de Ubuntu-FR, si vraiment je ne trouve pas l’info sur leur merveilleux wiki)

Le Web a évolué en 2.0. Stackoverflow en est un pur produit: c’est un “forum” que je conseille vivement pour trouver des solutions à vos problèmes.

Mais la meilleur façon d’apprendre, c’est encore de lire du code, du vrai, du brut.
Il n’y a pas de honte à ne pas être un “Shakespeare” du C#… certaines personnes écrivent des romans et d’autres des articles de magazines… on ne fait pas tous  le même boulot.

Mon vrai premier "ordinateur" a été un Amstrad CPC 6128, et pour jouer à un jeux... il fallait le coder en recopiant le listing du bouquin!

Aujourd’hui, le Web 2.0 vous offre un outil magique pour lire du code: j’ai nommé http://www.google.com/codesearch !
C’est devenu un reflex pour moi: quand je ne comprend pas une fonction, au lieux d’aller consulter la MSDN, je cherche du code qui exploite cette dernière.

A noter que cette magie n’existerai pas sans l’émergence de l’OpenSource. S’il y avait principalement que Sourceforge au début, vous pouvez maintenant héberger vos projets OpenSource sur de nombreux sites comme Google Code, Github, Bitbucket, Codeplex, etc.

Bien sûr, les blogs restent une bonne source d’information. En ce moment vous pouvez y voir pas mal d’article sur les “CoRoutine” avec une utilisation astucieuse du mot clé “yield”: http://www.codinginstinct.com/2010/06/sequential-async-using-coroutines.html

Si j’ai réussie à vous donner envie de lire, je vous conseille de regarder ceci.
J’ai découvert ce code lors de mon apprentissage de CQRS (cf GoogleGroups d’ALT.Net) et je le trouve très élégant (pas étonnant qu’on le trouve sur http://elegantcode.com/ )

Lire du code provenant d’autres langages peut aussi vous apporter beaucoup: ne restez pas enfermé dans vos habitudes, et regardez les pratiques des autres. C’est en cherchant quelque chose sur Google Code Search que je suis tombé sur le code suivant: http://www.google.com/codesearch/p?hl=en#LH6NMiZyrsw/trunk/src/documentpresenter.vala

Ça ressemble à du C#? Mais c’est du Vala. Le projet est un IDE, avec une architecture MVP (Model Vue Presenter) avec de l’injection de dépendance etc. Je le trouve très lisible, clair et concis.
Pour ceux qui ne connaissent pas Vala, regarder ici:  http://live.gnome.org/Vala/QuickIntroForCSharpProgrammers

En parlant d’autres langages, je vous conseille quand même d’éviter de lire du Brainfuck  je ne veux pas être responsable de votre autisme.

Je n’ai plus qu’a vous souhaitez bonne lecture Mais allez bronzer un peu quand même :p

Cela fait du buzz en ce moment, Google sort son navigateur Google-Chrome, et pour l’illustrer l’annonce est faire sous forme de BD!!

Premièrement, j’adore la style “BD”, car comme on le dit : “un schéma vaut parfois mieux qu’un long discours”. Et on comprend tout de suite ce qu’ils veulent dire quand on voit la représentation “imagé”.

J’aime bien donner mon point de vue, et je vais surtout m’attarder sur l’aspect “interface utilisateur” et “Web vs Desktop”.
J’avais déjà lu de nombreux trucs sur la gestion des onglets dans les navigateurs, et en résumé on remarque que l’OS gère tellement mal les fenêtres, que l’on a inventé une nouvelle “barre de tâches” intégrée au navigateur (les onglets).
Certes, avec des gestionnaires de fenêtres tel que sous MacOS, avec Exposé, ou sous Linux, avec Compiz, il est facile de naviguer entre les fenêtres d’une même application sans avoir besoin d’onglet.
Quand on dit que le Web converge vers le Desktop, on s’aperçoit qu’un site n’est ni plus ni moins qu’une application. Cela est d’autant plus flagrant avec des sites comme GMail, ou Facebook. Personnellement, je les laisse toujours ouverts, et pour éviter de les fermer accidentellement, je les laisse dans une fenêtre séparée de ma navigation “temporaire”.
De mon point de vue, ça ne devrait pas être le rôle du navigateur de gérer des fenêtres (onglets), mais plutôt celui de l’OS.

“Mais il subsiste des onglets dans Google-Chrome!!??” me diriez-vous. En effet, je crois que c’est quelque chose qui fait partie des habitudes difficiles à perdre…
Mais un onglet est maintenant une entité bien distincte, et chaque onglet tourne maintenant dans un processus différent comme des applications différentes.
De plus, Google-Chrome propose aussi un mode “standalone” comme dans Google Prism, c’est à dire que l’application web (tel que Gmail) s’ouvre dans une fenêtre dédiée, sans barre de navigation etc… “nul besoin, je suis dans Gmail, et je reste dans Gmail. Les boutons de navigations du site me suffisent.“
J’en profite pour dire que j’adore leur façon de gérer les popups (la BD l’explique mieux que mes mots )

Dans la troisième partie, ils parlent des onglets qui incluent leurs propres boutons de navigation ainsi que leur propre barre d’adresse. Comme je l’ai dit, chaque onglet est une application à part entière avec sa propre interface, et les boutons de navigations/barre d’adresse en font partie.
Il est vrai que j’utilise rarement la boite de recherche, car finalement je tape un mot dans la barre d’adresse, ce qui lance “google j’ai de la chance”… Que les deux soient “fusionnés”, me semble naturel aussi. Google appelle ça “l’omnibox“.
Enfin, Google corrigent des bugs de “fonctionnalité” de Firefox, comme le fait d’aller sur le site “http://cnn.com” quand je tape “cnn“, et non la dernière page mémorisée dans l’historique, à savoir “http://cnn.com/2008/politics/07/27/campaign.wrap/index…..“

Je suis aussi fan de l’idée de la recherche/complétion à l’aide de la touche “tab” dans l’omnibox. C’est peut-être un peu geek, mais ça me rappelle la complétion en ligne de commande sous Linux/MacOS ou MsDos.

Google expliquent aussi les sources des problèmes concernant les ressources et le caractère “mono-threadé” d’un navigateur.
Qui n’a pas déjà pesté sur la lenteur d’affichage des pages, d’exécution du Javascript, du freeze du navigateur à cause d’une pub flash, ou des 380mo en mémoire pris par Firefox ???
Gérer les ressources, c’est normalement le rôle de l’OS. Et je le répète : un site web n’est ni plus ni moins qu’une application, elle devrait alors avoir son propre processus, avec sa propre gestion de ressource, sans empêcher la navigation dans les autres onglets.

Coté performance, on blame souvent Javascript….
Les applications web se rapprochant des applications Desktop, elles deviennent de plus en plus “dynamiques” et “user friendly”. Pour se faire, on utilise Javascript depuis bien longtemps. Mais ce n’est que depuis peu (Web 2.0) que le Javascript est exploité massivement. Et c’est la qu’on se rend compte de ses limites en terme de fonctionnalité et de performance.
Certains contournent le problème, en intégrant un “plugin” tel que Flash/Java/Silverlight, et réalisent leurs sites en partie/entièrement avec. Parfois, le navigateur ne sert plus qu’à lancer le player flash, qui lui gère entièrement l’interface graphique.
Je suis fan de Javascript car ça reste léger, non propriétaire, et cela s’intègre bien avec le HTML. Vous allez me dire que je suis vieux jeux, et qu’il faudrait tout migrer immédiatement vers du Silverlight mais ça c’est un autre débat.

Google est repartie de ZERO pour réaliser son moteur Javascript, chose qui m’étonne peu. Mais ce qui m’a en tout cas fait rire, c’est de lire qu’ils font carrément une machine virtuelle ! L’avenir est aux machines virtuelles, tel que Java et .Net, que ce soit par leur gestion de la mémoire, ou les optimisations de compilations. D’autres arguments sont cités dans la BD, et ils paraissent souvent évidents. Mais il n’y a qu’un géant comme Google qui peut dire “bon, les autres trucs c’est de la merde, on va tout refaire à zero en apprenant des erreurs du passé”. Mine de rien, c’est un challenge énorme, et on a tendance à préférer ré-utiliser un existant même s’il faut le faire évoluer.

A la fin, ils parlent aussi un peu de Google Gears. Pour moi, c’est comme si le navigateur était devenu une machine virtuelle pour héberger nos applications web, et Google Gears c’est le “framework”, qui offre la possibilité d’étendre leurs fonctionnalités à l’aide de “librairies” réutilisables. L’écart Web-Desktop se resserre encore…

Un petit mot sur la sécurité : le fait d’isoler les onglets dans des processus différents permet d’isoler les programmes “malveillant” des autres. Quand le processus est lui aussi découpé en plusieurs niveaux d’isolation, c’est encore mieux. Quelque chose m’a amusé concernant l’interaction entre l’utilisateur et la Sandbox : on dirait qu’il y a un pare-feu interne entre eux, et que seul l’utilisateur peux initier une “connexion” avec la sandbox, qui ne peux que lui répondre. L’explication en image est bien plus parlante -_-’

Je ne couvre pas tout, je vous laisse découvrir la BD par vous même.
Je suis sûr que ce navigateur va changer beaucoup de chose dans nos façons de développer des applications Web, et dans notre façon de surfer.

Pour les tâches quotidienne il y a http://www.rememberthemilk.com, mais pour le boulot il y a Trac.

J’ai découvert cette merveilleuse application web en Python, et je ne m’en passe plus pour la gestion de projet.
Le problème se pose quand on est plusieurs à travailler sur un projet car il est nécessaire de :

• récupérer les sources ou de consulter les derniers changements.
• rédiger un bug ou une tâches à faire
• savoir qui travail sur quoi, qu’est-ce qui est prioritaire et surtout pour quand ça doit être fait
• rédiger de la documentation technique pour les autres membres de l’équipe

Bref, Trac permet de résoudre tous ces problèmes. Bien sûr, ça ne remplace pas un testeur qui entre les bugs, ou un chef de projet qui définie les priorités et les échéances. Ça reste reste un outil, il faut prendre du temps pour s’en servir

J’ai testé plusieurs outils de ce genre, mais j’ai préféré Trac car :

• il est gratuit
• la gestion de bug et le wiki sont rassemblés sur le même site
• il existe de nombreux plugins qui étendent les possibilités de Trac (Forum, Blog, Gantt, etc.)