Ci sono molte parti di Umbraco che hanno bisogno di essere… “aiutate” per funzionare correttamente!

Molto si trova con la pratica, molto leggendo blog come il mio :)
Quindi, visto che non sono geloso, vi giro un altro blog da cui ricavo un sacco di informazioni utili, che spesso utilizzo:

http://www.nibble.be/

A discapito dell’estensione, il sito è in comprensibilissimo inglese, e punta molto sull’argomento “startup” di Umbraco, che io spesso posso tralasciare per motivi pratici…

Utilizzando l’oggetto Image, può capitare di ricevere un errore, abbastanza criptico, che spesso è impossibile da interpretare:

Generic Error in GDI+

Chiaramente, i componenti COM non hanno la buona educazione di avvisarci riguardo a _quale_ sia effettivamente l’errore….
Per fortuna, in ASP.NET le cause per questo errore sono principalmente due:

1: Permessi. Ossia, stiamo cercando di salvare un immagine in un percorso in cui l’utente interattivo non ha i permessi di scrittura. Come al solito, ma non solo in questo caso, è buona norma assicurarsi che i permessi siano corretti soprattutto quando si portano i file dal proprio PC al server di stage/produzione

2: Si sta chiamando il metodo Save() passandogli il full path del file. Non so perchè, ma in quasi tutte le prove che ho fatto questo metodo fallisce. Purtroppo, non in tutte. Il giorno in cui capirò perchè sarò, probabilmente, un uomo felice. Nel frattempo, ostento finta felicità utilizzando un oggetto FileStream:

using (FileStream fileStream = System.IO.File.Create(filePath))
{
   img.Save(fileStream, ImageFormat.Jpeg);
}

In questo modo, di solito, non fallisce :)

Mi è capitato un problema bizzarro, ultimamente, uno dei tanti in cui mi sto scontrando lavorando con siti con alto traffico di utenti.

Il problema in questione era che il DataReader, improvvisamente, è “impazzito”, restituendo una System.IndexOutOfRangeException nel metodo GetOrdinal. In pratica, mi diceva che nel set di dati restituito mancava la colonna che cercava di leggere. Peccato che, nel metodo in questione, la colonna ci fosse, la stored fosse corretta… insomma, funzionasse tutto “normalmente”. Come nel classico dei bachi, il problema si presentava in maniera assolutamente randomica. Quindi, per esempio, andava perfettamente in 10 casi, l’undicesimo esplodeva.

Il progetto in questione utilizza un mio “storico” data access helper, utilizzato ormai in una marea di progetti anche con più traffico, e più importanti, di questo. Quindi, ho cercato in altri punti il problema, senza arrivare a soluzione alcuna. Mi sono quindi rimesso in discussione, ed ho ricontrollato il data access, trovandolo senza falla (per fortuna!). L’unico dubbio che mi è, per fortuna, venuto, riguarda il fatto che il progetto era gestito da un’altra azienda, cui ho dato alcune dritte, ma che poteva tranquillamente aver male interpretato le mie istruzioni. Quindi, vado a rivedere _come_ è stato utilizzato il mio data access… ed ho trovato la magagna!

In sostanza, il mio data access ha la possibilità di operare in ambiente multi transazionale. Aprendo una transazione, ed una connessione, il data access si predispone a “transazionare” tutti gli oggetti di business in un determinato contesto. Senza questa funzionalità attiva, il data access si predispone per aprire, utilizzare, e richiudere subito la connessione in modo da rimandarla nel pool. L’utilizzo improprio, invece, ha fatto in modo che la connessione venisse aperta _fuori da un contesto transazionale_, e poi di fila venivano chiamati 5 o 6 metodi che riempivano un reader e lo consumavano, chiudendolo ma senza utilizzare CommandBehavior.CloseConnection. Alla fine di tutto, veniva chiusa la connessione.

Senza nessun contesto transazionale attivo, e vista l’intrinseca concorrenzialità di un progetto web, succedeva che i dati del datareader venissero “mischiati” da una chiamata arrivata tra la lettura e l’effettivo consumo del reader. Ho trovato una buona spiegazione di questo problema in questo post sul forum. Per risolvere è bastato rimuovere le connessioni aperte e chiuse in maniera programmatica, e lasciare fare a lui il suo lavoro.

E con questo siamo a due problemi di concorrenza su thread nel corso di una sola settimana… è un segno che, in giro, si fa troppa poca attenzione a questo genere di problematiche? :)

In uno dei tanti progetti che sto seguendo, mi è capitato un errore di quelli che nessuno vorrebbe mai avere: l’applicativo schizza come una lippa ma, improvvisamente, la CPU schizza al 100% (su un server con 16 core e 16 giga di ram…) e rimane li, inchiodata, per quasi un minuto. Poi va giù, senza generare errori rappresentativi, e ritorna a funzionare… per non si sa quanto!

Abbiamo passato differenti giornate a cercare di capire il problema. Alla fine, siamo abbastanza sicuri di aver isolato la causa: l’utilizzo di una cache esterna basata su Dictionary, “falliva” in ambiente multithread in quanto si era dimenticata che le Generic Collection non sono thread-safe. Come dice giustamente in questo post, la funzionalità è stata volutamente lasciata fuori. Peccato che, in certi casi, un FindElement su una collection che è magari stata modificata nel frattempo da un altro thread, può portare .NET a un loop infinito (e questo, però, vorrei tanto capire per quale motivo dovrebbe succedere….). Questo post mi ha abbastanza aperto gli occhi sul motivo per cui si sono rivelati i problemi!

Modale della favola: fate attenzione quando utilizzate tutti gli oggetti, anche quelli forniti dal Framework, e controllate bene se sono thread-safe, in caso vogliate usarli in applicativi con alto traffico! Ora, rimane solo da vedere se la cosa risolve veramente :)

Probabilmente molti di voi, usando Umbraco, si appoggiano a dei template XSLT per gestire le proprie macro. Se già non lo fate, iniziate a farlo… la gestione dei template è importante, e permette di mantenere gli XSLT relativamente semplici da gestire.

Una comodissima funzionalità dei template XSLT è la possibilità di richiamare un dato template, passando dei parametri. Questi parametri possono essere passati, o avere un valore di default che verrà utilizzato all’interno del template stesso.

Per dichiarare il template con i parametri, la sintassi è

<xsl:template match="node" mode="list">
    <xsl:param name="startingLetter">A</xsl:param>
    <!-- do something here –>
</xsl:template>

Per richiamarlo, invece, la sintassi è

<xsl:apply-templates select="$currentPage" mode="list">
    <xsl:with-param name="startingLetter">
        <xsl:value-of select="$startingLetter" />
    </xsl:with-param>
</xsl:apply-templates>

In questo modo, se non si passa il parametro, il template prenderà il valore di default “A”.

… e speriamo che sia l’inizio di un periodo con più sonno! :)

E’ online da pochi minuti il nuovo sito di Vogue Italia, la mia ultima fatica in Umbraco! Così capirete cosa intendo quando parlo di “siti impossibili” usando Umbraco :)

Umbraco ha alcune grandi pecche. Una delle più grandi è la crescita, a volte incontrollata, della base dati. Questo succede perchè per ogni salvataggio, Umbraco si tiene una versione di tutte le proprietà specificate per un DocumentType, nella tabella cmsPropertyData. Questo è comodissimo dal punto di vista redattoriale, ma per siti con grande ricambio di dati (come le testate giornalistiche che sto seguendo in questo periodo) si traduce in una crescita veramente esponenziale. Inoltre, anche la tabella umbracoLog cresce a dismisura, poichè non è possibile filtrare il livello di verbosity: o si spegne tutto, o ci si becca qualsiasi operazione loggata (salvataggio, pubblicazione, etc). Su Style.it, lanciato a fine Novembre, in soli tre mesi di attività eravamo arrivati a 4gb di dati.

Per la umbracoLog, è necessario cancellare la tabella. Per le versioni vecchie, invece, purtroppo non è prevista (per ora) una funzionalità di cancellazione delle versioni vecchie. E’ quindi necessario farlo a mano. In questo post, viene spiegato quali istruzioni SQL lanciare per farlo. Dopo aver cancellato le ultime versioni ed eseguito il clear del log, il database si è ridotto da 4gb a 400mb.

Esistono anche dei tools offline, la maggior parte non sono aggiornati. I più “recenti”, cioè quelli che dicono di funzionare sulla 4.x, sono i Client Tools for Umbraco, che però purtroppo non sono mai riuscito a far funzionare… se qualcuno ci riesce me lo faccia sapere :)

Io personalmente ho una stored, grazie all’aiuto di Xeed, che prende le ultime versioni precedenti ad una certa data, e cancella i relativi dati. Molto utile per evitare di zappare tutti i contenuti alla redazione: lasciargli solo l’ultima settimana di aggiornamenti è piu che sufficente per salvare spazio, e mantiene un certo livello di sicurezza agli editori.

Una delle funzionalità più richieste è operare con il testo nell’ambito dell’XSLT. Uppercase e lowercase sono sicuramente i metodi più popolari. Umbraco, nelle sue extension, non fornisce supporto per queste funzionalità. Ma non è una mancanza: le funzionalità di questo genere sono esposte dalle Xslt string utilities. In particolare, per l’Uppercase, si dovrà scrivere:

<xsl:value-of select="Exslt.ExsltStrings:uppercase($month)"/>

Per il lowercase… beh, indovinate :)

Purtroppo, nella reference queste due funzioni non sono specificate… quindi è altamente probabile che possano sfuggire!

Ho scritto ieri riguardo il FamFamFam Icon Pack, ed alla sua importanza nel caso di alberi realmente complessi, per dare un feedback visivo all’utente/editore su quello che sta facendo.

Mi hanno scritto alcune persone dicendo che è “inutile”, poichè nella selezione del DocumentType, le icone non vengono visualizzate, quindi ci si trova con una combo lunghissima, senza poter sapere che cosa si sta selezionando.

Purtroppo, è un “baco noto” di umbraco quello di non visualizzare le icone con nessun browser, tranne Firefox. Quindi, se volete giocare con i DocumentType e le nuove icone, e non usate Firefox, dovrete costringervi ad usarlo solo per questo task, visto che non funzionano neanche con Safari, Chrome, etc. Di fianco potete vedere come si vedono le icone con IE8, e sotto con Firefox. Molto meglio, vero?

Sono sicuro che anche a voi le icone standard fornite da Umbraco scontentano proprio. Quando si ha a che fare con molti DocumentType, avere a disposizione una gamma più ampia di icone è quasi una necessità, per consentire alla redazione di lavorare meglio ed accorgersi, anche visivamente, nel caso stiano facendo qualche errore.

Il miglior icon pack che ho trovato per Umbraco è il Fam fam fam icon pack, del già “famoso” Mark James. Installatelo ed avrete a disposizione una marea di icone per i vostri DocumentType… avrete solo l’imbarazzo di dover svegliere quella giusta!

… e se pensate che sia solo una frivolezza inutile…. beh, questo di fianco è lo screenshot del primo canale di www.style.it, non espanso completamente: mancano tutti gli articoli. Contate  che ci sarebbero altri 5 canali egualmente complessi, più il nodo dei servizi. Con solo le 20 icone, tutte uguali, fornite da Umbraco, la redazione morirebbe :)

Teamcity è un ottimo prodotto gratuito (con limitazioni, ma molto ampie) che risolve brillantemente il problema della Continuous Integration, senza spostarsi su prodotti più articolati come TFS, che per molti clienti è fuori portata.

Lo uso abitualmente in congiunzione con SVN: formano un’accoppiata molto stabile, e non mi danno praticamente nessun problema.

Ogni tanto, però, la build si rompe per misteriosi motivi, soprattutto usando Umbraco. Come premessa, in tutte le solution che hanno umbraco come website ho disabilitato la compilazione del website, perchè ci mette un sacco. Quindi, l’unico modo per assicurarsi che tutto funzioni correttamente e fare un “publish” manuale del website prima di committare le modifiche. Mi è successo con l’AjaxControlToolkit, che la build si rompesse comunque, in progetti complessi con altre web application oltre ad Umbraco, indipendentemente dal fatto che il publish fosse eseguito con successo.

L’errore era: [exec] Nomecontrollo.ascx.designer.cs(23,27): error CS0400: The type or namespace name 'AjaxControlToolkit' could not be found in the global namespace (are you missing an assembly reference?)

Il motivo era che, per errore, la DLL dell’ajax control toolkit referenziata era quella in GAC, non quella nella cartella apposita sotto SVN che contiene le dll referenziate di terze parti. E’ bastato cambiare la referenza al percorso giusto, ed il problema è rientrato. In alternativa, si sarebbe potuto anche installare l’AjaxControlToolkit, ma non era una soluzione che mi piaceva molto, non essendo il server sotto la nostra giurisdizione.

In molti casi, è necessario estendere Umbraco per aggiungergli diversi tipi di funzionalità.
Nell’ultimo progetto, che andrà online tra qualche settimana, abbiamo dovuto creare un sito parallelo che girasse dentro umbraco (quasi come abbiamo fatto con www.style.it). In questo sito, che comunque gira sotto umbraco, abbiamo dovuto utilizzare la sessione per diversi motivi.

Ovviamente, pubblicato sull’ambiente di stage, non funzionava piu nulla. Gli “object reference not set” del log non davano molte informazioni, ma con un pò di magia abbiamo scoperto l’arcano: le sessioni erano tutte misteriosamente a null. Ma non nel senso valore null, nel senso che HttpContext.Current.Session era null. Praticamente non veniva caricato il modulo della Session. L’errore restituito è:

“Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive.”

L’unica differenza tra il nuovo progetto e quello che abbiamo fatto con style era l’utilizzo dei DirectoryUrl, ossia abbiamo levato le estensioni .aspx dai documenti di umbraco. Cercando in giro, abbiamo trovato la soluzione in questo post.

Praticamente, IIS7 ha una sorta di feature (baco?) per cui bisogna specificare nel web.config, nel tag Modules, l’attributo “runAllManagedModulesForAllRequests” e valorizzarlo a true. In questo modo:

<modules runAllManagedModulesForAllRequests="True">

… A me va anche bene, con la modifica tutto funziona.. mah.. mi chiedo perchè “discriminare” alcuni moduli, come quello della session, e altri no… mi sarei aspettato un sito totalmente non funzionante, non tutto funzionante tranne le Session! Anche perchè questo genere di problemi, se non si dispone di un IIS7 su cui fare debug (es: lo sviluppatore che ha XP o Vista sul suo PC, e pubblica su uno shared host), possono portare a un sacco di problemi!

Chiunque possegga un mac e lo utilizzi (violenti?) per farci girare windows, si scontra probabilmente ogni giorno con il grande problema della tastiera, soprattutto se si ha un macbook o macbook pro.

Una delle grandi conquiste che ho avuto negli ultimi tempi è trovare la combinazione per il tasto “INS”, comodissimo in certi casi, inutile in molti altri: fn+Invio. Me ne sono accorto a mie spese, quando l’ho attivato inavvertitamente (cercando di fare un canc, fn+Backspace) e ho sudato per levarlo… :)

Invece, non ho ancora trovato alternativa alla tilde… se non utilizzare la tastiera americana, o la mappa caratteri.. o il copia/incolla… la documentazione apple è altamente indietro, magari dovrebbero aggiornarla un pò…

In realtà, sono usciti il 19 di Gennaio… ma io sono _sempre_ in ritardo, e me li sono installati solo ora.

Risultato:spettacolo! Io ho un Macbook pro 2009 @ 2.8ghz e finalmente il mio Seven ha

- Smesso di pensare che il digital audio fosse sempre attivo, sparando fuori la luce rossa a-la Terminator dall’audio in;
- Risolto i problemi audio che avevo coi vecchi driver, ed ha iniziato a vedermi il microfono anche fuori dal registratore di suoni di Windows, senza fare giri strani con driver di terze parti e modifiche degli ini (che tra parentesi non sono mai funzionate bene…). E posso tornare ad usare Skype e Netmeeting senza particolari barbatrucchi
- Installato dei driver decenti per la mia NVidia, che ora arriva finalmente a 6.3 di Performance Index (prima era 5.3 con i driver bootcamp 3.0 standard. Bisognava passare da laptopvideo2go per avere qualche speranza di arrivare oltre i 6)

Assolutamente consigliati, installateli subito se non lo avete già fatto! Li trovate sia nella versione a 32 bit che in quella a 64 bit.

Forse non tutti sanno che, negli ultimi mesi, sono stato presissimo perchè la mia azienda si è occupata totalmente del rilascio del nuovo sito di style.it. Posso affermare senza ombra di dubbio che è il progetto piu complesso che abbia mai affrontato con Umbraco. Con qualche ombra di dubbio, posso affermare che è uno dei progetti più complessi che conosca in generale, sviluppato con Umbraco. Se qualcuno sta pensando al novello ASP.NET, la grande differenza tra i due è che ASP.NET è utilizzato e editato da gente che, più o meno, capisce quello che sta facendo. Style ha invece dietro di se una batteria di 30 redattori veri, cioè giornalisti che usano il PC per impaginare con Publisher. Questo è stato lo scoglio più insormontabile, che ci ha portato alla creazione di un numero impressionante di custom data type incredibilmente complessi, ed alla gestione di contenuti editoriali automatici e semiautomatici abbastanza complessi.

Tralasciando le magagne di sviluppo, che verranno sicuramente affrontate nei prossimi miliardi di post che farò su questo CMS, uno dei problemi principali che ci ha afflitto è la scarsità delle performance del backend. La rete interna del cliente non è il massimo e spesso si avevano degradazioni non imputabili al CMS, ma a fattori esterni.

L’onnipresente Niels, in un suo post del lontano 2007, ci ha fornito la soluzione: aggiungere l’expire a 7, o più, giorni sugli elementi comuni di Umbraco direttamente in IIS. Non tutti, attenzione, perchè anche molti css (tipo quelli sotto umbraco\css) sono gestiti in maniera dinamica. Nel post spiega esattamente quali cartelle possono subire questa variazione. Vi assicuro che le differenze in termini di performance sono chiaramente visibili!

Probabilmente molte persone che usano umbraco ormai sono a conoscenza della possibilità di visualizzare il trace di .NET ed i relativi messaggi di errore delle macro utilizzando umbShowDebugTrace (per chi non ne fosse a conoscenza, fate un salto qui: http://our.umbraco.org/wiki/how-tos).

Per chi invece già lo conosce e, come me, lo ritiene a volte poco intuitivo e pratico, segnalo questa utilissima estensione per Chrome di Kenneth, con cui ho avuto il piacere di lavorare spesso. In pratica ti aggiunge un menù che ti permette di entrare e uscire dalla modalità di debug, navigare direttamente in umbraco e un paio di altre cose carine. Veramente utile. Grazie anche a Giorgione per avermela segnalata.

Visto che, ultimamente, la maggior parte dei miei Weekly (Daily? Hourly?) Issue sono dovuti principalmente a questo CMS, ho deciso di creare una sezione apposta :)

Iniziamo con uno degli errori più comuni che mi sono capitati in questi ultimi giorni: non si sa per quale motivo, l’applicativo in produzione ha iniziato a crashare prima ancora di avviarsi, tirandosi dietro tutto il W3WP.exe. L’errore, abbastnza criptico, era:

Type 'umbraco.DataLayer.SqlHelperException' in Assembly 'umbraco.DataLayer, Version=0.3.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.

Dopo parecchi giri, discussioni via MSN con alcune persone del core team, e ricerche dovunque, si è scoperto che questo problema è dovuto ad una stringa di connessione sbagliata.
Lo so, è abbastanza ridicolo, e non ho ancora controllato i meccanismi di base per cui una stringa di connessione possa far crashare tutto l’applicativo invece di notificare l’errore. Ma vi assicuro che è assolutamente quello il problema: controllate bene il server, la password, qualsiasi problema di spelling o di mancanze (nel mio caso, lo script nant si era “mangiato” la keyword “Data Source”….).

Capita, ogni tanto, di avere a che fare con la lettura di dati da server remoti. In questi casi, HttpWebRequest ci viene in contro, fornendoci tutti gli strumenti necessari.

Finché si tratta di pagine web, ci sono pochi problemi. Abbiamo qualche piccolo pensieri in più, invece, quando si tratta di dati binari: spesso e volentieri, il risultato appare incompleto. Per esempio, le immagini vengono restituite con un bel po' di byte persi qua e là. Questo perché, se è vero che nel leggere stringhe basta utilizzare il consueto ReadToEnd, per leggere dati binari conviene sempre utilizzare il meccanismo del buffer, ossia leggere un pezzo per volta.

   1:   

   2:  byte[] output;

   3:   

   4:  WebRequest request = WebRequest.Create(url);

   5:  using(WebResponse response = request.GetResponse())

   6:  {

   7:     using(Stream rs= response.GetResponseStream())

   8:     {

   9:        using(MemoryStream ms= new MemoryStream())

  10:        {

  11:           int count = 0;

  12:           byte[] buffer = new byte[4096];

  13:           do

  14:           {

  15:              count = rs.Read(buffer, 0, buffer.Length);

  16:              ms.Write(buffer, 0, count);

  17:   

  18:           } while(count != 0);

  19:   

  20:           output= ms.ToArray();

  21:        }

  22:     }

  23:  }

In questo modo siamo sicuri di riuscire a leggere tutto il contenuto binario, senza perderci dati per strada. L’ideale è, chiaramente, fare un metodo helper che si occupi di tutto!

No, non vuol dire che mi sono venute manie strane riguardo al metal in genere…

Semplicemente, sto cercando di prendere maschera e boccaglio e di riemergere dall’apnea communitaria che mi ha contraddistinto in questi mesi… chi mi conosce sa che sono “periodico” da questo punto di vista. Tutto sta a vedere quanto gli impegni lavorativi mi permetteranno di stare fuori dall’acqua! Se non altro, non ho libri in progetto per questo periodo, quindi speriamo bene!

A presto con nuovi issue :)