Configurando uma Wiki num Debian Linux

Introdução

O objetivo deste post é explicar como subir uma nova instância de uma Wiki (mesma ferramenta da Wikipedia) num ambiente Linux/Debian. Como eu já fiz isso várias vezes e toda vez esqueço algum detalhe que me faz perder tempo, resolvi escrever esse post.

É possível subir instâncias da Wiki em Windows também, mas acredito que em Linux seja bem mais simples. Todos os softwares usados aqui são Open Source.

Particularmente, acho essa ferramenta espetacular para criar bases de conhecimento em qualquer empresa. A sintaxe no começo pode parecer confusa, mas uma vez que você se acostuma com ela, não a troca por nada. Tem o mesmo esforço de escrever um arquivo texto, com a possibilidade de ter formatação, links, edição colaborativa, controle de versão entre outras coisas.

O nível de segurança previsto para essa instalação é para uma intranet. Se você quer colocar uma wiki dessas na internet, deve se preocupar com várias outras questões de segurança.

Download do Debian

O primeiro passo é fazer o download da sua imagem de Debian favorita. No meu caso, usarei o Debian 7 64 Bits (https://www.debian.org/distrib/netinst, plataforma amd64).

Instalação do Debian 64

Siga os passos na tela. Não é necessário instalar a interface gráfica (o que torna a instalação muito mais leve).

Instalação da Wiki

Se você não habilitou por default o servidor ssh na sua máquina Linux, é uma boa idéia fazê-lo. É bem fácil e relativamente seguro acessar máquinas dessa maneira, mesmo vindo de uma máquina windows ou outra máquina unix.

No Windows, o cliente ssh mais popular é o PuTTY. Se você não habilitou o seu servidor ssh na sua máquina linux, basta instalar através do apt-get:

apt-get install ssh

Para descobrir o IP da sua nova máquina linux:

ip addr

Existe um método mais avançado de autenticação com SSH usando chaves pública e privada. Não é meu objetivo abordar esse método aqui, nem fornecer informações exaustivas sobre como configurar SSH.

Próximo passo é instalar os pacotes necessários para subir a MediaWiki. Como é baseado em php, você terá que instalar php, apache e outras coisas. É possível instalar em bancos de dados diferentes ou servidores web diferentes. Vou pelo que é mais comum: php e mysql. Você pode continuar absolutamente tudo dentro de uma sessão ssh, logado como root.

O primeiro passo, export DEBIAN_FRONTEND=noninteractive serve para evitar que várias configurações sejam solicitadas via terminal. Explicarei quais arquivos editar posteriormente.

export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get install apache2 -y
apt-get install php5 -y
apt-get install php5-intl -y
apt-get install php5-mysql -y
apt-get install php5-mysqlnd -y
apt-get install mysql-server -y
apt-get install php-pear -y
apt-get install php-apc -y

Se você não definiu uma senha para o usuário root do mysql, você precisará definir. Use o seguinte comando:

mysql -u root -e "set password = password('novasenha')"

Desconheço um empacotamento específico para Debian para a MediaWiki. Por isso sugiro usar os seguintes comandos para baixar e descompactar:

mkdir /root/temp
wget https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.tar.gz /root/temp
tar -zxf /root/temp/mediawiki-1.23.6.tar.gz --directory=/root/temp

Agora, para copiar os arquivos para o diretório de publicação do apache, excluir o index.html default do apache e dar acesso para a pasta de imagens:

rm /var/www/index.html
cp /root/temp/mediawiki-1.23.6/* /var/www -r
chmod 777 /var/www/images

Agora, usando um browser navegue na nova wiki: http://seuenderecoip

Você cairá nas páginas de setup da WikiMedia. Daqui em diante é tudo muito simples, uma espécie de next/next/finish. Algumas informações sobre o host do seu servidor mysql serão solicitadas (neste caso, mesma máquina e a senha do usuário root que você mesmo definiu).

No final ele pergunta algumas questões adicionais ou se você está entediado. Se você seguir para as questões adicionais, tem algumas coisas interessantes como:

  • User rights profile: Aqui você determina se quer uma wiki fechada ou aberta. Para a maioria das intranets, a opção “Account creation required” é interessante. Qualquer um pode criar uma conta, mas precisa de uma para editar. Isso pode ser interessante para manter um bom histórico de alterações nas páginas.
  • Extensions: SyntaxHighlight_Geshi é bem interessante para “pintar” trechos de código em wiki.
  • Enable file uploads também é bem interessante

Após terminar de configurar tudo, a Wiki gera um LocalSettings.php para você. Você precisa colocar esse arquivo no /var/www da sua máquina remota. Se você está numa máquina Windows controlando um host linux, pode ser um pouco complicado isso. Algumas coisas que podem te ajudar são: WinSCP ou se você tem um Git Bash na sua máquina ou um cygwin, usar:

scp /caminho/para/seu/LocalSettings.php root@seuipremoto:/var/www

Ao acessar novamente sua nova wiki por http, ela estará funcionando (assim espero).

Backup

Para fazer o backup das wiki’s, você precisa se atentar a duas coisas:

  • Dump da sua base mysql
  • Imagens

Para fazer o dump do mysql:

mysqldump -u root -psuasenhado seudatabasegeralmentemy_wiki > /algum/diretorio/temporario/seu_db.dump

Para compactar o dump e suas imagens:

tar -cvpzf /local/destino/do/seu/arquivo/seubackup.tar.gz /var/www/images /local/do/seu_db.dump

Para colocar seu backup no cron, veja /etc/crontab. O jeito mais simples é colocar um link simbólico (ver comando ln) em /etc/cron.daily. O horário que o script será executado depende do que está configurado em /etc/crontab.

Restore

Para descompactar seu backup:

tar -zxf /seu/arquivo/tar.gz

Para importar o dump no mysql (o database precisa ser criado previamente)

/usr/bin/mysql -u root -psuasenha seudatabase < /caminho/para/seu_db.dump

As imagens, é só copiar de volta no diretório.

Sobre a relação entre metodologia ágil e morar fora do país

Recentemente, me vi diante de um processo de mudar de país. Quando esta idéia começou a se tornar possível, me vi, da noite para o dia com uma infinidade de coisas para resolver, num tempo muito curto e coisas que não tinha a menor idéia de como resolver. Como lidar com a saudade, pedir demissão do emprego, decidir o que eu vou fazer com o cachorro, decidir o que levar, desmontar a casa, passar procuração, resolver visto, fazer um planejamento financeiro, reservar vôo, tirar carteira de motorista internacional, ver onde ficar temporariamente até alugar uma casa, alugar uma casa em outro país, vender o carro, cancelar contas de prestadores de serviços (água, luz, internet, TV), fazer despedidas para os amigos e família e sai lá quantas outras coisas.

É muito difícil descrever como é essa sensação. Parece que você caiu de pára-quedas no meio de uma guerra.

Se nesse momento, eu tentasse resolver de uma vez só todos os problemas, provavelmente desistiria de tudo. Seria muito mais cômodo deixar tudo como estava. Mudar era um processo cheio de incertezas, riscos e custos.

Como um bom geek, resolvi atacar esses problemas como um projeto. Fui no visualstudio.com, montei meu projeto e comecei a organizar um backlog. Primeiro as estórias (cada uma das coisas que relacionei acima, tratei como uma história pois tinham objetivos e entregáveis bem definidos) depois a prioridade. O que é mais importante e o que tem maior risco primeiro. Depois quebrei o backlog em tarefas, numa idéia de entender o que precisava fazer para atingir aquele objetivo.

Mesmo nos casos onde não tinha a menor idéia de como resolver, como: tirar carteira de motorista internacional, lançava as atividades possíveis como “entender o processo de tirar carteira de motorista internacional”. Coisas como “tirar o visto”, lançava os formulários que tinha que preencher, os documentos que tinha que providenciar, as perguntas que tinha que fazer e as incertezas que tinha que eliminar.

Quebrei a complexidade das coisas definindo sprints. Criei uma primeira sprint com as coisas prioritárias para tornavam o processo viáveis. Nessa sprint entraram: visto, cachorro, pedir demissão e vender carro.

Depois fechei uma segunda sprint com as coisas que precisava viabilizar no processo da mudança. Casa, despedidas, onde ficar temporariamente, vôo.

Por último, deixei as coisas que só poderia resolver quando chegasse no outro país como: carro (se ia querer ou não) e alugar casa

O que é interessante é que a partir do momento que você comecei a definir objetivos menores para atingir um objetivo maior, definir atividades concretas e priorizar, a confusão mental decorrente de toda a incerteza existente no processo começou a ser eliminada. Toda a energia que era gasta com ansiedade e dúvida, passou a ser gasta em resolver de fato os problemas. O simples exercício de tomar notas, tirar as coisas da cabeça e torná-las tangíveis num backlog, abriu o espaço necessário para encontrar soluções.

O processo de quebrar em sprints me ajudava a manter o foco. De nada adiantava eu investir esforço no que estava na 2a ou 3a sprint sem resolver os problemas da primeiro. Isso me ajudava a lidar com a procrastinação. Aquelas coisas importantes, porém chatas de resolver, ficavam evidentes.

Isso foi determinante para viabilizar o objetivo de mudar para o exterior. A medida que eu atacava os problemas conforme a prioridade definida e encontrava as próximas atividades para as coisas que não sabia de antemão, mais aprendia sobre o processo e mantinha o controle dos próximos passos. Isso foi gerando um círculo virtuoso.

Em alguns meses, pouco a pouco, todos os obstáculos foram removidos. Quando menos percebi, estava dentro do avião pronto para recomeçar do outro lado do oceano. Meus agradecimentos ao mindset ágil por essa conquista.

E qual a relação de mudar para fora do país com metodologias ágeis no contexto de desenvolvimento de software?

Todo projeto de fazer um novo software é cheio de incertezas. Você precisa entregar algo que não sabe o que é, que provavelmente nunca foi feito antes, com tecnologias que você não conhece direito e com pessoas que nunca trabalhou antes. O primeiro passo é reconhecer claramente tudo isso. Saber o que fazer é provavelmente cerca de 50% do processo.

Quando você encara isso de uma maneira direta, sincera e honesta, move seu cérebro no sentido da solução. Sua cabeça foca em qual é a melhor alternativa que tem em mãos para atacar cada um desses objetivos. Se você simplesmente tentar prever todas as variáveis possíveis até o final do projeto, vai gastar muito mais energia que possui e provavelmente jogar a toalha no meio do caminho. Vai gastar tanto tempo tentando montar um plano infalível que vai acabar não executando nada deste plano por falta de tempo.

Vai ficar o tempo inteiro tentando fazer a realidade se encaixar no seu plano e não planejar de acordo com a as possibilidades existentes.

No final das contas, acho que é isso que as metodologias ágeis me ensinaram: como lidar com incertezas com naturalidade.

Sobre morar e trabalhar no exterior

Pessoal,

Recentemente, comecei uma nova oportunidade profissional, agora em outro país.

Para não misturar assuntos desse blog (profissional, para desenvolvedores) com outros assuntos, criei um blog separado, o “4 malas e o mundo” (4malas.com.br) para compartilhar um pouco das outras experiências de viver aqui (na Inglaterra).

O primeiro post: Como arrumar emprego na Inglaterra já é um que é interessante para os dois blogs. Terão vários cross-posts.

Caso interesse, apareçam por lá! Aproveitem e cliquem bastante nos Ad’s do outro blog para me ajudar a financiar a empreitada!

Abraço,

Eric

TDC 2014

Pessoal,

Novamente fui convidado para palestrar no TDC este ano (The Developers Conference) que será na universidade Anhembi-Morumbi. O evento começa em 06/08/2014 e termina em 09/08/2014.

Estarei palestrando na sexta-feira, dia 08/08 na trilha Arquitetura.NET. Esse ano o tema é “A influência dos processos de desenvolvimento na arquitetura”.

Se estiver no evento, será muito produtivo um bate papo presencial sobre tecnologia ou outros temas abordados aqui no blog.

Até lá!

Joseph Yoder no Brasil

6a0120a85dcdae970b012877701400970c-piJoseph Yoder estará ministrando um curso de TDD e Refactoring no Brasil!

Pra quem não conhece o Yoder, ele é um dos fundadores da Refactory, Inc., ao lado do Ralph Johnson e associados como a Rebecca Wirfs-Brock.

Sim, o Ralph Johnson, é um dos quatro da Gang-of-Four, autores do Design Patterns: Elements of Reusable Object-Oriented Software, na minha opinião, uma das pedras fundamentais da nossa profissão.

Em resumo, uma oportunidade talvez única realizar esse curso e conhecer uma figura ímpar como o Yoder. As inscrições podem ser feitas neste link

Open Source – Usar ou não usar?

Introdução

Já faz bastante tempo que software open source existe. Talvez um dos maiores responsáveis por isso tenha sido o sistema operacional Linux que contribuiu para a popularização do modelo.

Apesar disso, ainda vemos muitas empresas e pessoas com certos medos em adotar soluções baseadas em código aberto. Minha idéia com esse post é compartilhar algumas experiências reais que tive com open source no decorrer da carreira.

Para conhecer um pouco mais sobre a história do Open Source, vale a pena ler sobre o Richard Stallman, um dos primeiros “ativistas” sobre o assunto. Aviso antecipadamente: ele é polêmico.

Licenças open-source

Talvez a maior dificuldade em adotar open source esteja relacionada com a licença. Como disponibilizar o código fonte de uma aplicação sem perder os direitos sobre ela?

Para solucionar essa idéia, vieram licenças de código livre, como a GPL – General Public Licence, uma das primeiras e mais polêmicas sobre o assunto. A GPL tem uma idéia que qualquer um pode usar e ter acesso ao código fonte de um software licenciado pela GPL, porém, se modificar o código fonte ou fazer aplicações que se utilizem de qualquer binário licenciado sob a GPL, devem também ser licenciados pela GPL (ou seja, também precisam abrir seu código).

Na prática isso significa que se eu fizer uma aplicação que dependa de uma DLL GPL, minha aplicação também precisa ser licenciada pela GPL. Por essa razão, houve muita crítica a esse caráter viral ou “comunista” da licença GPL.

Por esta razão surgiram licenças menos restritivas como a LGPL, MIT, Apache e outras, que permitem modificações ao código fonte e utilização de binários sem necessidade de royalties.

Quando utiliza-se uma aplicação open-source, como um editor de texto ou um software de controle de versão não há essa preocupação tão restritiva com licenças, visto que pode-se usar gratuitamente o software, mas ao desenvolver uma aplicação é muito importante essa preocupação com qual é a licença do componente que se está utilizando.

O oposto ao licenciamento open-source é o que vemos na maioria das empresas comerciais. No modelo comercial, em geral você não “compra” o produto. Você compra o direito de usá-lo em um computador, por uma pessoa, ou um grupo de pessoas, dependendo do tipo de licença comercial que usa. Se tem algum problema, você entra em contato com o suporte e pede para eles resolverem. No caso do open-source, se você é um desenvolvedor, tem a chance de encontrar e resolver os problemas por conta própria.

Como ganham dinheiro com Open Source?

Apesar de muitos desenvolvedores contribuirem gratuitamente com projetos open-source, por questões de aprendizado ou mesmo alavancagem de carreira, a maioria das empresas que lidam com open-source não vivem de luz. Possuem uma estratégia focada em serviços para conduzirem seus negócios. Alguns exemplos que me vem à cabeça são a CollabNet, que inicialmente começou a desenvolver o Subversion, software de controle de versão gratuíto e open source e vende serviços e outros produtos de cloud, alguns baseados no subversion e outros não e também a SpringSource desenvolvedora do framework Spring, muito popular no mundo Java e um pouco menos no mundo .NET. Além de manter o codigo-fonte vendem serviços de consultoria e suporte comercial.

Outras como a Apache Software Foundation mantenedora do servidor http apache (um dos mais populares e mais usados no mundo), são entidades sem fins lucrativos e recebem doações.

Software open source tem qualidade?

Esse é um dos pontos mais interessantes da discussão. Muita gente questiona como um bando de desenvolvedores malucos que escrevem software no tempo livre podem escrever software melhor do que empresas que remuneram seus desenvolvedores. É um ponto polêmico, mas os fatos podem nos ajudar a chegar a uma conclusão:

  • Servidor http: Segundo esta pesquisa, o servidor web Apache (open source) tem mais de 60% de market share, enquanto o próximo da lista não open-source (IIS, da Microsoft), tem pouco menos de 14%.
  • Em pesquisas sobre controle de versão, como esta, esta e a pesquisa feita neste blog mostram uma preferência esmagadora por ferramentas open-source em detrimento de ferramentas “pagas”
  • Estas estatísticas sobre navegadores de internet, mostram que os de código fechado como Internet Explorer e Safari, tem uma fatia insignificante perto dos open-source

Existem diversas outras ferramentas open-source, desde issue-trackers, editores de texto, ambientes completos de desenvolvimento. Existem tanto ferramentas open sources melhores que pagas quanto o contrário. É o caso da suíte Office, que durante décadas continua sendo a mais usada mesmo existindo alternativas open-source.

Em geral, é muito importante saber quem é a comunidade ou a empresa que está por trás dos projetos open-source, isso é fator determinante na qualidade do produto final (o mesmo critério vale para as pagas!).

Há organização nos projetos open-source?

Depende do projeto, é claro. Este site: Ohloh.net possui muitas estatísticas sobre projetos open-source. É interessante ver projetos com centenas, ou até passando de mil colaboradores e pensar como esse pessoal todo trabalha junto, como garantem a qualidade e o roadmap de melhorias dos produtos.

Muitos destes projetos são hospedados em controles de versão e ferramentas de gestão de projetos hospedados na nuvem como o SourceForge (talvez o mais antigo de todos), o Git Hub ou o BitBucket. A maioria destes hosts utilizam justamente o tamanho e a carga dos projetos open-source que hospedam como argumento para vender serviços de hospedagem para outras empresas e alavancar seus modelos de negócio open-source.

Cada projeto possui uma estratégia de colaboração completamente diferente, mas em geral é muito interessante a organização. Vou citar alguns exemplos práticos de situações que já contribuí.

Projeto Indy

Até me assustei quando encontrei o site do Indy. Pra quem não viveu essa época, eram componentes Delphi para acesso à internet, coisas como http, ftp, e vinham junto com o Delphi, mas eram (ou são?) desenvolvidos por uma comunidade.

Numa dada situação (se me lembro bem, em 2005), precisei de um tipo de request não suportado pelo componente. Fui lá e escrevi a minha classe para resolver o problema e todo feliz e contente fui contribuir com o projeto. Recebi uma negativa polida porque meu código estava totalmente fora do padrão de qualidade deles. Foi frustrante.

SVN::Notify

Em idos de 2006, na minha primeira subida de um servidor Subversion na vida, queria um script para notificação dos commits, bonitinho, igual o cvsnotify que eu já usava a alguns anos. Encontrei o SVN::Notify, feito em Perl e fui todo feliz e contente instalar em Windows. Não funcionava nem com reza brava.

Entrei em contato com o autor e ele me respondeu: Windows? Eu não tenho o menor interesse de fazer o script funcionar em Windows. Se quiser, faça você mesmo.

Foi o que eu fiz. Baixei o fonte, e com toda a minha habilidade de programar em Perl (praticamente nula), corrigi o script. Fiz um “patch”, porque não tinha direito de commit no repositório dele e ele aceitou a modificação. Foi minha primeira contribuição para um projeto open source. Recentemente, instalei um novo servidor SVN e usei novamente o SVN::Notify. Fiquei feliz da vida por saber que ele ainda funcionava em Windows.

Spring.NET

Em 2007, trabalhei num projeto em Spring.NET. Como todo early adopter, tive problema com um bug. Baixei o código-fonte e rapidamente consegui rastrear que era um bug.

Entrei em contato com a lista de discussão dos desenvolvedores e rapidamente o problema foi reconhecido como um bug e registrado no issue tracker. No mesmo dia, recebi um patch com uma correção paliativa do problema e um mês depois a versão oficial foi lançada, incorporando a correção final.

FluentCodeMetrics e MSBuild.Community.Tasks

O FluentCodeMetrics é uma biblioteca .NET para ajudar na extração de métricas de código e o MSBuild.Community.Tasks uma biblioteca de tasks para o MSBuild.

Em ambos os casos foram algumas contribuições bem simples em situações que foi muito mais simples eu contribuir para um projeto já existente do que tentar criar outro e popularizá-lo.

Por serem repositórios hospedados no Git Hub, seguem o fluxo do próprio Git Hub: Você faz uma cópia do repositório para você (Fork), altera o seu repositório, entrega a contribuição no seu repositório no Git Hub (push) e avisa o autor que existe uma contribuição ali e pede pra ele pegar sua contribuição (Pull Request). Se ele quiser, ele incorpora no repositório principal.

Alguns exemplos de pull request: Issue corrigida no FluentCodeMetrics e Nova task GitVersion no MSBuild.Community.Tasks.

Jenkins

Essa é uma contribuição simples e recente, mas que ilustra um pouco do espírito de organização dos times open-source. O Jenkins é um servidor de integração contínua, provavelmente um dos mais populares e mais usados. Por isso provavelmente a melhor organização.

Encontrei um bug num dos seus plugins (build pipeline) que estava me atrapalhando um pouco. Consultando no issue tracker deles, percebi que já existia um bug aberto sobre o assunto.

Eu não sou especialista em Java, mas de nada custava dar uma olhadinha no Bug. Baixei um netbeans, fiz o fork do repositório no git hub, em algo em torno de 2h consegui encontrar o bug e corrigi. Fiz o pull request.

O supreendente é o comentário que veio no pull request: plugins » build-pipeline-plugin #82 SUCCESS. This pull request looks good.

Rapidamente percebi que o meu pull request, disparou um processo de integração contínua, que roda num Jenkins na nuvem. Lá, os testes unitários e de aceitação foram executados e o serviço automaticamente comentou o pull request avisando que ele “parece bom”. Mesmo assim, o pull request não subiu imediatamente para o repositório oficial. Na seqüência um colaborador do time do Jenkins fez o merge.

Como é a organização do seu time?

Conversando com diversos profissionais na área, percebemos que o uso eficiente de uma ferramenta de controle de versão infelizmente é algo ainda raro, integração contínua um desejo e testes unitários e de aceitação um tabu.

É claro que existem times que praticam tudo o que foi visto nesse exemplo do Jenkins assim como existem projetos open-source de uma pessoa só ou abandonados, mas se investigarmos um pouquinho mais, veremos que na maioria dos projetos mais ativos open-source, essas práticas são requisitos básicos para garantir a qualidade do produto final. Isso me faz acreditar, empiricamente, que a organização de times open-source é muito superior que a média, servindo de referência para times grandes, complexos e geograficamente distribuídos.

Mesmo em empresas que diferentes times de desenvolvimento conduzem produtos diferentes e um encontra problemas ou oportunidades de melhoria no código do outro, nunca vi um mecanismo como os pull requests do Git Hub para simplificar o processo de proposta e aceitação da correção ou melhoria.

E o suporte?

Sempre que surge uma discussão sobre adotar ou não open source, esse ponto é colocado na pauta. E o argumento mais utilizado é: Eu prefiro pagar para usar o software porque posso processar alguém se algo der errado.

Já ouvi isso incontáveis vezes. Em todos os exemplos que citei acima, consegui resolver o problema por conta própria. As razões disso são muito simples:

  • Projetos open-source são muito utilizados. A quantidade de informações existentes em blogs, sites de perguntas e respostas com o Stack Overflow é impressionante. Ferramentas pagas, de menor utilização possuem menos material de referência
  • Projetos open-source possuem listas de discussão ativas. Todas as vezes que tive algum problema e o comuniquei de forma respeitosa e com evidências em listas de desenvolvimento, fui prontamente atendido.
  • Ter o código fonte em mãos simplifica a localização e correção de bugs
  • Se tudo mais der errado e o grupo de desenvolvedores sumir, você pode dar continuidade na manutenção do código-fonte e outro grupo provavelmente o fará

Além desses pontos, vale lembrar que muitas ferramentas open-source possuem empresas que dão suporte comercial. Existe também muitas gigantes que embarcam software open-source junto com partes de software comercial. É o caso da IBM que utiliza Eclipse (open source) como base para a interface de diversos de seus produtos (toda a suite Rational por exemplo) e o caso da Oracle que a algum tempo atrás embarcava o servidor http Apache como parte de alguns de seus produtos (não sei ao certo se ainda é assim).

Na contramão, tive duas experiências muito interessantes com suportes comerciais de gigantes de software. Obviamente não vou citar o nome das empresas.

Numa situação, estávamos desenvolvendo uma aplicação em cima de uma API e tivemos problemas na utilização desta API. Acionamos o suporte “gold” que tínhamos direito e após umas duas semanas, o problema escalou para o segundo nível, sem solução. Após um mês, para o terceiro nível. Depois de um mês brigando com o bug, acabei encontrando sozinho a causa raiz dele e uma solução de contorno. Resolvi não comunicar o suporte que tinha encontrado a solução, para ver quanto tempo demorariam para me dar um retorno. Após 3 meses acompanhando a situação sem receber qualquer resposta, desisti de acompanhar o problema.

Numa outra situação, encontrei um bug no driver de um produto. Entrei em contato com o suporte e a primeira reação deles foi tentar desqualificar o bug, dizendo que o driver não fazia parte do produto, logo, não dariam suporte. Após convencê-los que o problema estava numa DLL fornecida no pacote de instalação do cliente do produto, se convenceram. A segunda reação foi argumentar que não era um bug. Após enviar uma boa quantidade de traces que não deixavam qualquer dúvida sobre a existência do problema, continuei não recebendo nenhum bug fix, patch ou correção. Após cada pedido de solução uma nova quantidade de traces era pedida. Desisti de acompanhar o problema após 5 meses de discussão e conseguir uma solução de contorno que não resolve totalmente o problema. Apenas faz com que ele ocorra com uma incidência menor.

Em todas essas situações que vivi, nunca vi qualquer intenção de processar qualquer um dos fornecedores pelos prejuízos causados.

Por outro lado, cada vez mais vemos gigantes que sempre tiveram fama de serem “fechadas” como a Microsoft, com iniciativas estratégicas baseadas em open source. Com o objetivo de aproveitar os feedbacks e contribuições da comunidade de desenvolvedores, a Microsoft abriu o código fonte de alguns de seus projetos, como o Signal R e também o projeto Roslyn. O Roslyn é simplesmente a plataforma de compiladores C# e VB.Net (!).

Conclusão

O modelo de software open-source (com e sem fins lucrativos) está presente e em pleno crescimento. Cada vez mais soluções open-source são adotadas em cenários críticos e não críticos.

Algumas empresas estão visualizando o diferencial competitivo que o modelo oferece, tanto empresas consumidoras de TI, com o objetivo de minimizar custos ou obter melhor valor agregado nos serviços quanto empresas fornecedoras de TI, com o objetivo de acelerar o desenvolvimento (usando componentes) como prestar serviços baseado em plataformas open. Outras empresas continuam resistindo ou mesmo ignorando o modelo. Acredito que a maioria delas por pura falta de conhecimento sobre bons cases de sucesso utilizando ferramentas open e desconhecimento do modelo de operação/desenvolvimento.

Pelas experiências que já passei, recomendo sempre considerar a utilização de ferramentas open, levando em consideração as questões levantadas no post como licença, suporte, “quem está por trás” do projeto e quem utiliza o projeto (cases). Em resumo, ter as mesmas preocupações que temos quando vamos fazer qualquer investimento.

Integrações entre Sistemas – Parte 16 – Consumo de Web Services Multi-Thread

Introdução

Uma das abordagens comumente usadas para diminuir o tempo total na integração é utilizar várias threads no consumo do serviço. O objetivo é compensar a espera por I/O paralelizando o processamento.

O objetivo desta parte da série (que eu nunca imaginava que chegaria na parte 16) é comparar este método com as demais abordagens.

Alterações no código

O servidor utilizado é o mesmo da parte 4, método síncrono normal. No cliente, tivemos algumas alterações:

        public override bool Execute()
        {
            Binding binding;

            if (this.EndpointType == "http")
            {
                binding = new CustomBinding();
                ((CustomBinding)binding).Elements.Add(new TextMessageEncodingBindingElement(MessageVersion.Soap11, Encoding.UTF8));
                ((CustomBinding)binding).SendTimeout = new TimeSpan(0, 50, 0);
                ((CustomBinding)binding).ReceiveTimeout = new TimeSpan(0, 50, 0);
                ((CustomBinding)binding).OpenTimeout = new TimeSpan(0, 50, 0);
                ((CustomBinding)binding).CloseTimeout = new TimeSpan(0, 50, 0);
                HttpTransportBindingElement element = new HttpTransportBindingElement();
                element.MaxReceivedMessageSize = 2048 * 1024;
                element.KeepAliveEnabled = false;
                element.RequestInitializationTimeout = new TimeSpan(1, 0, 0);
                ((CustomBinding)binding).Elements.Add(element);
            }
            else if (this.EndpointType == "nettcp")
            {
                binding = new NetTcpBinding();
                ((NetTcpBinding)binding).MaxReceivedMessageSize = 1024 * 1024;
                ((NetTcpBinding)binding).Security.Mode = SecurityMode.None;
                ((NetTcpBinding)binding).CloseTimeout = new TimeSpan(0, 50, 10);
                ((NetTcpBinding)binding).OpenTimeout = new TimeSpan(0, 50, 10);
                ((NetTcpBinding)binding).ReceiveTimeout = new TimeSpan(0, 50, 10);
                ((NetTcpBinding)binding).SendTimeout = new TimeSpan(0, 50, 10);
            }
            else
                throw new ArgumentException("Invalid value for EndpointType. Expected: http, nettcp");
            EndpointAddress address = new EndpointAddress(new Uri(WebServiceUri));

            IntegrationTestsService.IntegrationTestsServiceClient client = new IntegrationTestsService.IntegrationTestsServiceClient(binding, address);

            Log.LogMessage("Doing " + TotalBatches.ToString() + " batch calls with " + BatchSize.ToString() + " itens each");

            Stopwatch watch = new Stopwatch();
            watch.Start();

            int count = 1;
            ConcurrentQueue<ManualResetEvent> waitObjectQueue = new ConcurrentQueue<ManualResetEvent>();
            Task task = null;
            for (int i = 0; i < TotalBatches; i++)
            {
                int start = count;
                int end = count + (BatchSize - 1);
                count += BatchSize;
                
                if (UseTask)
                {
                    task = Task.Factory.StartNew(() => {
                        ThreadJob(client, waitObjectQueue, start, end);
                    });                    
                }
                else
                {
                    Thread thread = new Thread(() => {
                        ThreadJob(client, waitObjectQueue, start, end);
                    });
                    thread.Start();
                }
            }

            if (task != null)
                task.Wait();

            while (waitObjectQueue.Count > 0){
                ManualResetEvent e;
                if (waitObjectQueue.TryDequeue(out e))
                    e.WaitOne();
            }

            watch.Stop();
            Log.LogMessage("Total processing time: " + watch.Elapsed.TotalSeconds.ToString("0.00") + " seconds");

            return true;
        }

        private void ThreadJob(IntegrationTestsService.IntegrationTestsServiceClient client, ConcurrentQueue<ManualResetEvent> waitObjectQueue, int start, int end)
        {
            ManualResetEvent e = new ManualResetEvent(false);
            waitObjectQueue.Enqueue(e);

            ServiceTable[] stArray = client.GetServiceTables(start, end);
            foreach (ServiceTable t in stArray)
            {

                ServiceTable t2 = new ServiceTable();
                t2.ServiceTableID = t.ServiceTableID;
                t2.DescServiceTable = t.DescServiceTable;
                t2.Value = t.Value;
                t2.CreationDate = t.CreationDate;
                t2.StringField1 = t.StringField1;
                t2.StringField2 = t.StringField2;

                DAO.ProcessServiceTable(ConnString, t2);
            }
            e.Set();
        }

A propriedade UseTask, determina se o trabalho será feito numa Task ou Thread. A diferença entre usar uma task ou uma thread é explicada no post programação paralela – parte 1. Na prática, para este exemplo, vemos que não fará muita diferença na prática.

O objetivo do código é simples. Cada lote de requisições (mesmo cenário utilizado em todas as partes dessa série) é executada numa thread ou task separada. Teremos por um lado o ganho de não esperar a requisição terminar para começar outra e pelo outro o custo da troca de contexto e alocação de memória em threads (explicados na parte 2 e parte 3 da série sobre programação paralela. Outro ponto é a sobrecarga por mais processamento paralelo gerado no servidor.

Resultados

Abaixo seguem os resultados desta abordagem, executada tando em SOAP quanto em NET.TCP. O mesmo método é utilizado para computar os tempos, ou seja, são feitas 10 execuções e o tempo apresentado abaixo é a média deles.

pt16-Comparativo1

pt16-Comparativo2

Como os números mostram, o uso de threads ou tasks não faz praticamente nenhuma diferença neste caso. Minha melhor explicação para isso é que o TaskScheduler utilizado para delegar as tasks abre uma nova thread sempre que identifica que as demais estão em espera (ninguém está consumindo CPU). Como existe muito bloqueio de espera por I/O num cenário de integração destes, a Task Parallel Library acaba abrindo uma nova thread quase sempre.

Os números também mostram que o uso da abordagem async/await (parte 15 da série de integrações e parte 4 da série de programação paralela) é ~53% mais eficiente em SOAP e ~39% mais eficiente em NET.TCP.

Código fonte

O código fonte dos exemplos está atualizado no Git Hub: https://github.com/ericlemes/IntegrationTests

Conclusão

O aproveitamento do tempo de espera por operações de I/O mostra ser a melhor maneira de aumentar o desempenho das aplicações. A implementação do padrão async/await no framework .NET, cada vez mais mostra ser uma forma extremamente simples de atingir este objetivo. Realmente é um trabalho fantástico por parte da Microsoft.

Integrações entre Sistemas – Parte 15 – Web Service (Async) com Servidor Síncrono

Introdução

Após uma conversa interessante com o Roger Luiz Pereira (grande desenvolvedor e amigo de trabalho) no escritório, alguns questionamentos interessantes foram levantados sobre os métodos.

Um deles está relacionado com o quanto de desempenho a implementação com async/await no lado do servidor contribui no desempenho. O objetivo deste post é contemplar este cenário nos trabalhos.

Método

Para testar esse cenário, utilizei exatamente a mesma implementação do cliente utilizada na parte 14 para o lado do cliente, com um parâmetro a mais para utilizar o servidor síncrono (método GetServiceTablesAsync), invés do servidor assíncrono (GetServiceTablesAsynchronousAsync). A implementação síncrona é a mesma utilizada na parte 4.

Resultados

A mesma metodologia é usada nestes números. Os testes são executados 10 vezes e o resultado apresentado aqui é a média dos 10. Os resultados seguem na tabela abaixo:

pt15-Comparativo1

pt15-Comparativo2

Conclusão

Como vemos, a implementação do servidor assíncrona trás benefícios tangíveis no desempenho total. Para NET.TCP: ~37% mais rápido e para SOAP ~43% mais rápido.

Código-fonte

O código-fonte de todos os exemplos está atualizado no Git Hub: https://github.com/ericlemes/IntegrationTests

Integrações entre Sistemas – Parte 14 – Web Service (Async)

Introdução

Com a evolução do framework e a implementação do modelo Async/Await, fiquei curioso sobre como seria o desempenho em relação aos demais métodos de integração já apresentados nas demais partes desta série (Ver o Índice para localizar as demais).

O que muda na implementação?

Basicamente, peguei a mesma implementação usada na parte 4 para SOAP e NET.TCP e converti todas as chamadas, do cliente e do servidor para o modelo async/await. Na série sobre programação paralela (parte 4), expliquei no que consiste o modelo e a razão dos ganhos de desempenho apresentados por ele.

No código servidor, fizemos as seguintes alterações:

        public List<ServiceTable> GetServiceTablesAsynchronous(int IDInicial, int IDFinal)
        {
            if (String.IsNullOrEmpty(connString))
                GetConnString();
            List<ServiceTable> l = new List<ServiceTable>();
            Queue<Task<ServiceTable>> queue = new Queue<Task<ServiceTable>>();
            for (int i = IDInicial; i <= IDFinal; i++)
                queue.Enqueue(DAO.GetServiceTableAsync(connString, i));

            while (queue.Count > 0)
            {
                Task<ServiceTable> task = queue.Dequeue();
                task.Wait();
                l.Add(task.Result);
            }
            return l;
        }

A idéia do código acima é que cada chamada que vai no banco de dados é executada de forma assíncrona, sendo que a chamada subsequente não espera o término dela para fazer a próxima requisição ao banco. Por isso é usada uma Queue para guardar todas as tasks e aguardar o término delas antes de retornar a resposta a quem chamou o serviço externamente.

Óbvio que seria muito mais eficiente fazer a query, assíncrona com todo o lote de uma vez só, mas para manter o mesmo cenário utilizada nas 13 partes anteriores dessa série, utilizei essa abordagem.

A chamada ao banco, tem a seguinte implementação:

        public static async Task<ServiceTable> GetServiceTableAsync(string ConnString, int ServiceTableID, TaskLoggingHelper Log)
        {
            ServiceTable result = new ServiceTable();

            SqlConnection conn = new SqlConnection(ConnString);
            conn.Open();

            SqlCommand cmd = new SqlCommand("select ServiceTableID, DescServiceTable, Value, CreationDate, StringField1, StringField2 " +
                    "from ServiceTable where ServiceTableID = @ServiceTableID", conn);

            using (conn)
            {
                SqlParameter p1 = cmd.Parameters.Add("@ServiceTableID", SqlDbType.Int);
                p1.Value = ServiceTableID;

                SqlDataReader rd = await cmd.ExecuteReaderAsync();
                rd.Read();
                using (rd)
                {
                    result.ServiceTableID = rd.GetInt32(0);
                    result.DescServiceTable = rd.GetString(1);
                    result.Value = (float)rd.GetDouble(2);
                    result.CreationDate = rd.GetDateTime(3);
                    result.StringField1 = rd.GetString(4);
                    result.StringField2 = rd.GetString(5);
                }
            }

            if (Log != null)
                Log.LogMessage("Getting ServiceTableID: " + ServiceTableID.ToString());

            return result;
        }

A principal mudança no código foi “await cmd.ExecuteReaderAsync();”. Basicamente utilizando novamente o modelo assíncrono para cada cutucada no banco de dados.

No código do cliente, utilizamos o stub do WCF em sua versão assícrona. Basicamente, ao adicionar as referências, utilizamos as opções:

ServiceRef1

ServiceRef2

Os métodos gerados para o serviço WCF ganham o sufixo “Async” no final e os mesmos retornam Tasks, invés das tradicionais implementações síncronas.

O consumo deles foi escrito da seguinte maneira:

            int count = 1;
            Queue<Task<ServiceTable[]>> tasks = new Queue<Task<ServiceTable[]>>();            
            for (int i = 0; i < TotalBatches; i++)
            {
                tasks.Enqueue(client.GetServiceTablesAsynchronousAsync(count, count + (BatchSize - 1)));                
                count += BatchSize;
                
            }

            Queue<Task> queue2 = new Queue<Task>();

            while (tasks.Count > 0)
            {                
                Task<ServiceTable[]> task = tasks.Dequeue();
                                
                task.Wait();
                ServiceTable[] stArray = task.Result;

                foreach (ServiceTable t in stArray)
                {

                    ServiceTable t2 = new ServiceTable();
                    t2.ServiceTableID = t.ServiceTableID;
                    t2.DescServiceTable = t.DescServiceTable;
                    t2.Value = t.Value;
                    t2.CreationDate = t.CreationDate;
                    t2.StringField1 = t.StringField1;
                    t2.StringField2 = t.StringField2;

                    queue2.Enqueue(DAO.ProcessServiceTableAsync(ConnString, t2));
                }                
            }

            while (queue2.Count > 0)
                queue2.Dequeue().Wait();

A idéia é muito similar ao lado do servidor. Enquanto eu ainda não recebi a resposta para processar, continuo enviando requisições. Ao terminar de enviar todas as requisições, espero a primeira resposta, e vou processando o resultado de cada uma delas.

O nome do método GetServiceTablesAsynchronousAsync ficou bem estranho, porque minha falta de criatividade colocou o sufixo “Asynchronous” no nome do método no servidor (para diferenciar do outro método, síncrono) e ao gerar a chamada do método, o WCF adicionou o sufixo Async novamente.

O método que vai no banco de dados, do lado do cliente também foi implementado de forma assíncrona:

        public static async System.Threading.Tasks.Task ProcessServiceTableAsync(string ConnString, ServiceTable table)
        {
            SqlConnection conn = new SqlConnection(ConnString);
            conn.Open();

            SqlCommand cmd = new SqlCommand("insert into ClientTable (ClientTableID, DescClientTable, Value, CreationDate, StringField1, StringField2)" +
                    "values (@ClientTableID, @DescClientTable, @Value, @CreationDate, @StringField1, @StringField2)", conn);

            using (conn)
            {

                SqlParameter p1 = cmd.Parameters.Add("@ClientTableID", SqlDbType.Int);
                SqlParameter p2 = cmd.Parameters.Add("@DescClientTable", SqlDbType.VarChar, 200);
                SqlParameter p3 = cmd.Parameters.Add("@Value", SqlDbType.Float);
                SqlParameter p4 = cmd.Parameters.Add("@CreationDate", SqlDbType.DateTime);
                SqlParameter p5 = cmd.Parameters.Add("@StringField1", SqlDbType.VarChar, 200);
                SqlParameter p6 = cmd.Parameters.Add("@StringField2", SqlDbType.VarChar, 200);

                p1.Value = table.ServiceTableID;
                p2.Value = table.DescServiceTable;
                p3.Value = table.Value;
                p4.Value = table.CreationDate;
                p5.Value = table.StringField1;
                p6.Value = table.StringField2;

                await cmd.ExecuteNonQueryAsync();
            }
        }

O segredo aqui está em ExecuteNonQueryAsync. Isso significa que antes de receber a resposta do insert, já estou preparando o próximo insert.

A implementação toda tem por objetivo eliminar toda a espera entre cliente e servidor.

Tempos de execução

Como novamente tive mudanças no meu ambiente, fui obrigado a refazer os tempos. Como são muitos números e demora algumas preciosas horas reexecutá-los fiz apenas alguns métodos para conseguirmos ter uma relação de comparação com os demais métodos. A metodologia é a mesma. Cada teste é executado 10 vezes e o tempo apresentado aqui é a média.

Temos os seguintes tempos:

Comparativo1

Comparativo2

Como observamos, a implementação de NET.TCP ficou mais rápida que o meu antigo socket server multi thread! Até os métodos estudados, este era o mais rápido e mais complexo de implementar.

Isso significa que agora vou ter que reimplementar os servidores TCP puros novamente, utilizando dos mesmos benefícios do async/await. Quem sabe num post futuro?

Conclusão

A Microsoft fez um belo trabalho na implementação dessas API’s baseadas em async/await. Conseguiu tornar muito simples a aplicação prática de um conceito de difícil implementação.

Era isso!

Programação Paralela – Parte 4 – I/O Assícrono com Async/Await

Introdução

Na parte 3 desta série, vimos como o I/O assíncrono pode ser mais eficiente, liberando a CPU da thread que espera por I/O para fazer outra atividade, aumentando o desempenho geral da aplicação.

Vimos também como essa implementação pode ser complexa. O objetivo deste post é mostrar como as novas features de async/await, implementadas no framework 4.5 podem simplificar este processo.

Utilizando o async/await

No exemplo anterior, utilizamos um método que faz uma grande escrita em disco, seguida de um grande processamento. Vamos recriar este exemplo, utilizando o padrão async/await.

        [TestMethod]
        public void BigAsyncIOTest2()
        {
            Stopwatch watch = new Stopwatch();
            watch.Start();
            
            for (int i = 0; i &lt; 10; i++)            
                DoBigWriteAsync().Wait();
            
            watch.Stop();
            Console.WriteLine(&quot;Total elapsed (ms): &quot; + watch.ElapsedMilliseconds);
        }

        private async Task DoBigWriteAsync()
        {
            FileStream fs = new FileStream(&quot;file1.txt&quot;, FileMode.Create, FileAccess.ReadWrite);
            byte[] buffer = new byte[100 * 1024 * 1024]; //Não faça isso. Aloca 100Mb de memória.                        
            Task t = fs.WriteAsync(buffer, 0, buffer.Length);           
            Task t2 = t.ContinueWith(new Action((task) =&gt; { 
                fs.Flush();
                fs.Close();
            }));
            BubbleSort.DoBigBubbleSort(10000, null);
            await t;            
        }

O método DoBigWriteAsync teve um modificador “async” iniciado e um “await t” inserido no final. O método WriteAsync implementado pela classe Stream, provê os mesmos mecanismos. Na verdade em nível mais baixo da API é ele quem faz o tratamento da chamada de I/O assícrono.

Na prática, o que acontece nesta implementação é que cada vez que WriteAsync é chamado, uma continuação é inserida (para dar o Flush e o Close na Stream) e o BubbleSort é iniciado. Somente quando ocorre o “await t”, é aguardado o término do I/O para que o método devolva o resultado.

Na prática, o tempo que o método ficou parado com “await” não travou a thread da aplicação e sim a disponibilizou para executar outras atividades enquanto o I/O está em andamento. Aí está toda a mágica e a simplicidade do async/await. Você escreve um método com a mesma característica e simplicidade que escreve um método sícrono, porém, o framework não travará a thread.

Qual o desempenho?

Pelos testes muito simples executados nesta série, podemos perceber que há um overhead em relação ao método assíncrono puro (utilizado na parte 2 da série). O método executou em 13835 milisegundos, contra 9111 milisegundos da implementação pura. Meu palpite é que este overhead ocorre devido à mecânica da Task Parallel Library que exploraremos em seguida.

Quais as vantagens de usar?

Praticamente todas as API’s de I/O no framework estão sendo reescritas para suportar este padrão, entre elas: Acesso HTTP, Sockets, Web Services, Banco de dados (DataReader), etc. A lista completa está em: http://msdn.microsoft.com/pt-br/library/hh191443.aspx.

Você pode fazer, com baixo esforço, sua aplicação sofrer muito menos com problemas de responsividade e espera por I/O. Somente no exemplo acima, partimos de 20 segundos numa implementação totalmente síncrona para 14 segundos, basicamente trocando keywords nos métodos.

Como funciona?

Sempre que um método assíncrono (Ex.: WriteAsync) é chamado, o mesmo inicia a operação de I/O e cria uma Task que somente conclui quando o retorno do callback avisando que a operação de I/O terminou. Ou seja, quando o callback termina, a task é marcada como concluída. Nenhuma nova thread (worker thread) é criada neste processo. Este é um dos pontos que mais me gera confusão, pois apesar da classe Task fazer parte do namespace System.Threading, não significa que sempre que uma task é criada a mesma é executada numa thread separada.

Pelo próprio Task Parallel Library, toda nova task, é criada numa TaskFactory padrão, que utiliza um TaskScheduler padrão. O TaskScheduler padrão do framework é um ThreadPoolTaskScheduler. Ele tem um comportamento que a cada nova Task ele delega para seu thread pool a sua execução. Em outras palavras, ele tenta utilizar alguma thread livre do seu thread pool. Se não possui nenhuma, cria uma. Se possui threads demais (maior que a quantidade de cores da máquina), ele aguarda alguma task finalizar e pega uma das threads já criadas.

Com este comportamento, ele consegue manter o maior paralelismo possível, com a menor quantidade de trocas de contexto possível. Esperto, né?

Esse comportamento também proporciona um outro comportamento desagradável que é o fato de não sabermos exatamente em que thread a Task será executada, o que pode trazer potenciais problemas de locks, deadlocks, ou problemas com código não thread-safe sendo executado dentro de uma task. É o preço.

Por isso o overhead imposto acima. Numa execução simples, com a máquina com pouco processamento (cenário deste teste), há um incremento do tempo devido ao overhead imposto pelo processo de escalonamento das tasks. Num cenário de alta carga, o task scheduler deve valer seu preço.

Em contrapartida, sempre que executamos uma operação de I/O assíncrono no modelo async/await, esta task é enfileirada no TaskScheduler. Se ela está aguardando conclusão, a thread que originalmente estaria esperando pega outra Task e a executa. Essa outra task pode ser outra operação de I/O, um pedaço de processamento paralelo utilizado numa expressão PLINQ (parallel LINQ) ou qualquer outro processamento do framework que esteja encapsulado numa task.

Era isso.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 466 outros seguidores

%d blogueiros gostam disto: