jQuery – Asynchronous image loading

HTML

 

CSS

 

JavaScript

 

LIVE DEMO

JSUtils: alpha release

Su GitHub è disponibile il nuovo repository dedicato a JSUtils, una serie di utilities JavaScript che ti saranno utili per qualsiasi progetto. Il file è leggerissimo e le funzioni sono molto semplici da utilizzare, la lista è in continuo aggiornamento e qui sul blog per ogni release dettaglieremo i nuovi inserimenti con un esempio pratico.

Per utilizzare JUtils basta integrare il file nei tuoi documenti HTML:

Avrai subito a disposizione tutti gli strumenti della libreria, vediamo i primi esempi per le funzioni già pubblicate sul repository JSUtils.

 

 

isFunction(item)

LIVE DEMO

 

loop(counter,loopedFunction)

LIVE DEMO

 

 

confirmOperation(msg,fct)

LIVE DEMO

 

 

getUserIP(fct)

LIVE DEMO

 

Questo al momento per JSUtils è tutto . . . tanto altro è già pronto ma necessita della dovuta documentazione . . . appena ci sono novità sarai il primo a saperlo se segui questo blog.

Text Editor VS IDE

editor vs ide

 

A sentire certi developer se non usi un text editor non sei un vero sviluppatore. A sentirne altri se non usi un IDE non sei un vero sviluppatore. Nerdaggini e fazioni a parte c’è un bel po di differenza tra i due strumenti, diversi pro e diversi contro in entrambi i casi e quella che segue è la mia personalissima disamina.


Con un IDE lo sviluppo è decisamente meno dispersivo, non a caso si chiamano di ambienti di sviluppo integrati. L’editor del codice è solo una parte del gioco che include anche strumenti per il debug, il versionamento, i test automatizzati e moltissimo altro. A seconda della piattaforma è anche possibile fare debug in remoto su diversi dispositivi o pacchettizzare l’applicazione per l’OS di riferimento.

Gli IDE che ho provato sono troppi per una lista che sia utile a qualcuno, ma ho stilato una classifica in base alle mie preferenze/esperienze pregresse. Questi sono i software che preferisco:

  • XDK ( pensato per app multipiattaforma )
  • CodeLite ( campione in quanto a leggerezza )
  • Eclipse ( meglio del suo derivato Aptana )
  • Visual Studio ( solo Win e niente più )
  • WebStorm ( e si . . . è a pagamento )

Tutta questa versatilità si paga però con un eccessivo legame al dispositivo sul quale si sviluppa: cambiare sistema operativo e tipologia di macchina può essere un calvario o addirittura in alcune situazioni non è proprio fattibile. Come proseguire lo sviluppo di un backend iniziato su Mac avendo a disposizione solo un iPad?


L’immediatezza di un semplice editor di testi è imbattibile ma per scrivere software complesso il classico notepad non basta, bisogna trovare un editor completo e possibilmente estendibile via plugin così da modellarlo secondo le esigenze di sviluppo del momento. Highlight, completamento automatico,  file management, connessione remota (ftp/ssh), macro et similia sono le funzionalità aggiuntive più comuni. Questi sono gli strumenti che prediligo su tutti:

  • CodeAnywhere ( Browser – iOS )
  • jEdit ( MacOS – Windows – Unix)
  • TextWrangler ( Mac OS )
  • GoCoEdit ( iOS )
  • CODEpad ( iOS )
  • VIM ( MacOS – Windows – Unix)

A questi strumenti di solito affianco la developer edition di FireFox (indispensabile per il debug e i test) e la riga di comando. Ovviamente questa soluzione è più dispersiva rispetto ad un IDE, trovare la configurazione giusta e i plugin più efficaci richiede tempo e tentativi, e la riga di comando per molti non avvezzi ai metodi old style è un gran bel problema.

E si, ho inserito anche VIM nella lista che è vecchio, è brutto ed è complesso ma ci sono diverse situazioni in cui è la soluzione più rapida e alcune altre in cui è indispensabile.


I fattori che possono far propendere per uno strumento piuttosto che per un altro sono i linguaggi utilizzati e il tipo di software che si sta sviluppando. La mia scelta definitiva, considerato che al momento sviluppo principalmente in JavaScript/PHP/Phyton è un Text Editor di qualità. Mi capita spesso di sviluppare direttamente su server remoti. Mi capita spesso di sviluppare in mobilità da iPad. Mi capita spesso di cambiare i device dai quali sviluppo. Tutto questo mi porta a slegare il più possibile il lavoro dal mezzo che uso per svolgerlo.

Detto questo non posso omettere che ci sono situazioni nelle quali non utilizzo l’ Editor. L’eccezione alla regola è lo sviluppo di app mobili multipiattaforma, in questo caso non si può prescindere da un buon IDE (autolesionismo a parte) e la scelta perfetta per le mie esigenze si è rivelata XDK di Intel, ha tutto quello che serve, è rapido ed è anche intuitivo e usabile. Ed è gratis.

AJAX xml parsing

 

jQuery: bind textarea events

LIVE DEMO

JS Strict Mode

strict mode JavaScript

 

ECMAScript 5 ha introdotto da diversi anni la possibilità di eseguire il codice JavaScript in una modalità particolare detta Strict Mode che permette di gestire meglio errori ed eccezioni ed evita alcune delle bad practice molto comuni per tanti sviluppatori alle prime armi.

Per eseguire il codice in questa modalità, basta iniziare il file .js con questa riga prima di qualsiasi altro controllo.

Da questo punto del codice in avanti saranno valide le regole particolari dello StrictMode. Vediamo in pratica cosa significa con qualche esempio pratico e  qualche riga di codice.

 

DICHIARAZIONE. Con questa modalità utilizzare una variabile o un oggetto senza averlo prima dichiarato genera un errore.

ACCESSO ATTRIBUTI.  Un utilizzo non corretto degli attributi di un oggetto viene segnalato come errore, in Strict Mode ha più senso dichiarare attributi read-only o get-only.

EVAL. L’uso di eval può spesso rappresentare un problema per la sicurezza del software JavaScript. Con la modalità Strict diverse pratiche scorrette non sono consentite. Una di queste utili restrizioni é l’impossibilità di creare variabili per lo scope corrente tramite questa funzione.

PARAMETRI. I nomi dei parametri di una funzione devono essere univoci per essere considerati validi in Strict Mode.

THIS. L’uso della keyword this é differente in strict mode. Una delle prime cose che salta all’occhio é che con this non è piú possibile accedere all’oggetto window, nello scope principale this è uguale ad undefined. Non forzare this a diventare un oggetto ha un costo in termini di performance ma non espone gli oggetti globali ad errori e problemi di sicurezza. Nel caso esposto sotto uno sviluppatore distratto dimentica la clausula new per creare un nuovo oggetto, se non fossimo in Strict Mode questo oggetto sarebbe aggiunto a window mentre così viene giustamente generato un errore.

 

RESERVED KEYWORDS. In Strict Mode ci sono alcune parole chiave riservate in più, questo rende più longevo il codice che andiamo a scrivere perchè sono keywords che non potranno più essere utilizzate nelle prossime versioni del linguaggio.

  • implements
  • arguments
  • interface
  • Let
  • pacate
  • private
  • protected
  • public
  • static
  • yield

Il supporto alla Strict Mode non è omogeneo per tutti i browser, le versioni più datate supportano parzialmente o non supportano affatto questa modalità. Come sempre la spina nel fianco dei developer è Internet Explorer, in questo caso le versioni precedenti alla 10. La soluzione è testare il codice con varie versioni di browser (anche non recenti) e su vari sistemi operativi così da supportare quanti più utenti possibile e avvisare gli utenti non supportati dei possibili malfunzionamenti.

 

Il punto di riferimento migliore per conoscere di più sullo stirct mode resta la guida per gli sviluppatori di mozilla: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode.

[UtilsGolf] JavaScript loop function

LIVE EXAMPLE

Javascript Bitwise Operators

 

LIVE EXAMPLE

Validate credit card number with RegEx

LIVE EXAMPLE

Javascript empty for

JavaScript empty for

LIVE EXAMPLE