DWA-142 no Ubuntu Hardy
Resumo aos impacientes
Seguir os passos indicados no wiki do Ubuntu para instalação do ndiswrapper e do ndisgtk.
Obtenha os drivers do DWA-142. Isso já é um pouco mais trabalhoso, uma vez que a D-link só distribui os drivers para Windows e ainda por cima, em um arquivo executável de instalação. A solução não-higiênica é instalar um Windows em uma máquina virtual, instalar o driver e pegar os arquivos. Nesse caso é necessário saber quais os arquivos do driver; a saber:
Mrvw243.sys,Mrvw245.sysenetmw245.inf.Execute os procedimentos do wiki do Ubuntu para instalar os drivers e reinicie a máquina.
Aqui em casa funcionou usando WPA2, apesar do wiki do ndiswrapper apontar ao contrário. Não funcionou, entretanto, configurar a rede em roaming ou via
nm-appletno GNOME. Configurar na mão, mesmo que forçando o uso de DHCP, funcionou como um charme.Reportar na net que Wireless e Linux já não é bixo de sete cabeças e que as pessoas podem parar de temer.
Um pouco de história
Ao pensar em como seria a minha nova rede doméstica, decidi que seria tudo wireless por uma questão de conveniência. Decidi também que utilizaria componentes com os quais poderia obter o melhor desempenho possível, porque — francamente — ter internet banda larga e ficar limitado a interfaces wifi de 54Mbps é uma péssima idéia.
Também assumi como uma premissa que iria fazer todo o setup funcionar no Linux, não importa o trabalho que eu viesse a ter. Assumi isso de maneira consciente porque eu sei que o suporte dos grandes fabricantes de hardware wireless para Linux é medíocre no melhor caso.
Comprei um roteador DIR-625 e um adaptador USB DWA-142, ambos da D-Link. Ambos suportam 802.11 N e, segundo o fabricante, se usados em conjunto, conseguiria velocidades de até 300 Mbps.
Fiquei temeroso de não funcionar adequadamente. Primeiro pq o adaptador está meio escondido e, segundo, pq o funcionamento dele no Windows não está 100%. Deve ter a ver com o fato de eu ter reiniciado o Windows só umas 3 vezes depois da instalação.
No Linux, entretanto, está impecável. Até agora não me deixou na mão. A falta de drivers para Linux faz com que o trabalho de instalação não seja trivial como todo o resto, mas também não lembra em nada as loucura que era instalar drivers para winmodems.
Pão-de-Cast S2E08
No ar, mais um pão-de-cast para o deleite daqueles que tem paciência de nos ouvir.
Nesse episódio, tudo aquilo que os nerds adoram, xiitismo e jihadismo em torno de linguagens e conceitos de programação.
ID Selector
Que o OpenID é uma ótima ideia, muitos já sabem. Que um número grande de sites, portais e afins estão se mobilizando para serem provedores, também.
Mas mais do que isso, são necessários consumidores para que o OpenID se estabeleça e se torne padrão.
Com isso em mente o anúncio do ID Selector, um widget que facilita o uso consumo de OpenID provenientes de diversas fontes pré-configuradas e desenvolvido pela JanRain, é uma notícia interessante.
Por outro lado, fico imaginando esse tipo de widget não deveria ser considerado um anti-pattern, com os desenvolvedores e o mercado adotando uma solução mais elegante.
Squeak developer images no Ubuntu
Instalando o Squeak e o squeak developer image no Ubuntu:
Adicione o seguinte repositório ao /etc/apt/sources.list:
deb http://ftp.squeak.org/debian/ stable main deb-src http://ftp.squeak.org/debian/ stable mainAtualize os repositórios e instale o Squeak:
sudo apt-get update sudo apt-get install squeakBaixe uma das imagens de desenvolvimento (squeak-dev ou squeak-web) e descompate o arquivo em algum lugar conhecido, por exemplo
/opt/squeak
A instalação registra as imagens do Squeak como executáveis, permitindo que uma imagem seja executada a partir da própria linha de comando, ou seja, para rodar a imagem de desenvolvimento do Squeak basta:
$ /opt/squeak/nome da imagem.imageNo meu caso;
$ /opt/squeak/sq3.9.1-7075web08.04.1.image
Knuth e Testes
Com o único propósito de colocar mais lenha na atual discussão sobre a entrevista do Donald Knuth, segue a minha opinião.
Quando eu penso em TDD, escrever testes antes do desenvolvimento e tudo mais, não penso somente em ter uma ferramenta de compliance, teste puro e simples de código e suporte a refatoração.
Para mim, a grande vantagem de se ter testes antes é ter um artefato muito interessante para levantar e capturar requisitos.
Testes são mais diretos e amigáveis para desenvolvedores do que longos e redundantes casos de uso. Nos testes, se é obrigado a pensar em como será utilizado o código sendo desenvolvido e o que, de fato, precisa ser escrito.
Em grandes ambientes — tenha em mente o meu campo de trabalho, sou um consultor corporativo que vendeu a alma — considero esse tipo de abordagem fundamental para, em última instância, manter a sanidade dos envolvidos no processo de desenvolvimento.
Nada contra hacking. Sou a favor e costumo concordar com linhas de raciocínio que defendem a prática. Mas existem sim situações onde testes são necessários, nem que seja para realizar o mais besta dos requisitos possíveis.
