A lei de Demeter é um conjunto de regras para construir sistemas visando baixo acoplamento, também conhecida como Princípio do menor Conhecimento e Fale somente com os amigos. Apesar do nome, Demeter não foi o autor, Demeter é o nome do projeto conduzido pela universidade Northeasterns University em 1987 liderado pelo Dr. Karl Lieberherr. Foi projeto Demeter que as leis foram criadas e por isto o nome.
Em linhas gerais, as regras são:
Em orientação a objetos, definido que uma unidade=método de um objeto, a lei é traduzida da seguinte forma:
Um método M de um objeto O somente poderia acessar métodos de outros objetos que sigam as diretrizes:
-
Seja parâmetro de M
-
Um objeto que M criou
-
Um método do próprio objeto O
-
Objeto diretamente relacionado com o objeto O
-
Uma variável global acessível pelo objeto O
Para não ficar muito abstrato, vamos aos exemplos:
Seja parâmetro de M:
public class A{
public void FazAlgumaCoisa(B parametro){
parametro.FazOutraCoisa();}
}
Um objeto que M criou:
public class A{
public void FazAlgumaCoisa(){
B objetoB = new B();
B.FazOutraCoisa();}
}
Um método do próprio objeto O
public class A{
private void FazOutraCoisa(){
//faz algo}
public void FazAlgumaCoisa(){
FazOutraCoisa();}
}
Objeto diretamente relacionados com o objeto O
public class B{
public void FazOutraCoisa(){
//Faz algo}
}
public class A{
private B _objetoB;
A(){_objetoB = new B();}
public void FazAlgumaCoisa(){
_objetoB.FazOutraCoisa();}
}
Um dos grandes problemas que temos na manutenção de sistemas OO é o alto acoplamento, ou seja, nossos objetos “falam” com muitos objetos, e quando isto acontece, se eu alterar um objeto no sistema, posso ter efeitos colaterais nos chamadores. A lei de Demeter como vimos, ajuda a diminuir este acoplamento. Algo do tipo
public class C{
public void FazMaisOutraCoisa(){
//Faz algo}
}
public class B{
public C FazOutraCoisa(){
return new C();}
}
public class A{
private B _objetoB;
A(){_objetoB = new B();}
public void FazAlgumaCoisa(){
_objetoB.FazOutraCoisa().FazMaisOutraCoisa();}
}
fere a lei de Demeter, pois não estou mais falando com um “amigo” e sim com o método de C que é o objeto de retorno de B, o “estrangeiro”. Agora nossa classe A tem acoplamento com B e C. Se alterar algo em C, tenho efeitos em A. Sacaram ao que leva a lei de Demeter?
Um dos princípios de orientação a objetos que leva a concordância com a lei de Demeter, é o princípio da responsabilidade exclusiva do S.O.L.I.D. Porque digo isto? Simples, quando meu método começa a usar muitos recursos de outro objeto, em vez do próprio objeto ao qual pertence, provavelmente este método está no local errado, resumindo, não faz parte das responsabilidades do objeto que está. Outro princípio interessante de OO que ajuda a atingir a lei é o Tell don’t ask, mas este deixo para vocês lerem nas referências deste post.
Concordam com Lei, o que acham?
Referências: Law of Demeter, S.O.L.I.D, Tell don’t ask, Artigo do Giovanni Bassi sobre Tell don’t Ask
[]’s Fábio Margarito
Com certeza se desconhece estes termos, já os usou sem saber. Vamos ver em C# como isto rola.
Dynamic Dispatch: A Wikipedia define como "...processo de mapear uma mensagem para uma sequência de código em tempo de execução", simplificando, é o recurso que a plataforma de desenvolvimento oferece, onde você consegue executar um método sem saber detalhes do tipo em tempo de compilação. Se houver algum erro, como nome de método incorreto, falta de parâmetros ou tipo incorreto de parâmetro, só será possível saber em tempo de execução. Linguagem dinâmicas que não são tipadas(ex. JavaScript), utilizam o recurso de dynamic dispatch o tempo todo. Quando precisamos executar algum componente COM em .Net, também utilizamos dynamic dispatch. Para exemplificar, utilizando C# 3.5 vou executar o método Soma dinamicamente.
using System;
using System.Reflection;
namespace DynamicDispatchDynamicBinding
{
class Calculo
{
public int Soma(int a, int b){
return a + b;
}
}
class Program
{
static void Main(string[] args)
{
var tipo = typeof(Calculo);
var objeto = new Calculo();
var retorno = tipo.InvokeMember("Soma",BindingFlags.InvokeMethod,null,objeto ,new object[] { 10, 20 });
Console.Write(retorno);
}
}
}
Com a nova DLR(Dynamic Language Runtime) incluída no .Net 4.0, ficou bem mais fácil
using System;
namespace DynamicDispatcherDynamicBinding40
{
class Calculo
{
public int Soma(int a, int b)
{
return a + b;
}
}
class Program
{
static void Main(string[] args)
{
var tipo = typeof(Calculo);
dynamic objeto = new Calculo();
var retorno = objeto.Soma(10, 20);
Console.Write(retorno);
}
}
}
Dynamic Binding: É a forma de determinar a partir do objeto recebido, qual a implementação do método deverá ser executada em tempo de execução. Com exemplo fica mais fácil
using System;
using System.Reflection;
namespace DynamicDispatchDynamicBinding
{
class Calculo
{
public virtual int Soma(int a, int b)
{
return a + b;
}
}
/*Cálculo incorreto propositalmente*/
class CalculoFilho1:Calculo
{
public override int Soma(int a, int b)
{
return a + a + b;
}
}
class Program
{
static void Main(string[] args)
{
/*Dynamic Binding*/
Calculo calculo = new CalculoFilho1();
Console.Write(calculo.Soma(10, 20));
}
}
}
Nossa variável é do tipo Calculo, entretanto, o método executado foi da subclasse que é o tipo instanciado. Entenderam?
Referências: Dynamic Dispatch,
Dynamic Binding,
DLR
[]'s
Fabio Margarito
A galera do grupo Coding Dojo Floripa, postou aqui um excelente post com um apanhado de tutorias, vídeos entre outros recursos sobre TDD. Vale a pena dar uma olhada!
[]'s
Na prática, um percentual muito pequeno de desenvolvedores realiza algum tipo de teste nas aplicações, é triste, mas é a realidade. Sem testes(criados antes, ou depois da implementação de um código), torna-se impossível qualquer melhoria futura(Refactoring).
Ao observar equipes trabalhando, é perceptível que boa parte do tempo é gasto no Debug do Visual Studio(Ou ferramentas similares). A mecânica atual do trabalho de muitos desenvolvedores é a seguinte:
-
cria-se uma funcionalidade completa(Tela,Código, Banco)
-
roda-se a aplicação
-
o sistema falha(raramente roda da primeira vez sem nenhum bug)
-
inicia-se a epopéia no debugger para adivinhar onde ocorre o erro
-
corrige-se o bug
-
repete-se o ciclo até que todos os bugs foram corrigidos
Para mim é desperdício de tempo, e já justifica por si só, o tempo gasto na criação de um teste unitário. Eu Queria entender melhor, o motivo pelo qual eles trabalham da forma que relatei e questionei a alguns desenvolvedores. Por quê vocês não fazem testes unitários? . As respostas foram bacanas:
-
"Testes unitários demoraram muito para serem criados, pois tenho que criar tela para testar o código, etc..."
-
"Você está enganado, já fazemos testes unitários, o responsável pelo teste pega a aplicação pronta e reproduz na UI os passos previstos em algum caso de testes"
-
"Testes unitários são complicados, tenho que colocar n referências no código fora a dificuldade de configurar o ambiente para os meus testes"
Na realidade, o problema não são os testes, e sim a falta de conceitos, preparo dos profissionais e ausência de métricas que comprovem o desperdício de tempo e o real custo de um sistema(construção + manutenção).
Para não fugir do título do post e argumentar os motivos da não execução de testes unitários, vamos alinhar e entender a real diferença entre teste unitário e de sistema:
Testes unitários: São testes isolados que o desenvolvedor realiza em unidades de código isoladas, por exemplo, testar o método de uma classe. O teste unitário deve ser isolado e sem efeitos colaterais aos demais testes. Dependências externas(outros objetos, banco de dados,etc..), devem ser substituídas por mocks e stubs, pois a finalidade é testar aquele trecho de código em específico, e de presente você ainda cria aplicações menos acopladas. É ideal que os testes sejam automatizados, assim você os roda quantas vezes quiser a cada alteração de código. Se após a inclusão de uma melhoria, ou, adição de uma nova funcionalidade algum teste do conjunto falhar, é fácil identificar o bug, pois sei exatamente o que foi alterado, portanto, ganhamos produtividade. Existem n vantagem em utilizar testes, pontuei apenas algumas.
Testes de sistemas: São testes realizados na aplicação de modo integrado e pouco importa como a aplicação foi codificada. O teste é baseado nas funcionalidades solicitadas e requisitos não funcionais(usabilidade, desempenho, etc.). Existem vários tipos de testes de sistemas e estes devem ser executados conforme necessidade, tais como: Testes de usabilidade, de estresse, de carga de segurança entre outros. Para mais informações, consulte os links em saiba mais.
Saiba mais
Espero que tenha ficado clara a diferença e que as definições e material de apoio os ajudem a colocar os testes unitários no seu dia a dia, com certeza vocês não se arrependerão.
[]'s
Fabio Margarito
Freqüentemente, em reuniões de arquitetura, orientamos os desenvolvedores a criarem mecanismos de logging e tracing, com o simples objetivo de ajudá-los a identificar problemas em produção rapidamente. Estes mecanismos fazem parte do processo de instrumentação da aplicação.
Em grandes organizações, como bancos e seguradoras, o acesso a produção é restrito(graças a Deus, nosso dinheiro agradece), não conseguimos, por exemplo, em caso de problemas, abrir nosso componente e colocar uma entrada no eventlog com aquelas mensagens clássicas "Passei por aqui!!!", portanto, instrumentar o código é de fundamental importância, e com certeza vai te poupar muita dor de cabeça. Infelizmente é algo pouco praticado pelos desenvolvedores em geral.
Uma dúvida freqüente, é a diferença entre logging e tracing. A diferença está no teor e quantidade de informações coleadas e armazenadas.
Logging: É o registro contínuo, de qualquer tipo de informação que importante para o usuário final do componente e da aplicação. O logging gera um volume de dados bem inferior a um processo de tracing devido a natureza dos dados. Exemplos de logs:
-
Registro de um erro inesperado
-
Registro do nome do usuário e data quando um dado sensível do sistema foi alterado
-
Registro dos acessos realizados a um sistema, entre outros.
Tracing: Registro de informações extremamente detalhadas e geralmente de cunho técnico, sobre o processo de execução de um componente. É uma informação relevante somente ao desenvolvedor do componente e equipe de suporte.É interessante que o trace seja parametrizável(liga/desliga) e classificável(ERROR,INFO,etc...), possibilitando que ao ligar o log, você determina que tipo de trace é desejado. Exemplos:
-
Passo a passo de execução de uma rotina
-
Dados relativos ao tempo de execução de uma rotina
-
Erro detalhado(mensagem, pilha de execução, fonte, etc..)
Cuidados a serem tomados
Expurgo: Uma vez definido quais logs e traces sua aplicação terá, é necessário definir a política de tempo que a informação ficará em repositório(File System, Banco de dados, etc...). Geralmente logs oriundos de obrigações legais, ficam em torno de 5 anos armazenados, traces, devido a natureza prolixa com propósito de curto prazo, ficam um ou dois em base. Limpar logs é necessário, pois a taxa de crescimento é expressiva e consome muitos recursos.O expurgo pode ser feito de várias formas:
-
-
Tarefa agendada do Windows que executa alguma linhas de comando que faz a atividade de expurgo
-
A própria aplicação fazê-lo de tempos em tempos(não recomendável)
-
Produtos comerciais
-
Ferramenta criadas pela própria empresa
Baixa interferência: O logging/tracing não devem onerar a aplicação submetida a instrumentação. Se houver algum tipo de latência, que seja a menor possível. Menor é subjetivo e deve estar alinhado com tempo de resposta esperado pelo processo de negócio. A melhor forma de mitigar este problema é a inclusão assíncrona destes logs, ou seja, o componente não espera a inclusão de logging/tracing para que continue sua atividade.
Frameworks
Existem diversos frameworks, e utilitários já disponíveis para instrumentar a aplicação, dos quais posso citar:
TraceSource: Classe introduzida no .Net 2.0. O WCF o utiliza para o trace e diagnóstico de problemas
Log4Net: Um dos mais famosos frameworks para esta finalidade e portado do Java.
Logging Application block: Parte integrante do Enterprise Library.
Este é basicamente um post teórico e com objetivo de elucidar dúvidas sobre algo tão pouco posto em prática. Assim que possível, vou postar algo mais prático, mostrando algumas maneiras de instrumentar a aplicação, como por exemplo, por OAP.
Referências:
The Difference Between Logging and Tracing
Application Instrumentation
Vamos a um post menos técnico. Gostaria de falar um pouco sobre carreira, nossos papéis como técnicos e o futuro.
Trabalhar, desenvolver-se e realizar-se é o objetivo final da maioria dos profissionais, pelo menos deveria. Quando escolhemos alguma atividade para seguir, é necessário passar por todo um processo de amadurecimento que leva certo tempo. Em determinado momento, o profissional precisa tomar uma decisão, ou melhor, se conhecer e avaliar suas ambições de carreira.
Ainda hoje, acredita-se que o topo da ascensão é um cargo executivo. Está claro, e é fato, que existem diferentes tipos de pessoas, algumas se sobressaem melhor na área técnica (racionais) e outras tendem para a área de humanas.
Infelizmente, devido ao geral aculturamento que temos, nos é embutido que somente cargos executivos trazem sucesso e excelente remuneração. Assim temos a velha estória: “promovo meu melhor técnico e crio um gestor medíocre”.
Para resolver este tipo de problema e ajudar na decisão do futuro profissional, há o modelo de carreira em y, que visa basicamente o desenvolvimento parelho, em salário e oportunidades, tanto para a área técnica quanto para cargos gerenciais. O sistema não desprivilegia o candidato que não tem um perfil gerencial, até porque, cargos gerenciais são limitados.
Carreira em Y é excelente e seria muito justa se houvesse a aplicação real. Infelizmente, conto com os dedos da mão esquerda, às empresas que me disseram que aplicam este mecanismo(Brasil). Não precisamos ir muito longe, quantos programadores com mais de 40 anos (COBOL não vale 
) vocês conhecem? A quantos gestores medíocres vocês já estiveram subordinados? A resposta das questões dá um bom termômetro do mercado.
Aí me vem algumas perguntas:
-
Será que o Brasil está realmente preparado para geração carreira Y? Sinceramente não sei, pelo menos por onde já passei, não consegui vislumbrar nenhuma prospecção de que poderia ocorrer algo a curto e médio prazo, que mudasse a organização.
-
Não seria justo que excelentes técnicos, recebessem igualitariamente recompensas (bônus) por bons trabalhos e alcance de metas? Em minha opinião, é totalmente justo, visto que sem um bom time, nenhum gestor consegue atingir metas e superá-las. Ele precisa de um time de porte, que compre seu sonho de realização e que tenham potencial de torná-los viáveis.
Por tudo isto eu me questiono, vale continuar sendo técnico, ser desprivilegiado e ganhando salários inferiores, ou, investir na área de gestão (mesmo não tendo tanta aptidão), conseguir bons salários, viabilizar sonhos?
Qual a opinião de vocês? Eu ainda estou procurando a resposta!!!! Infelizmente o tempo voa.
Giovanni, comecei a disciplina recomendada no seu blog,rs.
[]’
Fabio Margarito
Olá pessoal,
Depois de um bom tempo sem escrever, voltei a ativa. Neste post queria indicar excelentes vídeos das palestras que ocorreram no NDC 2009. Temos diversos ícones da área de tecnologia, dos quais gostaria de destacar, Bob. Martin(Uncle Bob), Ayende Rayen e Scott Hanselman.
Vale a pena conferir: http://blog.fohjin.com/blog/2009/7/1/NDC_videos_are_published
[]'s
Fabio Margarito
A Scrum Aliance publicou um artigo excelente sobre os 10 maiores impedimentos organizacionais na adoção do SCRUM. Cada ponto de vista, foi defendido por especialistas de diversas empresas. Vou citá-los e colocar minha opinião a respeito de cada um. Fiquem a vontade em criticar,e dar sugestões.
Gostaria de salientar que as traduções foram livres e realizadas por mim.
10. Failure to Remove Organizational Impediments (Falha ao remover barreiras organizacionais)
Muitas empresas na quais trabalhei tem esta dificuldade, ou seja, problemas em promover mudanças a fim de melhorar o processo de trabalho, é como o autor captou a visão de cada uma “é assim que sempre fizemos negócios”, e “não queremos mudar porque já investimos muito nisto”. Para ganhar competitividade muitas vezes é necessário estar a frente do seu tempo. É um risco, mas se der certo você estará na frente dos seus concorrentes. Aqui posso citar o caso de uma grande seguradora, em 1994 a empresa tinha que decidir se utilizaria Windows e plataforma Microsoft, ou , se escolheria outra tecnologia. A decisão foi por Microsoft, na época, uma aposta. A aposta funcionou, em pouco tempo era a única seguradora com diversos processos automáticos e emissão na hora de apólice, com quadro de funcionários enxuto fazíamos o trabalho de grandes seguradoras. Muitas seguradoras já fazem isto, mas começamos bem antes, e, portanto, uma empresa inovadora e competitiva.
9. Misguided Cost Savings and Synergy Efforts (Economia de custos sem orientação e sinergia de esforços)
Este é interessante. Manter equipes com propósitos definidos, por exemplo, como citado, para quais ferramentais que foram homologados e que outras equipes devem usar. Não vejo problema em definir uma ou mais ferramentas, mas no fato de obrigar que outros times usem algo sem ao menos serem consultados. Acho fundamental antes de qualquer tipo de adoção, o envolvimento de todas as equipes, para que possamos ver em conjunto o que agrega e o que atrapalha, e assim, fazer com que todos comprem a idéia. POCs servem para isto. Alguém já viu ferramentas ou metodologias que são adotas por um tempo e depois caem no esquecimento? Por que será?
8. Lack of Training (Necessidade de treinamentos)
Empresas geralmente acham que treinamentos, coaching ou mentoring, são totalmente dispensáveis, isto fica claro em momentos de crises, as que têm este tipo de política, cortam em primeiro lugar treinamentos. O que não é legal é aplicar diversos treinamentos sem nenhum tipo de objetivo, pois com o tempo são totalmente perdidos,e aí sim, dinheiro jogado fora. Quando se deseja entrar em uma nova onda, na qual a equipe ainda não tem fluência, e de vital importância montar um planejamento de implantação, e em seguida selecionar os tipos de capacitações necessárias. Em 2004 na empresa que trabalhei, havia a necessidade de montar uma equipe de arquitetura. Com planejamento, inicialmente foram realizados alguns cursos e para emplacar, solicitamos um trabalho de mentoring, ou seja, condução de um projeto bem orientado e realizado a quatro mãos, que gerou um resultado final compensador.
7. Single-Function Groups (Grupos funcionais únicos)
Em grupos ágeis a comunicação é pilar principal e muitas vezes criar grupos especializados em alguns assuntos, podem coagir outras equipes. Quem nunca viu em uma empresa, aquele grupo denominado “Deuses”, o detentores de conhecimentos privilegiados, os inacessíveis,etc. Para mim, tudo balela, geralmente um grupo de egocêntricos, e no final da contas, pessoas com medo de ceder conhecimento e perder a posição. Em todos estes anos, percebi que o interessante e compensador é evangelizar e disseminar conhecimento.
6. Local vs Global Optimization(Otimização local versus otimização global)
A autora, pelo meu entendimento, critica o fato de montar estratégias locais em vez de globais, ou seja, esquecendo o alinhamento estratégico da organização como um todo e somente atuando pontualmente na organização. Exemplos estes como premiações, controles rígidos conservadores de projetos entre outros.
5. Assumption that Book Learning is Enough (Assumir que aprender com livros é o suficiente)
Vale algo que alguém falou para mim,”..os livros são fundamentais, porem, nos ensinam apenas a metade”. Ler alguns livros não significa que você se tornará um especialista. Nada como o conhecimento acadêmico aliado a prática, quando há a consolidação, temos o estado da arte. Outro ponto que auxilia em muito no aprendizado é o apoio de pessoas que já passaram por situações similares e que já aprenderam muito em outros projetos, o famoso orientador. Vamos aprender com quem já sofreu, não vale a pena reinventar a roda.
4. Individual Performance Evaluation and Reward (Avaliação individual de performance e premiações)
Se mal conduzido, pode jogar qualquer iniciativa no ralo. Quando se coloca prêmio(dinheiro, viagem, etc..) por algo realizado, muitas vezes para chegar em tal meta, “atalhos” são tomados, fora a concorrência interna e picuinhas. Times ágeis devem trabalhar em conjunto, com objetivo único, sem qualquer tipo rincha interna em prol de uma solução sólida.
3. Unrealistic Promises(Promessas irreais)
Típicas de alguns gerente de contas. “Sem problemas, para construir toda a sua intranet levo apenas 1 mês”, ou ,” implantar SOA é simples, em apenas 2 meses teremos serviços atômicos, bem definidos, reutilizáveis e com governança. “. Temos que ser pragmáticos, se for necessário um ano, precisamos falar, se for para fazer mal feito, melhor não fazer e continuar do jeito que está.
2. Assuming Agile Is All About Developers (Assumir que Agile é tudo sobre desenvolvedores)
Trabalhar com metodologias ágeis não é somente escolher uma abordagem TDD, programação em pares, entre outras técnicas de desenvolvimento. Gerenciamento de projetos ágeis envolvem toda uma mudança de paradigmas na organização, desde gestão de pessoas a relacionamento com clientes. Se não houver alinhamento estratégico entre os diversos times, é impossível atingir objetos significativos.
1. Silver bullet thinking and superficial adoption(Pensar que é bala de prata e adoção superficial)
Diversas consultorias de TI realizam fortes incursões de marketing afirmando que adotam metodologia ágil e todos os problemas de software como: funcionalidades não entregues, entrega fora do prazo e acima do custo estão resolvidos. No último Chaos Report do Standish Group 2009 podemos ver que ainda temos problemas. Ágil não resolve, ou levamos os problemas de uma abordagem para a outra? Como mencionei no item anterior, se não houver uma adoção sólida, seguindo boas práticas, com envolvimento real do cliente e alinhamento estratégico de todo o time, não tem jeito, o projeto afunda como todos os outros.
Trabalhamos em parceria com um consultoria que “utilizava” SCRUM, só que não tínhamos: reuniões diárias, feedbacks e muito menos um processo iterativo e incremental. No final das contas, foi um projeto cascata que ainda deixa um gosto amargo na boca.
Em resumo, acho que os autores foram muito felizes com o artigo e conseguiram captar a essência dos problemas, e que acho que podem ser aplicados a outros assuntos além de implantação de SCRUM. Vocês já sofreram com alguns dos itens mencionados?
[]’s
Fábio Margarito Martins de Barros
Neste segundo artigo da série, vamos iniciar a montagem de um ambiente voltado para integração contínua utilizando ferramentas Open Source.
A primeira etapa será a instalação da primeira ferramenta, o Cruise Control(CC), ferramenta Open Source de automação e gerenciamento de Build. O Cruise Control foi desenvolvido inicialmente pela empresa ThoutghtWorks e liberado como versão gratuíta para a comunidade. O CC, conta com uma arquitetura totalmente extensível, e possui três módulos distintos:
Build loop: é o coração do sistema, ele inicia processos de build e envia notificações aos usuários, como , problemas durante o build. A inicialização do processo de build poderá ser, por exemplo, quando o CC detecta uma mudança no sistema de controle de fontes (ex, Source Safe, SubVersion entre outros). O processo de build é composto por um workflow de tarefas, ex:
- Baixar os fontes
- Compilar
- Executar testes unitários
- Realizar cópia de arquivo
- Aplicar versão nos Fontes da aplicação
- Efetuar publicação da aplicação.
Todas as tarefas de build do projeto são mapeadas através do arquivo de configuração do CC que veremos em outro post. Cada tarefa, graças a arquitetura flexível do CC, poderá ser delegada a diversos plugins. Um dos plugins mais famosos é o NAnt, plugin de Build que também utilizaremos em momento oportuno.
JSP reporting: é o módulo responsável por exibir informações e artefatos gerados pelo processo de build. As informações são exibidas através de uma interface web de fácil utilização. Podemos visualizar informações tais como: tempo de build, data do build, erros, avisos, dados sobre testes unitários entre outras informações.
Dashboard: como o próprio nome diz, é um painel de instrumentos que tem o objetivo de mostrar status do build de um projeto. Este módulo também exibe os dados através de uma aplicação web rica em informações, que também pode ser acessada via
RSS.
A figura abaixo,retirada do site do Cruise Control, mostra a arquitetura detalhada do aplicativo:
OBS: Um pré-requisito é a instalação do Java Runtime Enviroment, que pode ser obtido no site do Java.
Então vamos começar a brincadeira, baixe o Cruise Control e execute o instalador, e clique em “Next”
Selecione o “Path” de instalação, vou manter o padrão. Clique em “Install”
Após procedimentos de instalação, o instalador pede que inicializemos o serviço do Cruise Control, através do Painel de controle de serviços. Clique em “Ok” e em seguida “Close”
Vá a Painel de Controle/Ferramentas Administrativas, e escolha a opção “Serviços”. Na listagem, procure o serviço do Cruise Control
Antes de iniciar é aconselhável configurar uma conta sob a qual o serviço irá rodar, esta conta deverá ter permissões restritas às atividades do servidor de Build. Para configurar é muito simples, basta clicar com o botão direito, escolher a opção “Propriedades”, escolher a guia “Log On” e informar o usuário.
Para iniciar, basta clicar com o botão direito do mouse e selecionar a opção “Iniciar”. Com o usuário configurado, inicie o serviço. Para sabermos se a instalação ocorreu com sucesso, vamos acessar o console de gerenciamento do Cruise Control através do endereço http://localhost:8080/dashboard/. Teremos a página abaixo:
No próximo post, vamos começar as configurações necessárias do Cruise Control.
[]'s
Fabio Margarito
Para quem quiser acompanhar, o Ayende Rahien(MVP) irá construir uma aplicação do zero, utilizando boas práticas de arquitetura de software. Diferente da maioria dos exemplos, desta vez não será locadora, biblioteca, ou até mesmo restaurante, será algo mais inusitado, o gerenciamento de uma prisão. Acho que vale a pena acompanhar.
Link da aplicação: http://ayende.com/Blog/archive/2009/07/27/macto-or-how-to-build-a-prison.aspx
Para quem não conhece o Ayende, ele é um dos contribuidores do NHibernate.
Provavelmente, vocês verão uma aplicação que não será distribuída(fisicamente), mas será distribuída em camadas lógicas, entretanto, as técnicas aplicadas ao domínio do problema são válidas e acredito que estará repleta de patterns utilizados na prática, e caso queiram expandir para uma aplicação distribuída fisicamente, bastaria criar uma camada de serviços nos servidores de aplicação(há outras questões que precisam ser discutidas) , utilizando, por exemplo, o WCF para comunicações com a camada de apresentação. Criar tudo em apenas uma máquina não é errado, é apenas um outro tipo de arquitetura.
Obviamente, diferente de uma aplicação distribuída, estas máquinas ao invés de especializadas para determinado cenário de utilização, serão mais potentes, e quando é necessário escalar a aplicação, é necessário colocar mais uma máquina no cluster, contendo um espelho da aplicação(técnica que o Windows Azure utiliza). Outro ponto legal da aplicação, pelos insights que vi, é que ela utilizará um Mapeador Objeto Relacional(ORM) que será o NHibernate(concorrente do Entity Framework da Microsoft, só que bem mais maduro, pelo menos até a versão corrente do EF).
No texto acima deixei diversos links com os conceitos e ferramentas.
Para quem não está acostumado com este cenário, é uma excelente oportunidade de aprendizado.
Vamos aguardar os próximos capítulos.
[]'s
Fabio Margarito