#JS13KGames, #gamedev e o jogo de desenvolver jogos

Acho que quase todo nerd de programação já deve ter pensado em desenvolver um jogo (se já não desenvolveu ou até trabalha com isso), eu não sou exceção.

Gamedev fun!

Gamedev fun!

Ano passado conheci o js13kGames, um desafio e competição, com prêmios, em que o objetivo é desenvolver em um mês um jogo usando apenas javascript e web em 13kb. Muito legal! Uma ótima chance de “brincar” de gamedev para quem já trabalha com web e com o incentivo de uma competição leve. Ainda ganhei um blusa!

Recomendo a todos que tem essa curiosidade, foi uma experiência bem legal e aprendi bastante fazendo isso e farei novamente esse ano.

Outras fontes de inspiração você pode achar no Compohub, que agrega competições, jams e desafios que estão acontecendo na web sobre gamedev. Um muito legal é o projeto One game a month, que como um rpg te da achievments e rewards se conseguir realmente manter um ritmo de um jogo simples por mês… mas eu só consegui fazer dois.

Enfim, fazer games é divertido, recomendo! Em próximos posts falo sobre o desenvolvimento em si :-)

Docker: containers, isolamento e replicabilidade de ambientes de produção

Se com o Vagrant você consegue ter o ambiente de dev como parte do código fonte do projeto, como ter o mesmo para o ambiente de produção? Conheça agora o Docker!

Docker é uma abstração, que adiciona recursos e simplifica o uso, dos linux containers (LXC), que são, basicamente, uma forma de isolamento de processo e sistemas, quase como virtualização, porém mais leve e integrada ao host. Linux-only, nesse caso.

O Docker então te permite criar aplicações e “containers”, que isolam o SO base e todo a pilha de dependências de seu app (libs, servidores, etc, etc) de forma leve em espaço e performance. É o vagrant para produção, basicamente. Pense em VMs muito leves, que podem rodar em cima de outras VMs, na verdade.

Assim, você pode usar o Docker para ter diversas aplicações com ambientes diversos (apache vs unicorn vs tomcat vs whatevernot) em uma mesma maquina ou vm porém sem perder muito em recursos.

O Docker trabalha ainda com um sistema de arquivos “empilhaveis”, o aufs, que permite que os passos para configuração do seu container funcionem de forma incremental e “cacheable”, mais ou menos como “commits” do GIT. Pense em GIT para seu ambiente de produção ;-).

Atualizou libs: commit. Instalou o server: commit. Terminou uma nova versão: Tag. Da mesma forma você pode mandar o ambiente em partes para a nuvem (push) você também pode trazer apenas as atualizações (pull). Viu, git.

E como fazer, afinal:

Primeiro, o Docker é para o linux, assim em outros sistemas você vai precisar de uma maquina virtual com linux (usando, por exemplo, o vagrant :-). Instale o docker para sua distro e comece seu primeiro projeto.

Você deve escolher uma maquina base, como uma das muitas disponíveis no Docker index. Pode ser que já tenha uma 100% como você precisa, ou até os 80% chatos prontos. Em seguida o principal comando do docker:

docker run -i -t ubuntu /bin/bash

Esse comando diz: docker, rode (run), de forma interativa (-i, para terminais), em cima da imagem do ubuntu (-t ubuntu, de tag) o comando bash (/bin/bash). Outro exemplo:

docker run -t ubuntu echo hello from docker

Repare que após rodar um comando esse vai retornar um identificador, esse é o id da imagem gerada pelo comando. Você pode ver todos os containers, ativos ou não:

docker ps # containers em execução
docker ps -a # todos

Como configurar uma maquina então?

CONTAINER=$(docker run -t ubuntu apt-get update) # atualiza e salva o id do container
CONTAINER=$(docker run $CONTAINER apt-get install apache2 -y) # instala o apache e salva o id do container
docker tag $CONTAINER diogok/apache2 # identifica o ultimo comando
$RUNNING_CONT=$(docker run -d -t diogko/apache2 apache -D FOREGROUND)
docker ps
docker logs  $RUNNING_CONT

Temos vários parâmetros importantes, alguns são:

Redirecionando portas: -p host:guest direciona a porta host para o porta do guest, pode usar várias vezes. Ou -P para expor várias portas aleatoriamente (apenas portas descritas como passiveis de expor, mais disso mais tarde).

docker run -p 8080:80 -t diogok/apache2 #direciona a porta 8080 da maquina host para a 80 do apache

 Variáveis de ambiente: usando -e FOO=BAR o container vai ter essa variável disponível.

Rordar em background: -d , pois por padrão ele vai ficar no seu terminal.

Compartilhar volumes(pastas): -v /pasta1:/pasta2 compartilha a pasta  /pasta1 do host como a /pasta2 do guest (ele monta como um volume). Pode usar para vários containers ao mesmo tempo.

Isso tudo é legal, mas o grande ganho eu acho que vem com  a configuração sendo parte do projeto, usando o Dockerfile.  O formato do Dockerfile é bem simples, eis um exemplo:

FROM ubuntu:14.04 # baseado no ubuntu 14.04
RUN apt-get update # rode esse comando
RUN apt-get install apache2 -y # lembre de confirmar automáticamente, pois você não vai ter um tty
ADD index.html /var/www/index.html # copia um arquivo do projeto
EXPOSE 80 # expõe a porta 80
CMD [“apache”,”-D”,”FOREGROUND”] # esse é o comando padrão

Para construir esse Dockerfile em um container basta executar, na pasta do projeto:

docker build -t diogok/apache2 .

Então para rodar o container:

docker run -d -P -t diogok/apache2

Para ver em execução:

docker ps

Ler os logs:

docker log $container_id

E enviar pro registro online:

docker push diogok/apache2

Cada passo é atômico e fica em cache, assim se você muda um passo ele só vai refazer este e os seguintes.

Isso tudo vai ter dar um ambiente replicação para dev,homolog e prod, seja lá onde cada um for (aws, digitalocean, linode, sua máquina…).

Experimente com diferentes construções do docker e divirta-se.

Dev env as code: Vagrant up

Quem trabalha com muitas tecnologias em diferentes projetos, ou mantém diversos projetos para plataformas diferentes com certeza já passou por isso: Como manter diversos ambientes de desenvolvimento na mesma maquina? Ou mesmo como reconstruir “aquele” projeto mais antigo? Para isso e para o clássico do garoto novo na empresa ter que configurar um ambiente novo ou quando você mesmo troca de maquina, temos o Vagrant!

Vagrant é uma camada de abstração para o ambiente de desenvolvimento. Ele permite definir o ambiente de dev do projeto através de um arquivo de configuração, o Vagrantfile, que passa a ser parte do código da aplicação, logo entrando para o controle de versão, distribuição e tudo mais. A partir desse arquivo o vagrant é capaz de criar uma maquina virtual com todo o ambiente pronto.

Algumas vantagens de usar essa abordagem:

  • Ambiente faz parte do código do projeto
  • Ambiente fica documentado
  • Portabilidade (mesma VM no linux, windows e mac)
  • Maior proximidade do ambiente de produção/homologação
  • Maior isolamento entre os ambientes de diversos projetos
  • Testar projetos distribuídos

Meus dois principais use-cases foram para permitir a quem entrar novo no time ter o ambiente pronto rapidamente, e de manter os ambientes isolados (tenho apps em php, clojure, ruby 1.9, ruby 2.1, etc…) sem afetar uma a outra.

Para usar o vagrant é simples:

Primeiro instale um virtualizador (como o virtualbox) e o vagrant no seu sistema.

Em seguida, no projeto, rode o comando “vagrant init”, ele vai criar um arquivo Vagrantfile de exemplo com comentários sobre como configurar sua maquina virtual. Tendo um Vagrantfile no projeto basta executar o “Vagrant up” para subir e configurar a maquina virtual. Com a maquina no ar você pode então executar “vagrant ssh” para ter acesso a ela e ir a pasta /vagrant, a qual é compartilhada com o projeto em si.

Resumindo:

$ vagrant init # cria um vagrantfile
$ vagrant up # inicia uma maquina virtual
$ vagrant ssh # acessa a maquina virtual
$ vagrant halt # desliga a maquina virtual

Algumas configurações importantes:

Deve-se definir a máquina base usando, por exemplo:

config.vm.box = "ubuntu/trusty32"

Além disso você pode buscar no vagrant cloud por várias máquinas já prontas, pode ser que a você precisa já esteja lá.

Usando a diretiva de rede no Vagrantfile a maquina virtual fica disponível nesse IP, assim como ganha uma rede interna para todas as vms poderem se acessar:

config.vm.network "private_network", ip: "192.168.10.10"

O mais importante do vagrant é a capacidade de provisionamento do ambiente, ou seja, instalar e configurar as dependências da sua aplicação de forma simples e automatizada, usando as ferramentas mais comuns de devops:

Pode até combinar eles, exemplo:

config.vm.provision "puppet" do |puppet|
 puppet.manifests_path = "manifests"
 puppet.manifest_file = "default.pp"
end

config.vm.provision "shell", :inline "apt-get install apache2 php5"
config.vm.provision "shell", :path "config.sh"

Temos também alguns plugins interessantes.

Concluindo, com um Vagrantfile no projeto você garante que o ambiente desse projeto está a um “vagrant up” de distância. Embora o tempo para instalar e configurar a maquina inicialmente demore um pouco (afinal está configurando uma maquina totalmente nova), o isolamento e a certeza de ter um ambiente uniforme valem a pena.

Em um próximo texto faço também alguns exemplos de configurações para os ambientes mais comuns.

Novos projetos: FastChat e Semaphore.js

Sempre curti micro-projetos úteis e reutilizáveis, principalmente widgets.

Bom, para o projeto que estou trabalhando vi a necessidade de dois widgets que imaginei que seria legal de reutilizar, e eis o resultado deles (ainda em desenvolvimento):

Semaphore.js

Um mini widget em javascript que apenas indica o status do servidor através de um semáforo.

Através de um url configurada do widget ele indica se o servidor está online, lento ou offline. É bem útil para aplicações totalmente em ajax, principalmente quando se depende de servidores instáveis ou serviços de terceiros. Permite ainda algumas integrações para cada estado.

Consiste apenas em um pequeno arquivo javascript.

FastChat

Fastchat: chat widget easy to use

Esse é mais legal! É um widget de bate-papo que basta carregar um pequeno javascript sem dependências e está pronto o chat!

Foi feito com um servidor em clojure, usando redis e javascript simples para o widget. Pode-se usar css para customizar a UI padrão, grava um histórico, possui uma “janela” por usuário, lista de onlines e etc.

Bom, é isso, o semaphore.js eu já usei em mais de um projeto e o fastchat ainda está em teste no projeto principal, mas acho que promete bastante.

Manifesto de volta, e com wordpress agora!

Long time no see!

Faz muito tempo que não dou atenção a este blog, mas pretendo voltar agora, sem promessas apenas vontade.

A novidade é que migrei do joomla(já muito desatualizado que estava, mesmo para um joomla) para o wordpress, migração tranquila com um pouco de sql e todo o conteúdo estava portado, e junto com um 301 na antiga pasta está tudo ok! (eu acho…)

E para quem acompanhava: meu feed antigo está morto :/ é preciso assinar o novo, se o conteúdo ainda interessar.

Aproveitei e atualizei tudo que tinha nesse servidor, que era outro wordpress e outro joomla e uns aplicativos perdidos. Os aplicativos eu removi, ficou apenas o que era estático (documentações, uns hotsites…) e o wordpress eu atualizei.

O outro joomla que roda aqui é um problema, antigo e meio complicado de dar manutenção. Tenho que ver o que fazer com ele, não pode ficar assim.

De resto, I am back!

Redis e PHP: Who is online?

Redis e PHP: Who is online?

Em um micro projeto precisei manter uma lista de usuários online, são usuários de várias fontes em conexões não persistentes, então fiz uma solução simples em PHP e Redis.

Primeiro você precisa conhecer o Redis e te-lo rodando, o que é bem simples:

$ git clone git://github.com/antirez/redis.git
$ cd redis
$ make
$ ./src/redis-server

Com o redis funcionando vamos usar a biblioteca Predis para trabalhar com Redis em PHP, pegue uma cópia atual e prepare o Phar do projeto:

$ git clone git://github.com/nrk/predis.git
$ cd predis
$ php bin/createPhar.php
$ mv predis-*.phar seu/projeto/predis.phar

Com as dependências prontas vamos a lógica para os usuários online: Vou implementar um método “ping” em um controller qualquer, a cada ação do usuário uma chamada ao “ping” vai ocorrer.

A cada ping o nome do usuário vai ser inserido em um “set” no redis, vou ter um “set” para cada minuto, mas usando “expire” só vou manter os sets dos ultimos 5 minutos.

Para descobrir os usuários online faço “sunion” dos ultimos 5 minutos para saber quem está online. Você pode ajustar o tempo como achar mais justo para sua aplicação.

Segue o “pseudo-controller”, devidamente comentado (no projeto é meio diferente, mas a base é essa):

PS: o Predis é para PHP 5.3, o que não deve ser um problema, certo?

Publicado em PHP

Servidor Git pessoal com gitolite

Usem o Git, vale a pena. Usem o Github quando puderem, também vale muito a pena. Mas as vezes precisamos de um repositório mais privado, e não estamos afim de pagar para o github (embora vale a pena!) já que temos servidores sobrando.

Entra o gitolite, que permite fácil configuração multiusuário para um repositório Git.

Eis como proceder: Primeiro copie sua chave pública para o servidor (a mesma do github, por exemplo):

$ scp ~/.ssh/id_rsa.pub user@servidor:~/

E então faça ssh para o servidor e se torne root, para seguir os seguintes passos:

# cd
# aptitude install git
# git clone git://github.com/sitaramc/gitolite gitolite-source
# cd gitolite-source
# mkdir -p /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
# src/gl-system-install /usr/local/bin /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
# useradd git -d /home/git -g users -m -s /bin/bash
# su - git
$ gl-setup /home/user/id_rsa.pub

Atenção: assumi que seu usuário padrão no servidor é user, se não for troque as ocorrências. Pronto assim temos o básico pronto, agora sobre operação geral.

Você pode configurar uma interface de consulta básica na web usando o próprio git, ainda no user git faça:

$ cd repositories/testing.git
$ git instaweb -d webrick -p 8081

Agora pode acessar seu servidor na porta 8081 para navegar nos projetos. Não precisamos mais estar no servidor para os próximos passos.

Então vamos criar um novo repo e adcionar usuários, da sua maquina:

$ git clone git@servidor:gitolite-admin.git
$ cd gitolite-admin

Nessa pasta edite o arquivo conf/gitollite.conf, nessa sintaxe:

repo nome-do-repositorio
  RW+ = user1 user2 user3

Sendo user1 user2 e user3 os usuários com acesso para escrita. O repositório será criado vazio e e para liberar os usuários basta copiar as chaves publicas para a pasta “keydir”, no formato “user1.pub” e etc. Agora envie as alterações.

$ git commit -a -m 'adionado repositorio nome-do-repositorio'
$ git push

Congratz, you got git!

Meu ambiente de Trabalho em 7 itens

Ae, o @gserrano descreveu seu ambiente de trabalho em 7 itens e me convidou para o meme, estão vou descrever meu ambiente de trabalho em 7 itens também:

0. Mesão
É, eu gosto de uma mesa grande, com espaço, com papel e caneta para rabiscar ideias. Espaço, espaço eu preciso de espaço! É o zero porque o meme fala sobre o ambiente virtual apenas :)

1. Opera e Firefox
Para navegação cotidiana, testes, e-mails e etc eu uso Opera. Acho o navegador muito ágil e o sincronismo de tudo desde de bookmarks até histórico e notas bem ajuda. O firefox só quando mexo com Javascript mesmo, ai entra o Firebug.

2. Rhythmbox/celular
Rhythmbox é o player de música no Ubuntu, quando não estou em casa uso o celular mesmo. Música é essencial! Do Punk ao Metal! Oh Yeah \o/

3. Git
Controle de versão é com Git sempre, e se for possível no Github.

4. VI
Meu editor de escolha, seus atalhos no teclado “rulez”.

5. Terminal
Vários utilitários, buscas em arquivos, testes e scripts sempre úteis!

6. SSH/screen/servidores e mais vi
Sempre tem um par de servidores remotos para testar as aplicações e fazer homologações também, além de brincadeiras de qualquer tipo e quando uma banda descente vem a ser necessária.

Agora convidar outros, certo? Vou chamar um pessoal variado também: O #dev companheiro de trabalho @pedromenezes, o #dev companheiro de #cparty @shdo, o designer @richardbarros (para reviver seu blog!) e o sysadmin @ebastos.

Valeu galera!