Acabei de terminar uma atualização importante do gist-it, o plugin para gerenciamento de código no WordPress.

Na primeira versão eu não poderia nem chamar de “gerenciamento de código” pois ele era muito focado em aproveitar o syntax highlight do Gist e pouco a possibilidade de ter uma interface para manipular o código direto do WordPress.

Agora o plugin além de criar um gist para utilizar o embed dos caras como syntax highlight, irá manter o código no WordPress e quando você modifica-lo, a alteração será enviada por cima da versão que está no Gist.

Algo parecido também ocorrerá se você editar lá pelo Gist (tanto na interface do site quanto pelo repositório): ao abrir o post para edição, o plugin puxa o código da versão online e sobrescreve a local.

Uma outra mudança foi a alteração da licença, que antes era GPL e agora virou MIT

download gist-it.
repositório no GitHub.

Eu adoro o jQuery. Não tem um dia que não brinque um pouco com ele.

É claro que ele não é a solução para a pobreza mundial, nem sequer para a tristeza dos emos. Como tudo nessa vida de softwares, é importante saber quando vale a pena adicionar à porrada de linhas de código que o jQuery adiciona ao carregamento da página, quando vale a pena usar algo que encaixa melhor no problema.

De qualquer forma eu tenho um motivo muito bom para você esquecer o discurso de quem é “anti” qualquer coisa, como o jQuery…

jQuery agora é algo que está no navegador

Há algum tempo atrás, o Google anunciou que hospedaria algumas bibliotecas de JavaScript, tais como jQuery; prototype; script.aculo.us; MooTools; dojo, apoiando os desenvolvedores a linkarem a parada diretamente de lá. A idéia é que com muitos desenvolvedores usando as bibliotecas que estão hospedadas no mesmo lugar, o usuário muito provavelmente terá uma copia da local em cache sempre.

O bom é que funcionou! O criador do jQuery acabou de falar: “Bom - A conta do jQuery na Amazon S3 ficou 1/3 mais barata que mês passado. As pessoas devem estar usando o Google Ajax API agora. Yay!”

E isso só vai aumentar. Podemos básicamente acreditar que o usuário já tem o jQuery (ou coloque aqui o seu framework JS preferido) pronto para ação no navegador! Ainda resta algum outro motivo para não utilizar?

gist-it é um um pequeno projeto (plugin para WordPress) que surgiu em uma tarde de sexta e está saindo para as massas segunda, aproximadamente 05:10 da madruga. Tudo isso por que eu gostei muito do Gist, que você deve saber o que é.

O que meu plugin faz é facilitar a inclusão de pedaços de código dentro de postagens no WordPress, por isso ele só deve lhe ser útil caso você seja um blogueiro-programador. Se você acha que ele vai te ajudar em algo, acesse a página que criei só pra ele: gist-it e divirta-se.

Então eu acordei essa manhã e me alimentei com o elemento que provem vida aos programadores: café.

Eu achava que seria um dia comum… que passaria a maior parte do tempo olhando para letrinhas coloridas, somente aplicando o que eu já sabia. Porem, em um dos últimos e-mails que eu havia marcado com a tag “para ler hoje” me deparei com dois links interessantíssimo enviados por um amigo também programador.

Um deles falava sobre um tal de “DRY” e o outro sobre um tal de “KISS”. A primeira vista pareciam mais uma dessas siglas que nós programadores usamos tanto… Ao ler com atenção percebi que se tratavam de conceitos para tornar meu trabalho mais produtivo. Sendo assim, resolvi aplica-los naquele dia para ver se valeria o esforço de aprender algo novo.

Para minha surpresa, no meio da tarde eu já havia terminado muito mais tarefas do que era acostumado a terminar em sexta-feiras. Eu havia terminando principalmente de escrever código nas linguagens que ainda estou aprendendo, como Ruby, ou tentando algo novo no jQuery (framework de JavaScript). Eu havia aprendido mais!

Nesse dia sobrou tanto “tempo livre” que o usei para escrever minha experiência com esses conceitos novos. Obrigado ao amigo Case que me falou sobre “Do Repeat Youself” e “Keep It Stupid, Stupid“.

Ficou parecido com uma historinha? Era a intenção. É uma historinha, a idéia é trabalhar em cima da seguinte frase:

Tentar a perfeição na primeira implementação é completa especulação. É extremamente difícil julgar a clareza de código que não está escrito, ou a performance de código que você não pode executar.

Wearing Out My Delete Key de James Golick, que eu já havia citado no último post.

Se estúpido for ter o trabalho pronto, o programa rodando e uma nova linguagem aprendida, eu vou ser um pouco estúpido.

Lembro de várias vezes que por otimizações prematuras, que por tentar o “jeito certo” ou a “lógica perfeita” eu não consegui terminar um projeto experimental (prova de conceito).

Porém, me repetindo a mim mesmo eu consigo jogar o que se passa na minha cabeça para o código. Deixo de me preocupar (em um primeiro momento) com os vários conceitos (como o DRY e KISS verdadeiro) que surgem quase todos os dias, esqueço que outra pessoa irá ler meu código, e assim eu simplesmente consigo antes de mais nada, faze-lo. Comentar é um passo após.

Quando você ler novamente sobre otimizações prematuras e o quanto isso é prejudicial, deixe de pensar somente na questão de performance, pense também nas otimizações que metodologias e a aplicação de conceitos trazem, pense se no primeiro momento eles são realmente necessários.

Assim provavelmente você vai se tornar mais produtivo, vai ter mais prazer ao “machucar código”. Mas lembre-se que agindo dessa forma, refatorar se torna muito mais importante. Quando olhar para o “problema lógico” resolvido, volte aos problemas que você teria tentado resolver antes. Lembre-se das questões para quais algumas metodologias foram criadas, agora é a hora de resolve-los, hora de refatorar código: quando ele já está pronto!

Ok, eu não sou um jedi em Ruby ainda, mas lendo o Ruby Cookbook pretendo me tornar um. O comportamento que você vai perceber nas telas eu aprendi lá!

Wow - nós estamos deletando mais código do que estamos mantendo!

Yeah, claro que estamos. Você não faz isso sempre?

As duas imagens abaixo foram adaptadas da apresentação Rails Taking the Red Pill que o Demetrius Nunes fez lá no Rio on Rails. Ela demonstra no código o paradigma “Convenção sobre Configuração” adotado pelo Rails.

Tentar a perfeição na primeira implementação é uma forma de especulação. É extremamente difícil julgar a clareza de algo que você não pode ler, ou a performance de algo que você não pode executar.

Quanto mais fácil de refatorar, ou reescrever (uma forma de refatorar), melhor. Essa é uma das razões de eu ser a favor de linguagens densas.

As citações são traduções de trechos do artigo Wearing Out My Delete Key de James Golick, leia!

Dharmesh Shah da HubSpot (startup de marketing na Internet) deixa claro em seu artigo “7 Uncannily Obvious Lessons From A Product Launch” o quão rápidas as iterações podem ocorrer dentro do conjunto de metodologias de desenvolvimento ágil de software. Principalmente em ambientes que facilitam tal perspectiva, como na web:

Seja realista na iteração: após os lançamentos eu intencionalmente limpo as pequenas distrações da minha agenda e então posso focalizar no software e iterar, iterar e iterar! Após o lançamento eu reescrevo software loucamente em vários updates diários do ambiente de produção! Nenhum dia pode passar em branco, sem que o software melhore para os usuários. Continue isso sempre que puder, quem sabe semanas ou mêses!

E eu que me achava estúpido por ter feito commit uma vez por dia em um dos serviços da boo-box por quase 2 semanas!

O que penso ser mais interessante do mercado que os americanos estão acostumados é a facilidade de se obter feedback (e a grande utilização do meio). No mesmo artigo Dharmesh diz que para se obter feedback, basta deixar algum lugar onde o usuário possa escrever sobre a ferramenta e clicar em “enviar”. Só isso!

Com o retorno dado pelos usuários a iteração fica mais rápida e produtiva, produzindo sempre um melhor serviço. Além disso, responder os contatos desses usuários enviando a solução para o problema é muito importante. Demonstra respeito pessoal a alguém que lhe fez o precioso trabalho de testar sua ferramenta.

Após escrever sobre a Creative Commons e MIT License chegou a vez da GPL - ou GNU General Public License - a precursora das licenças livres para distribuição de software. De quebra você vai entender o que é Copyleft e quais as diferenças entre as 3 licenças que expliquei até agora.

Uma forma fácil de entender a necessidade da criação da GPL é conhecer sua história, ou melhor: o que aconteceu com Richard Stallman que o levou a dedicar boa parte do seu tempo a criar e espalhar a idéia do software livre.

Nos anos 80 Stallman trabalhava no laboratório do MIT e um de seus projetos era um interpretador para linguagem de programação Lisp. Dentro do mesmo laboratório surgiu uma empresa chamada Symbolics com o intuito de produzir computadores de alto desempenho para pesquisas e projetos de IA (Inteligência Artificial) - chamadas de Maquinas Lisp.

Na época ocorreu a seguinte mudança nas indústria de computadores: os softwares que antes eram feitos para rodar somente em certos computadores passaram a ter características mais genéricas que possibilitariam o seu uso em maquinas de modelos e fabricantes diferentes. Antes só existia a indústria de maquinas completas, então uma vez que o foco da indústria não era especificamente linhas de código, e sim circuitos eletrônicos os programadores compartilhavam seus códigos livremente. Com essa mudança de perspectiva tornou-se importante para a concorrência existirem programas melhores, em vez de somente maquinas melhores. Foi quando as empresas passaram a exigir de seus funcionários que não divulgassem informações (códigos) para outras pessoas, usando como artifício as leis de direitos autorais (copyright).

A Symbolics que tinha acesso aos códigos que estavam nos laboratórios do MIT - por ser uma empresa de programadores do mesmo laboratório - usou boa parte do trabalho de Richard Stallman no interpretador Lisp aperfeiçoando e estendendo o programa. Porém quando Richard quis ter acesso às modificações feitas pela empresa, ela negou.

Desde então - especificamente 1984 - Stallman vem lutando para evitar casos como esse, de uma empresa que se aproveita do conhecimento criado por uma comunidade para então criar algo que não beneficie tal comunidade.

Achando muito difícil conseguir uma inversão de paradigmas somente mudando o pensamento dos programadores, Stallman decidiu se apoiar também nas leis de direitos autorais. Ele criou a Emacs General Public License que foi a primeira licença copyleft usada. E um pouco depois criou a GPL para ser usada no projeto GNU. Um licença de copyleft é a denominação para um tipo de direito autoral (sim, assim como as licenças de software proprietário se baseiam em leis de direitos autorais a GPL e outras licenças para software livre também!) que obriga a distribuição do código fonte de um programa derivado de outro que se encontrar sobre tal licença.

Espera! Essa é a alma do negocio, então eu preciso repetir.

Uma licença copyleft (assim como e principalmente a GPL) é a utilização das leis de direitos autorais para impedir que uma pessoa ou empresa se utilize de código aberto de software para criar/desenvolver um outro software derivado que seja proprietário, ou seja, que não disponibilize o seu código fonte na distribuição. Copyleft, Free Software ou Software Livre quer dizer uma mesma abordagem para evitar a necessidade de se pedir alguma autorização e enfrentar burocracias caso exista a necessidade ou vontade de melhorar, estudar, ampliar, adaptar um programa de computador.

Muitas pessoas podem confundir isso com software gratuito. Essas mesmas pessoas acham que programadores de projetos com código aberto (open source) são falsos comunistas, que dizem que é o software é livre querem mesmo é ganhar dinheiro. Que isso só aumenta as chances de sabotagem, e que não pode existir pessoas que trabalhem de graça.

Olha que viagem! Comunistas? Sabotador? Dá pra entender até onde vai as piras de quem não entende nadinha de uma boa sociedade baseada na livre circulação de conhecimento?

Chamar um software de livre não é necessariamente chama-lo de gratuito. Software livre como o nome diz está muito mais ligado em assegurar liberdades do que valores. Mais especificamente as liberdades podem ser resumidas para 4:

• A liberdade para executar o programa, para qualquer propósito.
• A liberdade de estudar como o programa funciona, e adaptá-lo para as suas necessidades. Acesso ao código-fonte é um pré-requisito para esta liberdade.
• A liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo.
• A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo que toda a comunidade se beneficie. Acesso ao código-fonte é um pré-requisito para esta liberdade.

Mas preste atenção: essa liberdades são asseguradas a quem adquirir uma copia do software.
Mas para adquirir uma copia do software você pode ter ou não que pagar por isso.

Ainda assim, se você pagar por isso poderá vender e até mesmo distribuir gratuitamente esse software. Por essa característica de dar a liberdade de “emprestar para seu vizinho” o programa pago, a maioria dos softwares livres já não são pagas desde sua primeira distribuição. E os desenvolvedores se utilizam de outras formas para criar uma cadeia econômica com o software livre. Como prestação de suporte e cobrança para aperfeiçoamentos e adaptações às características do comprador.

Caramba, você deve estar se perguntando quando eu vou começar a escrever sobre a GPL especificamente e parar com esse papo furado de software livre… Amigo, essa é a GPL (GNU General Public License)!

Claro que existem algumas diferenças entre outras licenças de código livre. Mas se você quer saber mesmo, ao se deparar com outra licença e tiver alguma duvida na diferença dela para a GPL, preste atenção no termo Copyleft. É esse termo que define a obrigatoriedade de se manter as 4 liberdades em trabalhos derivados.

Aproveitando o artigo, que uniu a explicação da GPL e do termo Copyleft gostaria de complementar as explicações que dei sobre Creative Commons e a Licença MIT (ou X11),

Creative Commons

Eu fiz uma certa confusão de palavras quando me referi ao uso da Creative Commons em projetos de código aberto e software livre.
O certo é entender que diferentemente do falado no artigo anterior código aberto não significa copyleft: obrigatoriedade em assegurar as 4 liberdades. Assim sendo, a Creative Commons pode ser utilizada sim em projetos de código aberto, porém não em softwares livres. Mais uma vez para reforçar: se o software é livre, ele deverá manter-se livre e a Creative Commons não obriga isso. Então ele é código aberto, mas pode deixar de ser…

Ainda relacionado a isso, existe um tipo de Creative Commons chamada Share-Alike. Ou compartilhamento sobre mesma licença. Ela chega mais próxima de ser livre, ao em vez de somente aberta. Porém como ela assegura somente que o projeto deverá ser redistribuído sobre a mesma licença e não necessariamente ter a mesmas liberdades, não podemos chamar nem mesmo a Creative Commons Share-Alike de copyleft.

Licença MIT

Diferentemente do que o artigo dá a entender, não é necessário somente incluir o aviso de copyright nas copias do software ou de seu código. Deve-se logicamente também seguir tais termos de copyright! (Veja a licença).

Complementando, a Licença MIT não obriga a distribuição do código fonte e também não sobrepõem seus termos sobre outras licenças. Isso quer dizer que como o software pode ser re-licenciado, pode ser que essa outra licença faça com que os termos da Licença MIT percam a validade.

Ou seja: Ela dá a liberdade de quem obtiver o software por ela licenciado, porém não obriga nem a disponibilização do código fonte, nem a manutenção dessa liberdade na próxima distribuição (como a GPL obriga). Por esse motivo, ela também não é uma licença copyleft.

Saiba Mais sobre outras licenças de conteúdo e software:

Esse artigo faz parte de uma série de outros dois artigos explicando as características de algumas licenças de livre circulação de material cultural, de código aberto e de software livre.
Veja mais:
Entendendo a Creative Commons
Entendendo a Licença MIT

* Esse artigo é baseado em Sinatra Tutorial. A good starting point por Ari Lerner. Você pode encontrar outras informações no RubyForge (Sinatra)

Sinatra é um framework para linguagem Ruby extremamente leve. Ele roda tendo como base o servidor Mongrel, servindo com muita rapidez as requisições.

Por não ter a extensa biblioteca de “helpers” que o Rails tem e também por não seguir a linha MVC de Rails e Merb, o seu uso não é indicado em grandes aplicações.

Com foco em Web Services e pequenos aplicativos, Sinatra é uma ótima solução para rodar pequenas aplicações desenvolvidas em Ruby com muita eficiência.

O propósito do artigo é ser um guia de inicio para quem quer aprender mais sobre o framework, para isso vamos desenvolver um pequeno “own-microblog”…

(more…)