Italian Agile Movement

Uncovering better ways of developing software

Finelli & Nusco

Visualizzazioni: 13

Allegati:

Rispondi

Risposte a questa discussione

Come ha detto qualcuno, gli strumenti non sono mai colpevoli. Sono le persone che ne fanno un uso sbagliato. Io ho visto persone (non oggi) peraltro certificate JCP che formalmente ti giurano sul Refactoring come se fosse la bibbia e poi ti scrivono classi di 4000 righe (e come nel caso della stored procedure di oggi non è un numero messo a caso ma purtroppo una triste realtà).

Quindi... innocente su tutta la linea!
Abusare della credulità popolare è fortunatamente un reato :)

Assolutamente colpevole!! :))
Voglio tentare un parallelo:
il denaro secondo voi e' colpevole di tutti i mali del mondo ?

Il Signor Relazionale e' come il denaro:
- indispensabile per vivere
- abusa tutti i giorni della nostra credulita'
- ci fa credere che con lui si possa fare tutto
Tutti lo vorrebbero eliminare, ma tutti ne hanno necessita'.

Con lui si fanno cose molto giuste e cose molto sbagliate, ma quando giudichiamo queste cose giudichiamo indirettamente le persone che lo usano.

Io da quando lavoro non ho mai fatto stored procedure, forse perche' amo troppo la flessibilita' del linguaggio di programmazione, ma forse alcune volte avrei fatto meglio a farle ...

Qualsiasi altra cosa al suo posto, oggi, non ci potrebbe dare maggiori performance, maggiore flessibilita' e maggiore semplicita'.

ASSOLUTA INNOCENZA !!!

Complimenti!
Sul discorso che gli strumenti non siano mai colpevoli non sono tanto d'accordo. E' evidente che sta alle persone utilizzarli e sceglierli con senno (right tool for the right job) ma è anche vero che alcuni di questi siano intrensecamente più complessi e peggiori di altri.

Francesco Carucci ha scritto un bell'articolo sul linguaggio da utilizzare per chi si avvicina al mondo della programmazione e voglia imparare e sostanzialmente si sconsiglia C (apriti cielo lo so ma io concordo :D).
La responsabilità va ripartita quindi.

Dei DB non si può fare a meno ma evidente che in molte situazioni lo si utilizzi con la filosofia "è il meno peggio" perché non ce ne sono di migliori visto e considerato che i tentativi di avvicinarli alla filosofia OO con gli ORDBMS sono falliti direi piuttosto miseramente, almeno finora...in ogni caso la foto del giuramento su Refactoring la dovete uppare :D
Per mia esperienza personale, nelle grandi telecom/banche assicurazioni ecc.., quasi sempre le stored procedure e altre feature più o meno proprietari del database server relazionale sono fondamentali nelle componenti più business critical delle loro applicazioni. Ho visto una pletora di applicazioni di banking, trading online, accounting, billing ecc...dove alla fine la transazione $vera$, quella cioè che genera revenue, è fatta con uno strato di stored procedure. La mia opinione personale è che in molti casi si trattata di una scelta sensata se non addirittura l'unica possibile. Queste soluzioni sono antitetiche al pensiero di chi ritiene che "un'applicazione fatta come dio comanda non ha bisogno di contaminazioni con le feature extra del RDBMS", però, agganciando in parte lo speech di apertura dell'Agile Day, hanno un forte sostegno dall'esperienza e quindi una robusta connotazione pragmatica, e sicuramente non sono agili.
le risposte cambiano man mano che la tecnologia si evolve.
i relazionali erano il futuro nel '90.
ora sono una tecnologia matura che aiuta ma inizia a mostrare molti limiti.
il futuro sara' differente, penso a qualcosa di piu' simile agli attuali CMS, sicuramente ad oggetti.
Ma oggi, per dati critici, non ci sono molte altre soluzioni.
Credo che anche il DB ricada ormai tra le componenti "dogmatiche" di un qualsiasi progetto. Lo scenario complessivo è rimasto sostanzialmente fermo da anni (linguaggi ad oggetti da un lato, e RDBMS dall'altro) e ciò ha permesso di sintetizzarlo in due o tre regoline (non sempre applicate bene per la verità) che permettono di fare un'applicazione buona per "tutte le stagioni".

Credo che anche solo il fatto di cominciare a porsi la domanda "Il DB relazionale è la migliore implementazione della persistenza per questo progetto?" sia un elemento di pragmatismo e di maturità architetturale. Credo che come ci si sta ricominciando a guardarsi attorno per quanto riguarda i linguaggi di programmazione, sia inevitable iniziare a farlo anche sul problema della persistenza, ampliando un po' il raggio di esplorazione.

E' però vero che in molti casi i problemi di un progetto possono essere pronosticati fin dai primi giorni, semplicemente osservando il comportamento del DBA e/o dell'architetto...
Purtroppo non son riuscito a seguirlo.

Qualcuno l'ha filmato ?
Io chiedo come regalo di Natale che venga postata la slide de "Lì 3 Layeri".
detto, fatto! la trovate in allegato al primo post di quest thread. Nel prossimo futuro ci sara' anche il video :-)
Grazie Mille.. "Lì 3 Layeri" è un capolavoro che non può mancare nella mia bacheca.

A mio avviso è stata una sessione divertente ma al tempo stesso interessante, che ha messo in evidenza come il DB relazionale sia al giorno d'oggi uno strumento che "o lo si odia, o lo si ama".
Di sicuro, un'analisi E/R mette in luce molte problematiche che è opportuno affrontare in fase di progettazione: sull'implementazione vera e propria della base dati invece, talvolta può essere "pragmaticamente" conveniente apportare denormalizzazioni o introdurre dei concetti di business logic che solo con uno strato di programmazione è possibile monitorare.
Ad ogni modo complimenti a tutti gli "attori" di questa sessione, vincitori e vinti, nessuno escluso.
Argh! purtroppo non ho potuto seguire la presentazione! In generale pero' direi che se gli sviluppatori sono creduloni va a loro demerito, non a demerito dei tool :)

Cio' detto, ritengo che l'algebra relazionale e il linguaggio SQL siano stati l'ultima vera innovazione che l'informatica abbia prodotto.

ASSOLTO PERCHE' IL FATTO NON SUSSISTE!

Quasi quasi intento una causa per calunnia! :))

Ste

RSS

© 2012   Creato da Marco.

Badge  |  Segnala un problema  |  Termini del servizio