ottobre 2004 Blog Posts
10 giorni fa è stato ammesso in INETA il primo user group .NET rumeno: RONUA (ROmanian .NET User Association).
Ha finora la bella cifra di 35 membri, compreso me :-)
Primissime impressioni:
Pro
Le domande sul forum sono discretamente interessanti
Contro
l'interfaccia fa veramente schifo!
sta sul sito del suo presidente...
Comunque, auguri RONUA!
Bill Gates, in un venerdì di settembre del 1997, iniziava così il suo speech al PDC di quell'anno:
"We've used this PDC as a really major milestone, in terms of our message to developers, about how to build modern applications."
Veramente una gran pietra miliare, per il fatto che con la sessione di Mary Kirtland, la Super COM Woman - altro che DataGrid Girl :-) - si sono messe le basi del futuro CLR. Verso la fine dell'anno uscirono due suoi articoli su MSJ che si sono mostrati lungimiranti:
M. Kirtland, "Object-Oriented Software Development Made Simple with COM+ Runtime Services", Microsoft Systems Journal,...
E costei chi è? :-)
E soprattuto che legame ha questa signora con .NET?
Se i miei quiz non vi bastano, potete provare quelli di Brad (ma questo senz'altro lo sapete) oppure il concorso mensile di Wintellect: "Who Wants to Be a Wintellectual?" (si vince un libro).
A quelli potenti e insoddisfatti anche dopo questo :-) magari il concorso mensile "Ponder This" fatto da IBM Research dovrebbe dire qualcosa. Una lista lunga di rumeni che hanno risposto correttamente a "Ponder This" l'ho compilata un po' di tempo fa in un commento a questo post di Adi Oltean, anche lui rumeno.
Oppure, potete partecipare alla TopCoder Competition, dove i rumeni sono all'ottava posizione.
Chi è costui? :-)
Le risposte lasciatele nei commenti.
Spinto dall'entusiasmo di Paolo Arvati verso JBoss, ho guardato interamente il webcast di un'ora di:
Marc Fleury, "JBoss: Professional Open Source Annotations and EJB3", Java Pro Live! 2004
A parte l'ottimo overview fatto sull'AOP e le idee che escono fuori dal codice della presentazione, mi ha impressionato la sincerità dell'apprezzamento della nostra piattaforma e il parechio numero di volte in cui cita lodativo .NET e C#.
Da guardare e da imparare.
Supponiamo che vi troviate davanti a un quiz come questo:
class Foo{ static void Main() { string s1 = string.Empty; string s2 = ""; double d = System.Math.PI; }}
Secondo voi, quanti warning "The variable 'variable' is assigned but its value is never used" otterreste in compilazione? Qualcuno dirà 3, un altro 2, un altro ancora 1, mentre i più fighi diranno nessuno. La risposta però è 2. Per capire il motivo non mi sono stati d'aiuto né le specifiche, nè Richter, né Box, né Gunnerson. La risposta l'ho trovata spulciando nel Rotor, nel corpo dei metodi FUNCBREC::reportUnreferencedVars (le righe 668-683) e FUNCBREC::bindAssignment (le righe 7488-7533). Vediamo cosa...
Partendo dalla misteriosa frase:
"The type of a null-literal is the null type"
che si trova nelle specifiche, ho scritto finora quattro altri post: ("The null type?", "The null type (un po' più chiaro)", "The null type (la risposta di Dominic Cooney)", "Di nuovo sul nulla :-)"). Oggi però, finalmente ho trovato nei sorgenti di Rotor la definizione di questo tipo:
/** NULLSYM - represents the null type -- the type of the "null constant".*/class NULLSYM: public TYPESYM{};
e andando in su nella gerarchia dei simboli ho trovato:
SYM
the base symbol
PARENTSYM (deriva da SYM)
a symbol that can contain other symbols as children
TYPESYM (deriva da PARENTSYM)
a...
Il problema chiedeva, utilizzando meno ipotesi possibili, di calcolare quello che sappiamo tutti, già dal primo contatto con l'informatica: il numero di bit in un byte.
Una soluzione potrebbe essere questa:
System.Convert.ToString(unchecked((byte)~0), 2).Length
tirata fuori da un'idea di Pietro Toniolo - ho apprezzato il fatto che NON ha pensato a "byte.MaxValue" (avrebbe fatto un'altra ipotesi ancora, quella del segno...). Però è un po' bruttino il fatto che calcoliamo il numero di bit in un tipo partendo da un valore (0) di quel tipo. Riusciamo a trovare una soluzione più "generale"?
Io ho pensato così:
System.BitConverter.ToString(new byte[1]).Replace("-", string.Empty).Length * 4
dove ci ricordiamo che la documentazione originale...
Un simpatico problema proposto da Stephen Hebert in un colloquio tecnico:
"Write a routine that counts the number of bits in a byte."
Voi come l'avreste risolto (facendo ovviamente meno ipotesi possibile)?
E' giusta l'osservazione di Matteo che da un po' ho rallentato il ritmo dei post. Ho cambiato il cliente, il progetto, il linguaggio. La mattina VB .NET, la sera ovviamente C# :-) e nei weekend continuavo a scrivere al corso di Java Servlets. Adesso sta arrivando sempre per lo stesso cliente anche un altro progetto (di più saprò domani), lavorerò un po' in paralello. Ho iniziato a pensare anche alla mia sessione su CLS, fra una settimana vorrei avere la scaletta chiara, magari la posterò qui per sottoporla ai vostri feedback. Come libri sono contentissimo degli ultimi acquisti di ieri:...
Per trasformare un DataSet in un Recordset hanno parlato nei loro libri Dino Esposito (vedi "Programmare XML in Microsoft .NET", pp. 170-179 e pp. 326-332) e Paolo Pialorsi con Marco Russo (vedi ".NET XML & WebServices Full Contact", pp. 27-35).
Magari pochi sanno la strada contraria: quella dal Recordset al DataSet. Per loro il seguente snippet:
public sealed class AdoConvert {
private AdoConvert(){}
public static DataSet ToDataSet(ADODB.Recordset rs) { OleDbDataAdapter da = new OleDbDataAdapter(); DataTable dt = new DataTable(); DataSet ds = new DataSet(); da.Fill(dt, rs); ds.Tables.Add(dt); return ds; } public static DataSet ToDataSet(string recordsetXml) { ADODB.Recordset rs = new ADODB.Recordset(); ADODB.Stream stream =...
Il 2 di dicembre presenterò al workshop "Architecture & Management" una sessione su "CLS: regole per compilatori e per sviluppatori".
Inizio proprio in modo "potente" :-) visto che nell'altra sala ci sarà proprio Andrea... L'argomento che presento però mi piace da morire: è veramente poco conosciuto (ho guardato il webcast di Marco Russo "Ambiente object-oriented, CTS, CLS, FxCop" e la farò ben diversa) e in più è un argomento pieno-pieno di sorprese.
Ah, un'altra cosa: visto il mio accento straniero, cercherò di parlare in IL, così mi capirete tutti :-)
Non poche cose si imparano provando a compilare programmi vuoti :-) Vediamone alcune:
Per esempio, vi dicevo nell'altro post che:
type foo.cs > foo.cscsc /t:library foo.cs
produce un assembly (DLL) di 3072 bytes identico a quello prodotto se foo.cs fosse fatto solo da namespace vuoti perché il concetto di namespace è al livello del linguaggio e non scende al livello IL. Quindi se i namespace non si "applicano" a nessun tipo il compilatore giustamente li ignora.
Il codice IL di questo assembly è:
.assembly extern mscorlib{.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ).ver 1:0:5000:0}.assembly foo{// --- The following custom attribute...
Vi sieti mai chiesti se i programmi vuoti (cioè da 0 bytes) compilano? Queste due righe nel VS .NET Command Prompt:
type foo.cs > foo.cscsc /t:library foo.cs
producono un DLL da 3072 bytes.
Forse per qualcuno sapere questo potrebbe sembrare una cosa di poco peso. Voglio però farvi notare che, se al posto del file vuoto compilate uno snippet che contiene un namespace vuoto:
namespace empty{}
risulterà un DLL della stessa dimensione di 3072 bytes. Se provate con ildasm a vedere il codice IL nei due casi, vedrete che sono identici.
Cosa vuol dire questo? Ci dobbiamo semplicemente ricordare che il concetto di namespace è al...