Qcon 2008: Strategic Design

Strategic Design
Palestra ministrada por Eric Evans - autor do livro - Domain Driven Design

Ele já começou questionando o que se considera um sistema bem desenhado. O que motiva as pessoas a fazerem refactoring?
Logo na seqüência ele já enunciou que nem todo sistema grande será bem desenhado. Um sistema grande que é importante, é também vivo e tem mudanças a todo tempo. A arquitetura sempre precisa de refactorings. Porém, de nada adianta colocar isso para o patrocinador do projeto ou unidade de negócio sem atrelar a um valor agregado compreensível. Esse ponto de vista é diferente daquele de refactoring em times ágeis, onde não necessariamente há inclusão de nova funcionalidade. Acho que é mais uma questão de postura de negociação do que o conteúdo do refactoring em si. Você tem de procurar vender a idéia de refactoring pensando em redução de custo, ou para facilitar as manutenções, ou mesmo aumentar a capacidade do sistema. Sem dogmas técnicos para o cliente ou product owner. O importante é ele ver algum valor no negócio. E nem sempre ele vai concordar. Isso me fez lembrar um caso. Tenho um amigo que já me contou uma situação em que um departamento de TI de um banco grande no Brasil decidiu comprar uma máquina bem mais poderosa em termos de processamento, ao invés de fazer uma mudança banal no sistema como, por exemplo, trocar o uso intenso de banco de dados por cache. Não é o negócio do banco ter o melhor sistema e talvez nem faça sentido a economia versus alocação de pessoas, desenvolvimento, testes e gestão de risco e impactos em mexer em sistemas.

Voltando à palestra, Eric citou um caso que ele vivenciou:
- um sistema antigo de 10 ou 12 anos de idade
- cliente infeliz

Como ele estruturou o refactoring do sistema:
- generic subdomains - genéricos no ambiente de trabalho
- supporting subdomains - tem haver com o domínio, mas não é a essência
- core domain - pequena parte que representa o que as pessoas procuram para gostar do produto

Do que eu entendi da classificação acima seria, para um sistema de blog, por exemplo:

- generic subdomain: sistema de e-mail para envia mensagens de anúncio da página ou post do blog. Uma estrutura genérica de servidores de e-mail;

- supporting subdomains - o sistema gerenciador de arquivos e quotas do conteúdo do internauta para armazenar blogs, fotos, vídeos, áudios, etc.

- core domain - subsistema de edição de posts e exibição da página.

É claro que esse tipo de classificação é contextual. Quero dizer, para o dono do produto blog, o core domain é certamente o que está citado acima, pois é onde o produto dele vai atrair ou não usuários. Porém, se você estiver com uma demanda de aumento de capacidade de armazenamento de contéudo do internauta, mantendo custo médio menor, o seu cliente ou definidor de requisitos deverá ser uma pessoa com perfil mais de operações e técnico. Por isso, nesse caso, o core domain passará a ser outro. Novamente, pensar sem travar em dogmas e contextualizar para tomar a melhor decisão é importante.

Os melhores programadores tendem a procurar os subdominios genéricos. Tem problemas mais interessantes. Isso se parece bastante com o que estou acostumado ver também. Os domínio mais genéricos tem relação com infra e o desafio técnico é maior.

Lembrando do papel do arquiteto no refactoring, Eric disse que às vezes é difícil conduzir isso com alguns programadores. Depois de alguns ajustes que são colocados, alguns programadores não tão experientes tendem a fazer ajustes fora do combinado no core domain. Como é no core domain que está a essência do valor para o negócio, isso, muitas vezes, leva a uma meritocracia injusta, onde uma pessoa não tão qualificada tecnicamente gera uma percepção de eficiência, e desorganiza a arquitetura do sistema. Por isso, ele aconselha a colocar as pessoas mais experientes no core domain também.

Embora as pessoas tendam vigiar o pior programador do time, o que causa mais danos é o segundo pior, pois ele está fora do alcance e não está em evidência.

Em resumo: coloque as pessoas melhores no core domain.
http://domaindrivendesign.org/

Qcon 2008: Apresentação adicional sobre o Google App Engine

Atualmente o uso de Google App Engine é gratuito, mas eles estão pensando em cobrar. O que eles garantem que será sempre grátis é:
- 500MB storage
- 2GB banda /mês
- em torno de 5 milhões de page views/mês

Quando for cobrado, o preço pode ser:
- CPU - 10-12cents/h
- GB storage - 15-18cents/h
- banda saída - 11-13 cents GB
- banda entrada - 9-11 cents GB

Funcionalidades presentes hoje:
- memcache
- ambiente de execução Python
- uso de persistência (Big Table)
- poder fazer http requests
- manipulação de imagens (tenho de olhar mais)
- https

Mais sobre essa apresentação, você pode encontrar no link abaixo. A senha é qcon .

 http://alexst.discovirtual.uol.com.br/disco_virtual/qcon2008/ManoMarks_App_Engine.ppt

Qcon 2008: Tutorial de Google App Engine

Participei de um tutorial de 4 horas sobre o google app engine (http://code.google.com/appengine/)  ministrado pelo Mano Marks.  Esse é um serviço em que você pode escrever o seu código Python, e colocá-lo para rodar como se fosse um CGI na infra-estrutura de data center do Google, tendo uma plataforma para persistência (Big Table). Você coloca a aplicação para funcionar e não tem de se preocupar com a quantidade de servidores onde ela será executada.

Set up do google app:
Muito fácil em Mac. Não sei se é assim no Windows

1 ) instalar SDK em http://code.google.com/appengine/downloads.html

2) pegue código exemplo para você ver em
http://google-app-engine-codelab.googlecode.com/files/AppEngineCodelab_v5.zip

3) comece a usar o GoogleAppEngineLauncher e leia um projeto já existente. Os botões dele vão te fazer navegar, pois a usabilidade do launcher é muito boa.

Tudo pode ser escrito em Python, por enquanto. Promete evoluir para outras linguagens, mas não garante COBOL. @:-)). Novidades serão anunciadas para o primeiro trimestre do ano que vem.

Por que Python? C++, Java e Python são as linguagens de programação no Google. Eles começaram a usar o Python. Um amigo (Gleicon) me disse que talvez eles tenha escolhido Python para poderem filtrar mais facilmente o que o desenvolvedor pode fazer. Por exemplo, o Python que é executado no Google App Engine não permite escrita em file system. A persistência só pode ser feita em Big Table.

BigTable é diferente de bd relacional. O relacionamento entre entidades se dá entre objetos e não entre classes. Logo há uma maior dependência da aplicação para manter a base de dados consistente e íntegra. Para acessar a base de dados, você deve usar GQL (google query language), que parece com o SQL, mas só tem select.

Cada aplicação tem um arquivo app.yaml para definir a aplicação. Lá diz onde qua o arquivo .py vai iniciar a aplicação.

Segundo o instrutor, a motivação do Google é:
 - melhorar a web
 - eventualmente será cobrado
 - quanto mais aplicações, mais publicidade e pessoas navegando

Os domínios podem appspot.com ou próprios

Eles também usam memcache api. Com vídeos educacionais, eles ensinam como os desenvolvedores a construírem aplicações mais escaláveis. Para isso, ele recomendda ver o vídeo building scalable web applications with google app engine com Brett Slatkin. O vídeo está abaixo.