Categoria:develop

Usare o non usare un Framework?

Stasera ho avuto una interessante conversazione con un amico sull’opportunità o meno di utilizzare un framework di sviluppo (o una o più librerie, come ad esempio JQuery e Bootstrap di Twitter) per la realizzazione di applicazioni.
Da questa semplice premessa è iniziato uno “scontro tra titani”: da una parte il mio amico, che difende la modalità di sviluppo completamente “da zero”, realizzando da zero tutte le funzionalità necessarie per lo sviluppo dell’applicazione (comprese le funzionalità ancillari, come un DatePicker JavaScript ed un framework di validazione dell’input utente JavaScript, ad esempio), dall’altra c’ero io che ovviamente difendevo la modalità di sviluppo che prevede l’utilizzo di framework o librerie di terze parti.
Chi difende la modalità di sviluppo “da zero” porta a sostegno della propria tesi alcune motivazioni come:
  • Estrema personalizzazione: il software fa esattamente quello per cui è stato progettato, massimizzando le performances;
  • Leggerezza: essendo il codice sviluppato estremamente minimale ed estremamente personalizzato, non c’è nemmeno “un byte” di troppo rispetto a quanto necessario;
  • Controllo: si è assolutamente certi di cosa il codice sorgente faccia, senza doverlo controllare e verificare;
  • Conoscenza: risolvendo in proprio ogni problema, si aumenta la propria “conoscenza di base”, entrando nel merito ed analizzando ogni singolo piccolo problema che si può presentare;

Dall’altra parte, ovviamente, chi difende la modalità di sviluppo basata su software di terze parti, porta altre motivazioni:

  • Rapidità di sviluppo: utilizzando framework o librerie già pronte, si accorciano notevolmente i tempi di sviluppo (cosa che rende intrinsecamente più competitivi, potendo offrire al cliente dei tempi di sviluppo minori e conseguentemente minori costi di sviluppo);
  • Riusabilità: un proprio snippet di codice sviluppato utilizzando un framework standard può essere facilmente riutilizzato in un altro progetto, senza alcun o con pochissime modifiche;
  • Evitare di perdere tempo “reinventando la ruota”: non si perde tempo a risolvere per ogni progetto una problematica già affrontata e risolta da tempo, magari da decine di sviluppatori, arrivando ad una soluzione largamente accettata e condivisa, che ormai può essere data quasi per “scontata”;
  • Aderenza agli standard: l’uso di framework e librerie ampiamente diffusi rende facilmente condivisibile e manutenibile anche da persone terze il proprio codice sorgente, per la standardizzazione della sintassi e la necessaria adozione delle best practices che con il tempo di sono venute a creare;
  • Accrescimento personale: imparando a sviluppare con framework diffusi comporta implicitamente un accrescimento personale ed una “maggiore rivendibilità” dello sviluppatore sul mercato del lavoro;
  • Concentrarsi sul reale obiettivo del progetto: non dovendo investire parte del proprio tempo a risolvere problemi ancillari, si può massimizzare i propri sforzi sull’analisi delle problematiche per la quale l’applicazione è in fase di sviluppo, magari investendo parte del tempo nella ricerca di qualche algoritmo particolarmente efficiente o innovativo per la problematica in oggetto;

E voi, cosa ne pensate?
Sviluppate tutto “da zero”, oppure preferite appoggiarvi a framework e librerie già pronti? Fatemi la vostra opinione.



SQL: calcolare i totali progressivi

Molto spesso, durante le analisi dati richieste dai clienti, viene richiesta l’elaborazione dei totali parziali, per riuscire ad avere facilmente una idea dell’andamento progressivo dei dati.
Purtroppo nella definizione SQL standard non esiste un operatore per questo tipo di calcolo: alcuni database, come SQL Server di Microsoft, offrono una implementazione proprietaria (attualmente lo statement COMPUTE, nelle prossime versioni sostituito da ROLLUP, una sorta di “GROUP-BY”) ma se la nostra esigenza è quella di mantenere una compatibilità cross database, oppure se stiamo lavorando con un database che non supporta questo tipo di operatori, come possiamo risolvere il problema?
Supponiamo di avere una tabella Orders, così definita:
CREATE TABLE [dbo].[Orders](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [OrderID] [int] NOT NULL,
    [OrderDate] [date] NOT NULL,
    [Amount] [money] NOT NULL
)
Come possiamo estrarre i dati, calcolando il totale complessivo?
Utilizzando questa SELECT:
select O.OrderID,O.OrderDate,O.Amount,
    (select SUM(Amount) from Orders where ID<=O.ID) AS RunningAmount
from Orders O
“It’s a kind of magic!!!” O forse no? 🙂
Il campo “RunningAmount” è definito come una subquery all’interno delle query principale, che effettua la somma di tutti i valori contenuti nel campo Amount aventi come ID un indice inferiore o uguale all’ID della riga corrente.
Semplice, rapido e funzionale… e sopratutto, valido per tutti i database, senza doversi appoggiare a “fastidiose” estensioni proprietarie.



Notazione ungara: un bene o un male?

Visto il successo ed i numerosi attestati di soddisfazione circa l’ultimo post di “programmazione teorica” (Linguaggi di sviluppo: tipizzazione forte o debole?) ho pensato di dare seguito ad una serie di post che affrontino alcuni aspetti della programmazione forse meno conosciuti o poco discussi, ma con i quali ogni programmatore si trova giocoforza prima o poi a doversi confrontare.
L’argomento di discussione di oggi è la notazione ungara (o notazione ungherese) della varibili, ossia quella convensione usata in programmazione, secondo la quale nel nome della varibile è necessario indicare il suo tipo.
La notazione è stata ovviamente pensata per essere indipendente dal linguaggio ed è stata molto utilizzata nei vecchi linguaggi come il VB6 i quali, non supportando la tipizzazione forte (vedi post precedente per i dettagli sull’argomento) anche se non è mai stata ratificata alcuna specifica ufficiale circa i prefissi da utilizzare, generando quindi un po’ di anarchia.
Alcuni esempi:
  • lngCount: numero long
  • strTemp: stringa
  • hwndWindows: handle di una finestra
  • bFlag: variabile boolean
Come si diceva poco sopra, la notazione ungara è stata a lungo diffusa tra i programmatori dei linguaggi senza tipizzazione forte, perchè di ausilio durante le fasi di scrittura del codice perchè si aveva immediatamente sott’occhio, nel nome della variabile stessa, il suo tipo, aiutando quindi a prevenire triviali errori di cast.
Il mondo informatico è comunque sempre stato spaccato circa l’utilità della notazione ungara ed anche parecchie personalità importanti (come Linus Torvald) si sono schierate contro:
Inserire il tipo della funzione nel suo nome (la cosiddetta notazione ungara) è una scemenza: il compilatore conosce comunque il tipo e lo può verificare, e l’unica cosa che fa è confondere il programmatore. Non stupisce che la Microsoft [che usa questa notazione] faccia programmi difettosi.
Personalmente ho sempre trovato la notazione ungara troppo “pesante”, il codice diventa di difficile lettura oltre che di difficile manutenzione: si ipotizzi ad esempio di avere un contatore che dal tipo Int deve passare ad un tipo Long, per questioni di dimensioni: non sarà sufficiente, volendo continuare a seguire la notazione ungara, semplicemente cambiare il tipo della variabile ma sarà anche necessario rinominarla, operazione che, anche con l’ausilio di un editor avanzato che supporti il renaming automatico delle varibili, richiederà comunque un certo tempo mentre invece, se non si dispone di un editor di questo tipo, sarà necessario operare manualmente, con tutti i rischi ed i possibili errori di regressione che una operazione del genere potrebbe introdurre.
Voi cosa ne pensate? Pro o contro notazione ungara?