Duncan Idaho a écrit 815 commentaires

À propos de l'experience et de mes motivations. 1000 excuses, c'est pas super bien écrit et il manque plein d'accents, je suis au boulot je peux difficilement passer plus de temps sur ce pavé).

J'ai malgré moi dû me convertir au developpement web il y a quelques années pour manger (je ne suis pas vraiment developpeur). J'ai découvert des horreurs (PHP) et des technos super cool (MODx—meme si c'est du PHP, et Javascript/Node.js) qui m'ont vraiment éclaté.

Ça faisait longtemps que je voulais faire quelque chose avec les nouvelles technos client/serveur completement en Javascript, et Meteor s'est imposé comme la techno que je voulais utiliser. J'avais testé Express (autre framework pour Node.js) que j'avais trouvé fascinant mais qui m'avait vite decouragé, parce qu'il y a énormement de travail de plomberie avant d'acceder au code metier. Meteor n'a pas ce defaut: il permet vraiment d'attaquer directement la partie qui importe (et pour un programmeur, la partie juteuse du projet, celle qui motive).

Sur les difficultés rencontrées: d'abord je suis une merde en HTML/CSS et c'est vraiment un truc qui me rebute (et ça se voit plutot pas mal dans ce projet). Autant le reste du code était un bonheur à écrire, autant j'ai eu l'impression de perdre des heures à le connecter pour en faire une interface utilisateur. Pour le coup ce n'est pas de la faute de Meteor, qui simplifie enormement la tache en proposant une version adaptée de Handlebar.js.

Les concepts de Meteor sont un peu difficile à appréhender au debut. Il laisse beaucoup de liberté pour organiser son projet comme on veut, et ça peut vite devenir le bordel (ce n'est pas un framework). Le principe des publications/inscriptions, très puissant, est aussi un peu difficile à comprendre au debut. Dans l'idée, le serveur met a disposition du client des informations de la base de donnée. Le client a sa propre base de donnée et son propre systeme de base de donnee, minimongo—un mongodb simplifié. Du coup, il faut generalement refaire les mêmes requêtes côté client et côté serveur. Au debut on a l'impression que c'est redondant et peu efficace, mais c'est un chouilla plus subtil.

Les publications (la mise a disposition d'information côté serveur) permettent de sécuriser un peu ce que l'utilisateur peut voir sur le site en fonction du contexte. Par exemple, dans mon projet il y a différentes publications qui mettent à disposition des informations provenant de la meme base de donnée. Ainsi, lorsqu'un client est sur la page d'accueil, il a acces a son propre document (son propre profil), à la liste de ses amis (une version tres light des profils, surtout pour recuperer le nom et la photo de profil), à ses amis en ligne (qui intersecte necessairement avec la liste de ses amis). Vous pouvez le testez vous meme: allez voir la demo et tapez Meteor.users.find({}).fetch() pour voir quels infos de la base Meteor.users vous pouvez voir. Du coup, côté client il faut organiser ces informations et refaire des requêtes pour séparer ses amis de soit-même lorsqu'on manipule les informations.
Si je visite le profil de quelqu'un, le contexte change et une publication me donne les informations pour ce profil.

En gros, on fournit au client les données et la logique, et il se demerde pour faire le rendu. Si vous voulez jouer, tester Collection.find({}).fetch() dans la console, em remplacant Collection par, au choix, Friends, Messages, Conversations, Notifications… pour voir quels informations sont dans votre BDD.

Maintenant, lorsqu'un document est ajouté/retiré/mis-à-jour dans la base de donnée, et que je suis inscrit a une publication qui diffuse ce document, ma mini-base de donnée côté client est automatiquement mise-à-jour. C'est là ou ca devient un peu compliqué: il y a tout un système de dépendence entre les Templates (bout de DOM utilise pour generer le rendu) et la base de donnée. En gros, si j'ai une Template qui utilise des informations de la BDD, Meteor va décider ou non de refaire le rendu de la Template, de la mettre a jour ou de ne rien faire lorsque la BDD est mise-à-jour. C'est de là que viens la réactivité, mais ça peut aussi etre terriblement chiant. Par exemple pour la création de profil, quand on clique sur "Save", le document de l'utilisateur est modifié , et ca devrait donc refaire le rendu de la page, puisque les champs de formulaire dependent de la valeur du profile utilisateur si elle existe. Du coup il m'a fallu déclarer que les informations que je récupere sont non-réactive, pour bloquer la mise-à-jour automatique de cette Template en particulier (jetez un oeil a client/views/includes/form/form_fields.js, la fonction en haut retourne la valeur a mettre pour un champ lorsqu'on génère un formulaire, notez que la dependance est bloquée en utilisant reactive: false).

Autre exemple un peu tordu qui m'a pris un peu de temps à concevoir, lors de la recherche d'utilisateur. Dans à peut prêt n'importe quel autre système, le client fait une requête du genre "Envoie moi tous les gens qui sont X et Y", le serveur fait la recherche puis renvoie une liste au client. Cette facon de faire serait tres inefficace avec Meteor, puisqu'il est très possible que certains utilisateurs soient dejà dans la base de donnée côté client, mais aussi parce que le serveur devrait retourner une liste d'utilisateur sous forme de liste qu'il faudra ensuite manipuler côté client—pourquoi faire ça alors que le client dispose de sa propre BDD? Du coup l'astuce consiste à demander au serveur de metter a jour une publication (qui, comme les templates précedemment, depend cette fois d'une variable de Session 'searchQuery'—si cette variable change, la publication est recalculée), lorsque le serveur a finit de mettre a jour la publication, il met a jour une autre variable de Session côté client ('searchQueryDone'). Côté client, j'ai une template qui depend de cette variable (et non pas des donnees, sinon ma page de recherche clignoterait a chaque fois qu'un nouvel utilisateur se creerait un profil par exemple), qui va donc se mettre a jour en utilisant les informations de la base de donnée ET refaire la requete locallement.

Là où Meteor brille, c'est qu'il s'occupe comme un grand d'optimiser tout ça, d'envoyer les bonnes informations au client, de refaire le rendu des parties concernées par les changements. Quand ça marche, c'est magique et vraiment super simple a faire fonctionner. Quand une heuristique foire (typiquement, dependance un peu severe, ou tout simplement lorsque Meteor n'arrive pas a faire un diff propre d'un bout de DOM avant/après), ca devient une super prise de tête.

Un dernier exemple pour la route, parce que ma matinee est foutue de toute facon. Imaginons que l'on veuille rajouter un nouveau widget qui affiche la liste des amis communs entre soit-meme et la personne dont on regarde le profil. La liste de mes amis est deja publie et disponible. La liste des amis de ma cible est publie lorsque je visite son profil, j'ai donc toutes les informations a disposition, rien besoin de changer cote serveur. La collection "Friends" indique que A est en relation avec B (et il y a un document de B vers A si la relation est reciproque). Bout de JS que vous devriez pouvoir tester chez vous avec firebug ou la console de Chrome:

var myFriends = Friends.find({me: Meteor.userId()}).fetch(); // mes amis a moi.

// 'currentUserProfile': variable de Session contextuellement mis a jour pour indiquer quel profil on visite.
var hisFriends = Friends.find({me: Session.get('currentUserProfile')}).fetch() // Ses amis a lui.

var myTargetIds = [], hisTargetIds = [];
myFriends.forEach(function(f){ myTargetIds.push(f.target) }) // la liste des _id de mes amis
hisFriends.forEach(function(f){ hisTargetIds.push(f.target) }) // la liste des _id de ses amis.

var commonFriendsIds = _.intersection(myTargetIds, hisTargetIds); // _ -> underscore.js, propose ce genre de fonctions pratiques.

// De la, on fait ce qu'on veut, par exemple:
var commonFriends = Friends.find({_id: { $in : commonFriendsIds}}) ; // Extrait de la base de donnee les amis communs, retourne un pointeur facile a manipuler.

Et voila! Le mega-pavé.

Ouais, la demo deconne pas mal et il y a enormement de bugs que je ne retrouve pas sur les versions locales (testees sur differentes configuration). C'est le serveur de deployment gratuit de Meteor, je pense que le debit et la latence pose probleme.

Elle est la, c'est tout chaud.

La demo

C'est ce que j'ai regarde ce matin, mais il faut apparemment installer un composant "mongoDB" et le tout etait estime a 50US$ par mois, du coup j'ai laisse tomber.
Meteor propose sa propre plateforme pour deployer des applications gratuitement, mais ca n'a pas marche.

Accessoirement aussi, j'ai un vrai boulot pour manger et je n'ai pas pu y passer autant de temps que je voulais, je re-tenterai plus tard.

(desole, qwerty).

Aucune idee, je n'ai jamais utilise Django.

Ce que je peux te dire de l'approche de Meteor, c'est:
- se reposer sur des librairies/framework existant, pour ne pas reinventer la roue (typiquement LESS/HandlebarJS)
- un systeme de publication/inscription bien foutu, avec une base de donnee simplifiee cote client, alimentee/synchronisee par la "vraie" base de donnee cote serveur. Le client a donc son propre jeu de donnee qu'il manipule comme il veut, tout le rendu se fait cote client, le serveur se borne principalement a delivrer les bonnes informations. Ce pourquoi c'est une "webapp" et pas un site web. En gros le client recoit l'application + les donnees du serveur, et construit son site web tout seul.
- c'est reactif. Si A change un truc qui affecte B, B est mis a jour tres rapidement. Seul les parties concernes dans le rendu de B est mis a jour. C'est la partie un peu technique et difficile a manipuler a mon avis. Typiquement dans Socialite, si A envoie un message a B, B recoit une notification immediatement. Ca se base sur websocket & Co.

Pour le reste, ce n'est pas un framework a proprement parler. Il impose peu de structure ou de convention, et beaucoup de l'API expose concerne en fait des framework integre avec Meteor, pas Meteor en soit.

Ben j'ai regardé pour la demo, mais ça va me couter des sous à héberger où que ce soit, pour un truc que je ne vais pas administrer et où les gens vont inévitablement poster des photos de pénis.

Donc non, pas de demo pour le moment, mais ça devrait tourner super facilement en local, il faut juste node.js et npm, les dépendances devraient être résolues automatiquement.

Ta mère est tellement grosse qu'Arthur a appelé pour récupérer ses blagues des années 90.

-> []

Depuis quelques annees, parce que je suis un sale type, je m'amuse a ne pas souhaiter la bonne annee (sauf effectivement, aux gens a qui je la souhaite reellement). La regle est simple, pas plus de 10 "Bonne annee", aux autres, je repond un franc "Merci!" quand il me la souhaite.

Personne n'a vraiment jamais remarque que je ne leur repondais pas ce qu'il fallait, ca fonctionne tres bien.

Alors moi je bois mon thé comme les vrais.

D'abord, je le laisse infuser pendant des plombes avec de l'eau très très chaude. Je m'en sers pour laver mes baguettes, ma tasse, mon bol et ma cuiller, parce que j'ai pas confiance. En vrai, quelqu'un le fait pour moi parce que moi j'ai un pénis. Du coup quelqu'un de gentil vient remettre de l'eau très chaude dans la theiere.

Ensuite, je m'enfile une dizaine de tasses, tout en baffrant des trucs gras. On remplit la theière un paquet de fois sans jamais changer le thé, d'ailleurs je sais pas ce que c'est comme thé. Il n'y a pas de filtre dans la théiere, du coup on mange aussi un peu de th a chaque fois. Souvent d'ailleurs, il y a une theière d'eau chaude, une theière de thé, comme ça on fait le mélange soit même. Ca se marie très bien avec le porc, le boeuf, les fruits de mer, les trucs verts, les trucs jaunes. La bière aussi d'ailleurs.

Sinon la journée je bois ca:

C'est du thé bête, froid, sans sucre sans rien. J'en bois des litres.

Je n'ai pas ce modele, mais celui tout en metal (en vrai, je dois en etre a ma troisieme, parce que je les ai fait bruler plusieurs fois), et ca fait de loin mon cafe prefere.

Ouais, il est brulant, ouais, c'est chiant quand tu veux refaire une tournee et que la cafetiere est proche de la fusion, mais le cafe obtenu est super. Il faut aimer le cafe corse…

Associe a un moulin a cafe, c'est le bonheur.

J'aime bien la skin du Typematrix, le contact est doux, la frappe est bonne (je viens de tester, 80MPM en qwerty). Mais surtout, si je garde la skin, c'est parce que c'est propre: je peux la laver facilement et je suis sur qu'il n'y a pas plein de miettes, de poils ou autres saloperies coincees dans mon clavier. S'il y en a sur la skin, je l'enleve facilement. Je passe un coup de coton avec de l'alcool de temps en temps pour nettoyer (tres rarement en fait, puisque la skin reste propre).

Puisqu'en en est a parler du TypeMatrix, j'en suis super fan. J'adore la frappe et le confort, mais j'adore aussi qu'il soit relativement compact, du coup je peux le trimballer facilement avec mon portable et garder toujours le meme confort de frappe pour bosser/developper.

MAIS TA GUEULE !

Je me repond a moi meme parce que je suis un connard pretentieux:
Real World Haskell semble etre un tres bon debut. Je m'en rejouis d'avance!

L'article est interessant, et j'adore les discussions dans les commentaires.

Un detail qui me chagrine un peu toutefois: est-ce possible de trouver un article/documentation/point de vue qui ne presente pas la programmation fonctionnelle sous l'angle "faisons une factorielle ou un quick sort, vous allez voir c'est epatant". Effectivement, c'est toujours epatant, mais j'avoue avoir du mal a relier ca au vrai monde.

Quand je programme autre chose qu'un exemple jouet pour m'amuser, je ne reimplemente pas le quick sort. Je fais des operations basiques genre "valider les entrees utilisateur", "iterer sur des lignes de ma base de donnee", "construire une reponse pour l'utilisateur"… Ce sont des cas completement triviaux qui, au pifometre, represente la majorite du travail de developpement pour la majorite des developpeurs. Je me pourleche quand je dois ecrire un algo de parcours de graphe un peu marrant, mais ca arrive… une fois par an. Dans les autres cas, je ne vois pas bien ce que la PF peut m'apporter:
- d'une part, je ne trouve pas d'introduction a la PF sur de vrais applications
- d'autre part, il est difficile, voir contre-productif de se forcer a faire des fonctions "pures": elles s'en approchent souvent par defaut (pas d'effet de bord), ou alors les rendre pures est inutile (cas typique: je passe a ma fonction un objet qui est mon entree de base de donnee, j'y fait des modifications et je sauvegarde tout ca a la fin).

Je trouve la PF fascinante, j'ai adore en faire et j'adorerait en faire a nouveau (dans un autre registre, j'adore le JS pour ca), mais j'avoue ne pas arriver a faire correspondre cet interet avec ce que je dois effectivement produire a la fin de la journee.

Excellente initiative. Question pratique toutefois: comment on applique la loi francaise pour des oeuvres achetees sur des serveurs a l'etranger, appartenant a des compagnies a l'etranger.

Autrement dit, a part la FNAC (sans doute), qui sera tenu de respecter la loi ?

Exemple, en utilisant MongoDB, comment s'assurer que chaque artiste entré est unique ?

ensureIndex est ton ami. C'est tres puissant et tu as meme des petites sucreries, notamment la recherche spatiale en deux dimensions.

D'une facon generale, tu as raison: la complexite se retrouve deleguee a la partie applicatif. En fonction de ton application ca peut etre un probleme ou pas.

D'un autre cote, le modele document offre une vraie facilite d'utilisation, ca torche un max et les requetes (acces/insertion/mise a jour) sont un bonheur a ecrire et a utiliser (la encore, je parle de MongoDB que j'utilise massivement pour un projet web).

Lu aujourd'hui sur l'excellent Images des Mathematiques, un article tres clair sur differents systemes de vote.

http://images.math.cnrs.fr/La-democratie-objet-d-etude.html

[NSFW!!]
C'est autre chose.
[NSFW !!]

Voila le dernier MacAir qu'on a recu a mon boulot.

Blague a part, je me suis fait refile un Mac Air gratuitement, ca tourne bien sous Linux ?

Tu auras la courtoisie d'aller te faire foutre, connard.

J'ai trollé sur les motos, pas sur ta vie, et je ne te permet certainement pas de commenter la mienne.

Puisqu'on parle de moto. Dans la derniere saison de Mythbuster ils demontrent que les motos, toutes les motos, sont plus polluantes que les voitures en terme d'emission de particules nefastes (pas de CO2).

Des avis ?

Du coup, a part se faufiler dans les embouteillages en mettant en danger un peu tout le monde, ca sert a quoi une moto ?

Allez, on va regarder K2000 !

Erf, c'est marrant de retrouver sur Linuxfr un lien vers l'article d'OWNI sur Linux, qui est un résumé de... l'article de Linuxfr :)

C'était le nom de mon chat. Mais elle a été renommée Marie Louise peu après.

(oui, tout le monde s'en fout, mais c'est un thread sur les noms de chats quand même.)

Son engagement dans l'Europe.

Attends moi !