Sabato 21 gennaio si è tenuta l’ultima ugialt.net conference, ultima nel senso che non ce ne saranno altre. Basta. Finito. Chiuso.

C’è un filo di dispiacere come per ogni cosa che finisce ma io, Simone e Claudio crediamo che sia stata la cosa più naturale da fare.

UgiALT.net è nata nel 2008, ricordo che nella prima conf eravamo circa una dozzina, Simone ci spiegava il nuovo ASP.NET MVC e Antonio ci parlava di metriche del codice, pochi ma molto attivi e con interessanti discussioni.

Continua a leggere…

Il post sui pagamenti ha fatto un po’ di rumore ed era quello che volevo, i pensieri che ho raccontato sono il sunto di mesi di osservazioni e di situazioni che sono peggiorate col tempo. Verso la fine dello scorso anno abbiamo preso alcuni provvedimenti che vorrei condividere con voi a partire dai contratti.

La prima cosa che abbiamo fatto è stato contattare un avvocato per formalizzare i nostri contratti. Sono più di 5 anni che lavoro come freelance/imprenditore e i miei rapporti con i clienti sono sempre stati regolati da offerte scritte di nostro pugno che spesso non venivano neppure firmate dal cliente. Quindi si basava tutto sulla parola di gentiluomini…e oggi ce ne sono pochi. A ottobre abbiamo contattato un avvocato per capire se c’erano margini di miglioramento. Ci ha ribaltato! Abbiamo fatto 2 o 3 incontri, gli abbiamo spiegato il tipo di attività che facciamo e i problemi ai quali andiamo incontro. Nel giro di poche settimane ci ha preparato una serie di documentazione che ad ogni offerta va allegata a quella che noi chiamiamo documento tecnico. Sono parecchie pagine, condizioni generali, particolari, clausole, ecc…scritte in legalese, e che il cliente deve firmare e mandarci via fax (no email, l’email, purtroppo in italia non ha valore legale) per accettare il tutto. Se anche voi volete rivolgervi ad un avvocato (cosa che consiglio) assicuratevi che abbia un minimo di competenza nel settore informatico altrimenti non sarà facile spiegare cosa fate e cosa vendete.

Continua a leggere…

Il 2011 è stato un anno particolare: la crisi, la situazione europea, il cambio di governo in Italia hanno mosso le coscienze dei cittadini che sembrano aver iniziato un percorso verso l’acquisizione di un nuovo senso civico (io ci voglio credere )

Da più fonti però si capisce che le cose non vanno benissimo, alcuni fatti.

• Ha fatto scalpore, ma non abbastanza, la notizia del suicidio dell’imprenditore veneto che non riusciva a riscuotere i crediti per 200k euro.
• Si è parlato molto su twitter di questo post in cui noi italiani siamo dipinti come eroi perché riusciamo a sopportare ritardi enormi nei pagamenti, e nonostante questo ce la facciamo (ma non sempre come abbiamo visto).
• Cris ieri su twitter ha scritto: “sono indeciso se cambiare la mia mission in “banca”, visto che sto continuando ad anticipare lavoro (quindi soldi) ai miei clienti. #shit“
• In CodicePlastico abbiamo chiuso un buon 2011 dal punto di vista del fatturato ma circa il 40% lo dobbiamo ancora incassare.

A me tutto questo fa molto incazzare, il nostro lavoro è principalmente di tipo intellettuale, fortunatamente non dobbiamo investire soldi in macchinari costosi ma questo non vuol dire che non c’è un’investimento alle spalle. Per poter fare una consulenza su ASP.NET MVC devo passare giornate a studiare, provare, formarmi, tutto tempo che *investo* per poi potermi vendere come consulente alle aziende che ne hanno bisogno. E siccome il mio cliente ottiene valore immediato dalla mia consulenza, io voglio essere pagato immediatamente.

Il proposito per il 2012 che io faccio, ma che vorrei che tutti i professionisti del web facciano, è quello di non concedere termini di pagamento lunghi e lasciar perdere i clienti che vogliono pagare a più di 30 giorni. Io nelle prossime settimane, abbandonerò alcuni clienti che seppur validi, hanno tempi di pagamento a 60 o 120 giorni. Lo faccio per me stesso e invito anche voi a farlo, e più siamo ad imporci più la qualità del nostro lavoro può migliorare.

Per chi non è ancora convinto di quello che ho scritto lo invito a guardare questo video dal titolo esemplare: Fuck you, pay me.

Lascio infine un paio di link sempre sul tema pagamenti, ritardi e pigrizia di Francesco Fullone: uno e due.

Le cose possono cambiare.

Come ogni anno questo è un periodo di bilanci sull’anno trascorso e di propositi per quello nuovo. Oggi sono andato a rileggermi la lista dei todo che a fine 2010 avevo scritto per il nuovo anno e posso dire con orgoglio che ho fatto quasi tutto quello che mi ero ripromesso di fare.

La lista conteneva MongoDb, un nuovo linguaggio di programmazione e partecipare ad un progetto open source.

MongoDb l’ho usato in un paio di piccoli progetti uno in C# e uno in RubyOnRails, in entrambi i casi ho amato la sua immediatezza e libertà nello schema dei dati, devo ancora capire e ragionare su come va modellato l’uso delle collezioni, degli embedded documents e delle relazioni, sono agli inizi, lo strumento è molto promettente (soprattutto in ottica DDD) ma come per tutti i db no-sql vanno affrontati i problemi derivanti da una mentalità relazionale.

Il nuovo linguaggio di programmazione è Ruby, ho scritto parecchio su questo tema, ho fatto un paio di progetti durante l’anno. Ruby è un linguaggio stupendo, di una semplicità elegante, sintetico ma leggibile, e poi c’è la community di Ruby che è attivissima, sforna gemme alla velocità della luce e realizza cose veramente interessanti. Non conosco ancora Ruby come vorrei, anche qui i miei legami con i linguaggi statici rallentano il salto verso il vero potere di ruby che sta nella metaprogrammazione.

Sul progetto OpenSource ci sto ancora lavorando, da un lato è nato conf-oo il sito usato per la ugialt.net che è disponibile su github, è molto prototipale, ha alcune buone idee ma ci si deve lavorare, è nato in fretta in queste ultime settimane vedremo di fare refactoring appena prendiamo fiato. Poi c’è un altro progetto in porto che però è ancora top-secret.

Questi sono stati i 3 todo “consegnati” a fine anno, ora è tempo di pensare al 2012.

Da qualche mese brescia è diventata un vulcano di iniziative legate la mondo web&startup. Ho già parlato di Webdebs ma in questo periodo stiamo andando oltre le nostre aspettative.

Webdebs è sicuramente stato il motore, la spinta che ha fatto emergere e far conoscere tante iniziative che rimanevano personali per la mancanza di un canale di comunicazione e che oggi meritano sicuramente uno sguardo. Un paio di settimane fa c’è stata l’inaugurazione di Talent Garden uno spazio di coworking in cui aziende talentuose e bravi freelance possono trovarsi per lavorare e per condividere conoscenza, c’erano circa 300 persone, ne hanno parlato i giornali, wired, il sole 24 ore, insomma hanno fatto un bel po’ di casino.

Tra le aziende che andranno ad occupare un po’ di spazio  c’è save the mom una startup che sta realizzando un’app per supportare le  mamme tecnologiche e impegnate dei giorni nostri.

Circa un mese fa c’è stato lo startup weekend da cui è uscito pepper tweet  un’applicazione web (scritta in node.js) che ha lo scopo di raccogliere le fotografie pubblicate su twitter relative ad un particolare evento (ci sarà alla prossima ugialt.net conference!)

Oltre a questo ci sono tante altre piccole realtà che stanno partento Igloo Labs, ViralFarm, UnclePear, Acqua Liofilizzata solo per citarne alcune.

Credo che il gruppo webdebs nato davanti ad un pirlo sia stato la scintilla che ha dato coraggio a tutte queste realtà di venir allo scoperto, farsi conoscere e condividere le proprie idee e di trovare amici, collaboratori e sostenitori…e proprio questa condivisione che ha sempre spinto le community è quel qualcosa in più che fa si che 1+1 sia maggiore 2.

Il motore organizzativo della ugialt.net conference si è attivato da qualche mese per organizzare la prossima conferenza.

Il 21 gennaio a Milano, presso la sede di Avanade, che da anni ci ospita, si terrà la settima UgiALT.net conference, un’occasione per confrontarsi sulle tematiche legate allo sviluppo di software .NET e non solo.

In questi giorni, fino a fine mese è aperta la Call For Paper, abbiamo già circa 30 proposte tutte di livello elevatissimo provenienti da illustri speaker italiani e anche stranieri. Se avete una proposta da inviarci potete farlo tramite il sito web http://ugialt.net fino al 27 novembre.

I prossimi step saranno le votazioni delle sessioni che vi  interessano. Avendo solo 19 slot dobbiamo a malincuore scartare alcune sessioni e riteniamo che il modo migliore sia far scegliere a chi parteciperà quali sono le più interessanti, perciò i primi giorni di dicembre apriremo una pagina per raccogliere le vostre 5 preferenze.

Quindi per ora mandate le vostre proposte….

Altre informazioni su date, scadenze, ecc…le trovate sul blog di simone.

Da poco più di un anno è attiva sul territorio bresciano una community, o meglio un gruppo di geek che va sotto il nome di WebDeBs. L’idea parte dal Cirpo circa un anno e mezzo fa, organizzando una serie di aperitivi chiamati BrainPirlo per chiacchierare di tecnologia, web, social media ecc…e oggi ci troviamo ad essere in 30-40 geek che una volta al mese si incontrano per una serata su vari temi legati al mondo web.

Io che ho sempre fatto centinaia di chilometri per partecipare agli incontri delle community non posso che essere strafelice di questa iniziativa che cresce di mese in mese e ci ha portato ad organizzare alcune delle più importanti conferenze italiane: quella sul mondo NoSql e quella di qualche settimana fa su Node.js (citata anche da SmashingMagazine…scusate se  è poco).

Oltre ai BrainPirlo serali ogni tanto ci scappa una grigliata in Baita, con protagonisti “stranieri” quali Odino, Fabio Fabbrucci e Davide Cerbo che ormai sono diventati “bresciani onorari”.

L’altra cosa che adoro di questa community, che la differenzia molto dalle altre che ho frequentato in passato è l’interculturalità che esiste grazie alla partecipazione di ragazzi che vengono da mondi diversi: ci sono programmatori PHP, Java, Ruby, C++, C#, Python…ma non solo ci sono web designer, imprenditori, esperti di social media, di marketing, di design, sistemisti, grafici, program manager…. tutte persone che hanno qualcosa da raccontare e insegnare agli altri e vi garantisco che ogni volta si impara sempre qualcosa di nuovo (…e si scopre che anche in PHP esiste un ORM!)

Questo aspetto, se da un lato può sembrare che tolga identità ad una community in realtà la arricchisce tantissimo perché permette di avere una visione delle cose molto diversa da come siamo abituati grazie al confronto di persone che fanno il nostro lavoro con strumenti e metodi diversi.

Insomma se siete Bresciani* o comunque volete partecipare tenete d’occhio il sito web, iscrivetevi alla mailing list, se volete proponete un vostro talk e sicuramente organizzeremo una serata.

*essere bresciani è una condizione interiore non geografica (cit.)

In questi giorni mi sto chiedendo quanto senso ha oggi scrivere un’applicazione (di medie/grosse dimensioni) in un solo linguaggio/framework.
Già nell’attuale versione del .NET Framework esistono 2 linguaggi che hanno scopi e usi differenti (C# e F#) e con l’arrivo di Windows8 si aggiungeranno anche Javascript e (pare) ci sarà il ritorno di C++, entrambi con scopi e utilizzi molto differenti.
Fuori dal mondo Microsoft, invece, si ha solo l’imbarazzo della scelta: RubyOnRails/Sinatra e decine di altri framework basati su ruby, PHP/Simphony/wordpress/ecc…, Python/Django, Node.js, Mongodb/Redis/Hadhoop/Couchdb… e chissa quanti altri ancora sono a disposizione di noi sviluppatori.

La particolarità è che quasi tutti questi strumenti e linguaggi non risolvono tutti i problemi, ma sono perfetti per affrontare in modo elegante e semplice un particolare problema, superando di gran lunga in termini di efficacia e performance linguaggi “general purpose” come C# o Java.

Quindi perchè non usarli?

Il primo problema, che vedo principalmente nelle aziende in cui faccio consulenza, è che si tende a specializzare i programmatori su un solo linguaggio/framework ritenendo di risparmiare  e facendo si che ogni problema debba essere risolto sempre con il Framework scelto creando a volte soluzioni complicatissime e mal funzionanti.

Il secondo problema è la pigrizia, io per primo pochi mesi fa, mi sono trovato a sviluppare un modulo in C#+SQL per fare delle cose che con Node.js+Redis avrei fatto in modo più semplice senza forzare il linguaggio e il framework in un contesto non completamente adatto al loro uso. Imparare un nuovo linguaggio costa, ma forse, sul lungo periodo, usare uno strumento non adatto costa di più …tant’è che ora, quel modulo, stiamo valutando di riscriverlo.

Il terzo problema è l’instabilità di alcuni di questi strumenti. Node.js sta per arrivare alla versione 0.5 è ancora molto giovane e di versione in versione i breaking changes sono numerosi costringendo chi lo utilizza ad un massivo refactoring per stare al passo con le novità. Poi, molti plugin, non vengono sempre aggiornati e quindi anche in questo caso vanno aperti e modificati (e se possibile pushati su github per renderli disponibili a tutti). Non è cosi per tutti, nel mondo Ruby si è raggiunta una certa maturità che garantisce una certa continuità e comunque il mondo open source è così, con i suoi lati positivi e negativi.

Ultimo problema la piattaforma. La maggior parte degli strumenti elencati sopra non va molto d’accordo con Windows e preferisce girare su un sistema unix/linux. Questo non lo vedo come un problema, linux si può avere gratuitamente e una macchina virtuale la si prepara in poco più di 10 minuti.

Detto ciò, soprattutto come consulente, mi sento in dovere di proporre al cliente la soluzione migliore che spesso non è solo .NET ma .NET affiancato ad altri framework che lo supportano dove (almeno per il momento) ci sono ancora delle lacune.

Perciò uno dei propositi per i prossimi mesi è alzarsi dal comodo divano di .NET e iniziare a guardarsi un po’ in giro per imparare ad utilizzare altri strumenti e linguaggi migliorando il modo in cui vengono realizzate le applicazioni e soprattutto dando più vantaggio ai nostri clienti.

ASP.NET MVC è stato rilasciato alcuni anni fa e nonostante non sia ancora diffusissimo (più che altro per questioni psicologiche) sta pian piano mangiando terreno ad ASP.NET WebForm dimostrando ancora una volta che la semplicità paga.

Infatti molti dev WebForm che hanno avuto la possibilità di provare ASP.NET MVC fanno il possibile per migrare al nuovo framework ma alcuni commettono l’errore di pensare ancora in termini di pagine introducendo a mio avviso un antipattern.

ASP.NET MVC implementa il pattern MVC (ma va?) o come sottolineerebbe il caro Andrea il pattern Model2.

La grossa differenza rispetto a WebForm è che l’applicazione non espone delle pagine ma delle risorse (o entità) su cui fare le operazioni e la corrispondenza dovrebbe essere una risorsa un controller (REST vi dice qualcosa?).

Quindi mentre con ASP.NET Web Form si tendeva a creare una pagina per ogni scenario di utilizzo indipendentemente dalle risorse coinvolte con ASP.NET MVC è preferibile creare dei controller che siano più coesi con ciò che rappresentano piuttosto che controller che contengano una sbrodolata di metodi non correlati. Su questi controller vengono poi montate una serie di View che prendono ed elaborano i dati per visualizzarli.

Faccio un esempio per chiarire cosa intendo. Consideriamo il seguente controller:

public class CustomerController : Controller
{
  // ...

  public ActionResult GetOrders(int customerId)
  {
    // ...
  }
}

Mi aspetto che il CustomerController effettui operazioni su un cliente ma il metodo GetOrders sta introducendo un’operazione su una nuova risorsa che dovrebbe avere il suo controller dedicato. Per questo la scelta più giusta sarebbe chiedere al controller di order di darmi l’elenco degli ordini del cliente in questione, e questa richiesta dovrebbe arrivare dal client (browser) utilizzando verosimilmente un javascript.

Può sembrare strano all’inizio perchè una parte di logica viene spostata sul browser ma non ci vedo nulla di male, ormai come detto più volte non siamo solo programmatori C# ma anche programmatori Javascript dove il browser è la nostra piattaforma di sviluppo e visto che non sono solo dei visualizzatori di HTML ma delle vere e proprie virtual machine javascript non vedo perchè non sfruttarli.

Procedendo secondo questo pattern quello che si ottiene è un server che espone delle risorse in formato Json (o XML o altr0) e un client che tramite javascript richiede a vari controller i dati che servono per comporre la pagina: un controller = una risorsa.

In questo modo risulta molto facile creare diverse tipologie di client riutilizzando al 100% il server che risulta agnostico al tipo di visualizzazione.