Beaucoup d’entre nous sont adeptes des post-it, qu’ils soient réels ou virtuels… et un des problèmes avec cette technique est de pouvoir ranger et classer toutes ces notes (je ne vous ferais pas un screenshot de mon dashboard encombré de notes à droite à gauche, ça devient juste impossible à gérer)
Voilà donc une petite application sous Mac bien pratique: PaperClip
Cette application vous permet d’attacher des notes à vos différentes applications (on voit en exemple une note attachée à MarsEdit pour les prochains posts de TDW que je prépare). C’est légèrement customisable (couleur, transparence, etc…) et plutôt super pratique.
Vous pouvez y placer textes, liens, images, films…

Et vous vous utilisez quoi pour vous y retrouver dans votre jungle de post-it?

Comme beaucoup d’entre vous je suis sûr j’utilise beaucoup de Services Web dans ma vie de TravailleurDuWeb: Gmail, Google Reader, BaseCamp, Pownce, Twitter, toutes ces applications web qui sont très pratiques… mais qui ne sont pas ce qu’on pourrait appeler de la navigation à proprement parler. Pourquoi alors ne pas leur donner un environnement spécifique? Certains le font via des applications (build in, via Air, etc…) pourquoi ne pas utiliser un Navigateur Spécifique, qui est en clair une application spécifique d’un navigateur pour un service web.

Aujourd’hui (j’en oublie peut être, corrigez moi si c’est le cas) nous allons comparer deux applications: Fluid et Prism.

Fluid: Application OS X
Application Cocoa basé sur WebKit (cf Safari)
Gratuit (à télécharger ici)

Prism: Application Windows / Os X / Linux
Projet de la fondation Mozzila basé sur le code de Firefox
Gartuit (à télécharger ici)

J’ai installé et testé les deux applications en essayant d’avoir un environnement de démarrage similaire. Démarrage du Mac sans ouverture d’application automatique. Installation de chaque application et test sur Google Reader.

Fluid:

Installation
Installation simple et rapide, on apprécie la possibilité de pouvoir choisir l’emplacement de l’application et de pouvoir choisir une icône alternative… pas d’accroc durant l’installation.

Utilisation
Lancement très rapide et bonne stabilité de l’application, tous les médias s’affichent correctement (images, flash, vidéo, etc…), mais certaines fonctionnalités avancées de Google Reader ne s’affichent pas (comme la liste de partage des amis…btw idem sous FF3 béta 5)

Prism:

Installation
Ici aussi l’installation est simple, avec quelques options en plus, comme la possibilité de rajouter la barre d’adresse, les flèches de navigations, etc… et de pouvoir créer un raccourcis sur le bureau ou dans le répertoire application.

Utilisation
D’après mes tests (qui n’ont rien d’ultra scientifiques) Prism est un poil plus lent, mais semble offrir plus de possibilités. Seul gros défaut à mes yeux l’impossibilité d’ouvrir deux applications Prism en même temps et certains plantages ou décalages dû à du contenu flash et du contenu quicktime (mais rien de révolutionnaire pour les habitués à FF).

Conclusion?
Les deux applications sont intéressantes bien que comlètement différentes. Prism va créer un raccourcis qui utilise l’application Prism vers une adresse spécifique alors que Fluid va créer une application différente pour chacun de vos services web. Chacun ont leurs avantages et défauts. Personnellement j’ai résolu le problème en utilisant Prism pour Google Reader et Fluid pour le reste…
Ces deux projets sont encore en cours de développement (surtout pour Prism) et on peut s’attendre à des nouveautés dans ce domaine très bientôt.

[Je trouve ça super dommage que ça n'existe pas sous Windows, encore que je ne suis plus très Windows en ce moment... si quelqu'un connaît un équivalent sous Win, postez le lien en commentaire plize!]

Voilà un site très intéressant et très pratique: iUseThis
En gros iUseThis référence les applications récentes (mais aussi les nouvelles versions d’une même application) et les applications les plus utilisées sous Mac Os X.
Il propose une description du produit, des screenshots, un lien pour télécharger le logiciel et un classement par tag.
Un site très intéressant qui m’a fait découvrir beaucoup d’applications très pratiques sous OS X.

Et oui la gué-guerre de la vidéo sur la web continue…
Après Joost et ses problèmes (suppression de postes, recentrage sur le marché américain, etc…) c’est Adobe qui s’engouffre dans le marché de la vidéo sur le web via son nouveau Adobe Media Player

Un player de plus… développé sous AIR (un peu normal venant d’Adobe) assez similaire dans certaines de ses fonctionnalités à Miro (mais sans le client Torrent intégré, et pleins d’autre trucs), intégrant des flux RSS vidéos de moults podcast vidéo et WebTV, mais avec aussi des accords avec certains fournisseurs de contenu traditionnels (CBS, MTV, etc…)

L’interface est pas mal, mais manque cruellement de contenu… comparé aux 4000 chaînes de Miro
Bref, un acteur de plus… et vous vous en pensez quoi?

Voilà un article fort intéressant de Codding Horror que je ne m’empêcher de traduire, tellement les conseils sont selon moi avisés…
[ces conseils proviennent d'un livre: Facts and Fallacies of Software Engineering (Agile Software Development)]

Les gens
1. Le facteur le plus important dans le développement est la qualité des développeurs.
2. Les meilleurs programmeurs peuvent être jusqu’à 28 fois meilleurs que les pires programeurs.
3. Ajouter des gens à un projet déjà en retard ne l’accélère pas.
4. L’environnement de travail a un impact profond sur la productivité et la qualité.

Outils et techniques
5. Les modes (pour les outils et technologies) sont un cancer pour le développeur.
6. Les nouveaux outils et techniques créent une perte initiale de productivité et de qualité.
7. Les développeurs parlent beaucoup d’outils mais les utilisent peu.

Estimation
8. L’une des deux causes pour un projet en déroute est une mauvaise estimation.
9. L’estimation arrive le plus souvent au mauvais moment.
10. L’estimation est faite la plupart du temps par les mauvaises personnes.
11. Les estimations ne sont la plupart du temps pas corrigés durant l’avancée du projet.
12. Ce n’est pas une surprise que les estimations soient mauvaise. Mais ce sont elles qui nous font vivre ou mourir demain!
13. Il y a une déconnexion entre les managers et les développeurs.
14. La réponse à une étude de faisabilité est quasiment toujours “oui”.

Ré-utilisation
(je dois dire que j’ai eut du mal à traduire ce morceau là… pas évident du tout à traduire, pour les anglophiles mieux vaut se fier à la version originale)
15. Ré-utiliser ponctuellement du code peut résoudre votre problème.
16. Ré-utiliser globalement du code ne résoudra pas vraiment votre problème.
17. La ré-utilisation globale marche mieux dans une famille ou un système similaire.
18. Les éléments ré-utiliables sont trois fois plus dur à construire et devraient être testés dans trois environnements différents.
19. La modification d’un code ré-utilisé est particulièrement source d’erreurs.
20. La ré-utilisation de Design Patternes est une solution pour résoudre le problème de ré-utilisation du code.

Besoins
23. L’une des deux causes de déroute d’un projet est des besoins instables (fonctionnalités demandées).
24. Les changement des besoins (et donc de fonctionnalité) sont les plus coûteux durant la production.
25. Les besoins manquants sont les fonctionnalités les plus dures à corriger.

Design
26. Les conditions explicites ‘explosent’ alors que les conditions implicites pour une solution évoluent.
27. Il y a toujours une solution de design triviale pour un problème logiciel.
28. Le design est un processus itératif complexe. Le design initial est le plus souvent mauvais et pas optimal.

Code
29. Les ‘fondamentaux’ des designers vont rarement de pair avec les ‘fondamentaux’ des développeurs.
30. COBOL est un langage vilain, mais tous les autres sont bien pires.

Supprimer les erreurs
31. Supprimer les erreurs est le processus le plus long du cycle de vie d’un programme.

Tester
32. Une application est souvent testée au mieux sur 55 à 60% de son tout.
33. Tester 100% de son application est tout de même loin d’être suffisant.
34. Tester les outils est essentiel, mais rarement fait.
35. Les tests automatiques sont rarement mis en place. La plupart des tests ne peuvent pas être automatisés.
36. Un mode-debug créé par un développeur, se doit d’être rajouté dans la liste des outils à tester.

Reviews et Inspections
37. Une inspection rigoureuse peut enlever jusqu’à 90% des erreurs avant même le premier test.
38. Une inspection rigoureuse ne doit pas remplacer les tests.
39. Des rapports post-livraison, postmortem et rétrospectifs sont important et peu ou jamais fait.
40. Les rapports sont techniques et sociaux, les deux facteurs se doivent d’être présents et adaptés.

Maintenance
41. La maintenance consomme entre 40 et 80% du coût de votre application. C’est sans aucun doute la phase du cycle de vie de votre application la plus importante.
42. Les améliorations représentent en gros 60% des coûts de maintenance.
43. La maintenance est une solution – pas un problème.
44. Comprendre le produit existant est la tâche de maintenance la plus difficile.
45. De meilleurs méthodes amènent plus de maintenance et non moins.

Qualité
46. La qualité est une somme d’attributs.
47. La qualité n’est pas la satisfaction de l’utilisateur, la satisfaction des besoins, rentrer dans les coûts et le planning ou la fiabilité.

Fiabilité
48. Il y a des erreurs que la plupart des développeurs font.
49. Les erreurs ont tendance à se condenser.
50. Il n’y a pas qu’une seule approche pour la résolution d’un problème.
51. Les erreurs résiduelles resteront persistentes. Le but doit être de minimiser ou éliminer les erreurs sévères ou critiques.

Efficacité
52. L’efficacité vient plus souvent d’un bon design que d’un bon code.
53. Un langage de haut niveau peut être à 90% aussi efficace qu’un code similaire en assembleur.
54. Il y a un gouffre entre optimiser le temps de réponse et optimiser l’espace occupé.

Recherche
55. La plupart des chercheurs tentent de convaincre plutôt que d’investiguer.

Après ces 55 faits, l’auteur nous présente donc 10 erreurs communes, qui ont l’apparence de la vérité…

1. Vous ne pouvez manager ce que vous ne pouvez mesurer.
2. Il est possible de suivre la qualité d’une application.
3. La programmation n’est pas une question d’ego.
4. Outils et techniques: un pour tous.
5. Les applications ont besoin de plus de méthodologies.
6. Pour estimer le coût et les délais, estimez d’abord le nombre de lignes de code.
7. Des tests au hasard est un bon moyen d’optimiser les tests.
8. “Given enough eyeballs, all bugs are shallow”. (celui là j’ai pas vraiment réussi à le traduire correctement donc je le laisse comme ça)
9. Pour prédire les futurs coûts de maintenance, il faut regarder dans les projets antérieurs.
10. Vous apprenez aux gens à programmer en leur montrant comment écrire du code.

Aucun doute il me FAUT ce livre… apparemment pas encore traduit en français, mais qui liste une bonne partie des problèmes qui existe dans notre profession.
Evidemment certains de ces faits sont difficilement praticables (surtout dans un contexte web), mais c’est cela que tout bon développeur et travailleur du web doit tendre.

Des réactions?