Milan Kotlin Community Conference
How, why and what has lead us to the Milan Kotlin Community Conference.
Eccoci qua, dopo 4 mesi, tutti riuniti per una nuova ed interessante giornata di camp.
La location, o lochescion dipende da come siete abituati :), è stata la bellissima cornice dell’agriturismo Polisena a Pontida, immersi tra colline e verde.
Posati borse, zaini, scatoloni (sì, pure scatoloni, sorpresa in vista 🙂 ) ci siamo ritrovati in una delle sale a noi dedicate dove Fabio ci ha accolto.
Questo il programma della giornata
Come ogni camp che si rispetti, tutto non può iniziare senza un buon caffè di benvenuto, a base di torte, spremute e soprattutto… Senza ice breaker!!
E chi se non Fabio poteva condurre, anzi dirigere l’attività… Sì, dirigere, come un buon direttore d’orchestra dovrebbe fare.
E il coro?
Il coro siamo stati noi, suddivisi in 3 gruppi, ognuno dei quali doveva canticchiare una strofa composta da frutti 🙂
3 gruppi, responsabili di canticchiare rispettivamente:
Vi risparmio i contenuti audio perché vi si vuole bene cari lettori, devo però ammettere che il risultato finale non è stato male.
#piccolocorodellantonianoscansati, giusto per sintetizzare con gli hashtag 🙂
Ugole scaldate, diamo voce a questo camp!!
Francesco ha ufficialmente aperto la giornata presentandoci attraverso alcune slide l’andamento dell’ultimo anno. Una metafora molto azzeccata, quella della scalata di in cordata, ha permesso di allineare tutti in merito al percorso di crescita dell’azienda: aiutiamoci, il percorso è ancora lungo, di strada ne abbiamo fatta, siamo in alto ma l’obiettivo è la cima!
Parola a Nando ora, o Ferdinando per gli amici :), che ci spiega le regole e i principi di una open conference.
Ma che cosa proporre ad una open conference?
C’è una sola legge, la LEGGE DEI 2 PIEDI: andiamo dove possiamo trarre / apportare valore, e 4 principi:
Questo il programma
I post-it che vedete al di fuori della griglia sono proposte purtroppo non entrate in programma: vi assicuro che avrebbero meritato eccome!
Come i calabroni e le farfalle, spostiamoci di stanza in stanza, trasportando in questo caso informazione e conoscenza 😊
Andrea, prodotto del vivaio aziendale (coltiviamo talenti nella nostra Hackademy 🙂 ) ha voluto proporci un sunto del suo lavoro di studio su tutte quelle buone pratiche che ogni programmatore dovrebbe fare sue, comunemente riassunte nelle parole Clean Code. A tal proposito, qui potete acquistare il sacro testo.
Nel tempo a sua disposizione, Andrea ha dapprima spiegato quanto sia importante la manutenzione del codice, sottolineando come statisticamente l’80% del lavoro di un programmatore è mantenere codice già scritto. Per cui, tanto meglio lo si scrive, tanto meno poi si deve investire in tempo e risorse per mantenerlo.
Andrea ha quindi spiegato alcuni principi di Clean Code, oggetto di capitoli nella bibbia sopra citata:
Molti altri principi di clean code Andrea ci avrebbe spiegato, ma vuoi il tempo tiranno, vuoi che in aula più volte si è acceso un sano dibattito tra i partecipanti (tra cui il sottoscritto)… è andata molto bene così!
Grazie Andrea, lavoriamo sempre duro per mantenere il codice sempre più pulito di come lo troviamo 🙂
#siamotuttiboyscout
Qui potete scaricare le slide dell’intervento.
Francesco ha un conto in sospeso con Javascript, e in questo talk ha voluto spiegarne le ragioni.
Javascript ha la fama di essere poco coerente e pieno di scelte implementative dubbie o controintuitive.
Oltre ai classici post sulle operazioni aritmetiche tra numeri e stringhe, alcuni esempi sono le keyword new e this.
Queste sono ottimi candidati a creare confusione in quanto hanno un significato ben definito in tutti i più famosi linguaggi object oriented, e in particolare Java, da cui Javascript ha preso ispirazione per parte della sintassi.
In Javascript però, non essendoci classi, istanze, metodi, costruttori, queste keyword devono avere necessariamente un significato diverso da quello che ci aspettiamo, deludendo quindi le nostre aspettative e creando frustrazione.
Alcuni altri aspetti, come i prototypes e la gestione dell’asincronicità, sono invece tipici di javascript e richiedono quindi uno sforzo diverso per imparare ad usarli.
Di fronte a queste differenze abbiamo due vie: cercare di aggirarle e far funzionare il codice, oppure capire come funziona veramente il linguaggio capendo le differenze e usandole a nostro vantaggio.
Francesco ha chiuso il suo intervento lasciandoci un ottimo spunto (nonchè gratuito) per migliorare e approfondire la conoscenza di javascript.
You don’t know JS? This is the answer.
#conosciamomegliojavascript
Mantenere e continuare a sviluppare legacy code è un lavoro complesso e frustrante, perché spesso i bug che correggiamo si ripresentano oppure generano altri bug.
Avete capito l’argomento trattato da Gianni :).
Come affrontarli?
E’ necessario assumere un atteggiamento positivo e propositivo che permetta di apportare miglioramenti reali e cost-effective al software e trasformare in energia positiva i sentimenti negativi dello sviluppatore che si approccia all’analisi e soluzione del bug!
Ok, ma come fare e da dove iniziare?
Analizzare il codice con metodi alternativi permette di individuare dove e come intervenire, mentre le tecniche di eXtreme Programming ci permetteranno di estirpare i bug alla ridice e migliorare la nostra code-base. Analisi del problema, comprensione della causa e sua risoluzione, cercando di applicare i valori e i principi del Manifesto Agile e puntando alla Eccellenza Tecnica sono la via da percorrere.
Vedere i bug come occasioni da sfruttare per migliorare la code-base e i processi di test, delivery e deploy porta a un aumento nelle nostre motivazioni e soddisfazioni inaspettate!
#ilbugpuòessertiamico
Ammettiamocelo, blockchain, cryptovalute, Bitcoin… Tutti termini sulla nostra bocca, ma quanto realmente ne sappiamo?
Io, e per fortuna non solo io, sono arrivato a questo camp con l’intento di cercare di capirne di più, avere un confronto costruttivo. Il talk di Johan è proprio cascato a fagiuolo 🙂
Il termine blockchain è composto dai termini:
Le transazioni viaggiano su una catena di blocchi appunto, e l’oggetto della transazione (moneta, dati sensibili, qualunque cosa) è criptato con un hashcode. Il blocco va inteso come un dado particolare, con 3 facce:
Una transazione, per essere considerata valida, deve appunto deve essere validata dal 51% dei nodi della rete. Provare ad alterare il dato di un blocco, appunto per provare a recuperare il dato, è molto complesso e porterebbe al ricalcolo dell’hashcode, invalidando il blocco e quindi rompendo la catena!
Per questo entrano in gioco delle regole di sicurezza che si basano sul consenso e sul proof of work. Minare, come si dice, cioè cercare di recuperare l’informazione da uno di questi blocchi significa cercare di recuperare la chiave, il che è un’operazione che richiede grande potenza di calcolo ed elettricità, dal momento in cui le macchine sul quale si cerca di fare questa attività di mining dovrebbero rimanere accese e lavorare per un lunghissimo periodo. Non è un caso che si dice appunto minare il bitcoin…
Johan ci ha poi mostrato un piccolo esempio di codice che realizza una blockchain, scritto in Node.js, con tanto di metodo per il calcolo dell’hashcode e mining del blocco.
Per chi volesse saperne di più, qui potete trovare sia le slide che il codice della Blockchain implementata e mostrata alla demo.
Bravo Johan e grazie, ci hai rischiarato le idee 🙂
#blockchainnontitemiamo
Damiano ha riproposto il talk tecnico su Java e la sua evoluzione lungo le varie versioni che aveva portato allo scorso camp aziendale.
Qui potete trovare quanto riportato sul talk, all’epoca intitolato Java++
#avolteritornano 🙂
In questa sessione Nando ha proposto un confronto sul tema del disegno a mano libera.
Ogni collaboratore di Intré, designer, sviluppatore o esperto di sistemi che sia, è un “lavoratore della conoscenza”: il suo pane quotidiano è la gestione delle informazioni, continua acquisizione e trasmissione. A causa di questo, nella quotidianità lavorativa può capitare di voler esprimere le proprie idee attraverso uno schema, un fumetto, o una generica rappresentazione grafica di concetti.
Acquisire manualità nel disegno a mano libera non è facile, ci vuole tanto allenamento; scopo di questo momento quindi è stato quello di condividere strategie e tecniche per accelerare l’apprendimento ed imparare il prima possibile come rappresentare semplici forme e concetti.
Si è scoperto che nessuno dei partecipanti avesse uno specifico percorso di studio alle spalle; nonostante questo, sono emersi interessanti trucchetti ed approcci per superare lo scoglio della scarsa manualità. Ad esempio si è visto come rappresentare forme complesse componendo delle forme semplici come triangoli, quadrati e cerchi; si è concordato sul fatto di utilizzare convenzioni note per esprimere concetti di base (ad es. un semaforo verde per indicare qualcosa di consentito, ed uno rosso per qualcosa di vietato).
Nell’ultima parte di questo incontro, i partecipanti si sono divertiti un po’ a rappresentare semplici situazioni: dopo una prima fase di scrittura proposte su un foglietto, a turno ogni ognuno ha pescato una tra le proposte, e disegnato per 2 minuti mentre gli altri cercavano di indovinare. Sì, Pictionary insomma 😊
E’ stato un bel momento, divertente e istruttivo!
#pictionarynonèsoloungioco
Altro talk nato dalla richiesta di aiuto da parte di qualcuno 🙂
Johan e altri colleghi si sono trovati con l’intento di chiarire le idee sul mondo del machine learning e vedere alcuni esempi (tra cui la tesi di laurea di Giulio).
Malgrado il poco tempo a disposizione, questo incontro ha aiutato i partecipanti a meglio comprendere i difficili algoritmi che entrano nel merito di questa disciplina.
In poche parole si è giunti alla conclusione che la difficoltà maggiore non sta tanto nell’algoritmo scelto (sono disponibili diverse librerie che li implementano) quanto nel reperire la mole di dati da elaborare e nel tempo richiesto per elaborarli.
#ilproblemastaneldato
Marco ha voluto discutere sull’annoso problema del legacy code, o debito tecnico (peraltro oggetto di capitolo del libro Clean Code).
Come dobbiamo comportarci quando abbiamo a che fare con codice scritto da altri? E’ corretto lamentarsene a priori? Noi siamo effettivamente più bravi e quindi nella posizione di poter criticare?
Forse dovremmo assumere un atteggiamento diverso, magari più costruttivo e quindi lavorare su tale codice al fine di migliorarlo.
Ricordiamoci della regola del boyscout: come un bravo boyscout dovrebbe lasciare l’ambiente migliore di come lo ha trovato, un bravo programmatore dovrebbe lasciare il pezzo di codice migliore di come lo ha trovato 🙂
Ognuno di noi è soggetto a scrivere del codice legacy, quindi come poter evitare, o meglio, far sì che sia il più possibile mantenibile e quindi meno criticabile?
Sfruttare alcune tecniche come il pair programming, fare refactoring frequente e confrontarsi spesso con il team.
Adottare il test driven development (TDD) quando scriviamo codice per nuove funzionalità, adottare assieme al team alcune regole e principi di programmazione tali per cui sì, all’inizio comporta più lavoro e sforzo per tutti, ma sicuramente nel tempo riduce il debito tecnico.
E’ stata un’interessante discussione, ognuno ha portato esempi dalla propria esperienza e questo ha portato diversi spunti per come migliorarsi tutti.
#uniticontroillegacycode
Specteex è un chatbot che permette a team delocalizzati di fare retrospettive da remoto.
Gianni ed Emanuele hanno realizzato un “wizard of Oz” per testarne la sua efficacia proprio durante uno degli slot del mattino. Il wizard of Oz è una tecnica di test di un prototipo, in cui si simula l’interazione dell’utente con il sistema attraverso un operatore nascosto che interpreta il sistema stesso. L’utente crederà di interagire con un sistema implementato, ma in realtà le risposte che riceverà sull’interfaccia sono inserite dall’operatore stesso.
Il test ha mostrato delle buone prospettive di successo per il futuro, facendo emergere anche alcuni punti deboli.
Il progetto proseguirà all’interno di un’altra gilda.
Emanuele ha voluto raccontarci l’evoluzione del processo di brandizzazione aziendale.
Intré ha un logo, ha un monogramma, simboli che aiutano a distinguere l’azienda tra le altre. Loghi che dovrebbero essere pensati anche per tutte le attività che vengono svolte:
Anche i punti di contatto che Intré ha con l’esterno, o meglio touchpoint, contribuiscono alla definizione di un brand.
Ad ora abbiamo diversi touchpoint:
Tutti elementi che sì aiutano a definire un brand, ma che ancora può essere migliorabile secondo Emanuele, per ancor meglio definire chi siamo, cosa facciamo 🙂
Come fare quindi per migliorare?
Un’altra idea di miglioramento del brand è la realizzazione di un metabrand, che sia personale e che in qualche modo ci identifichi.
Ognuno di noi ha un nickname dato dalle prime 3 lettere. Siamo tutti sviluppatori e designer, cosa potrebbe produrre l’incontro tra un designer e un programmatore? Dopotutto dietro ad un’interfaccia, un qualunque software back-end o front-end, ci sono 1 e 0…
Rifocillati dal pranzo e goduto del bel panorama offerto dalla terrazza dell’agriturismo, è giunto il tempo di presentare i lavori delle gilde definite all’ultimo camp del 5 Ottobre:
A rompere il ghiaccio siamo stati noi cavalieri della gilda Kotlin. Io, assieme a Damiano (candidato come presentatore del nostro lavoro), Ferdinando, Francesco, Fabio e Fabio abbiamo pensato di non preparare slide, bensì una demo live. Dopotutto Kotlin è un linguaggio di programmazione, e come tale va presentato mostrandolo per quello che è, righe di codice 🙂
Armato di istanza di IntelliJ (sì, Kotlin è sviluppato, come peraltro come IntelliJ, da quei bravi ragazzi di JetBrains ), ha dato una breve ma significativa dimostrazione dei vantaggi che si avrebbero nel passare da un codice scritto in Java ad uno scritto in Kotlin.
Vorrei essere onesto con voi, per quanto descritto prima, tramite IntelliJ si può effettuare questa operazione Java -> Kotlin conversion con una semplice opzione messa a disposizione, quindi sì, Damiano ha fatto vedere ciò ma è proprio da questo punto in poi che si è entrati nel vivo della dimostrazione.
Come esempio abbiamo preso un pezzo di codice che definisce un backlog, composto da qualche sprint, ognuno a sua volta composto da story con assegnatario, titolo e stima. Potete immaginare quindi come possa essere facile scrivere del codice verboso in questo caso.
Siccome il tempo a disposizione non era granchè, ci siamo preparati di una serie di commit ad hoc (w Git) per mostrare man mano come il codice kotlinizzato potesse e dovesse essere reso il più chiaro e leggibile possibile, sfruttando appunto il linguaggio Kotlin.
Grazie all’uso delle extension function, data classes e altre ottimizzazioni di codice permesse grazie ai costrutti e sintassi di Kotlin, Damiano ha mostrato come la versione finale del codice di implementazione di un backlog fosse praticamente uguale ad un oggetto Json, un elenco di attributi e proprietà leggibile e comprensibile anche a chi non conosce il linguaggio 🙂 Ovviamente funzionante ed eseguibile!!
Prima di chiudere la presentazione, Nando ha ricordato giusto una robetta… Organizzeremo la prima conferenza italiana su Kotlin!!!
#nientediserioingilda
P.S. per arrivare a realizzare una presentazione live con Kotlin, ringrazio lo sforzo impiegato da tutti i componenti della gilda, impegnati in ore di kata e TDD su esercizi come Roman numbers converter e Game of life
Ecco il turno dei nostri “nemici”, coloro i quali hanno deciso di studiare un altro linguaggio di programmazione molto interessante, Go!
Claudio, assieme ad Alex Marina Lorenzo Alberto Giulio Johan Luca e Gopher 🙂 hanno organizzato il loro intervento in 2 parti.
La prima parte relativa ai motivi che hanno spinto allo studio di questo linguaggio. Go, come Kotlin, è un linguaggio di programmazione relativamente giovane (prima versione di Go datata 2012, Kotlin nel 2011), pensato per sviluppo del backend di web-app, sviluppo di applicazioni da riga di comando (basti pensare che Docker è stato sviluppato in Go). Non adatto se si vuole sviluppare la grafica, o meglio il front-end di applicazioni.
La presentazione è proseguita spiegando il modus operandi tenuto per gli incontri di studio, gli esercizi svolti (TDD e kata), e il progettino finale oggetto poi della seconda parte della presentazione, ovvero una chat da riga di comando, chiamata i3Talk
E’ stato molto interessante vedere live la creazione di 4 utenti (1 per ogni istanza di riga di comando) in una chat che ricevono un messaggio in broadcast, e vedere un esempio di comunicazione tra 2 di questi utenti.
I ragazzi di Go hanno poi chiuso la loro presentazione spiegando quali secondo loro fossero i punti di forza e di debolezza del linguaggio, dandoci l’arrivederci per la prossima Goliardata 🙂
Qui potete scaricare la presentazione.
#goliardiciebravi
Daniele, Marco, Carlo, Carlo, Riccardo e Francesco ci hanno presentato il loro lavoro di studio su Docker, con l’obiettivo di imparare e comprenderne al meglio le potenzialità, contestualizzare Docker nei processi Intré e non solo 🙂
Ma…che cos’è Docker? Ce lo spiega Marco.
Docker è un software opensource, leggero (non occupa molto spazio installarlo su disco) che permette di eseguire singoli processi in ambienti isolati chiamati container. Aiuta sia noi sviluppatori che sistemisti fornendo la possibilità di creare\eseguire immagini contemporaneamente o meno (in base all’esigenza) via docker compose.
Marco ha poi spiegato brevemente l’architettura di Docker, e come siano arrivati ad imparare a gestire container Docker.
E come contestualizzare Docker nei processi Intré?
Nel suo tempo a disposizione, Daniele ci ha spiegato come poter accedere ai container Docker. Degno di nota l’utilizzo di Portainer.io come interfaccia di gestione immagini Docker, e Harbor (by VMware) per la gestione del registry delle immagini Docker aziendali.
Ultimo ma non per questo meno importante, Carlo ha spiegato il progetto scelto dal gruppo come caso d’usoper integrare Docker.
Grazie amici scaricatori di porto, presentazione molto divertente nonchè utile la nave Docker è pronta per il varo 🙂
#dockerspacca
E’ arrivato il turno della gilda dei nostri colleghi designer. Con un intruso, se così si può definire 🙂
Emanuele ha curato una breve introduzione spiegando quale fosse l’obiettivo della gilda, e cioè accrescere le conoscenze teoriche e pratiche sulle nuove tecnologie (da qui il nome DeLorean, richiamo della mitica trilogia cinematografica Ritorno al Futuro).
Modus operandi comune ai 3 mini gruppi è stata la modalità di lavoro, composta da 3 fasi:
Prima di lasciare la parola alle presentazioni dei progetti, Emanuele ci ha spiegato ciò che si è appreso da questa esperienza
Valentina e Matteo si sono occupati di realtà virtuale, presentando dapprima il loro lavoro di ricerca (tecnologie disponibili, campi di applicazione…) e soprattutto Aclumate (dal greco aclus = oscurità e dall’inglese mate = amico), una applicazione che si prefigge di aiutare tutte quelle persone, adulte e no, che vorrebbero sconfiggere la paura del buio.
Come anticipato da Emanuele, Valentina e Matteo ci hanno illustrato come hanno applicato la vision board, product canvas, business model canvas e soprattutto 2 user journey di un bambino prima e una ragazza poi.
Ulteriori dettagli potete trovarli scaricando la presentazione.
#combattiloscuritaconaclumate
Diego e Roberto hanno approfondito le loro conoscente sulla realtà aumentata, che per certi versi può essere vista come simile alla realtà virtuale.
La differenza è nei casi d’uso e conseguente implementazione.
La caratteristica principale della realtà virtuale consiste nella creazione di una realtà immersiva completamente alternativa a quella che ci circonda nel quotidiano. Un visore isola completamente dall’ambiente circostante.
Parlando invece di realtà aumentata, Internet e GPS possano confluire assieme per dar vita a dispositivi in grado di “aumentare” o arricchire soprattutto a livello di informazioni, il mondo che ci sta davanti.Ed è proprio questa la differenza fondamentale, perché i visori di realtà aumentata non prevedono l’isolamento totale dall’ambiente, al contrario necessitano invece che l’utente mantenga il contatto visivo con esso.
Roberto ha spiegato il progetto scelto, e cioè Arssistant, fusione tra augmented reality e assistant, cioè l’assistente che si può trovare in aereoporto.
L’idea infatti è una applicazione che aiuti chiunque viva poco serenamente, o con una insicurezza dovuta all’inesperienza, i momenti di attesa prima di un volo. Arssistant fornisce tutte le informazioni necessarie per condurre l’utente al gate corretto, piuttosto che informazioni sull’orario del volo o il numero dell’aereomobile.
#nostressconarssistant
Gianni ed Emanuele si sono occupati dello studio prima e realizzazione poi di Specteex, chatbot che come scopo ha l’aiutare un team nella configurazione e creazione di una board per la fase di retrospettiva di un progetto.
In questo articolo avete già letto in merito di Specteex, oggetto di uno dei talk durante la open conference, ma qui potete trovare ulteriori dettagli in merito al lavoro di ricerca e di progettazione svolto dai 2 colleghi.
#magodioz
Terminate le presentazioni delle vecchie gilde, sotto con la proposta di nuove gilde!
Francesco ha moderato il momento concedendo qualche minuto per elaborazione e presentazione proposte a tutti.
Dopodichè si è proceduto al dot voting, armati di ben 3 mini adesivi tondi a persona 🙂
Tutto chiaro, no? 🙂
A parte gli scherzi, ecco quanto emerso:
Prima di salutarci, Fabio ci ha intrattenuto con un divertente ice breaker sulla coordinazione del team. Come poter disegnare nel più beve tempo possibile una casa, un’auto… Qualunque cosa quando si ha a disposizione un pennarello montato su di un sostegno collegato a 10 fili, e quindi manovrare tale marchingegno coordinandosi appunto in 10 persone, una per ogni filo?
Ce l’abbiamo fatta, chi mettendoci di più chi meno, ma anche questa sfida è stata superata 🙂
Dopotutto siamo un bel gruppo, e rispetto a qualche annettofa…
Se prima eravamo in tre
A lavorare per Intré,
Adesso siamo in
A lavorare per Intré!!
e arrivederci al prossimo camp!!!
How, why and what has lead us to the Milan Kotlin Community Conference.
Racconto del camp aziendale svoltosi a Pontida, agriturimo Polisena
4o articolo sul mondo Vert.x a cura di Marco
3o articolo sul mondo Vert.x a cura di Marco
2o articolo sul mondo Vert.x a cura di Marco
NoSlidesConf: una conferenza diversa dal solito
Racconto della conferenza presso l'università degli studi Carlo Bo di Urbino
#IAD17: Racconto della giornata di unconference presso l'Università degli Studi Carlo Bo di Urbino
Racconto del camp aziendale svoltosi all'agriturismo La Camilla
Resoconto del camp aziendale svoltosi all'Oasi di Galbusera Bianca
CloudConf 2017 a Torino. Come è andata?
Il racconto della giornata al Mini Italian Agile Day tenutasi a Vimercate.
Nel week-end del 25-26 novembre 2016 si è svolto il Codemotion Milano 2016.
Francesco Sacchi e Ferdinando Santacroce ci raccontano com'è andata.
Il racconto della nostra giornata alla Angular Conf 2016 a Torino, sia come spettatori e soprattutto come sponsor.
Un racconto di come è andata la nostra giornata di team building, tra sorrisi e battaglie ;)
Cronistoria sulla nostra partecipazione alla 5^ edizione della Node.Js Italian Conference, con tante belle foto, stickers e...leggete :)
In questo breve intervista viene presentata Intré e il suo innovativo approccio allo sviluppo di software.
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.
Primo post sulla programmazione in Scala dedicato a future e promise, due costrutti fondamentali per la programmazione concorrente.
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.
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#.
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.
Questo è un breve test di come è possibile controllare Lego Mindstorm con Cloudfoundry usando HTML5 e WebSockets.
Questo articolo descrive come intercettare l'interrupt GPIO di una beagle bone e aggiornare, via web sockets, una pagina web usando node.js.
Come controllare e monitorare i device usando una piattaforma Cloud? La soluzione è stata presentata al Graphical Web 2012 a Zurigo.
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.
Via Gaslini, 2 20900 Monza (MB)
Telefono:+39 039.28.45.774
Codice Fiscale: 02885420964
Partita IVA:IT02885420964