Girando sui social mi sono imbattuto in post che mi ha divertito parecchio. Come realizzare il visto di Homer Simpson mediante css.
Questo sicuramente è il lato divertente del mestiere del web designer. Si è messo lì e ha realizzato il tutto mediante l’uso studiato di css applicato ad una pagina html ad hoc.
Mostra però le potenzialità dei css e quello che si può riuscire a fare conoscendoli bene e applicandoli correttamente.
Mi sto occupando della manutenzione di una applicazione Angular nata per dispotici mobile. Con questo scopo sono stati scelti in appoggio al framework una serie di componenti che ricalchino le app, così da permettere la stessa user experience. Tutto benissimo, finché il cliente ha voluto usarlo su dispositivi desktop. Fortunamente non esigente, e quindi lo stesso tipo di componenti e modalità di interazione mobile like è tollerata anche su desktop. Allora dove nasce il problema? Internet Explorer: il principale browser usato sui desktop dal cliente. Ecco qui il dramma. I componenti non sono certificati per IE. E allora scelta iniziale, aggiungere e verificare i vari polyfill per far funzionare in IE. Non è stato semplicissimo e neanche così indolore su alcune cose.
Ora che lo gestisco io, in qualche caso su IE ho notato qualche malfunzionamento lieve, ad esempio ridimensionando la finestra i componenti scompaiono per poi riapparire massimizzandola. Sicuramente fastidiosi anche se non invalidanti.
Però mi pongo il problema e l’idea era veramente di rendere completante differente la parte di usabilità sul desktop. Alternativa scegliere altri componenti che non creino problemi e siano certificati su desktop, vedi ad esempio Ionic.
E’ comunque in ogni caso un lavoro oneroso. Andando comunque a cercare casistiche e suggerimenti per la gestione di questo tipo di situazioni, mi sono imbattuto in un interessante articolo che condivido qui.
Il mondo della programmazione è sempre in evoluzione, e non si finisce mai di aggiornarsi. Alcune cose però hanno più valore di altre. Il singolo linguaggio di programmazione ha un valore relativo, quello con un buon manuale e un po’ di esercizio si impara.
Il valore più grosso è sulle buone tecniche di programmazione, come il design di una applicazione e del codice. Anche qui si parte da delle basi, che poi si possono portare in qualsiasi linguaggio si usi. Indubbiamente certi linguaggi permettono certe funzionalità addirittura facilitano l’uso di certi pattern, altri molto meno oppure non si possono usare.
Dal mio punto di vista chi fa questo mestiere dovrebbe avere letto almeno 4 libri fondamentali, che aprono la mente. Poi chiaramente sta alla coscienza di ognuno prenderli da spunto per migliorare oppure ignorare e continuare come ha sempre fatto.
I quattro libri fondamentali ve li elenco qui sotto.
Clean Code di Robert Martin, dove si danno una serie di spunti su come scrivere meglio il codice, in modo che sia facilmente manutenibile, resiliente e che anche chi viene dopo di te lo possa capire
Design Patterns della Gang of Four. E’ un libro datato, ma ancora attuale ed è dove è cominciato tutto, dove per la prima volta sono stati raccolti e codificati i Design pattern per una buona programmazione.
Refactoring: Improving the Design of Existing Code di Martin Fowler dove si dà una visione di come poter affrontare un refactoring del codice. Esistono due edizioni del volume, quella qui presentata è la seconda edizione: Consiglio comunque anche la prima.
Test-Driven Development: by Example di Kent Beck, dove si parla di testing, della sua importanza e di come possa guidare lo sviluppo del codice. Link su Amazon (non essendo in versione Kindle non c’è l’anteprima come per gli altri)
Questo è il punto di partenza, poi ognuno deve cercare la propria strada. E’ un cammino lungo, in continua evoluzione, ma è anche stimolante. Se non ci piacesse, non avremmo scelto questo mestiere.
Ed ecco che così continuo questo percorso di crescita 🙂
Il titolo è quello originale dell’articolo su Infoq.
Il testing è un importante strumento a disposizione dello sviluppatore. È una questione di mentalità però. Esistono sviluppatori che provano qualsiasi cosa usando un test, perché è semplice e permette di irrobustire il codice controllando qualsiasi algoritmo nei diversi casi. Altri che comunque lo fanno a mano e non se ne rendono conto.
Qui un articolo sulla tecnica del TDD, con il testing spinto al massimo, cioè scrivo il test prima del codice.
C’è anche un progetto di esempio che mostra a passi l’evoluzione del tdd in un progetto. Da provare almeno una volta nella propria carriera, almeno poi si può fare una scelta consapevole.
Qui di seguito un interessante articolo in merito alle posizioni ricercate dalle aziende e per le quali è difficile trovare professionalità.
Molto spesso è difficile trovare persone che siano curiose e che si assumano la responsabilità del lavoro che producono.
Poi molte volte è anche difficile trovare un accordo in merito allo stipendio; spesso si leggono annunci in cui si cerca persone che conoscano lo scibile in campo informatico, ma da assumere in apprendistato.
Questo connubio credo sia uno dei grossi problemi alla base del problema di incontro tra domanda e offerta.
Specie nel campo dell’informatica, di cui mi occupo, ai giovani posso consigliare di continuare a crescere professionalmente, anche se nell’azienda in cui lavorano non ce la si fa. Nel mercato del lavoro vale la TUA professionalità, competenza e serietà. Una azienda che è disposta a riconoscerlo la troverai e allora lì si potrà costruire qualcosa di bello.
Ecco il link dell’articolo da cui è partita la riflessione.
Uno dei problemi per chi si trova alle prime armi con angular è come poter utilizzare versioni diverse della cli.
Un punto fondamentale è quello che la cli DEVE essere installata a livello globale per poter funzionare. Quindi a livello globale si installa e tiene aggiornata alla versione con cui si vuole lavorare.
Nel caso in cui si abbia un progetto che usa una versione antecedente angular riconosce la versione e la continua ad utilizzare. Il problema da gestire è solo la creazione di nuovi componenti mediante le procedure della cli.
Per poter utilizzare anche la cli, si può procedere andando a sostituirla con la versione voluta a livello globale, oppure una soluzione secondo me più pulita anche se più complessa, andare ad utilizzare la copia locale di angular.
Qui un interessante articolo che indica passo passo le procedure che ho citato e lo mostra con degli esempi