Archive for the ‘Italiano’ Category.

Spegnere la luce di attenzione arancione dal Service Action Log di AS400

- Collegarsi con l'utente QSECOFR di sistema operativo.

- Digitare dalla riga comandi STRSST

- Inserire l'utente e password di manutenzione DST richiesti

Type choice, press Enter.  

Service tools user ID. . . . . QSECOFR
Service tools password . . . xxxxxxx (case sensitive)

- Selezionare Start a service tool / Avvio di un programma di manutenzione
(opz.1)

- Selezionare Hardware Service manager / Programma di manutenzione hardware
(opz.7)

- Selezionare Work with service action log / Gestione delle registrazioni
delle azioni di assistenza (opz.6)

- Dare la data di inizio ricerca errori più vecchia possibile (installazione del sistema ) fino alla data attuale, quindi invio.....

- Verificare gli errori che appaiono sul sito INFOCENTER

- Spegnere la luce di attenzione facendo l'acknowledge dei problemi
F6=Acknowledge All Errors / Ricezione di tutti gli errori

- Rimuovere tutti gli errori presenti , uno alla volta, utilizzando l'opzione 8 di Close (Chiusura) e poi 9 di Delete (Cancellazione).
Se non ci sono errori nella pagina ma è presente la funzione F6 fare comunque l'acknowledge per spegnere la luce.
Verrà richiesto un F10 di conferma

- Una volta eseguito l'Acknowledge(Ricezione) appare sul fondo della videata la scritta: All errors have been acknowledged / Tutti gli errori sono stati ricevuti (a questo punto la luce si dovrebbe essere spenta)

Too many illegal datagrams from the remote computer AS400

A volte nei log di sistema dei server Windows che convivono in una subnet con un AS400 può comparire il seguente errore:

"The browser driver has received too many illegal datagrams from the remote computer YOUR_AS400_NAME to name xxxx on transport NetBT_Tcpip_{DF3149C4-A44D-493F-BD8C-BE3B. The data is the datagram. No more events will be generated until the reset frequency has expired."

Il problema può essere risolto eliminando la spunta da "Invia annunci di ricerca" dalla configurazione del NetServer in iSeries Navigator.
Illegal datagram from AS400 - Configurazione iSeries Navigator

Software gestionale in Erlang?

Come forse saprete, il mio lavoro consiste nello sviluppo di software gestionale. Ultimamente, però, grazie agli amici dell'XP User Group di Milano, mi sto appassionando al linguaggio Erlang. Mi è allora venuta la balzana idea di vedere se le due cose potessero avere un punto di incontro. Sia chiaro, con questo post non sto invitando nessuno a sviluppare programmi gestionali in Erlang, cosa che ritengo piuttosto difficile, ma desidererei da un lato saggiare la duttilità del linguaggio, dall'altro cercare di imparare qualcosa riguardo ai principi di scomposizione funzionale dei problemi.

La gestione di un ordine

Durante una mia presentazione del linguaggio Scala tenutasi all'XP User Group di Bergamo, ho già affrontato la questione di scomporre "funzionalmente" un elementare problema gestionale. Gli esiti non sono stati brillantissimi in quanto a chiarezza, desidererei quindi riprovare utilizzando un diverso linguaggio.

Il problema giocattolo che vorrei affrontare è quello di effettuare dei calcoli su un ordine, rappresentato come una lista di righe d'ordine. Definisco quindi come prima cosa il record riga d'ordine:

 
-record(order_row, {description, price, qty, vat_rate = 0.2}).
 

Su questo record posso quindi definire delle banali funzioni quali il calcolo del prezzo netto, dell'IVA e del prezzo ivato:

 
net_amount(OrderRow) ->
  OrderRow#order_row.price * OrderRow#order_row.qty.
 
vat(OrderRow) ->
  net_amount(OrderRow) * OrderRow#order_row.vat_rate.
 
amount(OrderRow) ->
  net_amount(OrderRow) + vat(OrderRow).
 

Una generica elaborazione su un intero ordine si può quindi intendere come la composizione di un'operazione di aggregazione, quale la somma, e di una funzione di calcolo applicata ad ogni riga.

 
computation(Order, AggregationFunction, CalculusOnRow, StartResult) ->
  lists:foldl(fun(OrderRow, ResultSoFar) ->
                 AggregationFunction(CalculusOnRow(OrderRow), ResultSoFar)
              end, StartResult, Order).
 

Rielaborando questi mattoncini possiamo pertanto ottenere facilmente diversi tipi di computazioni:

 
total_amount(Order) ->
  computation(Order, fun erlang:'+'/2, fun amount/1, 0).
 
max_vat(Order) ->
  computation(Order, fun erlang:max/2, fun vat/1, 0).
 
min_net_amount(Order) ->
  computation(Order, fun erlang:min/2, fun net_amount/1, 0).
 

Conclusioni

La scomposizione funzionale del problema in Erlang sembra più semplice che in Scala. La sintassi Erlang per i record risulta però piuttosto "legnosa" e temo possa sfuggire presto di mano con problemi di dimensioni reali. Rimango inoltre sempre perplesso sulla tipizzazione dinamica: capire con che a parametri invocare una funzione potrebbe essere un problema. Ciò nonostante, ritengo che Erlang meriti senza dubbio un ulteriore approfondimento.

Bowling game Kata in Erlang reloaded

So my first solution to the Bowling Game Kata was wrong! Well, a good chance to learn something. ;-)

Let's try to solve the problem again.

I added the last test to my test suite, which shows the previous bug:

Then I modified the code this way

The code now is not so clear, but it passes tests! What I learned from this exercise? Well, Ron Jeffries said:

I would bet, though, that if we were to take some set of problems that can be solved in a natural fashion both recursively and iteratively, and had a bunch of programmers write both versions, they would have more trouble with the recursive ones, on the average.

My experience seems to confirm his opinion, even if I should consider that it's more than twenty-five years that I solve problems iteratively, while I came to use recursive solutions only a few times. Thus, perhaps my way of seeing problems is not accustomed to think in a recursive fashion, and it requires some more time to get into this way of thinking. So, let's do more Erlang exercises!

Il sofista

E' da qualche giorno che sulla lista italiana di "Exteme programming" infuoca una polemica su cosa sia XP, chi abbia il diritto di darne una definizione e quale definizione se ne debba dare. Non so perch, ma tutte queste discussioni mi fanno tornare in mente un brano dell'Apologia di Socrate. Ecco cosa Platone fa dire a Socrate.

E se qualcuno vi ha ancora detto che io faccio leducatore e che ne ricavo gran guadagno, neppure questo vero. Riconosco certo che bello essere capace di educare gli uomini, come un Gorgia Leontino, un Prodico di Ceo, o un Ippia di Elide. A costoro concesso, o Ateniesi, di andare di citt in citt e di attirare al loro insegnamento i giovani, i quali invece potrebbero benissimo, senza spendere nulla, frequentare linsegnamento di quei concittadini che volessero scegliersi; quelli invece sanno persuaderli ad allontanarsi da questi e a venire loro, a pagarli profumatamente e a mostrare anche la dovuta gratitudine. Che dico? E venuto qui fra noi un sapiente uomo, un cittadino di Paro, come ho potuto apprendere per avere io parlato con uno che con i Sofisti ha speso pi denaro che tutti gli altri messi insieme, Callia precisamente, il figlio dIpponico. Voi sapete che egli ha due figli; ebbene io ho voluto interrogarlo:
-Callia [...] A chi dunque bene affidare [i giovani]? Chi abile a sviluppare in loro le virt proprie delluomo e del cittadino? Suppongo che tu ci abbia molto riflettuto, poich hai dei figli. C qualcuno che ne sia capace o no?
-Certamente, mi rispose.
-E chi costui, chiesi, e di quale paese , e che prezzo chiede per il suo insegnamento?
-E Evno di Paro, o Socrate, mi rispose, e chiede cinque mine.
-Felice Evno, pensai io, se veramente possiede questarte e linsegna a cos modico prezzo! Anchio mi sentirei fiero e felice se sapessi fare altrettanto; ma io non so, o Ateniesi.

Anche noi, come gli Ateniesi di oltre due millenni fa, ci troviamo nelle condizioni di dover distinguere gli insegnamenti dei sofisti da quelli dei socratici. Alcuni indizi potrebbero forse aiutarci.

  • Il sofista colui interessato pi al guadagno che alla ricerca della verit.
  • Il sofista annuncia agli altri di conoscere la verit, il socratico dichiara solo di ricercarla.
  • Il sofista vuole imporre la propria autorit, al socratico l'autorevolezza data dagli altri.

In base a questi criteri, in me molti dubbi sorgono su alcuni presunti "guru"....

Italian Agile Day 2009 - Le mie impressioni

Un altro Agile Day passato ed eccomi nuovamente a scrivere un sommario della mia esperienza.

Peter Stevens - Fixed Price Projects With Agile It can be done!

Possiamo stimare a priori tempi e costi di un progetto agile? Possiamo applicare i metodi agili quando il costo ed il tempo sono scolpiti nella pietra? Certo, sarebbe bello poter vivere in un mondo in cui tutti i contratti fossero tagliati sul concetto di iterazione, di sviluppo incrementale. Purtroppo ci sono occasioni nelle quali dobbiamo stimare i costi, nei quali dobbiamo sapere se riusciremo a rilasciare entro una certa data, magari remota. Chi, ad esempio, sviluppa il software per gestire grandi eventi come i mondiali di calcio non pu chiedere di spostare la data della finale perch lavora in un team agile e ha bisogno di una nuova iterazione per completare le storie!

Peter Stevens ritiene che lo sviluppo agile si possa adattare a queste situazioni, anzi che sia il miglior metodo da adottare. Questo perch l'unico sistema per valutare in corso d'opera la velocit alla quale lo sviluppo si sta svolgendo.


Waterfall

Per affrontare progetti di questo tipo occorre per:

  • un cliente del quale fidarsi;
  • una pianificazione che lasci "cuscinetti" liberi nei quali compensare eventuali ritardi;
  • criteri certi (e automatizzabili) per determinare quando una funzionalit conclusa;
  • criteri per stabilire l'importanza delle varie funzionalit per realizzare prima le storie pi importanti e consegnare alla fine del progetto, quando la pressione maggiore e le energie si esauriscono, le funzioni di minor rilievo;
  • un team esperto.
  • Maggiori dettagli sulla presentazione si trovano qui.

Alberto Brandolini - Possiamo fare di meglio

La presentazione mattutina di Alberto Brandolini partita da una serie di provocazioni ad effetto sui seguenti temi.

  • Spesso si rompe il rapporto di fiducia tra il software e chi lo usa, sia egli un utente finale o chi fa parte dello stesso team di sviluppo. Scatta allora il meccanismo della "complessit compensativa", cio degli strani trucchi per aggirare i comportamenti errati dei sistemi.
  • A volte gli sviluppatori accettano passivamente i requisiti che sono dati loro: ma chi d questi requisiti il vero esperto del problema, o, se lo veramente, ha avuto modo di pensare ai requisiti in maniera critica? I requisiti non sono in alcuni casi semplicemente la mummificazione di un processo che potrebbe essere invece migliorato?
  • Nei progetti software pu nascere quello che stato definito "technical debt". Brandolini suggerisce una metafora pi calzante per questa progressiva deriva nella qualit del codice: inquinamento, ovverosia un processo estremamente dannoso, difficilmente reversibile e con un tempo di riparazione incalcolabile.
  • A volte lo sviluppatore non ha abbastanza umilt per capire di dover approfondire il dominio da un punto di vista non semplicemente informatico.

Dopo aver introdotto questi spunti di discussione, Brandolni ha lasciato la parola all'uditorio. L'esito di questo esperimento di "terapia di gruppo" a mio avviso non per stato brillantissimo: purtroppo non emerso molto di interessante, se non una collezione di aneddoti sul nostro lavoro.

Pietro Brambati - ASP.NET MVC: Programming & Testing

Dato che prima del pranzo non mi sembrava vi fossero relazioni degne d'interesse, mi sono infilato nell'auletta dedicata alla presentazione dell'ambiente di test creato per .NET MVC. Io odio gli strumenti di sviluppo Microsoft!!! Questo mio sentimento nacque anni fa quando Visual Basic 6, con un fantastico "Il controllo OCX non registrato correttamente", mi fece affogare in un oceano marrone nel bel mezzo di una demo ad un centinaio di persone. Nonostante questo, mi sembrato che il supporto di Microsoft ai test unitari sia discreto e che l'oratore, molto preparato, sia riuscito a dare a i colleghi della sponda Microsoft un buon numero di informazioni utili su come scrivere codice in modo pi efficace. L'impressione comunque che con questo prodotto Microsoft stia svolgendo un diligente compitino per conquistarsi la medaglietta "agile" e la relativa fetta di sviluppatori.

Alberto Quario - Scenario testing

Questo forse stato l'intervento pi interessante della giornata. All'Agile Day si molto parlato di processi, ma ci si un poco scordati del codice. Alberto Quario ci ha riportati nel cuore del problema, citando le parole di Gerard Meszaros: I test possono diventare il collo di bottiglia dei processi agili. (Ma allora non le sparavo cos grosse quando parlavo dei test come palle al piede!). Uno dei principi da seguire per evitare che i nostri test divengano dei mostri incomprensibili, difficili da scrivere, leggere e manutenere il seguente: nel corpo del test deve andare tutto e solo quanto strettamente necessario per la sua comprensione.

Alcuni consigli sono quindi:

  • radunare in metodi dal nome esplicito (operational methods) i dettagli di inizializzazione dello scenario del test
  • se il test prevede, come nel caso si utilizzi DBUnit l'uso di file di inizializzazione, magari in XML, parametrizzarne la creazione rendendone chiaro l'intento all'interno del test

Francesco Mondora: vivere in un angolo proattivo

Francesco Mondora nel corso della sua presentazione ha detto di apprezzare eventuali riscontri da parte del pubblico. Ecco quindi il mio, che purtroppo negativo. Il tema trattato mi apparso fumoso, ed il tono ieratico utilizzato era probabilmente fuori luogo. Ma forse il problema solo mio che non sono riuscito a capire cosa si volesse comunicare...

Alberto Brandolini - Introduzione al Domain Driven Design

Ecco un'altra gran bella sessione, nella quale Brandolini ha descritto con abilit e preparazione i principi del Domain Driven Design.

Entrare nel dettaglio di quanto visto molto difficile, data la mole di informazioni trasmesse. Mi piacerebbe comunque segnalare il concetto di Bounded context, ossia il limite entro il quale il significato di un'astrazione del dominio non ambigua, o, per usare una visione pi orientata al codice, il limite di applicabilit di un gruppo di classi del sistema. Mi sono imbattuto in questo problema quando, nella mia presentazione su Scala, ho parlato di oggetti che ingrassano a dismisura. Da quanto ho capito, anche nel DDD ci si occupa di questo problema, ma da una prospettiva "sistemica": occorre definire l'ambito entro il quale opportuno riutilizzare il codice che definisce un'astrazione. All'esterno di tale ambito meno costoso riscrivere parte delle astrazioni ed accettare una certa duplicazione nei sistemi. Il tema, interessante e complesso, alla base del fallimento di grandi utopie Object Oriented come il progetto San Francisco di IBM. Anzi, a mio avviso mette in discussione tutti i miti dell'Object Orientation a partire dalla riusabilit, ma forse converr parlarne in un'altra occasione.

Conclusioni

Anche quest'anno l'Italian Agile Day non ha deluso le aspettative: relazioni quasi tutte di altissimo livello, con l'apprezzabile idea di aprire a contributi internazionali. Se proprio si vuole fare un piccolo appunto, si dovrebbe parlare di un'eccessiva enfasi posta sugli aspetti di processo a scapito delle sessioni "pratiche", anche se, come avete potuto leggere, i "puri" sviluppatori come me non hanno avuto occasione di annoiarsi.

Grazie a Marco Abis ed ai ragazzi dell'XPUG Bologna per l'enorme e riuscitissimo sforzo organizzativo.
(Ah, avete gi donato qualcosa all'Agile Day? ;-) )

Il miglioramento delle nostre capacit non previsto

Ho partecipato ad un sondaggio promosso da un nostro fornitore. Alla domanda "Quali delle seguenti azioni sono state intraprese dalla Vostra azienda per affrontare la difficile congiuntura economica?" le risposte possibili erano:

  • Riduzione dellorganico
  • Riduzione degli stipendi
  • Incremento dellattivit commerciale per trovare nuovi clienti
  • Incremento delle tariffe
  • Riduzione delle tariffe
  • Automatizzazione delle attivit svolte per i clienti
  • Nessuna delle prededenti

La risposta "Investimento in ricerca e sviluppo per migliorare la qualit dei prodotti e dei servizi offerti" non era prevista!!!

Ecco, un bel sondaggio pensato da un managment lungimirante.... :-(

Presentazione su Scala caricata su Slideshare

Ho deciso di provare il servizio di Slideshare pubblicando la presentazione su Scala che avevo tenuto presso l' XP-UG di bergamo qualche mese fa.

Il mio primo sito in PHP: Claudio Destito, artista contemporaneo

Ho finalmente completato il sito dell'artista contemporaneo Claudio Destito. Questo artista, che attinge al vocabolario del minimalismo reinterpretandolo in chiave nuova ed ironica, a mio avviso uno degli autori pi interessanti che operano attualmente nell'area di Milano.
E' stato interessante realizzare questo sito, sia perch le opere d'arte di Destito mi hanno coinvolto profondamente, sia perch ho avuto modo di scrivere codice di produzione in PHP.
L'impressione che ho avuto di questo linguaggio stata ambivalente: da un lato PHP uno strumento estremamente facile da apprendere, dall'altro...beh, forse non il pi adatto a creare codice pulito. Ma probabilmente questo solo l'impressione di un novizio: per avere un quadro diverso della situazione sarebbe magari opportuno seguire il corso sull'argomento di Francesco Cirillo ;-)

RDS Kata

In questo post mostrer la mia discutibilissima soluzione allRDS Kata proposto sul blog di SI-Agile, il vivace gruppo che raccoglie gli agilisti della Svizzera Italiana. Il codice presente in questo file zip, spero a breve di creare un progetto su Google Code per ulteriori sviluppi.

Funzioni di utilit

Partiamo subito con la prima sequenza di test.
Leggendo tutti i requisiti del Kata, ho pensato fosse necessario avere in primo luogo una funzione che centrasse le stringhe secondo le specifiche. Ho pertanto creato dei test per un metodo statico center da inserire nella mitica classe di utilit StringUtils, che non pu mancare in qualsiasi progetto Java. Il primo banale test, testCenterDoesNotChangeTooLongStrings, mi servito per disegnare linterfaccia del metodo. Per scrivere i test successivi mi sorta la necessit di avere una funzione blanks, che, guarda caso, mi poi tornata utile anche nel codice di produzione. Ho deciso di non scrivere un test specifico per blanks, avendo fiducia che, una volta creata correttamente la funzione stringOf, la sua specializzazione che creasse stringhe di spazi fosse banale.
Uso qui volutamente il termine di funzione, in quanto questi metodi hanno la propriet di trasparenza referenziale, ovvero restituiscono sempre gli stessi valori a fronte dei medesimi ingressi, indipendentemente da un qualsiasi concetto di stato del sistema; inoltre non hanno alcun effetto collaterale. Se ci fosse la possibilit di utilizzare i metodi statici come parametri di altre funzioni ;-)
Concludendo le divagazioni, vorrei solo annotare che, per migliorare la leggibilit del codice e ridurre le duplicazioni, ho fatto un po di refactoring sui test estraendo il metodo assertCenterReturnsAStringOfFixedLength.

Le classi principali

Sono poi passato al disegno principale della mini applicazione tramite i test di RDSGeneratorTest che ho cercato di rendere indipendenti dal numero di caratteri del display.
Leggendo le specifiche del Kata ho cercato di elaborare una metafora: le varie parti da mostrare sul display (autore, data, titolo) sono gruppi distinti di parole, ovvero delle frasi. Ho quindi stilato i test di RDSSentenceTest, facendo anche in questo caso attenzione a rendermi indipendente dalla lunghezza del display. La prima stesura della classe RDSSentence, che comunque supera tutti i test, stata la seguente:

 
public class RDSSentence {
 
  private final String sentence;
  private final int displaySize;
 
  public RDSSentence(String sentence, int displaySize) {
    this.sentence = sentence;
    this.displaySize = displaySize;
  }
 
  public String[] tokens() {
    if ("".equals(sentence.trim())) {
      return new String[]{};
    }
 
    String[] tokens = sentence.trim().split("\\s+");
    if (tokens.length == 0) {
      return new String[]{};
    }
 
    Collection<String> result = new ArrayList<String>();
    StringBuffer accumulator = new StringBuffer();
    for (int i = 0; i < tokens.length; i++) {
       if (accumulator.length() + tokens[i].length() + 1 <= displaySize) {
         if (accumulator.length() > 0)  {
           accumulator.append(" ");
         }
         accumulator.append(tokens[i]);
       } else {
         if (accumulator.length() > 0) {
           result.add(accumulator.toString());
         }
         accumulator = new StringBuffer(tokens[i]);
       }
       if (i == tokens.length -1) {
         result.add(accumulator.toString());
       }
    }
 
    return result.toArray(new String[]{});
  }
 
}
 

Come potete vedere, il codice troppo complesso, con un numero ciclomatico molto elevato. Per un buon refactoring occorreva unaltra metafora: il display che accumula parole fino ad una certa lunghezza pu essere appunto visto come un accumulatore elettrico, o, se vogliamo, idraulico che, raggiunta la capienza, si svuota in un tubo di scarico. Sono nate cos le classi Accumulator e StringWharehouse, che non hanno test autonomi, ma vengono esercitate indirettamente dai test di RDSSentenceTest. La classe StringWharehouse, con una leggera modifica, mi poi stata utile per migliorare il MockRadioStation, che in un primo tempo accumulava i dati in un semplice StringBuffer.

Conclusioni

Cosa ho cercato di esercitare con questo Kata?

Sicuramente non ho raggiunto completamente i miei obiettivi, spero comunque di aver fatto un piccolo passo in questa direzione.