Essere smart

Featured

Viste le recenti uscite sui social in materia di remote working, sento la necessità di condividere con voi una serie di pensieri e di considerazioni che mi frullano nella testa. Il momento storico è particolarmente delicato, la stretta morsa della pandemia si sta allentando e all’orizzonte vediamo la luce. Ma non solo, l’imminente (e chi lo sa in realtà) e totale apertura delle attività spingerà a fare i conti con una scelta tra un “ritorno al passato” o un vero e proprio “rinnovo”.

Nemmeno una pandemia riesce a farci cambiare per il verso giusto

Si leggono esternazioni su quanto i lavoratori dipendenti non siano produttivi o concentrati da casa e, allo stesso tempo, post in cui per alcuni le aziende siano considerate retrograde perché non capiscono il valore aggiunto della pratica del lavoro remoto. Vediamo anche forti critiche a realtà che hanno visto nella pandemia solo una costrizione a vivere una condizione a cui non erano abituate, accuse sulla loro necessità di avere totale controllo delle persone che operano in loco a discapito della salute delle stesse, considerazioni sugli sprechi che potrebbero essere evitati e via discorrendo. Ovviamente da una parte e dall’altra.

Il tono polemico e accusatorio assunto da ambo le parti non porta a nulla e la prima constatazione che mi balza in mente è che nemmeno una pandemia riesce a farci cambiare per il verso giusto. Vale probabilmente in tutti i contesti, ma soprattutto ora viene da chiedersi “perché non stiamo facendo analisi retrospettive sull’accaduto?”. È come se avessimo trattenuto il fiato fino a risalire in superficie e ritornare a respirare. La pseudo conversione culturale che abbiamo affrontato tutti quanti, volenti o nolenti, non è paragonabile a un soffocamento, anzi! È vero che in molti hanno sofferto, tanti non ce l’hanno fatta a superare il momento e tantissimi probabilmente rischieranno di perdere il lavoro. Purtroppo però non possiamo farci nulla direttamente, quindi, per chi ha avuto la fortuna e la forza di passare indenne questo paio di anni, perché non cogliere l’occasione per migliorarsi, per provare a cambiare, per capire le condizioni di tutti gli attori e per fare critiche sì, ma costruttive?

Ancora una volta si finisce sul concetto di cambiamento, non se ne può fare a meno. E nuovamente conflitti sui punti di vista, non per forza complementari ma di certo in contrasto per quanto riguarda il succo centrale della situazione: lavorare fuori dall’ambiente ufficio.

Un datore dovrebbe ragionare ad obbiettivi, ma siamo sicuri che sia sempre corretto affermarlo e che, tra l’altro, sia possibile in ogni caso applicare questo pattern? Un lavoratore dipendente dovrebbe garantire presenza ad orari fissi, indipendentemente da quello che fa, ma siamo sicuri che non ci sia una soluzione migliore? Chi é in team dovrebbe partecipare con gli altri membri nelle stesse fasce di orario, ma se i fusi orari sono differenti? Ho letto su alcuni post che “una grande azienda può definirsi tale se lascia decidere il miglior posto di lavoro al dipendente”, ma siamo certi che tutti i dipendenti vogliano questo e che, più in generale, sia una sentenza corretta in ogni caso? Non so, non ho di certo la conoscenza in mano, ma a mio modo di vedere frasi così dirette e sicure come si leggono qui e là lasciano il tempo che trovano, e si tramutano in critiche non costruttive simil-motivazionali, per fare un po’ di rumore sulle varie piattaforme. Ognuno é e deve essere libero di esprimere il proprio pensiero, ma allo stesso tempo deve essere pronto a ricevere commenti e, sperabilmente, ad affrontare una discussione.

Detto questo, datori e lavoratori dipendenti ne hanno vissute di cotte e di crude. Chi, come il sottoscritto, ha vissuto da entrambi i lati per anni, può capire quanto sia fondamentale eliminare quel muro che si viene a creare tra le parti. Un po’ come vale per DevOps, abbattere i confini, comunicare e condividere, fluidificare, scegliere insieme per il bene e il benessere di tutto e tutti, imparare di continuo dalle esperienze fatte, sono i mantra su cui ogni vita lavorativa dovrebbe basarsi ogni giorno.

Insomma, é vero che lo stress sta uccidendo chi si deve (talvolta) inutilmente recare sul posto di lavoro, spesso lontano. É altresì importante il fatto che il nostro pianeta risenta anche dell’emissione di polveri sottili derivanti dal trasporto autonomo. E infine, é ovvio che il tempo e le energie sprecati per viaggiare rendono chi lavora terribilmente meno performante. Ma vediamo anche l’altra faccia della medaglia: siamo sicuri che lavorare solamente da casa (o da dove ci sentiamo meglio) anche per stare con la nostra famiglia il più possibile, sia veramente la soluzione? Sicuri che la qualità di quel “vedere la nostra famiglia” sia così alta? Dobbiamo pur sempre lavorare e, almeno mio figlio, non é che abbia potuto godersi il suo papà così tanto. Allo stesso tempo, io ho visto in maniera sfocata la sua crescita, non presente mentalmente. Questo non genera stress? Siamo certi che il consumo elettrico, il riscaldamento invernale e il raffreddamento estivo aumentati nelle nostre abitazioni sia così poco dannoso in termini di emissione? Abbiamo tutti controllato che chi ci eroga energia non lo fa, ad esempio, con combustibile fossile? E in inverno, accendiamo magari stufe a pellet, la cui combustione non é per nulla ecosostenibile! Quelle stufe magari potevano starsene spente. Per chiudere, le performance sono migliori evitando gli sprechi della nostra energia in viaggio nel traffico, potendo magari risposare meglio, vero, ma il side effect del lavorare molte ore in più (perché se non si é disciplinati temo si finisca con il lavorare molto più tempo) é proprio quello di ridurre drasticamente le nostre capacità cognitive e di focalizzazione, fatto estremamente deleterio per chiunque lavori con ragionamento, pensiero e creatività.

L’idea è semplicemente basata sul pattern inspect and adapt, ovvero osservare con cura, capire e, sulla base dell’ispezione, adattarsi alla situazione.

Non dico che vi sia una soluzione definitiva e oggettiva. Non ho il sapere in mano, però mi sono fatto qualche idea negli ultimi tempi sulle persone che fanno parte della nostra realtà e i clienti che ho conosciuto. Come spesso accade, seguire la via ibrida, risulta essere la scelta più efficace ad un costo più che accettabile. Ibridazione ed elasticità sono due caratteristiche a mio avviso fondamentali quando si tratta di rapporto di lavoro e di base per poter parlare di smart (termine più che abusato e utilizzato in maniera errata) ma il tutto dovrebbe essere supportato da un modo di vivere l’azienda consapevole da parte di tutti i membri, dal vertice alla base. E una serie di strumenti collaborativi aiuta ancora di più nella comunicazione dello stile di vita in e con l’azienda. L’idea è semplicemente basata sul pattern inspect and adapt, ovvero osservare con cura, capire e, sulla base dell’ispezione, adattarsi alla situazione. Così facendo si ottiene una personalizzazione elevata sul lavoro delle persone, con un equilibrio tra presenza in ufficio e lavoro remoto, partecipazione in team e fusi orari differenti, il tutto a supporto delle esigenze aziendali e personali e supportato da strumenti collaborativi, come chat (slack, Teams, ecc.), strumenti per videoconferenze (zoom, Teams, meet, ecc.), strumenti di gestione attività e sviluppo (Azure DevOps, Trello, Jira, ecc.) e via discorrendo. In fin dei conti, è importante ascoltare le persone per metterle nelle condizioni di lavorare al meglio, a pro dell’azienda e delle persone stesse. Cosa meglio di una soluzione ibrida può supportare questo?

Concludendo, abbiamo gli strumenti, possiamo affrontare tutto quanto descritto con un cambiamento culturale graduale e non da farsi tutto e subito, dovremmo ridurre sprechi, aumentare il benessere delle persone e quindi anche quello aziendale. Con i dovuti spunti e le osservazioni di ciò che accade nelle nostre realtà, potremmo cogliere finalmente un’occasione per una trasformazione più naturale e meno polemica di come la stiamo vivendo. Avrà dei costi, ma il ritorno dell’investimento credo che sia impagabile.

Agile@School 2021 – La serie completa

Per chi volesse dare una letta alla stagione 2021 di Agile@School qui sotto le puntate. Ogni episodio è dedicato a un personaggio o a un gioco, proprio per la natura del progetto:

Agile@School – Giornata conclusiva

Ultimo appuntamento di Agile@School 2021. Per questa occasione ci racconta l’incontro Alex, una new entry che qualche anno fa prese parte a questa iniziativa proprio come i ragazzi. Siamo finalmente arrivati all’appuntamento che pone sotto i riflettori l’impegno e la dedizione dei ragazzi ovvero i progetti ultimati.

L’idea di fondo proposta era quella di avere una presentazione composta da una panoramica del progetto a 360 gradi partendo quindi dalla descrizione di quest’ultimo per poi procedere con pregi, difetti, punti di forza, difficoltà incontrate e motivi accattivanti per spronare un possibile giocatore ad acquistare il prodotto per poi concludere con la presa visione del progetto e la conseguente prova dello stesso da parte di noi supervisori momentaneamente nei panni di “gamer”.

Presentazione dei progetti

Una volta superata la tensione generale il Team Cromosomi# ha preso l’iniziativa e, anche se non al completo causa assenze, è riuscito a presentare un progetto interessante caratterizzato da un gameplay che assume dinamicità grazie anche al cambio di musica in base alle scelte fatte dal giocatore.
Il gioco è stato presentato su console application e salvo qualche inserimento di dato non previsto non presentava problemi che ostacolassero la giocabilità. Un paio di consigli proposti per migliorare il tutto sono stati l’inserimento di un valore per indicare la vita del giocatore e l’inserimento di immagini che seguono il cambiamento musicale per incrementare il coinvolgimento in game.

A seguire ha preso parola il Team Fisher, team in questo caso al completo.
Presentazione ben organizzata che ha principalmente fatto focus sulle molte tecnologie utilizzate caratterizzata anche da un video realizzato su misura per l’occasione. Ben strutturata anche la storia narrativa che sta dietro al progetto. In questo caso il gioco è stato lanciato direttamente con il proprio eseguibile ed è stato provato dal sottoscritto, che non ha perso tempo per una citazione di alto calibro (infatti ho inserito subito come nome del protagonista della mia partita Rohan Kishibe… ed ho detto tutto). Gameplay con una profonda trama che fa quasi pensare ad un libro-game e che da luogo a una moltitudine di finali raggiungibili variando le scelte del nostro personaggio giocando più volte. Un problema relativo al cambio di musica durante il gioco non ha comunque influito sulla giocabilità in generale.

È stato poi il momento del Team MonkeTeck anche loro al completo.
Idea molto promettente per il progetto di questo team che grazie alla loro presentazione molto ben organizzata hanno centrato l’obbiettivo di dare informazioni che spieghino il processo creativo ma allo stesso tempo attirino il giocatore spiegando il Perché e il Come ponendo anche l’attenzione sul fattore curiosità. Gameplay che si distingue come tema dagli altri avendo come protagonista una nave a scelta che può compiere diverse azioni che possono portare anche alla distruzione della stessa se si azzerano i punti salute. Nota di merito va proprio a quest’ultimo punto, ovvero la vita o salute che finalmente vediamo implementata in uno dei progetti, l’unico fino ad ora. Molto accattivante anche la differenziazione delle statistiche in base alla nave scelta. In questo caso i consigli dati per possibili feature sono stati l’inserimento di immagini o suoni che rendano più coinvolgente la battaglia tra due navi.

Ultimo ma non per importanza è il Team GentsAndLady.py purtroppo in carenza di componenti ma carico abbastanza da sopperire alla mancanza. Presentazione abbastanza esaustiva, anche nel loro caso sarebbe stato ottimo avere una parte dedicata al Perché del gioco ma hanno compensato questa mancanza parlandone direttamente a voce, almeno per far capire a noi l’intenzione che c’era dietro. Anche in questo caso troviamo un gioco in console application preso di mira stavolta da Pier-Paolo, ormai diventato game-tester della giornata che non si è fatto sfuggire l’occasione di mettere qualche dato per far “scoppiare” tutto. Tralasciando piccoli problemi non gestiti nel complesso il gioco segue quanto promesso, quindi la storia di Napoleone in parte romanzata ma che segue un filo logico che permette lo studio giocando più volte.

Fine della corsa

Arrivati a questo punto devo ammettere che siamo stati molto sorpresi e soddisfatti dei ragazzi in quanto nonostante difficoltà, membri mancanti e tester improvvisati rompi scatole sono tutti riusciti a portare a termine un prodotto che, anche se imperfetto, risulta comunque completo.
Anche personalmente sono rimasto particolarmente stupito nel vedere i lavori realizzati dai ragazzi in quanto anche io, giusto qualche anno fa, ero al loro posto e, come loro, avevo realizzato il mio personale progetto con Engage. La differenza che ho notato maggiormente è stata la dedizione riposta in questi lavori. Quando frequentavo la scuola, non c’era questo livello nei progetti ed erano quasi tutti realizzati giusto perché “andavano fatti”. Nel mio caso il gruppo di lavoro era costituito da me :-). La voglia di fare che avevo non era particolarmente condivisa, di conseguenza, seppure non sia stato un progetto rivoluzionario, la mia “chat bella che funzionante tra smartphone e pc” l’avevo portata a termine (soddisfazione alle stelle).
Sono convinto che avvicinandosi sempre di più alle loro passioni si avrà un consenso sempre maggiore a questa iniziativa e una conseguente qualità dei progetti in continuo aumento.

Spero vivamente di poter partecipare nuovamente in futuro proprio per assistere di persona a questa evoluzione e per inserire qua e là qualche citazione di alta classe… Yare yare daze.

Agile@School – Anno sesto, terzo incontro

Arriviamo oggi al terzo appuntamento di Agile@School 2021. Pier-Paolo ci racconta l’attività dal punto di vista della programmazione.

Negli incontri precedenti abbiamo cominciato a tracciare la strada delle attività (come vedremo, non tutte strettamente legate alla programmazione vera e propria) che i ragazzi dovranno svolgere per arrivare al loro obiettivo, cioè rilasciare un videogioco in stile libro-game.

Lungo questo percorso vogliamo insegnare loro non solo gli aspetti “tecnici” di realizzazione di un software, ma anche quello che sta “al contorno” di un progetto di questo genere: parliamo ovviamente dell’approccio Agile – DevOps, quindi tutta una serie di pratiche e cerimonie volte a facilitare la collaborazione, la condivisione delle conoscenze e la gestione dei progetti. È risultato evidente come sia già consolidato l’utilizzo degli stand-up meeting all’inizio di ogni lezione, tant’è che oggi sono stati i ragazzi stessi a proporsi per un veloce aggiornamento sullo stato dei progetti, dal quale sono emersi spunti molto interessanti legati agli aspetti di software selection di cui si era parlato nel post precedente.

Infatti, due dei gruppi che avevano scelto di utilizzare Unreal Engine per la realizzazione del loro progetto si sono resi conto che non avrebbero fatto in tempo a produrre qualcosa di funzionante entro la fine degli sprint: questo non li ha però scoraggiati e, messe da parte le loro preferenze personali, hanno avuto un buon senso di responsabilità nel decidere di intraprendere una strada di sviluppo differente, pur mantenendo intatta la trama principale scelta inizialmente.

Il Team Fisher ha quindi deciso di realizzare il videogioco tramite una web application, fruibile quindi da browser, con l’intenzione di integrare nel gioco dei file multimediali precostruiti. Il Team GentsAndLady-py ha invece deciso di implementare una console application in Java; anche loro hanno dichiarato di voler utilizzare grafica e audio per aumentare il coinvolgimento all’interno del gioco.

In entrambi i casi, tale decisione è stata presa non tanto in base alla difficoltà della creazione del software tramite lo stack tecnologico scelto, quanto alla valutazione delle tempistiche di rilascio del software stesso. Questa a mio avviso è stata una scelta molto oculata, soprattutto se considerata in un contesto aziendale in cui i tempi sono fondamentali forse più che la tecnologia scelta.

Dopo una rapida revisione delle board di ogni team è seguita una parte di suggerimenti e correzioni delle user story inserite dai ragazzi: la scrittura di questi item talvolta non è facile neanche per chi segue le pratiche Agile da molto tempo, per cui era facile aspettarsi qualche sbavatura. Ci aspettiamo che per la prossima lezione le user story vengano migliorate, e soprattutto che vengano utilizzati in maniera più intensiva i task per la suddivisione delle attività.

A questo proposito, una nota positiva viene dal Team Fisher che ha chiesto se fosse corretta la suddivisione delle attività da loro individuate fra più persone in parallelo e l’affiancamento di due persone su una stessa attività di programmazione: non solo questo è corretto, ma è proprio quello che si auspica con l’adozione delle pratiche Agile! E pur non sapendolo (non ne avevamo ancora parlato), ne hanno messo in evidenza uno degli aspetti chiave, cioè il pair programming. Molto bene!

Il resto della lezione è proseguito con l’introduzione del software per il controllo del codice sorgente Git, che però temo non abbia avuto l’impatto sperato. Purtroppo, non siamo stati in grado di effettuare degli esercizi live, un po’ perché non è stato possibile installare il software sulle postazioni usate dai ragazzi, un po’ per problemi logistici (noi e i ragazzi siamo lontani “fisicamente”, chi in classe, chi da casa, e la connessione instabile non permetteva una condivisione dello schermo). Abbiamo comunque chiesto a ciascuna squadra di creare un repository su GitHub, sia per poterlo connettere successivamente ad Azure DevOps e dimostrare come si possano collegare i task alle modifiche del codice, sia per iniziare a caricare i file del proprio progetto.

See the source image

Con questo appuntamento si concludeva in teoria il primo sprint, ma fra cambi di tecnologia e necessità di adattamento all’Agile i ragazzi non sono ancora riusciti produrre nulla di significativo, ma non disperiamo, c’è tutto il secondo sprint!

Agile@School – Anno sesto

Siamo ancora in pandemia. Abbiamo una buona percentuale di vaccinati, ma ancora dobbiamo avere a che fare con relazioni in remoto. Lo stesso vale per il nostro amato e inarrestabile progetto: Agile@School. Siamo arrivati al sesto anno consecutivo e questa volta, con un’idea orientata al mondo videoludico.

Non a caso l’immagine di copertina richiama uno dei giochi punta e clicca più conosciuti di tutti i tempi, col quale ho perso ore e ore nei pomeriggi della mia adolescenza: The Secret Of Monkey Island tm.

Il cosa

“Facciamo un gioco, sì, produciamolo. Pur semplice che sia, ma creiamo qualcosa di nostro”. Questa è la missione che i ragazzi hanno quest’anno. Il tipo è quello della saga di “Lupo Solitario” (Lone Wolf), un famoso libro game di qualche tempo fa. Abbiamo deciso di far fare agli studenti un piccolo motore basato su “decisioni –> conseguenze”, un grafo in cui una storia viene sviluppata e diventa la strada di un personaggio con una semplice caratteristica, l’energia vitale.

Il come

Decidano i ragazzi. C++? Java? Angular? Javascript? Python? Quello che vogliono. Ci sono solo tre vincoli:

  • La storia deve essere derivata dal programma di una materia, anche per coinvolgere altri professori.
  • La storia deve essere un’avventura semplice, per arrivare ad un lavorato funzionante in un solo mese.
  • Le scelte possibili devono essere al massimo 3, con altrettante conseguenze: avanti senza subire danni, avanti subendo danni, fine del gioco prematura (fine energia vitale improvvisa).

Gli strumenti

La gestione del progetto sarà in Agile, e con SCRUM. Per implementare la parte di gestione, abbiamo creato 4 team con altrettanti backlog, solo Product Backlog Item e Task. Utilizzeremo git come source control manager e, in generale, ogni editor di codice legato alla tecnologia scelta dai ragazzi.

Infine, le presentazioni prevedono un piccolo video, una serie di mock grafici nell’arco del progetto e una bella demo del software alla fine di tutto.

I team

I ragazzi hanno già scelto i nomi dei team:

  • FISHER: “perché abbiamo tutti un soprannome comune che richiama tale nome”
  • CROMOSOMI#: “un joke per il linguaggio C++”
  • MONKETECK: “due parole, e la seconda per esprimere senso di tecnologia”
  • GENTS&LADY.PY: “gentlemen e una ragazza, in python, o almeno ci proviamo”

Ogni team è di 5/6 persone e le figure che abbiamo identificato sono:

  • PO: product owner, uno per team, che si riferirà a me per lo stato dei lavori (non dimentichiamo che io sono il cliente del gioco).
  • Marketing: figura che curerà la presentazione.
  • Tech lead: figura che seguirà le implementazioni anche a livello decisionale, riferimento di Pier-Paolo, che anche quest’anno sarà il loro appoggio tecnico.
  • Developer: chiunque partecipi al progetto e sviluppa parti del gioco

Insomma, ci sarà da divertirsi. Aspettatevi qualche post nel breve, perché i ragazzi hanno già iniziato a buttarsi a capofitto nel progetto. La passione sembra averli abbracciati.

Stay Tuned!

Engage Stories – digest 1

Come promesso, ecco la prima tranche di #EngageStories:

Altre interessanti storie, sempre in Engage, qui:

Our 2021

Everyone was waiting for this 2021, 2020 has been one of the worst year ever due to the Coronavirus pandemic. We need to start from scratch, both for relationships and professional development.

Due to the COVID-19, I have lost relatives and also some of my relationships with my fellows. From a professional perspective, I’ve travelled less, worked mostly in remote-working and I’ve invested in making our daily work in our company smarter. Anyways, we’re speaking about two sides of the same coin: trouble Vs opportunity.

For tech companies, the crisis has been a great opportunity. The disease has triggered (forced to be honest) a set of unstoppable changes. This is true also for Countries’ governments, school, services in general. At the same time, many small businesses and craftsmen stopped working due to lack of consumers. The world is changed and is going to change more and more. The change is killing someone and is testing severely the resilience of the others.

Luckily, our company is still alive and we are growing. I’ve learned many lessons in terms of recruitment, team management, tech stuff, project management. I’ve started to change my mind about multi-tasking and I’ve switched from many things at “the same time” to “the right number of things well managed” (but not only one 😉 I’m not yet able to follow such pattern).

We have dealt with the second big step of scaling out. Our organization is becoming bigger and more structured. The model is still flat, but now each individual is in charge of a single role. As a result, the quality of the product is improved, people are more focused and committed, but on the other hand, the time to market has increased. We have added a new role, which orchestrates the projects into the roadmap, increased the number of POs, created an R&D department, and fully involved Operations guys into the lifecycle (thanks Wikis!). All this stuff has been the game-changer for us.

It’s been so difficult to learn and cover so many topics, but we’ve accomplished our mission. Now we’re ready for the next year with many ideas. We already know that our team will grow more, and we’ll require new approaches. We know that we will deal with teams in different timezones and languages, so what is “smart” now, must become “smarter” tomorrow. Exciting, for sure!

Why am I writing this post? Not just to wrap-up something that happened this year. I would share with you that, starting from February 2021, Engage Labs (this will be our new name) will publish our guys’ blog posts periodically (in Italian language). Our great team will cover many topics, like professional development, lessons learned in the company, technology, and so on. We are a DevOps oriented organization and we would like to let our guys describe themselves.

So, stay tuned😉

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 02 – build

In a previous post, we’ve described the “from scratch” approach on the development side. When everything works well there, a push (or check-in) triggers the build engine. We must deal with two SQL Server instances (SSIS Servers hereafter), with an environment for each of them:

The build pipeline

The SSIS Servers keep Vertica‘s test and production mappings as well as test and production connection strings for the SQL Server databases. So we need the right variable mapping for all the scenarios, but this is not in the scope of the post, we will speak about it in the next posts. Anyways, here is how the build pipeline works:

Our build process

You may notice that the task “Copy vertica deploy scripts” is disabled. Well, to be honest, right now we’re waiting for the target integration environment.

Build process explained

In the beginning, the build server gets the source files from the repository and creates the target artifacts folder with a Powershell script. This will be the path from which we will push the artifacts to the release pipeline.

The build server generates the .ispac file for the SQL Server Integration Services packages using the dedicated task. The copy tasks will be executed:

As you can see, we’ve got a set of utilities and transformation tools, that will be executed in the release pipeline as well as the environment script. This one contains the SSISDB variables mapping and the SSIS Project configurations statements. Misc files, .sql files for environments and the .ispac file will be copied to the target artifacts folder.

The tasks above copy our template of the .nuspec file to generate the NuGet file (NuGet pack step). This is what we get using NuGet:

Then, we’re ready to publish the files to the release pipeline. We will see how the release pipeline works in the next posts.

Ehm… you miss Vertica

Yes, you’re right. But, it’ll be just a copy of .sql files to the artifacts folder. We will see how the release manager will execute them, so…

Stay tuned!

Display Reporting Services usage statistics with Grafana

Introduction

In this post, we will describe an efficient way of showing the usage statistics of our SQL Server Reporting Services hosted reports. Most of the queries below have been addressed in another article published by Steve Stedman. Even though they are really useful, the article shows their results through SQL Server Management Studio.

The problem

One of the problems that often occur in our organization as well as some of our customers, is to get immediate feedback about usage statistics of reports. Usually, the request of creating reports is out of control and some of them are executed only “that time” and not anymore. In the worst-case scenario, many of them aren’t executed at all and some of them could become even overlapped or duplicated.

Therefore, it is important to know the usage statistics, user by user and report by report, to make the reader aware of them, let him interpreting the values of the same query in multiple ways and graphical layouts. While this is not possible with a tabular format (unless you export the values using any external tools such as Excel) it is simpler when it comes to a dashboard.

Our solution: Grafana

We considered two factors: simplicity and efficiency, in order to make this first-sight dashboard. Grafana enables us to get both of them, as well as being very powerful and immediate. Even though this is not the right definition for it, we can say that “it is a portal to create dashboards using connectors, which support the most famous tools that return data”. We can find them in its marketplace. For instance, tools such as PRTG and Prometheus (monitoring), NewRelic (APM), also SQL and NoSQL data sources are supported:

Obviously, we can find SQL Server. Also, we can contribute to create others, as well as to modify Grafana itself, since it is completely an Open Source project. Examples of possible graphical representations are listed below:

Creating a dashboard is really simple. Just add each panel with a button.

Then, write the query and modify settings to get the desired type of representation.

As mentioned before, the connectors are many. Once selected you can to configure them with parameters:

If you would like to install and configure Grafana you can read the official documentation which also includes a short guide that illustrates how to take your first steps.

That’s it!

Conclusions

With half a day of work (including the setup of the server), we have solved one of the most important problems of our customers, derived from the lack of awareness of reports deployed in production environments. We did it with very little effort and the result, as you can see, is pleasant and effective. Everything is now ready to be published every time we update the dashboards also through a delivery software (Octopus Deploy, Jenkins or Azure DevOps) so all these things fall into the second and third way of DevOps (according to The Phoenix Project): Immediate Feedback and Continuous Improvement.

Stay Tuned!

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 2)

Intro

In the previous post we’ve described the idea behind the automation we’re trying to implement on a scenario based on MicroFocus Vertica database.

How it works

This “sandbox” is not a real isolated development workstation. Let’s separate it into two parts, the first one for the development on everything but Vertica (Windows local workstation) and the other one for a Vertica instance (probably Unix/Linux VM) shared between developers.

In this shared instance we will get a schema for each developer is working on the solution, in order to let everyone to get his own “environment”.

The source control folder tree (which will be TFVC source control on-premises) will be designed on the desired branch as the following:

/Project
    /Instance
        /Process1
            /_Master
                schema.ps1 
                tables.ps1
                views.ps1
            /Tables
                Table1.sql
                Table2.sql
            /Views
                View1.sql
                View2.sql
            Schema.sql
        /Process2
            /Tables ...
            /Views ...

As you ca see, under the Project folder there is the Vertica database folder, which contains, schema by schema, all the .sql files for Tables and Views DDLs (CREATE TABLE and CREATE VIEW). You can notice also .ps1 files, which contains the list of executions based on a certain order (business driven).

The file for a, let’s say, “Table1”, can be like this one:

CREATE TABLE :SCHEMA.Table1
(
    RowId int NOT NULL,
    RowStringValue varchar(30) NULL,
    CONSTRAINT PK_<schema>Table1 PRIMARY KEY (RowId)
);

We’ve added a :SCHEMA parameter, which allows each developer to create its own schema as described before. This is the only way we’ve found for isolating developers in a Vertica shared instance, avoiding an instance for each developer, which could be resource intensive for available PCs. Running the application locally, before committing any change set to the Source Control, a simple tool will execute .sql files with the new schema name and in the sort order given by the .ps1 file.

The Tables.ps1 file can be as the following:

param(
[parameter(Mandatory=$true)]$hostname,
[parameter(Mandatory=$true)]$port,
[parameter(Mandatory=$true)]$user,
[parameter(Mandatory=$true)]$psw,
[parameter(Mandatory=$true)]$schemaName,  
[parameter(Mandatory=$true)]$scriptsFolder
)

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table1.sql")"
Invoke-Expression -command '$schemaCommand'

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table2.sql")"
Invoke-Expression -command '$schemaCommand'

You may notice the term “vsql”, which is the command line provided by Vertica for executing queries. Further information here.

Also, usernames and passwords will be stored in an external config file (or a secured API), like the following one:

{
"host": "MyHost.Hos.Ext",
"port": 1234,
"user": "user",
"psw": "password",
"schemaName": "MYSCHEMA"
}

We’ve got the DDLs, the PoSh files for executing them and the Vertica command line. Good, in a development environment, however, a set of tools should be prepared for helping us to keep these artifacts on a single pipeline, too. This is the reason why we’ve created a “builder” script, like  this one:

$config = Get-Content (Join-Path $currentFolder "Build-Config.json") | Out-String | ConvertFrom-Json

$schemaCommand = $(Join-Path $scriptsFolder "Tables.ps1") 
$schemaCommand += " -hostname $($config.host)" 
$schemaCommand += " -user $($config.user)"
$schemaCommand += " -port $($config.port)"
$schemaCommand += " -psw '$($config.psw)'"
$schemaCommand += " -schemaName $($config.schemaName)"
$schemaCommand += " -scriptsFolder $scriptsFolder"

Invoke-Expression -command $schemaCommand

This is another layer of management, which allows us to organize every part of the DDLs to be executed against Vertica.

Note: Our scripts will destroy and rebuild any given SCHEMA. But this is the way we like.

Now, let’s see the possible scenarios.

Start from scratch or get started

When someone wants to start from scratch, this is the pipeline to follow:

  1. get latest version of the branch;
  2. check and change the configuration file (JSON);
  3. execute the create-vertica-database-from-scratch.bat file (it contains our powershell “build” script);
  4. that’s it, we’ve got a new schema in Vertica, empty and ready to be consumed.

If you want to preserve your data, this is not the right path for you. Executing the “builder” tool is optional.

New development

When a developer would make and try its changeset:

  1. change Visual Studio application (SSIS or SSRS here) when needed;
  2. change the Vertica schema (adding tables, columns and so on);
  3. get the .sql file of a new object or change the .sql file of an object which has been updated;
  4. replace them into the TFVC file structure;
  5. change the .ps1/.txt files if any DDL has been added (or if something that impacts on the order occurs);
  6. build the Visual Studio application and try it;
  7. When everything works good, check-in.

Now, everyone can get the latest changes in a CI way.

Get delta changes

When a developer is going to get the latest changes that contains an updated version of the Vertica objects, but wants to preserve its data, this is a little bit more tricky. The person who has made the change could share in a collaborative chat tool the ALTER script. This is not so reliable and comfortable, but without any comparison tool, there isn’t any best way to make this happen.

That being said, we’ve implemented our diff-script generator, based on the analysis of Vertica metadata (the catalog, browsing v_internal objects). So, after our friend gets the latest version, he executes a generate-diff-script.bat tool and lets this script to execute the generated ALTER script. Tricky, but it works like a charm (we will speak about this comparison tool in next posts, maybe) . Anyway, we’re looking forward hearing updates from MicroFocus. Hopefully, we’ll get an official diff tool from them soon!

Conclusions

I’ve just shown the way we’re managing tables DDLs and how we’ve created PowerShell scripts, but the real scenario is more complex. We have to drop Vertica schema (CASCADE DROP) before, then re-creating the new parametrized schema, then tables, then views and so on. Sometimes, we’ve got Vertica schemas which are referenced each other, so we have to create for everyone of them tables before, then views. The business logic is managed by how we write the “build” PowerShell script as well as the automated build process will.

Also the build process is not always “straight”. Some of the business processes need to be managed in a dedicated way. Cross reference will occur but this is the job that the “builder” will do. Both for the manual and the automated one. Moving responsibility to the build process allows us to feel more comfortable about our development solution.

Last, but not least, the manual-development-build process allows the developer to choose between re-create the database or not. They should not waste time in managing the things that a script can do repeatedly and efficiently. This is the reason why we kept somehow static the PowerShell instead of writing complicated business logic. Just adding rows of vsql invocation in the right order, that’s it.