CoffeeScript, una alternativa a JavaScript…o quasi!CoffeeScript, an alternative to JavaScript…more or less!

16 aprile 2012 Nessun commento

In questo articolo vorrei parlare brevemente di un curioso linguaggio di programmazione che ho conosciuto da poco: CoffeeScript.

CoffeeScript logo

logo di CoffeeScript

Questo linguaggio nasce il 13 dicembre 2009, data in cui il suo autore Jeremy Ashkenas (autore anche di Backbone.js) ha eseguito il primo commit sul suo canale GitHub con il commento “commit iniziale del misterioso linguaggio”. L’ultima versione disponibile in questo momento è la 1.3.1.

Come suggerisce il nome è un linguaggio di scripting e viene transcompilato in JavaScript, pertanto necessita dell’installazione di un suo compilatore al fine di eseguire la compilazione. Anche il compilatore stesso è stato scritto in CoffeeScript.
Dal sito ufficiale si può leggere che la regola d’oro di CoffeeScript è: “E’ solo JavaScript”. Questo perché ogni linea di codice viene compilata una-ad-una nel suo equivalente JavaScript e non c’è alcuna interpretazione a runtime. Qualsiasi libreria JavaScript può essere usata in combinazione con CoffeeScript e viceversa. Nel sito ufficiale vi è anche un utile tool per provare il linguaggio senza installare nulla in locale.

coffeescript compile

esempio di compilato

 

La sua sintassi è inspirata a RubyPython and Haskell. Infatti come per questi linguaggi la sua sintassi permette di aumentare la chiarezza e leggibilità del codice e la velocità di scrittura da parte del programmatore.

Per concludere vorrei elencare le principali caratteristiche del linguaggio:

  • Nessun “;” alla fine di una riga di codice
  • Dichiarazione di una funzione senza parentesi
  • Supporta la dichiarazione di funzioni con un numero variabile di argomenti
  • Durante la compilazione quota automaticamente le parole riservate usate come proprietà di un oggetto
  • La dichiarazione di una classe usa la parola chiave “class” proprio come si fa con i linguaggi object oriented puri
  • shortcut “@” per accedere ad un attributo di “this”
  • L’operatore “unless” esegue l’opposto dell’istruzione “if”
  • L’operatore di uguaglianza “==” viene compilato in “===” al fine di evitare coercizioni sbagliate
  • “Switch” con “when” e “then” al posto di “case” e “break” al fine di evitare comportamenti non voluti a causa di un mancato “break”

Per chi volesse approfondire ulteriormente consiglio di leggere l’intervista al suo creatore.

CoffeeScript, una alternativa a JavaScript…o quasi!CoffeeScript, an alternative to JavaScript…more or less!" tw:url="http://www.alessandrolanza.com/2012/04/16/coffeescript-una-alternativa-a-javascript-o-quasi/">
-->
Categorie:web Tag: , ,

Recuperare codice ASCII di qualsiasi carattereRecuperare codice ASCII di qualsiasi carattere

13 febbraio 2012 Nessun commento

A volte capita di dover inserire in una pagina web un simbolo di cui non conosciamo assolutamente il suo codice ASCII. In questo articolo illustrerò un semplice trick per ottenere il codice HTML di qualsiasi simbolo.

I passi da fare sono:

  1. aprire il tool di windows (o equivalente su altri SO) mappa dei caratteri: Start -> Accessori -> Utilità di sistema -> Mappa caratteri;
  2. scegliere il carattere desiderato;
  3. guardando nella parte bassa della finestra di mappa caratteri alla destra troveremo il codice esadecimale corrispondente al carattere e sulla sinistra la conversione in decimale dello stesso carattere.

A questo punto per ottenere il codice HTML sarà sufficiente usare il valore decimale senza zeri iniziali preceduto da &#. Ovviamente se abbiamo solo il codice esadecimale dovremmo prima convertirlo in decimale.

Qui sotto un breve esempio per il carattere &#213.

esempio per carattere

 

Recuperare codice ASCII di qualsiasi carattereRecuperare codice ASCII di qualsiasi carattere" tw:url="http://www.alessandrolanza.com/2012/02/13/recuperare-codice-html-di-qualsiasi-carattere/">
-->
Categorie:tips and tricks, web Tag: , , , ,

Titanium VS PhoneGapTitanium VS PhoneGap

29 gennaio 2012 Nessun commento

Lo sviluppo di applicazioni mobili è uno delle killer-app degli ultimi anni, ma quali problemi si nascondono dietro al loro sviluppo?

I problemi principali nel convertire un’idea vincente in un’app sono due:

1. la grande varietà di piattaforme diverse presenti sul mercato (ad es. iOS, Android, webOS, WP7, solo per citarne alcune)
2. i diversi fattori di forma dei device, fatta eccezione per l’iPhone che ha delle dimensioni pressoché uguali tra le versioni

Per quanto riguarda il secondo problema si sta cercando di adottare uno standard comune tra i diversi costruttori anche se la strada è ancora lunga, mentre sul primo problema l’ostacolo più grande da superare è quello di dover usare linguaggi di programmazione diversi in base alla piattaforma. Ad esempio se dobbiamo sviluppare un’app per Android useremo Java; un’app per iPhone useremo Objective C; e così via. Questo implicherà per un’azienda avere più linee di sviluppo separate e replicare per ciascuna piattaforma gli interventi di manutenzione e/o di evoluzione dell’app.
Proprio dall’esigenza di riuscire a scrivere il codice una sola volta e deliverare su più piattaforme sono nati dei tool di sviluppo mobile cross-platform. Ce ne sono in commercio diversi, la maggior parte di essi si possono utilizzare gratuitamente, ed il guadagno principale delle aziende che li hanno creati deriva dai corsi di formazione, sparsi per il globo o in via telematica, per i developer che decidono di usarli. Una panoramica degli ambienti di sviluppo per mobile si può trovare qui.

I due tool più famosi che voglio presentare e mettere a confronto sono: Titanium di Appcelerator e PhoneGap di Nitobi (acquistato da qualche mese da Adobe). Entrambi permettono di scrivere la proprio applicazione usando HTML5, CSS e JavaScript e deployare applicazioni native per diverse piattaforme. La documentazione è ben fatta e ci sono molti esempi per entrambi.

Di seguito due brevi video che li presentano:

Per quanto riguarda le differenze tra i due:

  • Titanium ha un maggior numero di API e di componenti UI native rispetto a PhoneGap;
  • Titanium è sotto licenza Apache che è più rigida della MIT di PhoneGap;
  • Titanium ha come target platform: Android, iOS e presto BlackBerry;
  • PhoneGap ha come target platform: Android, iOS, BlackBerry, Symbian, webOS, WP, Bada;
  • Titanium ha un proprio IDE Eclipse based, Titanium Studio, derivato da Aptana.

Al di là di quale dei due si sceglierà di usare, come detto in precedenza permettono di scrivere una sola volta il codice ed ottenere applicazioni native per più piattaforme, ma ci sono due problemi principali nel loro uso:

  1. se vi sono dei bug nel framework di Titanium o PhoneGap, nonostante le relative aziende che sono dietro questi prodotti si sforzino di essere il più celeri possibili nel bug fixing, la loro risoluzione potrebbe prendere un po’ di tempo. Come si può immaginare, se questi bug sono bloccanti per noi, il ritardo nella loro risoluzione causerà disagi e rallentamenti nello sviluppo della nostra app ;
  2. quando viene rilasciata una nuova versione di una piattaforma (ad es. il recente iOS 5) non si potrà immediatamente deployare per la nuova piattaforma, ma si dovrà attendere la release del framework che conterrà l’allineamento del framework stesso per la nuova versione della piattaforma.

In conclusione, dalla mia esperienza con questi due strumenti, il mio consiglio è che se dobbiamo sviluppare applicazioni complesse è preferibile capire in quale piattaforma mobile ricade il bacino più consistente dei nostri user target e sviluppare direttamente un’app nativa per quella piattaforma e solo in un secondo momento arrivare nei marketplace delle altre piattaforme. Mentre è preferibile usare questi tool per applicazioni semplici.

Titanium VS PhoneGapTitanium VS PhoneGap" tw:url="http://www.alessandrolanza.com/2012/01/29/titanium-vs-phonegap-2/">
-->
Categorie:mobile Tag: , , , , ,