Newsgroup: it.lavoro.informatica
Titolo: IT for dummies

 
 
Mannagger dell'azienda Scacciavitari &C., un rozzone arricchito con
vaghissime nozioni di informatica, fa riempire un questionario ai suoi
sottoposti, per sapere quali siano le loro conoscenze e per capire come
meglio sfruttarli nel call center / help desk...
 
[ ] Linguaggio SQL
[ ] Linguaggio Java
[ ] Linguaggio C
..
[ ] Linguaggio HTML
 
e così via (tralasciamo i commenti sulla dubbia utilità e correttezza di
questi strumenti).
 
Raccoglie i questionari, li analizza e poi indice una riunione, alla
quale si presenta piuttosto incazzato.
 
Mannagger "Ma come è possibbile che nisciuno ha messo la crogetta sul
'Linguaggio C'? E' innaccettabbele!"
 
Ad un breve silenzio di circostanza segue una timida domanda:
 
Sottoposto "Ma perché te lo sai il C?" (nonostante la forte gerarchia,
si danno del tu)
 
Mannagger "Eh! Certo! Ho letto il libro!" (*)
 
(*) Il K&C si presume
 
Commenti sopiti nelle retrovie... "Eh, sì anche io ho letto le poesie di
Bukowski, ma non è che adesso so scrive le poesie..."
 
M.

 (*) Il K&C si presume
 
 
che sarebbe?
 
 

Tex Willer ha usato la sua tastiera per scrivere :

http://www.amazon.it/linguaggio-Principi-programmazione-manuale-riferimento/dp/887192200X/ref=sr_1_2?ie=UTF8&qid=1352459057&sr=8-2
 
 
 


Sarebbe che mi sono sbagliato: K&R
 
M.


Penso intendesse "Il K&R"...
 

On 09/11/12 12.12, Mau C ha scritto:

Eh si vede che neanche tu conosci il C, altrimenti lo avresti saputo!
 
:PPPPPPP
 
G.
 

 (*) Il K&C si presume
 
 
che sarebbe?
 
 

Sostituendo il manager ad un laureato in (ingegneria) informatica, che è un
soggetto diverso dall'Ingegnere o Dottore nella mia personale classificazione
avendo si questi ultimi si il titolo _MA_ anche i neuroni operativi, una
peculiarità biologica sempre più rara e recessiva. La versione IMO diventa:
 
Non conosci il PHP!? Non sei innamorato di Java!? Con la stessa faccia ed
irritazione nervosa del manager di Mau C...
 
Tempo fa mi capitò un soggetto simile, brava persona, all'inizio di un 
dottorato, teoricamente studioso ecc. mi disse tutto contento che una delle
novità di non so che compilatore Microsoft faceva il type-check dell'SQL
hard-coded in C#&c "questo si che è un compilatore". Alla mia risposta:
"questo si che è un prodotto da CANCELLARE, non si deve MAI hard-codare
query, porte, ip, nomi dns ecc!" s'è gelato e c'è voluto un bel po' per
fargli intuire che qualcosa nella sua idea non era granché.... Un'altra mi
capitò con un prof di reti che in teoria lavorava pure in un'azienda a tema:
chiese "un programma" che via tcpdump/wireshark facesse alcune statistiche
su un file cap sniffato da chissà dove. Presentato uno scriptino perl con
graphviz disse stupito: "Ma io il perl non lo conosco! Fallo in C++!" alla
controrisposta: "a parte che il data-munging in C++ è un bagno di sangue
sono sostanzialmente delle exec*/system, il lavoro lo fa tcpdump e graphviz"
la sua risposta restò: "io il perl non lo conosco, non capisco se i grafici
che sputa il tuo coso sono giusti o sbagliati!".
 
Poi ci si lamenta che le cose vanno male...

 (*) Il K&C si presume
 
A parte che è K&R (però penso che sia un refuso tipografico, per cui per questa volta non sparo), in effetti a mia memoria arrivare in fondo al libro per me è stato abbastanza pesante (*). Certo, retrospettivamente gran libro, c'era tutto dentro, però effettivamente dire di averlo letto è già un bel passo.
 
(*) ricordo ad esempio la fatica che ho fatto per capire il concetto di union; oggi mi vien da ridere, ma era decisamente distante dal mio modo di pensare.
 
-- 
Ciao!
Luca
 

 query, porte, ip, nomi dns ecc!" 
 
Oh bella, sul resto son pure d'accordo, ma perché le query no?
Aggiungo: probabilmente si riferiva a Linq (che in effetti non è affatto un brutto concetto).
 
-- 
Ciao!
Luca

 ha scritto:

Oh cazzo!!! E' il libro mastro dell'informatica!!!
 

 ha scritto:



 è già un bel passo.
 
beh non è che sia un romanzo con una trama che deve appassionare. il 
pregio principale di quel libro, come di altri testi di riferimento, è 
quello di esprimersi con formalismi corretti. sicuramente il concetto di 
union sarebbe stato ancora più ostico comprenderlo se spiegato in modo 
più "leggero".   
ricordo ad esempio un caso eclatante di un confronto che feci fra il k&r 
e un testo della collana shaum sulla spiegazione degli operatori logici: 
ebbene quest'ultimo si dilungava per pagine in modo discorsivo, per 
carità piacevole da leggere, ma in nessun punto faceva riferimento alla 
regola della short-circuit evaluation. quindi uno legge il secondo, pensa 
di aver tutto cristallino perché è spiegato con parole semplici, salvo 
poi scoprire (forse) che gli mancano nozioni fondamentali.
 

 più "leggero".   
 
Condivido totalmente. In effetti, almeno secondo me, è un testo esemplare non tanto per il contenuto ma per il 'come'. Ne ho letti molti altri, ma nessuno, nemmeno quelli storici di Stroustrup o di Grogono, sono riusciti ad arrivare allo stesso livello.
 
Per quanto mi domando se questa 'esemplarità' non sia legata anche al fatto che, almeno da un punto di vista formale, il C è un linguaggio 'semplice'.
 
-- 
Ciao!
Luca

 ha scritto nel messaggio 
news:201211101...@mynewsgate.net...

si,
ma era un po' provocatoria e un po' retorica,
è il K&R, non il K&C
 
 

 poi scoprire (forse) che gli mancano nozioni fondamentali.
 
Concordo. Meglio non capire niente alla prima e pure alla seconda
lettura di un testo impegnativo (*), piuttosto che pensare di aver
capito tutto avendo invece solo appreso concetti parziali
 
(*) si spera che alla terza lettura le cose diventino chiare  :-)
 

 Oh bella, sul resto son pure d'accordo, ma perché le query no?
 
Perche' se devi cambiare la query (magari per metterci un campo in piu' o
magari per aggiungerci "AND a > 12") e l'hai inchiodata nel codice, poi la
devi ricompilare, e tu sai, vero, quale e' la trafila burocratica da fare
ogni volta che ricompili ?
 
Se non te la ricordi te la ricordo io:
 
- si va da quelli del Cofiguration management e gli si chiede di
"scongelare" il codice (3 giorni lavorativi da pagare al Configuration
management)
 
1 - si esegue la correzione in ambiente di sviluppo (1 giorno lavorativo)
 
2 - si rieseguono tutti i test (o almeno quelli di non regressione) in
ambiente di sviluppo, in ambiente di test, in ambiente di collaudo e in
ambiente di certificazione: n-mila giorni di lavoro (e, come ben sai, a
parte l'ambiente di sviluppo, quelli di test, di collaudo e di
certificazione, implicano avere disponibili anche altre aziente, oltre
alla tua e quindi l'allocazione di tutta una serie di persone (diciamo m
persone) di k aziende diverse per gli n giorni di attivita' dei test)
 
3 - si deve passare la palla a quelli che fanno il deploy in produzione (e
magari provare a fare qualche test anche in produzione)
 
4 - si  rimanda il software da congelare al configuration management.
 
5- se ti chiedono qualche modifica alle query: si ricomincia da 1.
 
Invece se la query l'hai configurata da qualche parte, invece di fare
quanto sopra, si telefona al sistemista (o meglio gli si invia una email
o, al massimo, gli si apre un ticket) e gli si dice: "mi cambi la query ?"
 
 
Ciao,
Marco.
 
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 


 
Direi che il sistema di rilascio ha qualche problema. Se per il rilascio
di un applicativo si segue tutta una trafila burocratic-burocratica, se
per una quesry che potenzialmente ha la stessa possibilita` di generare
bachi orribili si apre un ticket e basta quello, allora esiste un
problema nelle procedure di rilascio.
 
Come puoi essere sicuro che la query in produzione non si metta a
cancellare dei record che non dovrebbe se non hai fatto dei test?
 

 cancellare dei record che non dovrebbe se non hai fatto dei test?
 
Ovviamente qualche test si rifa' anche in quel caso, ma in genere e' una
cosa che fa il sistemista da solo, visto che eventuali problemi possono
essere presenti solo nella query e non nel codice, che non e' stato
ricompilato. 
 
Per altro: non e' la stessa cosa che nel caso degli IP ? 
Perche' gli IP non li inchiodi nel codice ?
 
Ciao,
Marco


 ?"
 
ah, quindi la modifica la fai praticamente a caldo sull'ambiente di 
produzione, senza il minimo test e senza paracadute. il minimo errore di 
battitura tuo o del sistemista e partono i fuochi d'artificio...
roba per stomaci forti, direi.
 

 Perche' gli IP non li inchiodi nel codice ?
 
razzismo? :)
potrebbe essere una esigenza concreta, magari perché è un dato che 
dipende dall'ambiente di esecuzione del programma.
 

 ogni volta che ricompili ?
 
Marco, sinceramente io vedo due casi possibili:
 
1) la query fornisce dati che poi vanno consumati dal codice che in qualche modo deve farne uso; in questo caso è inevitabile, se hai qualche ragione per modificare la query allora DEVI modificare anche il codice, per cui la trafila che descrivi è inevitabile;
 
2) la query viene semplicemente invocata, perché magari fa un trasferimento di dati da una tabella a un'altra; in questo caso, e solo in questo il codice, che deve conoscerne solo il nome, non deve essere modificato, per cui la trafila può essere evitata.
 
-- 
Ciao!
Luca

 Perche' gli IP non li inchiodi nel codice ?
 
LA SO, LA SO!!
 
Gli IP sono una configurazione, non delle scatole cui tu butti dentro qualcosa per avere in cambio qualcosa d'altro.
 
Voglio dire: e' ovvio che la configurazione di un server LDAP cui accedere è una cosa che va messa esterna. Però facciamo un caso pratico preso dal mio lavoro.
Io, in un'applicazione, devo visualizzare dati tabellati. Supponiamo che mi si richieda di visualizzare, oltre al nome utente, anche il suo uid. Qui devo inevitabilmente modificare la query che costituisce la vista logica di supporto, ma come minimo devo anche modificare il backend che fornisce i dati e il frontend che quei dati presenta. Devo rifare tutte le verifiche in ambiente di test? certo che devo rifarle!
 
-- 
Ciao!
Luca
 
 

 dipende dall'ambiente di esecuzione del programma.
 
Puo' essere.
Ma (in parte) vale anche per le query. Quando lavoravo alle poste, avevamo
una query che selezionava i primi m numeri di telefono di utenti che
avevano ricevuto piu' di n SMS/giorno e inviava una email ad un
"responsabile" nel caso in cui questo evento si verificasse.
Sostanzialmente era un "wathchdog" per verificare che non ci fossero
utenti che si "sparavano" k-mila SMS/giorno per ricaricarsi la
SIM.Inizialmente avevamo fissato m ed n=5 pero' poi ci siamo accorti che
era meglio lasciare n ed m come "configurabili" (oltre ad altri parametri)
perche' si e' poi visto che n=5 era troppo basso, visto che molti utenti
ricevevano normalmente piu' di 5 SMS giorno per quel servizio. Quindi n ed
m andavano "tunati" con l'applicazione in esercizio (quando l'abbiamo
messa su la prima volta non avevamo idea di quanto sarebbe stata
utilizzata).
 
Che si fa, si ricompila ogni volta che vogliamo cambiare n ed m ?
 
Si preferi' mettere la query in un file esterno (per altro era una query
in puro SQL standard, non una stored procedure o altre cose che prendono
parametri da codice: veniva banalmente letta dal codice ed eseguita,
magari con qualche controllo sul fatto che qualcuno non avesse sostituito
select con delete).
 
La verifica del fatto che l'email arrivi correttamente al responsabile
dopo avere eventualmente modificato la query la puo' fare il sistemista
lasciando andare tutta l'applicazione, non solo provando la query, 
aggiungendo magari se stesso in copia al responsabile a cui viene inviata
l'email.


rootkit ha scritto:

Dove lavoravo io Il sistemista dell'ambiente di esercizio era anche
sistemista dell'ambiente di test, anche se magari non sempre questo accade
(anzi credo che da quando sono venuto via le cose da questo punto di vista
siano cambiate). Decideva lui se fare prima una prova in test e poi in
produzione (in realta' dipende. A volte le modifiche ai file di
configurazione in ambiente di test le facevo direttamente io e poi, se le
modifiche sembravano funzionare, gli mandavo direttamente i file da
mettere in produzione, ma diciamo che la procedura teoricamente corretta
sarebbe quella di passare sempre dal sistemista)
 
Ciao,
Marco
 
-- 
Per i lavoratori a bordo dei cacciabombardieri non esistono sabati, ne'
domeniche. Mai un momento di pausa.
"Per costruire 12 ospedali servono 250 milioni di dollari, quel che ci
costano 8 ore di guerra in Iraq...si prendessero un giorno di ferie!".
Gino Strada


 produzione 
 
Per evitare di tornare anche su questo punto: ovviamente la procedura
corretta e' di fare le prove prima in ambiente di test e immagino che le
facesse ("decideva lui" significa solamente che se si occupava lui di
entrambi gli ambienti senza che partecipassi io, non so di preciso come
procedesse, visto che non c'ero).
 
Ciao,
Marco
 
 
-- 


 
 
<cut>
 
Domanda: ma quella era un sw house o un ministero?
 
Nelle varie sw-house che conosco o dove ci lavorano amici:
 
1) se qualcuno propone una cosa del genere "el paron" della sw house ti
prende a fucilate;
 
2) con in genere le modifiche da consegnare per ieri, sta sicuro che
qualche passaggio si salta di sicuro;
 
3) quando il cliente ti chiede una modifica del genere, come gli
giustifichi la fattura di 8 ore invece di una? In altre occasioni mi
sono sentito dire: "Ma come tutto sto tempo, si trattava solo di
aggiungere un if codice = 'pippo'". E allora vagli a spiegare che la sua
richiesta per coerenza andava gestita in altri punti del programma, che
il pippo andava parametrizzato ecc.
 
4) in alcuni casi, quando a creare una situazione di test ci vuole
troppo tempo, si passa direttamente il programma in produzione e si
invita il cliente a fare una prova.
 
Sinceramente, ho sempre sentito parlare di analisi, scrittura della
documentazione, testing ecc. Ma in poche occasioni ho visto implementare
decentemente l'analisi ed il testing. Di solito:
 
a) cliente chiede la modifica al capo;
b) il capo riferisce al programmatore quello che ha capito ("a volte" il
punto a e b avvengono solo telefonicamente);
c) il programmatore fa la modifica e la consegna al cliente;
d) il cliente dice che voleva tutt'altra cosa;
e) il cliente si mette ad urlare con il capo;
f) il programmatore parla direttamente con il cliente;
g) ripetere i punti da c ad f fino a quando non funziona;
h) il capo chiede: ma come mai ci sono problemi con il cliente?
 
Ad un cliente che si lamentava per le "troppe modifiche successive al
primo rilascio" � stato proposto di fare l'analisi delle loro richieste
(ovviamente a pagamento) e che nel preventivo sarebbe stato conteggiato
il tempo di test. Ha preferito procedere nel modo "consueto".

 Che si fa, si ricompila ogni volta che vogliamo cambiare n ed m ?
 
certo che no, il parametro variabile si mette in un file esterno o una 
tabella. ma il parametro, non tutta la query... 

 roba per stomaci forti, direi.
 
Vabbè, l'errore di battitura o comunque operativo può avvenire in
qualunque attività fatta manualmente. Bisognerebbe proprio eliminare
fisicamente ogni essere umano nella catena. Ma presto avverrà... :-))
 


Aggiungo che, fermo restando di fare tutti i test del mondo, è molto
consigliabile saper cosa fare in caso di malfunzionamento di qualche
rotellina dell'ingranaggio.
Nel caso specifico, potrebbe essere che la query sia una piccola parte
di un programa, il quale a sua volta è piccola parte di una procedura
immensa, con l'immaginabile complicazione di far rigirare *tutti* i
test di integrazione relativi.
La presenza di gente esperta (ed aggiungerei dotata di un minimo di
sicurezza in quel che fa...) evita di ricorrere ottusamente alla
semplice riesecuzione di *tutti* i test per ogni virgola cambiata.

 qualunque attività fatta manualmente.
 
appunto. 


E quindi, non si fa nessuna attività manuale? Al di là del caso della
query, ci sarà sempre un punto in cui qualcuno si deve prendere
qualche minima responsabilità. E' bene rendersene conto.

 1) la query fornisce dati che poi vanno consumati dal codice che in qualche modo deve farne uso; in questo caso è inevitabile, se hai qualche ragione per modificare la query allora DEVI modificare anche il codice, per cui la trafila che descrivi è inevitabile;
 
Non è detto, fai conto un "select... where flag=1" potrebbe essere
cambiato in "... where flag in (1, 12)" e per il programma
potenzialmente non cambia nulla.
 
 

 potenzialmente non cambia nulla.
 
OK, ma riconoscerai che è un caso molto particolare. Io parlavo più del risultato da un punto di vista strutturale, perché cose come qu le hai descritte normalmente io le gestisco con una vista logica, proprio per evitarmi problemi del genere.
 
-- 
Ciao!
Luca
 

 di integrazione relativi.
 
quindi siccome la modifica ha impatto su una procedura immensa e ci 
sarebbero da fare troppi test, la soluzione è... non ne facciamo nessuno.
geniale :P

 il tempo di test. Ha preferito procedere nel modo "consueto".
 
Beh, il rovescio della medaglia e' che quando i clienti sono quelli che
dico io magari un software che un team medio-piccolo sviluppa in 3-4 mesi
costa (o almeno costava prima della crisi) dai 200.000 Euro in su, visto
che, appunto, devi mantenere tutto l'apparato burocratico intermedio.


 E quindi, non si fa nessuna attività manuale? 
 
non certo al volo sull'ambiente di produzione. senza scomodare test e 
metodologie varie credo basti il buonsenso a suggerire che non si tocca 
il codice in produzione al di fuori delle procedure di deploy.

 potenzialmente non cambia nulla.
 
questo non lo puoi dire senza aver valutato il codice. in realtà 
potenzialmente cambia eccome, visto che la business logic nel primo caso 
può assumere che nel resultset ci sia un solo valore per 'flag' mentre 
nel secondo no.
 
in ogni caso in tutto questo c'è una stupidità di fondo. visto che 
l'esigenza è cambiare a runtime i parametri di una query si rende esterni 
i parametri e non tutta la query, magari in una tabella così resta tutto 
in ambito sql. negli altri casi una query sql *è codice* pertanto non si 
capisce perché il rilascio di una modifica debba bypassare le procedure 
di deploy di tutto il resto del codice.  

 A parte che � K&R (per� penso che sia un refuso tipografico, per cui per questa volta non sparo), in effetti a mia memoria arrivare in fondo al libro per me � stato abbastanza pesante (*). Certo, retrospettivamente gran libro, c'era tutto dentro, per� effettivamente dire di averlo letto � gi� un bel passo.
 
 
 
Va bene, � pesante. Che poi � relativo. Il K&R (quello con la C era un
refuso, eh :-) � stato il mio secondo libro, dopo quello del Borland
Turbo Pascal (non mi ricordo pi� se 3 o 4). Lo divorai, perch� in quel
periodo mi ero appassionato al C.
 
La mia critica, insita nel messaggio originale � : non puoi dire di
conoscere un linguaggio soltanto dopo aver letto il libro. Soprattutto
quando chi afferma una cosa del genere � un rozzone che non ha la bench�
minima idea di cosa sia programmare.
 
E' come imparare a nuotare con lezioni scaricate da internet ed
esercitandosi sul pavimento di casa (cit. The Big Bang Theory).
 
M.


Non se sia tanto particolare. La vista la puoi usare in alcuni casi,
mica a tappeto per tutte le select, sennò sai che esplosione di
pezzetti software, che poi vanno gestiti.
Quindi valutare bene la situazione: oggetto software (in senso di
sorgente, non oo)  unico onnicomprensivo, rigido ma chiaro <-> gruppo
di oggetti software coordinati, flessibile ma di gestione più
complessa.

 geniale :P
 
ovviamente ti piace scherzare :-) Quel che dico è chiaro: se cambio un
punto in punto e virgola valuterò quali test vanno fatti. Altrimenti è
meglio che vado a fare un'altro lavoro.
 

 test di integrazione relativi.
 
Il punto non e' tanto questo, quanto il fatto che se tu hai una query in
un file di configurazione e cambi solo quello, sei relativamente sicuro
che se il codice era funzionante prima, sara' funzionante anche dopo che
hai cambiato la query, quindi sembra ragionevole assumere che l'errore
eventuale che si dovesse presentare, possa essere solo nella nuova query
(non e' del tutto vero, sempre se si ammette che sia valida la tesi di
Djkstra, visto che potrebbe essere che la nuova query riveli un errore
presente da qualche altra parte nel codice, errore che non era stato
rilevato dai test eseguiti in precedenza; comunque questa, all'atto
pratico, e' una possibilita' abbastanza remota, almeno nella mia
esperienza e, in ogni caso, si verificherebbe solo nel caso in cui nel
codice fosse presente un errore *gia' prima* che la query venga sostituita
e solo casualmente  quell'errore non si verificava prima della
sostituzione della query)
 
Invece se ricompili il codice non hai modo di sapere se il programmatore
non ha accidentalmente alterato qualche altra parte del programma, oltre
alla query e quindi dovresti rifare tutti i test (anche questi in realta'
non assicurano che l'errore venga trovato, ma sempre meglio di niente).
 
Ciao,
Marco.
 
-- 
Per i lavoratori a bordo dei cacciabombardieri non esistono sabati, ne'
domeniche. Mai un momento di pausa.
"Per costruire 12 ospedali servono 250 milioni di dollari, quel che ci
costano 8 ore di guerra in Iraq...si prendessero un giorno di ferie!".
Gino Strada
 


 di deploy di tutto il resto del codice.
 
Sono d'accordo che la query è codice, ma se la estrai dal programma
ciò che va testato non è solo la query, o solo il programma, ma
l'insieme dei due. Alla fine come la giri la giri, la divisione in
tante parti è solo una comodità, ma ciò che teoricamente dovrebbe
essere verificato è sempre il loro insieme. Questo però è un ottimo
argomento per riflettere bene prima di esternalizzare qualcosa dal
programma.
In effetti se giustamente devo comunque ritestare tutto l'insieme, a
cosa mi serve avere la query appoggiata sulla tabella esterna? A non
leggermi l'intero programma?
Penso che, se si è deciso di parametrizzare qualcosa, questo è
giustificato dalla volontà di non affrontare ad ogni modifica tutta
intera l'onerosa trafila di test completo.
 
 

 tabella. ma il parametro, non tutta la query...
 
Se non sbaglio nel caso specifico, visto che era un watchdog che inviava
praticamente un WARNING a un responsabile, si decise di mettere tutta la
query fuori perche' si disse che se poi si volevano aggiungere altri campi
da inviare al responsabile, oltre ai numeri di telefono, sarebbe stato
sufficiente appunto cambiare la query per selezionare anche gli altri
campi da inviare al suddetto responsabile (anche se e' roba del 2007 per
cui potrei ricordare male)
 
Ciao,
Marco.


 non ha accidentalmente alterato qualche altra parte del programma
 
git diff ?
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

 niente).
 
direi che è abbastanza falso. il modo di sapere se accidentalmente o meno 
sono state modificate altre parti c'è eccome, non solo, hai anche modo di 
accertarti che nel rilascio vada solo e soltanto quella fix.
per quanto riguarda i test: già limitandosi alla ripetizione degli unit 
test sul dao modificato scremi il 99% dei possibili errori introdotti con 
la modifica stessa. 

 git diff ?
 
Di solito chi fa i test funzionali dopo le modifiche al codice e' diverso
da chi sviluppa (spesso sono proprio aziende diverse) e chi fa i test,
teoricamente non ha modo di sapere se lo sviluppatore ha lanciato "git
diff" o meno (e, secondo me, non e' molto corretto che assuma che il
programmatore lo abbia fatto. Dal punto di vista del tester il codice e'
appunto codice ricompilato dopo una modifica. Se il tester assumesse che
il programmatore ha fatto tutto quello che doveva, estremizzando non ci
sarebbe nemmeno bisogno di rifare il test, specialmente quando la modifica
non aggiunge nuove features). Inoltre chi fa i test funzionali potrebbe
non avere accesso al repository del codice.
 
Ciao,
Marco
 
 
-- 


 la modifica stessa.
 
Non dico mica di non fare gli unit test. Ma al solito quelli che fanno i
test funzionali in genere sono diversi da quelli che fanno gli unit test.
Teoricamente chi fa test funzionali puo' essere un'azienda diversa da
quella che produce il codice (era cosi' anche nel caso in esame, almeno in
parte. In altri casi addirittura erano diverse le aziende che facevano i
test in collaudo da quelle che facevano i test in altri ambienti); quelli
che fanno i test potrebbero non avere alcun accesso al repository del
codice per cui, dal loro punto di vista, che il codice sia fatto con DAO o
che sia "spaghetti code" con accessi al DB da tutte le parti poco cambia.
Non credo che sia teoricamente corretto assumere che chi fa i test conosca
come e' fatto il codice.
Viceversa anche chi fa i test in genere sa cosa c'e' nei file di
configurazione e cosa no.
 
Ciao,
Marco


 che chi fa i test conosca come e' fatto il codice.
 
e infatti gli unit test che sono fatti da chi invece il codice lo conosce 
sono assolutamente propedeutici ai test di tipo black box, perché è 
inutile dare in pasto una funzionalità ad un tester se non vi è certezza 
che al suo interno il codice non è stato esplorato in modo sistematico. 
 
detto questo, si torna alla questione precedente: se io faccio i test 
funzionali in staging ma poi disaccoppio la query rilasciando solo 
quella, in questo modo invalido i suddetti test perché in produzione non 
ho lo la certezza di avere stesso assembly che ho testato. tu dirai che 
non è vero e che avrai tutte le attenzioni del caso, ma in realtà se per 
i deploy si fanno sotto forma di package non è solo per perdere tempo. 
 

 Perche' gli IP non li inchiodi nel codice ?
 
Perche` gli IP sono dei paramentri e non vanno a toccare la logica 
di funzionamento (per il resto cambiare a muzzo un URI puo` causare le
peggio cose.
 
 

 peggio cose.
 
In realtà anche per l'IP può benissomo cambiare la logica di
funzionamento. Per esempio se passi da IPv4 ad IPv6 devi per forza
cambiare qualcosa nel codice che lo gestisce.
Il discorso è un altro: è tacitamente accettato da tutti che l'IP sia
un valore che può cambiare con frequenza molto alta, e quindi è molto
opportuno estrarlo dal compilato (*) e metterlo come parametro.
Ma se hai qualcosa che si ritiene non verrà cambiata per la prevista
durata di vita del programma, allora estrarre questo qualcosa dal
codice è assolutamente inutile, e probabilmente pure peggiorativo
nella parte di gestione.
 
(*) Già se non è un compilato ma un interpretato la valutazione può
benissimo cambiare, si potrebbe fare semplicemente un moduletto da
includere dinamicamente che faciliti i cambiamenti delle costanti, ma
senza avere una gestione vera e propria dei parametri
 
 

 nella parte di gestione.
 
direi proprio di no, sopra ho spiegato un motivo dei possibili.

 direi proprio di no, sopra ho spiegato un motivo dei possibili.
 
Al contrario, hai proprio spiegato uno dei motivi per cui si sceglie
di parametrizzare certe cose, ovvero il cambio frequente dell'ambiente
entro la vita del programma. Se non devo cambiare quasi mai l'ambiente
la parametrizzazione non mi serve.
Tra l'altro se voglio adattare il programma a vari ambienti, è molto
probabile che proprio il dbms sia una di quelle cose da poter
modificare "al volo", e quindi istruzioni SQL esterne farebbero molto
comodo. Ma d'altro canto averle compilate nel codice potrebbe dare
migliori performance. Ecco quindi che la valutazione migliore è quella
calata nel caso specifico.
 
 
 
 

 la parametrizzazione non mi serve.
 
per conto mio non è questa la logica. qualsiasi informazione che dipenda
da fattori esterni al programma sarebbe buona cosa che non fossero hard coded,
anche perché non ti è dato sapere se, quando e quante volte cambieranno.  
oltretutto che non si fa una gran figura se, come nel caso che ti ho descritto
sopra, per cambiare un puntamento ad un ip bisogna fare una nuova release...

 dov'è il vantaggio di disaccoppiare questa benedetta query? 
 
Se cambi solo la query, se un sistemista si occupa di sostituire il file
della vecchia query con la nuova query
 
a) e' una cosa che puo' anche fare lui da solo se l'analista funzionale
gliela chiede (e quindi non paghi il gruppo di sviluppo per effettuare
modifiche al codice, visto che modifiche al codice non ce ne sono. Invece
se devi ricompilare paghi anche gli sviluppatori)
 
b) se c'e' un errore nella nuova query il sistemista puo' anche
accorgersene lui e correggere lui (dopo aver chiesto conferma ovviamente)
e quindi non hai bisogno di passare dagli sviluppatori.
 
c) In genere, almeno nella mia esperienza,  procedi molto piu' velocemente
(che puo' essere un vantaggio nel caso in cui un cliente ti metta fretta)
 
Poi, se mi dici che se parametrizzi il 99% di quello che c'e' da
parametrizzare (magari compresi i campi restituiti dalla select, i nomi e
il numero delle tabelle da mettere in join, tutti i parametri della where
clause ecc.), allora in quel caso le differenze tra i due approcci sono
minime posso anche concordare (ma sbaglio o sento gia' la voce di qualche
programmatore che bestemmia :-)? Non so se sia un atteggiamento corretto,
ma sicuramente se si deve rendere tutto parametrico i tempi di sviluppo in
parte si allungano. A me qualche programmatore che chiedeva di rendere
parametrico solo il minimo indispensabile che serviva e' capitato.
Purtroppo spesso capitava anche che si andasse in produzione senza avere
certezze su cosa sarebbe stato bene che fosse parametrico o meno, visto
che si sa che spesso nemmeno il cliente sa prima cosa vorra' cambiare
dopo. E non sempre e' disponibile a pagare dopo quello che non ti ha
chiesto di cambiare prima).
 
Ciao,
Marco.
 
 
 
-- 


 benissimo quali siano i files da ricompilare.
 
Si' ma il tester sa solo che e' stato ricompilato il codice. Non sa come
e' fatto il codice. Non dovrebbe assumere che ci siano "classi" nel codice.
Per il tester il codice puo' anche essere tutto procedurale. Il tester
dovrebbe occuparsi solo di verificare le funzionalita' indipendentemente
da come e' scritto il codice. Se ad uno che fa dei test tu gli porti un
nuovo codice compilato, per il tester quello e' semplicemente "nuovo
codice compilato", indipendentemente dal fatto che sia stata toccata una o
cento classi.
 
Inoltre nel caso che citavo io c'era da fare un tuning in esercizio
(che,se non ricordo male, comprendeva anche "quali campi" avrebbe dovuto
restituire la select i quali campi diventavano quindi a loro volta
parametri). Centro si potra' sempre dire che potrei avere un file di
configurazione dove scrivo una lista dei campi da far restituire alla
query per rendere anche questi parametrici, ma a quel punto, almeno
secondo me, la differenza tra le due soluzioni e' abbastanza minima (visto
che in un caso hai un codice del tipo
 
<leggi la select [ed eventualmente fai qualche controllo che non sia
diventata una delete]>
<esegui la select letta da file di configurazione>
<invia i dati restituiti al responsabile>
 
nell'altro caso hai
 
<leggi i parametri [tra cui i campi da far restituire dalla select, sui
quali campi magari qualche controllo e' bene farlo]>
 
SELECT <lista [o come si chiama] dei campi che hai letto da
configurazione> from <tabella o join fra tabelle> (tabella o tabelle che
eventualmente possono essere anche loro parametriche) where <condizioni
sui parameri letti da configurazione>
 
<invia i dati restituiti al responsabile>


 metta fretta)
 
"velocemente" si possono fare anche i rilasci con tutti i sacri crismi. 
voglio dire, i sistemi per automatizzare la build non sono certo una 
novità: che poi ci sia una burocrazia di mezzo non lo discuto ma è un 
altro problema, oltretutto nel tuo modo mi pare che saltiate tutto a piè 
pari.
 

 sopra, per cambiare un puntamento ad un ip bisogna fare una nuova release...
 
Rimanendo all'IP, dove sto io (grande ente) è vero che cambia con una
certa frequenza, ma mica ogni giorno e neppure ogni mese. Tutto
sommato ponendolo in una  libreria di accesso comune dovresti fare una
release di tale libreria diciamo una volta all'anno, nulla di
scandaloso.
In altri contesti non lo puoi fare, sicuramente.

 di costi (che poi e' da vedere chi paga) per raggiungere l'obiettivo.
 
Indovina. Di sicuro non il cliente.