Indice articolo

Il 25 e 26 Novembre 2016 si è tenuto a Milano un importante evento sullo sviluppo di software: il Codemotion 2016 

Sme.UP ha partecipato con ben 11 elementi dello laboratorio di sviluppo. Si parlava di coding, test, deployment, database, operation, mobile, user interaction, cultura, team, leadership… non potevamo mancare!

Questi i topic in cui erano organizzati gli speech:

  • Mobile
  • Game Dev
  • Security
  • DevOps
  • Architectures
  • Front-end
  • Cloud/Bigdata
  • Inspirational
  • Javascript
  • Meetup
  • VR/AR
  • AI/Machine Learning
  • Golang
  • Design/Frontend
  • Programming

Le presentazioni sono state quasi tutte registrate e caricate a questi indirizzi Youtube e Slideshare

Abbiamo raccolto alcuni appunti che riportiamo in questo (lungo e) interessante post.

Buona lettura!

Da developer a team leader

  • Dare sempre indicazioni precise su quello che serve ma non pretendere che lo sviluppatore scriva codice come lo scriveresti tu. Ognuno ha il suo stile.
  • Il lavoro va seguito. Utili riunioni brevi ogni giorno per fare il punto della situazione e dei problemi.
  • Le tempistiche sono fondamentali ma non assolute. Anche il miglior analista sbaglia, bisogna essere pronti a rivedere i tempi delle singole parti di sviluppo senza perdere di mira i tempi di consegna.
  • Il teamleader ha funzioni di controllo e di relazione fra committente (manager o cliente) e sviluppo. Ogni azione che scavalchi questo filtro (ad esempio, dirigente che fa richieste allo sviluppatore) è deleteria perché crea confusione e toglie autorità al teamleader.
  • Separazione delle ansie: ruolo del teamleader è evitare che i problemi tecnici arrivino ai committenti e che le ansie dei committenti arrivino agli sviluppatori.
  • (Risposta a domanda finale) L’outsourcing è un mito: per funzionare richiede specifiche di progetto dettagliate, un criterio di controllo dei risultati molto rigoroso e un continuo contatto. Va bene per lavori a basso valore aggiunto (dataentry massivo, conversioni) ma per lavori importanti è molto difficile da gestire.

Applicatione Security

  • E’ importante progettare non solo sistemi per il testing del software prodotto ma anche test di sicurezza, soprattutto nei contesti web o social
  • Esistono tool commerciali e free per l’esecuzione di test di sicurezza di ogni tipo (vulnerability test, penetration test, DOS attack test ecc ecc)
    • Progetto OWASP che raccoglie tutta una serie di tools free che coprono quasi tutte le casistiche legate all’application security legate al Web
    • Dawnscanner, prodotto commerciale
  • Punti fondamentali per produrre un sistema sicuro
    • Automatizzare il rilascio di una release. Ridurre al minimo l’intervento manuale, se un operatore umano ha la possibilità di sbagliare prima o poi sbaglia-
    • Diffondere a tutto il team di sviluppo i concetti base dell’application security
    • Automatizzare i processi di test per la sicurezza
    • Preferire l’utilizzo di collector tool e orchestratori coma Canaveral. Migliorano la raccolta dati e sono integrabili nelle procedure attraverso API.
    • Quando si individua un problema non generare un report ma utilizzare un sistema di Ticketing. Il report viene dimenticato, il sistema di ticketing obbliga il destinatario a prendere in carico il problema e lascia una traccia di ogni operazione fatta (o non fatta)

Test Driven Development

  • Testo di riferimento assoluto: “TDD by example” di Kent Beck
  • Principi:
    • Realizzare test di poco codice facilmente leggibili.
    • Frammentare il problema in micro-problemi per realizzare test semplici.
    • Il test dev’essere progettato per testare una funzionalità specifica, quindi fallire per un motivo strettamente legato a quella funzionalità che si sta testando.
    • Usare gli oggetti mock
    • Repository su Github del relatore con materiali
    • GOLANG

Obiettivo: sviluppo di un’applicazione per il televoto in grado di gestire in modo efficace grandi quantità di dati senza richiedere grandi risorse hardware (basso rapporto costo/prestazioni). Il target richiesto è la registrazione di 10.000 voti/sec con una configurazione hardware abbastanza economica (cluster con tre server Linux su piattaforma Intel).

Viene riportata l’esperienza di sviluppo e le tecnologie utilizzate nelle varie fasi

  • Java: buona velocità di elaborazione (4000 voti/sec), ottimo supporto tecnologico ma richiesta eccessiva di risorse che eleva i costi.
  • Ruby on rails: framework operativo molto efficiente anche se fortemente orientato al web. Buone prestazioni (3000 voti/sec)
  • C++: multipiattaforma, prestazioni elevate (6000 voti/sec) ma troppo complesso da gestire ed ottimizzare. L’uso di una libreria di garbage collection semplifica le cose ma peggiora notevolmente le prestazioni e la richiesta di risorse
  • C#: prestazioni e limitazioni simili a Java, ha il vantaggio di essere un sistema più chiuso (poche tecnologie in concorrenza tra loro) e di avere ambienti di sviluppo molto efficienti. Compilatore Linux non allineato alla corrispondente versione ufficiale per Windows, quindi richiede attenzione per la portabilità.
  • NodeJS: ha dalla sua la modernità della soluzione e la grande offerta di librerie e tecnologie correlate. Buone prestazioni, buona scalabilità. Non raggiunge però il target richiesto.

Alla fine la soluzione migliore è risultata Golang:

  • Alte prestazioni, soprattutto nella gestione di thread concorrenti. Raggiunta una capacità di elaborazione di 11000 voti/sec.
  • Linguaggio moderno, di alto livello e ottimamente documentato e supportato (c’è dietro Google)
  • Deploy semplicissimo: il compilatore produce un solo file eseguibile che contiene tutto il necessario e che può essere distribuito così com’è.
  • Multipiattforma, esiste un compilatore per tutte le principali piattaforme e le librerie disponibili non hanno dipendenze specifiche con la piattaforma sottostante.
  • Grande disponibilità di librerie, possibilità di integrare anche librerie C/C++ e anche Java (seppur con qualche limitazione).
  • Difetti: non propone soluzioni standard per i vari contesti applicativi (gui, web ecc ecc). Esistono soluzioni alternative offerte da librerie esterne ognuna delle quali ha pregi e difetti. Richiede quindi una valutazione attenta nella scelta di librerie di terza parti.

Angular

Pregi:

  • Data Binding
  • Dependency Injection
  • Modularità e riusabilità dei componenti.

Evitare:

  • Controller troppo grandi, mappati 1:1 con HTML.
  • Come la peste, copia/incolla di codice.
  • Spaghetti Bindings incontrollato

Spaghetti Binding  -> logica applicativa nel frontend

Già in Angular 1.5 conviene usare la logica a componenti. Angular 2.0 è basato tutto su componenti, quindi la portabilità sarà più facile.

Cosa è un componente?

Un sottoinsieme di logiche e UI che incapsula un comportamento specifico. Fornisce API esplicite per Input/Output.

Come si definisce una API per un componente?

  • Bindings di INPUT
  • Bindings di OUTPUT
  • Naming convention (aiuta anche ad evitare Spaghetti Bindings)

Tree Model nei componenti: in componente può essere composto da componenti. Quelli più in alto sono più applicativi e intelligenti, quelli più in basso più generici e stupidi:

  • SMART o STATEFUL components (a livello alto): Specifici per la logica di Business, difficilmente riutilizzabili in modo generico, ma molto potenti.
  • DUMB o STATELESS components (a livello basso): Sono generali e soprattutto indipendenti.

Note: I componenti DUMB per comunicare “lanciano” eventi verso i componenti a livello più alto che li usano, mentre i componenti SMART ricevono gli eventi e “decidono” cosa fare. In compenso il flusso dei dati parte dall’altro, dai componenti SMART, e arriva in basso verso i componenti DUMB.

Quindi:

EVENTI Down->Up

DATI Up->Down

Se devi fare 2 cose fai 3 component. Due che fanno le due cose e uno che fa entrambe.

Tutti i componenti hanno i LIFECYCLE HOOKS che sono:

  • ONINIT: scatta quando viene creato il componente.
  • ONDESTROY: scatta quando viene distrutto il componente.
  • ONCHANGE: scatta quando cambia qualsiasi dei campi (binding) di INPUT del componente.

Test consigliati:

  • Unit Test
  • Integration Test con progetto Single Component (facile da realizzare dato l’isolamento del codice).

Apple Watch (Base)

Le “applicazioni” su WatchOS 3 sono di tre tipi:

  • Apps
  • Notifications
  • Complications

C’è da tenere presente che:

  • si tratta di un “Fast device” e quindi bisogna annullare il tempo di caricamento. Nessuno vuole attendere e vedere un caricamento mentre alza il polso.
  • ha uno schermo piccolo.

Ha un SDK dedicato usabile con XCode (WatchKit).

Dalla versione 3 di WatchOS esiste il concetto di Dock (e dock area) in cui fissare le applicazioni.

Una volta nel Dock ed in background l’applicazione ha un numero massimo di “slot” di refresh in 24 ore per mostrare le informazioni:

  • 50 push garantiti per le complications
  • 24 push garantiti per le app normali.

Di conseguenza bisogna stare decidere come gestirli.

APPS

Dal punto di vista tecnico, una applicazione per watchos è composta da 2 parti:

  • La watchApp che contiene la StoryBoard e i resource Files (analogamente ad iOS).
  • WatchKit Extensions – che si interfaccia al telefono e all’eventuale app del telefono.

Nota: L’interfaccia dell’applicazione non è libera. Si possono scegliere solo 2 layout: in linea o in colonna.

La navigazione, definita nella Storyboard può essere solo di 3 tipi:

  • A pagine
  • A gerarchia
  • Modale

Un’altra opportunità per lo sviluppo su WatchOS sono i Context Menù.

Sono opzionali (non necessari per tutte le app) e la loro definizione forza il touch dell’orologio ad attivare il Menù.

I context menù devono seguire rigorosamente HIG definito da APPLE.

I Settings dell’applicazione sono SOLO su iPhone e possono essere di 2 tipi:

  • Definiti nell’app specifica che ha l’equivalente in Apple Watch.
  • Condivisi con i settings accessibili tramite l’app “Apple Watch” su iPhone.

NOTIFICATIONS

C’è da sapere che qualsiasi App esistente che gestisce le notifiche funziona già di default.

Le notifiche hanno 2 viste:

  • SHORT: dura 2 secondi e non è personalizzabile. E’ quella che appare di default.
  • LONG: dura fino a quando non viene chiusa o scatta il tempo di inattività. E’ personalizzabile ed accessibile dalla SHORT oppure direttamente se l’app è predisposta.

COMPLICATIONS

A partire da qualsiasi App per Apple Watch è si può definire una complication. Vale quanto detto nel capitolo APPS ed è sempre possibile integrarla in un APP.

Solo i “widget” che puoi aggiungere in prima schermata (orologio) e a cui puoi accedere rapidamente.

Le complications:

  • Hanno delle viste specifiche.
  • Tramite loro puoi, se predisposte, accedere all’app intera.
  • Non caricano quando “alzi il polso” di conseguenza per aggiornare le informazioni, serve un preload dei dati (temporizzato o pushato).

IBM Watson Conversation

WATSON: serve a creare applicazioni/BOT che capiscano linguaggio naturale e consentano dialoghi interattivi.

https://www.ibm.com/watson/developercloud/

Composto da una serie di servizi divisi in aree: Vision, Language, Speech, Data Insight.

CONVERSATION (Language)

Servizio che interpreta l’input di un utente e gestisce il flusso di un dialogo, raccogliendo informazioni dove e quando ne necessita

intenti → scopo utente

  • per il riconoscimento serve apposito training
  • a un intento corrisponde un flusso di dialoghi per completare la richiesta

entità → oggetti di input che danno specifiche di un intento (azioni, contesti, oggetti)

  • intento → n azioni

dialogo → costituito da serie di nodi, può dare risposte compiute, risposte che necessitano di variabili di contesto (utilizzo di servizi per completare), entità aperte (troppi risultati → utilizzo di servizio ALCHEMY), anything_else ( → servizio RETRIEVE AND RANK per sgrossare)

Piattaforma IBM Bluemix

https://console.ng.bluemix.net

Project INTU: Embed cognitive functions in various form factors such as spaces, avatars or other IoT devices

Veder TJBot : robot per stampante 3d + raspberry

User experience

One vision

Chi sono i tuoi utenti?

Fare i wireframe! Meglio carta. Strumento https://www.invisionapp.com/

Google Monarch

Gestione dei datacenter.

Configurazione in python

Combining AI and IOT

Problemi IOT: tanti protocolli, sicurezza, affidabilità, accesso a device, flessibilità, ambiente di utilizzo

IOT (molti dati) → AI → Dati rilevanti per applicazione/scopo

GSM + Arduino

I servizio devono adattarsi agli utenti, non viceversa.

whatevermobile.com

  • Mobile connectivity as a part of IoT
  • Multinetwork solutions

risorse: http://karinapopova.com/wp/2016/08/23/cellular-connectivity-as-an-integral-part-of-iot/

Big Data, Small Dashboard

Come migliorare un dashboard. Quali dati e come presentarli graficamente.

Testo di riferimento di Stephen Few, Information Dashboard Design: Displaying data for at-a-glance monitoring

Graph databases

Data leak relativo a compagnie off-shore di 2,8 TB di dati. https://panamapapers.icij.org

ICIJ (International Consortium of Investigative Journalists) 190 giornalisti investigativi di 65 paesi.

Machine Learning

Passaggi:

  • acquisire i dati
  • preparare i dati
  • analizzare i dati (imparando dai dati storici)
  • costruire il modello di analisi
  • validare il modello
  • applicare il modello agli eventi (a scopo predittivo)

Con Neo4j (db a grafi gpl3 -> licenza non per uso commerciale) hanno analizzato i dati in 1 settimana.

ICIJ EXTRACT tool di estrazione open source su GitHub

Search on the fly

Apache Lucene

Orient DB

Database a grafi e a documenti

Full Java (java -jar orientdb!) – standalone o embedded

Usa lucene per ricerca full text

Licenza Apache 2 che consente utilizzo commerciale

Plugin geospaziale per utilizzo con google maps

Json

WTK: well known text

commons-csv (libreria apache per la gestione csv) 

Editor: intellij e webstorm

https://www.jetbrains.com/idea/download/#section=linux

https://www.jetbrains.com/webstorm/

Test api: postman (tool per http request)

https://www.getpostman.com/

Microservice con Spring

Netflix OSS https://netflix.github.io/

https://spring.io

From monolith to microservice

Errore 1: non cambiare il modo in cui ci si organizza. Separare e distribuire le responsabilità tra componente, mantenendo legami a spaghetti è inutile

Errore 2: comunicazione sincrona. Per disaccoppiare deve essere asincrona

Creare un message bus!

Usare push communication

Database distribuito tra servizi: se il db è centralizzato, si blocca tutto. Se è distribuito, se qualcosa non funziona si può mantenere una cache.

Microservice: aumentano gli OPS cost, aumenta la flessibilità, diminuisce il costo di sviluppo, diminuisce il costo di rilascio

Non sottostimare le problematiche di rete. Assumi che ci saranno sicuramente problemi.

Next generation frontend

Modelli:

MVC, MVP, MVVM, DCI, FLUX, MVI.

MVI dovrebbe essere il più figo

Reactive programming

Public speaking

  • Consigli per affrontare nel modo migliore una sessione di public speaking
  • Se siete timidi patologici la soluzione è lo psicologo, non questi consigli.
  • Materiale interessante da vedere su youtube o TED:
    • james-whittaker : the act of stage presence
    • nanogirl
    • amy cuddy – ted – body language
  • Immaginare di avere una conversazione con il pubblico
  • Il linguaggio del corpo è importante e spesso non percepito da chi parla. Non allenarsi parlando davanti ad uno specchio ma registrare un video e rivedersi.
  • Avere un rituale pre conferenza aiuta a smaltire la tensione
  • La parte iniziale della presentazione è quella principale: se si sbaglia quella e si perde l’attenzione del pubblico poi non si recupera più.
  • Raccontare sempre storie reali
  • Parlare solo di cose che si conoscono bene. Solo i più bravi riescono a parlare per ore del nulla.
  • Le citazioni creano emozioni ma non esagerare.
  • Le battute sono importanti per mantenere alta l’attenzione ma devono essere naturali, inerenti al contesto e non troppo numerose.
  • Procrastinazione creativa: non prepararsi troppo. Il cervello sente le cose come trite e ritrite, quindi ti fa esprimere noia quando le esponi. Preparare una presentazione all’ultimo momento consente di includere anche le idee dell’ultima ora e favorisce un processo creativo. Tenere però conto dei tempi di preparazione.
  • Le slide importanti sono la prima e ultima, queste sono le sole parti che vanno preparate bene, tutta la parte in mezzo va fatta a braccio nel modo più naturale possibile

From IOT to Human

Cisco DevNet: portale CISCO per lo sviluppo (stile Bluemix, Azure, etc.)

Cisco TROPO. Cloud API for communications: voice and messaging

Cisco Spark: collaboration

developer.cisco.com

Continuous Budgeting

Tenere in relazione strategia (1 anno) con tattica (semestre, trimestre, mese).

Aggiustamenti continui indotti dal “mercato”

Cynefin framework

Categorizzazione di un problema/situazione in

Beyond budgeting

Debito tecnico (Meir Manny Lehman)

Serverless data architecture

  • Kubernetes
  • Apache Beam
  • Google BigQuery
  • Google data studio

Distiributed systems explained (with NodeJS)

CAP theorem

  1. Consistency
  2. Availability
  3. Partition tolerance

non si possono ottenere tutte e tre

Sistemi CA (1. 2.) -> Rete sempre su

Sistemi AP (2. 3.) -> Sistemi “eventualmente” consistenti (Cassandra, Dynamo, Riak)

Sistemi CP (1. 3.) -> Sempre consistenza ma non disponibilità (Google Spanner)

Progessive web app

Performance reali vs percepite

Service worker -> non utilizzano il thread principale (funzionano solo su https)

  • strategie di cache (diversa cache browser): cache only, network-fallback to cache, cache-fallback to network, cache then network

Lighthouse -> tool estensione di google chrome che ci aiuta a fare analisi sui nostri siti

From GOF to lambda

Behavioral patterns rivisti in programmazione funzionale: come togliere overhead di OOP in pattern che riguardano azioni e interazioni.

https://github.com/mariofusco/from-gof-to-lambda

I pattern:

  • The command pattern
    • The strategy pattern
    • The template pattern
  • The observer pattern
  • The decorator pattern
  • The chain of responsibility pattern
  • The interpreter pattern
  • The visitor pattern

Risorse ed esempi:

https://www.voxxed.com/blog/2016/04/gang-four-patterns-functional-light-part-1/

https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-2/

https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-3/

https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-4/

Stop using bootstrap please!

slides: https://speakerdeck.com/makhbeth/stop-using-bootstrap-please

Drones collaboration and IOT

IoT significa anche avere a disposizione un elevatissimo numero di sensori.

Sensori che se installati su droni possono moltiplicare la loro efficacia.

I sensori devono però poi essere in grado di comunicare e collaborare. Entrambe le cose devono essere fatte nel modo e con il canale più opportuno.

Strumenti che possono aiutare nella collaborazione:

Cisco Spark

Cisco Tropo

Come rendere il proprio prodotto una bomba creando una community

Come può un prodotto evolvere correttamente nel tempo? Con l’aiuto delle persone.

Persone che vanno messe sempre prima del prodotto. Persone che devono sentirsi “al sicuro” e non spaventate dal prodotto.

Creare ambienti di lavoro in cui gli sviluppatori sono isolati dagli utenti (torri d’avorio) è pericoloso. Gli sviluppatori assumono che chiunque sia uno sviluppatore.

Bisogna imparare a conoscere gli utenti.

Bisogna testare il più possibile e avere feedback. Chi meglio degli utenti possono darci feedback?

Tutto questo può essere fatto creando una community sul prodotto.

E’ molto più difficile abbandonare una community di persone, piuttosto che un prodotto senza faccia. Con una community si construiscono relazioni, che sono molto più importanti delle caratteristiche stesse del prodotto.

Le community devono crescere pian piano.

La prima esperienza è sempre quella critica. Dai sempre il benvenuto alle nuove persone. Falli sentire ascoltati. Dai immediate risposte ai primi post.

Bisogna saper essere comprensivi. Sii umile e non prenderti troppo sul serio. Ringrazia sempre per i contributi.

Aiuta. La gente si rivolge alle community principalmente per ricevere aiuto, non per darlo. Fornisci qualcosa in cambio del loro aiuto.

Ascolta e rispondi. Non lasciare domande / discussioni senza risposta.

Ascolta ciò che dice e chiede la community. Ma non farti dire cosa devi fare.

Talking and listening to webpages

WebSpeech API:

  • NPL: Natural Language Process → per interazione secondo Test di Touring
  • API: del 2012, richiedono il permesso di aquisire l’audio
    • Speech recognition
      • può essere one-shot o continuus
      • funziona con Chrome (-webkit v25+)
      • grammar → per facilitare il riconoscimento
      • metodi: start, stop, abort
      • logica ad eventi eventi
      • mostra il risultato grigio se incerto, nero se considerato ok
      • si basa su Damerau–Levenshtein distance
    • Speech synthesis
  • Problemi dovuti a implementazione da parte dei browser

Evolution of Asynchronous Javascript

Concurrency Model + Event Loop: JS → message queue = eventi con funzioni da lanciare

JS non è “bloccante”

  • per avere blocco: callback  → problemi: callback hell, piramide of doom
  • Chiamate asincrone  → inversione di controllo, “perdita del control flow”, difficoltà gestione errori

PROMISES

  • Rappresentano proxy per un valore non ancora noto
  • Consentono di associare un handler al successo o insuccesso di un’azione
  • Permettono a metodi asincroni di restituire un valore: restituiscono una promise
  • Possono essere: pending, fullfilled, rejected, settled
  • Costrutti .then .catch
  • Problemi:
    • promises hell
    • non usabili per flow control
    • performance

GENERATORS

  • sono un nuovo tipo di funzione
  • Ritornano iterators observable
  • consentono
    • block
    • pull valori
    • push valori

GENERATORS+PROMISES

  • iterator attendono promises (resola or reject)
  • poi (then) riprendono il messaggio o generano un eccezione (throw) con il motivo

function *getdata() {
try {
let user = yield loadUser();
let cart = yield loadCart(user);
….
} catch(e) { …

ES2017

  • async/await

async function *getdata() {
try {
let user = await loadUser();
let cart = await loadCart();
….
} catch(e) { …

Game design principles

I concetti che vengono applicati alla progettazione e realizzazione di prodotti per l’intrattenimento (in particolare i giochi), possono essere di grande interesse, oltre che molto utili in generale in tantissimi ambiti.

La differenza è solo nella misura in cui applicare più o meno un concetto.

Durante la progettazione di un gioco bisogna tenere sempre presente da cosa è composto:

  • Regole
  • Obbiettivi
  • Condizioni di vittoria e di sconfitta
  • Conflitti
  • Interattività ed usabilità
  • Sfide

La differenza tra un prodotto (software) ed un gioco è che nel primo le difficoltà derivano dall’imitazione della realtà mentre nel secondo sono introdotte artificialmente.

Sono quattro le componenti da curare durante lo sviluppo:

  1. Estetica: ciò che colpisce l’utilizzatore.
  2. Storia: la sequenza degli eventi (o delle operazioni nel caso dei prodotti) è importante.
  3. Tecnologia: Il “motore” (l’engine per i giochi o la realizzazione software per i prodotti).
  4. Meccanica: Si intende l’attività principale che definisce la regole di utilizzo, le condizioni di vittoria e l’operatività/usabilità.

(Ci si rifà al modello di sviluppo MDA: Mechanics – Dinamics – Aesthetic )

Le quattro componenti di cui sopra devono essere unite da un tema, che rappresenta, ovviamente, il motivo per cui è stato creato il gioco/prodotto.

L’obbiettivo finale è: CREARE UNA ESPERIENZA MEMORABILE.

Sia nei giochi sia nei prodotti bisogna sempre tenere presente alcuni concetti importanti:

  • FOCUS: bisogna focalizzare l’attenzione dell’utilizzatore sia in generale, sia nel “punto” dove si è pensato. Questo consente a chi utilizza il software di apprezzarlo, mette enfasi sui punti forti del prodotto e riduce la visibilità di eventuali difetti.
  • BILANCIAMENTO: Questo è più importante per i giochi, ma ovviamente vale in parte anche per i prodotti. Si tratta di non rendere il gioco troppo difficile ma nemmeno troppo facile, così come troppo lungo ma nemmeno troppo corto. Bisogna sempre rimanere nella soglia tra la “noia” e la “frustrazione”. Ci sono diversi metodo di bilanciamento ma quello più utilizzato è tramite “gradini” (sogli di avanzamento che aumentano di volta in volta la difficoltà).
  • REWARDS: Ogni gioco deve dare delle gratificazioni al giocatore, sotto forma di “regali” o anche solo di feedback (dire bravo al giocatore è importante). Per i prodotti la gratificazione tendenzialmente è il fatto che l’utente sia riuscito a svolgere il compito in maniera semplice, veloce ed intuitiva e che quindi si senta bravo nell’utilizzo del software (e di conseguenza nel suo lavoro).

Nobody likes working with you

  • Tutti vogliono sentirsi importanti
    • Usa i nomi propri quando ti rivolgi alle persone
    • Ringrazia!
    • Dai fiducia
  • Non criticare
    • Dai feedback costruttivi
    • Non ti focalizzare sugli errori
  • Pensa a cosa vogliono le altre persone
    • Ascolta!
    • Tutti sanno qualcosa che tu non sai
  • Evita le discussioni polemiche
    • Non essere sempre in disaccordo
    • Non arrabbiarti
    • Cerca un terreno comune
    • Sii disposto a rinunciare
    • Al limite, posponi la discussione

Coding Culture

Cultura dell’innovazione
L’innovazione è fondamentale!!!
Bisogna dare agli sviluppatori il tempo per provare le loro idee.
Gli sviluppatori amano vedere le proprie idee realizzate
Le idee buone posso capitare a chiunque e in ogni momento, bisogna dargli la possibilità di crescere.

Cultura della felicità
Bisogna star bene con i propri colleghi

  • Costruire relazioni. Comprenderne punti di forza e di debolezza.
  • Bisogna celebrare i traguardi raggiunti!. Sia quelli grandi che quelli più piccoli

Bisogna comprendere il livello attuale di felicità

  • Fare dei “sondaggi” ma non in modo tradizionale e noioso.
  • Parlare con gli insoddisfatti per aumentare il livello di soddisfazione

Cultura dell’equilibrio
Gli sviluppatori creano software perché gli piace. Ma non bisogna dimenticarsi di rendere felici anche i clienti. Non bisogna mai dimenticare i clienti.
Serve passione verso il codice che si sviluppa. Il codice deve essere ingegneristicamente “bello”. Ma non bisogna essere troppo narcisisti in questo. Bisogna anche raggiungere gli obiettivi.

Cultura dell’essere squadra
Le persone devono stare e lavorare insieme.
Bisogna evitare la mentalità “a silo”. Evitare di lavorare in compartimenti stagni.
Bisogna cercare di conoscere i colleghi e farsi conoscere.
Bisogna ascoltare tutti.
Serve trasparenza.

  • La trasparenza aiuta nello stare insieme.
  • La trasparenza aiuta la diffusione della cultura

Tutto deve essere scalabile
Servono piccoli gruppi che siano in grado di cooperare.
I gruppi devono essere autonomi, trasparenti e ci deve essere fiducia tra di loro.
I gruppi devono avere la cultura del “fare”.
Ma devono poter “scalare” in base alla velocità di sviluppo.

Valori
Avere cultura significa avere dei valori.
Valori che vanno mostrati e ricordati a tutti.