Come ho cambiato lavoro (Prequel di: com’è lavorare da remoto?)

Vi ricordate che ho cambiato lavoro? E’giunto il momento di parlarne un po’.

Per chi lavori?

La mia società si chiama Bemind e, a parte il fatto di sentirci molto fighi per il fatto di essere Beminders, per ora non siamo molto presenti sul web. E’ una società molto giovane nata dall’idea di un CEO che un bel giorno ha detto: io non voglio fare il dipendente di nessuno. Se il CEO vuole palesarsi su questo blog, a disposizione!

logo_bemind_grande

Come vi siete conosciuti?

Questo è un argomento sottovalutato da molti, eppure secondo me è fondamentale. Circa un anno fa ho trovato un loro annuncio non sui soliti siti noiosi, ma su posti interessanti come Stack Overflow e LinkedIn (primo punto a loro favore).

L’annuncio non era il solito listone di competenze da possedere, bensì spiegava per sommi capi che tipo di persona cercavano, quindi un “search by personality”; Mi ha colpito il fatto che non mi è stato richiesto di inviare un curriculum, bensì una lista dei tre libri tecnici più interessanti che avessi letto, oltre a una breve descrizione del perchè li avessi trovato interessanti. Poi è seguita una call in cui ci siamo effettivamente conosciuti.

Purtroppo in quella occasione cercavano una figura più “part time”, visto che il progetto che stavano realizzando era ad alto rischio, e non avevano garanzie che prendesse piede (spoiler: ha preso piede). Così mi chiesero di risentirci più in là nel tempo.

Una persona normale avrebbe dimenticato l’episodio e sarebbe andato avanti, ma io ho avuto un presentimento molto positivo dopo quella call. Periodicamente li ho scritti chiedendo info dal punto di vista tecnico, specialmente sui microservizi (su cui ci siamo scambiati feedback e libri) e su altri eventi tecnici nazionali. Ad esempio, ho sentito parlare di un framework per microservizi chiamato Apollo (di Spotify) e loro mi hanno risposto con un progetto con una filosofia molto simile, Spark.

Dopo circa 6 mesi in cui ci siamo sporadicamente scritti, principalmente scambiandoci opinioni su argomenti tecnici, ecco che vengo ricontattato dal mitico CEO che mi chiede se sono ancora disponibile a lavorare con loro.

Cosa fai?

Il mio ruolo principale è lavorare alla diffusione di Gestpay di Banca Sella, il gateway italiano per i pagamenti. Se avete un e-commerce, una startup, o rivendete servizi e avete bisogno di accettare pagamenti dai vostri utenti, Gestpay è LA soluzione, che stiamo completamente rinnovando. (Ne esistono anche altre: di sicuro conoscerete Paypal, e noi siamo loro partner nel senso che potete accettare pagamenti anche attraverso di loro, oltre che con le carte di credito, e ricevere i soldi nella stessa dashboard).

Nei prossimi giorni pubblicherò l’articolo che ho già scritto: com’è lavorare da remoto

Com’è lavorare da remoto?

Prima di parlarvi di come lavoro da remoto, se non l’avete ancora fatto, leggete la prima parte: per chi lavoro e cosa faccio.

Basta Michè, hai fatto un prequel che è durato sei mesi. Vuoi spiegarci o no com’è lavorare da remoto?

Lavorare da remoto è … meglio.

il telelavoro (quanto è anni ’90 sta parola?) nasce da una consapevolezza: è possibile lavorare da casa a progetti seri, veri, con la stessa qualità di un lavoro d’ufficio.

Ciò significa anche che si possono gestire gli orari diversamente (io ancora non riesco a crederci e sto lavorando 9-18, comunque), così come il posto di lavoro: dei remote workers che conosco, pochi lavorano davvero da casa e quasi tutti preferiscono incontrarsi da qualche parte (spazi di coworking) per poter avere intorno qualcuno con cui prendere un caffè.

Dal punto di vista qualitativo, ho accettato questo lavoro anche perchè stavolta non sono più un mero esecutore di idee altrui, bensì posso proporre e realizzare una mia idea. Inoltre l’idea di lavorare da remoto mi ha permesso di iniziare una vita più serena, ad esempio facendo sport ed evitando 2 ore di autobus per raggiungere Napoli ogni giorno.

Dal punto di vista quantitativo non ho notato nessuna differenza in termini di “quanto” lavoro: io dico sempre che quando c’è da lavorare di più, lo faccio, purchè non sia uno “straordinario permanente”. Mi è capitato di rimanere fino alle 19.30 incollato ad un problema, perchè se staccavo avrei perso il filo il giorno dopo. Ma l’ho fatto in totale autonomia e forse i miei capi non sanno nemmeno che è successo.

Da un punto di vista organizzativo, stiamo cercando di organizzarci e rendere la vita più facile a tutti, sia noi che lavoriamo in remoto sia coloro che seguono il nostro lavoro, quindi per ora stiamo usando:

  • una sottoforma di Scrum, implementato via software tramite Jira
  • Slack è uno strumento irrinunciabile per gestire la comunicazione tra team, non solo per le chat, ma anche per sentirsi a voce e per, ehm, cazzeggiare.
  • Github e Git per il codice: che imbarazzo i primi tempi quando mi chiedevano di fare “pull sul branch”, e io fino al giorno prima avevo lavorato con SVN.
  • la suite di Google Docs per email, documenti e file e qualche volta conferenze con hangouts.
  • Spotify aziendale. Questo è uno dei benefit che gli altri mi invidiano di più, eppure costa 3€ al mese :p

Per il resto, massima libertà di scelta dei tool (ad esempio io uso molto Visual Studio Code, mentre i colleghi usano WebStorm), della serie “se ti serve, usalo”.

La mia preoccupazione più grande, comunque, è di trovare il modo di riportare ai miei colleghi (e capi) quello che sto facendo, le decisioni che sto prendendo, etc etc. 

Cosa serve per lavorare in remoto?

  • Essere autonomi: se hai problemi devi essere bravo a risolverteli da solo. Sia chiaro, se chiedi aiuto a un collega è molto probabile che ti aiuterà (io stesso rispondo a chiunque mi chiede una mano) ma è difficile sistemare un problema se si è seduti a 800 km di distanza. Quindi, la capacità di ragionare e di risolversi i problemi da soli diventa fondamentale.
  • Sempre sull’autonomia, può capitare che per proseguire il lavoro serva la risposta di un collega, che in quel momento è impegnato in una riunione: piuttosto che stare con le mani in mano è opportuno portarsi avanti, magari ragionando sui prossimi task.
  • Essere onesti e ragionevoli: quando si parla di stime non ha senso mentire, e lo stesso vale sui problemi che si potrebbero incontrare. Una cosa che in genere richiedono ai remote workers è di avere una forte personalità e di “lottare per le proprie idee“.
  • Ogni tanto è imporante vedersi: io cerco di incontrare gli altri “resident” del gruppo ogni 3-4 mesi, ma questo dipende un po’ da ognuno.

Lo consiglieresti a chiunque?

No, penso che il lavoro remoto debba essere un po’ una scelta e un po’ una conquista.

All’inizio della propria carriera è importante conoscere il mondo del lavoro tradizionale: avere dei colleghi, un capo, delle regole da rispettare (anche sul dressing code!) ti permette di capire se questo è il mondo che fa per te. Ne ho conosciute di persone che si lamentano, eppure l’azienda è la loro vita.

Inoltre, un giovane ha bisogno di “mentori” che possono indirizzarlo nelle scelte o comunque consigliarlo rispetto a dove sta andando il mercato. Per un telelavoratore tutto questo potrebbe non esserci.

E non dimentichiamo la solitudine: se ne soffri, telelavorare non è sicuramente per te.

Le aziende tradizionali scompariranno? Lavoreremo tutti da casa?

Non credo proprio, altrimenti non sarà più così figo lavorare da remoto 🙂

How to log a PHP Soap call with NuSoap

I am doing some debugging in PHP for Gestpay.

Gestpay is an italian system that allows to accept payments from customers, all over the world. If you have an e-commerce and want to try something (in my opinion) way more powerful than other systems, you should definitely check this out.

So, today I had to send a php SOAP call to Gestpay, but for some reasons I was doubting that the actual xml contained exactly what I was sending.

We are using NuSoap, a PHP library that allows to use SOAP on old versions of the language, as old as 4.x, and that does not have any external dependencies, so it should work with a great number of hostings. You may feel better using something more powerful and modern.

Back to our question: how do you show the NuSoap call?

Here it is:

And you’ll see something the output of your code to something like …

I found this tip on stack overflow… I’m sticking it in my blog because I’m sure I’ll need it in the future!

My very personal Javascript Fatigue: the truth about JS testing

Trying to write this post as a 2007 blog post: personal, not so politically correct. (I’m not involved in JS politics by the way)

Well, In 2007 I was already studying JavascriptHTML and CSS, and I vividly remember that I HATED the web world because different browsers were doing crazy stuff for the same instruction. These were the good ol’ HTML 4 days.

I was pretty wrong. Browser apps are everywhere.

I have worked with a lot of javascript till now, I have also started a Javascript Meetup here in my home town, Salerno. I have mentored and teached people about NodeJS. I have explained the story of the single thread and the differences between browsers and servers … and still, there was something that I was missing.

Everybody talks, nobody really does it: TESTING

It’s very easy to say that testing is important, it’s just three words nonetheless. I have heard this a thousand times, from a bazillion of people. However, when I have asked to talk to me honestly about javascript testing, the answer was more or less:

nobody really does testing 

WTF? I have heard this from people that I respect, and at many companies where I was interviewed. Why?!

Our apps are not so big that you can’t test them manually 

Well, this can be an explanation, but not a great one.

I can’t find any resources about testing in javascript 

Uhm … we are reaching the point …

Testing in javascript is f***ing difficult 

Now that’s the truth, ol’ boy. Let’s dive into it.

testingdifficult

My personal testing jurney

I decided to revamp a very old project, written in Java and Swing (yes, it was a standalone application, that’s how computers worked in 2010). In 2016, since browsers can do better things than before, I have decided to rewrite everything in javascript and to write the frontend in something that is more mantainable.

I decided to write my stuff in angular 1 (I know it very well and since I have no spare time this was the only option for me). As a build tool, i have decided to use Gulp + Browserify. For those who don’t know what Browserify is, well, it’s a JS library that lets you import other javascript modules exactly like NodeJs (so, you would use require('./TimerService')  to import it in your file). This has given me the ability to decouple angular from the actual JS code. Another advantage is that I can test it better, since it’s only Javascript.

What about Gulp? Gulp is a build tool that can do a lot of stuff for you. I use it to trigger actions everytime I save a file, like running a syntax checker and convert my ES6 code to more archaic compatible ES5.

I also run my unit tests everytime I hit Ctrl+S  (save).

How do you write unit tests in Javascript?

It would be great to just say, “use this!” and we’re happy. In Javascript there are many libraries that are competing in the same space that there is no clear winner. I had to choose something that was well supported, well documented and used. I don’t know if they are the best for every scenario, but since my time is limited, I am using these because they were the first result on Google they worked at the first attempt.

One library? NO! In JS, at least for browser testing, you need:

  • a test runner, like karma
  • a library to actually write the tests, like mocha
  • an assertion library, like chai

WTF, again? 3 libraries to do something that JUnit  (for Java) does alone ?? This is an example of the over-populated, github-based, quality-variegated NPM package manager.

These 3 pieces of software still don’t have many years of maturity on their shoulders, and are not immune to bugs (which are promptly resolved, however). I have found one in mocha, for example, and I could not figure out until I upgraded.

Once you understand how to use these three libraries, then you have to actually write tests for your application: I don’t have words to describe how difficult is to test a function that uses multiple  setTimeout()  in the code (it’s an audio player, and deals with timing…). And now my next step in this journey is to mock stuff.

Another discovery I want to share with you (well, it’s not a discovery, since it’s on chai ‘s web page): you can check the test correctness in two ways, the  assert way (like the one used in JUnit), or via a “behavioural” testing definition, something like “ expect(this).to.be.greaterThan(that) “. two syntaxes for the same thing.

Moral of this story rant

Do we really need testing in Javascript? I believe that yes, testing is fundamental as the application grows, and expecially if you want to do some refactoring that has some sense.

Should it be this difficult to test stuff? No.

At some point in the future, testing JS will be easy like every other language in the programming world. Modern languages born with testing capabilities built in, and Javascript is so old that testing was just not cool to think about it.

So, if you believe that your application will be refactored some time in the future, if you don’t want to become crazy, test it. Test it now. Run tests every Ctrl+S . This is the only way to be sure that things will not break up. Js is a dynamic language, it’s not statically typed, and IDEs do not do type checking for you. Help yourself with testing.

And finally, when testing will be cool again, you can say you were already doing it when stuff was being developed. You can talk like a good, ol’ Testing Granpa.

Progetti a cui lavoro: HYPE – carta di credito, conto bancario, app. 3 in 1!

Uno dei prodotti su cui lavora la mia azienda é Hype.

Hype é molte cose: una carta di credito con IBAN, quindi é anche un conto bancario, e si gestisce tramite un’app che ha delle funzionalità avanzate.

“Tutto qui? Ce ne sono centomila come Hype!” vero, e siccome io non vivo nelle caverne e maneggio soldi e carte di credito sfortunatamente più per spendere che per incassare, ecco la mia opinione a riguardo.

hype-logo

Ovviamente si dovrebbe aver capito che lavoro per loro, anche se non lavoro direttamente su Hype; se non fossi stato convinto della bontà del progetto non ne avrei mai parlato spontaneamente.

Hype é un progetto in cui crediamo molto, nato da una collaborazione tra Banca Sella e noi di Bemind.

Innanzitutto é totalmente gratuito, nella sua versione starter.

La registrazione e l’attivazione si può fare dalla app per cellulare, e ci siamo inventati un metodo super fico per evitare di farvi firmare cataste di documenti (tipici dell’ambito bancario) e poi spedirli: un Selfie con un documento di riconoscimento, e voilà, la carta sarà a casa vostra nel giro di un paio di giorni.

l’attivazione della carta con il selfie l’ha introdotta anche Unicredit, ma poi c’è sempre un passaggio in banca per poterla attivare. +1 per noi!

Nel frattempo, una volta approvata la richiesta di apertura del conto (in genere 10 minuti durante l’orario di ufficio), potete già utilizzare l’app da cellulare che é funzionante all 100% e con la quale potrete effettuare bonifici, inviare soldi, ricaricare, etc.

Funzionalità ovvie

Nella sua versione base, Hype é una carta ricaricabile e un conto bancario. Quindi può essere ricaricata via bonifico (ci vogliono 1-3 giorni…)  o via carta di credito (istantanea). Le ricariche sono gratuite.

controlate sempre la data in cui ho scritto questo articolo e verificate che le condizioni contrattuali siano quelle che descrivo io.

Le spese di prelievo sono gratuite dai Bancomat.

Stando ai foglietti promozionali, sono gratuiti anche i prelievi dai Postamat, ma questo non l’ho ancora provato / verificato.

Potete fare bonifici, pagare on line, o nei negozi, come se fosse una normale carta di credito prepagata.

Killer Features!

Con “killer features” si intendono quelle funzionalità che, una volta provate, diventano irrinunciabili.

Potete trasferire soldi tra carte Hype in maniera istantanea e senza costi, e i soldi vengono ricevuti istantaneamente (un bonifico con gli steroidi!). Immaginate ora quando andate in pizzeria e dovete dividere la spesa con la vostra comitiva… Non sarà più un incubo.

Postepay, ad esempio, è uscita adesso con questa funzionalità che noi avevamo già da un anno. E a noi è gratis.

Un’altra funzionalità indispensabile, per lo meno per me che sono uno spendaccione, sono gli obiettivi. E’ possibile impostare un’obiettivo (Es. assicurazione dell’auto) e una data di scadenza (es. gennaio 2017), un importo, e Hype provvederà a “nascondere” una parte del credito, ad esempio 2,5€ al giorno, così da arrivare all’obiettivo coi soldi risparmiati senza sforzi.

Che ve lo dico a fare …. ci hanno copiato anche questa funzionalità!

Altra funzionalità per chi è stato vittima di frodi telematiche: la carta è attivabile e disattivabile a piacimento, tutte le volte che si vuole. E’ possibile bloccare solo gli acquisti online, o solo quelli fisici, in modo da evitare che un malintenzionato possa divertirsi con i nostri soldi.

Per questo Hype è diventata la mia carta di riferimento per gli acquisti on line, e la attivo solo quando devo fare un acquisto, così sono sicuro che nessuno può fare macelli a mia insaputa.

Tutto qui?

Assolutamente no! Con l’appoggio di Banca Sella, sarà possibile pagare con hype su internet (tramite il loro gateway di pagamento, Gestpay) e nei negozi, senza neanche tirare fuori la carta di credito. Questo è particolarmente utile per i commercianti che vogliono offrire più possibilità di pagamento ai propri clienti, oltre ad avere alcune statistiche sulla propria attività (e i propri competitor…). Maggiori dettagli sul sito di Hype for business.

Spero di avervi convinto. La carta è perfetta per quei giovani che hanno bisogno di una carta per gestire i loro risparmi e le loro vacanze, ma anche per chi ha bisogno di trasferire soldi con i propri familiari e amici.

Attivare la carta è questione di minuti e, considerato che è gratuita, conviene farlo!

 

 

 

 

Come scrivere un annuncio di lavoro efficace (soprattutto quando hai poco budget)

L’articolo sul mio cambio lavoro ha riscosso qualche successo (wow!), e qualcuno mi ha chiamato per sapere dove fossi finito, che stessi facendo, etc.

In particolare una persona, dopo avermi contattato per farmi gli auguri, mi ha chiesto un aiuto: per il suo studio di comunicazione deve trovare uno sviluppatore full stack con caratteristiche “senior” ma non ha risorse, per così dire, infinite.

Così mi chiede: puoi aiutarmi a trovare uno sviluppatore con esperienza in [X, Y, Z]? Sono disposto a dargli una certa cifra [molto bassa rispetto al mercato].

Sarete d’accordo con me che “senior” e “cifra bassa” sono due cose che non vanno d’accordo.

Inoltre l’annuncio di lavoro era il solito mappatiello di sempre: cerchiamo sviluppatori che conoscano Java, JavaScript, Html5, Python, Ruby, SEO, etc (la mia descrizione non é la stessa dell’annuncio ma avete capito che si cercava un po’ di tutto e anche oltre).

A questo punto ho fatto notare al mio amico che, se cerca una figura del genere con un budget limitato, deve cambiare almeno un paio di cose.

Piuttosto che un senior (che costa tanto) punterei su un giovane capace: in Yahoo dicono di assumere non quelli che già conoscono le tecnologie più usate, bensì quelli che hanno ben capito le basi, così che dopo saranno capaci di imparare qualunque cosa con poco sforzo.

Inoltre un neolaureato (o comunque una persona alle prime armi) é più disposta a fare esperienza per uno stipendio più basso, in cambio però di un’esperienza di alto livello con le tecnologie più fighe. Tutto questo con la promessa che se diventa davvero bravo gli viene dato un aumento per allinearsi agli standard di mercato.

Questo mio amico ha una web agency che non fa lavori banali; scrivere un annuncio richiedendo un elenco di tecnologie é il modo migliore per far scappare qualunque aspirante. Io avrei riscritto l’annuncio così:

ciao, siamo la Web Agency […].  Ci occupiamo di questo e quello, siamo specializzati in sviluppo web ma anche di applicazioni mobile. I nostri clienti vogliono app belle da vedere, rapide e funzionali. Siamo sempre attenti agli ultimi trend e cerchiamo di offrire a chi lavora con noi la possibilità di imparare le ultime tecnologie del settore.

Stiamo cercando un giovane, anche alla prima esperienza, che voglia mettersi in gioco e aiutarci nel soddisfare i nostri clienti. Se pensi che il mondo del web ti piaccia, se pensi che le nuove tecnologie siano migliori delle vecchie, scrivici!
Offriamo: il tempo di crescere su determinate tecnologie + [budget annuale lordo].

Ecco, un annuncio del genere non lo vedrei male. Io sono per pagare bene il talento, ma quando ti offrono la possibilità di imparare qualcosa di nuovo che poi puoi rivendere anche ad altri, un minimo di compromesso soprattutto a inizio carriera ci può stare. É così importante aggiornarsi sempre, che se un programmatore non lo fa rischia di trovarsi fuori mercato alla prossima rivoluzione tecnologica (in genere ce n’é una ogni 10 anni, l’ultima é stata quella delle app… Quale sarà la prossima? Forse é il Cloud?)

E con questo passo e chiudo da Biella. Ciao!

Cambio Lavoro

Big news nella mia vita! Ho cambiato lavoro!

Siete curiosi di sapere come, perchè, quando, dove, ma dovrete attendere un po’ per tutti questi dettagli. Li sto ancora metabolizzando anch’io.

Volevo spendere qualche parola sul posto che ho appena lasciato, e provare a rispondere in parte a “perchè”..

Sono stato due anni fantastici in Engineering, e alla fine le persone che hai intorno diventano parte della tua famiglia. Anzi, le vedi più della tua famiglia, motivo per cui cerchi di andarci d’accordo più che puoi. Nel mio caso non mi sono dovuto sforzare poi molto, erano tutte persone decisamente ragionevoli 🙂

Quando ho deciso di cambiare lavoro sono stato il primo a domandarmi: ma come, lasci un lavoro fisso, in un posto tranquillo, con garanzie di futuro, etc.
Ammetto che non é la prima volta che faccio un salto del genere, da qualcosa di “sicuro” a qualcosa di leggermente più rischioso. Ma c’erano alcune cose che volevo urgentemente sistemare, prima che diventassero un problema.

Viaggiare per lavorare

La vecchia azienda non era proprio in un luogo felice. Dentro si, ma fuori no. Situata in una delle zone più complesse e industriali di Napoli, nel bel mezzo del nulla, per raggiungerla impiegavo circa un’ora di autobus ogni giorno (e poi ancora un’ora al ritorno). Dunque mi svegliavo presto e ritornavo tardi, soprattutto questo tempo mi sembrava profondamente sprecato.Per questo, uno dei requisiti che ho cercato nel prossimo lavoro é di limitare il più possibile gli spostamenti.

Metteteci poi che quelle poche volte che andavo in auto mi hanno rubato lo stereo (danno di circa 180€) e i copricerchi (danno di 80€)…

“Solo un’ora? Firmerei per poter lavorare a un’ora d’autobus!” – a me non stava più bene, non vuol dire che valga lo stesso per voi. Ho conosciuto gente che veniva a lavorare da ben più lontano e andava bene così …

Stimoli

Gli ultimi due anni li ho passati a conoscere profondamente il mercato dei software sanitari italiani, e ho visto da vicino le difficoltà di chi sviluppa e di chi usa questo tipo di SW che sono estremamente specialistici – si interfacciano con macchinari, stampano etichette, etc.. Non è esattamente roba per startup che vogliono disruptare il mercato, visto che servirebbe una conoscenza specialistica notevole.

Tuttavia c’è una costante che mi ha accompagnato nei primi quattro anni della mia carriera: sono sempre stato un “operaio” più che un progettista. In genere c’era sempre qualcuno che mi diceva cosa fare, e i margini di miglioramento / ottimizzazione di una funzionalità erano piuttosto limitati. Roba come interazione, design, ottimizzazione del backend, misurazione degli eventi dell’utente, sono tutte tematiche di cui ci si interessava poco. Perciò uno dei requisiti che avrebbe dovuto avere il mio prossimo lavoro è di darmi un grande margine di intervento su ciò che avrei fatto.

Uscire dal mondo “ONLY JAVA”

Da mesi sto approfondendo Javascript e tutte le tecnologie correlate – react, angular, nodeJS… . Ho addirittura fondato un meetup che sta avendo un discreto successo (pur rimanendo nei limiti Salernitani).

Ben conscio che nessun linguaggio è quello definitivo, ho notato che a Napoli una volta entrati in una fetta di mercato (inizi come sviluppatore Java? sarai sviluppatore Java a vita) è difficile uscirne. Inoltre Java è uno dei linguaggi più diffusi al mondo, quindi perchè provare a cambiare?

Secondo me non è il _miglior_ linguaggio del mondo, ha qualche pecca, anche se ammetto che è quello che conosco meglio e di cui ho esplorato maggiormente la vastità delle sue possibilità. Con Java ci ho fatto di tutto, dalle interfacce Swing, a interfacce web con GWT, ho esposto servizi SOAP e poi anche REST, insomma java java java …

Un altro requisito che mi ero imposto era di spaziare il più possibile in un’altra direzione rispetto a Java. In fondo, programmare mi piace ancora tantissimo.

Per finire …

Me ne sono andato venerdì 17, non proprio il miglior giorno per salutarsi 😅 . Giocava Italia-Svezia, era la pausa tra primo e secondo tempo. Ho chiesto di uscire due ore prima, come non accontentare la richiesta di un ormai ex dipendente? Così, mentre Conte pensava a quali sostituzioni effettuare nella nazionale per rafforzare la squadra, io uscivo da Eng non senza emozioni, salutando tutti calorosamente.

Neanche il tempo di pensarci che la nuova avventura è già iniziata. Si ricomincia!

Flow e Typscript: Type checking per Javascript

ho trovato questo interessantissimo link sulla differenza tra Flow (di Facebook) e Typescript (di Microsoft). Vi consiglio di dargli uno sguardo perché sono slide che si capiscono (rarità!).

Entrambi sono ottimi tool che permettono di portare il vostro codice JS a un altro livello.

flow-hero-logo

Flow è un type checker “offline”, nel senso che è un tool da linea di comando che controlla se avete commesso errori di tipo (es. assegnare un numero a una stringa). Ovviamente esistono plugin per i migliori editor, e tante altre facilities (babel,, webpack…)

Typescript invece è un vero e proprio linguaggio, superset di JS; questo codice viene poi compilato in JS con tutti i crismi e i carismi.  Anche qui c’è tanto supporto da parte dei tool.

La differenza più importante però ve la dico io. Flow non è (ancora) supportato su Windows. Esistono port non ufficiali, ma ci vuole ancora un po’ per un supporto completo.

Avrei voluto utilizzare / provare Flow, proprio perchè posso integrarlo man mano che ne ho bisogno nel codice già scritto, piuttosto che Typescript che invece richiede proprio di ridisegnare il proprio build set. E qui a lavoro ho solo una macchina Windows.

In ogni caso, sono entrambi grandissimi pezzi di software che semplificano la manutenzione di codice complesso, quindi vi consiglio di usare il migliore dei due per i vostri compiti, soprattutto se avete una webapp complessa da cui dipende la vostra vita lavorativa.

Visual Studio Code, l’editor che mancava per JS e Node

Visual Studio Code è l’editor/IDE Javascript definitivo. Lo so, mi sto sbilanciando, la concorrenza è tanta, ma ha alcune feature essenziali a costo quasi zero. E pensare che è sviluppato e sponsorizzato da Microsoft ! Chi l’avrebbe mai detto 5 anni fa?visual-studio-code

Ecco una guida su come installarlo per le mie esigenze:

Scaricare Visual Studio Code

Ovviamente scaricarlo dal sito ufficiale (per Windows, Mac, Linux…)

EsLint

Installare EsLint e il suo plugin per VS. EsLint è un un syntax checker e inoltre permette di evitare una serie di bad practice riconosciuti dalla community nel corso degli anni. Per installare EsLint globalmente, se non l’avete mai installato:

A questo punto recatevi presso la directory del vostro progetto su cui volete eseguire EsLint e lanciate il comando

Ora che abbiamo installato il tool, integriamolo col nostro editor: in VS lo si fa aprendo la finestra dei comandi rapidi ( Cmd + P ) e scrivendo ext install vscode-eslint . Riavviate Visual Studio Code se non volete comportamenti strani.

(Ho riscontrato a mie spese che VS non richiede il riavvio dopo l’installazione di plugin, però poi si incarta se non lo fai. Quindi fatelo.)

La Console

Per aprire il terminale nella directory corrente basta un semplice Cmd + Shift + C .

Typings

Typings è un package di Node che permette di avere un aiuto contestuale man mano che scriviamo. Dal sito web non si capisce benissimo, è scritto in maniera piuttosto oscura, ma è un enorme raccoglitore di API per tutte le librerie JS più diffuse. Se siete programmatori Java, VS sta provando a fare quello che faceva Eclipse con i Javadoc.

Fate una prova ora che typings non l’avete ancora installato. Provate a creare un file in VS scrivendo:

Visual Studio senza Typings

Senza Typings, Visual Studio prova a dare un aiuto, ma non ci riesce veramente: Infatti tutto quello che viene mostrato in console non serve a nulla.

Bene, proviamo ad aggiustare questo comportamento. Facciamo sì che VS ci restituisca suggerimenti utili quando proviamo a usare metodi dei nostri oggetti. Per farlo installeremo Typings:

poi dobbiamo installare le definizioni di Node:

Manca un passaggio nascosto, ossia bisogna cliccare sull’icona a forma di lampadina in basso a destra, per creare un file di configurazione dell’IDE, che permette di abilitare la magia.

visual-studio-magic

cliccando su quest’icona verrà creato un file di configurazione dell’IDE, voi non dovete fare nulla se non salvarlo e riavviare.

Riavviate Visual Studio, che a questo punto è già configurato per funzionare con Typings, et voilà!

un esempio di suggerimento contestuale che è davvero d'aiuto.

un esempio di suggerimento contestuale che è davvero d’aiuto.

C’è tutto un mondo di altre opzioni e possibilità da esplorare con VS, ad esempio Git, o l’esecuzione in debug di app, ma il tempo è tiranno come al solito quindi ne parleremo in futuro! 🙂

Gestire le dipendenze frontend con… bower

Avete un progetto web che include molte librerie esterne (angular, moment, jquery…)? Aggiornarle, gestirle e censirle sta diventando un problema? Nel corso degli anni sono usciti molti tool per la gestione delle dipendenze, e questo vale per ogni linguaggio di programmazione esistente al mondo; per il frontend una delle soluzioni più semplici da implementare è bower che con pochissimo sforzo si configura anche negli ambienti più ostici.

bower-logo

Bower!

Bower è un gestore delle dipendenze frontend, ossia gestice i file .js, e funziona in modo molto simile a Maven (se venite da tecnologie Java). Con bower è possibile definire un file (chiamato bower.json ) in cui vengono inserite tutte le dipendenze della nostra webapp e gestirle con pochi  comandi. Obiettivo? ridurre la complessità, semplificare gli aggiornamenti, vivere più felici con il proprio team 😀

Per installare bower come prerequisito bisognerà installare NodeJs, dal sito nodejs.org.

Nerd Alert! per poter usare bower e/o Node vi servirà un po’ di dimestichezza con il terminale. Tutti i comandi che vedrete qui andranno lanciati da linea di comando.

Successivamente:

npm  è un package manager di NodeJs, ossia un tool da linea di comando che permette di installare programmi, dipendenze, librerie, etc. Il comando install si preoccupa di scaricare il pacchetto specificato, bower , e con l’opzione  -g  stiamo dicendo che bower deve essere installato globalmente (dunque sarà disponibile da qualunque path del terminale).

Non mi addentro in ulteriori spiegazioni su npm, perchè può fare molto di più se lavorate con NodeJs (addirittura c’è chi lo usa al posto di bower!), prometto di ritornare su npm in futuro.

Una volta installato bower è molto facile iniziare ad utilizzarlo: dal sito http://bower.io/search/ si potranno ricercare pacchetti (es. angular, moment…) e se ci interessano basterà digitare da linea di comando

Per installare la versione di angular più recente.

Se invece vogliamo installare una versione specifica, possiamo scrivere

Usare Bower like a “pro”

Quello che abbiamo visto fino ad ora riguarda dipendenze “one shot”; di solito noi vorremmo poter catalogare tutte le dipendenze della nostra webapp così da condividere con i colleghi solo il file delle dipendenze. Insomma, piuttosto che intasare SVN o Git con migliaia di file esterni, identici ad altri già presenti on line, scambiamo solo il file bower.json e chiediamo a bower di scaricare le dipendenze per noi.

Se vogliamo seguire questo approccio, lanciamo il comando  bower init  all’interno della cartella che contiene il nostro progetto, rispondiamo alle domande che bower ci fa (nome del package, autore..) e successivamente avremo uno scheletro di file bower bello e creato.

Ora che abbiamo creato un bower.json qualsiasi, possiamo scaricare e salvare una dipendenza usando il comando

che oltre a scaricare angular all’ultima versione disponibile, lo inserisce anche nel bower.json.

Un caso pratico

A lavoro ho creato un progetto “base” che dovrà servire come punto di inizio per le prossime webapp che andremo a sviluppare. Contiene principalmente angular, jquery e qualche altra libreria creata da noi (quindi è interessante vedere come integrare in bower librerie aziendali, private).

Per creare questo progetto ho per prima cosa creato un file di configurazione che si chiama .bowerrc (notate il punto all’inizio). Serve a dare istruzioni di carattere “generale” a bower. Non è obbligatorio se vi stanno bene le configurazioni di default.  Eccolo:

Queste impostazioni sono tipiche in una realtà enterprise dove c’è un proxy da configurare. Provo a spiegare le più importanti:

  • directory: specifica in quale directory andare a scaricare le dipendenze esterne. Ad esempio, se importiamo angular, la troveremo in lib/angular .
  • proxy e https-proxy: se avete qualche proxy impostato per accedere a internet, cosa assolutamente normale in ambienti aziendali, li configurate così.
  • no-proxy: se ci sono host da raggiungere che fanno parte della rete locale, e che dunque non devono passare per il proxy, si possono specificare qui.
  • strict-ssl: se il vostro SVN o Git privato è raggiunto in modalità https, è molto probabile che il certificato non sia validato da un’autorità riconosciuta. settando questo flag a “false”, bower ignora i controlli di validità sul certificato.

Questo file  .bowerrc  può andare sia nella home dell’utente sia nella home del progetto, dato che sono impostazioni globali. Bower quando va sui repo cerca il file .bowerrc  più vicino andando a vedere prima nella directory corrente, poi in quella superiore, etc. fino alla home utente.

Superata questa prima fase di configurazione, che farete una sola volta, vediamo il file bower.json che contiene la vera e propria lista delle dipendenze:

name e version sono due attributi utili a bower per poter cacheare il pacchetto. private invece serve a evitare che il pacchetto venga committato per errore su bower central.

all’interno delle dipendenze vediamo i 3 tipi di dipendenze che ho utilizzato:

  1. jquery è uno di quei pacchetti presenti nel bower globale (raggiungibile a bower.io/search), quindi è specificato solo per versione;
  2. jquery-scrollintoview è un plugin di jquery e non esiste su bower central, ma solo su GitHub. Scrivendo litera/jquery-scrollintoview  lo stiamo andando a prendere da github. La versione è la #06834cf7fdba0e86cac84ed7761ea64a3a5fbec8  (che sarebbe l’hash del commit su github). Quando una dipendenza non ha versioni, è possibile fissare il download ad un commit specifico in questo modo.
  3. mylib non è una dipendenza presente nè su bower nè su github, perchè nostra, quindi ho specificato la sua versione con il path su SVN. Se il vostro repository inizia con http o https, bisogna aggiungere svn+  davanti all’indirizzo, altrimenti bower assume che sia un repository git. Se il nostro progetto è versionato in maniera standard, ossia con le cartelle branches , tags , e trunk , bower sceglierà la versione giusta andando a vedere se esiste un cartella in tag con quel nome. Dunque nel nostro caso andrà all’interno della cartella “tags” presente su svn e poi prende il contenuto della cartella “0.0.1” e farà il checkout da svn+https://<mysvnrepo>/frontend-libs/mylib/tags/0.0.1/.

Una volta che abbiamo specificato tutte le dipendenze che abbiamo, possiamo semplicemente lanciare un fantastico bower install  dalla root del progetto e bower si preoccuperà di scaricare tutte le dipendenze per conto nostro. Provare per credere!

Nel prossimo articolo: private-bower

In molte realtà aziendali, dipendenze esterne vengono versionate anche su server privati dell’azienda, o per renderne più veloce lo scaricamento, o perchè sono stati corretti dei bug in librerie open dunque le si vuole gestire internamente.

Con git e svn bower è già compatibile con la stragrande maggioranza dei repo globali, ma resta il fatto che bisogna scrivere in bower.json il path completo dei repository. Questa cosa fa un po’ storcere il naso ai puristi che vorrebbero gestire queste librerie in maniera trasparente (ossia, io ti dico solo la versione, e tu la vai a prendere dal mio server bower). Questo problema lo risolve un package chiamato private-bower, di cui spero di riuscire a parlare in un prossimo articolo (scrivere questo mi è costato 3 settimane, per mancanza di tempo!). Spoiler: facciamo puntare bower  da riga di comando al nostro server private-bower , che cercherà i pacchetti per noi; se non li trova li va a scaricare da bower.io  (il server centrale). Non resta che vedere come farlo.

Buona bowerizzazione dei vostri frontend!

Altre risorse:
Bower Getting Started – http://bower.io/#getting-started