[Python] Proposta di collaborazione

[enrico franchi]

2015-04-20 11:49 GMT+01:00 Strap <lab a strap.it>:

> Un interessante punto di vista: http://bit.ly/1bjQvpy
>

Ma si... solito discorso. C'era anche quello che aveva proposto un modello
"3 innovation token" per prodotto. Il che ha senso: se fai tutto bleeding
edge l'unica cosa di bleeding saranno le chiappe di chi deve mantenere il
tutto. Il corollario e' che i token e' meglio spenderli per la roba che
importa davvero, piuttosto che per l'infrastruttura (vero: ai tuoi utenti
interessa relativamente poco quale sia il db che usi, fintanto che il
servizio che offri funziona bene).

Il problema e' che la definizione di "maturo" andrebbe un pochetto staccata
dalla definizione di "vecchio" e di "lo usano tutti". E' vero che essere
vecchio e usato da tutti aiuta molto per maturare, ma non e' che sia per
forza un se e solo se.

In particolare, nel post la sopra secondo me insieme a frasi estremamente
sagge, sta facendo del gran FUD.

Il punto fondamentale e' che se hai le persone che lo sanno fare (ovvero,
riesci a trovarle, riesci a pagarle, riesci a tenertele) cancelli qualunque
difetto di un prodotto. Con le persone giuste fai scalare quasi qualunque
cosa, fai andare forte quasi qualunque cosa. Voglio dire... PHP va troppo
piano per Facebook? Ok, riscriviamo PHP. Lo hanno fatto. Due volte.

Pero' probabilmente l'azienda media la fuori non ha le risorse per
riscrivere PHP. E se PHP va troppo piano, e' meglio che passino a Java che
con un minimo di buon senso va ragionevolmente forte e non e'
drammaticamente complesso da fare scalare.

Ah, e in tutto questo probabilmente falliranno il loro scopo perche' non
avranno in casa le competenze (no, un corso di formazione e un po' di ore
di un consulente non combinano un tubo). E probabilmente il loro problema
in principio non era che PHP non andava abbastanza forte, ma semplicemente
che la gente che avevano assunto non era in grado di fare andare PHP
abbastanza forte. Si, l'esempio usa due tecnologie poco amate qui *apposta*.

Quindi, quando l'autore dice che tirare tecnologie a caso in un progetto
(o, appena meglio, scegliere sempre i top ranker di reddit) non e' molto
saggio, ha ragione. Quando dice che "a noi MySQL funziona bene", sta
dicendo che il loro know how interno sommato a quanto adatto e' MySQL per
quello che devono fare, e' sufficiente per farlo funzionare bene.

Quando dico che MySQL fa schifo, in effetti intendo che la quantita' di
risorse che devo investirci per farlo andare decentemente e' inutilmente
alta e che con PostgreSQL posso fare funzionare le cose con uno sforzo
molto minore (per qualche definizione di funzionare). Poi ci sono anche
tecnologie che proprio non funzionano o tendono a funzionare male qualunque
livello di cura ci metti sopra. MySQL qualche anno fa era in questo
stato... adesso piano piano stanno aggiustando un sacco di problemi. Io
continuo a preferire Postgre i cui sviluppatori invece che spendere tempo
in risolvere problemi che non sarebbero manco dovuto esistere lo possono
spendere per darmi tecnologia assolutamente favolosa.

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150420/7de3d7fc/attachment-0001.html>