Redirecionando a saída padrão para o JTextArea

ago 22
2009

Em Java, a saída padrão é redirecionada usualmente para o console. Aqui vamos ver como fazer para que seja redirecionada de forma fácil para um componente gráfico, no caso um JTextArea.

Saída Padrão, Saída Padrão de Erro e Entrada Padrão – Uma Breve História

Tudo começou quando os sistemas operacionais ainda possuiam apenas interface de texto. Os programas não gráficos escrevem na saída padrão (normalmente o vídeo) e leem da entrada padrão (normalmente o teclado). A saída e entrada padrão podem ser redirecionadas pelo sistema operacional, por exemplo, se a saída for redirecionada para a impressora, ela é impressa, sem que se precisse modificar uma única linha de código. Também há a possibilidade de fazer com que a saída padrão de um programa, seja a entrada de outro, um mecanismo chamado pipe. Os fãs de Linux, aqueles que adoram a tela preta do console, escrevem linhas de comando enoooooormes, redirecionando a saída de um programa para a entrada de outro. Isso também pode ser feito no Windows, mas simplesmente não faz parte da cultura.

Read the rest of this entry »

Como projetar um Wizard

ago 20
2009

O que são Wizards?

Wizards guiam o usuário através de vários passos, realizando as tarefas em um ordem definida. Um Wizard pode ser implementado de diversas maneiras. A forma mais usual inclui uma série de telas, onde o usuário passa de uma para outra seqüencialmente. A estrutura de um Wizard pode ser linear (A) ou possuir saltos ou ramificações (B), em qualquer um dos casos deve ser dada a opção de voltar. Há também a possibilidade de se implementar em apenas uma tela, onde os passos vão sendo habilitados ou mostrados à medida que os campos são preenchidos. Nesse último caso, diferentes passos podem ser identificados com títulos.

estrutura
Read the rest of this entry »

Otimização de Software: Quando? Onde? Porquê?

ago 13
2009

A otimização de software é um dos tópicos mais mal-entendidos pelos profissionais de TI. Muitos pensam que a performace só deve ser levada em consideração ao final do desenvolvimento, devido a uma máxima conhecida por muitos "premature optimization is the root of all evil", em tradução livre "otimização prematura é a raiz de todos os males". Este dizer é mal-interpretado por muitos como: todas as considerações de performace devem ser feitas apenas ao final do desenvolvimento. É mesmo? Problemas de performance podem e devem ser previstos durante a fase de projeto, como tudo em software, quando mais cedo o problema é encontrado, mais barato é a solução.

O mal entendido

O dizer “otimização prematura é a raiz de todos os males” de Donald Knuth está incompleto. A forma completa é “We should forget about small efficiencies, say about 97% of the time, premature optimization is the root of all evil.”, em tradução livre “Devemos esquecer as pequenas eficiências, digamos 97% do tempo, otimização prematura é a raiz de todos os males.” Donald Knuth estava falando da micro-otimização do código, não fornecendo um passe livre para métodos ineficientes.

Outro ponto a ser considerado, é a época na qual Donald Knuth fez a sua declaração. Naqueles idos tempos, otimização normalmente consistia em ficar contando ciclos de CPU gastos em cada instrução. Com certeza, esse tipo de preocupação não é adequada no momento do projeto do sistema. Ele não estava falando da escolha do algoritmo, estruturas de dados, uso adequado de loops, etc..

Read the rest of this entry »

Últimos Visitantes

Google Friend Connect