Segue a relação dos cinco melhores posts (ou os mais acessados e comentados) do ano de 2009.
.NET, Arquitetura, Ruby, Unix
Em um post anterior mostrei como serializar objetos em JSON utilizando .NET. Agora vamos fazer a mesma coisa com Ruby on Rails.
Esse é o Jason, não JSON.
Vamos utilizar como exemplo uma classe de modelo chamada SomeFake:
class SomeFake < ActiveRecord::Base end
Utilizando essa migration:
class CreateSomeFakes < ActiveRecord::Migration
def self.up
create_table :some_fakes do |t|
t.string :text
t.float :value
t.timestamps
end
end
def self.down
drop_table :some_fakes
end
end
No script/console vamos criar uma instância do modelo SomeFake com os seguintes dados:
>> fake = SomeFake.create :text => "I am a sample text.", :value => 150.85
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:18ac9f0,'0.15085E3',8(12)>, created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">
Então queremos serializar a variável fake em JSON para obter o seguinte resultado:
{"id":1,"text":"I am a sample text.","value":150.85}
Para fazer isso, vamos chamar o método to_json na variável fake (estou usando o comando print para uma exibição melhor no console do JSON gerado):
>> print fake_json = fake.to_json
"{"some_fake": {"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.", "id": 1, "value": 150.85, "created_at": "2009-12-13T19:43:28Z"}}"
O resultado que obtemos não é exatamente igual ao que estávamos querendo.
Primeiro, o nome do nosso modelo foi serializado como raiz do objeto em JSON. Isso aconteceu porque por padrão em uma aplicação Rails, a opção ActiveRecord::Base.include_root_in_json é configurada para true no arquivo config/initializers/new_rails_defaults.rb. Nós podemos alterar essa opção para false nesse arquivo, o que afeta a serialização em JSON de toda a aplicação, ou podemos alterá-lo no próprio script/console para nossos testes:
>> ActiveRecord::Base.include_root_in_json = false
=> false
Agora nosso objeto serializado fica assim:
>> print fake_json = fake.to_json
"{"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.", "id": 1, "value": 150.85, "created_at": "2009-12-13T19:43:28Z"}"
A segunda diferença é que não queremos que os atributos de timestamps (created_at, updated_at) sejam serializados. Então vamos dizer para o método to_json não serializar esses atributos, utilizando a opção except:
>> print fake_json = fake.to_json(:except => [:created_at, :updated_at])
“{”text”: “I am a sample text.”, “id”: 1, “value”: 150.85}”
Para fazer o inverso, transformar dados em JSON para um objeto, criamos uma nova instância da classe SomeFake e chamamos o método from_json passando a variável fake_json como parâmetro:
>> other_fake = SomeFake.new
=> #<SomeFake id: nil, text: nil, value: nil, created_at: nil, updated_at: nil>
>> other_fake.from_json fake_json
=> #<SomeFake id: nil, text: "I am a sample text.", value: #<BigDecimal:1708a04,'0.15085E3',8(12)>, created_at: nil, updated_at: nil>
Caso você precise serializar objetos em JSON sem os atributos timestamps com frequência, ao invés de sempre passar a opção except para o método to_json, podemos incluir um novo método na classe ActiveRecord::Base que faça a serialização sem esses atributos. Dessa forma, todos os nossos modelos terão essa funcionalidade.
Vamos chamar esse método de to_json_no_timestamps, o qual sua implementação é mostrada abaixo:
class ActiveRecord::Base
def to_json_no_timestamps(options = {})
timestamps_options = [:created_at, :updated_at]
if (options.has_key? :except)
if (options[:except].class == Array)
timestamps_options = options[:except] | timestamps_options
else
timestamps_options &lt;&lt; options[:except].to_sym unless options[:except].nil?
end
end
options[:except] = timestamps_options
to_json options
end
end
E então basta chamar nosso novo método em uma instância de qualquer modelo:
>> fake = SomeFake.first
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:1712798,'0.15085E3',8(12)>, created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">
>> print fake_json = fake.to_json_no_timestamps
"{"text": "I am a sample text.", "id": 1, "value": 150.85}"
Vamos usar um pouco de magia negra do Ruby para encontrar uma alternativa à implementação clássica do Design Pattern Decorator apresentado pela GoF.
Imagem original de MarketFare Foods, Inc.
.
Este post é a continuação de dois anteriores:
Se você ainda não os leu, recomendo que o faça para entender o contexto do exemplo onde estamos aplicando o Design Pattern Decorator. O ponto onde paramos no último post foi o meu descontentamento em decorar um objeto Cheeseburger de uma forma não muito intuitiva.
No post Cheeseburgers, Decorators e Mocks eu mostrei um exemplo prático de utilização do Design Pattern Decorator, que começa com um design usando herança, desaclopa usando composição e finalmente aplica Decorator. Tudo isso foi feito em .NET com C#. Agora vamos fazer o mesmo exemplo de Decorator Pattern utilizando Ruby. Para entender melhor o contexto do exemplo utilizado, sugiro que você leia antes o post anterior.
Imagem original de MarketFare Foods, Inc.
Além de Ruby, utilizarei o RSpec como ferramenta de testes unitários. No final do post há os links para baixar o código completo.
Em São Paulo, eu sempre comi cheeseburgers feitos com pão, hamburguer e queijo. Mas quando eu fui para Itararé, cidade do interior do estado de São Paulo, descobri que eles também colocavam milho no sanduíche.
Para exemplificar, vamos imaginar que o cheeseburger de Ilhéus-BA, venha com molho de pimenta. Só para constar, eu nunca fui para Ilhéus, apesar de ser a cidade natal de meu pai. Então na verdade não tenho a mínima idéia de como seja o cheeseburger de lá.
Imagem original de MarketFare Foods, Inc.
Vamos transportar esses três tipos de cheeseburgers para objetos e fazer alguns testes com eles. Usarei como plataforma .NET, linguagem C#, a ferramenta de testes unitários que vem com o Visual Studio 2008 e o Rhino Mocks como framework de criação de mocks.
Em agosto será lançada a tradução do livro Domain-Driven Design: Tackling Complexity in the Heart of Software
A versão em português, Domain-Driven Design: Atacando as Complexidades no Coração do Software, será lançado pela editora Alta Books com o preço inicial de R$ 85,41.
No site da editora aparece que o livro estará disponível a partir de 31/07/2009, mas de acordo com Anderson Camara da Alta Books, a previsão de lançamento é para 10/08/2009.
No Submarino o livro já aparece no catálogo como indisponível. Você pode cadastrar seu e-mail nesse endereço para ser avisado quando o livro estiver disponível para venda.
Uma coisa ruim é que o livro não terá o mesmo formato de capa dura do livro original. De qualquer forma, é uma ótima aquisição para quem trabalha com arquitetura de software e às vezes prefere ter um material de estudo em português.
Meu pai, que considero um exemplo de pessoa honesta, humilde e de bom caráter, me ensinou que na vida precisamos agir com serenidade. Ele me apresentou a oração da serenidade:
Concedei-me, Senhor, a serenidade necessária para aceitar as coisas que não posso modificar, coragem para modificar aquelas que posso e sabedoria para distinguir umas das outras.
Agora, o que isso tem a ver com desenvolvimento de software?
Imagine um cenário que você precise incluir uma nova funcionalidade em uma aplicação existente. Suponha que o código dessa aplicação não está muito bom, há acoplamentos entre os objetos, pouca cobertura de testes e a arquitetura deixa a desejar. Você precisa incluir a nova funcionalidade, mas não pode aumentar o débito técnico.
Por outro lado, você não irá refazer toda a aplicação de uma forma melhor, pois além de você não ter tempo (e dinheiro) disponível para isso, o sistema hoje atende os requisitos atuais e executa sem problemas.
Nessa situação, você precisa de sabedoria para distinguir o que pode ser modificado neste momento no código existente para melhorá-lo e o que você não irá modificar agora, já que não afeta diretamente a nova funcionalidade.
Você necessita de coragem para modificar o código legado, pagar o débito técnico, criar testes automatizados, refatorar, tornar o código mais claro, reformular o design, diminuir acoplamentos.
Você terá serenidade para aceitar que nem tudo pode ser melhorado agora, pois você tem prazo e orçamento a serem cumpridos. O objetivo neste momento é implementar a nova funcionalidade.
Com serenidade você pode alcançar uma melhoria contínua no seu software.
.
Obs.: Após rascunhar o conteúdo deste post dei uma olhada no meu leitor de feeds e me deparei com o post Parar e Refatorar? da InfoQ Brasil. A discussão sobre o tema é longa, mas a serenidade também se aplica.
No próximo dia 27 de junho vai rolar o primeiro evento do grupo de discussão sobre arquitetura de software .NET Architects.
Eu infelizmente não vou, pois estarei em outro evento. Mas Luciano Coelho e Rodrigo Ortiz, que trabalham comigo, irão e poderão nos contar tudo que aconteceu.
Algo interessante é que exatamente todos os assuntos que serão abordados, estaremos utilizando em um novo projeto que irá iniciar no segundo semestre.
Veja o conteúdo das palestras:
Programando com prazer com Domain Driven Design (DDD)
Giovanni Bassi
O Domain Driven Design é uma nova abordagem para desenvolvimento de software. Mas não é tão nova assim. Ela reune melhores práticas de OO e traz uma nova visão a velhos conceitos. Entenda nesta palestra a proposta do DDD, e porque ele pode mudar sua maneira de programar.
Utilizando Injeção de Dependência com Unity (Enterprise Library)
Leandro Daniel
Nessa palestra veremos o padrão de Injeção de Dependência como uma alternativa técnica na construção de aplicações plugáveis, onde se deseja manter a flexibilidade para troca de componentes com menor impacto de manutenção, maior reusabilidade e facilidade na aplicação de testes.
ASP.NET MVC: tome seu HTML de volta
Victor Cavalcante
Nessa palestra veremos o que é o ASP.NET MVC e o que ele não é, como ele funciona, diferenças entre ASP.NET MVC e Web Forms, extensibilidade, testabilidade, criação de templates com T4 e jQuery. A intenção desta palestra é dar informações suficientes para que o arquiteto decida utilizar ou não ASP.NET MVC.
ORM - Sendo preguiçoso com NHibernate
Juliano Oliveira
Nessa palestra você verá os principais pontos que fazem dos frameworks de ORM e do NHibernate ferramentas tão importantes nos projetos, desmistificar seus maiores mitos, os principais recursos, ferramentas de análise (NHProof) e verá também como ser produtivo com o NHibernate.
Testes: garantindo que seu código faz o que você quer
Mauricio Aniche
Entenda porque testes automatizados de software são importantes e quais as vantagens que ele traz para a equipe de desenvolvimento. Veja também na prática que criar testes automatizados é simples, rápido e realmente útil.
O valor da inscrição é de R$ 50,00 e o evento terá aproximadamente 9 horas de duração.
Mais informações você pode ter diretamente na página do evento.
“Frameworks and DDD: Keeping the Model Clean” foi mais uma das apresentações que assisti na QCon San Francisco 2008, em que Tim McCarthy mostrou algumas técnicas para desacoplar o modelo de domínio da infra-estrutura da aplicação e ainda sim continuar usando recursos de frameworks em .NET.
Tim McCarthy é autor de .NET Domain-Driven Design with C#: Problem - Design - Solution
A idéia é sempre deixar o domínio intacto, somente com o código do coração do software. Se você utilizar as famosas ferramentas de “arrastar e soltar”, vai poluir as entidades do domínio com código de infra-estrutura.
Quando falou a respeito do ADO.NET Entity Framework, o novo framework de mapeamento objeto-relacional da Microsoft, Tim se expressou indignado: “Oh, my God!”. Segundo ele, arrastar e soltar tabela por tabela do seu banco de dados, deixando o Visual Studio gerar um monte de código para você é algo não muito bom para se fazer.
Essas ferramentas de geração de código podem ser uma armadilha para desenvolvedores inexperientes. Para sistemas pequenos, sem grandes pretensões, isso pode ser uma solução rápida e que atende sua necessidade. Mas para grandes aplicações é preciso se concentrar no domínio e eliminar qualquer código que polua suas entidades de negócio.
Não é uma boa idéia criar um modelo de domínio fazendo a relação de uma entidade por tabela no banco de dados. As tabelas do banco de dados pertencem à infra-estrutura do sistema. O seu modelo de domínio deve ser rico e refletir seu negócio, o mais próximo da realidade possível. A partir do seu modelo de domínio é que você constrói uma infra-estrutura de persistência de dados.
A apresentação de Tim McCarthy foi repleta de exemplos reais (e rodando) de código. Num deles, mostrou uma classe de entidade do domínio onde havia uma referência using para o namespace Microsoft.SharePoint. Esse foi um tipico exemplo de entidade de negócio poluída.
Também tivemos um exemplo de utilização de repositórios (Repository), que segundo Tim, são um tipo de abstração da persistência, comparando-os como um tipo de coleção de dados, onde é possível listar, inserir, alterar e remover seus itens. Ele enfatizou que o classes do modelo de domínio podem usar repositórios, mas elas devem estar ligadas somente às interfaces dos repositórios, não acopladas às suas implementações.
Outra parte “prática” da apresentação foi a utilização de injeção de dependência (Dependency Injection) de repositórios nas classes de serviço e alteração do tipo de persistência via arquivo de configuração.
Tim também mostrou a implementação de uma unidade de trabalho (Unit of Work), onde a mesma não conversava diretamente com a base de dados.
A apresentação excedeu 10 minutos do tempo previsto, pois tinha muito código interessante a ser mostrado. Isso só acabou instigando a dar uma olhada no seu livro, que vem com o código fonte de todos os passos de construção de uma aplicação em .NET aplicando os padrões de DDD.
Só não esqueça que todo esse código somente vai poder lhe ajudar se você definir bem seu modelo de domínio, consistente e conciso com a realidade do seu negócio.
Você pode assistir à palestra no site da InfoQ:
http://www.infoq.com/presentations/Clean-Model-Tim-McCarthy
Baixe também os slides da apresentação em PDF neste endereço:
http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//TimMcCarthy_DotNet_Domain_Driven_Design_With_CSharp.pdf
.
Post original:
http://tecblog.locaweb.com.br/2008/11/24/qcon-frameworks-and-ddd-keeping-the-model-clean
Vou aproveitar o embalo do post sobre Automatização que o Erich colocou no blog de Tecnologia da Locaweb, onde ele fala que Neal Ford, no seu último livro “The Productive Programmer“, escreveu um capítulo inteiro sobre o assunto.
No último mês de novembro, estive na QCon San Francisco 2008 e tive o privilégio de assistir à palestra
“10 Ways to Improve Your Code” apresentada por Neal Ford.
São elas:
Você pode assistir à palestra que agora está disponível no site da InfoQ:
http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford
Baixe também os slides da apresentação em PDF neste endereço:
http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//NealFord_10_Ways_to_Improve_Your_Code.pdf
Comentários