Ping.fm – mise à jour de statut collective

Publié le 18 August 2008, par Babozor

ping.jpg

Voilà un petit service bien pratique: Ping.fm
Cet outil vous permet de mettre à jour votre status sur moults plateformes de micro-blogging et réseaux sociaux: twitter, facebook, plurk, pownce, myspace, linkedin, tumblr, identi.ca, brightkite, friendfeed, jaiku, blogger, Plaxo, WordPress.com, etc…

ping_fm.jpg
Bien pratique…
Il existe aussi une interface spéciale pour votre iphone pour tenir tout le monde au courant de votre achat de poireau ou que vous regardez la retransmission du curling sur gazon aux JO.
Indispensable évidemment!

Vos applications web préférées…

Publié le 11 May 2008, par Babozor

webapp.jpg

Quelles sont vos applications web préférées?
Voici une liste (longue mais non-exhaustive, je compléterais au besoin. Liste honteusement piquée sur ReadWriteWeb)

Donnez nous vos 5 préférées… et surtout pourquoi

A.nnotate
alert thingy
alphatwitter.com
Amie St.
Apture
aroxo.com
Aviary
Backpack
BaseCamp 2
Blist 2
brainfloor.com
Brightkite
bumptop
Buzzword 2
Capzules
Cogmap
comindwork
coRank
craigslist.org 2
createworkspace.com
Dapper
dealoco.com
del.icio.us 4
digg 2
Diigo
Dipity
Disqus 2
EBSCOhost
edocr
etymonline.com
Evapt
Evernote
eyeOS
facebook 2
facebook’s fanpages
Facebook’s Thrift
fisheye plugin for Firefox
FiveRuns
Flickr 7
Free My Feed
Freebase
FriendFeed 7
Fring
fuser.com
Geni
getdropbox
Gijit
Gmail
Google App Engine
Google Apps
Google Docs 2
Google Maps 2
Google Reader 7
GottaGotta.com
grandcentral 3
Gridstone Research
Hadoop
Hulu
Intense Debate
Isolatr
Itzbig
jaanix
Jajah
Jott
KeywordSpy
kickfly.com
Kirix Strata
kiva.org
last.fm 6
LinkedIn 2
LiquidPlanner
Locle.com
Loopt
loopt.com
mahalo.com
Meebo 4
mint.com 2
MinutesNotice (facebook app)
Mixx
Mumboe
Naked
NetVibes 3
OpenDNS
ourlikes.com
Pandora 2
Party Line
persontation.com
Picnik 3
Ping.fm
plaxo 2
popurls
Pownce 2
PropertyMaps
Proquest
Qik 2
Quintura.com
ReadBurner
Redfin
remember the milk 4
reQall
RescueTime.com 3
response-o-matic.com
ringside networks
Scribd 2
scrybe.com
secondbrain.com
Seeqpod 3
shoutwire
skype
SlideRocket
Slideshare.net 2
SMSguru.de
social gaming network
socialthing!
SolarWinds
Songza 2
soocial 2
Speedate.com
Spiceworks
SpotJots.com
SproutBuilder
squidnote.com
strutta.com
stumbleupon
Taaz.com
Technorati
thefreedictionary.com
thesixtyone.com
TimeBridge.com
TimeXchange.net
toluu
Topspin Media
TradeVibes
Tumblr 3
tweetscan.com
Twhirl.com 5
Twine 2
Twitter 10
typolight CMS
Utterz
vcvideomatch.com
vendorrate.com
viewdle.com
vimeo
voicethread
Webex
weheartit.com
wherever.tv
whrrl.com
Wikinvest
Wikipedia
Xobni
xtimeline
Yahoo! Pipes
Yahoo’s Pig
YouTube 3
zebate.com
Zebtab
Zemanta 2
Zivity

Pour moi:
Gmail (le meilleur outil de mail pour moi aujourd’hui simple et ultra puissant), Basecamp (un peu comme gmail adpaté à la gestion de projet), Vimeo (découvert il y a peu pour la qualité de la vidéo et l’interface plaisante), Twitter (des infos super intéressantes et ça flatte mon égo) et delicious (meilleur outil de bookmark à ce jour, simple mais puissant)

Prism vs Fluid: la bataille des Navigateurs Spécifiques

Publié le 22 April 2008, par Babozor

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:
fluid_install.jpg
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.
gr_fluid.jpg
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:
prism_install.jpg
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.
gr_prism.jpg
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.

Faits et erreurs du développement logiciel

Publié le 26 March 2008, par Babozor

dev_day.jpg

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?

Adobe Air: Pownce / Analytics

Publié le 29 January 2008, par Babozor

Image 16.jpg

Après avoir testé Prism, je me devais de tester un standard du marché (qui lui aussi est en version béta) et qui semble lui aussi très prometteur dans un autre domaine: Adobe Air.

Qu’est ce que c’est?
En gros ça sert à pouvoir créer des applications qui accèdent à des services web, dans un package desktop (sous la forme d’une application à installer), mais surtout de pouvoir utiliser la puissance de Flash (et donc des trucs potentiellement plus beaux/interactifs que Prism).

J’ai donc testé deux applis:
Pownce
Google Analytics

Alors?
C’est très beau (en tout cas plus que Gmail ou GReader sous Prism), c’est encore en béta (avec quelques fois des comportements assez bizarres mais pas critiques) mais ça tient plutôt pas mal la route…
C’est en tout cas très prometteur (à quand un équivalent de MarsEdit pour WordPress avec resize d’image sous Air??) et j’aime beaucoup…

Un petit lien pour pleins d’applis à tester (malheureusement la plupart ne marchent pas sur mon ordi)

Alors, votre avis?