O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
Gostaria de saber de quem veio, ou ainda continua trabalhando, com
aplicações desktop principalmente com linguagens como C/C++ e Delphi,
se adotaram o modo RoR de desenvolvimento, gerando o BD a partir do
mecanismo de Migrations ou fazem como antes, modelam o banco de dados
primeiro em uma ferramenta CASE para depois linkar aos Models.
Ola Gedean, no inicio eu modelava em alguma ferramenta de case e depois
dentro do rails criava as migrations, nunca cheguei a fazer direto no banco
de dados sem usar as migrations do rails, mas eu nao criava uma migration
para cada alteração, eu alterava as migrations existentes (gerada por script
scaffold). Mas Agora faço no rails way, ou seja, vou criando migrations para
as alterações, correções, novos models, etc, e modelo o bd com papel e
lapis mesmo, devo confessar que é bem mais simples trabalhar assim. Então
sugiro que experimente trabalhar só com migrations, o que é interessantes
principalmente para facilitar o deploy e manter o estado do banco de dados
atual correto para o código do programa, interessante quando mais de um
programador esta trabalhando na aplicação. Sugiro que assista o episódio 83
do railscast <http://railscasts.com/episodes/83-migrations-in-rails-2-0> fala
bem sobre migrations.
> Gostaria de saber de quem veio, ou ainda continua trabalhando, com
> aplicações desktop principalmente com linguagens como C/C++ e Delphi,
> se adotaram o modo RoR de desenvolvimento, gerando o BD a partir do
> mecanismo de Migrations ou fazem como antes, modelam o banco de dados
> primeiro em uma ferramenta CASE para depois linkar aos Models.
Concordo com o Diego, ainda trabalho com .NET e sempre usamos ferramentas
CASE, no entanto em meus projetos Rails so utilizo as migrations. Vale muito
mais a pena.
> Ola Gedean, no inicio eu modelava em alguma ferramenta de case e depois
> dentro do rails criava as migrations, nunca cheguei a fazer direto no banco
> de dados sem usar as migrations do rails, mas eu nao criava uma migration
> para cada alteração, eu alterava as migrations existentes (gerada por script
> scaffold). Mas Agora faço no rails way, ou seja, vou criando migrations para
> as alterações, correções, novos models, etc, e modelo o bd com papel e
> lapis mesmo, devo confessar que é bem mais simples trabalhar assim. Então
> sugiro que experimente trabalhar só com migrations, o que é interessantes
> principalmente para facilitar o deploy e manter o estado do banco de dados
> atual correto para o código do programa, interessante quando mais de um
> programador esta trabalhando na aplicação. Sugiro que assista o episódio
> 83 do railscast<http://railscasts.com/episodes/83-migrations-in-rails-2-0> fala
> bem sobre migrations.
>> Gostaria de saber de quem veio, ou ainda continua trabalhando, com
>> aplicações desktop principalmente com linguagens como C/C++ e Delphi,
>> se adotaram o modo RoR de desenvolvimento, gerando o BD a partir do
>> mecanismo de Migrations ou fazem como antes, modelam o banco de dados
>> primeiro em uma ferramenta CASE para depois linkar aos Models.
Obrigado pelas respostas! Acho que estou mesmo com o mind-set errado,
muito atrelado ao desktop, afinal com outra tecnologia, temos que
trabalhar de acordo com o que ela preconiza ...
Eu fico indagando também sobre questões como integridade referencial,
otimização de índices, etc.
Outra coisa, é que eu gosto do modo como nomeava os objetos do banco
de dados: tb_nome_tabela, vw_nome_tabela, com o Rails é outra
convenção, o nome do Objeto do código pluralizado. No fundo, é o que
mais me incomoda nessa transição de teconologia.
> Obrigado pelas respostas! Acho que estou mesmo com o mind-set errado,
> muito atrelado ao desktop, afinal com outra tecnologia, temos que
> trabalhar de acordo com o que ela preconiza ...
> Eu fico indagando também sobre questões como integridade referencial,
> otimização de índices, etc.
> Outra coisa, é que eu gosto do modo como nomeava os objetos do banco
> de dados: tb_nome_tabela, vw_nome_tabela, com o Rails é outra
> convenção, o nome do Objeto do código pluralizado. No fundo, é o que
> mais me incomoda nessa transição de teconologia.
> > Obrigado pelas respostas! Acho que estou mesmo com o mind-set errado,
> > muito atrelado ao desktop, afinal com outra tecnologia, temos que
> > trabalhar de acordo com o que ela preconiza ...
> > Eu fico indagando também sobre questões como integridade referencial,
> > otimização de índices, etc.
> > Outra coisa, é que eu gosto do modo como nomeava os objetos do banco
> > de dados: tb_nome_tabela, vw_nome_tabela, com o Rails é outra
> > convenção, o nome do Objeto do código pluralizado. No fundo, é o que
> > mais me incomoda nessa transição de teconologia.
Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
coisa fora de lugar ... desalinhado com o jeito RoR.
Eu trabalho com consultoria em um segmento muito específico de
governo, uso conhecimentos em programação para desenvolver ferramentas
para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
bases pré-existentes, mas agora, como vêm surgindo necessidades de
novas ferramentas, sinto vontade de implementá-las com o RoR, mas
ainda não sinto segurança, até porque existe um conjunto enorme de
outras capacidades que devo desenvolver para projetos web, ex.: Web
Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
curva de aprendizado de algumas ser bastante tênue. E em adição a
isso, novas práticas no desenvolvimento da aplicação ... praticamente
só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
Vai aqui, como o Gedean solicitou a minha experiência relativamente
recente (tive esta discussão num grupo de aprendizado que participei a
cerca de um ano).
Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
sempre desenvolvi orientado a modelagem de banco primeiro), quando
comecei a aprender Rails, questionei MUITO as "opiniões",
principalmente em relação a implementar relacionamentos fora do banco,
pois tenho problemas sérios numa aplicação VB desktop até hoje por
conta da falta de integridade referencial no banco.
Outra questão que eu questionei muito foi a da performance (criação e
administração de índices).
Vamos ao que concluímos lá neste grupo de estudo:
1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
legadas? Dá, mas vai dar bastante trabalho.
2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
Como eles mudavam toda hora lá no trabalho e variam também de cliente
para cliente, prefiro fazer o design no papel, como o colega já citou,
documentar muito bem no banco (comentários para tabelas, colunas, e se
o banco permitir para os demais objetos), e depois usar a ferramenta
CASE da ocasião aplicando engenharia reversa no banco.
3 - A questão do plural no nome das tabelas, é uma simples questão de
convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
instâncias daquele objeto, ou no singular porque a tabela representa a
classe dos objetos? Eu, até então sempre usava no singular, mas
preferi me adaptar ao Rails do que ter mais trabalho (Eehh
preguiça...), mas como já disseram dá pra fazer do outro jeito.
4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
scripts específicos no migrations e fazer o que você quiser, até de
forma explícita (comandos SQL diretos), para, por exemplo, colocar
comentários no banco, criar índices, etc.).
5 - Procure pensar TODA a solução, incluindo o banco de dados, em
Inglês, depois use as facilidades de "internacionalização" para
"nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
solução já fica "universal".
Espero ter ajudado.
Grande abraço.
On 3 nov, 15:11, Gedean <gedean.d...@gmail.com> wrote:
> Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
> coisa fora de lugar ... desalinhado com o jeito RoR.
> Eu trabalho com consultoria em um segmento muito específico de
> governo, uso conhecimentos em programação para desenvolver ferramentas
> para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
> bases pré-existentes, mas agora, como vêm surgindo necessidades de
> novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> ainda não sinto segurança, até porque existe um conjunto enorme de
> outras capacidades que devo desenvolver para projetos web, ex.: Web
> Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
> curva de aprendizado de algumas ser bastante tênue. E em adição a
> isso, novas práticas no desenvolvimento da aplicação ... praticamente
> só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
MarcRic,
Já que é experiente na area, poderia responder a duvida de um relativamente
novato?
O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
.NET ou Java que Rails é diferente, mas não lento.
> Vai aqui, como o Gedean solicitou a minha experiência relativamente
> recente (tive esta discussão num grupo de aprendizado que participei a
> cerca de um ano).
> Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
> e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
> sempre desenvolvi orientado a modelagem de banco primeiro), quando
> comecei a aprender Rails, questionei MUITO as "opiniões",
> principalmente em relação a implementar relacionamentos fora do banco,
> pois tenho problemas sérios numa aplicação VB desktop até hoje por
> conta da falta de integridade referencial no banco.
> Outra questão que eu questionei muito foi a da performance (criação e
> administração de índices).
> Vamos ao que concluímos lá neste grupo de estudo:
> 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
> legadas? Dá, mas vai dar bastante trabalho.
> 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
> Como eles mudavam toda hora lá no trabalho e variam também de cliente
> para cliente, prefiro fazer o design no papel, como o colega já citou,
> documentar muito bem no banco (comentários para tabelas, colunas, e se
> o banco permitir para os demais objetos), e depois usar a ferramenta
> CASE da ocasião aplicando engenharia reversa no banco.
> 3 - A questão do plural no nome das tabelas, é uma simples questão de
> convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
> CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
> instâncias daquele objeto, ou no singular porque a tabela representa a
> classe dos objetos? Eu, até então sempre usava no singular, mas
> preferi me adaptar ao Rails do que ter mais trabalho (Eehh
> preguiça...), mas como já disseram dá pra fazer do outro jeito.
> 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
> scripts específicos no migrations e fazer o que você quiser, até de
> forma explícita (comandos SQL diretos), para, por exemplo, colocar
> comentários no banco, criar índices, etc.).
> 5 - Procure pensar TODA a solução, incluindo o banco de dados, em
> Inglês, depois use as facilidades de "internacionalização" para
> "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
> solução já fica "universal".
> > Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
> > coisa fora de lugar ... desalinhado com o jeito RoR.
> > Eu trabalho com consultoria em um segmento muito específico de
> > governo, uso conhecimentos em programação para desenvolver ferramentas
> > para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
> > bases pré-existentes, mas agora, como vêm surgindo necessidades de
> > novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> > ainda não sinto segurança, até porque existe um conjunto enorme de
> > outras capacidades que devo desenvolver para projetos web, ex.: Web
> > Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> > seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
> > curva de aprendizado de algumas ser bastante tênue. E em adição a
> > isso, novas práticas no desenvolvimento da aplicação ... praticamente
> > só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
Igor, se não te preocupares com indexação o teu SGBD vai para o buraco.
Vai atolar a tua máquina.
Não tem mágica em acesso a SGBD-R. Tem que indexar corretamente.
O Rails oferece bom suporte a indexação através das Migrations.
Sugiro que dês uma lida a respeito.
Abs,
Igor Leroy escreveu:
MarcRic,
Já que é experiente na area, poderia responder a duvida de um
relativamente novato?
O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
indices, relacionamentos e etc. As vezes é dificil convencer um xiita
em .NET ou Java que Rails é diferente, mas não lento.
Vai aqui, como o Gedean solicitou a minha experiência relativamente
recente (tive esta discussão num grupo de aprendizado que participei a
cerca de um ano).
Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
sempre desenvolvi orientado a modelagem de banco primeiro), quando
comecei a aprender Rails, questionei MUITO as "opiniões",
principalmente em relação a implementar relacionamentos fora do banco,
pois tenho problemas sérios numa aplicação VB desktop até hoje por
conta da falta de integridade referencial no banco.
Outra questão que eu questionei muito foi a da performance (criação e
administração de índices).
Vamos ao que concluímos lá neste grupo de estudo:
1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
legadas? Dá, mas vai dar bastante trabalho.
2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
Como eles mudavam toda hora lá no trabalho e variam também de cliente
para cliente, prefiro fazer o design no papel, como o colega já citou,
documentar muito bem no banco (comentários para tabelas, colunas, e se
o banco permitir para os demais objetos), e depois usar a ferramenta
CASE da ocasião aplicando engenharia reversa no banco.
3 - A questão do plural no nome das tabelas, é uma simples questão de
convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
instâncias daquele objeto, ou no singular porque a tabela representa a
classe dos objetos? Eu, até então sempre usava no singular, mas
preferi me adaptar ao Rails do que ter mais trabalho (Eehh
preguiça...), mas como já disseram dá pra fazer do outro jeito.
4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
scripts específicos no migrations e fazer o que você quiser, até de
forma explícita (comandos SQL diretos), para, por exemplo, colocar
comentários no banco, criar índices, etc.).
5 - Procure pensar TODA a solução, incluindo o banco de dados, em
Inglês, depois use as facilidades de "internacionalização" para
"nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
solução já fica "universal".
Espero ter ajudado.
Grande abraço.
On 3 nov, 15:11, Gedean <gedean.d...@gmail.com>
wrote:
> Obrigado novamente!
>
> Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo
uma
> coisa fora de lugar ... desalinhado com o jeito RoR.
>
> Eu trabalho com consultoria em um segmento muito específico de
> governo, uso conhecimentos em programação para desenvolver
ferramentas
> para meu uso próprio, venho testando Ruby e Ruby On Rails em cima
das
> bases pré-existentes, mas agora, como vêm surgindo necessidades de
> novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> ainda não sinto segurança, até porque existe um conjunto enorme de
> outras capacidades que devo desenvolver para projetos web, ex.: Web
> Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de
a
> curva de aprendizado de algumas ser bastante tênue. E em adição a
> isso, novas práticas no desenvolvimento da aplicação ...
praticamente
> só se aproveita os conhecimentos do negócio e de Orientação à
Objetos.
> MarcRic, > Já que é experiente na area, poderia responder a duvida de um relativamente > novato? > O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem > indices, relacionamentos e etc. As vezes é dificil convencer um xiita em .NET > ou Java que Rails é diferente, mas não lento.
>> Vai aqui, como o Gedean solicitou a minha experiência relativamente >> recente (tive esta discussão num grupo de aprendizado que participei a >> cerca de um ano).
>> Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"), >> e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e >> sempre desenvolvi orientado a modelagem de banco primeiro), quando >> comecei a aprender Rails, questionei MUITO as "opiniões", >> principalmente em relação a implementar relacionamentos fora do banco, >> pois tenho problemas sérios numa aplicação VB desktop até hoje por >> conta da falta de integridade referencial no banco.
>> Outra questão que eu questionei muito foi a da performance (criação e >> administração de índices).
>> Vamos ao que concluímos lá neste grupo de estudo:
>> 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações >> legadas? Dá, mas vai dar bastante trabalho. >> 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo. >> Como eles mudavam toda hora lá no trabalho e variam também de cliente >> para cliente, prefiro fazer o design no papel, como o colega já citou, >> documentar muito bem no banco (comentários para tabelas, colunas, e se >> o banco permitir para os demais objetos), e depois usar a ferramenta >> CASE da ocasião aplicando engenharia reversa no banco. >> 3 - A questão do plural no nome das tabelas, é uma simples questão de >> convenção, e existem adeptos das duas possibilidades: CUSTOMER ou >> CUSTOMERS, qual é a melhor? No plural porque a tabela armazena >> instâncias daquele objeto, ou no singular porque a tabela representa a >> classe dos objetos? Eu, até então sempre usava no singular, mas >> preferi me adaptar ao Rails do que ter mais trabalho (Eehh >> preguiça...), mas como já disseram dá pra fazer do outro jeito. >> 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar >> scripts específicos no migrations e fazer o que você quiser, até de >> forma explícita (comandos SQL diretos), para, por exemplo, colocar >> comentários no banco, criar índices, etc.). >> 5 - Procure pensar TODA a solução, incluindo o banco de dados, em >> Inglês, depois use as facilidades de "internacionalização" para >> "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a >> solução já fica "universal".
>>> > Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma >>> > coisa fora de lugar ... desalinhado com o jeito RoR.
>>> > Eu trabalho com consultoria em um segmento muito específico de >>> > governo, uso conhecimentos em programação para desenvolver ferramentas >>> > para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das >>> > bases pré-existentes, mas agora, como vêm surgindo necessidades de >>> > novas ferramentas, sinto vontade de implementá-las com o RoR, mas >>> > ainda não sinto segurança, até porque existe um conjunto enorme de >>> > outras capacidades que devo desenvolver para projetos web, ex.: Web >>> > Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou >>> > seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a >>> > curva de aprendizado de algumas ser bastante tênue. E em adição a >>> > isso, novas práticas no desenvolvimento da aplicação ... praticamente >>> > só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
inicialmente desculpem se estou desviando o tópico.
As migrations do Rails oferecem um modo de se evoluir uma aplicação de
modo iterativo-incremental [1]. Provavelmente, encorajar um ciclo de
vida iterativo-incremental é mais uma das "opiniões" do Rails, opinião
aliás muito bem vinda. Do modo que é, o mecanismo de migrations
desencoraja - mas de modo algum impede - que se realize big design up
front [2], o que também é ótimo. Enfim, já que se falou em mindset na
thread, na mudança para o Rails pode ser interessante que se repense
também o modo como a atividade de desenvolver software é encarada.
Estou falando de desenvolvimento ágil de software [3], para o qual o
Rails, sua comunidade e seu ecossistema caem como uma luva. Foi este,
aliás, o principal motivo de minha mudança de Java/JSF para Ruby/Rails
como principal plataforma de desenvolvimento, no primeiro semestre
deste ano.
> On 04/11/09 20:42, "Igor Leroy" <ip.le...@gmail.com> wrote:
> MarcRic,
> Já que é experiente na area, poderia responder a duvida de um relativamente
> novato?
> O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
> indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
> .NET ou Java que Rails é diferente, mas não lento.
> Vai aqui, como o Gedean solicitou a minha experiência relativamente
> recente (tive esta discussão num grupo de aprendizado que participei a
> cerca de um ano).
> Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
> e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
> sempre desenvolvi orientado a modelagem de banco primeiro), quando
> comecei a aprender Rails, questionei MUITO as "opiniões",
> principalmente em relação a implementar relacionamentos fora do banco,
> pois tenho problemas sérios numa aplicação VB desktop até hoje por
> conta da falta de integridade referencial no banco.
> Outra questão que eu questionei muito foi a da performance (criação e
> administração de índices).
> Vamos ao que concluímos lá neste grupo de estudo:
> 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
> legadas? Dá, mas vai dar bastante trabalho.
> 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
> Como eles mudavam toda hora lá no trabalho e variam também de cliente
> para cliente, prefiro fazer o design no papel, como o colega já citou,
> documentar muito bem no banco (comentários para tabelas, colunas, e se
> o banco permitir para os demais objetos), e depois usar a ferramenta
> CASE da ocasião aplicando engenharia reversa no banco.
> 3 - A questão do plural no nome das tabelas, é uma simples questão de
> convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
> CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
> instâncias daquele objeto, ou no singular porque a tabela representa a
> classe dos objetos? Eu, até então sempre usava no singular, mas
> preferi me adaptar ao Rails do que ter mais trabalho (Eehh
> preguiça...), mas como já disseram dá pra fazer do outro jeito.
> 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
> scripts específicos no migrations e fazer o que você quiser, até de
> forma explícita (comandos SQL diretos), para, por exemplo, colocar
> comentários no banco, criar índices, etc.).
> 5 - Procure pensar TODA a solução, incluindo o banco de dados, em
> Inglês, depois use as facilidades de "internacionalização" para
> "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
> solução já fica "universal".
>> Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
>> coisa fora de lugar ... desalinhado com o jeito RoR.
>> Eu trabalho com consultoria em um segmento muito específico de
>> governo, uso conhecimentos em programação para desenvolver ferramentas
>> para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
>> bases pré-existentes, mas agora, como vêm surgindo necessidades de
>> novas ferramentas, sinto vontade de implementá-las com o RoR, mas
>> ainda não sinto segurança, até porque existe um conjunto enorme de
>> outras capacidades que devo desenvolver para projetos web, ex.: Web
>> Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
>> seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
>> curva de aprendizado de algumas ser bastante tênue. E em adição a
>> isso, novas práticas no desenvolvimento da aplicação ... praticamente
>> só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
> inicialmente desculpem se estou desviando o tópico.
> As migrations do Rails oferecem um modo de se evoluir uma aplicação de
> modo iterativo-incremental [1]. Provavelmente, encorajar um ciclo de
> vida iterativo-incremental é mais uma das "opiniões" do Rails, opinião
> aliás muito bem vinda. Do modo que é, o mecanismo de migrations
> desencoraja - mas de modo algum impede - que se realize big design up
> front [2], o que também é ótimo. Enfim, já que se falou em mindset na
> thread, na mudança para o Rails pode ser interessante que se repense
> também o modo como a atividade de desenvolver software é encarada.
> Estou falando de desenvolvimento ágil de software [3], para o qual o
> Rails, sua comunidade e seu ecossistema caem como uma luva. Foi este,
> aliás, o principal motivo de minha mudança de Java/JSF para Ruby/Rails
> como principal plataforma de desenvolvimento, no primeiro semestre
> deste ano.
> 2009/11/4 Marcelo Castellani <marc...@hypequino.com>:
> > Oi Igor
> > Rails tem tudo isso.
> > Marcelo
> > On 04/11/09 20:42, "Igor Leroy" <ip.le...@gmail.com> wrote:
> > MarcRic,
> > Já que é experiente na area, poderia responder a duvida de um
> relativamente
> > novato?
> > O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
> > indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
> > .NET ou Java que Rails é diferente, mas não lento.
> > Vai aqui, como o Gedean solicitou a minha experiência relativamente
> > recente (tive esta discussão num grupo de aprendizado que participei a
> > cerca de um ano).
> > Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
> > e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
> > sempre desenvolvi orientado a modelagem de banco primeiro), quando
> > comecei a aprender Rails, questionei MUITO as "opiniões",
> > principalmente em relação a implementar relacionamentos fora do banco,
> > pois tenho problemas sérios numa aplicação VB desktop até hoje por
> > conta da falta de integridade referencial no banco.
> > Outra questão que eu questionei muito foi a da performance (criação e
> > administração de índices).
> > Vamos ao que concluímos lá neste grupo de estudo:
> > 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
> > legadas? Dá, mas vai dar bastante trabalho.
> > 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
> > Como eles mudavam toda hora lá no trabalho e variam também de cliente
> > para cliente, prefiro fazer o design no papel, como o colega já citou,
> > documentar muito bem no banco (comentários para tabelas, colunas, e se
> > o banco permitir para os demais objetos), e depois usar a ferramenta
> > CASE da ocasião aplicando engenharia reversa no banco.
> > 3 - A questão do plural no nome das tabelas, é uma simples questão de
> > convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
> > CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
> > instâncias daquele objeto, ou no singular porque a tabela representa a
> > classe dos objetos? Eu, até então sempre usava no singular, mas
> > preferi me adaptar ao Rails do que ter mais trabalho (Eehh
> > preguiça...), mas como já disseram dá pra fazer do outro jeito.
> > 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
> > scripts específicos no migrations e fazer o que você quiser, até de
> > forma explícita (comandos SQL diretos), para, por exemplo, colocar
> > comentários no banco, criar índices, etc.).
> > 5 - Procure pensar TODA a solução, incluindo o banco de dados, em
> > Inglês, depois use as facilidades de "internacionalização" para
> > "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
> > solução já fica "universal".
> >> Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
> >> coisa fora de lugar ... desalinhado com o jeito RoR.
> >> Eu trabalho com consultoria em um segmento muito específico de
> >> governo, uso conhecimentos em programação para desenvolver ferramentas
> >> para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
> >> bases pré-existentes, mas agora, como vêm surgindo necessidades de
> >> novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> >> ainda não sinto segurança, até porque existe um conjunto enorme de
> >> outras capacidades que devo desenvolver para projetos web, ex.: Web
> >> Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> >> seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
> >> curva de aprendizado de algumas ser bastante tênue. E em adição a
> >> isso, novas práticas no desenvolvimento da aplicação ... praticamente
> >> só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
Respondendo a você e englobando partes do que já foi dito desde a sua
pergunta.
Não há mágica em relação ao banco, você precisa SIM, se preocupar com
a criação de índices, e pode, se julgar conveniente, e dependendo do
RDB utilizado, criar objetos de apoio como constraints por exemplo,
tudo usando o recurso padrão de migrations, e de forma mais ou menos
explícita. Vão existir comandos específicos para um determinado RDB,
que não são mapeados por nenhum ORM como o active record por exemplo.
Daí você pode usar até comandos SQL explícitos, mas mantendo o uso das
migrations.
O que o Rails proporciona através das migrations (como também já foi
dito), é uma maneira de ir evoluindo e documentando todo o processo,
sem ter que se preocupar com todos os possíveis relacionamentos e os
possíveis filtros desde o início, o que, cá entre nós, se não é
impossível, é desaconselhável, pois vai levar o seu projeto para o
modelo waterfall, afastando-o do modelo ágil de sprints curtos com
entrega de valor para o cliente.
Como o Rodrigo falou, quando você passa a desenvolver em Ruby on
Rails, é uma boa hora para mudar a forma de conduzir os seus projetos,
se não no trabalho (as vezes isto não é possível), ao menos, nos seus
projetos particulares.
Grande abraço.
P.S. Sou experiente sim, na área de TI (mais de 30 anos), em Web em
geral, tô estudando e aprendendo a cerca de 4 anos apenas, Ruby,
comecei no final de 2007, e Rails em meados de 2008. E tem é coisa pra
aprender hein...
Aprender é ótimo.
On 4 nov, 20:42, Igor Leroy <ip.le...@gmail.com> wrote:
> MarcRic,
> Já que é experiente na area, poderia responder a duvida de um relativamente
> novato?
> O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
> indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
> .NET ou Java que Rails é diferente, mas não lento.
> > Vai aqui, como o Gedean solicitou a minha experiência relativamente
> > recente (tive esta discussão num grupo de aprendizado que participei a
> > cerca de um ano).
> > Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
> > e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
> > sempre desenvolvi orientado a modelagem de banco primeiro), quando
> > comecei a aprender Rails, questionei MUITO as "opiniões",
> > principalmente em relação a implementar relacionamentos fora do banco,
> > pois tenho problemas sérios numa aplicação VB desktop até hoje por
> > conta da falta de integridade referencial no banco.
> > Outra questão que eu questionei muito foi a da performance (criação e
> > administração de índices).
> > Vamos ao que concluímos lá neste grupo de estudo:
> > 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
> > legadas? Dá, mas vai dar bastante trabalho.
> > 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
> > Como eles mudavam toda hora lá no trabalho e variam também de cliente
> > para cliente, prefiro fazer o design no papel, como o colega já citou,
> > documentar muito bem no banco (comentários para tabelas, colunas, e se
> > o banco permitir para os demais objetos), e depois usar a ferramenta
> > CASE da ocasião aplicando engenharia reversa no banco.
> > 3 - A questão do plural no nome das tabelas, é uma simples questão de
> > convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
> > CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
> > instâncias daquele objeto, ou no singular porque a tabela representa a
> > classe dos objetos? Eu, até então sempre usava no singular, mas
> > preferi me adaptar ao Rails do que ter mais trabalho (Eehh
> > preguiça...), mas como já disseram dá pra fazer do outro jeito.
> > 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
> > scripts específicos no migrations e fazer o que você quiser, até de
> > forma explícita (comandos SQL diretos), para, por exemplo, colocar
> > comentários no banco, criar índices, etc.).
> > 5 - Procure pensar TODA a solução, incluindo o banco de dados, em
> > Inglês, depois use as facilidades de "internacionalização" para
> > "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
> > solução já fica "universal".
> > > Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
> > > coisa fora de lugar ... desalinhado com o jeito RoR.
> > > Eu trabalho com consultoria em um segmento muito específico de
> > > governo, uso conhecimentos em programação para desenvolver ferramentas
> > > para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
> > > bases pré-existentes, mas agora, como vêm surgindo necessidades de
> > > novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> > > ainda não sinto segurança, até porque existe um conjunto enorme de
> > > outras capacidades que devo desenvolver para projetos web, ex.: Web
> > > Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> > > seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
> > > curva de aprendizado de algumas ser bastante tênue. E em adição a
> > > isso, novas práticas no desenvolvimento da aplicação ... praticamente
> > > só se aproveita os conhecimentos do negócio e de Orientação à Objetos.
Obrigado pelas dicas. Geralmente que se vê em blogs ou pela net, da a
entender que desenvolvedores Rails não ligam muito para o comportamento do
banco, achando que o Active Record ja faz tudo. Pelo jeito me enganei e
muito.
Estou no mundo Ruby ha menos de um ano, ainda tenho MUITO a aprender.
> Respondendo a você e englobando partes do que já foi dito desde a sua
> pergunta.
> Não há mágica em relação ao banco, você precisa SIM, se preocupar com
> a criação de índices, e pode, se julgar conveniente, e dependendo do
> RDB utilizado, criar objetos de apoio como constraints por exemplo,
> tudo usando o recurso padrão de migrations, e de forma mais ou menos
> explícita. Vão existir comandos específicos para um determinado RDB,
> que não são mapeados por nenhum ORM como o active record por exemplo.
> Daí você pode usar até comandos SQL explícitos, mas mantendo o uso das
> migrations.
> O que o Rails proporciona através das migrations (como também já foi
> dito), é uma maneira de ir evoluindo e documentando todo o processo,
> sem ter que se preocupar com todos os possíveis relacionamentos e os
> possíveis filtros desde o início, o que, cá entre nós, se não é
> impossível, é desaconselhável, pois vai levar o seu projeto para o
> modelo waterfall, afastando-o do modelo ágil de sprints curtos com
> entrega de valor para o cliente.
> Como o Rodrigo falou, quando você passa a desenvolver em Ruby on
> Rails, é uma boa hora para mudar a forma de conduzir os seus projetos,
> se não no trabalho (as vezes isto não é possível), ao menos, nos seus
> projetos particulares.
> Grande abraço.
> P.S. Sou experiente sim, na área de TI (mais de 30 anos), em Web em
> geral, tô estudando e aprendendo a cerca de 4 anos apenas, Ruby,
> comecei no final de 2007, e Rails em meados de 2008. E tem é coisa pra
> aprender hein...
> Aprender é ótimo.
> On 4 nov, 20:42, Igor Leroy <ip.le...@gmail.com> wrote:
> > MarcRic,
> > Já que é experiente na area, poderia responder a duvida de um
> relativamente
> > novato?
> > O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
> > indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
> > .NET ou Java que Rails é diferente, mas não lento.
> > > Vai aqui, como o Gedean solicitou a minha experiência relativamente
> > > recente (tive esta discussão num grupo de aprendizado que participei a
> > > cerca de um ano).
> > > Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
> > > e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
> > > sempre desenvolvi orientado a modelagem de banco primeiro), quando
> > > comecei a aprender Rails, questionei MUITO as "opiniões",
> > > principalmente em relação a implementar relacionamentos fora do banco,
> > > pois tenho problemas sérios numa aplicação VB desktop até hoje por
> > > conta da falta de integridade referencial no banco.
> > > Outra questão que eu questionei muito foi a da performance (criação e
> > > administração de índices).
> > > Vamos ao que concluímos lá neste grupo de estudo:
> > > 1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
> > > legadas? Dá, mas vai dar bastante trabalho.
> > > 2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
> > > Como eles mudavam toda hora lá no trabalho e variam também de cliente
> > > para cliente, prefiro fazer o design no papel, como o colega já citou,
> > > documentar muito bem no banco (comentários para tabelas, colunas, e se
> > > o banco permitir para os demais objetos), e depois usar a ferramenta
> > > CASE da ocasião aplicando engenharia reversa no banco.
> > > 3 - A questão do plural no nome das tabelas, é uma simples questão de
> > > convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
> > > CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
> > > instâncias daquele objeto, ou no singular porque a tabela representa a
> > > classe dos objetos? Eu, até então sempre usava no singular, mas
> > > preferi me adaptar ao Rails do que ter mais trabalho (Eehh
> > > preguiça...), mas como já disseram dá pra fazer do outro jeito.
> > > 4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
> > > scripts específicos no migrations e fazer o que você quiser, até de
> > > forma explícita (comandos SQL diretos), para, por exemplo, colocar
> > > comentários no banco, criar índices, etc.).
> > > 5 - Procure pensar TODA a solução, incluindo o banco de dados, em
> > > Inglês, depois use as facilidades de "internacionalização" para
> > > "nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
> > > solução já fica "universal".
> > > > Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
> > > > coisa fora de lugar ... desalinhado com o jeito RoR.
> > > > Eu trabalho com consultoria em um segmento muito específico de
> > > > governo, uso conhecimentos em programação para desenvolver
> ferramentas
> > > > para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
> > > > bases pré-existentes, mas agora, como vêm surgindo necessidades de
> > > > novas ferramentas, sinto vontade de implementá-las com o RoR, mas
> > > > ainda não sinto segurança, até porque existe um conjunto enorme de
> > > > outras capacidades que devo desenvolver para projetos web, ex.: Web
> > > > Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
> > > > seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
> > > > curva de aprendizado de algumas ser bastante tênue. E em adição a
> > > > isso, novas práticas no desenvolvimento da aplicação ... praticamente
> > > > só se aproveita os conhecimentos do negócio e de Orientação à
> Objetos.
> > --
> > -- Igor Leroy
> > -- Desenvolvedor Web
> > --www.igorleroy.com
|
