August 2008 - Posts
Se vi chiedessero di nominare 5 libri di informatica che avete letto e che hanno avuto un contributo significativo per la vostra cultura e per la vostra crescita professionale, quali nominereste ?
Domanda banale ? Domanda troppo complicata ?
Forse sì, anche perchè il confronto può risultare arduo quando si vanno a considerare testi che differiscono non solo per contenuti, ma anche per approccio o, magari, per stile.
Un libro che non posso togliere dalla mia classifica, ad esempio, è il primo che ho letto integralmente, del quale non ricordo nè autore nè casa editrice (sigh ...) ma solo il colore della copertina (rosso acceso) e l'argomento (una sorta di guida di livello intermedio sui PC e sul loro funzionamento).
[Non se ne trovano più in giro. Non so se è una sensazione solo mia, e magari errata, ma adesso la tendenza sembra premiare il "tutorial-che-ti-insegna-a-programmare-in-6-lezioni-da-un'ora" :-(]
Don Box trova posto come autore (così ne occupa solo uno :-P ... insomma, se vinci non puoi anche arrivare secondo). La Addison-Wesley, spannometricamente parlando, come casa editrice.
E poi c'è questo volumetto da 300 pagine o poco più, edito da O'Reilly, acquistato più per curiosità che per reale interesse (almeno all'epoca) ed entrato in top five a velocità sorprendente.
Shared Source CLI Essentials è un viaggio negli gli internals della "macchina virtuale" .NET.
E' un libro che ti fa venire voglia di prendere in mano un debugger e di fare le pulci a quel runtime che ospita le tue applicazioni di tutti i giorni.
E' un libro che riprenderei in mano volentieri, ad avere anche solo un pochino di tempo.
Ecco perchè sono davvero contento di leggere, da Joel Pobar e da Ted Neward, che è disponibile una bozza della versione 2 del succitato volume, arricchito da:
Updated to reflect the 2.0 source code. A *lot* of stuff changed internally, specifically for deeply engrained type system features like Generics. Added a chapter on Reflection and Code Generation features. We talk about new 2.0 features like Lightweight Code Generation (LCG) and the new Reflection caching mechanisms. Added a chapter on Generics to explore how it works under the hood, from metadata changes, right through to runtime data structure changes. Added an Appendix tutorial that walks through step-by-step the changes required to add a new opcode to the runtime (everything from verification, to JIT compilation). Explores a new interface call dispatch architecture called “Virtual Stub Dispatch”. Looks at the new native x86 calling convention.
Un must, come si dice. Davvero !!
I Microsoft Office Labs hanno reso disponibile pptPlex, un add-on per PowerPoint che ... dà vita alle presentazioni aggiungendo effetti di zoom e pan durante la navigazione tra le slide (e all'interno della stessa slide, quando i contenuti sono troppo minuscoli).
pptPlex is a plug-in that explores an alternate method for presenting a PowerPoint slide deck. Using pptPlex, you can present your slides as a tour through a zoomable canvas instead of a series of linear slides
Le parole si spiegano molto peggio di un video :-)
L'ho installato e provato per qualche minuto e devo dire che è estremamente interessate, e non solo per via degli effetti.
Offre una modalità di navigazione (e quindi di presentazione) che ben si presta all'esposizione di contenuti non sequenziali, per la quale un ritorno ad una schermata di overview interattiva è utile didatticamente, oltre che molto ad effetto.
Utilizzare questo add-on "in produzione" forse è prematuro:
Q. Can I run my business with these tools?
A. These prototypes are unsupported so we don't think that would be a good idea.
Speriamo quindi in un buon supporto e, magari, in una integrazione nella prossima versione di Office :-)
Oggi mi sono appollaiato sotto il sole dell'alta Toscana con l'intenzione di preparare un po' di materiale per la SharePoint Conference di ottobre.
Ho riorganizzato un po' di esempi, completato qualche snippet di codice lasciato da un po' di tempo nei "todo" di outlook e poi mi sono dedicato al packaging per la sessione su STSADM che terrò con Igor.
Ovviamente non svelo nulla (:-P) ma, giacchè sono tuttora appollaiato sotto la luna dell'alta Toscana, vi scrivo un piccolo tip.
L'esigenza è stata quella di creare una solution SharePoint in grado di effettuare il deploy di una custom stsadm extension. Il che si riduce, per farla breve, alla distribuzione di un assembly in GAC (e sin qui nessun problema) e alla copia di un file in [12]\CONFIG.
Il meccanismo di packaging in solutions consente entrambe queste operazioni (definendo i relativi elementi Assembly e RootFile nel manifest della solution, e ovviamente includendo i file nel pacchetto generato):
<Solution ... >
<RootFiles>
<RootFile Location="CONFIG\stsadmcommands.Spc2008.xml" />
</RootFiles>
<Assemblies>
<Assembly Location="Spc2008.StsAdmExtensions.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
Purtroppo, però, STSDEV non è in grado di inserire file nella directory CONFIG.
Ponendo come presupposto che:
- Tutte le mie altre demo sono basate su progetti creati con STSDEV ... e vorrei mantenere un minimo di omogeneità almeno con me stesso :-)
- STSDEV è un tool eccellente, sia per funzionalità che per facilità di estensione
- STSDEV è corredato da codice sorgente
tutto sommato l'idea di metter su una patch non è così tanto campata per aria.
Step by step, la patch è costituita da:
1) In Globals.cs, definizione di un nuovo campo String all'interno della classe stsdev.Globals, inizializzato con il percorso della directory CONFIG:
public readonly static string ConfigFolder = RootFilesFolder + @"\CONFIG";
2) In CabDdfBuilder.cs, modifica del processo di generazione del file DDF (alla base della successiva creazione del pacchetto WSP), rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
3) In ManifestBuilder.cs, modifica del processo di generazione del manifest della solution, rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
Rebuild, test e via :-)
Ah, per inciso.
L'avete visto, no, che Ted Pattison (creatore - tra l'altro - di STSDEV) terrà una sessione proprio sulla sua creatura ?
Paul Andrew annuncia che è disponibile su Codeplex una "not-even-alpha version" della SharePoint Guidance.
La descrizione schematica che troviamo in home è piuttosto precisa:
Project Description
We plan to provide guidance to customers on how to build SharePoint Intranet Applications. This includes guidance on how to Architect, Design, and Develop applications as well as best practices.
Intended Audience
This guidance is intended for software architects and software developers who are building applications on Microsoft Office SharePoint Server. Familiarity with Windows SharePoint Services, Microsoft Office SharePoint Server, and ASP.NET is useful for evaluating the guidance.
Guidance is not even Alpha
Please note that this guidance is in draft form and will change dramatically before it is released on MSDN. We provide you access to drops to give you an idea of our direction and get your feedback. The code will continually be refactored until the point we publish it on MSDN.
Evidentemente ... "they heard from customers" (cit.) :-)
Non aspettatevi di trovare nulla di lontanamente definitivo ... però, visto che curiosare è in fondo lecito e, a dire il vero, richiesto, diamo un'occhiata partendo dalla "vision" di questa drop. Mi sono permesso un ritaglio dal pdf:
Interessante il ranking delle richieste più gettonate.
Il Debugging sembra avere la meglio su altre "piccole" questioni quali tooling (VSeWSS vs STSDEV vs WSPBuilder vs SmartTemplates vs Custom Batch vs Tutto A Mano ...) o Sviluppo in Team (che secondo me è invece il punto più interessante e aperto, e se volete va giù a domino coprendo la maggior parte degli altri desiderata).
Interessante soprattutto il fatto che alcune esigenze, che personalmente giudico *primarie* per *qualsiasi* ambiente di sviluppo, siano presentate in un documento di Vision come must have, e quindi sia lecito aspettarsi una risposta "ufficiale" (da seguire o non seguire a discrezione, ci mancherebbe, ma sempre utile come termine di confronto).
Mi riferisco in particolare al SDLC (Software Development Life Cycle) e a quanto/come/quando di questa disciplina si possa/debba applicare alle soluzioni SharePoint.
In termini più pratici, e solo per fare un esempio, tutti sappiamo che si devono fare i test, semmai il punto è individuare la metodologia più corretta per farlo, tenendo ovviamente in conto l'ambiente target, i suoi vincoli e le sue particolarità.
Alla SharePoint Conference avremo sicuramente occasione di discutere anche di queste cose. Io ho già pronta qualche domandina per Ted Pattison ... preparate le vostre :-)