lunedì 1 agosto 2011

Symfony 2

Dopo circa 3 anni di sviluppo esce finalmente la versione 2.0 del framework Symfony... devo assolutamente trovare il tempo di studiarmela.

mercoledì 27 luglio 2011

755 è meglio di 777

L'avventura di oggi riguarda Wordpress. In particolare uno script che si occupa di ridimensionare le immagini.
Tutto bene, installazione e configurazione velocissima il sito funziona perfettamente arriva il momento di caricare le immagini della galleria e niente la galleria non funziona. Il server di Aruba restituisce un magnifico Internal Server Error.
Analizzando l'errore mi imbatto nel seguente messaggio di log: Directory "/home/(...)/public_html/wp-content" is writeable by others
Premature end of script headers: timthumb.php
La spiegazione è che alcuni server non permettono agli script php di girare se la cartella è scrivibile da utenti che non fanno parte dello stesso gruppo. Ovvero la soluzione è stata cambiare i permessi della cartella da 777 a 755.

mercoledì 8 giugno 2011

Enterprise Design: Repository Pattern

In accordo con Martin Fowler il repository pattern è: "layer of abstraction over the mapping layer where query construction code is concentrated". In pratica è una collezione di metodi per l'accesso ai dati e visibili alle classi di dominio. Ancora meglio: il repository pattern crea un livello di astrazione sopra l'ORM. Abbiamo subito tre vantaggi concreti:
  1. Testabilità: utilizzando il repository pattern otteniamo un layer su cui è semplice sostituire i dati con delle classi stub per effettuare test sulla logica di business senza interessare il codice di accesso ai dati.
  2. Astrazione: questa atrazione permette di modificare di disaccoppiare la logica di business dallo strato di accesso ai dati.
  3. Dependency Injection: permette di utilizzare containers Di per iniettare oggetti che si vogliono utilizzare nel codice.
Si parte dalla creazione di un'interfaccia, nel mio caso:
public interface IShopRepository
{
IList<
Shop> FindAll();
IList
<Shop> FindAll(int index, int count);
IList
<Shop> GetShopByCategory(int idcategory);
IList
<Shop> GetPrimoPiano();
IList
<Shop> GetAltri();
Shop FindById(int id);
Shop FindByName(string name);
IList
<Category> GetAllCategory();
IList<Product> GetProductBoxMostSell();
IList<ShopAffiliato> GetAllShopAffiliati();
(...)

}
In questo caso abbiamo solo operazioni di "select", in generale avremo tutte le operazioni cosidette CRUD (create, read, update, delete).

Il secondo passo è costruire una classe che implementa i metodi definiti nella interfaccia. Nel mio caso questa classe interagisce con l'ORM sottostante: Entity Framework.

 IList<Shop> IShopRepository.FindAll()
{

var negozi = from n in new IperclubShopEntities().tShops
where n.attivo == true
select new Shop
{
Id = n.ShopId,
Nome = n.nome,
Attivo = (bool)n.attivo,
CodiceZanox = n.codicezanox,
Descrizione = n.descrizione,
Logo1 = n.logo1,
Logo2 = n.logo2,
PrimoPiano = (bool)n.primopiano,
ScopriAltri = (bool)n.scoprialtri,
TipoConversione = 1,
TassoConversione = n.tassoconversione,
IndiceConversione = (float)n.conversione,
UrlNegozio = n.url,
TestoVetrina=n.testovetrina,
ListaBrand = from b in n.tBrands
where b.attivo == true
select new Brand
{
Attivo = (bool)b.attivo,
BrandId = b.BrandId,
Descrizione = b.descrizione,
Logo1 = b.logo1,
Logo2 = b.logo2,
Nome = b.nome
},
ListaTag = from t in n.tTags
select new Tag
{
Id = t.TagId,
Nome = t.tag
},
ListaCategory = from c in n.tCategories
select new Category
{
Id = c.CategoryId,
Nome = c.nome
},
ListaRegole = from r in n.tRules
select new Rules
{
RegolaId = r.RegolaId,
Attiva = (bool)r.attiva,
Conversione = (float)r.conversione,
Note = r.note,
Punti = (int)r.punti,
Shopid = (int)r.Shop_id,
TestoRegola = r.testoregola,
TipoRegola = (int)r.tiporegola,
ValoreMassimo = (decimal)r.valoremassimo,
ValoreMinimo = (decimal)r.valoreminimo
},
Tiponegozio = new TipiNegozio{ Id=n.tTipiNegozio.id, Nome=n.tTipiNegozio.tipo},
};

return negozi.ToList();
}

Ora non rimane che dire implementare nel layer dei servizi una classe che istanzi un oggetto di tipo IShopRepository e ne utilizzi i metodi per ottenere collezioni che possibilmente abbiano implementata l'interfaccia IEnumerable
public class ShopService
{
private IShopRepository _shoprepository;
public
ShopService(IShopRepository shoprepository)
{
_shoprepository = shoprepository;
}

public
IEnumerable<ShopViewModel> GetAll()
{
return
_shoprepository.FindAll().ConvertToShopViewList();
}
(....)
}

In questo spezzone di codice viene fatto anche il mapping tra gli oggetti del model e gli oggetti del viewmodel.

Dove avviene la magia?

Nel progetto del sito MVC ho creato una classe BootStrapper che si occupa di assegnare ad una richiesta di un tipo astratto un tipo concreto:

public class BootStrapper
{ public static void ConfigureDependencies()
{ ObjectFactory.Initialize(x=>
{
x.AddRegistry<ControllerRegistry>();
}); }

public class ControllerRegistry : Registry
{
public ControllerRegistry()
{
ForRequestedType<ICategoryRepository>().TheDefault.Is.OfConcreteType<CategoryRepository>();
ForRequestedType<IShopRepository>().TheDefault.Is.OfConcreteType<ShopRepository>();
ForRequestedType<IPartnerRepository>().TheDefault.Is.OfConcreteType<PartnerRepository>(); }
}
}


Nell'evento Application_start:

protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterRoutes(RouteTable.Routes);
BootStrapper.ConfigureDependencies();
ControllerBuilder.Current.SetControllerFactory(new IoCControllerFactory());
}


E il gioco è fatto. Il layer dei servizi è completamente disaccoppiato dal modo con cui si accede ai dati.

martedì 17 maggio 2011

Google Tv e Android

Android sta diventando sempre più il sistema operativo dei dispositivi mobili. IOs ha probabilmente raggiunto la massima quota di mercato e Windows Phone 7 non sfonda.
Cercando un nuovo televisore mi sono imbattuto nella Google Tv, probabilemente non sarà la mia prossima televisione, ma intanto mi ha incuriosito.

Google Tv utilizza una versione di Android, durante questa estate verrà fatto l'upgrade a Android 3.1 ma cosa bisogna tener conto per poter sviluppare applicazioni per Google Tv?
Due sono gli aspetti fondamentali: la dimensione dello schermo e l'interazione con l'utente.

Si hanno due possibilità di risoluzione la prima definita HD è: 1280x720 ovvero più bassa di quella utilizzata dai tablet. L'altra risoluzione possibile è quella definita Full HD: 1920x1080.
Ma non basta considerare le dimensioni in pixel, nel disegnare la grafica va considerato che mentre i tablet e i telefoni sono device che si possono capovolgere, questo non può essere fatto con la tv che verrà utilizzata sempre in modalità landscape. In genere i tablet vengono usati in modalità landscape mentre i telefoni in modalità portrait.
Anche la densità dei pixel è diversa, nei televisori è di 96dpi.

Infine l'interazione: nei tablet e nei phone avviene tramite touchscreen mentre il televisore non si tocca dato che in genere si trova ad alcuni metri di distanza dall'utilizzatore...

La distribuzione delle applicazioni ricalca lo schema di quella dei cellulari e dei tablet ovvero avviene tramite l'android market.

Sono curioso di vedere come andrà a finire, certo è che l'introduzioni di televisori smart cambia le regole ormai fossilizzate del mercato televisivo con tutto quello che comporta non solo sul piano economico.

giovedì 28 aprile 2011

Enterprise Design: Service Layer

In ambito enterprise è molto comune poter distinguere operazioni che possono essere modellate come servizi ovvero funzionalità indipendenti e condivise da più moduli.

Nell'ambito della reingegnerizzazione del sistema informatico dell'azienda si è pensato di applicare alcuni principi di design cosidetti SOA (Service Oriented Archicture) e in particolare l'idea principale è stata la gestione del motore di ricerca dell'offerta turistica come modulo indipendente a tutti i sistemi.

Prima un pò di teoria.

I 4 principi del design SOA sono:

I confini devono essere espliciti
L'interfaccia del servizio deve essere semplice e chiara più che possibile e avere un approccio consistente con i dati scambiati.

I servizi sono autonomi
Il client deve essere in grado di collegarsi al servizio e con un'unica operazione atomica ottenere il risultato sperato.

I servizi condividono contratti e non classi
Il nucleo dell'architettura SOA è l'interoperabilità questa viene garantita con lo scambio di informazioni relative a come comunicare ma non dell'implementazione del servizio. Questo viene fatto tramite lo scambio di messaggi xml che sono neutrali rispetto alla piattaforma.

I servizi basano il loro consumo su regole di policy
I servizi dovrebbero esporre una policy su come devono essere usati e su questa i client basano il loro utilizzo.

L'interconnessione tra le applicazioni e i motori di ricerca aveva portato ad avere 5 implementazioni diverse di un oggetto che si occupasse dic ercare nella stessa base dati con tutti i relativi problemi di manutenzione e scalabilità.

Oggi è concluso il primo step del nuovo progetto.

Il motore di ricerca è quindi realizzato con la tecnologia Windows Communication Fondation 4.0, in ingresso si aspetta: un xml contentente i parametri di ricerca, il set corrente e la lunghezza in termini di risultati del set di risultati da esporre. In uscita i dati sono incapsulati in un vettore JSON.

venerdì 22 aprile 2011

POCO vs Entity Framework

Se vi dovesse capitare il seguente errore: Mapping and metadata information could not be found for EntityType.

Sappiate che è quasi certamente dovuto alla non corrispondenza tra le classi del modello e il mapping di EF:
  1. Proprietà scritte male è case sensitive
  2. Proprietà mancanti
  3. Tipi non corrispondenti
  4. Enums nelle classi POCO che a oggi EF non supporta
A me sono servite 12 ore di craniate per scoprire dove era nascosto il problema.