Acabei de adquirir o serviço virtua de 10 Mb e fiz um teste através do site http://www.speedtest.net/. Olhe que números…
Só de pensar que em 1997 eu usava um link de 56 kb e ficava feliz com download a 5kbs.
[]’s
Fabio Margarito
Quase 23 horas, e eu aqui instalando o SQL Server Reporting Services 2008. A instalação ocorreu bem, mas quando tentei abrir o gerenciador de relatórios, “””pã””
Ok, erro novo para mim, instalei diversas vezes o Reporting Services e isto nunca tinha acontecido, a única diferença é que eu estou tentando instalar no Windows 7 Home Premium, o SO que que veio no note que comprei recentemente.
Depois de uma pequena pesquisa descobri o problema. Para eu poder rodar o gerenciador de relatórios do Reporting Services, é necessário que o usuário pertença ao grupo de administradores locais. Para resolver, a ação foi simples, bastou eu dar um “run as administrator”, ou “Executar como administrador” o IE. Pronto, tela de configuração.
Fui em “configurações de pasta”, em seguida “Atribuição de nova função” e associei meu usuário a “Construtor de relatórios” e “Gerenciador de conteúdo”.
Pronto, agora consigo entrar no gerenciador de relatórios sem problemas..
Espero que seja útil para alguém.
[]’s
Fabio Margarito
Vou fugir um pouco do post técnico, e tentar escrever sobre estratégia, e como ferramentas de análise de cenário, utilizadas para planejamento estratégico empresarial, podem nos ajudar na tomada de decisão.
Como já falei em palestras que ministrei e em conversas informais com amigos, na minha visão, o arquiteto deve escolher a melhor solução pensando em diversos fatores, tais como: equipe, plataforma tecnológica, cultura da empresa e alinhamento com a equipe de negócios. Arquitetos devem sugerir e implementar soluções sustentáveis.
No MBA que faço na FGV na disciplina de Estratégia Empresarial, fui exposto a uma metodologia de análise de cenários chamada SWOT, e quando me refiro a cenário, podemos falar de uma área da empresa, da empresa como um todo, da sua vida, etc…, ou seja, você foca em um escopo que deseja analisar. O objetivo da análise, é fornecer os insumos necessários para que possamos tomar uma decisão e montar um planejamento estratégico. SWOT é um acrônico e significa:
S e W, são avaliados pensando em fatores internos, e internos definimos como fatores que temos controle e podemos atuar, gerenciáveis.
O e T, são fatores que não temos controles, não gerenciáveis. A figura abaixo ilustra o quadrante gerado pela análise SWOT.
fonte da imagem:blog sem palavras
Achei extremamente pertinente a utilização desta metodologia para tomada de decisões das mais variadas possíveis. Vou colocar um cenário já discutido em um passado não muito distante, onde uma equipe gostaria de alterar os namespaces de um framework distribuído gratuitamente. Colocamos o problema e começamos a levantar, a partir da experiência dos participantes, pontos que seriam relevantes e passíveis de classificação.
Forças
Fraquezas
Oportunidades
Ameaças
-
Fornecedora do framework lançar um hotéis. Devido a customização, a equipe gestora do framework alterado, não consegue entregar a nova versão rapidamente, para, por exemplo, resolver um problema de produção.
Com os pontos colocados, foi decidido pela não alteração do namespace, visto que haviam mais ameaças e fraquezas do que pontos fortes e oportunidades. Obviamente, não foram apenas estes itens, mas um conjunto bem maior.
Para levantar os quatro quadrantes, há a necessidade de um trabalho em grupo, onde os quadrantes são exibidos e os diversos participantes apontam fatores e em conjunto, decidem em que quadrante cada fator deve ficar.
Vocês conseguem ver este tipo de análise em outros cenários? Exemplos:
Acho que vale o exercício.
Quer aprender mais?
SWOT
[]’s
Fabio Margarito
Tudo pessoal?
Outro dia uma amigo me questionou sobre a utilidade do padrão Unity of Work (para facilitar, chamarei de UoW), na visão dele, o padrão não faz sentido e teria pouca utilização. Será que não tem nenhum valor? Para não respondê-lo por e-mail, resolvi postar a resposta.
Segundo Martin Fowller o padrão UoW é definido como:
Mantains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
em tradução livre:
Mantém uma lista de objetos afetados por uma transação de negócio, coordena a efetivação das mudanças e soluciona problemas de concorrência.
Para facilitar a compreensão do UoW, trazendo um pouco para a realidade de muitos, imagine o processo de negócio de emissão de uma nota fiscal (processo extremamente simplificado):
O processo de negócio somente será efetivado, se as três etapas forem concluídas. Como resolvemos este tipo de situação?
Geralmente abre-se uma transação no banco de dados, e se todas as etapas forem concluídas com sucesso, efetivamos a transação, caso contrário, abortamos, ou seja, voltamos ao estado anterior a transação.
O UoW é o cara que abre a transação, efetiva ou aborta, só que trabalhamos com o controle dos objetos (quais foram alterados, quais foram inseridos, excluídos , etc..).
Em um modelo orientado a objetos do nosso problema, a nota fiscal é um objeto, quando emito uma nota, no final das contas, instanciamos um objeto nota e incluímos o estado desejado (número da nota, data de emissão, lista de produtos (outro objeto),etc..) , portanto, a nota torna-se um novo objeto passível de ser persistido no banco de dados.
Se for uma alteração, basicamente retornamos os dados do banco, preenchemos um objeto do tipo nota, alteramos o estado do objeto, e este, posteriormente é persistido no banco. Com a exclusão, o processo é similar. Conseguiram ligar a expressão “Mantém uma lista de objetos afetados por uma transação de negócio” , com o exemplo exposto? Em nosso exemplo, teríamos outros objetos que serão gerenciados pelo UoW, e por ele conhecer todos, e os respectivos estados, consegue saber se houve algo errado, e abortar, se necessário.
Para a criação de UoW, Fowller em seu artigo sugere a seguinte interface:
Sacaram onde o objeto nota fiscal poderia ser incluso em cada situação?
Outro ponto importante, e faz parte da definição do UoW, é o controle de concorrência, que é outro assunto extremamente complicado e extenso, mas posso citar um exemplo:
Imagine duas pessoas, uma sem conhecimento da outra, alterando dados de um mesmo cliente, o que fazer no momento da persistência? Há algumas técnicas, como o bloqueio pessimista, ou seja, no momento que eu resgatar um cliente eu bloqueio este cliente, impedindo que qualquer outro o altere, ou , bloqueio otimista, onde faço a checagem se houve alguma alteração no momento da persistência. Enfim, implementar tudo isto não é algo tão trivial, e como o conceito padrão de projeto, é a solução para um problema recorrente, podemos imaginar que alguém já implementou isto, correto? Com certeza, vejamos alguns exemplos:
-
NHibernate, um ORM opensource bem conhecido: No NHibernate, temos o objeto Session, qual a função do Session? Ele abre a transação e monitora todos os objetos utilizados no processo de negócio.
-
Entity Framework, ORM desenvolvido pela Microsoft: No Entity Framework, temos um objeto similar ao Session do NHibernate, o datacontext.
-
DataSet do .Net Framework: Um dataset, é um banco em memória e desconectado do banco de dados, trocando em miúdos, podemos retornar dados de um banco, alteramos, incluímos dados em memória e solicitamos que as alterações sejam persistidas.
Conclusão
Não feche os olhos aos padrões, entendê-los é importante, fazem parte do nosso dia-a-dia, e são a melhor forma de reuso de conhecimento gerado a partir do sofrimento de muitos.
Fala sério, também fica bonito em uma reunião técnica, rs…
Quer aprender mais?
[]’s
Fabio Margarito
Ontém ocorreu o evento Codificando .Net 2010, e foi bem bacana. Cheguei logo cedo, e saí quase as 19:00. O evento inicou com o KeyNote do Facunte, sobre o Windows Phone e SilverLight 4. Como sempre a palestra do Facunte foi bem bacana, um cara bastante extrovertido e diverto. Em seguida um overview das tecnologias que chegaram em 2010, como o Visual Studio 2010, novidades do ASP.Net 4.0 e .Net Framework 4.0 com a equipe de líderes do Codificando .Net. As 14:00 teve inicío da Joint Venture entre Codificando .Net e DotNetArchitects. A equipe do Codificando nos cedeu uma sala para uma sessão aberta para discutirmos soluções de arquitetura na plataforma .Net. Foi uma discussão bem bacana, com muita gente inteligente e a participção da cúpula do time DotNetArchitects, como o Leandro Daniel, Emanuel Brandão, Vinícios Quaiato, Victor Cavalcante , Daniel Fonseca e eu. Em paralelo, o Victor estava palestrando sobre MVC e Jquery com maestria(logo que acabou nossa discussão de arquitetura, também fui conferir a palestra). A estrutura do evento foi muito bacana, muita gente(em torno de 300 pessoas) deixando de lado o fim de semana de diversão, para compartilhar conhecimentos e reencontrar amigos. Equipe Codificando, em nome do DotNetArchitects, agradecemos a oportunidade, e parabéns pelo evento.
[]’s
Fabio Margarito
Tudo bem galera?
No dia 12/06 tivemos uma apresentação sobre MEF, infelizmente tivemos problemas com a internet e não foi possível transmitir ao vivo a apresentação. Mas sem problemas, vou preparar um webcast com o conteúdo dado. De qualquer forma, segue a minha apresentação e a demo apresentada. A demo foi desenvolvida pelo Alexandre Santos Costa, o Magoo, deficiente visual com grande conhecimento e que contribui bastante com a comunidade.
Demo da Apresentação
[]’s
Fabio margarito
E aí galera, blz?
Depois de um bom tempo voltei a escrever para a revista .Net Magazine. O artigo da edição 72 trata um assunto bem interessante, o processo de refactoring.
A idéia do artigo é trazer um exemplo real, saindo um pouco dos exemplos lúdicos, espero que gostem. O Guinther já publiou em seu blog um bom resumo da edição.
Junto com meu artigo, temos nesta edição meu colega de trabalho, o Fabio Gouw falando sobre dois patterns pouco explorados e de grande potencial, e também contamos com a presença do Leandro Daniel na sequência que fala sobre as novidades do .Net 4 e Visual Studio 2010, é DotNetArchitects comparecendo em massa.
[]’s
Fábio Margarito
Olá pessoal, tudo bem?
Segue minha apresentação e a demo que utilizei no evento. Infelizmente não foi possível finalizar a demo do Code Contracts devido a algum problema de versão, falha minha, pois não testei no notebook da apresentação que não era meu :-).
Apresentação
Para rodar a demo é necessário:
Para saber mais
Durante a semana vou detalhar mais sobre Code Contracts, pois há muita coisa legal para mostrar!
Espero que tenham gostado do evento!!!!
[]’s
Fabio Margarito
Olá Pessoal!!
É com imenso prazer que neste próximo sábado(18/03), vamos apresentar o evento Community Launch 2010 – São Paulo! Neste evento iremos apresentar as novidades do Visual Studio 2010 e .Net Framework 4.0, não percam.
Detalhes do evento e inscrição, vocês podem encontrar em nosso hotsite.
[]'s
Fabio Margarito
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