Archivio per la categoria "Programmazione"



This\is\lame\r\n … è un namespace, almeno in PHP 5.3

Finalmente la lunga saga dell’introduzione del supporto per i namespace in PHP 5.3 è giunta, forse, al termine nelle ultime ore. Finalmente perché la discussione è andata avanti per diversi mesi, con lunghi thread su php.internals aperti in maniera pressoché perpetua ma spesso abbastanza inconcludenti. Vi anticipo fin da subito il finale della storia, ma vi avviso che secondo me non è dei migliori: è stato deciso di sostituire :: con il carattere \ per identificare la separazione dei namespace.

Il problema principale della scelta di :: come separatore per i namespace, secondo i core developer di PHP, risiede nel fatto che in alcuni casi può crearsi un’ambiguità non risolvibile dall’interprete poiché lo stesso :: viene usato anche per accedere ai metodi di classe statici. Ecco un esempio pratico:

1 // -------------------------------------- 2 // primo caso: Classe::methodoStatico() 3 4 class Foo { 5 public static function bar() { 6 echo "Foo::bar()"; 7 } 8 } 9 10 Foo::bar(); 11 12 // -------------------------------------- 13 // secondo caso: Namespace::funzione() 14 15 namespace Foo; 16 17 function bar() { 18 echo "Foo::bar()"; 19 } 20 21 Foo::bar();

L’ambiguità delle righe 10 e 21 risulta evidente, tanto che anche l’interprete in questo caso non saprebbe come comportarsi. Per questo motivo gli sviluppatori di PHP hanno pensato di aggirare il problema cambiando appunto in \ il separatore per i namespace.

Se doveste chiedermi cosa ne penso vi direi che, così di primo acchito e pur non avendo da offrire soluzioni in merito alla questione, per conto mio l’idea non è stata delle migliori. Senza alcun dubbio c’erano dei problemi, ma se da un lato è vero che così vengono risolte possibili ambiguità, con la scelta di \ vedo l’introduzione di bug subdoli dovuti alla mancata attenzione nell’uso della quotazione singola o, in caso contrario, un errato escaping.

$singleQuote = new ReflectionClass('foo\bar\className'); $doubleQuoteWithEscape = new ReflectionClass("foo\\bar\\$classNameInVar");

Ad ogni modo vi fornisco alcuni link la cui lettura può tornarvi utili per farvi un’opinione sulla decisione presa:

Microsoft Silverlight 2.0 RTM, support per Eclipse, port su Symbian. Poi?

Ok anche questa volta penserete allo scherzo ma no, non lo è nemmeno in questo caso. Scott Guthrie, oltre ad aver appena annunciato via conferenze telefonica che domani (14 ottobre 2008) vedrà la luce la versione RTM di Silverlight 2.0, ha dato la notizia che la piattaforma di sviluppo offerta da Eclipse sarà supportata, seppur non direttamente, per la creazione di applicazioni Silverlight:

Microsoft announced plans to support additional tools for developing Silverlight applications by providing funding to Soyatec, a France-based IT solutions provider and Eclipse Foundation member, to lead a project to integrate advanced Silverlight development capabilities into the Eclipse IDE. Soyatec plans to release the project under the Eclipse Public License Version 1.0 on SourceForge and submit it to the Eclipse Foundation as an open Eclipse project.

Potete trovare maggiori dettagli in questa pagina fresca di pubblicazione, inoltre è stato reso noto il sito Eclipse Tools for Microsoft Silverlight su cui è già online e disponibile per il download una prima alpha del plugin per Eclipse con dettagli e istruzioni su alcune modalità di configurazione. Nella stessa pagina si può notare anche una curiosa nota: Windows XP SP2 (or above) or Windows Vista SP1 – Other OS are planned for future versions. In effetti mi chiedo quanti sviluppatori .NET su Windows usino Eclipse, considerazione che riporta un po’ tutti con i piedi per terra, però quel futuro supporto per altri sistemi operativi… mah, chissà…

Ad ogni modo l’altra notizia (di cui non ci sono ancora testimonianze ufficiali scritte mentre sto scrivendo) è che a quanto pare Microsoft e Nokia lavoreranno per portare Silverlight su piattaforma Symbian.

Per ora sembrerebbe non esserci altro. E dire che il PDC 2008 è tra meno di quindici giorni…

Ruby Social Club, Milano – Atto terzo: missione compiuta

Anche se con un po’ di ritardo, ci tenevo a esprimere la mia soddisfazione per la bella serata che è stata organizzata mercoledì scorso in quel di Milano dai ragazzi di Mikamai per il terzo Ruby Social Club. Una trentina di persone (successone), atmosfera molto informale, talk veloci ma interessanti e una transumata di massa al locale dove sono continuate le discussioni sugli argomenti più disparati tra birra e qualche piatto di cibarie. Purtroppo non sono mai riuscito a partecipare alle precedenti edizioni e devo dire che questa volta è valsa la pena fare di tutto per esserci. Il buon riffraff (a cui tra l’altro devo anche una birra, lo scrivo qui così rimane fino alla prossima occasione) ha già scritto qualche dettaglio sparso sulla serata, per cui non mi dilungherò ulteriormente. Sicuramente ci saranno altri appuntamenti in futuro, per cui… al prossimo RSC :-)

Microsoft e jQuery (sembra uno scherzo, ma non lo è)

Risale a qualche minuto fa la notizia che Microsoft ha stretto una partnership con il team di jQuery non solo per supportare ufficialmente questa libreria all’interno dei suoi prodotti di sviluppo come Visual Studio 2008 e la versione free di Visual Web Developer ma anche per distribuirla in alcune sue librerie web-oriented come l’ormai prossima ASP.NET MVC o AJAX Control Toolkit. Il supporto negli ambienti di sviluppo sarà fornito inizialmente da un pacchetto scaricabile gratuitamente nelle prossime settimane mentre in futuro sarà integrato direttamente in Visual Studio. Vorrei citare solo due passaggi, il primo dal blog di Scott Guthrie che riporta l’annuncio:

We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch.  The files will continue to use and ship under the existing jQuery MIT license.

Il secondo invece arriva dal post di Scott Hanselman (e che in effetti riassume uno dei principali motivi per cui questo annuncio mi ha stupito):

Folks have said Microsoft would never include Open Source in the platform, I’m hoping this move is representative of a bright future.

Ecco i rispettivi annunci ufficiali da parte di Scott Guthrie e John Resig (il quale estende la notizia riportando anche la collaborazione ufficiale di jQuery con Nokia).

Sinatra has taken the stage!

Non si tratta del compianto Frank, ma di uno degli ultimi framework per lo sviluppo web arrivati in casa Ruby. La caratteristica principale di Sinatra è la sua semplicità, ancora più spinta rispetto a quella a volte anche un po’ troppo magica di Camping: con sole 5 righe è possibile ottenere una risposta dal server. Non ci credete? Allora, dopo averlo installato usando rubygems (gem install sinatra -y), provate il seguente codice…

# main.rb require 'rubygems' require 'sinatra' get '/' do 'Cool, Sinatra is performing on the main stage!' end

Usando il comando ruby main.rb si ottiene un’istanza di Mongrel con la nostra applicazione pronta a ricevere le chiamate dal browser, mentre nella finestra del terminale si viene avvisati che Sinatra has taken the stage on port 4567! Non resta da far altro che verificare l’effettivo funzionamento con un semplice wget -qO- http://localhost:4567/ (oppure curl http://localhost:4567/ se preferite):

Cool, Sinatra is performing on the main stage!

Sinatra può essere definito un micro-framework traverstito da DSL dotato di una grammatica ridotta, semplice e immediata. Sinatra non obbliga lo sviluppatore a strutturare la propria applicazione seguendo l’architettura MVC (ma è comunque possibile replicarla), non è legato a un particolare motore di template (ma supporta molto bene ERB e l’ottimo HAML), non offre la miriade di helpers inclusi nel prezzo come altri framework e inoltre è assolutamente ORM-agnostico: tutto ciò può avere i suoi pro e contro, ma queste caratteristiche lo rendono indubbiamente un ottimo framework per lo sviluppo di prototipi o di applicazioni semplici ma relativamente veloci. Sinatra, per come è strutturato, promuove inoltre lo sviluppo di interfacce REST per le proprie applicazioni web, rendendolo quindi uno strumento agevole per prototipizzare API.

get '/' do # mostra risorsa end post '/' do # crea risorsa end put '/' do # aggiorna risorsa end delete '/' do # cancella risorsa end

Viene naturale a questo punto chiedersi come vengano gestite le rotte, ma anche in questo caso è tutto molto semplice e intuitivo:

get '/hello' do redirect '/hello/anonymous' end get '/hello/anonymous' do 'Hello Mr. Anonymous, I would be glad to know your name!' end get '/hello/:name' do user = params[:name] "Hello, #{user}!" end # wget -qO- http://localhost:4567/hello # Hello Mr. Anonymous, I would be glad to know your name! # wget -qO- http://localhost:4567/hello/anonymous # Hello Mr. Anonymous, I would be glad to know your name! # wget -qO- http://localhost:4567/hello/NRK # Hello, NRK!

Occorre solamente far notare che Sinatra effettua il lookup delle rotte nell’ordine di definizione, per questo motivo la seconda rotta /hello/anonymous non viene catturata dalla terza che invece specifica un più generico /hello/:name. Concentrandosi appunto su quest’ultima, possiamo notare come più in generale le variabili all’interno di una rotta possano essere definite semplicemente sfruttando la stessa sintassi utilizzata per definire un simbolo in Ruby e come esse vengano automaticamente rese disponibili nell’hash params.

Se avessimo bisogno di un approccio più in stile MVC? Partendo dal presupposto che con Sinatra non serve creare una classe controller ma basta definire le singole azioni, a questo punto mancano solo le viste. Occorre quindi creare una directory views nel path della nostra applicazione, preparare il proprio template salvando il file relativo nella suddetta directory (per esempio greet.haml oppure greet.erb a seconda di quale motore di template vogliate usare) e scrivere una semplice riga di codice per la rotta:

get '/hello/:name' do haml :greet end

Per convenzione Sinatra effettua l’autocompletamento del nome del file della vista aggiungendo .haml o .erb, per cui basta specificarne il nome. Se avessi voluto utilizzare erb avrei scritto erb :greet ma dal momento che haml tutto sommato mi piace (gem install haml), ecco qui il codice d’esempio assolutamente minimale:

!!! %html %head %title Greetings! %body %span Hello, %strong= params[:name]

A questo punto la chiamata a http://localhost:4567/hello/NRK produrrà il seguente output:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title>Greetings!</title> </head> <body> <span> Hello, <strong>NRK</strong> </span> </body> </html>

Tutto molto semplice, no?

Sinatra è in una fase di sviluppo abbastanza attiva ma è un framework già particolarmente interessante per tutte quelle necessità in cui Ruby on Rails oppure framework similari risulterebbero soluzioni spropositate. Essendo basato su Rack è possibile servire le applicazioni usando server differenti da Mongrel, come per esempio Thin o Phusion Passenger via Apache. Personalmente lo sto provando nei ritagli di tempo per creare una sorta di gateway da un servizio JSON-RPC che avevo realizzato qualche tempo fa a un servizio REST-oriented con tanto di interfaccia web per la gestione delle azioni e la visualizzazione dei dati, per ora sono molto soddisfatto della sua semplicità.