mikamaiblog - Tumblr blog

mikamaiblog · 4 years

Text

Why we went from Slack to Discord

The beginning of 2020 was one of the most difficult moments of the last decade. The rapid spread of SARS-COVID-2 and the consequent quarantine imposed by the various countries of the world has led many companies to discover and approach remote work for the first time, in order to protect their employees while still being able to work without attending the office. However, choosing the right tools to support remote collaboration is almost as difficult a challenge as adopting "smart" working methodologies that allow you to keep productivity high. The panorama of available choices is vast, from open-source tools such as Jitsi and Nextcloud to commercial services such as Slack and Google GSuite, each with its own strengths and peculiarities.

At Mikamai we have always been used to working in a "smart" way, preferring asynchronous and written collaboration wherever possible to make our business more streamlined and agile. This allows us to expand our operational area to the entire world, both in terms of customers and collaborators. In fact, many colleagues do not work from our main office in Milan, Italy, but from more comfortable places for them, such as other Italian or European cities, even other continents. We have long been GSuite users for shared documents, GitHub for hosting our projects, Trello for managing activities and Slack for internal communication.

However, we recently started to feel the limitations of Slack’s free plan. Mikamai has grown, the number of people and messages written every day has grown significantly with it, and we have found ourselves to frequently exceed the limit of 10,000 messages, thus losing potentially important conversations and messages. The lack of group video calls forces us to use Google Meet, an excellent video conferencing solution but which lacks the immediacy of starting a call directly from the text chat. However, paid plans, the price of which increases for each employee present in the workspace, are not very appealing to us. So we started scouting for a tool that would better meet our needs.

In the past few months we have tried several online communication tools, in particular Mattermost, an open source alternative to Slack, JetBrains Space, a collaboration and management service that includes a chat very similar to Slack, and Discord, a communication platform designed for gamers and online communities, but with very interesting features also for companies that work in a distributed way.

The latter has caught our attention, and here are the reasons that led us to adopt it as our corporate communication tool.

Voice chat is only one click away

Despite working mainly in an asynchronous way through email, Trello cards and comments on the code repositories, direct conversation is a very important tool especially for creative activities that benefit from a rapid and continuous exchange of ideas between the participants. The ability of immediately entering a group voice chat, with excellent audio quality and with the support of text chat and screen sharing is perhaps Discord's main strength, and what really convinced us in attempting the transition.

Brainstorming and planning sessions can be started quickly without the overhead that changing tools entails when using services outside the chat, as was our case with Google Meet. Everything is much more natural and immediate, promoting communication and the exchange of ideas rather than discouraging them.

It is also very convenient for organizing virtual coffee breaks, allowing you to maintain human contact with colleagues that you risk losing by working remotely.

Granular control over roles and permissions

Discord was created to host online communities, mainly in the gaming world but extending over time to all those groups of users who need a safe digital space in which to meet and chat. For this reason, the platform provides a wide range of permissions, which can be grouped into roles to be assigned to users, allowing you to granularly control which actions are granted to which users, and in which channels. In our particular case we do not manage a public space but a private server, however it is not used solely for business purposes. We have dedicated some channels to external activities, like video games or role-playing games, which involve the presence of users who are not part of the company staff, such as family members and playmates, former colleagues and partners of other companies. Thanks to Discord's powerful permission system, these users have access only to the channels for which they were authorized, while the company's internal chats are hidden and inaccessible.

This also allows us to invite our customers to join the server to facilitate the exchange of information with them. For each project, a text channel and a corresponding voice room is created, along with a role that allows access to them. When the customer enters the server and is assigned the role, he can then access these channels and actively collaborate with us, without being able to see reserved areas and spaces dedicated to other active projects.

We have also created a dedicated announcement channel, in which only Mikamai's administrative staff can write, to support the internal mailing list in quickly sharing official news and communications with colleagues.

External integrations

Slack boasts a multitude of integrations with third-party systems, from ticketing and project management platforms to infrastructure alarms and monitoring systems. Discord does not have the same spread in the business and development world, but provides the possibility to configure the integrations in a Slack compatible mode, basically allowing to integrate any system that can interact with Slack. Discord also has a robust and diverse chatbot ecosystem, small applications that act like automatic users and increase native chat features. For example, a very successful bot in Mikamai’s server is Groovy, a bot that allows you to play music to all users connected to a voice channel as a kind of virtual jukebox. Thanks to it, we can share our music with colleagues, allowing everyone to add songs to the playlist being played.

Cost

Obviously one aspect that we have not underestimated during our evaluation is the monetary cost compared to the competition. All of Discord’s core features are completely free, providing paid additions mainly aimed at the gaming world, especially streamers and youtubers, such as the ability to add custom emojis, customize the profile and improve audio and video quality. This, added to the points previously discussed, was one of the key points for Mikamai in making the decision to migrate to Discord.

Testimonials

Given that I’m not a very techy person, which often limits me in discovering the full potential of this type of tool, I must say that I find Discord very versatile. I really appreciate the possibility of enabling audio channels that allow an immediate switch between text communication and voice communication (especially group chats). Having an unlimited number of messages always available free of charge is, of course, another nice advantage.

Debora, Office Manager.

Discord adds syntax highlighting for code snippets, unlimited message history, integrated calls, screenshare with up to 50 people (during the COVID-19 period), a really advanced role and permission system, and is very easy to integrate with external tools. I don't know what more you could ask for.

Nicola, Tech Lead.

I have been using Discord for more than a year mainly for gaming but also to talk or see my friends. I immediately found it intuitive and with a youthful graphic feeling. Its strength is absolutely being free, I still remember when I had to communicate with other players simultaneously, we used TeamSpeak and it required us to spend a lot of money every month for a dedicated server, with an increasing cost based on the amount of users who could connect at once, a real nightmare. With Slack, I suffered (and still suffer) because of the limited chat history, 10,000 messages or a month of history and then that’s it. How many lost links, how many chats that have fallen by the wayside ("I wrote it to you on Slack", "When ???")... Discord is, in my opinion, the tool par excellence of remote communication both for gaming, chatting and companies.

Daniela, Frontend Developer

Conclusions

Discord has proved to be an excellent corporate communication platform despite being mainly geared towards the world of gaming and digital communities. The speed with which it is possible to start talking with colleagues and organize virtual meetings has allowed us to facilitate the transition even for those who were not previously used to working completely remotely, and has given us back a part of the warmth that sharing the day with our coworkers transmit, reducing the alienation due to the emergency situation in which we find ourselves. We will have the opportunity to test it thoroughly in the coming months, but we are sure that it will prove itself to be a valid and central tool for our daily work.

#Discord #Slack #Smart working #chat #digital transformation #chat aziendale #coronavirus #remote working #covid #covid2019 #covid19 #mikamai

0 notes

mikamaiblog · 4 years

Text

Perché siamo passati da Slack a Discord

L’inizio del 2020 è stato uno dei momenti più difficili dell’ultimo decennio. La rapida diffusione del SARS-COVID-2 e le conseguenti quarantene imposte dai vari Paesi del mondo ha portato tantissime aziende a scoprire ed approcciare per la prima volta il lavoro remoto, non potendo mettere a rischio la salute dei dipendenti chiedendo loro di continuare a frequentare l’ufficio. Tuttavia scegliere gli strumenti adatti per supportare la collaborazione remota è una sfida ardua quasi quanto adottare metodologie di lavoro “smart” che permettano di mantenere alta la produttività. Il panorama di offerte disponibili è vastissimo, da tool open-source come Jitsi e Nextcloud a servizi commerciali come Slack e Google GSuite, ognuno dotato dei suoi punti di forza e delle sue peculiarità.

In Mikamai siamo da sempre abituati a lavorare in maniera “smart”, preferendo la collaborazione asincrona e scritta laddove possibile per rendere più snelle ed agili le nostre attività. Questo ci permette di espandere il nostro bacino di utenza al mondo intero, sia in termini di clienti che di collaboratori. Molti colleghi infatti non lavorano dalla sede di Milano, ma da luoghi più confortevoli per loro, altre città italiane o europee, addirittura altri continenti. Siamo da lungo tempo utilizzatori di GSuite per i documenti condivisi, GitHub per l’hosting dei nostri progetti, Trello per la gestione delle attività e Slack per la comunicazione interna.

Riguardo a quest’ultimo strumento, Slack, abbiamo cominciato recentemente a sentire i limiti del suo piano gratuito. Mikamai è cresciuta, il numero di persone e di messaggi scritti ogni giorno è cresciuto sensibilmente con essa e ci siamo trovati più volte a superare il limite di 10.000 messaggi di storico, perdendo così conversazioni e messaggi potenzialmente importanti. La mancanza di videochiamate di gruppo ci costringe ad usare Google Meet, un’ottima soluzione di videoconferenza ma che manca dell’immediatezza di cominciare una chiamata direttamente dalla chat in cui si stava discutendo. Tuttavia i piani a pagamento, il cui prezzo aumenta per ogni collaboratore presente nel workspace, risultano poco interessanti per noi. Abbiamo quindi cominciato a guardarci intorno, alla ricerca di uno strumento che soddisfacesse meglio le nostre necessità.

Nei mesi passati abbiamo provato diversi strumenti di comunicazione online, in particolare Mattermost, un’alternativa open source a Slack, JetBrains Space, un servizio di collaborazione e management che include una chat molto simile a Slack, e Discord, una piattaforma di chat pensata per videogiocatori e community online, ma dotata di features molto interessanti anche per aziende che lavorano in maniera distribuita.

Quest’ultimo ha colpito la nostra attenzione, ed ora vi illustreremo le motivazioni che ci hanno portato ad adottarlo come strumento di comunicazione aziendale.

Chat vocali a portata di click

Pur lavorando principalmente in maniera asincrona, tramite email, card su Trello e commenti al codice, la conversazione diretta è uno strumento importantissimo soprattutto per attività creative che beneficiano di uno scambio rapido e continuo di idee tra i partecipanti. La possibilità di entrare immediatamente in una chat vocale di gruppo, con ottima qualità audio e con il supporto della chat testuale e della condivisione dello schermo è forse il punto di forza principale di Discord, e quello che ci ha davvero convinto nel tentare il passaggio.

Sessioni di brainstorming e planning possono essere avviate rapidamente senza l’overhead che cambiare strumento comporta quando si usano servizi esterni alla chat, come nel nostro caso Google Meet. Tutto è molto più naturale ed immediato, favorendo la comunicazione e lo scambio di idee anziché scoraggiarle.

Risulta inoltre molto comodo per organizzare pause caffè virtuali, permettendo di mantenere il contatto umano con i colleghi che si rischia di perdere lavorando da remoto.

Controllo granulare su ruoli e permessi

Discord è nato per ospitare comunità online, principalmente nel mondo gaming ma estendendosi nel tempo a tutti quei gruppi di utenti che necessitano di uno spazio digitale in cui incontrarsi e chiacchierare. Per questa ragione la piattaforma mette a disposizione un ampio ventaglio di permessi, raggruppabili in ruoli da assegnare agli utenti, permettendo di controllare in maniera molto precisa quali azioni sono concesse a quali utenti, e in quali canali. Nel nostro caso particolare non gestiamo uno spazio pubblico ma un server privato, tuttavia non viene usato unicamente a scopo lavorativo. Abbiamo dedicato alcuni canali ad attività esterne, come videogiochi o giochi di ruolo, che comportano la presenza di utenti che non fanno parte dello staff aziendale, quali familiari e compagni di gioco, ex colleghi e partner di altre aziende. Grazie al potente sistema di permessi di Discord questi utenti hanno accesso esclusivamente ai canali per cui sono stati autorizzati, mentre le chat interne all’azienda risultano nascoste e inaccessibili.

Questo ci permette anche di invitare i nostri clienti ad unirsi al server per agevolare lo scambio di informazioni con loro. Per ogni progetto viene creato un canale testuale ed un corrispondente canale vocale, assieme ad un ruolo che permetta di accedere ad essi. Quando il cliente fa il suo ingresso nel server e gli viene assegnato il ruolo, può accedere a questi canali e collaborare attivamente con noi, senza che possa accedere ad aree riservate e agli spazi dedicati ad altri progetti attivi.

Abbiamo inoltre creato un canale dedicato agli annunci, in cui soltanto lo staff amministrativo di Mikamai può scrivere, per affiancare la mailing list interna nel condividere rapidamente notizie e comunicazioni ufficiali ai colleghi.

Integrazioni esterne

Slack vanta una pletora di integrazioni con sistemi di terze parti, dalle piattaforme di ticketing e gestione progetti a sistemi di allarmi e monitoring infrastrutturali. Discord non dispone della stessa diffusione nel mondo business e dello sviluppo, ma fornisce la possibilità di configurare le integrazioni in una modalità compatibile con Slack, permettendo sostanzialmente di integrare qualsiasi sistema che possa interagire con Slack. Discord dispone inoltre di un robusto e variegato ecosistema di chatbot, piccoli applicativi che si comportano come utenti automatici e aumentano le funzionalità di chat native. Ad esempio, un bot di grande successo in Mikamai è Groovy, un bot che permette di riprodurre musica a tutti gli utenti collegati ad un canale vocale come una specie di jukebox virtuale. Grazie ad esso possiamo passare il tempo di lavoro condividendo la nostra musica con i colleghi, permettendo a tutti di aggiungere canzoni alla playlist in riproduzione.

Costo

Ovviamente un aspetto che non abbiamo sottovalutato durante la nostra valutazione è il costo monetario rispetto alla concorrenza. Discord è completamente gratuito per tutte le funzionalità fondamentali, fornendo aggiunte a pagamento principalmente rivolte al mondo del gaming, soprattutto a streamers e youtubers, quali la possibilità di aggiungere custom emoji, personalizzare il profilo e migliorare la qualità audio e video. Questo, sommato ai punti precedentemente discussi, è stato uno dei punti chiave per Mikamai nel prendere la decisione di migrare a Discord.

Testimonials

Premettendo di non essere una tecnica, cosa che spesso mi limita nello scoprire la piena potenzialità di questo tipo di strumenti, devo dire che trovo Discord un tool versatile. Apprezzo molto la possibilità di attivare dei canali audio che permettano uno switch immediato tra comunicazione testuale e comunicazione vocale (anche e specialmente di gruppo) e avere a disposizione un numero di messaggi illimitato sempre a titolo gratuito è ovviamente un altro bel vantaggio.

Debora, Office Manager.

Discord aggiunge syntax highlighting per il codice, storico dei messaggi illimitato, call integrate, screenshare con fino a 50 persone (durante il periodo del COVID-19), un sistema di ruoli e permessi davvero avanzato, ed è facilissimo da integrare con tool esterni. Non so cosa altro si possa chiedere.

Nicola, Tech Lead.

Utilizzo Discord da più di un anno principalmente per il gaming ma anche per sentire o vedere i miei amici. Da subito l’ho trovato intuitivo e con un feeling grafico giovanile. La sua forza è assolutamente il costo zero, ricordo ancora quando dovevo comunicare con altri giocatori simultaneamente, usavamo TeamSpeak e richiedeva spendere parecchi soldi ogni mese per un server dedicato, con costo sempre maggiore in base alla quantità di utenti che potevano entrare nel canale, un incubo. Con Slack ho sofferto (e soffro ancora) lo storico della chat, 10.000 messaggi o un mese di history e poi stop. Quanti link perduti, quante chat cadute nel dimenticatoio (“te lo avevo scritto su Slack”, “Ma quando???”)... Ad oggi Discord è, a mio parere, il tool per eccellenza di comunicazione a distanza sia per gaming, chatting e aziende.

Daniela, Frontend Developer

Conclusione

Discord si è rivelato un’eccellente piattaforma di comunicazione aziendale nonostante sia principalmente orientato al mondo gaming e communities digitali. La rapidità con cui è possibile cominciare a parlare con i colleghi e organizzare meeting ci ha permesso di agevolare la transizione anche per chi non era precedentemente abituato a lavorare completamente da remoto, e ci ha ridato una parte del calore che il condividere la giornata con i propri coworkers trasmette, riducendo l’alienazione dovuta alla situazione d'emergenza in cui ci troviamo. Avremo modo di metterlo alla prova nei prossimi mesi, ma siamo sicuri che si dimostrerà uno strumento valido e centrale per il nostro lavoro quotidiano.

#Slack #Discord #Smart Working #Mikamai #digital transformation #lavoro da remoto #chat #chat aziendale #covid #coronavirus #covid2019 #covid19

0 notes

mikamaiblog · 4 years

Text

Artshell: i servizi di intelligenza artificiale di AWS al servizio dell’arte

Artshell nasce dalla passione per l’arte e dall’osservazione del suo mondo, un mondo complesso, fatto da molteplici attori: gallerie d’arte, fondazioni, collezione private, musei, enti pubblici e privati. In questo immenso mercato, creare un singolo strumento in grado di gestire il lavoro, l’amministrazione e la comunicazione quotidiana di tutti questi diversi enti è stata una grande sfida.

Ma cos’è Artshell? Artshell si propone come sistema integrato per la gestione completa d’opere d’arte, e si rivolge a un pubblico di galleristi, collezionisti e artisti. Attraverso una web app, un'app Mobile e un'app per Desktop, è possibile digitalizzare e archiviare le opere e i dati ad esse connessi e poter successivamente dedicarsi al marketing.

Mikamai ha aiutato Artshell mettendo a sua disposizione una squadra di professionisti che, al suo fianco, ha creato un’infrastruttura su Amazon Web Services (AWS) ad alta affidabilità, scalabile e sicura, in grado di fornire degli strumenti efficienti per creare tutti i servizi necessari ed estenderli, sfruttando l’intelligenza artificiale e il machine learning e digitalizzando l’immenso lavoro manuale prima indispensabile per l’archiviazione delle opere d’arte.

Scopri di più su Mikamai e su Artshell e sul lavoro che i due team sono riusciti a creare sfruttando la potenza di AWS.

#artshell #aws #mikamai #artificial intelligence #Intelligenza artificiale #machine learning #amazon web service #art #arte #web development

0 notes

mikamaiblog · 6 years

Text

Mikamai e Le Wagon: il primo giorno di scuola non si scorda mai!

Ieri siamo stati felici di incontrare gli studenti all'inauguarzione del corso di Le Wagon Milano dedicato a Ruby!

Abbiamo avuto la possibilità di conocscere tanti/e ragazzi/e nuovi/e con molto entusiasmo e voglia di imparare, oltre a rivedere i nostri instacabili amici di Le Wagon Milano.

Le premesse sono molto buone e siamo certi che ci aspettano tante soddisfazioni e sorprese nei mesi a venire. Grazie alla nostra nuova partnership, i nostri developer saranno coinvolti attivamente durante il corso e al suo termine affiancheranno il migliore studente per uno stage di tre mesi! Un grande in bocca al lupo a tutti i/le ragazzi/e. Ci vedremo presto da Impact Hub per condividere ancora dritte, sorrisi e tanto codice insieme! Se vuoi scoprire di più su Le Wagon e sui suoi corsi, clicca qui.

#Le Wagon #Le Wagon Milano #Mikamai #Ruby #Bootcamp #Partnership #Stage #Intership #Rails #Ruby on Rails

0 notes

mikamaiblog · 6 years

Text

Mikamai & Le Wagon: a new partnership!

It is with great pleasure that we are announcing the beginning of a new partnership between Mikamai and Le Wagon! Le Wagon is the best coding bootcamp out there. It organizes classes to create Full Stack developers and it is ideal for passionate and creative people with no technical background and those who are taking the first steps in the world of development, offering the fundamental support, mindset and skills to grow and learn. Like us, Le Wagon has a special place in their "stack" for Ruby and they decided to cultivate and promote this language (and its framework), helping those who want to discover it. We recommend the first Le Wagon class on the 5th of March dedicated to Ruby (you can find the information here) where Mikamai will be actively involved both during and after… …the most exciting news is that the best students of the class will have the chance to work with us for a 3 months internship side by side with our best developers! And then we will see... one thing leads to another...

#Ruby #Ruby On Rails #Bootcamp #coding #Mikamai #Le Wagon #Intership #Stage #class #Partnership

0 notes

mikamaiblog · 6 years

Text

Mikamai e Le Wagon: una nuova partnership!

È con molto entusiamo che annunciamo l'inizio della nuova partnership tra Mikamai e Le Wagon! Le Wagon è attualmente il miglior coding bootcamp al mondo, ed organizza corsi per creare figure Full Stack. Indirizzato sia a chi è completamente a digiuno di codice, sia a chi ha iniziato a muovere i primi passi e vuole tuffarsi nel mondo della programmazione con il giusto mindset e il giusto supporto. Come noi, Le Wagon ha riservato un posto speciale per Ruby e ha deciso di cercare di coltivare il più possibile questo linguaggio (e i rispettivi framework), aiutando tutti coloro che lo vogliono scoprire. Vi segnaliamo subito il corso di Le Wagon del 5 marzo dedicato a Ruby (trovate qui tutte le informazioni) che vedrà la nostra partecipazione sia durante, con un nostro intervento, sia dopo... ...la novità che ci emoziona di più è che i migliori studenti del corso potranno venire da noi e fare una Intership di 3 mesi a stretto contatto con i nostri migliori dev! E poi da cosa nasce cosa...

#Mikamai #Le Wagon #Le Wagon Milano #Bootcamp #Ruby #Ruby on Rails #RoR #coding #Full Stack

0 notes

mikamaiblog · 6 years

Text

Follow up - Come vendere con i chatbot

Il 15 novembre, abbiamo dedicato una serata ai chatbot. L'evento, intitolato "Come vendere con i chatbot", è stato organizzato da Mikamai e LinkMe, in collaborazione con Milano Chatbots Meetup e Diginventa. Cos'è un chatbot? In che modo è possibile programmare e similura una comversazione? Quali sono le variabili da prendere in considerazione? Come sfruttarlo per vendere? Queste sono alcune delle domande a cui abbiamo dato risposta attraverso gli interventi di Paolo Montrasio, Software Architect e organizzatore del meetup Milano Chatbots, Valentino Spataro, consulente legale e web developer, Giovanni Lela, Tech Lead di LinkMe e Paolo Faranda, CEO di Diginventa. Se vuoi scoprire di più, consulta le presentazioni: Paolo Montrasio: "Chatbot e Milano Chatbots Meetup" Valentino Spataro: “Mappe mentali e chatbots” - Mappa Mentale Giovanni Lela: "Chatbot offering" Paolo Faranda: "I casi Linear e Viniamo" Oppure guarda il video della serata:

youtube

#Mikamai #LinkMe #Paolo Montrasio #Evento #Valentino Spataro #Milano Chatbots #Chatbot #Diginventa #Giovanni Lela #Paolo Faranda

0 notes

mikamaiblog · 7 years

Text

15 novembre - Come vendere con i chatbot

Mercoledì 15 novembre dalle 19:00 alle 21:00, Mikamai e LinkMe, in collaborazione con Milano Chatbots Meetup e Diginventa, organizzano una serata dedicata ai chatbot: "Come vendere con i chatbot". Le aspettative nei confronti dei chatbot, software che sfruttano l'Intelligenza Artificiale per simulare una conversazione con gli utenti in una chat, continuano ad aumentare. Come però sfruttare un simile servizio per rendere più efficace ed efficiente la vendita? La serata del 15 novembre verterà su queste tematiche e vedrà l'intervento di Paolo Montrasio, Software Architect e organizzatore del meetup Milano Chatbots, Valentino Spataro, consulente legale e web developer, Giovanni Lela, Tech Lead di LinkMe e Paolo Faranda, CEO di Diginventa. Ecco il programma della serata: 19:00 - Welcome a cura di Gianluca Randazzo di Mikamai 19:05 - Paolo Montrasio: "Chatbot e Milano Chatbots Meetup" 19:20 - Valentino Spataro: "Mappe mentali e chatbots" 19:25 - Giovanni Lela: "Chatbot offering" 19:40 - Paolo Faranda: "I casi Linear e Viniamo" 20:10 - Light Aperitif Iscrivetevi qui per partecipare! NB Durante l’evento potremo raccogliere immagini sotto forma di foto o video da pubblicare sui nostri siti o social network per finalità di carattere informativo e promozionale. L’evento sarà disponibile in streaming su Facebook.

#chatbot #milano #meetup #diginventa #mikamai #linkme #milano chatbots

0 notes

mikamaiblog · 7 years

Text

Crescita delle startup: cash o equity? - Follow up

Il Mikamai Startups Program nasce come acceleratore tecnologico per accompagnare le startup nelle varie fasi di sviluppo (MVP, real product, etc). Mikamai ha quindi deciso di organizzare una serie di serate divulgative dedicate a questa tematica.

Durante il secondo appuntamento, dal titolo “Crescita delle startup: cash o equity?”, che si è svolto mercoledì 4 ottobre ed è stato organizzato da Mikamai e LinkMe, in collaborazione con Ulule, L-Move e Tip Ventures, abbiamo discusso di un problema fondamentale che si trovano ad affrontare le startup: quando arriva il momento di accelerare lo sviluppo tecnologico, l'equity può essere la scelta giusta? Come muoversi quindi sull’equity crowdfounding? Alla serata sono intervenuti Nicola Furnari, Community manager di Ulule, Matteo Masserdotti, CEO & Founder di Tip Ventures, Felipe Aguilera, Co-Founder e Managing Partner di L-Move, Alessandro Basile, Legal Advisor e Gennaro Ardimento, Mr Ideas. Per chi non c'era e avrebbe voluto partecipare e per chi volesse rivedere i temi trattati durante la serata, ecco le presentazioni dei nostri speaker:

Nicola Furnari, Ulule - "Cash o Equity"

Matteo Masserdotti, Tip Ventures - "How to succeed in Equity Crowdfounding"

Felipe Aguilera, L-Move - "Presentazione L-Move"

Alessandro Basile, Legal Advisor - "Equity e Startup"

Gennaro Ardimento, Mr Ideas - "Presentazione Mr Ideas"

Oppure guarda il video della serata sul nostro canale YouTube!

youtube

#ulule #mikamai #linkme #startup #evento #equity #crowdfunding #lmove #tipventures

0 notes

mikamaiblog · 7 years

Text

Hack.Developers: l’evento di apertura da Mikamai e LinkMe

L’11 settembre, Mikamai e LinkMe hanno hanno ospitato l’evento di apertura del Meetup di Hack.Developers, il primo di una serie di eventi che si svilupperanno su venti tappe e toccheranno le principali città italiane. Lo scopo del meetup è quello di incontrare gli sviluppatori e le tech community per presentare loro l’Hackathon “Hack.Developers”, organizzato per le date del 7-8 ottobre e promosso dal Team per la Trasformazione Digitale in collaborazione con Codemotion, con la sponsorizzazione di Cisco, DCX.technology, Ibm, Intesa San Paolo, Microsoft, Oracle, Red Hat e TIM. La maratona di programmazione coinvolgerà sviluppatori e tech community italiane e si svolgerà in contemporanea in oltre 20 città. L’obiettivo dell’hackathon è quello di sviluppare progetti open source per PA, proponendo così soluzioni che possano migliorare i servizi al cittadino e renderli più funzionali, accessibili e utilizzabili. Il codice verrà ospitato nella piattaforma Developers.Italia.it, la community open source lanciata a marzo dal Team Digitale. La prima serata di presentazione si è tenuta proprio a Milano e Mikamai e LinkMe hanno aperto le porte agli organizzatori di Hack.Developers e del Codemotion. Presente alla serata anche Roberta Cocco, Assessore a Trasformazione digitale e Servizi civici del Comune di Milano che sarà attivamente coinvolto nell’organizzazione della tappa milanese a ottobre. Per scoprire di più e partecipare all’Hackathon, clicca qui.

#Hackathon #Mikamai #LinkMe #Hack.Developers #Hack Developers #Team per la Trasformazione Digitale #PA #opensource #open source #Codemotion #Comune di Milano #Roberta Cocco #Trasformazione digitale #Meetup #evento

0 notes

mikamaiblog · 7 years

Text

Crescita delle startup: cash o equity?

Continua il nostro viaggio di approfondimento nel mondo del crowdfunding capitanato da Mikamai e LinkMe, che questa volta organizzano una serata in collaborazione con Ulule, L-Move e Tip Ventures. Mercoledì 4 ottobre ti aspettiamo in via Venini 42 dalle 19:00 alle 21:30 per parlare di “Crescita delle startup: cash o equity?”. La serata inizierà con un breve cappello introduttivo. A seguire approfondiremo l’argomento con Nicola Furnari di Ulule, Matteo Masserdotti di Tip Ventures e Alessandro Basile, Legal Advisor. Termineremo con la presentazione di due case study e un light aperitif offerto a tutti i partecipanti! Il programma della serata:

19:00 Welcome a cura di Gianluca Randazzo di Mikamai

19:10 Nicola Furnari, Community manager di Ulule "Crowdfunding world"

19:30 Matteo Masserdotti, CEO & Founder di Tip Ventures "La soluzione equity crowdfunding"

20:00 Alessandro Basile, Legal Advisor "Equity, startup e strumenti giuridici”

20:10 Case study MrIdeas

20:40 Light Aperitif

21:30 Fine dell'evento

Iscriviti subito per partecipare! NB Durante l’evento potremo raccogliere immagini sotto forma di foto o video da pubblicare sui nostri siti o social network per finalità di carattere informativo e promozionale. L’evento sarà disponibile in streaming su Facebook.

#startup #Mikamai #LinkMe #Ulule #L-Move #Tip Ventures #Crowdfunding #Equity #evento #Venini42

0 notes

mikamaiblog · 7 years

Text

Debito tecnico: definizione e approccio pratico

Lo sviluppo di software avviene tradizionalmente in tre fasi: sviluppo, testing, rilascio. A seconda dei casi queste fasi possono poi essere divise ulteriormente: la fase di sviluppo potrebbe prevedere dei rilasci continui in un ambiente alpha che conterrà feature incomplete ma permetterà di avere feedback più rapidi; il testing potrebbe avvenire in diversi ambienti a cascata (es. Il primo è un ambiente isolato con base dati vuota, il secondo contiene una base dati realistica, il terzo è sottoposto a stress testing, etc.).

Nello sviluppo tradizionale di software consideriamo la feature al pari di un prodotto fisico come una sedia o un tavolo: arrivati al rilascio in produzione il prodotto è considerato esente da difetti strutturali, funzionante, e si può passare ai prodotti successivi. In alcuni casi si alloca un periodo di regime controllato dopo il rilascio, durante il quale si ammette che possano verificarsi bug (che verranno quindi risolti). Ma dopo questo periodo, il prodotto è appunto esente da difetti.

Il problema è che una feature software non è una sedia. Una volta rilasciata potremmo scoprire che gli sviluppatori non avevano compreso appieno le specifiche, con la necessità di riscrivere parti di codice in fretta, senza badare troppo alla leggibilità. Potrebbe anche produrre esattamente il valore di business richiesto, essere performante e non contenere bug. Eppure, malgrado uno sviluppo eccellente, un cambio di strategia potrebbe richiedere di modificare la feature mesi o anni dopo. Anche nei casi più fortunati, il solo passare del tempo aumenta di giorno in giorno la possibilità che il codice vada toccato di nuovo, per accomodare un aggiornamento tecnologico ad esempio.

In qualunque modo capiti, d’un tratto abbiamo per le mani codice di tanto tempo fa, scritto da persone che hanno lasciato da tempo il team, scritto con una tecnologia obsoleta, e persino una piccola modifica che normalmente richiederebbe qualche giorno improvvisamente richiede settimane.

Ad esempio ci si ritrova ad aver scritto due anni fa un ecommerce nell’arco di un mese, ma ad aver bisogno oggi di due mesi per poter cambiare una singola feature, e a chiedersi di chi è la colpa, e se è il caso di continuare a mantenere uno strumento tanto costoso. Stiamo andando per esagerazioni, ma neanche tanto.

Cos'è il debito tecnico?

Solitamente si tende a considerare il debito tecnico come qualcosa che colpisce solo il “codice vecchio”. Ma non è detto che un applicativo scritto negli anni ‘70 sia più complicato di uno scritto negli anni ‘90.

Il concetto di debito tecnico è una metafora concepita da Ward Cunningham per descrivere quanto un progetto software sia complesso. Secondo Cunningham rilasciare un codice non-buono è come contrarre un debito, che può essere ripagato riscrivendo il codice stesso. Ogni minuto passato sul codice non-buono aumenta l’interesse di questo debito.

Quindi, se lo sviluppo avviene senza seguire una corretta metodologia, l’interesse sul debito può salire fino a paralizzare il progetto.

Certamente c’è differenza tra sviluppatore e sviluppatore, e tra fornitore e fornitore. L’esperienza aiuta a scrivere codice migliore, a comprendere meglio le specifiche di ciò che si sta facendo. Ma non basta: a volte anche il codice migliore è comunque difficile da capire e modificare, e quindi ha un debito tecnologico alto.

Un’altra definizione, la più comunemente accettata a oggi, è quella data da Michael Feathers nel suo Working Effectively with Legacy Code: è codice senza copertura di test. È sicuramente una descrizione migliore che associare il termine solo a codice arcaico.

Il motivo per cui la scrittura di test è una così buona precauzione contro il debito tecnico è che i test forniscono una documentazione sul funzionamento dell’applicativo.

Per cui piuttosto che di codice non testato, si parla di codice:

Scritto in modo non chiaro

Che non contiene spiegazioni sul funzionamento

Che non spiega quali idee e quale processo decisionale hanno portato alla sua scrittura

Il che offre un punto di vista completamente diverso sulla questione. Perché a questo punto il debito tecnico non è più solo un problema tecnico, ma è anche un problema di comunicazione.

Sei interessato conoscere lo stato e i problemi della tua applicazione web?

Come si genera il debito tecnico?

Riprendiamo l’esempio dell’ecommerce citato all’inizio.

Alle prime 100 righe di codice scritte questo debito tecnico si potrebbe ripagare mostrando il codice ad un collega. Questa operazione permetterebbe di condividere la conoscenza, di avere una conferma che la logica sia corretta e che il codice sia leggibile da altri.

Dopo un mese, al rilascio, c’era il codice minimo indispensabile per far funzionare la piattaforma. In questo momento il debito tecnico si potrebbe ripagare illustrando il processo d’acquisto ai colleghi, ricontrollando il codice in modo da assicurarsi che non vi siano punti troppo complessi da leggere e scrivendo dei test automatici che garantiscano il funzionamento del processo d’acquisto. È un debito tecnico più alto, ma sembra ancora accettabile.

Due mesi dopo avviene lo sbarco in un paese asiatico: cambia tutto, da tasse calcolate a dati richiesti. Dato che ogni modifica può rompere il processo d’acquisto, gli sviluppatori iniziano a fare prove sull’ambiente di staging dopo ogni modifica. Il che crea un rallentamento negli sviluppi. Il debito tecnico è ora talmente alto che inizia a causare i primi problemi. Per ripagarlo bisognerebbe cambiare completamente strategia, iniziando a dedicare del tempo per scrivere test e ripulire il codice nei punti più ostici.

Sei mesi dopo. Ad ogni nuovo rilascio appaiono nuovi inquietanti bug, per questo motivo è stato assunto un addetto al controllo qualità che si occupa di visitare l’ambiente di staging prima di ogni rilascio per individuare bug. In questo momento l’interesse generato dal debito tecnico è tale da richiederci una professionalità in più, di cui altrimenti non ci sarebbe bisogno.

Un anno dopo. L’azienda si è ingrandita e bisogna aggiungere il concetto di brand all’ecommerce. Il che richiede di ristrutturare tutto l’applicativo. Il team fa quello che può, ma gli sviluppi procedono a rilento. Possiamo immaginare in questo momento il debito tecnico come un serpente che si morde la coda: il debito tecnico è tale da rallentare il team negli sviluppi, di conseguenza il team non ha tempo per rifattorizzare.

Si arriva di solito ad una situazione di stallo non troppo lontana da quanto descritto. Riscrivere l’applicativo è troppo costoso (e riscrivere non è quasi mai una buona scelta), modificarlo è troppo rischioso.

Volendo sintetizzare, ogni volta che si parla di:

Codice difficile da modificare

Codice difficile da leggere

Applicativo instabile

Lentezza dei tempi di sviluppo

Difficoltà a espandere il team

Difficoltà ad aggiornare l’applicativo

Difficoltà a tenere in piedi l’applicativo

Performance basse

Stiamo parlando di debito tecnico.

Come riduciamo il debito tecnico?

Abbiamo detto che il debito tecnico è un problema di comunicazione, e la cosa non può non farci tornare alla mente la legge di Conway: la base di codice di un’organizzazione riflette le strutture di comunicazione dell’organizzazione stessa.

Prima ancora di risolvere il debito tecnico nel dettaglio, modificando il codice, bisogna quindi risolvere il problema della comunicazione. Una volta stabilite le strutture di comunicazione da usare per documentare il funzionamento del progetto, il progetto decisionale che ha portato a definire le specifiche funzionali, le idee dietro lo sviluppo del codice, allora si può iniziare ad addentrarsi nella modifica del codice.

Quali sono questi strumenti di comunicazione, che determinano con così tanto margine la riduzione del debito tecnico?

I test di behavior: test automatici che verificano il funzionamento di una feature a un livello molto alto (es. Usando il browser in un prodotto web). Oltre al loro valore come test, sono di solito; semplici da capire e rivelatori sulle intenzioni dello sviluppatore

Il codice stesso

I commenti e la formattazione del codice. Anche una semplice riga vuota tra due blocchi di codice può comunicare molto (ad esempio che i due blocchi si occupano di due fasi distinte del processo);

La nomenclatura di variabili, oggetti, metodi e funzioni. Chiamare una variabile “valore” non dice molto su cosa contiene, un metodo “calc” non sta dicendo molto su cosa stia calcolando;

Gli errori: lanciare errori con una descrizione dettagliata di ciò che succede può salvare ore fra sei mesi o un anno, quando quell’errore sembrerà apparire dal nulla e rompere un processo che non dovrebbe rompersi;

Di nuovo sugli errori: non c’è cosa peggiore che non lanciarli. La situazione peggiore è quando niente si rompe ma non c’è nessun risultato (es. Vedo la pagina “acquisto riuscito” ma non ho comprato nulla). Gli errori servono, non vanno evitati.

Il version control system. Un commit su Git scritto bene può essere lo strumento più prezioso quando bisogna risolvere un bug incomprensibile, o quando si incontra una riga di codice oscura.

La documentazione tipica “di progetto”: procedure di setup, di deploy, di creazione di nuovi ambienti, per l’esecuzione dei task di sistema, e così via;

Chat/gruppi aziendali come slack o forum. Hanno uno storico persistente e possiamo usarle per tenere traccia di discussioni sul processo decisionale;

e ce ne sono tanti altri, alcuni più ovvi e alcuni meno.

Così facendo, si sfrutta il debito tecnico per costruire qualcosa di nuovo, una base di partenza che permetterà la condivisione della conoscenza tra gli sviluppatori (presenti e futuri) e un ponte di comunicazione tra l’owner della piattaforma e gli sviluppatori della stessa.

Con gli strumenti di comunicazione pronti, si procede ad analizzare il progetto come se fosse un ritrovamento archeologico, documentando ogni reperto e cercando di dare una spiegazione ad ogni elemento.

La vera pulizia di codice dovrebbe poi essere fatta per gradi, man mano che si sviluppano nuove funzionalità o che il tempo passa. Riscrivere un prodotto non è quasi mai una buona idea, perché nella riscrittura si perderanno tante specifiche “implicite”, tante feature nascoste che però permettevano il funzionamento che conoscevamo.

Solitamente è più conveniente per tutti se si pulisce ciò che si ha intorno. Avviare un processo di refactoring massiccio pone tutta una serie di problematiche:

Richiede un budget sostanzioso

Richiede che gli sviluppi cessino mentre si effettua la pulizia

Aumenta la possibilità di generare bug perché potremmo pulire feature che non comprendiamo a pieno e che non verranno testate in tutti i loro casi limite

Immaginiamo di avere casa in disordine e che ci siano ospiti in arrivo (comprare una casa nuova e vendere la vecchia non è un’opzione). Se cerchiamo di pulire tutte le camere insieme c’è il rischio che gli ospiti arrivino e la casa sia ancora in disordine, o che dobbiamo accontentarci di una pulizia sommaria. Ha più senso ignorare per ora le stanze che probabilmente non visiteranno come la camera da letto, e concentrarci su soggiorno e sala da pranzo. Allo stesso modo si può procedere con il refactoring. Si scrivono le parti nuove usando gli strumenti di comunicazione definiti e ogni punto dell’applicativo vecchio che viene toccato deve essere pulito e aggiornato al nuovo standard.

Individua le criticità della tua applicazione e scopri come affrontare un intervento di software remodeling.

Un approccio pratico

L’esperienza ci ha insegnato a procedere con metodo quando veniamo contattati per rifattorizzare, aggiornare o mantenere applicativi esistenti.

Quando veniamo contattati, il primo passo è una Code Inspection, per valutare la situazione. Eseguiamo un’analisi sul codice, facendoci un’idea di quali sono i colli di bottiglia sulle performance, i punti del codice più difficili da leggere o da modificare, le vulnerabilità di sicurezza, quale documentazione manchi. Come risultato consegniamo al cliente una documentazione che descrive cosa abbiamo trovato e quali passi il cliente potrebbe intraprendere per migliorare la situazione.

A questo punto spetta al cliente decidere se far seguire la code inspection con l’avvio di un processo che miri a migliorare la base di codice. Se questo processo parte, si passa alla creazione di un team:

Se esiste già un team tecnico con una certa seniority i nostri sviluppatori di solito si integrano nel team;

Se esiste già un team tecnico composto da sviluppatori giovani cerchiamo di solito di lasciare i nuovi sviluppi al team esistente, magari integrando un mentor. Mentre un secondo team composto da specialisti si occupa della maintenance;

Se non esiste un team tecnico ne forniamo uno noi;

Alla definizione del processo di rilascio:

Nelle situazioni peggiori non è possibile prescindere da un team di operations;

Se puntare a rilasci continui (è ciò che consigliamo quando non vi sono controindicazioni) o schedulati in milestone;

E alla definizione delle cerimonie e degli strumenti di comunicazione: questo passo dipende molto da cliente a cliente. Un esempio potrebbe essere il seguente:

Standup di 15 minuti ogni mattina alle 10:00

Review meeting di 30 minuti ogni mercoledì alle 15:00

Planning meeting di 30 minuti ogni mercoledì alle 15:30

Rilascio in produzione ogni giovedì alle 02:00

Retrospettiva e report ogni primo venerdì del mese alle 17:00

Creiamo le definizioni di Completo. Esempio:

Perché una feature possa essere rilasciata in staging deve:

Contenere test automatici

Ricevere una Code Review da un collega

Essere documentata nel Changelog

Avere un test d’integrazione

Perché una feature vada in produzione deve:

Essere approvata dal Product Owner

Essere tradotta

Perché un bugfix sia rilasciato deve:

Avere almeno un test che descriva l’assenza del bug

Solo a questo punto si parte con l’operatività. L’obiettivo è di rendere l’applicativo stabile, raggiungendo quel punto di equilibrio tra crescita e stabilità nel quale non siamo rallentati negli sviluppi e riusciamo a mantenere un debito tecnico basso.

Nel tempo ci ritroviamo a ridurre man mano la dimensione del team che allochiamo sul progetto perché:

La mole di test automatici riducono le regressioni ad ogni nuovo sviluppo;

Il codice diventa più leggibile e più facile da gestire;

Gli sviluppatori più giovani imparano come scrivere codice con un debito tecnico ridotto o assente.

Il benessere che si crea a seguito di questo processo permette quindi di effettuare modifiche più facilmente. Allo stesso tempo crea anche una nuova classe di sviluppatori, più virtuosi e più attenti a certi temi. Alla fine questo processo diventa parte della cultura aziendale.

Leggi l'articolo in inglese pubblicato su Mikamayhem, il blog dei Developer di Mikamai.

Contattaci per una analisi della tua applicazione o per un confronto sul nostro metodo di lavoro.

Articolo scritto da Nicola Racco

!function(f,b,e,v,n,t,s) {if(f.fbq)return;n=f.fbq=function(){n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)}; if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0'; n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0]; s.parentNode.insertBefore(t,s)}(window,document,'script', 'https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '475678749439170'); fbq('track', 'PageView');

#Debito Tecnico #sviluppo web #mikamai

0 notes

mikamaiblog · 7 years

Text

La Q in QA: come assicurare la qualità del codice

La qualità del codice è un obiettivo elusivo. Inizialmente accordarsi sugli standard da rispettare sembra semplice, ma gli strumenti per produrre un codice di qualità sono molteplici, proprio come le opinioni e i punti di vista. Oggi parleremo di Quality Assurance e in particolare del processo di code review (CR). Tale processo viene effettuato in pairing e consiste nella valutazione del codice scritto da uno sviluppatore da parte di un suo collega, con l’obiettivo di individuarne i difetti e i possibili miglioramenti. Da Mikamai, abbiamo introdotto la code review alcuni anni fa per migliorare il nostro processo di QA; questa pratica ci ha portato molti vantaggi e siamo pronti a condividere la nostra esperienza personale rispondendo ad alcune tra le più diffuse domande (FAQ) su questo argomento.

Qual è il vero scopo del processo di CR?

Il processo di CR non dovrebbe mirare principalmente alla correttezza del codice, ma alla sua leggibilità, alla sua manutenibilità e alla sua consistenza. Ha inoltre un valore educativo. Da questo punto di vista la CR si differenzia dal pair programming. Mentre lo scopo educativo del pair programming è quello di incoraggiare il passaggio di conoscenza e di capacità di problem-solving tra i membri di un team, la CR serve principalmente per educare un team a rispettare gli standard che il team stesso si è prefissato. Per riuscirci, la CR deve essere equa e aperta e gli standard del team devono essere stati concordati e accettati da tutti i membri. Se vuoi approfondire, puoi leggere questo interessante articolo sul processo di code review.

Cos’è più importante: scrivere i test o fare code review?

Risposta breve: entrambe. Si, la CR può individuare alcuni errori di base o alcuni punti in cui il codice non funziona come dovrebbe. Tuttavia, il codice dovrebbe arrivare alla fase di CR solo quando è stato già testato ed è pronto per essere messo in produzione. Inoltre, dato che anche i test automatici sono fatti di codice, dovrebbero ugualmente essere soggetti alla review, che in alcuni casi può anche rivelare eventuali problemi architetturali. Una CR può mettere in evidenza se la test coverage è adeguata o se certi casi limite del funzionamento sono stati presi in considerazione durante la scrittura dei test. Come fare manutenzione e refactoring del tuo applicativo.

E il codice legacy?

Visto che il problema del codice legacy è proprio la mancanza di test, è legittimo chiedersi quale sia un modo sicuro e attento alla QA per metterci mano. Un problema che sicuramente molti di noi si sono trovati ad affrontare. Il primo consiglio è quello di introdurre i test ogni qualvolta sia possibile: il refactoring e l’aggiunta di nuove feature dovrebbero essere accompagnati dai propri test, mentre un cambiamento piccolo o grande di un pezzo di codice pre-esistente può fornire la possibilità di dare un po’ di copertura a comportamenti precedentemente non testati. Anche se tutto ciò può apparire scontato, non è sempre fattibile. Inoltre, anche nel migliore dei casi, le regressioni sono sempre in agguato nelle parti di codice non testate. I test manuali sono spesso l’ultima risorsa in questo tipo di situazioni, ma la CR può essere utile? Anche se, come abbiamo già spiegato, la CR non sostituisce i test, se il reviewer conosce bene il codice legacy, può comunque essere utile per individuare eventuali inconsistenze o funzionalità che non rispettano più il comportamento desiderato, a causa di incongruenze tra il codice nuovo e quello pre-esistente. Leggi l'articolo originale in inglese scritto da Cecilia Nardini e pubblicato su Mikamayhem, il Blog dedicato ai developer di Mikamai.

Come fare manutenzione e refactoring del tuo applicativo.

#QA #quality assurance #CR #code review #web development #mikamai #mikamayhem

0 notes