really really really awesome php application with bdd behat and iterfaces

Editor's Notes

• #2: Già il nomed ‘coders’, scrivere codice eh… ma scrivere poi è la parte piu piccola, ci metti 3 mesi per corteggiare il cliente, ci metti i mesi di giorni per capire il cliente, ci metti mesi per far capire al cliente l’Agile, ci metti mese per far capire al cliente cosa veramente ha bisogno, se poi ci aggiungi i giorni di imprecazioni per capire il codice che hai scritto nell’iterazione prima, il tempo per scrivere i test prima di fare codice, pensare a cosa fare… scrivere codice è il 10%, spendi piu tempo Mi piace la definizione che da il libro managment 3.0: I developer sono knowledge workers provvedono a soddisfare il business con un valore che prima non avevano.
• #3: NON siamo qui per parlare di awesome application ma per parlare di really awesome appl Non ho preparato un talk, perchè mi aspettavo la sala vuota, mi sono detto parlo di awesome application in PHP, nemmeno volevo fare le slide, bene PHP e qualità quanti di voi si sono persi o sono in questa sala per sbaglio? No non parleremo di PHP… Di solito quando si è programmatore PHP si ha un senso di inferiorità, se sei un programmatore PHP pensi che gli altri siano piu bravi di te di solito quando sei un programmatore PHP lo sai… si lo sai.. lo sai che hai di fronte un linguaggio che fa schifo di solito quando mi chiedono in che linguaggio uso, io dico prima una cosa per sembrare intelligente del tipo l’hai letto il libro managment 3.0 sul agile …
• #4: sono liuggio ho 30 anni e sono un programmatore PHP PHP è un acronimo che voleva dire spaghetti code PHP (acronimo ricorsivo di "PHP: Hypertext Preprocessor") “PHP is the new VB6 in a C dress.” cit Ha sempre avuto tanto successo e tanto odio
• #5: DIsegnare linguaggi è difficile e non è poi così scontato che i piu grandi scienziati sono anche fautori che hanno partecipato alla creazione di linguaggi ma nessuno di loro ha mai lavorato nel php. Ma lo sapete che su internet ci sono piu siti che fanno blaming sul PHP che quelli che ne descrivo come fare del codice fatto bene? Ci sono piu siti che infamano PHP che siti porno no questo non è vero...
• #6: E poi tutti che ai accaniscono con tutti i linguaggi
• #8: Ma è veramente cosi schifoso? Diciamo che ha i suoi difetti
• #9: facebook, wikipedia wordpress ci hanno fatto un impero yahoo è mezzo in php, non so se siete mai andati a visitare Youporn beh youporn è fatto in PHP con symfony2. Il php è qualcosa di veramente terribile?
• #10: Il php è usatissimo … il PHP è economico è veloce. Il linguaggio è la sua comunità, in effetti il php è migliorato grazie a Symfonu, buone pratiche disaccoppiamento nelle conferenze gia da alcuni anni si è iniziato a parlare di metodologie TDD /BDD /DDD.
• #11: Il miglior linguaggio di programmazione non vi salvarà dallo scrivere codice di …. orribile
• #13: Si ma questa frase ad effetto non ha significato perche: che vuol dire linguaggi terribili che vuol dire great application che vuol dire talented coders? Quindi andiamo capire come essere dei talented coders per scrivere bellissime applicazioni ------------------------------------------- Ecco il titolo. “talented coders can write great applications in terrible languages”
• #15: Già il nomed ‘coders’, scrivere codice eh… ma scrivere poi è la parte piu piccola, ci metti 3 mesi per corteggiare il cliente, ci metti i mesi di giorni per capire il cliente, ci metti mesi per far capire al cliente l’Agile, ci metti mese per far capire al cliente cosa veramente ha bisogno, se poi ci aggiungi i giorni di imprecazioni per capire il codice che hai scritto nell’iterazione prima, il tempo per scrivere i test prima di fare codice, pensare a cosa fare… scrivere codice è il 10%, spendi piu tempo Mi piace la definizione che da il libro managment 3.0: I developer sono knowledge workers provvedono a soddisfare il business con un valore che prima non avevano.
• #16: L?innovazione come benzina per la crescita, programmatori ma anche azienda
• #17: portatore di conoscienza
• #18: Ma chi sono i talented developers scrivono usando TDD Chi sa cosa è il TDD? Chi di voi programma usando il TDD? Chi di voi vorrebbe ma in azienda non glielo permettono? Chi di voi prende in giro chi sta in una azienda in cui non gli permettono di usare TDD?
• #19: IL TDD è un processo dello svilupppo, che risiede su ripetizioni brevi, kent beck[1] Beh il TDD è una metodologia che scientificamente ti porta a scrivere codice modulare, di certo non deve essere sottogamba perche è stata un grande rivoluzione ma nemmeno deve presa come dogma o legge o come unico modo per raggiungere il codice modulare, quello che è certo che DEVE essere utilizzata almeno fino a che non ci si rendo conto che porta ad un beneficio reale. stavo cercando di descrivere qualitativamente un great developers
• #20: - Code fast - Connected code - No Version Control System - Lazy, closed to learn - Flat languages or old frameworks - His/Her code is secret - Superb - No Passion - Solution Driven Development - Community silos seniority Alla fine essere bravi coder vuol dire dare il giusto bisogno al business, quindi non essere ossessionati da una tecnologia, agire senza pregiudizi, non essere incarcerati, non adattare la soluzione alla tecnologia. E’ problematico se siamo ossessionati dal linguaggio non cerchiamo più di trovare un prodotto di valore per il cliente ma adattiamo la tecn. cosa stiamo facendo come sviluppatori? Il valore non è fare un sito in drupal ma dare qualcosa di valore per il cliente.
• #21: L?innovazione come benzina per la crescita, POssiamo definire i talented coder come: programmatori ma anche azienda
• #22: Quindi per essere un talented coders si …. Si ma come soddisfare il business? beh lo step è capire il business, Soddisfare il business è difficile è difficilissimo, non se vi è mai capitato che nel primo giorno di analisi il product owner cerca di ottimizzare il suo tempo dicendovi e cercando di dire tutto, beh mi è capitato e la sera mi sentivo cosi:
• #23: Quindi se dopo anni abbiamo capito che magari il codice è meglio scriverlo incrementale, abbiamo anche inziato a capire che il business si comprende incrementalmente? Se durante la stima dei costi vi si avevano presentato un pianeta, nel primo giorno di incontro è un universo.
• #24: Quindi affrontiamo il business nel primo giorno si presenta cosi vi vedete voi? si siete li, intorno piano a piano si crea il buco nero detto della consapevolezza e iniziano ad apparire pian piano le galassie presentate come pianeti o come satelliti.
• #25: Ci sono varie tecniche per capire quale galassia prima affrontare, scoprire prime le difficoltà etc, per poi andare a capire i pain points. ci sono varie metodologie per capire il impact mapping per allineare l’overall business objectives and make better roadmap decisions.
• #26: A questo punto si prende un problema e si inizia a descrivere per sviluppare il software MA una applicazione è fatta da software e hardware, tutti e due sono molto importanti, ma quando il software ci parla dei loro problemi noi dobbbiamo evitare: errori di traduzione contaminare il linguaggio del business con tecnicismi che non appartengono al dominio. se noi riuscissimo a scrivere del software seguendo il linguaggio del business, seguendo i comportamenti del business riuscremmo ad evitare le frizioni che si hanno generalmente tra gerghi tecnici (programmatori/product owner). L’informatica è la parte che si deve adattare al gergo tecnico del business, deve aderire al modello. quindi dovremmo disegnare la nostra applicazione defindendo bene diversi livelli, il dominio è quello dove c’è la logica, le costrizioni gli eventi le regole e gli oggetti del modello del business. è lo strato piu interno dovremmo iniziare a modellare l’applicazione partendo da quello non pensando a come implementare il database, dobbiamo solo seguire i comportamenti.
• #27: A questo punto si prende un problema e si inizia a descrivere per sviluppare il software MA una applicazione è fatta da software e hardware, tutti e due sono molto importanti, ma quando il software ci parla dei loro problemi noi dobbbiamo evitare: errori di traduzione contaminare il linguaggio del business con tecnicismi che non appartengono al dominio. se noi riuscissimo a scrivere del software seguendo il linguaggio del business, seguendo i comportamenti del business riuscremmo ad evitare le frizioni che si hanno generalmente tra gerghi tecnici (programmatori/product owner). L’informatica è la parte che si deve adattare al gergo tecnico del business, deve aderire al modello. quindi dovremmo disegnare la nostra applicazione defindendo bene diversi livelli, il dominio è quello dove c’è la logica, le costrizioni gli eventi le regole e gli oggetti del modello del business. è lo strato piu interno dovremmo iniziare a modellare l’applicazione partendo da quello non pensando a come implementare il database, dobbiamo solo seguire i comportamenti.
• #28: lo strato di applicazione è quello che contiene l’orchestra degli oggetti di dominio, muove gli oggetti di dominio, il terzo strato è quello di interfaccia di presentazione che decora i casi di uso i comandi che appartengono allo strato precedente. Se vedete bene tecnicamente lo strato di presentazione vede solo comadi non vede il dominio. The inner-most layer is the Domain Layer. This layer contains your business logic and defines how the layer outside of it can interact with it. Business logic is central to your application. It can also be described as 'policy' - rules your code must follow. The domain layer and its business logic define the behavior and constraints of your application. It's what makes your application different from others. It's what gives your application value. If you have an application with a lot of behavior, your application can have a rich domain layer. If your application is more of a thin layer on top of a database (many are!), this layer might be "thinner". Quando pensiamo al dominio NON dobbiamo pensare ai dettagli implementativi il database dopo. l’Application è lo strato che fa muovere le entità del dominio nei diversi stati. Just outside of the Domain Layer sits the Application layer. This layer orchestrates the use of the entities found in the Domain Layer. It also adapts requests from the Framework Layer to the Domain Layer by sitting between the two. For example, it might have a handler class handle a use-case. This handler class in the Application Layer would accept input data brought in from the Framework Layer and perform the actions needed to accomplish the use-case. It might also dispatch Domain Events raised in the Domain Layer. This layer represents the outside layer of the code that makes up the application. -............. Quindi vogliamo seguendo questa notazione andare a sviluppare un esempio pratico di come dare il bisogno al business partendo da una storia. Il modello esponde metodi pubblici e comportamenti delle classi che sono aggregati, eventi etc L’applicazione espone richieste e casi di uso Lo strato esterno decora ed esponde al cliente nel formato scelto. QUini vogliamo un linguaggio che sia aderente al business che ci guidi nello sviluppo, be è proprio il linguaggio del business.
• #30: Mappiamo ogni step in una funzione php cosi da unire le funzionalità ai test automatici. Immaginate di avvicinarvi ad un cliente o il vostro capo, fatelo partecipare il piu possibile alla scrittura delle storie scrivete esempi, quindi Gerghin, quando inziate pensate a quale business value, gerghin a business driven readable language, funziona come documentazione, ma anche guida automatic test, descrive il comportamento del software, quindi scrivendo le storie condividendo le storie con il cliente, si condividono le responsabilità.
• #31: vi ricordate il tdd? scrivete il test, create la classe e la funzionalità test verde e ricominciate? beh qui è diverso, ….
• #32: Mappiamo ogni step in una funzione php cosi da unire le funzionalità ai test automatici.
• #33: Mappiamo ogni step in una funzione php cosi da unire le funzionalità ai test automatici.
• #34: Mappiamo ogni step in una funzione php cosi da unire le funzionalità ai test automatici.
• #35: Mappiamo ogni step in una funzione php cosi da unire le funzionalità ai test automatici.
• #38: Il miglior linguaggio di programmazione non vi salvarà dallo scrivere codice di …. orribile
• #39: Follow the business.
• #40: No prejudice