Sobre a reunião do DNA, PMI X Scrum, e podcast

Antes de postar o próximo post do ABC App eu quero comentar sobre dois acontecimentos.

Dia 26 de setembro aconteceu mais uma reunião do grupo DNA (.NetArchitects), o tema foi PMI X Scrum. O objetivo era fazer uma mesa redonda em que cada um dos lados tivesse defensores em que apresentassem a sua defesa pelo uso de um ou do outro. Infelizmente,  do lado do PMI nossos convidados não apareceram, o nosso grupo DNA, é praticamente 100% a favor do Scrum, então dois se ofereceram para defender a visão do PMI:  André Dias (http://blogs.msdn.com/andredias/, siga @andrediasbr) e Victor Cavalcanti (http://www.cavalcante.net, siga @vcavalcante), do lado do Scrum ficou o Giovanni Bassi (http://unplugged.giggio.net, siga @giovannibassi).
Fora a frustração evidente do André e do Victor, de ter que defender o PMI o papo foi muito legal. O que tirei da conversa:

  • O PMI é velho! Hoje estamos cada vez mais dinâmicos, aplicações são escritas por pessoas que não são desenvolvedores em suas horas vagas, arrancando pedaços de participação de mercado de empresas, e por conta disso,  precisamos de mais velocidade; então por quê continuar com algo que é lento? Onde precisamos de controle vamos controlar, onde não precisamos de controle não vamos controlar! (do manifesto ágil: Individuals and interactions over processes and tools)
  • Se precisamos cada vez mais de velocidade , é por que precisamos de software pronto o mais rápido possível, tanto para atender uma demanda de mercado, como uma mudança de negócio de uma empresa; então por quê perder tempo com o que não é essencial? Com o que não vai trazer ROI? Vamos entregar! (do manifesto ágil: Working software over comprehensive documentation)
  • Se precisamos de software rápido e funcionando, precisamos de pessoas capacitadas, treinadas, focadas, interessadas para desenvolver. Então por quê não valorizamos esses profissionais? Por quê esprememos deles coisas inúteis como cumprimento de horário, vestuário, entre outras coisas? Vamos deixar as pessoas trabalharem confortavelmente, vamos investir nos bons profissionais, vamos recompensar quem traz ganhos para a empresa! (do manifesto ágil: Individuals and interactions over processes and tools)
  • Para isso tudo acontecer precisamos ser dinâmicos, não nos fechar, não entrarmos em uma bolha, tratar funcionários e clientes como parceiros; Por quê então tornamos eles nossos inimigos? Vamos construir pontes, ao invés de derrubá-las! (do manifesto ágil: Responding to change over following a plan)

Scrum é isso, nada mais que isso, o que falta aí é documento Product Backlog e as cerimônias de planejamento, reunião diária, e de finalização do Sprint. Precisamos mais do que isso para entregar um software? Não precisamos escrever extensos documentos que nunca serão lidos, não precisamos ficar montando cronogramas de coisas que não podemos prever, não precisamos ter alguém para mandar, só precisamos deixar que foi contratado para fazer o trabalho… trabalhar!

Quem quiser saber o que rolou na reunião veja pelo link do livemeeting, o André Dias também fez um post muito legal, tem até uma colagem de uma conversa com o @RenatoFerracini que rolou no twitter.

O outro assunto é sobre o mais novo episódio do podcast do .NetArchitects , que falamos sobre a profissão de Arquiteto, o assunto foi muito legal e vamos voltar a falar sobre ele com certeza! Assine o feed, ouça e comente!

Ainda essa semana sai o próximo post…

A falácia do desenvolvimento em 3 camadas

O desenvolvimento em 3 camadas, pedido em tantas vagas de emprego, em projetos de software, tanto discutido e difundido em fórums, livros e revistas de TI é uma verdadeira falácia!

falácia1
fa.lá.cia1
sf (lat fallacia) 1 Qualidade de falaz. 2 Engano, logro, burla. 3 Sofisma.

sofisma
so.fis.ma
sm (gr sóphisma) 1 Lóg Raciocínio capcioso, feito com intenção de enganar. 2 Argumento ou raciocínio falso, com alguma aparência de verdade. 3 pop Dolo, engano, logro.

Antes de começarmos a codificar alguma coisa, é bom um pouco de história para nos situarmos ! O termo foi difundindo erradamente. Vamos começar do começo e por partes, ou camadas , se preferir. 😛

Tive um primeiro contato com o termo desenvolvimento em camadas por volta do ano 2000. Na época, uma das linguagens mais usadas era o Visual Basic 6.0, o Java estava crescendo, e o Delphi era bem usado. A Microsoft recomendava o uso de ADO, presente no pacote MDAC, em detrimento ao DAO. O objetivo era ir no banco o mais tarde possível, pegar os dados e fechar a conexão o mais cedo possível. Surgiu então o Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.

A arquitetura Win DNA

A MS,  então,  comecou a divulgar a divisão de responsabilidades. A maioria dos programadores VB na época não usava nem o conceito de Classe, isso passou a ser mais demonstrado nos exemplos e no próprio livro, mas como o VB não era verdadeiramente OO não surtiu muito efeito. Até mesmo a divisão em DLL’s não era comum, o que mais se via eram executáveis gigantescos ou vários gigantescos por módulo!

O acesso aos dados era feito usando-se o RecordSet do ADO, criava-se um, ia no banco de dados, populava ele, fechava-se a conexão e usava na aplicação. A arquitetura,  então, era os Formulários (Form) no EXE e DLL’s;  A escrita do CRUD ficava em uma DLL. Na época,  a MS incentivava o uso massivo de Stored Procedures. E começou um movimento para tirar a lógica de negócios da camada de apresentação, ainda na fase dessa arquitetura era muito comum ter regras no banco de dados, mas falava-se em colocar essas regras em DLL’s também, então a camada de apresentação chamava uma DLL que continha algumas regras, que chamava a DLL de CRUD, que populava um RecordSet e retornava pela cadeia até a tela do usuário.

As coisas mudam no .Net

Com a vinda do .Net tivemos uma migração de algumas aplicações de maneira automática por meio de Wizards, alguns programadores também começaram a programar em VB.Net ou foram para o C#, uma linguagem mais de “gente grande” por ser mais parecida com Java. Porém,  o paradigma é diferente! VB 6.0 não é puramente OO, VB.Net sim! Aliás, o VB.Net é somente a sintaxe do VB 6.0, ele é uma linguagem em cima de outra plataforma.

Mas as pessoas são acostumadas a hábitos e,  o desenvolvimento em .Net foi feito da mesma maneira que vinha sendo feito no VB 6.0: lógica separada dos dados.

O paradigma OO nos diz: Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. (fonte: Wikipedia)

Na arquitetura Win DNA os dados ficavam em um RecordSet e o comportamento em funções de uma classe em uma DLL, o RecordSet passeava pela aplicação e,  se ela fosse um controle de Estoque uma função recebia o RecordSet, percorria ele para ver se algum item estava zerado para gerar um novo pedido.

Na arquitetura OO não existe essa separação, o que eu quero mostrar com os próximos posts é que ao termos objetos de domínio, estamos facilitando o desenvolvimento por deixarmos tudo agrupado (comportamento + estado), a facilidade de manutenção será muito maior. Outra coisa, o uso de DataSet’s deixa o código também mais confuso, usando classes POCO o código será muito mais fácil de entender e leve.

Continue acompanhando!

ABC App – 01

Ano passado comecei um projeto no CodePlex para mostrar o padrão MVC em Windows Forms para quem ainda não conhece. Mas o projeto ficou parado, mudei de .Net 2005 para .Net 2008 e o projeto não andou, esse ficou pesado, mas acho que é hora de começar me mexer!

Resolvi que não vou focar em MVC, vou usar o projeto para escrever sobre boas práticas, coisas que uso no meu dia- a-dia, então mudei o nome dele novamente (hehe) e ficou assim: ABC App.

Aqui no blog vou usar a categoria abcapp para publicar os posts referentes a essa série.

O código fonte deste projeto está hospedado no CodePlex em ABCApp, e , como o projeto é para quem também está iniciando então vou usar as ferramentas Express da Microsoft, Visual C# Express 2008. Vou usar também o TortoiseSVN, é só baixar o arquivo MSI e instalar. Antes , para acessar o CodePlex usando o TortoiseSVN era necessário o uso do  SvnBridge, desenvolvido pela equipe do site, agora não é mais necessário. Todo o projeto tem uma URL para ele, do ABCApp é https://abcapp.svn.codeplex.com/svn.

Eu criei o projeto na pasta Projects que o VS.Net cria dentro da pasta Documentos do Usuário.

Depois que você instalou o TortoiseSVN é possível baixar em qualquer lugar o projeto, basta clicar com o botão direito do mouse dentro de uma pasta vazia, e escolher a opção “SVN Checkout” do menu de contexto.

Conforme o projeto for evoluindo é só atualizar o fonte, para isso clique com o botão direito do mouse dentro da pasta e escolha “SVN Update”.

Quem tem uma licença do VS.Net, pode baixar aqui o Team Explorer, ele não vai funcionar com as versões Express, infelizmente!

Para quem quer saber mais sobre o Subversion e Tortoise , saiu uma matéria na edição 07 de Fevereiro/Março da Mundo.Net, e aqui você pode baixar um livro sobre o Subversion.

Próximo post vou começar a desenvolver o aplicativo e vou começar a falar de uma maneira de desenvolver usando objetos de negócio acessando o banco de dados sem o uso de Dataset’s!

Tema para VS.Net

Desde os tempos em que eu usava o  AutoCAD o meu fundo de tela é preto, o branco cansa muito a vista e para quem fica diante do computador várias horas ao dia é necessário tomar algumas providências para diminuir esse problema. Usar a tela com o fundo preto ainda por cima consome menos energia! 🙂

Com o VS.Net existe a possibilidade de também configurar esse ambiente. Logo quando conheci essa funcionalidade mudei o fundo para preto, mas são necessários  mais ajustes pois determinadas cores padrão não ficam muito bem com o fundo preto.

Sem querer um dia achei um tema adaptado no blog do Eduardo Miranda, ele usa o tema John Lam,  traduzido do TextMate para Visual Studio. Ficou bem legal, aqui está o post. Nos comentários tem uma pequena correção que o Israel Aece faz que é bem útil.

Ontem achei novos temas:

http://winterdom.com/2007/11/vs2008colorschemes

http://coelhonarede.110mb.com/2008/01/temas-para-o-visual-studio.html

Estou testando o Midtone Complete, que é uma adaptação do Midtone Scheme ( ambos encontrados no último link) a tela não é totalmente preta, fica um tom de envelhecido bem legal. Foi muito bem montada a relação de cores, quando se escreve uma String e fecha a última aspa ela fica verde, bem cuidadoso.

Para quem quiser criar um tema pode fazer as alterações em menu Tools > Options, e no treeview Environment > Fonts and Colors:

Tela do VS.Net para mudar cores e fontes
Tela do VS.Net para mudar cores e fontes

E para quem quiser adicionar um tema, adicionar e modificar em cima de um tema, ou guardar essas e outras configurações que fez no VS.Net, vá no menu Tools > Import and Export Settings, lá você também pode resetar para as configurações de atalhos, fonts, cores originais!

Compartilhe o seu tema, atalhos, e configurações legais que você fez no seu VS.Net!

Qual a próxima onda?

Já que é sexta-feira quero convidar a todos para fazer um exercício de futorologia e opinarem… o que vem em seguida? Qual a próxima onda?
Estamos entrando em uma onda chamada Cloud Computing, mas eu acho que ela não é o fim, é um meio.
Para mim,  a internet nunca foi um fim, e sim um meio de comunicação. Sempre vi como ela foi criada uma rede global, portanto sempre pensei que seria o meu suporte para conexão de sistemas, troca de informações, integração e não como o sistema em si, as chamadas web aplicações. Que ao meu ver são muito específicas, nem tudo dá para ser web.
Hoje o Giovanni Bassi twitou com o link de um vídeo em que a MS mostra a visão de futuro dela. É uma série de vídeos muito legais, tem um mais específico na área médica, outro da área de manufatura, eles estão aqui.
Logo mais teremos o Win7 chegando com suporte a telas por toque, a próxima versão do .Net framework vai trazer facilidades nesse aspecto, temos Silverlight rodando fora do navegador, MS Surface, …
Dito isto,  acho que a próxima revolução não será o Cloud Computing, que vai “apenas” (não é pouca coisa concordo) abstrair o computador pessoal em vários dispositivos e integrar muita coisa, mas acho que a próxima onde será a das interfaces! Integrá-las mais harmoniosamente ao nosso dia-a-dia, ter mais usabilidade, mais poder e mais facilidades.
O que você acha?

Campanha: Atalho para atualizar design no ASP.Net

Atualização (06/Ago/09): Conforme dica do Caio Proiete lá nos comentários o atalho é CTRL+SHIFT+Y, valeu Caio!

Comecei a programar em ASP.Net e logo uma coisa me deixou desconfortável.

Eu gosto de programar em código, mas vez por outra é legal dar uma “olhadela” em como esta ficando o seu design, existe um atalho para isso: SHIFT+F7, e você fica alternando entre design e source. Legal…

Mas legal mesmo é você programar com a janela dividida entre código, só tem um problema. Como fazer um Refresh no Design quando você altera o código sem usar o mouse? Sou programador, escrevo código, não gosto de ficar arrastando o mouse.

Simplesmente não dá! Você tem que clicar na linha amarela, como essa aí embaixo:

Tarja do VS.Net para refresh do design
Tarja do VS.Net para refresh do design

Então resolvi comunicar a MS que ela deveria mudar isso e segui a recomendação do André Dias e postei uma sugestão no MS Connect, site da Microsoft para sugestões, críticas, …

Se você também acha pertinente a sugestão, vote, e twitte sobre ele!

Aqui vai o link https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=476075&wa=wsignin1.0

Padrão MVC arquitetura em camadas

(Nota: publiquei esse post inicialmente aqui, como movi o meu blog , e recebi pedidos para comentar mais a respeito, estou revisando e postando aqui para continuar a série de posts do blog antigo)

Estou desenvolvendo um novo sistema baseado na arquitetura MVC, ou melhor, pensei que estava.

Em 2007, participei da integração de um sistema legado ASP.Net com SAP que estava sendo implantado. O sistema já estava construído e basicamente deveríamos integrá-lo ao SAP usando Web Services disponibilizados através do serviço XI da SAP. Ou seja, ao invés de continuar buscando os dados no banco de dados Oracle, iríamos agora buscar no SAP, através de Web Services.

O sistema usava a arquitetura MVC. Usava? Bom, eu tinha uma DLL onde ficavam as classes Model, outra de Controller, tinha a interface gráfica em ASP.Net, mas eram somente camadas… Opa, mas MVC não são camadas?

Esse foi o meu primeiro contato com MVC e a partir daí comecei a estudar mais sobre padrões e arquitetura, e lógico vi que era hora de me aprofundar em Orientação a Objetos… Sim isso mesmo, aprofundar.

Eu vim do VB6 (por favor, VB6 é sim uma linguagem de gente grande!), quando comecei a programar o ADO estava sendo lançado, praticamente. Logo em seguida tive contato com a arquitetura Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.

E foi aí que surgiu para mim o conceito de camadas, dividir para conquistar, já que na época tínhamos o DLL Hell, era muito bom você criar pequenos componentes que sofreriam manutenção em separado, e nada melhor do que juntar esses componentes por funcionalidades! Assim os componentes usados para a interface gráfica ficavam juntos, o de acesso a dados ficavam em outro, o que diminuía a possibilidade de dar um problemão quando alguma coisa sofria manutenção, eu disse diminuía…

Daí pra frente eu só desenvolvia em camadas, camadas lógicas, pois na verdade o software ficava instalado todo na máquina cliente, ou seja, eram instaladas várias DLL’s, mas todas no mesmo lugar. Algum projeto saiu usando o COM+, aí tinhamos Tiers, componentes usados em interface gráfica ficava na máquina cliente e compoentes de negócio e banco de dados ficavam no servidor.

Mas onde entra o MVC aí? Aí é que está… Não entra!! O MVC não é sinônimo de desenvolvimento em camadas! Nem em tiers! O MVC é um padrão de arquitetura, e ele é baseado no comportamento dos objetos. Sim, comportamento!! E mais, o MVC é padrão para interface gráfica, e não para todo o sistema.
Muitos de nós, principalmente que viemos do VB6, Win DNA, …; começamos desenvolvendo em OO criando classes que tem os atributos como os RecordSets do ADO, ou seja somente dados! Mas um objeto por definição possui comportamento. Então não adianta criar uma classe de dados, como se fosse um RecordSet, uma classe de serviço como se fosse uma classe do VB6 (que sim, antes que alguém fale, não é orientado a objeto, porém chegava perto…), e ficar passeando pelas camadas, que isso é MVC. Aliás nem OO é, pois você não estará usando comportamentos dos objetos.

Não vou chover no molhado explicando isso aqui, o Phillip Calçado Shoes já escreveu um artigo muito bom sobre isso, então usando um dos princípio de OO que é a reusabilidade , para saber mais leia os artigos MVC e Camadas e Evitando VO’s e BO’s, leia também as referências e acompanhe o blog dele! 😀

Na edição 46 da .Net Magazine o Rodrigo Sendin escreveu um artigo sobre MVC, porém quem leu o artigo e ler os artigos do Phillip Calçado vai entender que a crítica do Rodrigo esta errada quanto ao padrão MVC.

Bom se eu não vou explicar o que é MVC, nem camadas, nem BO ou VO, então pra que este post? Como eu disse estava desenvolvendo um projeto pensando estar usando MVC, no momento na versão 1.0 ele irá sair usando BO’s, trafegando pelas camadas, etc… Mas estou montando a arquitetura da versão 2.0 em MVC, não vou usar nenhum framework, pelo menos por enquanto.

No próximo post (espero mesmo começar aqui neste novo endereço do blog em breve) vou começar uma série de artigos compartilhando minha experiência, principalmente com uso de objetos POCO, pois percebo que no Brasil o uso de DataSet’s é abusivo, logicamente para pequenos projetos é uma boa solução mas para projetos médios, ou com muitos acessos ao banco de dados o peso começa aumentar. E também vou dar um foco no acesso a dados. Vou publicar o código acho que no CodePlex (o código esta aqui, ou melhor, estará :D), daí é só baixar o código para estudar ou começar outro projeto em cima. Quem quiser se unir a empreitada é só entrar em contato.

Espero que acompanhem, comentem, entrem em contato para trocarmos idéias.

Adobe Reader posto, Adobe Reader morto!

Se você acompanha esse blog sabe que sou desenvolvedor da plataforma .Net, e portanto sou mais pelo lado do software proprietério, pois ganho dinheiro com isso… Gosto dos produtos da MS, e defendo eles sempre que a discussão vai pro lado filosófico e sai das questões técnicas.

Portanto, era natural que para ler PDF eu usasse o software “original”, o Adobe Reader…
Mas uma coisa sempre me intrigou nesse software, apesar de saber que ele não é apenas uma leitor, você pode desenvolver formulários com ele. É complicadinho, usa Java Script, mas funciona e,  dizem que os norte-americanos declaram o imposto de renda assim; além de ele ter uma segurança elevada no PDF usando certificados digitais, etc… E portanto,  isso faz dele um software “robusto”. Ele é robusto DEMAIS!

É extremamente grande, extremamente pesado, e extremamente chato pois de mês em mês, ou menos, baixa uma atualização de mais de 40Mb!!! Eu disse uma atualização de mais de quarenta megabytes!! Ou seja, baixa toda vez que ele faz um update um novo Adobe Reader! Uma vez,  até eu mandei um e-mail para a Adobe perguntando o porquê de o software ser tão pesado, logicamente não tive resposta.

Bom… O tempo passou e tudo isso me fez perder a paciência, ainda mais no peso quando eu quero abrir mais de um arquivo ao mesmo tempo. E decidir matar o Adobe Reader… pelo menos na minha máquina.

Eu já havia visto algumas soluções de leitores de arquivo PDF, mas nenhuma me agradou, até que ano passado vi que o Foxit melhorou muito! A interface ficou confortável, é verdade que não é parecida com a da última versão do Adobe Reader, mas não se pode ter tudo. Mas o que mais me chama a atenção é a leveza, poxa, é pequeno e muito leve, já usava nas duas últimas empresas e agora instalei aqui em casa, e estou feliz… e leve!! 🙂

Nesse caso o software livre se mostrou muito superior ao fechado, e nesse caso em específico eu faço propaganda, mate o seu Adobe Reader também!

http://www.foxitsoftware.com/

Google Developer Day 2009

Participei da edição 2009 do Google Developer Day, ou #gdd no Twitter.

Foi um evento de um dia só, o que é uma pena, pois 3 trilhas ocorrem em paralelo e você tem que decidir e sempre acaba perdendo alguma coisa legal. No entanto, o Google tem a política de disponibilizar as filmagens no YouTube, daí dá pra ver o que perdemos.

No início da manhã tivemos um Keynote e a apresentação do Google Wave, com Stephanie Hannon e Torsten Nelson, do Google Brasil, que foi muito boa, mas foi mais do mesmo, já que tinha visto o lançamento em vídeo. Quando essa ferramenta estrear acho que vamos ter uma nova revolução na comunicação, no mesmo estilo que o GMail fez. (Adendo: ontem 30/Jun/09, recebi um convite para testar o Wave, depois escrevo sobre ele)

À tarde escolhi a trilha de mapas, 3 palestras seguidas com Pamela Fox, já que estou trabalhando no uso dessas API’s nada mais natural, e foram muito boas, mas eu ainda sou iniciante nelas, então, não de pra se empolgar muito. O que dá para perceber é que o Google investe muito nessas API’s de mapas. Agora a parte alta foi ouvir a segunda palestra no português arranhado e carregado da Pamela, não tem preço! (Até por quê o evento é gratuito… hehehe)

As duas últimas palestras que eu vi foram do Patrick Chanezon, uma sobre Web Social, falando da integração do Open Social do Google com sites, blogs, etc… E a outra sobre HTML 5, que foi um aprofundamento do Keynote que ele fez na parte da manhã. O Chrome e o Firefox já implementam muita coisa do HTML5 e eu quero saber por que a MS fica para trás nesse tipo de coisa.

Outro ponto, será que o HTML5 derruba Flash, Flex, Silverlight e JavaFX? Alguns levantaram essa bola, o Google deve estar louco para isso já que eles investem pesado em Javascript e não tem um componente RIA como os citados acima. Outros dizem que não, por quê esses plug-ins atingem outras funcionalidades, vamos ver, de camarote.

Balanço: Muita informação, fiz pouco network, ganhei umas bolinhas do Google, adesivo do GMail, almoço e coffee na faixa, e no fim foi um dia divertido, forcei bastante o inglês, já que me dá nervoso ficar ouvindo a tradução simultânea.

Fotos do evento estão aqui. Espero participar ano que vem.

.Net Architects Day 2009

Pessoal,

O .Net Architects Day 2009 aconteceu, dia 27 de Junho de 2009, na UNIP do Tatuapé! E o feedback que temos recebido é que foi um sucesso!
Foi muito gratificante participar da organização, de ajudar o evento acontecer, de ver os participantes gostando do que foi planejado.

Infelizmente, tínhamos só das 09 às 18:30 de palestras! Mas acho que vários ficariam mais tempo. Durante o coffee, participantes trocaram idéias com os palestrantes, e eu pude, juntamente com o Daniel Fonseca, colher alguns depoimentos que logo serão compilados em um clip e disponibilizados.

O Fabio Margarito fez um post e disponibilizou algumas fotos aqui, a Fernanda Sallai, que era participante, postou com feedback e fotos dos brindes que distribuimos aqui. Conforme o pessoal for postando eu atualizo aqui.

No Twitter o pessoal usou a tag #dnad2009, veja os comentários.

Valeu!

E agora acho que vou conseguir me dedicar mais aqui para o blog.