Alquerubim: Maio 2010
Enjambrado por forinti às 13:53 0 comentários
A Europa parece ter sido o centro do Império de 8 bits porque a maior parte de seus países fabricou máquinas desse tipo. Um fato interessante é que todos os países socialistas tiveram suas próprias máquinas, exceto a Albânia.
No ocidente, há algumas faltas surpreendentes, como a Suíça e a Noruega. Ambos são países ricos e tecnologicamente avançados. Mesmo assim, não parecem ter se interessado pelos micros.
Portugal, Grécia e Irlanda estão hoje no centro dos problemas financeiros da Europa e na década de 1980 eram os mais pobres do ocidente. Não é estranho que não tenham tido seus próprios computadores.
O Reino Unido era o centro mais ativo. No auge, teve 600 fabricantes. Pode-se contar nos dedos os modelos dos outros países. A França foi a única a fazer frente aos ingleses, talvez por rivalidade. Enquanto os ingleses atacavam em todas as frentes (e ganhavam muito dinheiro com jogos), os sisudos franceses pareciam estar mais interessados no mercado corporativo.
Os países do leste fabricaram muitos clones do Apple II e do ZX Spectrum, embora alguns modelos tenham sido realmente interessantes. Os Pravetz foram muito usados em colégios da Bulgária e neles foi desenvolvido o vírus Dark Avenger, que atacava os Apple II. O Jet da Romênia (fabricados pela Electromagnetica) usava a carcaça de um telefone e as teclas eram identificadas com papéis escritos à mão. Os alemães orientais levaram muito a sério a concorrência com o ocidente e chegaram a produzir memórias de 1 megabit.
Os russos usavam os micros principalmente nos centros de pesquisa, mas em 1983 publicaram o projeto do Micro-80 na revista Radio. Foi o primeiro computador DIY e baseava-se no processador 8080 da Intel. Seguiram-no vários projetos publicados em revistas soviéticas.
Um pouco mais atrasados, os países do leste continuaram a produzir micros de 8 bits até o início dos anos 1990. Foi a queda do muro de Berlim que decretou o fim dessa tecnologia na Europa.
Enjambrado por forinti às 12:06 0 comentários
Meu micro estava há um bom tempo teimando em não desligar completamente. Ele até desligava os discos, mas continuava com a ventilação funcionando. Como última tentativa, resolvi atualizar a BIOS. Funcionou, mas um detalhe importante apareceu.
A imagem da BIOS tem 512KB. Isso é exatamente o tamanho da ROM que continha o sistema operacional RISC OS do Archimedes. Este era um sistema operacional multi-tarefa com interface gráfica, conforme ilustra a figura abaixo.
Então, o que há 20 anos seria o suficiente para um sistema operacional bastante avançado, hoje mal serve para ligar e deligar a máquina.
Enjambrado por forinti às 05:28 1 comentários
Uma das maiores fontes de erros e ineficiência que costumo encontrar em sistemas Web escritos em Java é o mau uso das classes de formatação da package java.text.
A documentação avisa que as classes não podem ser usadas concorrentemente. Mas quem lê a documentação? Outro problema é a instanciação excessiva. Tenho a impressão de que ela não ocorre por precaução, mas por indiferença.
Em sistemas Web, principalmente os de alto tráfego, alguns detalhes podem fazer muita diferença. Se instanciar um objeto não custa muito, removê-lo é muito demorado. Num teste simples, descobri que reutilizar uma instância é quatro vezes mais rápido que criar uma nova. E uma instância reutilizada não precisa ser recolhida pelo coletor de lixo.
A solução está na classe ThreadLocal do pacote java.lang. Nem é preciso importar a package! Para a formatação, costumo criar uma classe utilitária da seguinte forma:
public class Formato {
private static final ThreadLocal formatoData =
public static SimpleDateFormat getFormatoData() {
return formatoData.get();
public static Date data(String value) {
return getFormatoData().parse(value);
public static String data(Date value) {
return getFormatoData().format(value);
Uso nomes bem concisos para os métodos para tornar o código mais simples. O significado fica bastante claro pelo uso:
String hoje=Formato.data(new Date());
Assim, fica garantido que para cada linha de execução haverá apenas uma instância para cada formatação. E todas as operações são feitas usando essa mesma instância. Os servidores de aplicação costumam reaproveitar as threads e então, uma vez criado, cada objeto terá uma longa vida. Além disso, não tem sentido ter muitas linhas de execução por processador. Tipicamente, usam-se 4 ou 8. Se houver mais que isso, o processador vai ficar mais tempo trocando de contexto que fazendo algo útil.
Para executar outras transformações, basta adicionar subclasses de ThreadLocal e os respectivos métodos, conforme o exemplo. Será necessária uma instância para cada tipo de conversão.
Enjambrado por forinti às 10:52 5 comentários
O padrão Visitor é deveras útil, mas pode ser melhorado com um pouco de reflexão. O maior problema dele é que é preciso adicionar um método para cada classe a ser visitada. Geralmente o código não faz mais do que chamar o respectivo método visit() no Visitor. Com reflexão, pode-se eliminar esses métodos. Eliminar código é sempre bom!
Vamos começar pelas classes que serão visitadas.
class FunnySquare extends Square {
return "FunnySquare";
class ReallyFunnySquare extends FunnySquare {
return "ReallyFunnySquare";
Duas são subclasses de Square e para elas não vou criar métodos visit(). O Visitor com reflexão está no código abaixo.
private void visit(Circle c) {
System.out.printf( "I visited a Circle (%s)\n", c);
private void visit(Square s) {
System.out.printf("I visited a Square (%s)\n", s);
public void visit(Object e) throws Exception {
visit(e, e.getClass());
private void visit(Object e, Class c) throws Exception {
Method m = getClass().getDeclaredMethod("visit", c);
m.invoke(this, e);
visit(e, c.getSuperclass());
O único método público é o visit(Object e). Ele usa uma versão privada que procura um método adequado para a classe do alvo e, se não achar, recursivamente procura métodos usando a superclasse do alvo.
O código abaixo executa um pequeno teste.
FunnySquare f = new FunnySquare();
ReallyFunnySquare r = new ReallyFunnySquare();
Visitor v=new Visitor();
for(Object o : new Object[] {
new Circle(), new Square(), new FunnySquare(), new ReallyFunnySquare()
v.visit(o);
I visited a Circle (Circle)
I visited a Square (Square)
I visited a Square (FunnySquare)
I visited a Square (ReallyFunnySquare)
Eu deixei apenas um método visit() público para evitar que o cliente use um método mais abrangente. Como o compilador escolhe o método conforme o tipo da referência e não o tipo do objeto, se for utilizada uma referência com tipo de uma superclasse da instância, perde-se a oportunidade de usar um método mais específico.
Um bônus nisso tudo é que não é preciso usar ifs.
Enjambrado por forinti às 13:09 0 comentários
Diziam os ingleses que o sol nunca se punha no Império Britânico. Eu resolvi descobrir qual a extensão do Império dos 8 bits. Isto é, quais países produziram micros de 8 bits durante a década de 1980.
Comecei pelas Américas e descobri os seguintes países:
Os Estados Unidos, como era de se esperar, desenhou e fabricou a maior parte dos micros. Canadá parece ter tido apenas uma empresa (Semi-Tech) que desenhou um micro (Pied Piper) baseado no Z80 e o produziu nos Estêites. A Argentina tinha 2 fabricantes. A Czerweny fabricava clones do ZX Spectrum (devidamente licenciados) e a Talent/Telematica fabricou 3 modelos de MSX. O Brasil teve um pouco mais de variedade, provavelmente por causa da reserva de mercado.
E o império começa a tomar forma.
Enjambrado por forinti às 08:50 0 comentários
Não tenho paciência com quem tem medo de computador. Geralmente são as mesmas pessoas que ignoram o limite de velocidade na estrada ou tomam o remédio que a vizinha indicou.
Minha mãe começou a usar computador para editar textos no WordWise do BBC B+ com 128KB de RAM. Com ele, edita-se o texto em um modo texto de 40 colunas por 25 linhas. Para saber mais ou menos como vai sair a impressão, usa-se um modo de 80 colunas de 2 cores. Não chegava a ser uma limitação, porque a impressora era matricial (Epson LX80) e monocromática. Havia memória livre para 28KB de texto. Então, para um trabalho grande, era preciso dividir o texto em capítulos. O texto era decorado com palavras-chave que indicavam a formatação. Era quase como programar. Nos disquetes de 5,25" cabiam 400KB.
Depois veio o WordStar. Ainda não era WYSIWYG, mas pelo menos a edição era feita em 80 colunas. Os comandos eram digitados com seqüências estranhas e a mãe os dominava como ninguém: Ctrl-K-B, Ctrl-K-K, etc. A impressora ainda era matricial e os disquetes só continham 360KB.
Finalmente, chegou o Word, começando no Windows 3.11. Desde então, as coisas não mudaram muito, inclusive a resistência de muitos.
Sempre que escuto "estou muito velho para isso" ou "isso é muito difícil", tenho que conter o ímpeto de retrucar com "se até a minha mãe consegue", porque a verdade é que ela tem uma habilidade extraordinária de aprender e não tem medo de enfrentar tecnologia nova.
O controverso (e pouco amado) Sindppd-RS quer reduzir a jornada de trabalho do setor de TI para 30h. É uma discussão que levanta opiniões bem fortes e, em grande parte, pouco elaboradas.
Não me parece absurdo, porque, tendo já trabalhado 30h, sei que é possível fazer bastante com 6h diárias ininterruptas. Mas parece que há um sentimento de que há mais valor em trabalhar muito, como se mais horas criassem exponencialmente mais valor. Pessoalmente, acho que a semana de 40h está de bom tamanho, mas as 40h do hemisfério norte (das 9h às 5h). Lá as pessoas precisam levar os filhos ao colégio, pagar as contas e fazer compras no fim do dia. Aqui, parece que não.
De qualquer forma, não acho que exista um número mágico que seja bom para todos. Por isso, creio que seria mais sensato se as empresas oferecessem vagas com cargas horárias alternativas. Um estudante poderia trabalhar 20h e um pai poderia oferecer 30h. Algumas já fazem isso.
As empresas de TI não costumam vender exatamente o mesmo produto para todos os seus clientes. Não vejo por que tenham que oferecer exatamente o mesmo contrato de trabalho a todos os seus funcionários.
Enjambrado por forinti às 11:11 2 comentários
A primeira solução para encontrar espaços na numeração de uma chave primária tinha um defeito: se não existisse registro para o primeiro número, todos os números até o registro mais baixo permaneceriam vagos.
Pode-se resolver a questão mudando um pouco a consulta. No lugar do olhar para frente, com LEAD(), olha-se para trás, com LAG().
select numero2+livre
lag(numero, 1, 0) over (order by numero) numero2
on livre < numero1 - numero2
Usei lag(numero, 1, 0), porque quero que a numeração comece com 1 (o segundo select usa rownum e este começa com 1).
Enjambrado por forinti às 06:04 0 comentários
Enjambrado por forinti às 14:23 0 comentários
Arthur C. Clarke escreveu em um de seus livros que "não se pode distinguir de magia qualquer tecnologia suficientemente avançada". Esse momento eu testemunhei muito antes de 3001.
Um belo dia de sol, uma britadeira começou a trabalhar na rua abaixo do escritório. O sistema olhou nos olhos perplexos do usuário. Por que o computador está fazendo esse barulho? Queimará?
A máquina desligou e o barulho continuou. Como pode o sistema fazer barulho com o computador desligado? Mesmo tirando da tomada! Não pode ser! Os elétrons não estão a fluir!