Leandro Daniel

Ética e desenvolvimento de software

Tue, 07 Feb 2012 17:32:00 -0200

No último episódio do Void Podcast, tocamos no assunto “ética no desenvolvimento de software” (em especial por parte de consultorias e fornecedores de produtos e serviços de software). Relacionamos a falta de ética como um dos grandes óbices para a reversão de um quadro de brownfield para greenfield.

Uma pequenina discussão foi iniciada nos comentários do episódio, onde uma significativo depoimento foi colocado pelo Daniel Yokoyama. Embora quase que a totalidade das pessoas com quem converso a respeito sejam descrentes com relação a ética aplicada, gostaria de discorrer sucintamente sobre o tema.

Algumas (pouquíssimas, mesmo!) palavras sobre ética e a história recente do Brasil

Fui criado no longínquo século XX onde, por incrível que pareça, as empresas se preocupavam de fato em satisfazer seus clientes. Também peguei a época em que disciplinas como OSPB e EMC eram obrigatórias em qualquer escola.

Puxa, talvez você tenha pouca idade e desconheça essas siglas. Vamos lá:

OSPB (Organização Social e Política Brasileira) foi uma disciplina que, de acordo com o Decreto Lei 869/68, tornou-se obrigatória no currículo escolar brasileiro a partir de 1969, juntamente com a disciplina de Educação Moral e Cívica (EMC). Ambas foram adotadas em substituição às matérias de Filosofia e Sociologia e ficaram caracterizadas pela transmissão da ideologia do regime autoritário ao exaltar o nacionalismo e o civismo dos alunos e privilegiar o ensino de informações factuais em detrimento da reflexão e da análise. O contexto da época incluía a decretação do AI5, desde 1968, e o início dos ‘anos de chumbo’ - a fase mais repressiva do regime militar cujo ‘slogan’ mais conhecido era ‘Brasil, ame-o ou deixe-o’.

Dessa forma, as duas matérias foram condenadas pelos Parâmetros Curriculares Nacionais (PCN), estabelecidos pela Lei de Diretrizes e Bases da Educação (LDB) de 1996, por terem sido impregnadas de um ‘caráter negativo de doutrinação’.

Julgue esse período como quiser, pois não é foco deste post ponderar sobre o tema. O que gostaria de ressaltar é que dentre todo o conteúdo passado nessas matérias o que mais ficou marcado pra mim foi justamente o que tratava a ética. Fora a primeira ocasião em minha vida onde apresentaram tal assunto.

Tenho minhas dúvidas se, no “mundo politicamente correto de hoje”, algum conteúdo sobre ética é passado nas escolas. E principalmente, esse conteúdo é passado a tempo? Ou seja, estamos contribuindo de forma adequada para a formação do caráter de nossas crianças?

Se a pergunta “Qual a conduta correta para um indivíduo em sociedade?” é muito complexa, talvez você consiga me responder...

... Qual a conduta correta para profissionais de TI?

O desenho abaixo ilustra três facetas da ética no dia a dia de um profissional de TI.

Mesmo sendo a ética alvo de longas discussões, gostaria de chamar sua atenção para uma definição de Código de Ética em Engenharia de Software resultante dos esforços de uma equipe de trabalho multinacional liderada pela IEEE/ACM.

Existe uma versão longa deste código, contudo, acho suficiente destacar o seguinte resumo:

Público. Engenheiros de Software devem atuar consistentemente com os interesses públicos.

Clientes e empregados. Engenheiros de Software devem atuar de modo a atender os melhores interesses dos seus clientes e empregados, consistentemente com os interesses públicos.

Produto. Engenheiros de Software devem assegurar que seus produtos e modificações relacionadas atendam os melhores padrões profissionais possíveis.

Julgamento. Engenheiros de Software devem manter a integridade e independência nos seus julgamentos profissionais.

Administração. Administradores e líderes de Engenharia de Software devem aderir e promover uma abordagem ética ao gerenciamento do desenvolvimento e manutenção de software.

Profissão. Engenheiros de Software devem desenvolver a integridade e reputação da profissão consistentemente com os interesses do público.

Coleguismo. Engenheiros de Software devem ser justos e dispostos a auxiliar seus colegas.

Identidade. Engenheiros de Software devem participar do aprendizado de suas vidas valorizando a prática da sua profissão e devem promover uma abordagem ética à prática da profissão.

Perceba que, mesmo com a versão resumida do código, após um exercício individual de reflexão, podemos constatar se estamos inseridos em um ambiente ético (ou se estamos chafurdados no brownfield plus, como foi dito no episódio do Void).

Um ponto de vista sobre a ética empresarial

Como mencionei anteriormente, o assunto é extenso, mas acho oportuno trazer aqui um ponto de vista colocado pelo advogado Joaquim Manhães Moreira, autor do livro “Ética na gestão empresarial”:

O único lucro moralmente aceitável é aquele obtido com ética. A moral impõe que a empresa aja com ética em todos os seus relacionamentos, com clientes, fornecedores, competidores e seu mercado, empregados, governo e público em geral.

Ainda dentro de seu pensamento:

Uma empresa ética incorre em custos menores do que uma antiética. A empresa ética não faz pagamentos irregulares ou imorais, como subornos, compensações indevidas e outros.

Por não efetuar subornos, ela consegue colocar em prática uma avaliação de desempenho de suas áreas operacionais, de forma mais precisa do que a empresa antiética. Um exemplo da dificuldade de avaliar o desempenho quando não se age com ética está na possibilidade de aceitação de desculpas de que uma venda não pôde ser realizada, porque o concorrente ofereceu um suborno maior ao cliente.

O lucro gerado para os acionistas não fica sujeito a contingências futuras, como, por exemplo, condenações por procedimentos indevidos.

Ao aderir a um código de ética consistente e claro, praticando uma conduta ética, a empresa empresta legitimidade aos seus negócios, envolvendo todos os seus empregados e administradores neste clima de lealdade e dedicação.

A empresa ética tem o respeito de seus parceiros, fornecedores e clientes, elevando a sua marca e facilitando sua expansão.

A empresa deve ser responsável por ajudar a melhorar continuamente a sociedade da qual obtém lucro, não somente no aspecto material, mas também abstrato, adotando práticas de ética.

A conclusão é sua :)

Fique à vontade para comentar.

Hey, que tal pensar além do Try... Catch... Finally? (parte 4)

Thu, 02 Feb 2012 14:51:00 -0200

E aqui estou para fechar esta série de posts. Vimos no primeiro a diferença entre erro e exceção, e no segundo tivemos um vislumbre da amplitude do assunto "Exception Handling". No último post tomamos contatos com jargões comuns em tratamento de exceções além de conhecer alguns anti-patterns.

Pensando além do Try... Catch... Finally. Finnally!

Se você acompanhou todos os demais posts da série, espero ter conseguido lhe dar embasamento suficiente para que as seguintes assertivas sejam válidas:

Assertiva 1
Tratamento de exceções pode ser tratado como um item de cross-cutting concerns, e como tal, pode tirar proveito de frameworks e libraries existentes no mercado (muitas delas "free").

Dica
Considere não reinventar a roda!

Assertiva 2
Dentro de uma empresa, a manipulação de exceções pode ser expressa em termos de políticas. Considere, portanto, envolvimento do usuário, administradores e demais interessados na solução para discutir tais políticas.

Dica
Pense sempre em flexibidade para configuração das suas políticas de manipulação de exceção!

Assertiva 3
Defina um plano para pensar na manipulação de exceções durante a fase de design de uma solução. O resultado deve ser uma estratégia consistente e comunicada para todos os envolvidos. Em alguns casos, exige alguma definição de processo entre departamentos (por exemplo, "em caso de exceção no sistema de câmbio a equipe responsável deve ser notificada, os administradores devem receber um log").

Dica
Análise de exceções podem trazer grandes oportunidades de avaliação e correção do processo como um todo!

Assertiva 4
Manipular exceções é um excercício de altruísmo.

Dica
Ajude a equipe de manutenção com o rastreamento da exceção e suas causas. Seja objetivo e direto!

Assertiva 5
Exceções fornecem os meios necessários para separar os detalhes sobre o que fazer quando algo fora do comum acontece a partir da lógica principal de um programa. Na programação tradicional, a detecção de erros, relatórios e manipulação conduzem frequentemente a código espaguete confuso.

Dica
Trabalhe de forma organizada e mantenha seu código limpo.

Alguns exemplos de Exception Patterns

Provavelmente, os três design patterns mais conhecidos para tratamento de exceções são:

Exception Shielding: Este padrão garante que o aplicativo não vazará informações confidenciais (nomes de servidores, caminhos físicos dos servidores etc.).

Exception Logging: Este padrão ajuda a diagnosticar e solucionar problemas de exceções, auditoria de ações do usuário, rastreamento de atividades maliciosas e outras questões de segurança.

Exception Translation: Este padrão descreve como quebrar exceções dentro de outras exceções específicas dentro de uma camada (inner exception) para garantir que elas realmente reflitam ações pertinentes dentro do contexto.

Perceba que todos os patters de manipulação de exceção apresentados se relacionam com as técnicas de tratamento de exceções apresentadas no post anterior. Por exemplo, para não deixarmos que informações confidenciais vazem usamos Replace Handler. Quebrar exceções dentro de outras exceções específicas pode ser feito via com um Wrap Handler. Notificar os usuários ou administradores do sistema pode ser conseguido com Propagate Exception. Além disse, devemos combinar essas técnicas sempre que necessário.

Estratégia de tratamento de exceções

O diagrama abaixo ilustra uma possível estratégia de tratamento de exceções entre as camadas de uma dada solução. Para chegar numa estratégia como essa, cada building block de sua arquitetura deve ser avaliado com critério.

Embora os exemplos desta série de posts ilustrassem situações corriqueiras em linguagens de programação como Java e C#, considere avaliar práticas de manipulação de exceção em banco de dados, processos de ETL, componentes de mensageria, SOA e qualquer outra tecnologia que forneça suporte para isso.

Conclusão

Todas as práticas envolvidas na manipulação de exceções oferecem como primeiro objetivo a possibilidade de uma aplicação continuar sua execução sem gerar maiores impactos. Contudo, um ganho excepcional pode ser oportunizado na auditoria das falhas ocorridas, ou até mesmo com um suporte efetivo para análise pela equipe de manutenção. Nunca subestime esse potencial.

Tratar exceções é muito mais que codificar um simples Try... Catch... Finally, ao contrário, é uma atividade que requer planejamento, análise (design), implementação e estudo constante.

Hey, que tal pensar além do Try... Catch... Finally? (parte 3)

Wed, 01 Feb 2012 15:14:00 -0200

Muito bem! Vimos no primeiro post da série a diferença entre erro e exceção, e no último tivemos um vislumbre da amplitude do assunto "Exception Handling". Estamos preparados para avançar um pouco mais nessa jornada e tomar contato com os...

... Jargões comuns em tratamento de exceções

Quando temos que manipular exceções, devemos desenhar uma estratégia robusta e bem-planejada. Isso é vital durante a fase de concepção, e ajudará no momento de implementação a evitar riscos. Apenas para citar algumas situações: exposição de mensagens de erro que contenham informações sensíveis, ou sair da aplicação em um estado inconsistente gerando erros nos dados quando um exceção ocorre.

Veja a seguir alguns jargões utilizados quando falamos em manipulação de exceções.

Wrap handler

A técnica de encapsular ou cobrir (wrap) uma exceção com outra pode trazer a capacidade de enriquecer com mais informações o rastreamento de pilha (stack trace). Por outro lado, o stack trace pode ficar demasiadamente longo (e irritante). Na maioria das vezes apenas o rastreamento de pilha raiz é interessante.

Replace handler

Consiste em substituir uma exceção por outra. A princípio parece uma péssima ideia, mas pode fazer sentido em determinados contextos onde informações sensíveis precisam ser mascaradas e substituídas por mensagens customizadas.

Logging handler

Um manipulador de logging é capaz de formatar a exceção (mensagem, stack trace e demais informações) e gerar um registro que pode ser publicado em diversos meios (Event Viewer, banco de dados, e-mail, arquivo texto, entre outros) para posterior auditoria.

Fault Contract exception handler

Este tipo de manipulador de exceção é utilizado para validar os limites de um contrato de uso de um serviço, classe, entidade, etc.

Interception handler

Consiste em interceptar exceções utilizando técnicas de AOP. Existem alguns frameworks (Java e C#) capazes de realizar interceptação em runtime e adicionar comportamento comum.

Multiple catch blocks

Muitas linguagens de programação suportam múltiplos blocos de catch. Segundo o Princípio de Responsabilidade Única (ou SRP, oriundo do SOLID), nunca deve haver mais de um motivo para uma classe mudar. A seguir temos dois exemplos de multiple catch blocks, onde podemos observar no segundo uma indicação muito forte de que o método pode estar quebrando o SRP.

Propagate exception

Embora toda exceção deva ser tratada, nem sempre é possível tratar uma exceção no mesmo escopo do método cuja invocação gerou a exceção. Nessas situações, devemos propagar a exceção para um nível acima na pilha de chamadas. Também é conhecido como rethrow de uma exceção.

Fault Tolerance Engineering

Técnicas para construção de sistemas com tolerância a falhas, bem como seu gerenciamento durante o ciclo de vida de uma aplicação têm sido alvo de debates há muitas décadas, sendo tema de diversos livros e pesquisas acadêmicas. Por estar relacionado com o tratamento e manipulação de exceções (seja em fase de design ou implementação), requer especial atenção quando tratamos de situações que exigem alta disponibilidade ou confiabilidade. Geralmente sistemas com essa características são baseados em redundância, quase sempre exigindo componentes especiais e/ou algoritmos específicos.

Obviamente, existem outros termos utilizados. Mas agora que vimos os mais comuns, para finalizar por hoje, vamos (tentar) nos divertir com...

... O horror dos anti-patterns de tratamento de exceções

Veja alguns exemplos de anti-patterns retirados do java.net (com algumas modificações que tomei a liberdade de fazer):

-> Log and Throw: escolha uma das duas coisas, nunca as duas!

-> Catch Exception: capturar exceções do tipo Exception (tanto em Java quanto em C#, por exemplo) quase sempre denota que um plano de tratamento de exceções não foi pensado com o devido cuidado. Tratar a exceção mais genérica pode indicar pouco conhecimento das funções de suas classes (ou no pior caso, demonstrar um design ruim).

-> Throwing the Kitchen Sink: Lançar várias exceções verificadas do seu método em geral é algo bom, contanto que exista de fato possíveis cursos de ação que o chamador pode querer tomar dependendo de qual exceção foi acionada.

-> Catching Exception: como vimos no post anterior, cada vez que uma catching exception é codificada um panda morre em algum lugar do planeta.

-> Destructive Wrapping: muito cuidado ao fazer o wrap de uma exceção, dê significado e acrescente informações de valor indiscutível.

-> Log and Return Null: quase sempre uma péssima ideia.

-> Catch and Ignore: o On Error Go to Next modermo!

-> Throw from Within Finally: o bloco Finally existe para ser executado, certo? nada mais justo que deixá-lo em paz.

-> Multi-Line Log Messages: alguns arquivos de log pode atingir tamanhos absurdos (para não dizer ridículos), portanto, cuidado!

Hey, que tal pensar além do Try... Catch... Finally? (parte 2)

Tue, 31 Jan 2012 12:40:00 -0200

Vimos no último post desta série a diferença entre erro e exceção. Enquanto o primeiro é irrecuperável, o outro dá margem para tomarmos uma ou mais ações a fim de permitir que a aplicação continue em execução.

Entendendo isso, o termo tratamento de exceções ganha um sentido imediato. Tratar ou manipular uma exceção requer muito critério e atenção ao contexto. Afinal, existe decisão puramente técnica?

Essa não! Catching Exception de novo!

Quem já trabalhou dando manutenção e suporte a sistemas em produção entende o valor do tempo. Poucos minutos bastam para desgastar (às vezes de forma irrecuperável) a imagem de um produto em caso de atraso na correção de um erro. Grande parte das boas práticas de desenvolvimento visam justamente retornar valor de forma eficaz durante a manutenção. O custo total de propriedade de um software deve levar em consideração o seu custo de manutenção.

Isso posto, podemos aferir que utilizar uma estrutura de “tratamento de exceções” (dedos no ar fazendo pequenos movimentos para realçar as aspas aqui) como vemos a seguir não traz qualquer benefício.

Na maioria dos casos essas exceções – que foram literalmente “engolidas” – confundem os desenvolvedores com um comportamento errático. Se você não sabe como tratar uma exceção, simplesmente não a capture. Simples assim. Quer logar? Tudo bem, capture e dê um rethrow, pelo menos é mais honesto com quem der manutenção depois.

Melhorias e evoluções no tratamento de exceções

O uso de exceções é um poderoso mecanismo que separa o código funcional do tratamento de erros. Contudo, mesmo que o uso de exceções simplifique a detecção de falhas (trazendo certa elegância para o código de manipulação de exceções) esse mesmo arranjo pode levar à negligência na recuperação de problemas. Esse tipo de falha pode representar: perda de dinheiro; comprometimento da imagem de uma empresa; perda de credibilidade por parte do cliente; outros problemas imensuráveis (ridículos ou, em alguns casos, catastróficos).

As linguagens de programação modernas, como C# e Java (entre tantas outras), têm fornecido cada vez mais suporte a manipulação explícita de exceções. Quando uma restrição semântica é violada ou alguma condição de erro excepcional ocorre, uma exceção é lançada. Uma exceção pode ser implicitamente propagada até o método original de chamada.

No exemplo a seguir vemos uma das muitas possibilidades de tratar exceções em Java.

Cuidado, se você é suscetível a flames ou trata desenvolvimento de software como religião, o texto a seguir pode causar incômodos. Nesse caso, pule para o último tópico do post.

Em Java existem três tipos de classes que podem ser “lançadas” durante o tratamento de exceções: checked exceptions (exceções verificadas), unchecked exceptions (exceções não verificadas), e erros.

Checked exceptions are exceptions that must be declared in the throws clause of a method. They extend Exception and are intended to be an "in your face" type of exceptions. A checked exception indicates an expected problem that can occur during normal system operation. Some examples are problems communicating with external systems, and problems with user input. Note that, depending on your code's intended function, "user input" may refer to a user interface, or it may refer to the parameters that another developer passes to your API. Often, the correct response to a checked exception is to try again later, or to prompt the user to modify his input.

Unchecked exceptions are exceptions that do not need to be declared in a throws clause. They extend RuntimeException. An unchecked exception indicates an unexpected problem that is probably due to a bug in the code. The most common example is a NullPointerException. There are many core exceptions in the JDK that are checked exceptions but really shouldn't be, such as IllegalAccessException and NoSuchMethodException. An unchecked exception probably shouldn't be retried, and the correct response is usually to do nothing, and let it bubble up out of your method and through the execution stack. This is why it doesn't need to be declared in a throws clause. Eventually, at a high level of execution, the exception should probably be logged (see below).

Errors are serious problems that are almost certainly not recoverable. Some examples are OutOfMemoryError, LinkageError, and StackOverflowError.

Começamos a entrar no campo das elucubrações sobre tratamento de exceções e erros. Só para citar um exemplo, veja esse post sobre o tema e esse outro aqui.

Pesquisando a respeito você encontrará muitos debates sobre o assunto. Se sua pesquisa se estender a outras linguagens, você chegará a conclusão que existe um sem fim de possibilidades, recomendações, padrões e estratégias para desenhar e arquitetar o tratamento de exceções.

Então devo desistir do assunto?

Claro que não! Ninguém é melhor do que você para criticar e decidir o que faz sentido sobre um determinado assunto. O que pode ser considerado uma vantagem para um pode não ser verdade para outro. Tudo depende do contexto, cenário e atores envolvidos. Nos próximos posts apresentarei várias considerações e técnicas.

Hey, que tal pensar além do Try... Catch... Finally? (parte 1)

Mon, 30 Jan 2012 16:06:00 -0200

Não adianta. Toda vez que preciso explicar para algum desenvolvedor o que significa de fato “tratamento de exceções” fico constrangido. Na verdade, é um constrangimento alheio, já que quase sempre a pessoa se mostra surpresa ao final de uma conversa desse tipo.

Até compreendo desenvolvedores menos experientes ficarem melindrados na hora de tratar exceções. Mas considero um absurdo alguém com anos de experiência (às vezes se auto-nomeando um "desenvolvedor pleno/sênior" ou "arquiteto de software/solução/sistemas/etc.") considerar que um Try...Catch...Finally é suficiente para liquidar o assunto. E olha que prefiro nem mencionar o que penso sobre os "try {} Catch(Exception ex) {}" da vida (sem qualquer código dentro do catch).

Frente a essa recorrente situação de ter que tocar no assunto "tratamento de exceções", resolvi escrever alguns posts. Não quero simplesmente despejar um monte de conceitos e padrões. Nem mesmo ser o algoz da ingenuidade (maléfica) de desenvolvedores e responsáveis por design e implementação que desconhecem ou nunca buscaram mais conhecimento a respeito. Acho mais interessante estimular um pensamento crítico sobre o tema.

Acho melhor começar falando... Não do início da história das linguagens de programação... Mas do meu início como desenvolvedor profissional aqui em São Paulo.

À honra do “On Error Resume Next”!

Minhas primeiras experiências profissionais em São Paulo foram com WDNA e a velha trinca: ASP, Visual Basic 6 e COM+. Não posso dizer que foi de todo ruim, mas boa parte do que aprendi na época com os desenvolvedores mais experientes serviram para fundamentar uma inquietação: codificar TEM que ser mais do que isso!

Para manter o foco no assunto deste post, vamos analisar as opções que tínhamos na época para tratar erros (ou exceções? hum, boa questão, não?). Veja como uma estrutura típica de tratamento de erros em Visual Basic se parecia:

Perceba que interessante, o Visual Basic antigo considerava qualquer problema em runtime como erro, não havendo portanto uma abordagem para tratamento de exceções. Era possível utilizar a palavra reservada Raise para lançar um erro de runtime para a chamada original. Outras três possibilidades estavam à disposição dos desenvolvedores.

O On Error GoTo dava a opção de usar uma determinada rotina em caso de ocorrência de erro de runtime. A execução do programa "pulava" para um trecho de código assinalado com um label pré-definido. Já o On Error GoTo 0 desabilitava qualquer manipulador de erro escrito dentro do procedimento ou função corrente. Mas todos os desenvolvedores de Visual Basic (não o .NET) eram unânimes em concordar que o mais transudo, o que realmente colocava um desenvolvedor no hall dos "caras fodões e corajosos" era o tal do On Error Resume Next.

O On Error Resume Next tinha a habilidade de especificar que, quando um erro de runtime ocorresse, a execução iria para a instrução imediatamente após a instrução onde o erro ocorreu. Além disso, o programa seguia sua execução normalmente, como se nada tivesse acontecido. What?!?

Não saberia descrever em poucas palavras a minha "alegria" quando, ao final de uma tarde inteira debugando um erro numa página de ASP clássico (ou ASP 3.0, como queira), encontrava um On Error Resume Next oculto em um arquivo de include. Ah, que emoção! E não vou ser hipócrita, já "resolvi" alguns erros de produção usando um simples On Error Resume Next (e o gerente ainda fazia questão de enaltecer seu sagaz recurso para o cliente enquanto eu tentava, discretamente, deixar claro que "não era para tanto").

Na época, considerando todas as características do Visual Basic (linguagem fracamente tipada, interpretada, dinâmica, orientada a eventos, entre outras peculiaridades), a forma como comumente os desenvolvedores tratavam erros (ou exceções) era aceita pelo statu quo. Sempre fiquei incomodado com isso, afinal, já havia programado em Delphi anteriormente, experimentando estruturas de tratamento de exceções como a seguinte:

Notei que frequentemente me pegava fazendo a mesma pergunta...

Isso é uma exceção ou erro?

Ainda que você não concorde com as definições a seguir, é bastante plausível considerar que temos ao menos duas causas distintas, cada uma com seus respectivos desdobramentos, que afetam a execução do "caminho feliz" de um programa. São elas: erro ou exceção, sendo que:

Erro é qualquer desvio em relação ao comportamento esperado do sistema ou do programa, que interrompe o funcionamento do mesmo;
Exceção é qualquer erro ou problema que pode ser manipulado/tratado de forma a permitir que o sistema ou programa continue sua execução.

Perceba que, conceitualmente, um erro significa que algo deu muito errado com seu programa, e isso é um motivo suficientemente bom para ele abortar sua execução. Enquanto que uma exceção é resultado de uma situação inusitada, mas que você antecipou como uma possibilidade, e portanto codificou algo a respeito. Nessa linha de raciocínio, uma divisão por zero é um erro, mas a tentativa de ler um arquivo e descobrir que ele não existe é uma exceção.

Sintetizando, notamos que: uma exceção é recuperável, mas um erro não. Essa percepção serve como fechamento para hoje.

Void Podcast: episódios #013 ao #016 disponíveis!

Mon, 23 Jan 2012 13:15:00 -0200

Void Podcast #013 – Dorg(m)as
Dessa vez, um assunto polêmico, discutido sem polêmicas, sobre os fanatismos nossos de cada dia. O (receptivo [gerente]) Vinicius Quaiato (@vquaiato) prega a paz mundial e aceitação de todas as tecnologias – independente de credo, raça ou religião (ou seria dogmas?!). Enquanto isso, o (cantor acusativo) Elemar Jr (@elemarjr) fala sobre complexos estranhos com nomes esquisitos (Você é pato? Você é Gabriela?) e o (ex-barbudo, com cavanhaque [latin-lover wanna be]) Leandro Daniel (@leandronet) mostra sua predileção por empregos extremos (de planos funerários a “grandes instituições financeiras”).

Void Podcast #014 – Elucubrações, percepções e desatinos
Dessa vez, uma discussão acalorada (sem pretensões, preocupações, consequências ou conclusões) sobre “os rumos” do desenvolvimento de software. Na defesa (ou seria no ataque) dos CRUD nossos de cada dia, temos: (arrobinha) Vinícius Quaiato (@vquaiato) e seus argumentos automotivos; Leandro Daniel (@leandronet) e seu sapiente cavanhaque arquitetônico (latin lover [really?!]); e o orquestrador caótico Elemar Júnior (@elemarjr). Completando o time (de peso?!) de heróis nessa edição, temos o Master of Coders (ou seria puppets?!) Juan Lopes (@juanplopes) em uma participação mais que especial.

Void Podcast #015 – Adeus Void velho, feliz Refactoring novo!
Queríamos falar sobre o fim-do-mundo, sobre o espírito do natal, sobre bons velhinhos, loucuras, orgias e, claro, sobre a paz mundial. Mas, no fim, falamos sobre aquilo que achamos que entendemos: código. Com a ausência percebida (por que será?!) do (arrobinha) Vinícius Quaiato (@vquaiato) e seus argumentos automotivos; temos o “sábio barbudo (com cavanhaque) das montanhas” Leandro Daniel (@leandronet) e o esperançoso/resharper-wanna-use Elemar Júnior (@elemarjr) em um debate frenético sobre o refactoring nosso de cada dia. Em um quase “essa é minha vida”, falamos cruamente sobre o que fazemos e como fazemos. Um void simples, mas honesto. Pobre, mas limpinho. Não é uma mensagem “bonitinha” de natal. Nem mesmo uma reflexão sobre o novo ano (afinal, o mundo vai acabar).

Void Podcast #016 – Void de gordo
Dessa vez, vamos confessar (todas) as gordices nossas de cada dia. Para isso, contamos com o apoio de um grande (!?) especialista: Dudu Sales (@papodegordo) do famoso e premiado “Papo de Gordo” que honra-nos com sua notória (!?) presença.

Nesta edição, encontramos um comedido, respeitoso e (acreditem!) trollado Vinícius Quaiato (@vquaiato), tentando entender o universo gordo. Já que, sendo o rostinho bonito que atraí ouvintes ao Void, não teve tempo (ou garfo) para viver a vida como ela é nesse “mundo redondo” (aliás, fartamente representado [por enquanto] pelos nossos outros dois heróis).

Ouça e entenda alguns dos complexos do (agora) diabético, (ainda) gordo, pé-grande, (segundo alguns) careca, sem internet e, conforme o convidado, fudido Elemar Jr (@elemarjr) sobre os (des)confortos que apenas um “corpinho” pode proporcionar em aviões, lojas de calçado e outros ambientes com espelhos. Com a edição homérica (digna de lenda) do artista revoltado (sim! agora ele fala palavrões) Leandro Daniel (@leandronet), descanse um pouco e relaxe ouvindo um Void despretensiosamente hilário.

É possível ouvir o podcast diretamente do post (usando o player), além disso, o Void Podcast agora está disponível também no iTunes.

Não deixe de comentar suas opiniões.

Existe decisão arquitetural puramente técnica?

Mon, 09 Jan 2012 15:19:00 -0200

Um arquiteto nunca deve decidir sobre uma arquitetura de forma arbitrária ou mesmo impensada. Todas as alternativas devem ser consideradas, fracionando o sistema (solução) em elementos e relações que possibilitarão o atendimento aos atributos de qualidade.

Alexander Wolf e Dewayne Perry definiram em um artigo intitulado “Foundations for the Study of Software Architecture” o seguinte modelo:

Arquitetura = { Elementos, Organização, Decisões }

De acordo com essa definição, a arquitetura de software é um conjunto de elementos arquiteturais que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições. São destacados três tipos de elementos arquiteturais:

Elementos de processamento: são elementos que usam ou transformam informação;
Elementos de dados: são elementos que contêm a informação a ser usada e transformada; e
Elementos de conexão: são elementos que ligam elementos de qualquer tipo entre si.

Já a organização dita as relações entre os elementos arquiteturais. Essas relações possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relações devem ser ponderadas de modo a indicar sua importância no processo de seleção de alternativas. As relações vão desde as interfaces tecnológicas necessárias para comunicar dois sistemas distintos até os processos (inclusive humanos) necessários para manter os estados desejados das informações dentro do ciclo de negócio.

Decisões arquiteturais

Ok, vimos até aqui que arquitetura é a arte de tomar decisões inteligentes de acordo com um contexto (lembrando que contexto é igual a “Elementos” e “Organização”). As decisões arquiteturais têm, basicamente, três características que devem ser consideradas: descrição, objetivos e fundamentação.

Por descrição devemos entender que se trata do que foi decidido para o sistema, podendo ser: descrição de um elemento, módulo, classe, ou serviço que existirá na arquitetura, a descrição da comunicação de um elemento da arquitetura com outro, a descrição da agregação de diversos elementos diferentes da arquitetura para formar um serviço, ou a descrição de um princípio ou mais princípios que conduzirão a evolução do sistema.

É sabido que toda decisão é feita com um ou mais objetivos. Isso posto, a segunda característica trata de explicitar qual o objetivo de dada decisão, normalmente, permitindo ou restringido um conjunto de atributos de qualidade do sistema.

Finalmente, uma decisão arquitetural só pode ter sido alcançada em meio a alternativas com algum embasamento ou fundamentação. Por esse motivo, cabe ao arquiteto explicitar por que tal decisão foi tomada, seja por conhecimento prévio de como satisfazer os objetivos em questão ou pela atual decisão ter mostrado os melhores resultados em meio a uma avaliação prévia das alternativas.

Lembre-se sempre do contexto

É comum e cômodo adotarmos as chamadas “boas práticas” como uma verdade incondicional. Afinal, boas práticas refletem ações, técnicas e processos utilizados com sucesso para resolver determinado problema.

Contudo, como vimos, toda a tomada de decisão requer, dentre outros fatores, embasamento e fundamentação. Por esse fato, só podemos considerar uma prática como boa se ela for avaliada dentro de um contexto bem conhecido e claro, onde obtemos com a aplicação dessa prática um retorno tangível e eficaz. Do contrário, aplicar uma boa prática - apenas por ser um padrão de mercado - não garantirá nada a não ser mais complexidade acrescida a solução.

Ora, se estamos falando de contexto, é possível pensar em decidir algo sem levar em conta a organização (empresa, por exemplo)? Pense bem, até mesmo a aplicação de um patch de segurança no servidor de produção não é uma decisão meramente técnica, pois se existe um risco do patch afetar algum building block arquitetural, isso deve ser levado em conta.

Para reflexão

Tenho visto por aí muita confusão a respeito das atribuições e competências de um arquiteto, seja um arquiteto de sistema, arquiteto de solução, arquiteto corporativo ou qualquer outro que exista ou inventem (já que ser arquiteto está na moda, não é verdade?). Gostaria de propor que o título desse post fosse um auto-questionamento para você, arquiteto.

E um grande ciclo se encerra. Que comece o próximo!

Sun, 01 Jan 2012 03:40:19 -0200

Não, não falo do ano de 2011. Não sou daqueles que se emociona gratuitamente com a virada do ano novo, acreditando que tudo será diferente. Refiro-me a um ciclo muito maior, que remonta uma fase de minha vida onde exerci a profissão de consultor. Onde iniciei um blog técnico com o intuito de aprender enquanto tentava ensinar. Falo da fase onde comecei a escrever artigos técnicos e acabei me tornando editor técnico de duas revistas. Quero relembrar esse grande ciclo onde participei ativamente de comunidades técnicas, organizei eventos e até palestrei.

Esse post registra minimamente os acontecimentos desse ciclo que passou.

Muitas palestras e novas amizades

Sem dúvida a parte mais legal de participar de comunidades é conhecer pessoas que têm conteúdo e fazem a diferença em nossa área. Nesse ano tive a oportunidade de conhecer muita gente bacana enquanto organizava a grade de palestrantes do DNAD 2011.

Também fui convidado para fazer várias palestras, entre elas: DNAD 2011, TDC 2011 e QCon 2011. Foi o primeiro ano em que palestrei para algumas universidades e achei a experiência muito rica.

Uma coisa que apenas esbocei esse ano foi palestrar em dupla. Com o meu amigo @elemarjr tive a chance de, por duas vezes, fazer uma palestra dividida em duas partes. Esse ano quero fazer uma palestra com ele (ou algum outro louco que tope) mas sem dividir os horários. Acho que será uma experiência no mínimo interessante.

Um ano incrível!

O que posso comentar sobre ter a felicidade de trabalhar a 50 metros de casa? E ainda fazendo algo que gosto muito: arquitetura de software? Ah, essa foi a grande realização do ano! E o que é melhor: agora tenho férias remuneradas!!

É incrível como às vezes nos prendemos a certas incertezas sem muito fundamento… E de repente, nos pegamos dizendo: porque não fiz isso antes? Pois é… C’est la vie. O ano de 2011 me trouxe o encerramento de um ciclo vitorioso (7 anos, manôlos) e o início de outro que será fantástico.

Qualidade de vida é tudo, só tenho isso a dizer!!

De editor técnico a editor de podcast

Quando comecei a escrever artigos técnicos em 2008 lembro-me muito do sentimento de colaboração sob o qual estive imbuído. De fato, eu havia entendido na época que a melhor forma de aprender seria tentando ensinar a outras pessoas. O conhecimento deve ser dividido, ou melhor dizendo, multiplicado. Foram dezenas de artigos escritos, e quase uma centena de outros que foram editados.

Durante esse período pude conhecer muitos autores legais e consegui levar muita gente boa para escrever para a .net Magazine. Tive o prazer de trabalhar com o grande mestre Guinther Pauli, editor geral das revistas .net Magazine e Clube Delphi.

Com a mudança de emprego o trabalho como editor técnico foi revisto, e gradativamente foi substituído pelo podcast, uma nova mídia para poder colaborar e tratar de forma mais dinâmica e ágil sobre diversos assuntos (inclusive técnicos).

public void Podcast()

Ter um podcast foi a única coisa que não planejei para 2011, no entanto, aconteceu. E foi muito divertido. Além de poder dar umas boas risadas e conversar sobre assuntos que gosto, ainda “ganhei de brinde” o trabalho de edição. Isso me obrigou a aprender a usar softwares de edição de áudio, o que acabou virando um hobby.

Para completar essa nova fase, passei a usar um MacBook Pro, e preciso confessar que gostei muito! Até mesmo uma mudança de sistema operacional aconteceu. Que coisa!

E o que muda aqui no blog?

Na verdade, não muita coisa… a princípio. Aproveitando esse encerramento de ciclo, decidi que o blog não mais se chamará Reverb. O Reverb foi o meu blog técnico, onde escrevia apenas sobre assuntos relacionados a minha profissão (similar ao blog Distortion, onde eu postava sobre música e mais recentemente sobre cinema de animação). Foi um período muito bacana, e quero conservá-lo em minha memória com carinho. Nesses últimos 4 anos passei por muita coisa, evoluí sob muitos aspectos e o Reverb não mais comportava tudo que eu queria expressar.

Pretendo continuar escrevendo nesse espaço muito conteúdo técnico, mas não quero me limitar apenas a isso, quero escrever também sobre música, cinema de animação, livros (inclusive não técnicos) e sobre vários outros temas. Enfim, o blog muda refletindo as minhas próprias mudanças como pessoa.

Que comece o próximo ciclo!

Pois é, responsabilidade social

Mon, 05 Dec 2011 22:46:00 -0200

Eu sei, todo esse papo do “politicamente correto” enche o saco, concordo. Parece que hoje, tudo é “politicamente incorreto” não é verdade? A ladainha da eco-responsabilidade também parece não ajudar muito… É muita pressão para forçar uma “consciência ecológica”, sei lá.

Como despertar a consciência de preservação da natureza em uma criança sem que ela queira de fato preservar a natureza porque compreende que ela é algo necessária (e não porque todos dizem repetidamente: “o planeta está morrendo e a culpa é sua!”)?

Só pra citar um exemplo: como é possível para alguém que não pisa na grama (porque é proibido), ou quebra um galhinho de uma planta (sem ser chamado de assassino cruel), ou subiu em uma árvore, enfim, que nunca experimentou a natureza, sentir a necessidade de desenvolver consciência ecológica?

Ao invés de vociferar todo esse papo de responsabilidade social, ecologia e meio ambiente, acho muito mais importante a prática no dia a dia, o exemplo é algo muito poderoso e menos intrusivo (se é que cabe falar dessa forma quando o assunto é a destruição do planeta, não mesmo?).

Tenho a felicidade de trabalhar em uma empresa que presa muito a questão socio-ambiental. E isso é tão natural dentro da cultura da empresa que ninguém precisa ficar em momento algum “cobrando” uma atitude de responsabilidade social ou de preservação da natureza. As ações e exemplos são percebidos diariamente:

Nas salas de reunião, onde todas as folhas são de papel reciclável e os lápis feitos com madeira de reflorestamento;
Nos bebedouros, onde podemos utilizar copos descartáveis biodegradáveis;
Em todas as impressoras, onde a preferência é por utilização de papel reciclável (salvo quando é exigido papel comum);
Na distribuição de sacolas retornáveis para todos os funcionários;

No Brasil...

66 sacolas são usadas por pessoa a cada mês

36.000.000 sacolas são consumidas todos os dias

400 anos é o tempo gasto para sua decomposição natural

Com o objetivo de reverter estes números e enxergando o caminho para a sustentabilidade como uma ação coletiva, estamos distribuindo a todos os funcionários do Rabobank Brasil uma sacola retornável, auxiliando a reduzir o consumo de sacolas plásticas e minimizando assim nosso impacto sobre o meio ambiente!

Para ter acesso a mais informações sobre o tema e saber dicas de como diminuir seu consumo de sacolas visite o sita da Campanha do Ministério do Meio Ambiente “Saco é um saco”.

Nos cartões de visita dos funcionários, que são confeccionados utilizando papel reciclável;
Na caixinha onde os cartões de visita são entregues, também feito de papel reciclável;
No uso de lâmpadas fluorescentes;
No desligamento programado dos computadores das 21h às 6h;
Na configuração para desligamento automático dos monitores após alguns minutos sem uso;
No contrato de compra de computadores da Dell, que desenvolve equipamentos com baixo consumo de energia;
No ajuste de temperatura do ar condicionado (desligamento durante a noite e aos finais de semana);
No apoio a campanhas como o Papai Noel dos Correios.
E tantas outras ações…

Enfim, exemplos concretos e ações efetivas, muito melhor que blá-blá-blá.

Void Podcast: episódios #009 ao #012 disponíveis!

Mon, 14 Nov 2011 10:21:00 -0200

Void Podcast #009 – Inove-me devagar, pois tenho pressa!
Escute um Void do ódio e com sangue nos olhos sobre early adopters, entusiastas e falsos profetas. Vamos falar sobre aqueles profissionais (bons e ruins) ansiosos por adotar as melhores tecnologias, de todos os tempos, da última semana. Participe do bate-papo entre o (sábio barbudo) Leandro Daniel (@leandronet) e o (revoltado?!) Elemar Jr (@elemarjr). Arrobinha (vulgo @vquaiato), não apareceu…

Void Podcast #010 – Pimenta na complexidade dos outros é refresco!
Discutimos sobre a complexidade nossa de cada dia. Há o melhor do complexo, do simples e da vaidade infinita do homem. Participe do bate-papo acalorado entre o (professor) Leandro Daniel (@leandronet), o (filosófico) Elemar Jr (@elemarjr) e o (inventivo Fowler) Arrobinha (vulgo @vquaiato).

Void Podcast #011 – Prestígio pouco é bobagem!
Dessa vez, ouça uma discussão acalorada, cheia de IMHOs, sobre o (baixo) prestígio de tecnologias classudas (?!). Tudo gravado em um famoso café que vende uma bebida chamada Java (com gosto duvidoso, segundo o Elemar), rodeada por loucos gritando para garantir a captação do áudio e assustar os outros frequentadores do “estabelecimento”. Esse void foi gravado nos dias do TechEd, sob risco de explosão causada por gases (do subsolo do Center Norte, segundo o defensivo Leandro) depois de um almoço tecno-nerd semi-vegetariano (por causa do arrobinha) e de uma visita inusitada, com fotos de propósitos suspeitos, a uma loja de brinquedos.

Void Podcast #012 – Saudoso malloc!
Dessa vez, ouça uma discussão melancólica, cheia de saudosismo, sobre as tecnologias dos “primeiros dias” de nossos heróis. Nela, encontramos os “como era melhor no meu tempo” do (quase hacker) Leandro Daniel (@leandronet) e do (empolgado “gritante”) Elemar Jr (@elemarjr).

É possível ouvir o podcast diretamente do post (usando o player), além disso, o Void Podcast agora está disponível também no iTunes.

Não deixe de comentar suas opiniões.

Em 2011…

Fri, 11 Nov 2011 18:41:23 -0200

O Reverb foi assim:

O Void Podcast foi assim:

FIT e IFSP 2011: Slides da palestra Arquitetura (evolucionária) e o arquiteto

Sat, 08 Oct 2011 15:37:00 -0200

Segue a minha apresentação feita na 4ª Semana Integrada / Faculdade Impacta 2011 sobre Arquitetura Evolucionária e o Arquiteto de Software. A receptividade foi muito boa, fiquei surpreso com o interesse dos presentes (que lotaram a sala). Deixo aqui o meu agradecimento ao Roberto Baptista pelo convite, foi muito bacana!

Caso queira entrar em contato para tirar alguma dúvida, fique a vontade.

UPDATE: Ontem (20/10/2011), foi a vez de falar para os alunos do IFSP. Achei muito bacana a estrutura da universidade e fiquei feliz em poder contribuir na semana de tecnologia.

FIT e IFSP - Arquitetura (evolucionária) e o papel do arquiteto

View more presentations from Leandro Daniel

Palestras na FIT e na IFSP

Mon, 03 Oct 2011 14:20:00 -0200

Durante o mês de outubro farei duas palestras para estudantes universitários, falando sobre arquitetura de software e o papel do arquiteto.

Arquitetura (evolucionária) de software e o papel do Arquiteto

A arquitetura de software pode ser definida de uma única vez durante o desenvolvimento de um software: mas essa não é uma boa ideia. Nessa sessão, o palestrante discorrerá sobre o tema, trazendo experiências próprias e reflexões no intuito de instigar os participantes a pensarem na necessidade de utilizar uma abordagem evolucionária no desenvolvimento de software. Desmistificando inclusive a ideia de que a arquitetura por si só é uma concepção complexa e rebuscada.

Segue abaixo a agenda:

4ª Semana Integrada / Faculdade Impacta - 3 a 7 de outubro

Minha palestra será quinta-feira (06/10/2011), às 19h30, com tempo de 1h30, sendo 1h de palestra e 30 min de arguição.

Endereço:
Unidade I (Graduação e Colégio)
R. Arabé, 71 - Vila Clementino
CEP 04042-070
São Paulo - SP

Mapa com a localização

Semana de Tecnologia do IFSP - 17 e 21 de outubro

Minha palestra será quarta-feira (19/10/2011), às 21h.

Endereço:
Rua Pedro Vicente, 625 - Canindé - São Paulo - SP

Nos vemos lá!

Tech-Ed 2011: Mais uma vez, como enviado da DevMedia!

Tue, 27 Sep 2011 20:58:42 -0200

Graças a parceria que tenho com a DevMedia (sou Editor Técnico da revista .net Magazine e também da Clube Delphi) estarei no evento Tech-Ed 2011. Gostaria de deixar aqui os meus agradecimentos a Kaline Donabella do Grupo DevMedia e a Daniella da Costa (Coordenação) por viabilizarem essa oportunidade.

Não deixe de acompanhar em tempo real os tweets que farei, na medida do possível passarei o que estará rolando no evento!

Você pode me seguir aqui: @leandronet

E se você vai participar do Tech-Ed, nos vemos lá!

QConSP 2011: Slides da palestra Praticando a Arquitetura Evolucionária

Sun, 11 Sep 2011 11:41:44 -0200

Segue a minha apresentação feita na QCon 2011 sobre Arquitetura Evolucionária. Caso queira entrar em contato para tirar alguma dúvida, fique a vontade.

QConSP 2011 - Praticando a arquitetura evolucionária

View more presentations from Leandro Daniel

Microsoft .NET Gadgeteer

Tue, 06 Sep 2011 21:26:00 -0200

Sabe aqueles hobbies viciantes, que basta um primeiro contato pra gente ficar doido? Pois é, usando o. NET Micro Framework e Visual Studio (ou até mesmo o Visual C # Express) podemos construir pequenos dispositivos eletrônicos com o Microsoft Gadgeteer (um conjunto de ferramentas open-source, veja que bacana) .

O .NET Gadgeteer combina as vantagens da programação orientada a objetos, sem solda de montagem de produtos eletrônicos com um kit de periféricos. Esta poderosa combinação permite que os dispositivos embarcados sejam projetados, construídos e programados em questão de horas. Na prática, temos uma pequena main board e inúmeros devices, sensores, dispositivos e gadgets que podemos ligar nessa placa, combinando-os para criar dispositivos e programando em .NET. Não é demais?

Segue alguns links úteis sobre o assunto:

No final de julho desse ano, participei de uma noite muito agradável e divertida na Globalcode na presença do @vsenger e diversos outros camaradas para fazermos um unpacking de uma placa de Netduino. Veja nos vídeos abaixo alguns momentos.

Globalcode - .NET MF + Netduino (Unpack) + Fun from Leandro Daniel on Vimeo.

O tão aguardado momento do unpacking da placa.

Globalcode - .NET MF + Netduino (Unpack) from Leandro Daniel on Vimeo.

É ou não é um entretenimento nerd de primeira?

Void Podcast: episódios #005 ao #008 disponíveis!

Mon, 05 Sep 2011 09:39:00 -0200

Void Podcast #005 – Nossa (maltratada) Língua Portuguesa
Neste episódio – um dos mais desconexos com a tecnologia – conversamos um pouco sobre a importância do bem falar e bem escrever na nossa querida língua portuguesa. Será que uma boa gramática, um bom texto, bons e-mails fazem parte dos requisitos de um profissional de TI? Até que ponto escrever de forma errada está ligado com ser ou não um bom programador? O hábito de ler – livros não técnicos principalmente – é algo importante, sabemos. E o que fazer para adquirir este hábito e/ou o gosto pela leitura? Como isso pode nos tornar profissionais melhores?

Void Podcast #006 – Mais dias na vida?! Mais vida nos dias
Leandro Daniel (@leandronet), Vinícius Quaiato (@vquaiato, vulgo arrobinha) e Elemar Júnior (@elemarjr) conversam sobre a rotina cansativa dos profissionais de TI, sobre o quanto as coisas eram mais fáceis no passado (arrobinha melancólico?!) e, por fim, sobre o que fazem para preservar sua saúde física e, quem sabe, aparente sanidade mental (será?!)

Void Podcast #007 – Eu devo sim, estou vivendo…
Nessa edição, Leandro Daniel (@leandronet), Vinícius Quaiato (@vquaiato, vulgo arrobinha) e Elemar Júnior (@elemarjr) confessam seus pecados e assumem escrever códigos não tão bons. Como tentativa de redenção, defendem mais um conceito “classudo” de nossa área: dívida técnica.

Void Podcast eXperience #001 – One minute chicken answers
Bem-vindos ao Void Podcast eXperience. Uma linha alternativa e um tanto confusa do Void Podcast. Trata-se de uma conversa maluca, de três bons amigos, sobre assuntos diversificados seguindo uma dinâmica bem desorientada. Escute as opiniões pouco ortodoxas do sábio (barbudo) Leandro Daniel (@leandronet), o jovem gafanhoto Vinícius Quaiato (@vquaiato, vulgo arrobinha) e o maluco beleza Elemar Júnior (@elemarjr) sobre vários temas (alguns inteligentes, outros nem tanto).

Void Podcast #008 – Cada um no seu cada um, com um pouco do cada um dos outros
Escute um void inflamado sobre … mercado. Vamos falar sobre profissionais, empresas e as respectivas relações. Participe do bate-papo entre o (barbudo) Leandro Daniel (@leandronet), o quase-formal (?!) Vinícius Quaiato (@vquaiato) e o (calvo, segundo os caluniosos) Elemar Jr (@elemarjr).

O voidpodcast teve um hiato forçado. Muitos eventos, compromissos, palestras e computadores estragados.

Nesse tempo, tomamos a liberdade de ir não agregar valor em outros lugares da podosfera. Participamos do DatabaseCast, atendendo um convite gentil (ou seria hostil) do Mauro Pichiliani e Wagner Crivelini (Acreditem, DBAs assumidos).

Se você está interessado em ouvir o resultado dessa mistura, vá lá e escute.

É possível ouvir o podcast diretamente do post (usando o player), além disso, o Void Podcast agora está disponível também no iTunes.

Não deixe de comentar suas opiniões.

Content Metamodel Overview: referência rápida para arquitetos

Wed, 31 Aug 2011 15:49:00 -0200

O TOGAF pode oferecer uma série de direcionamentos, ferramentas e práticas interessantes para um arquiteto de TI desenvolver seu trabalho em uma organização.

O diagrama abaixo (disponível publicamente aqui) nos dá um boa visão das preocupações relevantes durante o processo de definição de uma arquitetura. Ele também aponta os artefatos gerados pelo trabalho do arquiteto (por artefato, entendam: padrões, guias, especificações, contratos arquiteturais etc., e não somente documentos Word sem utilidade, por favor).

Traçando um paralelo com o meu post anterior, podemos ver um perfeito casamento entre os níveis e funções para um arquiteto dentro de uma empresa e as preocupações apontadas no diagrama. Note que as áreas de intersecção (diagrama do post anterior) entre os tipos de arquiteto representam as preocupações comuns e os pontos de contato e colaboração desses skills.

Experimente checar cada item do diagrama acima e constatar quais dessas preocupações fazem parte dos insumos utilizados em uma tomada de decisão no seu cotidiano. É um exercício rápido e que pode ser útil para melhorar a forma como você colabora com o time e a empresa.

Para aprofundar em cada conceito relatado no diagrama, consulte aqui o TOGAF.

Refletindo sobre funções e níveis de arquitetura em uma empresa

Tue, 30 Aug 2011 15:28:00 -0200

Em Junho de 2007, o IASA (Global IT Architects Association), estudou diferentes tipos de arquitetos de variados setores da indústria para chegar a uma série de recomendações gerais para as funções de um arquiteto de TI dentro de uma empresa.

Segundo o IASA, o estudo possibilitou a identificação de 4 funções para um arquiteto, ilustradas na figura a seguir:

Arquiteto corporativo

A missão para um arquiteto corporativo (com foco em IT) consiste em apoiar a estratégia de negócio da organização com soluções de tecnologia e informações. O arquiteto corporativo, ou grupo de arquitetos corporativos, deve ser responsável pela estratégia global sobre as capacidades de TI, bem como para garantir que a arquitetura de TI seja rentável.

É esperado que esse profissional tenha profundo conhecimento do negócio da organização, além de competências de:

liderança e capacidade de negociação;
experiência em governança, economia e gerenciamento de projetos;
conhecimento em arquitetura corporativa e modelagem de negócios.

Arquiteto de negócios

Esse tipo de arquiteto trabalha muito próximo ao negócio e entende detalhadamente como funciona a organização. Eles estão presentes na modelagem de processos da organização, e dão suporte na definição de arquiteturas, realizando a análise de requisitos de soluções novas ou existentes.

É esperado que esse profissional tenha profundo conhecimento do negócio da organização, além de competências de:

liderança e capacidade de negociação;
experiência em governança, economia e gerenciamento de projetos;
conhecimento em arquitetura corporativa e modelagem de negócios.

Arquiteto de soluções

Arquitetos de soluções têm responsabilidade especial para serviços e funções de reusabilidade. Eles alinham novas soluções para os princípios arquiteturais definidos em uma organização e as relaciona com foco em integração. Eles equilibram os requisitos funcionais e não-funcionais de acordo com as prioridades da empresa.

É esperado que esse profissional tenha:

amplo conhecimento técnico (geral);
profundos conhecimentos em infra-estrutura, modelos de dados, orientação a serviço;
boa compreensão da arquitetura corporativa.

Arquiteto de software

O arquiteto de software trabalha com a estrutura e o design de sistemas de software. O foco para o arquiteto de software é principalmente o projeto atual, enquanto o arquiteto de soluções tem um foco mais amplo, ligado a políticas e regulamentos.

É esperado que esse profissional tenha profundos conhecimentos em programação, frameworks, padrões e modelagem técnica.

Outros tipos de "arquiteto de TI"

Como vimos, cada organização poderá requerer algum dos arquitetos descritos, ou em alguns casos, todos. Embora a arquitetura dentro de TI seja uma função mais do que necessária, a forma e os limites de atuação de um arquiteto podem diferir dependendo do contexto, não havendo em muitos dos casos um consenso.

Já tive conhecimento de pessoas atuando com o cargo (ou papel) de:

Arquiteto de Sistemas
Arquiteto de Dados
Arquiteto SOA
Arquiteto de Infraestrutura
entre outras...

Também já ouvi muitas histórias sobre arquitetura compartilhada, embora nunca tenha presenciado um cenário desse tipo funcionando a contento.

Todavia, o importante em tudo isso é entender que: A arquitetura é uma atividade presente no desenvolvimento de qualquer software, ainda que ela seja negligenciada (afinal, mesmo sem pensar em uma arquitetura, o software depois de construído possuirá uma, certo?).

Agora é com você

Isso posto, refletindo sobre a empresa onde você trabalha, quais tipos de arquiteto são necessários? E se você não enxerga utilidade nesses papeis, por favor, exponha nos comentários suas razões.

Palestra de arquitetura no QCon 2011!

Tue, 23 Aug 2011 09:41:00 -0200

Estarei presente na edição deste ano da QCon, evento organizado pela Caelum e InfoQ. O QCon aborda não apenas uma única tecnologia ou aspecto: passa de Java, .NET, Rails, Arquitetura, Linguagens Funcionais, Mobile, Enterprise Agile Transformation, Práticas de Engenharia Ágil e outras.

A convite do organizador da trilha ".NET e as arquiteturas modernas", @vquaiato, darei continuidade no assunto "Arquitetura Evolucionária", dessa vez mostrando como praticá-la dentro do desenvolvimento na plataforma .NET. Veja abaixo a descrição da trilha:

A plataforma .NET já não é mais uma promessa: é uma realidade. Mais e mais aplicativos, sistemas e soluções são construídos utilizando-a. A da necessidade de softwares e soluções cada vez mais inovadoras e competitivas tem impulsionado arquitetos e desenvolvedores a buscarem alternativas e diferenciais na forma como o softwares são construídos e pensados. Hoje são possíveis resultados que há algum tempo estavam apenas no futuro: processamento paralelo, distribuído e escalável de maneira financeiramente aceitável; construções assíncronas na própria linguagem; múltiplas linguagens e tecnologias em uma mesma plataforma; desenvolvimento web de forma simples e com qualidade. Veremos aqui tecnologias, problemas e soluções que possibilitam a criação e construção de aplicações robustas, inovadoras e eficientes na plataforma .NET

O evento conta com inúmeros palestrantes nacionais e internacionais, confira aqui.

Nos vemos lá!

TDC 2011 Florianópolis: Slides da palestra Entendendo a Arquitetura Evolucionária

Mon, 22 Aug 2011 20:00:00 -0200

Segue a minha apresentação feita no TDC 2011 Florianópolis (The Developer’s Conference 2011) sobre Arquitetura Evolucionária. Caso queira entrar em contato para tirar alguma dúvida, fique a vontade.

Na edição Florianópolis tive a chance de fazer a palestra completa sobre o tema "Arquitetura Evolucionária". Fiquei muito feliz com a receptividade do pessoal, a sala estava cheia, e palestrar junto com o @elemarjr, @drspockbr, @vsenger e @scaphe foi uma tremenda responsabilidade (só feras).

Oportunamente, deixo aqui meu agradecimento ao @drspockbr, @yarasenger e @vsenger pela oportunidade! Obrigado mesmo!

TDC 2011 (Florianópolis) - Entendendo a Arquitetura Evolucionária

View more presentations from Leandro Daniel

O mito de Sísifo no desenvolvimento de software

Mon, 08 Aug 2011 21:01:47 -0200

Oriundo da mitologia grega, a história de Sísifo foi recontada em um ensaio do filósofo Albert Camus, em 1942. Sísifo era considerado o mais astuto dos mortais, contudo, por enganar os deuses foi castigado a realizar, por toda a eternidade, uma tarefa repetitiva e sem sentido. Ele foi condenado a rolar uma grande pedra de mármore com suas mãos até o cume de uma montanha, sendo que toda vez que ele estava quase alcançando o topo, a pedra rolava novamente montanha abaixo até o ponto de partida por meio de uma força irresistível.

No ensaio de Camus, ele utiliza o Mito de Sísifo para elaborar uma metáfora sobre a vida moderna. Veja, nas palavras de Camus, o resultado (que considerou fazer parte de um absurdo do homem): “O operário de hoje trabalha todos os dias em sua vida, faz as mesmas tarefas. Esse destino não é menos absurdo, mas é trágico quando em apenas nos raros momentos ele se torna consciente”.

Voltemos aos dias atuais, distantes e supostamente menos sofridos que os tempos descritos no Mito de Sísifo. Imaginando o dia a dia prático de um profissional de TI. Quais responsabilidades e obrigações são inerentes ao trabalho entregue no final de um projeto por um desenvolvedor? Quanto custa para a empresa um software que não segue as orientações de boas práticas de desenvolvimento? Qual a dificuldade que outros desenvolvedores terão em manter um sistema escrito às pressas, sem testes e com vários bugs? Será, que quando escrevemos nosso código, temos em mente essas questões todas? Ou melhor, será que nos importamos com elas, de verdade? Uma boa analogia, quando pensamos nessas dúvidas, é imaginar todos os problemas decorrentes de negligência como dívidas técnicas.

Uma dívida técnica (do inglês, “Technical Debt”) muitas vezes traduzida para Débito Técnico, é uma metáfora criada por Ward Cunningham para descrever uma situação onde o time decide optar por uma maneira mais rápida e menos correta de se criar um software ou um pedaço de um algoritmo para que ele possa ser entregue mais cedo. Normalmente os motivos são: pressão do cliente, tempo escasso, falta de capital, falta de conhecimento, pouca experiência entre outros. Estas dívidas, assim como as dos bancos, possuem juros, isso que significa que se não forem pagas logo, podem se acumular e causar grandes transtornos em longo prazo. E o mais interessante, é que muitas vezes reclamamos de nosso trabalho, achando-o repetitivo e sem sentido, mas não nos damos conta de que temos uma boa parcela de culpa. Criamos os meios para que a dificuldade experimentada no cotidiano seja alimentada permanentemente. Como Sísifo, tentamos remendar o sistema, adiar ao máximo a escrita de testes, nos esforçar para que “um trabalho” (sem objetivo claro) seja realizado em prol do software, para no final, tudo parecer retornar à estaca zero.

Se você, leitor, está dando os primeiros passos como desenvolvedor, atente-se para uma grande notícia: Tens todas as ferramentas necessárias para trilhar um caminho completamente diferente. Como? Darei algumas dicas a seguir:

Procure participar ativamente de comunidades de desenvolvedores que tenham a ver com as tecnologias que você deseja estudar. Isso lhe trará não só o benefício de trocar boas experiências na prática de desenvolvimento de software como também, e talvez mais importante, observar quais são os erros mais comuns e quais as soluções dadas. O importante, claro, é sempre manter um olhar crítico sobre tudo que você apreende de uma comunidade, aprendendo gradativamente a separar o bom do mau conteúdo.
• Existem inúmeros livros que tratam sobre boas práticas de desenvolvimento de software. É importante tentar extrair de desenvolvedores mais experientes quais livros eles leem para aprimorar suas técnicas. Isso não é difícil, bastando em muitos dos casos navegar pelos blogs técnicos existentes.
• Participar de grupos de estudo, como por exemplo, no formato “Coding Dojo” certamente será muito enriquecedor para ampliar as técnicas de programação. Um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se descontraírem, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo.

Termino aqui, esperando que o Mito de Sísifo tenha lhe despertado o interesse pela busca incessante pela excelência que nós, desenvolvedores de software, devemos objetivar cada vez que repousamos nossas mãos em cima do teclado. Codifique sempre de forma limpa, evite criar “pedras” que serão carregadas repetidamente em um trabalho sem sentido.

TDC2011 Floripa está chegando!

Tue, 02 Aug 2011 14:39:00 -0200

É com grande prazer que anuncio que minha palestra foi aceita na trilha de arquitetura do TDC 2011 Florianópolis coordenada pelo Alberto Lemos (Dr. Spock, do universo Java, rapá!).

O TDC2011 São Paulo foi um enorme sucesso, e a edição Florianópolis promete repetir a dose. O TDC 2011 é um evento organizado pela Globalcode sob o comando do competente e empolgante casal Vinicius Senger e Yara Senger (sério, você os conhece e fica empolgado com qualquer coisa que eles realizam na comunidade técnica).

Farei uma palestra sobre Arquitetura Evolucionária, onde procurarei explorar mais o tema junto com os congressistas presentes. Será bastante divertido! :)

Veja abaixo a localização do evento e outras informações.

Data
20 e 21 de Agosto de 2011

Horário
Das 8:30 às 18:30 h

Local
Universidade Estácio de Sá
Av. Leoberto Leal, 431 CEP 88117-001
São José - SC

Informações
informacoes@thedevelopersconference.com.br

Nos vemos lá!

Mestres do non sequitur e outros tipos perniciosos – Parte 6

Mon, 01 Aug 2011 10:18:00 -0200

Se você não leu os posts anteriores da série, faça agora.

Falácia no estilo “non sequitur”

Esta falácia deriva da confusão entre condição suficiente e condição necessária. O argumentador apresenta pelo menos duas proposições que não podem ser verdadeiras ao mesmo tempo. Em tais casos as proposições podem ser contrárias ou contraditórias.

Seek & Destroy

Mostre que, mesmo sendo as premissas verdadeiras, a conclusão pode ser falsa. Em geral basta mostrar que uma proposição pode ser consequência de outra coisa.

Mostre que a conclusão pode ser falsa mesmo que as as premissas sejam verdadeiras.

Parta de uma das afirmações e use-a como uma premissa para mostrar que a outra é falsa.

Mestres do non sequitur e outros tipos perniciosos – Parte 5

Thu, 14 Jul 2011 11:05:33 -0200

Se você não leu os posts anteriores da série, faça agora.

Falácia no estilo “hey, meu sobrenome é polêmica”

A definição que mais gosto para a palavra “polêmica” é:

Disputa amigável mas acalorada.

Ou seja, é uma oportunidade rica para confrontar ideias, expor novas visões sobre algum tema, enfim, produzir conteúdo relevante. O problema, é quando usa-se da polêmica para criar argumentos falaciosos.

Um bom exemplo é a introdução de um falso dilema num debate. Funciona da seguinte forma: A pessoa coloca um número limitado de opções (na maioria dos casos apenas duas), quando de fato existem mais. O falso dilema é um uso ilegítimo do operador "ou". Como, por exemplo, na frase “Utilize a tecnologia xyz OU você ficará ultrapassado.”

Outra forma engenhosa de gerar polêmica falaciosa é o apelo à ignorância. Nesse caso, os argumentos concluem que algo é verdadeiro por não se ter provado que é falso, ou conclui que algo é falso porque não se provou que é verdadeiro.

Há ainda a possibilidade do interlocutor se valer de uma pergunta complexa onde dois tópicos sem relação, ou de relação duvidosa, são conjugados e tratados como uma única proposição.

Seek & Destroy

Dois exercícios para identificar e matar esse tipo de falácia.

Identifique as opções dadas e mostre (de preferência com um exemplo) que há pelo menos uma opção adicional.

Identifique as duas proposições conectadas e mostre que acreditar numa não implica acreditar na outra.

Mestres do non sequitur e outros tipos perniciosos – Parte 4

Wed, 13 Jul 2011 14:40:09 -0200

Se você não leu os posts anteriores da série, faça agora.

Falácia no estilo “early adopter”

Early adopters são usuários que rapidamente adotam novas tecnologias, baseado no impulso inicial de pessoas inovadoras (leia post explicativo aqui).

Dentro da comunidade de TI, os early adopters são pessoas de grande destaque e capacidade de influência. Por adotarem antecipadamente uma tecnologia (ferramenta, plataforma, arquitetura, linguagens de programação etc), os EA têm um curto espaço de tempo para sedimentar conceitos. Exatamente aí reside o problema, pois a falácia pode nascer de um raciocínio indutivo, de uma generalização precipitada ou ainda de uma amostra limitada.

O raciocínio indutivo consiste em inferir das propriedades de uma amostra para as propriedades de um elemento não pertencente à amostra ou para as propriedades da população como um todo. Todo raciocínio indutivo depende da semelhança entre a amostra e a população. Quanto maior for a semelhança entre a amostra e a população como um todo, maior confiabilidade terá a inferência indutiva. Por outro lado, se a amostra tiver diferenças relevantes face à população, então a inferência indutiva não será confiável.

Não foram raras as vezes que li em blogs técnicos falácias oriundas de generalização precipitada. Frases de efeito como: "ORMs farão desenvolvedores nunca mais se preocuparem com queries!", "SOA morreu!", "Bancos de dados relacional são malignos!" - entre outras - são falácias resultantes de generalização precipitada.

Seek & Destroy

Para matar esse tipo de falácia, basta expor os dados em falta e mostrar que eles mudam a conclusão do argumento indutivo. Outra maneira seria identificar as dimensões da amostra e a população em questão e depois mostrar que a amostra é insuficiente.

Mestres do non sequitur e outros tipos perniciosos – Parte 3

Tue, 12 Jul 2011 09:41:00 -0200

Se você não leu os posts anteriores da série, faça agora.

Falácia no estilo “bullshit”

É comum nos valermos de definições para tornar os nossos conceitos mais claros. Uma definição deve expor com exatidão o significado de alguma coisa. Assim sendo, o interlocutor deve colocar uma definição de maneira breve e clara, e o receptor deve ser capaz de aplicá-la a situações concretas sem ajuda exterior.

Por exemplo, se definirmos o que significa “arquitetura”, o receptor deve ser capaz de aplicar a definição assertivamente. Caso o receptor falhe ao definir “arquitetura” e aplique o conceito a objetos que não façam parte dessa definição, então a definição é falha. Lembrem-se: “Definições não são argumentos, mas definições incorretas, por vezes tendenciosas, são muitas vezes incluídas em argumentos, tornando-os falaciosos.”.

Seek & Destroy

Identifique o termos que estão sendo definidos, em seguida, identifique as condições da definição. Procure um objeto que preencha as condições da conclusão mas que obviamente não seja uma instância do termo a definir. Pronto, você quebrou a falácia!

Contudo, fique atento, pois existem outros tipos de falácia que se encaixam nesse estilo. A falácia pode ser pouco clara, ou se valer de argumentos restritos, e no pior dos casos ser contraditória.

Mestres do non sequitur e outros tipos perniciosos – Parte 2

Mon, 11 Jul 2011 13:42:00 -0200

Se você não leu o post anterior da série, faça agora. Continuando, veremos o primeiro tipo de falácia.

Falácia no estilo “bichinho de Deus”

A definição “bichinho de Deus” foi evocada em uma conversa com o @mantov, onde lembrávamos da infância vivida em Minas Gerais. Situação: uma criança brincando com algum inseto, geralmente uma joaninha ou algum outro bem indefeso, aí vem um idoso (quase sempre) e diz: “Não faça isso menino, é bichinho de Deus! Deus castiga se você judiar!”. É o famoso apelo a piedade.

Alguém que solta falácias usando esse estilo se vale de um estado de lamúria para conseguir a aprovação de quem está ouvindo (ou lendo). Em tempos de twitter, seria a falácia oriunda de #mimimis.

Identify & help

Como vimos, não é bacana judiar dos "bichinhos de Deus", então o mais correto seria identifcar a proposição e o apelo à autoridade e argumentar que o estado lastimoso do interlocutor nada tem a ver com a verdade da proposição.

TDC 2011: Slides da Lightning Talk sobre Arquitetura Evolucionária

Sat, 09 Jul 2011 09:18:11 -0200

Segue a minha apresentação feita no TDC 2011 (The Developer’s Conference 2011) sobre Arquitetura Evolucionária. Caso queira entrar em contato para tirar alguma dúvida, fique a vontade.

Oportunamente, deixo aqui meu agradecimento ao @andrediasbr, @yarasenger e @vsenger pela oportunidade! Valeu!

TDC 2011 - Arquitetura Evolucionária faz sentido?

View more presentations from Leandro Daniel

Void Podcast: episódios #003 e #004 disponíveis!

Thu, 07 Jul 2011 13:05:00 -0200

Void Podcast #003 – Eventos de TI
Nesse Void Podcast: Elemar Jr, Leandro Daniel e Vinícius Quaiato (vulgo arrobinha) discutem suas relações, aspirações e expectativas sobre eventos técnicos e seus bastidores. Um pouco de utopia, beirando a inocência, sobre como deveriam ser esses eventos. Além disso, uma análise pouco imparcial de palestrantes e público.

Void Podcast #004 – Frameworks Corporativos
Nesse Void Podcast: Leandro Daniel (@leandronet) e Elemar Júnior (@elemarjr) discutem suas definições, decepções, desejos e aspirações sobre os polêmicos Frameworks corporativos. Para muitos, uma “praga” corporativa. Para outros, um mal necessário. Para poucos, uma #CoisaLindaDeDeus.

É possível ouvir o podcast diretamente do post (usando o player), além disso, o Void Podcast agora está disponível também no iTunes.

Não deixe de comentar suas opiniões.

Mestres do non sequitur e outros tipos perniciosos – Parte 1

Thu, 07 Jul 2011 09:56:00 -0200

Essa série de posts também poderia ter o título “Identificando falácias e a personalidade de quem as profere”, ou ainda, num tom mais pitoresco, “Pimenta na falácia dos outros é refresco”. Mas utilizar a expressão “non sequitur” vai mais ao encontro com a maioria das falácias técnicas que escuto e leio por aí.

“Non sequi-o-quê?!?”

Sabe aqueles pais que vêem o filho, ainda criança, brincando com o conjunto de química, misturando frascos, e diz: “Ah, meu filho quando crescer será um grande químico!”, e aí a criança vira um adulto e acaba se tornando bartender, misturando um monte de frascos de bebidas? Pois é... “non sequitur” é aquela falácia lógica, onde pressupomos a partir de duas afirmações verdadeiras, que uma terceira é verdadeira, enquanto que na realidade ela é falsa. O termo “non sequitur” significa literalmente "não se segue que". Veja o exemplo a seguir, onde analisamos o resultado de uma partida de futebol:

- Se jogarmos bem, ganhamos. Ora, ganhamos. Logo, jogamos bem!

As duas primeiras premissas são verdadeiras. Contudo, afirmar que “jogamos bem” em função dessas premissas pode ser irreal, já que poderia ter ocorrido do time que venceu ter jogado mal e os adversários pior ainda. A falha nesse tipo de falácia está em relacionar um resultado como conseqüência de duas premissas, quando na verdade é algo independente.

Analisando diversos tipos de falácias através do estilo dos interlocutores

Considero muito perniciosas as falácias no meio técnico (TI), pois com a quantidade de assuntos que temos que entender às vezes é impossível estudar a fundo tudo que precisamos. Temos que recorrer, em alguns casos, a opinião de outras pessoas que tiveram a oportunidade de estudar um assunto de nosso interesse, e de alguma forma elaborarmos a nossa própria opinião.

Felizmente, identificar a personalidade de mentes falaciosas não é algo impossível. De fato, essas pessoas se comportam de forma bem característica, de acordo com o estilo de falácia que elas dizem. E sendo a falácia, em grande parte, um equivoco lógico, muitas pessoas não as dizem de má fé.

Em posts futuros faremos, com bom humor, um passeio pelos tipos de falácia mais comuns.

TDC2011 está chegando

Mon, 27 Jun 2011 15:57:00 -0200

Entre os dias 6 e 10 de julho acontecerá em São Paulo o TDC 2011 (The Developer's Conference). Esse ano o evento contará com 30 trilhas com mais de 200 palestras! Fui convidado para fazer uma Lightning Talk sobre Arquitetura Evolucionária na trilha de ALM. :)

Veja abaixo a localização do evento.

Data
De 6 a 10 de Julho de 2011

Horário
Das 8:30 às 18:30 h

Local
Universidade Anhembi Morumbi

Rua Casa do Ator, 275
Itaim Bibi, São Paulo - SP

Informações
informacoes@thedevelopersconference.com.br

Nos vemos lá!

Void Podcast: segundo episódio no ar!

Mon, 13 Jun 2011 10:52:40 -0200

Nesse episódio, conversamos sobre comunidades – importância, comportamento dos integrantes – e outras coisas. Além disso, contamos, pela primeira vez, com a ilustre participação do arrobinha (vulgo @vquaiato).

Atendendo a pedidos, é possível ouvir o podcast diretamente do post (usando o player), além disso, o Void Podcast agora está disponível também no iTunes.

Se você está procurando por algumas risadas e comentários estranhos, acesse o Episódio #002 do Void Podcast: Alô comunidade!

Não deixe de comentar suas opiniões.

DNAD 2011–Veja algumas fotos

Mon, 06 Jun 2011 16:27:39 -0200

Veja algumas fotos do evento clicando na imagem abaixo.

DNAD 2011–Veja alguns vídeos

Mon, 06 Jun 2011 15:03:49 -0200

A organização do #DNAD11 disponibilizará todas as palestras no site do grupo .Net Architects. Enquanto isso, você pode conferir alguns momentos que capturei durante o evento.

No DNAD11 tivemos uma infraestrutura que comportava todos os participantes em um ambiente agradável para que discussões sobre arquitetura e tecnologia fossem realizadas nos intervalos das palestras ou nos Open Spaces. Realmente fantástico!

#DNAD11 - Dia 2 - Coffee e muita discussão sobre arquitetura from Leandro Daniel on Vimeo.

@guilhermecaelum numa Lightning Talk super dinâmica e com vários momentos engraçados.

#DNAD11 - Dia 1 - Concentração antes do evento from Leandro Daniel on Vimeo.

O evento nem havia começado e o auditório já estava quase lotado. Comunidade em peso, pessoas vindas de vários estados do Brasil!

#DNAD11 - Dia 2 - Lightning Talks from Leandro Daniel on Vimeo.

Um dos grandes momentos do evento, na minha opinião: @guilhermecaelum e @kumpera brincando no Dojo promovido pelo @juanplopes durante o Open Spaces do DNAD.

Coding Dojo DNAD11 from vinicius quaiato on Vimeo.

DNAD 2011: Minha palestra sobre Arquitetura Evolucionária

Mon, 06 Jun 2011 11:54:08 -0200

Segue a minha apresentação feita no .Net Architects Days 2011 sobre Arquitetura Evolucionária. Caso queira entrar em contato para tirar alguma dúvida, fique a vontade.

Espero que todos tenham gostado.

DNAD11 - Examinando a Arquitetura Evolucionária

View more presentations from Leandro Daniel.

Em breve colocarei mais material do DNAD 2011 aqui no Reverb.

Void Podcast está no ar!

Mon, 30 May 2011 20:08:21 -0200

A ideia desse podcast nasceu em uma das reuniões online para acerto de nossa palestra no DNAD. Nosso desejo é poder envolver mais pessoas nas nossas discussões. O nome “Void” é uma referência direta ao tipo com mesmo nome presente em muitas linguagens populares.

No Void Podcast, Quaiato (@vquaiato), Leandro Dainel (@leandronet) e Elemar Jr.(@elemarjr) falam sobre tudo um pouco: de arquitetura de software a futebol, de boas práticas até manias nerds. Ou seja, um bom papo entre amigos.

O primeiro episódio já está no ar, “VoidPodcast #001: O que é arquitetura (evolucionária) de software?". Confira o resumo abaixo:

Nessa edição, Elemar Jr e Leandro Daniel tentam responder uma questão (quase) existencial: Afinal, O que é arquitetura de software?

Entenda o que é arquitetura; Entenda as vantagens de uma abordagem evolucionária; Alimente suas neuroses quanto à arquitetura compartilhada; Perceba associações malucas de tudo isso com mitologia grega, Estatística e Termodinâmica; E veja que filhos são bons… mas…

Acesse, escute, comente, colabore. Se tudo der certo, comentaremos todos os feedbacks e responderemos o que for possível.

Você pode assinar o feed do Void Podcast e acompanhar as novidades pelo Twitter (@voidpodcast).

Void!

Lightning talk de Design Emergente na InfoQ

Wed, 11 May 2011 12:55:33 -0200

Acaba de ser publicado no site InfoQ esta lightning talk que fiz no DNAD10.

Foi uma experiência muito bacana, pois a apresentação foi no formato conhecido como ignite. Se quiser me ver passando aperto, é só conferir o vídeo na InfoQ.

Leandro Daniel se baseia numa série de artigos de Neal Ford, que tratam da arquitetura evolucionária, para nos falar a respeito da quebra de velhos paradigmas (como Waterfall e "Big Design Up Front"), através do design emergente (idéia trazida pelos agilistas), além da utilização de métricas e testes.

Expansão e novas publicações da DevMedia

Sat, 30 Apr 2011 21:04:32 -0200

Ano passado o portal DevMedia passou a integrar o grupo Web-03, juntamente com os portais Linha de Código e JavaFree.org. Com isso, o grupo Web-03 passou a deter um conteúdo impressionante, veja a seguir um pouquinho sobre cada portal.

JavaFree é um dos maiores sites de Java do Brasil. Seu fórum possui mais de 170.000 mensagens postadas. Diariamente ele é atualizado com as principais notícias da área de tecnologia. 25 mil usuários visitam o site todos os dias, somando 2,5 milhões de page-views por mês.

O Linha de Código é um site de conteúdo técnico especializado nas ferramentas de desenvolvimento da Microsoft. Atualizado diariamente com artigos, vídeo-aulas e notícias o site é considerado uma referência entre os desenvolvedores .NET. Existem cerca de 8000 posts publicados que levam 15 mil usuários a visita-lo todos os dias, gerando 3 milhões de page-views por mês.

DevMedia é o maior portal para desenvolvedores de software em língua portuguesa. O site é atualizado diariamente com artigos, vídeo-aulas, notícias e ainda possui serviços como divulgação de vagas de emprego e um fórum com mais de 350 mil mensagens. Atualmente o site possui mais de 16 mil posts. Todos os dias cerca de 24 mil desenvolvedores visitam o site, somando mensalmente 4,5 milhões de page-views.

Além da fusão, a DevMedia lançou novas publicações nos últimos 12 meses. São elas: Easy .net Magazine, Easy Java Magazine e Infra Magazine. Faço parte do time da DevMedia desde o início de 2009, escrevendo artigos para a .net Magazine e a Easy .net Magazine além de trabalhar como Editor Técnico da .net Magazine e mais recentemente da ClubeDelphi.

É uma grande satisfação poder colaborar com a comunidade de desenvolvimento de software através do grupo DevMedia. Se você ainda não conhecia, vale a pena pesquisar os portais aqui mencionados, pois temos grandes autores e pessoas interessadas em tecnologia participando ativamente em todos esses espaços.

#Guitar, #Boss, #M-Audio e #Vaio

Thu, 21 Apr 2011 14:57:46 -0200

Afinal, feriadão é pra descansar, né?