cstrap commented 7 years ago

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#legacy

Parlo per Django, Web2py l'ho usato in passato, ma i concetti sono molto simili.

Django e Web2Py hanno il concetto di applicazioni, come gli application server Java.

Le applicazioni, in Django, sono delle librerie che vanno ad arricchire il progetto. Tali applicazioni possono essere esterne o interne al progetto, utilizzando il file di requirements.txt. Tra l'altro anche le applicazioni sviluppate "internamente" potrebbero risiedere in un repository privato. Per Java c'e` maven central (o non mi ricordo come si chiama), giusto per far capire il concetto di libreria esterna. Chiaro, per Ruby ci sono le gemme. Non ho idea se una gemma possa essere una "pluggable app" per rails, ad esempio che si arrangia a fare tutto il giro di registrazione utente o qualche altra cosa, anche un CMS.

Non so se abbia senso dato che non si fa deploy con i war ma con i sorgenti.

Il deploy lo fai con i sorgenti, anche se in Django potenzialmente hai la possibilita` di pacchettizzare il tuo progetto e installarlo come se fosse un package.

Forse è un modo per far sentire a casa gli sviluppatori Java del 2005.

Direi di no, utilizzavo Java proprio in quel periodo e non vedo somiglianze, anzi...

Di sicuro Rails è andato bene con una sola applicazione per istanza.

Anche Django fa cosi, non si fanno girare piu applicazioni. Che poi la tua applicazione abbia tanti componenti (che guarda caso in Django si chiamano applicazioni) girano sempre sullo stesso server per un fine comune.

Riassumo: applicazione Django == package Python == gemma Ruby. Joke: se fossimo in JavaScript avrei dovuto utilizzare === e in PHP ==== :-D

Se ne serve una seconda sullo stesso server, si lancia un altro interprete Ruby con un'altra applicazione. E' utile anche per il parallelismo, che come in Python è per processo.

Come per django, se serve un'altra istanza del progetto lo si lancia con un altro interprete.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#il-deploy

In realtà nulla vieta di usare Capistrano anche per Python ma è strano che non esista uno strumento nativo.

Vero non esiste uno standard, esistono diversi package che automatizzano il processo di deploy, ad esempio fabric e Ansible.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#migrazioni-dry

I file dei modelli di Django si possono mettere ovunque, basta che ci sia un file models.py (devono stare tutti nello stesso file) e una directory migrations/ con dentro un init.py. Dovrebbe farlo Django in automatico. Per fortuna li si possono estrarre in file separati da importare da dentro models.py. Brutto default indurre lo sviluppatore a mettere tutti i modelli insieme.

Per spacchettare il file models.py lo si fa diventare un package, riporto l'esempio di django-cms: https://github.com/divio/django-cms/tree/release/3.4.x/cms/models

Rails invece fa autodiscovery degli attributi e la sua truth è lo schema del DB. Qual è la scelta migliore? Probabilmente sono sbagliate entrambe, chi più, chi meno.

Anche django lo puofare per creare i models, se il db esiste gia, altrimenti django non edatabase-driven, quindi si scrivono i modelli e man mano il db viene arricchito. Se ROR e ancora database driven, significa che lo sviluppatore dovrascrivere prima il db e poi iniziare a sviluppare, ecco, questo approccio a me, non e mai piaciuto. Chiaro che mi affido totalmente alla bontadell'orm, nulla vieta ad andare a fare fine tuning sul db, ma l'orm di django e sufficientemente potente e versatile da rendere il tuning prossimo allo zero (e dipende sempre da cosa stai sviluppando...)

Notare che benché le migrazioni di Rails siano tutte in db/migrations e i modelli tutti in app/models, anche con Rails si possono spargere file ovunque. Il metodo standard è creare gemme con le loro migrazioni, controller, modelli, viste, asset etc. È più laborioso che scrivere il codice tutto nell'app principale e quindi Rails non invoglia a farlo. Cattivo default?

Esattamente quello che succede in django: ciascuna applicazione (che alla fine e` un package, quindi paragonabile ad una gemma Ruby) mantiene al proprio interno le migrazioni.

Uno dei problemi con l'approccio di Django è che se per caso un modello sparisce per errore, poi manage.py makemigrations genera la DROP TABLE e si posso perdere i dati. Con Rails uno sviluppatore deve scrivere esplicitamente il comando di drop.

Qui sta allo sviluppatore, visto che ha la possibilitadi lanciare le migrazioni con un--dry-rune vedere cosa succede. Sempre lo sviluppatore dovrebbe aver un sentore che qualcosa non va se un model e sparito per caso :-)

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#import-automatico-vs-esplicito

>>> import this
The Zen of Python, by Tim Peters
...
Explicit is better than implicit.
...

In rare occasioni Rails può dare conflitti (uno o due in 10 anni nel mio caso) mentre Django obbliga a riempire il codice di import. Idem per la shell, che così diventa un po' meno efficiente.

E` una scelta, anche in Java si deve importare il mondo e anche in C, C++ e altri linguaggi :-D Non lo vedo un difetto, ma una scelta.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#fatica

ma davvero si vuol pagare questo prezzo ogni singola volta?

Non capisco. Mancano degli esempi concreti.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#templating

Il linguaggio di templating di Django purtroppo non è Python, ma un linguaggio molto limitato con lo scopo dichiarato di costringere lo sviluppatore a preparare tutti i dati nelle view (il controller) e non angustiare il designer con codici strani per lui.

A dire il vero si puoutilizzare jinja, ma il template engine di django e in grado di gestire le situazioni piu` comuni.

Quel che si sarebbe fatto in pochi secondi costa dieci minuti tra cercare, pensare, scrivere. Moltiplicandolo per un po' di occorrenze il costo per il cliente sale.

La risposta eche potresti preparare diversamente nel contesto la lista da mostrare, magari utilizzando lenamedtuple` Questo dipende molto dalla conoscenza del framework, ma anche della standard lib di Python.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#alto-livello-vs-basso-livello

Il misterioso file init.py deve essere presente in una directo...

Qui e` spiegato molto bene: http://chimera.labs.oreilly.com/books/1230000000393/ch10.html

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#mixed-paradigm

I file si possono spostare in altre directory e il nome del modulo cambia senza traccia né dentro al file stesso né in quelli dove è usato. Credo un male. È un linguaggio un po' disordinato...

Se usi un modulo si` non cambia, ma se usi un package qualcosa si rompe, vedi punto precedente.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#funzioni-predefinite

sort() e sorted

sort eun metodo,sortede una funzione che accetta un iterable e puoi applicare anche una funzione di ordinamento. Quindi qualsiasi oggetto con un metodo __iter__ puo` essere ordinato con la funzione sort.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#iteratori

Perché si deve affaticare lo sviluppatore e non si disegna un linguaggio dove basta questo?

Perchein Python c'e il concetto di generators che serve essenzialmente a non sprecare memoria, ma soprattutto "dealing with GIL".

ruby-python-elixir-reia.md#error-reporting

In Python 3 le eccezioni sono piu` puntuali, non mi fermerei al framework.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#string-join-e-split

Le stringhe hanno il metodo split() e join(), credo sia una questione di stile :-) Di nuovo, il metodo join() accetta un iterable, l'iterable potrebbe esser una lista di numeri, tuple ecc, che andranno opportunamente gestite per convertire i valori in stringa.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#fatiche-di-sintassi

I due punti

Parere personale, non credo arricchisca il vaolre della discussione.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#la-spaziatura

Conta, come la scelta del tab, dei quattro spazi. Volendo puoi indentare il codice con uno spazio, l'importatne e` esser coerenti

Se il problema ecopiare o incollare in una REPL... allora ipython e la soluzione.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#do-end

In Python si scrive di meno. Si paga il prezzo di possibili bug con gli spazi sintattici. De gustibus. Personalmente non disegnerei mai un linguaggio con spazio significativo. Lo spazio è solo per l'occhio, non per il compilatore. Non dopo le schede perforate.

Python obbliga lo sviluppatore ad indentare, questa critica esollevata da molti amici sviluppatori Java. De gustibus anche disegnare un linguaggio con spaziatura significativa, a mio avviso e un punto di forza di Python.

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#la-virgola-che-non-si-vede

Sono tuple... e` questione di linguaggio :-)

>>> type((2))
<type 'int'>
>>> type((2,))
<type 'tuple'>
>>>

https://github.com/pmontrasio/rubynights-20170301/blob/master/ruby-python-elixir-reia.md#interpolazione-di-stringhe

https://pyformat.info/