domenica 23 novembre 2014

coffeescript, alla fine anche le tonde pesano

Coffeescript quasi sempre non ha bisogno di parentesi, tonde, quadrate o graffe.
Non ci si deve preoccupare rispetto a javascript di chiudere nei posti giusti le parentesi graffe dei blocchi, che possono essere lunghi, indentati e quindi spesso la loro chiusura è abbastanza distante dall'apertura.
Se togliere le parentesi tonde negli argomenti delle funzioni può far sembrare il codice meno chiaro, scrivendo codice asincrono di nodejs si impara invece ad apprezzare questa caratteristica.
La riga
fs.readFile '/foo.txt', callback
può sembrare meno chiara rispetto a
fs.readFile('/foo.txt', callback)
Ma questa "callback" è una funzione che spesso viene definita (in modo anonimo) proprio quando viene chiamata, e quindi in javascript sarebbe qualcosa del tipo:
fs.readFile('/foo.txt', function(err, data) {
  console.log(data);
});
la parentesi tonda di chiusura degli argomenti di readFile se ne va quindi alla fine del codice.
In coffeescript se vogliamo mantenere le tonde degli argomenti, diventa:
fs.readFile('/foo.txt', (err, data) ->
  console.log(data)
)
Rimarrebbe quindi la parentesi tonda di chiusura, della quale, sinceramente, si inizia presto a non sentirne la mancanza.
Il codice può quindi essere meglio scritto come:
fs.readFile '/foo.txt', (err, data) ->
  console.log data
decisamente piu' pulito.

Meglio coffeescript, ma gli spazi sono importanti

Considerato che con lo stack MEAN si scrive molto piu' codice javascript rispetto agli altri ambienti, vale la pena usare Coffeescript, che non e' un linguaggio alternativo a javascript, ma un modo diverso di scrivere javascript che il compilatore coffescript produce corrispondenti file .js

Il codice e' piu' compatto, piu' comodo da scrivere e modificare, lo stile del codice e' meno soggetto a scelte stilistiche dei programmatori e quindi risulta piu' leggibile, e alla fine tutto questo garantisce maggiore sicurezza rispetto alla presenza di bug.

Invece di usare parentesi graffe aperte e chiuse, si usa l'indentazione.

Poi scompare il punto e virgola per la fine dell'istruzione e le parentesi per racchiudere gli argomenti sono opzionali.
Pero' richiede anche un po' piu' di attenzione, guardate ad esempio questi due pezzi di codice che hanno una piccolissima differenza:
1:
Anagrafica.findById anagraficaid
 .populate('conto')
 .exec (err, anagrafica) ->

2:
Anagrafica.findById anagraficaid
 .populate('conto')
 .exec(err, anagrafica) ->

ovvero un semplice spazio tra la chiamata ad exec e la parentesi tonda.
Questo spazio per coffeescript fa in modo che i due codici abbiano due significati diversi:

1:
Anagrafica.findById(anagraficaid).populate('conto').exec(function(err, anagrafica) {
2:
return Anagrafica.findById(anagraficaid).populate('conto').exec(err, anagrafica)(function() {
La freccia -> e' il corrispondente di definizione di funzione, function
Quindi entrambe le righe finiscono con la definizione di una funzione.
Ma nel primo caso, gli argomenti tra parentesi tonde (err, anagrafica) essendo staccati da .exec, sono argomenti della function, mentre nel secondo siccome sono attaccati, sono argomenti della .exec e la function e' una funzione senza argomenti.
Nel primo caso gli argomenti della funzione exec non sono racchiusi tra parentesi, perche' le parentesi su coffeescript (quando possibile) sono opzionali.
Quindi
.exec (err, anagrafica) ->
   ...
con lo spazio, corrisponde a
.exec( (err, anagrafica) ->
   ...
)

martedì 18 novembre 2014

5 soluzioni per l'hosting di applicazioni Node.js, anzi 77

Sandeep Panda nel suo post "5 Best PaaS Solutions for hosting NodeJS Apps" propone 5 servizi PaaS (platform as a service) dove fare l'hosting della propria applicazione Node.js:


In questa lista potrebbe essere comprensibile che non ci siano i più generici servizi cloud quali quelli di AWS di Amazon, Azure di Microsoft, Google Cloud Platform, però è strano che non ci sia Heroku, come invece troviamo sul più datato (maggio 2013) articolo "Comparing Node.js Support on PaaS Hosting Providers".

Per fare dei confronti tra le piattaforme, c'è l'interessante sito paasify.it il cui motto è "Find your Platform as a Service!". Non ci sono nel suo elenco DigitalOcean e Linode, ma si possono ad esempio fare dei veloci, es: Heroku vs Nodejitsu, Openshift vs Modulus e comunque selezionando "Node" come Runtimes vengono visualizzati ben 77 vendors

Altri articoli su questo tema:


  • Dic. 2013 code-tricks.com: Top Hosting Service for Node.js la cui lista è: 1. Heroku, 2. Nodejitsu, 3. Microsoft Azure, 4. AppFog, 5. Modulus, 6. Openshift, 7. dotCloud, 8. Clever Cloud, 9. Cloud Foundry
  • Luglio 2013 Where the heck do I host my … Node.js app? 12 opzioni in ordine alfabetico: Amazon Web Services, AppFog, CloudFoundry.com, dotCloud, EngineYard, Heroku, Joyent, Modulus.io, Nodejitsu, OpenShift, Windows Azure


mercoledì 12 novembre 2014

File di configurazione per nodejs: config.js, nconf, config & co.

12 Nov. 2014. Una delle prime cose, se non la prima, che si fa quando si prepara un progetto basato nodejs, è quello di impostare un file di configurazione, che di solito viene chiamato config.js

Con il crescere della complessità dell'applicazione, delle componenti (database e moduli vari) e dei diversi ambienti (sviluppo, produzione, staging, etc. etc.), può essere comodo utilizzare un modulo che agevoli nella impostazione di config, delle sue variabili e dei diversi valori che devono avere.
Una ricerca della keyword "config" su npmjs.org , il repository dei moduli per nodejs, produce centinaia di risultati (o più precisamente 5 pagine da 100 risultati circa ognuna, anche se non tutti si riferiscono alla generica configurazione di nodejs, ma ad aspetti o funzionalità specifiche).

Tra questi si possono selezionare i seguenti:
Ma quale scegliere? (spoiler: propongo convict)

I numeri su github

Un pò di numeri su github riassunti in una tabella:
nconfnode-convictrckonphygfigc
contributors
25
121151
stars13431941959011
fork922224112
Su npmjs.org abbiamo invece questi numeri:
nconfconvictrckonphygfigc
downloads in the last month
194k
7k532k1k0.5k
last updateda year ago14 days ago9 days ago8 months ago2 years ago
Version0.6.90.5.10.5.41.4.00.0.3
Il numero di download si riferisce a metà novembre 2014

Ad una prima occhiata il vincente sembrerebbe essere nconf.
Ma sono solo indicatori, perché la scelta di un modulo piuttosto che un'altro si basa sulle proprie esigenze e come vengono soddisfatte.
Comunque i contendenti sui quali puntare potrebbero essere principalmente due: nconfconvict

Gli autori: Mozilla vs Nodejitsu

Anche se abbiamo visto dai numeri di github che nconf ha 25 contributors, il programmatore di riferimento è il NewYorkese Charlie Robbins alias indexzero di Nodejitsu.
L'autore di convict è invece la comunità di sviluppatori di Mozilla, sicuramente una garanzia di qualità.
Bisogna considerare che dietro nconf c'è Flatiron, un framework per costruire applicazioni con Node.js e forse per questo si spiegano numeri più alti di quelli fatti dal modulo di Mozilla.
E' comunque simpatico notare che sul blog di nodejitsu c'e' un post di Marzo 2014 sul suo concorrente convict.

Alcune caratteristiche

Validation

Un file di configurazione sbagliato significa un sito che non funziona, per cui è comodo che i parametri possano essere controllati automaticamente da un validatore.
convict ha nativamente questa funzione, per nconf c'è comunque il plug-in nconf-validator

Coercion

Convict forza le variabili al loro formato richiesto, per esempio nel caso di numeri passati come stringhe.

Chiarezza contro complessita'

Le configurazioni impostate con convict sembrano essere piu' chiare e leggibili rispetto a quelle di nconf. Anche se nconf ha le funzioni di impostazione separate ed utilizzabili liberamente, la rigidita' di convict in realta' rende la configurazione molto piu' chiara e piu' leggibile, e per questo piu' solida e meno soggetta a pasticci e conseguentemente bug: e quando si trasferiscono gli aggiornamenti dagli ambienti di sviluppo a quelli di test e poi in produzione, l'ultima cosa che si desidera e' quella di perdere tempo a capire perche' un deploy che funziona nell'ambiente di test non funziona invece nell'ambiente di produzione, le cui differenze dovrebbero essere chiare nel file di configurazione.

Alcuni articoli utili sul tema