Una storia lunga 10 anni



e-xtrategy

blog

hai selezionato  torna al blog webdevelopment

La nostra esperienza con AngularJs: ModulAngular

fedeli alla promessa di qualche post fa siamo stati ospiti del Cowo di Ancona e abbiamo presentato tools e strumenti che, negli ultimi anni, sono stati sperimentati e usati con successo in ambito di enterprise web application.

avere ben chiaro l’obiettivo del nostro progetto per capire se la struttura modulare realizzata che gira intorno al framework AngularJS può dare un valido supporto nella gestione di progetti medio/grandi e di medio/lungo termine.

la struttura presentata deve rispondere a 3 obiettivi:
rispondere al cambiamento riusabile e ritorno dell’investimento iniziale
supportare la dinamicità del team quando i diversi team variano nel tempo, sia nelle figure professionali in gioco, sia nell’effort richiesto
manutenibile resistere nel tempo e alle risorse che man mano diventano obsolute, condivisione del debito tecnico generato

spiccano tra la carrellata di tools e buone pratiche la living styleguide automatizzata con tutti gli elementi presenti all’interno della nostra applicazione.
tale scaffolding è, per lo sviluppatore come lo user designer, un riferimento da cui partire per stilare le proprie funzionalità fino a creare un’interfaccia completa partendo dagli elementi già esistenti ma senza escludere la creazione di altri, sempre discussi e condivisi insieme al team.

da sottolineare le buone pratiche per gestire la struttura file che vanno da una semplice organizzazione per cartelle fino ad arrivare all’utilizzo di Require.js e System.js combinato con l’utilizzo di bower e npm per la gestione delle dipendenze.

altro concetto importante è che in un progetto web di dimensioni medio/grandi è fondamentale implementare un meccanismo di One Click Build per evitare di commettere errori e risparmiare tempo utile per sviluppare nuove features.

abbiamo trattato anche il testing di applicazioni AngularJS sia con Karma per quanto riguarda i test unitari che con Protractor per i test E2E.

Qui la pagina Lanryd dell’evento con tutti i dettagli sui speaker, link alle slide a ai video.

Di seguito il video della serata splittato in due filmati e le slide:

Dal CSSDay 2015 di Faenza

debutta quest’anno, da uno spin-off del jsday, la conferenza dedicata ai front-end developer e al mondo dei css.

venerdì 27 marzo al palazzo naldi di faenza si parte carichi, subito dopo i convenevoli organizzativi, con nove talk seguiti da una folla di professionisti che ha fatto registrare il sold out.

a parte due talk più specifici (uno sui consigli per lo sviluppo su ambiente windows (@pietrobr) e uno sull’email design (@morloi)) il resto dei talk hanno dato spazio a raccolte di best practice, di tool e strumenti di supporto per buona scrittura della parte presentazionale delle nostre interfacce.

ottimi spunti e valide condivisioni delle esperienze dei speaker e di come nel tempo ognuno abbia trovato la propria suite di strumenti e le proprie convenzioni per scrivere css con le seguenti caratteristiche:

  • comprensibile
  • condivisibile
  • manutenibile
  • riusabile
  • scalabile

sono tornato contento con qualche tool in più nella lista e la consapevolezza che si sta affrontando la stessa situazione: il bisogno di lavorare sereni, di testare, di condividere con il resto del team, di costruire sitemi che funzionano e non pagine a se stanti.

unico appunto è che ho avuto la sensazione che la fase di montaggio delle interfacce fosse vista sempre come fase che accade in un preciso momento: dopo la UI e prima dello sviluppo. a parte il talk sulle styleguide di @Fabbrucci in cui si è parlato di MVP, prototipazione e cicli iterativi di sviluppo nel resto dei casi ho intuito un approccio al markup più tosto waterfall. come se il nostro lavoro finisse al momento della consegna del markup allo sviluppatore.

ma il nostro codice non ha necessità di essere condiviso solo tra altri front-end developer. come metto in condizione uno sviluppatore di poter utilizzare gli assets specifici dell’interfaccia?
in che fase del progetto eseguo i test di comparazione? e cosa testo della mia interfaccia quando lavoro sui mock?
una styleguide è utile ma se non è “living” styleguide serve a poco dopo la fase di discovery. e come vengono manutenute le styleguide su progetti che durano mesi e anni? soprattutto, come posso automatizzarne la generazione?
cosa cambia se sviluppo un sito web o un’applicazione mobile web based?
in caso di applicazione modulare come gestisco la logica degli stili per mantenere coerente anche la modularità dell’interfaccia?

tanti temi da trattare e tante domande a cui dare risposta. non resta che segnarsi l’appuntamento del CSSDay 2016 ma nel frattempo proveremo a dare risposte il 29 Aprile all’evento DEV marche organizzato nel cowo di Ancona in cui tratteremo lo sviluppo di front-end su progetti di grandi dimensioni basati su angular.

a presto!

perché utilizziamo angularjs nei configuratori online

ptf_dis_scheda

sempre più spesso ci viene chiesto dai nostri clienti di realizzare dei sistemi che permettano all’utente finale di configurare online un determinato tipo di prodotto, per dare la possibilità di vedere in tempo reale il suo aspetto in una particolare personalizzazione, che sia un sedile a cui è possibile applicare un determinato colore di tessuto, una cucina disponibile in diversi materiali e colori o una porta che possiamo personalizzare con diversi tipi di maniglia.

data l’eterogeneità delle esigenze di ogni cliente, è impossibile utilizzare una soluzione standard e generica che aderisca in pieno agli obiettivi del progetto. con il tempo e l’esperienza, abbiamo selezionato degli strumenti che ci permettono con rapidità di implementare i vari casi d’uso – anche se molto diversi tra loro – in maniera soddisfacente. siamo arrivati a questo risultato utilizzando angularjs, il web application framework sviluppato e mantenuto da google, che ci ha aiutato a creare una single page application in html+css+javascript.

un caso in cui lo abbiamo utilizzato è il configuratore di calzature DIS in cui un utente può personalizzare ogni singola parte di una scarpa e vedere subito il risultato, da diverse angolature.

con la stessa logica abbiamo realizzato un’area del sito winxclub in cui gli utenti registrati possono personalizzare il loro web avatar, modificandone gli occhi, i capelli, il set di vestiti e altri accessori.

in entrambi i casi c’è stata una forte integrazione del configuratore con il backend del sito web attraverso l’utilizzo di servizi REST: nel caso di DIS, una volta terminata la personalizzazione della scarpa, l’utente può effettuare l’acquisto direttamente dal sito (grazie all’integrazione con drupal commerce); per il web avatar di winxclub, sono gli amministratori del sito a gestire da backend i singoli oggetti del guardaroba, in questo caso abbiamo legato al configuratore anche un sistema di in-app purchase, che permette l’acquisto di un item attraverso una moneta virtuale utilizzata all’interno del sito.

sono due casi d’uso totalmente differenti, ma che siamo riusciti ad astrarre e gestire in maniera semplice proprio grazie ad angularjs. se vuoi saperne di più o anche tu vuoi realizzare un configuratore online per il tuo prodotto, contattaci.

jsday & phpday 2014

jsday2014

photo credits: antonio chinnici

la ricerca del “miglioramento continuo” (kaizen) è fondamentale nel nostro lavoro e un modo per migliorarsi è quello di confrontarsi con gli altri.

è con questo spirito che la scorsa settimana (precisamente dal 14 al 17 Maggio) siamo stati a Verona per il doppio evento jsday & phpday organizzato dal GRUSP.  continua…

aggiornati i requisiti di accessibilità

accessibilita

circa quattro anni fa rispolverai i concetti dell’accessibilità ripercorrendola nelle sue tappe di crescita e aggiornamento. sottolineai che nonostante il boom del 2004/2005 l’accessibilità non fu solo una bolla esplosa in quel periodo ma l’approdo di un’etica di sviluppo che sempre più si propagava unitamente agli standard web che stava definendo in maniera sempre più seria come si fa il web e le professionalità necessarie per farlo bene. conclusi con l’allora recente aggiornamento delle WCAG alla versione 2.0 del 2009 dopo la versione 1.0 che risaliva al 1999.

oggi si parla di skills profiles e di layout adattabili, responsività, di fallback e di versioni mobile… tutti termini in voga per dei concetti già noti a certe filosofie di sviluppo (giusto rivisti per i nuovi device di oggi) come spiegai in un altro post in passato. chi pensa che l’accessibilità ancora oggi sia un'”attenzione particolare” applicabile solo in certi casi, si sbaglia di nuovo!  continua…



lavorano con noi

successivo
precedente