Archive for July, 2007

Re-introdução ao JavaScript

Tuesday, July 17th, 2007

O Diego Plentz acabou de me mandar um artigo muito bom sobre JavaScript. JavaScript? É, isso mesmo.

Trata-se de uma re-introdução ao JavaScript.

Porque você deveria ler isso? Porque o JavaScript é frequentemente subutilizado como uma linguagem para validação de formulários ou visto como um brinquedinho para iniciantes. Poucos desenvolvedores conhecem a verdadeira força desta linguagem e nos dias de hoje de Ajax e Web2.0 saber JavaScript pode fazer a diferença na hora de resolver vários problemas importantes.

Atualmente as aplicações web mais interessantes utilizam “toneladas” de JavaScript para torná-las mais interativas, como por exemplo o GMail, MindMeister, Yahoo Pipes, Netvibes e vários outros mais.

Leitura absolutamente recomendada.

Como fazer print screens no Mac OS X

Saturday, July 14th, 2007

O print screen (impressão ou captura de tela) é um recurso utilizado para “fotografar” a tela do seu computador em um certo momento. Ele gera uma imagem de tudo que está na tela, exatamente como está. Mas se você chegou até aqui, certamente já sabe o que é um print screen, só não sabe como fazê-lo no Mac.

Deixe-me adivinhar, você está procurando a tecla “Print Screen” desesperadamente e não acha mas você tinha certeza que já tinha visto esta tecla? Então eu tenho uma boa notícia: você não está louco e nem cego. Realmente esta tecla não existe no Mac, só nos PCs comuns. Foi lá que você viu.

Uma coisa boa do print screen do Mac é que você não precisa de nenhum programa além do próprio Mac OS para fazê-lo. Como sabemos, no Windows você teria que apertar a tecla “Print Screen” e depois colar a foto em algum programa (Paintbrush, Photoshop, Word, etc) para depois salvá-la. Parece bom o suficiente, mas no Mac, as coisas são bem mais legais (pra variar). Ele pode salvar a imagem direto para você sem precisar de programa algum, sem contar que você pode capturar uma tela inteira, um pedaço dela, ou somente uma janela… E se você quiser mandar para o clipboard (área de transferência) para colar no programa que quiser, também pode. Funciona assim:

command+shift+3: Captura a tela inteira e salva numa imagem no seu Desktop (Mesa), em formato PNG.

command+shift+4: Captura uma parte da tela que você escolher, e salva no seu Desktop. Ao usar esta combinação, o cursor do mouse vira um alvo e você seleciona a área que quer capturar. Você arrasta e quando soltar ele automaticamente captura a tela.

command+shift+4 e depois barra de espaço: Se você usar a combinação anterior (command+shift+4) e em seguida apertar a barra de espaço, o ponteiro do mouse que era um alvo vira uma câmera, e você pode clicar com ela em cima da janela que você quer para capturar somente ela e salvar a imagem no seu Desktop.

qualquer combinação+ctrl: Ao invés de salvar a imagem no Desktop, a imagem fica no clipboard e você pode colar no programa que desejar, sem gerar uma imagem automática.

alterar o formato do arquivo: É possível escolher o formato do arquivo que o print screen gera, pode ser PDF ou PNG. Para alterar esta opção, abra o Terminal e digite o comando “defaults write com.apple.screencapture type pdf” e pressione enter. Desta forma você altera o formato do arquivo para PDF. Para alterar para PNG, basta substituir no comando o pdf por png. Você deve fazer logout ou reiniciar o Mac para que esta alteração passe a valer.

E então? É fácil ou não é?

E não para por aí! Em todas as capturas de tela feitas através destes comandos, as imagens são armazenadas em formato PNG (Potable Network Graphics) que como o próprio nome já indica é um formato de imagem compactado, ou então em PDF que também não fica com a qualidade muito boa. Se você precisar de print screens com maior qualidade, você pode utilizar o programa Grab, que vem com o Mac OS e fica na pasta Utilities (Utilitários). Ele salva as imagens em formato TIFF com alta resolução. Ele é bem simples de usar e dispensa maiores explicações.

Configurando cores no Terminal.app

Saturday, July 14th, 2007

Para deixar o Terminal do Mac OS X mais colorido, faça o seguinte:

1) Adicione o seguinte conteudo no fim do arquivo ~/.bashrc (se ele não existir, crie-o):

export TERM=xterm-color
alias ls="ls -G"

2) Adicione o seguinte conteúdo no fim do arquivo ~/.vimrc (se ele não existir, crie-o):

:syntax on

Reinicie o Terminal e pronto, tenha uma vida mais colorida:

Terminal colorido

Se quiser melhorar ainda mais, o Zé Peleteiro escreveu no seu blog uma dica interessante sobre como configurar Unicode no Terminal. Vale apena conferir.

Aumenta a adoção de metedologias ágeis em 2007

Tuesday, July 10th, 2007

A notícia é um pouco velha mas como é uma boa notícia acho que ainda é tempo. O Scott Ambler publicou na Dr. Dobbs o resultado da sua pesquisa anual de adoção de metodologias ágeis.

A pesquisa de Scott Ambler este ano mostra que metodologias ágeis foram implantadas com sucesso na maioria das empresas. Seis anos após seus surgimento, ele acha que as metodologias ágeis finalmente cruzaram todo o “abismo de adoção de tecnologias de Moore”, que sugere que uma tecnologia passa por vários estágios de adoção, desde os inovadores e “early adopters” até os “laggards” (atrasados).

A utilização efetiva de metodologias ágeis no exterior tem crescido a passos largos, especialmente nos Estados Unidos. Isto indica que dentro de pouco tempo as metodologias ágeis também estarão muito difundidas aqui no Brasil e sendo adotadas em larga escala. É claro que muitas pessoas já conhecem, mas na prática o número de empresas que adotaram estas metodologias ainda é muito pequeno.

Na empresa onde trabalho muitos costumes já existem há vários anos e é muito complicado mudar tudo da noite para o dia. Mas lentamente várias práticas de XP e outras metodologias ágeis como o Scrum estão sendo introduzidas. Cada vez mais a alta gerência está consciente de que existem problemas no modelo atual de desenvolvimento de software e eles estão cada vez mais dispostos a tentar coisas novas.

Parece que coisas boas estão por vir.

A guerra entre REST e WS-* acabou!

Wednesday, July 4th, 2007

Acabo de ler um artigo no InfoQ entitulado The REST versus WS-* war is over!.

Só que pra ser bem sincero eu não concordo muito com este artigo. Para mim essa guerra nunca existiu.

Veja bem, é mais ou menos como tentar fazer uma guerra entre facas de pão e facas de peixe para tentar descobrir qual é a melhor. Oras, se você está comendo peixe, a melhor faca é a faca de peixe. Se você vai cortar um pão, a melhor faca é a de pão. Tá bom, essa analogia foi ridícula, mas é tão ridícula quanto uma comparação entre REST e WS-*/SOAP.

O que eu quero dizer é que, assim como funciona com as facas, o tipo de webservice que se usa varia em função do cenário de uso.

Nem todos os tipos de sistemas precisam da quantidade de recursos que WS-*/SOAP oferecem e isso torna-se um overhead desnecessário. Por exemplo, é muito mais fácil fazer mashups e sites com vários recursos Ajax utilizando webservices REST. Em compensação você pode precisar fazer orquestrações de webservices, operações transacionais, roteamento e outras coisas que REST não oferece mas que com WS-*/SOAP se faz com relativa facilidade.

Certamente há espaço para os dois no mercado, não vejo motivos para encararmos como uma guerra.

AJAX Compilation

Tuesday, July 3rd, 2007

Ajax Compilation é uma compilação de referências para diversas APIs e bibliotecas AJAX que você pode usar em seus sites para torná-los mais interativos.

Basicamente o dono do site teve o trabalho de catar para nós um monte de sites legais na internet e criar um catálogo deles, colocando um link para o site da ferramenta e para o demo online (quando é oferecido pelo site da ferramenta).

Nem tudo catalogado lá é AJAX, algumas coisas são em Flash e outras são em puro Javascript mesmo. Mas o que importa é que tem um monte de coisinhas legais e vale apena dar uma olhada. Recomendado para o cinto de utilidades dos desenvolvedores web. ;)

POST vs. PUT: quem insere e quem altera?

Monday, July 2nd, 2007

Eu e o Phillip Calçado estamos trabalhando numa aplicação com uma interface de webservices REST.

Um dos pontos que estavamos discutindo hoje é sobre os métodos POST e PUT. Qual deles que representa um INSERT e qual representa um UPDATE? Se você procurar na internet vai perceber que vários sites dizem várias coisas diferentes. Foi quando resolvemos mergulhar no problema e entender qual é a forma correta de se fazer as coisas.

Superficialmente falando, webservices REST são CRUDs (acrônimo para Create, Read, Update e Delete). Por isso é muito natural tentar traçar um paralelo entre os métodos HTTP e as operações de banco de dados feitas por um CRUD

HTTP -> SQL

  • GET -> SELECT
  • DELETE -> DELETE
  • POST -> UPDATE
  • PUT -> INSERT

O nosso erro foi justamente esse de tentar traçar um paralelo com as ações de um CRUD. Se você pensar em SQL, realmente faz sentido que o POST seja um UPDATE e o PUT um INSERT. Porém quando se trata de webservices REST a coisa fica um pouco diferente porque HTTP é um pouco diferente de SQL.

O funcionamento do método PUT é “colocar” uma página numa determinada URL. Se a página já existir naquela URL ela é substituída. Se não houver página, ela é criada e passa a ser a que foi enviada no PUT. PUT é uma operação limitada que simplesmente coloca uma página numa localidade. Além disso, PUT é idempotente, ou seja, se você fizer 20 vezes um PUT numa URL o resultado tem que ser o mesmo que seria se você fizesse uma vez só: é o mesmo que acontece se você executar 20 UPDATES em um registro, é o mesmo que executar um update só.

Para exemplificar, considere que estamos criando um usuário num sistema qualquer. Neste sistema, a URL para obter (GET) um usuário de ID 1, por exemplo, seria:

http://gc.blog.br/usuarios/1

Então, se você desejasse criar um usuário utilizando PUT, a URL teria que ser:

http://gc.blog.br/usuarios/[id]

Porém quando você cria um objeto você normalmente não sabe qual é a chave primária/id deste objeto. Quem te dá esta informação é o sistema, não é você que escolhe. Neste caso, se você fizer um PUT numa URL de um usuário que já existe, você o AUTALIZARIA ao invés de criar um usuário novo.

Para criar um usuário o correto seria fazer um POST para a URL:

http://gc.blog.br/usuarios

Ao receber um POST esta URL cria um novo usuário e retorna o ID dele no response. O POST não é idempotente e se esta URL for chamada 20 vezes, 20 usuários serão criados e cada um deles terá um ID diferente: o mesmo que acontece quando você executa 20 INSERTS. Esta URL pode ser considerada como uma Factory de objetos Usuario.

Sendo assim a forma correta de se mapear os métodos HTTP para ações de um CRUD é:

  • GET -> SELECT
  • DELETE -> DELETE
  • POST -> INSERT
  • PUT -> UPDATE

Em alguns casos, porém, você sabe qual é a URL que será criada para o usuário. Por exemplo, os seus usuários poderiam ser representados da seguinte forma:

http://gc.blog.br/usuarios/guilherme

Ou seja, para criar um usuário com PUT você poderia chamar uma URL com o padrão:

http://gc.blog.br/usuarios/[login]

Porém esta operação é extremamente arriscada. Se já existir um usuário “guilherme” o sistema achará que você está tentando atualizar o Guilherme ao invés de criar um novo e o “guilherme” antigo irá se perder. Se for um POST o sistema pode retornar uma mensagem dizendo que não pôde criar o “guilherme” porque já existe um usuário com este login.