Font per la programmazione

Ho recentemente scoperto che esistono tutta una serie di font specialistici per la scrittura di codice.

http://hivelogic.com/articles/top-10-programming-fonts/

Il loro intento è quello di favorire la leggibilità soprattutto di quei caratteri che nei font tradizionali risultano essere simili tipo: 1, l, I, o (lettera o), 0 (zero).

Sicuramente ne scaricherò e ne proverò qualcuno. Per ora sto usando il sempreverde Consolas.

Voi cosa usate?

Advertisements

I bravi programmatori battono i tasti

Vi è mai capitato di iniziare un a progettare software e poi durante l’implementazione ci si ritrova a ridiscutere o modificare grosse parti dello stesso? A me capita e spesso mi rendo conto che:

  • La soluzione iniziale era troppo complicata o prevedeva cose insensate;
  • Sto reinventando la ruota, forse c’è qualcosa che posso scaricare/riutilizzare.

Nella quotidianità c’è un feedback molto stretto tra l’implementazione e la progettazione. Per la mia esperienza di solito vanno pari passo e molta progettazione viene fatta durante l’implementazione.

La conclusione a cui sto arrivando è che forse cominciare a scrivere codice dopo aver pianificato troppo ha la stessa utilità che scrivere codice senza pianificazione alcuna.

È probabile inoltre che nel mondo software non sia possibile fare una progettazione completa (esempio con UML), consegnarla a sulla scrivania a un programmatore e avere l’aspettativa che il lavoro si completerà con successo. È improbabile riuscire a progettare un’applicazione per il mondo reale interamente su fogli di carta e poi cominciare a farla. Fare dei prototipi via via che il progetto prosegue è utile per raccogliere informazioni sulla fattibilità, le performance e problemi a cui non si era pensato.

Se vogliamo essere bravi sviluppatori dovremmo sempre prendere decisioni basate sui fatti e sull’esperienza. Una stretta relazione tra implementazione e progettazione permette tutto ciò. Se vogliamo essere bravi sviluppatori, che ci piaccia o meno, dobbiamo darci una mossa e battere tasti per scrivere quel dannato codice.

Compilare un database

Secondo Grant Fritchey costruire un database significa:

In application development, we build a working application from its constituent parts, compiling it in the correct order then linking and packaging it. The ‘build process’ will do everything required to create or update the workspace for the application to run in, and manage all baselining and reporting about the build.

Similarly, the purpose of a database build is to prove that what we have in the version control system – the canonical source – can successfully build a database from scratch. The build process aims to create from its constituent DDL creation scripts and other components, in the version control repository, a working database to a particular version. It will create a new database, create its objects, and load any static, reference or lookup data.

Since we’re creating an entirely new database, a database build will not attempt to retain the existing database or its data. In fact, many build processes will fail, by design, if a database of the same name already exists in the target environment, rather than risk an IFEXISTS...DROPDATABASE command running on the wrong server!

Ma cosa ce ne facciamo di una database build? Se voglio dare un database di sviluppo a una persona nel mio team non mi basta fare un backup e un restore nella sua macchina? Certo ma non è solo questo l’unico scopo di costruire un database da zero in maniera replicabile alla pressione di un pulsante.

Che vantaggi porto a casa?

Gli immediati vantaggi che la compilazione corretta di un db porta sono:

  • Controllo di salute dello schema del db: tutti gli oggetti sono validi e non fanno riferimenti a cose inesistenti;
  • Si può (deve?) automatizzare il processo. Così dopo ogni modifica dello schema di cui viene fatto il commit in un VCS parte la compilazione del database e verifica se abbiamo rotto qualcosa;
  • Automatizzando il processo si possono automatizzare dei test sul database;
  • Automatizzando i test si comincia ad avere un sistema automatico di controllo qualità del database.

Combinando quindi un database compilabile con un paio di altri strumenti possiamo ottenere quello che per le applicazioni esiste già da decenni, cioè un Database Lifecycle Management strutturato e automatizzato.

Voi avete implementato il DLM per vostro database? Il mio è corso d’opera e farò dei post per spiegare come l’ho ottenuto.

 

Tu sei il tuo peggior nemico

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be-

– Jeff Atwood

Per quanto Jeff “Coding Horror” Atwood possa essere a volte schietto e brutale penso che sia difficile contraddirlo in questo contesto.

Il miglior codice di tutti è nessun codice.

Abbiamo tutti le migliori intenzioni quando scriviamo codice ma poi ogni riga di ciò che scriviamo deve essere debuggata, deve essere capita, documentata ecc…

Facciamo al mondo un favore, se possiamo scriviamo meno righe di codice possibile.

Il desktop non è la destinazione

Sono molto ordinato nel mio desktop. Se fossi altrettanto ordinato nelle faccende domestiche la casa sarebbe in perfetto ordine (o quasi).

cattura

Per come la vedo io il desktop è un passaggio rigorosamente temporaneo per documenti / immagini / appunti in attesa di essere smistati il più velocemente possibile nella loro destinazione finale. Il desktop non è la destinazione finale. Perché? Perché il desktop non lo si vede quasi mai quando si sta veramente usando il computer in maniera produttiva. Vedere pixel del desktop significa sprecare spazio su schermo. Proprio per questo fatto mettere icone nel desktop è inutile perché non le si vede mai.

Allo stesso tempo e contraddicendomi spendo molto tempo nel cercare di abbellire il mio desktop con immagini ad alta risoluzione e di qualità, soprattutto per la postazione 4k in ufficio. Trovo piacevoli e rilassanti gli sfondi di paesaggi ma soprattutto del cielo azzurro con qualche nuvola. Mi piace iniziare il lavoro con un desktop accogliente, una bella immagine da osservare che può ispirare la giornata. Il desktop è come un vezzo estetico che mi dà soddisfazione anche tra i cambi di contesto quando finisco un’attività. Bello, pulito e ordinato lo fisso qualche secondo con soddisfazione prima di passare al compito successivo.

Le mie fonti per i wallpaper sono:

Se siete già partiti alla ricerca di un nuovo sfondo per il vostro desktop bene, attenzione però a non vederlo troppo spesso! 😉

P.S.: se vi siete invece messi a riordinare quel mare di icone che vi ripromettete di sistemare da mesi questo articolo sta avendo più successo del previsto e voi state facendo un’utilissima attività!

I test sono per le persone

State scrivendo test automatizzati per alcune parti del vostro codice in produzione. Congratulazioni! State scrivendo i test prima di scrivere il codice? Ancora meglio! Già fare ciò vi fa rientrare tra gli avanguardisti delle pratiche di ingegneria del software. Ma state scrivendo buoni test? Come si può dirlo? Un modo è chiedersi, “Per chi sto scrivendo i test?” Se la risposta è “Per me, per evitarmi di correggere bug poi” o “Per il compilatore, così possono essere eseguiti,” allora è possibile che non stiate scrivendo i test migliori possibili. Quindi, per chi dovremmo scrivere test? Per le persone che cercano di capire il vostro codice.
I buoni test servono anche da documentazione per il codice che stanno testando. Descrivono come il codice funziona. Per ogni utilizzo i test:

  1. Descrivono il contesto, il punto di partenza e le precondizioni che devono essere soddisfatte;
  2. Illustrano come il software viene chiamato;
  3. Descrivono i risultati attesi con le post-condizioni che devono essere verificate.

Le persone che cercheranno di capire il vostro codice dovrebbe guardare un paio di test, e confrontarli con le tre sezioni appena descritte e trovare in ciò una guida.

Progettare il rilascio

Provare e debuggare il processo di rilascio è spesso rimandato alla fine di un progetto. Nella mia esperienza, finora, non ho nemmeno mai visto progettare e/o pensare un processo di rilascio/installazione. Quello che ho sempre visto è il programmatore/consulente di turno compilare il programma col suo PC e con un processo manuale (copia-incolla-cambia stringa nel file config-fai un update nel database) portare a conclusione il deployment.

giphy.gif

Siamo nel 2016 ed esistono mille tool/software che svolgono egregiamente questo compito introducendo automazione e riducendo il rischio di errore (cazzo il file di configurazione punta al database di test!).

Penso che sia un punto critico da affrontare perché questo processo è il primo che un cliente nuovo vede e dovrebbe essere affidabile (o al limite facile da aggiustare).

C’è un progetto in azienda che è nelle sue prime settimane di vita e potrebbe essere interessante inserire proprio qui una progettazione anticipata del rilascio e dell’installazione.

Immagino che per avere un processo di installazione efficace dovremmo dotarci di:

  • Un ambiente (virtual machine o reale) che simuli una postazione utente con niente installato dove installare e configurare l’applicazione di turno;
  • Un altro ambiente che simuli un server pulito dove testare una installazione di SQL Server via riga di comando e con file di configurazione con successivo script di creazione e inserimento dati di base nel db;
  • Possibilità di resettare questi ambienti a piacimento (snapshot delle VM?);
  • Testare il processo di aggiornamento automatico della postazione utente.
  • Usare strumenti il più semplici possibili per concludere queste attività.

Suggerimenti?