Ir para conteúdo Ir para Menu

Post original em DojoRio.org.

Step In é um encontro para aprender com software livre.

Objetivo

  • entender como funciona um determinado software livre (ou parte dele, alguma funcionalidade);
  • refatorar algo do mesmo (secundário, opcional).

Requisitos

  • 1 piloto que tenha um bom conhecimento da linguagem usada no projeto, ferramentas de debugging e do projeto escolhido (esse último é opcional, mas ajuda).
  • 1 desktop/notebook;
  • 1 projetor (pra clonar a tela do computador);
  • 1 quadro-branco (opcional, mas ajuda na hora da explicação);

Como Funciona

Primeiro escolhe-se o projeto que será explorado. Pode ser um plugin, ferramenta, framework ou linguagem de programação. Qualquer tipo de software.

O piloto deve (obviamente) baixar o código do projeto.

Logo depois começa a explicá-lo passo-a-passo, tirando eventuais dúvidas da platéia. É uma boa executar código ao longo do processo para exemplificar o que está sendo analisado.

Para explicar, pode-se usar o quadro-branco, executar algum código que use a funcionalidade, debuggar o mesmo, usar analogias ou o que for conveniente.

Caso o piloto não saiba explicar alguma coisa, lembre-o que a documentação e o Google são seus amigos. Nada impede que alguém da platéia explique alguma coisa.

Pode ser interessante refatorar algo que não esteja bom, adicionar alguma funcionalidade que seja de rápida implementação ou consertar alguma falha de segurança. O piloto faria a mudança e checaria se os testes atuomatizados continuam passando ou criaria novos testes se necessário. Caso alguém da platéia tenha tido a ideia, pode assumir como piloto e o antigo piloto se torna co-piloto até a finalização da refatoração.

No fim do Step In, o piloto deve fazer uma review rápida do que foi aprendido. Também seria interessante que a review seja postada em algum blog.

O Que As Pessoas Podem Aprender

As pessoas podem aprender tanto funcionalidades da linguagem, conceitos usados e sobre as escolhas e estratégias do desenvolvedor da ferramenta.

De Onde Surgiu a Ideia

Outro dia eu estava olhando como funciona o roteamento de URL do Sinatra para ver como os blocos são executados.

Poucos dias depois, notei que seria interessante usar a estratégia deles num dos projetos que estou trabalhando.

Na palestra do Caike Souza no DevInRio, ele perguntou quem fazia Code Review dos projetos de suas empresas. A maioria não fazia.

Imaginei que não abrissem o código de projetos open-source mesmo dos que estivessem usando.

Minha cabeça explodiu.

De Onde Surgiu o Nome

O nome foi sugerido pelo camarada Henrique Bastos pós DevInRio.

O Que Estão Esperando?

Nos próximos open-spaces e palestras em eventos boladões, quero ver Step Ins em vários projetos!

O Que Acharam da Ideia e do Processo?

Sugestões são mais do que bem vindas. :-)

O cdto é um aplicativo que coloca um botão no Finder do Mac OS e que, ao ser clicado, abre o Terminal e dá cd no diretório aberto no Finder.

Como instalar o cdto

  • Baixe-o e descompacte-o;
  • Abra a pasta com o instalador correspondente à versão do seu Mac OS;
  • Arraste o aplicativo cdto para a pasta de Aplicativos do Mac OS;
  • Arraste o cdto da pasta Aplicativos para a barra de ferramentas de um Finder;
  • Pronto.

Como usar o cdto

  • Clique no ícone do cdto em uma janela do Finder;
  • Seja feliz.

O Homebrew é um gerenciador de pacotes para Mac OS muito melhor que o Mac Ports.

Melhor porque seus pacotes estão sempre atualizados. Os do MacPorts demoram séculos pra serem atualizados.

Ele é baseado em fórmulas.

Fórmulas são scripts Ruby com instruções sobre como baixar e compilar determinado pacote.

Onde os Pacotes são Instalados

Os pacotes normalmente são instalados em /usr/local/Cellar.

Logo depois são criados links simbólicos dos seus prefixos para os binários.

Como Instalar o Homebrew

  1. Instale o XCode, caso não o tenha feito ainda;
  2. Digite no Terminal: ruby -e “$(curl -fsS http://gist.github.com/raw/323731/install_homebrew.rb)”

Como Pegar pela Primeira Vez a Lista de Fórmulas do Homebrew e Atualizá-la

  1. Se não tiver o git ainda, instale-o e sinta vergonha de não ter feito isso antes;
  2. Digite brew update. Só isso.

Na primeira vez, ele baixará as fórmulas disponíveis.

Nas outra vezes, ele te mostrará os novos pacotes, os atualizados e os removidos.

Como Listar as Fórmulas Disponíveis

Basta digitar: brew search.

Exemplo de Instalação de um Pacote

Se quiser instalar o wget, basta fazer o seguinte: brew install wget.

A partir da fórmula do wget, o Homebrew:

  • instalará a libidn se passar –enable-iri como parâmetro;
  • baixará o código do wget da URL definida;
  • verificará a Hash MD5;
  • compilará;
  • instalará;
  • criará um link simbólico de wget pro binário.

Veja ao vivo:

Onde está Disponível a Lista de Comandos

Além do man brew, tem uma página na wiki do projeto.

Como se Cria Fórmulas e Como se Envia para o Autor

Acesse a página Formula Cookbook na wiki.

Lá tem tudo detalhado.

Curtiu? Espalhe!

Obrigado pela dica, sr. Jorge Falcon.

No dia 15 de maio de 2010 ocorreu o NoSQL Brasil, o 1º encontro sobre bancos de dados não relacionais no Brasil, organizado pelo Alexandre Porcelli em São Paulo.

Desenvolvedores no NoSQL Brasil

Desenvolvedores no NoSQLBrasil. Créditos: Henrique Bastos

Quem foi no NoSQL Brasil

Mais de 200 desenvolvedores compareceram para mostrar ao mundo que bancos de dados não são só SQL.

Assim como existem linguagens de programação que facilitam o desenvolvimento de determinada aplicação, existem bancos de dados (leia: SGBDs) que se encaixam melhor em um projeto.

NoSQL é sobre escolha.

Como estava a organização

Sensacional!

Porcelli teve ajuda de sua família e amigos.

Afinal, um evento que ia ter 40 pessoas tomando cerveja e conversando sobre NoSQL teve 200 pessoas e aconteceu num dia inteiro no Hotel Park Suites ITC na Vila Olímpia.

Os coffee breaks estavam muito bons em especial os pães de queijo. ;)

Quais foram as palestras

  • SQL anti patterns and NoSQL alternatives (Gleicon Moraes)

    Gleicon mostrou que você deve abrir a cabeça para a desnormalização.

    Uma apresentação recheada de exemplos do que você não deve fazer em bancos de dados relacionais e quais são algumas das opções para soluções racionais e elegantes.

  • Performance e simplicidade com Chave/Valor utilizando Redis (Luiz Fernando Teston)

    Redis é um banco de dados chave-valor rápido que guarda os dados na memória e persiste no disco de tempos em tempos.

    Me pareceu interessante para aplicações simples.

  • O papel do REST no Neo4J e CouchDB, um comparativo (Guilherme Silveira)

    Guilherme falou que devemos:

    • sempre desenvolver em camadas
    • evitar bater no banco de dados, devemos cachear tanto no client como no servidor. No máximo devemos ver se a informação cacheada é atual.
    • ter servidores stateless – não guardar dados de aplicação nos mesmos. Por exemplo: guardar dados de sessões de usuário no memcached.
    • aproveitar mais os cabeçalhos do HTTP como o de links
    • usar ETags para checar versões de dados.
  • Introdução ao MongoDB – direto da fonte! (Alberto Lerner)

    Alberto foi engenheiro do BigTable no Google e agora está começando na 10gen, empresa que criou o MongoDB.

    Ele deu uma introdução bem legal sobre o Mongo e como é possível escalá-lo.

  • Tio: um NoSQL made in Brasil (Rodrigo Strauss)

    Rodrigo apresentou seu projeto chamado Tio, um servidor de containers focado em publish/subscribe.

    Você pode criar servidores só mexendo no código do client.

    É possível criar um message Broker, servidor de fila e várias outras coisas.

  • Nas Nuvens com KVM, JBoss REST-Easy e InfiniSpan (Edgar Silva e Samuel Tauil)

    Os palestrantes falaram sobre mapeamento de verbos de serviços na web usando URIs (exemplo: /voos/atrasados/gru) e como usar usar Inifinispan como cache distribuído através de uma interface REST com o RESTEasy.

  • Divide et impera – Processamento massivo com Hadoop, Pig e HBase (Vinicius Carvalho)

    Vinicius falou que anda testando o Hadoop usando Pig na Amazon.

    Ele envia os dados pra Amazon S3 e executa o script Pig semanalmente com a Amazon Elastic MapReduce.

    Ele também disse que provavelmente não usaria Hadoop se não fosse pelas facilidades da Amazon.

    Hadoop é bem chato de instalar.

  • Estudo de caso: avaliando o Apache Cassandra como cache distribuído (Julio Viegas)

    Julio falou sobre como estão usando Cassandra como cache na SPC Brasil.

    Antes eram usados Ehcache e RMI.

    Sua equipe pesquisou o:

    • memcached – não usaram porque o failover era “manual”
    • Redis – não usaram porque tiveram problemas com chaves e memória. Isso os limitava.
    • Voldemort – não usaram porque tinha uma comunidade pequena

    Resolveram usar o Cassandra porque:

    • tem um bocado de gente grande que usa. Tipo o Digg, Rackspace e Twitter.
    • é tolerante à falhas
    • escala horizontalmente
    • é bem rápido

    Um ponto negativo (não é possível ter tudo num sistema distribuído) é que ele não é sempre consistente.

    Se ele buscar um certo dado em determinadas máquinas e não achar o que tem o timestamp mais recente, ele pode retornar uma versão antiga.

    Isso é difícil de acontecer, mas é possível definir quantas máquinas ele vai consultar.

    Quanto mais máquinas você buscar a informação, mais lenta fica a resposta, porém você ganha em consistência.

    Cassandra

    Cassandra é uma delicinha…

O que não foi legal

Porcelli fez de tudo pra acontecer o evento, logo teve que cortar algumas coisas.

Não tivemos acesso à interwebs.

Eu gostaria de ter testado os SGBDs enquanto os caras palestravam, mas não deu.

Fica como dever de casa. :)

Valeu a pena?

Claro, conteúdo e pessoal nota 10!

#HoraExtra sensacional no bar da esquina depois do evento com um monte de gente!

Mais uma coisa

Porcelli pagou boa parte do próprio bolso.

Mais de R$1000,00 em doações foram feitas durante o evento, mas não conseguimos tirá-lo do vermelho.

Participe da Vakinha para ajudar nosso amigo. ;)

Você curte bancos de dados não relacionais? Quais? Quer ver algum tutorial ou artigo sobre eles aqui no blog? Acha que é viagem?

Aloha, senhores, maior saudade de vocês! :}

Como meu projeto final da faculdade envolverá WebSockets, resolvi aprender fazendo um chatzinho com Node.Js e Sinatra. Talvez eu faça algo mais elaborado e escreva as experiências aqui no blog.

Achei legal essa parada de WebSockets e resolvi explorar outros recursos do HTML5 que são bem legais.

Selecionei uns sites pra compartilhar. Dêem uma olhada com carinho:

  1. Dive Into HTML5 ~ esse site bem ilustrado do Mark Pilgrim será publicado em formato de livro pela O’Reilly e tem um conteúdo bem legal
  2. HTML5 and The Future of the Web ~ artigo interessante da Smashing Magazine sobre as peculiaridades e onde é possível usar HTML5
  3. HTML5 presentation ~ slides interativos (feitos em HTML5) que mostram as funcionalidades do mesmo
  4. HTML5 Demos and Examples ~ algumas demos de aplicações feitas com HTML5
  5. HTML5 Tag Reference ~ referência feita pelo w3schools.com
  6. W3C HTML5 Specification ~ especificação oficial do HTML5 que está sendo escrita
  7. HTML5 MDC ~ mostra que recursos são suportados pela engine da Mozilla (Gecko)
  8. HTML5 Readiness ~ legal, mas não muito prático para ver quais navegadores suportam que recursos do HTML5
  9. The HTML5 Test ~ veja quais funcionalidades seu navegador atual suporta
  10. Canvas Demos ~ demos legais mostrando o que é possível fazer com Canvas
  11. Bônus: Canvas Tutorial ~ tutorial legal sobre Canvas escrito pelo pessoal da Mozilla

Tem alguma ideia legal que dá pra fazer com HTML5? Já usou sáparada? Onde? Acha que esse bagulho é doido? Conhece algum site legal sobre o assunto?

Compartilhe com a gente nos comentários! :D

« Anteriores - Próximos »

PedroMenezes.com © 2012 sob Creative Commons. Política de Privacidade e Responsabilidade.