VidaGeek.net

Linux, Open-source, Programação e Produtividade

Como funciona o Wii Remote

Wii Remote e Nunchuk
Esse post eu devo ao Marcos Bonci Cavalca, aluno de iniciação científica orientado pelo mesmo orientador que eu (prof. Marcel Jackowski). O Marcos está pesquisando interfaces para programas de imagens médicas e pretende usar o Wii Remote na interface que está desenvolvendo. Com as reuniões periódicas do grupo de pesquisa, eu acabei aprendendo um pouco também e resolvi contar aqui.

O Wii Remote tem dois sensores: uma câmera, que captura a luz infravermelha emitida por dois pontos na sensor bar, e acelerômetros, que permite obter a aceleração do controle nos três eixos (vertical, lateral e profundidade). A câmera encontra as fontes de infravermelho (lembrando: o Sol é uma, então jogar Wii a céu aberto num dia ensolarado não é uma boa) e emite as coordenadas dos pontos para o console. Com isso, dá para calcular a orientação do controle com relação ao chão e a direção para a qual você está apontando na tela. Já o Nunchuk, se não me engano, tem um acelerômetro só. Todos os dados são enviados via bluetooth para o Wii.

Uma curiosidade: Não sei se todo mundo sabe mas eu, pelo menos, descobri há pouco tempo. Vale não só para a sensor bar do Wii Remote, como para a maioria dos emissores de infravermelho usados em controles remotos. As webcams e (não testado) câmeras mais baratas e simples capturam infravermelho. Assim, você pode testar se seu controle remoto está funcionando apontando-o na direção de uma webcam ligada. A fonte de luz infravermelha vai aparecer branca na imagem.

Posts Relacionados:

  • Futuro dos Jogos
  • Microsoft e reconhecimento de voz
  • Como migrar de SVN para GIT
  • INC - Long Switch?
  • Palestra da Mozilla no IME/USP
  • Software útil
  • Algoritmos Humorísticos - Trainee Algorithm
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Como remover os malditos .svn

    Uma das coisas que mais me atrapalhava com o svn era quando eu queria gerar um snapshot do que tinha no repositório, mas sem os .svn .

    Um one-liner bash que faz isso:

    
    	find . -iname .svn | xargs rm -fr
    

    Explicação:

    1. find . -iname .svn: Encontra todos os arquivos ou diretórios que se chamem .svn
    2. xargs rm -fr: O xargs é um programa que executa o que vier depois dele pra cada linha que ele receber como entrada. Por isso apaga todos os .svn.

    Posts Relacionados:

  • Como descobrir todos que commitaram em um repositório SVN
  • Como migrar de SVN para GIT
  • Truques do Bash
  • Por que filtrar ips não deu certo
  • Sincronizando o Address Book do seu mac com os Contatos do Gmail
  • Mirror DSL
  • Deixando seu Ubuntu mais rápido
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    FISL 10: Scaling Rails

    Na segunda palestra que assisti (na verdade terceira, mas a primeira não conta porque, infelizmente, dormi :P), Sylvestre Mergulhão deu continuidade à palestra do Fabio Akita e falou sobre escalabilidade utilizando Rails no site RedeParede, um site de classificados com versões para toda a América Latina.

    Sylvestre começou falando da performance do site e o sistema de indexação do Google (o Googlebot). Falou que o Googlebot afetava perceptivelmente a performance do site quando estava indexando e era responsável por aproximadamente metade das requisições. Levantou também algumas teorias sobre o Googlebot (parte que achei mais interessante na palestra):

    1. Sitemap em XML => mais visitas
    2. Rank também é determinado por capacidade do site de receber visitas
    3. Queda de serviço => menos indexação por um bom tempo
    4. Mais atualizações => mais indexação

    Depois disso, Mergulhão falou um pouco sobre a estrutura física dos servidores do site. São seis máquinas atrás de um balanceador de carga, cada uma com cinco instâncias rodando atrás do NGINX. Falou também um pouco do memcached, utilizado para fazer cache de qualquer string, que está sendo utilizado em massa pelo site. Segundo ele, é uma biblioteca fácil de usar, apesar de pouca documentação. Deu também exemplos de configuração e de uso. Falou mais um pouco sobre problemas com caching (página muda de acordo com usuário) e sobre outros tipos de caching: de página (falou que era melhor usar o cache de HTTP com ETags), de ações (muito interessante: permite guardar o resultado de uma ação no cache; dobrou a capacidade de processamento do servidor deles) e de fragmentos (para guardar pedaços de páginas).

    Por fim, falou um pouco sobre o ganho de performance e de tempo de desenvolvimento (por não ter que usar mais SQL) com o uso do Sphinx.

    O começo da palestra foi interessante, mas minha impressão final é de que o palestrante não ficou muito feliz com o resultado da migração do site, antes em PHP, para Rails. Outro comentário que posso fazer é que já trabalhei num projeto em Rails com Sphinx e a equipe não gostou muito; acabamos mudando para o Solr.

    Posts Relacionados:

  • FISL 9.0: Entrando nos trilhos - Introdução a Ruby on Rails
  • Rails Vs Java e PHP
  • FISL 10: Agilidade e Qualidade de Projetos com Ruby on Rails
  • Inscrição de Caravanas para o FISL 8
  • FISL 8.0
  • FISL 10: Seaside versus Rails
  • Rails Summit
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Ontem, Fabio Akita deu uma palestra no FISL 10 sobre Ruby on Rails. Foi uma palestra lotada e divertida.

    A palestra começou com uma breve introdução ao arcabouço, um outline da palestra. O Fabio falou de como surgiu o arcabouço, qual era seu objetivo inicial, falou das atuais versões de Ruby, de Rails e do JRuby e da importância da comunidade para o projeto.

    Em seguida, na parte mais divertida da palestra, o Akita mostrou alguns dados sobre a performance da máquina virtual de Ruby. Mostrou, por exemplo, o ganho de velocidade da versão 1.8 para a versão 1.9 da máquina virtual “padrão” de Ruby por meio de um jogo muito interessante chamado “Rubystein” que eu, pelo menos, não conhecia nessa versão… hehehe). O jogo, aliás, utiliza uma biblioteca para acessar o hardware diretamente para fazer o desenho 2D: Gosu.

    Depois da demostração de ganho de velocidade realmente impressionante da nova máquina virtual, falou um pouco da importância da comunidade para se aprender e divulgar Ruby on Rails. Citou, inclusive, alguns sites muito bons para ficar por dentro das últimas novidades sobre o projeto:

    Em seguida, Fabio falou de alguns recursos que já vem embutidos no Rails mas que nem todo mundo lembra, motivo pelo qual, segundo ele, algumas pessoas xingam Rails sem motivo. Dentre essas funcionalidades, vale destacar o suporte a autenticação HTTP básica, Atom, internacionalização (i18n para os íntimos), XML, JSON, e-mail e caching.

    Para terminar, o Akita fez uma demonstração de algumas funcionalidades incrementando o já famoso blog de 15 minutos. Criou uma área de administração com login, colocou caching, um editor de texto mais incrementado e suporte a upload de arquivos, para citar as mais legais.

    Enfim, aprendi algumas coisas novas com essa palestra; gostei! E acho que também agradou a quem não conhecia quase nada de Rails. Parabéns, Akita. Mas faltou alguma coisa de metodologias ágeis na palestra (pelo título).

    O código que ele mostrou na palestra está no GitHub e os slides, no SlideShare.

    Assim que der tempo falo sobre as outras três palestras que assisti ontem, apesar da visita do nosso presidente ter atrapalhado um pouco o andamento do evento…

    Posts Relacionados:

  • FISL 9.0: Entrando nos trilhos - Introdução a Ruby on Rails
  • Rails Vs Java e PHP
  • Rails Summit
  • Inscrição de Caravanas para o FISL 8
  • FISL 8.0
  • Ruby e Rails no Mundo Real
  • FISL 9.0: Desenvolvimento ágil com Scrum e XP
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.


    Publicidade