A idéia deste artigo é tentar capturar dicas, conselhos e experiências dos leitores deste blog, para benefício próprio - e quem sabe de outros que talvez tenham o mesmo problema.

Há pouco tive uma conversinha rápida com o Miguel no GTalk, acabamos falando de planos futuros, projetos pessoais, etc e tals. E ele estava descrevendo que estava bastante contente com a concretização de alguns projetos pessoais, como aprender Python, Job4Dev, SigaSeuTime, fotografia, entre outros. Neste instante, comentei que admirava a sua disciplina, pois apesar de ter alguns planos, não conseguia me dedicar à execução dos mesmos se não tivesse alguma obrigação embutida.

Para tornar mais claro, vou dar dois exemplos pessoais que ilustram bem este problema:

1. Estava com o firme propósito de aprender Lisp para fazer desenvolvimento web (curiosidade pessoal gente, não atirem pedras, por favor). Comecei a estudar, brincar um pouco, e “puff”. O plano empacou. Não consegui me dedicar mais ao mesmo
2. decidi que era o momento de aprender estatística - me inscrevi como aluno especial em uma matéria sobre o tema na Esalq, e voilá … estou aprendendo.

Outro problema que sinto também, é balancear vida pessoal com estes objetivos de “desenvolvimento técnico-profissional“. Apesar de gostar muito do que faço, dificilmente troco uma cerveja com os amigos por algumas horas de programação em Lisp; ou então um treino/jogo de handebol pela leitura do artigo sobre MapReduce.

Exposto o problema, fica aqui o pedido de socorro aos leitores:

• O que vocês fazem para desenvolver a disciplina necessária para execução de projetos pessoais de “desenvolvimento técnico-profissional“?
• Como vocês fazem para determinar o equilíbrio entre as vidas pessoal e profissional?

Sintam-se à vontade de contribuir. Espero podermos reunir um bom material, e depois escrever um outro artigo a respeito (se não rolar nenhum churrasco no dia :-D)

Utilizando a mesma técnica do editor-chefe, de postar milhares de pequenos comentários sobre o que ele lê na internet, só para dizer que é super produtivo, vou compartilhar uma idéia muito interessante que li no blog Signal vs. Noise.

O autor conta que experimentou a sensação de trabalhar em pé, ao invés de sentado em frente ao computador, e segundo ele isto foi extremamente positivo. Segundo ele, quando sentado em sua confortável cadeira, sua postura era ruim, ele se distraía facilmente, e lutava constantemente contra a fadiga.

Trabalhando em pé, ele conta que sua atenção melhorou, assim como a capacidade de se concentrar em um problema por mais tempo.

Não sei se os ganhos de concentração seriam iguais para todos, mas acredito que os ganhos de bem-estar físico seriam ótimos, sem contar que eu não precisaria mais lutar contra o sono de manhã.

Esta idéia não é nova: várias pessoas têm observado esta prática,como Ernest Hemingway, Winston Churchill e Thomas Jefferson. Além disto, uma simples busca no Google sobre o tema irá lhe mostrar várias pessoas endossando a prática.

É claro que você não vai trabalhar em pé na mesa que você tem agora. Você precisará de uma mesa específica para este fim, mas opções não faltam.

Acho que vou tentar isto em casa. Se der certo, quero ver como vou convencer meu chefe a comprar uma mesa dessas pra mim, além de lidar com o fato de ser um estranho no ninho.

Para a felicidade de nosso editor-chefe, e para não ficar com a fama de ser o último a atender os incansáveis pedidos do mesmo, eis que após me deparar com um post que li no Suicyte Notes, um blog sobre bioinformática e coisas afins (viu editor-chefe, não só escrevo algo, como este algo é sobre bioinformática!!) e me animei a escrever.

O post comenta sobre um artigo que saiu na Nature, onde os autores descobriram um erro no programa utilizado para construir as famosas matrizes BLOSUM - matrizes utlizadas para pontuar alinhamentos entre aminoácidos, que se baseiam nas probabilidades de substituição de um aminoácido em outro (se tiver mais interesse no assunto, cheque os links). Estas matrizes têm sido empregadas por mais de 15 anos, e servido de base em diversos estudos científicos. Imagine o impacto que a descoberta deste bug não teria, levando milhares de pesquisadores a rever seus resultados.

No entanto, para a sorte dos autores do programa - Steven e Jorja Henikoff - que gerou estas matrizes, Murphy estava de férias naquele dia. O autor do artigo corrige o problema, refaz as matrizes, e faz a comparação entre as matrizes “zicadas” e as corrigidas. Resultado: as matrizes “zicadas” funcionam melhor que as corrigidas. Quisera Geoffrey Chang tivesse essa sorte.

Chang é um pesquisador que no início do ano passado, teve que se retratar publicamente, após ter publicado cinco artigos sobre estruturas de duas proteínas que ele e sua equipe haviam determinado. Cinco anos depois do primeiro artigo, 720 citações, e a comprovação por parte de outros grupos que as estruturas que eles haviam determinado estavam erradas, Chang e seus amigos descobriram um bug no programa que eles haviam criado, que resultou nas estruturas erradas. Ou seja, todos que desenvolveram pesquisas confiando nas descobertas de Chang, se deram mal. Incineração de filme no mais alto grau.

Fica aí a dica: se você não testa seus códigos, torça pra ter a sorte de Steve e Jorja, senão você pode se dar mal como Chang.

Há pouco meu caro amigo Miguel escreveu um artigo muito interessante sobre a facilidade que algumas linguagens oferecem ao utilizarmos expressões booleanas. A dica é muito boa, e certamente farei uso dela. No aspecto de legibilidade de código, não vejo problema algum.

No entanto, esta técnica me incomoda no aspecto de parecer anti-natural do ponto de vista da álgebra booleana, onde trabalhamos somente com dois valores (true/false, 0/1). Me parece misturar conversão de tipos de dados, com lógica booleana. Isso somente não me incomodaria, mas me fez pensar: que resultado eu terei de expressões como ( 0 == “”), (”" == null)? Será que ele adota o valor booleano pra comparar? Resolvi testar usando perl, python e javascript, e obtive resultados diferentes:

Perl:
> perl -e ‘ $a=0; print( “” == $a); print “\n”; ‘
> 1

> perl -e ‘ $a=0; print( nil == $a); print “\n” ‘
> 1

Python:
> python -c ‘_a=0; print ( _a == “” )’
> False

> python -c ‘_a=0; print ( _a == None )’
> False

Javascript:
> var a=0; alert( a == “” );
> True

> var a=0; alert( a == null );
> False

Bom, como podemos ver, cada linguagem de programação tem sua forma de tratar este tipo de comparação. Desta forma, fica aqui o toque para se tomar cuidado com esta técnica, levando-se sempre em conta as especificidades da linguagem que você está utilizando.

Para quem trabalha com pesquisa e desenvolvimento, acompanhar as últimas publicações em sua área é de fundamental importância. No entanto isto pode ser custoso, dado que as assinaturas de revistas científicas têm preços muito altos, dificultando o acesso ao conhecimento científico, e em última instância, desacelerando a evolução da ciência.

O conceito de “código livre” já é bastante antigo entre nós computeiros, e é certamente um dos principais fatores que contribuiu para o acelerado desenvolvimento de nossa área. Se não fossem iniciativas como o Linux, Apache e Mozilla, dentre outros, estaríamos talvez num estágio de desenvolvimento tecnológico similar ao de cinco anos atrás. Com este tipo de visão, diversas iniciativas têm sido criadas na área de divulgação científica, para fazer frente ao domínio das editoras científicas, e permitir a ampla divulgação de conhecimento. BioMed Central e PLoS são exemplos de editoras eletrônicas OpenAccess bastante conhecidas (ao menos na área em que trabalho - bioinformática, biologia e afins). Esta já é uma realidade mundial, que certamente substituirá o modelo anterior.

Seguindo esta tendência, a Faculdade de Artes e Ciências da Universidade Harvard decidiu tornar público todos os artigos publicados por seus pesquisadores a partir de 12 de fevereiro de 2008. De acordo com matéria da Agência FAPESP, também a Escola Médica Harvard pretende utilizar o modelo OpenAccess aos artigos resultantes de pesquisas apoiadas pelos Institutos Nacionais de Saúde. Iniciativas como estas, de centros de pesquisa renomados como os de Harvard, atestam o sucesso deste novo modelo de divulgação científica, e uma preocupação cada vez maior no que diz respeito à disseminação de conhecimento.

Para quem tiver interesse, o DOAJ é um diretório de publicações OpenAccess, compreendendo as mais diversas áreas. Talvez lá você possa encontrar alguma publicação que te interesse, não só para acompanhar as pesquisas recentes em sua área, como também para divulgar sua pesquisa.

Outro dia me deparei com este artigo de James Whitaker - CEO da DubCorp, uma empresa especializada em desenvolver negócios em nichos de mercado de pequeno e médio porte. O artigo me chamou a atenção, por trazer uma mensagem bastante incomum: “Não ser o melhor“.

Em um mundo competitivo como o nosso, onde o sucesso é medido pelo que se ganha e o que se tem, todos querem ser o melhor em alguma coisa, e obter sucesso a partir disto. Não é o caso de J. Whitaker. Se você já leu o artigo que citei, você pode ver que ele nunca foi o melhor em nada na vida, nunca obteve o primeiro lugar em nenhuma competição que participou … mas sempre esteve entre os 10% melhores em quase tudo o que fez. Muitas pessoas devem ter tido experiências semelhantes, e algumas devem ter se frustrado com essa vida de “quase” chegar no topo … no entanto, J. Whitaker conseguiu enxergar isto de forma positiva, e aplicar isto à sua vida profissional.

Conforme o autor, “superar o cara mediano é fácil, superar o cara que é melhor que eu é que é quase impossível”. A partir disto, ele decidiu não gastar energias em ser o melhor em um negócio, e sim ser melhor que a média em vários negócios. Certamente, ter um negócio de US$ 1 milhão por ano não é grande coisa, mas ter 50 negócios de US$ 1 milhão por ano, já é um negócio de US$ 50 milhões por ano. E é esta idéia que guia a DubCorp - “DubCorp será o negócio mais mediano do mundo … mas fará isso melhor que qualquer um”.

Eles já criaram o GreekHoodies.com (um e-commerce que produz camisetas para fraternidades), a SoulGear.net ( um e-commerce que vende roupas para eventos esportivos), e outros negócios na mesma linha.

Este modelo de negócios tem uma certa afinidade com o da 37 Signals (Basecamp, Backpack, Campfire) - eles são uma pequena empresa, e gostam de ser assim. Eles acreditam que são melhores assim, pois permite que sejam mais ágeis. E eles têm sido extremamente bem sucedidos desta forma.

Assim, se você todo dia pensa em como criar o maior e melhor negócio do mundo, talvez seja o momento de refletir. Ser o maior e o melhor é difícil … ser bom e pequeno é mais fácil, e talvez seja o suficiente.

Powered by ScribeFire.

Em 2001 o MIT anunciou a criação do OCW (MIT OpenCourseWAre). Esta é uma iniciativa que procura utilizar a internet para avançar o conhecimento e educar estudantes das mais diferentes áreas em todo o mundo - seguindo a missão da instituição. Através de seu site, o OCW publica gratuitamente materiais dos cursos utilizados no MIT, incluindo notas de aulas, conjuntos de problemas, vídeos e demonstrações.

O primeiro piloto, com 50 cursos surgiu em 2002. Em 2003 o projeto foi oficialmente lançado, contando com cerca de 500 cursos. De acordo com as informações do site, em 2007 praticamente todos os cursos do MIT foram publicados. É uma excelente fonte para aqueles que têm interesse de aprender algo novo, aprofundar seus conhecimentos e manter-se atualizado. Vale lembrar que de acordo com o ranking de universidades citado pelo Raphael, a instituição é considerada como sendo a décima melhor universidade do mundo.

Esta iniciativa inspirou diversas outras universidades do mundo, que então criaram o OpenCourseWare Consortium, que agrega desde renomadas instituições dos Estados Unidos, Europa e Japão, até instituições de países como Vietnã e Colômbia (não há nenhuma universidade brasileira no consórcio).

Cabe notar que a disponibilização do material não garante certificação de nenhuma espécie,  e tampouco corresponde fielmente a todo o material dos cursos. De qualquer forma, é uma excelente fonte por aqueles ávidos por conhecimento. Eu mesmo já comecei a consultar o material de três cursos bastante interessantes: Introdução à probabilidade e estatística, Algoritmos para Biologia Computacional e Análise Econômica para Decisões de Negócios. Mas se você preferir, pode fazer um curso sobre Imperialismo Europeu nos séculos XIX e XX, Alemão (língua) ou Biomedicina Aeroespacial e Engenharia de Suporte à Vida. São várias as possibilidades.

Mais uma da série “MyFaces e …”. Há algum tempo atrás, escrevi sobre a integração entre MyFaces e Tiles, para resolver o problema de gerenciamento de layouts. Agora, irei falar sobre como resolver a limitação do JSF no que diz respeito ao controle de escopo de managed beans.

Aqueles que desenvolvem aplicações web com JSF sabem que este framework possui três níveis de escopo: request, session e application. Para os desavisados isto parece bom, mas não irá demorar muito para você perceber que existe uma lacuna grande aqui - você com certeza irá precisar de um escopo que seja maior que request, e menor que session.

Um caso bem simples é o de utilizar commandLinks ou commandButtons dentro de um dataTable utilizando escopo request - ao clicar no link ou botão, simplesmente nada acontece, porque isto inicia uma nova requisição, mas os dados da dataTable que está sendo referenciada pelo link ou botão acionado não existe mais, pois estava disponível somente na requisição anterior. Solução número 1: colocar o dataTable no escopo session. A partir daí, tudo funciona … mas os dados ficam inutilmente ocupando espaço de memória até que a sessão se encerre. Para este problema específico, o MyFaces extendeu esta componente, criando o atributo preserveDataModel, que indica se o estado dos dados devem ser descartados antes dos dados serem novamente exibidos. No entanto, há outros casos que seria útil ter um escopo intermediário: casos de uso onde os dados são preenchidos em mais de uma requisição (agendamento de hotel, por exemplo); executar o mesmo caso de uso em duas janelas (tabs) na mesma sessão de usuário …

Alguns frameworks oferecem soluções para este problema: JBoss Seam, Shale Dialog Manager, Spring Web Flow. O primeiro parece muito bom, e aparentemente resolve bem este, e outros problemas. Os outros dois atacam especificamente o problema do controle de escopo, através do controle dos fluxos de requisições dos casos de uso. Por eu estar preocupado somente com o problema de escopo, descartei o JBoss Seam - seria um tiro de canhão pra matar uma mosca - e foquei nos outros dois.

Comecei com o Shale Dialog Manager, que conforme consta, foi fortemente inspirado no Spring Web Flow (SWF). Infelizmente, ele apresentou algumas limitações que me fizeram desistir dele:

1. Você não pode iniciar um outro fluxo estando no meio de outro (exceto que você o defina como parte do fluxo) - parte dos casos de uso de minhas aplicações são acessíveis por meio de menus - se para cada fuxo de operação (caso de uso) eu tivesse que inserir os fluxos acessíveis pelo menu, eu só faria isso na vida
2. Não é possível executar o mesmo fluxo em duas janelas (tabs) diferentes na mesma sessão

Dado isto, passei a testar o SWF, e a vida se tornou maravilhosa. Em primeiro lugar: a documentação é excelente - poucas vezes na vida encontrei um software open source tão bem documentado (recomendo a leitura do artigo do Leonardo que fala a respeito deste assunto); a integração com JSF é muito simples (aliás, o SWF é independente de tecnologia de apresentação - funciona com JSF, Struts, Tapestry, etc); não possui as limitações do Shale Dialog Manager; possui suporte a testes de unidade e testes de sistema dos fluxos de execução.

A integração do SWF com o MyFaces é bastante simples, e bastante bem documentada. Para definir cada fluxo, você deve criar um arquivo xml para cada um deles (este é o único ponto que não me deixou muito satisfeito, mas …). Os fluxos podem ser definidos por:

• ViewState: utilizado para definir uma interface a ser exibida, através da qual o usuário fornecerá dados ao sistema
• ActionState: utilizado para executar ações de negócio, e definir o próximo estado do fluxo baseado no resultado da execução
• DecisionState: realiza uma decisão sobre próximo estado do fluxo, através do teste de expressões booleanas
• SubflowState: inicia um novo fluxo como subfluxo do fluxo atual, permitindo a passagem de parâmetros
• EndState: indica o estado final de um fluxo, determinando o fim de sua execução

Com apenas estes estados, é possível definir os mais complexos fluxos de operação de uma aplicação web. No meu modo de ver, este framework é excepcional. Recomendo fortemente. E se você ainda não conhecia nada com relação ao Spring Framework, sugiro que você dê uma olhadinha em tudo o que ele pode fazer, e seus subprojetos. Para o desenvolvedor Java, pode ser extremamente útil, podendo complementar, ou mesmo substituir diversas tecnologias J2EE.

Powered by ScribeFire.

Há mais de um ano, meu caro amigo Miguel escreveu aqui uma dica sobre o FireBug, certamente o plugin do Firefox mais útil para mim quando estou desenvolvendo aplicações para web. Se você é um desenvolvedor, e não usa este plugin, sinto muito.

Agora, através de um artigo de Dan Hardiker, publicado por Jonathan Nolen no Atlassian Developer Blog, conheci o YSlow. Este é um plugin para Firefox, desenvolvido pelo pessoal da Yahoo, que se integra ao FireBug e análisa uma página web baseado num conjunto de regras para aumentar performance de páginas web (também desenvolvido pela Yahoo), dá uma nota à sua página, indicando os pontos que poderiam ser melhorados.

Mais importante do que o plugin, no entanto, são as regras. Conhecê-las e aplicá-las - sempre que for possível - pode fazer uma grande diferença na experiência do usuário ao acessar as páginas por você desenvolvidas. Como teste, utilizei a ferramenta no Gmail,que recebeu uma nota A com louvor, e na página de nosso humilde blog, que foi reprovado com um vergonhoso F (a pior nota possível). Agora é tentarmos, na medida do possível, trabalharmos sobre os pontos que é possível melhorarmos.

Bom, fica aqui a dica.

Powered by ScribeFire.

Como trabalho em uma cidade diferente da que resido, pego uma van, com outros funcionários da empresa (além de alguns de empresas próximas), para chegarmos ao local de trabalho. Normalmente, viajo dormindo e babando, mas hoje, diferente dos outros dias, tivemos discussões interessantes a respeito de nosso ambiente de trabalho. Um dos problemas discutidos diz respeito à perda de pessoas para outras empresas do setor, e o impacto que isto tem sobre nossas atividades. Por sermos uma empresa focada em pesquisa e desenvolvimento, as baixas de funcionários normalmente resultam em perda de conhecimento, prejudicando imensamente o andamento de nossas atividades.

Dentro deste contexto, um de meus colegas citou a seguinte frase: “O maior ativo de nossa empresa são as pessoas“.

Está é uma frase de grande impacto, muitas vezes proferidas pelo RH das empresas, para mostrar a seus funcionários o quanto elas são importantes dentro da estrutura. Mas, refletindo um pouco, chego à conclusão de que esta frase está completamente errada. O maior ativo de uma empresa não são - e nem pode ser - as pessoas, mas sim o conhecimento que elas geram. O que leva as empresas a exaltarem o valor de seus funcionários é uma política que permite a personalização do conhecimento, em detrimento de seu compartilhamento. Desta forma, quando um funcionário deixa a corporação, leva consigo algo de extremo valor, que nenhum outro colaborador é capaz de reproduzir imediatamente, causando prejuízos diversos - atrasos em projetos, necessidade de reestruturação, entre outros.

Para contornar isto, as empresas são obrigadas a remunerar melhor as pessoas, de acordo com a quantidade de conhecimento que esta pessoa adquiriu e que ninguém mais conhece, para evitar prejuízos em suas operações. De certa forma, a empresa acaba ficando escrava do funcionário (apesar de num primeiro instante, isto soar ridículo). No entanto, isto pode ser evitado, desde que ataquemos o problema real, ou seja, evitar que o conhecimento se acumule sobre uma ou poucas pessoas. É claro que nem sempre isto é possível, mas vou tentar colocar aqui algumas alternativas para pelo menos minimizar este problema.

1. Diminua a verticalização: muitas empresas se estruturam de forma a manter diversos níveis hierárquicos. Quanto maior a quantidade de níveis, mais difícil é divulgar o conhecimento, pois este tende a fluir melhor entre pessoas de um mesmo nível hierárquico. O problema maior se encontra na transmissão do conhecimento de cima para baixo - é muito comum que os chefes omitam informações de seus subordinados, muitas vezes por não acharem útil a eles, e em alguns casos, para manter seu status quo
2. Evite a formação de especialistas: mesmo em uma equipe formada por pessoas no mesmo nível hierárquico, é comum que cada uma delas tenha responsabilidades específicas (na área de desenvolvimento de softwares, existir uma equipe com DBA, analista, programador, testador), ou trabalhem em projetos específicos. O ideal é criar uma estrutura onde todos sejam capazes de realizar qualquer tipo de tarefa (mesmo que tenha maior responsabilidade sobre um tipo específico), e no caso de equipes muito pequenas trabalhando em cada projeto, que estas se alternem periodicamente entre os diferentes projetos, de preferência escalonando os membros da equipe
3. Crie estruturas para armazenar e divulgar o conhecimento: a utilização de sistemas informáticos para documentar e divulgar o que os colaboradores estão fazendo, processos da empresa, guias de operações, entre outros é fundamental para espalhar o conhecimento dentro da organização. Várias ferramentas (inclusive open-source) podem ser utilizadas para este fim, como wiki’s e blogs. Além disto, a divulgação dos trabalhos através de seminários e palestras periódicos, que estimulem também a discussão, é útil não somente para espalhar o conhecimento, mas também para desenvolvê-lo, ao permitir que pessoas de diferentes áreas, com diferentes olhares possam analisar os problemas sobre outra perspectiva.
4. Crie um ambiente social propício: isto talvez seja o mais difícil, mas é de fundamental importância. A criação de um ambiente colaborativo, que faça com que as pessoas queiram compartilhar conhecimento, depende do perfil dos colaboradores, e do clima da empresa. Animosidades e inimizades entre funcionários, assim como um ambiente profissional que valorize a competição e o individualismo, minarão qualquer tentativa de despersonalizar o conhecimento. Desta forma, preste atenção ao contratar, não somente nos aspectos técnicos, mas também nos aspectos de sociabilidade de seu candidato - para tanto, é sempre bom consultar a equipe que irá trabalhar com o candidato, caso este seja aprovado (já falei a respeito anteriormente). Além disso, valorize e premie os “compartilhadores”.

É claro que a implementação destas idéias não eliminam totalmente a dependência das empresas com relação a determinados funcionários. Haverá sempre aqueles funcionários extraordinários, extremamente eficientes e competentes, cuja saída representaria uma grande perda à empresa. No entanto, a criação de um ambiente colaborativo, onde o conhecimento é realmente da empresa, e não do funcionário, pode inclusive estimular a formação de colaboradores mais eficientes e competentes, uma vez que este não mais será insubstituível pela simples retenção de conhecimento.

Powered by ScribeFire.

Um antigo dito diz: “Dê um peixe a alguém, e ele terá comida para um dia; ensine-o a pescar e ele terá comida para toda a vida”. Bom, isto é meia verdade, afinal de contas, de nada adianta saber pescar se você não tiver condições de comprar vara, anzol, linha …

Seguindo esta linha de raciocínio, um grupo de pessoas criou o Kiva - um site cujo objetivo é colocar pessoas interessadas em ajudar os menos favorecidos, em contato com proprietários de pequenos negócios de países em desenvolvimento, permitindo que os que assim desejarem, realizem pequenos empréstimos de pelo menos US$ 25,00, com duração de 6 a 12 meses a estes micro-empresários. Durante o período do empréstimo, o credor pode receber notícias sobre o andamento do negócio que recebeu o empréstimo. Uma vez pago o empréstimo, você pode recuperar o dinheiro, ou emprestá-lo para um outro empresário, mantendo assim o ciclo virtuoso.

Para dar confiabilidade a este sistema, o Kiva mantém parcerias com instituições de microcrédito, responsáveis por selecionar os negócios que se qualificam para receber os empréstimos. Estas instituições cadastram os negócios, e você pode então escolher para quem você vai emprestar seu dinheiro. Este sistema mantém o registro destas instituições de micro-crédito, permitindo consultar o grau de confiabilidade da instituição, o montante que ela conseguiu obter em empréstimos para as empresas que cadastrou, e a porcentagem de “calotes” dado pelas empresas cadastradas.

Há outras formas de ajudar, afinal de contas, manter uma estrutura dessas, de alcance mundial não é fácil. Dessa forma, aqueles que desejarem podem se voluntariar para ajudar a manter e desenvolver o Kiva, ou mesmo trabalhar lá. Existe ainda a possibilidade de se tornar um Kiva Fellow, e ter então a oportunidade de viajar e trabalhar diretamente com uma instituição de microcrédito, e ver com seus próprios olhos o impacto dos empréstimos.

Atualmente, só há empresários da África e da Ásia cadastrados para receber empréstimos. Esta situação deve mudar, uma vez que há várias instituições dos outros continentes que se associaram recentemente ao Kiva. É bom ressaltar, que esta idéia é apoiada por empresas como Google, Microsoft, Yahoo, Starbucks, além de instituições como Clinton Global Initiative e WK Kellog Foundation

Está é uma idéia muito boa, e mostra como a tecnologia que desenvolvemos pode ser empregada para mudar a vida dos menos favorecidos. Não fosse o poder agregador da Internet, nada disso seria possível, ao menos não nesta escala. Conheça este projeto, e se possível, ajude a fazer a vida de outros melhor.

Powered by ScribeFire.

Kata - Um conjunto estilizado de movimentos que simulam uma variedade de defesas e ataques contra um inimigo invisível. Um kata é utilizado para aperfeiçoar o estilo, aprender concentração, assim como demonstrar ataques, defesa e contra-ataques. ( Extraído de http://la.essortment.com/karateterminolo_raan.htm - tradução livre )

Dojo - literalmente “lugar do Caminho”. Também “lugar da iluminação”. ( Extraído de http://www.aikido.itu.edu.tr/dictionary.htm - tradução livre )

Com certeza, todos o leitores com mais de 20 anos lembram-se do Daniel Larusso (vulgo Daniel Sam), aquele rapaz com cara de bebê chorão e chassi de pernilongo, destruindo seus adversários no “All Valley Karate Tournament”. E tudo isso graças aos gloriosos ensinamentos do Sr Miyagi, que iam de pintura de paredes e enceramento de carros, a dancinhas esquisitas à beira da praia, vulgo Kata. Provavelmente, baseado nesse incrível exemplo, algumas pessoas como Dave Thomas resolveram aplicar esta prática ao mundo dos programadores. De acordo com Dave, assim como em outras áreas, para desenvolvermos nossas habilidades precisamos de muito treino. Baseado nisto, ele desenvolveu uma série de katas para programadores - pequenos exercícios para treinar nossas habilidades de programação, lógica, estrutura de dados, etc.

Baseado neste mesmo conceito, um grupo de pessoas criou um Dojo virtual, para que as pessoas se reunam para a prática de katas. Este Dojo ainda está engatinhando, e atualmente contém somente cinco (em 04/09/2007) katas cadastrados. Mas certamente irá crescer.

Pessoalmente, gostei muito desta idéia. Muitos programadores têm o interesse e a vontade de aperfeiçoar suas habilidades, mas não sabem como fazê-lo. Desenvolver pequenos projetos sozinho, ou em grupos (comunidade open-source) é uma boa alternativa, mas nem todos têm tempo para se comprometer suficientemente para tais atividades. Além disto, nem sempre se consegue exercitar as diferentes habilidades úteis a um programador faixa-preta quinto dan.

Como gostei muito desta idéia, tentarei à medida do possível colocar uns katas aqui. E aqueles que quiserem, podem entrar em contato pelo alexandre(at)log4dev.com, que teremos prazer em divulgar suas sugestões, e dar-lhes sempre todo o crédito.

Nota: falando em dar o devido crédito, a idéia deste post surgiu a partir de um artigo de Amr Elssamadisy do InfoQ

Powered by ScribeFire.

Estou iniciando o desenvolvimento de uma aplicação utilizando MyFaces. Esta escolha se deu porque gosto do esquema do Java Server Faces (JSF), e após ter trabalhado com a implementação JSF da Sun, resolvi dar uma chance ao MyFaces, pois parece ter algumas soluções interessantes para alguns problemas que enfrentei com o anterior. Em conjunto, estou utilizando diversas componentes providas pelo Tomahawk, que extendem as funcionalidades das componentes básicas do JSF, além de oferecer diversas outras componentes.

JSF é muito bom, mas não resolve todos os problemas. Um destes problemas é a questão de gerenciamento de layouts - em JSF, se você quiser que todas as páginas de sua aplicação obedeçam a um mesmo layout, você tem que replicá-lo em todas as suas páginas; imagine se depois você quiser mudar esse layout, o problema que não vai ser alterar todas as páginas. Para resolver este problema, integramos ao JSF o Tiles. Este é um framework inicialmente desenvolvido dentro do Struts, mas que agora foi separado deste, que simplifica o desenvolvimento de interfaces de aplicações web. Ele se baseia no padrão Composite View, permitindo que se definam fragmentos de página (menu, header, footer, etc …), que podem ser agrupados em um layout, que pode ser aplicado às suas páginas. O conceito é bastante interessante, e para quem quiser mais detalhes, sugiro que leia o tutorial do Tiles.

Vou aqui explicar como estou realizando esta integração. A primeira coisa que fiz foi definir a estrutura do meu layout, que é composto por:

• Header
• Menu
• Conteúdo

Basicamente, o header e o menu são sempre o mesmo. A única coisa que varia é o conteúdo a ser exibido. Com isto, defini uma página ( layout.jsp ) onde defini o posicionamento destas componentes de layout, e a utilizei em uma definition no arquivo de configuração do Tiles:

      <definition name="layout" template="/layout.jsp" >
             <put-attribute name="header" value="/header.jsp" />
             <put-attribute name="menu" value="/menu.jsp" />
             <put-attribute name="content" value="/blank.jsp" />
      </definition>

Note que para cada componente do layout há uma página associada. Estes valores podem ser alterados em tempo de execução, e irei utilizar esta funcionalidade para exibir diferentes conteúdos da minha aplicação (alterando a página a ser exibida pela componente content. Abaixo, mostro o código de layout.jsp, onde posiciono um elemento embaixo do outro:

      <tiles:importAttribute scope="request" />
      <f:subview id="header">
           <tiles:insertAttribute name="header" flush="false"/>
      </f:subview>
      <f:subview id="menu">
           <tiles:insertAttribute name="menu" flush="false"/>
      </f:subview>
      <f:subview id="content">
           <tiles:insertAttribute name="content" flush="false"/>
      </f:subview>

Um problema desta forma de integração que adotei é que, para cada página (conteúdo) que desejo exibir, preciso criar dois arquivos jsp: um para definir o conteúdo, e outro para inserir este conteúdo dentro do layout. Abaixo, um exemplo da página que insere o conteúdo dentro do layout. Note-se que isto é feito utilizando a definition que criamos anteriomente, e sobrescrevendo-se a propriedade content:

      <f:view>
          <tiles:insertDefinition name="layout" flush="false" >
             <tiles:putAttribute name="content" value="/pageContent.jsp" />
          </tiles:insertDefinition>
      </f:view>

Certamente esta não é a melhor solução, mas foi a primeira que veio à minha cabeça. No futuro, pretendo gastar um pouco de neurônios pensando em uma forma de gerar apenas um arquivo jsp por página a ser exibida.

Para configurar o Tiles para ser utilizado pelo JSF, basta você acrescentar o seguinte código em seu arquivo web.xml (além dos jar’s do Tiles):

    <servlet>
       <servlet-name>tiles</servlet-name>
       <servlet-class>org.apache.tiles.servlet.TilesServlet</servlet-class>
       <init-param>
          <param-name>org.apache.tiles.DEFINITIONS_CONFIG</param-name>
          <param-value>/WEB-INF/tiles-defs.xml</param-value>
       </init-param>
       <load-on-startup>2</load-on-startup>
    </servlet>

Nesta solução, o que eu gostaria de alcançar era:

• facilidade de gerenciamento de layout
• manter o controle de navegação do JSF
• facilidade de integração

Tirando o overhead de gerar um arquivo a mais por página gerada, acho que a solução é boa. E tem funcionado bem para os meus propósitos. Se você tiver alguma sugestão, dica, crítica, não esqueça de deixar seu comentário. Se preferir, podes entrar em contato pelo alexandre(at)log4dev.com.

Powered by ScribeFire.

Christopher Owen, desenvolvedor da Atlassian, postou no Atlassian Developer Blog uma dica muito interessante sobre dados em URL’s, que acredito poucos desenvolvedores tenham conhecimento. Conforme definido pela especificação RFC 2397 The “data” URL scheme, é possível incluir dpequenos itens de dados como dados “imediatos”, como se tivessem sido incluídos externamente.

Para tanto, a URL deve ser da forma:

data:[<mediatype>][;base64],<data>

onde <mediatype> é a especificação da mídia, [;base64] indica que o dado está codificado em base 64, e <data> é o dado que se deseja incluir.

No artigo de Christopher, ele criou um exemplo para exibir uma imagem no formato gif utilizando esta funcionalidade. É importante notar que tal funcionalidade não é implementada por todos os browsers.

Powered by ScribeFire.

Muitos usuários de Windows e Mac já conhecem o Google Desktop - uma ferramenta que permite fazer buscas nos arquivos armazenados no seu computador (arquivos pdf, histórico da web, mails, etc …). Além disto, nas suas últimas versões há a funcionalidade de uma barra lateral, onde você pode instalar diversos gadgets (pequenas aplicações que variam desde leitores de notícias, até visualizador de fotos de seu Picasa, relógio, task lists … - muito similar aos gadgets que você pode instalar em seu iGoogle).

Depois de muito tempo, finalmente a Google lança a versão desta ferramenta para Linux:

Google Desktop now available for Linux

No entanto, esta versão contém apenas as funcionalidades de busca - não há ainda a barra lateral. Além disto, os instaladores disponíveis são para versões de 32 bit. De qualquer forma, funciona bem, e é melhor que utilizar o find para buscar arquivos, além de permitir busca por palavras dentro dos documentos. Vale a pena conferir.

Powered by ScribeFire.