HOWTO: Como fazer funcionar o microfone no Linux

Um problema recorrente nos fórums é o uso do microfone. Muitas pessoas tentam usar, por exemplo, o skype, mas o microfone está mudo.
Como solucionar?
Por algum motivo que não entendo até hoje, as distribuições (eu uso o Kubuntu) não vêm com estas configurações por padrão, mas, vamos lá...
Abra um terminal e execute o programa alsamixer. Você verá uma série de canais de volume. Pressione tab para alternar entre os modos playback, capture e all. No modo capture é que está o problema.
Placas de som diferentes possuem canais diferentes. Vou dar aqui dois exemplos, um do meu computador desktop e outro do laptop.
Desktop: Possui um chipset VIA. O comando lspci traz a seguinte informação:

80:01.0 Audio device: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller) (rev 10)

Tive que ativar a captura no canal "Capture" (usando a tecla de espaço) e aumentar o volume do canal "Digital".
Laptop: Possui um chipset Intel, identificado como:

00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

Aqui, foi necessário selecionar como "Input Device" o "Front Mic", que é o microfone embutido. Também aumentei o volume do canal "Capture" e selecioná-lo com a tecla de espaço.


Em ambos os casos, aumentar o "Mic Boost" ajuda para que o volume não fique baixo demais.

Mais KDE 4.1: Menu de compactar / extrair e plasmoid de início rápido

Quem já usou o KDE 4 (especialmente o 4.1), deve ter sentido falta de pelo menos uma coisa essencial no Dolphin (gerenciador de arquivos): ao clicar com a direita em um arquivo compactado, cadê o menu extrair? E ao selecionar arquivos e diretórios, cadê o compactar?
Bem, o fato é que oficialmente só no KDE 4.2. Mas, se você quer essa funcionalidade hoje, tem como!
Adicione o seguinte no seu /etc/apt/sources.list:

deb http://ppa.launchpad.net/samrog131/ubuntu intrepid main

Depois, rode os comandos:

sudo apt-get update
sudo apt-get install servicemenu-extractandcompress

Reinicie o Dolphin, e lá estarão os menus!

Outro elemento que falta para quem estava acostumado com o KDE 3.5 é um applet de início rápido (com vários atalhos em um só lugar). Para tal, após adicionar a linha acima no /etc/apt/sources.list e rodar o sudo apt-get update, rode:

sudo apt-get install plasmoid-quicklauncher

Depois, ao utilizar o adicionar widgets no painel ou na área de trabalho, você verá o QuickLauncher, para onde você pode arrastar os atalhos a partir do editor de menus ou do menu principal.

Driver NVIDIA e KDE 4.1

Quem já usou o KDE 4.1 em um micro com placa NVIDIA (usando o driver proprietário) sabe do que eu estou falando. Quando o cursor pisca em uma aplicação GTK, ao passar o mouse sobre o painel, os botões somem, piscam, mudam as cores...
E isso é um bug no driver da NVIDIA.
Era.
Acontece que foi lançado o driver 180.06 (beta), que pode ser baixado do site da NVIDIA (32 ou 64 bits), que corrige esse problema.
Basta baixar, abrir um terminal e executá-lo (chmod +x ;./).
Pronto. Aí é só alegria.
Ah, "de lambuja", a performance 2D ficou bem melhor também...
Só vale a pena lembrar que é um driver ainda beta, por isso, pode conter outros bugs... Mas no meu caso valeu (e muito) a pena atualizar.

[Atualização]
Atenção: Se você instalar o driver da NVIDIA manualmente, conforme descrito, sempre que seu kernel for atualizado (como aconteceu recentemente no Intrepid Ibex), o ambiente gráfico (X.org) não vai mais subir, e você terá que reinstalar novamente o driver.

KDE 4.1

Depois de algum tempo sem postar, uma atualização...
Eu sou um usuário do KDE de longa data.
Quando saiu o KDE 4.0, eu baixei e experimentei, mas ainda estava muito cru.
Em julho saiu o a versão 4.1, e eu não podia deixar de conferir...
No trabalho usamos o Ubuntu 8.04 (eu, particularmente, o Kubuntu). Pois instalei o 4.1.
Pôxa, acho que os caras estão fazendo um trabalho muito bom.
Não notei ele mais pesado que o 3.5, mesmo com muitos recursos a mais...
Ainda faltam algumas coisas, mas com certeza os caras estão no caminho certo.
E este fim de semana instalei o Kubuntu 8.10 (Intrepid Ibex) Alpha 5 em casa.
Como colocado na página, não é recomendado para quem se importa com bugs, pois ainda está em desenvolvimento... Mas o release promete.
Recomendo a todos que quiserem tentar o ambiente Linux, ou aqueles que já o conhecem, que experimentem instalar a versão final do 8.10 (que sai fim de outubro).
Vale muito a pena. O KDE 4.X chegou pra ficar.

Main layout by convention in Grails

Grails supports selecting the page layout either using the <meta name="layout" content="NAME"> tag or by convention, where the layout is grails-app/views/layouts/CONTROLLER.gsp or grails-app/views/layouts/CONTROLLER/ACTION.gsp.

I've asked myself several times why doesn't it support the main layout by convention? Maybe because of the partial pages retrieved by Ajax (like the <g:remoteLink> tag). Even on those cases, an heuristic might be applied to determine those cases. Let's go to the actual implementation:

Create a class called CustomLayoutDecoratorMapper on src/groovy:

import javax.servlet.ServletContext
import javax.servlet.http.HttpServletRequest
import org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper
import com.opensymphony.module.sitemesh.*
import org.codehaus.groovy.grails.web.servlet.GrailsApplicationAttributes
import org.codehaus.groovy.grails.web.metaclass.ControllerDynamicMethods

class CustomLayoutDecoratorMapper extends GrailsLayoutDecoratorMapper {

public Decorator getDecorator(HttpServletRequest request, Page page) {
Decorator decorator = super.getDecorator(request, page)
if (decorator == null) {
decorator = getNamedDecorator(request, "main")
}
return decorator
}
}

Then reference it on web-app/WEB-INF/sitemesh.xml, by changing the mapper tag, so that it looks like this: <mapper class="CustomLayoutDecoratorMapper">. Note that when running grails upgrade the file will be reverted to it's original form!.

Ready! No more need to declare the layout on every page. But, if the layout is declared, it will be honored.

But what about the Ajax requests? I can think of 2 approaches: The first one is easier for people using the Prototype framework. Just change the line:
if (decorator == null) {
to:
if (decorator == null && request.getHeader("X-Requested-With") != "XMLHttpRequest") {
Prototype adds the header X-Requested-With: XMLHttpRequest for Ajax requests. I don't know whether Dojo does something like that...

The second option is to declare an empty layout on Ajax pages with <meta name="layout" content="empty">, and create the layout called empty only with the tag <g:layoutBody>.

Hope this helps!

Layout principal por convenção no Grails

O Grails suporta a seleção do layout da página usando usando uma tag , ou por convenção para casos onde o layout é grails-app/views/layouts/CONTROLLER.gsp ou grails-app/views/layouts/CONTROLLER/ACTION.gsp.

Mas me perguntei algumas vezes porque ele não suporta um layout principal por convenção? Talvez por causa das requisições por ajax (como o com a tag %lt;g:remoteLink>), que retorna uma página parcial. Mas mesmo assim poderia usar um layout principal usando alguma heurística para esse caso. Vamos à implementação:

Crie uma classe chamada CustomLayoutDecoratorMapper no src/groovy:

import javax.servlet.ServletContext
import javax.servlet.http.HttpServletRequest
import org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper
import com.opensymphony.module.sitemesh.*
import org.codehaus.groovy.grails.web.servlet.GrailsApplicationAttributes
import org.codehaus.groovy.grails.web.metaclass.ControllerDynamicMethods

/**
 * Decorador de layout para permitir o uso de um layout global
 */
class CustomLayoutDecoratorMapper extends GrailsLayoutDecoratorMapper {

   public Decorator getDecorator(HttpServletRequest request, Page page) {
       Decorator decorator = super.getDecorator(request, page)
       if (decorator == null) {
           decorator = getNamedDecorator(request, "main")
       }
       return decorator
   }
}

Depois referencie essa classe no web-app/WEB-INF/sitemesh.xml, alterando a tag mapper para que ela fique assim: <mapper class="CustomLayoutDecoratorMapper">.

Pronto! Não precisa mais declarar o layout em cada página. Mas caso isso seja feito, será respeitado o layout definido.

Mas e os casos de requisições Ajax? Há duas abordagens. A primeira é mais fácil para quem usa o Prototype: Basta alterar a linha
if (decorator == null) {
para:
if (decorator == null && request.getHeader("X-Requested-With") != "XMLHttpRequest") {
Isso porque o prototype adiciona o cabeçalho X-Requested-With: XMLHttpRequest para requisições Ajax. Não sei se o Dojo faz algo do tipo...

A segunda opção é declarar um layout vazio em cada página parcial usar a <meta name="layout" content="empty">, e criar um arquivo de layout apenas com a tag <g:layoutBody>.

Espero que tenha ajudado!

Esta postagem também está disponível em inglês.

Linguagens de programação - De programador Java para programador Java

Aprendi programação em Visual Basic 3 (eca!), lá por 1995. De lá passei pro ASP (bah) em 2000, pro Java em 2001 e aí estou até hoje.
Mas desde o ano passado, venho estudando linguagens dinâmicas, como o Ruby e o Groovy. Já conheço há anos (e acho bem legal) o JavaScript, uma linguagem tão odiada entre os programadores para a web (o que acho uma injustiça). Mas cito Ruby e Groovy porque são linguagens que estão bem faladas hoje em dia, e têm uma infraestrutura bem completa.
Primeiro foi o Ruby. A linguagem é nota 10. É possível fazer coisas do tipo:

class String
 def bold
   "#{self}"
 end
end

Resultado: todas as Strings possuem um método bold, e se for invocado "teste".bold retornará teste. Para horror dos programadores Java mais conservadores, foi reaberta a definição de uma classe existente (e importante como a String), adicionado um método que nem tem um comando return e ainda por cima invocado sem usar parênteses!
E o que dizer de código tipo:

[1, 2, 3].collect {|x| x + 2}

O resultado? Um array contendo [3, 4, 5]. Assim também vários outros exemplos interessantes.
O Ruby tem sido muito impulsionado ultimamente pelo framework Ruby on Rails, que mudou drasticamente o conceito de framework web (Struts, Spring MVC...).
Apesar de muito interessante, a linguagem é bem distante do Java, e quem investiu pesado em formação e tecnologia Java (quem dirá servidores de aplicação) não vai querer jogar tudo fora...
Claro que existe o JRuby, que é uma implementação do Ruby para Java que é muito boa e permite fácil integração com classes Java, mas o "gap" ainda é grande.
Então conheci o Groovy, que tenta ser o mais próximo possível do Ruby, mantendo uma sintaxe bem semelhante à do Java. E tem também o framework Grails, que tenta trazer para o Groovy as facilidades do Ruby on Rails.
E o Groovy, junto com o Grails, é a minha aposta para o framework web. Certamente minha escolha para o próximo projeto Java. Ele "nasceu" integrado ao Spring e ao Hibernate, e pode ser instalado (algum termo melhor para deployed?) em qualquer servidor web Java.
Vale a pena dar uma olhada.
Claro que muitos ainda resistem à idéia de linguagens dinâmicas, pois se "perde o controle" que a tipagem estática oferece (apesar do Groovy permitir usar tipagem estática) e que "efeitos colaterais" de adicionar métodos dinâmicos em classes. Mas assim foi quando se passou do assembly para o C. Assim foi quando se passou do C para o Java. E assim está sendo para tornar o próprio Java obsoleto. Muito se fala hoje que o Java como linguagem está condenado. Mas a JVM é um ambiente sólido, performático e confiável, e esse sim, vai durar muito tempo.

Certificação Java

Em dezembro de 2004 fiz a minha primeira certificação Java (SCJP 1.4). Depois o tempo passou, e no ano passado (2007) tinha colocado como meta fazer a de desenvolvedor web. Como deixei para o fim do ano, acabei fazendo o exame no dia 27 de dezembro! Pode? Resultado: fiz até entrevista para o site da Sisnema. Quem quiser conferir, clique aqui.

JavaScripTools

Em julho de 2003 publiquei a primeira versão beta do JavaScripTools, que é uma biblioteca de funções e componentes JavaScript. Inicialmente a idéia era o uso de uma tabela que pudesse ser dinamicamente atualizada. Junto com ela, algumas funções genéricas faziam parte do pacote. Com o passar do tempo, a tabela foi ganhando cada vez mais opções, novas funções foram adicionadas, um conjunto de parsers e máscaras de digitação, para que o usuário possa, por exemplo, digitar números ou datas formatadas, além de máscaras personalizadas.
Quando o JavaScripTools foi publicado, ainda eram bem raras as bibliotecas JavaScript. Hoje existem inúmeros frameworks e opções (alguns dos mais conhecidos são: prototype, dojo, ext, yui, ...). Ainda assim, muitos sistemas utilizam o JavaScripTools, especialmente para as máscaras de digitação, que são bastante poderosas e customizáveis, além da tabela dinâmica.
Para quem estiver interessado, pode ver exemplos do JavaScripTools, ou baixar o pacote completo na página do Source Forge.

Free IT!!!

Este ano iniciou junto com uma nova empresa: Free IT.
Ela ainda é um exército de um homem só, mas não se pode subestimar o futuro, principalmente porque Deus está junto nessa!
O principal cliente da Free IT é a organização holandesa STRO, que tem um escritório em Porto Alegre chamado InStroDI, onde trabalho há quase 3 anos. Desenvolvemos o sistema Cyclos, que é um software bancário para projetos com moedas comunitárias.
Que este ano seja de sucesso aos projetos da STRO e da InStroDI, e de crescimento para Free IT.
Deus abençoe a todos!!!