La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

UGIALT.NET Conference II

Presentazioni simili


Presentazione sul tema: "UGIALT.NET Conference II"— Transcript della presentazione:

1 UGIALT.NET Conference II
UGIALT.NET Conference - 14 Giugno 2008 UGIALT.NET Conference II

2 Agenda della conference
10:00 – Benvenuto 10:15 – Introduzione a UGIALT.NET 10:30 – Lightning talks 11:00 – Pausa 11:15 – Prioritizzazione user stories 11:30 – Prima User Story introduttiva 12:00 – Users Stories 13:30 – Pranzo 14:30 – User Stories cont. 17:30 – Chiusura Lavori e futuro

3 Sponsor

4 Introduzione a UGIALT

5 Agenda Manifesto Storia Cosa significa ALT.NET Perchè ALT.NET

6 Manifesto Sei un dev che usa quello che funziona ma sei sempre alla ricerca di qualcosa di meglio Tieni d’occhio il resto del mondo per adottare il meglio da ogni community: Open Source, Agile, Java, Ruby, ecc… Non sei contento del tuo stato attuale. Le cose possono sempre essere migliorarate, codice più elegante e semplice, più manutenibile e di maggiore qualità Sai che I tools sono importanti, ma non ti portano molto lontano. Sono i principi e la conoscenza che contano. I tool migliori sono quelli che incorporano la conoscenza e incoraggiano I principi (ad. Es. Resharper)

7 Un po’ di storia Aprile 2007 – Il termine ALT.NET appare per la prima volta in un post di David Laribee Ottobre 2007 – Prima ALT.NET Conference ad Austin (TX) Novembre 2007 – Nasce UGIALT.NET Febbraio 2008 – 1° Conf UGIALT.NET Aprile 2008 – ALT.NET conf a Seattle

8 Cosa significa ALT ALT != Alternativo ALT == Avere Alternative

9 Perchè ALT.NET UserGroup tradizionali sono “about technology”
Più importante: Principi base dell’OOP Processi e metodologie di sviluppo Tool Alternativi

10 Ligthning Talks

11 Agenda Agilità (Emanuele DelBono) TDD (Roberto Valenti)
Mocking – Rhino (Claudio Maccari) IoC/DI (Simone Busoli) MVC/MVP (Simone Chiaretta) ORM (Matteo Baglini)

12 Agile Emanuele DelBono

13 Agilità Emanuele DelBono emanuele@codiceplastico.com
Agilità

14 Le metodologie tradizionali

15 Agility!

16 I tre capisaldi La femmina Il danaro La mortazza

17 I tre capisaldi (quelli veri)
Iterazioni Collaborazione Adattabilita’

18 Le persone non strumenti
le persone e le interazioni sono più importanti dei processi e degli strumenti

19 Software, non documentazione
è più importante avere software funzionante che documentazione

20 Il cliente collaborativo
collaborare con i clienti al di là del contratto

21 Adattarsi al cambiamento
essere pronti a rispondere ai cambiamenti più che aderire al planning

22 Perché? Fornire valore al cliente in breve tempo
Gestire il cambiamento Ridurre il rischio Migliorare la qualità Per divertirsi mentre si lavora!

23 Cos’è XP? XP è una metodologia basata su un insieme di pratiche:
Whole Team Planning Game Customer Tests Small Releases Simple Design Pair Programming Test Driven Development Design Improvement Continuous Integration Collective Code Ownership Coding Standard Metaphor Sustainable Pace

24 TDD Roberto Valenti

25 Cos’è Test Driven Development
Pratica di XP Sviluppo funzionalità guidato dai Test Attività di progettazione : Red : definire il comportamento atteso con asserzioni Green : rendere eseguibili con successo i test, le asserzioni sono verificate Refactor : effettuare refactoring mantenendo verificate asserzioni (eliminare duplicati, design pattern …)

26 TDD Mantra Processo TDD

27 Refactoring Migliorare il software tramite l’ applicazione di una serie di modifiche interne che non cambiano il comportamento esterno.

28 Scopo principale del TDD
Non è testare il codice. Aiutare sviluppatori e clienti durante il processo di sviluppo definendo requisiti non ambigui. TDD = Design (design emergente)

29 Velocità sviluppo tradizionale
Costo x Modifica nel Tempo

30 Tradizionale vs Agile Costo x Modifica nel Tempo

31 Benefici Codice semplice e funzionante Codice Testato
(Simple Design Principle) “Simplicity is more complicated than you think. But it’s well worth it” – Ron Jeffries Codice Testato (Test Behaviour Not Code) Facilmente manetunibile (Embrace Change) YAGNI (You Arent Gonna Need It) = No over design Microsoft al Teched a detto che loro non fanno qlc di simile perchè non saprebbero fare di meglio

32 Mocking Claudio Maccari

33 Rhino.Mocks Claudio Maccari Mail: cmaccari@absistemi.it
Blog (ITA): Blog (ENG): Rhino.Mocks

34 Cos’è Rhino.Mocks? Framework mock object per .net
Si parla di test… unit testing Ora disponibile versione 3.4 Microsoft al Teched a detto che loro non fanno qlc di simile perchè non saprebbero fare di meglio

35 Rende più semplice lo unit testing
Fake the hard stuff Risorse esterne Networks Databases Altri sistemi Risorse interne Qualsiasi cosa con setup complesso Legacy code

36 Si tratta di interazione
Objects talking to objects “State based testing” va bene “Interaction based testing” e più interessante

37 Struttura di un test con Rhino.Mock
Creazione di un mock Definizione delle comporamento atteso Esecuzione del codice sotto da testare Verifica delle aspettative Asserts addizionali

38 Basta chiacchiere Lets see some code!

39 Codice da testare

40 Test usando il mock

41 Per andare a fondo

42 Registra e ripeti La soluzione sta nel mezzo ?

43 Tipi di mock

44 Impostare le aspettative (1/2)

45 Impostare le aspettative (2/2)

46 Rhino.Mocks … Rocks! Download Wiki Quick Reference (ottimo documento)
Wiki Quick Reference (ottimo documento)

47 Q & A Dopo 

48 IoC/DI Simone Busoli

49 Dependency Injection Inversion of Control
Simone Busoli 14/06/ Milano Dependency Injection Inversion of Control

50 Di cosa si tratta Comunemente DI - IoC
Principi comuni di disegno software Alta coesione Basso accoppiamento Riduzione delle dipendenze tra componenti software Chi conosce chi? Risoluzione dipendenze tra componenti

51 Scenario Voglio poter registrare le iscrizioni ad un evento
Persistere i dettagli dell’iscritto Comunicare se l’iscrizione è andata a buon fine tramite mail SubscriptionService Service PersonRepository

52 Dependency Injection Elevato accoppiamento
SubscriptionService conosce direttamente i dettagli di Service e PersonRepository BAD

53 Dependency Injection Cambiamento di paradigma
Il servizio conosce solo l’interfaccia dei componenti che utilizza GOOD

54 Dependency Injection Iniettare dipendenze dall’esterno rende più onerosa l’istanziazione di componenti Necessario conoscere tutte le dipendenze

55 Vorrei un’istanza di SubscriptionService
Inversion of Control Hollywood Principle Don’t call us, we will call you! Vorrei un’istanza di SubscriptionService

56 Inversion of Control Container
Entità esterna all’applicazione Configurabile Conosce le dipendenze tra i componenti ed è in grado di soddisfarle a runtime IoC Container Vorrei un’istanza di SubscriptionService Istanza completa di tutte le dipendenze

57 Windsor Container Inversion of Control container open source
Stabile – production ready Si configura il container (xml, boo, C#) Si richiede l’istanza di un componente Il container si occupa di soddisfare le dipendenze e creare l’istanza

58 Windsor Container Esempio
Configurazione Xml

59 Windsor Container Esempio
Codice client Molto meglio, eh? Altri containers StructureMap Spring.Net Autofac

60 Risorse Inversion of Control and Dependency Injection: Working with Windsor Container Castle Project StructureMap

61 MVC/MVP Simone Chiaretta

62 UI Patterns: MVC – MVP 14/06/2008 – Sim0ne Chiaretta
blog ITA: blog ENG: UI Patterns: MVC – MVP

63 It’s all about separation
Loose coupling Necessario rimuovere l’ambiente esterno Uomo WebServer

64 UI Pattern MVC – Model View Controller MVP – Model View Presenter

65 Model View Controller Model Controller View

66 Model View Presenter View Presenter Model IView

67 Dove si trovano in natura
MVC MonoRail ASP.NET MVC Framework Prism MVP Mostly custom built WebClientSoftwareFactory CompositeUIApplicationBlock

68 Come saperne di più su MVC
- Sito ufficiale, con download P2 - Codice sorgente - tutti gli articoli su ASP.NET MVC - lista “commentata” di risorse Blog di MS ScottGu: ScottHa: PhilHa: Leggendo il mio blog  DotNetMarche – 27 Giugno – Testing automatizzato e Asp.NET MVC Framework

69 ORM Matteo Baglini

70 ORM - Object Relational Mapping
14/06/2008 – Matteo Baglini Mail: Blog: ORM - Object Relational Mapping

71 Quando e Perchè usare un ORM

72 Scenario Business Logic Layer modellato utilizzando il pattern Domain Model. Le tabelle del database secondo il modello relazionale RDBMS .

73 Problema Paradigm Mismatch ? ORM

74 Definizione di ORM L’ Object Relational Mapping è uno strumento che permette di mappare i dati fra il modello RDBMS ed il modello OOP.

75 Tecniche di Data Mapping
File XML Decorando Classi e Proprietà con Attributi

76 Vantaggi e Svantaggi

77 Vantaggi Permette di disegnare il modello seguendo la teoria OOP osservando solo la business logic. Approccio non più bottom-up ma top-down (dal dominio alla persistenza). Generazione automatica ed ottimizzata di statement sql creati ad hoc, i quali permettendo di gestire in maniera molto più granulare le operazioni CRUD.

78 Svantaggi Alta curva di apprendimento iniziale.
Leggeri compromessi nella progettazione del Domain Model, es. Implementare interfacce. Viene visto come “lo strumento” che permette allo sviluppatore di dimenticarsi del database.

79 ORM per .NET

80 I più famosi NHibernate Linq To Sql Entity Framework (Beta 3)
Open Source / Porting da Hibernate (Java) / Multi Database Vendor / Persistence Ignorance / Mapping Complessi Linq To Sql Supporto di MS/ Integrato con VS / Sintassi Linq / Molto Semplice Entity Framework (Beta 3) Supporto di MS/ Integrato con VS / Multi Database Vendor / Sintassi Linq / Mapping Complessi

81 Link Object Relational Mapping NHibernate/Hibernate
Wikipedia - C2.com - NHibernate/Hibernate Sito - Libro -

82 Link Linq To Sql Entity Framework
MSDN - Serie di di Post sul Blog di ScottGu - Entity Framework MSDN - CodePlex Samples-


Scaricare ppt "UGIALT.NET Conference II"

Presentazioni simili


Annunci Google