UGIALT.NET Conference II

1. 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 – ChiusuraLavori e futuro

3. Sponsor

4. Introduzione a UGIALT

5. Agenda • Manifesto • Storia • Cosasignifica ALT.NET • Perchè ALT.NET

6. Manifesto • Sei un dev cheusaquellochefunziona ma seisempreallaricercadiqualcosadimeglio • Tienid’occhioilresto del mondo per adottareilmegliodaogni community: Open Source, Agile, Java, Ruby, ecc… • Non seicontento del tuostatoattuale. Le cosepossonosempreesseremigliorarate, codicepiùelegante e semplice, piùmanutenibile e dimaggiorequalità • Saiche I tools sonoimportanti, ma non tiportano molto lontano. Sonoiprincipi e la conoscenzachecontano. I tool migliorisonoquellicheincorporano 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.NETConference ad Austin (TX) • Novembre 2007 – Nasce UGIALT.NET • Febbraio 2008 – 1° ConfUGIALT.NET • Aprile 2008 – ALT.NETconf a Seattle

8. Cosasignifica ALT • ALT !=Alternativo • ALT ==Avere Alternative

9. Perchè ALT.NET • UserGrouptradizionalisono “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. Emanuele DelBono emanuele@codiceplastico.com http://blog.codiceplastico.com Agilità

13. Le metodologie tradizionali

14. Agility!

15. I tre capisaldi • La femmina • Il danaro • La mortazza

16. I tre capisaldi (quelli veri) Iterazioni Collaborazione Adattabilita’

17. Le persone non strumenti

18. Software, non documentazione

19. Il cliente collaborativo

20. Adattarsi al cambiamento

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

22. Cos’è XP? • XP è una metodologia basata su un insieme di pratiche: • Whole Team • Planning Game • CustomerTests • SmallReleases • Simple Design • PairProgramming • Test DrivenDevelopment • Design Improvement • ContinuousIntegration • Collective Code Ownership • Coding Standard • Metaphor • Sustainable Pace

23. Cos’è Test Driven Development • Praticadi XP • Sviluppofunzionalitàguidatodai Test • Attivitàdiprogettazione : • Red : definireilcomportamentoatteso con asserzioni • Green : rendereeseguibili con successoi test, le asserzionisonoverificate • Refactor : effettuare refactoring mantenendoverificateasserzioni (eliminareduplicati, design pattern …)

24. TDD Mantra

25. Refactoring • Migliorareil software tramite l’ applicazionediunaseriedimodifiche interne che non cambianoilcomportamentoesterno.

26. Scopoprincipale del TDD • Non è testareilcodice. • Aiutaresviluppatori e clientiduranteilprocessodisviluppodefinendorequisiti non ambigui. • TDD = Design (design emergente)

27. Velocitàsviluppotradizionale

28. Tradizionalevs Agile

29. Benefici • Codicesemplice e funzionante (Simple Design Principle) “Simplicity is more complicated than you think. But it’s well worth it” – Ron Jeffries • CodiceTestato (Test Behaviour Not Code) • Facilmentemanetunibile (Embrace Change) • YAGNI (You ArentGonna Need It) = No over design

30. Claudio Maccari Mail: cmaccari@absistemi.it Blog (ITA): http://blogs.ugidotnet.org/makka Blog (ENG):http://testdrivendevelopment.wordpress.com/ Rhino.Mocks

31. Cos’èRhino.Mocks? • Framework mock object per .net • http://www.ayende.com/projects/rhino-mocks.aspx • Si parladi test… unit testing • Oradisponibileversione 3.4

32. Rendepiùsemplice lo unit testing Fake the hard stuff • Risorseesterne • Networks • Databases • Altrisistemi • Risorse interne • Qualsiasicosa con setup complesso • Legacy code

33. Si trattadiinterazione Objects talking to objects • “State based testing”vabene • “Interaction based testing” e piùinteressante

34. Strutturadi un test con Rhino.Mock • Creazionedi un mock • Definizionedellecomporamentoatteso • Esecuzione del codice sotto datestare • Verificadelleaspettative • Asserts addizionali

35. Bastachiacchiere Lets see some code!

36. Codice da testare

37. Test usando il mock

38. Per andare a fondo

39. Registra e ripeti • La soluzione sta nel mezzo ?

40. Tipi di mock

41. Impostare le aspettative (1/2)

42. Impostare le aspettative (2/2)

43. Rhino.Mocks … Rocks! • Download • http://www.ayende.com/projects/rhino-mocks.aspx • Wiki • http://www.ayende.com/Wiki/ • Quick Reference (ottimodocumento) • http://www.ayende.com/Wiki/GetFile.aspx?File=Rhino+Mocks+3.3+Quick+Reference.pdf

44. Q & A • Dopo 

45. Simone Busoli 14/06/2008 - Milano Dependency Injection Inversion of Control

46. Di cosasitratta • ComunementeDI - IoC • Principicomunididisegno software • Alta coesione • Basso accoppiamento • … • Basso accoppiamento • Riduzionedelledipendenzetracomponenti software • Chi conosce chi? • Risoluzionedipendenzetracomponenti

47. Scenario • Voglio poter registrare le iscrizioni ad un evento • Persistere i dettagli dell’iscritto • Comunicare se l’iscrizione è andata a buon fine tramite mail

48. DependencyInjectionElevato accoppiamento • SubscriptionService conosce direttamente i dettagli di EmailService e PersonRepository BAD

49. Dependency InjectionCambiamento di paradigma • Il servizio conosce solo l’interfaccia dei componenti che utilizza GOOD

50. DependencyInjection • Iniettare dipendenze dall’esterno rende più onerosa l’istanziazione di componenti • Necessario conoscere tutte le dipendenze