10/14/09

Django vu par un utilisateur de Rails (1)


Tout ce que vous allez lire est à prendre avec des pincettes car je ne suis qu'au début de ma découverte du framework Django. Je suis donc loin d'être un spécialiste de Django et je ne fais que donner « mon ressenti à chaud » par rapport à un autre framework que je connais mieux : Rails.

Création d'un projet
Après avoir installé Django (ce qui fera sans doute l'objet d'un autre article), première surprise de taille à la création d'un projet :
$ django-admin.py startproject taisteuh
$ cd taisteuh
$ ls
__init__.py manage.py settings.py urls.py
On ne peut pas dire qu'on est embarrassé par le nombre de fichiers générés ! Un peu déroutant lorsqu'on vient de Rails mais finalement une bonne surprise pour la courbe d'apprentissage. Comme je ne veux pas transformer ma bafouille en didacticiel, je résumerai en disant que "settings.py" est un peu le pendant "de l'environment.rb et du database.yml cumulés" alors que "urls.py" serait le "routes.rb" de Rails.

Mais alors, où sont mes modèles, mes controllers, mes vues et tout le toutim ? Va falloir y aller à la mimine mon gars ! (python manage.py startapp xxx sera notre ami la prochaine fois)

Moins de ciment entre les briques
Bien que ce soit « troublant » lorsqu'on vient de Rails, on ressent rapidement une plus grande liberté d'action et d'organisation ainsi qu'une meilleure compréhension du framework si j'essaie de me rappeler de l'époque de ma prise en main de Rails (même si ça date un peu maintenant). Les briques de Django sont moins étroitement liées que celles de Rails ce qui ouvre un « champ des possibles » plus important en terme d'organisation mais au détriment d'une production de code « initiale » également plus importante. Rails demande moins de code initial mais au détriment de conventions plus lourdes. Il faut penser « à la Rails » alors que je n'ai pas eu l'impression d'avoir à penser « à la Django » jusqu'à maintenant (enfin... beaucoup moins).

On se sent également plus proche du langage sous-jacent (Python pour Django vs Ruby pour Rails). Bizarre comme sensation. Encore une fois, c'est juste un ressenti personnel que je livre « tel quel » sans pour autant me l'expliquer réellement pour l'instant (juste peut-être parce que Rails dispose au départ de plus de « magie » que Django ?). Évidemment, la syntaxe de Python étant nettement moins « human friendly » que celle de Ruby, ça va certainement à terme user mes nerfs et mes yeux (Wait & See).

Du coup, pour un petit projet, Django est certainement beaucoup plus adapté que Rails. L'artillerie à mettre en place est beaucoup plus légère, on n'a pas l'impression de sortir un « canon de 75 » pour tuer un moustique. Attention ! je ne dis surtout pas que Django n'est pas adapté aux gros projets (je pense même l'inverse si j'entrevois bien ses possibilités et sa logique qui me laisse la mienne). Je dis juste que si j'avais un site léger (dynamique ou pas) à mettre en ligne, j'opterais sans hésiter pour Django même en l'état actuel de mes pauvres connaissances (d'ailleurs, si Merb existe, ce n'est pas pour rien ^^).

MVC ? MVT ?
Un autre point déroutant au départ est la vision d'un MVC par Django. En résumant, ses vues seraient les controllers de Rails et ses templates seraient les vues de Rails. On pourrait plus parler d'un pattern MVT (Model-View-Template). En fait, en creusant un peu, c'est surtout une histoire de vocabulaire et de définition. Pour Django, les vues décrivent les données qui vont être présentées à l'utilisateur mais ne tient pas compte de la forme (ce sont les templates qui s'occupent de cela). Pour Rails, c'est le contrôleur qui détermine quelles données seront présentées et ce sont les vues qui les mettent en forme. Pas de quoi fouetter un chat une fois qu'on a fait le point sur le sujet. Juste une question d'angle de « vue » (mouarf !).

Template (équivalent Vues de Rails)
Le système de templates de base de Django est surprenant mais réellement pertinent. « Surprenant » parce qu'on ne peut pas y insérer directement du code Python et « pertinent » parce que ça oblige à réellement séparer « la logique métier » de la présentation. Avec Rails, on peut rapidement se laisser aller à ne pas respecter ce point (mode goret ON). On doit donc se limiter aux tags de Django même s'il est à noter que sa souplesse nous autorise à utiliser un autre système de template ou à étendre celui existant. Quelques tags m'ont fait sourire car on sent bien l'adéquation aux cas rencontrés. A titre d'exemple, pour les boucles 'for', le 'forloop.counter' permet de savoir le nombre de fois qu'on a parcouru la boucle, le 'forloop.last' (booléen) permet de savoir si c'est le dernier élément de la liste parcourue (et donc, de ne pas mettre de "|" après le dernier élément d'une liste pour un menu par exemple. Le 'forloop.first' existe également). Bref, par expérience, des « tags malins » et une syntaxe 'template' très propre. L'héritage de template devrait permettre de garder une organisation propre tout en offrant un maximum de possibilités (à tester avec des cas m'ayant posé des soucis avec Rails).

Un autre point particulièrement soigné de Django, ce sont les pages d'erreurs. Du bonheur ! Contrairement à celles de Rails, elles permettent réellement d'aider à débugger. Ça dépasse largement le cadre de la page d'erreur. Rails devrait s'en inspirer.

La suite au prochain épisode.


9/30/09

Mémo Mac


Fermer une application qui ne répond plus :
CMD-OTION-ESC (équivalent du CTRL-ALT-SUPPR de l'autre)

Applications qui se lancent au démarrage :
Préférences Système > Comptes > Ouverture

Quelques raccourcis :
CMD-A Tout sélectionner
CMD-X Couper
CMD-C Copier
CMD-V Coller
CMD-Z Annuler
CMD-F Chercher
CMD-T Ouvrir un nouvel onglet
CMD-K Se connecter à un serveur
CMD-Q Quitter l'application
CMD-I Ouvrire la fenêtre d'informations (I comme Info)
CMD-TAB Cycler à travers les applications ouvertes
CMD-`(sur MacBook) Cycler à travers les fenêtres d'une même application
CMD-SHIFT-N Crée un nouveau dossier
CMD-L Créer un alias (L comme Link)
CMD-D Dupliquer un objet

Réduction de fenêtre dans l'icône de l'application (Snow only)
Préférences Système > Dock
Cocher « Réduction des fenêtres dans l'icône de l'application »


9/27/09

Readability


AVANT READABILITY


Appliquée à la plupart des blogs, le « web design » est une discipline totalement futile qui consiste à définir une charte graphique pour ensuite la massacrer à grands coups de verrues publicitaires. Que dire de cette fâcheuse manie d'occuper le premier tiers de la page avec un bandeau ? Ça vous viendrait à l'idée de mettre une enseigne de magasin qui vous oblige à baisser la tête pour entrer ? Ne parlons pas de cette fameuse colonne de droite qui sert souvent de dépotoir à publicités et des 3 à 4 secondes d'effort qu'il faut parfois pour trouver le texte à lire. Le « web design » des blogs vient trop souvent fusiller l'ergonomie et le plaisir du lecteur.

Il n'est déjà pas naturel de s'adapter à X chartes graphiques, à X polices, à X tailles de polices au gré de nos visites, alors, quand certains poussent le vice jusqu'à encadrer leur prose de publicités, ça devient tout simplement insupportable. On peut vouloir devenir la « F1 des blogs » sans pour autant devenir un « TF1 du web ».

Je vois pas mal de blogueurs se poser des questions au sujet des flux RSS. Je crois qu'ils ont raison de se poser cette question. J'avoue que si je suis abonné à un flux, je ne vais que très rarement sur le site et si je suis obligé d'aller directement sur un blog (par exemple un lien cité par le blogueur), cliquer sur Readability est devenu un réflexe.


APRES READABILITY




9/26/09

Trackpad MacBook vs MacBook Pro


Je viens de voir qu'il y a quand même pas mal de différences entre les possibilités offertes par le trackpad du MacBook et celles du MacBook Pro. Evidemment, les possibilités les plus « magiques » à l'utilisation ne sont malheureusement disponibles que sur le MacBook Pro (par exemple, « feuilleter » un PDF sur un MacBook Pro est un vrai plaisir). On se fait très vite à la navigation à 3 doigts. A titre d'exemple, j'utilisais peu Firefox jusqu'à sa version 3.5 parce qu'il n'était pas possible de revenir en arrière en utilisant cette possibilité du trackpad (il n'y avait pas que cette raison mais elle en faisait partie). A l'usage, augmenter la police d'une page avec 2 doigts est tout aussi pratique surtout lorsqu'on a la vue qui baisse :/

La différence la plus notable reste la qualité du trackpad lui-même. Celui du MacBook Pro est nettement plus précis.

Voici une courte vidéo qui indique ce qui est « possible » ou « impossible » avec le trackpad d'un MacBook.

9/25/09

Passer de PC à Mac


Ça y est ! le Mac du fiston est arrivé. Commandé Mardi, livré aujourd'hui, c'est du rapide.

Compte tenu que mon fiston ne le sait pas et qu'il va l'apprendre en lisant cet article, il risque de s'arrêter ici et descendre les marches 4 à 4 pour venir le chercher :p Je continue donc pour les autres (et pour lui, mais plus tard) ^^

Une fois l'objet récupéré, il risque évidemment de galérer un peu au départ comme cela m'est arrivé il y a un peu plus d'un an. Je vais donc profiter de l'occasion pour livrer quelques ressources afin que la transition se passe au mieux (pour lui comme pour moi si vous suivez ma pensée). Ça n'a pas la prétention d'un didacticiel mais juste d'une rapide prise en main pour un utilisateur « averti ».

Passage de PC à Mac : les bases
On a l'impression que le commentateur parle à un débile mais les informations sont pertinentes pour un débutant Mac.
Pour ouvrir une application, j'utilise plutôt cmd + barre d'espace et je tape le début du nom du logiciel dans la barre de recherche de Spotlight (en haut à droite). Ça évite de passer par le finder et tout ce qui m'évite de passer par le finder est bon pour ma santé (et oui... tout n'est pas idéal dans le monde Mac et j'avoue que je n'aime pas du tout le finder).

  • Aller tout de suite activer « Exposé et Spaces » dans les « Préférences Système ». Et oui, dans la famille, on a élevé les enfants au biberon Linux et quand on a connu les bureaux virtuels, il est difficile de s'en passer (cmd + barre d'espace -> taper "Pref" et entrée pour accéder aux « Préférences Système »). Tu règles cela comme tu veux, personnellement, j'ai repris mes habitudes "linuxiennes" :  [1] curseur en haut à droite =  équivalent F3, [2] curseur en bas à droite = voir tous les bureaux, [3] curseur en bas à gauche = montrer le bureau. Lorsqu'on est en [2], on peut déplacer n'importe quelle application d'un bureau à l'autre et encore plus facilement si on a fait [1] avant de faire [2]. Je n'ai toujours pas compris pourquoi il n'était pas activé par défaut (disons plutôt que j'ai peur de comprendre).
  • Tant que tu es dans les applications,  « clavier » puis cocher la case « Afficher le visualiseur clavier et caractères dans la barre de menus » car, toi aussi mon fils, tu vas connaître le grand jeu offert par Apple à tout nouvel utilisateur : « Mais bordel de m*rde ! comment je fais pour taper ce caractère ? ». Donc, au départ, avoir tout le temps ce petit utilitaire à portée de clic te permettra de garder ton calme.
  • Aller dans le répertoire « Applications » et drag & dropper le « Terminal.app » dans le Dock (la barre du bas). Ouf ! sauvé !  « Darwin Kernel » te répond en live \o/ Y a plus qu'à te créer ton petit .bash_aliases, .bashrc, .bash_profile et c'est le bonheur (parce que « brut de fonderie » le Mac est un peu léger de ce côté là, on ressent la philosophie « full clicodrome » d'Apple).
  • Tu peux virer le mail, l'agenda et le carnet d'adresses du Dock puisque SASAIMIEUX™(teste avant quand même « au cas où » mais personnellement, je les ai viré)
  • Penser à aller régler le trackpad également car, par défaut, c'est aussi léger de ce côté là. Voici le panel du trackpad de papa pour info ^^ Passer un peu de temps là-dessus n'est vraiment pas une perte de temps. C'est la première fois que je ne branche pas une souris sur un portable tant l'ergonomie apportée par le trackpad d'Apple peut être qualifiée de « magique ».
Logiciels :
  • C'est vrai mais SASAIMIEUX
  • SASAIBIEN™mais SASAIMIEUX™surtout depuis la 3.5; En fait, ce n'est pas que Safari ne soit pas bien, c'est surtout la gestion des onglets que je n'aime pas. Lorsqu'on ouvre beaucoup d'onglets, Safari propose un menu déroulant pour accéder aux onglets qui ne sont pas visibles (vraiment pas pratique) alors que Firefox offre la possibilité d'un scrolling des onglets nettement plus ergonomique). L'abonnement à un flux RSS depuis Safari ne me plait pas également. Ce n'est peut-être pas grand chose pour vous mais c'est déjà beaucoup pour moi. ^^
  • OpenOffice.org parce que je sais que tu en auras besoin (il y a NeoOffice également mais bon...). Personnellement, Google Docs me suffit amplement.
  • Growl fait partie des petits « plus » qu'on apprécie à l'usage.
Reste à expliquer comment on installe les logiciels sur un Mac mais c'est tellement basique que ça ne mérite pas qu'on s'y attarde (suffit de drag&dropper le logiciel dans le répertoire « Applications » depuis la fenêtre qui s'ouvre et de penser à demonter le volume depuis le bureau lorsque c'est fait pour le cas d'un .dmg)

La suite au prochain épisode.

CTRL-I des années 60



vidéo originale (via iTunes)


Je ne supporte pas d'être agressé en permanence par la publicité mais, paradoxalement, j'aime beaucoup regarder les publicités vintages (et tout spécialement celles des années 50 et 60). C'est sans doute leur côté naïf et rafraîchissant qui me plait autant. J'aime bien me sentir au pays des bisounours. Ça me repose.

En me baladant sur ce site, je suis tombé sur cette publicité d'IBM qui m'a évidemment fait sourire. Ça peut se résumer à « il faut moins de 5 secondes pour écrire en italique ». Je présume qu'il devait y avoir un bonus d'environ 5mn pour enlever l'encre sur les doigts.

Finalement, on s'est mis à tripoter des bits pour éviter de tripoter des boules. C'est beau le progrès !

9/21/09

Keep it simple


3 mots qui résument assez bien ma tendance générale depuis 2 ans ^^

Sur Mac, Fluid permet de lancer un site dans une fenêtre dédiée comme Prism. Fluid est toutefois mieux intégré à l'environnement Mac. Il utilise le moteur Webkit contrairement à Prism qui utilise évidemment le moteur Gecko. Très pratique pour séparer son mail (Gmail) ou son agrégateur de flux lorsqu'on utilise Greader. Je passerai sous silence le peu de reproche que je lui fais (ça concerne essentiellement les pièces jointes téléchargées).

Je trouve iPheeds particulièrement pertinent pour rendre son blog plus facilement consultable sur iPhone. iPheeds utilise le flux RSS du blog et affiche les news sous cette forme sur votre iPhone. Le rapport temps_de_mise_en_place/résultat est imbattable pour apporter un gros plus en confort de lecture.

On l'aura compris, en 2 ans d'absence, j'ai eu le temps de m'équiper d'un iPhone et d'un Mac comme poste utilisateur (MacBook Pro pour être précis). Il va falloir que je change mon iPhone vieillissant (1ère génération) et j'ai envie de me laisser tenter par une solution Androïd. Si quelqu'un a eu l'expérience des 2 types de téléphone, qu'il n'hésite pas à lâcher son avis sur le sujet en commentaire. Vu la fréquentation de ce blog délaissé depuis 2 ans, je ne rêve pas et j'ai réellement l'impression de lancer une bouteille à la mer... ;) Pas exclu non plus que je repasse sur un poste Debian car la dernière mise à jour du Mac en Snow m'a passablement agacé (quand on développe un peu, c'est le bronx cette mise à jour 64b).

En espérant que le prochain article ne sera pas publié en 2011 ^^