quinta-feira, 28 de fevereiro de 2013

Módulos e gerenciamento de memória

O problema dos módulos sempre foi e ainda é o gerenciamento de memória, mesmo agora na versão 4, fiz um teste com a versão 4.5.1, mesmo depois de descarregar o módulo usando loader.url = null e loader.unloadModule o módulo ainda continua ativo consumindo memória juntamente com os recursos que este carregou.

Um exemplo, se criar um módulo que tem um timer que de tantos em tantos segundo faz uma requisição http ou com um música tocando, depois que você o descarregar você verá que as requisições http ainda continuam ocorrendo e que a música ainda está tocando.

Nesse caso, além de "descarregar" o módulo é necessário desativar os recursos, mas mesmo assim a memória ainda estará sendo usada.

Não vejo a necessidade de usar módulos para conter somente uma tela, são realmente úteis com projetos muito grandes e mesmo assim tem que ser bem avaliado, porque ao gerar o swf da aplicação e colocar no servidor o client / browser irá identificar o novo swf e irá utilizá-lo.

E mesmo numa aplicação grande que terá benefícios reais modularizar o projeto acredito que usar sub-apps é mais recomendável, isto é, em vez de usar módulos criar sub-projetos cada um tendo o seu swf podendo ser independentes o que não acontece com os módulos que dependendem da aplicação principal.

Mais sobre sub-apps veja aqui.

quarta-feira, 20 de fevereiro de 2013

O fantasma da produtividade


Para quem tem pouco tempo, os pontos chaves que destaco:

Sintomas clássicos da falsa entrega de software:
  1. Efeito bumerangue – você entrega e ele volta rapidinho;
  2. Efeito formigueiro – sempre tem que mudar em vários pontos;
  3. Efeito dinheiro velho – ninguém consegue reutilizar o código;
  4. Efeito piano – custos altíssimos operação e sustentação;
  5. Efeito laxante – manutenção complicada, sempre dá merda;
  6. Efeito pipoca – todos os códigos modificados estouram;
  7. Efeito navalha – alguém sempre sai cortado;
  8. Efeito previdência – só segurados conseguem manter o código;
  9. Efeito sabão – manutenção sempre escorrega no orçamento;
  10. Efeito furacão – remendar cansa e não segura ninguém;
  11. Efeito ex-esposa(o) – cliente perde amor pelo projeto.
Todos – sem exceção – pregam ao máximo o excesso de produtividade, acreditando fielmente que produção de software é fabricação de telas no processo “1,2,3”… No entanto, esquecem que resultado vem da reutilização (RiSE – Reuse in Software Engineering), padronização, estabilidade, integração e, principalmente, sustentabilidade da solução que está sendo implementada (continuous quality enablement).

É claro que alguém vai gritar que testar é caro. ... um estudo realizado e publicado pelo Instituto Forrester que mostra que corrigir um defeito custa 30x mais que resolvê-lo na origem.

Na prática, todos sabem o tamanho do prejuízo, porém ninguém quer encarar o leão de frente, sendo mais prático passar a batata quente para frente, gerenciar o turnover de pessoas, disponibilizar uma equipe gigantesca de suporte. Na sequência, os novos clientes acabam tendo fila gigantesca de implantação e são servidos por um processo lento e caro que aos poucos mina o crescimento de qualquer negócio.

Nesse momento você fará uma nova pergunta: Prefere colocar o foco no problema ou na solução? Esse é o momento de dizer sim à mudança e trazer um novo momento ao negócio, procurando produzir software com estratégia e não mais fabricar aos modos “go horse”, pois o “débito técnico” acumulado é igual a cartão de crédito, a conta chega mesmo.

Complemento meu:

Em alguns lugares que passei se tem a filosofia de fila de produção, onde os desenvolvedores tem a preocupação de entregar a tarefa o quanto antes, e não entregá-la bem testada correndo o risco que volte por bugs simples de se identificar com um pouco de teste.

Nunca consegui seguir esta filosofia, voltar a corrigir algo que deveria estar ok no primeiro envio para testes é demorado, pois precisa se lembrar o que se quis fazer em cada código, reproduzir a situação, etc.


quarta-feira, 13 de fevereiro de 2013

JavaFX para iOS e Android

JavaFX compilando para iOS e Android, mas uma ferramenta cross-over para ser analisada.

Veja mais aqui.


quinta-feira, 7 de fevereiro de 2013

Verdades e mitos sobre JOINs

Li este artigo do blog iMasters de Jun/2012, só agora consegui lê-lo com atenção (correria), que recomendo para todo desenvolvedor / programador e profissionais de TI que precisam buscar informações de banco de dados.

[]s