Su questo blog:

1. 5 Rich Javascript Framework
2. 5 Best Web Code Editor

Per HTML.it:

1. XSS e PHP: teoria e pratica
2. SEOmoz svela i fattori di posizionamento nel 2011
3. Debugging avanzato: consigli per l’uso
4. Sviluppo Web: framework o micro framework?

Buona domenica a tutti i lettori!

Blogging

1. When it’s Time to Kill Your Blog?
2. How Being a Coder Can Make You a Better Blogger

Freelancing

1. L’agile non è affatto semplice
2. Increase Your Productivity through Crowdsourcing

Tools

1. InuitCSS

ExtJS

Ext JS 4 is a major step forward for web frameworks. Building on Ext JS 3.3, our latest release adds over 350 new APIs, 50 new classes, and 65% more documentation. Ext JS 4 also brings an entirely new data package that enables developers to use a model-view-controller architecture when building their app. The new MVC enables apps to leverage features like Infinite Scrolling a Grid to build an entirely new level of interactivity in to web apps.

Cappuccino

Cappuccino is an open source application framework for developing applications that look and feel like the desktop software users are familiar with.

Cappuccino is built on top of standard web technologies like JavaScript, and it implements most of the familiar APIs from GNUstep and Apple’s Cocoa frameworks. When you program in Cappuccino, you don’t need to concern yourself with the complexities of traditional web technologies like HTML, CSS, or even the DOM. The unpleasantries of building complex cross browser applications are abstracted away for you.

Cappuccino was implemented using a new programming language called Objective-J, which is modelled after Objective-C and built entirely on top of JavaScript. Programs written in Objective-J are interpreted in the client, so no compilation or plugins are required. Objective-J is released alongside Cappuccino in this project and under the LGPL.

Qooxdoo

qooxdoo is a universal JavaScript framework that enables you to create applications for a wide range of platforms. With its object-oriented programming model you build rich, interactive applications (RIAs), native-like apps for mobile devices, traditional web applications or even applications to run outside the browser.

You leverage its integrated tool chain to develop and deploy applications of any scale, while taking advantage of a comprehensive feature set and a state-of-the-art GUI toolkit. qooxdoo is open source under liberal licenses, led by the world’s largest web host 1&1, with a vibrant community.

Wijmo

Wijmo is a complete kit of over 30 UI widgets with everything from interactive menus to rich charts. If you know jQuery, you know Wijmo. Complete with documentation and professional support, every widget is hand-crafted and includes premium themes.

Dojo

Dojo saves you time, delivers powerful performance, and scales with your development process. It’s the toolkit experienced developers turn to for building superior desktop and mobile web experiences.

Probabilmente i migliori sulla piazza sono i primi due, ma c’è l’inconveniente del costo della licenza. Viceversa, e basta fare una ricerca su Google, potete trovare innumerevoli framework gratuiti, magari buoni per studiarne il codice e l’architettura, spunto per costruirne uno di tasca propria. Buona lettura.

Approfondimento: I migliori framework per temi WordPress

In questo blog una piccola review di TuoGuru, con una piccola intervista al suo creatore. Ho poi postato su un esperimento in jQuery per ricreare sul web una macchina da scrivere e su LimeJS, un framework HTML5 per lo sviluppo di piccoli giochi.

Buon fine settimana e buona lettura.

Blogging

1. The 10 Commandments to Successful Blogging

Web Design & Development

1. 30+ Impressive Examples Of Blog Header Designs
2. Landing Page Best Practices: the definitive guide (with infographics)

Freelancing

1. 10 Reasons Why You Need a Mobile Office
2. 14 Applications for Project Management and Collaboration

News

1. NoSQL Benchmark Open-Sourced
2. Debian 6: le novità in 10 immagini
3. Quanto costa pubblicare per Kindle

Ho pubblicato un mini-recensione di M Project (un framework per applicazioni mobile) e di Yii (un framework PHP veloce e potente).

Buon fine settimana e buona lettura.

Web Design & Development

1. Designing Web Registration Processes for Kids
2. Top 35 Google Chrome Extensions and Web Apps For Bloggers, Web Designers and Developers

Blogging

1. Why You Should Socially Promote Articles You Comment On
2. How Your About Page Can Make or Break Your Blog
3. Don’t Go It Alone: Relationship-building for Bloggers

Freelancing

1. Useful Resources and Tips for Managing Your Virtual Staff

Tools

1. LimeJS (HTML5 game framework)
2. nanoc (Ruby web publishing system)
3. Isotope (An exquisite jQuery plugin for magical layouts)

Da Blueprint CSS a 960, passando per 1kb, il designer ha a disposizione framework molto interessanti e largamente usati. Molti designer comunque preferiscono costruire griglie apposite in base al progetto da realizzare, e faccio riferimento a Andy Clarke per esempio.

Secondo altri il codice risultante, con l’utilizzo dei framework prima menzionati, risulta  complesso, spesso anche confusionario e significativamente pesante rispetto ad una soluzione fatta ad hoc, oltre che semanticamente discutibile.

Quindi la domanda è: usare o non usare uno dei framework sopra menzionati? E se sì, quale e perchè?

A una prima rapidissima lettura non avevo ben capito tutto quel parlare di convenzione sui nomi da utilizzare per file e classi. Ma è bastato un attimo per capire che proprio in quella lista di convenzioni è nascosta tutta la potenza di CakePHP.

A parte due file che racchiudono la configurazione globale dell’applicazione, CakePHP delega tutto al programmatore cui chiede soltanto di rispettare poche, semplici (e per quanto mi riguarda ottime) regole sui nomi da utilizzare. Tipo i controllers e i modelli riferiti al database, senza la necessità di scrivere un file di configurazione a parte. Tipo i nomi delle viste e dei template da usare. Il tutto è un’armonia generale che per il programmatore si trasforma in due vantaggi:

1. il fatto di dover rispettare le regole sui nomi ti obbliga, a te programmatore, a un ordine che è poi decisivo nel contesto globale del codice; più scrivi più ti entra in testa la struttura del programma e ho avuto l’impressione di scrivere anche più velocemente rispetto a Symfony;
2. non c’è il problema di dover mettere mano alla configurazione o di dover fare il sync fra tali file di configurazione e il database; tabelle e classi vivono senza file di terze parti da editare per far combaciare nomi e funzioni e classi. Questo, per un discorso di manuntenibilità nel tempo, credo si possa rivelare estremamente positivo.

La learning curve di questo simpatico framework è eccezionale. In un paio di giorni si riesce a padroneggiarlo in modo da poter mettere su una piccola applicazione dotata di tutti i meccanismi necessari per essere rilasciato in ambiente di produzione. Le performance mi sembrano buone, ma non ho avuto modo di testarle a fondo. A occhio comunque dovrebbe risultare più leggero di Symfony e più scattante. Assomiglia a Django e, fidandomi del rubysta, linguaggio che non conosco, assomiglia parecchio a Rails.

In questi giorni ho avuto modo di apprezzare che i tempi di sviluppo sono più corti rispetto al corrispettivo in Symfony. E, parere del tutto personale, mi diverto di più a smanettare su codice PHP piuttosto che sui file yaml che accompagnano lo sviluppo in Symfony.

Ho letto diversi pezzi che presentano CakePHP in modo sicuramente superficiale, descrivendolo semplicisticamente. Il che non corrisponde al vero. Almeno nell’ultima release stabile che ho per le mani posso affermare di non sentire la mancanza di certi meccanismi in Symfony. Certo il numero di plugin di cui dispone quest’ultimo è incommensurabile rispetto a CakePHP, ma penso si riesca benissimo a supplire con una buona progettazione del codice e magari la scrittura di librerie proprie.

A primo impatto ho nelle directory solo e soltanto i file che mi servono davvero e riesco ad avere un quadro d’insieme che in Symfony non era così chiaro.

Devo ancora approfondire il capitolo sicurezza, ma ho letto buone cose su validazione e sanitization dei dati, su ACL e sessioni. I primi giudizi non possono che essere positivi, dunque. Ho intenzione di provarlo fra qualche settimana su un mini portale che non richiede uno sviluppo particolarmente complesso. Soprattutto voglio capire se scala bene su una VPS e quanto traffico è in grado di supportare senza risentirne in termini di banda e reattività.

Non ho ancora preso contatto con la comunità italiana, per cui sono curioso di conoscere le vostre opinioni su questo framework. Le mie impressioni iniziali sono esatte?

Jo è un framework con le caratteristiche sopra menzionate. Le premesse sembrano davvero buone e il corredo di documentazione pubblicato sul sito ufficiale suggerisce di testare questo strumento.

In effetti, in simbiosi con la potenza di HTML5, Jo permette tutta una serie di operazioni in modo relativamente semplice. Un paio di classi si occupano della gestione dei dati, supportando appieno SQLite, e c’è spazio pure per la gestione degli eventi. Il resto è una utile gerarchia di classi per costruire interfacce Web e operare con i dati. Uno sforzo apprezzabile.

1. Documentare il codice

Scrivere chiari e precisi commenti è impagabile. Permettono di leggere più facilmente il codice senza impazzire dietro ad algoritmi o funzioni o parametri conditi di mistero e di cui se ne disconosce la funzione, il significato e il motivo della loro esistenza. Gli stessi commenti devono essere scritti con coscienza, senza badare troppo alla forma magari, ma senza rinunciare a una certa formalità e un certo stile. Bisogna cercare di essere sempre chiari nelle spiegazioni e di non dare nulla per scontato. Prolissi e completi quando è rischiesto dal contesto, concisi quando è inutile divagare o spiegare cose ovvie e facilmente deducibili. Quando a distanza di tempo ci toccherà rimettere mano a un codice che abbiamo scritto di nostro pugno e di cui non ricordiamo molto, una veloce lettura dei commenti ci permette in pochi secondi di ritornare nella dimensione di quel progetto. Una buona documentazione del codice permette un alto livello di maintainability dello stesso. Nel caso, poi, ci fosse la necessità di collaborare con altri sviluppatori, il non dover chiedere costantemente chiarimenti su una funzione o un parametro permette di velocizzare il lavoro e migliorarlo sotto tutti i punti di vista, in quanto troveremo tutte le risposte dentro i commenti.

E’ possibile, in ultimo, estrarre dal codice sorgente i commenti formattati in un certo modo e produrre così un manuale per gli sviluppatori o una reference. Tutto in modo automatico ed evitando un doppio e tedioso lavoro. Uno strumento molto apprezzato, in tale contesto, è phpDoc (facile immagine per quale linguaggio).

Ultima raccomandazione, che a molti potrà suonare strana o esagerata. Se pensate che il vostro codice possa essere degno del panorama internazionale, cioè di un pubblico non solo italiano, allora è bene cominciare a prendere confidenza con l’inglese-scritto e commentare il codice in questa lingua.

2. Scrivere buon codice

E’ difficile in poche righe capire cosa significa “scrivere buon codice”, ma ci provo. Fra l’altro è una delle prime cose che uno studente si sente dire da un buon professore. Il pieno significato di un simile avvertimento dal sapore di consiglio lo si coglie solo quando si lavora seriamente a qualche progetto. O quando ci si confronterà con altri sviluppatori. Scrivere buon codice significa scrivere i nomi delle funzioni scegliendo i migliori termini, i più espressivi in assoluto. Conviene eliminare inutili abbreviazioni, solo per risparmiare qualche carattere e guadagnare qualche decimo di secondo in più sulla digitazione. Significa scrivere un codice la cui sola lettura è bastevole per capirne l’implementazione. Generalmente una funzione chilometrica è sintomo di scarsa progettazione del codice, il che non vuol dire che poi le cose non funzionano. La migliore palestra, in tal senso, è la lettura di codice dei migliori programmatori che potete trovare in rete e l’analisi di progetti dal codice aperto.

3. Framework e librerie

Spesso ci si trova a riscrivere del codice che in realtà esiste già e probabilmente risulta più completo del nostro, oltre che più efficace. Pertanto prima di buttarsi a capofitto nella scrittura di nuove classi occorre capire cosa offre Internet. Esistono diversi utilissimi siti dove poter trovare del buon codice (citiamo su tutti Sourceforge). Ed esiste Google per cercare eventuali librerie già pronte per essere usate nei nostri progetti. Se nulla ci soddisfa allora non resta che scrivere quanto abbiamo di bisogno. Se abbiamo intrapreso quest’ultima strada è buona cosa pensare non al progetto in sé, quanto piuttosto ai problemi generali che intendiamo risolvere. E’ questo infatti il caso migliore per pensare a una libreria riutilizzabile pure in altri progetti. Se poi siamo soliti lavorare su applicazioni che in qualche modo hanno molte somiglianze fra di loro, beh allora conviene pensare a qualche framework. Generalmente una grande società di software ne progetta uno e provvede a usarlo nei vari lavori. Uno sviluppatore indipendente può lanciare a se stesso la stuzzicante sfida di costruirne uno nuovo, o studiare per bene un framework esistente.

In tal senso un buon framework (Rails per i programmatori Ruby, Zend o Symfony per i programmatori PHP, Django per gli appassionati di Python) potrebbe essere una ottima base per sviluppare una grande applicazione. Ma occorre valutare per bene ogni fattore. Spesso un framework rischia di appesantire lo sviluppo e se non riusciamo ad ottimizzarne la configurazione rischiamo pure di ottenere un prodotto dalle scarse performance. E’ opportuno inoltre non focalizzarsi soltanto su un prodotto, ma studiarne più di uno per capire realmente benefici e svantaggi di ognuno di loro. A quel punto, e solo a quel punto, conviene sceglierne uno e provare a padroneggiarlo al meglio. In altre parole: non limitarsi a leggere qualche articolo su Internet (raramente ho scovato delle analisi pienamente oggettive sui software e sui framework), ma sperimentare le soluzioni. Quindi specializzarsi su un prodotto.

4. Standard e best practices

I design pattern vanno studiati, compresi e quindi usati. Spesso ci si accorge che bravi programmatori li disconoscono ed è un male. Pattern quali MVC offrono una potenza incredibile. E numerosi altri pattern offrono una soluzione ottimale a ricorrenti problemi per quanto riguarda la programmazione (che è poi la definizione di Design Pattern).

Quando parliamo di best practices ci riferiamo a delle esperienze che altri hanno già maturato in qualche settore professionale e nelle quali hanno raggiunto ottimi risultati. Potete pensare a delle regole generali, più o meno formalizzate, o a degli esempi opportunamente descritti e commentati. Per quanto mi riguarda mi sono stati utilissimi i libri di ingegneria del software che ho letto e sui quali ho trovato diversi riferimenti a ulteriori libri e articoli. Potete recuperare su internet diverse interviste a eminenti sviluppatori che raccontano le loro esperienze e le loro idee.

5. Pensare. Poi scrivere codice

Lontano da una schermo e una tastiera si riesce meglio a programmare. Sembra un paradosso, invece è la pura realtà. Provate a pensare alla vostra architettura fuori da una finestra di Mac o di Windows o di Linux. Fogli di carta, penna, matita e idee. Non è tempo sprecato, anzi tutto il contrario. Uno schermo con icone e testo, una tastiera e un mouse possono risultare degli elementi destabilizzanti e di distrazione. Si è tentati di scrivere subito del codice funzionante, salvo poi scoprire che una funzione poteva essere scritta meglio, o un insieme di classi poteva essere progettato in modo più intelligente. A quel punto tornare indietro è complicato. Rifattorizzare equivale a partire da zero (e a un livello iniziale non si parla certo di refactoring) e, si realizzerà con estremo rammarico, di aver buttato via preziose ore di lavoro.

Ponderare bene le scelte: tracciare diagrammi, appuntare note e idee, provare a scrivere un piano di sviluppo. Anche senza badare alla forma, una sorta di brainstorming solitario. Fate una lista dei problemi da risolvere, delle possibili soluzioni cui avete pensato e, dopo una pausa lontano da tutti e tutto, rileggete con attenzione quanto avete scritto e cercate di capire se è l’ora di mettersi a scrivere codice o conviene dedicare ancora qualche minuto a questa meditazione pre-sviluppo.

Non esiste un libro delle soluzioni in informatica. Esiste però una quantità smisurata di handle di soluzioni. Queste maniglie altro non sono che il codice e gli applicativi che altri programmatori hanno già realizzato e rilasciato. Dare uno sguardo all’interno del codice scritto da terzi (e dovete ovviamente scegliere i migliori terzi, perché conviene imparare soltanto dai migliori) si rivelerà presto preziosa lettura e fonte di soluzioni. Il che non vuol dire che dovete copiare, ma certamente ispirarvi. O, più umilmente, imparare.