.NET,C#, CLR,CLI,Boas práticas,Arquitetura,Agile
Arquitetura
AppHarbor : parte I
014 days
Olá pessoal, essa semana conheci o AppHarbor, o AppHarbor é um PAAS que permite executar todas as etapas necessárias para a publicação de uma aplicação .NET, se você já escutou falar do heroku então você vai perceber rapidamente que o AppHarbor é a solução com suporte ao framework .NET. Pra iniciar é necessário criar uma conta, temos a opção do plano grátis, após criar a conta vamos configurar uma aplicação asp.net mvc de exemplo versionada no bitbucket. 1-Nova applicação HelloWorld no AppHarbor 
2-Criar o repositório HelloWorld no bitbucket 
3-Gerar a url de build Agora vamos copiar a url do repositório gerada pelo bitbucket, no meu caso a url é
agora o próximo passo e acessar a aplicação no AppHarbor e clicar no link BuildURL.
4- Adicionar o serviço do AppHarbor no Bitbucket
Para isso devemos acessar o menu admin do bitbucket e clicar no item services do menu lateral esquerdo. Para obter os dados necessários basta usar a url gerada durante o BuildURL, minha url de exemplo é:
no campo token devemos colocar o valor da querystring authorization, no meu caso o valor é: uRlrJD14REWvvL0SoQULTK2hBhU1OZ1Gj%2f2qwoKsnUc%3d, o nome do projeto também pode ser obtido através dessa url, no noddo exemplo o valor é: helloworld-125, agora basta salvar as alterações.
O padrão da url gerada durante o build é:
https://appharbor.com/application/{project}/builds?authorization={token}
5- Adicionar o usuário do AppHarbor no repositório
Agora vamos acessar o menu Access Management e dar acesso de leitura para o usuário apphb.
Pronto! já podemos testar a integração do AppHarbor, basta realizar um push para o repositório do bitbucket.
6- Push na aplicação asp.net mvc 
6-Build!Build!Build! 
7-Acessando a aplicação publicadaPara acessar a aplicação publicada basta navegar até o menu hostnames e lá está a url da aplicação, a minha url é
http://helloworld-125.apphb.com/
Por hoje é só pessoal, no próximo post veremos como rodar testes unitários durante o build. Abraços!
E quando Linguagem é ubíqua mas é Legada?
2486 days
Contexto do problema
Olá pessoal, como o texto sugere o assunto será a linguagem ubíqua de um projeto de migração de sistema. Atualmente participo de um projeto de migração de um sistema de workflow desenvolvido em VB 6 e coisas da época, Assim que cheguei a equipe teve o início de mudança de paradigmas. As mudanças ocorreram no processo de desenvolvimento, terminologias e tecnologias. O modelo antigo usava notação Húngara e as pessoas se comunicavam usando expressões do tipo: O método A espera os parâmetros idPart e tpSt. O que isso quer dizer? depende do método! A utilização de siglas fazia com que termos tivessem mais de um significado, em determinado contexto o significado era esse:
idPart = Id do participante
tpSt = Status
Todas as equipes envolvidas com o produto falavam a mesma língua mesmo que essa língua fosse dúbia as veze, O fato é que existia e ainda existe uma linguagem ubíqua.
Solução do analista/Arquiteto
Eu desempenho o papel de arquiteto nesse projeto(sei que muitos discordam quanto a consideração de arquitetura sendo um papel) e logo que começamos a desenvolver usamos novos padrões de nomenclatura, e isso significa:
- Eliminação da notação húngara
- Adoção do inglês como padrão
- Diminuição da quantidade de siglas
Estamos desenvolvendo a nova versão do produto que inclui muitos produtos “acessórios” e tudo está ocorrendo razoavelmente bem, os clientes estão satisfeitos mas de fato poderia ser melhor(assunto para outro post), a equipe está razoavelmente acostumada com a tradução entre termos e tudo mais..O problema?
Hoje vejo que fui responsável por destruir parte da linguagem ubíqua!
Hoje vejo que a comunicação seria excelente sem traduções e etc., quando cheguei no projeto não tive a maturidade para ver que já existia uma linguagem e que todos estavam satisfeitos com ela. Fico feliz em hoje conseguir ver que fiz uma escolha precipitada.
É isso pessoal, gostaria de ouvir de outros desenvolvedores que passaram por esse embate entre uma linguagem ubíqua “Fora dos novos padrões” e uma nova linguagem que não é compartilhada pela equipe. Tem experiências? conta ai..
Compartilhando dlls entre várias aplicações usando o GAC
0639 days
Reusar código é uma boa idéia, então provavelmente seria uma boa idéia reaproveitar códigos em uma dll que forneça serviços por exemplo.Normalmente nós desenvolvedores reusamos uma dll construida com funções básicas. Desde .net 1.1 é possível compartilhar dlls entre aplicações usando o global cache assembly. Este espaço existe em qualquer maquina com o framework instalado, para começar a usar é necessário que o assembly a ser registrado possua um “Nome forte” que entre outras coisas é responsável por identificar de maneira única o assembly.
Criando um nome forte para o assembly
Após a configuração veja que foi gerado um arquivo com extensão .snk
Adicionar assembly na aba referêncy do Visual Studio
Após esta configuração temos um assembly com o nome forte, agora falta registrar o mesmo no GAC.Antes de registrar vamos mover o assembly para a pasta:
%Program Files%\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies
Com o assembly nesta pasta o visual studio reconhece nossa dll como uma dll do .NET, assim fica mais facil adicionar referências.
Registrando o assembly
Para registrar o assembly vamos usar o utilitário gacutil. o comando é gacutil /i nomedoassembly.dll
Agora já é possível criar aplicativos que possuem como referência um assembly registrado no GAC. Para adicionar a referência basta procurar na aba .NET do visual studio.
E quando eu alterar o assembly adicionado no GAC?
Quando um assembly do GAC for alterado será necessário registrar novamente o mesmo e reiniciar o visual studio para que ele atualize a sua referência de desenvolvimento. Como no projeto que surgiu a necessidade de usar o GAC estamos constantemente editando o projeto adicionado nós criamos um script para execução no Build Events do projeto. Se alguem precisar so script pode comentar aqui que eu explico como funciona.
Gerando código com templates T4 – Parte IGenerating code with T4 templates – Part I
0886 days
Hoje muito se ouve na comunidade .NET sobre templates T4.Não vou entrar no mérito de falar o que é pois vários blogs já o fizeram, você pode obter referências aqui, aqui e aqui. Eu mostrar um exemplo de como podemos gerar código sem conhecer muito do T4.
A ferramenta que vou usar é o VS2010 beta 2 com o add-on tangible t4 editor que pode ser baixado diretamente do visual studio.Para iniciar vamos criar uma solução clas library e adicionar um arquivo chamado
No exemplo abaixo vamos criar uma classe com o crud de uma entidade chamada pessoa. vamos usar LINQTOSQL para facilitar o exemplo.
Após criar o banco com a tabela pessoa vamos adicionar um arquivo t4 chamado crud.tt .
vs2010:Selecionar a opção general nos tipos de arquivos e selecionar o arquivo text template.
vs2008:Adicionar um arquivo com extensão .tt.
1-Vamos começar alterando a opção extension na tag output, vamos colocar .cs.
2- declarar variáveis para armazenar os dados que serão utilizados várias vezes pelo template
<# var NomeDaClasse = “Pessoa”;
var NomeDoDataContext = “db”;
#>
3- Adicionar os namespaces que serão utilizados pelo nosso CRUD
using System;
using System.Collections.Generic;
using System.Linq;
4- Declarar a classe responsável pelo CRUD
public class <#=NomeDaClasse#>CRUD {}
5- podemos salvar o arquivo e ver como nosso .cs está ficando
6-vamos declarar o nosso dataContext e criar um construtor para inicializá-lo
<#=NomeDoDataContext#> db;
public <#=NomeDaClasse#>CRUD()
{
db = new <#=NomeDoDataContext#>();
}
No meu arquivo .cs o DataContext não ficou “colorido”, vou colocar o namespace da minha classe
namespace BlogT4
{
public class <#=NomeDaClasse#>CRUD
{
<#=NomeDoDataContext#> db;
public <#=NomeDaClasse#>CRUD()
{
db = new <#=NomeDoDataContext#>();
}
}
}
7- vamos adicionar nosso primeiro método, será o inserir.
public void Inserir(<#=NomeDaClasse#> entidade)
{
db.<#=NomeDaClasse#>s.InsertOnSubmit(entidade);
db.SubmitChanges();
}
O código acima está completamente amarrado com o LINQTOSQL, vamos manter assim para facilitar o exemplo. Acho que agora você já sabe criar o deletar e atualizar certo? então vou criar um método que retorna todas as pessoas
8- criando um método que retorna todas as entidades
public IQueryable<<#=NomeDaClasse#>> RecuperaTodasAsPessoas()
{
return db.<#=NomeDaClasse#>s;
}
Galera, já temos nosso código CRUD básico, para gerar o mesmo código para outra classe basta mudar a variável NomeDaClasse e pronto!
1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4:
5: namespace BlogT4
6: {
7: public class PessoaCRUD
8: {
9:
10: BlogT4DataDataContext db;
11:
12: public PessoaCRUD()
13: {
14: db = new BlogT4DataDataContext();
15: }
16:
17: public void Inserir(Pessoa entidade)
18: {
19: db.Pessoas.InsertOnSubmit(entidade);
20: db.SubmitChanges();
21: }
22:
23: public IQueryable<Pessoa> RecuperaTodasAsPessoas()
24: {
25: return db.Pessoas;
26: }
27:
28: }
29: }
no proximo post sobre T4 vamos melhorar as coisas e gerar código de maneira mais elegante! Até o próximo..
ps: o wordpres+ live writer estão sacaneando minha formatação..
Software:OrtogonalidadeSoftware:Orthogonality
0944 days
O conceito de ortogonalidade é conhecido e usado por muitos projetistas de software, e você, Conhece e faz uso desta técnica?
O exemplo legal de explicar ortogonalidade é o exemplo do controle de um helicóptero onde todos os dispositivos quando acionados causam impactos em outros, quando um botão é acionado a alavanca deve ser puxada. Neste exemplo você pode ver que fica difícil alterar o funcionamento de um dos itens, afinal de contas você vai ter que testar todas as combinações possíveis, pois o comportamento é determinado pela combinação.
Baseado no exemplo do parágrafo anterior pode concluir que os controles são componentes do sistema, sendo assim se quando um componente é alterado outros componentes param de funcionar é sinal que as coisas não estão ortogonais.
Ortogonalidade é próximo do conceito de coesão, onde um componente deve ser independente possuindo um único e bem definido propósito [yourdon,constantine].Sendo assim se a interface pública do componente não é alterada todos os outros componentes relacionados continuarão funcionando da mesma maneira.
Criar componentes ortogonais envolve um conjunto de boas práticas de desenvolvimento, podemos citar os princípios como KISS e o YAGNI além dos padrões de projeto. Alguns dos benefícios de utilizar sistemas ortogonais são estes:
Manutenção
Os compontes se comunicam por interfaces simples e claras logo é relativamente simples alterar o comportamento e a forma de interação.
Testabilidade
Os componentes são mais fáceis de testar visto que testes unitários tornam-se uma opção viável.
Redução de riscos
Alterações causam problemas apenas se as interfaces forem alteradas.
Design aprimorado
A aplicação como um todo fica mais simples de ser aprimorada ou extendida.
No livro The pragmatic programmers podemos encontrar uma vantagem adicional que diz o seguinte:
“Quando dois controles A e B respectivamente com funcionalidades K e Y são mesclados obtemos K*Y funcionalidades. De outra maneira quando mesclamos controles C e D não ortogonais com funcionalidades X e Y não obtemos o mesmo número de funcionalidades do mesmo caso visto que a junção sobrepõe funcionalidades duplicadas”
Ortogonalidade é fortemente relacionado com a coesão, portanto se você quer aumentar a ortogonalidade de seus componentes fique atento para as responsabilidades e objetivos deles.Orthogonality is a famous concept for software designers, and you, do you know this concept? Are you familiar with this technique?
The coolest sample to explain this is the helicopter sample. In this case all controls cause a side-effect in another control. So if you press a button you need to push the lever. As you can see is really hard to change the way things work. If you change one control you have to test the entire set of possibilities related.
Based upon the sample above we can realize that components could be your software components, so if you change one of your components and things stop working it could mean that you have a problem
Orthogonality is closed for cohesion concept, when a component should be independent and with only one clear purpose [Yourdon, Constantine]. Thus if there is any change in your system’s public interface all others should continue working in as before.
Build components involves a lot of development best practices, for instance KISS and YAGNI. In addition to it you should use design patterns. Here are some benefits when applying Orthogonality in your system’ components:
Maintenance:
Components are related by clear and simple interfaces, so is easier to change your code and the interaction of your components.
Testability
The whole system is easier to test. In addition to it you can create unit tests.
Risk Reduction
Changes are not so boring if its interfaces are not changed
Better design
Is easier to improve your application
Reading the Pragmatic Programmers Book you can see the following benefits:
“If controls A and B with functionalities K and Y are related we can get K*Y functionalities. In another hand if these controls are not well designed control ‘A’ will overlap control b, so you will not get K*Y functionalities anymore”
Orthogonality is strongly related to cohesion, so if you want to improve it in your system pay attention to its responsibilities and purposes
Comentários segundo Code Complete(Parte 2)
0983 days
Fala galera, voltando aos comentários segundo Code complete uma questão que o livro faz questão de enfatizar é o estilo do comentário. Como estilo você pode entender a maneira(layout) pelo qual os comentários são feitos. O estilo é importante para que comentar seja uma atividade sustentável no desenvolvimento. Caso o estilo seja inadequado a equipe não vai comentar, ou pior vai deixar os comentários obsoletos.Segue abaixo alguns estilos:
1: /**********************************
2: * Nome: FazAlgumaCoisa
3: * Proposito: Executa uma ação desconhecida
4: * Algoritmo: instancia uma classe x e executa x.FazAlgumaCoisa();
5: *
6: * input: -
7: * output: -
8: *
9: * Histórico de modificação: -
10: *
11: * Autor:Higor Ramos
12: * Data: 10/09/2009
13: * Telefone:(555)222-2255
14: * Cor dos olhos:preto
15: * Tipo sangue: A+
16: * Carro Favorito: Pontiac Aztek
17: * **********************************/
18: public void FazAlgumaCoisa()
19: {
20:
21: }
Não preciso falar que o estilo acima é loucura.. Não existe nada sobre o que está sendo feito
1: /// <summary>
2: /// Função que executa uma execução randômica,
3: /// usada quando é necessário gerar uma sequencia
4: /// desconhecida
5: /// </summary>
6: public void FazAlgumaCoisa()
7: {
8:
9: }
O estilo acima é simples e funcional
Agora que você tem um estilo pode comentar cada variável certo? não! calma.. Um bom início é comentar apenas os membros públicos, pois assim podemos fornecer informações aos usuários da classe e o desenvolvimento não fica “pesado”.
Você pode estar esperando ainda mais dos comentários certo? bem, eles ainda podem oferecer mais! Os comentários possibilitam a geração de documentação automática, para isso basta seguir um padrão(sustentável) e utilizar uma ferramenta como o Ndoc ou SandCastle. Eu gosto bastante da idéia de gerar documentação com os comentários, isso permite que eu crie uma documentação sempre atualizada pois sabemos que quanto mais perto do código a documentação mais chances da mesma estar atualizada.Para os praticantes do XP isso ainda pode ser uma boa prática, pois geramos uma documentação simples e sem perda de tempo.
Conclusão
O code complete deixa bem claro através de pesquisas e links que comentar pode ser uma boa prática. Mais uma vez afirmo que comentar não é desculpa para escrever código ruim. Eu uso comentários para descrever interfaces públicas, gerar documentação, reportar contratos e exceções que podem ser geradas.
Indico a leitura do capitulo sobre comentários do code complete, espero que o post ajude a usar comentários de uma maneira inteligente e funcional.
Comentários segundo Code Complete(Parte 1)
0984 days
Fala Galera,
mais um post sobre comentários.. eu que já havia me convencido a não discutir mais sobre comentários participei de uma discussão neste forum. Existem tantas idéias divergentes(xiitas) quando o assunto é comentar ou não comentar que eu não me empolgo e discutir se é uma boa pratica ou não. Eu gosto de comentários e apoio o uso deles nos projetos em que trabalho, de qualquer forma o principal ponto deste post será o capitulo de comentários do code complete.então vamos lá!
O code complete tem uma visão abrangente sobre o assunto, reservando um capitulo para o mesmo.O livro começa com uma discussao fictícia entre grandes filósofos sobre o assunto. Nesta discussão ele mostra os principais tópicos que são defendidos quando desenvolvedores falam sobre comentários
Contra:
- Comentários são perca de tempo
- Codigo bom deve falar por si
- Comentários estão sempre desatualizados
- Comentários repetem o que está no código
Pro
- Comentários desenvolvem o conhecimento em um nível maior de abstração
- Comentários são como cabeçalhos de livros técnicos, ajudam a buscar a informação
Ainda durante a discussão eles concordam que ter um código com comentários que o repetem ou comentários desatualizados é pior que não ter comentários mas que se bem feitos comentários são eficientes
1-Tipos de comentários
Repetição de código
Este tipo de comentário apenas repete o que o código faz em diferentes palavras, não possui informação adicional apenas faz o leitor do código perder mais tempo
1: public Int32 somar(Int32 x, Int32 y)
2: {
3: //retorna o somatorio de x e y
4: return x + y;
5: }
Explicação de código
Este tipo de comentário explica um pedaço de código complicado ou até um hack, geralmente são usados quando o código é confuso
1: public String formatarString(String valor)
2: {
3: //Caso o ultimo caracter seja um underline a string possui espaços separados por   que devem ser convertidos
4: String valorFinal = valor.EndsWith("_") ? valor.Replace(" ", " ") : valor;
5: return valorFinal;
6: }
Marcadores de código
Usando geralmente para marcar um código inacabado ou ainda um código que deve ser refatorado
1: public Int32 somar(Int32 x, Int32 y)
2: {
3: // TODO: implementar a soma
4: return Int32.MinValue;
5: }
Sumário de código
usado para descrever o que está sendo feito em poucas linhas, usado geralmente para comentar funções/métodos
1: /// <summary>
2: /// Formata uma string de acordo com a presença de _ para html
3: /// </summary>
4: /// <param name="valor"></param>
5: /// <returns></returns>
6: public String formatarString(String valor)
7: {
8: String valorFinal = valor.EndsWith("_") ? valor.Replace(" ", " ") : valor;
9: return valorFinal;
10: }
Comentários de intenção de código
usados para mostrar a intenção do código, geralmente são escritos em termos do projeto.
1: public String formatarString(String valor)
2: {
3: //Formata a string
4: String valorFinal = valor.EndsWith("_") ? valor.Replace(" ", " ") : valor;
5: return valorFinal;
6: }
Informação que não pode ser expressada pelo código
Usado para representar informação como copyright ou numero de versão
1: public String formatarString(String valor)
2: {
3: /* Autor: Higor Ramos
4: * Data: 09-09-2009
5: * Documentação on-line:http://www.higorcesar.com
6: */
7: String valorFinal = valor.EndsWith("_") ? valor.Replace(" ", " ") : valor;
8: return valorFinal;
9: }
2-Comentários ineficientes
O livro ainda fala um pouco sobre tipos de comentários ineficientes, estes tipos tendem a ficar desatualizados e prejudicar o entendimento do projeto. exemplos:
1: public String formatarString(String valor)
2: {
3: /************************************************
4: * Caso o ultimo caracter seja um underline *
5: * a string possui espaços separados por   *
6: * que devem ser convertidos *
7: * *********************************************/
8:
9: String valorFinal = valor.EndsWith("_") ? valor.Replace(" ", " ") : valor;
10: return valorFinal;
11: }
1: public Int32 somar(Int32 x, Int32 y)
2: {
3: // Variable Meaning
4: //-------- --------
5: // X primeiro valor a ser somado
6: // Y segundo valor a ser somado
7: // resultado resultado do somatorio
8:
9: var resultado = x + y;
10: return resultado;
11: }
Galera, tem mais sobre comentários.. vou deixar para o próximo post. abraços
Livros #2
01032 days
Fala Galera, neste post falei sobre meus planos de leitura para os próximos meses ou ainda pode ver o que ando lendo aqui. Hoje cheguei em casa e tive uma grande surpresa.. meus livros chegaram(não tive que ir buscar) são eles: More Effective c# e Framework Design Guidelines.
Livros
Estava fazendo as contas acho que minha cota de livros de 2009 está encerrada, estou planejando reler os melhores/importantes livros a partir de meados de outubro.. Estou sentindo o ano acabar e vocês? qual foi o balanço de leitura? eu estou me superando a cada ano 
agora vamos que vamos.. estou cheio de livros para ler e praticar..
ps: O dolar está caindo.. uhuu!! que caia por mais um Mês, pois poderei comprar mais livros..rs
Refatoração para padrões
01045 days
Fala galera, como mencionei em uns posts anteriores estou comprei o livro refatoração para padrões. Ontem iniciei a leitura e acho que já valeu a pena! Sinceramente esperava um “guia” de refatorações envolvendo padrões, algo similar ao livro de Refatoração do Fowler, mas achei muito mais.
O livro foi escrito pelo Joshua Kerievsky, o cara é evangelista de programação extrema e padrões, sendo assim ele responde uma pergunta que eu vinha me fazendo.
“A programação extrema prega o projeto no momento certo e com a solução mais simples para um dado problema. Os padrões são soluções extensíveis e reutilizáveis e adicionam um pouco de complexidade ao projeto. Como deve ser a utilização de padrões em projetos que seguem o XP?”
A capa do livro responde minha pergunta.
“Refatoração para padrões”
Como?
“O autor prega que durante uma refatoração é um bom momento para inserir ou projetar em direção aos padrões”
Seguindo o método acima conseguimos resolver dois problemas recorrentes no desenvolvimento de software, o primeiro deles o excesso de “projeto” no início do desenvolvimento, este seria o grande investimento em soluções super extensíveis que podem não ser usadas(YAGNI). O segundo problema ainda pode ser pior que o primeiro, esse acontece quando nenhum investimento no projeto foi feito.
O livro é de grande serventia para aqueles que usam XP como metodologia ou ainda todos aqueles que se preocupam com o momento certo de inserir um padrão de projeto no código.
A way to use facades
01059 days
Hello folks, Today in the morning I was reading my email when I saw an interesting post at dotnetarchitects. This post is a discussion about facades and its implementation. A lot of people gave their tips, I also recommend you have a look, I gave my tip too. My tip was based in my experience when using facades.
I’m working in a project called comperio, in this project I have been trying to be a junior architect. We(dev Team) thought that would be nice if we had a layer that could do all validations and if these validations were ok this layer could call the layer that knows how to process the operation.We had decided to use a Facade layer to do these validations, but this facade layer were an server-side layer and we thought, should we do the same code in client side to improve the UX ? after some discussion we decided to use the facade layer to do the validation in both. So we write an action that calls the validate method in facade and it worked fine.
A facade was used because we think that the business logic layer should work as system’s core. Thus any error that could be avoided should avoid before enter in the system’s core. If you look our architecture you can see that the UI project has a reference to Facade project and nothing more. So, every layer or application that wants to use our system’s core must call our facade. The other reason to do it was that we want provide an API, an this API cant use core resources without some validations.
This approach is a simple way to implement validation, if you agree the idea that validation should be done in client and server side. Other cool tip I read was the use of keys in the assembly so we can ensure that the UI project is Using the Facade project.