Já daqui alguém usou o gears on rails (http://code.google.com/p/gearsonrails/) num projecto? Pelo que estive a ler, é provavelmente a melhor opção para quem pretende disponibilizar uma versão offline de uma rails app.
As minhas dúvidas vão no sentido de tentar estimar o esforço para esta actividade, focando-se principalmente na facilidade de pegar na coisa e no quão necessário é alterar/adaptar código em relação à app dita normal (obviamente tendo em conta o próprio tamanho da app).
Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana
passada.
Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps
offline:
- o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não
haverá Gears para OS X Snow Leopard por causa disso
- a tua lógica tem que estar ao máximo client-side, em javascript, o que
não costuma ser o caso com apps Rails
> Já daqui alguém usou o gears on rails (
> http://code.google.com/p/gearsonrails/) num projecto? Pelo que estive a
> ler, é provavelmente a melhor opção para quem pretende disponibilizar uma
> versão offline de uma rails app.
> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta
> actividade, focando-se principalmente na facilidade de pegar na coisa e no
> quão necessário é alterar/adaptar código em relação à app dita normal
> (obviamente tendo em conta o próprio tamanho da app).
> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a
> semana passada.
> Segundo estive a ler, o Google Gears não é mais uma boa aposta para
> apps offline:
> o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não ha > verá Gears para OS X Snow Leopard por causa disso
> a tua lógica tem que estar ao máximo client-side, em javascript, o q > ue não costuma ser o caso com apps Rails
> Para aplicações Rails, existe o Slingshot (http://www.google.com/search?q=rails+slingsh > ot) mas nunca experimentei.
> Estou curioso para saber o que tu e outros terão a partilhar.
> Alex
> 2009/11/23 Miguel Machado <mls.mach...@gmail.com>
> Viva,
> Já daqui alguém usou o gears on rails (http://code.google.com/p/gearsonrail > s/) num projecto? Pelo que estive a ler, é provavelmente a melhor op > ção para quem pretende disponibilizar uma versão offline de uma
> rails app.
> As minhas dúvidas vão no sentido de tentar estimar o esforço para
> esta actividade, focando-se principalmente na facilidade de pegar na > coisa e no quão necessário é alterar/adaptar código em relação
> à app dita normal (obviamente tendo em conta o próprio tamanho da ap > p).
> On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <<alexandre.solle...@gmail.com>
> alexandre.solle...@gmail.com> wrote:
> Oi Miguel,
> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana
> passada.
> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps
> offline:
> - o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não
> haverá Gears para OS X Snow Leopard por causa disso
> - a tua lógica tem que estar ao máximo client-side, em javascript, o
> que não costuma ser o caso com apps Rails
>> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta
>> actividade, focando-se principalmente na facilidade de pegar na coisa e no
>> quão necessário é alterar/adaptar código em relação à app dita normal
>> (obviamente tendo em conta o próprio tamanho da app).
Obrigado pelas respostas. Eu estive a ver o slingshot mas parece-me
claramente abandonware. Nem sequer tem página oficial, apenas blog posts e
wiki... e todas as referências à coisa são de 2007 (no tempo em que o AIR
ainda se chamava apollo :P)
Curiosamente, o slingshot era *precisamente* o que eu precisava :) A ideia
era ter uma versão offline da app que quando em rede permitisse sincronizar
tudo up&down, sem me chatear. A cena é que *alguns* dos gajos que vão usar o
sistema nem sempre vão ter rede e precisam de registar info nalgum lado,
chegar a casa e sincronizar tudo com o server (merge com a web app).
>> On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <<alexandre.solle...@gmail.com>
>> alexandre.solle...@gmail.com> wrote:
>> Oi Miguel,
>> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana
>> passada.
>> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps
>> offline:
>> - o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não
>> haverá Gears para OS X Snow Leopard por causa disso
>> - a tua lógica tem que estar ao máximo client-side, em javascript, o
>> que não costuma ser o caso com apps Rails
>>> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta
>>> actividade, focando-se principalmente na facilidade de pegar na coisa e no
>>> quão necessário é alterar/adaptar código em relação à app dita normal
>>> (obviamente tendo em conta o próprio tamanho da app).
Penso que para efectuares o merge deverás recorrer a WebServices. Mas esses
WebServices iriam olhar para uma base de dados stand-alone, e sempre que a
app stand-alone recebesse uma flag a indicar que tinha acesso efectuaria a
sincronização com a BD central da APP.
> Obrigado pelas respostas. Eu estive a ver o slingshot mas parece-me
> claramente abandonware. Nem sequer tem página oficial, apenas blog posts e
> wiki... e todas as referências à coisa são de 2007 (no tempo em que o AIR
> ainda se chamava apollo :P)
> Curiosamente, o slingshot era *precisamente* o que eu precisava :) A ideia
> era ter uma versão offline da app que quando em rede permitisse sincronizar
> tudo up&down, sem me chatear. A cena é que *alguns* dos gajos que vão usar o
> sistema nem sempre vão ter rede e precisam de registar info nalgum lado,
> chegar a casa e sincronizar tudo com o server (merge com a web app).
>>> On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <<alexandre.solle...@gmail.com>
>>> alexandre.solle...@gmail.com> wrote:
>>> Oi Miguel,
>>> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana
>>> passada.
>>> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps
>>> offline:
>>> - o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não
>>> haverá Gears para OS X Snow Leopard por causa disso
>>> - a tua lógica tem que estar ao máximo client-side, em javascript, o
>>> que não costuma ser o caso com apps Rails
>>>> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta
>>>> actividade, focando-se principalmente na facilidade de pegar na coisa e no
>>>> quão necessário é alterar/adaptar código em relação à app dita normal
>>>> (obviamente tendo em conta o próprio tamanho da app).
> Penso que para efectuares o merge deverás recorrer a WebServices. Mas esses WebServices iriam olhar para uma base de dados stand-alone, e sempre que a app stand-alone recebesse uma flag a indicar que tinha acesso efectuaria a sincronização com a BD central da APP.
> Espero ter ajudado.
> Pedro Jorge.
> 2009/11/23 miguel machado <mls.mach...@gmail.com>
> hey,
> Obrigado pelas respostas. Eu estive a ver o slingshot mas parece-me claramente abandonware. Nem sequer tem página oficial, apenas blog posts e wiki... e todas as referências à coisa são de 2007 (no tempo em que o AIR ainda se chamava apollo :P)
> Curiosamente, o slingshot era *precisamente* o que eu precisava :) A ideia era ter uma versão offline da app que quando em rede permitisse sincronizar tudo up&down, sem me chatear. A cena é que *alguns* dos gajos que vão usar o sistema nem sempre vão ter rede e precisam de registar info nalgum lado, chegar a casa e sincronizar tudo com o server (merge com a web app).
> Mais ideias e/ou sugestões?
> _ miguel
> 2009/11/23 Pedro Sousa <froidexpl...@gmail.com>
> experimenta o Titanium Desktop: http://www.appcelerator.com/products/titanium-desktop/ > se o objectivo é fazer uma app pra desktop usando Ruby.
> acho que depende muito do objectivo da app...
> On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <alexandre.solle...@gmail.com> wrote:
>> Oi Miguel,
>> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana passada.
>> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps offline: >> o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não haverá Gears para OS X Snow Leopard por causa disso
>> a tua lógica tem que estar ao máximo client-side, em javascript, o que não costuma ser o caso com apps Rails
>> Para aplicações Rails, existe o Slingshot (http://www.google.com/search?q=rails+slingshot) mas nunca experimentei.
>> Estou curioso para saber o que tu e outros terão a partilhar.
>> Alex
>> 2009/11/23 Miguel Machado <mls.mach...@gmail.com>
>> Viva,
>> Já daqui alguém usou o gears on rails (http://code.google.com/p/gearsonrails/) num projecto? Pelo que estive a ler, é provavelmente a melhor opção para quem pretende disponibilizar uma versão offline de uma rails app.
>> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta actividade, focando-se principalmente na facilidade de pegar na coisa e no quão necessário é alterar/adaptar código em relação à app dita normal (obviamente tendo em conta o próprio tamanho da app).
Mas desenvolver uma aplicação em rails para o desktop não vai contra o
objectivo fundamental de desenvolver aplicações em Rails para a web?
A pergunta deve estar um pouco mal conseguida...
Estarei a pensar mal?
Ou o tópico é sobre criar uma aplicação web, e encontrar um meio de
converte-la para o Desktop, e ser usada off-line - correcto?
Uma resposta a este problema não seria instalar um servidor local onde
correria a aplicação e criar um script Ruby para fazer sincronização
de BDs?
Confuso...
On Nov 23, 9:17 pm, Miguel Machado <mls.mach...@gmail.com> wrote:
> Parece-me uma boa ideia, vou pensar nisso. Obrigado!
> _ miguel
> On 23 Nov 2009, at 16:25, Pedro Jorge wrote:
> > Boas Miguel,
> > Penso que para efectuares o merge deverás recorrer a WebServices. Mas esses WebServices iriam olhar para uma base de dados stand-alone, e sempre que a app stand-alone recebesse uma flag a indicar que tinha acesso efectuaria a sincronização com a BD central da APP.
> > Espero ter ajudado.
> > Pedro Jorge.
> > 2009/11/23 miguel machado <mls.mach...@gmail.com>
> > hey,
> > Obrigado pelas respostas. Eu estive a ver o slingshot mas parece-me claramente abandonware. Nem sequer tem página oficial, apenas blog posts e wiki... e todas as referências à coisa são de 2007 (no tempo em que o AIR ainda se chamava apollo :P)
> > Curiosamente, o slingshot era *precisamente* o que eu precisava :) A ideia era ter uma versão offline da app que quando em rede permitisse sincronizar tudo up&down, sem me chatear. A cena é que *alguns* dos gajos que vão usar o sistema nem sempre vão ter rede e precisam de registar info nalgum lado, chegar a casa e sincronizar tudo com o server (merge com a web app).
> > Mais ideias e/ou sugestões?
> > _ miguel
> > 2009/11/23 Pedro Sousa <froidexpl...@gmail.com>
> > experimenta o Titanium Desktop:http://www.appcelerator.com/products/titanium-desktop/ > > se o objectivo é fazer uma app pra desktop usando Ruby.
> > acho que depende muito do objectivo da app...
> > On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <alexandre.solle...@gmail.com> wrote:
> >> Oi Miguel,
> >> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana passada.
> >> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps offline:
> >> o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não haverá Gears para OS X Snow Leopard por causa disso
> >> a tua lógica tem que estar ao máximo client-side, em javascript, o que não costuma ser o caso com apps Rails
> >> Para aplicações Rails, existe o Slingshot (http://www.google.com/search?q=rails+slingshot) mas nunca experimentei.
> >> Estou curioso para saber o que tu e outros terão a partilhar.
> >> Alex
> >> 2009/11/23 Miguel Machado <mls.mach...@gmail.com>
> >> Viva,
> >> Já daqui alguém usou o gears on rails (http://code.google.com/p/gearsonrails/) num projecto? Pelo que estive a ler, é provavelmente a melhor opção para quem pretende disponibilizar uma versão offline de uma rails app.
> >> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta actividade, focando-se principalmente na facilidade de pegar na coisa e no quão necessário é alterar/adaptar código em relação à app dita normal (obviamente tendo em conta o próprio tamanho da app).
De facto isto não encaixa muito bem a nível conceptual, mas é aí que entra a engenharia :-) A cena é que o sistema em causa é *mesmo* uma web app. Simplesmente há um requisito obrigatório que obriga a disponibilizar uma versão offline da coisa para que possa ser facilmente instalado num qualquer laptop / notebook e permita introduzir informação. Se é o cliente que pede, não pode ir contra nenhum objectivo fundamental :P
Anyway, essa hipótese de instalar um servidor local e sincronizar as BD's vai ao encontro do que já disse o Pedro Jorge atrás. É uma hipótese. Resta saber como funciona isso de fazer 'merge' da informação com sincronizações entre BD's. É o que vou tentar saber, nunca fiz.
> Mas desenvolver uma aplicação em rails para o desktop não vai contra o
> objectivo fundamental de desenvolver aplicações em Rails para a web?
> A pergunta deve estar um pouco mal conseguida...
> Estarei a pensar mal?
> Ou o tópico é sobre criar uma aplicação web, e encontrar um meio de
> converte-la para o Desktop, e ser usada off-line - correcto?
> Uma resposta a este problema não seria instalar um servidor local onde
> correria a aplicação e criar um script Ruby para fazer sincronização
> de BDs?
> Confuso...
> On Nov 23, 9:17 pm, Miguel Machado <mls.mach...@gmail.com> wrote:
>> Viva,
>> Parece-me uma boa ideia, vou pensar nisso. Obrigado!
>> _ miguel
>> On 23 Nov 2009, at 16:25, Pedro Jorge wrote:
>>> Boas Miguel,
>>> Penso que para efectuares o merge deverás recorrer a WebServices. Mas esses WebServices iriam olhar para uma base de dados stand-alone, e sempre que a app stand-alone recebesse uma flag a indicar que tinha acesso efectuaria a sincronização com a BD central da APP.
>>> Espero ter ajudado.
>>> Pedro Jorge.
>>> 2009/11/23 miguel machado <mls.mach...@gmail.com>
>>> hey,
>>> Obrigado pelas respostas. Eu estive a ver o slingshot mas parece-me claramente abandonware. Nem sequer tem página oficial, apenas blog posts e wiki... e todas as referências à coisa são de 2007 (no tempo em que o AIR ainda se chamava apollo :P)
>>> Curiosamente, o slingshot era *precisamente* o que eu precisava :) A ideia era ter uma versão offline da app que quando em rede permitisse sincronizar tudo up&down, sem me chatear. A cena é que *alguns* dos gajos que vão usar o sistema nem sempre vão ter rede e precisam de registar info nalgum lado, chegar a casa e sincronizar tudo com o server (merge com a web app).
>>> Mais ideias e/ou sugestões?
>>> _ miguel
>>> 2009/11/23 Pedro Sousa <froidexpl...@gmail.com>
>>> experimenta o Titanium Desktop:http://www.appcelerator.com/products/titanium-desktop/ >>> se o objectivo é fazer uma app pra desktop usando Ruby.
>>> acho que depende muito do objectivo da app...
>>> On 2009/11/23, at 12:55, Alexandre Loureiro Solleiro <alexandre.solle...@gmail.com> wrote:
>>>> Oi Miguel,
>>>> Nunca cheguei a fazer nada, mas por acaso dei uma olhada no tema a semana passada.
>>>> Segundo estive a ler, o Google Gears não é mais uma boa aposta para apps offline:
>>>> o HTML 5 tem as funcionalidades oferecidas pelo Gears; aliás, não haverá Gears para OS X Snow Leopard por causa disso
>>>> a tua lógica tem que estar ao máximo client-side, em javascript, o que não costuma ser o caso com apps Rails
>>>> Para aplicações Rails, existe o Slingshot (http://www.google.com/search?q=rails+slingshot) mas nunca experimentei.
>>>> Estou curioso para saber o que tu e outros terão a partilhar.
>>>> Alex
>>>> 2009/11/23 Miguel Machado <mls.mach...@gmail.com>
>>>> Viva,
>>>> Já daqui alguém usou o gears on rails (http://code.google.com/p/gearsonrails/) num projecto? Pelo que estive a ler, é provavelmente a melhor opção para quem pretende disponibilizar uma versão offline de uma rails app.
>>>> As minhas dúvidas vão no sentido de tentar estimar o esforço para esta actividade, focando-se principalmente na facilidade de pegar na coisa e no quão necessário é alterar/adaptar código em relação à app dita normal (obviamente tendo em conta o próprio tamanho da app).
On Nov 24, 2009, at 10:39 AM, Miguel Machado wrote:
> Anyway, essa hipótese de instalar um servidor local e sincronizar as BD's vai ao encontro do que já disse o Pedro Jorge atrás. É uma hipótese. Resta saber como funciona isso de fazer 'merge' da informação com sincronizações entre BD's. É o que vou tentar saber, nunca fiz.
Precisas de ter a informação offline, ou é só mesmo introdução de dados? Se for esse o caso, guardas apenas os dados no cliente, depois o "sincronizar" é só fazer inserts na BD do servidor dos registos do cliente e apagá-los ao obter configuração. Bastante simples se for.
> On Nov 24, 2009, at 10:39 AM, Miguel Machado wrote:
>> Anyway, essa hipótese de instalar um servidor local e sincronizar as BD's vai ao encontro do que já disse o Pedro Jorge atrás. É uma hipótese. Resta saber como funciona isso de fazer 'merge' da informação com sincronizações entre BD's. É o que vou tentar saber, nunca fiz.
> Precisas de ter a informação offline, ou é só mesmo introdução de dados? Se for esse o caso, guardas apenas os dados no cliente, depois o "sincronizar" é só fazer inserts na BD do servidor dos registos do cliente e apagá-los ao obter configuração. Bastante simples se for.
> On Nov 24, 2009, at 10:39 AM, Miguel Machado wrote:
> > Anyway, essa hipótese de instalar um servidor local e sincronizar as BD's
> vai ao encontro do que já disse o Pedro Jorge atrás. É uma hipótese. Resta
> saber como funciona isso de fazer 'merge' da informação com sincronizações
> entre BD's. É o que vou tentar saber, nunca fiz.
> Precisas de ter a informação offline, ou é só mesmo introdução de dados? Se
> for esse o caso, guardas apenas os dados no cliente, depois o "sincronizar"
> é só fazer inserts na BD do servidor dos registos do cliente e apagá-los ao
> obter configuração. Bastante simples se for.
Eu sei o que é o couchDB e estou ± familiarizado com o conceito, só não
percebo é onde é que isso me traz novas perspectivas ao meu problema. Dá
para explicar melhor, sff?
>> On Nov 24, 2009, at 10:39 AM, Miguel Machado wrote:
>> > Anyway, essa hipótese de instalar um servidor local e sincronizar as
>> BD's vai ao encontro do que já disse o Pedro Jorge atrás. É uma hipótese.
>> Resta saber como funciona isso de fazer 'merge' da informação com
>> sincronizações entre BD's. É o que vou tentar saber, nunca fiz.
>> Precisas de ter a informação offline, ou é só mesmo introdução de dados?
>> Se for esse o caso, guardas apenas os dados no cliente, depois o
>> "sincronizar" é só fazer inserts na BD do servidor dos registos do cliente e
>> apagá-los ao obter configuração. Bastante simples se for.
>> Alcides
> --
> Norberto Leite
-- "To understand what is recursion you must first understand recursion"
On Nov 24, 2009, at 1:35 PM, miguel machado wrote:
> Eu sei o que é o couchDB e estou ± familiarizado com o conceito, só não percebo é onde é que isso me traz novas perspectivas ao meu problema. Dá para explicar melhor, sff?
Já viste como funciona a replicação de dados? Json com Json. Talvez ajude.
hmmm okay, vou checkar melhor. De qq maneira, acho improvável vir a usar
couchDB, cheira-me que muitos rails plugins não funcionem sem ser com bd
relacionais... alguém pode confirmar/desmentir?
> On Nov 24, 2009, at 1:35 PM, miguel machado wrote:
> > Eu sei o que é o couchDB e estou ± familiarizado com o conceito, só não
> percebo é onde é que isso me traz novas perspectivas ao meu problema. Dá
> para explicar melhor, sff?
> Já viste como funciona a replicação de dados? Json com Json. Talvez ajude.
> Alcides
-- "To understand what is recursion you must first understand recursion"
Tu tens 2 problemas.
1º queres uma aplicaçao web que funcione em modo ofline. Para alem da
utilização de ajax nao vejo grandes alternativas. O gears pode vir a
resolver este problema.(nao estou muito seguro disso!)
2º queres que os dados locais estejam sincornizados com os de servidor. Ora
utilizas uma solução como o couchDB ou implementas "a la carte" uma sistema
de sincronizaçao de dados (pode nao passar por db local!).
Sugeri que visses o couchDB porque me parece a soluçao indicada para o teu
problema.
Quanto a plugins para rails -> sudo gem install json (esta "de puta madre"
de comprovado!)
Aqui te deixo uns dos primeiros resultados do google para: rails couchDB
P.S. -> Qualquer plugin para rails pode estar sujeito a algum problema, nao
necessariamente sem ser para db relacionais.
P.S.P.S. -> A m3rd4 é a mesma o "cheiro é que é diferente"
> hmmm okay, vou checkar melhor. De qq maneira, acho improvável vir a usar
> couchDB, cheira-me que muitos rails plugins não funcionem sem ser com bd
> relacionais... alguém pode confirmar/desmentir?
>> On Nov 24, 2009, at 1:35 PM, miguel machado wrote:
>> > Eu sei o que é o couchDB e estou ± familiarizado com o conceito, só não
>> percebo é onde é que isso me traz novas perspectivas ao meu problema. Dá
>> para explicar melhor, sff?
>> Já viste como funciona a replicação de dados? Json com Json. Talvez ajude.
>> Alcides
> --
> "To understand what is recursion you must first understand recursion"
|
