Nitidez em fontes do Linux

Microsoft, Apple e Linux. Ambos tem excelentes configurações de
fontes, embora o Windows e o Linux insistem em não habilitá-las por
padrão. Bom, o windows deve fazê-lo por alguma falha no
desenvolvimento e o linux porque ele imita a Microsoft, e já que o
windows por padrão não tem, ele tb não deve ter. Ok ok, sarcasmos a
parte, achei um tutorialzinho que dá a dica de como fazer no linux.
Ele está em: http://www.viamais.net/blog/?p=284.

Multimidia no Debian 64 bits

Hello World!

Estou há alguns dias usando o beta2 do Debian Lenny e as impressões
não podiam ser melhores. Tudo funcionou no meu hardware de primeira e
tudo muito rápido. Rápido mesmo!!!
Então, me deparei com um problema comum com os 64 bits... Multimidia.
Sempre é um saco, mas surpreendentemente deste vez não o foi. Achei um
tuto na web que resolveu 100% dos meus problemas:
http://wiki.forumdebian.com.br/index.php/Multim%C3%ADdia_no_Debian#multim.C3.ADdia_em_AMD64

Apos seguir estes passos, tudo funciona perfeitamente no meu Debian.
Até alguns videos que inexplicavelmente travam o QuickTime no OSX,
rodam perfeitamente nele. Aliás, ultimamente só tenho me incomodado
com o OSX. Acho que ele não vai com a minha cara.

Descobrindo em que tabela está determinado campo no Postgres

Hoje, tive que procurar em qual tabela estava determinado campo. No postgres, consegui rapidinho com a seguinte query:

SELECT pg_class.relname
   FROM pg_attribute JOIN pg_class
        ON (pg_attribute.attrelid = pg_class.relfilenode)
   WHERE attname = 'texto';

Sendo que o campo pesquisado eh 'texto'!


É isso aí pessoal! []`s

Mais wallpapers de alta resolução!

Gosto muito do feed do favoritos, e o link dos 50 wallpapers de natureza, de hoje, é muito bom.

Só para registrar o link...

Threaddumps em Java e como reportar bugs do NetBeans

Um recurso muito interessante do Java é o Threaddump. Em algumas situações, pode ser interessante saber o quê cada thread está executando (ou o que não está executando, se está esperando ;) ), e isto é possível através do comando:

kill -3

Importante: se você mandar -9, killa mesmo!

O output será algo assim:

Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode, sharing):

"JSP Parsing" daemon prio=1 tid=0x42c04100 nid=0x94c600 in
Object.wait() [0xb383d000..0xb383dd90]
at java.lang.Object.wait(Native Method)
- waiting on <0x0f3dbdc0> (a org.openide.windows.CloneableOpenSupport$Listener)

at java.lang.Object.wait(Object.java:474)
at org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:744)
at org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:715)
at org.openide.text.CloneableEditorSupport.getDocument(CloneableEditorSupport.java:788)
- locked <0x0f3dbdc0> (a org.openide.windows.CloneableOpenSupport$Listener)
at org.openide.text.CloneableEditorSupport.getInputStream(CloneableEditorSupport.java:1349)
at org.netbeans.modules.web.jspparser.ParserServletContext.getEditorInputStream(ParserServletContext.java:363)
at org.netbeans.modules.web.jspparser.ParserServletContext.getResourceAsStream(ParserServletContext.java:326)
at org.apache.jasper.JspCompilationContext.getResourceAsStream(JspCompilationContext.java:304)
at org.apache.jasper.compiler.JspUtil.getInputStream(JspUtil.java:890)
at org.apache.jasper.xmlparser.XMLEncodingDetector.getEncoding(XMLEncodingDetector.java:127)
at org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:360)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:194)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:140)
at org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:374)
at org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:411)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:554)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1626)
at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1880)
at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:1139)
at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1450)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1649)
at org.apache.jasper.compiler.Parser.parse(Parser.java:165)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:223)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:124)
at org.apache.jasper.compiler.GetParseData.parse(GetParseData.java:164)
at org.netbeans.modules.web.jspparser_ext.WebAppParseSupport$1.run(WebAppParseSupport.java:482)

"Inactive RequestProcessor thread [Was:Default RequestProcessor/null]"
daemon prio=1 tid=0x010f8e60 nid=0x91c000 in Object.wait()
[0xb8262000..0xb8262d90]
at java.lang.Object.wait(Native Method)
at org.openide.util.RequestProces sor$Processor.run(RequestProcessor.java:939)
- locked <0x0ef58008> (a java.lang.Object)
... e por aí vai

Este output será feito no console que iniciou a aplicação, então se você utilizou um atalho do sistema para iniciar e não tiver o console, tente ver no seu sistema onde isto será escrito (no Mac, utilize o Console).
Isto pode ajudar muito desenvolvedor a achar onde está o gargalo de uma aplicação.

Aí que entra como reportar bugs do NetBeans, e foi como descobri a existência dos threaddumps.
Ao reportar um bug, e este sendo de lentidão ou travamento, sempre que possível inclua o threaddump do netbeans.

NetBeans 6.1

Lançado o NetBeans 6.1!

Espero que nesta versão tenham melhorado alguns bugzinhos feios, como a indexação constante dos fontes e perca das referências (é, vc não consegue corrigir imports, ir para a classe...) e algumas lentidões.

Ah, o que mais me chamou atenção foi ter uma versão "Early access for PHP"...

P.S.: li primeiro no blog do Bruno Borges...

Leitura interessante (online): A Catedral e o Bazar

Hoje, percorrendo pelas páginas do Trac, achei um link muito legal, para quase todo o conteúdo do livro "A Catedral e o Bazar", de Eric S. Raymond.
Do próprio site:

Eu analiso um projeto bem sucedido de código livre, o fetchmail, que foi executado como um teste deliberado de algumas teorias surpreendentes sobre a tecnologia de programação sugerida pela história do Linux. Eu discuto estas teorias nos termos de dois estilos fundamentais diferentes de desenvolvimento, o modelo ``catedral'' da maior parte do mundo comercial contra o modelo ``bazar'' do mundo do Linux. Eu mostro que estes modelos derivam de suposições opostas sobre a natureza da tarefa de depurar o software. Eu faço então um argumento sustentado na experiência do Linux para a proposição que ``Dados bastante olhos, todos os erros são triviais'', sugiro analogias produtivas com outros sistemas auto-corrigíveis de agentes egoístas, e concluo com alguma exploração das implicações desta introspecção para o futuro do software.

Tá, eu sei que está um pouco desatualizado (data de 1998), mas achei interessante, por dar alguns pontos de vista de como tratar a equipe de desenvolvedores, beta-testers...

Ah, nas informações do projeto Trac consta que o objetivo é desenvolver e melhorar o próprio Trac, de forma colaborativa, no estilo bazaar...