Git flow – seguire il flusso

Posted by & filed under Technical.

Git è indispensabile.

Git è il distributed version control system (DVCS) semplicemente irrinunciabile per chi sviluppa software; rappresenta lo spazio in cui il codice si muove, si sviluppa, si ramifica, si fonde ed in cui infine prende forma.

In questo stesso spazio il codice esplode in una galassia di commit, merge, conflict, damn: regression!, reset, rebase, abort and commit again.

Git flow to the rescue!

Serve ordine ed organizzazione. Ed è per questo motivo che abbiamo scelto git-flow.

Nel gennaio del 2010, @nvie (Vincent Driessen) ha pubblicato un post intitolato “A successful Git branching model”, in cui ha spiegato la sua strategia per mantenere i repository Git ordinati e puliti insieme al quale ha poi rilasciato git-flow.

Git-flow è una serie di estensioni di Git che impongono una struttura solida ai repository e permettono lo sviluppo incrementale e stabile di un’applicazione.

Cominciamo a mettere mano alla shell.

La nostra applicazione si chiamerà Enterprise; inizializziamo un repository git:

$ mkdir enterprise $ cd enterprise/ $ git init Initialized empty Git repository in /Users/eddie/Projects/enterprise/.git/

Dopo aver installato git-flow configuriamo il nostro repository per utilizzare git-flow:

$ git flow init No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes? feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? []

La branch structure di git-flow

Git-flow impone una branch structure al repository; seguendo la convezione che ci viene proposta, il nostro progetto sarà organizzato in diverse branch.

La struttura principale è composta da due branch “perpetue” che seguiranno dall’inizio alla fine la nostra applicazione:

  • master
  • develop

I nostri utenti usano origin/master, la branch principale della codebase. E noi lavoriamo per offrire un’applicazione sempre migliore, con nuove funzionalità, solida e senza bug… semplicemente production-ready.

Se origin/master è il nostro prodotto in vetrina, origin/develop è il nostro laboratorio. In questa branch converge tutto il lavoro incrementale che facciamo per estendere l’applicazione con nuove e strabilianti funzionalità.

Ogni nuova funzionalità che sviluppiamo è una feature che inizia da origin/develop e finisce in origin/develop. Queste branch possono essere considerate branch di supporto che nel modello strutturale di git-flow aiutano lo sviluppo parallelo e l’organizzazione di nuove feature, la preparazione delle nuove release ed il quick fix di bug in produzione (sigh). Diversamente dalle branch master e develop, queste branch hanno un lifetime limitato.

Le branch di supporto hanno questi prefissi:

  • feature
  • release
  • hotfix
  • support

At work! – features e release

Mettiamoci al lavoro e cominciamo ad estendere la nostra applicazione, “Enterprise”.

A partire da develop creiamo una nuova feature branch che chiameremo warp_drive.

$ git flow feature start warp_drive

Questo in pratica equivale ad un git checkout -b warp_drive… commit dopo commit realizziamo questa feature. Quando tutte le nostre spec saranno verdi (^_^) saremo pronti per promuovere la nostra feature ed includerla in develop.
Git flow si posa integralmente su Git e quindi tutte le best practices continuano a valere: checkout -b backup, merge develop, rebase develop, ecc…

Quando siamo pronti:

$ git flow feature finish warp_drive

Una volta risolti eventuali conflitti warp_drive sarà diventato parte di DEVELOP, e dal prossimo push, tutte le nuove feature che verranno sviluppate a partire da develop avranno il nuovo warp_drive.

Dopo che avremo sviluppato altre feature come turbolift, transporter, holodeck, deflector shield e tractor beam, avremo integrato un numero sufficiente di nuove funzionalità per giustificare un incremento di versione. Dopo esserci assicurati che develop passa tutti i testi, siamo pronti per una nuova release.

$ git flow release start 0.1.0 Switched to a new branch 'release/0.1.0' Summary of actions: - A new branch 'release/0.1.0' was created, based on 'develop' - You are now on branch 'release/0.1.0' Follow-up actions: - Bump the version number now! - Start committing last-minute fixes in preparing your release - When done, run: git flow release finish '0.1.0'

Stiamo creando una nuova branch a partire da develop con l’obiettivo di aggiornare la nostra versione master; da questo momento in poi accettiamo solamente modifiche minori o dettagli, infine incrementiamo il numero di versione, aggiorniamo il CHANGELOG, e chiudiamo questa release.

Git flow integra perfettamente il tag system di git quindi la nostra codebase sarà sempre annotata con label che segnano i passi intermedi di sviluppo.

$ git flow release finish 0.1.0 Switched to branch 'master' Merge made by the 'recursive' strategy. ... Deleted branch release/0.1.0 (was 9a54df0). Summary of actions: - Latest objects have been fetched from 'origin' - Release branch has been merged into 'master' - The release was tagged '0.1.0' - Release branch has been back-merged into 'develop' - Release branch 'release/0.1.0' has been deleted

In questo momento master ha raggiunto develop (git merge “under the hood“) e dal prossimo push & deploy Enterprise sarà in produzione.

bug!

Bug, modifiche urgenti e cambiamenti non pianificati che devono essere fatti con la massima priorità sono gestiti in branches particolari: le hotfix.

Una hotfix è una branch che parte da master ed apporta una correzione all’applicazione in produzione. Per esempio, diciamo che la versione Enterprise 1.3 ha dei problemi al sistema di navigazione. Le features in develop non sono ancora stabili e non possiamo aspettare una nuova release; dobbiamo quindi lavorare direttamente su master.

Apriamo una hotfix ed iniziamo subito ad indagare sul problema.

$ git flow hotfix start 1.3.1 Switched to a new branch 'hotfix/1.3.1' Summary of actions: - A new branch 'hotfix/1.3.1' was created, based on 'master' - You are now on branch 'hotfix/1.3.1' Follow-up actions: - Bump the version number now! - Start committing your hot fixes - When done, run: git flow hotfix finish '1.3.1'

Le best practices continuano a valere: scriviamo un test che fallisce (rosso), troviamo il bug e scriviamo la fix. Una volta che tutti i test vengono completati con successo (verde) non ci resta che portare i commit in produzione.

Inoltre per fare in modo che anche la branch di sviluppo e tutte le future features non soffrano di questo bug dobbiamo includere i commit della hotfix anche in develop.

Questo è fatto automaticamente da git flow chiudendo la hotfix:

$ git flow hotfix finish '1.3.1' Switched to branch 'master' Merge made by the 'recursive' strategy. fix.rb | 4242 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 fix.rb Switched to branch 'develop' Merge made by the 'recursive' strategy. fix.rb | 4242 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 fix.rb Deleted branch hotfix/1.3.1 (was 7eb4dd6). Summary of actions: - Latest objects have been fetched from 'origin' - Hotfix branch has been merged into 'master' - The hotfix was tagged '1.3.1' - Hotfix branch has been back-merged into 'develop' - Hotfix branch 'hotfix/1.3.1' has been deleted

Al termine di questa operazione, l’hotfix è stata inclusa in master ed in develop.

Come possiamo notare ed apprezzare, anche in questo caso git-flow gestisce i tag permettendoci di annotare la nostra codebase. Non ci resta quindi che incrementare il numero di versione da 1.3 ad 1.3.1 (minor release), push & deploy ed il problema è stato risolto.

Questo breve scenario dimostra quanto sia semplice gestire anche i progetti più articolati mantenendo una solida struttura, organizzata e facile da gestire.

Commit Early, Commit Often!

Due chiacchiere su Savory con Max Henry di CHaINA Magazine

Posted by & filed under Uncategorized.

Un mese dopo, l’intervista con Valentina di EDT, abbiamo passato un po’ di tempo con Max Henry, fondatore e direttore esecutivo di Chain Media, una società con base a Shanghai che offre consulenza in marketing e comunicazione alle aziende che si occupano di logistica e distribuzione in Asia.


Ciao Max, prima di tutto ti va di raccontarci come sono andate le cose? Cosa vi ha portato a utilizzare Savory?

Come molti altri editori abbiamo utilizzato a lungo InDesign per impaginare il nostro magazine, ma più passava il tempo e più ci sentivamo insoddisfatti a causa della complessità del software, del molto tempo speso per preparare un singolo numero e per l’aspetto un po’sciatto del nostro magazine una volta messo online (i PDF digitali hanno font troppo piccoli, e lo zoom non è la soluzione ottimale su schermi piccoli e su tablet).

Dopo aver provato altre soluzioni (come Onswipe, Pressly e vari plugin per WordPress) abbiamo scelto di utilizzare Savory per il suo design, la semplicità d’uso e il prezzo vantaggioso.

Quale prodotto editoriale state realizzando?

Stiamo pubblicando CHaINA, il nostro magazine principale dedicato a logistica e distribuzione, che è stato distribuito in forma cartacea negli ultimi 5 anni e che è passato recentemente a essere 100% digitale.

È un magazine che promuoviamo molto, e che viene letto da oltre 20,000 lettori ogni mese.

Molte aziende avrebbero investito in un’applicazione nativa, o avrebbero scelto una semplice newsletter. che cosa vi ha convinto a prendere questa direzione?

Abbiamo sperimentato con le applicazioni native, e abbiamo anche sviluppato un’applicazione per iPad del nostro magazine con la piattaforma PixelMags. L’abbiamo testata per 2 anni, non siamo riusciti a guadagnarci niente (Apple si prende tutti i profitti) e in ogni caso era basata su PDF, qualcosa che noi non volevamo più continuare a fare.

Per un piccolo editore è praticamente impossibile sviluppare e mantenere un’applicazione per iOS, una per Android, una per Blackberry e adesso una per Windows 8. Al contrario, avere un magazine in HTML5 che funziona su tutti i dispositivi e in qualsiasi browser rende tutto estremamente facile.

E’ stato difficile integrare Savory nel vostro flusso di lavoro?

No, come molti altri editori in fase di transizione dalla stampa al digitale abbiamo modificato totalmente il modo in cui lavoriamo al magazine, e da questo punto di vista Savory rende tutto molto facile.

Come sono cambiate le cose da quando avete lanciato il nuovo magazine?

Siamo molto soddisfatti: è semplicissimo da usare, e il nostro magazine è sempre molto bello da vedere, a prescindere dal dispositivo che si usa per leggerlo. Fino a qui, decisamente niente di cui lamentarsi.

E la relazione coi vostri lettori? E’ stata influenzata in qualche modo?

I nostri lettori amano il nuovo look and feel, e la possibilità di leggere il magazine su qualunque tablet o smartphone.

State sperimentando con le pubblicità. Come stanno andando le cose? Qual è stata la reazione degli inserzionisti?

Stiamo ancora faticando a convincere i nostri inserzionisti a seguirci in questa direzione, perché continuano a preferire la carta stampata. Ci vorrà un po’ di tempo, ma alla fine otterremo la loro fiducia (e il loro budget). Noi nel frattempo continuiamo a fornire ottimi contenuti, e un numero di lettori in forte crescita.

Un’altra cosa che stiamo facendo è lavorare a pacchetti pubblicitari creativi, che mettano insieme inserzioni, banner e social media.

Quali features vorreste vedere implementate nel prossimo futuro?

Penso che la più importante ora come ora sia il download automatico dell’intero magazine appena si inizia a leggere. Ora può capitare che sfogliare le pagine avvenga in modo un po’ lento.

Quali sono i principali problemi che avete dovuto affrontare? Ci sono stati concetti difficili da comprendere?

Nessuno, amiamo il vostro team e il grande supporto che offrite.

Savory su Enter the Cloud

Posted by & filed under Uncategorized.

Su Enter the Cloud c’è una lunga intervista a Andrea e Andrea dove parlano di Savory, cloud computing, sviluppo agile, software opne source e editoria di gitale.

 

La mia ambizione è che Savory consenta ad una fascia di persone che non sono strettamente “giornalisti” o “scrittori” di creare una propria pubblicazione. Ciò non toglie che sia un prodotto per sua natura più complesso di un blog, e quindi meno di massa.

D’altro canto la progettazione e realizzazione di un prodotto editoriale di qualità comporta costi (anche solo in termini di tempo) di fronte ai quali il nostro canone diventa secondario.

Il nostro punto di partenza è stato il mercato: qualsiasi prodotto professionale costa decine se non centinaia di volte più di Savory. Abbiamo visto un buco nell’offerta e abbiamo voluto riempirlo.

 

Il resto si legge qui

Due chiacchiere su Savory con Valentina Orsi di EDT

Posted by & filed under Uncategorized.

A un mese (o poco più) dal lancio di Savory, abbiamo fatto due chiacchiere con Valentina Orsi, che si occupa di comunicazione e marketing presso EDT, la casa editrice che – tra le altre cose – pubblica in Italia le guide Lonely Planet.

EDT usa Savory per pubblicare il suo bollettino ai librai, e lo fa da molto prima che lanciassimo il prodotto. Anche per questo per noi il loro parere è molto importante.

 


 

Ciao Valentina, prima di tutto ti va di raccontarci come sono andate le cose? Cosa vi ha portato a utilizzare Savory?

Già dal 2009 abbiamo sentito la necessità di comunicare in modo costante e diretto con le librerie e le biblioteche, al di fuori degli incontri commerciali periodici o delle occasioni istituzionali (fiere e festival).

Per un paio d’anni abbiamo utilizzato un semplice documento pdf che spedivamo come allegato a un’email, ma piano piano le cose da dire, le immagini da mostrare e i link da inserire aumentavano sempre di più, fino al punto in cui i nostri pdf sono diventati troppo pesanti, difficili da leggere e da scaricare.

Quindi ci siamo messi alla ricerca di uno strumento alternativo, in grado di produrre pubblicazioni che fossero veloci da consultare e accessibili anche attraverso i nuovi dispositivi che si stavano e si stanno diffondendo, ovvero non più solo computer, ma anche smartphone e tablet.

 

Quale prodotto editoriale state realizzando?

Realizziamo un mensile di informazioni editoriali riguardanti le novità e le attività della nostra casa editrice.

Per ogni area di pubblicazione (Viaggi, Musica, Ragazzi) segnaliamo i libri in uscita, le operazioni di marketing, le recensioni stampa, le pubblicità previste, i materiali promozionali che produciamo.

In questo modo i librai possono avere sempre presente ciò che facciamo e usufruire di uno strumento diretto per contattarci. Qualche esempio: usciamo con una nuova collana di guide turistiche e abbiamo realizzato un espositore ad hoc. Il libraio non ha prenotato l’espositore durante il lancio perché cinque mesi fa – quando glielo abbiamo presentato –  lo riteneva inutile.

Adesso, grazie al Bollettino, gli ricordiamo che le guide stanno uscendo insieme al nuovo espositore e che se lo desidera può ancora  riceverlo, contattandoci direttamente. Se non avessimo avuto il Bollettino digitale non avremmo mai mandato una mail ai librai solo per comunicare loro un’informazione del genere.

 

Molte aziende avrebbero investito in un’applicazione nativa, o avrebbero scelto una semplice newsletter. che cosa vi ha convinto a prendere questa direzione?

Il Bollettino non poteva essere un’applicazione nativa, perché non possiamo pensare che tutti i nostri interlocutori abbiano il mezzo per usufruirne.

Non poteva nemmeno essere una semplice newsletter, perché riteniamo la newsletter uno strumento molto efficace dal punto di vista della comunicazione commerciale, ma debole quando si tratta di comunicazione editoriale strutturata su argomenti molto diversi tra loro.

Una web app ci ha permesso di rendere sempre raggiungibile i nostri contenuti da diversi device, e ci ha permesso di realizzare una pubblicazione strutturata come una rivista, quindi ricca di contenuti e in un formato più riconoscibile per gli utenti del settore editoriale.

 

Come avete integrato Savory nel vostro flusso di lavoro?

Savory è entrato abbastanza agilmente nel nostro flusso di lavoro. Come mensilmente facevamo per realizzare il documento in pdf, una persona incaricata riceve dai responsabili delle diverse aree editoriali i materiali di cui parlare nel nuovo numero.

Con un paio di giorni di lavoro e di revisione tali contenuti vengono impaginati – se così si può dire – e, una volta strutturato l’indirizzario, viene inviata una comunicazione che avvisa della pubblicazione del nuovo numero del Bollettino.

 

Come sono cambiate le cose nella comunicazione con le librerie, da quando avete iniziato a usare il nuovo bollettino?

Innanzitutto il nuovo Bollettino ci consente, nel corso del mese di validità del numero, di aggiornare ogni informazione contenuta. E inoltre consente agli utenti di raggiungere il documento direttamente dal web, senza ricevere per forza una comunicazione one-to-one via email.

E essendo tutto archiviato sul web, ovviamente, si possono consultare i numeri passati. Infine con il nuovo bollettino sono molto più numerosi e immediati i modi per raggiungere i nostri altri canali (siti internet, canali social, eccetera).

 


 

Potete dare un’occhiata al bollettino EDT ai librai qui.

Savory is up!

Posted by & filed under Uncategorized.

Well, here it is. Savory. The new platform for digital publishing. It’s built with Treesaver®, the rule-based HMTL5 responsive and algorithmic layout engine, and managed by a powerful CMS  from ZephirWorks.

Savory is a new kind of web hosting service. Its page-based design is tuned for publications—regular collections of stories by different writers, photographers and artists. Savory puts the narrative first. It’s like a tablet-smartphone magazine app meets a blog hosting service.

Unlike apps, it’s on the web. The same Savory publication can be read on a phone, a laptop, a tablet—on any device that has a browser. You can share stories on the social networks, or e-mail links to friends.

Savory goes beyond the linear story river of blogs, which are fine for short iterative items and links, but not for an issue filled with different kinds of stories.

And it’s better for publications than a conventional web site.  (Have you ever used a magazine or newspaper web site that is as immersive and easy to read as the printed edition?)

Monthly service is an affordable $49, or €49. This is great for start-ups—or for new efforts at established publishing companies. The fee is charged monthly like a subscription, but there’s no contract.

At launch there are two complete design themes—one for magazines, and one for news publications. More features, and new themes will be introduced in coming months.

So check it out. Savory is ready to serve your publication. We look forward to working with you.

 

Savory è online!

Posted by & filed under Uncategorized.

Insomma, ci siamo. Savory, la nostra nuova piattaforma per l’editoria digitale, è online. È costruita su Treesaver®, il layout engine algoritmico e responsivo basato su HTML5, e utilizza il CMS che abbiamo sviluppato noi di ZephirWorks.

 

Savory è un servizio di hosting online per l’editoria completamente nuovo. Il design delle pubblicazioni è suddiviso in pagine, ed è ottimizzato per gestire collezioni di storie che possono essere realizzate da più autori, fotografi e artisti, e pubblicate con cadenza regolare. Savory mette la dimensione narrativa davanti a tutto. In un certo senso, è come se l’applicazione per tablet e smartphone di un magazine si unisse a un servizio di hosting per blog.

 

A differenza delle applicazioni, però, Savory vive sul web. Una stessa pubblicazione Savory può essere letta su uno smartphone, su un laptop o su un tablet: su qualsiasi dispositivo dotato di un browser. È possibile condividere le storie su tutti i social network, o inviare il link via email ai propri amici.

 

Savory consente di andare oltre il flusso lineare di storie di un blog, che funziona benissimo per contenuti brevi (o per condividere link), ma non consente di gestire al meglio il numero di una rivista composto da articoli anche molto diversi tra loro.

 

Savory si adatta alle esigenze di una casa editrice meglio di quanto non faccia un sito web tradizionale. Del resto, avete mai trovato un sito web in grado di offrire un’esperienza di lettura immersiva quanto quella di un’edizione cartacea?

 

Il costo mensile per il servizio è di soli 49€ (o 49$). Savory è la soluzione ideale per le start up, o per sperimentare nuove soluzioni all’interno di aziende già consolidate. Il pagamento viene rinnovato di mese in mese, e non è necessario firmare alcun contratto.

 

Al momento del lancio sono disponibili due temi completi: uno dedicato ai magazine e uno per le news. Nuove funzionalità e nuovi temi saranno aggiunti nel corso dei prossimi mesi.

 

Dunque, dategli un’occhiata. Savory è a vostra disposizione, e noi non vediamo l’ora di lavorare insieme a voi.

Dopo Editech, alcune considerazioni (e qualche idea per il futuro)

Posted by & filed under Uncategorized.

Una volta tornato da Editech, (per chi volesse, #editech su Twitter), mi è rimasta in testa la sensazione che i discorsi intorno all’editoria digitale ruotino sempre di più – sintetizzando al massimo, e cercando di cogliere il punto – intorno a una cosa che Craig Mod ha scritto sul suo blog, e su cui è tornato spesso durante il suo intervento : 

 

To not exist digitally means to be walled off. Silo’d. Unpointable. It means a text feels flat or lifeless or limp. Unnetworked (even if it’s on the network). It’s means to not be part of that growing corpus. Which, today, feels more damning than ever.

 

ll racconto di ciò che avviene, lo scambio di informazioni, il confronto – la conversazione – ognuna di queste cose succede in rete, dove rete significa – ovviamente – web, ma significa anche – ed è questo l’aspetto più importante – all’interno di un network, in cui ogni persona, ogni presenza, ogni oggetto dà il suo contributo alla creazione di un corpus.

Se proviamo a fare un passo indietro e ad abbandonare per un momento le categorie a cui siamo abituati fare riferimento – libri, riviste, giornali, ebook, applicazioni – quello di cui stiamo parlando è: il modo in cui le persone – cioè ognuno di noi – stanno producendo, trasmettendo e condividendo cultura, dove cultura è da intendersi nell’accezione più generale possibile del termine.

Porsi al di fuori di questo scenario – nella visione di Craig Mod, che mi sento di appoggiare – significa semplicemente porsi al di fuori della contemporaneità, su un piano diverso – quantomeno laterale – rispetto alle cose che accadono ora. E mettere a repentaglio la propria possibilità di sopravvivere sul lungo periodo.

 

 

Nel corso degli ultimi anni chi si è occupato di editoria digitale si è concentrato sui prodotti – sugli esiti del proprio lavoro – tendendo forse a non osservare lo scenario, il contesto. Gli ebook (a prescindere dal formato) e le applicazioni native sono prodotti definiti, dai confini certi. Sono soprattutto oggetti in qualche modo rassicuranti, controllabili e gestibili, estremamente più gestibili di quanto non lo sia il web – inteso come rete, non soltanto come infrastruttura. Si producono, si distribuiscono, si vendono. Un prodotto per ciascun lettore, e finito di leggere si passa ad acquistare il prossimo.

Per quanto possa sembrare paradossale, questi oggetti si trovano sul confine tra online e offline. L’infrastruttura su cui si reggono – distribuzione, vendita, comunicazione – esiste sul web, mentre i contenuti – si tratti di ebook o applicazioni –  sono in bilico: separati dalla rete aperta, in qualche modo isolati, frammentati in porzioni gestibili e controllabili.

La loro esistenza – soprattutto la percezione della loro esistenza dal punto di vista del lettore – non è online, è altrove, in un luogo terzo: all’interno di una piattaforma più o meno chiusa, su un device, e più in generale nel flusso che conduce dalla distribuzione alla vendita, e da lì alla memoria locale (o cloud) del dispositivo utilizzato.

Il problema  - ed è un problema sempre più sentito, e centrale – è che mentre l’industria editoriale si concentra su tattiche e strategie – sui suoi problemi e sulle sue esigenze – le persone agiscono, e agiscono in modo autonomo, indipendente e in un certo senso al di fuori dalla traiettoria desiderata. Soprattutto, agiscono online, e sono parte integrante di un network che contribuscono a costruire. Tutto quello che si posiziona al di fuori di questo contesto tende a essere percepito sempre meno – non è noto, se non in modo estremamente tenue, e in prospettiva rischia di diventare irrilevante: di non esistere.

Torniamo alle parole di Craig Mod:

 

It means a text feels flat or lifeless or limp.

 

Questo vale per i libri, le riviste, i giornali così come per le applicazioni o gli ebook: dov’è il network all’interno del quale abbiamo iniziato a vivere, se gli oggetti che veicolano i nostri contenuti – le nostre idee, le nostre storie – non ne fanno parte? Che cosa resta del corpus che stiamo creando – i commenti, le reazioni, le selezioni, le riorganizzazioni del contenuto – se non possiamo integrarlo all’interno del network? Dove siamo noi, in tutto questo?

 

 

A Editech si è parlato molto di open web, di HTML5 e di applicazioni web. Bill McCoy, direttore esecutivo dell’IDPF (l’ente che segue lo sviluppo dello standard Epub), ha detto durante il suo intervento che è il web la piattaforma giusta su per creare a compelling content experience. La sensazione, in questo caso, è che non si tratti di una scelta strategica, consapevole e determinata, ma di un adeguarsi allo stato di cose, a una direzione presa per necessità, a prescindere dalle intenzioni o dalla volontà.

I contenuti che creiamo cambiano insieme al modo in cui ne fruiamo e ai discorsi che li circondano. I libri (e le riviste, e i giornali, che siano o meno di carta, non è importante a questo punto) riflettono un’idea di mondo che sembra diventare  - più o meno velocemente – inattuale. Soprattutto, non riescono a inserirsi all’interno di un network, in cui lo scambio di opinioni è costante – così come il loro miglioramento – e in cui tutto viene ridefinito costantemente. Per dirla in un altro modo: oggetti chiusi, concepiti e prodotti per essere finiti una volta per tutte, non trovano spazio in un mondo sempre più agile, che risponde al cambiamento, più che seguire un piano.

Osservata da questo punto di vista – e in questo contesto – l’attenzione recente verso le applicazioni web come strumento editoriale non è altro che la ricerca di un mezzo per raggiungere un fine: riportare i contenuti online, di nuovo all’interno di un network, renderli parte di un corpus e restituirli ai lettori (alle persone, a noi) slegati dai limiti necessariamente stabiliti da piattaforme proprietarie, più o meno chiuse.

Del resto si tratta semplicemente di mettere in atto una vecchia regola: andare a cercare il proprio pubblico dov’è già – online – invece di pretendere che ci segua altrove.

Savory Is Coming (2) – The press release

Posted by & filed under Uncategorized.

The launch of Savory is getting closer every day, and we are really thrilled to finally announce our recent partnership with the Treesaver team.

Together we are building an amazing product, and in a few more weeks everyone intersted will be able to try it.

Here is the official pre announcement press release, to read and download.

Speak soon :)

Arriva Savory (2) – Il comunicato stampa

Posted by & filed under Uncategorized.

Il lancio di Savory è sempre più vicino, e siamo felicissimi di poter finalmente annunciare di aver stretto una partnership con il team di Treesaver.

Insieme stiamo costruendo un prodotto sempre migliore, che tra poco sarà a disposizione di chiunque vorrà provarlo.

Qui sotto il comunicato stampa ufficiale, da leggere e scaricare.

A prestissimo :)

Savory Is Coming (1)

Posted by & filed under Uncategorized.

Almost three months went by since the last time we talked about Savory, and in the meanwhile a lot of cool stuff happened.

E.g., I (Ivan) joined the Savory team here at ZephirWorks, and one of the things I’d really love to be able to get done in those first few days is to try to clearly explain what Savory is and what is meant to.

Savory makes it easy for you to publish your content on tablets, smartphones and PCs.

The great thing about Savory is that it lets you author, curate and manage your content, and then deliver it to every device (be it a PC, a smartphone or a tablet) with just one click. No magic involved: all you need is a browser, and you’re done.

All the content delivered using Savory is a proper web application, which lives and exhists within the browser, and this is the reason why you don’t need anything else to enjoy it.

Web applications are wonderful: open, standard compliant, scalable and flexible. Our customers won’t be tied to any hardware, software or proprietary file format. They will be able to deliver content crafted using web standards directly in a browser. This is something strictly related with freedom, and we care about freedom.

Here is another great thing about Savory: content is handled using HTML5 and CSS3 features. Those technologies enable responsive and context aware design. In other words, the layout adapts itself to the screen size and to the kind of device you are using to access the content. This way, great readability and beautiful tipografy is assured always.

Savory Is About to Come

We are all working really hard, and we are almost ready to release our Public Beta. We will tell you (and also show you, finally) more in the next few days. In the meanwhile, you can leave us your email on savory.io, and we will keep you posted.

And no spam, we promise :)