In quest'ultimo periodo in ZephirWorks stiamo tutti lavorando come dei pazzi e non c'è nulla come ricevere un riconoscimento pubblico per il proprio impegno per trovare nuove energie. In particolare questa settimana Andrea Campi è stato nominato da Opscode Most Valuable Player per il suo prezioso contibuto alla release 10.6 di Chef Server. Vedere citata ZephirWorks sul blog di Opscode e riconoscuto l'ottimo lavoro fatto da Andrea è una grande soddisfazione per tutti noi.

In particolare Andrea (sacrificando un po' del suo sonno...) oltre ad aver migliorato il supporto per FreeBSD nei cookbook Chef ha rifattorizzato alcune parti di Chef Server rendendone più facile l'installazione su Cloud Foundry ovvero la Platform as a Service Open Source sviluppata da Vmware.

E' stata anche una grande soddisfazione essere l'unica azienda europea presente a Seattle al Community Summit di Opscode Chef che si è svolto nei primi giorni di Dicembre. Abbiamo scambiato idee e impressioni con professionisti provenienti da aziende importanti come HP, Dell, Rackspace giusto per citarne alcune. Per noi è stata una importante verifica di quanto noi come azienda siamo facendo per diffondere e creare metodologie, best practices e strumenti DevOps e del perché non dobbiamo avere nessuna soggezione e/o timore reverenziale rispetto a quello che succede dall'altra parte dell'oceano. 

Per quanto mi riguarda poi ultimamente mi sono trovato a discutere e a presentare metodologie e strumenti DevOps in alcune grandi aziende - tra le quali anche una delle più importanti banche italiane - e il feedback che ne ho ricevuto è stato di grande interesse. Anche questa è una soddisfazione :)

Last but not Least, Savory l'ultima creatura in casa ZephirWorks sta per raggiungere la beta. Pietro ci ha lavorato alacremente e l'ultima release è più bella che mai!

Se siete interessati a pubblicare la vostra webzine o il vostro giornale su iPad/iPhone (ma anche sul galaxy tab :) ) sappiate che presto dovremmo poter mandare un nuovo batch di inviti quindi registratevi su savory.io, chissà che babbo natale vi recapiti un account Savory nuovo di zecca.

Permalink | Leave a comment  »

Noi di ZephirWorks stiamo cercando una persona che si dedichi al nostro nuovo progetto Savory.

Savory è la nostra piattaforma di publishing mobile e nasce con l'obbiettivo di permettere anche a realtà piccole - blogger, webzine, piccole case editrici - o grandi ma con budget piccolo di avere una versione per i più diffusi dispositivi mobile dei propri contenuti.

La persona che stiamo cercando dovrà occuparsi della preparazione dei template grafici treesaver ma anche della comunicazione social di Savory e dell'interfacciamento con i clienti più importanti.

Deve essere un/una entusiasta del web design: ce lo/la immaginiamo che legge smashing magazine mentre fa colazione, crea un mockup HTML5 nel pomeriggio e sperimenta con le feature più esotiche di CSS3 la sera.

Ci piacerebbe poi che avesse le conoscenze base di javascript e/o di rails e sarebbe fantastico ma non indispensabile avesse fatto una precedente esperienza in una azienda editoriale.

Quello che garantiamo è una retribuzione più che soddisfacente con inquadramento ccnl del commercio.

Se ti riconosci in questa job description mandaci una mail a jobs@zephirworks.com o un DM a @zephirworks

Permalink | Leave a comment  »

I really like CloudFoundry, it is an amazing project with great potential. So many projects born from within a corporation end up as nothing more than neglected step-children, lagging way too much behind the commercial product they originated from. Vmware has been a lot more open, at least so far, and the OpenSource code is apparently the same code base as they use in production.

The downside of this is that, until the community grows and more developers start contributing, the choice of supported frameworks and services is mostly driven by the needs of the commercial product. A few companies have stepped up to the plate and generously donated their work to the project.

Our first contribution to the project is a CouchDB service; we have pushed it to github and sent a pull request. This is a first draft, a few features are still missing (notably backup/restore/rebalance, as well as quota enforcement); we will be working on these in the coming weeks. Despite these limitations, if you run CF on your own private cloud and your applications needs CouchDB, you can start using testing today.

The reason I'm quite confident with the code is that we are using it to run Chef on CF in staging, with a goal to get it to production in the coming weeks. CouchDB support was the major roadblock; with this service, I'm happy to report it works quite well. We are currently using an external Solr PaaS, but we will be developing a CF service for that as well.

Permalink | Leave a comment  »

I assume you are vaguely familiar with JNI, the useful if tricky technology that allows Java code to call native C code. If you are not, fair warning--you will find this post boring or even slightly headache-inducing. Go read The Oatmeal instead.

Working with JNI may not be the most exciting proposition, but it doesn't need to be painful. Tools like JNIWrapper take care of the mundane parts such as loading the native library from the classpath, mapping the different types and so on. It even comes with a tool that will create wrapper code for you, so the only work that is left for you is implementing Real Stuff (TM).

That's all fine and well, until you introduce a bug; at that point chances are you'll get an error message that is just about as useful as a necktie in the Sahara. To wit:

1
2
3
4

Exception c0000005, at 1EEE3416
Access violation: attempting to read memory at address 00000004
Native function stack data: 0,3f49c0,20201,801c6,65637845,6f697470,3063206e,30303030

Turning to your trusty debugger won't help you much; even if you set a breakpoint in Eclipse and single-step over the call to native code, it will just skip over--and crash you again. Unless your problem is very obvious (say, passing a null in the first place), not useful.

A solution

The good news is, depending on the operating system two debuggers may be allowed to attach to the same process. In my case, working on Mac OS X, that means I can use both Eclipse and Xcode; the process will happily jump between them depending on the function I'm currently in. If you have two monitor, it's actually mildly entertaining (at least for me--but maybe I'm just easily entertained).

How to work that magic:

1. set a breakpoint in Eclipse, and start the application;
2. when execution stops, go over to Xcode and select Product > Attach to Process from the menu; find your process in the list and click it (it will probably just show up as "java"; the pid is also provided);
3. if you want to, you can also set breakpoints in your C code;
4. now go over to Eclipse and continue execution or single step until you hit the native code. You will see Eclipse pause execution, and Xcode will bring up the function you just entered.

Bingo!

One word of notice: you may want to wait a few moments between steps 2 and 4, otherwise Eclipse may lose its wits and error out with an obscure message. That's especially true if you have a lot of breakpoints.

If you are that kind of person, you can do the same in plain old gdb. Not sure why you'd want to do that, but who I am to argue. However if you do figure it out, please leave a comment with instructions for other weirdos like you.

Trivia

In case you are wondering, the code I'm calling is actually Objective-C (CoreAudio), with a relatively thin wrapper in C. Also, the Java code is a faceless applet that interacts with JavaScript.

So in a typical scenario, the user clicks on something in the browser, that triggers JavaScript, which calls Java, that will quickly go through C only to have it call into Objective-C. Enough to make your head spin!

Permalink | Leave a comment  »

Nel post precedente ho parlato di Cloud Foundry di VMware, la prima Platform as a Service open, e di come testare la propria applicazione Ruby on Rails su Micro Cloud Foundry in una virtual machine sul proprio Mac (naturalmente è possibile usare Micro Cloud Foundry anche su GNU/Linux o MS Windows, cambia solo la versione di VMware da installare!).

Avevo anche anticipato di aver incontrato qualche difficoltà; ecco che ne parlo.

Configurazione di Rete

All'avvio di Micro Cloud Foundry, come raccontavo, viene mostrato un breve menu che propone di configurare varie cose, fra cui la rete. Nel post precedente ho detto di aver scelto DHCP; quello che, per semplicità, ho taciuto, è che il DHCP non ha funzionato.

Sniffando la rete, ho scoperto che il problema è legato al timeout del client DHCP, troppo breve. È una cosa che ho già visto succedere in altri server out of the box, che a quanto pare si aspettano di ricevere una risposta entro pochissimi istanti.

Niente di grave, Alt-F2, entro con l'utente vcap, faccio le mie verifiche e infine faccio partire la rete. Nel frattempo, però, scopro dalla documentazione che è possibile usare Micro Cloud Foundry anche senza avere accesso alla rete.

Utilizzare Micro Cloud Foundry offline

Se non si dispone di un collegamento di rete, o se per qualunque motivo si vuole lavorare offline, è comunque possibile utilizzare Micro Cloud Foundry senza accedere alla rete, come descritto qui.

Per farlo, bisogna innanzi tutto spegnere la macchina virtuale, configurare VMware per usare l'opzione NAT e riavviare Micro Clound Foundry, inserendo il token di configurazione:

vcap.me

Micro Cloud Foundry avvierà quindi la configurazione per l'utilizzo offline, impiegando un paio di minuti circa, dopo di che verrà mostrato l'ip della macchina virtuale.

A questo punto è necessario creare un tunnel SSH tra la propria macchina e la macchina virtuale:

ssh -L 80:IPDELLAMACCHINAVIRTUALE:80 vcap@IPDELLAMACCHINAVIRTUALE

Fatto questo, è possibile procedere col deploy, avendo però l'accortezza di specificare api.vcap.me come target per vmc:

vmc target http://api.vcap.me

Deploy di applicazioni Ruby on Rails

Per essere sicuri di poter usare la propria applicazione Rails con Micro Cloud Foundry, bisogna seguire alcuni accorgimenti.

Usare Bundler

In teoria, Micro Cloud Foundry supporta applicazioni 2.3 tradizionali, con le gemme specificate in config/environment.rb, purché freezate in vendor/gems.

In pratica, ci sono molte probabilità che la vostra applicazione non funzioni.

In questo e in altri casi, il messaggio d'errore fornito da vcap deploy è un po' criptico; è però possibile saperne di più col comando:

vmc files NOMEAPPLICAZIONE logs/migration.log

Il team di Cloud Foundry consiglia di usare sempre e comunque Bundler, e nel mio piccolo lo consiglio anch'io, e non solo per poter usare Cloud Foundry, ma soprattutto perché ci si guadagna in salute.

Rubygems

Un'altra questione che ho incontrato è legata alla versione di rubygems utilizzata: Micro Cloud Foundry usa attualmente rubygems 1.8.6, che ha problemi con il formato delle date nel gemspec di alcune gemme, tra cui paperclip e due dipendenze di Rails 3.1, ovvero rack-cache e tilt.

Conviene quindi assicurarsi che le gemme utilizzate funzionino con rubygems 1.8.6 prima di effettuare il deploy su Micro Cloud Foundry.

Conclusioni

Questa prova con Micro Cloud Foundry mi ha mostrato che il prodotto è ancora giovane, ma molto promettente, e consente, con relativamente poca fatica, di testare le proprie applicazioni in un ambiente di pre-staging pulito e comodo.

Micro Cloud Foundry promette di essere un'ottimo tool per vedere la propria applicazione in un ambiente di pre-staging, verificarne le performance, scoprire eventuali dipendenze impreviste, effettuare test d'integrazione e in genere capire come si comporterà l'applicazione in un ambiente di produzione, senza dover dedicare risorse e tempo prezioso per questo scopo.

Permalink | Leave a comment  »

Today I was doing a spike on a crazy idea we've been toying on for a while, and I found myself in need of disabling authentication on one API endpoint in an existing application.

1
2
3
4
5
6

class Cookbooks < Application
  before :authenticate_every

  # ...
end

Of course I could just edit the source, but where's the fun in that? Surely there must be a better way. Alas the application is written in Merb, which has been in "suspended animation" since the merge with Rails was announced. As a consequence there doesn't seem to be much information around on this kind of -nasty hacks- advanced topics.

Long story short, Merb accepts an optional -I [filename.rb] argument; the file will be loaded and evaluated at some point during the application startup.

That's not the end of the story though: the file is evaluated early in the boot; merb-core is available, but none of your models, controllers and so on. Not a big deal, you just have to use the correct hook.

1
2
3
4
5

Merb::BootLoader.after_app_loads do
  class Cookbooks
    before :authenticate_every, :only => [ :create, :update ]
  end
end

And that's it--this controller is now wide open, just the way I wanted it!

Permalink | Leave a comment  »

Da pochi mesi, VMware ha annunciato Cloud Foundry, la prima Platform as a Service open (Licenza Apache 2), che promette di rimuovere i costi e la complessità della configurazione dell'infrastruttura e degli ambienti di esecuzione, consentendo quindi all'utente di concentrarsi solo sullo sviluppo dell'applicazione, rendendo il deploy semplice e indolore.

Cloud Foundry supporta Spring, Sinatra e Ruby on Rails, Node.js, Groovy, Grails, Scala e altre piattaforme.

Volevo verificare di persona quanto sia semplice il deploy di un'applicazione Rails su questa piattaforma, sia per test da fare sulla propria macchina di sviluppo che in un ambiente di staging o di sviluppo, installando localmente Micro Cloud Foundry, una versione completa di Cloud Foundry che gira su una virtual machine, basata su Ubuntu Server a 64 bit.

Ho deciso di raccontare questa prova in due post, uno con i passi di base da seguire quando tutto va bene, il prossimo con le difficoltà incontrate e le mie impressioni su questo software.

Installazione

Dal momento che la mia macchina di sviluppo è un macbook, per prima cosa ho installato VMware Fusion (versione di prova gratuita per 30 giorni); poi mi sono registrato sul sito di Cloud Foundry ed ho aspettato qualche ora prima di ricevere le credenziali d'accesso per poter scaricare Micro Cloud Foundry.

Con quelle credenziali ho anche potuto generare un dominio di terzo livello per la mia applicazione di prova, sotto cloudfoundry.me. Fatto questo, mi è stato dato un token da inserire successivamente in Micro Cloud Foundry.

Appena accesa la macchina virtuale, viene mostrato un menu molto scarno, e di fatto la scelta obbligata è la prima, "configure", che fa poche domande: password dell'utente vcap (che sta per VMware's Cloud Application Platform, ed è anche il nome del progetto su GitHub), configurazione di rete (DHCP o statica), token di configurazione del DNS.

Deploy di un'applicazione

Per il deploy di un'applicazione, si usa il tool a riga di comando vmc, da installare con:

gem install vmc

A questo punto, per prima cosa si deve indicare la destinazione del deployment, ovvero:

vmc target http://api.TUODOMINIO.cloudfoundry.me

Poi (solo la prima volta) occorre creare un utente, con:

vmc register

Verranno richiesti un indirizzo email e una password. Si può quindi procedere al login:

vmc login

Dopo aver digitato le credenziali immesse prima, si può finalmente eseguire il deploy vero e proprio; dalla directory dell'applicazione, digitare:

vmc push

Verranno richieste alcune informazioni, fra cui:

• se usare il path corrente per il deploy;
• nome dell'applicazione;
• URL dell'applicazione (vedi più avanti);
• se si tratta davvero di un'applicazione Rails come rilevato;
• se si vogliono usare servizi, ovvero, attualmente, mongodb, mysql o redis.

Pochi secondi dopo, il deploy è terminato e l'applicazione è accessibile su TUODOMINIO.cloudfoundry.me.

Semplice, no?

Beh, in realtà ho barato: confesso che ho incontrato qualche difficoltà, e che dopo diverse prove ho optato per il deploy di un'applicazione rails 3.0 hello world, o quasi, perché ci sono numerose limitazioni sul tipo di applicazione, le gemme e altro ancora. Nel frattempo però ho avuto modo di scoprire alcune cose interessanti su Micro Cloud Foundry, delle quali parlerò nella prossima puntata.

Permalink | Leave a comment  »

E' passato un mese dall'ultimo post sul blog, wow! Nel frattempo sono successe un sacco di cose...

Andando in ordine, Euruko 2011, la conferenza europea di Ruby, è stata un grande successo, come si era intuito dal "tutto esaurito" fatto dai biglietti, venduti tutti in pochi minuti (!). E' stato molto bello vedere quanto è viva la community Ruby internazionale.

Ahime gli italiano erano tra i meno rappresentati; a parte noi (quest'anno eravamo sponsor) c'erano solo altre 3 italiani. Per fortuna uno di questi era il grande Paolo Perrotta (@nusco), di gran lunga il miglior speaker presente :)

Il livello dei talk e degli speaker è stato un po' altalenante, ma per il resto un'ottima conferenza, organizzata in modo impeccabile. Farò di tutto per andare anche l'anno prossimo (Amsterdam).

Appena tornato da Berlino è stata la volta del Ruby Day, il primo evento di questo tipo e di queste dimensioni in Italia. 200 persone, per di più in un giorno feriale, sono state un successone! Complimenti davvero a tutti quelli che si sono dati da fare.

Alcune sessioni sono state molto stimolanti, penso ad Antonio Carpentieri (@acarpe) e anche di più a Matteo Vaccari; soprattutto Matteo ha dato il via ad una discussione in sala che ho visto raramente ad un evento italiano. Segno dell'interesse e della vivacità della nostra community; speriamo sia un ulteriore segnale che porti ad incontrarsi più spesso, anche con eventi più piccoli.

Ultimo ma almeno per noi altrettanto importante è stato il party per il lancio di Varnish 3, che abbiamo organizzato in contemporanea mondiale con un'altra ventina di città. 20 persone si sono ritrovate in ufficio da noi per 4 ore di presentazioni e chiacchere libere su Varnish, ma anche su altri argomenti di devops e "operations 2.0".

E' stata una bella esperienza, di nuovo con molta partecipazione del gruppo (a dire il vero composto in gran parte da facce ben note :) ). Durante la serata è emerso un interesse diffuso per proseguire e approfondire queste tematiche; abbiamo deciso di iniziare con una mailing list (https://groups.google.com/group/devops-italia), ma l'intenzione è quella di organizzare altri eventi e barcamp in autunno. Se ne riparlerà sicuramente a settembre!

Dopo tutti questi impegni, settimana prossima sarò in ferie ma la stagione delle conferenze non è ancora finita... Node.js a Settembre, MongoDB in autunno, e molto ancora. A presto!

Permalink | Leave a comment  »

Continuiamo la panoramica sulla nuova release di Varnish (iniziata nel post precedente) analizzando le nuove opzioni a disposizione per controllare quali pagine devono essere escluse dalla cache.

Ban e Purge

Varnish ha diversi meccanismi per eliminare un oggetto dalla cache; aggiunti in diversi momenti nella storia del progetto, svolgono compiti diversi ma sicuramente generano confusione. Varnish 3.0 porta chiarimenti nella nomenclatura, ma anche funzionalità potenti.

Verbo PURGE

Il metodo classico viene direttamente da Squid:

acl allowed_for_purge {}

sub vcl_recv {
        if (req.request == "PURGE") {
                if (!client.ip ~ allowed_for_purge) { error 405 "Not allowed."; }
                return (lookup);
        }
}

sub vcl_hit {
        if (req.request == "PURGE") {
                set obj.ttl = 0s;
                error 200 "Purged.";
        }
}

sub vcl_miss {
        if (req.request == "PURGE") {
                error 404 "Not in cache.";
        }
}

Con questo VCL è possibile eliminare un oggetto dalla cache semplicemente con una richiesta HTTP:

curl -X PURGE http://www.example.com/index.html

L'unica novità a riguardo è il comando purge, che sostituisce la manipolazione esplicita del ttl:

sub vcl_hit {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
        }
}

La semplicità di questo metodo è anche il suo limite: se volessimo far scadere dalla cache tutte le pagine di una sezione del sito dovremmo inviare centinaia o migliaia di richieste esplicite. 

Ban

Un ban indica a Varnish di non servire contenuti dalla cache in base a regole che possono essere anche molto sofisticate.

E' possibile inserire un ban tramite l'interfaccia di management:

req.http.host ~ "example.com" && req.url ~ "\.png" && obj.http.set-cookie ~ "USER=JOHN_DOE"

o anche da VCL:

sub vcl_recv {
        if (req.request == "BAN") {
                if (!client.ip ~ allowed_for_purge) {                        error 405 "Not allowed.";
                }
                ban("req.http.host == " + req.http.host "&& req.url == " + req.url);

                error 200 "Ban added"
        }
}

La semantica dei ban è molto precisa ed è importante capirla a fondo. I ban vengono memorizzati da Varnish, e ogni richiesta successiva che passa dalla cache causa la valutazione delle condizioni; se la richiesta matcha le condizioni viene gestita come miss e la risorsa viene eliminata dalla cache.

Gli oggetti già presenti in cache non vengono eliminati immediatamente; in altre parole, se un oggetto non viene mai richiesto rimarrebbe comunque in cache per tutta la durata del TTL. Per ovviare a questo problema e recuperare spazio nella cache, Varnish 3.0 abilita di default un thread in background che attraversa tutta la cache e fa scadere gli oggetti corrispondenti. Quando tutte le risorse sono state esaminate, il ban scade e viene cancellato.

Un ban non impedisce l'inserimento di nuove risorse in cache, anche se rispettano le condizioni del ban stesso. Questo è un punto importante se lo scopo è prevenire il caching di determinate risorse (e non semplicemente forzare il refresh): in questo caso sarà necessario modificare il VCL per vietare il caching di quelle URL, prima di inserire il ban.

Una nota finale per chi usa lo storage persistente: i ban vengono salvati nello storage e vengono riapplicati automaticamente dopo un riavvio.

Permalink | Leave a comment  »

La prossima major release di Varnish è finalmente in dirittura d'arrivo, la prima beta arriverà fra pochi giorni, seguita in tempi brevi dal rilascio pubblico.

Visto che al momento le informazioni in italiano sono poche per non dire inesistenti, nei prossimi giorni pubblicheremo qualche appunto su cosa vi potete aspettare da Varnish 3.0.

Ottimizzazioni gzip

La funzionalità che aspettavo con più ansia: nella nuova versione coesistono senza problemi out of the box, e si comportano esattamente come ci si può aspettare. Se però vi serve più controllo, sono state aggiunte delle direttive per controllare compressione e decompressione delle risposte.

Se vi interessano i dettagli tecnici:

In Varnish 2 ESI interagiva male con le risposte con encoding gzip, col risultato che era necessario disabilitare gzip dal backend--ammesso che il vostro carico ve lo consentisse. Peggio ancora, la conseguenza è che era Varnish a sua volta inviava i contenuti di risposta non compressi, ed era quindi necessario mettere davanti a tutto un ulteriore proxy per comprimere.

In Varnish 3 tutto il processo è stato ridisegnato e ottimizzato: Varnish di default chiede al backend il contenuto compresso; se il client non supporta gzip (e sono pochi) lo decomprime. La copia cachata è solo quella compressa, e questo si traduce anche in più oggetti a parità di cache, che non guasta.

ESI e gzip

Il caso ESI è più complesso, perché Varnish deve gestire la possibilità di documenti non compressi inclusi in pagine compresse e viceversa. La nuova implementazione gestisce questi casi bene, ed è anche molto ben pensata e realizzata.

Ogni documento su cui ESI è abilitato viene temporaneamente decompresso quando viene ricevuto dal backend, e Varnish genera del bytecode di controllo che tiene traccia della posizione esatta dell'include. In seguito quando è il momento di servire la pagina è possibile semplicemente concatenere i pezzi.

Qualcosa di questo tipo:

Contenuto originale:

<html>
....
<esi:include src="include1"/>
... 
<esi:include src="include2"/>
...
</html> 

Viene salvato in memoria come:

[parte 1, compressa]
[bytecode che indica la presenza dell'include di "include1"]
[parte 2, compressa]
[bytecode che indica la presenza dell'include di "include2"] 
[parte 3, compressa]

Al momento di un hit:

[parte 1, compressa]
[risultato della richiesta al backend di "include1", compresso]
[parte 2, compressa]
[risultato della richiesta al backend di "include1", compresso] 
[parte 3, compressa]

La parte importante è che il risultato finale non ha bisogno di essere decompresso e ricompresso: gzip supporta una modalità per cui tra una "parte" e l'altra è sufficiente inviare un comando di reset. Furbo, no?

Per approfondimenti e altre informazioni:

• https://www.varnish-software.com/blog/varnish-30-changes
• http://www.varnish-cache.org/lists/pipermail/varnish-misc/2011-January/005510...

Permalink | Leave a comment  »

TOC.pdf Download this file

Permalink | Leave a comment  »

Per serendipità, un post interessante oggi sul blog di book republic (traduzione di un post di Craig Mod):

Molti di questi parametri sono relativi all’accessibilità. Trovo terribile [sic] i più blasonati ereader (come le app di Wired / New Yorker / Time magazine) facciano a meno dell’accessibilità propria del testo digitale. Certo, questa è una fase di transizione, ma perché non partire subito con il piede giusto? Il testo digitale non è lo stesso artefatto del testo stampato. Non trattiamolo allo stesso modo.

Il motivo per cui la maggior parte delle pubblicazioni digitali per cellulare e tablet sono, nella migliore delle ipotesi, appena sufficienti è che si limitano ad adattare alla meno peggio un'esperienza che è aliena al nuovo mondo digitale, riportando di fatto l'orologio indietro ai CD-ROM multimediali degli anni '90.

Le tecnologie ci sono tutte, quel che mancano in gran parte dell'editoria sono fantasia e capacità di innovare.

Permalink | Leave a comment  »

Interessante articolo di Oliver Reichenstein che si innesta su una delle controversie più sentite nel settore editoriale:

The idea of creating a business class for online news where is not about buying information, but buying better experience, it’s about service and customer experience. That’s right: Customer (paying), not user (free).

http://www.informationarchitects.jp/en/business-class-news/

Non si tratta solo della questione paywall sì-paywall no, ma di qual è il prodotto dell'editoria oggi, nel mondo di Twitter / blog / mobile Internet / free press.

Paywall, pubblicità aggressiva, corsa alla scoop a scapito della qualità del giornalismo, sono tutti sintomi dello stesso problema: l'illusione che i lettori / utenti abbiano bisogno di leggere questa notizia, e di leggerla da noi. Questa è una assunzione completamente sbagliata: siamo sovraccarichi di contenuti, il problema semmai è come ottenere contenuti di qualità e rilevanti.

Bisogna uscire dalla mentalità per cui la notizia è il prodotto di valore e capire che è pura commodity. Per me il prodotto è l'insieme: l'esperienza d'uso; la linea editoriale come filtro delle notizie dal rumore; il posizionamento. Il tutto in un continuum dove ogni testata può scegliere di privilegiare un aspetto su un altro per meglio attirare l'audience a cui mira.^[1]

Il parallelo dell'articolo regge bene: per andare a Singapore posso scegliere di volare low-cost, Economy o Business Class; il risultato è lo stesso, ma l'esperienza sarà ben altra. Il tradeoff è spendere di più per ottenere qualcosa di più, sia in termini reali (più spazio per le gambe, lo champagne di benvenuto) che in termini di status.

Con le debite differenze, non ho dubbi che la stessa scelta sia trasferibile all'editoria.

1. Naturalmente esisteranno sempre contenuti originali ed esclusivi, aziende in grado di produrli e consumatori interessanti a comprarli. Il punto è che la stragrande delle notizie non vinceranno il Pulitzer, e che il lettore medio che visita un sito durante una pausa in ufficio non sta cercando quello.

Permalink | Leave a comment  »

Wikipedia la descrive così:

"Con il termine pet therapy (in italiano, zooterapia) s'intende, generalmente, una terapia dolce, basata sull'interazione uomo-aminale […] rafforza e coadiuva le tradizionali terapie e può essere impiegata su pazienti affetti da differenti patologie con obiettivi di miglioramento comportamentale, fisico, cognitivo, psicosociale e psicologico-emotivo”

Qualche giorno fa ci è venuta a trovare Olga, la gattina di Margherita, il nostro grafico.
Olga ha fatto un salto dal veterinario per un raffreddore. L'orario di lavoro era ormai prossimo, e Margherita ha deciso di portarla in ufficio. La sorpresa è stata estremamente gradita, e le pause sigaretta si sono ridotte, sostituendole con qualche coccola alla piccola micia rossa,  limitando quindi l'uso di nicotina e caffè :).
Ci si poteva aspettare di tutto da un gattino di 60 giorni. Sarebbe stato divertente (e qui qualcuno potrebbe avere qualcosa da ridire) vederla “zompettare” da una scrivania all'altra facendo qualche simpatico danno. In realtà Olga è stata perfetta. Una palla di pelo composta ed educata che ha reso l'ambiente di lavoro rilassato e divertito.

A questo punto lancio una petizione per il Micio Zephirworks, o comunque chiedo ai colleghi muniti di pets di condividerli con noi, senza per forza lasciarli a casa :).
Devo dire che è stata proprio una bella esperienza.
In Austria, addirittura, esiste un patentino speciale che consente ai padroni di portare il proprio animale in ufficio. Il tutto ovviamente è a discrezione delle aziende e rivolto principalmente a Fido, ma sembrerebbe un bel modo per non lasciarli da soli tutto il giorno migliorando inoltre l'umore del team di lavoro.

Senza entrare nei meriti della psicologia, gli animali in ufficio portano il buon umore e ribadisco, possono trasformare la pausa caffè o sigaretta in un intervallo più salutare che ha come unica controindicazione un tappeto di peli sui propri vestiti che non è poi cosi terribile....allergie permettendo.

Non è stato da meno Pablo.

Pablo è un gatto, tanto per iniziare, giovane e muscoloso. Un "fusto" pazzesco insomma, che girava per l'ufficio cercando nascondigli in cui infilarsi. Pablo è stato discreto, curioso e diffidente come solo un vero gatto macho sa fare. Si è accomodato sotto i mobili della cucina e ha trascorso lì una buona parte del tempo. Pablo non è uno sprovveduto, ha dimostrato pazienza e comprensione per noi bipedi. Ci ha lasciati lavorare facendoci visita di tanto in tanto e ha sgranocchiato qualche crocchetta. Quando si è fatta l'ora di andare a casa, ha preso la situazione sotto controllo e iniziando a miagolare ad Andrea Campi qualcosa del tipo “andiamoandiamoandiamoandiamoandiamo...”. Andrea che il miagolese lo capisce, ha accontentato Pablo, vista anche la tarda ora.

Speriamo che Pablo ci torni a trovare!

Olga At Work:

Permalink | Leave a comment  »

Questo è il secondo di una serie di post su come sfruttare al meglio Varnish. Il primo articolo parlava di access log con ESI.

In questo secondo post invece ci occupiamo di come conciliare due esigenze apparentemente in contrasto.

Da un lato, la ragione stessa di esistere di un proxy cache è quella di conservare il più possibile dei contenuti di un sito o di una applicazione nella propria cache, e di servirli dalla cache senza alcun intervento del backend. Varnish di default fa un ottimo lavoro nello scegliere i tempi di permanenza in cache in base agli header presenti nelle risposte; questi header però sono solitamente pensati per i browser e tarati in modo che questi debbano di tanto in tanto verificare col server se il contenuto è aggiornato. Per questo spesso si tende a forzare il TTL in Varnish perché sia molto più lungo.

D'altro canto la maggior parte dei siti ha contenuti che cambiano nel tempo, e preferiremmo che queste modifiche fossero rispecchiate nel più breve tempo possibile. L'ideale sarebbe anche che questo avvenisse col minimo sforzo e senza richiedere altri strumenti software.

Come far coesistere questi requisiti?

Purge della cache

Un modo sbrigativo ma efficace è quello di effettuare un purge selettivo della cache: in altre parole, il CMS (o qualsiasi altro software usato per gestire i contenuti) comunica a Varnish che una certa pagina è cambiata e che deve essere richiesta di nuovo al backend.

Se implementato correttamente questo approccio funziona bene, ma ha alcuni svantaggi:

• disponibiità software: il comando può essere inviato via HTTP o su un socket TCP di amministrazione, ma in entrambi i casi il CMS deve supportare questa modalità; ad oggi la lista dei CMS compatibili è cortissima.
• scarsa scalabilità: il backend deve inviare a *tutti* i proxy Varnish il comando di purge. In caso di problemi (se la richiesta fallisce, va in timeout e così via) ci si può ritrovare con delle cache inconsistenti, per cui gli utenti vedranno contenuti diversi.
• dipendente dall'architettura di rete: ogni backend deve avere una lista aggiornata di tutti i proxy, deve poterli raggiungere (quindi potrebbero essere necessarie nuove aperture nei firewall), ed è necessario accertarsi di non introdurre vulnerabilità e punti di fallimento.

Per i siti più semplici queste limitazioni possono essere poco significative o comunque gestibili; diventano più problematiche se l'architettura prevede backend diversi per differenti componenti.

Ma se si usa ESI in modo significativo, la cosa diventa presto incontrollabile: immaginate una pagina composta da una decina di "porzioni", serviti da 4 backend diversi. Una modifica di uno qualunque delle porzioni porterebbe ad una richiesta di purge, che quindi diventerebbe un'operazione molto frequente.

Come sempre, possiamo risolvere questo problema aggiungendo un livello di indirezione.

Include ESI con timestamp

La tecnica base è la stessa dell'articolo precedente: anziché servire direttamente la richiesta, il backend servirà un documento che contiene soltanto una direttiva ESI, che contiene l'URL interna del vero documento, più un timestamp (o un contatore che viene incrementato, poco importa); quando si vuole forzare l'aggiornamento della cache, il CMS dovrà rigenerare anche il documento intermedio, incrementando il timestamp. Questa è una tecnica familiare a tutti i team web, perché comunemente usata per le risorse statiche, ad esempio per i CSS.

Per fare un esempio, immaginate di avere un sito di news e che vogliate che eventuali correzioni in un articolo diventino immediatamente disponibili. Supponendo di avere un articolo con una URL tipo /news/20110412/hello-world.html, saranno necessarie queste modifiche:

1. il CMS dovrà fare in modo che il vero testo dell'articolo sia servito da un'URL diversa, ad esempio /news/20110412/_hello-world.html;

2. sempre il CMS, ad ogni modifica dovrà generare anche un documento che risponde all'URL originale, e che conterrà solo:

   <esi:include src="/news/20110412/_hello-world.html?20110413010045"/>

   dove "20110413010045" non ha nessun significato particolare, se non che cambia ad ogni modifica rilevante;

3. infine bisognerà configurare Varnish per non cachare il documento intermedio ma processarlo con ESI, e cachare a lungo il documento effettivo.

Il risultato finale è che ad ogni richiesta Varnish chiederà al backend il documento intermedio, e processandolo con ESI cercherà nella propria cache il documento effettivo tenendo conto dell'URL completa, incluso il timestamp. Se questo cambia, Varnish chiederà nuovamente il documento al backend.

La parte migliore è che questa tecnica si applica direttamente anche per frammenti di pagine ESI: in questo modo potremo far scadere dalla cache il testo principale dell'articolo, ma continuare a servire dalla cache le parti fisse tipo header e sidebar. Il tutto senza hardcodare gli indirizzi dei server Varnish, e senza limitazioni al numero degli stessi. Niente male!

Permalink | Leave a comment  »

The first few months of 2011 have seen a lot happen in the world of dynamic languages; from Clojure picking up speed to Scheme finally taking the front of the stage. Heck, at some point I thought we would see SNOJOB make a comeback!

If I had to pick just one project that is making a big splash, that would be JRuby; especially now that 1.6.0 has come out it has become a serious contender. The team is doing an amazing job there, pushing the JVM to the limit and even innovating comparing to Java in some areas (Unicode beyond UTF-16, for starters). My experience with JRuby so far has been excellent: we were able to switch most of our software over with little to no changes.

More exciting news are coming from the Perl 6 field: Rakudo Perl has had a few releases already (and yes, Duke Nukem Forever is also coming out in 2011, and yes, it will be written in Perl 6).

And yet, despite all this flurry of activity, something is still missing.

One of our projects manages collections of millions of photos for our customers, and we need to extract, process and manipulate metadata. There are a few tools around to do that, but most of them fall short; the de-facto standard is a Perl application called ExifTool. In a primarily Ruby shop like we are, each days that translates into hundreds of executions of a Perl interpreter in a few minutes at peak time. So far we have been able to manage that, but I figured there had to be a better way. And so, a few weeks back I finally sat down to do exactly that.

To cut to the chase, today we are announcing ruby-perl, a Ruby gem that bridges this gap by allowing Ruby to invoke Perl in a seamless and efficient way.

For Ruby developers this is a big opportunity, since it makes a huge amount of useful code available for reuse, including my favorite. More importantly, it has the opportunity to open us as a community up to a rather different culture and style of software development.

Perl users also get a pretty good deal too: through JRuby they are now able to run their software, and any web application in general, on a JVM, with no changes to their code.

Check out the code on GitHub, and let us know what extra-cool things you will do with it.

Permalink | Leave a comment  »

Sono sempre più i siti (soprattutto quelli con più traffico) che disabilitano i log degli accessi del loro web server, nel tentativo più che giustificato di limitare l'I/O su disco. Da Google Analytics a Omniture agli ultimi nati come mixpanel e gaug.es, le opzioni disponibili per tracciare e analizzare i propri utenti sono molte, e offrono parecchi vantaggi rispetto ai classici log analyzer.

D'altra parte molte aziende sono restie a fare questo passo, vuoi perché negli anni hanno costruito dei processi interni attorno alla raccolta e analisi dei log; vuoi per ragioni psicologiche. Se però arriva il momento di inserire Varnish (o qualsiasi altra soluzione di caching, se è per questo), le cose si complicano.

Lo scopo principale di un proxy cache è servire la maggior parte delle richieste da una cache molto veloce, alleggerendo così il carico del server web o dell'application server; in altre parole, evitando di mandargli quante più richieste possibili. Questo però significa che il web server avrà un log molto parziale degli accessi, il che lo rende praticamente inutile (anzi, vi consiglio di disabiitarlo proprio!). D'altra parte Varnish di default non salva un log delle richieste, perché farlo potrebbe rallentarlo non poco. Come fare?

Fortunatamente la soluzione c'è, ed è anche semplice da implementare; sfrutta ESI, una tecnica relativamente avanzata ma simile ai Server-Side Include (insomma, i classici .shtml) con cui più o meno ogni sviluppatore ha familiarità; ma anziché essere gestita dal server web, è implementata da varnish stesso. Descrivere ESI in dettaglio renderebbe questo post molto lungo e molto tecnico, ma non è necessario: quel che serve ai nostri scopi è molto semplice.

Supponendo che vogliate accelerare la home del sito (/index.html, di solito), non dovete fare altro che rinominarla (ad esempio in /_index.html) e creare un nuovo index.html che contiene solo:

    <esi:include src="/_index.html" />

Attenzione allo "/" finale, è obbligatorio! Questa direttiva dice a Varnish di richiedere il file, e di inserire il suo contenuto al posto del tag.

Ora viene la parte importante: configurate Varnish per *non* cachare il nuovo index.html, e per cachare /_index.html per un tempo sufficientemente lungo (quanto lungo dipende dal vostro sito e dal vostro business).

Il risultato finale è che Varnish non troverà /index.html in cache, lo chiederà al server web che lo servirà e loggerà nel suo access log, proprio come volevamo.

Permalink | Leave a comment  »

Da pochi giorni è stato rilasciata la versione 4.3 di iOS. Sicuramente una delle novità più interessanti, introdotte da Apple, è il nuovo Nitro JavaScript engine, il quale permette una forte riduzione nei tempi di esecuzione. Poco dopo il rilascio è stato subito notato, da The Register e da altri, come i miglioramenti sulla velocità di esecuzione del JavaScript siano vincolati all'esecuzione su Safari, mentre lo stesso JavaScript eseguito in modalità HomeScreen o in una UIWebView di una App mostra performance molto più basse.

Vista l'attenzione che riponiamo sul rapporto JavaScript&iOS, ci siamo posti l'obiettivo di misurare l'entità di questa differenze di performance variando il dispositivo, la versione di iOS ed l'ambiente di esecuzione del JavaScript. Per i test abbiamo usato il JS benchmark di SunSpider. Di seguito è riportata la tabella con i risultati. Gli errori non sono riportati poichè tutti simili tra loro ed intorno all'1%; i valori nella tabella sono espressi in secondi.

Da subito si evince che le differenze di prestazione, dovute all'ambiente dove viene fatto girare il benchmark, sono evidenti sotto iOS 4.3. Infatti i tempi di esecuzione dentro Safari sono meno della metà degli altri casi e questo si verifica su tutti i dispositivi testati. Sono invece simili le prestazione dentro la HomeScreen e la UIWebView, con una lieve differenza a favore di UIWebView. Abbiamo, anche, verificato i tempi di esecuzione in iOS 4.2; in questo caso non si notano differenze rispetto all'ambiente dove viene eseguito il benchmark ed i tempi sono in accordo con quelli di iOS 4.3 usando HomeScreen o UIWebView. Per completezza abbiamo anche verificato cosa succede sul simulatore. Qui i tempi sono tutti simili sia nella versione iOS 4.2 che in quella 4.3.

In conclusione quello che sembra evidente è che il boost di prestazione è limitato alle applicazioni JavaScript che girano sotto Safari, negli altri casi si rimane allo stato di iOS 4.2. Che sia un bug, una disattenzione o una scelta volontaria da parte di Apple non ci è dato saperlo. Comunque in questo post, legano le differenze di prestazione alla natura delle ottimizzazioni introdotte da Nitro JavaScript engine:

The engine converts JavaScript code into native ARM machine code.

Third parties have never been able to get access to [...] library that generates native code dynamically

Permalink | Leave a comment  »

Japan is exceptionally well-prepared to deal with natural disasters: it has spent more on the problem than any other nation, largely as a result of frequently experiencing them.  (Have you ever wondered why you use Japanese for “tsunamis” and “typhoons”?)  All levels of the government, from the Self Defense Forces to technical translators working at prefectural technology incubators in places you’ve never heard of, spend quite a bit of time writing and drilling on what to do in the event of a disaster. [...]

The overwhelming response of Japanese engineering to the challenge posed by an earthquake larger than any in the last century was to function exactly as designed.  Millions of people are alive right now because the system worked and the system worked and the system worked.

http://www.kalzumeus.com/2011/03/13/some-perspective-on-the-japan-earthquake/

Non oso immaginare cosa sarebbe successo in Italia, visto che basta un abete per metterci fuori gioco per ore...

Permalink | Leave a comment  »

Come forse avete già notato, nei giorni scorsi abbiamo messo online il
nuovo sito di Zephirworks, rivisitato nella sua veste grafica e nei
contenuti.

Crediamo che uno dei nostri punti di forza sia la capacità di
costruire e coltivare un buon rapporto con i nostri clienti. Per
questo abbiamo voluto dare spazio proprio ad alcuni di loro, lasciando
che raccontassero la loro esperienza.

Questo restyling è stato il mio primo progetto (sono arrivata in
ZephirWorks solo da due mesi), e per me è stato un piacere iniziare a
fare la conoscenza di alcuni di voi.

A proposito, mi chiamo Alice Mancini; ho lavorato per qualche anno
come addetta stampa nell'ambito teatrale e musicale, e a Current Tv
come office manager.
In ZephirWorks mi occupo di segreteria, amministrazione, relazioni
pubbliche e supporto all'organizzazione di eventi.

Potete contattarmi per qualsiasi informazione, sarò felice di aiutarvi
e di mettervi in contatto con i nostri project manager, sviluppatori
software e web designer per realizzare i vostri progetti.

Permalink | Leave a comment  »