Newsgroup: it.lavoro.informatica
Titolo: [Flame Oriented] Cari Sviluppatori

Perch� non seguite le linee guida quando sviluppate?
 
E sopratutto,quando il vostro applicativo va in errore, perch� chiedete di 
cambiare l'infrastruttura, invece di cambiare il vostro applicativo
seguendo 
le regole che tutti rispettano ?
 
perch�? perch�? perch�? la chiamer� michele perch�?
 
 
 
-- 
cambFORZAJ...@liVIVAMILANbero.it
 
togli le due bestemmie per scrivermi.
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 Perchï¿½ non seguite le linee guida quando sviluppate?
 
Solo che ora mi racconti da cosa arriva questo tuo grido di dolore, perbacco!!
 
Ciao!
Luca

 Perchï¿½ non seguite le linee guida quando sviluppate?
 
Poco tempo? Richieste assurde? Cambiamenti di specifiche a poco dalla consegna?
 
Al3x

 Perchè non seguite le linee guida quando sviluppate?
 
per lo stesso motivo per cui voi sbofonchiate, deridete e infine 
sistematicamente cassate i requisiti hardware di un software quando vi 
vengono fatte le richieste :)

 le regole che tutti rispettano ?
 
Perch� � pi� facile gettare la croce addosso ai sistemisti, invocare 
macchine sempre pi� potenti per cpu e memoria, aumentare le macchine nel 
cluster piuttosto che fermarsi, capire, ragionare e trovare la soluzione 
applicativa !
 
Soluzione applicativa che spesso c'�, � davanti ai nostri occhi ma non 
la si vuola seguire. Mi � capitato proprio una caso il mese scorso, 
volevano duplicare due macchine in produzione affinch� una ditta potesse 
fare dei lavori di estrazione dei dati... andando a sviscerare il 
problema � bastato aggiungere un utente applicativo con gli appositi 
grant di accesso e poco pi�....
 

 perch�? perch�? perch�? la chiamer� michele perch�?
 
perch� i matti son dappertutto sia da un lato che dall'altro! :-)
 
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/
 


Ti rammento che il sistemista non è responsabile del budget :) Il 
sistemista sistema, con quel poco o con quel tanto che gli viene messo a 
disposizione.

 perchè i matti son dappertutto sia da un lato che dall'altro! :-)
 
bello comunque lo scontro sistemisti contro sviluppatori... è la prima 
volta che mi trovo in questa mischia :)
 
La mia ultima diatriba con gli sviluppatori riguardava la configuazione di 
log4j.
I log venivano ruotati in base alla dimensione.
E' arrivata una richiesta precise di conservare i log per l'intera 
giornata.
Invece di rompere le -> OO <- a me, richiedendomi di fare strani calcoli 
per prevedere la dimensione dei log nell'arco di una giornata, e in base a 
questi calcoli stabilire a quanti MB ruotare i log, caro e pur caro 
sviluppatore, perché non riconfiguri il dannato log4j in modo da impostare 
un rotazione a tempo, che va *sicuramente* a coprire l'arco dell'intera 
giornata?
 
Risposta dello sviluppatore: log4j non lo può fare.
Risposta del sistemista (che non è nato ieri): tiè qui link e la 
documentazione che ti spiegano come fare.

 perch�? perch�? perch�? la chiamer� michele perch�?
 
qualche esempio ?
Scrivendo un po' di SQL 'come dio comanda' il tempo di esecuzione un job 
schedulato passa da120 minuti a 15 minuti.
Se la gente smettesse di fare select * (asterisco!!!) per ogni cazzo di 
query che gli capita sottomano, il mondo sarebbe migliore
Se avessi potuto dare un pugno a tutti gli scrittori di select nidificate  , 
oggi sarei un pugile professionista.
 
...
 
in sintesi : perche' non sono capaci. E dare la colpa ai server , alla RAM, 
alla rete, al dominio, (e negli ultimi anni a vmware, alle cpu virtuali, 
alla 'latenza' e ai tempi di wait) e' piu' facile.
 
Andrea
 
 

 virtuali, alla 'latenza' e ai tempi di wait) e' piu' facile.
 
beh qualche elemento dell'infrastruttura un po' di colpa ce l'ha, non 
dico quelli che hai citato (almeno non sempre) ma, per esempio, gli 
"inconvenienti" che hai descritto direi che hanno un database con nome e 
cognome :) 

 disposizione.
 
se vabbe'...il sistemista e' come l'omino delle pulizie !..:-)
 
ciao
fm 
 
 

 le regole che tutti rispettano ?
 
E perchè no? L'infrastruttura è intoccabile peggio di Garibaldi? :-)
Fermo restando che le regole vanno seguite, come qualcuno ha
giustamente detto talvolta si è costretti a passarci sopra,
tipicamente per motivi di tempo. L'unica accortezza è chiedere sempre
il placet dei capi supremi, facendo presente il problema.


non sono capaci o non hanno voglia...
 
Il cosidetto metodo della "scrivania a bilanciere":
qualunque problema viene passato ad altri ...
Dovrebbero essere stipendiati come centralinisti.
 
ciao
fm
 
 
 
 
 
 
 
 
 

 disposizione.
 
lo stesso, a maggior ragione, si applica alla programmazione. no?

 il placet dei capi supremi, facendo presente il problema.
 
Puoi chiedere il placet di chi vuoi, ma le risorse sono "finite", se per 
deficienza degli sviluppatori hai bisogno di 8 vCPU e 120 GB di ram, 8 
volte tanto quanto mi hai chiesto in origine, io potrei NON AVERLE 
disponibili !!!
 

 ed infine realizzata secondo le richieste di tutti.
 
Allora, allora. Vero, 90 volte su cento gli sviluppatori fanno male il proprio lavoro.
Però l'infrastruttura un minimo deve evolvere col tempo. In questo preciso istante sono in difficoltà perché un cliente, presso cui dobbiamo rilasciare un nostro applicativo scritto con Python e allineato alla versione 2.6 (quindi, sicuramente non l'ultima novità, è stato rilasciato nel 2008) ha il server aziendale Debian che a bordo ha Python 2.5 (mi pare, se non inferiore). 
 
Fortuna esistono i server virtuali...
 
-- 
Ciao!
Luca
 


Colleghi che se ne fregano, per cui è inutile che lo faccia anch'io (e 
faccio pure brutta figura perché ci metto più tempo di loro)?
 
Superiori che non sono certo in grado di apprezzare?
 
 
 
Ciao!! Buona giornata.
---
none^none

 Fortuna esistono i server virtuali...
 
E fortuna anche che su una stessa macchina Linux si possano senza 
problemi installare diverse versioni di Python, senza che queste 
facciano a botte. :-D

 
Ecco, Luca, il discorso si fa interessante...
 
Il cliente ha python 2.5, tu (è un tu generico) hai sviluppato per 
python 2.6.
 
Se il software è un "pacchettizzato" è ovvio che il cliente, se lo 
vuole, deve adeguarsi...
 
Se il software è stato uno sviluppo "ad-hoc" forse il software andava 
scritto per python 2.5... o comunque bisognava parlarsi prima... non credi ?
 
L'abuso (sottolineo ABuso) di macchine virtuali come soluzione a tutti i 
possibili problemi degli sviluppatori non può essere giustificato sempre 
e comunque, cioè non può essere sempre la scorciatoia per coprire i 
buchi di una mancata pianificazione o di un mancato controllo durante la 
fase di scrittura del codice o di fornitura dei dati da parte di entità 
esterne.
 
Non è possibile sentirsi dire:
"senti, per quella elaborazione ti avevamo chiesto 15 tera di spazio ma 
ci hanno dato immagini ad altissima risoluzione e l'elaborazione 
occuperò 170 tera... non ci sono problemi, in caso andiamo a comprare 
dei dischi esterni da 3 giga... costano 100 euro..." (per la cronaca, 
sarebbero almeno 52 dischi esterni, senza alcuna forma di ridondanza dei 
dati)
 
Puoi risolvere questo problema con una VM ?
 
 

 L'abuso (sottolineo ABuso) di macchine virtuali come soluzione a tutti i 
 
Appunto, hai detto abuso... :D
 
-- 
Ciao!
Luca

 facciano a botte. :-D
 
Lo so, ma chi lo gestisce preferisce darmi un server virtuale. Perché? mistero...
 
-- 
Ciao!
Luca


IMVHO son braccia rubate all'agricoltura ...
 
Fagli avere un preventivo per uno storage di buona qualità,
da 170 tera ridondati ... e poi vediamo se non ci sono problemi ..:-)
 
 
Ciao
fm
 
 
 

 scritto per python 2.5... o comunque bisognava parlarsi prima... non credi ?
 
Giusto, è proprio tutto qui. Se il software è un pacchetto il cliente
deve *lui prima* preoccuparsi delle specifiche sistemistiche, e
valutare se gli conviene prendere il pacchetto dovendo cambiare
l'infrastruttura. Se non lo fa si arrangia, e purtroppo è vero che ci
va di mezzo il sistemista.
Se il software è ad hoc neppure c'è da discutere.
 

 disponibili !!!
 
Che vuol dire? Si può sempre espandere e potenziare l'architettura
hardware e sistemistica. Ovviamente roba non banale nei casi di grossi
Ced, roba che richiede mesi, ma è sempre un'opzione. Certo se mi stai
dicendo che arriva un tizio che vuole far girare un singolo programma
o poco più e ti lascia la lista della spesa, *DOPO* aver già
realizzato il software, penso che costui è matto e pericoloso,
chiamate la neuro :-)
 
 
 

 chiamate la neuro :-)
 
Entrambe le cose: previsioni errate per imperizia nell'analisi, errate 
per imperizia nello sviluppo del software, esigenze *improvvise e 
urgenti* per le quali il software deve andare in produzione oppure 
manager che volutamente nascondono lo sviluppo di nuove applicazioni per 
evitare la trafila burocratica e poi con la motivazione dell'urgenza 
estorgono VM...

 documentazione che ti spiegano come fare.
 
ahaha solitamente gli sviluppatori sono pigri e spesso hanno sorgenti 
schifosi e meno vengono modificati e meno casini succedono, cmq questo 
era un caso strano ma log4j non ha un file di config? poteva 
impostarselo anche il sistemista! :-P
Esistono anche dei "sistemisti" che ragionano allo stesso modo non 
aggiornano nulla per paura di incasinarsi i server lol
 
Una cosa che mi fa arrabbiare (io sono programmatore) a me è tipo che il 
software a volte è talmente messo male che per es. funziona solo su 
macchine veloci se sono troppo lente si incartano i thread non safe o 
qualche altra porcheria (robe dell'altro mondo) e spesso si opta per 
aggiornare l'hw e non sistemare il software, perchè ci vuole troppo 
tempo. -.-


 chiamate la neuro :-)
 
Il nostro budget IT è triplicato negli ultimi 3 anni (ente pubblico), 
ovviamente la valanga di denaro non è ricaduta su chi lavora (almeno non
su 
chi lavora come operativo)
 
-- 
cambFORZAJ...@liVIVAMILANbero.it
 
togli le due bestemmie per scrivermi.
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 volta che mi trovo in questa mischia :)
 
 
Che poi si sa, [TROLL MODE] I sistemisti sono dei gran fighi e gli 
sviluppatori sono degli sfigati [/TROLL MODE]
 
;)


 schifosi e meno vengono modificati e meno casini succedono, 
 
nei miei programmi il log4j.properties sta insieme agli altri file di configurazione fuori dal jar/war/ear di programma, così che chi gestisce i log se lo sistema per conto suo. questo non per pigrizia ma perché non ha alcun senso che per modificare una impostazione sui log debba fare una nuova build.
 
 

 estorgono VM...
 
Però un conto è "l'esigenza superiore per cui tutto deve passare in
secondo piano", questo è un male di cui la responsabilità non è dello
sviluppo nè del sistemista, che la subiscono entrambi.
Altra cosa è la previsione errata per analisi superficiale e sbagliata
delle risorse richieste da un applicativo, qui parteggio decisamente
per i sistemisti.
 
 

 sviluppatori sono degli sfigati [/TROLL MODE]
 
 
http://atomictoasters.com/wp-content/uploads/2011/09/world_as_seen_by.png
 
 
 

Fulmy(nato) ha scritto:

Stampata ed appiccicata in bella vista in ufficio ;)


 disposizione.
 
Non volevo rispondere, ma visto che mi tirate per i capelli (che non ho):
 
ma secondo te il programmatore e' respnsabile del budget ?
 
Per altro, nei posti in cui ho lavorato io indovina le proporzioni di
budget a disposizione del "reparto sistemisti" e quello a disposizione del
"reparto programmatori".
 
Ora rispondo anche alla domanda di Morpher.
 
Ciao,
Marco
 
-- 


 le regole che tutti rispettano ?
 
Quali regole ?
E poi, se tutti le rispettano, come ha fatto il software ad andare in
errore ?
 
In ogni caso, tu lo sai, vero, cosa vuol dire cambiare anche una sola
linea di codice ?
 
Vuol dire:
 
a- "scongelare" il software che era stato consegnato al configuration
management (in Ericsson il costo minimo di questa operazione era pari a 3
giorni lavorativi da pagare al configuration management e questi il
software te lo consegnavano effettivamente tre giorni dopo che glielo
avevi chiesto)
 
b- riscrivere il codice. Operazione per la quale, se effettivamente e' una
linea di codice, viene richiesta 1 giornata lavorativa.
 
c- rifare *tutti* i test (perche' tu, ovviamente, non puoi sapere gli
effetti di quella modifica, fino a quando non hai rifatto i test), con i
conseguenti costi di allocazione di tutte le risorse umane (programmatori,
tester, sistemisti) e inumane (i test vanno fatti sia in ambiente di
sviluppo che in ambiente di test che in produzione). Il costo dei test
dunque si duplica, ogni volta che tocchi il codice. E queste attivita' di
test, in genere coinvolgono anche i sistemisti (che quindi, infrastruttura
o no, in genere "hanno da lavora'")
 
d- rifare il deploy dell'applicazione, con il costo conseguente
 
e- se qualcosa non va, ripetere tutti i punti b,c,d,e
 
f- riconsegnare il software al configuration management con altri costi
 
g- varie ed eventuali.
 
Se per "modificare l'infrastruttura" intendi che ti hanno chiesto un
aumento del 20% dello spazio disponibile per il DB, forse potrebbe essere
effettivamente la cosa meno costosa


 disponibili !!!
 
Mai visto nessuno che chiede l'allocazione di piu' RAM "a posteriori".
 
Quando sviluppavo, sviluppavo in C e se il software si mangiava la RAM era
chiaro che c'era qualche problema con i puntatori (al che, alcuni
[non dove lavoravo io] hanno avuto l'ottima idea di inventarsi la "linea
guida": sviluppa in C, ma non usare i puntatori, che e' un po' come dire:
guida l'automobile, ma non usare mai la frizione)
 
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


 ed infine realizzata secondo le richieste di tutti.
 
tutti chi? :)
alla fine l'infrastruttura la si progetta per far girare il software, che 
sia il mio, il tuo o quello di un altro.
 
che poi a dirla tutta bisognerebbe anche raccontare di quando entrano in 
azienda i consulenti oracle, quelli che come fanno annusare al server i 
loro dvd pagati come fossero oro zecchino i requisiti hardware aumentano 
di una manciata di giga di ram e un paio di core... :)

 
Marco,
tu citi un caso specifico che dimostra come l'allocazione di spazio sia 
ridotta arbitrariamente rispetto a quelle che sono le previsioni.
Poi parli di giga, una unit� di misura ancora "gestibile" facilmente.
 
In altro messaggio parli di linguaggio C, linguaggio dove un errore di 
gestione della memoria lo paghi con un bel dump.
 
Immagina invece ora uno sbaglio dell'ordine dei tera... non lo puoi 
gestire facilmente...
 
Poi immagina un bel application server java based, con programmi che 
partono e riempiono mega di log di exception ogni *secondo* senza che i 
programmatori se ne accorgano... processi che partono e non rilasciano 
mai la memoria (ma come � possibile !?!?!?) o che succhiano il 100% di 
cpu 24/24h 365 giorni all'anno (366 negli anni bisestili) per 
l'elaborazione di uno scarno file di log proveniente da un'altra 
applicazione....
 
Tutte cose che fanno accapponare la pelle.... ma dove stava in quel 
momento il project manager ? Possibile che non ci sia nessuno che sia in 
grado di guardare i log, fare un top, un check rapido che se un record 
occupa 100 bytes, ne inserisci di 1 milione per test, il fatto che ti 
sparisca una quantit� di spazio disponibile dal file system tripla 
rispetto al preventivato vuole dire che ci sono altri file che vengono 
scritti... file di log !?!!?
 
 
Oppure che se il tuo programma � monothread io te ne posso dare pure 15 
di cpu ma il tuo programma non andr� pi� veloce e che no, non puoi farne 
partire due insieme perch� essendo scritto a cavolo i due eseguibili si 
pestano i piedi a vicenda e ti corrompono i dati nel db...
 

 insomma, alla fine ci mette del suo incasinando...
 
si però se vai a cercare i più rintronati della categoria li trovi anche 
da altre parti eh... giusto un paio di episodi:
 
- cliente $gdo, infrastruttura web basata su tomcat dietro a apache+mod_jk 
mantenuta da $admin. arriva $grosso_fornitore e fa il deploy di un nuovo 
applicativo che, ahimè, ha dei picchi di accesso un po' più degli altri. 
risultato, durante i picchi di accesso si pianta baracca e chicchi. $admin 
comincia ad aggiungere ram al tomcat inveendo contro $grosso_fornitore e 
il suo applicativo presunto "vorace", arriva a raddoppiare l'heap ma la 
situazione migliora di pochissimo nel senso che il tomcat resiste solo 
qualche minuto in più prima di schiattare. vengo coinvolto io in qualità 
di "leva castagne dal fuoco della jvm", in realtà mi basta fare un giro 
con la jconsole e vedere che non è il consumo di ram il problema bensì il 
connettore mod_jk che non glie la fa. al che gli svelo l'arcano: come 
ampiamente documentato la best practice è portare fuori le risorse 
statiche e farle servire con una rewrite ad apache, così non solo 
resuscita il morto ma praticamente riduce ad un quinto le richieste in 
termini di risorse cpu. il problema è che mentre gli dicevo questo $admin 
mi guardava come fossi il mascetti che gli faceva la supercazzola...
 
- stesso cliente, però persona diversa. mentre ero lì che scaricavo roba 
da internet ad un certo punto vedo che il trasferimento rallenta fino a 
fermarsi. faccio notare la cosa e il ragazzo mi fa "ah si, lo so, è squid 
da riavviare. lo fa quasi tutti i giorni". per dirla breve: questi da 
quando hanno installato squid, da almeno 5 anni, non solo non l'hanno mai 
aggiornato, ma si stanno tenendo una versione bacata che per un bug di un 
modulo apre migliaia di processi fino a far piantare il server e ciò 
avviene praticamente una volta al giorno come fosse normale... 
 
quindi, come vedi, se si va a cercare il peggio lo si trova anche 
dall'altra parte :)

 sia il mio, il tuo o quello di un altro.
 
Esatto. Per questo si fanno i piani di sviluppo e si chiede a tutti 
quali sono le previsioni di capacità di calcolo, spazio disco, 
connettività, etc etc per i successivi uno, due e tre anni.
Si fa un elenco, si capisce quali debbano essere VM e quali reali, 
spazio disco, metti un po di tara allargandoti e poi compatibilmente con 
il budget compri, installi, configuri etc.
 
Poi arriva il progetto nuovo o quello con la previsione sbagliata che ti 
erode tutta la tara e anche un po del pianificato...

 
Due begli esempi !
 
Se nel secondo caso hai ragione, il sistemista è da silurare, nel primo 
non so se la colpa andrebbe data tutta al sistemista...  va bhe, questo 
forse rientra in come si è suddiviso il lavoro, nel nostro caso 
l'application server è a carico del fornitore

 Quali regole ?
 
CUT
 
Aggiungerei che non ci sono regole nemmeno per i
commerciali che vendono il loro software senza
cavillare troppo, basta che il cliente apponga la giusta
quantità di firme.
 
Hai fatto l'esempio di grande azienda, io ne faccio
uno di azienda piccola.
 
Nuovo applicativo di rilevazione presenze.
Il modulo software che dialoga con il
lettore di tessere magnetiche  viene
installato(dalla sw house) su un pc gia' disponibile
in azienda (guarda caso su quello
con cpu piu' potente, molta  ram
e disco  veloce)  sul quale ovviamente risiedono
altre applicazioni.
Tale modulo sw deve, apparentemente, solo intercettare le
le letture (max un paio di decine al giorno)
 e scriverle su un file di database.
 
Tuttavia il  pc diventa inutilizzabile:
cpu 100% fisso e l'occupazione di disco si gonfia come ci fosse il lievito.
 
4Gb di ram, cpu intel 3.3Ghz, hd sata da 450Gb 7200 rpm,
per leggere qualche stringa di pochi byte al giorno  dalla RS 232,
 
e processore al 100%   24h x 7gg ...????
 
Cliente: "Come mai questo computer adesso non va piu' ? "
Io: "Il nuovo programma  occupa tutte le risorse della macchina.
Avete chiesto alla sw house in merito?"
Cliente: "Ci hanno detto che e' cosi' ... non si puo' far nulla"
 
Bella Italia, amate sponde.
 
ciao
fm
 
 
 
 
 


lì no, fondamentalmente perché hanno fatto la scelta di condividere gli as 
fra fornitori.
comunque capisco lo sfogo perché di cialtroneria ce n'è veramente tanta a 
giro. 

 Cliente: "Ci hanno detto che e' cosi' ... non si puo' far nulla"
 
si ma qui anche il cliente deve scendere dall'albero. 
 
possibile che su ili il cliente fintanto è un proprio cliente è stronzo, 
non paga, vuole la luna, la vuole per ieri, etc... mentre quando è 
cliente di altri fornitori si fa infinocchiare come un bambino? lì uno 
segnala l'anomalia e fintanto non è risolta niente lilleri, così risposte 
tipo "non si può far nulla" sono estirpate alla radice. c'è qualcosa che 
non va in tutto il modo di girare di questo mondo...
 
 
 

 non va in tutto il modo di girare di questo mondo...
 
dura minga
 
ciao
fm 
 
 

 scritti... file di log !?!!?
 
Per la mia esperienza più volte ho sentito ripetere: prima si crea la
soluzione applicativa "pulita" (da un punto di vista metodologico) del
problema, e poi ci si preoccupa delle prestazioni. E questo lo dice
proprio il PM o team manager, mica l'ultimo povero lavapiatti-
sviluppatore. E così invece di fare, ad es., una select mirata per
acquisire l'unico campo richiesto si fa una bella select * per
costruire l'oggettino standard, con ovvie ripercussioni sulla
prestazione.
Dico questo non per criticare per forza questo approccio, ma perchè
molto di frequente crea importanti problemi, sistemistici ma anche
applicativi. Infatti non è poi sempre così banale modificare un
programma "pulito" per adeguarlo ai vincoli prestazionali.


 pestano i piedi a vicenda e ti corrompono i dati nel db...
 
Quest'ultimo probleme e' abbastanza chiaramente figlio della mentalita':
"il multithreading non si usa e l'accesso in concorrenza al DB non lo
gestisce il programmatore, perche' tanto c'e' il framework che ci pensa
lui a tutto". Mentalita' che, nella mia esperienza ha preso sempre piu'
piede negli ultimi anni (ormai se usi multithreading ti guardano come se
tu fossi un primitivo abitante delle caverne che rifugge da ogni
modernita')


 erode tutta la tara e anche un po del pianificato...
 
Appunto. Se ti arriva dopo 1 anno dalle tue previsioni un progetto nuovo
che richiede il triplo delle capacita' previste che fai, non lo metti su
perche' l'anno prima hai fatto un calcolo che non contemplava quel
progetto e non hai voglia di rifare i calcoli (questa e' una cosa che
effettivamente ho visto accadere! Tanto la grande azienda va avanti anche
senza il nuovo progetto, visto che comunque va avanti con i soldi nostri.
E se proprio non va avanti, invece di mettere in piedi il progetto nuovo,
e' piu' semplice madare a casa qualche lavoratore o, piu' probabilmente,
indire un'altra gara al ribasso per avere gli stessi lavoratori a prezzi
piu' bassi. Lo stipendio dei manager tanto cresce in qualsiasi caso)
 
Ciao,
Marco
 
-- 



ahahahhahah se la stampo e l'attacco in ufficio scoppia una rissa! :D


 si ma qui anche il cliente deve scendere dall'albero. 
 
Condivido totalmente, ne parlavo con mio fratello la settimana scorsa.
 
Hanno un CAD di posizionamento tessuti coperto da contratto di manutenzione (tieni presente questo particolare); il software prevede per funzionare una chiave hardware di attivazione; la chiave hardware, senza che l'azienda la danneggi, inizia a dare problemi.
 
La software house chiede 400 euro per la sostituzione della chiave. Alla domanda: ma non è coperta dal contratto di manutenzione? la risposta è stata: il contratto di manutenzione copre solo il software.
 
Al di la del fatto che sono fortunati, che nessuno pianta una causa per 400 euro anche se IMHO ci sarebbero gli estremi per aprirli in due come una mela, chiedo a mio fratello: ma perché non li mandate affanzum? mio fratello apre le braccia e non dice nulla.
 
-- 
Ciao!
Luca

 ahahahhahah se la stampo e l'attacco in ufficio scoppia una rissa! :D
 
In effetti, molto simpatica. Pero' c'è una cosa che non capisco. 
 
Io sono uno sviluppatore. Vero, nella mia vita ho fatto anche il sistemista, ma mi sono accorto che non è ciò che mi piace fare, dal momento che non ho il totale controllo su ciò che succede. Dio, è vero che ultimamente, con tutti 'sti framework che si usano e che sono comodi, spesso non è vero nemmeno quando sviluppo, ma tant'è.
 
Eppure, io non riesco a concepire l'idea di sviluppare senza pensare al sistema o ai sistemi di destinazione. E per farlo, dove le mie competenze terminano, ho bisogno di un buon sistemista che mi supporti; e visto che ultimamente sviluppo sotto Linux, le mie competenze terminano abbastanza in fretta.
 
Per cui: come si fa a sviluppare software senza pensare al sistema su cui girerà? come si fa a pensare a un sistema senza pensare al software che ci deve girare?
 
Ovviamente la riflessione volutamente lascia perdere le cose fatte in modo pedestre, da una parte e dall'altra.
 
-- 
Ciao!
Luca

 Per cui: come si fa a sviluppare software senza pensare al sistema su cui girerà? come si fa a pensare a un sistema senza pensare al software che ci deve girare?
 
Invece è proprio questa la strada consigliata da molti: astrarre,
astrarre, astrarre! Portabilità, scalabilità, immaterialità! Non a
caso le VM oggi così diffuse fanno proprio questo.
Non sto dicendo che abbiano torto, ma sta di fatto che di frequente
qualcuno ci sbatte il grugno contro la materialità e la finitezza
dell'hardware.
Mi accontento che quel qualcuno non sia io :-))

 per i sistemisti.
 
è un discorso complicato. 
 
chiedere una previsione di quante risorse richiede un applicativo spesso non è una domanda che comporta una risposta secca. come quando vai a comprare windows la ms ti dice quali sono i requisiti minimi che però sono diversi da quelli raccomandati per delle prestazioni accettabili e probabilmente ancora diversi da quelli per avere le prestazioni che t'aspetti. per questo la scena è sempre la stessa, il programmatore tende a sparare alto e il sistemista a fare la tara, col risultato che l'ultimo ad essere soddisfatto è l'utente finale.
 
 
 

 
Non è che non si ha voglia di rifare i calcoli, altroché, si fanno tutti 
i giorni !!!
 
Il problema risiede nel fatto che tu sviluppatore, nei 6 mesi durante i 
quali sviluppi il progetto ti sarai reso conto che non ci stai nelle 
stime e quindi avverti subito l'area sistemi per dire che alla consegna 
non serviranno x cpu e y giga ma una quantità superiore....
 
Sempre che il programmatore faccia dei seri test di carico 
dell'applicazione con dati verosimili e non con i db vuoti, si accorgerà 
che servono più risorse....
 
Ovvero, avverti appena ne hai coscienza !
 
Non ti presenti il giorno dell'installazione sulla macchina di 
produzione, già installata, patchata, allocata etc dicendo che ti 
servono cpu in più, che tanto la macchina è virtuale quindi è semplice...
 
 

 chiedere una previsione di quante risorse richiede un applicativo spesso non è una domanda che comporta una risposta secca. come quando vai a comprare windows la ms ti dice quali sono i requisiti minimi che però sono diversi da quelli raccomandati per delle prestazioni accettabili e probabilmente ancora diversi da quelli per avere le prestazioni che t'aspetti. per questo la scena è sempre la stessa, il programmatore tende a sparare alto e il sistemista a fare la tara, col risultato che l'ultimo ad essere soddisfatto è l'utente finale.
 
Senza dubbio valutare le risorse richieste da un'applicativo è una
cosa assai complessa.
A mio parere questo è un ottimo motivo per non trascurare un pò di
accorgimenti prestazionali quando si sviluppa, al prezzo di perdere
qualcosa in "pulizia" del codice. Magari non serviranno, magari invece
ti risparmieranno qualche giornata (e nottata) affannosa nel
rismucinare tutto per guadagnare qualche gb di RAM o qualche ora di
elaborazione.


una soluzione potrebbe essere: quando vengono a portargli la nuova chiave, gli fa trovare un bel mattone con su scritto "dio c'è" sul sedile della macchina ovviamente avendo cura che sia entrato dal parabrezza. e quando chiedono spiegazioni... tuo fratello apre le braccia e non dice nulla.

chiedono spiegazioni... tuo fratello apre le braccia e non dice nulla.
 
A tutto c'e' rimedio:
 
http://tinyurl.com/bs9v3fg
 
 
 
 
ciao
fm 
 
 

 Ovvero, avverti appena ne hai coscienza !
 
 
Ma scusa, da voi sono gli sviluppatori che avvertono l'area sistemi di
queste cose ?
 
Io al limite ho sempre avvertito i PM. Poi cosa ne facciano questi delle
mie informazioni, teoricamente non dovrei nemmeno saperlo.


 Al di la del fatto che sono fortunati, che nessuno pianta una causa per 400
euro anche se IMHO ci sarebbero gli estremi per aprirli in due come una mela,
chiedo a mio fratello: ma perché non li mandate affanzum? mio fratello apre le
braccia e non dice nulla.
 
Non sara' che il l'azienda fornitrice e' di proprieta' di
mogli/amici/parenti/amanti di un superiore di tuo fratello ? O magari: hai
indagato che tua cognata non possieda un'azienda software specializzata in
software di posizionamento dei tessuti funzionante con chiavi hardware :-)
?


 software di posizionamento dei tessuti funzionante con chiavi hardware :-)
 
No, è che quando alla persona che lo usa si prospetta l'idea di un cambio, gli vengono le convulsioni. Non so se tu hai idea di cosa sia aver a che fare con gli utenti beoti: a volte 'non va' = 'mi hai spostato il pulsante che usavo a destra di 0,5 cm, per cui non lo vedo più e... era meglio quello di prima'.
 
Penso però, alla luce di quanto accaduto, che prima o poi al tale le convulsioni verranno lasciate...
 
-- 
Ciao!
Luca

mi guardava come fossi il mascetti che gli faceva la supercazzola...
 
Paro paro, disparo in mano...tempo fa da un mio cliente, stesso tipo di
problema, stessa diagnosi, stessa cura...solo che...il cliente doveva far
riscrivere parte dell'applicazione per raggiungere l'obiettivo...costo
dell'operazione: xmila (n)euri...costo di ampliamento ram: xmila/0,35
(n)euri...secondo te quale e' stata la scelta del cliente? (eppoi mi diceva pure
Lui:"tanto prevediamo di ampliare gli accessi quindi altre risorse ci serviranno
cmq, da prossimo anno apriremo l'applicativo a tutte le aziende del gruppo,
triplicando gli utenti..." 
io:"si ma gli utenti concorrenti quanto crescono?"
Lui:"?!?!?"
io:"guarda che un utente non e' altro che un record nella tabella user e li non
fa danni, il problema e' quando gli utenti si connettono all'applicazione, ora
ha 250 utenti registrati ed una media di 50 utenti concorrenti, domani aprendola
al mondo intero avrai enne utenti registrati ma di questi quanti lavoreranno
contemporaneamente sull'applicativo?"
aho' parevo sceso io da marte... )

 fm 
 
 

 Solo curiosita', non voglio comprarmene uno !
 
veramente i pneumatici run flat sarebbero già alla tua portata, se tu li 
volessi... possono percorrere fino a 1000 km dopo una foratura.
 
 

 li volessi... possono percorrere fino a 1000 km dopo una foratura.
 
:-)
 
li conosco, sono in giro da un bel po'.
Ma si suppone che i pneumatici 'blindati' debbano sopportare ben altro che 
una semplice foratura ...
 
Andrea