.Net Unplugged

HTML 5: E daí?

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Sun, 12 Jul 2009 18:22:47 -0700

No post anterior eu comentei sobre o lançamento do tão esperado Silverlight 3, disse que achava que talvez estejamos indo longe demais com HTML + Javascript + CSS, e disse também que o HTML 5 já nascia morto. Algumas pessoas comentaram essa minha afirmação, o que me leva a escrever este post, já que diversas outras pessoas devem concordar com as que comentaram, mas não se deram ao trabalho de comentar. Esse post então é para trazermos a discussão para o local certo, e para que eu possa expor minhas idéias além de duas curtas frases.

Quando eu digo que o HTML 5 já nasce morto, não quero dizer que ele não vai ser usado. Eu acho muito difícil que, até o lançamento do HTML 5, o mundo pare de usar HTML e passe a usar qualquer outra coisa como base para suas aplicações web. O HTML 5 sucede o 4, e vai ser usado assim que for lançado. Isso, no entanto, não significa que as aplicações realmente ricas serão feitas com ele. E nesse sentido, sim, o HTML 5 nasce morto.

Para começar o HTML 5 vai estar pronto daqui a 13 anos (em 2022), segundo o seu próprio editor (confiram o calendário proposto pelo Ian Hickson). A primeira especificação em rascunho será liberada somente em 3 anos, em 2012, a segunda em 2015 (depois de 3 anos!), e a terceira em 2019 (daqui dez anos). Eu sei o que pretendo fazer nos próximos dois anos. Para daqui 5 anos, eu tenho planos. Não sei vocês, mas não tenho a menor idéia do que vou estar fazendo daqui a dez anos. Muita coisa pode mudar. Vai ver alguém aparece e inventa aquele monitor do filme "O pagamento" (Paycheck), que na verdade nem é um monitor, é só uma imagem em 3D flutuando sobre um pequeno aparelho (quem não viu o filme, recomendo). Na realidade, já inventaram tecnologias que deixam o HTML 5 obsoleto. Elas se chamam Silverlight, Flex, e JavaFx. E sabem quando é o lançamento destas tecnologias? Ontem, uns meses, uns anos atrás. Não é para daqui 13 anos, é para ontem.

Alguns dirão que o HTML 5 já é suportado para alguns navegadores. O Firefox 3.5, por exemplo, já suporta algumas coisinhas. A Microsoft, por outro lado, provavelmente não vai suportar absolutamente nada até que a especificação esteja concluída (com razão). Lembrando que ela detém por volta de 70% do mercado de navegadores, isso coloca o HTML 5 com lançamento oficial só em 2022 mesmo, quando o IE passar a suportá-lo. Ainda que o FF suporte, nenhum grande site vai usar as novidades do HTML 5 se ela é suportada somente em um navegador (ou grupo de navegadores) que detém menos de 20% do mercado. E mesmo que fosse o contrário, e somente o IE suportasse, ainda assim os grandes sites não iriam aderir, porque ninguém pode cortar 30% da sua audiência só porque o pessoal do HTML 5 só quer lançar uma pré-versão a cada 3 anos mais ou menos pelos próximos 13 anos. E, vamos lá… vamos dizer que todos os navegadores suportassem, o que aconteceria? Teríamos o inferno da incompatibilidade novamente, já que cada navegador implementaria as lacunas da especificação do seu jeito, já que a especificação estaria incompleta. Estaríamos de volta ao problema da verificação do navegador.

Não bastasse o fato do HTML 5 chegar tarde no jogo, ele chega apresentando novidades que sequer chegam aos pés das propostas pelas tecnologias RIAs de verdade. Como vocês podem ver na página do HTML 5 na Wikipedia, as "novidades" do HTML 5 são novos elementos, mais semânticos que os anteriores, como "section" e "footer", novos controles de formulários, alguns novos atributos, atributos globais, tratamento de erro, e algumas novas APIs. Essas APIs seriam a grande novidade, já que trazem coisas como controle de tempo de playback, drag and drop, um banco de dados local, entre outros. A mais famosa entre estas, e a mais falada é o canvas, um elemento que permite desenhar bitmaps com scripts. Isso, foi isso mesmo que você leu. Bitmaps. Desenhados com scripts. É, eu também tive vontade de me matar quando eu li isso (na verdade matar os caras que estão especificando este absurdo). Enquanto o mundo inteiro caminha para o desenho vetorial, o HTML 5 caminha para o lado oposto, o bitmap. Em 2022 eles vão estar em 1980. Excepcional! E desenhando de forma imperativa, com Javascript, e não declarativa (com XML, por exemplo, como faz o Silverlight), o que deixa o negócio todo ainda pior. Eu não sei vocês, mas não vou pedir para nenhum designer desenhar com Javascript (pode ser perigoso). (Em tempo: vi algumas referências – não oficiais – que podem indicar suporte a desenho vetorial no HTML 5, mas nada conclusivo, indicando que o HTML 5 seria capaz de manipular vetores, e não só exibí-los. Se alguém souber de algo me corrija.) Algumas coisas que são extremamente simples de serem feitas também parecem bem complicadas no HTML 5. Mas tenho certeza que nos próximos 13 anos (!?!?!) eles vão arrumar isso. Só que daí as tecnologias também vão ter evoluído 13 anos, e o nível exigido vai ser muito maior do que o que eles especificaram em 2012, quando fecharam o primeiro rascunho (10 anos antes da versão final): vai nascer obsoleto.

Tem ainda o problema de quem está tocando esse negócio todo. Tem gente do Google, gente da Apple, gente da Nokia… ou seja, gente demais. E eles não parecem concordar em muita coisa, como vocês podem ver pela recente briga a respeito dos codecs de video que está acontecendo. Cada um quer empurrar o codec que acha mais bonito, e na prática não há codec escolhido. O HTML 5 vai sair sem codec? Vai ver eles vão empurrar o lançamento um ou dois aninhos pra frente, para, sei lá, 2025, até resolverem isso. Afinal, que diferença faz, 2022 ou 2025, não é verdade? Irrelevância por irrelevância, está tudo na mesma.

Gostaria que ficasse claro então o que estou dizendo: o HTML 5 chega tarde demais no jogo, quando ele vai estar totalmente mudado, e sem trazer grandes melhorias. Não vai se estabelecer nunca como uma plataforma RIA. Vai continuar sendo suporte para outras tecnologias, como o Silverlight e o Flex (se esse sobreviver até lá), e vai trazer algumas novidades, que talvez nós nem venhamos a utilizar, porque a web vai ter mudado demais. É viver para ver.

Silverlight 3 concluído e disponível

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Thu, 09 Jul 2009 22:20:54 -0700

Yes! Silverlight 3 chegou a RTW (Release To Web). Baixem aqui:

http://www.microsoft.com/silverlight/resources/install.aspx

Novidades do Silverlight 3 incluem novos controles, 3D, aceleração de hardware, além da possibilidade de rodar o SL fora do navegador, entre várias outras. Vejam outras novidades da v3 aqui.

Ao mesmo tempo a Microsoft liberou o RC (Release Candidate) do Blend 3 e do SketchFlow, aquela ferramenta que fez todo mundo cair de queixo no último Mix. E claro, as ferramentas do VS 2008 para SL também já foram liberadas.

Eu não costumo falar muito de SL por aqui. Quer saber porque estou falando agora? Porque eu estou com um feeling que a terceira versão do Silverlight é a versão que vai deixar claro que o Flex, apesar de ser uma alternativa interessante, ficou para trás. Foi legal enquanto durou. É o HD-DVD das RIA. A partir de agora a distância vai começar a ficar cada vez maior.

Eu nem preciso dizer que me agrada muito abandonar o modelo stateless do HTML e abraçar o C#, o VB, o XAML, e o IronRuby no Silverlight, não é? Eu gosto muito de ASP.Net MVC, e tudo o que conseguimos fazer hoje com Javascript (e suas poderosas libraries) e CSS, mas acho que talvez o HTML já tenha ido mais longe do que devia.

Em tempo: o HTML 5 já nasce morto (igual ao Chrome OS, mas isso é assunto para outro post). Aliás, ainda nem nasceu. Está em especificação, e os próprios especificadores não sabem o que entra e o que não entra, quais codecs suportar para vídeo, etc, etc. O Firefox entra fazendo alarde que suporta um negócio que não está nem em Alpha… e que quer tentar competir com aplicações RIA de verdade, feitas com Silverlight. Dá até dó. Quando o HTML5 estiver pronto (especificado e disponível nos navegadores líderes), em 2020 (mais ou menos), ninguém nem vai mais querer saber o que é (era?) HTML (kind of).

O DBA morreu?

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Wed, 08 Jul 2009 08:08:00 -0700

Nesta segunda-feira mostrei que o mapeamento objeto relacional de uma aplicação inteira pode ser feito em 60 linhas de código e deixei no ar a pergunta que dá nome a este post:

- O DBA morreu?

Vou respondê-la agora:

- Não. Não morreu. Nem vai morrer. Aliás, é o contrário.

Porque não? Porque ele não morreu se agora o banco virou um mero repositório de dados? Respondo: não morreu porque o banco não é um mero repositório de dados. Apesar de hoje termos ORMs capazes de fazer todo o mapeamento automaticamente (ou mesmo que tenhamos que fazê-lo manualmente para depois o ORM gerar um banco de dados) isso só significa que temos produtividade neste contato com o banco. É o DBA, o especialista em banco de dados, quem vai ajudar a preparar o banco para uma aplicação, o que vai muito além de gerar algumas tabelas.

O que isso significa? Devemos então ignorar o automapeamento? Ou o mapeamento fluente? Temos que abandonar os ORMs?

Não, claro que não. Na maioria da aplicações (na minha experiência – e isso varia), em torno de 50% das suas operações de entrada e saída de dados são simples CRUDs, sem muita complexidade. É comum também que estas mesmas operações sejam pouco usadas pelos usuários, já que as telas que trazem valor para o negócio não são simples CRUDs, ou o sistema sequer seria necessário. É nestas telas complexas que nosso esforço deve se concentrar. E é nas telas de CRUD simples que o automapeamento e os ORMs realmente ajudam. No resto podemos usar um mapeamento manual, ou até eliminar o ORM por completo. Se precisamos de performance, se temos que espremer cada milisegundo, por exemplo, talvez um ORM não seja a solução ideal. Nesse cenário podemos isolar as partes da aplicação que tem essas características, e não usar um ORM. No resto, usamos um ORM com mapeamento automático. Ganhamos tempo e dinheiro para quem está pagando pela aplicação.

Além disso, um DBA sempre é importante no final das iterações do projeto, já que é lá que você vai precisar testar e otimizar a performance da aplicação, além de verificar sua adequação aos diversos padrões do projeto. Então, no final da iteração, você examina o modelo gerado pelo seu ORM junto do DBA e confirma se ele quer mudar alguma coisa, acrescentar índices, mudar colunas, tabelas, etc. Depois de pegar esse feedback o banco é refatorado, junto com o mapeamento, tudo é revisado, e a iteração segue para sua conclusão. O DBA atua confirmando se os desenvolvedores, que em geral não especialistas em banco de dados, não estão cometendo nenhum absurdo. É bom que ele faça isso, já que é ele quem vai conviver com o banco de dados depois.

Depois que paramos para pensar, parece óbvio, não é? No mundo de hoje precisamos de pessoas cada vez mais especializadas. Precisamos de especialistas em algorítmos, de conhecedores de paradigmas de linguagens diferentes, de arquitetos, entre outros tipos de especialistas, e os especialistas de banco de dados claramente não poderiam ficar de fora. E eles vão ficar mais importantes ainda, conforme as tecnologias de armazenagem evoluem. O que pode acontecer é que talvez precisemos de menos DBAs para sustentar as aplicações (algo que tem acontecido), mas eu não arriscaria minha vida nisso.

Mapeamento objeto relacional facilitado

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Mon, 06 Jul 2009 02:43:00 -0700

No .Net Architects Day eu apresentei rapidamente um exemplo iniciante de um sistema de blog durante minha palestra de DDD. Eu havia criado algumas entidades, post e comentário, e tudo funcionava.

Aí resolvi criar outra entidade: usuário. Criei a entidade, criei o controlador as views, liguei tudo, e tudo continuava funcionando. Não criei repositórios específicos, nem mapeamento, nem nada a mais, só a entidade e as partes de interface gráfica. Estava usando NHibernate para resolver o "problema" da relação objeto e dados relacionais. De repente a tabela apareceu lá, os dados salvavam corretamente, o SQL gerado era otimizado e eu estava feliz.

Tudo funcionava. Tudo automático. Muitos me perguntaram como isso foi feito. A resposta é muito simples. Além do NHibernate usei também um pouco de NHibernate Fluente e sua possibilidade de trabalhar automapeamento baseado em convenções. Minha classe de configuração do NHibernate fazia mapeamento de três formas: a básica do NH (com XML), a fluente (do NH fluente), e a automática. O código da classe de autoconfiguração é muito curto, cerca de 60 linhas:

public class Autoconfiguracao
{
    private static ISessionFactory _factory;
    public static ISessionFactory Configurar(bool gerarBanco = true)
    {
        if (_factory != null)
            return _factory;

        var config = Fluently.Configure()
            .Database(
            FluentNHibernate.Cfg.Db.MsSqlConfiguration.MsSql2005
            .ConnectionString(c =>
              c.Is(@"Data Source=.\sqlexpress;Initial Catalog=DNAD09Blog;Integrated Security=True"))
              .ShowSql()
        );

        config.Mappings(m =>
        {
            m.HbmMappings.AddFromAssemblyOf<Autoconfiguracao>();

            m.FluentMappings
                .AddFromAssemblyOf<Autoconfiguracao>();

            m.AutoMappings.Add(
                AutoPersistenceModel.MapEntitiesFromAssemblyOf<Postagem>()
                .WithSetup(s => s.IsBaseType = (type => type == typeof(EntidadeComId)))
                .ConventionDiscovery.Setup(c =>
                {
                    c.Add(PrimaryKey.Name.Is(x => x.EntityType.Name + "_Id"));
                    c.Add(DefaultLazy.AlwaysFalse());
                    //c.Add(ForeignKey.Format((prop, tipo) => prop.Name + "_Id"));
                    c.Add(Table.Is(x => x.EntityType.Name));
                }
                )
                .Where(t =>
                    t.Namespace == "Dnad09.Blog.Dominio.Entidades"
                    && t.IsInterface == false
                    && t.IsAbstract == false
                )
            );
        }
        );

        if (gerarBanco)
        {
            config.ExposeConfiguration(cfg =>
            {
                var schemaExport = new SchemaExport(cfg);
                schemaExport.Create(false, true);
            });
        }
        _factory = config.BuildSessionFactory();
        return _factory;
    }
}

Na parte de configuração, que vai até "config.Mappings" (linhas 17 a 42) todas as chamadas são baseadas em Lambdas. Em seguida se o flag gerar bancos é configurado então o banco é criado, e a factory do NH é retornada. Nela estão todas as configurações do NH, e a criação de sessões do NH, que é o que realmente importa, é muito facilitada. Para trocar o banco de dados para Oracle, por exemplo, bastaria trocar a chamada "Fluently.Configure" (linhas 9 a 15) para trabalhar com este banco de dados.

O mais interessante é a possibilidade de mapear automaticamente apenas a parte que interessa. Podemos mapear algumas classes automaticamente, aceitando as convenções, e em outras utilizar mapeamento fluente ou baseado em XML. Em um cliente recentemente fizemos isso através de atributos: se uma classe tinha um atributo de automapeamento que criamos, então usávamos ela no automapeamento. Senão, teríamos que trabalhar o mapeamento de forma fluente ou com XML.

A produtividade neste tipo de cenário é gigantesca. O foco é o domínio, ou seja, o coração de um software de negócios. A persistência dos dados não é sequer uma preocupação.

Essa abordagem toda é muito legal, mas levantou questões interessantes no .Net Architects Day, que foram inclusive discutidas em outras palestras, como a dada pelo Juliano, que foi mais focada em ORM. Entre elas, a mais polêmica foi sem dúvida a seguinte:

- O DBA morreu?

Minha resposta desta pergunta nesta quarta-feira de manhã. Aguardem.

Comunidade toma tempo

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Fri, 03 Jul 2009 15:38:42 -0700

Vejam o topo da minha caixa de entrada depois de uma tarde sem ver e-mails (e eu nem estou mostrando o resto – dá medo!):

Toma ou não toma?

Downloads e informações da palestra de DDD do .Net Architects Day 2009

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Tue, 30 Jun 2009 22:22:02 -0700

Pessoal, conforme prometido, segue aqui o material da minha palestra sobre DDD do .Net Architects Day 2009.

Apresentação:

Programando com prazer com DDD

View more documents from Giovanni Bassi.

Links:

Domain Language (empresa do Evans)
http://domainlanguage.com/
Grupo do Yahoo sobre DDD (em inglês)
http://groups.yahoo.com/group/domaindrivendesign
Greg Young (MVP - em inglês)
http://codebetter.com/blogs/gregyoung/
Domain Driven Design.org (em inglês)
http://www.domaindrivendesign.org/
Jimmy Nilsson (em inglês)
http://jimmynilsson.com

O download do projeto pode ser feito clicando aqui (incluindo a tão pedida auto configuração do NHibernate fluente).

Em breve eu posto minha visão do evento e as fotos.

Enviesamento político em questões técnicas

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Mon, 29 Jun 2009 20:59:28 -0700

O Lula, como todos sabem, esteve na última edição da Fisl, que aconteceu semana passada. E como sempre, discursou de improviso. O discurso está no site do planalto a disposição de quem quiser ouvi-lo.

Por volta dos 3 minutos e quinze segundos, ele solta esta pérola:

"Agora que o prato está feito, é muito fácil a gente comer. Mas fazer esse prato não foi brincadeira. Eu lembro da primeira reunião que nós tivemos na Granja do torto, porque eu não entendia absolutamente nada da linguagem que esse pessoal discutia, e houve uma tensão imensa entre aqueles que defendiam a adoção no Brasil do Software Livre e aqueles que achavam que nós deveríamos fazer a mesmice de sempre, de ficar no mesmo jeito, comprando e pagando a inteligência dos outros. E graças a Deus permaneceu no nosso país a questão e a decisão do software livre. (urros de alegria na platéia)

Porque nós tínhamos que escolher, ou nós íamos pra cozinha preparar o prato que nós queríamos comer, com esse tempero que nós queríamos colocar e dar um gosto brasileiro na comida, ou nós iríamos comer aquilo que a Microsoft queria vender pra gente. E prevaleceu simplesmente a idéia da liberdade."

Antes de continuar, temos que lembrar que o Lula não é bobo. Ele agracia a platéia com que fala. Se forem economistas fala de um jeito, se for o MST fala o oposto. Sempre fez isso, e não é agora que ia mudar. Além disso, já disse muita besteira de improviso. Essa não é a primeira vez que o freio não segura sua língua.

Diante disso, e apesar disso, acho inadmissível o presidente de um país se colocar de tal forma. Ele foi populista (como sempre), e, em vez de entrar no bom debate, preferiu descer para o nível mais baixo para agradar a horda que o ouvia.

Eu gostaria de saber qual era o "prato" que a Microsoft queria vender ao Lula. Porque eu vendo muitos pratos da Microsoft, e meus clientes estão todos muito satisfeitos. Não entendo porque o governo deve desconsiderar, nas palavras do presidente, qualquer "prato" que seja, simplesmente por questões ideológicas. E vejam bem, são ideológicas, e não morais. Não estamos discutindo aborto, eutanásia ou pena de morte, e sim qual a plataforma mais efetiva para a implantação de um sistema. Isso não se resume a uma receita de comida, como o presidente tentou reduzir o assunto. O debate é técnico e econômico, e não filosófico ou moral.

No começo ele menciona a mesmice de sempre, onde se compra propriedade intelectual. Oras, o próprio governo faz isso o tempo todo. Os remédios que o governo compra também são protegidos por propriedade intelectual, mas as poucas vezes em que investimos na quebra deste tipo de propriedade fomos duramente criticados. O modelo de desenvolvimento de remédios, muito parecido com o de software, precisa de investimentos. É o pagamento por um remédio que financia o desenvolvimento do próximo. Da mesma forma, é o pagamento por um software que financia o desenvolvimento do próximo.

Já senti vergonha deste governo atual muitas vezes. Quando dá guarida a um terrorista italiano, quando não critica a pseudo-democracia venezuelana, quando quase apóia as FARC, quando entrega pedaços da Petrobrás de graça para a Bolívia, quando apóia o regime iraniano, quando manda embaixadores para a Coréia do Norte… Na política nacional a última foi dizer que o Sarney não devia ser tratado como uma pessoa comum, jogando o artigo 5º da constituição no lixo. Não bastava ter criado o mensalão.
E agora mais um episódio.

Lamentável.

O .Net Architects Day 2009 foi um sucesso!

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Sun, 28 Jun 2009 21:33:42 -0700

O .Net Architects Day 2009 foi um sucesso. Já tivemos comentários de Fernanda Sallai, Juliano Oliveira e Fabio Margarito. Como ainda estou organizando fotos e vídeos (além da filmagem oficial, utilizamos minha filmadora pessoal para pegar um pouco das pessoas chegando do backstage, etc), e assim que tiver tudo isso pronto eu posto aqui.

O engraçado é que o Juliano Oliveira e eu tivemos a mesma idéia, de usar o Buddy Christ, do filme Dogma, para ilustrar uma idéia. Eu não tinha reparado que ele ia usar, e ele também não sabia de mim. Nada mais justo do que tirar uma foto para comemorar isso:

Uma com o Leandro Daniel, o Victor Cavalcante e eu:

Mais informações em breve. Fiquem ligados na hashtag #dnad2009 no Twitter, para saber mais do evento e acompanhar as últimas conversas. Tem coisa saindo por lá ainda.

Quero uma console interativa de C# !

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Sun, 28 Jun 2009 20:14:56 -0700

Estava em um cliente semana passada, quando tivemos um problema na formatação de um número. O número não formatava direito quando chamávamos ToString. Tudo parecia certo. Olhamos todo o código umas dez vezes, e não enxergávamos o problema. Mas havia um problema, nós que não estávamos vendo.

A primeira coisa a fazer era verificar a chamada do método ToString, que estava sendo chamado assim:

var texto = numero.ToString("00");

Queríamos uma formatação de um número com dois dígitos, ou seja, "9" virava "09", "2" virava "02", "49" ficava como estava, e por aí vai. Olhe o código acima. Está certo, não é?

Eu pensei "preciso isolar o problema". A melhor maneira seria abrir uma aplicação console simples e digitar o código lá, e imprimir a saída na tela. Aí pensei "Putz, vou ter abrir o outro VS, criar outro projeto, digitar, verificar, etc." Eu sei. É rápido, mas eu estava sem paciência.

Aí me ocorreu algo. Havia uma maneira mais rápida. Saquei meu console interativo de F#, que fica bem facinho no meu RocketDock (quem precisa de um Mac?):

Em menos de um segundos ele abriu. Digitei (clique para ampliar):

Enter. Excelente, agora tenho uma função que recebe um inteiro, e devolve uma string formatada como eu queria.

Basta agora digitar:

f 3;;

E enter! Resultado:

Pronto, resolvido. A premissa estava correta. O erro estava em outro lugar. Podia ter feito assim:

Ainda mais fácil!

Só tem um problema: eu ainda estou aprendendo F#! Não tenho uma super desenvoltura com a linguagem ainda (ainda!). Queria ser capaz de fazer isso com C#, que é algo que o Anders Hejlsberg já mostrou funcionando no PDC passado (vejam aqui o C# Evaluator), mas que não entrou na versão 4 do C#. Seria tão bom… Enquanto isso, não perca tempo, baixe o F# e ganhe o F# interactive. Ou baixe o IronRuby e ganhe o IronRuby Interactive, que faz a mesma coisa.

(Descobrimos depois. A variável numero não era um inteiro, acho que era uma string, ou um object, não me lembro. Foi só converter o tipo e resolvemos o problema.)

Anti-if campaign

unplugged.nospam@nospam.giggio.net (Giovanni Bassi) — Thu, 25 Jun 2009 07:18:00 -0700

Me aliei à campanha "Anti-if":

A idéia é: use polimorfismo, não use If.

Lembro de ter ouvido recentemente que switch ("select case" no VB) é malígno. Devem ser escondido no código, e evitado a todo custo. É verdade. Switch é um if anabolizado!

Última versão do System.Data.OracleClient

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Tue, 23 Jun 2009 20:20:40 -0700

A Microsoft anunciou, em um post do time de ADO, que não vai mais desenvolver seu provider de ADO.Net para Oracle. A última versão é a que sai agora no .Net 4.0, e todas as classes estarão marcadas como obsoletas. No .Net vNext, todo o provider não vai mais existir no BCL.

A Oracle faz o próprio provider dela, o ODP.Net, e ele é gratuito e funciona bem. Em diversos pontos é melhor que o da Microsoft, em outros pior.

A Microsoft não anunciou, e pelo que vejo, nunca vai anunciar, um provider para Entity Framework para o Oracle.

O que isso tudo significa?

Na minha visão isso significa que a Microsoft aprendeu, já quando lançou o EF1, que não deve fazer o trabalho de outras empresas, incluindo aí o da concorrente Oracle. As empresas querem um provider para Oracle para o ADO.Net ou para o EF, que pressionem a Oracle para que entregue um.

Exigir da MS que faça um provider de Oracle para o ADO.Net é como exigir que ela faça um player de Flash para o IE, e não a Adobe, ou uma VM de Java para o Windows, e não a Sun (ou qualquer outra empresa que implemente as especificações do Java). No caso, ela até fazia uma JVM própria, mas parou com isso. Agora foi a vez do provider do Oracle.

O que eu acho disso tudo?

Acho mais do que certo. Primeiro porque não é do interesse de uma empresa ficar fazendo software para suportar aplicações de outras empresas. Segundo porque o time de ADO vai estar livre para investir mais no ADO. Terceiro porque libera a Microsoft de ter que ficar polindo um produto que pode ter bugs, e os bugs muitas vezes nem são seus, ou nem deviam estar sob responsabilidade dela para começar. Quarto porque a Microsoft dá claros sinais de fortalecimento ao ecossistema de parceiros quando faz esse tipo de coisa, já que algum parceiro poderá implementar o provider. E quinto, a Microsoft para de reinventar a roda, assumindo que o que há no mercado é bom o suficiente, e por isso ela não tem que ter a versão dela da tecnologia xyz.

(Esse quinto motivo é meio complicado. Muitas empresas não usam software se não for marcado a ferro com a marca Microsoft. É o caso de componentes de Mock, onde a Microsoft não possui uma alternativa. Muita empresa não usa porque a Microsoft não incentiva oficialmente – descontado o P&P, não fomenta o uso, já que não tem um produto para atender.)

Eu sei que algumas empresas vão sofrer, porque utilizam o provider da Microsoft. Então fica aqui a recomendação: se você usa, pare de usar já. Comece a migrar para o ODP.Net ou para outras alternativas, praticamente todas pagas (o lado bom é que algumas suportam EF). Quem começar a pensar nisso agora tem uns bons anos pela frente, já que a Microsoft ainda nem deve ter entrado em fase de concepção do .Net vNext.

Além do mais, código legado vai continuar funcionando e compilando. O único problema será quando você converter uma solução de .Net 4 ou inferior para o .Net vNext. Nesse caso, você vai ter que substituir o provider. Ainda que o ADO.Net abstraia todo o conceito de objetos concretos, eu pouquíssimas vezes vi alguém usando um DbCommand no lugar de um OracleCommand. Dá-lhe mão de obra para arrumar isso.

Aproveitando o problema que esse tipo de coisa vai gerar, deixo aqui algo para reflexão: se você sofrerá com isso, lembre-se que não teria tido problema se adotasse um ORM (se possível). Quem sabe não é a hora?

.Net Architects agora tem podcasts

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Mon, 22 Jun 2009 20:27:25 -0700

O Daniel Castro está puxando o novíssimo podcast do .Net Architects, um podcast focado em arquitetura de software no mundo de .Net. O primeiro foi feito comigo, e foi sobre a história do .Net Architects. O segundo foi feito com os 5 palestrantes do .Net Architects Day 2009 (que será neste sábado). Está bem legal. São podcasts de uns 40 minutos ou mais cada, com bastante conteúdo.

Ouçam, comentem, critique, dêem sugestões. Vamos melhorar onde for possível.

Webcast sobre computação paralela dado diretamente pelo time do PCP

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Sun, 21 Jun 2009 20:21:19 -0700

A Microsoft americana vai realizar um webcast sobre computação paralela no .Net 4.0 (e Visual Studio 2010). O webcast é em inglês. Esses webcasts costumam ser fechados aos MVPs, mas este foi colocado aberto. Alguns dos membros do time do PCP (Parallel Computing Platform) vão estar presentes. Ou seja, é uma oportunidade única e rara.

Será dia primeiro de julho, às 13 horas.

Quem quiser participar, é só clicar neste link. Vejo vocês lá.

Webcast de C# 4.0 – Parte 2 – Apresentação e recursos

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Fri, 19 Jun 2009 20:40:14 -0700

Conforme prometido no webcast, seguem os recursos que apresentei no webcast neste post.

Apresentação:

C#4 - Parte 2 - COM interop e variância

View more presentations from Giovanni Bassi.

Links:

Meu site de consultoria: http://giovannibassi.com
Site do .Net Architects: http://dotnetarchitects.net
Grupo de discussão online do .Net Architects: http://tinyurl.com/DotNetArch
Evento de arquitetura de software (.Net Architects Day 2009): http://dotnetarchitects.net/dnad2009
Visual Studio 2010 Beta 1: http://tinyurl.com/vs10b1
C# 4 Resources: http://msdn.microsoft.com/en-us/vcsharp/dd819407.aspx
Eric Lippert (Microsoft, time C#): http://blogs.msdn.com/ericlippert/
Eric Lippert falando de variância: http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx
Traduzido pelo Felipe Fujiy: http://blog.fujiy.net/blog/category/Covariancia-e-Contravariancia.aspx
Sam NG (Microsoft) http://blogs.msdn.com/samng/archive/tags/Runtime+binding/default.aspx
Tags de C#4 neste blog: http://unplugged.giggio.net/unplugged/?tag=/c%234
Renato Guimarães (MVP C#): http://renatoguimaraes.spaces.live.com
Edição 60 com artigo meu sobre C#4: http://www.devmedia.com.br/resumo/default.asp?ed=60&site=1

Quer saber o que está rolando no TechEd Brasil 2009?

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Fri, 19 Jun 2009 20:20:27 -0700

O Tech-Ed Brasil vai ser de 25 a 27 de Agosto. Como ficar sabendo do que vai rolar no evento? De várias formas:

No Twitter:
1. Acompanhe a hashtag #TechEdBrasil. De longe a melhor maneira de você pegar feedback de todo mundo que vai ao evento e tem Twitter. É a informação não oficial na mão de todos. Não é a Microsoft, não são os MVPs, somos todos nós. Para ver como esse negócio funciona, é só conferir como o Scrum Gathering Brasil foi movimentado pela hashtag #ScrumGathering, e a Engenharia de Software Conference, na tag #ESConference. (Aviso, o search to Twitter está não está funcionando direito, e as buscas destas hashtags não estão voltando nada por enquanto.) Aproveito para incentivar: se for ao evento twitte tudo o que você vir. Vamos fazer uma cobertura por Twitter!
2. Acompanhe o @TechEdBrasil. Novidades quentinhas antes de qualquer blog post.
3. Acompanhe os responsáveis pelo evento, como o @LucianoPalma e o @RogerioC, o @FabioHara, entre outros. (Se alguém souber mais algum me avisa que eu atualizo a lista)
4. Acompanhe os palestrantes. Eles ainda estão em definição e a Microsoft ainda não divulgou oficialmente, mas já temos confirmados (via Twitter) o @RamonDuraes, o @LutiCM, e eu, @GiovanniBassi. (Se alguém souber mais algum me avisa que eu atualizo a lista)
O Pastel do Caverna é o blog oficial.
O site do evento, claro.

Conhece mais recursos? Me informe, eu atualizo o post.

Webcast de C# 4.0 (parte 2) daqui a pouco

unplugged.nospam@nospam.giggio.net (Giovanni Bassi) — Thu, 18 Jun 2009 04:26:00 -0700

Daqui a pouco tem a segunda parte dos webcasts de C# 4.0 (é agora ao meio dia). Vou falar de variância e interoperabilidade com COM.

Vejo vocês lá.

Quem paga pelo desenvolvimento? (ou entendendo porque o cliente sempre pensa em custo)

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Tue, 16 Jun 2009 20:39:08 -0700

A algum tempo percebi uma dinâmica um tanto perigosa que acontece nas empresas que demandam software via fornecedores internos ou externos. Isso engloba praticamente todo o mercado corporativo, mas deixa de fora empresas que desenvolvem software de prateleira. O que vou escrever a seguir trata deste primeiro tipo de empresa.

Sempre que um departamento precisa de um sistema, ele precisa demandar este sistema para alguém. Seja a demanda repassada para um departamento de TI interno, ou para um terceiro, o foco com razoável frequência costuma ser custo. Quando o departamento é interno estamos falando de rateio baseado em horas internas de outro departamento da empresa, então a discussão é em torno de horas. Quando a demanda vai para fora da empresa a discussão é financeira. Grandes empresas mantém departamentos de compras responsáveis por comprar desde toner para impressora e papel higiênico quanto software, e o tom, principalmente em tempo de crise, é comprar focado em preço. Para se proteger as empresas geralmente apostam em especificações e estimativas bem feitas (algo que não existe), e SLAs. Assumindo que a especificação determina o que vai ser entregue, faz sentido que o critério seja preço. Quer dizer, faria sentido se software não fosse software. Comprar software assim é como comprar serviços de advocacia por preço. Você faria isso se estivesse em uma enrascada? Arriscaria seu pescoço? E porque então arriscamos o dinheiro das empresas?

Invariavelmente os fornecedores, sejam eles internos ou externos, vão ter que baixar o custo para atender o cliente, que quer uma Mercedez pelo preço de um Fusca. Frequentemente o cliente simplifica o escopo ao máximo, a fim também de baixar o preço, e remove itens fundamentais a qualquer software. De cara morrem coisas "inúteis" como log de erros, por exemplo. Design gráfico também costuma nem entrar no projeto. Outros itens, de tanta falta de demanda, às vezes nem são oferecidos pelos fornecedores. Coisas "inúteis" como análise estática de código, integração contínua, e claro, uma análise arquitetural e/ou um arquiteto acompanhando o projeto. Afinal, essas coisas "inúteis" só acrescentam custo e não valor (atenção para a ironia). Então o cliente fala que não vai pagar por isso.

Porque isso acontece? Pois é, foi isso que eu descobri. Talvez vocês já saibam, mas para mim foi algo que de certa forma estava na minha cara, mas eu nunca tinha parado para ver.

A questão é simples: quem paga pelo software e quem paga pela manutenção? É muito frequente que o cliente final pague pelo desenvolvimento do projeto, mas não pelas pequenas manutenções subsequentes. O dinheiro sai do seu centro de custo somente no nascimento do projeto. Quem paga as manutenções geralmente é TI, que mantém uma equipe de suporte, alocada no seu centro de custo, debaixo do seu budget.

Esse fato leva o cliente a pedir o software mais barato possível. Os problemas e necessidades que vierem depois são resolvidos "de graça", ao custo do departamento de TI. E como o software foi feito de qualquer jeito, a manutenção é muito cara, o que leva a equipe de suporte a inchar cada vez mais, ou entregar cada vez menos valor. Quem disse que não existe almoço grátis?

Não é a toa que os CIOs são tão criticados por não entregar valor. Cerca de 80% do custo de TI vão para manutenção, e devido a essa dinâmica, uma manutenção cara que se originou nos próprios incentivos dados por TI.

Como eu disse no começo, essa é uma dinâmica perigosa, já que os custos do projeto são muito maiores do que o planejado, e o software não é feito para durar, mas para sair de qualquer jeito. E o trabalho do arquiteto é justamente fazer software para durar.

Gostaria de saber se isso é uma visão particular das minhas experiências ou se vocês confirmam esta visão. Comentários são muito bem vindos.

C#: Resposta a "Qual Overload é chamado"

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Mon, 08 Jun 2009 05:50:00 -0700

Respondendo então à questão de qual overload é utilizado que fiz aqui na quinta-feira passada. Se você não viu a questão, leia lá antes de ler aqui para não perder a graça.

Revendo as funções:

FazAlgo(object arg) {} //overload 1
FazAlgo(params object[] args) {} //overload 2

Minha chamada é assim:

string[] parametros = {"Giovanni", "Bassi"};
FazAlgo(parametros);

Qual overload é chamado? Revendo as opções:

O primeiro é chamado, passando um array de strings como um objeto.
O segundo é chamado, passando um array de strings como se fosse um array de objetos.
O segundo é chamado, passando um array de strings como um objeto do array args, como se implicitamente fizesse "FazAlgo(new object[] {parametros})"

Adianto que a opção 3, apesar de tecnicamente ser possível, não é a correta porque há duas opções mais diretas. Nesta terceira opção o compilador tem que expandir o objeto de object para object[], e, como nas outras duas opção não há mudança alguma, a terceira opção é descartada.

Graças à covariância entre arrays, podemos converter implicitamente de string[] para object[]. Isso coloca o overload 2 como mais específico que o overload 1, e portanto ele é o escolhido. Um array de strings pode até ser um object, mas ele é mais especificamente um array de objetos. O tipo mais específico sempre ganha.

Engraçado que normalmente quando essa questão é levantada a maioria das pessoas dizem que a opção 1 é a correta. Mas não me parece a mais óbvia. Talvez as pessoas não entendam a questão da variância.

Estimativa == cálculo aproximado

unplugged.nospam@nospam.giggio.net (Giovanni Bassi) — Fri, 05 Jun 2009 05:56:00 -0700

"You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one's impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)
Does this sound like what you are asked for when you're asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better."

Primeiros parágrafos do livro "Software Estimation: Demystifying the Black Art", da Microsoft Press, que você compra aqui na Amazon por meros 50 reais.

É tão importante deixar claro que uma estimativa não é um contrato, não é um compromisso, que o cara abre o livro dizendo isso.

Quantas pessoas e empresas entendem isso?

Acho que esse parágrafo, por si só, resolveria 90% dos problemas comerciais decorrentes de mudança de escopo e desvio de prazo presentes no mercado hoje.

Estimativa == Cálculo aproximado.

Combinado?

Webcast de C# 4.0 – Parte 1 – Apresentação e recursos

unplugged.nospam@nospam.giggio.net (giovanni bassi) — Thu, 04 Jun 2009 09:48:00 -0700

Conforme prometido no webcast, seguem os recursos que apresentei no webcast neste post.

Apresentação:

C#4 - Parte 1 - Dinamismo E Argumentos opcionais e nomeados

View more presentations from Giovanni Bassi.

Links:

Meu site de consultoria: http://giovannibassi.com
Site do .Net Architects: http://dotnetarchitects.net
Grupo de discussão online do .Net Architects: http://tinyurl.com/DotNetArch
Evento de arquitetura de software (.Net Architects Day 2009): http://dotnetarchitects.net/dnad2009
Visual Studio 2010 Beta 1: http://tinyurl.com/vs10b1
C# 4 Resources: http://msdn.microsoft.com/en-us/vcsharp/dd819407.aspx
Eric Lippert (Microsoft, time C#): http://blogs.msdn.com/ericlippert/
Sam NG (Microsoft) http://blogs.msdn.com/samng/archive/tags/Runtime+binding/default.aspx
Tags de C#4 neste blog: http://unplugged.giggio.net/unplugged/?tag=/c%234
Renato Guimarães (MVP C#): http://renatoguimaraes.spaces.live.com
Edição 60 com artigo meu sobre C#4: http://www.devmedia.com.br/resumo/default.asp?ed=60&site=1