"text-editor that's like 50 years old and whose key-bindings are based on Klingon"

DarKeep> au bout d'un moment, faut se rendre compte d'un truc : toute la littérature technique intéressante, ou presque, est en anglais.
Et plus on parle de technique/langage récent, moins tu trouveras de ressources dans ta langue si ce n'est pas de l'anglais.

Je suis désolé, l'article en question n'a pas de traduction. Mais si tu as envie d'évoluer dans la programmation en te limitant au français, tu seras vite limité.

Ceci dit, je ne suis pas du tout un "j'parle english j'suis tro for lol", loin de là : je le lis, je le comprends, je peux vaguement l'écrire, et à l'oral, c'est une catastrophe
Mais si tu veux rester à la page sur les technos web récentes, t'as pas trop le choix.

Sur ce topic, on parle de node.js, et au final, malgré mes recherches, il y a vraiment très peu de contenus web en français sur node. Et encore moins de contenus web pertinents et de bonne qualité sur ce sujet en français.

Donc voilà, au bout d'un moment, faut se sortir les doigts du cul et arrêter le franco-centrisme : t'as beau ne pas être d'accord, le milieu tech s'exprime en anglais, c'est comme ça et ça ne changera jamais.

ps: c'est en forgeant qu'on devient forgeron : je me sens bien meilleur en anglais depuis que je me force à lire des articles en anglais ;)

G RI hipster vs. franco-centriste

@Lisarael: même si DarKeep fait un peu son trollll, c'est vrai que les ressources fr c'est quand même sympa. Par exemple là je mate des tuto vidéo grafikart qui permettent d'introduire pas mal de technos (je viens d'apprendre qu'on pouvait faire des applications desktop en node... ).

Quand t'as pas envie de te concentrer ou quand tu as envie de vite rentrer dans le sujet, un tuto video de qualité et dans ta langue c'est quand même le TOP !

MAIS comme tu le dis, les meilleures ressources sont en anglais.

J'dis pas que ça n'existe pas, j'dis juste que tu as vraiment peu de *bonnes* ressources en français sur les technos récentes.

Grafikart fait du super boulot et essaie de traiter un max de nouveaux trucs, mais bon, voilà, au bout d'un moment, faut se rendre à l'évidence : l'anglais est indispensable si tu veux progresser.

Je m'en suis rendu compte quand j'ai commencé à publier des trucs sur github : t'as beaucoup plus d'utilisateurs et de retours si tu prends la peine de documenter tes trucs en anglais plutôt que dans ta langue maternelle.

Je me permet d'upper le topic pour vous demander où vous avez appris à utiliser Node.js ?
Vous avez suivi des formations ou vous y êtes allés directement avec la doc ?

J'aimerais bien m'y mettre mais tout le monde ne code pas de la même manière et j'aimerais prendre des bonnes habitudes dès le début.
Merci

Perso, en commençant avec les 10 lignes d'example qu'on voit sur le site officiel, puis en regardant la vidéo d'introduction anciennement featurée sur le site officiel[0], et après en me référant à la doc.

Le tout couplé à un moteur de recherche pour les situations où je ne sais pas comment faire pour arriver à mes fins, et à NPM pour chercher parmis l'écrasante quantité de librairies disponibles.

[0] http://youtu.be/jo_B4LTHi3I

De mon côté, un p'tit survol de la doc, puis le cours de codeschool pasque leur système d'exercices corrigés en ligne est vraiment pratique pour partir du bon pied, puis pareil que vava, google/stack overflow pour les cas spéciaux, et npm pour les libs, avec depuis quelques temps l'ajout de toute une tripotée de libs persos dans npm, des fois que ça pourrait servir à d'autres.

Et pour le JS dans sa globalité (donc node mais pas que), je te conseille de bookmarker http://www.echojs.com, ton nouveau meilleur ami

vous connaissez un module nodejs qui permettrait de charger une page html dans une variable pour faire des analyse sur le DOM ?

TrollDieu :

Charger une page (d'après la doc) : http.request[0], http.get[1], ou http.ClientRequest[2].

[0] http://nodejs.org/api/http.html#http_http_request_options_callback
[1] http://nodejs.org/api/http.html#http_http_get_options_callback
[2] http://nodejs.org/api/http.html#http_class_http_clientrequest

DOM, d'après une recherche sur le web (j'ai jamais testé le module en question), tu as `jsdom`[3] qui semble populaire (et qui peut apparemment abstraire la partie chargement de page).

[3] https://github.com/tmpvar/jsdom

TrollDieu> j'ai déjà utilisé jsdom, qui est sympa, mais tu as aussi cheerio (https://github.com/cheeriojs/cheerio), que j'utilise sur quelques projets et qui très, très chouette, à toi de choisir celui qui convient à ce que tu as besoin de faire.

merci,
j'ai essayer d'utilisée jsdom mai pas de chance pas encore installer Visual studio express sinon il a l'air pas mal.

sinon cheerio est super bien je pense que je vais plus pouvoir m'en passer

yop,

Comment se passe le cache sur nodejs ? Vous connaissez des modules pour ça ?

Ça dépend un peu ce que tu veux cacher... express a des middlewares de cache bien foutu si tu bosses avec express, et si c'est pour cacher des données plutôt que des pages, je te conseille de te pencher sur Redis, qui est juste hallucinant en terme de performances.

Je pensais à une gestion de cache à la django (cache de vues, de fragments de templates ainsi que bas niveau) sans que j'aie à tjs me préoccuper du système de cache. (pouvoir passer d'un système de cache fichier, à redis ou bdd.. sans trop de difficultés)

Qui permettrait d'également de définir une expiration. Il me semble que sur redis c'est possible.. Par contre je crois qu'on ne peut pas le faire sur le contenu particulier d'un hash..

S'il y a aussi des triggers à la CppCMS genre ça : http://cppcms.com/wikipp//en/page/cppcms_1x_adv_caching , ça serait pas mal..

En fait je ne demande pas spécialement un framework, juste pour savoir si ça "existe" déjà sur node.. ou s'il faudra le coder soi même.

Je ne savais pas qu'Express le proposait, j'irais voir.. (oui je pose une question avant de google, pas bien ..)

Vu le nombre de packages dispos sur npm, ça doit sûrement déjà exister.
Après, faut voir si ça correspond à tes besoins.
Y a quelques mois je cherchais un système de cache in-memory simple, avec fallback vers du json, et ce qu'il y avait sur npm était soit incomplet, soit pas fini... au final, j'ai codé le mien.

J'ai une question :

Jviens de jeter un coup d'oeil à node, un pdf dessus, et j'vois les mecs qui mettent dans leurs modèles mongoose.connection("...") et n'utilisent pas de mongoose.disconnect()

Donc en fait ils importent souvent leurs modèles... Ca pose pas de problème ? Ca crée combien de connexions ?

Pareil pour redis...

Perso je fais en sorte que les connexions ne se font qu'une fois, mais dans les faits, les connexions à Mongo et Redis sont très peu gourmandes si tes scripts tournent sur la même machine... ceci dit, en termes de perfs, vaut mieux privilégier une seule connexion, tant qu'à faire.

Après, concernant ta question sur l'importation dans node, il faut savoir que quand tu fais un "require( 'module' )", le code n'est exécuté qu'une seule fois et sa référence mise en cache.

Ah ok, mais du coup il y a des déconnexions ou elles restent en permanence ouvertes à chaque utilisation d'un "require()" pour un modèle différent ? (vu que tu dis que la référence est en cache..)

En gros ça veut dire que si on a utilisé 100 modèles, ça fait 100 connexions ? (tant qu'on "kill" pas le process)

ceci dit, en termes de perfs, vaut mieux privilégier une seule connexion, tant qu'à faire.

Comment fait-on en pratique ? C'est mieux de faire passer l'instance de connexion aux middlewares et fonctions que d'utiliser une variable globale ?

Merci de prendre ton temps de répondre aux questions sinon.

Ben en fait non, ça dépend comme se fait ta connexion.

Admettons que tu ais un module "db.js" qui fait ta connexion, et qui expose l'instance de la db en membre public de ce module (via exports ou module.exports).

Ensuite, tu as trois modèles A, B & C. Dans chacun, tu fais un "var db = require( 'path/to/db.js' );". Le premier a être exécuté, disons A, exécutera aussi le module db.js, qui fera la connexion et exposera l'instance. Ensuite, B s'exécute, et le moteur interne de node voit la ligne du require, et regarde en cache si ce module n'est pas déjà exécuté, et comme c'est le cas, affecte à la variable db, dans le module B, la référence au module en cache.

Tu n'as donc qu'une seule connexion, quel que soit ton nombre de modèles, en suivant ce principe.

Quant aux variables globales, je te le déconseille. Le plus gros problème de javascript côté client a toujours été l'immense facilité à polluer le scope global, avec les résultats imaginables.
Node.js, via son système de modules, corrige enfin ce problème.

C'est juste un coup à prendre, le système de modules, mais une fois que t'as saisi l'astuce, c'est vraiment un bonheur à utiliser.

En fait pour le coup des 100 connexions, je demandais par rapport à l'exemple que j'ai lu (c.a.d un "redis.CreateClient" par modèle..)

Admettons que tu ais un module "db.js" qui fait ta connexion, et qui expose l'instance de la db en membre public de ce module (via exports ou module.exports).

Si je saisis bien, ce module devient alors une dépendance ? (dans le sens où on pourra bâtir d'autres modules/fonctionnalités indépendants les uns des autres à partir de "db.js"..)

Quant aux variables globales, je te le déconseille. Le plus gros problème de javascript côté client a toujours été l'immense facilité à polluer le scope global, avec les résultats imaginables.

Si je fais un app.set('connection',connection) et que je m'en sers dans les modèles des modules, c'est donc également déconseillé ?

C'est juste un coup à prendre, le système de modules, mais une fois que t'as saisi l'astuce, c'est vraiment un bonheur à utiliser.

Oui ^^ Moi l'idée me plaît bien car on est d'avantage dans l'idée de choisir ce qui est nécessaire à notre application.. Faudrait que jpasse à la pratique maintenant !