90% do código primeiramente desenvolvido representa os primeiros 90% do tempo de desenvolvimento. Os restantes 10% do código são responsáveis por outros 90% do tempo desenvolvimento.
Notas diversas sobre desenvolvimento de software, Software Livre, Linux, Computação em Nuvem e diversas outras tecnologias.
quinta-feira, 29 de novembro de 2007
A regra dos noventa-noventa
Dizem que todo gerente de projeto deve estar bem consciente do significado da regra dos noventa-noventa:
domingo, 11 de novembro de 2007
Restaurando o MBR do Vista
Após instalar o Fedora 8 no meu Laptop, resolvi remover-lo e usar-lo como máquina virtual dentro do Vista. Instalei o VistaBootPro para tentar remover o Grub, mas ele falhou, e eu não conseguia dar mais boot.
O que me salvou foi o Super Grub. Dei um boot por ele, e mandei restaurar o MBR do Windows, além de ativar a partição do Windows, de acordo com as instruções que encontrei num post.
O que me salvou foi o Super Grub. Dei um boot por ele, e mandei restaurar o MBR do Windows, além de ativar a partição do Windows, de acordo com as instruções que encontrei num post.
sexta-feira, 27 de julho de 2007
Bug na Java Native Interface da JVM 1.6
Estava fazendo um protótipo de uma aplicação Delphi carregando a JVM e executando o Tomcat embedded, isso tudo num Windows XP. Utilizei a última versão do JRE, a 1.6.02. Ao carregar o Tomcat, o meu processo era derrubado, e examinando o console, encontrei a mensagem de erro EXCEPTION_FLT_STACK_CHECK.
Nesse momento, fiquei acreditando que eu estava fazendo algo de errado. Fiz uma pesquisa no Google, e encontrei apenas um tópico do fórum java com esse erro, aonde a pessoa menciona que o erro se apresentou quando ele migrou seu código da JVM 1.5 para a versão 1.6.
Fiz o caminho inverso, e voilá, tudo funcionou perfeitamente.
Nesse momento, fiquei acreditando que eu estava fazendo algo de errado. Fiz uma pesquisa no Google, e encontrei apenas um tópico do fórum java com esse erro, aonde a pessoa menciona que o erro se apresentou quando ele migrou seu código da JVM 1.5 para a versão 1.6.
Fiz o caminho inverso, e voilá, tudo funcionou perfeitamente.
quinta-feira, 24 de maio de 2007
Tendências em Linguagens de Programação
É muito importante para uma linguagem de programação a existência de uma comunidade forte. Essa premissa vale não só para linguagens de programação, mas para qualquer tipo de linguagem. Quando o número de pessoas usando uma linguagem é pequeno, essa linguagem está ameaçada de extinção.
Utilizo diversos indicadores para tentar identificar essas tendências:
Utilizo diversos indicadores para tentar identificar essas tendências:
- O número de hits no Google Search.
- O Google Trends.
- O Freshmeat.
- TIOBE Programming Community index.
Bug no Ubuntu: Falha no Power Off ao final do Shutdown
Ao fazer o upgrade do meu Ubuntu 6.06 lts para o novo Ubuntu 7.04, minha máquina parou de se desligar no shutdown. Após uma pesquisa encontrei a solução no fórum:
Adicionar a seguinte linha no /etc/modules.
Adicionar a seguinte linha no /etc/modules.
apm power_off=1
sexta-feira, 20 de abril de 2007
Investigando o consumo de memória do Engine
Estou investigando o consumo de memória da nova versão do Engine 4(ainda em beta), que está demasiadamente alto em algumas situações. Estou utilizando o excelente AQTime, que felizmente possui um profiler específico de uso de memória.
No Engine 4, o JavaScript Runtime realiza alguns truques para aumentar a performance, como por exemplo não chamar o destrutor de objetos que não necessitem de um clean up. Entretanto esse comportamento confunde o profiler do AQTime, passando a ser desativado no momento do profile.
Com o profiler, eu posso observar num determinado momento a quantidade de objetos de uma determinada classe. É interessante essa visão, pois permite de uma maneira mais objetiva, observar objetos que com pequenas alterações permitiriam um grande consumo de memória, tendo um impacto na performance da aplicação.
Estou investigando o consumo de memória da nova versão do Engine 4(ainda em beta), que está demasiadamente alto em algumas situações. Estou utilizando o excelente AQTime, que felizmente possui um profiler específico de uso de memória.
No Engine 4, o JavaScript Runtime realiza alguns truques para aumentar a performance, como por exemplo não chamar o destrutor de objetos que não necessitem de um clean up. Entretanto esse comportamento confunde o profiler do AQTime, passando a ser desativado no momento do profile.
Com o profiler, eu posso observar num determinado momento a quantidade de objetos de uma determinada classe. É interessante essa visão, pois permite de uma maneira mais objetiva, observar objetos que com pequenas alterações permitiriam um grande consumo de memória, tendo um impacto na performance da aplicação.
quinta-feira, 19 de abril de 2007
Stack Trace no Delphi
Nesta semana, trabalhei na implementação do Stack Trace no Engine Runtime. Basicamente, usei a implementação do Jcl. Infelizmente o stack trace não é muito preciso, principalmente quando ele está fazendo o trace de rotinas do interpretador JavaScript, mesmo usando a opção RawTrace, que realiza toda a operação sem confiar na existência de Stack Frames. Acredito que o FastMM utilize a mesma rotina do Jcl.
Internamente, o JclDebug faz um patch no executável em tempo de execução, alterando o System.pas para possibilitar a captura do Stack trace no momento que uma exceção é gerada. Ainda não pude observar o custo de processamente dessa operação de captura.
Além do JclDebug, existem outros projetos, como o FastCode, que requerem o uso de patchs para realizarem otimizações no Delphi. Estive pensando se não seria interessante fazer o patch, em tempo de compilação, ao invés de em tempo de execução. Acredito que fazer o patch da aplicação em tempo de execução iniba um melhor uso da memória virtual por parte do sistema operacional.
Nesta semana, trabalhei na implementação do Stack Trace no Engine Runtime. Basicamente, usei a implementação do Jcl. Infelizmente o stack trace não é muito preciso, principalmente quando ele está fazendo o trace de rotinas do interpretador JavaScript, mesmo usando a opção RawTrace, que realiza toda a operação sem confiar na existência de Stack Frames. Acredito que o FastMM utilize a mesma rotina do Jcl.
Internamente, o JclDebug faz um patch no executável em tempo de execução, alterando o System.pas para possibilitar a captura do Stack trace no momento que uma exceção é gerada. Ainda não pude observar o custo de processamente dessa operação de captura.
Além do JclDebug, existem outros projetos, como o FastCode, que requerem o uso de patchs para realizarem otimizações no Delphi. Estive pensando se não seria interessante fazer o patch, em tempo de compilação, ao invés de em tempo de execução. Acredito que fazer o patch da aplicação em tempo de execução iniba um melhor uso da memória virtual por parte do sistema operacional.
Assinar:
Postagens (Atom)