ciao,
qualcuno ha dato un’occhiata a questo:
cosa ne pensate?
grazie
Ciao Roberto,
ci sono tanti elementi interessanti ma mi spaventa un po’ l’insieme di
DSL
e convention derivanti dai componenti che compongono l’architettura.
È differente dall’avere un core snello al quale applicare
indipendentemente
dei PORO o delle librerie più strutturate.
Magari vedere qualche caso d’uso minimalista di Trailblazer potrebbe
rendermi meno scettico.
In Rails, (giusto per poter avere un confronto e a prescindere dalla sua
complessità interna), uno degli usi minimalisti è:
routes.rb
get ‘/foo’, to: ‘welcome#foo’
app/controllers/welcome_controller.rb
class WelcomeController < ApplicationController
def foo
end
end
app/views/welcome/foo.html.erb
Hello World
3 file con un commitment relativamente ridotto.
Ci sono capitato su proprio poco tempo fa.
Ci sono elementi interessanti, ma mi sembra che lavori a livelli di
astrazione un po’ troppo elevati (o, almeno, lo sono per me). E non mi
sembra che aiuti troppo a portare in evidenza il dominio del problema.
Insomma: sposta il problema un po’ più in là, invece che affrontarlo.
Preferisco adottare librerie più piccole, introducendole man mano che
servono e solo dove servono (uso con soddisfazione, per esempio,
GitHub - drapergem/draper: Decorators/View-Models for Rails Applications e
GitHub - trailblazer/reform: Form objects decoupled from models.).
Creo classi che rappresentano un action non appena il controller supera
una
certa soglia di complessità.
My 2 cents,
Silvano
Il giorno 26 giugno 2015 12:52, maurizio de magnis <
[email protected]> ha scritto:
Hello World
cosa ne pensate?
–
Maurizio ಠ_ಠ My profile
https://plus.google.com/100973969013103507046/about
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Considera l’ambiente prima di stampare questa email. Be a total user
rather
than a complete waster.
. . . Silvano S. . . .
❡ email: [email protected]
❡ site: http://www.sistrall.it
★ future: http://contiamoci.com/
★ kitchen: http://keepcooking.it/
2015-06-26 12:52 GMT+02:00 maurizio de magnis
[email protected]:
Ciao Roberto,
ci sono tanti elementi interessanti ma mi spaventa un po’ l’insieme di DSL
e convention derivanti dai componenti che compongono l’architettura.
un dubbio che ho avuto anche io, ma forse inizialmente ho avuto la
stessa
sensazione la prima volta che ho visto rails… poi ci si abitua…
magari avere delle costrizioni nel mettere la roba nel posto giusto
quello che serve a molti, a me sicuramente, per non avere fat model,
violare srp, non avere codice nelle view e nei controller, non avere
validazioni condizionali, e varie amenit del genere…
ovvio che questi sono limiti miei nella modellazione del software ma se
qualcuno, o meglio qualcosa, mi aiuta nel tenere tutto pi ordinato e
pulito e non dovermi interrogare sempre su “questo pezzo di codice dove
lo
metto?” ne sarei felice anche a costo di essere costretto a usare delle
convenzioni.
anzi credo che sia proprio quello che cerco, a meno che non stia
cercando
nella direzione sbagliata…
differente dall’avere un core snello al quale applicare indipendentemente
dei PORO o delle librerie pi strutturate.
ok, ma quali? non mi pare esista una “rails way” per questo.
rails “campa” sulle convenzioni ma quando ora di fare qualcosa al di
fuori di un crud scaffold mi sento lasciato solo in mezzo all’oceano…
rails implementa mvc, ma non c’ solo quel pattern. e gli altri?
come faccio a scrivere del “buon” codice?
esistono delle convenzioni “standard” per farlo? delle gem?
un modo in cui anche chi non ha mai visto il codice capisce che una cosa
deve essere messa in un certo posto perche lo impone una regola (che
poi
quello che anche rails fa), non so se riesco a spiegarmi…
se per esempio voglio seguire dei principi tipo questi
io posso farlo in un modo e tu in un altro (sicuramente migliore del mio
;-P)
sarebbe auspicabile avere un modo comune per farlo che ripeto la stessa
cosa che ha fatto rails per mvc, tutti sappiamo dove mettere il codice
per
le view e dove quello per interfacciarsi ai dati…
Magari vedere qualche caso d’uso minimalista di Trailblazer potrebbe
rendermi meno scettico.
finch non ci si sporca le mani difficile… magari qualcuno ha voglia
di
provarlo e fare un talk al prossimo ruby day…
end
app/views/welcome/foo.html.erb
Hello World
3 file con un commitment relativamente ridotto.
questo vero ma solo per il 10% dei servizi che si vanno a realizzare
nella realt, almeno cos nella mia (poca) esperienza
2015-06-26 13:16 GMT+02:00 Silvano S.
[email protected]:
Ci sono capitato su proprio poco tempo fa.
hai realizzato qualcosa?
in caso sarebbe possibile vederlo?
Ci sono elementi interessanti, ma mi sembra che lavori a livelli di
astrazione un po’ troppo elevati (o, almeno, lo sono per me). E non mi
sembra che aiuti troppo a portare in evidenza il dominio del problema.
Insomma: sposta il problema un po’ pi in l, invece che affrontarlo.
scusa ma non ho capito: cosa intendi per “dominio del problema”?
Preferisco adottare librerie pi piccole, introducendole man mano che
servono e solo dove servono (uso con soddisfazione, per esempio,
GitHub - drapergem/draper: Decorators/View-Models for Rails Applications e GitHub - trailblazer/reform: Form objects decoupled from models.
).
mi sembra giusto usare solo quello che serve.
io ho chiesto di trailbalzer ma in realt mi interessa pi l’approccio.
poi trailblazer, o chi per lui, un insieme di librerie (reform una di
queste) e si possono usare solo quelle che servono di volta in volta.
Creo classi che rappresentano un action non appena il controller supera una
certa soglia di complessit.
ok, ma come dicevo nella risposta a Maurizio esiste un punto d’incontro,
un
modo in cui possiamo uniformarci?
del resto il problema comune a tutti ma ognuno lo risolve a modo
proprio,
non mi sembra molto ingegneristico…
Conosco personalmente Nick ed abbiamo avuto modo di discutere di
Trailblazer in diverse occasioni.
Trailblazer ha diversi concetti interessanti utili a risolvere problemi
che
qualsiasi sviluppatore che lavora in Rails da un po’ di tempo su app di
una
certa complessita’ prima o poi ha incontrato.
In DNSimple abbiamo cominciato ad introdurre diversi pattern anni dopo
formalizzati da Trailblazer.
Personalmente non condivido l’idea di usare Trailblazer semplicemente
perche’ a quel livello voglio avere la liberta’ di poter definire una
soluzione al problema nel modo piu’ efficace rispetto al progetto in cui
sto lavorando.
Per intenderci, in DNSimple abbiamo un concetto molto simile alle
Operations in Trailblazer, ma che meglio si integra col resto delle
convenzioni del progetto.
La mia idea e’ che Trailblazer e’ un ottimo proof of concept e puo’ dare
diversi spunti, ma cercare di incastrare un’applicazione dentro tutte le
convenzioni di Trailblazer mi rimane stretto. Ovviamente, nulla vieta di
adottare quei componenti (e.g. cells) che si ritengono utili a risolvere
uno specifico problema.
Anche in Lotus Luca ha cominciato ad introdurre pattern per risolvere
problemi comuni come le operations (in Lotus si chiamato Interactor e
derivano da un discussione che ebbi con Luca dove gli mostrai come
abbiamo
implemnetato quel pattern in DNSimple).
Come vedi, i problemi alla fine restano gli stessi. Ma in
un’applicazione
medio grande, un livello di formalizzazione dipendende da un framework
come
Trailblazer (o altri simili) potrebbe non garantire l’autonomia che
prima o
poi avrai bisogno per risolvere i problemi in modo efficiente.
Tuttavia, questo concetto si applica a diversi altri campi. Ad esempio,
in
DNSimple abbiamo nel tempo re-implementato diversi punti ciritici come
l’autenticazione invece di adottare prodotti confezionati come Devise
(usavamo Authlogic in principio) perche’ arrivi ad un punto dove
inevitabilmente cerchi di far passare un cilindro (la tua app)
attraverso
un buco quadrato (la lib) e cominciano i workaround.
Il segreto, nonche’ la parte complessa, e’ bilanciare questi due aspetti
tenendo a mente costi e benefici, ovvero tempi ed esigenze.
– Simone
2015-06-26 12:52 GMT+02:00 maurizio de magnis
[email protected]:
Hello World
cosa ne pensate?
–
Maurizio ಠ_ಠ My profile
https://plus.google.com/100973969013103507046/about
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Passionate programmer and dive instructor
Twitter: @weppos https://twitter.com/weppos
Ciao,
Premetto di non aver mai usato Trailblazer, ma l’idea di avere delle DSL
su altre DSL che cambiano velocemente, non mi sembra l’ideale di
manutenibilità da ricercare per una applicazione da mettere in
produzione.
In ogni major release, Rails ha sempre introdotto cambiamenti non
retrocompatibili. Questo potrebbe succedere alle API su cui Trailblazer
si basa. Cercare di usare Rails come una libreria di basso livello
(quale esso non è), aggiunge complessità ulteriore a quella già
esistente.
Condivido molto dei concetti introdotti quali Operation, Cell, Form,
Repesenter, ma è difficile far “cambiare carattere” a Rails.
La sfida che sto portando avanti con Lotus, è quella di andare oltre il
“Flat MVC” di Rails, supportando nativamente i componenti su citati. Da
qui la definizione di “complete web framework”.
Lotus lavora su layer fondamentali (routing + actions), standard
(aggiungi views, templates, models), e opzionali (aggiungi validations,
interactors, presenters).
I primi due layer sono modellati attorno al paradigma MVC. L’idea è
quella di offrire una API di alto livello che sia stabile nel tempo. Ad
esempio, se non cambiano Rack o HTTP, non c’è motivo di cambiare
Lotus::Action. Stessa cosa vale per Model, che espone concetti CRUD, più
query e commands verso un data store. Il giorno in cui CRUD diverrà
obsoleto, cambieremo la libreria, altrimenti resta così com’è.
Questo garantisce una stabilità nel tempo ed una manutenzione del codice
molto bassa.
I layer opzionali, vanno ad integrare quanto sopra descritto, fornendo
un “Full MVC”. Che è quello che manca a Rails, e che Trailblazer cerca
di colmare. Qui si va oltre il blog in 15 minuti. Questi componenti
dovrebbero essere introdotti quanto la complessità dei layer base MVC
diventa non gestibile. Un esempio, rimuovere la logica di presentazione
da un modello o da una view, utilizzando un presenter.
Lotus è production ready? Siamo alla 0.4, quindi la risposta vien da sé.
Credo ci sia bisogno ancora di tempo per fare in modo che il codice
maturi.
Quello che chiediamo sempre a chiunque fosse interessato è di provarlo
per capirne i concetti, ed eventualmente sviluppare una piccola
applicazione non vitale per il vostro business. Anche questo è
contribuire all’Open Source.
D’altro canto, ci sono delle aziende coraggiose che usano Lotus in
produzione o stanno per farlo (DNSimple).
Envato usa delle HTTP API apps per la ricerca
di http://market.envato.com/.
Tatsu è un servizio che basa il suo business interamente su
Lotus https://tatsu.io/.
Credo ci siano anche altre piccole realtà che però sfuggono al mio
network.
Spero di porter approfondire questi discorsi personalmente con voi al
RubyDay.
Luca
Luca, una domanda che volevo fare da tanto riguardo Lotus: per quanto
riguarda connessioni persistenti / server push (websocket, server side
events, etc) ci sono piani di integrazione?
Perdonate l’OT
–
Maurizio De Santis
Il giorno 26 giugno 2015 17:39, Luca G. [email protected] ha
scritto:
2015-06-26 13:24 GMT+02:00 Simone C. [email protected]:
perche’ a quel livello voglio avere la liberta’ di poter definire una
uno specifico problema.Tuttavia, questo concetto si applica a diversi altri campi. Ad esempio, in
DNSimple abbiamo nel tempo re-implementato diversi punti ciritici come
l’autenticazione invece di adottare prodotti confezionati come Devise
(usavamo Authlogic in principio) perche’ arrivi ad un punto dove
inevitabilmente cerchi di far passare un cilindro (la tua app) attraverso
un buco quadrato (la lib) e cominciano i workaround.Il segreto, nonche’ la parte complessa, e’ bilanciare questi due aspetti
tenendo a mente costi e benefici, ovvero tempi ed esigenze.
appunto
chi non in un’azienda (piccola/media/grande/non so…) come pu essere
DNSimple ma un “full stack developer” magari non riesce a implementare
autonomamente dei pattern e alla fine costretto a usare le convenzioni
che rails (o chi per lui) offre (o non offre).
devise noto che viola diversi principi essendo un prodotto che non
‘loosely coupled’ e che attraversa tutto lo stack mvc, ecc… per cui o
ti
va bene cos o devi ricorrere a delle “pezze”.
trailblazer, o meglio le gemme che lo compongono, a prima vista mi
sembrano
meno “pericolose” da questo punto di vista e forse possono lasciare
l’autonomia di cui si ha bisogno (questo naturalmente va verificato “sul
campo”). o magari esistono delle librerie migliori, o un framework
migliore, non so.
lotus l’avevo visto tempo indietro e mi aveva incuriosito. non era per
ancora pronto per andare in produzione per cui non ho approfondito.
magari sarebbe il caso di riguardarci
OT: a proposito ora un prodotto maturo? qualcuno ha esperienze a
riguardo? magari comincio un altra discussione a questo scopo…
Maurizio,
All’inizio della prossima settimana annunceremo i piani per la release
0.5.0 prevista per il 23 Sett.
Ci saranno in websocket. La soluzione userà l’IO esposto da Rack Hijiack
e non il Reactor Pattern (come Faye). Il che significa che funzionerà
con un web server concorrente come Puma e non di uno basato su
EventMachine come Thin. Ottima notizia.
Ho fatto delle prove con Rack e la gemma websocket e sembra funzionare
bene.
Luca
2015-06-26 17:39 GMT+02:00 Luca G. [email protected]:
Ciao,
Premetto di non aver mai usato Trailblazer, ma l’idea di avere delle DSL
su altre DSL che cambiano velocemente, non mi sembra l’ideale di
manutenibilità da ricercare per una applicazione da mettere in produzione.In ogni major release, Rails ha sempre introdotto cambiamenti non
retrocompatibili. Questo potrebbe succedere alle API su cui Trailblazer si
basa. Cercare di usare Rails come una libreria di basso livello (quale esso
non è), aggiunge complessità ulteriore a quella già esistente.
ok, mi avete convinto.
in effetti è stato un pianto qualsiasi porting da una major release di
rails all’altra, in questo caso inoltre occorrerebbe sperare che
trailbalzer riesca a stargli dietro e che non soffra degli stessi
problemi
di retrocompatibilità. troppe variabili e troppi condizionali…
Condivido molto dei concetti introdotti quali Operation, Cell, Form,
Repesenter, ma è difficile far “cambiare carattere” a Rails.
ok, allora mi sa che non rimane che mandarlo a quel paese 
se non cambiano Rack o HTTP, non c’è motivo di cambiare Lotus::Action.
essere introdotti quanto la complessità dei layer base MVC diventa non
da questo punto di vista dato quello che ho sottomano al momento credo
di
potermi permettere di provarlo.
RubyDay.
sarebbe molto interessante
La soluzione userà l’IO esposto da Rack Hijiack e non il Reactor Pattern
(come Faye)
Concordo, secondo me è l’unica soluzione sensata quella di integrare la
gestione della connessione persistente nell’application server, ed anche
l’unica che possa essere di fatto competitiva con nodejs e compagnia
cantante.
Da una parte mi dispiace, oramai mi ero deciso ad abbandonare Ruby ed
abbracciare Elixir/Phoenix per i prossimi progetti (almeno per quelli
sperimentali), così invece torno ad essere combattuto…
–
Maurizio De Santis
Il giorno 26 giugno 2015 23:41, Luca G. [email protected] ha
scritto:
dimenticavo: questo discorso però vale anche per le altre gem che potrei
usare con rails per avere quei componenti mancanti. o sbaglio?
Esatto, prendi ad esempio act_as_paranoid, acts_as_paranoid3 e paranoia.
Tre gem diverse per tre release diverse di Rails (dalla 2 alla 4),
ognuna delle quali abbandonata dopo un tot di tempo, fino a quando un
nuovo sviluppatore non ha cercato di fare il porting e crearne un’altra.
Il punto è che una libreria del genere è meno fondante di Trailblazer,
che è alle basi della tua architettura.
Luca
2015-06-29 11:08 GMT+02:00 Roberto P. [email protected]:
non è), aggiunge complessità ulteriore a quella già esistente.
ok, mi avete convinto.
in effetti è stato un pianto qualsiasi porting da una major release di
rails all’altra, in questo caso inoltre occorrerebbe sperare che
trailbalzer riesca a stargli dietro e che non soffra degli stessi problemi
di retrocompatibilità. troppe variabili e troppi condizionali…
dimenticavo: questo discorso però vale anche per le altre gem che potrei
usare con rails per avere quei componenti mancanti. o sbaglio?
Concordo con Luca. Ogni gem esterna e’ un potenziale collo di bottiglia.
Ribadisco quello che scrissi ad inizio thread, e’ importante valutare
costi
benefici. L’uso di una gem esterna puo’ essere un vantaggio all’inizio
di
un progetto e diventare un problema successivamente.
Un’architettura modulare e ben studiata consente di sostituire anche in
corsa una dipendenza, ma richiede un po’ di sforzo aggiuntivo e spesso
si
finisce ad integrare una gem in modo cosi’ saldo che diventa una
dipendenza
irremovibile.
Ogni dipendenza che si porta in un progetto andrebbe valutata
attentamente.
Piu’ la dipendenza e’ strutturale, maggiore e’ l’attenzione che dobbiamo
prestare.
– Simone
2015-06-29 13:52 GMT+02:00 Luca G. [email protected]:
Luca
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Passionate programmer and dive instructor
Twitter: @weppos https://twitter.com/weppos