Manuel's blog

In questi anni le tecnologie Microsoft si sono evolute (anche fin troppo velocemente, tanto che non è possibile assimilare tutto). Servono anni per appropriarsi di una tecnologia eppure tutto adesso si sviluppa nel giro di poco.

Oltre alle tecnologie abbiamo visto nascere nuovi pattern. Devo ancora approfondire ASP.NET MVC (ma gli strumenti non me lo consentono) però tutti questi linq, entity, etc non mi hanno entusiasmato. Per non parlare poi delle soluzioni delle aziende: interi DAL sviluppati e poi accantonati.

E' interessante conoscere i pattern e giusto svilupparli ma (la seguente affermazione dipende dal contesto):

"Io preferisco le query sql" 

Eh si, di gran lunga le più pratiche, veloci e capibili da tutti. Non se ne sente più parlare ma spero siano ancora le più usate. Non serve creare strutture complesse per gestire tutto: piuttosto serve qualcosa per scrivere le query velocemente. Per me è più utile un generatore di query che un pattern da seguire. Per aggiungere un campo su una pagina  devo scrivere 5 righe di codice non 10 classi.

Lo so che in tanti ora mi riprenderanno, ma, come ho detto prima, dipende dal contesto. Eppure non è in un progetto complesso che va usato un Data Layer complesso: piuttosto dove ci sono delle grosse elaborazioni va ottimizzato tutto. E fidatevi, se i progetti passano di mano... w le query! 

Mi sarebbe piaciuto farvi leggere un articolo scritto su un vecchio sito, dove viene spiegato come si sente una persona quando inizia a lavorare, come trascorre i primi giorni, il primo mese...ma non l'ho trovato. Peccato.

Oggi vorrei fare un paio di riflessioni sulla squadra di lavoro e fare un po' di concorrenza a Minudel  . Nel nostro lavoro, molto spesso nelle aziende piccole, si lavora in maniera individuale, ma a volte capitano dei progetti un po' più grandi dove bisogna lavorare in team. In queste occasioni nascono delle situazioni di confronto, di contrasto, di accordo che ci aiutano a crescere.

Io però non creo la squadra, sono un giocatore. E proprio come in ogni sport che si rispetti, ogni squadra ha i suoi membri con determinati compiti. Nel mondo del lavoro (e non parlo solo del nostro) molto spesso non è così. E' difficile valutare le competenze di ogni individuo ma è importante che in una squadra ci siano giocatori di tipo "diverso". Quel diverso è molto sottile: non si parla solo di ruolo. In una squadra, perchè sia tale serve l'introverso e l'estroverso, serve il portiere e l'attaccante, serve chi gioca sulla difensiva e chi sull'offensiva, serve chi innova e chi è tradizionalista...perchè tutte queste diversità possano amalgamarsi e dar luce a un "gioco" misto e vincente.

Purtroppo molte di queste caratteristiche non vengono considerate. E' stupefacente poi come una persona con 10 anni di esperienza abbia più competenze di una con due lauree e tre diplomi... ma l'obiettivo di una squadra è far acquisire il metodo e le conoscenze di chi ha studiato a chi non lo ha fatto e pratica a chi ha non ce l'ha.

Servono anni a creare una squadra vincente: parlo anche solo di 4-5 persone, figurarsi quando il numero sale. Ci vogliono pochi minuti a smembrarla. Un contrasto può derivare da mille ragioni: non ne elenco nessuna dato che non sto parlando di me e non vorrei che qualcuno equivocasse (se poi considerate che non viviamo in un Paese libero...). La mancanza di un elemento fondamentale della squadra vincente fa fallire l'intera squadra, così come l'inserimento di una pedina fuori posto.

Che dire? Preservate in tutti i modi le vostre squadre. A volte bisogna abbassare la testa, ma lo si fa a turno

Un po' spaventato da quello che è emerso sul recente sondaggio fatto, a proposito del testing sulle applicazioni, dico: approfondiamo!!! Io scrivo dei test, per quanto mi è possibile a causa dei ritmi di produzione, solo per applicazioni complesse. Finora non mi è mai capitato di scrivere prima il test e poi l'algoritmo e condivido l'opinione che il tester dovrebbe sempre essere una persona diversa rispetto a chi scrive la soluzione di un problema.

La questione però è un'altra. Molto simile a quella che avevo già trattato in altri post e che mi sta molto a cuore. La professionalità nel nostro campo è molto importante. Non sono una di quelle persone che sta a guardare se hai 2 lauree o 10 certificazioni: per me non conta. Riesco però a capire chi "è avanti" e ad ammirare chi si sforza di ampliare il proprio sapere e le proprie conoscenze.

Attualmente sto leggendo un libro su Javascript. E' il primo di un percorso che mi porterà verso Jquery che già uso e che, secondo me, è stata una delle più grandi rivoluzioni di questi anni. Lo applico ma mi rendo conto che la soluzione migliore dovrebbe prevedere la sua applicazione sopra le mie pagine già esistenti (proprio come mi è stato confermato dalla sessione di DotNetMarche tempo fa). Che dire? I ritmi di produzione lasciano poco spazio alle prove ma ci provo lo stesso... E alla fine di questi due libri ho in previsione un "must": Framework Design Guidelines..., perchè non si finisce mai di imparare.

Penso che una delle cose più belle sia leggere il codice degli altri: allarga gli orizzonti. Me ne accorgo quando eredito i progetti degli altri che sono fatti seguendo logiche di programmazione del tutto differenti dalle mie.

Non mi piace assolutamente chi "mette le toppe": è una soluzione che si paga alla lunga. Troppa gente fa il nostro lavoro: il nostro errore più grande è stato dare a disposizione gli strumenti per "creare" una parte di web. Forse dovevamo permettere solo la manipolazione. Troppi, oggi, si sentono padroni del web; troppi incompetenti. E io, che guardo comunque con occhio curioso, me ne rendo conto. Servirebbe davvero una bella pulizia: chissà magari si scoprirebbe che il livello è davvero molto alto e che anche io rientrerei tra quelli scartati...

A partire da questo post, ho creato (partendo da System.Web.Extensions e jquery):

protected void Page_Load(object sender, EventArgs e)

{

    JavaScriptSerializer serializer = new JavaScriptSerializer();

    Response.Write(serializer.Serialize(EmanueleFiller.FillEmanuele(new Emanuele())));

    Response.End();

}

$(function() {

    $('.mybutton').click(function() {

        $.getJSON('/PaginaDelServizio.aspx', {}, function(result) {    

        $('.mytesto').text('Nome:' + result.Nome );

        });

    });

});

E' uscita la nuova versione per il Framework 3.5:

http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=11121

Invece della crisi, forse ci dovremo preoccupare della tempesta?

http://www.repubblica.it/2009/05/sezioni/tecnologia/cellulari-2/cellulari-2/cellulari-2.html?ref=hpspr1

Con tutto il rispetto per tutti i programmatori, sottolineando che conosco le condizioni di produzione e che faccio parte di questa categoria, mi permetto di scrivere questo racconto per un piccolo sorriso. 

Buonasera,

siete seduti comodi? Bene! Siete davanti al Visual Studio e state per premere new ClassLibrary?

Siete proprio sicuri? E va bene, allora fatelo.

Quanto tempo avete a disposizione? Poco? Allora iniziate col chiamare il vostro lavoro "Insieme di classi" e non "Libreria". Se invece ne avete un po' di più allora ve lo permetto . Ma questo insieme di classi serve a voi per seguire un certo pattern o serve per distribuirlo a qualcun altro? Per gli altri? Allora cercate di prendere un bel respiro...

Che bellooo!!! Una nuova avventura... e ora? Vedete quel Class1 creato automaticamente? Vi serve? No? Allora cancellatelo, perchè lasciarlo lì a marcire?

Ora cominciate pure a scrivere del codice, a includere eventuali reference esterni. Perfetto.

Avete aggiunto qualche namespace del tipo System.Web.UI.WebControls? Si? State per caso sviluppando una libreria di controlli? No? Allora perchè lo avete fatto? Per poter utilizzare un controllo che verrà passato? Ma siete davvero sicuri che vi serve tutto il controllo? Non è che per caso vi basta una proprietà? Magari elaborandola e poi restituendola al mittente?

Bene... proseguite pure... perchè state includendo System.Configuration? Dovete impostare delle configurazioni sulla libreria? Non vorrete mica leggerle dall'esterno!!! Settings e parametri sui costruttori non vi sembrano una soluzione migliore?

State scrivendo qualche query? Avete pensato di configurare una connectionstring o qualche parametro in più per poter configurare il database di destinazione?

Avete cablato delle stringhe o dei messaggi di errore? Perchè? E se io volessi far diventare l'applicazione multilingua? Devo aprire la libreria con il Reflector e copiarmi i metodi relativi?

Ma quante belle classi avete scritto... ma non ci sono un po' troppi metodi uguali? Mai sentito parlare di ereditarietà? Provate a semplificare.

Avete finito? Di già? Mai sentito parlare del "virtual" per permettere a chi utilizza la vostra libreria di personalizzarla?

E infine... presente quelle righe verdi? Non sono inutili... perchè non commentate tutti i vostri metodi public e protected? Vi richiede troppo lavoro? Ma state consegnando qualcosa di completo, nei tempi giusti ma incompleto, che rallenterà comunque qualcun altro.

State compilando? Sicuri di non aver dimenticato ancora niente? Che ne dite di generare il file xml relativo ai commenti? Vi richiede 10 secondi del vostro tempo.

Ora, forse, avete prodotto qualcosa di accettabile, che se compilato in Release potrà essere utilizzato da qualcun altro. Una valutazione da FxCop vi richiede un altro minuto, perchè non darci un'occhiata?

 Applausi...

Ora dobbiamo anche chiudere questa falla:

http://dean.edwards.name/weblog/2005/03/ungreased/