O meu processo de absorção de novidades é por etapas. Em geral eu leio ou ouço falar sobre algo novo, e guardo em um lugar remoto do meu cérebro. Muitas vezes, eu conto com a colaboração do meu colega de blog e junkreader profissional, senhor Lullis, Raphael Lullis. Com o passar do tempo, algumas das novidades vão sendo eliminadas, e algumas poucas são promovidas para a próxima fase. Após alguns paredões, eu acabo resolvendo aprender as que sobreviveram. Normalmente, as tecnologias que ficam são aquelas que por algum motivo se tornam necessárias no meu cotidiano.

Foi assim com django, com Ajax, com python. E agora, sistemas de controle de versão distribuídos (Mercurial ou Git) estão próximos da fase final de aprovação. Pra variar, o Raphael é parcialmente culpado por isso. Ele tem um lado Cuco: a cada 2 dias reaparece e martela sobre um tema. E vira e mexe ele vem me falar das maravilhas do uso de um Mercurial da vida. No começo achei um tanto quanto viajado. Mas agora, me parece extremamente útil.

Aliás, quero aproveitar antes para falar sobre o conceito de repositório. Pelo fato de um sistema distribuído não ter o conceito de repositório central, algumas pessoas acham que a coisa tende ao caos. Eu pensava assim. O grande lance é que ao contrário de um sistema como SVN onde existe um repositório e as pessoas baixam working copies, num sistema distribuído cada máquina é um repositório.

Dois elementos me parecem muito atraentes nestes sistemas, e me fazem falta atualmente: a possibilidade de ter um repositório local, e a possibilidade de compartilhar seu trabalho com outras pessoas sem a necessidade de passar por um repositório central.

O primeiro elemento é algo que pode ser parcialmente resolvido por bons IDEs como o Eclipse, que oferece um histórico local. Mas históricos locais são ótimos para resolver problemas em arquivos separados. A coisa se torna mais complicada quando queremos voltar conjuntos de arquivos. Para isso, já nos acostumamos a ter uma ferramenta de controle de versão, que permite comitar e comentar checkpoints de trabalhos. O fato é que quando se trabalha em grupo, o ideal é que os commits no repositório central sejam completos. Mas muitas vezes, uma implementação pode ser quebrada em várias sub-tarefas que não podem/devem ser compartilhadas com a equipe, e ter um histórico apurado destas subtarefas pode ser muito útil. Que jogue a primeira pedra aquele que nunca passou horas e horas escrevendo código,  e que no final das contas teve que voltar tudo atrás usando um revert.

O segundo elemento é algo que pode resolver vários problemas. Um deles é  permitir criar níveis de repositórios: um de desenvolvimento, um de testes, um de produção. Todos com histórico, tags, versões e afins. Trabalhei num projeto onde muitas vezes o repositório ficava instável, e era um deusnosacuda para montar uma versão para cliente.

Outra característica interessante é permitir que subgrupos dentro de uma equipe de desenvolvimento possam compartilhar código sem a necessidade de ter que criar um branch ou, pior, zipar o diretório e mandar por email. Tudo se resolveria com um merge simples entre pares.

Eu sei perfeitamente que para que tudo isso funcione, é necessário uma readaptação da equipe à nova ferramenta e sobretudo, ao novo modus operandi. Mas parto do pressuposto que as pessoas que trabalham comigo são espertas o suficiente para isso. E pensando bem, se fomos capazes de aprender a trabalhar com sistema de controle de versões, porque não seríamos capazes de aprender a trabalhar com um sistema distríbuido?

A primeira, noticiada pelo Blog oficial do GMail é para aficcionados por comunicação instantânea (eu por exemplo):  será possível fazer chat de áudio e vídeo dentro da interface web do sistema de emails. Basta instalar um plugin, e se divertir. Se funcionar corretamente, irá transformar o GMail numa central de comunicação completa.

A segunda notícia é mais intrigante. O Google.org, braço filantrópico do Google, está lançando uma ferramenta de detecção de epidemias de gripe nos Estados Unidos. O mecanismo de detecção é de uma simplicidade incrível, e ao mesmo tempo um tanto quanto preocupante: o próprio sistema de buscas da empresa. A premissa básica é que atualmente, quando pessoas sentem sintomas de alguma doença, procuram na Internet informações a respeito dos sintomas. Como hoje em dia, busca na Internet é sinônimo de busca no Google, então “basta” eles analisarem e georeferenciarem a ocorrência de termos específicos (coisa que a ferramenta Google Trends faz de graça),  para obter uma boa estimativa de regiões onde poderiam estar começando epidemias. Nada de registros médicos, apenas buscas simples na interface do Google.

Expandindo a idéia, como hoje em dia a fonte básica de pesquisas é a internet, e boa parte dela passa pelos servidores do Larry e do Sergei, e que ferramentas como o Google Analytics mostraram que a questão do georeferenciamento de IPs já foi resolvida, então podemos assumir que eles se tornaram a maior empresas de análises estatísticas do mundo. Que aliás eles utilizaram para analisar buscas feitas durante a campanha eleitoral.

Big Brother?

Novamente, destaquei o “por decisão judicial”, porque acho o cúmulo do absurdo o comunicado da empresa deixar  a entender que a culpa é da Justiça, eque está fazendo isso contra a sua vontade. Afinal todos sabemos que o inicio disso tudo foi uma liminar de um juiz de Baurú proibindo a Telfônica de exigir o provedor.

Ridículo.

A boa notícia é que o site deles oferece uma lista de provedores com “preços e promoções” especiais…..

Motivação e Exemplo

No meu ponto de vista, AOSD não é algo que veio revolucionar o desenvolvimento de software, mas sim um avanço incremental do paradigma de orientação a objetos (OO). Todo bom programador sabe que se deve tentar distribuir as responsabilidades (concerns) do programa em módulos, de forma que cada módulo seja fácil de implementar, entender e reusar. Em C, por exemplo, funções podem ser consideradas módulos. Pra qualquer programa não trivial, você não vai criar somente uma função main(), vai separar a funcionalidade em muitas funções que se chamam pra realizar o objetivo do software. Já OO prega a modularização do software em uma hierarquia de classes e conta com polimorfismo, herança, etc. A motivação de AOSD é que existem algum concerns que entrecortam a hierarquia, ou seja, que mesmo criando essa hierarquia de classes, você não tem como separar dois concerns que deveriam ser separados (para serem melhor implementados, entendidos e reusados).

Pra não ficar somente no abstrato, vamos à um exemplo bem simples, que é utilizado constantemente pra apresentar AOP. Imagine que você tem uma classe que faz o controle do acesso ao banco de dados. O código abaixo é um esboço de como uma classe dessas seria implementada em Java. Você tem um gerente de transações e, em todos os métodos de acesso ao banco de dados, você chama o gerente pra iniciar uma transação e fazer commit se tudo deu certo, ou rollback se deu algum problema. Note que hoje em dia ninguém faria um código assim, já que existem soluções melhores do que ficar escrevendo SQL no seu código (como Hibernate), mas é bem ilustrativo do problema.

public class DB {
	TransactionManager manager = ...;

	public void storeUser(User u) {
		manager.start();
		try {
			// write some sql code storing u into the DB
			manager.commit();
		} catch (DBException e) {
			manager.rollback();
		}
	}
	public void storeAccount(Account a) {
		manager.start();
		try {
			// write some sql code storing a into the DB
			manager.commit();
		} catch (DBException e) {
			manager.rollback();
		}
	}
	...
}

Claramente dá pra perceber que eu tô misturando dois concerns na mesma classe. Um é persistência (salvar o User e a Account no banco de dados) e outro é controle de transações. Em OO, não tem um jeito elegante de separar esses concerns. Você pode até tentar fazer uma interface com uma callback pra tentar minimizar a repetição de código, como no código abaixo, mas não fica ideal.

public interface TransactionalTask {
	public void execute();
}
public class TransactionManager {
	TransactionManager manager = ...;

	public void executeInTransaction(TransactionalTask task) {
		manager.start();
		try {
			task.execute();
			manager.commit();
		} catch (DBException e) {
			manager.rollback();
		}
	}
	...
}
public class DB {
	public void storeUser(User u) {
		manager.executeInTransaction(new TransactionalTask() {
			public void execute() {
				// write some sql code storing u into the DB
			}
		});
	}
	...
}

A idéia de AOSD é criar um novo módulo (chamado aspecto) em que você possa encapsular esses concerns que não tem como você modularizar com classes. AspectJ é a implementação mais conhecida de AOP, tanto por ser a primeira, quanto por ser bem robusta e contar com apoio de diversas empresas. Em AspectJ, que é uma extensão de Java (todo código Java é código AspectJ válido), nós criaríamos um aspecto pra encapsular controle de transações. O pseudo código abaixo mostra a idéia (eu não testei o código, então não garanto copy-and-paste funcionando).

public aspect TransactionManagerAspect {
	TransactionManager manager = ...;

	around(Object o) : execution(public void DB.*(..)) && args(o) {
		manager.start();
		try {
			proceed(o);
			manager.commit();
		} catch (DBException e) {
			manager.rollback();
		}
	}
}

public class DB {

	public void storeUser(User u) {
		// write some sql code storing u into the DB
	}
	public void storeAccount(Account a) {
		// write some sql code storing a into the DB
	}
	...
}

A classe DB agora contém somente código relativo à persistência e o aspecto é responsável pelo controle de transações. Em terminologia de AOSD, around é um tipo de advice e execution um tipo de pointcut. O que esse código tá dizendo é que sempre que a execução do programa for iniciar um método publico, que retorna void, na classe DB, o método deve ser substituído (por isso “around”) por esse advice aqui. O código do advice vai fazer o controle da transação e vai chamar proceed pra executar o código original. Note que o código do advice é muito parecido com a nossa solução usando callbacks. A grande novidade aqui é que usando pointcuts a gente consegue especificar quando que a “callback” deve ser usada, deixando o código da classe DB bem mais limpo.

Esse exemplo mostra a parte dinâmica da história, isto é, como usar aspectos pra “interceptar” alguns pontos da execução de um programa e inserir (ou remover) funcionalidade (código) nesses pontos. Mas AOSD também trata da parte estática ou “estrutural” da coisa. Por exemplo, imagine que no nosso exemplo nós quiséssemos inserir um controle de concorrência bem primitivo, pra garantir que ninguém modificou o User no tempo entre eu buscar no banco e salvar. Pra isso, eu poderia adicionar um campo na classe User com um contador que é incrementado sempre que ele for salvo no banco. Desta forma, na hora de salvar, eu confiro se o valor do contador no objeto que recebi é o mesmo do banco de dados. Se não for, significa que alguém alterou o objeto e eu recebi um objeto inconsistente. Novamente, o problema é que esse campo não faz parte do concern persistência ou modelo de dados. Portanto, não faria sentido eu declarar o contador na classe User. Pra resolver esse problema, AspectJ usa intertype declarations, que permitem a declaracão de campos e métodos em outras classes. Por exemplo, o código abaixo declara e inicializa um campo counter na classe User, removendo dela o concern tratamento de concorrência.

public aspect ConcurrencyManagerAspect {
	long User.counter = 0;
	...
}

Conceitos

Quando eu estava descrevendo o exemplo eu me referi à alguns conceitos de AOSD. Mas acho importante deixar um pouco mais explícito, então seguem algumas definições.

Existem alguns eventos que acontecem durante a execução de um programa que são interessantes de serem interceptados. Esses pontos são chamados join points. Nós vimos que a execução de um método é um ponto interessante quando o objetivo é substituir o método ou introduzir funcionalidade antes ou depois do método. Outros join points, por exemplo, são a chamada de um método (não confundir com a execução), a leitura ou escrita de um campo, ou a inicialização estática de uma classe. Mas esses join points são eventos concretos que acontecem em tempo de execução. Pointcuts são um jeito de especificar de forma abstrata (por exemplo, com regular expressions) quais join points você quer interceptar. AspectJ oferece pointcuts primitivos pros join points mais importantes (como execution, call, get, etc) e outros pointcuts usados pra identificar os objetos envolvidos nos eventos e ligá-los a variáveis. No nosso exemplo, args foi usado pra pegar uma referência ao objeto passado como parâmetro ao método. Outros pointcuts importantes são target (e.g., o objeto que é o destino de uma chamada de método) e this (e.g., o objeto que faz a chamada).

Quando um join point acontece em runtime e ele faz match com um pointcut, então se executa o advice relativo ao pointcut (se tiver algum). Nós vimos como um advice do tipo around funciona. AspectJ também tem advices before e after (que pode ser after throwing ou after returning), que servem pra introduzir código antes ou depois do join point. Intertype declarations também são disponibilizadas por AspectJ pra introduzir novos campos métodos em outras classes, como vimos no exemplo.

Um aspecto é então um módulo usado pra encapsular todas essas construções, do mesmo jeito que uma classe encapsula métodos e campos. O objetivo principal de um aspecto é de modularizar um interesse (concern) que não faz parte da decomposição normal da hierarquia de classes. Esses concerns são chamados de crosscutting concerns, porque eles entrecortam a hierarquia. A implementação de um concern é dita espalhada (scattered) quando ela não está localizada, e entrelaçada (tangled) quando ela está misturada com outros concerns.

Pra quem tiver interesse, o AspectJ Programming Guide é um excelente tutorial com bons exemplos e referências pros diversos tipos de pointcuts, além de explicar alguns problemas que você pode encontrar quando não tiver muita experiência com aspectos.

Discussão

No texto acima eu tratei AOSD e AOP quase como sinônimos, mas eu quero enfatizar que são distintos. Orientação a aspectos surgiu como AOP, pois trazia soluções pra problemas diretamente ligados ao código, como no exemplo sobre controle de transações. Contudo, percebeu-se que seria interessante elevar o nível de abstração e que crosscutting concerns podiam também ser encontrados em design, arquitetura, análise de requisitos, etc. Então AOSD trata não só da programação, mas também de todo o conjunto de metodologias, processos, etc, ligados ao desenvolvimento de software usando a idéia de que crosscutting concerns devem ser tratados como “first class citizens”.

Na minha experiência, AOP como encontrada em AspectJ é utilizada quase que exclusivamente em círculos acadêmicos. Existem algumas empresas que adotam AspectJ para alguns projetos, mas a linguagem está longe de ser adotada em larga escala. Porém, alguns conceitos de AOP são muito usados em alguns frameworks e application servers como Spring e JBoss. Spring, por exemplo, tem o conceito de interceptors, que nada mais são do que pointcuts e advice, mas menos poderosos (não permitem interceptar join points de pouca granularidade, como getters, se não me engano).

Eu acredito que existem atualmente dois grandes impedimentos pra se usar AOP em larga escala. Primeiro é a tecnologia do compilador. Hoje em dia ninguém aceita trabalhar com um compilador que não seja incremental. Quando você usa Eclipse e faz uma alteração no código, o JDT só compila o necessário. O similar para AspectJ, AJDT, tenta fazer o mesmo. Porém, a tarefa é muito mais difícil, pois uma pequena mudança tem que ser verificada perante todos os pointcuts do seu sistema, pois de repente o que você mudou pode agora ser interceptado pelo pointcut. Assim, apesar de ter uma performance relativamente boa, trabalhar com AspectJ usando AJDT não é tao agradável quanto trabalhar com Java usando JDT.

Segundo, AOSD não vai acabar com todos os seus problemas. É difícil pros programadores entenderem os conceitos e leva tempo pra comunidade desenvolver design patterns e entender o que tirar de melhor do paradigma. Pointcuts são atualmente regular expressions, então eles são frágeis e qualquer mudança de nome de um método pode fazer um pointcut não mais interceptar aquele método, e você não tem como perceber que isso aconteceu. Suporte de boas ferramentas é então essencial. Além disso, eu tenho dúvidas de que aspectos sejam bons pra modularizar concerns heterogêneos como “logging”, que foi sempre um dos principais exemplos. O problema é que cada instância de logging é muito específica pro contexto, então não faz sentido você remover todas as chamadas de log e encapsular em um advice, pois o advice teria que ser diferente pra cada ponto que ele interceptasse. Controle de transações é homogêneo, pois o advice sempre faz a mesma coisa, então é um exemplo mais apropriado. Existem estudos que apontam que Mixin Layers são melhores pra concerns heterogêneos como logging, mas isso seria assunto para um outro post.

==========================
Nota no dia 5/11

Conversando com o Miguel eu acabei percebendo algo que talvez não tenha ficado muito claro. AspectJ é uma extensão de Java e precisa de um compilador especial que compila as classes como se fossem Java e depois analisa os aspectos do sistema e faz diretamente as modificações no código (ou introduz testes de tempo de execução quando não tem como verificar estaticamente o resultado). Esse último passo, “introduzir os aspectos”, é chamado weaving.

Existem duas alternativas principais de compiladores pra AspectJ. O ajc é parte do AJDT, que é uma extensão do JDT do Eclipse. Como o JDT, o AJDT contém editor, compilador, debugger, e tudo o mais, implementados em plugins pro Eclipse. O principal objetivo do projeto é que a compilação seja rápida pra que você tenha a mesma experiencia que programando em Java, ou seja, ele tenta ser incremental e o código do compilador em si é otimizado (leia-se, não-facilmente extensível).

A outra alternativa é o abc (Aspect Bench Compiler), que é um compilador acadêmico cujo objetivo principal é ser extensível pra que se possa fazer pesquisa com linguagens de programação, otimização de código, análise estática, etc. Dessa forma, compilar um sistema grande com abc, principalmente usando as otimizações disponíveis, é bem demorado. O ideal é programar usando o AJDT e usar o abc pra gerar o bytecode de produção, já que ele é bem mais otimizado que o gerado pelo ajc.

Além disso, AspectJ não é a única linguagem orientada à aspectos derivada de Java. No site da aosd.net, por exemplo, tem uma lista com alguns sistemas (derivados ou não de Java) e algumas ferramentas orientadas a aspectos.

Baseado na tecnologia Adobe Flex e Adobe AIR, o SlideRocket permite criar, compartilhar e exibir apresentações online. Os pontos fortes do sistema são a interface de criação de slides, a qualidade do resultado e a possibilidade de exibir online (em modo fullscreen) ou de criar um executável para o Desktop com o AIR.

Tive a oportunidade de ver uma apresentação utilizando esta ferramenta, e achei os resultados surpreendentes. Segundo um amigo marketeiro e criador constante de apresentações, apesar de alguns bugs a facilidade de uso vale a pena. Em alguns casos, como incluir vídeos em Flash, o software  é inclusive superior ao Powerpoint. 

O sistema oferece 3 opções de  planos. O plano gratuíto oferece 250MB de espaço, ferramentas de criação e número ilimitado de apresentações (desde que não ultrapassem os 250MB, obviamente…). Os planos pagos oferecem, entre outras coisas, mais espaço e possibilidade de controle de versão.

Sim….

Uma das grandes coisas que Java trouxe para o mundo do desenvolvimento foi uma moderna JVM, e um Garbage Colector eficiente, que foi se aprimorando ao longo dos anos. Com isto, o desenvolvedor pode deixar de se preocupar com questões de alocação e liberação de memória, fontes de perdas de cabelos e noites de sono perdidas de muitos programadores C/C++.

Nestas linguagens, um vazamento de memória se caracteriza como sendo uma região do heap alocada pelo desenvolvedor em algum momento do ciclo de vida de um software, cujo ponteiro se perde. Assim sendo, fica impossível (ou pelo menos extremamente difícil) recuperar esta área de memória para uso futuro. O efeito imediato é que o consumo de memória vai aumentando com o tempo, até tornar o sistema inviável.

É fato que este tipo de situação não existe em Java, uma vez que em última instância, a JVM sempre terá uma referência para uma área de memória alocada pelo desenvolvedor, e cuidará de fazer a limpeza caso necessário. Mágica? Não, tecnologia. Explicando de forma beeeeeeeeeeem resumida, o GC mantém uma contagem de quantas referências criadas pelo desenvolvedor apontam para um determinado objeto. Quando este contador chega a zero, está na hora de limpar a memória, pois com certeza esta não será mais útil.

Fica claro então que áreas de memória nunca serão perdidas em Java.

Miguel, você bebeu? Como é que vazamentos podem ocorrer então?

Bom, quem nunca perde a referência é a JVM.  Mas é possível perder o controle das referências para um objeto. Como eu disse antes, o GC coleta objetos sem referência. Mas e se você esquecer que tem referências perdidas no código e não zerá-las? Aí o objeto nunca será removido, e podemos ter um vazamento de memória, segundo Java. Para apaziguar certos ânimos, passarei a chamar este problema de Travamento de memória.

A boa notícia é que é bem mais fácil consertar em Java, e isto só se torna um problema real em grandes projetos que criam muitos objetos ao longo do tempo. Se você desenvolve exclusivamente para Web usando servidores de aplicação como JBoss, provavelmente pode fechar este artigo e voltar às suas atividades cotidianas.

A má notícia é que como se criou o mito de que este tipo de situação é impossível, ninguém hoje em dia se preocupa mais com isso. Não que isto seja ruim por si só. O problema é que quando suspeitamos de que isso pode estar acontecendo, consertar pode ficar mais complexo.

Uma situação clássica que pode gerar travamentos é o uso de Observers/Observables. Suponha que você tenha um objeto A do tipo Observable, e que ao longo da vida do seu software, você crie constantemente novas intâncias de objetos do tipo B que se cadastram com observadores de A. Nesta arquitetura, A contém referências a todos as intâncias de B, de forma não explícita (ou seja, contém referências à interface Observer). Basta alguém esquecer de limpar a referência da lista de observers e pronto…memória travada!

Como resolver isso? Bem, tentar racionalizar o processo de criação e limpeza de objetos, centralizando estes processos em pontos bem controlados. O processo de “limpeza” de recursos é muito importante, sobretudo quando a árvore de objetos e referências for grande.

==========================

Nota do dia 26/10

Como bem lembrado pelo leitor Thiago, uma outra possível solução é o uso de WeakReferences em Java. Um objeto deste tipo funciona como uma referência normal em Java, mas não trava o GC: caso um objeto seja referenciado apenas por WeakReferences, ele será coletado normalmente. Vale a pena olhar este artigo:

http://www.ibm.com/developerworks/java/library/j-jtp11225/index.html

Comecei a utilizar Emacs no início da minha primeira iniciação científica, nos idos de 1999. Fui feliz durante muito tempo, escrevendo código em Perl e C, algumas páginas HTML, diversos relatórios em Latex … tudo muito tranqüilo, nenhuma reclamação com aquele ambiente de desenvolvimento.

Eis que por volta de 2002, ao definir a linguagem de programação que iríamos utilizar na Scylla, optamos por Java, uma linguagem até então desconhecida para mim. Arregacei as mangas, peguei meu Emacs, e mandei bala. Tudo muito tranqüilo, afinal não tinha parâmetro de comparação. Até que fui apresentado ao Eclipse: auto-complete, code-checking durante a digitação, etc e tal - Como pude viver sem isso? - programar em Java ficou muito fácil.

Tudo ia muito bem, até há pouco tempo atrás, quando por razões que nem o Padre Quevedo poderia explicar, a configuração de meu ambiente de desenvolvimento foi para o espaço, sem formas de recuperá-lo. Isto, associado à vontade dos orixás da conexão internet intermitente (vulgo péssima estrutura de TI), impediram que eu conseguisse baixar uma outra versão do meu querido Eclipse. Após falhar neste teste de paciência, decidi que tinha de voltar a trabalhar com o que eu tinha à mão. Resultado: tirei a poeira do Emacs e o coloquei para trabalhar.

O começo foi duro: vários impropérios foram proferidos por conta de erros de digitação que resultavam em erros de compilação; sem contar no aumento de caracteres que tive que passar a digitar - já não me lembrava mais que era preciso escrever imports (aliás, não lembrava que a classe Connection estava em java.sql e que a classe DataSource em javax.sql ?). Mas muitos xingos e litros de café depois, me adaptei a esta nova realidade.Neste instante, compreendi claramente a diferença entre JaL e JaP - (Java a Linguagem x Java a Plataforma - veja os comentários).

Não quero defender aqui que a verbosidade de Java, condenada veementemente por alguns, seja um impedimento ao uso da linguagem ( devagar com as críticas Lullis, por favor ), mas vejo esta verbosidade como um atributo para melhorar sua forma de programar. Agora, penso melhor no código que escrevo, procuro formas de reaproveitar o código … até mesmo os nomes das variáveis que utilizo são pensadas de forma a evitar a fadiga. Coisas que eu não tinha porque me preocupar, pois tudo era muito simples, graças ao poder do Ctrl Enter.

Não defendo tampouco a aposentadoria de ferramentas como o Eclipse. Gostaria de voltar a utilizá-lo no futuro. Mas neste instante, pretendo continuar a utilizar o Emacs por um bom tempo, forçando-me a melhorar minhas práticas, e então sim, voltar para o Eclipse, que inegavelmente é uma ferramenta fantástica para aumento de produtividade.

Atendendo a decisão judicial a Telefônica não pode mais prestar o “acesso” à internet diretamente aos clientes do Speedy.

A partir de 21 de agosto de 2008, para utilizar o Speedy os novos clientes deverão contratar um dos diversos provedores de acesso à internet existentes no mercado. Alguns destes provedores, em parceria com a Telefônica, fazem ofertas especiais para clientes Speedy.

Os clientes Speedy que realizam o acesso à Internet diretamente pela Telefônica, receberão um comunicado específico estabelecendo a data limite para contratação de um dos provedores disponíveis no mercado.

OK, na prática isto quer dizer que aquele usuário internet@speedy.com.br não irá mais funcionar.

Mas o mais interessante é notar na cara de pau da primeira frase:  “Atendendo a decisão judicial a Telefônica não pode mais prestar o “acesso” à internet diretamente aos clientes do Speedy.”. Primeiro por que deixa a entender que a empresa estava permitindo acesso direto sem necessidade de provedor externo de autenticação por vontade própria, o que é falso: foi uma liminar da justiça de São Paulo que a obrigou a fazer isso.

Segundo porque o texto faz parecer que o tal acesso é algum serviço complexo prestado por ela. Ora, todos sabemos que o tal “acesso” se resume a simplesmente verificar uma senha em uma base de dados! E além do mais, o único serviço prestado de fato pela Telefônica é o de fornecer o acesso à Internet!

Aos descontentes, eu diria que existem basicamente dois caminhos: um caminho possível é mudar de provedor de banda larga, para um que realmente possa oferecer acesso à Internet. A outra é entrar na Justiça. Um bom ponto de início para isso seria o site ABUSAR (http://www.abusar.org.br/).

===========================================

NOTA DO DIA 07/11/2008

A partir de hoje, o Speedy realmente não pode mais dar acesso sem um provedor externo. Veja mais em http://log4dev.com/2008/11/07/speedy-agora-realmente-nao-pode-mais/

Esta brincadeirinha, disponível para acesso aqui (http://www.google.com/search2001.html) permite fazer duas coisas interessantes. A primeira é relembrar como era a Internet de 2001, quais os assuntos na moda e quais os termos que ainda estavam por vir. A segunda é ver como o design das páginas evoluiu nestes 7 anos, pois é possível ver a versão atual da página e a versão da época.

Fiz a busca pela palavra iTunes, e comparei os dois primeiros resultados. O primeiro é o site da Apple, versão 2001 e versão 2008 . O outro é um artigo da revista Business Week, sobre o tocador, O texto original continua lá, mas o design da página mudou bastante, de 2001 para hoje.

Mais informações podem ser encontradas no Official Google Blog.

======================================================

Correção: como foi bem anotado pelo nosso leitor esquentadinho Luis, digno habitante do mundo real (porque o meu aparentemente é o mundo de Alice, quiçá da Lua) , o cache das páginas vem do Internet Archive que, confesso, eu não conhecia. Mas é culpa da mídia do meu mundo, um tanto quanto lerda….

My Cousin’s Buddy is a Web Designer

Then let him do it.

The money you save by using your cousin’s buddy is nothing compared with the cost in time and money required to undo his mistakes.

Simples. Perfeito.

De lá para cá, foram um Performa, três iMacs, um eMac e alguns notebooks. E em todas as aquisições, sempre tinha o lado de “Apple é coisa de rico, é elitista, não tem assistência técnica no Brasil…”. Não deixava de ser verdade. Mas tem algo no ar: a percepção e a visão do público em relação à Apple está, em minha humilde opinião, mudando. Eu vejo a quantidade de pessoas a minha volta, computeiros ou não, que hoje pensam seriamente em comprar um MacBook, ou um MacBookPro, ou um iMac. Com certeza, a adoção da plataforma Intel, o dólar favorável e consequentemente a redução dos preços ajudou bastante. O efeito iPod/iPhone também. E em geral todos eles ficam extremamente felizes com a troca.

Motivos para se ter um Mac acho que não faltam. Vou listar alguns aqui, que para mim são bem importantes, e que acho que podem ser importantes para o público deste blog.

Antes do Mac O X, o grande trunfo do sistema operacional da Apple, além de sua usabilidade excepcional, era a sua altíssima integração com o hardware. Isso lhe dava a estabilidade que muitas vezes faltava ao Windows, que tinha (e ainda tem que) dar suporte à uma infinidade de drivers e periféricos, muitas vezes de baixa qualidade. Por este motivo muitos aplicativos complexos (como Photoshop) apresentavam benchmarks melhores no Mac do que em PCs com processadores mais rápidos.

Mas com o OS X, baseado no BSD e no microkernel Mach, a Apple adotou de vez as qualidades dos sistemas UNIX Like: um sistema realmente multiusuário, multitarefa preemptivo, com memória compartilhada. Ou seja, além do hardware extremamente bem controlado, agora o Mac oferece um SO moderno, eficiente e muito mais robusto.

E daí os leitores me perguntam: “se OS X é Unix like, porquê então gastar os tudos num Mac se eu posso ter um PC mais barato rodando Linux?” Boa pergunta! Eu diria que a resposta está nos detalhes. Eu gosto muito de Linux, tanto que recentemente mandei o Windows da minha máquina de trabalho pro espaço e instalei o Ubuntu. E isso com certeza aumentou muito a minha produtividade e felicidade. Inclusive, fiquei extremamente bem impressionado com a evolução do processo de instalação e da interface gráfica do Linux, dos quais eu estava afastado desde 2006.

Mas eu ainda tenho um pé atrás com ter Linux no meu computador pessoal. Porquê tem horas que eu quero desenvolver, hackear o sistema, fazer scripts. Mas em muitos momentos eu quero simplesmente que as coisas funcionem, quero que minhas placas de rede, vídeo, câmera embutida, HDs externos e afins sejam reconhecidos e integrados ao resto do sistema sem ter que ficar pesquisando horas em fóruns. As vezes quero não ter que escolher entre as milhares de opções de aplicativos para música ou vídeo. E sobretudo: eu sempre quero ter uma interface gráfica que funcione perfeitamente, que seja redonda e bonita. E aí chegamos ao outro grande trunfo da Apple: colocar uma interface gráfica matadora por cima do Unix, chamada Aqua. A Sun parece ter desistido de tentar fazer isso há um bom tempo, porquê o ambiente gráfico de suas estações de trabalho são muito fracos. O KDE e o Gnome me parecem estar no caminho certo, e estão bem pertos de ter um ambiente pronto para usuário final.

Até agora eu só falei do software. E o hardware, não tem nenhuma vantagem? Bom, se olharmos friamente apenas características como placa mãe, placas de vídeo, rede, processador, talvez não. Mas de novo, a diferença está nos detalhes. Está no conector magnético do cabo de energia (que já me salvou de desastres umas três vezes). Está na câmera embutida de altíssima qualidade. Está no teclado do MacBookPro com backlight, que ajuda muito a escrever em situações de baixa luminosidade. Está no acelerômetro que proteje o HD em movimentos bruscos. E sobretudo: está no design incrível, que permite que máquinas sejam clean, leves e finas. Além de bonitas. Acho isso bem importante.

“OK, OK, e os aplicativos do mundo Windows que eu amo tanto? Existe equivalência? E eu posso integrar um Mac no ambiente Windows da minha casa ou trabalho?”.

Sim, na grande maioria dos casos. Pacote Office da M$ (que é sagrado para boa parte da população usuária de Windows) existe para Mac, e tem compatibilidade total com o pacote para Windows. Aplicativo de IM, como MSN, Skype tem verão nativa, e existem vários programas que são compatíveis com GTalk, ICQ e MSN. Grande parte das ferramentas de processamento de imagens como Photoshop, Lightroom e outras tem versões nativas. O OS X é compatível com redes Windows, permitindo que arquivos sejam compartilhados entre Macs e PCs de forma transparente. Boa parte das impressoras oferece drives para ambos os sistemas operacionais e o processo de instalação é bem simples.

E se tudo mais falhar, ainda existe a opção de instalar Windows dentro de uma máquina virtual, com o Virtual Box da Sun, ou o VMWare Fusion ou o Paralels. Instalei o VMWare Fusion no meu MacBookPro, e o resultado é muito bom. A versão 2.0, divulgada há pouco tempo permite que aplicativos Windows rodem de forma completamente integrada no ambiente Mac, sem a necessidade de uma janela da máquina virtual, e permite que atalhos sejam criados no sistema para ativação automática. Além do mais, eles garantem a compatibilidade total de vários jogos.

“Ahá, peguei você: JOGOS! A listinha de vinte e poucos jogos que rodam no VMWare Fusion não me impressiona. E aí?”. Pois é, chegamos ao único ponto sensível: jogos. A lista de jogos que estão sendo publicados para Mac está aumentando, mas ainda não chega aos pés da lista de jogos pra Windows. Mas neste caso, existe sempre a possibilidade de se instalar o Windows diretamente no Mac com um sistema de dual boot. Neste caso, todos os jogos rodam perfeitamente.

E para todo o resto, existe o Mac OS.

Preços: de 1000 a 3000 na Claro, e de 899 a 2199 na Vivo.

Acho que não será agora que terei meu iPhone. Muito caro!

Será no dia 26 de setembro, em evento conjunto da Apple, Claro e Vivo. O telefone será lançado também na Turquia neste dia.

Mas a pergunta quer não quer calar: quanto vai custar o bendito?! Isso nem Jobs deve saber……

Essa foi a parte propaganda para o evento, agora vem a propaganda para mim. Meu irmão comprou o ingresso para o evento quando eles estavam com uma promoção para ingressos adiantados, e pagou 300 reais. Depois eles criaram uma promoção de 100 reais para estudante. Como a organização disse que não tem como devolver o dinheiro, eles deram 3 opções pra quem comprou antecipado mas tem direito a estudante:

• ele pode transferir o ingresso antigo para alguma outra pessoa e comprar um de estudante;
• ele pode dividir o ingresso dele com mais 2 estudantes; ou
• ele pode desfrutar de um credito de 200 reais em serviços de um patrocinador do evento.

Eu não entendo muito bem essa historia de “não tem como devolver o dinheiro”. Pelo menos neste ano ainda não tem CPMF, então bastaria eles colocarem de volta 200 reais na conta, ou devolver no cartão de credito, ou mesmo entregar em mãos. Mas de qualquer forma, pelo menos eles estao tentando ressarcir de alguma forma.

O problema é que meu irmão não conhece ninguém que esteja interessado, e também não está interessado em nenhum produto do patrocinador. Então, se alguém se interessar e quiser dividir a entrada ou comprar a entrada pelo preço antecipado, entre em contato comigo e a gente tenta ajeitar isso.

Vale lembrar que o preço (mesmo o de 300 reais) é muito barato pelo retorno que traz: palestras de altíssima qualidade, contato com gente interessante e ainda contando com almoço e coffee breaks. Queria eu estar no Brasil nesses dias!

Usuários do Emacs sabem que esta tecla é o atalho para o Meta, base para a maioria dos comandos. Mas é também, infelizmente, a tecla necessária para se escrever a maioria dos acentos no teclado Mac: Alt+e+e = é, Alt+c = ç, Alt+n+a = ã, e assim por diante.  Aliás, isto apenas corrobora o fato de que nada é perfeito no mundo.

Por default, o Emacs processa o Alt como Meta. Portanto, enquanto a Apple não lança um teclado decente, devemos abdicar dos acentos?

Não! O povo do Aquamacs ofereceu uma ótima solução. Os comandos

(setq mac-option-modifier nil)
(setq mac-pass-option-to-system t)

dentro do arquivo .emacs forçam o editor a repassar o controle da tecla Alt para o sistema operacional, reestabelecendo a funcionalidade do acento. Mas desta forma, temos que usar o pouco ergonômico ESC para obter o Meta?

Também não! É possível mapear outras teclas para esta função. Uma possibilidade é o Command (tecla da maçã), através do comando

(setq mac-command-modifier ‘meta)
que inclusive apresenta a vantagem de ser ao lado da tecla Alt. Por outro lado, bloqueia o acesso a atalhos específicos do Mac, como Command + S. Isso talvez não seja nenhum problema para os mais puristas do sistema do Stallman.

Outra solução é mapear a tecla Fn (function) para assumir a função de Meta, através do comando

(setq mac-function-modifier ‘meta)

Esta foi a minha solução favorita e definitiva!

Olá!

Gostaria de levar a conhecimento de vocês que consegui meu trabalho através do job4dev!
Na verdade isso já tem 3 meses e meio. Estava para fazer isso há um tempo, mas sempre algo impedia.
Hoje estou aqui pra expressar minha gratidão a vocês! Muito obrigado!

Empresa que me contratou: Apontador.com (atualmente Apontador MapLink)

Parabés por essa iniciativa.
Vou publicar a gif de vocês no meu site.

Abs!

Não sei quanto a vocês, mas este tipo de feedback só faz aumentar a minha motivação e a minha convicção de que este projeto está no caminho certo.

Está sendo uma semana agitada para o twitteiros de plantão.

Primeiro veio o blip.fm que é uma rádio customizada que você pode integrar em diversas plataformas de microblogging como twitter, pownce e Jaiku. Por essa eu passei ileso.

Agora veio o Chrome, o navegador do Google. Aí não teve jeito, vi a comoção geral das pessoas no twitter (procure pela tag #chrome no summize.com e entenda) e instalei a novidade. As primeiras impressões são positivas, mais por ser do google do que por ser bom mesmo, até proque não deu tempo de avaliar os recursos disponíveis. Mas em linhas gerais gostei do melhor aproveitamento da tela - a navegação é fullscreen por default -, gostei dos atalhos de páginas favoritas para desktop, aprovei a intolerância para com pop-ups e achei ótimo que eles tenham mantido uma estrutura semelhante à do firefox.

A pergunta que não quer calar: vou trocar o Firefox pelo Chrome? Por enquanto não porque ainda não existem os plug-ins para twitters e delicious da vida. Mas é uma questão de tempo. O Google é o midas digital, tudo que ele toca (ou quase tudo) vira ouro.

Aposto que em breve eles lançarão um banco.

[Patrice Lamiral, além de leitor do log4dev, é marketeiro, entusiasta de novas tecnologias e mídias digitais e baixou o Chrome antes que muito computeiro por aí… ]

O código, em linguagem C, era algo como o seguinte:

do {
  __alguma_coisa;
} while (false);

Em princípio fazer uma construção de laço para executar algo apenas uma vez parece algo bem bizarro, não?! Diria que é quase um primo-irmão do if (liberado==true). Foi exatamente o que eu achei. Mas colocando esta construção dentro do contexto em que eu a achei eu consegui ver (depois de alguma pesquisa, é claro) que ela é extremamente útil em alguns casos.

A primeira vez que eu me deparei com esta construção eu estava analisando o código-fonte do GNUChess, um jogo de xadrez de código livre. Como eu sei que o pessoal que escreve código livre algumas vezes utiliza umas construções bem diferentes do que normalmente estamos acostumados, resolvi investigar o porquê deles estarem utilizando esta construção. Afinal de contas, se este código é livre e várias pessoas já devem tê-lo revisado, não havia motivo para um laço aparentemente tão inútil estar lá sem alguma utilidade verdadeira, não é mesmo?!

E foi só pesquisar um pouco sobre o assunto para enteder melhor o que estava acontecendo. As construções como a acima só apareciam em definições de macros. Nunca em código “normal”. Para quem talvez não tenha muita familiaridade com macros em C, elas são basicamente códigos que você define e que serão literalmente expandidos pelo compilador onde seu identificador aparecer no código. Ou seja, um código assim:

#define macro_exemplo printf("Macro de exemplo!\n");
int main(void) {
  macro_exemplo
  return 0;
}

seria entendido pelo compilador, após o processamento das macros, da seguinte forma:

int main(void) {
  printf("Macro de exemplo!\n");
  return 0;
}

Ou seja, o preprocessador de código do compilador substitui a referência à macro_exemplo pela sua definição literal. No caso do nosso código bizarro, teríamos que definir a macro da seguinte forma:

#define macro_exemplo2 do { __alguma_coisa; } while (false);

ou ainda:

#define macro_exemplo3 do { \
                         __alguma_coisa; \
                       } while (false);

Note que uma macro deve ser definida sem quebras de linhas ou com quebras de linhas sinalizadas pelo caracter de escape barra invertida (’\').

Mas, ainda assim, não haveria motivo para o laço na minha macro, certo? Bom, se você pensar na macro como um código por si só, talvez isto esteja certo, mas não podemos esquecer que este código será copiado literalmente para algum outro lugar sempre que o identificador da macro for referenciado pelo programa. E muitas vezes não queremos fazer macros simples como as que eu mostrei no meu exemplo. Por exemplo, podemos querer fazer algo mais complexo como o seguinte:

#define IMPRIME_ESPACOS(n) for (int j = 0; j < n; j++) printf(" ");
#define ROTULO(rot) printf("L%d:", rot); do { \
          int n = numeroDigitos(rot); \
          IMPRIME_ESPACOS(6 - (n + 2))\
} while (false);

A macro IMPRIME_ESPACOS(n) imprime uma quantidade de espaços em branco representadas pelo “argumento” n. Estou usando argumento entre aspas porque o argumento de uma macro em C se comporta de maneira diferente de um argumento de função, já que não há checagem de tipo e sim uma simples substituição do valor passado como argumento da macro nas suas referências dentro da própria macro. Já a macro ROTULO(rot) recebe como “argumento” um rótulo e imprime Lrot seguido de um numero de espaços de tal forma que todas as linhas que chamarem a macro ROTULO(rot) estarão identadas na mesma posição (desde que o rótulo tenha menos de 6 caracteres, que era o limite utilizado no programa a partir do qual tirei o código de exemplo).

Alguém certamente já bateu o olho no código acima e deve ter dito: poxa, eu poderia chamar a função
numeroDigitos(rot) dentro de IMPRIME_ESPACOS na definição da macro ROTULO. Não podemos nos esquecer no entanto que macros não são chamadas de função e que onde se lê IMPRIME_ESPACOS em ROTULO dever-se-ia ler na verdade a definição de IMPRIME_ESPACOS. Neste caso, se passássemos uma chamada de numeroDigitos como “argumento” de IMPRIME_ESPACOS, a função numeroDigitos seria chamada dentro do loop definido em IMPRIME_ESPACOS sempre que a condição de parada do loop fosse ser calculada. Ou seja, teríamos um número excessivo e desnecessário de chamadas a numeroDigitos. Para solucionar este eventual problema, decidi criar uma variavel para armazenar o valor da chamada de numeroDigitos e passar esta variavel como argumento para IMPRIME_ESPACOS. O problema é que dependendo de onde este código for ser substituído pode não ser permitido ter declarações de variáveis.

Neste último caso (e em muitos outros), o código mostrado no início deste post, por mais bizarro que possa parecer a primeira vista, pode ser a solução, pois o uso do do { ... } while (false); torna possível a criação de um contexto local dentro das chaves do falso loop na macro. Dentro deste contexto é possível criar-se quantas variáveis se queira ou, por exemplo, encadear comandos dentro de uma macro que não ficarão perdidos se esta macro for utilizada dentro de um if-else.

Ah, e se alguém ficou curioso, procure na Internet: vocês verão muitos outros usos do do-while (false). Sinceramente, muitos deles, na minha opinião são dispensáveis e só servem para complicar código que poderia ser escrito de outra forma. E, pra falar a verdade, a única construção que eu já achei em códigos livres foi esta que eu cito aqui, dentro de macros. É preciso ter dicernimento na hora de usar este tipo de construção. Aliás, para falar a verdade, mesmo este caso que eu descrevi aqui, que eu acho interessante e útil eu só usária em últimos casos em códigos profissionais.