Epifania Cercasi: dati agili


#1

Lo so che tanto siete tutti in vacanza, ma io ci provo. Ho bisogno di
un’idea per attaccare un problema…

Il problema è il seguente: mettete di avere un wiki in cui le pagine
rappreseentano istruzioni eseguite dal wiki stesso.
E’ pensabile quindi poter scrivere web apps direttamente entro il wiki,
versionando le pagine, creando dipendenze tra pagine/versioni, etc.

Il grosso problema sono i dati.

A quale app appartengono? chi li crea? chi li distrugge? come gestirli?
In
generale l’intero concetto di migration diventa molto pesante in quel
contesto.

Supponiamo che il wiki non debba servire uno zillione di utenti… ma sia
fatto per fare prototipi rapidi… in questo caso potrei avere un
in-memory
db che posso dumpare come yaml ogni X secondi/minuti, oppure il DB
potrebbe
essere un’altra pagina wiki contenente i file yaml o del testo in
formato
tabulare… oppure potrei avere un paio di tabelle fisse nel sistema che
tengono tutti i dati spezzettando le colonne di quelle che sarebbero
tabelle rails come rows all’interno di queste meta-tabelle dinamiche.

avete altre idee?
sia sulla gestione dei dati che sull’applicativo?


#2

— chiaro scuro removed_email_address@domain.invalid wrote:

Lo so che tanto siete tutti in vacanza, ma io ci
provo. Ho bisogno di
un’idea per attaccare un problema…

non ancora in vacanza… ma se dio vuole entro la fine
della settimana :slight_smile:

A quale app appartengono? chi li crea? chi li
distrugge? come gestirli? In
generale l’intero concetto di migration diventa
molto pesante in quel
contesto.

esiste un concetto di “applicazione” all’interno del
wiki?
Intendo, se io faccio “new app: foo” e poi aggiungo il
codice che la compone è relativamente semplice
assegnargli i dati, se invece un’ìapplicazione è un
concetto impreciso collegato alle pagine è pèiù
difficile. Ma anche in quel caso si potrebbe associare
il pacco di dati all’applicazione intendendo come tale
la pagina che viene eseguita.
In entrmabi i casi io vedrei bene un DB OO/gerarchico
in cui la root dei dati è il nome dell’applicazione

tengono tutti i dati spezzettando le colonne di
quelle che sarebbero
tabelle rails come rows all’interno di queste
meta-tabelle dinamiche.

non pensare in termini di tabelle, madeleine direi che
fa al caso tuo, se funziona ancora.
L’evoluzione dello schema è automatica, ed è semplice
mostrare i dati come una pagina virtuale del wiki.
Come dicevo prima, la separazione tra i vari dati è
comunque semplice pensando che ogni pagina fa da
radice per un albero di oggetti che sono quelli
dell’applicazione.


Goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

  ___________________________________________________________

Yahoo! Answers - Got a question? Someone out there knows the answer. Try
it
now.
http://uk.answers.yahoo.com/


#3

On 7/31/07, gabriele renzi removed_email_address@domain.invalid wrote:

esiste un concetto di “applicazione” all’interno del
wiki?

Intendo, se io faccio “new app: foo” e poi aggiungo il

codice che la compone è relativamente semplice
assegnargli i dati, se invece un’ìapplicazione è un
concetto impreciso collegato alle pagine è pèiù
difficile. Ma anche in quel caso si potrebbe associare

non lo so ancora, tu che dici? :slight_smile:
è possibile pensare a una non-applicazione ma solo a degli entry point
diversi su un’ecologia di logica e dati?

il pacco di dati all’applicazione intendendo come tale

la pagina che viene eseguita.
In entrmabi i casi io vedrei bene un DB OO/gerarchico
in cui la root dei dati è il nome dell’applicazione

questo semplificherebbe un pò le cose… ma quanto sarebbe fico lasciare app
e dati disaccoppiati?
si lo so mi sto complicando la vita. iniziamo come dici tu :slight_smile:

non pensare in termini di tabelle, madeleine direi che

fa al caso tuo, se funziona ancora.

bello, un prevayler engine. lo hai provato?

L’evoluzione dello schema è automatica, ed è semplice


#4

— chiaro scuro removed_email_address@domain.invalid wrote:

non lo so ancora, tu che dici? :slight_smile:
è possibile pensare a una non-applicazione ma solo a
degli entry point
diversi su un’ecologia di logica e dati?

a parte il termine ecologia… perché no?
Magari con una micro-api del tipo

data = data(:name)
dove :name è una pagina del wiki, mantenuta come yaml
o dentro il tuo db. L’applicazione diviene
praticamente solo una vista divers sui dati. Ma è
ragionevole condividere i dati in questo modo?
A che punti inserisci le regole di dominio per
mantenerli consistenti se ognuno accede direttamente?

sarebbe fico lasciare app
e dati disaccoppiati?
si lo so mi sto complicando la vita. iniziamo come
dici tu :slight_smile:

complicando la vita no, solo che mi prude la schiena a
pensare che una pagina che fa casini manda a donnacce
tutte le applicazioni. D’altronde se il metodo di
accesso ai dati usa il versioning potrebbe
funzionare…

non pensare in termini di tabelle, madeleine direi
che

fa al caso tuo, se funziona ancora.

bello, un prevayler engine. lo hai provato?

un sacco di tempo fa e funzionava discretamente.
Era anche la cosa con cui funzionava instiki quindi
dovrebbe avere una certa affidabilità, ma ripeto non
so se si aggiornato per andare correttamente con ruby
1.8.6

  ___________________________________________________________

Yahoo! Mail is the world’s favourite email. Don’t settle for less, sign
up for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html


#5

Il giorno mar, 31/07/2007 alle 12.47 +0200, chiaro scuro ha scritto:

concetto impreciso collegato alle pagine è pèiù
in cui la root dei dati è il nome dell’applicazione
Sono d’accordo con Gabriele qui.

questo semplificherebbe un pò le cose… ma quanto sarebbe fico lasciare app
e dati disaccoppiati?

Non sarebbe per niente fico :wink:
Personalmente ritengo il disaccoppiamento tra applicazione e dati una di
quelle idee che suonano bene sulla carta, ma in pratica non funzionano.

si lo so mi sto complicando la vita. iniziamo come dici tu :slight_smile:

non pensare in termini di tabelle, madeleine direi che

fa al caso tuo, se funziona ancora.

bello, un prevayler engine. lo hai provato?

Io non ho provato Madeleine, ma ho avuto esperienze con db a oggetti (in
Smalltalk) e devo dire che rendono molte cose molto più semplici. Quindi
ti direi di andare di Madeleine.

Certo che se Ruby avesse un immagine come Smalltalk, non avresti neanche
il problema: ti limiteresti a salvare l’immagine :wink:

Giovanni


#6

On 7/31/07, Matteo C. removed_email_address@domain.invalid wrote:

Il 31/07/07, chiaro scuro removed_email_address@domain.invalid ha scritto:
Premetto che sono in vacanza e intendo restarci :wink: ma vorrei suggerirti di
creare al volo dei piccoli db sqlite, uno per webapp. Facili da versionare
(una migration è semplicemente un’altra entry del wiki), gestire (sono
file)
e per rintracciarli basta fare un match webapp-file. Oltretutto esistono

non è male affatto come idea. l’idea di vedere il db come file me lo fa
sembrare meno minaccioso in questo contesto :wink:
mi ero fissato con il fatto che ci volesse un meccanismo diverso e non
ci ho
pensato. adesso provo a vedere se è fattibile…

E’ un’idea semplicistica? Ci avevi pensato? Se sì, perché l’hai scartata?


#7

Il 31/07/07, chiaro scuro removed_email_address@domain.invalid ha scritto:

avete altre idee?
sia sulla gestione dei dati che sull’applicativo?

Premetto che sono in vacanza e intendo restarci :wink: ma vorrei suggerirti
di
creare al volo dei piccoli db sqlite, uno per webapp. Facili da
versionare
(una migration è semplicemente un’altra entry del wiki), gestire (sono
file)
e per rintracciarli basta fare un match webapp-file. Oltretutto esistono
plugin per rails che ti permettono di connetterti a db diversi, non so
il
nome ma mi ricordo che sono stati trattati qui in questa ml.

E’ un’idea semplicistica? Ci avevi pensato? Se sì, perché l’hai scartata?

Matteo


#8

Il 01/08/07, chiaro scuro removed_email_address@domain.invalid ha scritto:

non è male affatto come idea. l’idea di vedere il db come file me lo fa
sembrare meno minaccioso in questo contesto :wink:
mi ero fissato con il fatto che ci volesse un meccanismo diverso e non ci
ho
pensato. adesso provo a vedere se è fattibile…

Allora può funzionare? :slight_smile:


#9

On 8/3/07, Matteo C. removed_email_address@domain.invalid wrote:

Allora può funzionare? :slight_smile:

non ho ancora avuto tempo. voglio prima esplorare madeleine (perchè sono
geek) poi provo anche questa soluzione :slight_smile: