Con il brand Team Scaling abbiamo affiancato Photosì in questo progetto che prevede l’utilizzo di Micro Frontend per raggiungere obiettivi sfidanti. Scopri di più sul Case Study nel video dell’intervento tenuto per l’Università degli studi di Urbino!
In questo articolo parleremo e approfondiremo un progetto reale, sviluppato dal nostro brand Team Scaling in collaborazione e per conto di Adrias Online, azienda specializzata nella creazione di siti web full responsive e marketing per il mondo del turismo.
Scopri di più!
Esistono molti design pattern nell’OOP, che servono a rispondere a diverse e specifiche esigenze, questi sono divisi in 3 macro categorie principali: “Creazionali, Strutturali, Comportamentali” In questo articolo vi parlerò del pattern Strategy, che è di natura comportamentale. L’obiettivo che si pone questo modello, è di aiutarvi a separare delle strategie dal contesto per rispondere a uno scopo comune. Proverò ad essere “agnostico” sulla sintassi del codice, in modo da rimanere in un contesto teorico…
Questo articolo ha come obiettivo conoscere ed approfondire con alcuni casi concreti riscontrati nello sviluppo quotidiano il testing funzionale di applicazioni Angular 2 eseguito tramite Protractor.
Il test funzionale detto anche E2E (end to end) consiste nel verificare la funzionalità completa di un’applicazione. Al contrario di quello unitario che si prefigge il test di funzionalità atomiche, il test E2E ha come obiettivo verificare che tutte funzionalità lavorino correttamente assieme.
Lo strumento principale utilizzato con Angular è Protractor, un framework di test E2E che viene integrato in applicazioni generate con Angular cli.
Le modifiche da applicare ad un progetto standard per avere più controllo sull’esecuzione dei test unitari tramite karma.
Per chi sviluppa frontend, le questioni relative al testing sono spesso “meno lineari” rispetto al classico approccio TDD dello sviluppo backend. Chi ha avuto occasione di lavorare in angular 2 avrà sicuramente potuto apprezzare angular CLI e gli strumenti che mette a disposizione, soprattutto per il testing.
Nello sviluppo quotidiano ho riscontrato che “ng test”, il comando che ci permette di eseguire test unitari tramite karma, non fornisce la possibilità di scegliere quali test eseguire, cosa che al crescere del numero dei test rallenta considerevolmente l’esecuzione, soprattutto in modalità “watch” rendendo così quasi impossibile un approccio TDD.
Infatti, ci capita spesso di lavorare su progetti frontend molto complessi per i nostri clienti e, nonostante questo tipo di problema, al contempo vogliamo mantenere alti i livelli qualitativi, anche con tecniche come appunto il TDD.
Per ovviare al problema ho perciò applicato le seguenti modifiche al mio progetto angular per avere la possibilità di lanciare e tenere in modalità watch solo i test che mi interessano durante lo sviluppo.
Come tutti sappiamo PHP è stato concepito come linguaggio a tipizzazione dinamica: visto da una parte dello scenario come pro, dall’altra come contro.
Nonostante l’esistenza di diversi linguaggi con tale caratteristica quest’ultima è stata per diverso tempo motivo di critica. E’ chiaro che lo sviluppo con certi linguaggi aiuta a scrivere codice più pulito, ma di certo è difficile affermare che la tipizzazione dinamica sfoci in codice spazzatura.
Così come le critiche a PHP spesso sono incomplete o riferite a codice deprecato, così accade per la tipizzazione; per esempio PHP ha e ha avuto per diverso tempo diverse modalità per trattare con i tipi ed è possibile garantire che uno specifico tipo venga utilizzato in uno specifico punto del codice.
Anche il type hinting è stato utilizzato per molto tempo, anche se in modo incompleto.
Con PHP7 sarà possibile far sì che le funzioni e i metodi accettino parametri di determinati tipi.
Andiamo più nello specifico: i principali RFC del nuovo PHP7 sono fondamentalmente tre:
Molte cose possono mettere un grande progetto fuori rotta: la burocrazia, obiettivi poco chiari, mancanza di risorse, solo per citarne alcuni, ma è l’approccio alla progettazione che determina in gran parte come il software complesso può diventare.
Quando la complessità sfugge di mano il software non può più essere compreso abbastanza bene per essere facilmente modificato o esteso; al contrario, un buon design può dare opportunità su quelle caratteristiche complesse.
Alcuni di questi fattori di complessità nella progettazione sono di carattere tecnico, ma per molte applicazioni non lo sono, la complessità è nel dominio stesso o l’attività commerciale dell’utente.
Quando questa complessità di dominio non viene affrontata nella progettazione, non importa se la tecnologia infrastrutturale sia ben concepita. Un design di successo deve affrontare sistematicamente questo aspetto centrale del software.
In questi casi un ottimo approccio da valutare è proprio il Domain Driven Design.
Programmare in XP è come lo sviluppo con poche pratiche e concetti in più, per esempio i test automatizzati. Comunque come tutto il resto lo sviluppo con XP, a differenza di come può sembrare, è semplice. Ogni concetto di esso è abbastanza semplice a dirsi, tuttavia è metterlo in pratica che diventa più difficile; oltretutto, sotto pressione le “vecchie” tecniche riaffiorano.
Tra alcuni dei concetti come il continuous integration, che riduce i conflitti e pone fine a incidenti e come il pair programming che ha una forza unificatrice nello sviluppo, troviamo il concetto di collective ownership che incoraggia tutto il team a rendere migliore l’intero sistema.
Indubbiamente viene da pensare che sia pericoloso dato che ognuno potrebbe cambiare ogni parte di codice del sistema in ogni momento; oltretutto se non ci fossero i test sarebbe ulteriormente rischioso. Perciò a rendere sicuro il processo vi è la rete di valori strettamente legati di continuous integration, sviluppo guidato dai test, refactoring, small-releases, etc. come in figura.
