1 / 76

UGIALT.NET Conference II

UGIALT.NET Conference - 14 Giugno 2008. UGIALT.NET Conference II. 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

tybalt
Download Presentation

UGIALT.NET Conference II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related