Arquivo → February, 2009
Groovy como linguagem de script – como instalar e minha experiência
Groovy tem sido minha linguagem de script favorita por pelo menos um ano, conseguindo algo que até então era impensável pra mim: substituir o Perl, que até então quebrava todos os meus galhos e troncos (muitos troncos). Claro: meu caso não é uma regra, porém acredito que seja muito próximo da realidade de diversos programadores que trabalhem com Java.
Tudo começou da forma mais gambiarristica possível. Um belo dia um cliente me pediu para implementar um relatório que só seria utilizado uma única vez. Dado que conheço bem o que este “só vai ser usado uma única vez” significa, normalmente minha primeira opção consiste em implementar este relatório em uma aplicação independente, só para garantir que no futuro, caso seja necessário, o próprio usuário a execute de acordo com suas necessidades.
Porém, desta vez foi diferente. O relógio marcava 16 horas e eu tinha um compromisso às 17. A esmagadora maioria do código que eu precisaria já se encontrava implementado em Java. Somando 2 + 2, qual linguagem escolher? Groovy, é óbvio. Em meia hora o trabalho estava pronto, o cliente tinha em mãos sua bendita planilha gigantesca no formato Microsoft Excel e eu ainda cheguei pontualmente ao meu compromisso.
Como 90% do meu tempo é gasto com código Java, que não é tão simples assim de se acessar usando Perl, Groovy caiu como uma luva. Bastou configurar o meu ambiente de execução e boom. De repente, executo 90% das minhas tarefas corriqueiras com meus scripts escritos em Groovy. E o mais interessante foi: configurar o ambiente é MUITO simples, tal como irei expor abaixo.
Configurando o seu ambiente Groovy
O primeiro passo, claro: consiste em possuir instalado no seu computador o JDK 1.4 ou posterior (1.5 ou posterior seria o ideal). Com o JDK já instalado, baixe a última versão binária do Groovy no seu site oficial: http://groovy.codehaus.org
Em seguida, descompacte o arquivo zipado no diretório de sua escolha e, basicamente, siga os passos abaixo:
- Crie uma nova variável de ambiente chamada GROOVY_HOME, cujo valor deverá consistir no diretório no qual o Groovy foi desinstalado.
- Inclua no path do seu sistema o diretório GROOVY_HOME/bin
Para testar se as coisas realmente estão funcionando, no seu ambiente de linha de comando, execute o comando “groovy”. Se tudo estiver de acodo, será impresso algo similar a
error: neither -e or filename provided usage: groovy [options] [args] options: -p process files line by line and print result (see also -n) -D,--define <name=value> define a system property -a,--autosplit <splitPattern> split lines using splitPattern (default '\s') using implicit 'split' variable -c,--encoding <charset> specify the encoding of the files -d,--debug debug mode will print out full stack traces -e <script> specify a command line script -h,--help usage information -i <extension> modify files in place; create backup if extension is given (e.g. '.bak') -l <port> listen on a port and process inbound lines -n process files line by line using implicit 'line' variable -v,--version display the Groovy and JVM versions
Porém, ainda não podemos dizer que seu ambiente esteja 100% pronto, uma vez que seu código legado ainda não será visto pelo seu interpretador groovy. O último passo portanto consiste em tornar seu código legado (ou suas bibliotecas) visíveis ao mesmo. Fazer isto é “quase” simples. :)
Dentro do seu diretório GROOVY_HOME, busque um subdiretório chamado conf. Em seu interior há um arquivo chamado groovy-starter.conf, cujo conteúdo será mais ou menos o que exponho abaixo:
# alguns comentários acima
# load required libraries
load !{groovy.home}/lib/*.jar
# load user specific libraries
load !{user.home}/.groovy/lib/*.jar
# tools.jar for ant tasks
load ${tools.jar}
Como pode ser visto, este arquivo é responsável por instruir ao interpretador/compilador Groovy quais diretórios analisar em busca das suas bibliotecas favoritas. No meu caso, bstou incluir uma linha a mais:
load !{user.home}/.groovy/lib/*.jar
Nesta linha, eu aponto para o diretório .groovy/lib que criei dentro do meu diretório de usuário no Mac e pronto. Se preciso usar alguma biblioteca ou código legado, simplesmente incluo os arquivos .jar em seu interior e estou pronto para criar meus scripts!
(para obter mais detalhes a respeito, acesse este endereço)
Groovy Console é seu amigo
Um ponto que consta muito em favor do Groovy como linguagem de script no meu caso consiste no Groovy Console. Para aqueles que já programaram em Ruby, é exatamente a mesma idéia do irb, ou seja, um ambiente de execução composto por dois componentes: um editor e uma caixa de texto de somente leitura a partir da qual seja possível visualizar a saída do meu script.
Para executar o Groovy Console, na linha de comando, simplesmente execute o programa groovyconsole. Surgirá uma janela similar à que exponho na imagem abaixo:
Trata-se de uma interface bem espartana, mas que contém os elementos fundamentais para a criação de novos scripts, como por exemplo as opções de salvar e carregar scripts, além de, o que é fundamental, executá-los e visualizar o resultado de sua execução imediatamente.
Claro: se você for um viciado em IDEs que completem o seu código enquanto você digita, provávelmente odiará profundamente o Groovy Console. Porém, ele possui a grande vantagem de, em momentos nos quais você precisa apenas criar um script, não consumir toda a memória do seu computador para que você possa simplesmente escrever algumas linhas e executá-las em seguida.
Reusabilidade conta (e muito)
Finalmente, não podemos esquecer a questão da reusabilidade. É bacana ter uma ferramenta que lhe permita criar quebra galhos rapidamente, porém é fato que estes quebra galhos acabam virando quebra troncos. A partir de então, é necessário criar uma aplicação mais decente que possa ser usada pelo usuário.
Neste caso, o que fazer? Simples: como no final das contas, código Groovy vira bytecode padrão Java, você pode simplesmente adaptar o seu script para que se torne uma classe e, em seguida, transformá-la em um software mais decente ou, mais interessante ainda, integra-lo a um sistema já existente (claro, que com as devidas precauções).
Concluindo
Não quero dizer aqui que você deva substituir a sua linguagem de script por Groovy. Porém, se em seu cotidiano, é necessário lidar com código Java legado (ou bibliotecas), Groovy se apresenta como uma opção formidável para esta situação.
Existem outras linguagens que você pode experimentar também, como JRuby, Clojure, Scala, etc. Porém, Groovy possui como diferencial o fato de apresentar uma sintaxe extremamente parecida com a que programadores Java já estão acostumados. Consequentemente, a curva de aprendizado é menor (nos momentos de aperto, isto COM CERTEZA faz A diferença) e o aspecto de facilidade que linguagens de script apresnetam será acentuado.
PS: e com relação àquele “incêndio” que citei no início do post? Nunca mais apareceu! (até agora)
Leituras obrigatórias (ao menos pra mim) a todo desenvolvedor
Uma das grandes frustações que tenho diz respeito aos livros que leio, pois conheço pouquíssimas pessoas que também os leram para que possamos trocar algumas idéias a respeito. Sendo assim, dado que este blog está ficando cada dia mais popular (muito obrigado a todos vocês por isto), segue aqui alguns dos livros que, pelo menos na minha opinião, são essenciais para a formação de um bom desenvolvedor.
E, claro: poeremos posteriormente debater a respeito. O que acham?
Sendo assim, aqui vem a lista:
Code Complete: de Steve McConell
Quase uma bíblia para mim. Aliás, é um dos poucos livros que li basicamente todas as edições (li a primeira em inglês e a segunda em português). Se você procura por um guia de boas práticas de desenvolvimento, EIS a fonte.
O livro trata basicamente da etapa de implementação dos sistemas e, o mais interessante é que, apesar de ser publicado pela editora Microsoft, trata de problemas comuns em diversas outras linguagens não-Microsoft, como por exemplo Java, Pascal, Cobol e outras.
E sabem o que é mais engraçado? Após ler o livro, e em seguida confrontar a Win32, fica nítido que a própria Microsoft deveria ter lido com mais atenção ao mesmo. :)
Introduction to Algorithms: Thomas H. Cormen
Um fato que me choca: poucos desenvolvedores possuem um livro básico de algoritmos em sua biblioteca. Curiosamente, quando estou trabalhando em algo realmente cabeludo, um dos primeiros livros que procuro é justamente este.
São os algoritmos básicos que vemos na faculdade: ordenação, grafos, processamento de caracteres, etc. Sendo assim, o que este livro tem de diferente dos demais? Simples: é a referência básica usado por estes.
The Art of Computer Programming: Donald E. Knuth
Publicado em quatro volumes (o quarto só saiu 20 anos após a escrita dos três primeiros), é A BÍBLIA para quem leva desenvolvimento REALMENTE a sério ( ficaria muito feliz se me dessem o box contendo os quatro volumes de presente).
Me lembro que costumava andar com estes volumes debaixo do braço como se fossem a coisa mais valiosa do mundo enquanto estudava na UFMG. O que realmente fascina neste livro consiste no fato de seu primeiro volume ter sido publicado em 1968 e, até hoje, ser extremamente atual.
Se o “Introduction to Algorithms” do Cormen é a fonte de referência de todos os outros, este é a referência básica de Cormen. O que é bacana neste livro consiste na abordagem científica que Knuth dá aos algoritmos. E a maneira como é escrito também é maravilhosa. Um clássico (e só pra lembrar, aceito doações!).
Me lembro que era extremamente caro até bem pouco tempo atrás, mas atualmente já é possível comprar o box completo na Amazon por um preço bem razoável.
A Linguagem de Programação C: Kernighan e Ritchie
O livro que torna muita coisa clara. Li a primeira edição do mesmo em inglês na faculdade e foi realmente um momento de iluminação para mim.
Como vêm diretamente da fonte (são os criadores do C descrevendo-o), acaba por explicar muito mais do que o simples funcionamento da linguagem. O interessante é que este pequeno livro acidentalmente vai além da própria linguagem C. No final das contas, o leitor irá ler a descrição de como funcionam de fato elementos presentes em praticamente todas as linguagens de programação, como por exemplo strings, ponteiros, variáveis, etc.
Mesmo que você jamais venha a escrever uma única linha em C, a leitura deste livro é obrigatória para aqueles que desejem saber como as coisas REALMENTE funcionam por trás dos panos.
Escrevendo Código Seguro: David Leblanc
Outro bom livro da editora Microsoft (aliás, eles tem títulos ótimos): basicamente, se o “Code Complete” é um guia de boas práticas de desenvolvimento, “Escrevendo Código Seguro” pode ser visto como um quase excelente guia de como se, como o próprio nome já diz, se deve escrever “código seguro”.
Entra na lista por ter sido uma experiência incrívelmente reveladora para mim. Isto porquê me expôs a diversos dos erros que até então eu estava cometendo e simplesmente não me dava conta. É incrível como sua auto estima vai para o chão após sua leitura (isto é ótimo!).
Há muito conteúdo relacionado à geração de código em si, porém muito mais interessante é a parte “administrativa” do mesmo, ou seja, quando o autor expõe como desenvolvedores devem se relacionar com seus colegas de trabalho ou clientes quando o assunto é segurança.
E aí você me pergunta: “porque um guia quase excelente”? Simples: o foco é basicamente tecnologias Microsoft e, apenas tecnologias Microsoft, o que é compreensível levando-se em consideração qual a sua editora.
Bem, estes são os livros que, ao menos na minha opinião, deveriam estar na estante de todo desenvolvedor que leve a sério seu trabalho. E as suas sugestões? Quais seriam? E com relação a estas, o que achou?
Com JavaScript, quem precisa do Erwin (ou quase isto)?
Por acaso descobri um projeto MUITO interessante: se chama WWWSQLDesigner. Trata-se de um editor de diagramas de entidade/relacionamento 100% baseado em JavaScript.
Pelo que pude experimentar, funciona 100% no Firefox e chega inclusive a gerar scripts SQL para a geração dos bancos de dados. Também é muito interessante a opção de salvar o conteúdo como um XML, que posteriormente pode ser aberto pelo próprio programa.
A instalação não poderia ser mais simples: baixe o projeto no site oficial, descompacte-o em um diretório de sua preferência e em seguida, simplesmente abra o arquivo index.html no seu navegador. É realmente surpreendente.
Se não quiser ter este trabalho, eu fiz o upload do projeto para o site da itexto. Sendo assim, para experimentá-lo, simplesmente clique aqui.
A TI (em empresas grandes) vive na caverna (shh! ela ainda não sabe disto!!!)
Devo confessar: eu não gosto do modelo relacional. É difícil de escalar, simplório demais e acredito que possui um alto potencial para mutilar mentes de desenvolvedores (mais sobre isto em outro tópico (ou neste mesmo)). Ao buscar alternativas, acabei topando com o CouchDB (aguardem novidades em breve), que utiliza um modelo basicamente oposto (é baseado em documentos, não em tabelas).
Em um primeiro momento, me empolguei muito com o novo brinquedo para que, no seguinte, tomasse um banho de água fria ao comentar o assunto com alguns (varios, na realidade) colegas de TI. Em 98% dos casos, nem tentaram compreender o modelo proposto. Simplesmente o rechaçaram com o argumento de que “se já existe o modelo relacional, que resolve todos os problemas, pra que buscar outra coisa?”.
Foi quando caiu a ficha: a TI está na caverna. Ao menos em empresas grandes, está. E provávelmente não sairá de lá por um bom tempo. Para aqueles que não conhecem, estou me referindo ao mito platônico descrito na República. A idéia é a seguinte: é descrita uma situação na qual escravos são criados desde o seu nascimento acorrentados em uma caverna de tal modo que jamais possam virar-se para trás e a única coisa que vêem consiste em sombras projetadas na parede em sua frente, relativas à luz de uma fogueira localizada atrás dos mesmos. Para estes escravos, portanto, o mundo é composto apenas por estas projeções e nada mais.
Um belo dia, um dos escravos se solta das algemas e, tateando as paredes da caverna, acaba por subir à superfície. Ao se deparar com o mundo exterior, primeiro é ofuscado pela luz do Sol. Em seguida, conforme vai se acostumando à luz, começa a observar objetos que jamais havia sonhado: árvores, grama, animais, casas, para seu espanto outros homens e, finalmente, o céu. Óbviamente, nosso escravo fica maravilhado. E, de tão maravilhado que fica, decide voltar à caverna para contar a seus companheiros a novidade. Ao fazê-lo, primeiro é tido como louco para, em seguida, ser assassinado pelos mesmos.
Hmm… a semelhança já está nítida? Caso não, vamos substituir alguns dos elementos do texto:
Resolve então apresentá-la a seus colegas. Estes, em um primeiro momento, o vêem como um sonhador. Passado algum tempo, começam a se sentir ameaçados com a novidade para que, no final, optem por tornar sua experiência de trabalho tão insuportável ao ponto do mesmo se demitir ou ser demitido.
É incrível como o mito da caverna é atual (claro: é o mito fundador da sociedade ocidental). O que se percebe é, na realidade, o velho conflito de gerações: funcionários (o termo funcionário é muito bem selecionado no caso) mais antigos, que já se encontram bem familiarizados com o ambiente e que se sentem ameaçados pelos novatos e suas novidades. Um possui a vantagem de possuir maior know how, ao passo que o outro possui idéias frescas que poderíam de fato melhorar a qualidade do trabalho produzido até então.
No final das contas, todos perdem. A empresa perde a chance de presenciar uma melhoria na qualidade dos seus processos. O veterano perde a oportunidade de se reciclar. E o coitado do novato, bem: além de perder o emprego e o estímulo para continuar na empresa, perde também a oportunidade de aprender algo com a experiência do veterano.
(claro: no final das contas, o novato vai sair no lucro por ter se livrado de um ambiente de trabalho retrógrado, mas ao menos momentâneamente, este ganho não estará nítido para o mesmo)
Isto, é claro: em empresas grandes que possuam (ou ao menos achem que possuem) algo a perder. Neste sentido, ser menor é muito melhor. Como o que há a se perder (se é que há) é muito menor, o “ambiente cavernoso” não possui lugar (seria muito caro), dando origem aos “Davis” contemporâneos.
Hoje li no Twitter algo que cai muito bem aqui: “optar por trabalhar em empresas grandes consiste em se optar por parar no tempo”. (twitter do usuário lucastex)
Grails: entendendo a estrutura de diretórios
Se você deseja conhecer o Grails, a primeira coisa que deverá conhecer BEM consiste em sua estrutura de diretórios. Esta é criada após a execução do comando
grails create-app [nome da sua aplicação]
dentro do diretório [nome da sua aplicação]. A primeira vista, pode parecer um pouco complexa, porém, como veremos neste post, é incrívelmente simples de ser compreendida e, uma vez assimilada, tornará nítido o conceito de programação baseada em convenções.
(Neste post não irei explicar o que são os arquivos expostos na imagem (serão assunto para um post futuro), sendo assim, foquemo-nos apenas ao que interessa: os diretórios)
Comecemos portanto pelos diretórios presentes na raiz de nossa aplicação:
grails-app: contém o que realmente interesssa, ou seja, a sua aplicação. 99% das classes que você venha a criar para a mesma deverão estar contidas em um dos subdiretórios presentes nesta entrada.
grails-app/conf: armazena arquivos de configuração da sua aplicação, como por exemplo acesso a banco de dados e a configuração do Spring ou Hibernate.
grails-app/controllers: todas as suas classes de controle serão incluídas neste diretório
grails-app/domain: as classes de domínio de sua aplicação (aquelas que serão persistidas no banco de dados e contém sua lógica de negócio)
grails-app/i18n: recursos de internacionalização para a sua aplicação
grails-app/services: armazena os “serviços” de sua aplicação. O que vêm a ser um serviço? Grails incentiva o desenvolvedor a não incluir toda a sua lógica de negócios nas classes de domínio (por favor, não as inclua (nem um pedacinho!) nos controladores). As classes de serviço são gerenciadas pelo Spring, e são responsáveis portanto por encapsular determinados aspectos da lógica de negócios de sua aplicação.
grails-app/taglib: armazena todas as tags customizadas criadas usando o Grails (mais sobre isto em um post futuro, aonde você ficará boquiaberto com a facilidade que Grails nos trás nesta tarefa)
grails-app/utils: neste diretório serão armazenadas classes utilitárias para sua aplicação, como por exemplo codecs de strings e classes utilizadas por alguns plugins oferecidos para o Grails.
grails-app/views: contém todos os arquivos GSP responsáveis por renderizar as páginas utilizadas pela sua aplicação. Cada classe de domínio possui um diretório equivalente dentro deste diretório. Suponha por exemplo que exista uma classe de domínio chamada Livro. Seguindo as convenções do Grails, deverá existir também (caso esta classe venha a necessitar de uma camada de visualização) um diretório chamado grails-app/views/livro.
lib: neste diretório deverão ser incluídos todos os arquivos .jar referentes a bibliotecas terceirizadas que você queira utilizar, como por exemplo drivers JDBC, bibliotecas para geração de PDF e, principalmente, seu código legado, caso seja necessário reaproveitá-lo.
scripts: caso seja necessária a criação de novos scripts para facilitar o desenvolvimento da sua aplicação, os mesmos deverão ser incluídos neste diretório. Todos os scripts usados pelo Grails são desenvolvidos usando GANT (Groovy Ant), que consiste em uma camada de abstração para o Ant feita em Groovy.
src: No diretório src você pode armazenar código fonte a ser reaproveitado por sua apliação. Normalmente, consiste em código fonte legado que não se encaixa fácilmente na estrutura de diretórios proposta pelo Grails. Dentro deste diretório há dois outros: groovy e java, aonde é possível armazenar código fonte das duas linguagens.
test: armazena todos os seus testes unitários, funcionais e de integração
web-app: O conteúdo estático de sua aplicação, como por exemplo arquivos html, imagens, css, etc.
MARAVILHOSO!!! Bloquinhos nunca mais serão os mesmos
ISTO que eu chamo de tecnologia MARAVILHOSA!
A expressão “eu não soube me expressar direito” é válida?
Devo confessar: nestes dias tenho tido experiências tristemente fascinantes com “profissionais” da área de TI e, em TODAS elas, uma mesma frase aparece: “me desculpe, eu não soube me expressar direito”.
Tenho visto isto com “desenvolvedores”, “técnicos de informática”, “consultores”, “diretores”, “gerentes de TI”, etc. Cabe então a seguinte pergunta: é possível não saber se expressar direito?
A pergunta parece tola (afinal de contas, “vemos” pessoas se expressando mal o tempo inteiro), no entanto é MUITO válida por uma simples razão: não há como se expressar incorretamente.
Como???
O que vêm a ser o “expressar”? Consiste na transmissão de uma informação de uma ponta a outra. No caso, de uma pessoa a outra(s). A informação é transmitida através da linguagem e interceptada pela outra ponta. E aonde fica a informação? No cérebro do locutor. Logo, o locutor expressa aquilo no qual está pensando. Não há portanto um problema de expressão, mas sim no que se encontra no cérebro do locutor.
Um fato óbvio precisa ser esclarecido: se você conhece alguma coisa, necessáriamente conhece também o vocabulário que a envolve. Logo, se ocorre um “problema de comunicação”, fica evidente não o “não saber se expressar”, mas sim a sua própria ignorância a respeito do assunto.
Irei dar um exemplo clássico: suponhamos que você trabalhe em uma grande firma como desenvolvedor cujo produto final não seja um produto de TI, mas qualquer outra coisa: uma fábrica de biscoitos por exemplo. Seu trabalho como desenvolvedor consiste em desenvolver/manter os sistemas de contabilidade e controle de estoque da fábrica. Um belo dia, o dono da fábrica em uma conversa informal com você solta a seguinte pérola: “o seu trabalho não produz dinheiro para a empresa, apenas gastos”.
Em seguida, você pode responder ao mesmo: “não. meu trabalho agrega valor ao seu produto, uma vez que garante a qualidade da contabilidade da empresa”. E qual resposta você provávelmente receberá deste seu “chefe” (supondo que ele tenha o mínimo de inteligência)? “Tem razão. Eu me expressei mal”.
Na realidade, ele não se expressou mal. Ele realmente via seu trabalho como uma fonte de custos para a sua empresa. Somente após a sua justificativa é que a imagem foi alterada. Sendo assim, não houve um “mal expressar”, mas sim um “expressar preciso”.
Outro exemplo clássico: ao observar a arquitetura de um sistema, você observa pontos de estranhamento na mesma. Ao questionar o responsável pela mesma, você recebe qual resposta: “é. não sei. Não soube me expressar direito”.
Neste caso, o “não saber se expressar direito” reflete o que? A ignorância do sujeito com relação à realidade que está tentando reproduzir. Nítido.
Sendo assim, por favor: evite o “não soube me expressar direito” e assuma o “não domino este assunto”.
“Técnico em informática” deveria ter licença para trabalhar
Sexta-feira às 20 horas recebo um telefonema:
“Alô… eu gostaria de falar com o Sr. Henrique. Ele está???”
“Sou eu, boa noite. Quem é?”
“Meu nome é fulano, sou técnico em informática e estou aqui na instituição X aonde vim dar manutenção no servidor de um dos seus clientes. Como eu faço para colocar o seu sistema de volta ao ar?”
“Uai: é só iniciar o servidor”
“Ai que tá o problema: eu formatei o HD e agora preciso do CD de instalação do software.”
“Você o que???”
A criatura formatou o servidor do estabelecimento com todos os dados sem NEM sequer fazer backup. TODOS os dados do cliente foram perdidos.
Nestas horas me pergunto: a vida profissional dos estabelecimentos é armazenada digitalmente hoje em dia. Aquelas informações são o resultado do trabalho de ANOS e MUITO dinheiro investido. Se um taxista precisa de licença para dirigir, assim como um médico ou um engenheiro, POR QUE DIABOS técnicos em informática não precisam de licença para operar?
Seria a informação no formato digital um bem menos precioso? Conversando com o sujeito acima, ficou nítido que o coitado não fazia a MENOR idéia do que estava fazendo, pois sempre é aplicada a mesma solução: “o computador deu pau? Simples: basta formatar o HD e instalar o WIndows de novo”.
Na minha opinião, deveria haver um teste similar ao que a OAB aplica aos advogados para aqueles que desejem trabalhar com manutenção de sistemas computadorizados. Um teste que avaliasse tanto a capacidade teórica quanto prática do sujeito. Somente assim poderíamos evitar catástrofes como a que acabo de descrever.
O que me faz pensar: de ONDE vem este tipo de “profissional”? Novamente, a fonte é a mesma: da ignorância. Quem tem um olho em terra de cegos, é rei. Mais uma vez podemos ver o usuário avançado (também conhecido como “entendido em informática”) emergindo na “Ignoranciolândia”. Dado que o uso dos computadores se iniciou domésticamente, os usuários de computador ainda sofrem com os efeitos da inércia evolutiva.
Verdade seja dita, ainda se vê o computador como uma ferramenta de hobistas. A informação em formato digital é tida como um cidadão de segunda classe comparada à impressa. E de quem é a culpa? Ai eu pergunto: quem é o pai do “usuário avançado”?
O consumidor. Somente a partir do momento em que este começar a investigar mais a fundo QUEM está lhe prestando serviços poderemos finalmente nos ver livres do MALDITO “usuário avançado” disfarçado de “profissional”.
É incrível como raríssimas vezes vejo qualquer uma das perguntas abaixo ser feita a um técnico:
- Qual a sua experiência na área?
- Possui alguma especialização?
- Quem são os seus últimos clientes?
Nada disto é questionado: a única pergunta feita é: “que horas você poderia vir aqui arrumar o meu computador?” ao primeiro nome que for encontrado nas páginas amarelas. Logo em seguida o “entendido em informática” causa catástofres e quem paga o pato? Aqueles que também trabalham na área mas são de fato profisisonais, e que agora tiveram seu filme queimado devido à irresponsabilidade de um ignorante.
Fato assustador: programadores analfabetos
Recentemente cheguei a uma triste conclusão: boa parte dos programadores com os quais lido não sabe ler, o que me tranquiliza com relação ao desabafo que farei neste e-mail (afinal de contas, não será lido).
No meu dia a dia, é muito comum responder a uma média de 5 a 10 e-mails relativos a dúvidas de programação (em sua maior parte, Groovy/Grails e Java em geral). Destes e-mails que respondo, em aproximadamente 60% dos casos, envio um artigo relacionado para complementar a minha resposta ou que, simplesmente, já contém a solução para o problema/dúvida.
E é exatamente ai que a coisa fica interessante: quando envio um e-mail contendo um artigo em inglês, há dois comportamentos distintos (claro, há excessões (e significativas)): ou o remetente me envia uma dúvida que já se encontra elucidada no artigo em questão ou simplesmente me envia a dúvida novamente, porém relativa a algum código presente no artigo (a pessoa só leu o código fonte).
Se o artigo não possui código algum, a dúvida inicial normalmente volta em sua forma original, expondo assim que o artigo sequer foi lido. Ao indagar estas pessoas do porquê (de uma maneira sutil, como “uai, você não leu isto no artigo?”, é muito comum receber a resposta: “sim, mas estava em inglês”.
E é neste ponto que o bicho pega. Se você trabalha com desenvolvimento, e não sabe inglês, você é analfabeto. Isto porque infelizmente, 90% do (bom) conteúdo produzido para a nossa área ESTÁ em inglês. Isto quer dizer que não há conteúdo de qualidade em português? Claro que não! Muito pelo contrário, a DevMedia e a Editora Mundo tem feito um trabalho maravilhoso neste aspecto, porém, por mais que se esforcem neste sentido, não mudarão o fato de que a maior parte da produção intelectual AINDA é produzida em inglês.
Quando o artigo é escrito em português, também observo um comportamento muito interessante: se o artigo contém código fonte, a partir dos e-mails que recebo em resposta, fica nítido que o sujeito só leu o código fonte, ignorando completamente o texto que o envolve. E ai recebo respostas maravilhosas: “o código que você me passou naquele artigo não funciona”.
Percebe-se neste caso um triste comportamento: há preguiça de se ler algo que não seja código Java/C/Groovy/Pascal/etc. Um argumento que escuto normalmente é “eu não tenho tempo”. Mas por trás dos panos, o que percebe-se é o famoso comportamento do “siga o exemplo”.
Entra o “usuário avançado”
Acredito que se trate, em nosso caso, de um problema grave de formação cuja raiz se encontre no usuário avançado: aquele sujeito que vai um pouco além do Windows/Office básico, e que inicia sua “carreira” escrevendo algumas macros e arquivos em lote.
Infelizmente, boa parte dos “profissionais” presentes no mercado atualmente não passam de usuários avançados. Pergunte-lhes o que é uma árvore binária e receberá um olhar interrogativo (sério: faça a experiência). Para este tipo de profissional, curso superior se trata de um luxo desnecessário, o que é facilmente compreensível levan
do em consideração que 99% dos trabalhos realizados por estas pessoas consiste em produzir formulários que alimentem bancos de dados e, em seguida, exponham estes dados na tela.
Realmente, para este tipo de trabalho, conhecimento de algoritmos é quase desnecessário. Afinal de contas, temos ai o Access que produz formulários automaticamente, ou mesmo o Visual Basic e Delphi, que possibilitam a criação de aplicações apenas arrastando componentes e relacionando-os com tabelas e campos presentes em um banco de dados.
(nada contra Visual Basic ou Delphi (minto: tenho alguma coisa contra). Sei que vão além da “programação orientada a mouse”, porém é inegável que em 90% das vezes são usados desta maneira)
E, pior ainda: aqueles que se esforçam em crescer na profissão, e trabalham com ambiente visual de desenvolvimento, ao comprarem algum livro nas livrarias, 95% das vezes topam com livros que apenas ensinam a arrastar e soltar componentes. São raríssimos os livros para estes ambientes de desenvolvimento que realmente cheguem a descrever de maneira decente como funciona a linguagem por trás dos mesmos.
É quando a bomba explode: invariavelmente chega um dia em que estes “programadores” cometerão erros graves, capazes de gerar prejuízos reais a seus clientes. Neste momento, toda uma classe é desmoralizada: a dos desenvolvedores.
Sim, porque para o cliente, não há distinção entre um usuário avançado e um desenvolvedor. Se um usuário avançado se apresenta como desenvolvedor, a partir daquele momento todos serão nivelados para o cliente. E, pior que isto: como este “usuário avançado” considera fácil o que está produzindo, acaba por minar o mercado cobrando preços baixíssimos pelo seu produto, tornando “caro” qualquer serviço prestado por um desenvolvedor de verdade.
Sendo assim, criei um pequeno checklist para se identificar este tipo de profissional:
- Conhece algum algoritmo básico de ordenação ou busca?
- E estruturas de dados? Quais além da matriz você conhece?
- Já trabalhou em algum ambiente de desenvolvimento não visual?
- Quais os outros sistemas operacionais além do Windows você já trabalhou?
- Consegue imaginar uma aplicação que não utilize um banco de dados?
- Uma aplicação sem interface gráfica é possível? Como seria? (este tipo de desenvolvedor não consegue sequer SONHAR em uma aplicação sem janelas)
- E o mais cruel de todos: observe que o sujeito simplesmente não consegue trabalhar em NENHUM outro ambiente de desenvolvimento que não seja o visual NO QUAL aprendeu a programar.
Caso o sujeito em questão se encaixe no perfil descrito acima, escute meu conselho: CORRA!
A Dialética do SPAM
Com o desenvolvimento da Internet, novas formas de fazer negócio foram criadas, e a possibilidade de ver seu produto sendo divulgado nacionalmente e internacionalmente a preços extremamente baixos se tornou uma realidade. Suponhamos aqui que você possuí um produto e deseja ardentemente divulgá-lo pela Internet pois acredita que com isto poderá ter lucros absurdos. Uma das alternativas que lhe foram expostas foi a do SPAM, ou seja, enviar sua mensagem por e-mail para uma lista imensa de pessoas que ainda não lhe conhecem e que passarão a conhecer através do seu e-mail.
Terá início então um processo constituído por três estágios basicamente, nos quais talvez você se identifique caso já tenha tentado enviar mensagens não solicitadas para se divulgar.
O primeiro estágio têm início quando você acredita que a melhor alternativa para se divulgar seu negócio é o SPAM. São expostas três vantagens que tornam tal prática simplesmente imbatível: alta velocidade, a possibilidade de divulgar seus produtos para uma quantidade enorme de pessoas e o melhor: a um preço mínimo. As pessoas que lerem sua mensagem gostarão tanto do seu produto que acabarão visitando sua página, e desta multidão que verá seus produtos, pelo menos uma parte os comprará, o que lhe proporcionará um lucro fantástico!
Bom, o próximo passo consiste em conseguir uma lista de endereços. O problema é que você colocou seu site na Internet faz pouquíssimo tempo, e este ainda não está muito conhecido. No entanto, nem tudo está perdido, pois você recebeu em sua caixa postal uma mensagem oferecendo-lhe um CD contendo uma lista gigantesca de endereços de correio eletrônico. Logo, a saída mais óbvia (e também a mais prática) consiste em comprar este CD, que é vendido a preços muito baixos. Observe bem como o SPAM funciona! Você acaba de comprar um produto de alguém que lhe enviou uma mensagem não solicitada que poderá suprir suas necessidades! Se funcionou com o cara que está lhe vendendo este produto, com certeza funcionará para você também!
Passado algum tempo o CD chega à sua casa. Nele estão contidas as gigantescas listas prometidas pelo vendedor, também estão incluídos alguns programas que lhe possibilitarão enviar suas menagens. Agora basta que você redija o seu texto utilizando um destes programas, abra uma lista e pronto, milhares de pessoas virão em busca de seu produto.
Após enviar sua mensagem você verifica sua caixa postal. Há inúmeras mensagens novas! Enquanto observa seu computador baixando as mensagens, imagina que serão seus clientes, todos ávidos por seu produto. Baixadas todas as mensagens, percebe que a imensa maioria delas contém o mesmo assunto: são mensagens que voltaram para você. Outra parte destas mensagens consistem em pessoas pedindo-lhe para que remova seu endereço de sua lista, pois seu produto não lhes interessa. Há mais dois tipos de mensagens que talvez você receba. Parte delas consiste em produtos que lhe estão sendo oferecidos. E uma minoria consiste em mensagens realmente úteis (estou supondo o recebimento de pelo menos UMA mensagem útil).
“Que estranho…” – você pensa. “Acabei de comprar esta lista, e me voltam mensagens”. “Mas a lista está novinha? Como isto é possível?”. Bom, então provavelmente a culpa é do programa que você utilizou para enviar suas mensagens. Novamente você tenta enviar sua mensagem (com um outro programa, também incluído no CD, ou então que você baixou da Internet), e a mesma situação se repete.
Até então, o que importa é que as pessoas recebam suas mensagens. Se não voltaram todas as mensagens que você enviou, então é sinal de que algumas chegaram a seus destinatários que você até então realmente acredita que leram e se empolgaram bastante com o seu produto. E se eles leram sua mensagem, e gostaram do seu produto, é bem possível que tenham visitado o seu site (suponha aqui que do resto das mensagens que não voltaram, não foram todas as pessoas que lhe pediram para remover seu endereço da lista). Sendo assim, você ansiosamente visita a página do seu contador, e têm uma surpresa incrível!
O número de acessos continua baixo. Se subiu, não subiu tanto quanto você imaginava que fosse subir. Mas sejamos otimistas. O número de acessos ao seu site subiu um pouco. Se você recebia 20 visitas por dia, passou a receber 21. No entanto, com o passar do tempo desde que você enviou sua mensagem (lembre-se, você a enviou duas vezes, pois acreditava que a culpa era do programa, e não da lista), o número de acessos do seu site voltou a ser de 20 acessos por dia.
Bem, se você mandou a mensagem daquela vez, e a audiência do seu site aumentou, e logo depois diminuiu, é sinal de que você deve enviar sempre as suas mensagens, pois assim as pessoas continuarão a visitar sua página e comprar seu produto, pois se ninguém o comprou até agora, talvez de tanto você insistir acabe comprando não é mesmo?
Bom, após algumas mensagens enviadas, você percebe que o número de e-mails que você recebe pedindo para serem removidos de sua lista começa a crescer. Se começa a crescer, é sinal de quê cada vez mais e mais pessoas não querem mais receber notícias a seu respeito. Agora você entrou em um novo estágio nesta dialética do SPAM.
Neste novo estágio, você percebe que o SPAM não lhe ajudou em nada. Apenas o seu lado era visto, e não o do destinatário. Você supunha que este iria se interessar pelo seu produto (se não o apresentasse, como o iriam conhecer não é mesmo?), no entanto percebeu que a maior parte daquelas pessoas para as quais sua mensagem fora enviada ou não existem ou então pediram para serem removidas, ou seja, as que realmente existiam estavam sendo incomodadas por você.
Então você começa a se indagar o porquê disto. E, visto que agora está consciente de quê sua prática estava causando transtornos para aqueles a quem você devia estar ajudando com seu produto (estou supondo aqui que você não se interessa só pelo dinheiro que irá ganhar com seu produto, mas também com o fato de que este ajudará em muito as pessoas que o utilizarem), ou seja, ao invés das pessoas passarem a gostar daquilo que você estava vendendo, passaram a ter uma certa antipatia(estou sendo otimista) por este e pela sua marca (ou seja, por você).
Neste novo estágio em que você entrou, de repente percebe que se vê apagando diariamente da sua caixa de correio uma série de mensagens prometendo produtos simplesmente fantásticos, e de repente se liga que outras pessoas deveriam estar fazendo o mesmo com as suas mensagens. Conversando com seus amigos, nota que a grande maioria se queixa destas incômodas mensagens, que acabam por ocupar todo o espaço em seu provedor e lhes dão um bom trabalho na hora de apagá-las.
Um dia, por curiosidade, pega aquele CD que não serviu para nada e o coloca no computador. Você deseja ver o conteúdo das listas. E percebe algo muito interessante. As listas contém inúmeros e-mails, não há dúvidas de quê pelo menos uma pessoa recebera aquelas mensagens que você enviava, mas no entanto, não há como ter a menor certeza a respeito de quem foi esta pessoa, se você quiser chegar a esta pessoa novamente, terá de enviar toda a sua lista novamente, e causará todo aquele transtorno a todas aquelas pessoas que lhe pediram para remover seus endereços de sua lista.
De repente a expressão “mensagem não solicitada” (SPAM) passa a fazer sentido para você, que passa a simplesmente repudiar qualquer tipo de prática de SPAM. Agora envia mensagens de correio eletrônico só para seus amigos ou para aquelas pessoas que visitaram sua página e entraram em contato com você por estarem interessadas em seus produtos.
Você se informa melhor, e descobre inclusive que uma das maiores ameaças para o futuro da Internet é a tal prática, que congestiona os servidores, faz com que alguns provedores de acesso sejam bloqueados por outros que deles recebem SPAM, descobre também que há pesquisas feitas pelo mundo inteiro que comprovam o fato da maior parte da população ser avessa a tal prática, etc. Resumindo: percebe que estava totalmente equivocado.
Mas o número de acessos do seu site continua baixo. É preciso que haja uma outra alternativa para divulgar seus produtos pela Internet. Uma alternativa que seja viável financeiramente, visto que o dinheiro anda em falta. E chega também à óbvia conclusão de que nada surge do nada. Talvez haja algo que possa ser aproveitado desta sua experiência mal sucedida.
É neste ponto que nossa dialética encontra sua síntese. Você teve uma idéia que deverá finalmente aumentar a audiência do seu site. Claro, não existem resultados mágicos que farão seu site deslanchar, mas você encontrou uma solução, solução esta que sempre esteve na sua frente, rindo de você por estar sendo ignorada de uma maneira tão ridícula (já reparou que as melhores soluções costumam ser as mais simples?). Esta consiste simplesmente em pedir às pessoas que se interessarem pelo seu conteúdo que estas lhe forneçam seus dados, para que assim torne-se possível mantê-las atualizadas.
Assim, você poderá saber exatamente com quem está falando, e poderá inclusive, dentro desta sua lista de endereços, selecionar somente aquelas pessoas para as quais sua mensagem realmente interessa. Estas realmente lerão sua mensagem, e mais: provavelmente, caso troquem de e-mail, lhe enviarão uma mensagem pedindo para que você continue enviando suas mensagens, só que para o novo endereço, coisa que era simplesmente inimaginável com a prática do SPAM. Aquelas pessoas passaram realmente a se interessar pelo seu produto, e o indicam para outras pessoas, e com o tempo, seu produto passa a ficar mais conhecido, e o que é melhor, as vendas aumentam! Claro, o sucesso poderia ser bem maior se você não tivesse adotado o SPAM, pois o número de pessoas com antipatia de seu produto seria menor.
Caro leitor, caso esteja interessado em praticar o SPAM, o caminho a ser seguido será muito similar a este. É muito improvável que algo mágico ocorra e um caminho totalmente diferente seja trilhado. É possível pular o primeiro estágio desta dialética. A terceira parte do processo é sem sombra de dúvidas a mais eficiente. Agora que se encontra informado, fazer a escolha certa é apenas uma questão de inteligência.
