Sometimes you need to stage a client site to he can see it, but some clients are a little neurotic about others seeing their sites before the launch, what is an acceptable behavior. In one job that Im doing I dropped in this case and need to protect entire site from access. It will be easier to do with a clean Rails installation, but Im using Devise, and Devise do some jobs on basic auth, so, it don't play nice at start... The solution was create an extra strategy for Warden, in order to make it do the authentication, after a lot of research and code read I reached a solution, and I'm here sharing it with you :)
At first you need to create the strategy and configure Devise:
After you need to configure your application controller:
And it will make your entire site to be protected with http basic auth.
To make it works I first created a separated scope for this login, otherwise the devise will go crazy, and also I need to created that FakeModel class, because devise always try to serialize/deserialize the record save, to make a record compatible, just need to have an "id" method on instance, and a "find" method in class.
So, if you need to protected your site for staging, this solution will make everyone happy :)
Para ativar as tags em um documento basta incluir o módulo Mongoid::Taggable:
No seu formulário:
Nesse caso, seu campo de texto deve receber uma lista de tags separadas por vírgula (abaixo nesse documento você verá como trocar o separador padrão.
Então seu documento terá as propriedades tags e tags_array. A propriedades tags você deve usar como uma string com as tags separadas por vírgula, o tags_array é um array de tags, essas duas propriedades são sincronizadas automaticamente.
Indexando Tags
Essa biblioteca irá criar automaticamente um índice das tags após salvar o documento, esse índice é bastante útil para ter uma lista de todas as tags usadas nos documentos ou para criar um tag cloud. Veja o seguinte exemplo para entender como usar isso:
Se você não for usar esse recurso, é bom desativar para melhorar a performance:
Mudando o separador padrão
Para alterar o separador padrão você precisa apenas chamar o método tags_separator na sua classe:
O Harmony, desenvolvido por Martin Aumont, é uma nova DSL Ruby para executar código JavaScript e que usa DOM a partir de aplicativos Ruby. Por que isso é legal? Porque isso possibilita a criação de testes unitários para o Javascript utilizado em suas aplicações em Ruby, ou seja, tudo pode ser testado com um único conjunto de testes!
Falando assim parece que o Harmony é uma biblioteca incrivelmente complexa, mas na verdade ela encapsula outras bibliotecas, como a Johnson, que oferece acesso ao interpretador de Javascript da Mozilla Spidermonkey no Ruby, e env.js, um ambiente DOM recriado em JavaScript.
Veja o "Hello World" do Harmony:
HolyGrail - O plugin para Rails
Se você está usando Rails, o HolyGrail é o plugin que leva o leva o poder do Harmony às suas aplicações (até o momento só para testes funcionais). Veja alguns exemplos com o HolyGrail:
Bom, estive tendo alguns problemas para instalar as coisas aqui no Ubuntu, mas consegui resolver, segue o passo a passo de comandos para ter tudo instalado e pegando:1. Instalar o XAMPP e o XAMPP development package (instrucoes no site do xampp) 2. Instalar o Ruby com Development Package: sudo apt-get install ruby1.8 ruby1.8-dev rubygems1.8 irb rake libopenssl-ruby1.8
3. instalar o rails sudo gem install rails
4. rodar o xampp sudo /opt/lampp/lampp start
5. instalar o mysql sudo gem install mysql -- --with-mysql-dir=/opt/lampp/ --with-mysql-lib=/opt/lampp/lib/mysql --with-mysql-include=/opt/lampp/include/mysql
6. configurar link para socket sudo mkdir /var/run/mysqld sudo ln -s /opt/lampp/var/mysql/mysql.sock /var/run/mysqld/mysqld.sock É isso, com isso rolo tudo certo aqui :)UPDATE:Eu percebi que o link do mysqlsock é perdido sempre que o sistema é reiniciado. Então eu criei um script para iniciar o xampp e criar o link automaticamente na inicialização:crie o arquivo abaixo:/usr/bin/lamppstart #! /bin/bash
/opt/lampp/lampp start mkdir /var/run/mysqld ln -s /opt/lampp/var/mysql/mysql.sock /var/run/mysqld/mysqld.sockapós criar o script é nescessário incluí-lo na inicialização do sistema, para isso adicione a linha para executa-lo dentro do arquivo /etc/rc.local, o meu arquivo ficou assim:/etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing.
Olá galera,Atualmente eu estou criando uma biblioteca para Specs em PHP.Como toda boa biblioteca do gênero, eu decidi que os testes iriam rodar atravéz da tela de comando.Para o caso de testes, eu considero bastante importante que se tenha uma saída colorida para identificar de forma mais rápida os resultados. Pesquisando na net achei muita coisa sobre comandos ANSI que permitem fazer várias coisas legais, como por exemplo mover cursor, mudar a cor... Tudo muito bonito, até chegar no console do windows...A desgraça não queria pegar cores de jeito nenhum, até achei em vários tutoriais na net para abilitar o ANSI no windows, mas no meu Vista (eca...) não funcionou... Então fui pro lado prático da coisa, fui ver onde funcionava. Eu utilizo o Cucumber para testes do Ruby aqui, e ele consegue fazer a saída colorida, então decidi ir por esse ponto. Depois de alguns testes eu vi que incluindo certas bibliotecas na hora de rodar o ruby, ele consegue automaticamente converter os ANSI para o console do windows, oque foi lindo, então eu meio que usei o ruby de proxy para a execução do programa em PHP, assim ele iria ler a saída, converter e exibir. Funcionou :DResultado:
Como podem ver, bastante colorido e legal :)O código Ruby que eu usei para o proxy está aqui:
Claro que para uma futura versão de release isso ai vai mudar muito (adaptar pra verificar se está em windows, tratamento de erros e etc...)Enquanto isso a Limber Spec já está dando os primeiros passos e deve ter algo funcionando de verdade em breve :)Só pra finalizar, uma referência esperta pra quem quizer dar uma olhada sobre comandos ANSI: http://academic.evergreen.edu/projects/biophysics/technotes/program/ansi_esc.htm
Quando o professor da faculdade pediu um projeto para ser apresentado na cadeira de Linguagem de Programação 2 (que na minha faculdade é considerado orientação a objetos, ensinado com Java), eu perguntei se poderia fazer o projeto em outra linguagem que não fosse Java, e felizmente o professor aceitou.Decidi então programar em Ruby, sobre o projeto, eu não tenho muita criatividade para softwares esporádicos, então minha decisão foi fazer um remake de um antigo jogo para windows 95, o "Bow and Arrow" (ou barrow para os mais chegados =P). Decidi que seria um bom desafio e me ajudaria a entender melhor o Ruby (já estudo Ruby a cerca e 1 ano, mas nunca fiz mais do que pequenos scripts e testes).Depois de roubar todos os sprites do jogo original, eu comecei a programar, para criar a camada visual eu decidi utilizar o Shoes, porque eu ja tinha algum conhecimento sobre o mesmo, e também porque tem muito jogo feito com ele, então a comodidade me fez ficar nele.Antes de começar eu decidi ler algums fontes de jogos feitos com Shoes, baixei vários jogos no shoesbox para ver como as pessoas estavam lhe dando com frame-rate, sprites animados... Infelizmente essa parte da missão não teve muito resultado, pouquissimas aplicações utilizavam algum tipo de engine para seus jogos e as soluções não tinham nada de muito sofisticado, a única conclusão foi que todo mundo usada o metodo "animate" para o main loop do jogo.No começo do desenvolvimento eu fiz tudo em apenas um arquivo Ruby, apenas para fazer alguns testes, nesse ponto era possível controlar o arqueiro com o mouse, e atirar as flechas (que eram imediatamente repostas após atiradas). Depois de vários testes feitos eu vi que era hora de organizar aquela bagunça, então comecei a criar uma engine própria para o jogo.A primeira parte era deixar o arquivo principal o mais enxuto possível, então deixei ele apenas iniciando a aplicação em Shoes, criando uma instância da classe do jogo, iniciando o "animate" e chamando o loop do jogo a cada iteração do animate. Eu sabia que eu precisaria separar as fases do jogo, mas eu decidi começar o desenvolvimento pelos elementos do jogo, então comecei pela classe básica dos elementos, essa classe não tinha muita coisa, apenas definição de variáveis básicos do elemento (x, y, largura, altura), teste de colisão (que também fiz a sobrecarga do operador & para testar colisão entre objetos, hehehe), e um método draw vazio. Sem muitas delongas, a partir dessa classe eu fiz a classe do herói, das flechas e dos balões.Para o herói de inicio a coisa foi um pouco mais complicada, a inicar pelo problema de "estados", afinal o herói deveria poder ter vários "estágios":
stand -> estágio padrao, onde ele pode puxar a flecha para atirar
armed -> estágio armado, onde ele está preparado para atirar uma flecha
waiting -> estágio de aguardo, onde ele tem que aguardar um tempo para poder voltar ao stand para poder atirar novamente
Se eu estivesse em outra linguagem eu provavelmente teria feito um "switch/case" (ou case/when para ruby =P) dentro do método draw que iria fazer um teste para cada estado. Mas, eu to no mundo do Ruby, e eu já sabia que eu precisaria controlar estados em vários objetos diferentes. Então eu fui a lugar para criar uma StateMachine.A idéia básica era simples, seria um módulo, onde teria métodos de classe para adicionar estados (onde os parâmetros seriam o nome do estado e um bloco para a execução do estado), e também o módulo já deveria sobrever o método draw para acionar o estado correto, e por final, métodos para ler/modificar o estado atual.A idéia não teve problemas... já para implementar... Eu gastei umas 3 horas para fazer essa classe, não por ser difícil ou trabalhosa, mas por não conhecer direito essa parte do Ruby. Depois de alguns estudos eu vi que o correto seria usar algo do tipo:
module StateMachine def self.included(base) base.extend ClassMethods end module ClassMethods # aqui vem os métodos da classe endend
Até ai tudo bem, mas meu primeiro erro foi conceitual, em não pensar na classe como uma instância, isso me "comeu" algum tempo, quando eu me dei conta disso, então eu sabia que deveria salvar os estados no "objeto da classe" e depois acessa-los a partir das instâncias. Depois de várias e várias tentativas, eu descobri que poderia fazer isso usando variáveis de instância dentro do ClassMethods, e acessando elas atravez de self.class dentro da instância (até agora não sei se foi o caminho mais correto, mas funcionou).detalhe traumatizante: o Shoes não existe mensagens no console padrão, e quando tinha algum erro de execução ele simplesmente deixava a tela branca ou travava o jogo, sem dar nenhuma mensagem de erro... so depois de desenvolver cerca de 70% do projeto eu descobri que apertando "alt+/" o Shoes abre um console onde apareciam as mensagens de erro... agora imagina testar recursos de linguagem que você não conhece sem conseguir ver mensagens de erro (é algo parecido como depurar JavaScript em IE 6)Depois disso a StateMachine ficou ok, e usei ela para implementar os estados no herói. Outro detalhe legal nesse ponto foi o uso de um hook, pois existiam ações do herói que eram comuns a todos os estados, então para resolver isso fiz um alias para o método draw da StateMachine, e redefini o método draw executando as ações padrão e depois chamando o draw do StateMachine (agora chamado de old_draw). Com isso eu já tinha feito várias coisas do jogo, tava indo tudo bem, então eu fui desenvolver usando o "Hackintosh" do meu notebook (tenho windows e leopard no meu HP), então me dei conta de um problema, no Mac o jogo estava rodando mais rápido... Isso significava que o "animate" do Shoes não garantia o frame-rate (oque pra mim até o momento era verdade...). Com isso foi nescessário a criação de calculos sobre tempo, eu fiz isso dentro do loop principal do jogo, calculanto o tempo passado entre o atual momento e a ultima iteração, tive que mudar muita coisa no jogo inteiro para sair passando esse "tempo passado" por entre todas as classes (em verdade... ontem depois de ter o jogo pronto eu pensei seriamente se não deveria ter deixado isso numa variável global ou em um ponto de acesso geral, para não ficar repassando isso por todo mundo, mas agora ja foi, que sabe num próximo refactoring?), e fora isso também foi nescessário mudar os cálculos de velocidade (que já estavam sendo usados nas flechas e nos balões) para trabalharem de acordo com o tempo.Timing ok agora, o jogo no windows rodava com um FPS menor que no Mac, mas a velocidade do jogo era a mesma :)Outro detalhe no herói, eu decidi que nessa versão não seria nescessário clicar com o botão direito do mouse para recarregar a flecha (nunca gostei desse detalhe no jogo original), mas para também não ser uma "metralhadora ambulante" eu coloquei um pequeno delay para ele poder atirar uma nova flecha (a troca entre os estados). Oque estava me incomodando era a implementação desse delay... no momento salvava o tempo ao entrar no estado de waiting, e no estado de waiting verificava o tempo passado a cara iteração até passar o tempo nescessário para então voltar ao estado stand. Me lembrei então do método setTimeout do Javascript, que me seria extremamente conveniente nesse caso, mas que não existe no Ruby. Então foi a hora de criar uma TimerMachine!Como eu já tinha o dado do tempo passado a cada ciclo isso não seria difícil de implementar, e de fato não foi. Quando pronto, era apenas incluir o módulo TimerMachine, e dentro do ciclo do objeto deveria ser chamado o método update_timers(elapsed) para atualizar o tempo dos timers. Para utilizar era apenas fazer "add_timer(time, repeats, &block)", e o bloco seria executado após o tempo (em segundos). O repeats por padrão era 1 (executar apenas 1 vez) e em caso de 0 seria repetido indefinidamente. Essa implementação já estava adequada, mas me liguei que poderia ir mais longe :)Como por padrão o método de update de todos os objetos era draw (de fato essa era a interface para o acesso externo), então eu criei um hook automático no módulo do TimerMachine, que verificava se a classe onde o mesmo foi incluido tinha o método draw definido, e em caso de sua existência, ele mesmo ja criava o hook chamando o update_timers automaticamente (Ruby's Magic!!)Acho que posso dizer que depois desse ponto o desenvolvimento ficou mais fácil, basicamente eu criei a abstração para as fases e separei a parte básica do jogos dos níveis, fui criando as fases 1 a 1, sempre fazendo refactoring quando nescessário até o projeto sair.Para quem quizer ver "mais de perto" os problemas que falei, por favor veja o histórico de código do projeto: http://github.com/wilkerlucio/bow_and_arrow/tree/masterO projeto também foi enviado para o ShoesBox (coleção de aplicações feitas em Shoes): http://the-shoebox.org/apps/139Quem quizer dar uma olhada no gameplay do jogo eu enviei um vídeo para o youtube:Para rodar o jogo é preciso ter o Shoes instalado na maquina, você pode baixar o Shoes em: http://www.shoooes.net/Com o shoes instalado, apenas faça um clone do projeto na sua maquina, e rode com: shoes bow_and_arrow.rbComo ainda me considero iniciante em Ruby, programadores mais experientes podem encontrar várias coisas no código que poderiam ter sido melhor implementadas com Ruby (tenho certeza que existem muitos pontos assim no codigo...), mas mesmo assim acho que pode ser útil para quem quizer dar uma estudada ;)Quem quizer dar mais algum progresso para o jogo (eu ainda não implementei todas as fases do jogo original, como por exemplo a fase do Bull's Eye onde você tem que acertar o meio do alvo) por favor usem o GitHub como várias de vocês já devem conhecer ;)Espero ter conseguido contribuir com algo para a comunidade, qualquer dúvida sobre o jogo podem perguntar pelos comentários ;)
Geek guy that really like to be on the edge of web technologies, like music and guitar (but play really bad), also like to see all kind of non-sense things in internet.