So why am I writing this blog post? To cut it straight to the point, I think there’s sometimes a little misconception about the very reason for which Predis exists nowadays and Aleksey’s recent blog post is offering me a good opportunity to clarify things a bit. Don’t get me wrong he made various valid points, but what has actually caught my attention and prompted me to write this post is the very introduction:

As some of you may know, I’m crazy about speed. So when I saw that people were happily using Predis as their choice of PHP client for Redis, I was a bit confused.

Why use a client written in PHP for something that should be ‘fast’ like Redis?

That kind of defeats the purpose - unless you don’t really care about response times and scalability. 

Predis was initially developed to fill the lack for a decent client library but turned into a more comprehensive solution allowing for maximum extensibility. In a sense, you may think of this library not only as a mere client for Redis but as a sort of framework (pass me the buzzword) with various building blocks that developers can leverage to create abstractions for features based upon Redis and expose them through a consistent interface. In my opinion a great example of such extensibility is the abstraction used to support Lua scripts exposing them as if they were common Redis operations such as GET or SET (and it works when using client-side sharding or master/slave replication too). Some parts were also reused to build a fully-asynchronous version of the client!

Obviously there’s a price to pay for everything and, in our case, that price is a penalty in raw speed compared to a C-based extension due to the undeniable greater overhead of a pure-PHP implementation. You can mitigate part of this overhead by using PHP >= 5.4 (faster at method dispatching), an opcode cache (you should do that anyway on production servers) or even plugging in phpiredis for faster protocol (de)serialization, but in the end you are optimizing your stack on a single-server basis. You can have 5, 10, 100 servers hitting Redis for distributed operations: that’s where Redis shines the best and that’s why it’s considered blazing fast. In such distributed scenarios, when one or more Redis instances are running on remote hosts, you will soon notice that most of the difference in speed is lost due to network round-trip times so you will be left for the most part with the inherent overhead of compiling the source code (or loading the cached opcodes) of Predis on each request. We’ve always been clear on what to expect out of Predis in this case and this is the reason why we have a FAQ about performances shipped along with the library. It’s a matter of trade offs: you sacrifice a low overhead for the sake of flexibility.

But then again, is it possible to use Predis when you also need decent overall performances or scalability? Depending on your definition of “decent performances” in the context of your application and provided a correct setup and architecture, yes. I personally know of a few high-load web sites using Predis, each one with a different reason behind their choice. Sure, if you don’t need fancy features and you only have one server performing requests against Redis running on the localhost then you would probably prefer to stick with phpredis thanks to its lower overhead, but that doesn’t mean being able to scale. Is Predis better than phpredis, or the other way around? Simply put, they are two solutions to the same problem and both have their different strong and weak points. In the end you are the one to decide based on your needs but, more importantly and as Aleksey concluded, don’t base your decisions on assumptions. And, I’d just like to add, not even on general benchmarks.

As an happy owner of the DSC-RX100 I can’t deny that the news that Sony is about to announce a revised version of this high-end and enthusiast-oriented compact camera on 27th June (namely the DSC-RX100M2) has caught my attention. Actual details about this camera come from its recently leaked Japanese user manual. The great Sony Alpha Rumors blog spotted the rumor first and they recently confirmed it by publishing a bullet-point list of changes extracted from the above mentioned manual, I simply reused their list in this post to add my own considerations but credits for the actual news go to them.

Let’s start with the list of improvements of the DSC-RX100M2:

1. Exmor R (BSI) sensor
   It sports the same size and resolution of the previous Exmor CMOS sensor (1″ and ~20 megapixels) but that R indicates it’s now back-illuminated. This may be nice news but the BSI technology is said to be mostly useful on sensors with a photosite size equal or less than 1.75µm (usually on 1/2.3″ sensors or smaller) while the size of the photosites of the RX100 is 2.4µm. I guess we can’t really say anything without seeing the actual RAW output first.
2. Wi-Fi 802.11b/g/n
   This is not something I miss and I’d be inclined to classify this addition as typical P&S gadgetry, unless it allows for some kind of remote shutter release control of some kind, but I highly doubt it and I don’t see any indication of it.
3. NFC
   I suppose this is solely meant to easily configure Wi-Fi connectivity for transferring photos to other devices such as smartphones. See above.
4. Multi Interface Shoe and EVF support
   The MIS is a proprietary camera hotshoe system (21+3 pin) introduced by Sony in late 2012. Besides the dedicated Sony accessories, it can drive ISO flashes. It will also make it possible to use an external electronic view finder which is definitely a nice addition albeit the recommended retail price of $/€ 449.99 for the FDA-EV1MK (the same EVF for both the DSC-RX1 and DSC-HX50V) does hurt.
5. Mini-HDMI has been moved from bottom to side, next to Micro-USB
   Surely OK, actually they should have positioned it like that since start, but how many times do you film/shoot with the camera while attached to a TV?
6. Improved battery life, from 330 to 350 shots (CIPA)
   Even slight improvements are yays in the battery life department to me, but I can easily get a full day of shooting with the current RX100 and I prefer to have a spare battery with me anyway, so it’s not something that would affect me much in practice. The battery remained the same NP-BX1 which is good.
7. ISO starts from 100 instead of 125
   I suppose they are referring to native ISO since the current RX100 can go as low as ISO 80 and 100 through expansion.
8. Control ring can be set to smooth or click
   This improvement is big if you listen to most of the complaints over the internet about the control ring being clickless, which makes setting certain parameters such as ISO levels almost impossible without looking at the display if you have sounds turned off as I do. Luckily for me I like having the control ring assigned to manual focus operations where a smooth ring is actually better, so I’m not affected that much.
9. Movie button can be disabled
   The dedicated movie button is handy and it proved to be so in a few real-life occasions, but sometimes it can be accidentally pressed. It happened a couple of times to me, but I still prefer to have it enabled to catch those unexpected moments instead of having to manually switch the camera to video mode which takes more time.
10. 24p option for movies
    The original RX100 is already quite capable for shooting videos but having the added ability to record them in 24p is nice.
11. White balance bracketing
    This is hardly useful when capturing images in the RAW format as you can adjust the WB later, but when shooting with multi-shot noise reduction or automatic HDR (both are only able to output JPG files for obvious reasons) this can be useful. Personally I’d have vastly preferred a more flexible exposure bracketing system than the current one which uses 3 exposures at only 0.3EV or 0.7EV intervals.
12. Improved in-camera battery recharge times
    The charging current has been increased from 0.5A to 1.5A (approaching the 1.89A limit of the NP-BX1 battery), this should translate to 3 times faster charging times. While 99% of the time I use an external battery charger which offers faster charges, having the ability to charge the battery in-camera via USB is still useful and being able to do it faster is great.
13. Tilt screen
    This is a great addition with the downside of making the camera slightly thicker (only 2.4mm), but that shouldn’t affect by much its jeans-pocketabily. The tilt system being used looks similar to the one adopted for the NEX-3N.
14. Weight increased from 240g to 281g
    Finally, this is the price to pay for these physical improvements in terms of weight.

Now let’s see what didn’t make it in this revision compared to what people kept whining about:

1. First of all, for those wanting both a wider lens but faster at the telephoto end it’s been confirmed that such a thing won’t happen: the lens is still a Vario-Sonnar T* 28-100mm (35mm equiv.) f1.8/4.9. Honestly I think far too many people keep demanding the impossible in terms of lens performances out of such a compact package. It’s most likely impossible to achieve a wider lens (many ask for 24mm!) keeping its f1.8 capabilities when the original RX100 already suffers from soft edges at 28mm due to barrel distortion corrections, and a faster lens at telephoto would surely require a different disposition of the optical groups. I’m also ignoring absurd requests for powerful zoom capabilities going up to say 140mm. At this point, and with a sensor of that size, almost nothing can be sensibly improved in terms of lens performances without affecting the whole package size.
2. No integrated GPS. I find it useless anyway as it adds burden to the battery, personally I’m more than satisfied with using my TranSystem iBlue 747A+ GPS logger (now superseded by a newer model) to log all of my trips: I keep it always on when out for the whole day up to five days without worrying about battery, it’s fast to lock satellites and it’s probably way more precise than any built-in GPS. The obvious downside is that you must manually synchronize the internal camera time with the GPS time (you actually need to do that only once in a while) and you must geotag your shots later, but GeoTag makes it easy to do that in bulk from a GPX file and can write EXIF data to JPG, RAW files of various vendors and XMP files.
3. On-sensor phase-detect autofocus. That’s simply not gonna happen, not even the DSC-RX1 has it.
4. No hand grip or rugged surface for a more secure handhold. This can be easily worked around using third-party accessories, personally I don’t feel the need for it.
5. No signs of the new JPEG engine that promises an improved compression quality. This engine will debut on Sony’s new Xperia flagship device (C680X code-named Honami) and will also be used on cameras starting with the SLT lineup through a firmware update. I find the current JPEG engine used by Sony to perform poorly compared to the output generated by other vendors.

All in all some of the improvements over the original DSC-RX100 are nice, but as a whole they are probably not worth the upgrade for anyone already owning it as they seem to be mostly targeted to satisfy those finding this camera lacking due to the absence of a tilt screen or an EVF-capable hotshoe.

Personally I’d be more interested in the new sensor if it proves to yield higher SNR ratios translating to visibly better outputs in low-light conditions and with less noise at high ISO levels, but I guess this is unlikely happen to an appreciable degree (we won’t get a whole stop of advantage). I find it very disappointing that the maximum shutter speed remained at 1/2000th second making wide apertures in strong sunlight a bit problematic, especially since there’s no built-in ND filter. Also, the EB is still limited to 3 exposure at 0.3EV or 0.7EV intervals.

Conclusions? Revision or not, the DSC-RX100 (with its flaws and compromises, just like any camera) provides the best IQ in such a pocketable package and competition has yet to announce a product comparable when combining performances and size.

• Dopo svariati anni ho cambiato completamente la pagina nella root di questo dominio pensando a qualcosa di molto semplice ma decisamente più utile di quella precedente.
• Twitter rules (lo ribadisco) e no, niente Facebook (ci tengo a ribadire anche questo).
• Alla fine in Giappone ci sono stato! Circa 10 mesi fa a dire il vero. Che dire, ci vorrebbe un blog intero solo per raccontare l’esperienza. Ovviamente nei piani è previsto un ritorno in pompa magna nel paese del Sol Levante, ma in un periodo non ancora definito. Posterei anche qualche fotografia, se solo avessi finito di sistemarle (sono fermo a 330 su circa 1200 foto).
• Evviva gli EeePC. Windows 7 + Kubuntu sul disco e ArchLinux (con fluxbox) su chiave USB e posso fare praticamente tutto ovunque io sia. Tra l’altro è solo qualche mese che utilizzo ArchLinux ma devo ammettere che mi sta piacendo molto come distribuzione.
• Vorrei scrivere un blog "tecnico" in inglese, ma come potrei anche solamente pensarci quando non riesco ad aggiornare nemmeno quello nella mia lingua madre?
• Tra l’altro girano leggende metropolitane tra qualche persona che conosco secondo cui un post che compare su questo blog è presagio di impressionanti catastrofi, o quanto meno di tempo metereologico palesemente avverso per il fine settimana. Nel dubbio oggi è caduta grandine, per il weekend staremo a vedere.
• Ah, buona Pasqua.
• 42

OK, lo ammetto, in realtà era tutta una scusa per postare qualcosa dopo un anno esatto Mi piacerebbe ripartire, ma dovrei trovare prima il tempo e saper scegliere tra la miriade di argomenti che potrei trattare. Non sono sicuro di riuscirci, ma vedremo come andrà

• Ho iniziato a usare GitHub, di conseguenza Git come DVCS, per condividere il codice su cui lavoro. C’è un po’ di tutto: esperimenti come couchdb-lua-viewserver oppure hpricot-pure ma anche lavori un po’ più utili e seri come redis-lua oppure ironruby-hpricot e ironruby-json.
• Proprio ironruby-hpricot e ironruby-json rappresentano i miei primi due progetti concreti per IronRuby e sono i rispettivi i port delle librerie hpricot e json (entrambe basate su Ragel) che sono disponibili per l’MRI. Ora come ora mi sto divertendo focalizzandomi principalmente sulla compatibilità di IronRuby con l’MRI, come del resto testimoniato dalla natura della decina di bug report che ho aperto, ma prima o poi inizierò anche con qualche progetto che si integri con il framework .NET (e ho già qualche idea in merito, manca solo il tempo).
• Con Twitter ormai ci ho preso gusto, soprattutto negli ultimi 6 mesi. Ho potuto seguire botte-e-risposta interessanti, sono potuto entrare in contatto con gente altrettanto interessante e tecnicamente molto preparata, inoltre la velocità con cui è possibile catturare notizie è stupefacente. Certamente la percezione di "interessante" e di "utile" può variare da persona a persona ed è proprio per questo che, a chi fosse ancora scettico, non posso far altro che dire che solo con la prova sul campo è possibile carpirne le potenzialità. Per la cronaca io stesso ero uno dei poco convinti, se non addirittura uno dei suoi quasi-detrattori. Ah, per inciso non mi iscriverò mai a Facebook. Si lo so, mai dire mai, ma c’è sempre l’eccezione che conferma la regola.
• Il mese scorso ho riesumato anche il mio tublelog, con tanto di nuovo look visto che quello vecchio faceva abbastanza schifo (il nuovo tema è uno di quelli disponibili sulla galleria di temi di Tumblr ma con modifiche e adattamenti sparsi).
• Giappone! Finalmente si sta per concretizzare un viaggio che per motivi sempre differenti sono stato costretto a rinviare più volte negli ultimi 6 anni. In realtà è già tutto pronto, manca solo la partenza OK non c’entra nulla con le mie attività online, ma mi andava di dirlo lo stesso.

Per ora chiudo qui, credo di avervi tediato abbastanza. Ora vedremo se riuscirò a tener fede al fatto che questo post non vuole essere uno pesce d’Aprile, ovvero spero di riuscire a non scrivere il prossimo messaggio tra altri 5 mesi ma di dargli un seguito con qualcosa di più interessante e tecnico entro breve.

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:

• Use \ as namespace separator e Description of what it means to use \ as namespace separator.
• Request for Comments: Namespace Separators
• Annuncio del cambiamento sulla mailing list php.internals

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…

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).

# 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à.

Digressioni & deliri messi da parte, ci terrei a confessarvi di avere una discreta quantità di argomenti utili e interessanti (spero) su cui scrivere, mi auguro di avere il tempo materiale per riuscire nell’impresa, prima però preferirei seguire un percorso riabilitativo al posting abbastanza dolce per cui… ecco il temibile tag <ul/>, una bella unordered list per voi:

• Chrome. Google è un fenomeno del marketing, me lo fa pensare il fatto che tutti stiano andando pazzi per un browser che fondamentalmente… crasha. Ehi, però crashano i singoli tab, mica tutto il browser: accidenti scusate, allora è tutto ok posso unirmi al delirio generalizzato! Ironie e crash a parte, il browser è veloce e in effetti v8 è una scheggia, magari non sempre sovraumana in tutte le circostanze come vorrebbero far credere con i benchmark studiati ad hoc ma si tratta comunque dell’engine ECMAScript/Javascript più performante attualmente in circolazione, lo sta dimostrando con dei fatti. Il browser in sè potrebbe non essere malvagio, ma magari ci rivedremo più avanti quando Google l’avrà sistemato ancora un po’, avrà fatto uscire qualcosa di compilato anche per le altre piattaforme e magari, già che sono in ballo, avrà smesso di fare presunti pasticci con l’EULA. Per ora sulla mia macchina virtuale linux di sviluppo sono rimasti solo i sorgenti di v8 e il risultato della loro compilazione, mi interessano molto di più di tutto il resto.
• A proposito di macchine virtuali, ho acquistato una VPS linux con SliceHost scegliendo il loro piano di base da 20$/mese. In seguito ho registrato un nuovo nome di dominio con Aruba (mi tornava comodo solo per la registrazione, infatti ho provveduto a cambiare immediatamente i nameserver autoritativi con quelli di SliceHost appena è stato possibile) e infine per gestire la posta ho creato un account di Google Apps sottoscrivendo il profilo standard nonché gratuito. Livello di soddisfazione: elevato, per ora. Ho diverse idee in testa, tra le varie figura anche la migrazione di questo blog (come del resto mi ripropongo da almeno due anni), ma ogni cosa avverrà a tempo debito.
• Scusate se non ve l’ho mai detto, ma io è un linguaggio di programmazione grandioso. Dinamico, basato sulla prototipizzazione degli oggetti come Javascript, interamente orientato ai messaggi, totalmente privo di keywords, dannatamente curioso e divertente da scoprire. Ok è molto giovane, ci sono pochissime librerie e la documentazione non è propriamente aggiornata con lo stato dello sviluppo, inoltre è probabile che non sarà nemmeno la next big thing in programming (anche se non si sa mai), però vi assicuro che è un linguaggio molto divertente.
• L’altro giorno ho acquistato il gadget allegato all’ultimo numero di Win Magazine (mai comprato in vita mia, sia chiaro): un telecomando IR per PC e Media Center, completo ovviamente di ricevitore USB. Semplice, sottile, 15€… ne volevo uno da tempo, ma non lo desideravo abbastanza intensamente da giustificare una spesa da 30€ o più. Peccato però che non sembri andare molto d’accordo con Zoom Player (da anni il mio player video per Windows preferito) per quanto riguarda la mappatura dei comandi. Fortunatamente però ZP è grande e può essere remotato in maniera piuttosto banale e documentata via TCP/IP oppure usando l’API SendMessage di Windows, per cui ho pensato: perché non sviluppare un’applicazione residente in background che ascolti i comandi provenienti dal mio bel telecomando e li traduca in comandi da inviare a ZP, mappando il tutto come diamine voglio io? Ci sto lavorando in C#, anche se il core è più lavoro di interazione con le API Win32 che altro. Qualche messaggio sull’argomento approderà anche su questi lidi.
• Dalla saga del telecomando è scaturito quasi per caso un altro piccolo progetto, questa volta più generico e potenzialmente più utile anche ad altri. L’idea inziale per l’applicazione di cui vi ho accennato poco sopra prevedeva l’utilizzo integrale di IronRuby per la sua realizzazione, tuttavia mi sono accorto presto che le sue capacità di interop sono ancora particolarmente limitate per diversi aspetti (ecco perché ho scelto di usare C#). In compenso il codice che ho scritto per le prove mi ha portato all’idea di effettuare un porting per IronRuby del modulo Win32API distribuito nella standard lib dell’MRI, il tutto in onore di una sana compatibility-love. Dopo 3 giorni avevo già una prima versione funzionante come testimoniato da questo gist, ora inizia il lavoro di pulizia e ottimizzazioni che si concluderanno con il rilascio del tutto su GitHub e con una serie di post sul blog dedicati all’argomento dal momento che ci sono svariate considerazioni tecniche che potrebbero risultare particolarmente interessanti.

Per ora è tutto. Per ora…

• supporto per una settantina di linguaggi/grammatiche differenti… anche se manca LOLCode, nonostante ci sia Brainfuck
• pastie (qui chiamati gist) pubblici o privati, anonimi oppure "identificati" se effettuati tramite il proprio account GitHub. Le operazioni, in questo caso, sono elencate all’interno della dashboard
• ogni gist può essere composto da file multipli, con possibilità di scaricare comodamente la versione raw di ogni file oppure di effettuare il download del pacchetto intero in formato tar.gz
• possibilità di modificare i propri gist con tanto di accesso allo storico delle varie revisioni
• clone URL pubblici e privati per ogni singolo gist, pronti per essere dati in pasto a Git

Provatelo, è veramente ottimo. Giusto per curiosità, questa è la pagina con i miei Gist pubblici…

Attualmente per installare LuaRocks nella maggior parte delle distribuzioni Linux è necessario prelevare il tarball ed eseguire i soliti passaggi ./configure && make && make install, tuttavia l’installazione sulle Ubuntu-derivate a partire da 8.04 Intrepid Ibex o su Debian a partire da 5.0 Lenny sarà molto più semplice dal momento che basterà installare il pacchetto luarocks tramite apt-get. Per Windows esiste un installer che automatizza le procedure, lasciando all’utente la scelta se installare un interprete Lua basilare senza librerie fornito dallo stesso installer o se utilizzare un interprete già installato nel proprio sistema. Tutte le informazioni necessarie al download e all’installazione di LuaRocks sono disponibili sul relativo sito.

Nel frattempo pochi mesi fa è nato un installer di Lua per Windows chiamato, con molta fantasia, Lua for Windows. Esso include molte delle più note librerie per Lua e un ambiente di sviluppo/debug già configurato e basato su SciTE. Si tratta quindi di un’ottima soluzione per avere in pochi secondi tutto il necessario per poter programmare in Lua, tuttavia LuaRocks non è stato ancora incluso per cui ecco i passaggi da seguire per integrare il tutto:

• Scaricare Lua for Windows (LfW) e procedere con l’installazione: la mia installazione è stata effettuata nel path proposto di default, ovvero C:\Programmi\Lua\5.1
• Scaricare LuaRocks per Windows, decomprimere l’archivio e aprire la shell dei comandi nella directory contenente install.bat
• L’installer di LuaRocks permette di specificare alcune opzioni. Ecco come installarlo in modo che sfrutti l’interprete reso disponibile da LfW e che utilizzi un unico path per l’installazione dei pacchetti rock:

  install /LUA C:\Programmi\Lua\5.1 /BIN C:\Programmi\Lua\5.1 /P C:\Programmi\Lua\5.1\LuaRocks\0.6 /CONFIG C:\Programmi\Lua\5.1\LuaRocks /TREE C:\Programmi\Lua\5.1\LuaRocks\ /SCRIPTS C:\Programmi\Lua\5.1\LuaRocks\ /FORCECONFIG

  Di default LuaRocks permette anche ad utenti non amministrativi di installare dei pacchetti rock locali (solitamente in %APPDATA%/luarocks/rocks/), mentre con l’opzione /FORCECONFIG verrà considerato un unico file di configurazione, quello specificato da /CONFIG, e un unico path per l’installazione di rock e script a livello di sistema, specificati rispettivamente da /TREE e /SCRIPT. Potete fare riferimento alla documentazione per un approfondimento in merito.

• La directory C:\Programmi\Lua\5.1 viene automaticamente aggiunta al PATH di sistema dall’installer di LfW per cui possiamo creare un hardlink ai file luarocks.bat e luarocks-admin.bat con il fine di poter invocare gli stessi più comodamente dalla shell. Da Windows XP in avanti si può operare come segue:

  cd C:\Programmi\Lua\5.1\LuaRocks\0.6
fsutil hardlink create ../../luarocks.bat luarocks.bat
fsutil hardlink create ../../luarocks-admin.bat luarocks-admin.bat

• Modificare la variabile di sistema LUA_PATH aggiungendo ai path già impostati da LfW il seguente percorso per il caricamento dei file della libreria LuaRocks:

  C:\Programmi\Lua\5.1\LuaRocks\0.6\lua\?.lua

Ora LuaRocks è installato e funzionante, basta aprire la shell dei comandi e lanciare luarocks search –all per visualizzare tutti i pacchetti rock disponibili sul server (è disponibile anche un elenco consultabile più comodamente) e luarocks install nomepacchetto per installare i pacchetti rock nel sistema. A questo punto negli script Lua basterà aggiungere la riga require "luarocks.require" che si occuperà di effettuare l’override della funzione require standard di Lua, rendendo possibile il caricamento delle librerie installate tramite LuaRocks. Alternativamente si può ottenere lo stesso risultato lanciando così l’interprete: lua -lluarocks.require

Ecco un esempio di come sfruttare una libreria installata tramite LuaRocks:

-- luarocks install colors

require "luarocks.require"
require "colors"

green = colors.new("#0f8923")

print("Verdolino:", green)    -- Verdolino:    #0f8923

LuaRocks con l’ultima release ha raggiunto un livello di maturità accettabile e l’elenco delle librerie disponibili sotto forma di pacchetti rock è in lento ma costante aumento, ma ci sono alcune applicazioni o framework che ne traggono beneficio per l’installazione e la gestione delle loro dipendenze come per esempio Kepler (un framework per lo sviluppo web generico in Lua), Orbit (un altro framework per lo sviluppo web in Lua, ma MVC oriented) e Sputnik (un wiki scritto in Lua, leggero ma estendibile). Per la cronaca, ecco invece cosa si era costretti a fare solamente un anno fa per avere un’installazione minimale di Lua in Windows e cominciare ad aggiungere librerie come LuaSocket.