Guerra dei palazzinari

La guerra dei palazzinari che continuerà a sommergerci di cemento: http://www.adusbef.it/consultazione.asp?Id=6325&T=A

Il passaggio del testimone

La mia Professoressa di Italiano che non sentivo da un pò, e che quando ero ancora tra i banchi, con ancora tutti i capelli, tanta energia, ed infinite speranze, mi lusingava con voti mai sotto l'otto; mi ha scritto che avrebbe voluto passare il testimone dell'insegnamento ad un ragazzo come me. Questo mi ha fatto interrogare su che tipo di insegnante sarei stato. Devo innanzitutto dire che non ci ho mai pensato ad insegnare, sopratutto una materia come l'Italiano. Quando mi sono diplomato, ero indeciso se all'università iscrivermi ad Ingegneria oppure ad Italiano. Proprio nell'ultimo anno avevamo un assistente di laboratorio di elettronica, che era iscritto a Lettere, e che ci spiegava che la sua passione elettronica la sfogava nel lavoro, mentre quella per la letteratura nell'università. Alla fine mi sono iscritto ad Ingegneria, per poi passare a Scienze dell'Informazione, e da quel momento è iniziato un lento ma progressivo allontamento dall'entità Italiano.

All'università, purtroppo, l'Italiano non è una materia considerata, né molto praticata. I compiti scritti sono dimostrazioni matematiche, che necessitano di poche parole di spiegazione. Per quanto riguarda gli orali, non mi ricordo di nessuna richiesta in merito ad uno sforzo di espressione, del resto nemmeno le lezioni erano un esempio di retorica, tra un professore con un marcato accento napoletano, e le sue simpatiche lezioni dialettali, e un professore ungherese che a dire la verità, l'italiano lo aveva imparato abbastanza bene.

E' vero che mi rimaneva quella alta media di libri letti all'anno per essere un ragazzo e sopratutto italiano, ma forse questa unica frequentazione non si è dimostrata sufficiente. Non sarei mai stato in grado di insegnare. La mia ignoranza troppo ampia, la mia oratoria sempre considerata inferiore al mio saper scrivere, e la pazienza, anche questa inferiore a quanto se ne richiede in una professione così difficile.

No, credo proprio che sarei stato un pessimo insegnante. Forse c'è solo una cosa in cui forse avrei avuto qualche possibilità. Leggevo qualche tempo fa, Come un romanzo di Pennac, nel quale lui descriveva il suo vecchio professore, che entrava in classe con una pila di libri, li posizionava sulla cattedra, ne prendeva uno, e aprendolo cominciava a leggere.

Ecco forse, l'immensa passione per la lettura, quella l'avrei saputa divulgare.

Ballata del Programmatore

Tutta da ascoltare: La Ballata del programmatore

Java ostacolo alla formazione di solide basi per gli studenti

Nell'articolo Computer Science Education: Where Are the Software Engineers of Tomorrow?, Robert B.K. Dewar e Edmond Schonberg, illustrano i loro dubbi in merito alla adozione di Java come primo linguaggio di programmazione, nelle facoltà di Informatica. Nel doppio ruolo di professori della New York University e fondatori di una società specializzata in programmazione con Ada, ravvisano come questa scelta abbia indebolito la preparazione degli studenti, e come diventi ogni giorno più difficile recrutare personale dotato di solide basi. Secondo gli autori, negli ultimi anni, si stanno concretizzando alcuni trend negativi nell'insegnamento di Scienze dell'Informazione:

• Il contenuto teorico matematico nei corsi di Informatica si sta riducendo
  
• L'acquisizione di competenze in diversi linguaggi di programmazione sta lasciando il posto ad un approccio di ricopiatura di pezzi di codice, l'utilizzo di grosse librerie o package specializzati
  
• Le competenze acquisite sono insufficienti per l'industria del software odierna, mentre invece sembrano indicate per l'industria dell'outsourcing e così si producono professionisti facilmente sostitubili.

Ma quali sono le ragioni che li inducono a pensare che non sia corretta la generale adozione di Java come linguaggio di programmazione nei corsi introduttivi. Sicuramente la popolarità del linguaggio nell'ambito delle applicazioni Web e la relativa facilità con cui permette anche ai novizi di creare programmi dotati di grafica ha favorito questa scelta, ma verificano le difficoltà già nel primo corso di sistemi. Gli studenti hanno difficoltà nello scrivere programmi privi di interfaccia grafica, non riescono a percepire la relazione tra il sorgente e le elaborazioni hardware e non riescono ad entrare nella semantica dei puntatori.

Mi sembra molto chiaro il principio che spiegano in merito alla bellezza della programmazione. L'essenza della programmazione consiste nella riduzione di processi complessi in una serie di semplici operazioni primitive. Il linguaggio Java, secondo gli autori, invece di adattarsi a questa essenza, propone un approccio alla "idraulico in un negozio di ferramenta": rovistando in una moltitudine di cassetti - package - si arriverà a trovare un qualche attrezzo - classe - che più o meno è adatto a fare quello che ci serve. Come lo fa non è importante. Questo porta gli studenti ad essere dei confezionatori di pezzi di programma, ma non dei programmatori.

Un altro problema che individuano nell'uso delle librerie Java e dei framework è il fatto che gli studenti non riescono ad avere la percezione del costo di runtime di quello che producono, perchè è estremamente difficile ricostruire ciò che ogni metodo chiama e tutto il codice eseguito.

Devo dire che le ragioni esposte non mi convincono molto se applicate solo a Java. Sembra più che altro che si stia facendo una critica alla programmazione orientata agli oggetti, perchè le problematiche esposte si possono facilmente applicare a tutti quei linguaggi che si basano su questo paradigma. Ma del resto, chiariscono nel proseguio dell'articolo, che considerano importante imparare il Java, ma come competenza aggiuntiva.

Quindi per chiarire riassumendo, i due professori ritengono che come primo linguaggio di programmazione, per formare basi solide, non sia adatto un linguaggio object oriented, ma piuttosto un linguaggio imperativo, e sopratutto non si debba praticare un unico linguaggio, ma vederne diversi.

Donare il sangue e vincere un viaggio

Ad agosto con la città finalmente svuotata e il lavoro tranquillo, decido un giorno di andare a donare il sangue. Sono iscritto all'AVIS da qualche anno e quindi periodicamente vado presso il Policlinico di Roma, a fare la donazione.
Questa volta ho deciso di andare all'ospedale Grassi che si trova ad Ostia, dove risiedo. Il centro trasfusionale è piccolo ma funzionale. Effettuo il test previsto per la conferma della possibilità di donare; il dottore mi misura la pressione, e faccio la donazione.

Alla fine una signora mi dice che l'Associazione Gruppo Donatori Volontari "Amici del Servizio Trasfusionale dell'Ospedale G.B.Grassi di Ostia" per ringraziare i donatori del loro gesto, effettua periodicamente un'estrazione di un viaggio premio e mi invita ad inserire il mio nominativo nell'urna. Lo faccio e vado via.

A metà settembre mi telefona la signora Stefania Zoppis, presidente del Gruppo donatori, che mi comunica che sono stato estratto e che ho vinto un viaggio premio. Ci incontriamo la sera davanti ad un'agenzia di viaggio di Ostia, e con il budget del premio (tra i 300 e i 400 euro), l'Associazione ci paga (anche a mia moglie) un soggiorno ad Ischia per due notti in mezza pensione.

Una cosa stupefacente!!!

Ruby il linguaggio coetaneo di Java

Ruby è un linguaggio ideato dal Yukihiro Matsumoto nel 1995, quando usciva anche Java. E' un linguaggio interpretato scritto in C. Ha una versatilità non indifferente, dei costrutti innovativi come i Blocks. Nonostante esista da più di 10 anni, solo da relativamente poco ha avuto un discreto successo grazie a Ruby on Rails, un framework per lo sviluppo di applicazioni web.

Re-engineering Combat School

Comincio la mia carriera di blogger parlando della realtà del lavoro informatico che faccio ogni giorno. Nelle grandi aziende che frequentiamo per lavoro (Telecom, Hp, Agip, Sogei) e nelle quali introduciamo o tentiamo di farlo, strumenti informatici per la gestione di processi, il problema principale rimane sempre lo stesso. Occorrerebbe ridisegnare il processo che si va ad automatizzare, ma non ci si riesce quasi mai, perchè c'è sempre qualcuno che rema contro, o che semplicemente non fa il lavoro secondo i nuovi dettami, magari per semplice antipatia rispetto al prodotto che si trova sotto mano. Ma non è una questione di prodotto, perchè nonostante abbia avuto a che fare con diversi prodotti, e in diverse realtà, spesso il risultato è sempre lo stesso. In una realtà in cui si inserisce un prodotto informatico, che molti combattono si finisce per peggiorare l'efficienza complessiva del processo, e alla fine tutto il progetto implementativo viene buttato di "sana pianta".