Scusa ma nel tuo lavoro quotidiano non usi gli strumenti migliori? Non metti i dipendenti nelle migliori condizioni?

Qualche domanda, spero retorica:

  • se sei un fotografo usi la Polaroid o una Canon/Nikon reflex di fascia alta? (per par condicio le ho messe entrambe così si evitano discussioni off topic)Utensili Beta
  • se sei un meccanico utilizzi gli attrezzi della Beta o la brugola dell’Ikea?
  • se sei un manager nel tuo ufficio hai 5 server di fianco alla scrivania? L’aria condizionata in fronte? La sedia senza schienale o senza ruote?

E così via, credo che potrei andare avanti per coprire qualunque settore lavorativo.

Ma allora qualcuno deve spiegarmi perché quando giro in aziende che sviluppano software sento e vedo sempre più spesso situazioni del genere seguente.

“Il cliente tipicamente rimane sbalordito dalle caratteristiche del mio portatile”

La brugola, lo strumento simbolo dell'IkeaSi ho un portatile con processore di ultima generazione, tutta la ram che ci può stare dentro e 2 dischi di cui uno SSD.

Non vedo perché dovrei usarne uno più lento visto che ci lavoro sopra 8 ore al giorno, compilo, ci girano i test (hai i test vero?), gira il database, magari qualche macchina virtuale.

Oggi l’hardware ha dei costi veramente irrisori rispetto al tempo che ci fa risparmiare e al minore stress che ci provoca una macchina lenta.

“Ho visto aziende con sviluppatori ammassati su tavoli scomodissimi, piccoli e con sedie rotte o in posizioni infernali (tipo col sole alle spalle o vicino alla rumorosa sala server).

Oppure in cui i dev scrivono il nome sullo schienale perché non ci sono abbastanza sedie per tutti e domani potrebbero non trovarla!”

Ricordo che chi produce software ancora per oggi è un essere umano. La produttività di uno sviluppatore è legata anche all’ambiente lavorativo che lo circonda. Quindi magari può essere utile che non sia troppo rumoroso, troppo caldo, troppo freddo, che la sedia abbia lo schienale, che il tavolo mi consenta di starci sotto senza che abbia un piede del tavolo stesso tra le gambe. Pensate che i dev chiedano troppo? O forse spesso non chiedono perchè per passione o per sovraccarico sono talmente immersi nel lavoro che non ci pensano o per reverenza e pudore non ve lo chiedono.

“Incontro sviluppatori che programmano 8 ore su monitor da 15 o 17 pollici.”

Anche questo è legato alla produttività e alla qualità di quello che facciamo. Un monitor più grande mi consente di avere sotto controllo più informazioni, di facilitare i confronti, di affaticarmi di meno. Tralascio sull’utilità di 2 monitor affiancati…

“Mi serve un software per fare l’attività X. Ne ho trovato uno eccezionale, fatto da una società molto in gamba. Però costa troppo allora uso questa alternativa open-source. Spesso si blocca, non ha documentazione e devo manutenerlo di continuo ma costa zero”

Ecco qui il tema non è la diatriba open-source/closed source ma se esiste un software che mi fa lavorare meglio, produrre di più, ridurre i costi siamo sicuri che il ROI legato al costo di acquisto non sia ben più favorevole di un’altra soluzione? Per non parlare di chi si sviluppa in casa tool che magari sul mercato sono già ampiamente collaudati e ricchi di funzionalità.

A volte prima di parlare di architettura, DDD, Agile, SCRUM che vanno tanto in voga oggi e che piacciono tanto ai PM credo che sarebbe necessario partire dall’abc che ogni imprenditore o manager di qualunque settore dovrebbe conoscere e applicare.

Come fai ad essere Agile su un Pentium?

Come al solito l’informatica è diversa dagli altri settori e come spesso capita questa diversità è in negativo.

Dai che con poco si può fare un grosso salto in avanti!

PS: qualche consiglio pubblicitario per gli acquisti:

  • monitor: almeno 24 pollici, magari 2 monitor
  • Ram: tanta, almeno 4 gb
  • se proprio non volete cambiare il PC o il notebook fate la cosa che oggi ha in assoluto il miglior rapporto prezzo/prestazioni: comprate un disco allo stato solido!
  • un sistema operativo performante e stabile (leggasi Windows 7 se si parla di mondo Microsoft)
  • il migliore IDE che ci sia in commercio (leggasi Visual Studio 2010 se si parla di nuovo di mondo Microsoft)
  • la sedia con le ruotine please!
  • magari spostare i dev dal magazzino ad un ufficio
Share

Aggiornare in automatico i package NuGet in tutti i progetti della soluzione Visual Studio

Difficilmente una soluzione Visual Studio contiene solo un progetto.

Supponiamo di avere una soluzione con due class library project A e B e di aggiungere il package NHibernate versione 3.1.0.4000 ad entrambi i progetti.

Se si utilizza NuGet out of the box e si esegue il comando (sul progetto A)

 

Update-Package NHibernate

 

verranno aggiornate solo le reference del progetto A e non del progetto B.

E’ quindi necessario eseguire manualmente l’update su tutti i progetti che usano un certo package.

Per aggiornare tutti i progetti che utilizzano uno specifico package è possibile installare preventivamente il package NuGetPackageUpdater che si occupa proprio di aggiornare in automatico tutti i progetti che utilizzano un determinato package.

Eseguendo quindi il comando

 

Update-Package NHibernate

 

si ottiene questo risultato:

PM> update-package NHibernate

Updating NHibernate in all referenced projects

‘Iesi.Collections (= 3.2.0.2001)’ not installed.

Attempting to retrieve dependency from source…

Done.

Successfully installed ‘Iesi.Collections 3.2.0.2001’.

Successfully installed ‘NHibernate 3.2.0.2001’.

Successfully removed ‘NHibernate 3.1.0.4000’ from ClassLibraryA.

Successfully removed ‘Iesi.Collections 3.1.0.4000’ from ClassLibraryA.

Successfully added ‘Iesi.Collections 3.2.0.2001’ to ClassLibraryA.

Successfully added ‘NHibernate 3.2.0.2001’ to ClassLibraryA.

‘NHibernate 3.2.0.2001’ already installed.

Successfully removed ‘NHibernate 3.1.0.4000’ from ClassLibraryB.

Successfully removed ‘Iesi.Collections 3.1.0.4000’ from ClassLibraryB.

Successfully added ‘Iesi.Collections 3.2.0.2001’ to ClassLibraryB.

Successfully added ‘NHibernate 3.2.0.2001’ to ClassLibraryB.

Successfully uninstalled ‘NHibernate 3.1.0.4000’.

Successfully uninstalled ‘Iesi.Collections 3.1.0.4000’.

NB: se si utilizza il file nuget.config per spostare tutti i package come riportato in questo precedente post questo tool non funziona. Comunque la feature che consente di avere un solo folder a livello di soluzione è in corso di implementazione (http://nuget.codeplex.com/wikipage?title=Package%20Updates%20Should%20Be%20Global).

Share

SMAU Bologna e Community Tour 2011 – Windows Phone, HTML 5 e MVC

Giovedì 9 giugno 2011 nel contesto di SMAU Business alla Fiera di Bologna si terrà una nuova tappa del community tour organizzata da DotDotNet.

L’evento avrà come tema il presente ed il futuro del web con sessioni su Windows Phone 7, HTML 5 e MVC 3.

Mi è piacevolmente toccata la sessione su ASP.NET MVC 3 che considero un prodotto fondamentale per chiunque sviluppi su web applicazioni di una certa dimensione/durata.

Come al solito vi invito all’evento ed alla cena a seguire.

Agenda

Ora Sessione Speakers
13.45 – 14.00 Registrazione
14.00 – 14.45 Keynote – Presente e futuro del Web Microsoft Italia
14.45 – 15.45 Introduzione alla piattaforma Windows Phone

Windows Phone 7 ha introdotto un nuovo modo per intendere il telefono e una nuova piattaforma basata su hardware consistente, una piattaforma di sviluppo basata su Silverlight e XNA e un Marketplace con nuove opportunità di business.
In questa sessione vedremo come sviluppare su Windows Phone, come promuovere le proprie applicazioni tramite il marketplace e inoltre vedremo le moltissime novità della versione “Mango” che verrà rilasciata in autunno.

Lorenzo Barbieri
Microsoft Developer Evangelist
15.45 – 16.00 Pausa
16.00 – 17.00 Le novità di HTML5

HTML5 è il nuovo riferimento per lo sviluppo di siti e applicaizoni web based. In questa sessione vedremo come il nuovo standard può essere utilizzato per realizzare contenuti cross-browser e plugin-free ad alto impatto visuale.

Alessandro Scardova
Microsoft MVP, DotDotNet
17.00 – 18.00 ASP.NET MVC3

MVC favorisce la manutenzione delle applicazioni web tramite una architettura elegante ed una chiara ed esplicita separazione delle competenze, l’impiego dei più diffusi pattern di software engineering, il controllo completo dell’HTML generato e degli URL, la testabilità ed estendibilità. In questa sessione vedremo le novità principali della versione 3.

Stefano Benedetti
DotDotNet

Registrazione

Per registrarsi potete seguire questo link: http://dotdotnet.org/content/SmauBo2011.aspx

Share

Spostare la cartella packages di NuGet

Nella configurazione di default NuGet crea una cartella chiamata packages nella root della soluzione dove vengono copiati tutti i package installati.

Questa configurazione non corrisponde però alla struttura delle mie soluzioni che normalmente è:

  • lib
  • src

dove lib contiene tutte le librerie da cui dipendono i progetti mentre i sorgenti della soluzione si trovano in src.

Fortunatamente esiste una feature non documentata che consente di specificare la posizione dei packages. E’ sufficiente aggiungere il file nuget.config allo stesso livello del file .sln e configurare il parametro repositoryPath.

Ad esempio per supportare la configurazione lib – src creare il file nuget.config in questo modo:

<settings>
	<repositoryPath>../lib/packages/</repositoryPath>
</settings>

NB: il path non può essere assoluto ma deve essere relativo rispetto al file .sln

In questo modo sia il package manager che la package console funzioneranno perfettamente utilizzando il nuovo percorso. Ovviamente i package già scaricati dovranno la prima volta essere spostati a mano nella nuova cartella.

Importante: lo stesso Phil Haack precisa che la feature non è supportata e non documentata perchè presenta ancora alcuni problemi e potrebbe essere rimossa/modificata nelle future release di NuGet.

Share

Gestire le librerie con NuGet. Package reference e Package Console

Nel precedente post ho fatto una breve introduzione a NuGet e alla sua installazione in Visual Studio 2010.

In questo post entro invece più in dettaglio sulla gestione dei package e su cosa avviene dietro le quinte.

La gestione dei package con NuGet

Per prima cosa per utilizzare tutti i comandi di NuGet è necessario che sia aperta una soluzione.

Nell’esempio ho creato una web application con nome NuGetTest.

A questo punto per installare, modificare o eliminare un package è possibile:

  • Utilizzare il menù contestuale “Add library package reference” nel progetto
  • Utilizzare la console “Package Manager Console” PowerShell

Gestire i package dalla finestra Add library package reference

La finestra “Add library package reference” è accessibile dal menù contestuale di ogni progetto.

Il suo contenuto e funzionamento è simile all’Extension manager di Visual Studio.

E’ possibile:

  • Cercare un package online
  • Installare un package
  • Visualizzare i package installati
  • Aggiornare un package a una nuova versione
  • Rimuovere un package installato

Vediamo alcuni esempi concreti.

Esempio: aggiungere log4net tramite il library package reference

add library package reference

Nell’esempio ho scelto log4net

Add library package reference window

Premendo “Install” viene scaricato ed installato il package. Il risultato è il seguente:

    1. Viene creata una cartella packages nella root della soluzione
    2. Viene aggiunta una reference alla DLL

log4net reference

  1. Viene creato il file Packages.config nella root dell’applicazione

Packages.config

Dato che tutta la configurazione dei package installati è su file system all’interno della soluzione si ha immediatamente il vantaggio che è condivisa all’interno del sistema di versionamento (TFS, Subversion o Git ad esempio).

Rimuovere e aggiornare i package dalla finestra Library Package Reference

Dalla finestra Library Package Reference è possibile anche disinstallare un package oppure aggiornarlo a una nuova versione.

Ad esempio per rimuovere log4net è sufficiente visualizzare tutti i package installati e premere uninstall.

uninstall-log4net-from-library-package-reference

Anche l’aggiornamento di un package si fa con un paio di click. Si seleziona Updates e se sono disponibili degli aggiornamenti per un package installato è sufficiente premere Update.

Nell’esempio è stato installato il package NHibernate in versione beta. Nell’elenco degli updates compare la versione definitiva di NHibernate 3.

update-nhibernate-from-library-package-reference

L’aggiornamento provvede automaticamente a rimuovere la vecchia libreria e a referenziare la nuova.

Gestire i package tramite la Package Manager Console

La package manager console è lo strumento più potente e flessibile per gestire i package.

Da riga di comando è possibile ad esempio scegliere la versione da installare oppure disinstallare un package forzando o no la rimozione dei package da cui dipende (solo se non utilizzati da altri package).

Digitando il comando

get-help about_NuGet

viene mostrato l’elenco dei comandi disponibili.

La guida completa è anche online su CodePlex a questo indirizzo:

http://nuget.codeplex.com/documentation?title=Package%20Manager%20Console%20Command%20Reference

Esempio: aggiungere NHibernate tramite la Package Console

Digitare il comando get-package. Viene visualizzato l’elenco dei package attualmente installati:

get-package log4net

Il comando get-package –remote visualizza l’elenco dei package disponibili nel feed corrente (ricordo che di default si tratta del NuGet official package source).

Al momento in cui scrivo si ottiene una lista di circa 1000 package. E’ possibile filtrare la lista con l’opzione filter.

Ad esempio con il comando

get-package –remote –filter nhibernate

si ottiene la lista di tutti i package con nhibernate nel nome o nella descrizione:

get-package filter nhibernate

A questo punto per installare il package NHibernate eseguire il comando:

install-package NHibernate

NB: il progetto in cui viene installato il package è quello selezionato nel menù a tendina “Default Project” nella console.

install-package nhibernate

In questo caso va notato che il package di NHibernate ha 3 dipendenze:

  • Iesi.Collections
  • Antlr
  • Castle.Core

e per ogni dipendenza è specificata la versione minima necessaria.

NuGet si accorge che le dipendenze non sono ancora installate e provvede automaticamente a scaricarle, installarle e configurarle.

A questo punto nella soluzione sono state aggiunte le nuove reference:

nhibernate reference

Viene inoltre aggiornato il file packages.config e la cartella packages nella root della soluzione:

Packages.config nhibernate

packages folder nhibernate

Esempio: installare ELMAH

Eseguire adesso il comando

install-package elmah

In questo caso oltre alla solita configurazione delle reference è necessario modificare il web.config.

NuGet aggiunge in automatico una nuova configSection nel web.config

elmah configsections

e configura i necessari httpmodules e httphandler:

elmah httpmodule httphandler

Da notare che la configurazione è stata fatta correttamente sia per IIS 6 che per IIS 7.

Esempio: disinstallare ELMAH

Per disinstallare un package è sufficiente eseguire il comando:

uninistall-package

Ad esempio il comando uninstall-package ELMAH esegue in automatico questi passi:

–          Rimuove la reference dal progetto

–          Ripulisce il file web.config

–          Rimuove l’entry dal file di configurazione package.config

–          Rimuove la libreria dalla cartella packages

Aggiornare un package dalla Package Console

L’aggiornamento di un package dalla Package Console avviene con il comando:

update-package nomepackage

Ad esempio installando NHibernate in versione beta ed eseguendo il comando

update-package nhibernate

viene rimossa completamente la vecchia versione ed installata la nuova.

update-nhibernate-from-package-console

Riferimenti

CodePlex: http://nuget.codeplex.com/

Elenco dei comandi da console:
http://nuget.codeplex.com/documentation?title=Package%20Manager%20Console%20Command%20Reference

Phil Haack blog: http://haacked.com/tags/NuGet/default.aspx

Share

Slide ed esempi della sessione Powerful Asp.net 4 e Internet Explorer 9

Ecco le slide e la soluzione di esempio che ho utilizzato per mostrare le novità di Asp.net 4.0 e di Internet Explorer 9 durante l’evento Community Tour 2010 a Bologna.

 

Codice di esempio: Asp.Net 4 e IE9 samples

Presentazione Power Point: 

Share

log4net, il Framework .Net 4.0 e il Client Profile

Questa settimana un cliente mi ha segnalato un problema relativo all’utilizzo di log4net con Visual Studio 2010 e il Framework 4.0.

In pratica creando un’app

licazione console e referenziando log4net in versione 1.2.10 in fase di build si riceve questo errore:

“The referenced assembly “log4net” could not be resolved because it has a dependency on “System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which is not in the currently targeted framework “.NETFramework,Version=v4.0,Profile=Client”. Please remove references to assemblies not in the targeted framework or consider retargeting your project.”

Come esplicitato d

al messaggio il problema risiede nel fatto che la console application targettizza il Framework 4 Client Profile.

Framework-Client-Profile

Il Client Profile è il target predefinito per i nuovi progetti Windows Forms, Console Application, WPF e Window Service. L’idea di base del Client Profile è quella di ridurre le dimensioni del Framework .Net rimuovendo tutte le assembly che in certi progetti non servono.
Nello specifico il client profile non contiene:

  • ASP.NET
  • alcune funzionalità avanzate di Windows Communication Foundation (WCF)
  • il .NET Framework Data Provider per Oracle
  • MSBuild
log4net utilizza l’assembly System.Web tramite l’AspNetTraceAppender e quindi non è possibile compilare i progetti che targettizzano il Framework 4 Client Profile.
La soluzione più rapida è quella di modificare le proprietà del progetto selezionando come target framework “.Net Framework 4”.
La domanda a questo punto però è: “E’ corretto scegliere come target il framework in versione full?”
Se la risposta fosse solo nelle dimensioni direi che si potrebbe utilizzare direttamente la versione full.
Queste sono le dimensioni del framework 4 come riportato sul blog di Scott Hanselman:
3.5 SP1 4.0 RTM
32 bit Client Profile Online: 28 MB
Offline: 255MB
28.8 MB
32 + 64 bit Client Profile N/A 41 MB
32 bit Full N/A 35.3 MB
32 + 64 bit Full N/A 48.1 MB
32 + ia64 bit Full N/A 51.7 MB
32 + 64 + ia64 bit Full 231 MB N/A

In pratica la differenza di dimensioni si attesta sui 7 mega quindi secondo me non sostanziale.

L’accento probabilmente va posto su due punti:

  • concettualmente gli applicativi desktop è corretto che non abbiano riferimenti ad assembly relative al mondo web
  • il Framework 4 Client Profile è il framework che viene distribuito sui desktop tramite Windows Update
In base a questi punti direi che si può targettizzare il framework full in ambienti ben controllati o enterprise e preferire il Client Profile per tutti gli applicativi desktop.
Per quanto riguarda log4net nello specifico nelle versioni future potrebbe essere rilasciata una build compatibile col client profile senza riferimenti a System.Web altrimenti è necessario ricompilarlo rimuovendo l’AspNetTraceAppender.
Riferimenti:

.NET Framework Client Profile
Towards a Smaller .NET 4 – Details on the Client Profile and Downloading .NET
What’s new in .NET Framework 4 Client Profile RTM

Share