Estou lendo um livro muito bom sobre Teoria dos Jogos, de Ronaldo Fiani, e estou entrando em contato com algumas idéias muito interessantes, que tranquilamente podem ser aplicadas a um departamento de tecnologia. Segundo a Wikipedia, a "Teoria dos Jogos é um ramo da matemática aplicada que estuda situações estratégicas onde jogadores escolhem diferentes ações na tentativa de melhorar seu retorno". A palavra chave aí é retorno, também chamado de recompensa.

Ok, e aí? Aí que, através de uma série de modelos, a teoria dos jogos ajuda a entender as reais motivações das pessoas, a maneira com que elas tomam algumas decisões, como elas consideram o ambiente e os outros componentes do jogo, ou interação estratégica.

Pensando nisso tudo, coloquei alguns dos modelos da teoria dos jogos para funcionar com algumas premissas:

  1. Todo mundo quer maximizar o retorno;
  2. O mercado de tecnologia está muito aquecido. Mesmo nesta crise financeira a demanda ainda supera a oferta de profissionais. Há entre 15 e 70 mil vagas disponíveis no país, não preenchidas por falta de profissionais qualificados (depende de onde você pega a pesquisa);
  3. Os terceiros têm uma rotatividade acima da média, já que não podem contar com estabilidade, e aproveitam melhor as oportunidades que aparecem, seja para ganhar mais, seja para realizar um trabalho com melhores perspectivas (aprendizado, promoção, salário, etc);
  4. Pela minha experiência, os funcionários CLT de tecnologia também mudam de emprego a cada 4 ou 5 anos em média. É mal visto o profissional com dez anos de empresa na mesma posição. E não é todo mundo que pode (ou consegue) ser gerente.
  5. Hoje em dia os departamentos de TI estão tomados por terceiros, muitos inclusive em posição de tomada de decisões, até mesmo as que involvem custos.

Só com essas premissas dá para concluir, utilizando uma generalização, sem tocar nos casos de menor proporção que:

  1. As empresas devem contar com a saída de boa parte do seus decisores:
    1. se for um terceiro, em até 3 anos mais ou menos;
    2. se for CLT, em até 5 anos mais ou menos;
  2. Como as pessoas trabalham por recompensas, e estas geralmente vêm por entregas mensuráveis como redução de custo, entrega no prazo e índice de erros (entre outros), as pessoas vão fazer o que for necessário para atingir estes objetivos. Frizando: o que for necessário. Vão jogar o jogo da empresa, usando as regras que dispões (e suas brechas) e vão dobrar algumas delas.
  3. O que acontece depois que a pessoa sai da empresa não é mais problema dela. Isso quer dizer que os projetos de TI de responsabilidade de uma pessoa devem funcionar somente até a pessoa sair da empresa. Depois disso são problema de outra pessoa.
  4. Existem muitos casos em que uma pessoa/equipe é responsável por projetos e outra pessoa/equipe por manutenção de software pré-existente. Nesse caso fica mais fácil ainda: o projeto tem que funcionar somente até a homologação. Depois disso a pessoa de projeto nem precisa sair da empresa: o projeto já é de outro assim que é homologado.

Por fim, a conclusão final é:

Se for necessário, para atender maximizar a recompensa, deve-se remover "empecilhos" como boas práticas de engenharia ou arquitetura, um processo de gestão que funcione na organização (qualquer que seja ele), padrões de codificação, testes, documentação. Afinal, a recompensa é quem manda. Se não for possível remover esse tipo de trabalho "extra", tenta-se pelo menos "facilitar". Isso explica um monte de empresas que já visitei e que hoje não têm padrões, ou não os seguem, ou eles já foram tão entortados que não servem para mais nada. Afinal, colocamos a raposa para vigiar o galinheiro, não é?

Muitos dirão: isso se resolve com processos. A empresa coloca um processo que de deve ser seguido e que é auditado e medido. Exemplos:

  1. Toda aplicação deve ter documentação, que siga um padrão pré-determinado.
    Já cansei de ver isso. Só que o tal padrão tem umas 20 folhas, onde o cidadão só preenche umas 3 no meio, e põe o nome no começo. De resto, fica tudo em branco. Preenche de qualquer jeito, só para atender a auditoria. E todo mundo aprova sem ler. Inclusive quem está pagando (o patrocinador do projeto), e quem vai usar (o usuário).
  2. Toda aplicação deve ter testes unitários.
    Ok, e quem olha isso? Existem ferramentas para avaliar isso (como o Visual Studio Team System), só que a maioria não sabe usar. E mesmo assim, você pode criar um teste inútil. E um teste inútil é muito mais difícil de ser rejeitado do que nenhum teste.
  3. Toda aplicação deve seguir um padrão de arquitetura.
    Essa é a mais engraçada de todas. Como se toda as aplicações fosses iguais, as empresas definem então que todas devem seguir o mesmo padrão. E sofre do mesmo problema anterior: as pessoas podem não seguir e ninguém vai ver, ou podem seguir nas coxas e vai ser difícil provar que está errado.
  4. O processo de desenvolvimento agora é ágil.
    Aí vem a bala de prata. Como se o processo conseguisse resolver problemas de testes mal feitos, por exemplo. Cai na velha discussão do Scrum: o que é DONE?

Todos esses problemas acontecem porque sempre tem alguém na ponta dizendo que o projeto tem que sair mais rápido, que o custo está alto demais, que o produto não era o esperado. Os gestores conduzem um departamento de tecnologia, de engenharia, de ciências exatas, como se fosse um departamento financeiro: corte, corte, corte. Porque lá em cima alguém disse que o objetivo de TI era isso. No final, fica a empresa inteira insatisfeita, e vem o CEO falar que TI não provê a inovação que deveria, e que os custos são muito altos. Também… com TI sentada em um monte de processos que não servem para nada, criando produtos que custam muito além do que deveriam, tanto para fazer quanto para manter. Não tinha como dar outra.

Por isso o nome deste post: Longo prazo. Não vejo hoje nas empresas uma preocupação de longo prazo no departamento de TI que vá além da escolha do modelo dos servidores ou do ERP. Faz-se software que vai durar 3 anos no máximo, porque em dois anos metade da empresa já foi embora. Até o CIO, muitas vezes.

Como fica o papel do arquiteto de software neste cenário? Fica complicado, difícil. Um das principais tarefas do arquiteto de software é pensar no futuro. Coloco aqui um trecho do meu artigo que vai sair na .Net Magazine do mês que vem, edição 58, onde vou falar muito de arquitetura e padrões, sob uma visão prática:

"Não seria necessário montar uma arquitetura focada em melhores práticas se acreditássemos que a solução teria somente os requisitos apresentados (…). Preparamos uma arquitetura fundada em padrões reconhecidos justamente porque sabemos que a aplicação não vai manter os mesmos requisitos durante toda sua existência. Na verdade, aplicativos do mundo real não mantêm os mesmos requisitos nem mesmo durante o desenvolvimento do projeto inicial, quem diria ao longo de toda sua existência."

Será que gestores e clientes que estão mais preocupados com a empresa em que vão trabalhar daqui a 6 meses do que a que trabalham agora se preocupam com arquitetura de software? Duvido muito. Parece ser muito mais fácil fazer software sem padrões, arrastando e soltando do que ter que se preocupar com infra-estrutura, padrões de projeto, injeção de dependência, mapeamento objeto relacional, DDD, testes, tratamento de erro, etc, etc. Mas não é. Esse tipo de software pode até ficar pronto mais rápido (ou não), mas custa muito mais à empresa, que vai pagar por ele muitas vezes, já que ele vai ter que ser refeito também muitas vezes. Isso sem contar os custos de manutenção entre cada reconstrução. Só que quando esse custo for ser pago, quem tomou a decisão de fazer sem bons padrões de arquitetura já está trabalhando em outro lugar.

Esse tipo de problema não acontece tão frequentemente em empresas pequenas ou familiares, onde o gestor muitas vezes tem participação nos resultados da empresa. Neste caso, o foco dele é o longo prazo. Custa muito caro investir em TI para jogar fora logo depois.

Talvez o grande desafio do arquiteto hoje seja tentar demonstrar às pessoas que software bem feito vale a pena, mesmo se for até elas sairem da empresa. Não adianta argumentar que daqui a 10 anos vai estar rodando bem ainda, se o gestor está preocupado com o curto prazo, e com os bônus que vai receber, e não com a empresa que trabalha.

Lembrando que estou tratando de generalizações. Você pode perfeitamente viver algo que contradiz o que eu estou propondo, sem invalidar nada do que escrevi.

Opiniões, como sempre, são bem vindas.


Postado na(s) categoria(s) Arquitetura pelo Giovanni Bassi em 3 de dezembro de 2008 às 15:45 | Tags:

3.4 ponto(s). Avaliado por 5 pessoas

  • Currently 3,4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Surface em uso nas lojas da IBM

O Surface está cada vez mais próximo. Agora foi a vez da BMW adotá-lo com uma aplicação que foi chamada de BMW Product Navigator. Dêem uma olhada no vídeo à esquerda, ou aqui diretamente.

Além de poderem usar as mãos, os clientes podem também usar alguns objetos em volta do Surface para mudar cores e acessórios. Muito legal.

Quem achava que esse tipo de tecnologia ia demorar a chegar estava engando. O futuro não é agora. Pelo visto, já foi ontem.

Eu diria que quem começar a estudar esse negócio hoje vai ter bastante trabalho nos próximos anos.


Postado na(s) categoria(s) Outros pelo giovanni bassi em 2 de dezembro de 2008 às 09:43 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Ufa, já faz 2 semanas que eu falei de C# 4. Estou finalizando uma edição da .Net Magazine e o grupo de arquitetura, o .Net Architects, tem tomado meu tempo (para assuntos bem legais, é verdade, ainda assim…). Assim que o fechamento da .Net Magazine passar tenho um monte de coisas para escrever por aqui. Enfim, vamos lá.

Se você está chegando agora, este é o quarto post sobre o assunto. Se você não viu os posts anteriores:

  1. C# 4.0 – Quanto antes melhor – onde apresentei um resumo das novidades, além de assuntos que envolvem a nova versão da linguagem;
  2. C# 4.0: Uma linguagem dinâmica – onde apresentei as novidades do C# 4.0 que vão aproximá-lo mais de uma linguagem dinâmicas.
  3. C# 4.0: Teremos covariância e contravariância – onde apresentei a tão esperada variância do C#.

O assunto que vou tratar aqui hoje, argumentos opcionais e nomeados, é mais uma feature para o pessoal reclamar que o C# está ficando parecido com o VB. Se você está reclamando já adianto, C# e VB são linguagens irmãs, são dialetos de uma mesma lingua, e, segundo a Microsoft, vão ficar mais e mais parecido ao longo dos anos. Tudo que tiver em um vai ter no outro (o que for possível, ao menos). Não vou ficar falando que VB é uma linguagem tão profissional quanto C#, e que as duas têm prós e contras, porque já disse isso aqui antes, em um dos posts da série Polêmicas (para a qual já tenho uns 5 ou 6 assuntos guardados). Fato é: as linguagens todas vão ficar mais dinâmicas. É a influência do Ruby (e do LINQ) sobre o .Net. Você não precisa usar, mas vai perder um monte se não usar.

Na linha deste tipo de preocupação, na última reunião do grupo, o André Dias e eu estávamos conversando sobre essa história do C# vir com dinamismo, e que tem gente achando que a palavra-chave dynamic é igual a um "Dim". Não é. Depois aproveito e posto sobre isso também.

Indo então ao ponto: argumentos opcionais e nomeados. Antes, se você tinha um método, e quisesse que algum parâmetro fosse opcional, você fazia um overload:

    class Boliche
    {
        public void Derrubar(int pinos)
        {
        }
        public void Derrubar()
        {
            this.Derrubar(0);
        }
    }

Assim, chamar Boliche.Derrubar(), sem parâmetros, é o mesmo que chamar Boliche.Derrubar(0), passando zero. Funcionava perfeitamente, só que dava um trabalhão, principalmente se você tivesse um monte de overloads, além de não ser explícito para o consumidor da classe, que tinha que ficar escolhendo qual overload usar e não sabia qual o valor padrão. Afinal, o consumidor não tem acesso ao fonte necessariamente, e onde está escrito que o valor padrão é zero? Pois agora esse problema será resolvido. O C# utilizará uma sintaxe muito parecida com a do VB, onde, após a definição do nome do parâmetro, você coloca um igual e o valor padrão. No VB ainda precisa da palavra-chave "optional". No C# não precisa. É simples assim, e é uma mão na roda, livrando a gente daquele monte de overloads, para fazer algo tão simples:

    class Boliche
    {
        public void Derrubar(int pinos = 0)
        {
        }
    }

A chamada do cliente ao método fica idêntica.

Parâmetros opcionais não são nada de novo. Existe no .Net (e portanto no CLR e no CLS) desde a versão 1.0, já que eram necessários para o VB funcionar. A IL sempre gerou parâmetros opcionais para o VB. São "novidades" em uma linguagem com release de 8 anos, existente desde o VB com guaraná com rolha… Não entendo porque o C# não tem isso desde o princípio… vai ver o pessoal do Java e do C/C++ que estava migrando ia reclamar que C# era muito parecido com o VB. Vai saber…

Pois bem, isso são parâmetros opcionais. Indo em frente: Argumentos nomeados vêm de mão dadas com parâmetros opcionais. Vejam esse exemplo:

    class Boliche
    {
        public void Derrubar(int pinos = 0, int pinosRestantes = 10)
        {
        }
    }

Posso chamar direto Boliche.Derrubar(), mas isso passaria zero e dez aos parâmetros. E se eu quisesse chamar o método passando somente o segundo argumento, chamado pinosRestantes? Fácil:

        static void Main(string[] args)
        {
            var b = new Boliche();
            b.Derrubar(pinosRestantes: 7);
        }

Neste caso, estou dizendo ao compilador que quero passar somente o segundo parâmetro, e que no primeiro aceito o valor padrão, que é zero. Também muito simples.

Algumas regras:

  1. Parâmetros opcionais são sempre os últimos. Você não pode ter um parâmetro não opcional à direita de um opcional. Faz sentido se você pensar na estruturação da sintaxe.
  2. Somente constantes são aceitas como valores padrão de parâmetros opcionais. Isso pode ser um bom motivo para continuar a usar overloads em alguns casos.
  3. Argumentos nomeados podem ser especificados em qualquer ordem. Você poderia chamar, por exemplo, Boliche.Derrubar(pinosRestantes: 5, pinos: 3), sem problemas. Mas ainda que possam ser especificados em qualquer ordem, eles serão avaliados na ordem escrita no método que está chamando, e não na ordem declarada na função. Isso é importante caso você esteja chamando funções para passar valor aos parâmetros, como Boliche.Derrubar(pinosRestantes: this.ObterPinosRestantes(), pinos: this.ObterPinosDerrubados()). Neste caso, o método ObterPinosRestantes é chamado antes do método ObterPinosDerrubados. Isso pode ser um problema caso você tenha funções com efeitos colaterais, algo que deve ser evitado a todo custo (não crie uma função que retorna um valor, e altera outro no contexto quase de forma escondida, a não ser que queira problemas para depurar depois).
  4. Você pode especificar argumentos não opcionais por nome normalmente. Isso não está restrito a argumentos opcionais.

Essas features são plenamente suportadas no CTP do Visual Studio 2010 que saiu em Outubro, ao contrário das features de variância e dinamismo, que estão pela metade.

No próximo post de C# 4.0 vou falar de interop com COM, e vocês vão ver o quanto isso ajuda neste tipo de caso.


Postado na(s) categoria(s) .Net pelo giovanni bassi em 1 de dezembro de 2008 às 19:08 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Jerry Lewis - The Bellboy Já fui perguntado algumas vezes qual provedor uso para hospedar este site, domínio, e-mails, etc. Então decidi compartilhar com vocês porque sem dúvida é muito mais barato do que as opções que temos aqui no Brasil, já que é um provedor nos Estados Unidos. Seu nome é Godaddy, e é um dos maiores provedores de lá. Só para vocês terem uma idéia, a hospedagem mais simples deles custa 5 dólares por mês, ou seja, pouco mais de dez reais. E o domínio é uns 10 dólares por ano. E você leva 10 GB de espaço, 300GB de transferência, SQL Server, MySQL, controle total sobre o domínio, 25 subdomínios, e 100 contas de e-mail. Ainda pode usar ASP.Net 3.5 e PHP, tem total controle sobre as aplicações no IIS. O IIS já é versão 7.0 e você leva ainda 50 usuários de FTP.

E a performance dos caras é excelente. É óbvio que a latência é maior do que se estivesse hospedado aqui no Brasil (fica em torno de 200ms), mas ainda assim é pequena, e na verdade não faz a menor diferença, ainda mais no mundo de banda larga como o nosso. Essa latência é mais ou menos a mesma latência do Youtube. Nada mal, certo?

Comparando com qualquer provedor brasileiro, você paga uns 20 reais (o dobro) para ter 5GB de espaço (a metade), e uns 100 GB de transferência (um terço). Mas não tem SQL Server. Resumindo: perde em mais ou menos um quarto do valor, sem contar as funcionalidades…

Se você comparar as contas intermediárias (é uma dessa que eu tenho), você pode hospedar quantos domínios quiser (eu hospedo alguns vários, incluindo o recém criado dotnetarchitects.net), e o espaço sobe para 150 GB (15 vezes mais), e a transferência para 1.5 TB (5 vezes mais), por somente 7 dólares, ou seja, 15 reais. Ainda assim é mais barato que as contas básicas que temos aqui no Brasil. Uma conta dessas aqui no Brasil passa de 100 reais. Não dá nem para considerar.

Para o e-mail eu uso Google Apps. Porque? Por vários motivos: porque foi o primeiro a dar um suporte decente a e-mails pessoais, porque a interface do meu e-mail pessoal (@giggio.net) é a mesma do Gmail (e eu adoro essa funcionalidade de agrupar mensagens de um mesmo assunto como se fossem uma conversa – e de fato são), porque é grátis, e porque meus e-mails pessoais saem sem propaganda nenhuma. E eu tenho direito a 25 e-mails de 7GB cada um. Sete! Gigabytes. Isso dá quase 200 GB de espaço de e-mail. De graça. Ok, eu aceito ver umas propagandazinhas, vale o custo, afinal ainda ganho interface mobile, SMTP, IMAP, POP e tudo aquilo que o Gmail tem. E ainda ganho mais um monte de frescuras do Google, que mal uso, como GTalk interno para o domínio, Google sites, Google Calendar, etc, etc. Tudo com o branding Giggio.net (você troca o logo do Google/Gmail pelo seu). Legal, não é? E o melhor: grátis.

E posso usar Google Apps porque o Godaddy me libera controle total sobre o DNS, então eu aponto meus registros de e-mail para onde bem entender. Hoje botamos o servidor de Subversion do .Net Architects no ar em 15 minutos com o controle de DNS. Até SPF eu tenho no meu domínio, ou seja, você nunca vai receber um spam do domínio giggio.net. Tudo isso por 10 reais por mês, e com uma interface fácil de usar. Fala se isso não faz você desistir de ficar com um e-mail @gmail.com ou @hotmail.com e ter o seu próprio, e abandonar o Wordpress e o Blogger e hospedar você mesmo seu blog, podendo customizar o que você quiser com um software excelente como o Blogengine.net (que roda esse blog e o .Net Architects) ou o Screwturn wiki.

Fica aqui então a dica. Vamos de "um PC em cada mesa", para "um domínio por pessoa".

Observação: gostaria de ressaltar que não tenho nenhuma relação com a Godaddy, isto aqui é só uma dica mesmo. Pago mensalidade como todo mundo e não recebo nada por contar aqui que o serviço dos caras é bom.


Postado na(s) categoria(s) Dicas pelo giovanni bassi em 27 de novembro de 2008 às 18:21 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Capa da edição 57

Acaba de chegar às bancas a edição 57 da .Net Magazine com meu artigo de introdução ao Domain Driven Design. Esse foi um artigo muito legal de escrever, porque me fez, depois de bastante tempo trabalhando com DDD, voltar às raízes e revisar o DDD conceitualmente, o que me ajudou a relembrar e clarificar alguns assuntos. É claro que não dá para entender DDD de ponta a ponta em 10 páginas de revista, mas dá para você ter uma boa idéia do que é DDD. No último encontro do grupo .Net Architects eu falei que o artigo estava para sair, e recomendei que todos dessem uma lida para se preparar para a próxima reunião, onde vou abordar aspectos práticos e experiências que vivi com o DDD.

Camadas segundo o DDDNão posso infelizmente publicar o artigo aqui, mas posso adiantar um pouco do material que está na revista, por exemplo, aqui está o modelo de camadas proposto pelo DDD. Esse desenho, por si só, já tira muitas das dúvidas.

- Minha camada de interface pode falar com a camada de infra-estrutura?
- Pode.
- E minha camada de domínio, conhece a camada de interface?
- Não, de jeito nenhum.
- Mas o domínio conhece quem?
- Só a camada de infra.
- Se eu tiver um serviço na camada de aplicação, ele pode falar com a camada de infra?
- Oras, claro, porque não?

E outras dúvidas parecidas…

Diagrama de classes com DDD

Já essa outra figura, mostra duas entidades (carga e itinerário), um serviço (de agendamento), e uma especificação (de rota). E dá para entender um pouco como eles interagem a partir da figura.

Eu gosto bastante do conceito de especificação. É o tipo de conceito que ajuda muito quando você aprende a usar, e cada vez que usa aprende um pouco mais sobre o ele. Definitivamente recomendo a exploração desse conceito tão pouco utilizado.

 

Enfim, se você quer dar uma olhada em uma das abordagens mais interessantes hoje para o desenvolvimento de aplicações complexas, compre a revista e dê uma lida nessa introdução ao DDD. Mês que vem eu sigo no assunto, mas com um artigo mais prático, que ficou bem legal.


Postado na(s) categoria(s) Artigos técnicos pelo giovanni bassi em 26 de novembro de 2008 às 17:02 | Tags: , , , , ,

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Depois de grande ansiedade, recebi o preview do Windows 7 que estreou no PDC, por fontes que não posso revelar. Mas é real (clique para ampliar):

Instalando Windows 7

Logando Windows 7

Esta rodando em uma VM (claro) dual core, e instalou sem problemas, e muito rápido (bem mais rápido do que uma instalação de Vista). Por algum motivo ele não aceitou drives SCSI, mas instalou normal em um drive IDE.

Em breve mais informações.


Postado na(s) categoria(s) Windows 7 pelo giovanni bassi em 25 de novembro de 2008 às 17:46 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

A segunda reunião do grupo foi neste sábado passado, bem no meio do feriado, em 22 de Novembro. Tivemos em torno de 15 pessoas presentes, o que quase dobrou a quantidade de pessoas da reunião anterior. A reunião foi novamente na Unip do Jaguaré.

A reunião foi muito proveitosa: começamos falando do tema do encontro, que era metodologia ágil, apresentado pelo Antonio Zegunis, onde ele falou por uns 40 minutos, principalmente sobre o que é metolodologia ágil e Scrum, e como foi a adoção na empresa que trabalha. Ele postou no blog dele os slides da apresentação. Em geral o grupo entendeu que desenvolvimento ágil é o novo caminho a seguir, com algumas críticas feitas à praticas de desenvolvimento 100% em cascata, baseadas em PMI e CMMi (ainda que as muitas práticas destas instituições/certificações sejam bastante válidas).

Definimos então o software que iria rodar a home page do site do .Net Architects, e acabamos escolhendo o BlogEngine, software que roda este blog. Para mais informações a esse respeito há uma notícia lá no site.

Mudamos a periodicidade das reuniões, que não serão mais mensais, mas a cada três semanas. As próximas reuniões, com os temas a serem apresentados, serão:

  1. 13/Dezembro – Giovanni Bassi – Tema: DDD
  2. 10/Janeiro – André Dias – Tema: Ciclo de vida de desenvolvimento com Team System
  3. 31/Janeiro – sem responsável – Tema em aberto

Os seguintes temas foram sugeridos para as próximas reuniões. Estamos aguardando voluntários:

  1. TDD
  2. Sistemas distribuídos
  3. Inversion of Control / Dependency Injection

O André Dias lembrou que nossos temas estão muito focados em processo, e sugeriu outros assuntos no grupo de e-mail, onde também surgiram mais sugestões. Entre eles:

  1. Sync Framework
  2. Velocity
  3. ADO.NET Data Services,
  4. SQL Data Services,
  5. .NET Services,
  6. Enterprise Library,
  7. ESB,
  8. WCF,
  9. WF,
  10. Windows Dublin
  11. NVelocity
  12. Spring.Net
  13. Castle Project

A idéia dos temas é apresentar a experiência de quem esta apresentando. Alguns temas estariam fora desta categoria, pois são muito novos (Dublin, por exemplo, nem foi lançado ainda), e poderiam ser apresentações da tecnologia.
Também falamos que pode-se trazer convidados para apresentar temas nos quais não tenhamos especialistas.

Mudamos a distribuição do horário das reuniões. Fica assim agora:

  1. Uma hora de apresentação do tema;
  2. Uma hora de discussão
  3. Intervalo de até 15 minutos, opcional;
  4. Uma hora de outros assuntos que o grupo quiser tratar, como problemas que alguém está enfrentando, e discussões diversas.
  5. Almoço opcional, se o grupo quiser.

O assunto do projeto aberto de referência de arquitetura foi jogado para a próxima reunião. O grupo sente que ainda não está preparado para tocar o projeto. O assunto vai sendo abordado recorrentemente em todas as reuniões.

Foi solicitado que o grupo fosse cadastrado nos grupos de usuário do MSDN e da Ineta. Eu já fiz isso, e está disponível por lá. Por causa do nome do grupo, que começa com um ponto, acabou sendo o primeiro grupo da lista, que está em ordem alfabética.

Todos concordaram que já podemos tratar do evento. A data foi definida para Abril. Sugeri que utilizássemos alguns dos temas das reuniões como palestras, e o grupo concordou. Continuaremos a discutir o assunto por e-mail e na próxima reunião. Fiquei de cadastrar o evento no site da Ineta também, e com isso conseguiremos o apoio da Ineta/Microsoft no evento.

Todo o encontro foi filmado por uma equipe profissional de áudio e vídeo. O vídeo está em edição e provavelmente esta semana teremos disponível para exibir. Isso permitirá aos membros do grupo que não foram ao encontro, ou que não são de São Paulo acompanhar as reuniões. Quem sabe mais para frente não temos até algo online?

Depois da reunião quase o grupo todo foi almoçar. A reunião terminou uma hora da tarde, mas o almoço foi até as 4 da tarde. Em certo momento notamos que estávamos discutindo arquitetura por seis horas ininterruptas (ok, paramos alguns instantes para falar de Xbox durante o almoço).

Estou muito satisfeito com o resultado desta segunda reunião. Foi a primeira reunião com a pauta mais estruturada. O nível da discussão foi sempre muito bom e sinto que continuaremos assim. Os membros do grupo são bastante capacitados e de posições e empresas distintas, o que traz bastante diversidade e profissionalismo ao grupo.

Não posso deixar de agradecer novamente à Unip por disponibilizar desta vez, não só o local para a reunião, mas também à Infra-estrutura para filmar e editar a reunião.


Postado na(s) categoria(s) Arquitetura pelo giovanni bassi em 25 de novembro de 2008 às 06:03 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Pessoal, o .Net Architects, nosso grupo de arquitetura, está com site reformulado, e em processo de melhoria.

Amanhã vou postar sobre a terceira reunião, que foi bem legal, lá e aqui. E logo logo vou passar a comentar sobre o grupo só por lá, ou seja, quem acompanha por aqui, sugiro passar a acompanhar por lá também. Temos um feed rss exatamente para isso.


Postado na(s) categoria(s) Arquitetura pelo giovanni bassi em 24 de novembro de 2008 às 17:03 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Pessoal, a segunda reunião do grupo de arquitetura (.Net Architects) é amanhã e tudo indica que vai ser bem agitado, segundo o movimento no grupo online de discussão.

Se você ainda não indicou interesse ainda dá tempo. Me mande seu nome completo e RG que eu coloco na lista. O e-mail é giggio arroba giggio.net

Vejo vocês lá.


Postado na(s) categoria(s) Arquitetura pelo giovanni bassi em 21 de novembro de 2008 às 03:43 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Pessoal, o Ramon Durães estará lançando seu livro "Desenvolvendo para web" na Fnac da Av. Paulista, em São Paulo, no dia 9/12, às 19 horas. Será uma boa oportunidade de conferir o livro, rever as pessoas da comunidade e parabenizar o Ramon pela escrita do livro, algo que não é nada fácil.

O livro já tem até uma comunidade própria, feita no NING:

http://www.desenvolvendoparaweb.net

E há uma lista de RSVP na comunidade:

http://www.desenvolvendoparaweb.net/events/lancamento-livro-em-sao-paulo

Estarei lá.


Postado na(s) categoria(s) Eventos pelo giovanni bassi em 19 de novembro de 2008 às 06:35 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Continuo trazendo as novidades de C# 4.0. Este é o terceiro post, se você não viu os posts anteriores:

  1. C# 4.0 – Quanto antes melhor – onde apresentei um resumo das novidades, além de assuntos que envolvem a nova versão da linguagem;
  2. C# 4.0: Uma linguagem dinâmica – onde apresentei as novidades do C# 4.0 que vão aproximá-lo mais de uma linguagem dinâmicas.

Ou ainda pela tag: C#4.

Aviso: Antes de continuar, vou contar novamente a história triste (já contada nos posts anteriores sobre o mesmo assunto). Os bits que estão disponíveis para download não são tão quentes quanto os bits apresentados no PDC. Sorry, mas é verdade. Isso quer dizer que algumas das coisas que vou mostrar aqui não vão compilar no build do CTP. Sabendo disso, vamos lá.

Neste post vou falar de covariância e contravariância, o que finalmente vai por um fim à invariância predominante no C# (fora os arrays que já são covariantes). É o segundo grande assunto sendo abordado porque é o segundo mais legal e interessante na minha opinião. A princípio é meio contra-intuitivo pensar sobre variância, mas depois que sua mente já deu uns nós ela volta ao normal e de repente você começa a entender. Se acontecer com você, não se preocupe, é assim mesmo, é normal.

Para entender um pouco melhor o drama da variância, dêem uma lida em uma reclamação minha sobre o problema gerado por ela aqui no blog. Vale a pena também ver o trabalho do Felipe Pessoto, que traduziu uns posts do Eric Lippert (do time do C#, e um ótimo blogger) que tratavam muito bem sobre o assunto. Se você não conhece o assunto eu recomendo a leitura.

Lembrando então rapidamente> Arrays são covariantes. Isso significa que você pode pegar um array de strings:

string[] textos; 

E tipá-lo como um array de objetos, porque string herda de objeto:
object[] objetos = textos; //compila sem problemas

Mas tipos genéricos são invariantes. Isso quer dizer que se você tiver uma lista de strings:

IList<string> textos = new List<string>(); 

Você não consegue passá-la para uma lista de objetos:
IList<object> objetos = textos; //não vai compilar no C# 3 

Ainda que toda string seja um objeto também, o problema acontece porque IList<string> não herda de IList<object>, e portanto a associação não é permitida. Se fosse, você poderia quebrar o tipo genérico em runtime assim:
IList<object> objetos = textos; 
objetos.Add(new Button()); //pau em runtime: um botão não é uma string

De fato, é exatamente o que pode acontecer com arrays. Seguindo no exemplo, se você fizer isso:

objetos[0] = new Button(); 

Vai compilar porque um botão é um objeto, mas em runtime você vai ter um exceção sendo lançada, porque um botão não é uma string, e na verdade o array é originalmente um array de strings, apenas tipado como um array de objetos. Perigoso, certo?

Ok, mas imaginem que tivéssemos um enumerador de strings:

IEnumerable<string> textos = ObterUmEnumeradorDeStrings(); 

Não seria tão perigoso assim associar este enumerador a um enumerador de objetos:
IEnumerable<objects> objetos = textos; 

Porque, na verdade, não temos como alterar os tipos contidos pelo enumerador, ele é uma coleção em que os itens só podem ser lidos e iterados, e é por isso somente-leitura. Esse tipo de conversão não é perigosa, e não teria problema algum em ser permitida, certo?

Na verdade, o que acontece com IEnumerable<T>, é que este tipo genérico apenas devolve o tipo T em operações, ele não o recebe como parâmetro em nenhum momento, o que elimina a necessidade de qualquer conversão. Sua assinatura é assim:

    public interface IEnumerable <T>: IEnumerable
    {
        IEnumerator<T> GetEnumerator();
    }

É diferente de IList, que recebe T como parâmetro, por exemplo, nos métodos Insert e IndexOf (além de outros das interfaces que IList implementa):

    public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable
    {
        T this[int index] { get; set; }
        int IndexOf(T item);
        void Insert(int index, T item);
        void RemoveAt(int index);
    }

Por este motivo, no caso de IList, o objeto não seria covariante com segurança, porque se isso fosse possível, um IList<object> poderia, no fundo, ser um IList<string> e receber uma chamada de Insert(0, new Button()), o que resultaria em um erro em runtime.

Para indicar este tipo de situação em tempo de compilação, o time do C# incluiu duas novas palavra-chave opcionais na definição de generics: "out" e "in". "Out" é para ser usado quando o tipo genérico é covariante, e pode ser retornado em alguma função ou propriedade readonly, como no caso do IEnumerable. "In" é para quando o tipo genérico é contravariante, e pode ser recebido como parâmetro.

Assim, a interface IEnumerable na nova versão ficaria assim:

    public interface IEnumerable <out T>: IEnumerable
    {
        IEnumerator<T> GetEnumerator();
    }

E você poderia então fazer isso:

IEnumerable<string> textos = ObterEnumerador(); 
IEnumerable<object> objetos = textos; //vai compilar no C# 4 

Porque o compilador sabe que é seguro. Um enumerador de strings é sempre um enumerador de objetos e não há perigo em tratá-lo pelo tipo menos específico (objeto). Muito inteligente, certo?

Um exemplo de contravariância é uma interface que só recebe parâmetro de entrada. O exemplo dado pela própria Microsoft foi a interface IComparer. Originalmente assim:

    public interface IComparer<T>
    {
        int Compare(T x, T y);
    }

Ela poderia ser alterada com a palavra chave "In", e ficaria assim:

    public interface IComparer<in T>
    {
        int Compare(T x, T y);
    }

O que permitiria isso, que até o momento não é permitido no C# 3.0:

IComparer<object> comparadorObjetos;
IComparer<string> comparadorStrings = comparadorObjetos;

Isso porque uma classe que é capaz de comparar objetos, também é capaz de comparar strings. Por esse motivo, a interface é marcada como genérica e contravariante, ou seja, aceita tipos genéricos apenas como entrada em formato de algum parâmetro, mas não como saída (de uma função, por exemplo).

Isso conclui o básico sobre a novidade de variância. Faço apenas três observações:

  1. Assim como no caso dos tipos dinâmicos, a máquina virtual disponibilizada para download pela Microsoft com Visual Studio 2010, Rosario, C# 4.0 e .Net 4.0 não contém ainda os bits necessários para fazer essa sintaxe compilar. Isso quer dizer que não dá ainda para criar tipos variantes em C# 4.0 com essa VM, e não há os tipos IEnumerable<out T>, ou IComparer<in T> no BCL. Vamos ter que esperar a próxima verão sair, e, depois de todo esse auê com C# 4.0, espero que não demore tanto.
  2. O segundo aviso é que tipos de valor, como tipos primitivos e structures, são sempre invariantes, ou seja, não dá para fazer cast de um IEnumerable<DateTime> para IEnumerable<object>.
  3. O terceiro aviso é que parâmetros passados como "out" ou "ref" não podem ser variantes, porque eles seriam "in" e "out", e acabam não sendo nenhum dos dois.

Boa parte do .Net Framework 4.0 foi alterado para acomodar essa grande mudança. Além dos já citados IEnumerable e IComparer, também há outros, como IQueryable<out T>, e também delegates, como Func<in T, out R>, Action<in T>, e Predicate<in T>. Notem que Func tem um tipo genérico "in" e outro "out". Isso tem cara que vai deixar muita gente confusa… No fim das contas, a maior parte das pessoas vai simplesmente usar e nem se preocupar como isso tudo está funcionando.

O negócio vai ser tão automático que, quando estivermos trabalhando com C# 9.0, em, sei lá, 2020, alguém vai falar algo do tipo:
- Lembra quando C# era totalmente invariante com generics?
E algum newbie vai dizer:
- C# já foi invariante?

Ah… o futuro…


Postado na(s) categoria(s) .Net pelo giovanni bassi em 17 de novembro de 2008 às 19:16 | Tags:

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Está rolando no grupo de discussões online do grupo de arquitetura uma discussão sobre eficácia do TDD (Test Driven Development). Fiz agora um comentário que acho legal ficar por aqui também.

Há um estudo feito pela NRC Institute for Information Technology sobre a eficácia do TDD, comparando-o com a abordagem convencional:
http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html
Para os sem tempo ou sem paciência, leiam só o abstract. Ele diz o seguinte:

  • A abordagem "teste antes" ou "teste depois" não fez diferença;
  • Os desenvolvedores que escreveram mais testes tiveram melhor qualidade;
  • Desenvolvedores de TDD escrevem mais testes;
  • TDD gerou melhor qualidade.

Ná conclusão do estudo há um parágrafo bem legal:

"Test-First programmers did not achieve better quality on average, although they achieved more consistent quality results. We attribute the latter observation to the influence of skill on quality, which Test-First tended to dampen. Writing more tests improved the minimum quality achievable and decreased the variation, but this effect does not appear to be specific to Test-First."

Interessante, não é? Na verdade, a conclusão é que não faz a menor diferença se você escreve testes antes ou depois, desde que o faça. Para quem gosta do assunto e tem paciência de ler as 13 páginas do documento, acho que vale a pena.

Sugeri também que a quarta reunião do grupo tenha este assunto na pauta de introdução, onde passamos uma hora e meia discutindo o assunto. Vamos ver se alguém se propõe a falar.


Postado na(s) categoria(s) Arquitetura pelo giovanni bassi em 15 de novembro de 2008 às 07:29 | Tags: , ,

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Pessoal, estou pensando em montar um curso de ASP.Net MVC, com foco na tecnologia mas também com um fundo de melhores práticas. É um curso ainda sem precedentes no Brasil, e que só deve sair nos CPLSs da vida (Ka, BF, etc) em um ano mais ou menos, e mesmo assim em um estilo de treinamento que não acho que vai ter esse foco em boas práticas, ou material em português. Quero o feedback de vocês sobre a idéia, então votem, por favor, abaixo. Se o interesse for suficiente eu vou em frente e monto o curso.

Agradeço.


Postado na(s) categoria(s) ASP.Net MVC pelo giovanni bassi em 13 de novembro de 2008 às 20:02 | Tags: ,

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Seguindo na série de novidades do C# 4.0 que vou abordar aqui no blog, quero agora dar uma olhada no dinamismo adicionado à linguagem.

Aviso: Antes de continuar, gostaria apenas de contar para vocês uma história triste. Os bits que estão disponíveis para download não são tão quentes quanto os bits apresentados no PDC. Sorry, mas é verdade. Isso quer dizer que algumas das coisas que vou mostrar aqui não vão compilar no build do CTP, e por isso, eu posso até errar alguma vírgula, já que não vou ter confirmação do compilador ou testes. Enfim, é o que dá trabalhar na borda das novidades de tecnologia, faz parte… Então vamos lá.

Não foi nesta versão (e não vai ser nunca) que o C# se tornou uma linguagem dinâmica como o Python ou o Ruby (implementados no .Net como IronPython e IronRuby). Mas agora, em poucas palavras, é possível ter uma variável tipada como "dynamic", e chamar sobre ela qualquer método. Isso quer dizer que quando você coloca o ponto (.), nada aparece. Nada. E você pode digitar o que quiser depois do ponto. E compila. E esse negócio todo vai ser resolvido só na hora que o aplicativo estiver rodando (em runtime). Ou seja, não há verificação em tempo de compilação, o que é um dos contras de linguagens dinâmicas. Mas há vários pros, então não se preocupe. Além disso, você só usa se quiser.

Você pode resolver esse problema de não ter verificação em tempo de compilação com a utiliação de testes unitários! Muito bem, testes, testes, testes! Crie muitos testes. (Aliás, crie testes mesmo se você não for trabalhar com C# e suas capacidades dinâmicas. Testes são bons, fazem você crescer mais forte, morrer mais tarde, casar com uma pessoa legal, e além disso previne espinhas. E dá muita sorte.)

É muito parecido com o que o VB faz com Late Binding, mas é mais poderoso. Isso porque permite integrar vários modelos de chamada dinâmica, como Javascript, POCOs, COM, e outros que você quiser, já que é extensível.

Por exemplo, se estiver trabalhando estático, segue abaixo o código simples de uma calculadora:

    class Calculadora
    {
        public long Adicionar(int numero1, int numero2)
        {
            return numero1 + numero2;
        }
    }

Você faz sua soma em um windows form desta forma:

        private void butSomar_Click(object sender, EventArgs e)
        {
            Calculadora calc = new Calculadora();
            int numero1 = Convert.ToInt32(txtNumero1.Text);
            int numero2 = Convert.ToInt32(txtNumero2.Text);
            long resultado = calc.Adicionar(numero1, numero2);
            lblResultado.Text = "Resultado: " + resultado;
        }

Até aí tudo bem. Mas e se for dinamicamente? E se eu não souber o tipo? Bom, o C# de hoje já permite isso, com Reflection, e em grande parte é o que VB faz por baixo dos panos quando você faz late binding. Fica assim:

private void butSomarQuaseDinamico_Click(object sender, EventArgs e)
{
    object calc = new Calculadora();
    Type type = calc.GetType();
    int numero1 = Convert.ToInt32(txtNumero1.Text);
    int numero2 = Convert.ToInt32(txtNumero2.Text);
    long resultado = (long)type.InvokeMember("Adicionar",
        System.Reflection.BindingFlags.InvokeMethod,
        null,
        calc,
        new object[] { numero1, numero2 });
    lblResultado.Text = "Resultado: " + resultado;
}

Maior trabalhão, certo? Veja com C# 4.0 e tipos dinâmicos como isso facilita:

Novo método de adicionar:

        public dynamic Adicionar(dynamic numero1, dynamic numero2)
        {
            return numero1 + numero2;
        }

E novo método de chamada:

        private void butSomarDinamico_Click(object sender, EventArgs e)
        {
            dynamic calc = new Calculadora();
            dynamic numero1 = txtNumero1.Text;
            dynamic numero2 = txtNumero2.Text;
            long resultado = calc.Adicionar(numero1, numero2);
            lblResultado.Text = "Resultado: " + resultado;
        }

Bom, apesar de parecer que vai funcionar, na verdade, não vai. Alguns problemas: apesar de a avaliação de tipos dinâmicos ser feita em runtime, ainda assim o tal do tipo dinâmico ainda tem um tipo. Declará-lo como dinâmico significa apenas que o compilador não vai checar suas chamadas, mas em runtime isso vai ser feito. Neste caso, as variáveis numero1 e numero2, declaradas dinâmicas, são na realidade strings. E ao chamar o operador "+" sobre strings, o que acontece é uma concatenação, e não uma soma. Para resolver isso, você deve voltar a converter. Assim:

        private void butSomarDinamico_Click(object sender, EventArgs e)
        {
            dynamic calc = new Calculadora();
            dynamic numero1 = Convert.ToInt32(txtNumero1.Text);
            dynamic numero2 = Convert.ToInt32(txtNumero2.Text);
            long resultado = calc.Adicionar(numero1, numero2);
            lblResultado.Text = "Resultado: " + resultado;
        }

Dessa forma, a variavel numero1 é declarada dinâmica, mas no fundo, ela é um inteiro. Isso mostra o poder do dinamismo: o operador é chamado sobre o tipo que você passou, qualquer que seja ele. Se for uma string ele concatena, se for um inteiro ele soma. Isso é muito poderoso.

Observação: Não se anime muito com esse exemplo ainda, porque esse é um caso típico de bits não disponíveis ainda. Esse código vai dar um erro de compilação na linha que diz "return numero1 + numero2;", porque os bits do CTP não implementaram ainda resolução de operadores. Esse exemplo da o seguinte erro: "Operator '+' cannot be applied to operands of type '::dynamic' and '::dynamic' ". O próximo CTP (ou já o Beta) vai ter isso funcionando.

O mais engraçado disso tudo é que o C# continua sendo uma linguagem estática, mas com "aspectos" dinâmicos. A variável numero1, por exemplo, é "estáticamente tipada como dinâmica". Ela possui um tipo, e esse tipo é "dynamic". E esse tipo tem naturezas dinâmicas, e é tratado de forma diferente pelo compilador. Mas no fim das contas, um tipo dinâmico é um object com tratamento especial em compilação e em runtime. É isso.

Outra coisa importante de saber é que operações com objetos dinâmicos sempre retornam outro objeto dinâmico. Assim, se você chamar:

        public dynamic Somar10(dynamic numero)
        {
            var ret = numero + 10;
            return ret;
        }

A variável ret vai ser de tipo dinâmico. Tipos dinamicos se propagam, então tenha cuidado.

Acho que isso já dá pra entender o que é um tipo dinâmico. Pegando os exemplos da Microsoft, veja o que mais você pode fazer:

            dynamic d = RetornaObjetoRemoto();
            //chamando um método:
            d.M(7); 
            // setando propriedades:
            d.f = d.P; 
            // indexadores funcionando dinamicamente
            d["one"] = d["two"]; 
            // operadores:
            int i = d + 3; 
            // objeto dinamico é na verdade um delegate
            string s = d(5,7); 

É claro que, neste caso, não seriam todas as operações possíveis, por causa do tipo. Você não tem indexadores em delegates, por exemplo… Mas esse código deve compilar com a versão final do C# 4.0 (a do CTP da erro nos operadores – novamente - e mais um erro nos indexadores - "Cannot apply indexing with [] to an expression of type '::dynamic' ").

Outra coisa interessante é como é feita a resolução de uma chamada a um método que possui sobrecargas, com tipos dinâmicos. Assim, por exemplo, se tivermos um método sobrecarregado desta forma na nossa calculadora:

        public DateTime Adicionar(DateTime data, int dias)
        {
            return data.AddDays(dias);
        }

(Lembrem-se, já havia um outro método Adicionar que aceitava dois inteiros.)

Ao chamar a função Adicionar em um tipo dinâmico, ele vai ser resolvido de acordo com os valores de runtime. Assim:

            dynamic calc = new Calculadora();
            calc.Adicionar(1, 2);
            calc.Adicionar(DateTime.Now, 2);

A primeira chamada a Adicionar vai chamar o overload Adicionar(int, int), e a segunda vai chamar Adicionar(datetime, int). E essa resolução é feita em toda pelo framework. Legal, não é?

Se você quiser ver uma aplicação legal, veja o vídeo em que o Anders Hejlsberg apresenta o C# 4.0, mais ou menos no minuto 26, e você verá uma aplicação Silverlight que utiliza o Virtual Earth e integra C# no code-behind e javascript. No Javascript há isso:

Código Javascript de chamada do Virtual Earth

Note que Javascript é uma linguagem bastante dinâmica, e não há tipos declarados.

E no código em C#, há a chamada ao método javascript, através da Interoperabilidade (a parte: só o fato do Silverlight permitir essa interoperabilidade é o máximo, não é?):

Código C# do Silverlight que chama o código Javascript anterior

Vocês notaram no código C# as chamadas todas são feitas de uma maneira um pouco estranha, através de métodos "Invoke" ou "SetProperty". Detalhe, tudo isso já é possível hoje, com C#3 e Silverlight.

Pois bem, o Anders começa então a aplicar um pouco do dinamismo. Ele aplica o método de extensão AsDynamic, que retorna estes tipos dinâmicos, nos dois objetos que eram trabalhados, um HtmlDocument e uma HtmlWindow. E faz então alguns ajustes, chamando diretamente os métodos que eram chamados via "Invoke", e setando propriedades sem "SetProperty". Fica assim:

Código C# do Silverlight modificado para usar as propridades dinâmicas do C# 4.0

Bem mais legível, certo? E como os métodos eram chamados com strings, e não havia verificação em tempo de compilação, nada mudou com relação a isso.

Em seguida, ele recorta o código Javascript, cola ele no código C# e faz alguns ajustes. Bem poucos, na verdade, e fica assim:

Código C#, migrado do antigo código Javascript, e todo trabalhado dinamicamente

A partir daí, este código C# passa a funcionar. Tudo dinâmico, e até meio "mágico". É nesse tipo de aplicação, na interação com linguagens dinâmicas, ou objetos desconhecidos, que o custo das linguagens dinâmicas se paga.

É importante lembrar que todo este código traz uma dependência sobre o DLR, que é o Dynamic Language Runtime. O DLR vai vir junto com a próxima versão do .Net Framework e ainda não está concluído. Este fato, inclusive, é um dos problemas do pessoal do IronRuby, que também dependem do DLR, mas só podem progredir se o DLR já tiver implementado algumas coisas (o IronRuby é um projeto opensource). Além disso, por enquanto tenho ouvido falar de problemas de performance no DLR, o que está sendo endereçado pela Microsoft, e tudo isso leva tempo.

Assim que sair o novo CTP do VS 2010 e o suporte a tipos dinâmicos estiver implementado eu volto a falar do assunto. Enquanto isso, vou seguir nas outras novidades do C# 4.0.

Vocês gostaram dessa novidade? Onde mais vêem aplicações reais dessa nova funcionalidade do C#?


Postado na(s) categoria(s) .Net pelo giovanni bassi em 11 de novembro de 2008 às 16:59 | Tags:

5.0 ponto(s). Avaliado por 1 pessoas

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

A segunda reunião do grupo, conforme eu já havia contado aqui, será em 22/11, no mesmo local da reunião anterior.

2º Encontro do Grupo de arquitetura de software
22/11/2008 (sábado) – 10 horas da manhã
UNIP da Cidade Universitária/Marginal Pinheiros
Av. Torres de Oliveira, 330 - Jaguaré, São Paulo - SP
CEP 05347-020
Tel.: (11) 3767-5800

O tema do começo da próxima reunião será "Metodologia ágil", a ser apresentado pelo Antonio Zegunis, que está trabalhando com isso há um tempo, e está passando nesse momento pela adoção desse processo na empresa que trabalha e atuando diretamente para o sucesso da empreitada.

Se você quiser ir, demonstre seu interesse neste post do grupo de discussão online, respondendo à mensagem. Por motivos de segurança só será possível entrar na Unip com cadastro prévio.

Atenção, há duas semanas até lá. Dá tempo pra se planejar, não deixe para em cima da hora.


Postado na(s) categoria(s) Arquitetura pelo giovanni bassi em 9 de novembro de 2008 às 19:23 | Tags: ,

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Quem é Giovanni Bassi

Giovanni Bassi Sou uma pessoa apaixonada por tecnologia e especificamente por .Net. Sou consultor independente especialista em .Net, focado em arquitetura e melhores práticas. Tenho dezenas de artigos publicados na .Net Magazine, revista da qual sou editor técnico. Ministro palestras e cursos de vez em quando, e quando dá tempo eu respiro um pouco. Mais detalhes nesta página.