4 réflexions sur « Nipdev 30 – NodeJS »

1. Bonjour,

   Je viens d’écouter l’émission 🙂 merci au passage.

   J’aimerais apporter une précision concernant la possibilité dans lancer des fonctions I/O bloquante.
   Il existe sous NodeJS (pour les fonctions natives en tout cas) une version synchrone et donc bloquante des fonctions. Par exemple il est possible de lire le contenu d’un fichier de façon bloquante en utilisant la méthode readFileSync => http://nodejs.org/api/fs.html#fs_fs_readfilesync_filename_options

   Alexandre.

   Répondre

2. Merci parrain de communiquer sur notre nouvelle aventure 😉

   Pour nodejs, un truc un peu bizarre c’est la portée des variables avec les includes, les objets crée à partir d’un fichier inclus par exemple.
   Pour exemple dans un de mes jeux:
   var Map=require(‘./bombermanM_MapB.js’);
   Et dans la classe incluse un « module.exports=Map; »

   Attention à la phrase : « comme il n’y a pas de compilation, il y a des erreurs qui arrivent seulement pendant le runtime »
   Je fais actuellement du C++ et j’ai beaucoup d’erreurs qui n’arrivent que dans le runtime 😉
   Exemple tout bete: on défini un dictionnaire dans son .h sans l’instancier, dans une méthode on fait un ajout dans ce tableu, et bim erreur 🙂

   Répondre

   1. En fait chaque include de fichier retourne un objet export sur lequel tu peux accrocher des variables ou fonctions. Cela permets de retrouver une mécanique de privé/public

      C’est un peu la même ruse que en jQuery avec le pattern ou tu encapsule le ($)

      Dans SARAH cela m’a permis de recharger à chaud des modules sans péter tout le soft

      Répondre

3. Merci pour le Podcast !

   Un des arguments pour lesquels j’ai choisis NodeJS pour SARAH c’est
   1. La simplicité: pas d’IDE, pas de compilation
   2. La popularité tout le monde connait JS c’est le prochain Python

   Le point qui bloque pour les gens c’est l’asynchrone quand ils veulent faire des choses un peu avancées

   Le point « décevant » pour moi c’est l’asynchrone au niveau du serveur web. Cela impose de
   1. Calculer ses données
   2. Faire le rendu

   Ce qui est une bonne approche dans la logique multi device car le backend va servir des données en REST qui seront habillées. Mais on perds en simplicité de rédaction des pages.

   Ensuite il faut réinventer la roue:
   – Sur l’authentification
   – Les logs
   – Le debug
   – Le multilinguisme
   – …

   La gestion des NPM est une horreur car il n’y a pas cette phase de validation de Maven du coup c’est le bordel car on se retrouve avec un arbre de module avec potentiellement des modules redondants

   Vous n’avez pas parlé de PhantomJS ou de Node Webkit ?

   On peut faire des IO Bloquant mais on bloque tout, mais parfois cela a du sens.
   – Au niveau API il existe des méthode « sycn » readSync()
   – Et il y a des lib qui fournisse une manière d’imposer du code synchrone

   Il y a des librairies JS qui sont ensuite compilée en C. Typiquement sur des moteurs 3D

   A noter le Meetup NodeJS Paris
   http://www.meetup.com/Nodejs-Paris/

   Et l’initiative Freelance Academy
   http://www.freelance-academy.fr/home

   Répondre