All Posts in Coding

gennaio 5, 2017 - No Comments!

Serverless Test Driven Development

serverless tdd

Il paradigma serverless permette di dimenticarci della gestione dei server per poterci concentrare sulla realizzazione di funzionalità. Insieme a Filippo Liverani all'Italian Agile Day abbiamo visto come creare funzioni Lambda mantenendo alta la qualità del codice, con l'utilizzo del test driven development e ambienti locali di sviluppo e di produzione quanto più simili possibili con Docker.

Durante il talk, Filippo ha mostrato in un'applicazione di test come scrivere il primo test di accettazione in locale, un microciclo red, green, refactor e il deploy su Amazon Web Services con il framework Serverless, per poi eseguire con successo il test di accettazione direttamente sull'endpoint creato su AWS.

Repository del progetto: https://github.com/xpeppers/serverless-tdd

Slides della presentazione

Contattaci per maggiori informazioni su come adottare Serverless in azienda e se l'argomento test driven development ti interessa non perdere la prossima edizione del corso TDD explained.

dicembre 5, 2016 - No Comments!

Ruby Day 2016 – La nostra esperienza a Firenze

by Alessio Coser, Christian Fei, Matteo Pierro

Sabato, 26 Novembre 2016, abbiamo partecipato al Ruby Day 2016 a Firenze (programma).

Presentazione del Ruby Day 2016

Presentazione del Ruby Day 2016

La conferenza è iniziata con l'intervento di Xavier Noria che ha proposto alcuni concetti di codice leggibile, corretto e conciso.

Abbiamo visto alcune porzioni di codice scritte in modi diversi: alcuni più concisi, altri più leggibili e ci ha fatto notare che la scelta di come scrivere il codice è molto soggettiva, ma che dovrebbe comunque essere condivisa interamente dal team in cui ci si trova.

Successivamente abbiamo deciso di seguire una presentazione improntata su Integration testing, di Piotr Szotkowski. Il ragionamento di Piotr è partito dalle problematiche emerse in questi anni su integration testing ed ha preso come esempio l'articolo di J.B. Rainsberger intitolato "Integrated Tests Are A Scam!".
E' partito con un'introduzione sui test doubles, come e quando vengono usati, ma soprattutto quali sono le loro limitazioni. Ci ha spiegato come Bogus (un tool per il testing) affronta questi problemi in modo diverso e ci aiuta nel tdd-outside-in.

Prima di pranzo Devon Estes ci spiega come applicare concetti funzionali ad applicazioni Ruby. Ci ha invitato a ripensare il modo in cui scriviamo il codice sfruttando concetti del paradigma funzionale mostrandoci alcuni esempi di come sia possibile scrivere codice testabile e mantenibile.

Ruby Refinements - Paolo Perrotta

Refinements the worst feature you ever loved - Paolo Perrotta - Ruby Day 2016

Nel pomeriggio Paolo Perrotta ci ha raccontato di una fantastica feature poco conosciuta utilizzata di Ruby chiamata "Refinements". Ci ha parlato di come questa feature sia un'arma a doppio taglio e del motivo per il quale è stata introdotta: cercare un'alternativa sostenibile al monkey patching.

In seguito Simone Carletti ci racconta come la sua curiosità verso altri linguaggi di programmazione (Elixir, GO, Crystal e Java in particolare) lo abbiano portato ad evolvere il modo con cui scrive codice in Ruby.

Il talk successivo, proposto da Benjamin Roth, era incentrato sul tema dei ServiceObject e su come comporli per creare quello che lui chiama realistic context. Ha sottolineato come un approccio del genere porti ad avere dei Controller più light e con meno codice ripetuto. A supporto della presentazione ha introdotto una serie di gemme che "facilitano" -l'applicazione di questa pratica. Tra queste quella che ci ha colpito di più è stata Waterfall.

Nel tardo pomeriggio abbiamo partecipato al talk Lessons learned while building Hanami di Luca Guidi.
Ha parlato di tutti gli aspetti che si celano dietro lo sviluppo e il mantenimento di un progetto Open Source, di come la comunicazione e la collaborazione siano aspetti molto importanti nella buona riuscita di progetti di questo tipo.

Secondo la sua esperienza la scrittura di codice arriva alla fine di tutte quelle azioni che permettono la crescita della comunità intorno al progetto come la comunicazione che deve essere “inclusiva“ e propositiva in modo da aiutare, chi lo desidera, a collaborare al progetto.

Inoltre ha toccato un aspetto molto importante: la gestione del tempo. Consiglia di dedicasi al progetto ogni giorno anche per poche ore. Però non proprio ogni giorno, infatti si dovrebbe riuscire a ritagliarsi del tempo (come il week-end) per la propria vita privata e non permettere che questa attività, anche se è appassionante, assorba tutto il tempo libero.

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Piotr Solnica ha concluso la giornata parlando della sua esperienza nello sviluppo di progetti OpenSource e di come la comunità cerca di migliorare l'ecosistema Ruby.

E' stata veramente una bella esperienza che ci ha permesso di confrontarci con la comunità Ruby e di passare una giornata divertente e stimolante.

ottobre 25, 2016 - No Comments!

Reasons to adopt a microservices architecture

by Paolo D'incau

microservices

Microservices based architecture is a trending topic in these days: more and more companies try to take a big step and shape their software and internal organisation following the examples of well-established realities such as Spotify, Netflix and Zalando. Even though it's always positive to keep an eye on new technologies, languages and frameworks available in the market, it wouldn't be wise to blindly embrace them. In this article we will discuss with concrete examples three different reasons that should trigger your interest in knowing more about microservices.

1) Faster Deployment

One of the things that I have noticed in the past years of work on monolithic architectures is that most of the times the process of deploying working features in productions becomes difficult and time consuming. Let me try to expand this point and explain why I believe that a microservices approach can ease these kinds of organizational issues.

When the products you are working on becomes somehow stable and is actively used by customers, the daily work of your team splits in three different activities, that are:

  • new features implementation
  • bug fixing
  • changes of the existing features (small ones, most of the time)

If your code is organized in a monolithic structure chances are very high that your Continuous Integration/Delivery/Deployment pipeline will reflect the same structure which means that it has a unique flow and therefore each and every change to the codebase will need to pass through tests or build steps that are totally unrelated to the change itself; this obviously means that you need more time to deploy your new code in production with all the costs that this implies.

When you need to push to production an urgent fix, but your continuous delivery pipeline remains blocked by non related broken user acceptance tests for hours (they can even be tests on features that are seldom used) your team can undergo frustration and and irritability. I have noticed the same frustation to arise when someone (probably the PO) asks to deploy a given feature to production without deploying other features that are still not ready and the team just can't satisfy the request because the deploy follows the motto "get everything or nothing".

Microservices obviously can help in tackling these kind of issues. If you separate your big project in smaller services built around features you can obviously decouple the related code, with the great benefit that your deployment strategy will follow. This means that you can decide to create a different pipeline for each microservice and therefore you will be able to deploy each component indipendently decreasing drastically the time your bug/feature/change takes to be released and used in production.

2) Easier onboarding

So you develop and improve your software for quite a lot of time (can be years), but things change and some of your developers (I hope not all of them) decide to leave and seek their fortune away from your company. Your product is widely used in production and obviously it needs support and new features, so you decide to hire new developers.

For newcomers it can be really difficult to approach a monolithic codebase and to become productive in a few weeks. It is very reasonable if you reflect on it: your new developers have to understand not only the new business features that need to be added, but also the overall business domain and the way it was coded down by other people who left the project! A monolithic architecture is the main reason that made me hear during the last years things like: "To be productive on this codebase you need N months" or "A couple of years ago we decided that...", I bet you heard something like this during your career too!

If you hired new developers and you want them to be productive as soon as possible, you may consider switching to a microservices architecture. I strongly believe that with such approach new team members can develop all the new features you need in a faster way without the burden of a limited knowledge of what lies in the monolith. Also, I recommend that newcomers should practice work on these new features while pair programming with somebody with more experience on the project so that they can be thought about the business domain, monolith architecture and, why not, team/project history.

3) Smarter scaling

Scalability seems to be a big concern nowadays and it's very common to hear business people ask the dev team whether the system under development "will scale". With the advent of cloud and virtualization everything seems very easy: you just need to deploy your application to several machines and put some sort of load balancer in front of them (e.g. country based) and voilà: you get the scalability you desired almost for free.

While it's pretty obvious that today we have a lot of platforms and tool that comes to our help, it is worth to remember that the way we design and organize our architecture still plays a big role.

Suppose your application just became mainstream and day by day is used by more users: with a monolith, if you want to scale, you are forced to deploy everything to several "replica machines", without taking into consideration whether you need to scale all the features the application provides or just a small subset of them. This kind of approach introduces different business related issues in your organisation, not only technical ones: for example you will have to use several new machines that must provide the computational power needed by the entire application and obviously this will cost you more.

When talking about scalability, microservices seems to outperform many other architectural choices out there. Whenever you feel the urge to scale some part of the system (and I hope you are forced by real metrics and not by your gut) you can decide to spin new small machines that will host only the service that provides the needed feature and nothing more; so if you are running an online shop you will be able to scale only the part connected to searches, while keeping the parts that implement shipment tracking or products recommendation as they are.

With a microservices approach you will get another great benefit: you will be able to kill some of the instances with no mercy because you are confident that just by stopping one or more microservices you are not shutting down the entire system but only a part of it.

Conclusions

In this article we have looked at three good reasons that should address you towards a microservices based architecture when redesigning your legacy monolithic application or starting it from scratch. With microservices you can boost your team productivity, reduce your time to market and scale those parts of the systems that really need it.

It is worth noting that microservices are not the only way to achieve those results, so before embracing them you should evaluate different solutions and also consider the issues that this kind of architecture can bring into your organisation. Finally you should alway keep these words by Sam Newman in mind:

About me

I have a double identity: I code OOP by day and spread FP by night (and during the weekends). I love talking about Erlang, Continuous Delivery, refactoring and microservices. I fight for to the coding “made in Italy".
I've started collecting useful resources about microservices here.

ottobre 12, 2016 - No Comments!

ReactJS Day 2016 Verona

by Christian Fei

Venerdì, 7 ottobre 2016, ho partecipato alla seconda edizione dell'evento "ReactJS Day 2016" a Verona.

La conferenza è iniziata con la presentazione dell'associazione GrUSP e di Frontenders Verona (FEVR).
Dopodiché in lineup c'erano due presentazioni sui temi "Individual paint for your React components" e "CSS is dead, long live CSS (but in modules, please)!", quindi entrambi riguardanti lo stilyng di componenti React.
Johannes Stein (@frostney) ci ha condiviso la sua esperienza con le varie tecniche per stilizzare componenti con React, dai famigerati inline-styles, da Aphrodite, da react-with-styles a una marea di webpack-modules. Adesso bisogna solo scegliere..

Dopo una breve pausa, Emanuele Rampichini (@emanuele_r) ha parlato dei vari tipi di testing di applicazioni di React. Partendo da una filosofia "PnP (Push-and-Pray)", come si crea un' applicazione che è in linea con il titolo della sua presentazione "How to push a ReactJS application in production and sleep better"? Non nuoce avere conoscenza della libreria react-test-utils e react-shallow-testutils per testare componenti React unitariamente o integrazione. Per una soluzione all-in-one di Airbnb, consiglia(mo) enzyme.

Con Massimiliano Mantione sul palco non c'era altro che aspettarsi una sbalorditiva demo con live-coding.
Ci ha lasciato tutti a bocca aperta con la dimostrazione di un suo esperimento dell'uso di React per lo shallow rendering della view, Redux per la gestione dello stato dell'applicazioni e tre varianti di "view" a la "TodoMVC":

  • una parte renderizzata con componenti HTML
  • un canvas 2D
  • un canvas 3D renderizzato con WebGL


*Modificando la todolist in una view, cambiava in tutte e tre 😎*

Francesco Strazzullo ci ha raccontato dello sua esperienza con la libreria MobX per lo state management in applicazione web JavaScript.

Nella presentazione "Building Modular Redux Applications" Gian Marco Toso presenta l'attuale stato dell'arte per l'organizzazione di progetti e del codice di applicazione modulari scritte con Redux.js.

Scrivere applicazione con una codebase "ridotta" (in termini di logica di business, linee di codice, complessità etc.) è veramente un gioco da ragazzi, ammettiamolo. Ma cosa succede in una codebase di grande scala? Il codice si riduce a codice illegibile e inutilmente complesso (aka "Spaghetti Code"), o è comprensibile e mantenibile?
Erik Wendel parla della sua esperienza ormai di quasi 5 anni in Bekk Consulting, insomma in una organizzazione a larga scala, in cui sono state adottate le librerie React e Redux. Wow!

Hoti Fatos ci introduce nel mondo GraphQL, e con una dimostrazione live ci spiega concetti del nuovo Query Language "GraphQL" (di Facebook).

La fantastica giornata al ReactJS Day 2016 finisce con la presentazione del carismatico Michele Bertoli su "Proper Error Handling with React/Redux".

seguita dall'invito al Node.JS Conf, il 22 Ottobre a Desenzano. Ci vediamo lì!

agosto 17, 2016 - No Comments!

AngularJS per lo sviluppo di applicazioni web

Un nuovo corso si aggiunge al catalogo. AngularJS per lo sviluppo di applicazioni web ti permetterà di approfondire la conoscenza del framework di Google e alla fine del corso sarai in grado di realizzare un’applicazione AngularJS in maniera autonoma.

corso per sviluppare con AngularJS

Il corso base ha una durata di 2 giornate, gli argomenti potranno essere modificati per rispondere meglio alle tue esigenze:

  • Javascript, jQuery vs AngularJS, qual’è il cambio di paradigma?
  • MVC (Model View Controller;
  • Iniezione delle dipendenze (Dependency Injection);
  • Le promesse (Promises);
  • L’architettura di AngularJS;
  • Come strutturare l’ambiente di sviluppo: npm, bower, grunt, gulp;
  • Moduli e controller;
  • Espressioni e filtri;
  • Scope e rootScope;
  • Cos’è e come funziona il binding bidirezionale (two way)?
  • Form e modelli;
  • Il routing di una applicazione con e senza uiRouter;
  • Direttive e servizi
  • Quali sono e come utilizzare direttive e servizi messi a disposizione dal framework;
  • Come sviluppare direttive e servizi personalizzati;
  • Intercettori di richiesta, cosa sono e come usarli;
  • Esercizio finale

Il corso può essere erogato presso la vostra azienda o possiamo ospitarvi presso le nostre sedi di Milano, Roma e Trento. Al momento non ci sono edizioni pubbliche in programma, puoi proporre una data o contattarci per un preventivo.

luglio 22, 2016 - No Comments!

AWS lambda zombie workshop

Stiamo reclutando nuovi sviluppatori per la AWS Lambda Signal Corps

zombie workshop

In uno scenario in cui gli zombie hanno preso il sopravvento nelle aree metropolitane, la AWS Lambda Signal Corps ha costruito un sistema di comunicazione per tenere in contatto i sopravvissuti.

Partecipa al AWS Lambda Signal Corps!

Un workshop, già collaudato in altre città degli Stati Uniti, in cui i partecipanti hanno lavorato in gruppi per costruire un'applicazione di messaggistica serverless per i sopravvissuti ad una apocalissi zombie, utilizzando Amazon S3, Amazon DynamoDB, Amazon gateway API, e AWS Lambda. I partecipanti hanno imparato a conoscere modelli di microservizi e le best practice per le architetture serverless. Hanno poi esteso la funzionalità dell'applicazione chat serverless con varie funzionalità e add-on - come l'integrazione per l’invio di SMS, e il rilevamento del movimento di zombie - utilizzando i servizi aggiuntivi come Amazon SNS e Amazon elasticsearch.

Dal diffuso interesse dei nostri clienti per le architetture serverless e AWS Lambda, e il nostro entusiasmo per questo argomento, siamo felici di annunciare che ospiteremo questo workshop gratuito il 22 Settembre a Milano.

Aiutaci a salvare l'umanità! Registrati qui

Cosa sono le architetture serverless?
Le architetture serverless consentono di creare ed eseguire applicazioni e servizi senza dover gestire infrastrutture. L'applicazione viene eseguita ancora sul server, ma tutta la gestione del server è fatto per voi dal provider cloud. Le architetture serverless possono rendere più facile costruire, gestire e scalare le applicazioni sul cloud, eliminando gran parte delle problematiche derivanti dalla gestione dei server.

Cosa è AWS Lambda?
AWS Lambda permette di far girare il tuo codice senza il provisioning o la gestione di server. Paghi solo per il tempo di elaborazione che consumi, non ci sono quindi costi quando il codice non sta girando. Questo rende più facile che mai costruire applicazioni scalabili con managed services potenti, in modo da poter concentrarsi sul proprio core business - come sopravvivere - mentre AWS si occupa della gestione delle infrastrutture.

giugno 30, 2016 - No Comments!

Quando usare React Native? Una nostra analisi

react native

React Native è un framework per lo sviluppo di applicazioni su piattaforme native che permette di unificare l'esperienza di sviluppo su diversi sistemi operativi.

React Native è un progetto basato su ReactJS, che adotta un nuovo approccio allo sviluppo Web.

Attualmente è disponibile per lo sviluppo di applicazioni iOS e Android, ma a breve dovrebbe essere rilasciata la compatibilità con la piattaforma Windows.

Le peculiarità

I Componenti

ReactJS si basa sul concetto di componente. Il Componente è qualcosa che ha uno stato, che può accettare delle proprietà e che ha un suo ciclo di vita.

Questo approccio di sviluppo "atomico" risulta perfetto per effettuare Unit Test o per creare componenti più complessi includendone altri più semplici.

Approccio funzionale e Virtual-DOM di React

I React Components possono essere visti come funzioni pure e idempotenti, infatti l'interfaccia di un componente viene espressa chiamando il suo metodo render() che può accedere allo stato corrente ed alle proprietà.

Il flusso di aggiornamento di ogni componente avviene in questo modo:

  1. La gestione del Virtual DomSi esegue il metodo render() che riceve dei dati in input e restituisce un albero di contenuti da visualizzare (Virtual-DOM).
  2. Il metodo render() viene eseguito ad ogni modifica dei dati e genera un nuovo Virtual-DOM.
  3. React calcola le differenze tra il Virtual-DOM corrente e quello relativo allo stato precedente del componente ed applica le minime operazioni necessarie per avere il DOM reale aggiornato.

Questo approccio ha le caratteristiche della programmazione funzionale, infatti può essere visto come una funzione che prende in input 2 DOM e restituisce una lista di operazioni da eseguire sul DOM Reale per applicare in modo corretto i cambiamenti necessari.

Nessuna WebView

La WebView è uno strumento basato sul motore Webkit che permette di renderizzare correttamente pagine web formate da Javascript, Html e Css.

Molti framework ne fanno uso perchè permette di unificare lo sviluppo di una app che può quindi essere pubblicata sia su Apple Store che su Play Store, senza grandi modifiche.

L'aspetto negativo di questo strumento è che ha bisogno di molte risorse, quindi le applicazioni risultano meno performanti rispetto a quelle sviluppate con una UI nativa.

A differenza delle classiche WebApp, React Native mappa ogni suo componente attraverso l'interfaccia utente nativa della piattaforma iOS o Android.

L'approccio iniziale

Per un primo approccio a React Native può essere di aiuto avvalersi di un progetto ben configurato con un'impostazione modulare e Test Friendly per lo sviluppo.

PepporoniUn progetto interessante è Pepperoni: un modello open source che include una serie ditool già pronti all'uso.
Fornisce uno scaffolding sempre aggiornato di React Native, una struttura modulare ed è predisposto per effettuare Unit Testing con Mocha e Enzyme.

Mocha è uno strumento per il testing unitario di Javascript solitamente associato ad una potente libreria Chai.js, Enzyme invece è un tool che semplifica il testing dei componenti ReactJS.

Pepperoni, inoltre, integra delle librerie come Redux e ImmutableJS per la gestione dello stato dell'applicazione.

Supporta anche il caching dello stato applicativo che permette il funzionamento offline e l'apertura più rapida dell'applicazione.

Oltre ad un sistema di autenticazione (OAuth), ha molti altri strumenti che semplificano notevolmente la configurazione iniziale del progetto.

Pro

  • Di facile utilizzo
    Una volta capito l'approccio di React Native diventa molto semplice sviluppare nuovi componenti.
  • Più performante grazie all'interfaccia nativa
    React Native guadagna molto in termini di performance rispetto alle comuni WebApp, perché fa uso di un'interfaccia nativa e non delega alla WebView il rendering della UI.
  • Un ciclo di sviluppo molto rapido
    React native è a tutti gli effetti una applicazione nativa che interpreta la business logic scritta in javascript, questo permette di velocizzare notevolmente il ciclo di sviluppo: ad ogni modifica del codice non è necessario ricompilare l'intera applicazione.
  • Virtual Dom
    Questo approccio permette di calcolare il minor numero di operazioni da effettuare per apportare le modifiche al DOM guadagnando velocità nel rendering della UI.
  • Semplifica lo sviluppo di test unitari
    Grazie alla sua struttura a componenti atomici risulta più semplice e più rapido lo sviluppo di test unitari.

Contro

  •  E' comunque un'astrazione
    Nonostante la UI sia nativa, la business logic viene comunque interpretata, quindi risulta meno performante delle applicazioni native.
  • Permette minor controllo rispetto alle applicazioni native
    Nelle applicazioni native si ha un maggior controllo soprattutto sulla gestione delle performance.
  • Attualmente non supporta la piattaforma Windows
    A breve dovrebbe essere disponibile il supporto per Universal Windows Platform.

Alternative

  • Ionic
    ionicUn framework javascript molto comune che si basa su Cordova e AngularJS per la creazione di applicazioni mobile. A differenza di React Native, si avvale di una WebView che rende l'applicazione meno performante. Con Ionic, però, è possibile sviluppare una sola applicazione ed effettuare il deploy sia su Android che iOS (Develop once, deploy anywhere).
  • Xamarin
    xamarinUn framework C# per lo sviluppo di applicazioni native. Xamarin permette di scrivere una sola volta la logica di business modificando solo la UI in base al sistema operativo. E' già presente il supporto per Windows e, utilizzando XamarinForms, è possibile scrivere una singola UI per Android, iOS e Windows. Rispetto a React Native è uno strumento certamente più complesso ed è pensato per un team di sviluppatori già orientato allo sviluppo mobile.
  • nativescriptNative Script 2.0
    E' un framework TypeScript e AngularJS. Native Script permette di sviluppare applicazioni native senza utilizzare la WebView.

Conclusioni

React Native è sicuramente un ottimo framework che permette di sviluppare applicazioni con buone prestazioni ed una interfaccia paragonabile a quella delle app native. Questo strumento, però, ha indubbiamente alcuni svantaggi che si rispecchiano sia nelle prestazioni (anche se migliori di altri framework JS) sia nella possibilità di controllare tutte le funzionalità che una applicazione nativa può offrire.

React Native può essere una soluzione ideale per un team più orientato allo sviluppo in javascript. Questo perché offre degli strumenti che facilitano e, in qualche modo, unificano la logica di business e il deploy sulle varie piattaforme mobile.

Per uno sviluppatore di applicazioni native, invece, React Native può non essere il framework più adatto perché ha un approccio differente e potrebbe non rispondere a tutte le esigenze di uno sviluppatore mobile esperto.

Per sviluppare un MVP in poco tempo e con buone prestazioni rimane un'ottima soluzione, soprattutto se a sceglierlo è un team di sviluppatori Javascript.

febbraio 25, 2016 - No Comments!

Coding Dojo a Trento: Refactoring codice Java

Il 27 gennaio abbiamo organizzato presso la sede trentina di XPeppers un coding dojo che ha riscosso un'ottima partecipazione di sviluppatori e sviluppatrici provenienti da tutta la regione Trentino-Alto Adige/Südtirol.

L'argomento della serata è stato il refactoring di codice legacy in Java, e i partecipanti si sono confrontati sulla risoluzione del Gilded Rose kata. Lo scopo del kata in questione è quello di andare ad aggiungere delle funzionalità ad una codebase esistente, scritta in modo ben lontano dall'ottimale e priva di test che ne provino il funzionamento corretto.

Come si è svolto il nostro Coding Dojo

Dopo una piccola introduzione al problema le persone presenti all'evento hanno avuto occasione di alternarsi in pair programming alla tastiera (prima come navigatore e poi come driver) e di mettere mano alla codebase con il supporto di tutte le persone partecipanti. Inizialmente si è cercato di comprendere meglio la codebase andando ad aggiungere un minimo set di test che dimostrassero la validità delle funzionalità già presenti.

Coding Dojo: Tutti assieme attorno alla tastiera

Tutti assieme attorno alla tastiera

Dopo questa prima fase abbiamo deciso di introdurre le nuove funzionalità richieste e qui ci sono venuti in soccorso i test scritti precedentemente perchè eseguendoli spesso ci hanno dato la sicurezza di non introdurre regressioni.

Tra un test in barra verde e una mossa di refactoring su Eclipse, i partepanti hanno potuto consumare degli stuzzichini delle bibite gentilmente messe a disposizione da XPeppers.

Pur non essendo riusciti a concludere l'esercizio, nelle 3 ore di coding dojo abbiamo avuto occasione di metterci a confronto con persone aventi background, skills ed esperienze diverse. E' stata sicuramente un'esperienza positiva e ne è riprova l'ottimo feedback emerso nel corso della retrospettiva tenutasi a fine incontro dove abbiamo analizzato con il classico "glad/sad/mad" la serata e i risultati ottenuti.

Coding Dojo: Retrospective time

Retrospective time

A fine sessione ci siamo lasciati con l'auspicio di organizzare questo tipo di eventi in modo più ripetitivo in modo da esplorare assieme argomenti di diverso tipo e creare un gruppo di appassionati di sviluppo software.

 

febbraio 15, 2016 - No Comments!

FOSDEM 2016 a Bruxelles

by Christian FeiTiago Martinho

Anche quest'anno XPeppers ha partecipato alla conferenza FOSDEM il 30 e 31 gennaio a Bruxelles!

FOSDEM è una conferenza gratuita dedicata a sviluppatori ed ormai è diventata il punto d'incontro in Europa che ogni anno ospita più di 7000 persone, presso l’università ULB di Bruxelles.

Da tutto il mondo sviluppatori appassionati di open-source vengono per discutere e condividere le loro esperienze.

Ci sono innumerevoli stanze dedicate a linguaggi di programmazione, tecnologie e pratiche come virtualizzazione, testing e automazione, fino al mondo open-source in generale.

Abbiamo seguito talk soprattutto legati ai temi Testing and Automation, Virtualisation, Configuration Management, Containers and Process Isolation e IoT.

Nel talk Jenkins as Code abbiamo conosciuto il plugin per Jenkins Job DSL, che rende programmabile la creazione di job Jenkins. Il presentatore ha mostrato come l'infrastruttura di Uber ha sfruttato questo strumento per scalare e automatizzare molti processi che prima richiedevano un intervento manuale.

Per rimanere nel contesto testing e automazione, abbiamo seguito la presentazione "Beyond config management", in cui l'autore ci ha esposto le sue considerazioni su DSL (scritti in Groovy) per modellare e definire l'infrastruttura in modo programmatico. Potendo compilare questo codice, abbiamo la possibilità di avere un'analisi statica sul codice dell'infrastruttura, oltre alla sua testabilità.

Secondo l'autore, e anche secondo noi, l'approccio di modellare l'infrastruttura tramite codice, cioè "Infrastructure as code", è una pratica essenziale per creare architetture affidabili e resilienti.

Nel talk PostgreSQL features for IoT da Simon Riggs abbiamo visto le nuove funzionalità di PostgreSQL dove la vision è avere un database che permette la creazione di applicazione dove l'ambulanza arriva prima del incidente perché la misurazione del battito cardiaco ha rilevato che la persone sta per avere un infarto. Questo database può registrare una grande quantità di dati in poco tempo in continuo, l'esempio fatto è quello di registrare le misurazione di glucose ogni minuto di ogni cittadino del europa.

Nel talk Build an IoT platform on Matrix da Matthew Hodgson è stata presentata una introduzione al framework Matrix. Questo framework permette di create una piattaforme aperta e decentralizzata dove vari dispositivi IoT riescono a comunicare tra di loro in una forma semplice e affidabile.

Puoi trovare i video di tutti talk qui FOSDEM 2016


 

Ogni anno viene organizzata una serata dedicata al FOSDEM, al Delirium Café vicino al Grand Place, la piazza centrale di Bruxelles. Non potevamo perderci questo evento per conoscere nuove persone, per fare networking e per goderci delle ottime birre belghe (la scelta è molto vasta; parliamo di oltre 25 birre)!

Come potete vedere non abbiamo resistito agli sticker che venivano distribuiti ai vari stand:

FOSDEM stickers!

gennaio 15, 2016 - No Comments!

Apple TV Tech Talks for tvOS

We had the opportunity to participate at the Apple TV Tech Talks at Berlin. This was a one-day event where was possible to get in-depth technical information on building and designing for tvOS, and obtain valuable development instruction from Apple experts.

1

The event started at 9:00 and finished at 17:00 approximately, for a total of 11 talks each one with the duration of half an hour. During all day was possible to meet with Apple experts to get development help for tvOS.

The agenda was the following:

Morning Agenda:

  • Apple TV Tech Talks Kickoff
  • Designing for the Apple TV
  • Focus-Driven Interfaces with UIKit
  • Break
  • Siri Remote & Game Controllers
  • On-Demand Resources & Data Storage
  • Lunch

Afternoon Agenda:

  • Media Playback
  • Leveraging TVML for Media Apps
  • Best Practices for Designing tvOS Apps
  • Break
  • Tuning Your tvOS App
  • Making the Most Out of Top Shelf
  • App Store Distribution
  • Reception

We will now dive deep into each talk and describe what impress us the most.

Apple TV Tech Talks Kickoff

2

In this introduction talk was explained the agenda and expectations for the day. A event talking about the mindset, best practices, state of the art developing into this new Apple platform.

It was talked that the rate of innovation in mobile is very different in regard to the one seen on the TV.  In the words of Apple "The future of TV is Apps". Apps optimised for media consumption like NetflixYoutubeHBO, etc. Apps for fitness like Zova. For shopping like GILT. And gaming apps, like Disney InfinityDoes Not CommuteAlto Adventure. Or even the digital comic book like Madefire. And also children apps like Sago Mini Fairy Tales.

Apple says we are still at the beginning it is still needed to bring the innovation from the mobile platform.

Next was talked about the three tvOS Fundamentals and how they differ from the mobile:

  1. Living Room Experience
  2. Always Connected
  3. Powerful Hardware

6

The Living Room Experience differs from the mobile since it is used from distance, the interaction with the user is focus-based and the attention should be on the content. It often can be a communal experience with a shared device and multiple people interacting, in group or at different hours.

The fact it is a device that is (probably) always connected enables services like http live streaming, on-demand resources and cloud storage to always be easily accessible, versus a mobile connection that usually is unreliable.

3

The "powerful hardware" present on the Apple TV is basically an iPhone 6 without screen and without sensors, it contains the A8 chip with 64-bit architecture (1.5 GHz dual-core + quad-core GPU). Apple says that for developers this HW sets a new performance baseline development, instead of the A5 chip with 32-bit architecture (800 MHz dual-core + dual-core GPU) if you are still supporting the iPhone 4S (which still runs iOS 9).

4

Doing a tvOS app means you are using a separate SDK, with a standalone binary (versus targeting iPhone and iPad where the binary is the same). For developers means you can also use the same tools and frameworks with extra support for media and gaming.

5

Designing for Apple TV

Designing for tvOS means designing for the Living Room Experience. You should connect people to content in a direct way, even if the TV is far away from the user. With the remote you can use gestures, small or quick movements.

7

The experience should be connected, clear and immersive. The omnipresent parallax effect should delight and connect the user to the content.

Some things should be intuitive, it should be clear where the user is at the moment. It never should be hard to read text, and the UI should never be dense.

The app navigation should be clear, one in-out path.

8

The system font San Francisco was optimised for large distances, and it responds to accessibility settings.

When possible should be used the grid structure with the item at focus clear at distance.

There should not be ambiguous gestures with the remote.

When correct it should be used a cinematic experience with edge-to-edge background of movie images.

The user can interact with the TV using the touch surface, menu button, play/pause button. It is not appropriated to use multi-touch gestures with two fingers, but you can use one-finger gestures.

The Play/Pause button can be used for playback or game shortcuts.

The Menu is the back button for navigation (there should be no back buttons on the UI).

The Accelerometer and Gyro are available for use, and in certain cases can help to connect users with the content, for example with subtle movements in the controller affecting the content rotation.

The remote can also be used in landscape, for example in the break neck game.

The content should move in the expected direction, inverse of direct manipulation like iOS (except in fullscreen mode or games).

The UI buttons can have different distinct states, unselected, selected focus, highlighted, disabled.

The focus should be obvious, a good test will be: "Look out of the TV and look back, the content at focus is obvious?".

It is possible to add animation to make it easy to see which content is at focus.

Measurements for grids and spacing are available for use at Apple Human Interface guidelines.

Most of the times use clicks instead of taps, taps can be made accidentally, click is intentionally and often will be a better option.

Focus-Driven Interfaces with UIKit

The focus-driven interface present in the TV follows the finger movement and states the next view in focus. This engine calculates how to move and animate, where the focus should be at any moment, the parallax effect, the speed adaption (if I move faster the finger on the remote).

The focus engine handle all the (numerous) tasks related to focus model.

9

The Focus API gets the focusable view, the initial focus and current focus.
A new property was added to UIView called canBecomeFocused to tell if the view can become focused.

The new protocol UIFocusEnvironment introduces new the property preferredFocusedView and table and collection views delegate methods for handling the focus model. To UIView and UIScreen were also added new read-only properties.

11

The focus should not be set manually, the user should be in control of the focus.
Avoid ambitious cases, for example when views are removed, new views are presented or dismissed, the focus update requests where the focus should go. To do this use canBecomeFocused and preferredFocusedView

You can request focus, with setNeedFocusUpdate and update focus if needed for collection view cells, just remember to adjust the cell when the ancestor is focused, for example respond to focus changes by showing/hiding a label with animation.

The animation timing should responds to speed of swipe in the remote, fast movements make faster animations.12

If you want to listen to focus updates implement the method didUpdateFocusInContext.

Use focus guides to guide focus when it is not clear in the UI where the focus model should move.

13

14

To debug focus use the property whyIsThisViewNotFocusable, or using the option "Quick Look"  in the Xcode debugger.

15

16

It is also possible to tap edges of the remote Up, Left, Right, Down, Arrow, works on Siri remote, and with game controllers pads

You can also implement low level event handling, the touch API is also available, coordinates are from center of focused view.

Siri Remote & Game Controllers

You can use the Siri Remote as a game controller directly by using the game controller framework.

Touches on the Digital Pad are windowing, that is the framework creates a window with a center where user first puts the finger and all values are relative to this virtual window.

DPAD values are by default in portrait, you can adapt it automatically with a the allows rotation property.

The menu button in gameplay should toggle pause/resume instead of handling navigation.

You can integrate the controller with UIKit with the user interaction enabled property.

To disable the screensaver timeout with idleTimerDisabled property, this should be done not always but only while in gameplay mode.

To access device motion use the GCMotion profile, this access accelerometer and gyroscope data, this data is already filtered and uses fused data from both sensors. This access is not intended for vigorous shaking aggressive movements.

17

18

There is a limitation for the number of controllers you can use: one siri remote plus up to two MFI controllers. You should always take input from all controllers if possible.

19

On-Demand Resources & Data Storage

20

Instead of traditional apps and downloading all the bundle, in the TV based on user interactions and predictions you download the resources you need. For example, when the user downloads the game, the app may contain the first level, and based on the level he is playing the resources are downloaded for that level, and when no longer in use they are erased.

21

The dynamically loaded content is hosted in the App Store. The on-demand resources feature enabled prioritised downloads and intelligent caching.

What the customer gets with on-demand resources? Better install experience with reduced time install, more apps on the device, and up to 20GB of content.

You can define install tags (download on demand) for the content and prefetch tags (immediately download after install).

The TV storage limits are the following base app up to 200MB, on-demand up to 20GB, in use app up to 2GB.

22

Initialise the content with a set of tags, then begin requests, and after tell the system when you are finished. You can track the progress of request, but ideally you should not have need to use this, instead you should anticipate the user needs better. Temporary data is subject to purge.

You can set the loading priority, and also set an urgent priority if the user is waiting for the content. You can use the property Is content available? You can conditionally begin accessing resources and receive the result with a completion handler.

23

You can also set a preservation priority to tell the system how important is to keep around the disk, this is for content not actively used, and is used for caching, it is relative to your app not system wide (don't set it to 100 to keep it around more than other apps ;)).
To test on-demand resources you can use Xcode and Xcode server, this is a artificial download, it should test correctness not performance.
If you use TestFlight closer to deploy, you get real world performance with the network link conditioner.
You can also embed the resources in the build, build settings to embed assets into the app, not correct for App Store, can be used to distribute ad hoc the app outside of App Store.
It is also possible to host the content in your internal web server, for example in a enterprise scenario.

To store small preferences data you can iCloud key-value store, for structured and bulk data you can use CloudKit. Remember that the user might not be signed in and multiple people may be sharing the device.

24

The cool thing is that public data is available even if user is not signed in. There is however a single sign in account per user.

Media Playback

The TV can offer a very good media playback experience. The video player present in the framework does a lot of heavy lifting for you. The AVFoundation and AVKit provides a info panel, language, subtitles, sound, content scrubbing.

AVAsset represents a single media asset, from a file or streaming. AVPlayerItem, references single asset, with metadata. AVPlayer, manages the playback of a AVPlayerItem and AVQueuePlayer plays multiple items in sequence.

To show metadata in the info panel, you set it in AVPlayerItem or set it with external metadata. "What did he/she just say" feature of Siri uses this metadata.

25

Interstitial time ranges, time ranges not part of actual content (ads,legal,warnings,etc.) and you can set different rules for it, for example no skipping ads. Avoid swapping players to display interstitial, instead use AVPlayerViewController delegate methods for managing interstitial , for example to disable skipping.

Rare cases can use AVPlayerLayer directly, use it when you want to customize the playback experience, this provides No Controls or UI, Zova uses it to skip/previous exercises.

The reproduce media can be file based (Local bundle, On-Demand Resources, or cached). This has to be downloaded prior playback and should be very short clips to avoid long loading times.

The ideal way to provide media is trough http live streaming (HLS), segments are downloaded during playback and is adaptive based on the available the internet connection status

27

The used codec is H.264 / AVC, it supports up to 60fps.

In the audio can be add described video track for accessibility. To support "trick play" it is needed to add frames with EXT I FRAMES. Subtitles are important for accessibility of for the "what did he just say" Siri feature.

For more info on the media reproduction with accessibility it is recommended to see the presentation of the WWDC13 Preparing and Presenting Media for Accessibility.

Leveraging TVML for Media Apps

TVMLKit is used by the App Store, music and video apps from Apple. It is recommend when the server content is the focus of the app.

2

TVML is template based language that offers consistent UI, and can lead to reduced development effort with shorten time to market.

1

Optimal cases where leverage existing client server architectures benefit a lot from TVMLKit, you
provide native experience with little development times.

As said clearly by Apple this is not a web browser.

The UI is defined with a XML document. and you can link the JavaScript with Swift or Objective-C. The TVJS framework has access to system frameworks, and you can bridge from native to JavaScript and vice-versa.

4

3

5

6

For debugging you can use the Safari web inspector.

Apple haves sample projects made with TVML and content server samples.

Best Practices for Designing tvOS Apps

This talk was about the common questions and problems when designing for tvOS.

In the TV loading is a constant, since the local storage is limited and you can always assume a network connection. Therefore you should at all costs avoid blank screens, is better to use placeholder for images and the UI, while the content is being loaded.

1

Activity indicators or other UI elements can indicate well progress, The game Does Not Commute and Rayman Adventures do it very well. In the first the radio of the car presents a loading bar and then it is the place where the game is played, in the latter we see Rayman running when loading the content.

Always try to set expectations to loading time, and use the loading time to educate the user (with useful info) or entertain him. Galaxy on Fire app when loading shows the story or if you skip show game tips.

Try to avoid authentication since it is not a good experience, if you need it, for example with payment systems, delay it until it is really necessary. GILT app lets browse everything without sign in until you try to buy something.

Important if you need to ask for emails remember to use the correct keyboard that shows the Recent emails entered in any system app.

When needed you can create a companion app to do more complex authentication behaviours.
Not on the high street app completes the payment with an iOS companion application, it finds your device in the network using the bonjour technology.

Since the apps in the TV can have multiple users Include a fast profile switching like in the Airbnb app.

Very likely your app will be used in different devices, iOS or tvOS, therefore make restore purchases obvious.

2

The on boarding is critical to show how to use your app. Try to get out of the way, remember people want entertainment, they don't want to read instructions.
Badland app does not show any instructions when starting, when you start playing the possibilities are gradually presented.

The on boarding should not be a crutch for a bad UI. If developing a game show the controls when the user pauses the gameplay, like Breakneck app does.

Transistor app show different instructions based on the controller you are using. Click with Siri remote, or press buttons with MFI controllers.

The Alto Adventures game show instructions as you go, much more fun than displaying a list of instructions (that everyone will skip).

3

Try to anticipate the need for help and give the information to users gradually.

Using a cursor to point something is wrong , the focus model is right. Try to design the UI right to take advantage of the focus model.

4

Take in mind that the TV is a totally new device, design specifically for this platform don't try to port from Mac or iOS, it will not work.

Making the Most Out of Top Shelf

The tvOS has a feature called "Top Shelf", that is when the user moves the app to the Top Shelf (the upper dock of the main screen).

When the app is at this position it has control of the content displayed on the Top Shelf. This can content can be a static image, and so it is not interactive.

If your app was moved to the top of the home screen the users are already using it, this is no place to capture users, but instead to promote content to your users and provide a quicker access to parts of your app.

If you choose to display dynamic content try to ship it on the first version otherwise people may lose it. This dynamic content has also the advantage that it is not linked to the bundle so it is always update when you change the service that serve this content.

Sing by Smule app does it with image content from the application. Zova shows the most relevant content for the user. The Newsy app shows featured content.

This feature can saves steps by going directly to content, and you should implement play to start immediate playback.

To be personalised you can  use the TV top shelf provider protocol. You can choose the Top shelf style, that can be a unique part with inset or divided by sections.

To populate the shelf you define a Tv content item array, specifying the image ratio and other metadata. If you use the section style you return an array with the sections.

You should provide links to content, with custom URL schemes for your app and responding to system calls, like you do right now in iOS.

The URL with media should go directly to playback when the play button is pressed.

You should implement the play direct option and display for all content on the top shelf, posting to different parts of your app.

To let the system know when the items will need to change using the notifications : tv top shelf items did change notification.

App Store Distribution

A the moment the tvOS App Store is available in over 100 countries. All apps are handpicked by Apple, trough their submission process, very similarly to iOS. The sections in the store are Editorial curated by local Apple employees and the store also displays a search feature and the traditional top charts, divided by paid, free and grossing.

The top markets for iOS at the moment is the following:

IMG_0235

There are some business considerations to define when developing an tvOS app. These Business models are the same as iOS. And application can be free and make money by selling services or goods (GILT, Airbnb, etc.), it can be a pay once strategy (Alto Adventures, etc.), a Freemium model, free to download and pay after for contents or features or even a Paymium model, where the user pays to download and then pays after for contents or features.

For the TV almost 40% of the applications are paid, contrary to the 10% in iOS.

IMG_0233

IMG_0234

Depending on what you want to achieve reach (maximum number of users), revenue (maximum return) or both, you have to find a solution that fits you and your users.
Freemium can be a good model to reach both a user base and still make a good revenue from the app.
It is a difficult task to find the right price for throughly charge users, and what kind of model does your user expect.
To help reasoning you have to think which kind of use is your app best at, people will use it periodically for a quick use or it has a lasting value? Does the app gets better the more user it has? All these are important questions that affect you product development.

With the TV Apple introduces a feature called "Universal Purchase" this is a non reversible action that enables your users to purchase once and use it in iOS and tvOS.

In app purchases are a place where you can use this feature, always demand the same question "What is most important reach, revenue or both?". Take in mind that customer don't want to pay two times, but if you offer something different/platform specific it may work. Take in consideration also case where you have Content right limitations , show in mobile and tv may not be the same and the user understands it (a little bit like Netflix does with their business model).

Both app stores enable global expansion and make it easy to start a global business, the iOS App Store is right now at 154 countries. But take in mind that the editors of the App Store like to feature local content. A good strategy should be to consider the top markets by leveraging also your own data and localise the app right in order to meet customer expectations (if I see a app in the store in my language but after I download it and I don't understand anything I will delete it).

Remember every visitor in the store is a potential customer, polish your Icon, have a good, unique, short app name, match uniqueness, short, no Apple TV or tvOS trademarks. Take great screenshots of your app. The first 3/4 lines of the description are the most important.

Keywords are important for ASO. Use all 100 characters, commas, plurals and category are not necessary, they are automatically added by the engine. Add relevant keywords by understanding well the rules.

IMG_0238

IMG_0239

When developing marketing materials use tvOS approved image in guidelines, Download the App Store badge to display in your website, add icon imagery. A good example is the Sago Mini Fairy Tales app.

Getting featured in the store is very easy, just make a great app that customer will love. 🙂IMG_0241

Always ask yourself the following questions: Is the app unique? What make people love your app?

The app should be engaging, provide a living room experience when interacting with a group of people. It should be have a intuitive use of Siri remote.

The first time a user opens you app should be fantastic, with great on boarding (don't use on boarding screens, don't pop up for login at start).

Remember that performance matters, if the app is slow at loading, freezes or crashes, it will not be featured.

If the app is not a port of a Mac or iOS but it is clear that is designed specifically for tvOS also helps getting featured.

Getting featured is also a matter of understanding the process at Apple. They refresh the contents every Thursday. Usually the it has certain themes for holidays or periods of the year (for example a fitness app in January, I see what you did there Zova 🙂 ). They have a preference for localised content, and have focus on initial launch and significant updates.

Even if Apple does not naturally discovers your app you can also let them know. Be sure to send the Product details, Apple ID and App Store link. Tell what makes your app special, your product roadmap, send the marketing material. Be sure to contact before going online, 3/4 weeks before is the recommend time frame. The contact email is appstorepromotion@apple.com

IMG_0243

Quality always comes first when getting featured, having the right business model to enable sustainable development of your app. Try to think global but be local. Create a great product page to help drive your sales and don't forget to market your app.

Conclusion

Overall the Apple TV Tech Talks for tvOS was a great day, the presentations had a great quality and the Apple experts at the event were very available to answer any doubt regarding different parts of tvOS.

All the materials of the event are present here.