Remover modelo no Rails

Para remover um modelo criado no Rails:

rails destroy model model_name 

Se a migration criada para este model foi adicionada ao banco de dados, criando uma tabela para esse modelo, para remover essas alterações:

bundle exec rake db:rollback
Anúncios

Welcome aboard no Rails 4+

No Rails 4+, a página inicial da aplicação “Welcome aboard” não fica mais em public/index.html (como até no Rails 3), e sim está localizada em uma gem. Ao acessar a aplicação no browser, no log do server dá para saber onde está o arquivo index.html. No meu caso está em:



/home/user/.rvm/gems/ruby-2.2.1/gems/railties-4.1.8/lib/rails/templates/rails/welcome/index.html.erb


 

Atributo acessível por meio de Form no Rails 4+

Para que um atributo de um modelo fosse acessível através de um formulário no Rails, bastava adicioná-lo à lista de atributos acessíveis da classe de modelo, em app/models/class.rb

class Class < ActiveRecord::Base
  attr_accessible :atribute1, :atribute2  
end

A partir de Rails 4, o attr_accessible foi substituído pelo conceito de Strong Parameters.
Para dizer à classe modelo que um atributo é acessível por meio de um formulário, basta adicioná-lo como atributo permitido no método class.params do controller respectivo da classe modelo, em app/controllers/”name_table_db”_controller.rb:


 private    
    def class_params
      params.require(:class).permit(:atribute1, :atribute2)
    end
end

Sobre Padrões de Projeto

Terminando o curso “Design Patterns para bons programadores em C#”,  da Caelum, onde vi alguns padrões de projeto, fui desafiada a escrever a respeito, concluindo o que aprendi no curso.

Sobre Padrões de Projeto, vejo que são soluções elegantes para resolvermos os problemas do dia a dia de desenvolvimento como vários ifs, repetição de código, trechos de código parecidos, alto acoplamento entre as classes e classes e métodos que tem variadas funções (baixa coesão). Os padrões de projeto resolvem esses e outros problemas, visando um código com qualidade.

Os padrões de projeto fazem uso de abstrações como interfaces e classes abstratas. Implementam classes coesas, pequenas, com responsabilidade única, o que facilita o entendimento e manutenção dessas classes, e, também, a expansão do sistema mantendo a qualidade do código. Antes da implementação desses padrões, o mais importante é o entendimento do conceito por detrás de cada um deles, ou seja, por que surgiu e em quais situações deve ser aplicado. Se eu entender o conceito atrás de um padrão, poderei identificar as situações no meu dia a dia de desenvolvimento onde aplicar determinado padrão ou outro, sempre visando um código de qualidade, utilizando os conceitos de Orientação a Objetos.

Em resumo, os padrões de projeto aplicam os conceitos de Orientação a Objetos, como interfaces, classes abstratas, baixo acoplamento, alta coesão, independência funcional, ocultamento de informação. Aplicando padrões de projeto na minha maneira de programar estarei utilizando a OO.

 

Padrão de desenvolvimento de aplicativos para Windows Phone

O que chamou minha atenção quanto à plataforma móvel do Windows – Windows Phone – foi seu design, sua “carinha” moderna, “despojada”, “jovem”, “sem formalidade”, diferente das outras que, como usuária, vejo que tem uma “carinha” mais séria, padrão, sem diferenças grandes ou marcantes. Já o padrão do Windows Phone me cativou. Apaixonei-me por ele (hehe). Sinto que é minha cara (haha): alegre, divertido, dinâmico, cheio de cor, de vida. Como usuária, me identifico com o Windows Phone.

Passando para desenvolvedora de aplicativos para plataformas móveis, iniciante, no momento, comecei a estudar sobre o desenvolvimento para Windows Phone. O e-book que estou lendo diz que o padrão dos aplicativos desta plataforma é apenas um guia a ser seguido ou não. Diz que é mais importante a identidade visual das empresas (como Facebook ou Twiter) do que o padrão de cada plataforma. Bom, eu discordo totalmente e explico por quê. Primeiro, por que foi justamente pelo padrão do Windows Phone que me apaixonei. Então, para mim, como usuária, ele é importante e é importante que eu o veja nos aplicativos que instalo no meu smartphone. Eu não me apaixonei pelo padrão do Android ou do iOS, se assim o fosse, eu usaria essas plataformas. Segundo, eu sugeriria às grandes empresas, como Facebook ou Twiter, que desenvolvam seus aplicativos respeitando o padrão de cada plataforma, por favor. Eu, como usuária de Windows Phone, quero pegar seu aplicativo e ver nele a “cara” do Windows Phone, usá-lo como aplicativo de Windows Phone, ou seja, ter a experiência de usar um aplicativo Windows Phone. Assim, o usuário do Android ou do iOS também espera o mesmo. É possível manter a identidade visual da empresa ou de seu aplicativo mantendo o padrão de cada plataforma. Isso é bem possível. Aliás, se precisarem de dicas, me procurem! Como usuária, posso apontar onde o padrão da minha plataforma preferida não está sendo respeitado! Concluindo, cada plataforma possibilita uma experiência de usuário diferente e, por favor, deve ser respeitada. Seja pelas grandes empresas ou qualquer desenvolvedor que publica seus aplicativos em uma Store. Vamos estudar sobre cada plataforma, sobre como essa experiência é importante para o usuário. Dessa forma, vamos ter motivo de nos orgulharmos pelos nossos aplicativos publicados. No caso das grandes empresas, vão fazer seus usuários felizes. E, fazer um usuário feliz é importante, pois é esse (ou deveria ser) o propósito do nosso trabalho como desenvolvedores de aplicações. Melhorar ou simplificar a vida das pessoas, proporcionar experiências positivas a elas são objetivos que vou buscar com o meu trabalho, com a minha profissão de analista de sistemas (\o/).