Newsgroup: it.lavoro.informatica
Titolo: Cercasi collaborazione per progetto open-source (OOP-Perl e PHP)

Cerco collaborazione per lo sviluppo software di un programma di 
schedulazione scritto in Perl (ma non solo).
Cerco una persona con buone conoscenze OOP in Perl e uno sviluppatore 
PHP per l'interfaccia.
Due parole sullo scopo del progetto:
Se qualcuno di voi si è imbattuto in un gestore di WorkFlow (altresi 
detto scheduler) come ad esempio $Universe (della Orsyp) o quello 
prodotto dalla CA o altri... sa quanto siano, a volte, inutilmente 
contorti. Questa caratteristica negativa è dovuta al loro sviluppo 
fragmentato nel tempo, raramente vi è stata una ristesura dell'intero 
codice.
Il mio scopo è quello di sviluppare un prodotto leggero ($Universe 
occupa parecchie decine di megabyte), privo di hole-security, funzionale 
e soprattutto........ facilmente implementabile dal cliente finale.
Per raggiungere questo obiettivo ho scelto di scrivere il codice in 
Perl. Questi sono i motivi della mia scelta:
a) è multipiattaforma
b) ha una larga diffusione
c) il codice è interpretato
d) implementa paradigmi avanzati (OOP, overload degli operatori...)
e) ha una produttività elevata
f) sono disponibili infinite librerie
g) si interfaccia facilmente con il C
Non mi dilungherò oltre, non vorrei correre il rischio di tediarvi.
Voglio precisare che questo progetto sarà OpenSource, ovvero coperto da 
licenza GPL, ma potrebbe avere un ritorno economico interessante.
Infatti, sono in contatto con una ditta il cui core-business è.... la 
consulenza in ambito schedulazioni.
La società in questione potrebbe commercializzare questo software 
includendolo in un pacchetto codice+consulenza+teaching.
Questa interazione mi permette, inoltre, di conoscere le esatte esigenze 
dei clienti di questa tipologia di prodotti.
Chi fosse interessato a collaborare mi può contattare al seguente 
indirizzo: 
cati...@yahoo.com
Imiei dati sono visibili al seguente indirizzo:
http://www.geocities.com/catinella
Cordiali saluti
Silvano Catinella

 c) il codice è interpretato
Solo un appunto su questo: ti sembra veramente un punto di forza ?
Io non direi proprio...
Massimo

 c) il codice è interpretato
essendo interpretato non lo puoi proteggere ( penso )
quindi sara' copiabile da chiunque e non vedo a dire
il vero un possibile guadagno

 
Mah ... vediamo quando ti troverai a gestire hash di hash di
array di hash con tutte quelle belle '{' che arrivano fino
all'orizzonte.
Uso Perl da qualche anno e non credo sia un linguaggio molto
adatto a sviluppare programmi complessi. Sulle piccole cose
e' molto efficente (gestione di stringhe, file di testo) ma
quando cominci ad avere bisogno di strutture dati complesse
diventa efficente quanto un linguaggio tipo il C++.
Saluti,
Lobster

 diventa efficente quanto un linguaggio tipo il C++.
A dire il vero, a me risulta che il C++ *sia* efficiente nella gestione di
strutture dati complesse... e non che questo sia un suo limite, come sembri
affermare.
Massimo

Ciao Silvano,
prendila come una constatazione oggettiva ma non è che la tua sia proprio
una idea originale,
infatti se vai qua 
http://sourceforge.net/search/
 e digiti scheduler ti
escono fuori una trentina di
progetti tra cui alcuni in perl ed altri in php. Poi se vai qua vedi che
anche su CPAN
ce ne sono parecchi (tipo 200)
http://search.cpan.org/search?query=schedule&mode=all
.
A riguardo della scelta di programmare ad oggetti usando il perl tieni
presente che dopo il SAS ed il
cobol, il linguaggio del cammello è quello che meno si presta (a mio avviso
ma credo anche
a detta di molti) al paradigma di programmazione ad oggetti. Da questo punto
di vista l'alternativa
più prossima sarebbe il pyton. Poi non vedo perchè dovresti sviluppare su
due linguaggi con tutte le
complicanze del caso dato che il perl  può benissimo essere utilizzato come
linguaggio di scripting
server side al posto del php. Anche sulla parte del multipiattaforma
insomma... dal punto di vista di
multithreading, gestione dei socket e task/processi/servizi le cose cambiano
per il perl da una piattaforma
posix ad una win32 (e quelle che ho nominato sono tutte cose che un
ipotetico scheduler dovrebbe utilizzare).
Quindi, secondo me,(poi fai come vuoi )sarebbe il caso prima di pianificare
meglio quello che vuoi fare
(magari con casi d'uso , una bozza del manuale del prodotto finito, un
prototipo, un cronogramma di lavoro
un diagramma delle classi, l'individuazione del target di riferimento
aprendo un progetto su 
sourceforge.net
e schiaffandoci tutto questo materiale preparativo) e poi una volta fatto
questo tornare qua
e dire: ragazzi, ho in mente questo, come  vedete so bene cosa voglio ed ho
già pianificato tutto, chi vuole farlo con me?
Io personalmete, compatibilmente con i miei impegni una mano te la darei, ma
a patto di imbarcarmi conoscendo
prima capitano,vascello,equipaggio, rotta, traguardo e premio.
p.s. non si è capito (almeno io non l'ho capito) se cerchi uno sviluppatore
che implementi per te il progetto
o un co-programmatore.
Clemente.

Complimenti, hai letto con particolar cura il mio msg!
In particolar modo dove asserisco che il progetto da me proposto sarà 
Open Source.
Ti prego non postare inutili domande tipo: "....allora dove sarebbe il 
guadagno?". Piuttosto leggi qualcosa sul mondo economico dei prodotti 
OpenSource.


Potrei concordare con te, il C++ è più idoneo per gestire programmi 
complessi. Ma forse, più che il linguaggio, influisce come scrivi il 
codice: se i tuoi listati sono un groviglio caotico di istruzioni nessun 
linguaggio potrà aiutarti.
Per ciò che concerne la produttività del Perl: prova a chiedere 
informazioni ai vari gruppi di sviluppo Perl sparsi per il mondo. Alcuni 
di loro hanno ottenuto risutati eccellenti.
Riguardo al campo di utilizzo del Perl: capisco che tu lo abbia 
utilizzato per manipolazione di stringhe e "piccole cose". Ma questo non 
vuol dire che le potenzialità di questo interprete siano tutte qui! 
Forse vuoi dire che questo è ciò che conosci, concetto ben diverso.
Ti invito a leggere i paragrafi introduttivi dei libri della O'Reilly, 
in particolar modo dove definisce la filosofia del Perl: l'essere un 
collante.
Ti assicuro che nella sua sintassi e semantica puoi apprezzare una 
impeccabile eleganza matemaica, tipica del C++, ovviamente non a pari 
livello.


 posix ad una win32 (e quelle che ho nominato sono tutte cose che un ipotetico scheduler
 > dovrebbe utilizzare).
Questa è un'ottima obiezione. Ho curato il design del software in modo 
tale da ottenere un interfaccia al sistema isolata rispetto al core del 
programma. In tal modo, basterebbe riscrivere l'interfaccia per ogni 
sistema operativo.
 > Quindi, secondo me,(poi fai come vuoi )sarebbe il caso prima di
 > pianificare meglio quello che vuoi fare (magari con casi d'uso ,
 > una bozza del manuale del prodotto finito, un prototipo, un
 > cronogramma di lavoro un diagramma delle classi, l'individuazione del 
 > target di riferimento aprendo un progetto su 
sourceforge.net
 > e schiaffandoci tutto questo materiale preparativo) e poi una volta
 > fatto questo tornare qua e dire: ragazzi, ho in mente questo, come
 > vedete so bene cosa voglio ed ho già pianificato tutto, chi vuole
 > farlo con me?
Hai ragione, in realtà ho già analizzato il problema e iniziato a 
scrivere le classi. Inoltre avevo in mente di aprire un progetto su 
sourceforge. Tuttavia speravo di affrontare il problema di persona, ma 
capisco di aver sbagliato e di ciò mi scuso. Avrei dovuto dare maggiori 
dettagli e non aspettare che questi mi venissero chiesti. Ma io ho un 
approccio ellenico verso le problematiche scritto-orale, e ciò non è 
ottimale su un ng.
 > Io personalmete, compatibilmente con i miei impegni una mano te la
 > darei, ma a patto di imbarcarmi conoscendo prima capitano, vascello,
 > equipaggio, rotta, traguardo e premio.
Ti assicuro che me la hai gia data una mano facendomi capire l'errore da 
mecommesso nella stesura della richiesta di collaborazione.
 > p.s. non si è capito (almeno io non l'ho capito) se cerchi uno
 > sviluppatore che implementi per te il progetto o un co-programmatore.
Speravo questo si evincesse dal mio CV, di cui avevo comunicato 
l'indirizzo ove vederlo. Stavo cercando un altro sviluppatore.
Ciao e spero di sentiti ancora.
Silvano Catinella

 Ti invito a leggere i paragrafi introduttivi dei libri della O'Reilly
Ho imparato buona parte di quello che so su Perl usando "Programming
Perl (3rd Edition)", della O'Reilly.
Saluti,
Lobster

 
Sono d'accordo con te. Nel mio post sono stato poco chiaro.
Saluti,
Lobster

 Perl (3rd Edition)", della O'Reilly.
Spero di non essere risultato borioso nell'affermazione sui libri O'Reilly.
"Programming Perl" è un testo di ottima qualità (anch'io l'ho letto), 
ultimamente sto leggendo "Advanced Perl Programming"... comunque, quello 
che volevo dire è che, nei suddetti testi, la filosofia del Perl è 
spiegata molto chiaramente seppure in modo sintetico (come daltraparte 
l'oggetto del discorso) e quindi spesso ostico.
Saluti
Silvano Catinella

 generale: una hash con un puntatore collegato.
Peccato che, quando si parla di programmazione a oggetti, la legge generale
dovrebbe invece essere proprio "ogni cosa è un oggetto" :-)
Massimo

 dovrebbe invece essere proprio "ogni cosa è un oggetto" :-)
non mi pare d'aver mai letto che la metodologia implementativa dell'OOP 
"deve" seguire uno schema particolare, forse tu parli di religione??
Vediamo.... "Programmazione orientata agli oggetti" di J. Cox 1990, "The 
C++ Programming" di Stroustrup, "Thinking in C++" (questo lo dovrei 
riguardare), e altri... NESSUNO asserice ciò che tu riporti come verità 
bibblica. Allora chi decide la legge generale? tu???????
Per quanto mi riguarda è palese che leggi diverse che spiegano fenomeni 
diversi, o aspetti differenti di un egual fenomeno, possono coesistere 
avendo il massimo grado di generalizzazione all'interno del loro "piano 
di esisteza".
Sei un meccanicista? credi nell'unificazione delle forze? ahahahahaah... 
bhe mi spiace darti questo dolore, ma Heisemberg (spero sia corretto) 
dimostra che di fatto il meccanicismo è una favoletta ottimistica.
Inoltre nel C++ non tutto è un oggetto: i metodi per esempio.... 
Quindi, secondo te, il C++ non è OOP??????
Una legge, in senso lato, è solamente la modellizzazione di un aspetto 
o, se preferisci: una fnzione che descrive un insieme di oggetti 
appartenenti al suo dominio.