English readers and other languages: Many posts are in portuguese, you can use the Translate button at left side.

Clique nas imagens dos artigos! Elas levam você para o site do artista que a criou e muitas
vezes tem assuntos relacionados ou outras imagens para expandir seus horizontes!

quinta-feira, 19 de novembro de 2009

Concordo: Justiça proíbe teste cego da Kaiser - Cirrose e Computador

Este é meu comentário publicado no blog do Marcelo Onaga, da Revista Exame: Justiça proíbe teste cego da Kaiser

Em 19/11/2009
"...A Justiça concedeu liminar a pedido da AmBev proibindo a veiculação da campanha publicitária da Kaiser que mostra o resultado de um teste cego feito com mais de 2500 consumidores. A Femsa, dona da Kaiser, deve recorrer..."


Meu comentário:

Como consumidor e profissional, notei uma coisa simples, mas que pode ter passado despercebido pela maioria das pessoas:

O tal teste cego anunciado, fala em "qualidade", mas parece que na verdade trata-se de quantidades vendidas.

Dependendo aonde você mora, não tem muita opção, e no meio de uma cervejada, o pessoal compra o que tiver mesmo. Da mesma forma, determinados estabelecimentos só vendem certas marcas.

Qualidade não é o mesmo que quantidade e, é só olhar o mix de marcas apresentadas naquele anúncio para comprovar que tem de tudo ali.

É muito parecido com a nossa área de informática, quem não conhece acha que computador é tudo igual e pior, bebem qualquer coisa, digo, colocam qualquer coisa goela abaixo, digo, na empresa e depois o fígado é que sofre, digo, os lucros é que se vão pelo ralo.

quinta-feira, 12 de novembro de 2009

quinta-feira, 5 de novembro de 2009

Como ser um bom programador

Foto: riebschlager

Como ser um bom programador


Programação é uma atividade intelectual, racional, emocional, artistica, espiritual e mística. Tudo depende do como cada pessoa vai trilhar este caminho.

Seguindo na proposta de comentar sobre otimização, desenvolvimento e outras coisas, coloco então algumas observações que tenho coletado, observado e principalmente, vivenciado nestes anos todos.

Tornar-se um bom programador tem a ver com desenvolver suas habilidades pessoais em primeiro lugar. Ter gosto pelo estudo mas sem se apegar a dogmas e paradigmas. Estar pronto a revisar conceitos. Procurar fazer o melhor de si.

Claro que aprender tecnologias é importante, mas de nada adianta decorar milhares de parágrafos de informação se na parte da interação social entre você e as demais pessoas, o computador ficar como uma barreira.

O programador realiza a tarefa de projetar em detalhes e traduzir para o computador uma determinada tarefa humana. É isto que deve ser lembrado, os computadores devem estar a serviço da humanidade e é por isto que é sempre bom aprender sobre as pessoas.

Nosso trabalho é aprimorar as maneiras de se conseguir isto, mesmo que seja trabalhando muito mais para que outros possam trabalhar muito menos.

Acredite que você pode fazer melhor e trabalhe para isto.

Se você encontrar algo errado, arrume. Não interessa quem fez, se está na sua mão é responsabilidade sua melhorar ou resolver o problema.

Simplifique a vida do usuário. Seu programa deve ser simples e fácil de usar. Inclua tratamento decente de erros, com mensagens claras e objetivas. Crie tratamento automatizado para os erros mais comuns.

Teste seu programa de todas maneiras. Teste seu programa de todas maneiras. E principalmente, teste seu programa de todas maneiras. Só porque tem um botão na tela, não pense que alguém vai clicar direto nele. É mais provável que vão fazer de tudo, e as vezes, até clicar o maldito botão.

Documente seu código. O código deve ser claro, auto-documentado. Evite siglas e menmonicos, prefira nomes auto-explicativos.

Use bem os recursos de máquina. Boa performance economiza tempo, energia e ajuda a conservar o meio ambiente.

Dedique o tempo necessário para conseguir uma boa solução. Mas não gaste mais tempo do que o benefício que se pretende conseguir.

Identação de código é obrigatório. Desculpe, mas se você não entende nem isto, por favor, mude de ramo, esqueça programação e nunca mais chegue perto de um programa.

Lembre que algum dia alguém vai ter que mexer neste programa. Pode ser até você mesmo, mas com certeza, os comentários e clareza do código serão de imensa ajuda.

Evite malabarismos desnecessários só para mostrar que aprendeu alguma mágica diferente.

Elimine código inútil ou sem uso.

Fuja do código spaghetti tanto quanto possível.

Divida o programa em pequenas secções, use funções, etc.

Pense no que está fazendo. Longas cadeias de IFs ou IFs quilométricos, que se extendem por páginas e páginas são uma fonte certa de dor de cabeça e não tem a mínima justificativa.

Faça modelos ou programas de exemplo para testar o funcionamento das diferentes partes, algoritmos e/ou funcionalidades.

Nenhum otimizador de programa ou SQL ou seja o que for, vai fazer milagre se o seu código for mal feito. Pode até melhorar um pouco e virar um código mal feito otimizado. Otimizadores funcionam bem mesmo é com código razoavelmente bem feito. Nenhum deles vai fazer milagre em arrumar lógica absurda.

Máquina mais rápida faz código ruim rodar um pouco menos devagar. Melhore o código até chegar ao equilíbrio entre tempo de desenvolvimento versus custo de hardware.

Lembre, programar é a arte de dizer ao computador quais são os passos que deve executar com as informações. Ponto. Portanto, estude lógica e pratique.

Verifique, compile, teste seu programa com frequencia.

Leia seu código fonte. Quanto mais você ler o código fonte, melhor vai ter compreensão dele.

Use padrões.

Reutilize código que funciona. Crie funções genéricas para atender necessidades comuns.

Use sua auto-crítica.

Otimize. Reotimize. Melhore e aperfeiçoe.

Adote um padrão de codificação.

Foto loupiote (Old Skool)

Não seja preguiçoso. Fazer algo correndo pode lhe custar dez vezes mais tempo mais tarde. Ao invés de ser preguiçoso, use sua criatividade para desenvolver ferramentas que vão tornar seu trabalho mais fácil. Lembre, no início havia apenas a linguagem de máquina. Depois algum programador criou o Assembler e as linguagens de programação que facilitaram tudo.

São os programadores quem vão criar as ferramentas que serão usadas amanhã, portanto, não espere encontrar tudo pronto nalguma ferragem.

KISS. Sigla de "Keep It Single Stupid". Tradução: Faça isto simples estúpido!

Código bom é código simples. Mesmo que seja uma rotina complexa, pode ser feita com clareza a objetividade.

Não se case com nenhuma idéia. A pior coisa é você estar atrelado a uma grande idéia e ter apenas uma única grande idéia.

Mantenha contato com seus superiores e usuários para saber se vocês estão indo na mesma direção.

Converse com outros desenvolvedores para debater sobre o código, algoritmos, metodologias, etc. Conversa de bar está liberada.

Mantenha-se informado e adote novas tecnologias sempre que adequado.

Estudar novas tecnologias e também outras áreas, incluindo ciências humanas, lhe trazem idéias, inspiração e conhecimento sobre diferentes maneiras de fazer as coisas, de pensar, analisar e solucionar problemas.

Aprenda outras linguagens e principalmente, aprenda a programar de maneira diferente pois cada linguagem tem conceitos diferentes. Se você faz a mesma coisa com linguagens diferentes, está desperdiçando o potencial que cada ferramenta possui. É por isto que vejo tanto programa spaghetti feito em linguagem Java!

Não existe uma linguagem que seja ótima para tudo. Se necessário, adote linguagens que possam ser complementares, utilizando o melhor de cada uma, de acordo com a necessidade a ser atendida.

Pense para o futuro! A sigla de tecnologia da moda de hoje, será ultrapassada em dois anos.
Em cinco anos você vai descobrir que a linguagem atual é muito mais parecida com a linguagem de 20 anos atrás do que você pensa.
Em dez anos você vai saber que os princípios continuam os mesmos, apenas temos ferramentas melhores, hardware mais rápido e barato.
Boa parte das melhores ferramentas de hoje, foram idealizadas e desenvolvidas pelos que já pensavam nelas a 20 ou 30 anos.
Se você duvida, é só ler os livros e manifestos dos anos 70 e 80.

P+
05/11/2009



Leia também:



.'.

Voodoo no Chefe

Boneco de Voodoo do Chefe
A antiga arte poderia ser usada em TI, ou nos negócios em geral?

Poucos sabem, mas Voodoo pode, e preferencialmente deve, ser usado para o bem, para coisas positivas.

Eu já tinha visto este boneco tempos atrás, mas só agora encontrei algumas fotos.






Ao invés de procurar nocautear, ele é guiado pelo desejo de atitudes positivas em favor do requerente, como "Seja bonzinho", "Me dê um elogio" até "me dê um aumento". (risos)

Brincadeiras a parte, o importante é buscar canalizar energia para atitudes positivas.

Seria interessante experimentar a técnica, fazendo um boneco da placa mãe do computador e tentar operar mudanças no processamento.

Falando sério, se você busca mudanças, quem sabe ao invés de causar dano, seria melhor trazer coisas boas? Se seu chefe tem problemas, pedir que ele encontre luz para mudar e se tornar melhor.

Se não tem jeito, tipo, chefias que são decididamente más, geralmente com aprovação do escalão superior,então é melhor você mesmo tomar uma atitude positiva e pedir luz para você conseguir outra colocação, num lugar mais saudável.

Em tempo: sempre digo que uma das melhores maneiras de se livrar de um inimigo é abrindo os caminhos dele. Se ele ganhar na megasena, ou encontrar a sua verdadeira alma-gêmea lá do outro lado do planeta, vai com certeza se mudar para bem longe e sair da sua vida. E ainda por cima, pode até lhe agradecer!

.'.

Leia outros artigos relacionados clicando nas tags abaixo:

Videos. Ufos e viagem à Lua

Pyramids in the moon.
Montagem do artista NewZazita



Existe algo suspeito a sobre as atitudes da NASA em relação aos UFOs?
Veja:  "Secret Space"



Site: "A Fraude do Século"

Este site questiona a veracidade da chegada do homem à a Lua.

Pessoalmente  não concordo com a maioria das colocações do autor, mas mesmo assim é interessante de se visitar.

Só para lembrar, quando se aprende a desenhar perspectiva, percebe-se que as sombras vão direcionar-se para o ponto focal "ao fundo da imagem".

http://www.afraudedoseculo.com.br


.'.

Veja também:


.'.

quarta-feira, 4 de novembro de 2009

Manifesto pelo Desenvolvimento Ágil de Software

Manifesto for Agile Software Development


Gostei desta e presto meu apoio:


Manifesto para Desenvolvimento Ágil de Software


Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas.

Software em funcionamento mais que documentação abrangente.

 Colaboração com o cliente mais que negociação de contratos.

Responder a mudanças mais que seguir um plano.
 
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.




Princípios por trás do Manifesto Ágil

Nós seguimos estes princípios:
  Nossa maior prioridade é satisfazer o cliente
através da entrega contínua e adiantada
de software com valor agregado. 


Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.


Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente. 


Entregar frequentemente software funcionando,
de poucas semanas a poucos meses,
com preferência à menor escala de tempo. 


Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto. 


Construa projetos em torno de indivíduos motivados.

Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho. 


O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é através de conversa face a face. 


Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente. 


Contínua atenção à excelência técnica e bom design
aumenta a agilidade. 


Simplicidade--a arte de maximizar a quantidade de
trabalho não realizado--é essencial. 


As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis. 


Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.




Site do manifesto: http://www.agilemanifesto.org

.'.

quinta-feira, 29 de outubro de 2009

A Diferença entre Nerds, Geeks, Dweebs e Idiotas



Isto é cópia postagem de outro site (vide nota ao final). Achei a uma análise simples e bem interessante. E engraçada.





Acho que observando a imagem acima fica bem claro o que é o que, mas vamos a uma rápida análise!

Nerds: São pessoas sem vida social, inteligentes e que sonham em ganhar muita grana e se casar com uma gostosa que vão se apaixonar pelo seu dinheiro!

Geeks: Um Nerd que se preocupa um pouco mais com a vida social, esses bebem cerveja e eventualmente comem mulher! Possuem vida social normal, ou quase!

Dweeb: Um parente próximo do Nerd, igualmente inteligente e sem vida social, mas sem ambição alguma, ou seja, nunca irão comer uma gostosa, já que não deverão ser ricos!

Idiotas: Aqueles que sonham em ser alguma coisa na vida, mas não são inteligentes e não possuem capacidade para criar/desenvolver/montar algo sozinho! Como não tem vida social, dificilmente arrumarão algum bom emprego por indicação! A única vantagem é que os idiotas costumam comer as gostosas, mas propriamente as gostosas dos Nerds ricos!



.'.

Nota: O site onde isto foi postado não existe mais, o link da postagem original era:
http://hein.com.br/quer-entender-um-pouco-mais-a-diferenca-entre-nerds-geeks-dweeb-e-idiotas

Linux Koala alça vôo: Ubuntu 9.10 liberado.

Foto: arrayexception (M. Lobo)

Com novidades interessantes, como a "Personal Cloud", foi liberado oficialmente hoje o Ubuntu 9.10 (Karmic Koala).

O engraçado foi meu colega "Linux addicted" que ficou desde as primeiras horas da manhã clicando Refresh no browser só para ver o momento da liberação no site.

Estão disponíveis diversos release mirror e (para pensar nos franceses que querem barrar P2P), sugere-se o uso de bittorrent para o download. 

.'.

Adicionar Hardware Não Compensa Software Lento

Relação de Amor e Ódio
Foto: Jay Murdock

Adicionar Hardware Não Compensa Software Lento
29/10/2009

Por causa da redução do preço do hardware ou limitações de desenvolvimento (tempo, experiência, etc), tornou-se prática comum colocar mais máquinas para compensar o fraco desempenho dos sistemas.

Além de maior consumo de energia e dos impactos ambientais, isto não significa tanta melhoria assim nos resultados.

"Você é programador? Quer fazer algo pelo meio ambiente e mesmo, fazer do mundo um lugar melhor? Então comece a otimizar seu código! - Jeff Atwood."


Simplesmente colocar mais equipamento tem sido a solução preferida ao invés de fazer o software rodar mais rápido com o hardware existente. Fazer mais com menos é uma regra importante a ser lembrada, tanto quanto a Lei de Wirth: "Software fica lento mais rápido do que o hardware acelera."

Como resultado, isto anula os ganhos com a Lei de Moore!!! O hardware fica mais rápido a cada 18 meses, mas o software dobra de tamanho, fica maior, mais lento.

Jeff Atwood sugere alguns passos para começar:
  1. Coloque hardware mais rápido e barato para o problema de performance.
  2. Se o aplicativo atingir sua meta de performance, pare por aí mesmo.
  3. Faça benchmarks para determinar aonde estão os problemas de performance do seu software.
  4. Analise e otimize as áreas que você identificou no passo anterior.
  5. Se agora o aplicativo atingir sua meta de performance, pare por aí mesmo.
  6. Volte ao passo 1.

Outra coisa importante a observar é quais aspectos otimizar, como por exemplo, a interação com o usuário. Um tempo de resposta de até um segundo é até aceitável. A partir de um segundo, isto já chama a atenção do usuário e pode começar a irritar. Se passar de dez segundos (máximo!), o usuário vai perder a linha de raciocínio e passar a fazer outras coisas enquanto espera.

Para grandes volumes de dados também existirão os aspectos de tempo de execução e da quantidade de volumes alocados durante o processamento, que certamente afeta outras tarefas que poderão estar sendo feitas.

Otimização de performance envolve mais testes e menos adivinhação. Quando se pensa numa escala de milhões de operações por segundo, qualquer detalhe pode ser importante. Mas também existem detalhes que tomam tempo e não valem a pena otimizar.

Com certeza, a otimização requer conhecimento efetivo e prática dos recursos e técnicas adotadas.

Pessoal com menos experiência vai ter melhores resultados se trabalhar em grupo e utilizarem intensos benchmarks para analisar cada porção do software.

E claro, isto vale para mim e para todos: Sempre estude. Procure aprender de quem sabe mais que você. Graças a internet, hoje alguns dos melhores programadores do planeta mantém sites, blogs, etc com um amplo conjunto de informações e código fonte que merecem ser cuidadosamente estudados.

Dica: soluções de estruturas de lógica, de "como fazer", podem ser feitas com diferentes linguagens, portanto, amplie seu foco de estudos. Como se diz faz décadas, basicamente "quase tudo são IFs e assinalamentos."

As vezes, descobre-se que seria mais desejável reescrever o software. Isto deve ser considerado quando:
  1. O código for efetivamente ruim ou mau feito;
  2. A solução atual puder ser realmente melhorada;
  3. Houver incompatibilidade na maneira que o código faz o processamento, em relação a algum outro recursos, normalmente externo.

E lembrando, muitas vezes o código é reescrito apenas porque o programador não entendeu o que foi feito. Geralmente falta estudar o código. Portanto, antes de qualquer coisa, estude o código e a solução de lógica adotada, conheça a ferramenta ou linguagem que está usando.

Soluções de automatização de performance, como as existentes nos gerenciadores de banco de dados e, em certas linguagens de programação, podem muitas vezes ser uma armadilha. As pessoas acham que o computador vai resolver sózinho o trabalho de melhorar a execução do código, mas esquecem completamente que isto vai ser feito de acordo com algumas regras padronizadas. Logo, com frequencia os resultados podem ser bem fracos em relação ao esperado.




Leia também:




.'.

quarta-feira, 28 de outubro de 2009

RIP Geocities

Foto: Viche (Victoria Cormie)

Conforme comunicado a vários meses, o Yahoo encerrou as atividades do Geocities, ativo desde 1994.

Nestes 15 anos o Geocities tornou-se um repositório imenso de informações que dificilmente serão encontradas novamente, pois muitos dos sites tinham pouco tráfego, ou seus autores não puderam mais efetuar atualizações. Eu sou um deles.

Tive vários sites no Geocities, inclusive o mais acessado do mundo a respeito do sintetizador Roland JD800, um clássico profissional, e meu hobby semi-profissional. Outros sites eram de programação e coisas diversas.

Para quem precisar de coisas que estavam no Geocities, a sugestão é que se utilize o web.archive.org para buscar a versão em cache dos sites que deixam de estar disponíveis.

Também existem outros sites que mantém cópias de boa parte do material do Geocities.
Alguns principais são:
 .'.