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?

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

Apresentação:

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.

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. 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.

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.)

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!

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?

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.

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á.

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

Apresentação:

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

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:

1. 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)
2. O Pastel do Caverna é o blog oficial.
3. O site do evento, claro.

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

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á.

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.

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:

1. O primeiro é chamado, passando um array de strings como um objeto.
2. O segundo é chamado, passando um array de strings como se fosse um array de objetos.
3. 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.

"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?