Da molto leggo su questi post messaggi relativi a esami di certificazioni superati, e volevo aggregarmi al thread per riferire non la mia esperienza di certificazione, ma la mia intima conoscenza di un certificato MCSD.
Costui si vende in un azienda presso cui lavoro e, nell'ordine:
Non ha una conoscenza base delle naming convention da usare per scrivere buon codice, dice che tutte le classi debbono essere prefissate dal "cls", cosa che mi risulta si facesse in VB ( non posso dirlo per esperienza personale, dato che il buon Dio mi ha sempre aiutato risparmiandomi l'onere di usare tale linguaggio )
Non ha idea di cosa significhi programmare per interfacce, ne tantomeno di come disaccopiare il codice, tanto che ha deciso che ogni classe che deve essere prodotta debba prendere nel COSTRUTTORE l'instanza CONCRETA di un oggetto "configuratore" che legge da un file .INI vecchio stile le informazioni .
Non ha idea di cosa voglia dire caricare un assembly dinamicamente ( lascerei perdere le indagini sulla conoscenza di reflection)
Non conosce i fondamenti di COM interop, e di quanto possa essere utile -ancorchè, aggiungo io, -indispensabile- esporre via COM delle interfacce ( magari marcandole con dovuto GUID ) piuttosto che degli oggetti concreti.
trova una cosa meravigliosa l'ereditarietà ( forse è normale per un programmatore abituato a visual basic ) rispetto alla composizione.
Non ha una neanche accennata conoscenza di strumenti quali NUnit.
Ritiene che sia intelligente aprire una connessione ad inizio programma per poi chiuderla alla fine.
Ovviamente Composite UI Application block è per lui un oscuro mistero.
Quindi la domanda che mi sorge dal cuore è: ma come vengono assegnate queste certificazioni ??????
Esiste un organo di controllo, per cui se io ritengo che uno si "autocertifichi" possa essere smascherato ?
Non posso credere che MS faccia rappresentare se stessa da simili personaggi, a meno che il loro marketing non abbia deciso di trasformare la certificazione in un prodotto da vendere.
Ho appena rilasciato la versione alfa di un add-in per reflector che integra le funzionalità di un debugger a livello IL in reflector. In pratica è possibile debuggare le chiamate in assembly che non hanno informazioni simboliche, però con l'aiuto di Reflector e del suo disassembler. La versione appena rilasciata avrà sicuramente qualche bacherozzo, ma se qualcuno avesse voglia di provarla può avere ulteriori informazioni a questo
link.
Ho trovato una versione free di Codesmith con dei template per generare automaticamente le classi e gli hbm di nHibernate partendo dal db. Sfortunatamente i mapping non vengono accettati dall'engine di HIbernate corrente, in particolare non è accettato un campo column sotto una relazione one-to-one....
Sono un po' deluso, non voglio di sicuro mettermi a scrivere i file di mapping unio per uno.....
Il cruccio che avevo esposto in questo
post credo di averlo risolto...
qui la soluzione che ho provato.
Il cruccio che avevo esposto in questo
post credo di averlo risolto...
qui la soluzione che ho provato.
Voglio iniziare ad usare NHibernate come O/R nel progetto che sto facendo, ma ci sono un mucchio di cose che mi disturbano architetturalmente. in primis, per ragioni di scalabilità e robustezza la mia business logic è costruita in EnterpriseServices, e con un po' di sforzo sono riuscito a disaccopiare tutti i miei componenti in modo che esistono solo delle interfacce condivise ed il resto è gestito da un framework che inietta in ogni serviced component le "dipendenze di servizio". Ora il primo problema è: NHibernate ha un session factory, che dovrebbe per ragioni di efficienza essere singolo all'interno di una applicazione. L'altro problema è: come condivido tra tutti i serviced component il session factory ? La prima soluzione che mi viene in mente è: sfruttare Shared Property Manager per mantenere una reference condivisa visibile a tutti i componenti. Ammesso che questo funzioni, poi ho le classi di mapping. Visto che i componenti sono molto disaccopiati, e che ciascuno necessita di zone ben individuabili di database, vorrei che fosse il componente a tenere traccia dei template di mapping, con le relative classi, e questo cozza con la sessione unica, che mi costringe in fase di creazione del session factory a specificare tutti gli hbm. Insomma c'è qualcosa che non mi quadra, mi sembra che mettere su nhibernate mi faccia buttare alle ortiche tutto il lavoro di disaccopiamento tra componenti che ero riuscito ad ottenere.
Ho pensato di provare a scrivere un piccolo tutorial per raccogliere le mie esperienze su Enterprise Services.
Trovate qui la prima puntata. Sono graditi commenti e sparate sul pianista ;-)
Il primo browser, chiamato WorldWideWeb. L'ho trovato dal blog del creatore del WWW, Tim-Berners Lee.
In questo we ho trovato il tempo ( in verità ne è servito pochissino ) per mettere dasBlog sul mio sito
personale.
La scelta dell'engine è partita dagli interessanti
post su Ugi, e dal fatto che non avevo voglia di comprarmi il supporto SQL su Aruba, non tanto per il costo, ma perchè l'amministrazione remota mi preoccupa un po'.
In questo periodo sto lavorando ad una applicazione che prevede un data layer su 2003 server e client pocket PC. Alcune problematiche di base mi hanno fatto desistere dall'idea di implementare una web application, preferendo invece una applicazione winform leggera che si interfaccia con web service. Il CF 2 ha migliorato di molto quello che era il problema della velocità, tant'è che da palmare non si ha nemmeno la sensazione di utilizzare una applicazione distribuita ( il collegamento ovviamente è WiFi ). per l'interfaccia utente sul pocket ho deciso di utilizzare una strategia fortemente basata su dependency injection, implementando un mini framework molto leggero. In pratica la form principale dell'applicazione ha un panel che fa da host per degli user control ( che sono le videate dell'applicazione ) marcati con un attributo ( ie [SmartPanel] ) . un oggetto coordina la creazione e la visualizzazione dei vari pannelli e gestisce la associazione tra pubblicatori e sottoscrittori di eventi, nonchè l'iniezione delle dipendenze di "servizio". La cosa simpatica è che ho scritto veramente poco codice per mettere su la libreria, ed adesso l'applicazione procede piuttosto veloce e la separazione tra la gestione e l'interfaccia, ma anche tra i singoli elementi grafici di UI è completa.
Sfortunatamnte non ho ancora trovato una soluzione in rete, e non ho ancora immaginato come potrei fare, per portare lo stesso concetto di DI in Component Services. Il mio obiettivo sarebbe avere un framework su CS che, possibilmente senza utilizzare oggetti di factory personalizzati, potesse implementare un meccanismo di pubblicazione-sottoscrizione di servizi in modo da disaccoppiare e rendere intercambiabili i componenti all'interno di una applicazione "Servcied".