Category Archives: Software livre

Por que resolvi largar o Flash e partir pro HTML 5 :)

HTML5_logo_and_wordmark.svgNada como algumas rotações da Terra pra mudar as coisas né? No dia 3/1/2010 publiquei aqui um texto chamado “Por que resolvi largar o HTML e partir pro Flash” que é um dos posts mais acessados deste blog desde então. Mas quando olho pro meu histórico percebo que na realidade nem deu tempo de largar o HTML 5 e a esmagadora maioria das frustrações que eu tinha com este até então não existem mais (aliás, nem sei se ainda restou alguma destas limitações).

Foi tudo muito rápido. No mesmo ano comecei o desenvolvimento de jogos em… HTML 5 usando canvas. Em dezembro eu já tinha uma versão do Space Invaders 100% canvas que também é outro post bastante popular aqui no blog. Fantástico né? Agora vamos voltar às minhas reclamações de três anos atrás.

O pesadelo do HTML (os tais “web standards”)

Na época se não me engano o grande problema era o Internet Explorer e a maior parte dos browsers não dava um suporte razoável aos novos recursos do HTML 5. Wow, como as coisas mudaram. Pra começar, hoje na média, de acordo com o site “Can I Use…” estamos com suporte de aproximadamente uns 80%, ou seja, basicamente apenas os recursos menos usados não são suportados pela maioria.

html5_support

Internet Explorer

E o Internet Explorer? Bom: ao menos no meu blog corresponde a bem menos de 10% dos acessos, mas neste caso não vale muito pois minha audiência é técnica. Mas tirando isto, vou usar uma fonte bem mais confiável. Atualmente corresponde a 15,6% de todo tráfego da Wikipédia.

O próprio Internet Explorer acabou melhorando bastante: a versão 10 possuí um suporte bem melhor e, além disto, pelo fato de a Microsoft ter adotado Javascript/HTML como sua plataforma de desenvolvimento preferencial (mesmo por que ao que tudo indica ninguém mais liga pro Windows) a coisa parece que vai ficar ainda melhor no Internet Explorer 11: ou ela se adapta ou tá fora, simples assim.

Como quase optei pelo Flash

Na época eu estava desenvolvendo um produto que era basicamente um kanban eletrônico (mas gostei tanto do Trello que acabei largando o projeto). Então basicamente era drag and drop o tempo inteiro na interface do usuário e o suporte que eu tinha no HTML 5 era bem fraco para alguns detalhes da interface. Além disto, a linguagem Action Script também tinha me fisgado: me apaixonei por ela conforme ia lendo mais a respeito.

Durante o desenvolvimento deste projeto meu interesse foi para a área de jogos: comecei criando algumas coisas com OpenGL (sim, existe um “Duke Nanna” em algum lugar aqui em casa) mas por algum acaso resolvi experimentar o canvas do HTML 5 (um experimento muito tosco me acordou). Boom! De repente as coisas que eu achava serem possíveis apenas no Flash eu estava conseguindo com Javascript! Logo em seguida vieram animações com CSS 3, suporte a persistência local, dados de localização e pronto: em algo tipo seis meses eu já podia fazer práticamente tudo o que o Flash oferecia sem precisar comprar uma licença do produto.

O suporte que os navegadores passaram a oferecer a estas tecnologias veio muito rápido, bem mais rápido do que eu esperava (no post eu falo algo sobre o HTML 5 só estar pronto em 2022). Erro meu, que bom! :)

A presença “universal” do Flash

Eu realmente acreditava que só a Apple iria chutar o Flash e com o tempo acabaria voltando atrás. Wow, como estava errado! Na realidade diversos players começaram a simplesmente abandonar a plataforma por completo. Meu celular atual (um Nokia Lumia 800 com Windows Phone 7.8) já apresenta dificuldades ao lidar com o formato, idem para diversos dispositivos Android. Dado que mobile, e não desktop é o futuro, Flash não está mais com os dias contados, pois simplesmente não há mais dias para contar: acabou.

E ei: a popularização de coisas como Phone Gap e Appcelerator também contribuiram muito pra isto. De repente estamos criando aplicações semi nativas mobile usando HTML 5. Mais um prego no caixão.

Concluindo

Bendito seja o dia em que resolvi brincar com o canvas! Até então eu não conseguia ver o potencial da plataforma que estava surgindo (ela realmente se mostrava muito débil pra mim). HTML 5 pode até não ser oficialmente um padrão hoje, mas na prática é: e ao que tudo indica vai ser o padrão durante os próximos anos e talvez das próximas décadas.

O proprietário vai aos poucos sendo enterrado e o aberto dominando. Me pergunto: visto que esta plataforma está dominando de tal forma, será que aquele velho sonho de tornar o sistema operacional mero comodite já está se concretizando? Será que poderemos dizer em pouco tempo que tanto faz você ter um Mac ou PC pois sua aplicação foi feita pra rodar inteiramente na web? Acho que sim: mas ainda vai demorar um pouco.

PS: daqui a três anos eu volto a este post pra ver o quão certo ou errado eu estava ok?

O framework “Maria vai com as outras”

“Sabe Kico, eu acho Grails muito legal, mas fico receoso em usá-lo no meu novo projeto porque não é um framework muito popular. O que você acha disto?”. Escuto esta pergunta umas 4 ou 5 vezes por semana. Então resolvi me aprofundar nesta questão e, como resultado, surgiu este post, que não deve ser lido como algo específico sobre Grails, mas sim meus pensamentos aplicados a qualquer tecnologia “nova” ou “menos popular”.

Definição de popularidade

A definição mais ingenua seria “aquilo que é muito usado” porque só leva em consideração a quantidade, ignorando completamente “quando” e “onde”.

Muitas vezes escuto a seguinte frase: “tecnologia X não é muito popular, pois não conheço muitas pessoas que a usam”. É um argumento idiota: basta pedir ao sujeito que saia um pouco da sua zona de conforto e pesquise direito antes de falar bobagem. 90% dos profissionais com quem lido trabalham com Java. Isto quer dizer que .net seja impopular?

Outro bom contra-exemplo: Cobol. Não conheço nenhum programador COBOL, mas um estudo de 2007 da Gartner descobriu que 75% (SETENTA E CINCO PORCENTO) das aplicações corporativas eram escritas em… bem: Cobol.

Sendo assim, antes de pensar na popularidade de uma tecnologia, remova as suas impressões pessoais sobre o assunto.

Popular então é algo que possua um grande número de usuários em um certo domínio em um dado momento. Ok, uma definição mais completa, mas que não adiciona nada (ao menos pra mim), e que levanta a seguinte questão:

Qual o grande “ganho” da popularidade?

Mais gente pra falar a respeito e maior suporte da “indústria”. Além disto, também há aquele sentimento imbecil de que “se é muito usado, é porque deve ser muito bom”.

Gerentes cretinos amam,  pois fica mais fácil encontrar mão de obra e substituir elementos problemáticos. Se você pensa na sua equipe como uma linha de montagem de software, a popularidade de um framework é fundamental.

Pessoalmente tenho nojo desta linha de raciocínio porque só serve para uma coisa: alimentar a mediocridade gerada pela massificação.

É inegável o sentimento de segurança provido pela popularidade de um framework: afinal de contas, peixes muito grandes torcem para que isto ocorra, pois assim conseguem reduzir os custos de produção.

(só pra lembrar, o uso em massa de uma tecnologia acarreta na redução do seu custo que, no caso do software, é a mão de obra, ou seja, você desenvolvedor)

Qual o grande risco da “impopularidade”?

Óbviamente o desaparecimento da tecnologia. Porém este risco só é real se esta for fechada e o acesso a seu código fonte inexistente. Mas como hoje open source domina, no pior dos casos você ainda poderia dar manutenção naquela base de código sozinho. Afinal de contas, migrar de framework em 99,999% dos casos equivale à reescrita completa da aplicação, certo?

O que realmente importa?

Atender bem ao cliente. Não vou usar um framework só porque todas as pessoas “legais” do meu bairro o fazem também, mas sim porque me sinto à vontade com ele e o resultado do seu uso gera um produto cujo nível de qualidade satisfaça (e bem) as necessidades do meu cliente.

Tenho cá minhas dúvidas se realmente é possível atingir a qualidade sem o prazer na execução do trabalho. Eu pelo menos nunca consegui. E outra: se o projeto é seu, por que ficar usando o que não gosta só porque é popular? Pra aparecer bonito na fita?

No final das contas…

Há dois caminhos a serem seguidos: ser pastor ou cordeiro. Escolhi o caminho mais caro que é o primeiro e até hoje não me arrependi. :)

PS: e sobre o Grails?

Bem, no Grails Brasil tem quase 1000 membros inscritos. Tá de bom tamanho pra mim :)

PS2: e o Grails Brasil 2?

Muito provávelmente no final de semana que vêm ;)

Apache Ant: como pude te ignorar por tanto tempo???

“Comodismo emburrece”. Sempre repito orgulhosamente esta frase. Nesta semana acabei por perceber que também cai vítima do mesmo. Devido à comodidade que o Netbeans nos oferece no deploy e build de aplicações, acabei por ignorar completamente o motor responsável por esta comodidade: o Apache Ant.

Na realidade, não foi só o comodismo que me privou de aprender a ferramenta: confesso que a preguiça foi o fator fundamental. Toda vez que lia os scripts do Ant (escritos em XML), me lembrava dos meus tempos do make. Além disto, sempre via os scripts do Ant com certo desdém (não sou fã de DSLs baseadas em XML). Mas recentemente topei com um problema: como automatizar o deploy de minhas aplicações utilizando Java Webstart?

Como utilizo o Spring + Hibernate, a quantidade de arquivos no formato JAR que preciso distribuir é significativa. O que implica na necessidade de executar sempre executar as mesmas tarefas:

  • Assinar todos os meus arquivos .jar
  • Criar um arquivo .jnlp
  • Enviar tanto o arquivo .jnlp quanto os arquivos jar assinados para o servidor

O Netbeans está atualmente caminhando para tornar esta tarefa corriqueira, porém enquanto isto ainda não se tornou realidade, eu precisava repetir esta tarefa manualmente (SHAME ON ME!). Posteriormente escrevi um script em Groovy, porém acabei decidindo por me arriscar com o Ant. E o resultado foi maravilhoso!

A opção pelo Ant se deu quando encontrei por acaso na Internet uma biblioteca de tags chamada Orange Volt cujo objetivo era justamente a automatização do processo que listei acima. Basicamente, a utilizo para gerar o arquivo jnlp, porém todo o procedimento anterior é executado usando as tags nativas do próprio Ant.

Bem, visto que já babei o ovo do Ant, convém descrever a criatura. Trata-se de uma ferramenta de build similar ao GNU Make, porém sem os problemas decorrentes desta. Para começar, não é baseada na execução de aplicações instaladas no computador do usuário, mas sim em classes Java, o que torna seus scripts muito mais fácilmente portáveis. Além disto, o fato de usar o XML acabou se mostrando uma alternativa bastante interessante também (e ai eu paguei lingua) em comparação com a sintaxe do Make (qualquer um que já enfrentou problemas com o caractere tab no make sabe do que estou falando).

Instalação

A instalação do Ant é muito simples, e é composta pelos seguintes passos:

  1. Baixar o Ant em seu site oficial: http://ant.apache.org
  2. Descompactar o conteúdo do arquivo zipado em um diretório de sua escolha
  3. Criação de uma variável de ambiente chamada ANT_HOME, cujo valor deve consisistir no diretório no qual o arquivo zipado foi descompactado.
    Sendo assim, se você descompactou o arquivo no diretório C:\Ant, esta variável deverá possuir o valor C:\Ant
  4. Incluir no path do seu sistema o diretório ANT_HOME/bin
  5. Verificar se a variável de ambiente JAVA_HOME está definida no seu sistema.

Executados estes passos, no seu shell digite o comando ant. Se obtiver uma resposta similar a


Buildfile: build.xml does not exist!
Build failed

é sinal de que o ant foi instalado com sucesso.

Usando o Ant

Como mencionei acima, um script de build do Ant consiste em um documento no formato XML tal como no exemplo abaixo:

<pre><project name="meuProjeto" default="dist" basedir=".">
<description>
Um script ant que não serve para nada!
</description>
...
<target name="dist">
<!-- Eu irei fazer alguma coisa -->
</target>
</project></pre>

Este documento no formato xml deve se chamar build.xml. Quando o comando ant é executado, é buscado no diretório corrente a existência deste arquivo (trata-se do comportamento default da ferramenta). Como pode ser visto no exemplo acima, o elemento raiz deste documento se chama project.

Os principais atributos a serem definidos nesta tag são:
name: o nome do projeto
default: o alvo (target) a ser executado por default pelo script caso nenhum seja definido na linha de comando (mais sobre isto adiante)
basedir: o diretório base para a execução do script. No exemplo acima, se trata do diretório corrente.

A tag description é opcional. Serve apenas para fins de documentação.

Em um projeto podem ser definidos mais de um alvo (target). Um target consiste em um conjunto de tarefas a serem executadas pelo script. Tal como no make, você também pode definir interdependências entre as mesmas, tal como no exemplo abaixo:


<project name="projeto" default="distribuir" basedir=".">

<target name="copiar">
...
</target>

<target name="compilar">
...
</target>

<target name="distribuir" depends="compilar, copiar">
...
</target>

</project>

No exemplo acima, o target distribuir que é o default ao ser executado irá antes chamar os alvos compilar e copiar. Convém mencionar no entanto que a ordem de execução não necessáriamente será compilar e copiar. Se houver mais dependências nas tags compilar ou copiar, estas serão executadas antes das mesmas.

É possível também pela linha de comando executar um target específico. Se for executado o comando ant compilar, por exemplo, a tag distribuir (definida como default no exemplo) não será executada.

Tasks

Assim como um projeto é composto por alvos, um alvo é composto por tarefas (tasks). Uma task nada mais é do que um pedaço de código que pode ser executado. Simplificando ainda mais esta descrição, pense em uma task como um comando. A sintaxe de definição de uma task dentro de um target é muito simples:


<nome_da_task atributo1="valor1" atributo2="valor2" ... atributoN="valorN"/>

O Ant já vêm com uma série de tasks pré definidas, cuja lista pode ser acessada neste link.

Para melhor entender o funcionamento das tasks, segue abaixo um exemplo de build file bem simples. No caso, ele irá fazer o backup de um projeto qualquer.


<project name="backup" default="backup" basedir=".">

<property name="diretorioDestino" location="../backup"/>

<target name="backup">

<mkdir dir="${diretorioDestino}"/>
<zip destFile="${diretorioDestino}/backup.zip"
basedir="."/>

</target>

</project>

Ao ser executado, o script irá executar o alvo default (que também é o único no caso): default. As tasks definidas em seu interior serão executadas na ordem em que são definidas.

Sendo assim, primeiro será criado um diretório um nível abaixo do corrente chamado backup (convém mencionar que este diretório somente será criado caso já não exista). Para tal, utilizamos uma propriedade do script de build.

Pense em uma propriedade como se fosse uma variável utilizada pelo script. No caso, a propriedade em questão diz respeito a uma localização no disco rígido do usuário (o que explica o atributo location passado para a mesma).

Utilizamos o valor da propriedade diretorioDestino na task mkdir utilizando uma sintaxe bastante similar à EL com a qual estamos acostumados a trabalhar em arquivos JSP. Basicamente é a seguinte:


<task nome_do_atributo="${nome_da_propriedade}"/>

Em seguida, é executada a task zip. A função desta tag consiste em criar um arquivo no formato zip. No caso, usei apenas dois dos seus atributos: destFile (que indica o nome do arquivo a ser criado) e basedir (que diz qual o diretório raiz que contém os arquivos a serem incluídos no conteúdo compactado).

Dica importante: sempre consulte o manual do Ant online. http://ant.apache.org/manual/index.html

Criando e usando suas próprias tasks

Óbviamente as tasks que acompanham o Ant não irão suprir 100% das suas necessidades. Neste caso, é possível criar as suas próprias tasks. No manual do Ant há um guia muito simples de como fazê-lo: http://ant.apache.org/manual/developlist.html

Criadas as suas tasks, estas deverão ser empacotadas em arquivos jar. Uma vez gerados os seus arquivos jar, basta copiá-los para o diretório ANT_HOME/lib e em seguida utilizá-las em seus projetos do Ant.

Em seguida, para utilizá-las em seus scripts, utilize a task taskdef, tal como no exemplo abaixo:


<code><project name="blabla" basedir="." default="blablaTask">
<taskdef name="mytask" classname="caminho.para.sua.Task" />
...</code>
</project>

Esta task possui apenas dois atributos:
name: o nome que identificará a sua task dentro do seu script
classname: o caminho da classe que contém a sua implementação

Sendo assim, no mesmo exemplo acima a task poderia ser utilizada como


<code><project name="blabla" basedir="." default="blablaTarget">
<taskdef name="mytask" classname="caminho.para.sua.Task" />

<target name="blablaTarget"></code>

<mytask attribute1="algum valor" attribute2="outro valor"/>

</target>

</project>

Lembre-se: tasks só podem existir dentro de targets!

Tasks realmente úteis

Dentre as tasks disponíveis pelo Ant, algumas se mostraram incrívelmente úteis para mim:

signjar: é a tag que utilizo para assinar todos os meus arquivos .jar (e que me ajudou a resolver o problema com o Java Webstart)

jar: gera arquivos .jar

war/ear: Geram respectivamente arquivos .war e .ear (trata-se de uma especialização da tag jar

tar: gera arquivos .tar

zip/unzip: Compacta/descompacta arquivos no formato .zip

patch: executa patchs em arquivos originais

sync: sincroniza arquivos presentes em diretórios diferentes.

Conclusões

  • Comodismo gera ignorância :). Procure sempre que possível pensar FORA de sua IDE favorita.
  • A sintaxe em XML do Ant, apesar de inicialmente gerar resistência é uma mão na roda.
    Mas se você não gostar da sintaxe XML do Ant, pode contar com o GANT também (eu acho lindo como Groovy sempre torna as coisas mais bonitas)
  • Ant é MUITO mais simples do que aparenta em um primeiro momento.
  • Muito cuidado para não ficar viciado no Ant (agora gero scripts do Ant pra basicamente TODAS as minhas tarefas de manutenção em meus computadores (e em alguns momentos apenas por diversão))

“Windows 2008 Server está fabuloso! Está igualzinho o Linux!” (ou por que software livre importa)

Recentemente ouvi a pérola que dá o título deste post de um colega que, após sair de uma demonstração de produtos Microsoft, ficou fascinado com a modularidade do novo sistema operacional, cuja interface gráfica agora pode ou não ser instalada. Por trás desta ingenuidade, no entanto, esconde-se uma realidade assustadora.

(é um bom exemplo de pateticidade, ou seja, a aparência comica que disfarça uma realidade infeliz)

Minha resposta foi óbvia: “hmm… entendi. Então você vai abandonar toda a liberdade que o software livre te dá em troca de algo que imita o que você já possui e ainda pagar para obter esta perda! Você é um ‘gênio’! ” A pessoa ficou meio atordoada com a resposta (provavelmente me considerou um xiita ou simplesmente um esnobe), o que é normal quando vemos o objeto de nossa ilusão desfazer-se diante de nossos olhos.

Mais uma vez, o problema do determinismo linguistico se aplica. Como a maior parte de nós em nossa formação basicamente só vimos produtos Microsoft, tudo aquilo que é diferente desta nos parece ameaçador. Como de uns anos pra cá a baixa qualidade dos produtos desta se mostrou evidente (o crescimento do Linux e da Apple expõe isto de forma gritante), muitos se sentem aliviados ao ver que os produtos da Microsoft estão “iguaizinhos os softwares livres”. 

O ponto óbvio é: tudo isto que hoje é visto como “fabuloso”, “inovador” e “criativo” já existe há décadas FORA da plataforma Microsoft. Não se trata de uma novidade em si, mas sim de uma novidade nos produtos Microsoft. Como a maior parte dos profissionais da área só conhecem produtos desta empresa, acaba-se por criar a ilusão de que, de fato, são novidades absolutas. 

(mais uma vez o mito da caverna se apresenta)

Observe que normalmente só vemos dois polos: Microsoft e Linux. Muitos vão para o Linux simplesmente por causa do custo. Linux é visto como algo cuja única vantagem consiste no preço. O fato de possuir uma qualidade superior nem é levado em consideração nestes casos. O importante é apenas reduzir o custo. E com isto se esquece o que de fato vêm a ser o software livre. 

Só pra lembrar, um software é considerado livre se fornece quatro liberdades ao usuário:

 

  • Liberdade de usar o software como, onde e quando quiser
  • Liberdade de acesso ao código fonte do software, assim como de alterá-lo.
  • Liberdade de distribuir o software
  • Liberdade de distribuir a sua versão modificada do software

 

Uma vez compreendidas estas liberdades (o que farei aqui), fica nítido que voltar a usar software proprietário é no mínimo retrocesso. 

Liberdade de uso do software: este é a liberdade mais óbvia. O usuário deve poder usar o software onde e como e quando quiser. Parece estranho pensar nisto em um primeiro momento. Afinal de contas, quando compro por exemplo uma licença do Office, eu o uso como, quando e onde quiser, certo? Errado. Leia sua licença. 

LIberdade de acesso ao código fonte, assim como de alterá-lo. A primeira vista, esta liberdade pode até parecer descartável. Afinal de contas, somente programadores irão compreender o que significa aquele “monte de texto maluco”, correto? Errado. Possuir acesso ao código fonte implica em saber o que de fato o software faz, como funciona e se está de fato trabalhando corretamente. Você pode até mesmo não entender nada de programação. Mas o fato de existirem pessoas que saibam, e que auditam este código continuamente fornece uma segurança muito maior ao usuário.

E por que alterá-lo? Simples: se o software faz quase o que você precisa, ele não faz o que você precisa. Neste caso, o que você faz? Espera indefinidamente por uma versão que faça o que você precisa? 

Liberdade de distribuir o software: os usuários de software proprietário podem até não perceber, mas encontram-se divididos. Divididos porque não podem compartilhar as ferramentas que utilizam. Se um usuário pode redistribuir o software que recebeu, ele e aqueles que o receberem na realidade se unem. Todos irão falar o mesmo idioma. 

Liberdade de distribuir versões modificadas do software: se sua modificação solucionou seu problema ou resolveu um defeito do software em questão, nada mais natural do que passá-la pra frente. É neste ponto que o software livre apresenta sua qualidade superior. 

Um software proprietário ao qual você possua acesso ao código fonte não lhe permite alterar seu código. E mesmo que permita, não lhe permite distribuir suas modificações. Afinal de contas, é proprietário. Se você soluciona um bug neste tipo de software, o máximo que poderá fazer consiste em enviar sua sugestão de reparo a seu fabricante e este, talvez, a incorpore em uma nova versão. No caso do software livre, o reparo é imediato. Encontrou um bug? Envie-o para a comunidade. Esta não aceitou sua solução? Sem problema: publique a sua versão modificada em seu site. 

Outra vantagem: se você possui a liberdade de distribuir versões modificadas do software, você é um fornecedor também. Consequentemente, a partir desta liberdade, torna-se impossível que o software em questão possua um único fornecedor. É o fim do vendor lock in!

Após entender o porquê das quatro liberdades, fica nítido que voltar ao modelo proprietário é retrocesso (retrocesso é minha maneira educada de dizer burrice). Infelizmente, a maior parte dos “profissionais” de nossa área que usam software livre sequer leram alguma vez a GPL ou qualquer licença. Software livre para estas pessoas equivale a software gratuito. E gratuito é diferente de livre. E por ignorância, veremos diversos casos de retrocesso rolando por ai.

Não se trata aqui de benevolência ou trabalho comunitário. Longe disto! Trata-se de um modelo justo visando o benefício do usuário (que é quem realmente interessa no final das contas) e, ao mesmo tempo, evita que o desenvolvimento da tecnologia seja definido por um número pequeno de fornecedores. Há um interesse economico FORTE por trás do software livre. Convenhamos: o modelo proprietário já expos que não aceita a proliferação de concorrentes (atualmente os fabricantes de software de peso consistem apenas em Microsoft, Apple, Adobe, Sun, Symantec e Oracle. Antes do predomínio da Microsoft, no entanto, haviam BEM mais). 

Aliás, a justificativa que ouvi da mesma pessoa foi: “mas a integração do Windows com os produtos Microsoft já vale a pena”. É… vale “muito” a pena cair DE NOVO no mesmo golpe do fornecedor único “geninho”…

 

 

PS: outro bom argumento que escuto: “produtos proprietários são mais fáceis de usar”. Cara, não são. Na realidade, são tão fáceis de usar quanto os livres. A diferença é que como você só OS conhece, eles na realidade estão ocultando sua incompetência lhe fornecendo a ilusão de poder.