Un cronografo piccolo piccolo

A volta capita che una procedura PL\SQL sia lenta.
In questi casi per individuare le porzioni di codice lento è utile misurarne il tempo di esecuzione.
Per far ciò ho realizzato un package che implementa un cronografo.

CREATE OR REPLACE PACKAGE CRONO IS
   TYPE tTimer IS RECORD(
      s TIMESTAMP
     ,e TIMESTAMP
   );
 FUNCTION  new     RETURN tTimer;
   PROCEDURE stop    (this IN OUT NOCOPY tTimer);
   PROCEDURE reset   (this IN OUT NOCOPY tTimer);
   FUNCTION  time    (this IN OUT NOCOPY tTimer) RETURN VARCHAR2;
   FUNCTION  hour    (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  minute  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
   FUNCTION  second  (this IN OUT NOCOPY tTimer) RETURN NUMBER;
 END;
CREATE OR REPLACE PACKAGE BODY CRONO IS
  
  FUNCTION  new RETURN tTimer IS
    this tTimer := NULL;
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
    RETURN this;
  END;
  
  PROCEDURE starting(this IN OUT NOCOPY tTimer)IS
  BEGIN
    this.s := SYSTIMESTAMP;
  END;
  
  PROCEDURE stop (this IN OUT NOCOPY tTimer) IS 
  BEGIN
    this.e := SYSTIMESTAMP;
  END;
  
  PROCEDURE reset (this IN OUT NOCOPY tTimer) IS
  BEGIN
    this.s := SYSTIMESTAMP;
    this.e := NULL;
  END;

  FUNCTION  time (this IN OUT NOCOPY tTimer) RETURN VARCHAR2 IS
    ret VARCHAR2(32767):=NULL;
  BEGIN
    ret := this.e - this.s;
    
    ret := ret || ' ' || 'h:' || (extract(hour from this.e - this.s));
    ret := ret || ' ' || 'm:' || (extract(minute from this.e - this.s));
    ret := ret || ' ' || 's:' || (extract(second from this.e - this.s));
    
    RETURN ret;
  END;

  FUNCTION  hour (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    h NUMBER :=NULL;
  BEGIN
    h := (extract(hour from this.e - this.s));
    RETURN h;
  END;

  FUNCTION  minute (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    m NUMBER :=NULL;
  BEGIN
    m := (extract(minute from this.e - this.s));
    RETURN m;
  END;

  FUNCTION  second (this IN OUT NOCOPY tTimer) RETURN NUMBER IS
    s NUMBER :=NULL;
  BEGIN
    s := (extract(second from this.e - this.s));
    RETURN s;
  END; 
END;

Il suo utilizzo è molto semplice.
A seguire un esempio:

DECLARE
  t1 CRONO.tTimer; --Variabile di tipo cronometro

  --Codice che consuma tempo
  PROCEDURE NOP(cycle IN NUMBER)IS
  BEGIN
    FOR i in 1..cycle LOOP
      DECLARE
       c NUMBER := 0;
      BEGIN
        select 1 into c from dual;
      END;
    END LOOP;
  END;

BEGIN
  --Il cronometro t1 viene creato ed avviato
  t1 := CRONO.new();
  
  NOP(cycle=>1000);
   
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);

  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso A:' || CRONO.time(t1));

  --Si resetta il cronometro t1
  CRONO.reset(t1); 
  
  NOP(cycle=>500);
 
  --Il cronometro t1 viene fermato
  CRONO.stop(t1);
   
  --Si stampa il tempo misurato dal cronometro t1
  DBMS_OUTPUT.PUT_LINE('Tempo trascorso B:' || CRONO.time(t1));
 
END;

La psicologia “semplice” del developer

Ho sempre ritenuto che nel nostro lavoro la componente psicologica sia molto importante, purtroppo ho registrato spesso una scarsa sensibilità verso questo tema.

Ma è veramente così difficile avere a che fare con i developer ?
E’ possibile disegnare il profilo psicologico di un developer ?

Recentemente, durante una di queste riflessioni, ritengo di aver colto una verità interessante.

Un developer professionale è molto simile ad un artigiano, i suoi manufatti sono diretta espressione della sua arte e del suo genio.

Inoltre:

  • trae piacere nel fare bene il suo lavoro e cerca l’eccellenza
  • ha bisogno di dare un senso al proprio lavoro e quindi cerca conferma che il suo manufatto sia utile
  • ha stima di chi fa il suo stesso lavoro e trae beneficio dal far parte di una comunità

Da ciò discente in modo chiaro che chiedere ad un developer di produrre “cacca” equivale a soffocare il sue ego ed infangare la sua arte, ingenerando un profondo senso di frustrazione. 

Di converso per alimentare e mantenere alta la motivazione dei developer è facile individuare una serie di azioni:

  1. manager competenti
  2. retribuzione commisurata al valore prodotto
  3. ambiente informale
  4. auto organizzazione
  5. disponibilità degli migliori strumenti
  6. agevolare l’accesso a informazioni e a formazione
  7. agevolare la partecipazione a community
  8. ridurre il debito tecnico
  9. rendere il lavoro sostenibile

Naturalmente ci sono dei lati oscuri che conviene tenere in debita considerazione:

  1. la ricerca dell’eccellenza è nemica della gestione del tempo
  2. l’ego spiccato può determinare sporadici deliri di onnipotenza

Sulla contrazione dell’universo

Le aziende sono organizzazioni che cambiano nel tempo.
La crescita di un’azienda è un fenomeno simile all’espansione dell’universo.
Quando il numero di persone cresce tipicamente si cerca di contrastare l’entropia creando nuove funzioni, livelli e ruoli aziendali che vanno ad accrescere la struttura gerarchica aziendale a forma piramidale.

La realtà e che non siamo affatto certi che l’espansione dell’universo sia continua. Allo stesso modo non possiamo dare per scontato che l’azienda cresca in modo indefinito.
Negli ultimi decenni abbiamo sperimentato un’altissima variabilità sui mercati e ci siamo dovuti ricordare che la crescita non è una costante.

Un’azienda allora per essere longeva dovrebbe assumere una struttura plastica, malleabile al bisogno e con bassa inerzia al cambiamento.
Prendere coscienza di questa necessità spesso innesca transizioni verso strutture organizzative più moderne e a sviluppo orizzontale.

Se strutturare un’azienda in fase di espansione può essere relativamente facile, gestire una fase di contrazione ed appiattire la gerarchia è impresa ardua.
I livelli, i ruoli e le funzioni creati nel tempo debbono essere revisionati in modo profondo e spesso doloroso.
Per le persone coinvolte in queste transizioni è come trovarsi nel compattatore dei rifiuti di Star Wars: è naturale opporsi in tutti i modi, cercando di sabotare la stessa sala comandi.

Per questo un processo del genere deve necessariamente partire dall’alto, ma oltre all’autorità serve autorevolezza.
La prima cosa da fare infatti è allineare tutti i livelli sui principi ed i valori nuovi.
Ciò può risultare estremamente difficile se negli anni precedenti i comportamenti e la linea di condotta hanno smentito nei fatti i principi ed i valori che si cerca di radicare: quello che serve è una buona dose di credibilità, ma ci vuole tempo.

Per questo motivo è più semplice creare da zero un’azienda che aderisca a certi principi e valori piuttosto che riconvertirne una esistente.

Contenitore Vs Contenuto

Qualche giorno fa sono entrato in una Libreria.
Era molto tempo che non lo facevo più.
Ho scorso velocemente la sezione di science-fiction.
Me stavo andando quando un libricino ha attirato la mia attenzione: “Lo Zen nell’arte di scrivere”.
Il formato e la promessa che il titolo nascondeva erano stuzzicanti, il fatto che l’autore fosse Ray Bradbury mi ha convinto.
Ho soppesato un attimo l’idea di acquistarlo su Amazon in formato elettronico, ma mi sono abbandono al romanticismo: stavo già accarezzando le pagine e non vedevo l’ora di leggerlo.
Ho comperato il libro a 15 EUR. Una volta uscito ho resisto all’impulso di verificare quanto sarebbe costato su Amazon.

Qualche ora più tardi ho ceduto alla curiosità.
Su Amazon lo stesso libro in formato cartaceo costa 13 EUR ma in formato elettronico 5 EUR!

Sono rimasto piuttosto stupito, il romanticismo mi è costato caro.
Ma ciò che mi ha colpito è che il contenuto pesa solo per 1/3 sul prezzo complessivo di questo libro cartaceo.
Tutto ciò mi sembra sinceramente assurdo.

Naturalmente un solo libro non è un campione significativo, ma è facile capire perché il mercato dei libri stampati sia in crisi.

Da tempo ormai preferisco gli ebook per motivi di praticità.
Il libro stampato però ha una caratteristica che tende ad essere sottovalutata: con le dovute cautele (persone affidabili) può essere prestato e ciò lo rende un prezioso vettore di idee.

Come si può attraversare un fiume ?

Fiume
Fiume

Qualche tempo fa ho partecipato ad un bell’evento sul gaming.
Tra i vari giochi uno richiedeva di scrivere in 10 minuti in solitaria un elenco di modi per attraversare un fiume.

Comincio scrivendo le mie soluzioni:

  • con la barca
  • a nuoto
  • con un ponte
  • con una liana
  • con una pertica
  • con un tronco
  • ecc.

Finisce il tempo ed il coach chiede ad un partecipante di leggere una soluzione.
La persona si alza e declama: “Sulle spalle di un altro…”
Lì per lì rimango di stucco poi comincio a riflettere.

Parto da me. Probabilmente per me e per i miei colleghi del gruppo tutti di estrazione ingegneristica è stato naturale scovare strumenti per attraversare il fiume, ciò ha determinato automaticamente l’esclusione di una persona come strumento.

Mi metto nei panni dell’altro. Forse la persona è un manager. I manager per definizione gestiscono risorse tra cui esseri umani. I manager non sono uomini del fare. I manager da un certo punto di vista utilizzano le persone per lavorare, quindi tutto sommato la risposta non dovrebbe stupire.

E’ stupefacente come un gioco di tale semplicità possa far emergere in modo così chiaro una tale differenza d’impostazione nella mentalità di una persona.

Il background ed il contesto influenzano il nostro modo di pensare e di affrontare i problemi, limitando di fatto l’area in cui cerchiamo le soluzioni.