Newsgroup: it.comp.macintosh
Titolo: Programmare per il web...

Salve a tutti ragazzi,
Questo inverno ho deciso di ampliare i miei orizzonti di programmazione.
Vorrei iniziare a lavorare un pò sul web, niente di speciale e niente di
professionale piuttosto una curiosità mia.
Ho già un libro di PHP 5 & MySql e per quanto poi non ami come è
strutturato questo linguaggio per certe cose mi risulta comodo. Tuttavia
vedo che parecchie persone qui dentro lo snobbano a favore di Ruby? Ruby
on Rails? Python? Perl?
Insomma ho un pò di confusione. Che linguaggio o framework o quello che
volete voi mi consigliate per fare roba seria (per me è un gioco però
non voglio giocare con i giocattoli....tiè che frase)? Domani forse
torno nella mia amata capitale e con l'occasione cerco qualche buon
libro su quello che mi consiglierete.
Fatemi sapere, grazie mille.
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 
malcom, non c'entra nulla, ma non si può provare nemo?
ricordo di essermi iscritto alla newsletter (o quel che era), ma non ho 
saputo più nulla!
alecs.

 Fatemi sapere, grazie mille.
Il mio personalissimo consiglio è Perl come linguaggio e Catalyst come 
framework:
http://www.catalystframework.org/
Questo ad esempio è stato realizzato con Catalyst:
http://www.editgrid.com/new
(prova ad usarlo anche con la tastiera).
E se sei daa capitale, te poi iscrive a Roma.pm
http://roma.pm.org/
che è un gruppo di cultori del Perl, e più ancora della porchetta.
Ciao,
Emanuele.
-- 
What does VISTA mean?
Viruses, Infections, Spyware, Trojan horses & Adware.

 on Rails? Python? Perl?
Di tutti quelli che hai nominato, PHP è certamente il peggiore. Peggiore
anche di alcuni che non hai nominato (tipo servlet java, jsp e
ambaradan).
Io personalmente (e lo dico da Pythonista) ti consiglio Ruby e Rails
(nel senso che Rails è un framework scritto in Ruby).
Ruby è uno splendido linguaggio di per se (come lo è Python) che vale la
pena di essere conosciuto: apre la mente. È comodo e lo puoi usare per
un sacco di altre cose, ivi inclusa la programmazione di tutti i giorni.
Le librerie sono immense.
Rails è un framework per sviluppare web davvero ben fatto. Usa
pienamente il macro-pattern MVC e fornisce un semplice (ma efficace)
mappatore relazionale-ad-oggetti.
Inoltre ragiona benissimo con Javascript (che puoi scrivere in Ruby
stesso) e AJAX.
Framework del genere ne esistono anche per Python (e immagino per Perl),
tuttavia a mio avviso non sono altrettanto supportati e maturi, pur
essendo magari in determinati punti migliori di Rails stesso.
La comunità è attiva e IMHO è un ottimo investimento per il futuro.
Ad ogni modo un programmatore un minimo skillato Ruby lo impara in due o
tre giorni (e altrettanti Python). Rails poco di più. IMHO in grosso
modo una settimana scarsa sai già tutto quello che ti serve per scrivere
roba che al limite puoi anche spedire in produzione.
Le parole chiave sono:
1) Test
2) Test
3) Test
In particolare:
1) Unit tests
2) Functiona tests
3) Integration tests
*e* *prima* scrivere i test, poi il codice che passa i test.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 non voglio giocare con i giocattoli....tiè che frase)?
Come ti consiglia anche il Franchi, se stai cominciando da zero e puoi
scegliere, parti con Rails, Ruby lo impari in un paio di giorni, per il
framework ti consiglio il libro "Agile Web Development with Rails". Dovrai
imparare anche l'html e il javascript, ma non e' difficilissimo.
-- 
"We're just two lost souls swimming in a fish bowl -
year after year"

 imparare anche l'html e il javascript, ma non e' difficilissimo.
Si ma imparare HTML e Javascript (ammesso che non li conosca) li
dovrebbe imparare anche con qualunque altra cosa.


 dovrebbe imparare anche con qualunque altra cosa.
Ho visto i video di Ruby on Rails... sembra abbastanza sfizioso!
Però mi sorge una domanda: ci sono servizi di hosting che lo supportano??

 *e* *prima* scrivere i test, poi il codice che passa i test.
ecco, questa secondo me e' una grande puttanata. mi da' l'impressione
che poi non si dia all'algoritmo (o al pezzo di codice che deve passare
il test) l'attenzione che si merita.
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 Perň mi sorge una domanda: ci sono servizi di hosting che lo supportano??
A tonnellate direi. TextDrive, DreamHost, PlanetArgon, WebFaction solo
per elencare i piů noti.
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 per elencare i più noti.
ar ub gebingb hab vyyvzvgngb r tenghvgb trfgvgb qn ha vaqvnab... :C


 dovrebbe imparare anche con qualunque altra cosa.
Ah questi matematici :D
[Comunque presa una tecnologia server-side,] dovrai imparare anche l'html e
il javascript, ma non e' difficilissimo.
-- 


:

Si, cerca nel wiki.
Io sono su PlanetArgon.
  ngw

 ar ub gebingb hab vyyvzvgngb r tenghvgb trfgvgb qn ha vaqvnab... :C
Jurer, cyrnfr yvax!! :-)

 per elencare i piů noti.
Grazie!

ngw ha scritto:

Grazie anche a te!




 Le librerie sono immense.
Interessante risposta... ma mi viene un dubbio: ho provato python, e per 
il web funziona come cgi (non ho provato frameworks). Non č piů lento, 
rispetto ad esempio a php (che, beninteso, non sopporto).
ciao e grazie
m.


Grazie!

-Hakuin <s_inco...@hotmeil.com.invalid>:

Non usare CGI, usa FastCGI o SCGI.
  ngw

 Però mi sorge una domanda: ci sono servizi di hosting che lo supportano??
Yessir. Io ne ho pure uno.





 rispetto ad esempio a php (che, beninteso, non sopporto).
Ma non č vero. Ci sono circa un fracco di modi per fare girare Python
sul web. cgi, fastcgi, mod_python, server twisted dedicato... 
Detto questo veloce o lento ha un significato relativo: quello che conta
č che sia "veloce abbastanza".


 per elencare i più noti.
Site5...


 ar ub gebingb hab vyyvzvgngb r tenghvgb trfgvgb qn ha vaqvnab... :C
dove?



bello...


 il javascript, ma non e' difficilissimo.
Volevo solo che fosse chiaro che non è che sia una cosa da fare "in più"
per Rails. Anzi, volendo con Rails Javascript lo può trascurare e andare
di RJS... 



ti registri e scarichi, questo non appena riesco a pagare il dominio
altirmenti nisba.
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 una pratica *molto* consigliata.
anche win e' molto consigliato...


 anche win e' molto consigliato...
Direi che il paragone non calza


 Direi che il paragone non calza
dipende.


 TDD č una tecnica di progettazione e non solo di test.
[cut]
dio ci salvi dagli ingegneri informatici... :)
-- 
Non si fo credito

 anche win e' molto consigliato...
No. Direi che non sei molto familiare con le tecniche di sviluppo agile.
Forse ne avrai sentito parlare di sfuggita.


 dio ci salvi dagli ingegneri informatici... :)
Non capisco...


 Non capisco...
e' questo il punto. :)


 Forse ne avrai sentito parlare di sfuggita.
no ne so abbastanza. ma non sono d'accordo con questo paradigma di
progettazione del software. 


 Non capisco...
uhm... lapsus freudiano: pensavo "ingegneri del software" ed e' venuto
fuori informatici.
Riguardo alla boutade, non penso che sara' una metodologia piuttosto che
un'altra a salvare il mondo...


 è che sia "veloce abbastanza".
Bella, mi piace questa cosa. Veloce abbastanza nel funzionare e anche da 
sviluppare... :)
ciao

 dipende.
sono tutt'orecchi.


 progettazione del software. 
Non è dogmatico, nessuno ti obbliga a sviluppare in TDD. Mi domando
perchè non sei d'accordo comunque. 


 un'altra a salvare il mondo...
Nemmeno chi conta veramente sta salvando il mondo :-)
Ad ogni modo è una metodologia che funziona. Poi tu sei libero di non
usarla (non è di certo l'unica che funziona)


 usarla (non č di certo l'unica che funziona)
per carita', ce n'e' di piu' aberranti...


 per carita', ce n'e' di piu' aberranti...
Mi domando cosa c'è di aberrante nel TDD allora :-)


 perchè non sei d'accordo comunque. 
Infatti. Sarebbe vedere sulla base di cosa viene data questa opinione.


 un'altra a salvare il mondo...
Certo che no. Non salverà il mondo (a meno che non venga impiegata per
sviluppare il software che piloterà lo shuttle che porterà Bruce Willis
o chi per lui a fare scoppiare qualche bomba atomica sul prossimo
meteorite in collisione con la terra).
Ma questo non significa che non sia un'eccellente metodologia e che per
adesso sia senza dubbio una fra quelle che portano maggiori
miglioramenti nel processo di produzione del software.


 per carita', ce n'e' di piu' aberranti...
Non vedo cosa ci sia di aberrante nel TDD.
Ma le spiegazioni vedo che latitano.


 on Rails? Python? Perl?
Tranne Python che rimane un grosso buco nella mia cultura, i linguaggi
che hai citato li ho passati un po' tutti, per il web o per altro a
seconda... faccio prima a dirti cosa ci ho combinato e quali sono state
le mie impressioni.
PHP: ho iniziato con il PHP4 dovendo far manutenzione su un forum
scritto molto male (ma veramente, veramente male). Primo impatto con la
programmazione web, con i form... prima di quello avevo solo una
preparazione accademica in C, Pascal, Java, un po' di Assembly, ma in
pratica vale a dire niente, non avevo ancora sviliuppato applicazioni e
ragionavo ancora a procedure.
Il forum in questione è il compendio di ciò che NON si dovrebbe fare
nella programmazione web: un'unica grande palla di codice dove non ci
sono neanche le procedure, bensì lunghe catene di if inframmezzate
nell'HTML, con dentro anche le query SQL, naturalmente. Per non parlare
poi dello schema dati demenziale... mah! manco quando programmavo in
Basic programmavo così, e pur non avendo nessuna esperienza di
database, lo capivo intuitivamente che le cose non andavano fatte
così. Ho visto che Lawrence è intervenuto in questo thread -- se mi
legge probabilmente se la starà ridendo, perché per un po' ha
partecipato anche lui a quel forum disastrato. :-D
Il problema del PHP a mio avviso è un po' questo: "sviluppo rapido" a
tutti i costi, tonnellate di libri a disposizione dei principianti, ma
c'è una scelta talmente ampia che è difficile trovare un buon libro
che ti insegni *anche* a sviluppare con criterio. Purtroppo noto una
certa tendenza alla gratificazione istantanea con la paginetta che
"funziona", ma in quel che ho letto in giro non si dava mai la giusta
importanza alla strutturazione a oggetti e alla separazione tra logica
e presentazione. A questa conclusione ci sono arrivato perché ho letto
quei corsi on-line (libri sul PHP non ne ho comprati), ho provato a
fare i miei progetti, mi sono impantanato, ho capito dove sbagliavo, mi
sono corretto nei progetti successivi, ma il naso comunque l'ho
sbattuto e non ero stato preavvisato.
PHP fa un sacco di cose, ma a mio avviso è troppo imperniato sul web
(difficilmente lo si userebbe per altro), e ha tante, troppe
inconsistenze nei nomi delle funzioni, per non parlare poi del fatto
che ogni versione maggiore non è mai del tutto compatibile con le
precedenti -- cioè un programma che su PHP4 funzionava, sul 5 magari
non funziona più... e non programmini del cavolo, ma robe "toste" e
diffusissime come phpBB, che ha dovuto essere esplicitamente adattato a
PHP5.
Insomma, PHP lo usano tutti, l'ho usato anch'io, è facile da imparare,
ma non mi piace: troppo "canna al vento" secondo me.
Perl: eh... il Perl l'ho amato, per un po'. È veloce da imparare, è
persino decentemente veloce ad eseguire il codice (non è così
importante ma male non fa), ha moduli per fare TUTTO, sia in ambito web
che non, è ben documentato, meno "modaiolo" di PHP quindi più stabile
(per lo meno uno script Perl4 gira sull'interprete Perl5). Le
espressioni regolari sono il suo pane quotidiano, la loro sintassi è
la più compatta in assoluto e per me la cosa conta, ma veniamo ai
difetti...
1) "TIMTOWTDI", "There Is More Than One Way To Do It". Boh, non mi
convince. Non ne sento un gran bisogno, tant'è che in genere scelgo
uno tra i tanti modi di fare le cose e poi uso sempre quello, per il
piacere dei miei occhi e di quelli che leggono il mio codice.
2) Non è a oggetti, e diciamocelo: la programmazione "seria" di tutto
ciò che non è un sistema embedded si fa a oggetti. Vista questa grave
mancanza, gli oggetti sono stati "hackati" dentro, funzionano, sono
anche carini, ma resta il fatto che sono stati hackati e che se il
programmatore non è terribilmente auto-disciplinato, questo hack gli
si ritorce contro. Penso che per programmare a oggetti in Perl serva
una buona esperienza di programmazione a oggetti in un altro
linguaggio, e capire in cosa il Perl è diverso, altrimenti è un
suicidio.
3) Qual è il framework di riferimento? Che tipo di supporto c'è? Boh.
Framework ce ne sono diversi, ma non ho mai capito quale sia quello
"ufficiale" o circa-tale. PHP lo usano tutti ed è supportatissimo (per
quanto brutto), Perl è molto meno diffuso, o meglio, era molto diffuso
in passato sotto forma di CGI, *prima* che emergessero i framework per
il web, prima dell'esplosione di PHP.
Ciò nonostante, il Perl in assoluto mi piace perché fa di tutto e di
più, e se sei auto-disciplinato, è più pulito del PHP... peccato che
per il web, mah, l'ho visto usare quasi sempre con l'interfaccia CGI e
quindi non saprei dirti se ci siano dei buoni framework (pare di sì
comunque).
Python: passo la mano, non lo conosco. Però mi ero messo a studiarlo
un pochino (i soliti esercizietti didattici), non mi piace che mi
imponga l'indentazione anche se sono un maniaco dell'indentazione, e
non ero riuscito a ingranare in fretta, cosa che con Ruby invece mi è
riuscita.
Ruby: è geniale, lo adoro! :-D Tra tutti è in assoluto il mio
linguaggio preferito, e sì che col Perl mi sono divertito parecchio...
però Ruby lo surclassa perché fa le stesse cose, niente di meno, in
modo pulito. C'è anche lì un po' di eclettismo, ma è un eclettismo
chiaro, non fuorviante. Per intenderci: se hai bisogno di scrivere uno
scriptino "usa e getta", niente ti impedisce di scriverlo a procedure,
visto che di fatto sono metodi di un oggetto implicito. Da questo punto
di vista è all'esatto opposto del Perl: in Perl hai degli oggetti che
sono di fatto degli hash particolari, i metodi sono di fatto dei
puntatori a funzione, e la sintassi incolla insieme le cose in modo che
ti sembri di avere a che fare con degli oggetti. In Ruby invece tutti i
dati sono degli oggetti, tutte le operazioni sono dei metodi, e se puoi
scrivere "2 + 2" è perché è una semplificazione sintattica che in
realtà intende "2.+(2)" e niente sfugge a questa regola.
Il che ha delle interessanti implicazioni perché puoi ridefinire
qualsiasi metodo di qualsiasi oggetto, persino a run-time... il che
apre delle possibilità allucinanti sulle quali non mi dilungo perché
questo post è già abbastanza lungo così.
Ruby è spettacolare per come permetta di scrivere programmi chiari e
concisi: solitamente ho delle serie difficoltà a scrivere metodi più
lunghi di 10 righe. Tanto per dirne una, ho implementato un piccolo
server monoprocesso ma multitask che controlla una batteria di modem
per fare delle chiamate in 560 righe, tutto compreso (gestione dei
timeout, callback, un generico gestore di risorse riutilizzabile, etc.)
Gasato da questo risultato, ho provato a riscrivere un pezzo del forum
di cui parlavo sopra in Ruby, e il risultato è stato che a parità di
funzionalità mi è venuto 1/3 del codice... e questo senza usare
Rails, che è un capitolo a parte.
Rails, parliamone. A mio avviso, NON è facile da imparare come
dicono... specialmente se arrivi da PHP, imparare il modello MVC non è
immediato, e quand'anche riesci a capire come gira (non
difficilissimo), ti resta comunque da orientarti in un'API vasta e
documentata solo da una guida di riferimento. I corsi che ho trovato in
giro sono troppo basilari per farci qualcosa di veramente utile, quindi
di tempo per capire cosa Rails può fare al posto tuo ne devi investire
un bel po'. Però ne vale la pena, perché quando incominci a
orientartici un po', ti rendi conto che il codice che ti tocca scrivere
è veramente pochissimo, quasi al limite del ridicolo. L'unica cosa che
un po' mi spaventa è il "deployment", che non ho ancora provato a fare
e che richiede una configurazione particolare di Apache, tra fastcgi e
mod_rewrite... mah, staremo a vedere.
Inoltre ho letto in giro che esistono framework MVC sia per Python che
per PHP, ma non li ho provati quindi il mio resoconto è parziale...
d'altro canto ho intenzione di restare su Ruby per un bel po', perché
Rails è un bel framework, e prima ancora, Ruby è un linguaggio di una
potenza e di una semplicità tale che bisogna bisogna provarlo per
crederci. Tanto per fare un esempio semplice semplice: dopo aver
mappato senza troppe difficoltà il database esistente del forum di cui
sopra sugli active record di Rails, posso cercare i miei post in un
dato forum con questa chiamata:
@posts = Post.find_all_by_fid_and_author(98, "wiz")
Il metodo viene generato al volo dal framework! E se non bastasse
questo a farti sbavare, nel codice si possono inserire dei breakpoint,
dopo di che ti connetti a un server con una console apposita, e quando
l'esecuzione incontra un breakpoint la console si attiva e puoi
ispezionare gli oggetti, modificarli e addirittura modificare il codice
al volo! Quando l'ho visto però non sono rimasto più di tanto
sorpreso perché lo avevo già fatto con il serverino di cui parlavo
prima, ma quando l'ho fatto vedere ai miei colleghi sono giustamente
rimasti a bocca aperta. ;-)
Bon, penso di aver detto tutto quello che potevo dire in proposito, e
forse anche di più. ;-)

 framework (pare di sì comunque).
Che vuol dire peccato per il web?!
Molti dei portali più sofisticati, ad altro traffico e con i più elevati 
requisiti di sicurezza di tutta Internet, sono scritti in Perl.
Ciao, Emanuele.

 ....
No, anche hackati va bene, cazzata mia sorry ;-)

 No, anche hackati va bene, cazzata mia sorry ;-)
Premesso che fanno schifo tutti e due, "hackerati" è il peggio dei due:
l'hacker è "colui che hacka", quindi meglio "hackati"...
-- 
Ci sono 10 tipi di persone: quelle che capiscono il
sistema binario e quelle che non lo capiscono.

 l'hacker è "colui che hacka", quindi meglio "hackati"...
Appunto, "hackerati" nel senso di "sottoposti all'azione di un hacker", 
che in italiano è certamente più comune e meno cacofonico di "hackati".
Comunque riconosco che hackati (come traduzione di "hacked") in italiano 
  non è peggio di "hackerati" (ma mi sembrava di averlo già detto), e se 
serve ad espiare, posso anche ammettere che è meglio.
Avevi da dire solo questo o c'è anche qualcosa di più pregnante? ;-)

 ma non mi piace: troppo "canna al vento" secondo me.
Penso di essere l'unico essere vivente a non essere riuscito a finire il
tutorial del PHP. 


 lettura, anche per me assolutamente importante :-)
Su questo potresti pure scriverci un tema. Credo che sia semplicemente
una questione di filosofia. Python ha nel suo zen (apri una shell, avvia
python e digita "import this") questa frase: "There should be one-- and
preferably only one --obvious way to do it."
Ovviamente come tutti gli Zen e le filosofie non è 1-1 con la realtà. Ci
sono tonnellate di frameworks web ad esempio in Python e non è vero che
c'è un solo modo per fare ogni tal cosa, ma in genere si tende a
minimizzare il numero di alternative, è questo lo spirito di Python.
Esplicito è meglio di implicito, questo è il suo motto. Non sempre ci
riesce. 
Penso che la chiave sia mediare tra il "o fai cosi o non fai niente" e
il "beh hai 347 modi per fare la stessa cosa".
Personalmente uso Python anche perchè cerca di mediare verso il basso
:-)


 Avevi da dire solo questo o c'č anche qualcosa di piů pregnante? ;-)
Un bel "vaffa" sarebbe abbastanza pregnante? Se vuoi rimedio subito...
:-)


 requisiti di sicurezza di tutta Internet, sono scritti in Perl.
Sfondi una porta aperta: l'altra porcheria su cui faccio manutenzione
(gratis, per giunta) è un forum il cui funzionamento si *basa* su
register_globals -- se conosci PHP sai di che cosa terrificante sto
parlando. Io stesso ho detto nel mio post originale che le prestazioni
di Perl sono sorprendentemente buone per un linguaggio interpretato...
Ad ogni modo, non intendevo fare dell'"advocacy", ma solo dare a
Malcolm il mio punto di vista di uno che sviluppa applicazioni web da
un po' e che di linguaggi per questo scopo ne ha usati tre, li ha
studiati e approfonditi, ha scoperto pro e contro anche sbattendo il
naso: penso che il parere di un non espertissimo ma neanche del tutto
principiante gli possa essere utile, ovviamente ogni informazione
aggiuntiva è benvenuta. Però spero che converrai con me sul fatto che
il Perl sia ormai sempre meno usato in ambito web (e che questo sia un
bene o un male non sta a me stabilirlo, anche perché se fosse per me
avrei fatto a meno di imparare il PHP), e che la sua implementazione
degli oggetti, per quanto effettivamente funzionante e facile da usare,
sia quanto meno discutibile.

 lo so, ed è questo che lo rende il nemico naturale del Perl :-)
Dovresti vedere come programmo io in Perl allora... (-:
- use strict, sempre (beh ma non usarlo è farsi del male)
- assegnamenti il più possibile vicini all'inizio di una procedura
- dereferenziazione dei valori nelle strutture in variabili dai nomi
corti sempre all'inizio della procedura, per non doverlo fare poi,
magari ripetutamente
- tutte le dichiarazioni di variabili all'inizio, tranne che per le
variabili di iterazione che dichiaro solo nel loro scope
- righe mai più lunghe di 80 caratteri
- sintassi strettamente C-like, cioè chiamate a procedura sempre con
parentesi, evitare gli if postposti e gli "unless", preferendo "if
(!$condizione)"
Stranamente però da quando programmo in Ruby sono più "lasco"
sull'ultimo punto, forse perché è un linguaggio molto diverso dal C
almeno nell'aspetto, quindi ogni tanto indulgo all'omissione di
parentesi (ma mai per gli hash, anche se si potrebbe) e occasionalmente
ci scappa anche qualche condizione postposta, se usandola viene fuori
una frase umanamente leggibile. È molto carino infatti usare questa
possibilità con i metodi con i punti interrogativi. (-:
Ecco, in Ruby mi manca un po' il "my": so come funziona lo scope delle
variabili, sono abbastanza ordinato da non cadere in trappola, ma mi
sento un po' un funambolo senza rete.

 l'hacker è "colui che hacka", quindi meglio "hackati"...
Temo purtroppo che "to hack" sia fondamentalmente intraducibile. È quasi
come il verbo "puffare". Ecco... traduciamo "to hack" con "puffare".
Quindi:
Mi hanno puffato il sito.
È un vero puffo.
È un grande puffo.
È Il grande puffo.
Non puoi costruire un programma a suon di puffate.
Sono stato all'incontro dei puffi. (Hack Meeting)
Utilizzare lo switch in questo modo è una puffata astuta.


 rischio il linciaggio per questa dichiarazione.
Evidentemente Apple la pensa come te, visto e considerato che al momento
credo tutti i mac vengano con un mouse a tre bottoni con rotella e che
in breve l'ultimo monotasto sparità dall'AppleStore.
Io personalmente lo trovo estremamente riposante per a mia mano.


 tutorial del PHP. 
Io lo ho studiato per il solo gusto di partecipare ai flames PHP
Sucks... :)


 sento un po' un funambolo senza rete.
Questo *mai*. Il my non lo ho mai apprezzato, ne in Perl, ne analoghi
costrutti. Lo trovo ridondante.
Peraltro ci sono fior di strumenti che mi avvertono se cazzeggio con
variabili non inizializzate (posto che comunque vengono tutte fulminate
al primo rake test:units o analogo),


 Io personalmente lo trovo estremamente riposante per a mia mano.
Come può un bottone in più affaticare la tua mano?
P.S.: io ho il Mighty Mouse, e ho notato che ha una certa tendenza a
intendere il clic sinistro anche se clicco a destra... così alla fine
mi sono abituato a control-cliccare come fanno i Veri Maci-sti ( ;-) ),
ma sta di fatto che alla rotella non ci potrei rinunciare, anzi, trovo
la pallina del Mighty maledettamente comoda rispetto alla rotella di
qualsiasi altro mouse abbia mai usato.
Però che ridere che anche il fatto che l'iPod Shuffle non abbia il
display te lo spaccino come un pregio anziché una palese mancanza.

 costrutti. Lo trovo ridondante.
Sarebbe?


 che Rails giri attraverso CGI (fCGI non c'è, è mal configurato, etc)
Mi risulta che sia pieno di tutorial su come fare andare Rails con
fastcgi o mi sbaglio? 


 rischio il linciaggio per questa dichiarazione.
Si è orribile. Però c'è da dire che m'è venuto anche da ridere leggendo
questo post di Dave Shea sul Mighty mouse:
 
http://www.mezzoblue.com/archives/2006/08/24/mighty_mouse/


 variabili di iterazione che dichiaro solo nel loro scope
Questo non lo faccio pių da quando usavo Turbo Pascal.
Siccome non c'č una forte separazione tra dichiarazione e
inizializzazione in Python come in altri linguaggi dinamici quando mi
serve una label per un valore (una variabile appunto) la uso e basta


 serve una label per un valore (una variabile appunto) la uso e basta
Sì però dichiarando tutte le variabili all'inizio della procedura,
hai il vantaggio che sai esattamente quali variabili saranno
utilizzate, e quando programmo in Perl uso questa sua "costrizione" a
mio favore. Con altri linguaggi invece le variabili non si dichiarano
proprio, quindi fine del problema ma anche dell'implicito vantaggio.

 Ma le spiegazioni vedo che latitano.
Per me č estremamente piů produttivo scrivere test su una implementazione
esistente, anche se estremamente semplice e incompleta, per poi rifattorizzare
in un secondo tempo test e codice man mano che il progetto prende forma.
E' l'inizio che č aberrante, ho tentato e ritentato, non mi č _mai_ capitato
di partire scrivendo un test per poi implementare il codice e non dover
cambiare il test immediatamente perchč l'implementazione del
metodo/funzione/quel che č non corrispondeva a quello che avevo pensato
inizialmente.
Invece se scrivi i test su del codice esistente ti trovi con un minimo di
implementazione su cui far riferimento, e hai esattamente lo stesso effetto
e gli stessi vantaggi, pur risparmiando il passaggio iniziale.
  ngw

 che Rails giri attraverso CGI (fCGI non c'è, è mal configurato, etc)
Ma io direi proprio di no ...
Nulla dei signalers sicuro, nulla tra i 43things/43places, niente della nostra
roba in Assembla, è folle far partire un interprete a processo se non in fase
di sviluppo.
La configurazione tipo e consigliata e che tutti usano, è apache come proxy e n
instanze di mongrel dietro (mongrel-cluster), se non devi tenere in piedi una 
bestia lighty e fcgi/scgi (come profy lighty fa cagare).
CGI è da matti, e non ha senso visto che alla fine configurare il tutto non è
queto incubo, l'ho fatto io ...
  ngw

 Il punto è questo: [...]
Sono assolutamente persuaso che il TTD sia una buona cosa (e sto
cercando di adottarlo in maniera sistematica, e di farlo adottare),
ma secondo me per "venderlo" bisogna evidenziarne un aspetto e 
affrontarne un altro.
L'aspetto da evidenziare è il fatto che il TTD non paga solamente nella
fase di sviluppo (ad esempio per gli effetti collaterali che il TDD ha
sul design, cosa di cui hai già parlato), ma anche e IMO soprattutto
nella fase di modifica.
Se si considera che una parte considerevole del tempo di sviluppo di una
applicazione consiste in refactoring, manutenzione, modifiche per
variazioni o aggiunte ai requisiti, allora è impagabile il fatto di
possedere delle "specifiche eseguibili" che possano in maniera
automatica verificare l'aderenza dell'applicazione a quanto ci si
aspetta da lei.
Il secondo aspetto è il fatto che i test sono difficili da scrivere.
Gli unit test ancora ancora, nella maggior parte dei casi. Ma i 
test di integrazione non altrettanto, ed è molto facile ritrovarsi
impantanati in sistemi difficili o almeno non banali da testare: in 
questi casi gli esempi tipo 
  ok( sum(2, 2), 4 );
che si vedono talvolta nei talk introduttivi suonano più come una presa
per i fondelli :)
S.  
-- 
Stefano Rodighiero      |  
http://larsen.perlmonk.org
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it

 e gli stessi vantaggi, pur risparmiando il passaggio iniziale.
Non sono sicuro che abbia gli stessi vantaggi. Ad ogni modo la chiave di
XP è la flessibilità e l'adattare le metologie a se stessi, non se
stessi alle metodologie.
Ragion per cui fai assolutamente bene a fare come fai (anche perchè
comunque non sono certo io quello che può venire a darti consigli).


 display te lo spaccino come un pregio anziché una palese mancanza.
Ma sinceramente non vedo il problema. Fa parte del concetto di "ad ogni
cosa il suo uso". Non avere il display è una limitazione, vero, ma è
*anche* un vantaggio.
La mia ragazza ha il nano, mio padre lo shuffle. Per esempio per fare
sport etc vedo molto meglio lo shuffle, si rovina meno, si scassa meno,
è molto più robusto, ti da meno pensieri.
Ribadisco: ad ogni cosa il suo uso. Per l'uso dello shuffle, non avere
un display è un vantaggio. Significa che è più robusto, e questo è un
vantaggio.


 Sarebbe?
my $a;
# code...
$a = 5;


 fastcgi o mi sbaglio? 
Certamente. Ma non tutti gli hosting lo fanno (o per lo meno non lo
facevano, ora credo di si).


 quello č Basic :-D
Adesso non sai cosa sta per succedere :)


 forza lo stato privato di una classe, c'č semplicemente una convenzione.
Ecco, ti confesso che io personalmente apprezzerei alquanto che invece
ci fossero delle keyword. Gusto mio eh... in questo mi piace piů Ruby.
Č roba chiaramente modificabile dinamicamente (quindi non mi limita), ma
di per se c'č.
E comunque in uno dei duecento-ottanta-sette framework per sviluppare ad
oggetti in Perl (questo č per wiz) c'č anche il modo per indicare
private public e tutto.


 puntatori a funzione. [...]
Questa affermazione è per metà riduttiva e per metà falsa [1].
Una definizione carina di oggetti in cui mi sono imbattuto è
  "[in Perl] un oggetto è un coso benedetto".
In effetti, in Perl un oggetto è una qualunque reference 
che sia stata sottoposta a blessing. Il blessing lo puoi pensare
come una sorta di battesimo: alla reference viene attribuito un
nome di classe, che servirà da quel momento in poi per determinare
il package (o I package) all'interno del quale andare a cercare
i metodi via via invocati sull'oggetto. 
Nota che (anche se è frequente e tipico), non è assolutamente
obbligatorio che il riferimento "bless()-ato" sia ad un hash. 
Inoltre, è particolarmente inesatta la parte "le cui chiavi 
sono [...] metodi". E` possibile mantenere nell'hashref 
benedetta anche dei riferimenti a funzione, ovviamente, ma i 
metodi stanno solitamente nel package il cui nome corrisponde
alla classe dell'oggetto. 
Se non sbaglio la tua definizione è più calzante per linguaggi
tipo Javascript.
ciao,
S.
[1] Ma restano vere le restanti considerazioni a proposito 
    dell'implementazione dei meccanismi che aiutato a programmare
    ad oggetti sulla base di costrutti pre-esistenti.



S.



ciao,


 quello è Basic :-D
Non ho parlato dei numeri di riga e dei goto...

 ci fossero delle keyword. Gusto mio eh... in questo mi piace più Ruby.
Personalmente preferisco la modalità di Python (convention over
configuration :-P), cosi non capitano casi come in .NET 1.0 che m'era
capitato di trovare una classe che erronaeamente era stata marcata
"sealed" e non avrebbe dovuto esserlo. Nei linguaggi statici se fai un
errore di progettazione di una libreria girarci intorno può essere
penoso, in Python basta accedere alla parte privata segnalandolo in
previsione della prossima relase che corregga il baco. Tutto qui.


 come il verbo "puffare". Ecco... traduciamo "to hack" con "puffare"
"Smanettare" o "manomettere", a seconda delle accezioni =:)

 il Perl sia ormai sempre meno usato in ambito web
Convengo sul fatto che negli ultimi anni Perl abbia perso delle quote di 
mercato (soprattutto a favore di PHP), ma rimane in assoluto uno tra i 
linguaggi più diffusi.
Se diamo un qualche credito a Tiobe, questa è la situazione attuale:
http://www.tiobe.com/tpci.htm
E per quanto riguarda il web, esistono indici di penetrazione ancora più 
attendibili, come ad esempio l'installazione di moduli Apache 
Perl-related rilevata mensilmente da securityspace, la quale mostra, 
ancora una volta, come a tutt'oggi Perl sia secondo solo a PHP in 
termini di diffusione (i moduli Perl-related sono svariati e le loro 
quote vanno sommate: "perl", "Perl", "AxKit", "Embperl" etc.)
http://www.securityspace.com/s_survey/data/man.200607/apachemods.html
Ciao,
Emanuele.

 (!$condizione)"
Anche questa secondo me (e secondo molti altri) è una restrizione 
eccessiva. Benché sia corretto evitare il costrutto:
     unless (condizione) {...} else {...};
invece un costrutto di questo tipo, ad esempio all'interno di un ciclo:
     next unless $last;
risulta estremamente chiaro e leggibile, come del resto avviene con:
     die if $error;
Del resto se lo fai in Ruby, non vedo perché tu non debba farlo in Perl ;-)
Ecco, la filosofia del TIMTOWTDI consiste proprio nell'offrire il 
costrutto più adatto al particolare contesto nel quale ci si trova, un 
po' come avviene per la lingua naturale, che offre sinonimi, idiomi ed 
interpretazioni dipendenti dal contesto (del resto Larry Wall è un 
linguista).
Quella filosofia non suggerisce affatto di scrivere codice 
arlecchinesco, utilizzando ogni volta un costrutto diverso solo per 
divertimento (benché questo possa accadere, da parte di un programmatore 
scadente).
Ciao,
Emanuele.

 :-)
Beh, sarebbe certamente più intelligente di quello che hai scritto fino 
ad ora, e probabilmente una delle più alte produzioni intellettuali di 
tutta la tua significativa esistenza :-)

 e gli stessi vantaggi, pur risparmiando il passaggio iniziale.
Sono sostanzialmente d'accordo con te, nel senso che pur essendo la TDD 
una tecnica validissima, risulta realisticamente praticabile soltanto 
quando le specifiche di progetto sono cristalline, cosa che nella triste 
realtà della vita quotidiana non avviene quasi mai.
Si può solo aggiungere che se non segui rigorosamente la TDD, allora 
diventa vitale l'adozione di strumenti per misurare il test coverage del 
codice medesimo, cosa di cui fortunatamente dispongono tutti i 
principali linguaggi di programmazione (Perl ha Devel::Cover, Python i 
vari moduli *coverage.py ed anche altro, e Ruby rcov).
Giusto un paio di giorni fa ho trovato un bug (introdotto solo 
nell'ultima versione) in quello che è forse il modulo Perl più diffuso 
in assoluto (CGI.pm), dovuto proprio al fatto che una porzione di codice 
non era coperta da test.
Al di là della TDD, è il testing del codice ad essere veramente vitale 
(che, benché possa suonare banale e scontato, è un fatto allegramente 
sottovalutato, anche in ambienti professionali).
Ciao, Emanuele.

 "Smanettare" o "manomettere", a seconda delle accezioni =:)
Non traduce però il "clever hack".


 tutta la tua significativa esistenza :-)
Vedo che non perdi occasione di dimostrare al mondo la tua straordinaria
carica di simpatia...
-- 
Ci sono 10 tipi di persone: quelle che capiscono il
sistema binario e quelle che non lo capiscono.

 Non traduce però il "clever hack".
Cos'è, la variante elettronica del Clever Hans...? :-)


 carica di simpatia...
Invece uno che prima viene a correggerti (su una facezia inconsistente), 
e poi ti manda pure al quel paese, è proprio un gran burlone!
Scusami se non sono fasato sul tuo sense of humor ;-)

 previsione della prossima relase che corregga il baco. Tutto qui.
Infatti io non ti parlo di linguaggi statici. Ti parlavo di Ruby. Dove
se ti serve il metodo fai
class A
  public(m)
end
tutto qui...


 Non ho parlato dei numeri di riga e dei goto...
Il primo basic che ho usato (fine anni ottanta) *non* aveva numeri di
linea e supportava le funzioni, ergo non era punto necessario usare
GOTO.
GOTO che peraltro esiste in C, viene anche usato (ci sono alcuni esempi
celebri) e che se anche non sai di usarlo, usi qualcosa di
concettualmente analogo quando usi uno switch.
Il problema di goto è quando lo usi per muoverti fra pezzi di codice che
sono logicamente delle funzioni, non quando lo usi (limitatamente) per
il flusso di esecuzione all'interno di una stessa funzione.
Anzi, trovo che in un linguaggio senza eccezioni, goto possa tornare
relativamente comodo in un paio di casi.


 l'hacker è "colui che hacka", quindi meglio "hackati"...
Solo una persona molto piena di sé può vedere in questo una correzione e
aversene a male...


 tutto qui...
Beh che cambia dover fare un hack o semplicemente accedere al metodo con
l'underscore?


 relativamente comodo in un paio di casi.
Personalmente l'ho anche usato qualche volta, quando smanettavo nel
codice di Python quest'estate. In Python goto è usato per raggruppare la
finalizzazione di risorse o i messaggi di errore. In fondo in C non hai
gestione di eccezioni...


 aversene a male...
Per carità, semmai era il "vaffa" di cui mi sfuggiva la pregnanza.
OK, quindi, per dirla proprio con le tue parole, un bel "vaffa" può 
chiudere qui la cosa? ;-)