Newsgroup: it.lavoro.informatica
Titolo: Sfogo: programmatori cacciavitari/sparagestionali

È ufficiale, odio con tutto il mio cuore la maggior parte del sottobosco
di "programmatori" che infestano le aziendo coi loro carissimi e
merdosissimi programmi verticali di merda.
Ultimo esempio oggi col cazzo di programma che abbiamo qui da noi per la
gestione dei "cartellini" (insomma, accesi e uscite). Sto cazzo di
programma di merda, venduto dai commerciali ai nostri capi senza consultare
i tecnici, è una merdata scritta in PHP che utilizza chiave HW e Zend
Compiler per offuscare il codice (certo, un'applicazione così fenomenale te
la vogliamo copiare tutti, sì sì) che, secondo loro, ha bisogno di
*Oracle*. Per gestire gli accessi di 200 persone. Probabilmente un Sqlite
basterebbe e avanzerebbe, ma no, mettiamo un Oracle (che non vogliono
gestire loro compreso nel prezzo, chiaramente). Per cui alè, montiamo una
VMWare del cazzo con un Oracle dentro per non rompere troppo le balle.
Ma cosa fa la geniale applicazione? Se perde la connessione a Oracle anche
solo per un microsecondo, CRASHA!! E bisogna rilanciarla manualmente, anche
se è un servizio di Windows, perchè gli idioti non sanno manco configurare
2 cose in croce, e io con la loro merda non mi ci sporco le mani.
Madonna mia che rabbia.
-- 
Vide

 Madonna mia che rabbia.
Io ho rabbia perché ciò che descrivi è solo un punto di vista di un
circolo vizioso in cui tutti i tecnici coinvolti potrebbero dire la
loro. Sono certo che se vai dal programmatore che l'ha fatta, ti dirà
che l'hanno costretto a scriverlo in 10 minuti e che, visto che Oracle
conosceva, per brevità ha utilizzato Oracle.
-- 
Ciao!
Luca

 conosceva, per brevità ha utilizzato Oracle.
Probabilmente è così, anche se il fatto che usino Oracle (da PHP eh, non da
Java) io credo sia semplicemente fatto per fare i fighi e vendere meglio il
prodotto. "ooooh, usano Oracle! che profescional!"
-- 
Vide

 merdosissimi programmi verticali di merda.
capisco bene la tua situazione, anch'io sto mettendo mano ad un programma 
scritto da uno di questi programmatori "cacciavitari" come li chiami tu e 
c'è da mettersi le mani nei capelli (ad averceli). si farebbe quasi prima a 
riscrivere tutto da capo.
Ma ti invito a riflettere prima di avercela a morte con noi programmatori. 
In realtà il programmatore è povero un operaio alla catena di montaggio, in 
realtà le responsabilità sono di chi questa catena dovrebbe controllarla e 
per negligenza o incapacità non lo fa.
Il programmatore che ha sviluppato quell'applicazione probabilmente non 
brillava per capacità ed ha sicuramente avuto poco tempo per svilupparla, 
perchè il commerciale voleva che fosse pronta entro ieri. Ma alla fine lui 
ha fatto quello che gli chiedevano e per cui lo pagano, ha realizzato 
qualcosa che più o meno funzionicchia ma che è fatto da cani. Però nessuno, 
nè chi ha venduto, nè chi ha aquistato, nè tutti quelli che ci sono in 
mezzo, ha fatto un minimo di controllo di qualità.
Quindi non te la prendere tanto con il povero programmatore, ma con chi sta 
sopra di lui.

 sta sopra di lui.
Ok ok, cambio il subject :P
-- 
Vide


Hai mai visto un muratore accettare di tirar su muri con cazuole di cartone?
:-)
Voglio dire, è ora che i tecnici aumentino la loro professionalità pure
cercando di imporre dei vincoli minimi per lo sviluppo di soluzioni, o no?
Troppo facile lamentarsi dopo...
Ciao, Alessandro

 cartone?  :-)
Ho visto fare ben di peggio, credi...
-- 
Ciao!
Luca


Ora però mi hai incuriosito... tipo?
Ciao, Alessandro

 merdosissimi programmi verticali di merda.
non credo proprio che la verticalità sia il problema.
anzi, ringrazia il cielo che almeno è verticale, così a calci e pugni
lo fai partire. hai idea di cosa può combinare un team di incompetenti
che per giunta si mette anche a generalizzare?

 Troppo facile lamentarsi dopo...
Assolutamente d'accordo. Troppo comodo dire "Mi hanno detto di fare così
e io faccio così".Se uno vuole essere considerato un professionista deve
anche sapersi opporre alle cazzate che gli vengono imposte. Proprio
questi giorni l'azienda dove sto si trova nella merda per un progetto in
outsourcing fatto alla cazzo di cane, tra l'altro anche perché non mi
hanno dato retta per certe cose che avevo proposto. Avevano fretta di
avere il software prima possibile, quello è stato fatto con metodologia
"Caga e guarda cosa esce fuori", senza un minimo di pianificazione,
senza specifiche, senza documentazione, e come tale è stato consegnato a
noi. Risultato: manutenibilità zero, possibilità di estenderlo zero,
performance da far piangere, e pieno di bug (anche gravi). Ah, cosa più
importante: tempo speso era almeno il triplo rispetto a quello che ci
avremmo messo noi a farlo in casa, e in modo come lo avevo suggerito io.
Per non dire che chi prendeva in carico il progetto aveva detto che il
progetto sarebbe finito in pressoche metà del tempo che avevo stimato io.
Il direttore ora mi sta evitando nei corridoi, o si mette a parlare con
qualcuno quando passo o entra in qualche ufficio a caso, ecc.
E c'è da dire che è il secondo progetto che è andata così nel giro di
pochi mesi. Nel primo caso ce l'ho fatta a correggere i problemi e
rendere il software utilizzabile, ma in questo caso sarà da riscrivere.
Vorrei proprio vedere come andranno le cose la prossima volta quando si
deciderà come fare i proggetti e se sentirò ancora la odiata frase:"Non
c'è tempo per documentare ora, abbiamo fretta, dobbiamo essere operativi
prima possibile".
P.S: Ora vi sarà anche chiaro perche ho scelto quel nick che ho. Avrei
preferito qualcosa che descrivesse un "programmatore in ambiente di
lavoro tecnicamente avanzato e con i dirigenti e i commerciali che danno
retta ai tecnici", ma purtroppo sarebbe una bugia.

 prodotto.
Su questo sarei d'accordo.
Nel 2004, lavorando in Ericsson mi e' capitato di sviluppare una
applicazione relativamente complessa (il progetto e' durato poco
meno di un anno, solo perche' la maggior parte delle cose le avevamo gia'
fatte. Abbiamo solo dovuto fare il porting sulla nuova piattaforma), su
una piattaforma TSP, ovvero una piattaforma con circa 20 processori, ognuno
con 1 GB di RAM associata, sulla maggior parte dei quali girava un
S.O. DICOS (definito soft real time), su un paio girava il S.O linux,
utilizzato per le operazioni di I/O. La macchina aveva 2 schede SS7
(che nella applicazione in questione non sono state utilizzate) un
paio di HD (sempre per operazioni di IO. I processori DICOS, in quanto
soft real time, non avevano dischi associati). Nell'architettura
della macchina era anche compreso un database ad oggetti proprietario
che faceva bilanciamento e replicazione automatica dei dati sui
vari processori (come meccanismo di fault tolerance). Erano
previsti vari meccanismi di cifratura dei dati che viaggiavano dal client
al server, un programma che  simulava un server HTTP che girava
su tale macchina, utilizzo di oggetti strani (tipo OCX) lato client e
meccanismi di autenticazione abbastanza sofisticati (simulazione
di una autenticazione GSM con lettura dell' IMSI della SIM dell'utente
lato client, spedizione dell'IMSI cifrato al server HTTP simulato,
inoltro dei dati ad un altro server che potesse interrogare l'HLR
dell'operatore, ricezione delle triplette di autenticazione, inoltro di
randomici per la challenge al client, valutazione della risposta alla
challenge facendo girare l'algoritmo GSM sulla SIM, inoltro della risposta
alla challenge verso il server, verifica che la risposta alla challenge
fosse corretta, attesa che il service provider interrogasse il server
di autenticazione per l'avvenuta verifica dell'autenticazione stessa).
simulazione di un web server Il tutto per gestire
circa uno o due accessi/giorno.
 "ooooh, usano Oracle! che profescional!"
Infatti secondo te l'architettura di cui sopra (che per quanto ne
so io, solo HW+ S.O costa poco meno di un milione di Euro)
al cliente l'ho voluta fornire io che sono programmatore.
Ovviamente! 
Indovina un po' chi e' andato dal cliente a dirgli: "guarda quanto e'
figa la nostra piattaforma". Ti aiuto: non sono stato ne' io' ne
altri programmatori che lavoravano con me.
Indovina che mestiere fa quello che e' andato a dirgli la cosa di
cui sopra.
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 prodotto. "ooooh, usano Oracle! che profescional!"
bah. secondo me è molto più banale: semplicemente l'hanno sviluppato
sul primo cliente che aveva oracle.

 Troppo facile lamentarsi dopo...
Secondo me e' troppo facile dire  "cercando di imporre dei vincoli minimi
per lo sviluppo di soluzioni"
Senza dire quali sono questi vincoli e, soprattutto, come penseresti
di "imporli" (tra l'altro, "imporli" a chi )?


 retta ai tecnici", ma purtroppo sarebbe una bugia.
Appunto. Ancora non capisco come pensate di "imporvi".


 sul primo cliente che aveva oracle.
Non ho mai sviluppato applicazioni *serie* che avessero un bisogno 
massiccio di accesso ai dati e persistenza degli stessi (niente per cui 
non bastasse un file .txt o qualchhe .xml), ma per quel po' che ho 
lavorato sui DB ti dico che un DAL che implementasse un AbstractFactory 
pattern con delle implementazioni concrete "intercambiabili" non è nulla 
di "trascendentale". Basta avere pochi concetti di architettura del 
software.
Ora, io non so se il DAL dell'applicazione che usa Vide sia così 
imponente da non poter essere riscritto per altri DBMS, ma *a occhio* - 
quindi senza la pretesa di giudicare il lavoro di nessuno - è mancato 
qualcosa "prima".
Ciao,
Giulio
-- 
OnAir: Pain of Salvation - "This heart of mine"

..................
Probabilmente questo programma dà i risultati previsti, non si sa come
ma
li dà. Probabilmente è fatto secondo i "trend" attuali: PHP, Oracle...
Quindi
i commerciali lo vendono bene, ed i clienti  lo
accettano meglio, che so, di uno in Cobol con base dati Access.
Per i crash ed Oracle, tanto c'è il sistemista pagato per fare anche
quello....
Morale: in un'azienda a volte si fanno considerazioni non
esclusivamente
di qualità ed efficienza tecnica. Non che io sia d'accordo con questo.
Però è uno scenario frequente: sistema informatico pieno di falle
tenuto
in piedi in modo accettabile dal lavoro di personale pagato apposta
allo scopo.

 cercando di imporre dei vincoli minimi per lo sviluppo di soluzioni, o no?
intanto ti riferisci ai "tecnici" come se fossero una categoria 
professionale ben definita, come i dentisti o gli avvocati, con un codice 
deontologico da seguire. Non lo sono. Chiunque può leggersi un manuale di 
java e trovare qualcuno che gli dà uno stipendio (magro) per scrivere 
programmi. E visto che probabilmente lavorerà a cocopro e che comunque sarà 
l'ultima ruota del carro all'interno della società, figuriamoci se oserà 
impuntarsi con i suoi capi dicendo "no, questo non si può fare", "mi serve 
più tempo", ecc. Ammesso poi che abbia le capacità e la volontà e che gliene 
freghi qualcosa. PIù probabilmente farà semplicemente quello che gli viene 
detto di fare, nel modo in cui lo sa fare (o non lo sa fare)
I problemi sono:
- quando una società assume un programmatore, dovrebbe controllare se sa 
programmare o solo se si spaccia per programmatore.
- non c'è nulla di male anche ad assumere qualcuno che sa programmare poco o 
male, gli si può insegnare, basta che ci sia un capo progetto/capo tecnico 
di adeguata esperienza e che a costui gliene freghi qualcosa di farlo (cosa 
non scontata). Dovrebbe essere chi sta sopra al programmatore a dirgli come 
deve essere fatta una cosa, non viceversa. SI è mai visto un operaio di 
catena di montaggio impuntarsi con i superiori perchè le saldature del pezzo 
non vengono fatte bene? Quando va bene si limiterà a fare un'osservazione ai 
superiori e poi tornerà al proprio posto. Se non gliene frega nulla, non 
dirà nulla.
- non esiste un modo per controllare la qualità di un software su misura, se 
non provandolo in maniera estensiva, quindi quando è già stato acquistato. E 
una volta acquistato e iniziato ad usare è molto difficile buttare via tutto 
e ripartire da zero con un altro programma. piuttosto si cercherà di fare 
funzionare quello che si ha a calci e pugni. Questo è il fenomeno che tiene 
in vita una buona parte delle "software house" (con molte virgolette) 
italiane.
- se anche esistesse un modo (io non lo conosco) sicuramente la quasi 
totalità degli imprenditori e commerciali lo ignora e comunque tenderà 
sempre ad effettuare la selezione sulla base di amicizie e parentele. 

 cui sopra.
Ma sì! Infatti ho corretto il tiro lamentandomi con la ditta in generale (e
con quelli qua che hanno scelto sta piattaforma del menga)
-- 
Vide

 considerati dei professionisti" ?
Quoto.
Come ho detto nell'altro post, bisogna smettere di considerare il 
"programmatore" come una categoria professionale definita. chiunque può fare 
il programmatore, dal super guru al ragazzetto sbarbato che ha letto java 
for dummies. Probabilmente a quest'ultimo non gliene fregherà nulla di 
essere considerato un professionista. 

 Appunto. Ancora non capisco come pensate di "imporvi".
Chi ha parlato di "ImporsI"? Almeno non l'ho scritto io...o ha scritto
AleTV. e riguardavoa solo l'imposizione dei vincoli entro i quali si
dovrebbe sviluppare per avere software decente. Io ho parlato di
"Opporsi" alle cazzate che vengono imposte dai non-tecnici incompetenti.
Ed è quello che faccio sempre e ovunque.

 Ed č quello che faccio sempre e ovunque.
Si, ma nella mia esperienza "opporsi" significa che al massimo
tu gli puoi dire: "guarda che questa e' una cazzata. Sarebbe meglio
fare in quest'altro modo..."
Ma sai quante volte gli abbiamo detto che per un server che gestisce
2 accessi/giorno si puo' utilizzare tranquillamente linux+MySQL mentre
quelli volevano come minimo Windows 2000 server + SQLServer (quando
poi non hanno accettato quel catafalco di cui all'altro post, che non
sono certo andato io a proporgli). 
Se quelli vogliono cosi' c'e' poco da opporsi.


 dal canto suo). Mi sembra un fatto incontrovertibile
A me non sembra incontrovertibile per niente. Perche' esattamente dovrebbe
esserlo?

 
Invece, secondo me, bisogna farlo.
Ciao.

 "programmatore" come una categoria professionale definita. 
Sono contento che concordi con me, ma dal mio punto di vista la
soluzione piu' che "bisognerebbe smettere di" consiste nel
"bisognerebbe cominciare a"... e dovrebbero cominciare soprattutto
i programmatori.
Ciao,
Marco.
[SNIP]


 esserlo?
Vogliamo fare il contro fra progetti LAMP (o anche solo *AMP) e progetti
PHP-Oracle?
-- 
Vide


Ma non è questione che uno debba preoccuparsi di sapere come lo considerano
gli altri, è questione di riuscire a non impazzire dovendo seguire i
progetti in modo randomico. Se poi esistono delle persone che si divertono e
trovano soddisfacente lavorare in questo modo, be', saranno +- matti...
Ciao, Alessandro

 Ciao.
Dove lavoravo fino all'anno scorso i programmatori lo hanno ripetuto fino
alla nausea che i sistemi che il cliente comprava erano assurdamente
costosi per le loro necessita'. Il risultato e' che ne hanno comprati di
piu' costosi :-). Poi ora si ritrovano impelagati in una marea di debiti,
ma questi non dipendono dai prodotti comprati, quanto dalle politiche
di gestione dell'azienda ad alti livelli (vedi le note vicende
di Tim/Telecom)


 io con la loro merda non mi ci sporco le mani.
Nessun programmatore sano di mente sceglierebbe autonomamente l'accoppiata PHP-
Oracle in questo caso.
Dall'alto è sicuramente arrivata la "direttiva". Il problema sta nell'alto, non 
in chi implementa e magari fa il massimo con la tecnologia a disposizione.
-- 
__________________________________________________
Luc (34, CO)
MS Visual Studio developer - Programmer since 1985
__________________________________________________

 Ciao, Alessandro
Il discorso e' diverso. Io non mi diverto affatto. Ma non ho alcun
potere di impedire che avvenga cosi'. Potessi impedirlo lo farei
volentieri.



Be', dipende dal contesto.
Io ho sempre lavorato in realtà piccole, quindi non so quanto i miei
approcci siano applicabili anche in aziende grosse.
Però se chi non ha sensibilità implementativa sufficiente a causa di poca
esperienza mi viene a dire :"tu fai così che mi assumo io la
responsabilità", e io so che ciò che viene proposto è controproducente, ho
sempre risposto "no, non lo faccio" motivando le mie ragioni e andando per
la mia strada. Ovvio che poi il risultato doveva essere garantito,
altrimenti le rimostranze sarebbero state viste come inutili.
Su progetti grossi, tempi di sviluoppo lunghi, enne persone coinvolte, forse
metterla su questo piano è più difficile, però, cavolo se le enne persone
coinvolte si trovano daccordo, be', vuoi dirmi che la loro voce non conta
nulla?
Ciao, Alessandro


Non ti invidio per niente...
Ciao, Alessandro

 Marco.
Ottimo. C'è giustizia in questo mondo, se non umana, allora divina.

 Sentenza wrote:


Come fai a confrontare il numero di progetti in cui praticamente
tutto e' free o comunuqe Open Source, 
con il numero di progetti in cui c'e' una roba come
Oracle che non e' che te la regalano ed e' quanto di piu' commerciale
possa esistere.
E' come se io dicessi: vogliamo confrontare il numero di progetti
*-Oracle con il numero di progetti *-AMP, ma limitandoci
solo all' ambito bancario (ma anche in ambito telecomunicazioni,
considerando
pero' aziende di grandi dimenzioni) ?
Secondo me il dato si capovolge completamente


anche sapersi opporre alle cazzate che gli vengono imposte. 
proprio vero ma mica sempre e' possibile. Una esperienza personale di
poco tempo fa': anni fa realizzamo un grosso gestionale (non per la
parte contabile) per un nostro cliente dell'epoca. Analisi e sviluppo
andarono regolarmente (lavorammo con due incaricati del cliente), la
30ina di utenti dell'applicazione ci fecero poi vedere un po' di
"sorci verdi" al momento della "messa in produzione" (la fase di test
si limito', per volonta dello stesso cliente che aveva fretta di avere
la nuova applicazione pronta per l'uso, ad una settimana in cui i due
soggetti che ci avevano assistito in fase di analisi realizzarono
qualche decina di transazioni su di una applicazione che nasceva per
gestirne qualche decina di migliaia, e di conseguenza avrebbe meritato
forse un test un pochino piů "robusto") segnalandoci i bug, che erano
al 10% errori veri e propri ed all'90% carenze in fase di analisi
circa le features di cui l'applicazione necessitava. Scoprimmo infatti
che le due persone con cui avevamo svolto il lavoro di analisi non
erano esattamente i destinatari tipo del prodotto (ne erano destinati
ad utilizzarlo nella maniera completa degli utenti normali) ma "solo"
due elementi di fiducia del dirigente che ci aveva affidato il
compito. Indubbiamente la nostra analisi fu' carente ma lo fu' anche
perche' le persone con cui dovevamo lavorare non erano in grado di
esprimere completamente le necessita' e le funzionalita della loro
struttura e noi anche se qualche dubbio magari lo avevamo avuto non
eravamo in grado come fornitori (per inesperienza personale, timidezza
congenita, imperizia ed impreparazione ecc ecc) di imporre un diverso
punto di vista (anche se contrattualmente eravamo "blindati", c'era
stato un documento di analisi - contenete anche i requisiti e le
funzionalita' per l'utenza - ampiamente firmato e sottoscritto dai
responsabili aziendali prima che noi si iniziasse lo sviluppo vero e
proprio). 
Questo accadeva nel 2001 l'inverno passato il nostro ex cliente ci
richiama, semplicemente ora la base utenti e cresciuta (enormemente,
hanno o sono stati assorbiti da un'altra azienda) da circa 30 previsti
si e' passatti ad un 200, 200 utenti che esprimono delle necessita'
diverse a distanza di 5/6 anni da quando il prodotto fu' realizzato.
Ci chiedono di aggiornarlo, dopo una breve discussione/analisi
(stavolta facendoci carico di richiedere la presenza di persone
competenti) siamo a suggeririgli di riscrivere il prodotto (che per
aggiornarlo come da loro richiesto ci sarebbe voluto poco di meno -
come tempo e denaro - che a riscriverlo ex-novo). Il cliente nicchia,
alla fine gli faccio notare che i sorgenti li hanno, un reparto
tecnico con almeno un pajo di persone in grado di modificare
l'accrocchio pure e che quindi possono tranquillamente fare da se. In
sovrappiu' se avessero incontrato dei problemi e senza eccessiva
fretta di risolverli ci potevamo impegnare a fornirgli un minimo di
assistenza nel chiarirgli qualche punto o passaggio oscuro.
Per due mesi silenzio, un po' prima dell'estate ci richiama, i suoi
tecnici hanno messo mano alla procedura ma i risultati non sono stati
soddisfacenti, dunque vorrebbero che noi correggessimo i loro errori
aggiungesimo qualche nuova funzionalita' e rimettesismo l aprocedura
in "carregiata" ma senza riscriverla limitandoci a correggere ed
integrare l'esistente. Il socio che si era incaricato di seguirlo deve
ancora spedire il preventivo per il lavoro che nessuno di noi ha
voglia di fare.

 Ciao, Alessandro
Il punto non e' tanto la dimensione del progetto quanto la dimensione
dell'azienda. Molto spesso in aziende molto grandi (io conosco abbastanza
le realta' Ericsson e Tim) e' proprio il progetto in se a non avere
grande significato. Molti progetti vengono portati avanti non perche'
si vuole ottenere un prodotto finito che serva a qualcosa ma ad esempio
perche' in Tim c'erano  dei "centri di costo" (ora pare che non ci
siano piu') che avevano un budget annuale da spendere e se non lo
spendevano, l'anno successivo gli veniva ridotto il budget 
annuale a disposizione.
Quindi a loro in realta' non interessava realizzare un prodotto
funzionante.
Gli interessava spendere dei soldi.
In passato (nel 2002 mi pare) mi capito' di lavorare ad un progetto per
Tim con una piccola
azienda calabrese che aveva le maggiori responsabilita' e il maggiore
budget relativamente al progetto (io ero in Ericsson). Allora si
diceva che i titolari di tale azienda fossero  molto amici di Tronchetti
Provera, per cui quella piccola azienda poteva ricevere un finanziamento
non indifferente dai centri di costo (ovviamente serano solo voci, non so
quanto ci sia di vero. Pero' per quanto ne so io poi le cose sviluppate con
quel progetto non so se siano mai state usate. Anzi, il test-plant di
Tim dove erano state installate, l'anno scorso e' stato spostato da Roma
a Torino).
Attualmente, anche se il meccanismo dei centri di costo non c'e' piu'
la logica e' sempre quella (anche se ultimamente non lo so. Da marzo
di quest'anno lavoro in altri ambienti, che pero' seguono logiche
molto simili o forse anche peggiori).
Il progetto singolo conta tra poco e pochissimo (comincia a contare
qualcosa quando fa fatturare dai 2-3 milioni di Euro in su), figuriamoci
le persone che ci lavorano.
Ciao,
Marco


 Ottimo. C'è giustizia in questo mondo, se non umana, allora divina.
Insomma...
Vista la situazione i fornitori sono stati piuttosto penalizzati
e io, che lavoravo per il fornitore (ed ero, insieme ad altri, 
tra quelli che diceva: "guardate che il cliente compra robe
assurdamente costose") ho dovuto cambiare lavoro.
Mentre chi si e' comprato Telecom non avendo soldi mi pare
che sia sempre li' e si becchi anche una valanga di "non e' colpa sua". 


 [SNIP]
Non so, non mi pronuncio in quanto non conosco abbastanza bebe la
situazione.

 software.
dove, in php? quel linguaggio dove per accedere ad oracle ci sono le
funzioni oci_*, mentre per mysql ci sono le funzioni mysql_* e via
discorrendo? :)
ma a parte questo, il problema non è avere uno strato in più o un
factory, semmai tutto l'sql che è stato scritto col dialetto oracle e
le funzioni oracle. quello è il classico problema di quando il
programmatore si appoggia pesantemente ad un database. il resto sono
quisquilie, niente che non possa essere risolto in un'ora di lavoro
con una search/replace.

 "profescional" ?
due parole: connection pooling.
bye!

 possa esistere.
Veramente Oracle c'è in versione "gratis", facilmente scaricabile da
oracle.com
In ogni caso è la filosofia che è completamente differente php+mysql è
(era?) qualcosa di snello, veloce, magari un po' "fatto male" (penso a PHP
prima della 5 o MySql prima della 4.1), però che ha una barriera di accesso
davvero bassa. Dall'altro lato hai un prodotto enorme, che può fare un
sacco di cose ma per cui devi perdere 2 giornate solo per installarlo
correttamente.
-- 
Vide

 PHP-Oracle?
E il conto tra Java-Mysql e Java-Oracle chi lo fa? E su QUALI basi 
soprattutto ??????

 possa esistere.
E appunto: se il soggetto e' "sitarello web" allora grazie arca: PHP-Mysql.
Ma se mettiamo Oracle di mezzo, vuol dire che parliamo di sistemi di un
certo peso, se non altro economico. Questo restringe di molto l'ambito,
e secondo me non c'e' abbastanza da fare una statistica significativa.
Io, per esempio, ho visto molto piu' facilmente Oracle interfacciato
a PHP che non a Java, il quale invece l'ho visto interfacciato a Mysql.
Significa qualcosa? Ovviamente NO!

 voglia di fare.
Vi prego, mandategli un preventivo ben salato. Tanto lo accetteranno 
comunque, non hanno scelta.
E gli servirą da lezione per la prossima volta. Per loro e per tutti quelli 
del "e checce vole, lo faccio fare a mio fijo che ha er picci". 

 con una search/replace.
Ti ripeto: per non-esperienza personale non posso dirti se hai ragione o no.
Ma a occhio direi proprio di si! ;-)
Ciao,
Giulio
-- 
OnAir:

 due parole: connection pooling.
Guarda che e' un po' che si puo' fare anche con PHP eh!

 del "e checce vole, lo faccio fare a mio fijo che ha er picci". 
Non so se siano del tutto applicabili a questa situazione, ma con le
ultime due frasi concordo a prescindere. Troppe volte ho sentito delle
situazioni simili, dove si considerava un programmatore pari a un
operaio: uno si fa male? Nessun problema: Avanti un altro! Se poi
combinato con l'avarizia del cliente e con la corsa al ribasso dei
prezzi/tariffe, un preventivo salato a chi prima ti aveva detto di no č
di dovere.

 soprattutto ??????
Ok, Java-Mysql sicuramente ce ne saranno di più, questo è vero, ma in ogni
caso in misura minore che PHP-Mysql. Ovviamente parlo spannometricamente,
per quella che è la mia esperienza e di persone che conosco/con cui ho
parlato.
-- 
Vide

nel thread - del PM, del commerciale, della dirigenza...etc...?
ma sai per esperienza personale ;-) i clienti (o il lavoro in
generale)  a volte ti mettono i paletti piu' diversi (compatibilita
con sistemi esistenti, riutilizzo di risorse - hw o sw - gia presenti,
rispetto per gli skill aziendali,  tempistiche anomale, budget piu' o
meno ampi, ecc ecc), insomma siamo cuochi che debbono inventare un
menu' con la spesa fatta da altri (a volte ma non sempre riusciamo a
suggerire una ricetta ad hoc "imponendo" noi la lista della spesa).
Alla fin fine l'unico vincolo che i nostri prodotti hanno e' proprio
quello da te apparentemente sottovalutato, il sw deve funzionare e lo
deve fare nell'ambito dei paletti posti dal cliente, se uno di questi
pali di confine viene rimosso o spostato non ci si sorprenda se poi il
sw puo' non rispondere piu' adeguatamente. Il bravo programmatore e'
anche quello che sa rendere chiaramente al PM al commerciale al
dirigente di turno i limiti impliciti e espliciti di quanto si sta'
realizzando, affinche il PM, il dirigente o il commerciale sappiano
porsi adeguatamente nei confronti del cliente o dell'utenza.

del "e checce vole, lo faccio fare a mio fijo che ha er picci". 
ma quelli non impareranno mai e cmq quel tipo di mentalita' e'
"imbattibile" imvho

 Guarda che e' un po' che si puo' fare anche con PHP eh!
premetto che non sono aggiornato, ma per quello che ne so fra il
connection pooling e le connessioni permanenti del php ci corre come
trombare e stare a guardare...

 porsi adeguatamente nei confronti del cliente o dell'utenza.
Sono pronto a sottoscrivere *col sangue* queste parole.
Ma permettimi di raccontarti anche io un minimo di esperienza personale.
Non sono un informatico (vengo dall'elettronica) e faccio lo 
sviluppatore ma fino ad un certo punto. Già dagli anni dell'università e 
poi con la partecipazione a piccoli progetti SW (non per il mio lavoro 
"ufficiale"), o spulciando i sorgenti di altri per trarre ispirazione, 
mi sono imbattuto spessissimo in situazioni quali:
- logica di applicazione nella GUI;
- tutto nel "Main";
- tutte le classi e i metodi statici;
- utilizzo dell'identificativo "myvar" per qualsiasi variabile, di 
qualsiasi tipo, di qualsiasi scope...etc...
- 5 funzioni richiamate da 5 classi diverse che fanno la stessa cosa, 
modificando magari variabili globali in maniera disordinata...etc...
- UnitTesting? Cosa? E che sarebbe?
..ed altre amenità del genere.
Questo significa che il codice è assolutamente non modulare, 
difficilmente estendibile, difficile da debuggare e quanto altro.
Dunque non mi meraviglierebbe affatto che una persona che durante gli 
anni dell'università scrive codice per avere come unico scopo la 
funzionalità immediata (e assolutamente non generale), quando va a 
lavorare scriva applicativi legatissimi al DB, non distingua la logica 
di business da quella dell'accesso ai dati e cose così. E la colpa di 
chi è? Del PM? Del Commerciale?
Sia chiaro: io non mi reputo migliore di questi sviluppatori, anche io 
ho fatto/faccio le mie brave stupidate, ma ho la fortuna di accorgermi 
che certe cose sono deleterie. Dunque acquisire metodo e mentalità può 
essere un costo ora ma che verrà sicuramente ripagato (e per quanto mi 
riguarda il tempo di recupero di questo costo è stato assolutamente 
breve, grazie anche al fatto che da un paio d'anni lavoro in un ambiente 
assolutamente "favorevole" da questo punto di vista).
Ciao,
Giulio
--
OnAir: Emily Loizeau - "je ne sais pas choisir" (capolavoro assoluto)

 Guarda che e' un po' che si puo' fare anche con PHP eh!
Se per un po' intendi due settimane... Oracle ha appositamente
realizzato un connection pooling database-side da utilizzare con PHP
per la 11g. Ho *qualche* dubbio che l'applicazione di cui parla Vide
abbia la 11g come backend, sinceramente :^)
bye!

 abbia la 11g come backend, sinceramente :^)
Infatti...
Comunque qua si è cambiato discorso da quello che stavo facendo io, ovvero
che sto cazzo di programma di merda che c'han venduto (non voglio sapere a
quanto) NON ha bisogno delle funzionalità di Oracle, ma nemmeno di 1%.
Probabilmente non gli serve manco un RDBMS, ma un DBMS gli basta e avanza.
La cosa che mi fa girare le balle e che mi ha fatto scrivere sto sfogo è il
fatto che poi rompono le balle telefonando A ME perchè per un secondo e
mezzo Oracle ha perso connessione e cade tutto senza possibilità di
riprendersi se non manualmente. Non sta ne in cielo nè in terra sta cosa...
-- 
Vide


1. perchè rompono le balle a te?
2. perchè oracle perde la connessione ?
3. tu che ruolo hai in azienda?

 riprendersi se non manualmente. Non sta ne in cielo nè in terra sta cosa...
e perchè rompono le balle te?

assolutamente "favorevole" da questo punto di vista).
credo che siamo "figli" di un approccio diverso: personalmente
realizzo sw su commissione, mi ritengo maggiormente uno specialista di
processi (o come mi avevano definito un tempo di aree funzionali) e di
volta in volta debbo "sposare" le esigenze funzionali con quelle
tecnologiche, in questo senso realizzare un qualcosa che "gira" con
db2 e non con mysql non mi pone problemi di alcun tipo (anzi se db2 ha
una splendida gestione dell'integrita' referenziale, cosa che mysql
non aveva fino ad un pajo d'anni fa' - non so' ora -, non vedo perche'
dovrei "perdere tempo" a reinventare la ruota se altri l'hanno gia
fatto per me, il fatto che la mia applicazione non potra' essere
riutilizzata con altri db e' secondario). Certo nel tempo ho
realizzato un personale magazzino di funzioni, classi, procedure, pgm
tout-court che "riutilizzo" di volta in volta (visto che cmq l'area
operativa che copro e' cmq "ristretta") aggiornandole quando
necessario. Ai miei clienti o sicuramente sempre suggerito l'adozione
di questa o quella prerogativa (db, framework, ecc ecc) ma
l'esperienza m'insegna che il fornitore difficlmente puo' imporre al
cliente qualcosa di totalmente alieno o di totalmente diverso dal
proprio contesto, a meno di non prospettare diversi tipi di vantaggi
(economici - e sia detto senza malizia -, di marketing, ecc ecc).
L'approccio da te delineato meglio si confa a realta' di tipo
"industriale" dove pero' (per esperienza personale, avendocilavorato
in realta' del genere) possono venire a crearsi vincoli di altro tipo
(ricordo in particolare un famoso prodotto per la gestione di aziende
di credito che dopo aver girato per anni su db oracle fu convertito al
db2 perche' l'azienda aveva allacciato una partnership commerciale con
ibm - che pochi anni dopo avrebbe acquistato l'azienda stessa)

 con una search/replace.
L'SQL è un linguaggio standardizzato, basta attenersi a quello per
avere tutta l'intercambiabilità umanamente possibile.
Certo che se nel gruppo di sviluppo nessuno sa cosa sono gli standard
ISO dei vari linguaggi...... E capita spesso.

 3. tu che ruolo hai in azienda?
Amministratore di sistema.
-- 
Vide

 Una volta perchè l'ho migrato di VMWare server e l'altra volta perchè uno,
ahi ahi ahi... lo sai che Oracle NON è certificato per funzionare
sotto VMWare? ;^)
bye!

 loro.
Si, ma di aziende che fanno gestione accessi ce ne sono un fottio. Ma 
che cazzo, quanto e' mai complicata sta gestione accessi?
Le poche applicazioni di gestione accessi che ho visto sono un vero 
cesso. Do ragione all'amico Vide pure sull'inutilita' di proteggere il 
programma con la chiave hardware.
Un programma per il controllo accessi di quel tipo un programmatore 
bravo lo realizza con 2 giorni di lavoro, e tutto con software con 
licenza GPL. 

 (differenti contesti, soprattutto umani, lo rendono impossibile)
Non sta scritto da nessuna parte, e nessuno diche che quella sia la strada 
da seguire in qualsiasi progetto.
Detto questo, fare un'applicazione intrinsecamente dipendente da un RDBMS 
significa porre dei limiti al proprio software, e la cosa puo' ripercuotersi 
negativamente sul cliente.
Se veramente il tuo progetto ha bisogno di utilizzare pesantemente funzioni 
o altre pecularita' oracle, perche' ti abbatte i costi di sviluppo del 50% o 
altre situazioni simili, allora ok. E' una scelta.
Ma se lo si fa per comodita' propria e poi si costringe il cliente a 
comprare Oracle spendendo una barca di soldi, e se quello stesso software 
poteva essere generalizzato facimente, beh allora stai vendendo (o cercando 
di vendere) un prodotto tutt'altro che buono. 

 battuto ciglio tranne il programma che si collega ad Oracle.
bah.
premesso che un programma scritto da cani resta un programma scritto da 
cani con tutto il suo fardello di problemi per chi lo deve gestire, mi 
vengono però d'acchito un paio di osservazioni:
- un vmware server con n macchine virtuali (e a quanto mi pare di capire 
con n >= 3) e una interfaccia da 100 mbit mi puzza di soluzione senza 
troppe pretese, e puntualmente si è dimostrata tale :)
- dovendo fare una installazione oracle apposta per un programma che (a 
detta tua) non ha esigenze "enterprise", a me sarebbe venuto in mente la 
express edition direttamente sulla stessa macchina del php. è una regola 
fondamentale: se il programma fa cacare, più lo isoli e meglio è :)

 voglia di fare.
Di situazioni cosi' ne ho viste un'infinita'.
In genere il cliente e' contento di spendere molto di piu'
per fare una modifica oggi, metterci una pezza domani, riscrivere
un pezzetto il giorno dopo, ecc. piuttosto che finanziare una
riscrittura totale, chiaramente meno costosa nel complesso.
In  pratica preferiscono trascinarsi dietro valanghe di problemi,
introduzione di probabili nuovi problemi, inefficienze, 
difficolta' crescenti di manutenzione ecc.
piuttosto che finanziare una riscrittura sicuramente meno costosa.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 voglia di fare.
Di situazioni cosi' ne ho viste un'infinita'.
In genere il cliente e' contento di spendere molto di piu'
per fare una modifica oggi, metterci una pezza domani, riscrivere
un pezzetto il giorno dopo, ecc. piuttosto che finanziare una
riscrittura totale, chiaramente meno costosa nel complesso.
In  pratica preferiscono spendere di piu' per trascinarsi dietro valanghe 
di problemi, introduzione di probabili nuovi problemi, inefficienze, 
difficolta' crescenti di manutenzione ecc.
Misteri italiani (ma forse non solo italiani).
Ciao,
Marco.



L'amante del capo?

 trombare e stare a guardare...
No, c'e' un componente esterno di middleware che aggiunge proprio il 
vero pooling:
http://www.oracle.com/technology/pub/articles/deployphp/lim_deployphp.html
http://sqlrelay.sourceforge.net/

 assolutamente una ferrari)...
Puo' avere tutta l'efficienza del mondo!!!!!!
Stavamo parlando di un'applicazione di controllo degli orari no? Che senso
ha che sia multipiattaforma e multidatabase? Assolutamente nessuno, ne
scegli UNO e lavori su quello, potrebbe essere perfino Access per quel
che importa. Il punto semmai e' che lavora col db SBAGLIATO.

 abbia la 11g come backend, sinceramente :^)
No si puo' fare con componenti esterni, come dicevo in un altro messaggio...

 negativamente sul cliente.
Ribadisco, non stiamo parlando di un grosso sistema di ecommerce, parliamo di
di gestire i CARTELLINI! Ha da segna' ingresso e uscita, piu' limitato di 
cosi'? Dici che ci perdi qualcosa a progettarlo per uno specifico db?
Non perdiamoci inutilmente nei massimi sistemi... :-))

 Probabilmente non gli serve manco un RDBMS, ma un DBMS gli basta e avanza.
Infatti secondo me andava bene pure con Access :-))))

 battuto ciglio tranne il programma che si collega ad Oracle.
Vabbe' e grazie ar ca pero' :-))

 vero pooling:
http://sqlrelay.sourceforge.net/
Ecco, questo mi mancava... grazie per la segnalazione ;^)
bye!

 L'amante del capo?
No. Direi marketing e/o PM.


 vero pooling:
però devi *esplicitare* l'uso del pooling? in altre parole, vide deve
riscrivere tutto il programma?
perchè in java (ma anche in altri ambienti) il programmatore se ne può
tranquillamente fregare. prende la connessione dal datasource, se si
tratta di una connessione pooled o no non è affar suo.

 tratta di una connessione pooled o no non è affar suo.
Si e in Java in cambio ammazzi la macchina anche per dire "ciao mondo".
Che c'entra? Niente ovviamente, ma visto che stiamo qui a paragonare
mele con crauti fritti, ne sparo una grossa pure io :) PHP e Java sono
ambienti diversi pensati per cose diverse, non ha assolutamente il minimo
senso mettersi a sostenere "e' meglio questo" in senso assoluto. Per 
esempio, tornando al nostro sistema di gestione dei cartellini, per me
chi volesse realizzarlo in Java e' un pazzo criminale al pari di chi 
decide di metterci Oracle :)

 essere un costo ora ma che verrà sicuramente ripagato 
E su questo non ci piove. Ma hai mai provato a spiegarlo al PM di una
multinazionale ?
Io si'.
Ciao,
Marco


 ISO dei vari linguaggi...... E capita spesso.
Puo' capitare, anzi e' capitato anche a me, specialmente qualche anno fa.
Pero' a me e' capitato molto piu' spesso avere "superiori" che
ti dicono: "dobbiamo usare i trigger di oracle". 
"Oracle ha la sua funzione XXX" che fa la cosa "YYY", usiamo quella
"Con Visual C si possono usare MFC => usiamo quelle" (obiezione: ma il C
standard... funzionerebbe lo stesso e si farebbe anche prima). "Chi se
ne frega!!! Se hanno messo quella funzione allora e' meglio usare quella"),
ecc.


 decide di metterci Oracle :)
se l'alternativa è php non sono daccordo. altri linguaggi parliamone.

se l'alternativa è php non sono daccordo. altri linguaggi parliamone.
infatti e' una scelta che mi lascia mooolto perplesso, a meno che non
sia il frontend dell'applicazione e l'acquisizione dei dati dai
lettori badge non sia auromatizzata ma fatta su richiesta dell'utente.

 Io si'.
E l'esito quale è stato?
;-)
Ciao,
Giulio
-- 
OnAir: Pain of Salvation - "Waking every God"

 se l'alternativa è php non sono daccordo. altri linguaggi parliamone.
Non e' mica detto. Dipende da cosa deve fare il programma. Se vuoi avere
per un qualsiasi motivo completa consultazione dei dati da web (magari per
farli vedere ai dirigenti da intranet) allora potresti fare benissimo tutto
in PHP per la parte di consultazione, che e' presumibilmente la maggior
parte dell'applicazione, con solo un modulo separato per l'acquisizione dei
dati dal lettore dei badge (ecco questo pezzo non lo farei, in PHP :))

 lettori badge non sia auromatizzata ma fatta su richiesta dell'utente.
Beh ma cosi' a naso, il 95% dell'applicazione e' appunto proprio la
consultazione. Per acquisire i dati puoi avere un modulo separato.

 Non e' mica detto. Dipende da cosa deve fare il programma.
ragionando in termini di "dipende da cosa deve fare il programma"
andrebbe messo in discussione anche la realizzazione web, perchè non è
detto sia la soluzione.

 Non e' mica detto. Dipende da cosa deve fare il programma.
No, dipende da chi lo fa.
Tanto per (reale) curiosita', esisten in PHP la possibilita' di fare unit 
testing, integration testing ecc? 

"Sentenza" <sent...@STACEPPAosteriafuoriporta.net> ha scritto nel messaggio 
news:slrnfdsndh....@osteria.gruppogsi.it...

Non hai capito allora.
Non stiamo parlando di altissime problemaitche di sviluppo, stiamo parlando 
di costringere un cliente ad usare Oracle e a sborsa inuitlmente quattrini, 
quando non ce ha realmente bisogno.
Quali massimi sistemi? Piu' elementare di cosi'. 

Vide wrote:
:: Probabilmente č cosě, anche se il fatto che usino Oracle (da PHP eh,
:: non da Java) io credo sia semplicemente fatto per fare i fighi e
:: vendere meglio il prodotto. "ooooh, usano Oracle! che profescional!"
Aho, hai detto Oracle mica bau bau micio micio

Vide wrote:
:: Ma cosa fa la geniale applicazione? Se perde la connessione a Oracle
:: anche solo per un microsecondo, CRASHA!! E bisogna rilanciarla
:: manualmente, anche se è un servizio di Windows, perchè gli idioti
:: non sanno manco configurare 2 cose in croce, e io con la loro merda
:: non mi ci sporco le mani.
So cose che capitano quando non si ha ben chiaro come si gestisce la 
persistenza :-)

Giulio Petrucci wrote:
: Ora, io non so se il DAL dell'applicazione che usa Vide sia cosě
: imponente da non poter essere riscritto per altri DBMS, ma *a occhio*
: - quindi senza la pretesa di giudicare il lavoro di nessuno - č
: mancato qualcosa "prima".
DAL, Abstract Factory e PHP? Mi sa che non ti rendi conto del livello medio 
dei "programmers" Italiani :-)

 dei "programmers" Italiani :-)
Italiani? Non si stava parlando di programmatori spagnoli?
;-)
Comunque ti capisco, anche se credo che forse il livello medio sia un 
po' più "alto"...
Ciao,
Giulio
-- 
OnAir:

 testing, integration testing ecc?
Unit testing si... non so se esistono tool per integration testing ma
credo ce ne siano. Uno dei problemi per il php e' di non avere un
ambiente di sviluppo potente e diffuso come puo' essere vstudio o
boh... netbeans. Ne esistono tanti e ognuno con le sue belle rogne per
cui la maggior parte degli sviluppatori usa editor come dreamweaver o
anche piu' profescional come ultraedit. Per cui molti non sanno
neanche cosa sia lo unit test, il debug, i layer applicativi ecc. per
cui ci si ritrova con scriptoni mischiati in mezzo alle pagine html da
far paura.
Personalmente, quando sviluppo in php5 (x il 4 vade retro satana) uso
zend studio, smarty per la separazione della business logic e ui, e
dreamweaver per il disegno dell'interfaccia. Applico tranquillamente
es pattern abstract factory, faccio unit test, debug e via dicendo.
Quasi come se sviluppassi in c#.

 detto sia la soluzione.
Eh no, aspetta: se il programma e' in web, io do' per scontato almeno che
abbia reale bisogno di essere in web - e che quindi dovendo essere web,
il PHP va probabilmente piu' che bene. Se invece e' un sistema stand-alone,
allora non ha nessunissimo bisogno di essere web e meno che mai di essere
in PHP. Ma qui non e' piu' un problema del linguaggio, ma del cretino che
ha pensato la cosa.
~

 testing, integration testing ecc? 
Yoho? Ho appena detto: il PHP e' pensato per certe cose. Come non faro' mai
un sistema web veloce in Java, non faro' mai un sistema di controllo
numerico in PHP.
Che senso ha dire che non ha certe cose, se nel suo ambito di applicazione
NON E' previsto che servano?

 Quali massimi sistemi? Piu' elementare di cosi'. 
Questo l'avevo gia' sottolineato io :) forse ti e' sfuggito che da "costringere
ad usare il database sbagliato" si era arrivati a "costringere ad usare un solo
database", che per quel tipo di applicazione e' appunto perfettamente
irrilevante.

 far paura.
No dai, adesso se uno non ha l'ambiente di sviluppo fico non conosce
le metodologie di sviluppo? Se non le conosce e' un pigrone LUI :O 
al massimo possiamo dire che senza ambiente di sviluppo fara' molta piu'
fatica...

 fatica...
adesso non vorrei riempire il ng di post inutili ma mi sento di
risponderti di si... senza un solido e comodo ambiente di sviluppo
puoi star certo che il 90 % degli sviluppatori prendera' strade...
raffazzonate alla meno peggio come e' puntualmente accaduto con il
php. Ovviamente non parlo dei presenti che anche usando il notepad
riescono ad avere una proiezione mentale chiara e senza errori :) Ora
con php5 che permette di programmare seriamente e con alcuni ambienti
di sviluppo abbastanza potenti la cosa si puo' ovviare. Ti voglio
vedere a creare una architettura multilayer distribuita e poi a
tappare la miriade di bug stampando a video le variabili o cercare le
funzioni tenendo aperte svariate finestre o facendo search e replace.

 funzioni tenendo aperte svariate finestre o facendo search e replace.
Beh e' banale dire che una volta lo facevano tranquillamente tutti...
naturalmente non c'era altra via, dunque tutti imparavano a farlo. Non e'
che perche' non c'erano ambienti di sviluppo strafichi nessuno scrivesse
buon codice. Adesso e' piu' che giusto e sacrosanto che la tecnologia
ti semplifichi la vita, senno' che cosa ci sta a fare :) ma non e'
altrettanto sacrosanto che se per caso la tecnologia non ti supporta, tu
non ci provi neanche a fare da solo. Altrimenti il programma lo potevamo
pure far fare ad una scimmia.
Si lo so che sembro il vecchietto sulla panchina, eh ai nostri tempi,
caro lei :-)))

 buon codice.
il tuo discorso l'ho capito come penso che tu hai capito il mio quindi
stiamo parlando di sfumature. Nel caso di php pero' le sfumature sono
tante. Fino alla versione 5 (che ancora non tantissimi usano) il
linguaggio aveva dei problemi grossi come una casa nel caso a qualcuno
fosse venuto in mente di programmare ad oggetti. Per fare qualche
semplice esempio che mi viene in mente, tutte le variabili erano
pubbliche, non cerano modificatori di visibilita delle funzioni (e.s
private o public) non c'erano interfacce ecc. ecc. ecc. Quindi, metti
insieme delle grosse carenze del linguaggio con la mancanza di un
ambiente di sviluppo solido e diffuso et voila'... orde di scriptari
esperti nel copia e incolla del codice. In altri linguaggi anche in
mancanza di ambienti di sviluppo potenti e' lo stesso linguaggio che
ti spinge al rigore e alla buona programmazione.

 ne frega!!! Se hanno messo quella funzione allora e' meglio usare quella"),
Questo non è in sè uno sbaglio. Chi dà quella direttiva sceglie una
certa strada
(nel caso specifico andrà a sfavore della portabilità). L'importante è
esserne
coscienti.
Diverso è il caso di quello che è ignorante, e non sa che
ci sono gli standard. Cosa inammissibile non solo per un PM ma anche
per uno sviluppatore senior.


Ho fatto dei programmi batch (non Internet/interattivi) con PHP su
Windows con I/O su Oracle (server Unix). Ho usato Odbc, pertanto ho
usato un numero limitato di
funzioni Php, che vanno bene per tutti i Db supportati da Odbc.
Con questo voglio dire che anche in Php si possono fare cose
abbastanza ordinate ed efficaci, anche se c'è sicuramente di meglio
per le prestazioni pure e l'aderenza a certi standard, tipo OO.
Un piccolo batch che legge le timbrature dei cartellini giornaliere
di una media azienda e le scrive sul db si può fare tranquillamente
anche in Php.

 pure far fare ad una scimmia.
Perfettamente d'accordo.
E d'altronde da chi usa gli ambienti di sviluppo è lecito aspettarsi
codice  con percentuali infime di bug, viste le sofisticate
funzioni di debug e test, no? Ma mi sa che non è proprio proprio
così.... ;-)

 numerico in PHP.
Non mi pare che non si possa fare roba veloce in Java. Se per veloce
intendi "performante". Se intendi "velocemente" allora possiamo essere
più d'accordo :D
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 E l'esito quale è stato?
Temo come parlare ad un sordo.
D'altronde molti di questi PM subiscono una sorta di lavaggio del 
cervello che recita "riduci i costi, taglia, riduci i costi, taglia".
Ed a forza di tagliare fanno carriera e soldi.
Quindi vade retro investimento (un rischio inutile) e chi se ne frega 
dell'ipotetico ROI futuro.
;-)
Bye
Jarod