i 12 passi per scrivere ottimo codice...

qualche giorno fa è appara sulla mia scrivania un bellissimo link, che consiglio  tutti i developer leggere..
http://www.joelonsoftware.com/articles/fog0000000043.html

si parla di dodici passi che devi fare per poter garantire la scrittura di codice quantomeno accettabile. Dopo aver apprezzato l'articolo ho provato a raccoglier le risposte peggiori che si posson fornire ad ogni domanda posta, scoprendo amaramente che sono più comuni di quanto vorrei...

Q1 usi un software di controllo sorgente?
re- "no, i miei dev sviluppano da soli e si scambiano il codice  via mail, uniamo poi il tutto appena possibile"

Q2 puoi compilare con una procedura semplice e nota?
re- "ho scelto appositamente un linguaggio interpretato e senza compilazione cosí da evitare questi problemi"

Q3 fai compilazioni notturne?
re- "non compilo, non ne ho bisogno"

Q4 hai un database delle anomalie?
re- "il cliente manda mail e telefona se ha un problema, inseguo sempre il cliente più incazzato"

Q5 correggi i bug prima di scrivere altri pezzi nuovi?
re. "no, se non li sollecita nessuno signfica che non sono gravi e posson stare li."

Q9 usi il miglior software che il denaro possa comprare?
re. "ho deciso di usare solo prodotti open source cosí da non dover investire in licenze"

Q10 hai dei tester ?
re "i clienti possono tranquillamente sopportare un poca di instabilità e sono una base di test più che sufficiente"

Q11 fai scrivere codice durante i colloqui di assunzione?
re. "no, i criteri di valutazione sono solo legati a costo (poco) e tette grosse..."



Q12 fai test di usabilità del softwaew?
re . "ho scritto un manuale di 6890 pagine,i clienti possono leggersele"

Confrontare due resx...

Su un progetto pluriennale e multilingua, diventa importante manutenere i file contenenti le traduzioni statiche.

In c# dei comodi file di risorse, resx, rimangono alla base dell'apparato tecnico. Quello che diventa più impegnativo di solito è mantener allineate tutte le lingue possibili.

Quando poi le chiavi diventano migliaia, individuare le "nuove chiavi non tradotte" diventa una fatica inenarrabile. Per questo mi sono scritto un piccolo programmino di supporto

Ho creato una semplice console application, inserito dentro il progetto due resx (ItalianoMaster.resx ed EnglishTranslate.resx)

E il semplice codice

static void Main(string[] args)
{
// carico tutte le traduzioni  di default (per me italiano)
Dictionary italiano = new Dictionary();
ResourceSet resourceSetùMaster = ItalianoMaster.ResourceManager.GetResourceSet(CultureInfo.CurrentUICulture, true, true);
foreach (DictionaryEntry entry in resourceSetùMaster)
{
    string resourceKey = entry.Key as string;
    object resource = entry.Value;
    italiano.Add(resourceKey, resource.ToString());
}

// carico tutte le traduzioni in inglese
Dictionary inglese = new Dictionary();
ResourceSet resourceSet = EnglishTranslate.ResourceManager.GetResourceSet(CultureInfo.CurrentUICulture, true, true);
foreach (DictionaryEntry entry in resourceSet)
{
    string resourceKey = entry.Key as string;
    object resource = entry.Value;
    inglese.Add(resourceKey, resource.ToString());
}



foreach (string k in italiano.Keys)
{
    if (inglese.ContainsKey(k))
    {
        inglese.Remove(k);
    }else
    {
        System.IO.File.AppendAllText(@"c:\temp\daaggiungere.txt", String.Format("{0}ç{1}{2}", k, italiano[k], Environment.NewLine) );
    }
}

Informazioni sul metodo chiamante

http://msdn.microsoft.com/en-us/library/hh534540.aspx

Gli attributi descritti ritornano solitamente utili per effettuare operazioni di trace e log. Qualche tempo fa mi sonotrovato nella situazione di dover effettuare il redirect di un metodo verso un altro oggetto che rispondesse alla stessa interfaccia ma su una istanza diversa.

Nella prima implementazione mi son messo a scrivere tutte le chiamate, accorgendomi poi che il lavoro era smplice ma noiosissimo. Così ho cercato una tecnica più complessa ma che mi consentisse di scrivere zero codice per specifica e nuova implementazione. Ecco, usando questi attributi, un poca di reflection e molta fantasia ho ottenuto un router manager!!!!

Sketch o non sketch?

Sono diversi anni che mi occupo di sviluppo software, alla fine la modalità e l'approccio per capire cosa sviluppare è sempre la stessa... Si ascolta il cliente, si comprende cosa desidera, si progetta una soluzione che verrà poi testata e rilasciata al cliente che...

Ecco, questo è il punto chiave,tra quello che si aspetta il cliente e quello che viene prodotto realmente c'è una certa distanza, elevata tanto quanto ha fallito la comunicazione durante tutto il processo descritto sopra.
Dove fallisce la comunicazione? Beh, in ogni momento in cui due persone, devono condividere una idea, un obiettivo.

Bisogna trovare strumenti per semplificare questi passaggi e ridurre le possibili incomprensioni.

Documenti dettagliati definiscono bene cosa va fatto e schemi uml chiariscono le interazioni, ma la loro compilazione è dispendiosa e la lettura da parte di utenti non tecnici diventa difficile.

Una soluzione a supporto di questa  attività sono i prototipi e le simulazioni, chiariscono le interazioni senza esser troppo tecniche, e rimuovono ambiguità nella comunicazione.

Nelle ultime settimane sto utilizzando Blend per creare sketch per applicazioni WPF.
Da che mi ricordi Blend ha questo supporto, ma in passato non era un esempio di stabilità e consistenza. Ci ho riprovato, con la versione allegata a Visual Studio 2013 e sono piú che soddisfatto del risultato ottenibile con uno sforzo bassissimo. Molto inferiore al tempo che mi sarebbe servito per spiegare i comportamenti li semplicemente disegnati...

Quindi... sketch o non sketch? direi proprio di si, soprattutto quando le cose sono coplesse, gli attori sono molti e le idee non troppo chiare!!!

Risultati inattesi....

Questo blog è un povero diario bistrattato dal proprietario che non ha mai abbastanza tempo per rimpolpare le pagine di cose piú o meno interessanti...

 Ma alla fine queste poche pagine finiscono per dare soddisfazioni non previste... Basta una occhiata alle statistiche e scopro che ha generato piú di 19000 viste
...

Per molti forse saranno numeri bassissimi, ma a me sembra una enormità di persone... Devo ricominciare a pubblicare post, chissà che non ne venga fuori qualcosa di buono per il futuro, o almeno chissà che non si possa risolvere un piccolo problema a qualcuno nel mondo..

Modificare il path default dei prompt di msdos

Modificare il path standard un tempo, molto tempo fa era una sciocchezza... basta semplicemente toccare un filettino chiamato autoexec.bat...


ora non c'è più, sostituito da una incredibile interfaccia utente, che fa le stesse cose, ma in modo più complicato, almeno per un vecchietto come me... :)

Quindi qui è spiegata la corretta sequenza di click per arrivare alla variabile corretta...

http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx

Individuare problemi caricamento com-addin in outlook

Per lavoro mi è capitato diverse volte di sviluppare componenti COM.

Quando è una mia applicazione ad eseguirli, individuare il problema anche durante il carcamento tutto sommato non è un problema.

Purtroppo quando sviluppiamo addin per prodotti di terze parti non abbiamo il controllo del processo di loading, e quindi a volte vediamo semplicemente il risultato. Non si carica... Individuare il motivo è spesso estremamente arduo.

Mi hanno girato una soluzione che abilita un log del caricamento, garantendo così l'accesso a informazioni altrimenti non visibili.

Le istruzioni per attivarlo e trovate qui:

Troubleshooting com add in load failures