Como utilizar uma biblioteca de log a seu favor

Eu costumava desenvolver minha própria biblioteca de logs até um dia conhecer o log4net. Com ela os logs passaram a ser muito mais descritivos e úteis, além de mais leves. Passei a fazer log de tudo. Veja quais features do log4net que mudaram a minha forma de programar:

• Xml Configuration. Com apenas uma versão do binário eu posso ter diferentes arquivos de configuração com verbosidades, appenders e formatações diferentes para meu arquivo de log.
• Rolling File Appender. Agora meus arquivos de log têm tamanho limitado, mas sem perder nenhuma informação. Muito útil para ler arquivos de log em editores comuns do Windows, que não funcionam bem com arquivos gigantes.
• Xml Formatter. Inclui todas as informações úteis (stack trace em uma exception por exemplo), e ainda permite que eu monitore o arquivo de log através de uma ferramenta pronta com interface web.
• Debug e Info. Não preciso fazer uma versão específica de depuração, a versão única pode ser configurada com uma verbosidade de acordo com a necessidade. Informações que antes não eram logadas agora são, pois eu sei que isso não diminuirá a performance da minha aplicação de produção.
• Lossy Logging. Posso incluir informações de Debug e Info apenas quando houver um Erro, ele armazena estas informações em um buffer e só gravará no log quando houver um erro.
• Custom Appenders. Eu posso jogar o log aonde eu quiser, enviar por e-mail, jabber, sms, enviar pro event viewer, etc.

Confiram este excelente tutorial de log4net em 15 partes: 

• Iniciando
• Configuração XML
• Appenders
• Layouts e Patterns
• Objetos Logger
• Contexto do evento de log
• Filtros
• Lossy Logging
• Extension Methods
• Práticas recomendadas
• Isolando bugs
• Logs consomem espaço
• Outros tutoriais e recursos
• Twitter Appender
• Personalizando caminhos dos logs após a configuração

Como turbinar seu Visual Studio com Power Commands Add-In

Power Commands é um plugin para qualquer versão do Visual Studio. Ele adiciona dois comandos muito úteis ao menu de contexto (aquele menu que aparece quando você clica com o botão direito):

• Remove and sorting usings for all files in this project. Muito útil para diminuir o tamanho do cabeçalho de cada arquivo, e mantê-los normalizados sem muito esforço. Ajuda também a identificar quais bibliotecas não estão sendo utilizadas.
• Open Windows Explorer in this folder.  Este é o comando mais útil, permite manipular arquivos e também serve como atalho para usarmos o Tortoise.

E tem também outros comandos úteis. Você pode baixá-lo em:

• Power Commands para Visual Studio 2008
• Power Commands para Visual Studio 2010

O que você precisa saber sobre controle de versão distribuído antes de mudar

Você que usa um controle de versão centralizado, exemplos:

• CVS
• SVN Subversion
• VSS Microsoft Visual Source Safe
• TFS Microsoft Team Foundation Server

nunca usou um DVCS (Distributed Version Control System), exemplos:

• GIT, desenvolvido por Linus Torvalds e usado pelo time Linux Kernel
• Mercurial (Hg), para o qual foram desenvolvidas ótimas ferramentas gráficas e é suportado pelo Google Code Project Hosting
• Bazaar
• Darcs

 e pretende conhecer essa tecnologia, precisa saber dos seguintes fatos sobre o DVCS:

• o repositório é descentralizado, mas isso não impede de ter também um repositório central
• o repositório é descentralizado, e isso significa que você pode ter acesso a versões específicas da máquina de um dos desenvolvedores, que não serão publicadas para os demais
• o repositório é sempre local, isso significa que atualizações, reversões e comparações serão sensivelmente mais rápidas, pois não se comunicarão com um repositório remoto
• embora a primeira vez que você clona um repositório pode ser até 50% mais lento, as operações seguintes são mais rápidas
• é mais complexo, pois a recepção é dividida em duas etapas: a sincronização com um repositório remoto (pull) e a atualização da versão a ser editada (update)
• é mais complexo, pois a submissão é dividida em duas etapas: a gravação no repositório local (commit), e a sincronização com um repositório remoto (push)
• essa complexidade pode ser amenizada com configurações que simulem o comportamento dos antigos controles de versão (automatic update e automatic push)
• os merges são mais seguros e simples
• forks, branches e outras ramificações são feitas sem medo, devido à simplificação dos merges
• criar um repositório local exige um simples comando
• com o DVCS você vai encontrar mais usos para o controle de versão, com ele você pode controlar a versão de binários em produção, e de outros arquivos menos importantes do dia a dia para os quais não vale a pena o esforço de configurar um repositório dos SCM centralizados
• DVCS é muito útil quando trabalhando sozinho, e muito mais vantajoso quando em grupo

Como criar aplicações de tempo real

No meu projeto final de Engenharia Eletrônica nós fazemos processamento de tempo real de um sinal de áudio. Inicialmente líamos o sinal da porta de entrada em um loop infinito, e isso fez com que o processamento fosse mais lento que o fluxo do sinal. Com o tempo aprendemos que é necessário:

1. Processar blocos enviados por eventos (interrupções)
2. Configurar a prioridade do processo para tempo real

Existem também outros items que podem se provar úteis

3. Armazenar os dados em um buffer.
4. Configurar a afinidade do processo para apenas um core em uma máquina de múltiplos processadores.

As razões para cada um dos items é explicada a seguir:

1. Interrupções: O processamento deve ser feita em uma thread paralela ao recebimento para que o primeiro não interrompa o segundo. O método de melhor perfomance com este fim é o desenvolvimento orientado a eventos.

2. O Windows escalona os processos de acordo com sua prioridade, se nosso processo de tempo real não estiverem configurados com a prioridade máxima haverão outros processos escalonados antes deles e haverão demoras no processamento. Mas atenção, antes de habilitar este modo tenha certeza de que sua aplicação não possui loops infinitos, ou seja, que ela seja orientada a eventos conforme o passo 1, senão ela tomará conta do processador e não liberará pra nenhuma aplicação de prioridade inferior. Em C# é possível mudar a prioridade do processo atual da seguinte forma

var process = Process.GetCurrentProcess();
process.PriorityClass = ProcessPriorityClass.RealTime;

3. O buffer pode ser uma opção viável quando a necessidade de um fluxo contínuo é superior a necessidade de que este fluxo seja processado o mais cedo possível.

4. A afinidade de processador pode trazer um maior controle sobre a ordenação dos pacotes de saída caso haja um jitter no processamento. Em C# isso é feito assim:

var process = Process.GetCurrentProcess();
process.ProcessorAffinity = (IntPtr)1;

Onde 1 é o primeiro core, 2 seria o segundo core, 3 ambos (sem afinidade), num computador de 2 cores.

Versões do Mono nas distros Linux mais conhecidas e suas limitações

O Ubuntu 10.04 Lucid Lynx LTS foi lançado com pacotes do Mono 2.4. O Mono 2.4 não suporta System.ServiceModel.Web.

O Debian 5.0.4 Lenny, a atual versão stable foi lançado com pacotes do Mono 1.9 que não suporta System.Windows.Forms, nem System.Threading.ReaderWriterLockSlim

O que é prevalência em programação?

Como salvar o estado de uma aplicação entre sessões? Existem várias formas de persistir seus dados. Você pode salvar os objetos em arquivo ou em banco de dados, por exemplo. Quando salvamos em arquivos temos que serializar os dados e decidir quando fazê-lo.

As bibliotecas de prevalência tratam disso para você. As mais famosas são:

• Java http://www.prevayler.org/
• .NET http://bbooprevalence.sourceforge.net/
• .NET http://sourceforge.net/projects/xprevail/

Quando não devo usar "var" no C#?

O palavra chave "var" facilita a vida, mas ela pode ser imprevisível às vezes. Olhe o código abaixo por exemplo:

var a = 2147483647;
var b = 2147483648;
var c = -2147483649;

As três variáveis acima são de tipos diferentes. A primeira é int, a segunda é uint e a terceira é um long.

 

Tornando o Windows ainda melhor

Eu costumava dizer que o Windows não sabia lidar com arquivos gigantes. Se for um arquivo de texto de mais de 100 MB qualquer aplicativo gráfico trava: Bloco de notas, Wordpad, Word, Notepad++, Notepad2, EditPad, you name it. Então eu usava as ferramentas básicas do Linux para tratar estes arquivos: wc, sed, grep, etc.

Mas recentemente descobri que estas ferramentas também estão disponíveis para Windows. Estão no pacote Core Utils da gnuwin32.

http://gnuwin32.sourceforge.net/packages/coreutils.htm

Porque escrever testes primeiro

A primeira regra do desenvolvimento dirigido por testes (TDD), também conhecido como programação orientada a testes, é "Escreva os testes primeiro". Esta regra, em conjunto com as outras duas é essencial para que:

1. Certificar que o teste falha.
2. Os testes executem todos os caminhos possíveis de código.
3. Haja confiança total no código.
4. Evitar depuração.
5. Acelerar mais ainda o desenvolvimento.

Se escrevermos o teste depois, pode haver um problema no teste que o faça passar mesmo que o código testado esteja errado. Uma forma de testarmos o teste é, ao invés de escrever um teste para o teste, ter certeza que o mesmo falha quando a implementação está incorreta.

Se os testes não exercitam cada trecho de código, então este código não testado é legado. O código legado não dá confiança ao programador e é difícil de entender, o que leva ele a usar a depuração (debug). E lembre-se que código não testado é código não documentado, já que os testes são a especificação.

A confiança e o entendimento do código gerado pelo TDD se dão em níveis incomparáveis aos conhecidos fora deste método, vale a pena experimentar. Essa é  uma forma de acelerar mais ainda o desenvolvimento com testes, já que escrevendo testes depois você vai perder tempo debugando não apenas o código mas também o teste.

Para isso não basta escrever os testes antes do código. Também é necessário que:

1. Todo código de produção seja o mais simples possível para fazer passar um teste.
2. Os testes e implementações devem ser feitas em passos de bebê.

Facebook bate a audiência do Google nos EUA, e daí?

O Facebook pode ter batido a audiência do mecanismo de busca do Google nos EUA, mas o faturamento por visitante deste ainda é 6x maior que do primeiro. Veja mais neste outro blog