5 novembre 2018
Intré Camp – 30 Ottobre 2018

Fine Ottobre, Halloween è dietro l’angolo, Natale è vicino, e il camp sta per iniziare 🙂
A questo giro siamo stati ospiti nella splendida cornice del castello di Casiglio, in quel di Erba.
C’è fermento nell’aria, voglia di stare tutti insieme per condividere idee e conoscenze, e allo stesso tempo divertirci.
Questo è il camp in Intré!

Dopo un accogliente benvenuto a base di caffè torte e pasticcini, Fabio ci ha richiamati all’ordine per dare inizio alla giornata con uno degli icebreaker già provati nei camp precedenti. Morra cinese, o forbice-carta-sasso 🙂

Di volta in volta, il vincitore della partita sfida il vincitore della partita della coppia a fianco, e lo sconfitto deve tifare per la persona che lo ha battuto.
Ad ogni iterazione quindi, ogni vincitore ha un seguito di persone sempre crescente, pronte a tifare per lui, sino allo scontro finale 🙂

Cosa emerge da questo icebreaker?
Il team, in ogni suo membro, deve essere sempre pronto a cooperare per raggiungere l’obiettivo, lavorando con determinazione e volontà.

Ognuno al suo posto, il camp sta per cominciare!

Introduzione

Francesco ha aperto ufficialmente la giornata con una sua presentazione.

Come è andato il 2018?
Intré è ulteriormente cresciuta sia in termini di fatturato,  nuovi collaboratori e branding (il nuovo sito è online 🙂 ).

Che cosa ci aspettiamo dal 2019?
L’intenzione è di non fermarsi, con ulteriori assunzioni (te che stai leggendo, vorresti far parte di un’organizzazione che apprende?) e l’avviamento di nuovi progetti.

Momento religioso
Il cristianesimo, come l’ebraismo, si poggiano sui 10 comandamenti, che ogni credente dovrebbe rispettare.
Ma la storia ci ha insegnato che l’uomo è ricorso all’adorazione di falsi idoli in momenti di sconforto (si pensi al vitello d’oro).
Secondo Francesco, anche uno sviluppatore ha un primo comandamento, e degli idoli da adorare.
Quali sarebbero questi idoli?

  • Loro non hanno le idee chiare
  • Non c’è abbastanza tempo per fare ciò che loro chiedono
  • Loro non hanno fatto test
  • Il pc non è abbastanza performante,
  • Colpa della lentezza della connessione di rete

Quindi?

Piuttosto che adorare questi idoli, o meglio incolpare sempre e comunque qualcuno o qualcosa, pensare diversamente. Anzi, inversamente (passatemi la parola).

SE C’E’ UN PROBLEMA, QUELLO L’HO PROVOCATO IO!

Ecco svelato il primo comandamento che uno sviluppatore dovrebbe seguire.

Ma non è semplice, secondo Francesco si dovrebbero abbandonare determinati atteggiamenti che vanno contro il comandamento, come ad esempio:

  • altezzosità
  • prepotenza
  • presunzione
  • senso di superiorità
  • superbia

In favore di altrettanti, quali:

  • modestia
  • semplicità
  • gentilezza
  • pazienza
  • attenzione
  • risolutezza
  • puntare all’obiettivo

E se ci pensiamo bene, non si tratta di compiere chissà quale sforzo. Dopotutto:

„L'uomo nella sua arroganza si crede un'opera grande, meritevole di una creazione divina. Più umile, io credo sia più giusto considerarlo discendente degli animali.“ - Charles Darwin

Open space

Fatta eccezione dello scorso camp di Giugno dove la mattinata fu dedicata ad interessantissimi workshop, solitamente la prima parte viene dedicata all’open space.

Un open space può essere visto come una conferenza organizzata al momento.
In una prima fase infatti, vengono proposti degli argomenti. Chiunque ne può proporre uno, collocando un post-it sul foglio di una flipchart dove è stata disegnata una griglia orari\spazi (solitamente 3 aule).
Ma non solo proposte, anche richieste di aiuto su qualunque argomento o tematica.
L’intento è ottenere 3 sessioni di talk di durata di 45 minuti l’uno.

Al termine di questa fase, ha luogo il market-place per organizzare al meglio le proposte in accordo con gli spazi a disposizione e preferenze.

A scapito del talk Appunti sparsi proposto da Giulio, è stato deciso di dedicare spazio al dry-run del talk Code is Law che Johan presenterà ai prossimi Italian Agile Days di Brescia 🙂

Mind maps drawing

Ecco un esempio di talk nato dall’esigenza di qualcuno di colmare lacune 🙂
Giulio infatti, su richiesta di Johan, ha organizzato una sorta di mini workshop sulle mappe mentali.

Che cos’è una mappa mentale?
E’ un modo per prendere appunti che siano comprensibili. Quante volte ci è capitato di scrivere un elenco puntato, piuttosto che scrivere informazioni in riquadri, collegandoli ognuno con frecce cercando di dare loro un senso?
Una mappa mentale può essere vista come un pattern da applicare per prendere appunti in forma grafica comprensibile in qualunque momento si voglia rileggere quell’appunto.

L’idea è partire scrivendo il topic principale al centro, e man mano scrivere i concetto chiave che estrapoliamo disponendoli in forma circolare, partendo dall’alto in senso orario. Da ogni concetto è possibile poi creare diramazioni.

Per farci meglio comprendere, Giulio ha chiesto ai partecipanti di dividersi in 3 sottogruppi, e provare a creare una mappa mentale che descrivesse Intré.
Muniti di carta e penna quindi, ci siamo cimentati dapprima scrivendo ognuno la propria mappa mentale, poi un breve momento con il resto del gruppo per concordare una mappa comune, e infine un confronto con Giulio e gli altri gruppi.

Oggi Giulio riesce a costruire sue mappe mentali su di un foglietto di una piccola agenda, ma è il risultato di tanti anni di pratica.
Il suo consiglio è quello di partire da normali fogli A4, e di sforzarsi ad utilizzarle non solo per prendere appunti durante presentazioni o meeting, ma anche per altri momenti della nostra vita di tutti i giorni.

Che cosa ci è piaciuto?

  • Rappresentazione grafica delle informazioni aiuta. E’ immediato
  • Semplicità legata all’utilizzo di singole parole
  • Sinteticità

Cosa non ci è piaciuto? Quali difficoltà abbiamo incontrato?

  • La difficoltà nell’avere sin da subito il quadro completo, ti porta a creare troppi rami. Aiutiamoci con una pre-mappa, con delle macro aree
  • Se siamo ad una conferenza, diamo un’occhio all’agenda per scrivere in anticipo gli argomenti principali nella mappa
  • Dare il nome giusto al ramo: è difficile, ma è una parte fondamentale di tutto il lavoro

Ammetto la difficoltà nel creare una mappa mentale concentrica, ma altrettanto ammetto l’utilità di avere uno schema logico che in un secondo momento, anche a distanza di anni, ti aiuta a recuperare velocemente informazioni su di un certo argomento.
Ora sta a me, fare pratica e lasciare che il mind mapping diventi la prima opzione.

Grazie Giulio!

Consigli utili per dominare il caos

Gianni, come la maggior parte di noi (e suppongo anche te, caro lettore), vive una quotidianità lavorativa dove il caos la fa da padrone.
Non importa che tu sia sviluppatore, manager, designer… diversi fattori portano il  caos nel nostro lavoro:

  • requisiti che cambiano frequentemente
  • idee poco chiare sulle attività di progetto
  • mancanza di test, sia unit test che integration test
  • mancanza di tester
  • mancanza del tempo
  • codice applicativo scritto male
  • story scritte male: poche righe, che inizialmente danno l’idea che sia facile, poi quando ci inizi a lavorare scopri che la mole e la difficoltà sono tutto fuorchè facili.
  • a volte si ha uno scontro di opinioni
  • competenze tecniche, magari carenti sul dominio applicativo o sul framework\tecnologia del progetto

Mi rendo conto, stiamo ricadendo proprio nella situazione dei falsi idoli dello sviluppatore descritta da Francesco nella sua presentazione… che azioni potremmo quindi intraprendere per mitigare alcuni di questi fattori?

Cosa possiamo fare noi sviluppatori a livello di team?

  • Potremmo condividere competenze, ciò potrebbe ridurre la probabilità di avere del codice scritto male.
  • Potrebbero essere utili delle linee guida da seguire per scrivere codice, di modo tale da non mettere in difficoltà noi stessi qualora dovessimo riprendere in mano quel codice a distanza di tempo, o nuove persone che entrerebbero a fare parte del team.
  • Code review: trovare quell’oretta di tempo per ragionare assieme su una certa porzione di  codice. Rivederlo, e magari cambiarlo.
  • In caso di refactoring\riscrittura di una porzione di codice, non scrivere anche solo un test minimale è impensabile.
    Almeno un test ci deve essere. Anche semplice, pensandolo in modo furbo (ad esempio, un test che accerta che la chiamata rest X  torni qualcosa). Magari anche relativo alla porzione di software che abbiamo modificato.

Ma questo cambiamenti, ad esempio sull’iniziare a scrivere test, devono partire da noi.

Ancora una volta, smettiamo di pensare che il problema sia sempre là fuori.

Il caos è una brutta bestia per tutti noi, ma smettiamo di temerlo e iniziamo a fronteggiarlo.
Stop scaring of, start fighting!

Kafka

Alberto e Alessandro hanno organizzato una presentazione su Apache Kafka, dapprima spiegandone l’architettura e fornendo i concetti principali (a cura di Alberto) e poi mostrandoci esempi pratici (a cura di Alessandro).

Che cos’è Kafka?

Apache Kafka è una piattaforma open source di stream processing scritta in Java e Scala e sviluppata dall'Apache Software Foundation. Il progetto mira a creare una piattaforma a bassa latenza ed alta velocità per la gestione di feed dati in tempo reale. Questo progetto viene usato principalmente per tutte le applicazioni di elaborazioni di stream di dati in tempo reale. - Wikipedia

Concetti principali dell’architettura Kafka:

  • topic: una sorta di categoria per raggruppare messaggi, composto da una o più partizioni
  • partizione: contenitore di un certo numero di messaggi. Possono avere dimensioni differenti; permette di rendere scalabile il sistema
  • record: l’insieme messaggio + key + timestamp; un record è inviato alla partizione, identificata da un offset
  • producer: processo responsabile dell’invio dei messaggi; diverse logiche di invio messaggi:
    • invio ad una precisa partizione tramite una precisa key; i messaggi con questa key saranno processati da uno più consumer
    • randomico, i messaggi vengono assegnati con una logica round-robin decisa dal broker
  • consumer: processo che legge il messaggio
  • gruppo: insieme di consumer
  • broker: processo che gestisce ricezione e salvataggio dei messaggi
  • cluster: insieme di broker
  • zookeeper: processo che monitora lo stato del sistema
  • Bilanciamento: sistema che garantisce l’equilibrio tra numero di partizioni e numero di consumer.
    Ad esempio: sistema 4 consumer, 3 partizioni. Quando un consumer si disconnette, Kafka riassegna le sue partizioni ad un consumer scarico. E’ importante gestire le partizioni. Ogni consumatore può avere minimo 1 partizione. Non ci possono essere un numero di partizioni superiore al numero di consumatori. Questo perché ci sarebbero consumatori che non ricevono messaggi.

Quanti concetti! Ma vediamo Kafka all’opera.

Dopo aver avviato un container Docker con Kafka, Alessandro ci ha mostrato come:

  • creare un nuovo topic, specificando zookeeper, quante repliche, quante partizioni, e il nome del topic
  • creare un producer: specifando l’url di Kafka e il topic sul quale mandare messaggi
  • creare un consumer: specificare il groupId, cioè il nome del gruppo, e nome consumatore

Il tutto eseguendo degli script di test forniti da Kafka. Ammetto pensavo fosse più complicato, in realtà basta parametrizzare opportunamente questi script, e il gioco è fatto 🙂

Alessandro ci ha mostrato alcuni comandi quali:

  • list <nome zookeeper>: comando per verificare la presenza di un topic
  • describe <nome zookeeper>: comando che dà ulteriori informazioni su di un topic
  • ottene la lista dei gruppi di consumer

Giusto per non farsi mancare nulla, Alessandro ha speso due parole su Kafka tool e Kafka Offset monitor, software utili per mostrare informazioni utili sul cluster.

  • Kafka offset monitor: avviato da browser web,  fornisce dettagli sui gruppi di consumer (esempio: broker, offset).
    Permette di vedere anche la lista di topic e una rappresentazione grafica (grafo) del sistema configurato
  • Kafka tool: simile a Kafka offset monitor, fornisce ulteriori informazioni come la lista di messaggi, le partizioni che li contengono.

Nei minuti (ahimè e ahinoi) finali di questa sessione, Alessandro e Alberto hanno realizzato piccole demo su:

  • sistema publish\subscribe con un producer e 2 consumer che ricevono contemporaneamente il messaggio. Hanno definito un topic di nome pubSub, i 2 consumer sottoscritti allo stesso topic, con attenzione sul groupId. Deve essere diverso per i 2 consumer.
  • coda: un topic, 2 consumer ma solo un solo consumer scoda i messaggi inviati, nonostante i 2 consumer abbiano uno stesso gruppo.

Dulcis (e che dolce!) in fundo, Alberto ed Alessandro ci hanno mostrato una loro piattaforma di trading basata su Kafka e microservizi 🙂

Gran bella sessione, grandi ragazzi!

Pranzo

Al camp rifocilliamo non solo lo spirito e la mente… anche il corpo 🙂

Serious game

Nel salone principale sono comparsi dei segni sul pavimento…delle griglie 5 x 7.
Che sta succedendo?!

Fabio ci ha riuniti tutti e suddivisi in 3 squadre.

L’obiettivo è che ogni membro del team deve completare un certo percorso sulla griglia, un passo alla volta, scoprendo di volta in volta il percorso corretto.

Le regole sono poche ma chiare:

  • il resto del team al di fuori della griglia, non può suggerire
  • il giudice deve notificare la correttezza o meno degli step sulla griglia
  • Ogni volta che si effettua un passo errato, bisogna tornare indietro e ripetere correttamente i passi all’indietro
  • vince il team che per primo completa il percorso. Tutti i membri devono completarlo

Che cosa emerge?

  • Il team deve collaborare per raggiungere l’obiettivo, anche pur rimanendo esterno al sistema.
  • E’ più facile agire all’interno del sistema, strategie fatte inizialmente, per quanto utili, possono essere cambiate in corso d’opera. Bisogna reagire al cambiamento.
  • Bisogna stare attenti alle specifiche che vengono fornite: una delle regole era NON SI PUO’ PARLARE, il che non vuol dire che NON SI PUO’ INDICARE IL PERCORSO CORRETTO. Attenzione!

Un gran bel momento, non solo di divertimento ma anche di apprendimento 🙂

Presentazione gilde

Come ogni camp, è arrivato il momento dedicato alla presentazione dei lavori delle ultime gilde:

  • Kubernetes
  • Blockchain
  • Studio di nuovi tool per la progettazione
  • Architetture
  • Free gilda

Prima di iniziare con le presentazioni, Francesco e Luca hanno introdotto una novità, nata da un’esigenza comune.
E’ difficile condensare in 15 minuti di presentazione un lavoro di studio di 4 ore settimanali svolto in 4 mesi.
Tanto si vorrebbe dire, mostrare e dimostrare. Come si può fare?

Gildonferenza

Nome scelto non a caso 🙂

Francesco e Luca hanno proposto un format di conferenza interno ad Intré, dedicata appunto alle gilde.
Tramite prenotazione del biglietto via Eventbrite, ognuno può prenotarsi per una delle gilde in essere.

L’idea è dedicare spazio a tutte le gilde, tramite presentazioni\mini workshop di  1 ora di tempo.

Bellissima idea, grandi ragazzi!

Kubernetes

Obiettivo di questa gilda è stato lo studio del tool Kubernetes:

Kubernetes (abbreviato K8s), è un sistema open-source di orchestrazione e gestione di container. Inizialmente sviluppato da Google adesso mantenuto da Cloud Native Computing Foundation. Funziona con molti sistemi di containerizzazione, compreso Docker. - Wikipedia

2 i motivi hanno portato la nascita di questa gilda:

  • La curiosità sulle potenzialità che il prodotto offre, e dall’esigenza di utilizzarlo in un progetto reale.
  • Trovare soluzioni alternative per semplificare i rilasci e la loro successiva manutenzione.

Nonostante le difficoltà legate ad esigenze di progetto, del lavoro è stato svolto:

  • studio del tool seguendo il tutorial
  • prove su cluster del progetto cliente
  • creazione cluster su Amazon Web Services
  • deploy di una app di chat in autoscale: in base al carico, la app scala le risorse

Che cosa è piaciuto di Kubernetes:

  • comodità nella fase di rilascio dei microservizi
  • è svincolato dall’hardware
  • facilità di accesso\modifica alle informazione del cluster

Che cosa non è piaciuto:

  • qualche bug presente 🙂
  • alcuni tool che vengono messi a disposizione, come la dashboard, sono ancora acerbi
  • instabilità ereditate dal cloud su cui si appoggia (Microsoft Azure)

Blockchain

Obiettivo di questa gilda, al quale ho fatto parte. è applicare la blockchain di Ethereum, ad un progetto reale.

Il progetto in questione è I3-WAY, una applicazione, realizzata in AngularJs dal collega Fabio, che permette a qualunque collaboratore di Intré di segnare un appuntamento in un calendario visibile da tutti gli altri, di modo tale appunto da sapere chi è dove (Where Are You :)).

Un pò come per i colleghi della gilda Kubernetes, anche noi abbiamo trovato delle difficoltà legate al tempo da trovare per lo studio, ma siamo comunque riusciti nell’intento.

In che modo?

Sfruttando la nostra blockchain Ethereum oggetto di studio della scorsa gilda blockchain, abbiamo realizzato l’integrazione con I3-WAY creando un database contenente i riferimenti alle transazioni.
Una transazione è la memorizzazione sulla blockchain delle informazioni relative all’appuntamento tramite uno smart contract, con il conseguente vantaggio dato dal fatto che tali informazioni possano essere recuperate in qualsiasi momento (ogni membro della blockchain ha una copia aggiornata della blockchain)

Il lavoro quindi svolto è stato:

  • Modifica database
  • sviluppo di un semplice smart contract
  • sviluppo server in Node.js per la gestione degli smart contract
  • modifiche lato front-end per mostrare le informazioni relative allo stato della transazione nella blockchain
  • modifiche lato front-end per l’aggiunta della funzionalità di verifica dei dati in I3-WAY con quelli memorizzati sulla blockchain

Ciò che ci è piaciuto è apprendere ulteriore conoscenza su questo mondo sempre più parte della nostra quotidianità, e la consapevolezza di aver realizzato un modulo completamente slegato dal contesto applicativo. Oggi lo abbiamo applicato ad I3-WAY, domani…chissà 🙂

Studio di nuovi tool per la progettazione

I nostri colleghi designer si sono dedicati ad una gilda di ricerca e studio di tool in grado di migliorare le performance legate ai flussi di lavoro interni e gestione dei sorgenti.

Rifacendosi al modello Design Eye, vediamo quindi le aree di interesse toccate e quali tool sono stati considerati:

  • Ricerca:
    tool: Google Forms come strumento per questionari\interviste
    Pro: template facilmente declinabile alle esigenze
    Problemi risolti: Ricevere risposte da remoto (paesi differenti)
  • Sviluppo
    • wireframe
      tool: Adobe XD: gestione simboli e font icon; anteprima diretta su device
      Problemi risolti:

      • lentezza tool usati
      • molti elementi da riutilizzare
      • conversione macchinosa da wireframe ad interfaccia
      • rischio di incoerenze dello stesso elemento in schermate diverse
      • difficile individuazione di asset da riutilizzare (ad esempio icone)
      • assenza di un’anteprima web
      • conversione macchinosa da interfaccia a prototipo
      • impossibilità di riprodurre nel prototipo alcune interazioni
    • condivisione specifiche e asset
      tool: Zeplin
      Utile per la generazione automatica specifiche ed asset; generazione automatica snippet e css
      Problemi risolti:

      • difficoltà e lentezza nel trasmettere misure e altre specifiche al team di sviluppo
      • condivisione asset non immediata
    • html\css
      tool: Sass
      Linguaggio che fornisce un modo efficiente di organizzare il codice css con uso di variabili e componenti.
      L’idea è utilizzare uno starter kit creato, per evitare ogni volta di partire da 0.
      Problemi risolti:

      • assenza organizzazione in file e cartelle e convenzioni sul naming
      • assenza codice base di partenza all’inizio dello sviluppo
      • organizzazione di file e cartelle diversa da persona a persona
      • rischio di incoerenze dello stesso elemento in porzioni di codice diverse

Architetture

Obiettivo di questa gilda, lo studio e l’applicazione di alcuni pattern architetturali per lo sviluppo software.

Come ci si è organizzati?

  • scelta di quali architetture studiare
  • ricerca di documentazione su ognuna delle architetture scelte
  • creazione delle  sezioni su Draw.io
  • esercitazione con schemi basati su kata architetturali
  • realizzazione del tic-tac-toe, nome anglosassone del gioco del tris

Architetture scelte:

Per ogni tipologia di architettura, il modus operandi è stato il seguente:

  1. Raccolta documentazione
  2. Kata architetturali: esercizio su come disegnare l’architettura per un certo progetto
  3. Sviluppo del gioco tic-tac-toe applicando l’architettura presa in esame

Ogni membro della gilda ha appreso molti concetti relativi alle architetture, sono stati considerati positivi i diversi momenti di confronto avvenuti durante le esposizioni delle idee, e l’aver imparato a giocare a tic-tac-toe, alle volte perdendo contro il software da loro sviluppato 🙂

Freegilda

Una gilda incentrata su tanti piccoli argomenti.

Una gilda diversa dalle altre, nata con lo scopo di colmare lacune su argomenti troppo piccoli per essere oggetto di uno studio di 4 mesi.

Come si sono organizzati i componenti del team per tenere traccia delle attività?

Usando una semplice board su Trello

Quale è stato il modus operandi?

  • backlog iniziale
  • punto della situazione, quando serve
  • nella wiki interna, aggiornamento di un journal
  • studio e produzione di un output

Ma quale può essere l’output di una gilda che studia diversi argomenti?

  • pubblicazione di un articolo
  • presentazione di un talk ad una conferenza
  • workshop
  • presentazione interna
  • tutorial online (video)
  • progetto con codice funzionante pubblicato su Gitlab

Che argomenti\progetti hanno trattato?

Possiamo dire che la freegilda è piaciuta e molto probabilmente continuerà a piacere? 🙂

Nuove gilde

Terminato la presentazione delle nuove gilde, si è passati alla fase di definizione delle nuove gilde.

Francesco, supportato da Luca, ha munito di carta e penna ognuno di noi e lasciato del tempo per pensare a idee e proporle.

Dalle svariate proposte iniziali, si è necessariamente dovuto fare una scrematura.

Spiace per coloro che si sono visti bocciare la proposta (ritentate, sarete più fortunati :)), ma per il futuro prossimo le gilde saranno:

  • freegilda 2.0
  • Let’s make a videogame
  • Design for emotions
  • Progressive web-apps

Per ulteriori dettagli, continuate a seguirci 😉

Conclusione

Come abbiamo iniziato, è stato giusto concludere.

Fabio ha riproposto l’icebreaker che riscosse successo e divertimento al camp di Ottobre del 2017.

Tutti riuniti in cerchio, scopo del gioco è contare ad alta voce un numero a testa, partendo da 0, applaudendo anziché parlare ogni volta che si arriva ad un numero suddivisibile per 3 o contenente il numero 3. Chi sbaglia, esce dal cerchio. E si riparte.

Il gioco termina quando rimangono 3 persone in gioco 🙂

E’ davvero tempo di saluti ora, arrivederci al prossimo racconto di questa fantastica giornata assieme 🙂

Tag
Intré Camp – 26 Giugno 2018

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Agile Venture Prato 2018

Il racconto della giornata della prima edizione di un agile venture in quel di Prato.

A reactive programming example
Milan Kotlin Community Conf

The first Kotlin related Italian conference made from the community to the community!

Let's see how was it...

DroidCon IT, Turin, 19 & 20 April 2018: our report
Milan Kotlin Community Conference

How, why and what has lead us to the Milan Kotlin Community Conference.

Intré Camp – 13 Febbraio 2018

Racconto del camp aziendale svoltosi a Pontida, agriturimo Polisena

Vert.x – 4o articolo su Mokabyte!

4o articolo sul mondo Vert.x a cura di Marco

Vert.x – 3o articolo su Mokabyte!

3o articolo sul mondo Vert.x a cura di Marco

NoSlidesConf 2017

NoSlidesConf: una conferenza diversa dal solito

Vert.x – 2o articolo su Mokabyte!

2o articolo sul mondo Vert.x a cura di Marco

Vert.x – 1o articolo su Mokabyte!
IAD Urbino 2017 – Conferenza 18 Novembre

Racconto della conferenza presso l'università degli studi Carlo Bo di Urbino

IAD Urbino 2017 – Unconference 17 Novembre

#IAD17: Racconto della giornata di unconference presso l'Università degli Studi Carlo Bo di Urbino

Intré Camp – 5 Ottobre 2017

Racconto del camp aziendale svoltosi all'agriturismo La Camilla

Intré Camp – 18 Maggio 2017

Resoconto del camp aziendale svoltosi all'Oasi di Galbusera Bianca

CloudConf Torino 2017

CloudConf 2017 a Torino. Come è andata?

Mini IAD Vimercate 2017

Il racconto della giornata al Mini Italian Agile Day tenutasi a Vimercate.

Codemotion Milano 2016

Nel week-end del 25-26 novembre 2016 si è svolto il Codemotion Milano 2016.
Francesco Sacchi e Ferdinando Santacroce ci raccontano com'è andata.

Angular Conf 2016

Il racconto della nostra giornata alla Angular Conf 2016 a Torino, sia come spettatori e soprattutto come sponsor.

Intré Camp – 3 Novembre 2016

Un racconto di come è andata la nostra giornata di team building, tra sorrisi e battaglie ;)

Node.Js Italian conference – V edition

Cronistoria sulla nostra partecipazione alla 5^ edizione della Node.Js Italian Conference, con tante belle foto, stickers e...leggete :)

Business24 TV: Fabio Ghislandi presenta Intré

In questo breve intervista viene presentata Intré e il suo innovativo approccio allo sviluppo di software.

Come cambia il mondo dei linguaggi
WebRTC – #1 Video-Chat in javascript

Con la tecnologia WebRTC (Real Time Communication www.webrtc.org) è possibile integrare, all’interno di applicazioni che comprendono javascript, funzionalità di audio e video-chat, registrazione chat, condivisione schermo e signaling.

Future e Promise in Scala

Primo post sulla programmazione in Scala dedicato a future e promise, due costrutti fondamentali per la programmazione concorrente.

Come inviare dati live da un’applicazione C# Desktop al web usando le WebSocket

Questa è una guida passo passo su come esporre dati live da un'applicazione C# console ad un web browser usando le WebSocket. L'esempio è stato testato su Windows 7.

IOS Push notifications iOS 6 con Sencha Touch 2.2

Se state cercando di inviare una Push Notification al vostro iOS6 iPhone/iPad usando Sencha Touch 2.2 probabilmente avrete incontrato diversi problemi. In questo articolo vedremo passo passo come configurare i certificati, impostare il file Sencha package.json ed inviare una push notification con uno script PHP o C#.

Creare una issue in Jira con i sub-task predefiniti

E' possibile programmare script in Atlassian Jira usando Groovy. Questi script possono essere eseguiti allo scattare di un evento come alla creazione di una issue o al suo aggiornamento. Sfruttando questo principio vediamo come creare uno script che crea i sub-task in automatico alla creazione di una Issue.

Lego controllato con Cloudfoundy via WebSockets

Questo è un breve test di come è possibile controllare Lego Mindstorm con Cloudfoundry usando HTML5 e WebSockets.

Beaglebone how-to. Come cambiare lo stato di una pagina web premendo un pulsante con node.js

Questo articolo descrive come intercettare l'interrupt GPIO di una beagle bone e aggiornare, via web sockets, una pagina web usando node.js.

youSCADA presentato al Graphical Web 2012

Come controllare e monitorare i device usando una piattaforma Cloud? La soluzione è stata presentata al Graphical Web 2012 a Zurigo.

Chiamare una REST API con node.js

Node.js sta rivoluzionando il modo di programmare le piattaforme software. Basato sul Google V8 JavaScript Engine permette di scrivere codice lato server in JavaScript.

Top
Ogni nostro Sprint ha l'obiettivo di massimizzare il Valore per l'utente finale
Il tuo browser non è aggiornato!
Aggiornalo per vedere questo sito correttamente.Aggiorna ora

×