mercoledì 3 settembre 2008
ecco la schermata delle opzioni di Google Chrome
Che cosa vuole dire "Roba da smanettoni"??? Sarà che il termine "smanettone" mi è sempre stato sulle @##@[ perchè vuole dire tutto e niente :D, la gente in continuazione ti incontra al bar e ti dice "tu che sei uno smanettone, ieri mi è successo questo, stavo girando sul sito amici dei gatti quando improvvisamente si è aperta una finestra che....",
Ora vorrei vedere la versione inglese che cosa contiene nel terzo tab.......
La scelta è sicuramente più ragionata, mi chiedo chi ha curato la versione italiana, come dice un mio amico "Ma l'hanno fatto due nerd nello scantinato??"
alk.
mercoledì 27 agosto 2008
Leggendo il post di Andrea mi trovo a condividere i suoi problemi. Le tastiere dei portatili, all'inizo le odi perchè sono piccole, poi non puoi fare a meno di apprezzare la leggerezza dei tasti. Io personalmente ho provato una logitech standard e non mi è piaciuta, sono quindi passato alla ultra flat
http://www.logitech.com/index.cfm/keyboards/keyboard/devices/177&cl=it,it
e debbo dire che mi ci trovo abbastanza bene, non è leggera come quella del portatile, ma sicuramnte è moolto più leggera di una tastiera tradizionale, complice soprattuto la minore escursione che deve fare il tasto per essere premuto.
La tastiera costa veramente pochi euro, ma è indubbiamente una delle parti più importanti, considerando che per chi ci digita 10 ore al giorno, il rischio tendinite è sempre dietro l'angolo.
alk.
lunedì 25 agosto 2008
Ho trovato un link: http://www.stupidcubicle.com/ dovrebbe contenere materiale per geek :), il problema è che quando ci vado trovo questo
Ok, è vero che da queste informazioni non si ricava nulla, ma fare vedere gli spezzoni di codice a tutti è un bug di sicurezza. L'utente non sviluppatore dovrebbe vedere una semplice pagina di scuse tipo "Sorry, the application has encountered an error", loggare l'errore tipo con elmah, e non far vedere a nessuno il codice che c'è dietro. A livello di security dare un messaggio di errore cosi dettagliato è una cattiva pratica.
alk.
martedì 19 agosto 2008
Dopo avere letto il libro JQuery in Action (che caldamente consiglio a tutti coloro che sviluppano web) ho iniziato a usare le prime istruzioni JQuery.. e debbo dire che rimango affascinato da come semplifichi la vita nella gestione delle classiche funzionalità ajax di un sito. Decisamente una libreria molto utile e potente.
alk.
lunedì 18 agosto 2008
Ho appena letto un bellissimo post di Roberto Messora, nel quale Roberto evidenzia come cercare la perfezione lo porta spesso ad essere meno produttivo e da li si parte su un discorso più ampio.
Con l'uscita di EF infatti MS ha "Sdoganato" gli orm, ora che si ha un ORM di casa Microsoft tutti si interrogano sul: è utile? può aiutarmi nel mio lavoro di tutti i giorni? etc, etc e contemporaneamente sempre più si parla di pattern, progettazione OO, e chi più ne ha più ne metta.
Il problema di questo interesse verso le nuove tecnologie è che si perdano di vista le necessità degli stakeholder, siano essi i committenti del progetto, ma più spesso anche gli utenti che andranno ad utilizzare il software stesso, con il rischio che il prodotto completo alla fine non soddifi le reali esigenze.
La domanda fondamentale che ogni sviluppatore/architetto/modellista software deve porsi, prima di decidere quale metologie adottare, è: "l'adozione delle tecnologie/pattern/principi X Y Z può aiutarmi a scrivere software che soddisfi maggiormente gli stakeholder?". Il problema nasce quando la domanda in realtà è: "Usare le tecnologie/pattern/principi X Y Z mi fa scrivere software che soddisfi maggiormente me stesso che lo scrivo o altri sviluppatori che poi ci lavoreranno?".
Sarà che ho letto recentemente "Why software sucks", ma la sostanza è che noi sviluppatori/architetti/modellisti diamo al software pesi pesi differenti dai nostri stakeholder e tendiamo a dare maggiore enfasi a caratteristiche del codice che a conti fatti, non portano nessun beneficio osservabile per chi poi il software lo usa veramente. Il problema quindi è adottare una tecnologia solo quando ci aiuta a scrivere software migliore (per gli altri, non per noi stessi) e non invece solo perchè ci piace o perchè è di moda.
Un esempio classico è il Testing, argomento controverso e molto attuale. Il rischio è che si passi da una situazione in cui i progetti non hanno nemmeno un test automatizzato, ad una in cui si perde tempo solo per raggiungere 100% code coverage, oppure ancora peggio, si adottano architetture particolari con la sola ragione di rendere il software Testabile. Alla fine dei conti al cliente non importa nulla se gli facciamo vedere una schermata di NCover che mostra come ogni linea di codice sia stata testata. ;)
Alla fine tutto questo discorso può comunque essere riassunto da una bellissima frase di Raf a commento del post di Roberto.
"La conoscenza è "obbligatoria" per fare il mestiere, saper scegliere è quello che fa la differenza."
Da qui ne discende che è sempre bene cercare di aumentare sempre il più possibile le proprie conoscenze, ma cercare nel contempo di capire a fondo dove realmente applicarle e dove no.
Alk.
venerdì 8 agosto 2008
Il Cruise Control .NEt è veramente uno strumento che quando hai messo su la prima volta non ne puoi più fare a meno. Una delle cose che preferisco è che quando uno sviluppatore rompe la build, (ad esempio si scorda di aggiungere con tortoise i nuovi file) subito il cc.tray diventa rosso e segnala il problema. Sono quindi lontani i giorni in cui la mattina fai un update e ti trovi che la soluzione non compila, mancano file o ci sono errori e lo sviluppatore che fatto l'ultimo checkin è andato in ferie proprio quel giorno :D :D
La cosa più carina è però la possibilità di suonare un file audio se la build si rompe, dopo una piccola ricerca ho trovato in un sito questo bellissimo suono di piatti rotti :D.
Spesso quando sono in skype la gente mi dice "hey...ti si è rotto un piatto a casa?"
Naturalmente quando invece la build compila ancora è necessario sentire un bell'applauso :D.
alk.
mercoledì 6 agosto 2008
Ieri sera alla periodica riunione di DotNetMarche abbiamo come al solito mangiato qualche bel kilo di fiorentina, non si può proprio dire che siamo vegetariani.
Scherzi a parte, sembra che siamo pronti per il grande passo, ovvero fare di DotNetMarche un'associazione senza scopo di lucro ufficialmente riconosciuta. Il tutto verrà fatto probabilmente dopo l'estate, intanto si sta organizzando un evento su sharepoint...insomma, dopo quasi due anni di attività siamo ancora li e questo è già un bel traguardo.
Ciao a tutti.
Alk.
martedì 5 agosto 2008
Sto istallando l'ultima versione di Tortoise, debbo dire che è un prodotto decisamente interessante, e che permette di gestire il subversion in maniera veloce e completamente intuitiva. Cmq personalmente ho sempre istallato anche il client in modalità console, utilissimo specialmente per fare file bat.
Ad esempio, avendo più progetti in più repository (lavoro, locale, googlecode etc), è semplicissimo farsi un file bat nel desktop che uno dopo l'altro aggiorna tutti i repository in maniera automatica, senza doverci fare tasto destro etc etc. Decisamente trovo che l'accoppiata Tortoise+Subversion sia veramente veloce e produttiva, soprattutto quando avete i repository in macchine internet a cui accedete tramite vpn, con una adsl sembra quasi di lavorare in locale.
alk.
giovedì 31 luglio 2008
Ho appena letto un paio di post, uno di Andrea ed uno di Raf, sul domain model e sulla effettiva necessità di un dominio non solo "persistence ignorant" ma infrastructure ignorant. Decisamente poter creare un dominio infrastructure ignorant è una sfida interessante, e non posso che dire di essere daccordo con Andrea. D'altra parte come Raf fa notare, pensare di usare proxy potrebbe essere veramente dannoso per le prestazioni.
Personalmente non vorrei preoccuparmi a priori delle prestazioni, a parte il "premature optimization is the root of all evil", preferisco avere una architettura più manutenibile, e tenere sotto controllo le prestazioni durante lo sviluppo per capire se le soluzioni adottate siano in linea con i requisiti. La generazione di proxy a runtime può essere interessante (ci ho lavorato e la reflection.emit è decisamente divertente), ma a mio avviso non è adatta per questo genere di cose, si è vero, posso generare un proxy che supporti INotify... e quello che mi pare, ma poi è una classe che a design time non esiste, non posso interagirci, etc etc.
Un approccio decisamente migliore è la generazione del codice design time, un po come il dataset Strongly typed. In questo modo ad esempio si potrebbe scrivere un generatore di DTO a partire dagli oggetti di dominio. L'approccio dei DTO è infatti quello che preferisco, anche perchè è possibile in questo modo ridurre i dati da trasmettere. Se ho un oggetto con 10 proprietà e mi serve una lista di tali oggetti da mostrare su una griglia che binda solo 3 proprietà su 10, avere un DTO specializzato allo scopo è sicuramente la cosa migliore.
Il problema dei Dto è naturalmente che: se li gestisci a mano, puoi farlo per un dominio di poche entità, altrimenti diventi matto, se usi un generatore, questo deve essere il più possibile automatizzato. A suo tempo pensai ad esempio ad usare codesmith, ma c'è bisogno di qualche cosa di più efficiente. La cosa migliore sarebbe avere un designer simile a quello delle classi o dei dataset strongly typed, potere fare drag and drop di classi, decidere quali proprietà spostare e generare tutto il codice a design time, magari utilizzando anche delle partial property per potersi intrufolare in mezzo al codice generato se possibile. Il problema maggiore di un approccio fortemente DTO oriented è che, come dice raf
Il costo di creazione e manutenzione dei proxy e del codice che serve a fare quelle stesse cose (ma dall'esterno dell'entity) non è poco: maggiore complessità e ciclo di vita più lungo del software
Però in certi casi sono cose che tolleriamo senza problemi, il lazy load NHibernate lo fa con Castle.DynamicProxy (Nhibernate 2.0 dovrebbe essere portato a DynamicProxy2) ed è una cosa che non ha mai sollevato troppe obiezioni. D'altra parte ci fidiamo del fatto che il generatore di codice sia corretto, per cui l'unica manutenzione è al massimo quella di mantenere i file di mapping o qualsiasi artefatto sia stato creato per stabilire come il codice debba essere generato.
Il problema di fondo è che raggiungere la completa ignoranza dell'infrastruttura è sicuramente utopico e forse anche troppo radicale, quello che vorrei è solamente poter limitare al minimo questa intrusione. NHibernate riesce a fare persistenza richiedendo poche specifiche alle nostre classi (membri virtuali per i proxy, un costrutture di default, ..), per cui è sicuramente possibile fare librerie di infrastruttura poco intrusive ;). Mi piacerebbe che quando qualcuno progetta infrastrutture cercasse di realizzarle nel modo meno intrusivo per le entità di dominio, se poi questo non è possibile bene, ma almeno provare.
Il rischio è che ci si trovi ad avere la classe X che implementa 10 interfacce solo per il piacere di essere usata da EntityFramework, Reporting Services, Crap Library, bla bla.
alk.
martedì 29 luglio 2008
"...the programmers and architects and managers who develop software don't understand their customers anywhere near as well as they should, as well as designers in other industries have been forced to"
"As with many areas of computing, user interface design is a highly specialized skill, of which most programmer knows nothing"
"Programmers value control more than ease of use, concentrating on making complex things possible instead of making simple things simple."
"User interface design guru Alan Cooper defines a "computer-literate user" as one who has been hurt so many times that the scar tissue is thick enough so he ho longer feels the pain"
"The human dimension is the first problem that any security system need to solve, and very few even attempt it".
Da Why software sucks di David S.Platt.
Debbo dire che è un libro veramente carino che si fa leggere decisamente bene. Sono rimasto sorpreso anche dal fatto che c'è una lunga sessione dedicata alla sicurezza. Sicuramente un libro da leggere.
Alk.
Tags: Why software sucks