Elf Blog

Este post irá descrever de forma mais completa o que a gem gploy faz, acredito que não será um post grande pois a gem não faz tanta coisa assim. Gploy é uma RubyGem que pode ser usada para configurar seu projeto Ruby on Rails e seu servidor para realizar deploy usando git. De forma alguma quero tentar substituir ou algo assim gems muito melhores e eficientes como o Imploy ou o locarails, até mesmo pois essas fazem o trabalho de outra forma.

Resumo

Gploy é uma Gem Ruby simples para configurar e fazer deploy de apps Rails, essa gem foi escrita por min(Edipo), o codigo não esta elegente como deveria, mas estou trabalhando nisso .

O que preciso ter.

Se faz necessário o uso de git para controle de versão de seu projeto Rails, o que acredito que seja praticamente impossível alguem do Rails não esta usando git para versionamento, você também precisa um servidor web(sério?) que rode Ruby on Rails, até agora somente testei na locaweb, pois essa gem faz o uso de uma estrutura de pasta em particular que é encontrada nos servidores da locaweb(mas imagino que outros servidores não são diferentes disso), outra coisa muito importante é que, novamente, até o momento, essa gem faz o uso de um repositório git no mesmo servidor que irá esta hospedada a aplicação, então seu servidor também precisa ter suporte a git. Dito isso, a estrutura de pasta que o gploy usa é a seguinte:

~/repos -> Repositorio git
~/rails_app -> Onde fica seu projeto de produção
~/public_html -> Aqui irá ser criado um link simbólico com a aplicação.

Logo a pasta repos poderá ser substituída por qualquer uma de sua preferencia atras de uma configuração adicional.

Que arquivos são usados

Os comandos gploy -c e gploy -pr geram dois arquivos, config/config.yaml e config/post-receive respectivamente. O primeiro é um arquivo yaml que guarda as informação do seu servidor, nome da app e origin(git).

Acho que não tem muito o que falar sobre esse arquivo ele é auto-explicativo, apenas tome cuidado com a ultima linha(origin) caso você já tenha no seu git um origin configurado use outro nome. Caso você tenha um key ssh configurada para seu servidor na sua maquina e não necessite senha simplesmente deixa essa opção em branco.

O segundo arquivo é o post-receive que é um hook do git, basicamente falando é um arquivo que é executado sempre que o repositório em questão sofre algum tipo de ação, no nosso caso é quando ele recebe um push, esse arquivo se parece com isso:

Esse conteúdo é o que é gerado pelo gploy, também acho que é auto-explicativo o que ele faz, caso você tenha mais tarefas para serem executadas quando você der um novo deploy simplesmente coloque ela nesse arquivo usando o env -i na frente como os demais.

Como a gem Trabalha.

A forma como a gem trabalha é bem simples, o que ela faz é usar um pouco do poder do git ao seu favor, basicamente é:

→ Se projeto não estiver versionado então inicio um repositório git localmente e faça o primeiro commit.
→ Adiciona a url remota configurada no config.yml ao git
→ Faz um git push
→ Faz um clone dentro do servidor da pasta repos para rails_app
→ Adiciona a url “remota” dentro do servidor
→ Cria o link simbólico entre public_html e rails_app
→ Cria diretório tmp na aplicação caso não existir
→ Faz upload do arquivo de hook configurado anteriormente
→ Roda Migrations e Restart Servidor

Isso é o que acontece quando você executa gploy -s. Nesse momento seu projeto esta no ar, se tudo aconteceu como o esperado.

Novos Deploys.

Toda vez que você quiser atualizar seu projeto em produção simplesmente faça gpoy -d, ele irá ir até a branch master e fazer um simples push.

Quando usar essa gem?

Eu não recomendaria usar ela para algum projeto real no qual você possa perder dinheiro se o mesmo não estiver ok no ar. Mas acredito que se você esta desenvolvendo algo mais simples e quiser simplesmente colocar em produção para testes externos, ou até mesmo para colocar em produção sistemas ou Web Sites mais simples e que não precisem ficar 24/7 online acredito que possa vir a ser útil, eu até mesmo uso em algumas coisas que estão online.

Logs

O gploy mantem arquivo de log bem simples, ele simplesmente informa qual comando foi executado e se o mesmo foi feito localmente ou remotamente, você pode encontrar esse arquivo dentro da pasta logs do seu projeto Rails.

Testes

Essa gem não tem cobertura 100% de testes unitários, basicamente o que mantenho até o momento são 22 testes usando Rspec. Obviamente não esta tudo testado com esse numero, mas por hora já me ajuda a não ter muita dor de cabeça na hora de mexer no código do projeto. Abaixo o resultado gerado pelo Rcov para a cobertura de testes dessa gem.

Funcionalidades Futuras.

Ainda não tenho nada certo para novas funcionalidades do gploy, o que pretendo implementar é um forma de poder deixar para o usuário escolher qual pasta quer usar para repositório(ou seja, se quiser mudar o nome de repos para qualquer outro), também uma forma simples de usar seu repositório do github, já que o mesmo suporta hooks.

Conclusão

Esta é uma RubyGem simples mas que pode ser útil em certas situações, caso você tenha gostado, faça um fork do projeto no github e sugira modificações e correções de bugs. E quem tiver acesso a outros servidores que não sejam da locaweb por favor entre em contato para que possamos realizar alguns testes, mas penso que a estrutura seja a mesma praticamente.

Links:
Source Code: http://github.com/edipofederle/gploy/
RubyGems: http://rubygems.org/gems/gploy

Git Documentation: http://git-scm.com/documentation

Hoje estava configurando o Rcov para o gploy, e na hora de gerar as estatisticas de cobertura de testes para o projeto alguns erros aconteciam, basicamente algo como a imagem abaixo:

Após um pouco de investigação o que acontece(eu acho) é que como estou fazendo o uso do FakeFs em meus testes e como o rcov precisa rodar os testes(obviamente) ele da erro ao tentar copiar os arquivos necessarios de template do rcov(reparem o comando cp ali), e como isso é manipulação de arquivos ele falha, ao tentar usar o FakeFs para fazer tal operação, já que o mesmo esta ativo em nossos casos de testes.
Solução

Em seu arquivo de teste onde é feito o uso deo FakeFs provalmente você tenha algo assim.

O que fiz foi usar o before e after para ativar e desativar o fakefs.(agora me veio uma solução mais simples, active no inicio e de deactivate no final do teste, mas não tenho como testar isso agora ).

Abaixo segue a tarefa rake para rodar o rcov, caso esteja usando testunit ao invés de rspec mude o local de arquivos de testes de spec para test.

Bom é isso pessoal, espero que ajude alguem.

Até Mais.

Este não será um post com texto, apenas uma implementaçao simples que fiz de uma pilha usando TDD + Junit com Java. Obviamente não usei a classe Stack do Java. Se alguem tiver sugestões so postar.

Primeiros os Testes de Unidade.

Depois as duas classes.

É isso, espero sugestoes e muitas criticas para refatorar

Motivação

Bom, normalmente eu não escrevo posts no estilo que esse irá(está) ser escrito, minha motivação para escrever tal texto já vem se criando à um certo tempo, mas agora finalmente resolvi escrever mesmo que o que venho à apresentar seja totalmente bobagem para muitos, mas tenho certeza que será correto ou resoavelmente bom para muitos.

Grande parte da motivação para eu escrever esse texto vem de vários lugares, como por exemplo: universidade,…. bom basicamente a universidade encapsula todo o resto, o que inclue professores, alunos e outras n váriaveis. ( ou seriam constantes??)

Bom dito isso vamos começar.

Nota I

Quero deixar bem claro aqui que não sou um conhecedor profundo de NADA, muito menos dos tópicos desse posts. Tudo que for apresentando aqui se refere basiscamente ao que eu penso e idéias das quais simpatizo.

Entregue-me um diagrama e lhe entregarei um Software

A grande maioria das universidade(ou não) ensinam UML, não vamos entrar em questões se isso é bom ou ruim, o fato é que UML não é tudo, você não consegue fazer um software apenas com um(s) diagrama(s) UML, e certamente você não não irá fazer um software seguindo fielmente uma especificação de diagrama de classe por exemplo, é basicamente sobre isso que esse post irá tratar…..

Diagramas, Diagramas, Diagramas

Sejamos sincero com nos mesmo, somente UML não é suficiente, o que muitos pregam por ai parecendo xiitas é que a única coisa que você precisa para fazer um software é uma especificação vinda de algum analista de sistema ou sei la quem vestindo um terno.  Não estou falando aqui que a UML não é boa ou que não resolve alguns problemas, de forma alguma, acho a UML um ótima ferramenta para expor visualmente algumas idéias e fluxos mais complexos de um sistemas,  mas onde eu acredito que realmente reside o bom uso de UML é na comunicação, ou seja fazer realmente o que seja importante, não sair desenhando todas as classes do sistema e em cada classe todos atribuitos e métodos, isso é simplesmente perda de tempo, acredito que o bom uso da UML seja pra coisas realmente importante, algo como “para se ter uma ideia”. Você quer detalhamento? Qual melhor local para isso do que no código?, é nesse que você tem que ser detalhado, cuidadoso e muito especifico, pois é isso que irá fazer seu software funcionar ou não.

Agora vamos ser realistas, na grande parte das vezes os Softwares não passam de um monte de cadastros(CRUDs e mais CRUDs) e não me entra na cabeça fazer meia dúzia de diagramas para fazer especificações sobre como implementar um simples CRUD que em 90% dos casos não tem nada de especial e nem vou entrar no assunto de documentações de casos de uso, ah ia me esquecendo casos de uso de ….. CRUD.

Acredito que grande parte disso tudo venha do modelo de desenvolvimentos tradicional de software o cascata, onde existem níveis bem definidos e funções bem especificadas em cada nível, ou seja:

Finalizada um etapa podemos seguir para a próxima, basicamente aquela história, “toma aí o diagrama peão(programador) codifica essa especificação assim como um pedreiro segue uma planta de um engenheiro, no final você vai ter um software “. Usei a palavra peão para programador pois é assim que se parece, e é assim que muitos pensam. Essa abordagem me sugere dois principal resultados, um, o projeto de software é concluído fora do prazo, do orçamento e em grande parte das funcionalidades não batem com o que o cliente solicitou, o sistema vai para produção e a empresa fica eternamente pagando manutenções para que sejam corrigidos problemas que  deviam ter sido detectados na face de analise ainda( e que passaram despercebidos pelos testes), problemas esses muitas vezes de mal entendimento de requesitos do cliente; segunda, o software não é finalizado.

Então a UML não serve ?

Sou suspeito para falar isso, sou um fã de metodologias agéis, como eXtreme Programming por exemplo, eu realmente nunca ouvi falar de uma equipe XP usar diagramas de UML para nada, e segundo a literatura existente isso é pouco feito, segue um trecho do artigo “O Design Está Morto?” de Martin Fowler, que recomendo a todos ler.

“Há diversos pontos de incompatibilidade. É fato que XP possui muito pouca ênfase em diagramas. Embora a posição oficial é a de “usá-los quando eles forem úteis”, há uma mensagem implícita que diz que “verdadeiros adeptos de XP não fazem diagramas”. Esta conclusão é reforçada pelo fato de que pessoas como Kent não se sentem confortáveis com diagramas; na verdade eu nunca vi Kent voluntariamente desenhar um diagrama de software em uma notação determinada.”

E nem é pelo fato de não se usar de diagramas que não teremos um bom software, existe outras n técnicas para tal função que acredito ser muito mais interessante e mais proxima do cliente também, como os cartões CRC:

Acho isso muito elegante e eficiente, recomendo ler http://www.agilemodeling.com/artifacts/crcModel.htm que foi de onde tirei essas duas imagens acima.

Não estou falando aqui que deve-se substituir UML por cartões CRC, o que eu falo é que existe algumas situações onde cada um tem seu maior valor e praticidade, ou um junção de ambos como o Martin Fowler diz que usa, na realidade o que o que realmente importa é saber medir as coisas e saber usar a coisa mais adequada em cada situação e não tentar forçar o uso de uma única ferramenta para resolver todos os problemas e esperar grandes resultados.

O que realmente queria dizer nesse post todo é que muitas vezes principalmente em universidade e certos professores acabam achando que aquilo que é passado na aula é tudo o que se tem para resolver problemas, e só aquilo que deve ser usado e pronto, me de ótimos resultados com isso, quando as coisas são muito mais complicadas… ou posso simplesmente esta falando bobagem….. quem sabe.

Olá pessoas, finlamente estamos devolta para falar novamente de Ruby, dessa vez iremos dar uma olhada básica na criação de classes em Ruby.

Iremos fazer nossos exemplo em cima de uam classe chamada Matemática.

Definição de uma Classe

Simples como só o Ruby poderia ser , usamos a palavra chave do Ruby class para criar uma nova constante para fazer referência a nossa classe, nome de classe e constante ambas são as mesma, é por isso que devemos declarar classes com letra Maiúscula.

A palavra chave self

Podemos usar a palavra self para nos referir a própria classe, essa palavra vem dentro da definição da classe, por exemplo.

Criando uma Instância de Matematica

Até o momento ainda não colocamos nada de atributos ou métodos em nossa classe, mas isso não impede que agente crie uma instância dessa classe, para isso usamos a palavra-chave new.

Todo e qualquer objeto de classe tem um método new.

O que temos de importante para fazer com um objeto que não tem nenhum método ? Bem podemos pedir para ele qual é seu tipo, para tal operação:

Inicializar a Nossa Classe

Construtores é a palavra se você vem ou é do mundo Java, queremos inicializar nossa classe com dois argumentos x e y. Mas como você não está no Java aqui isso se chama initialize.

Simples heim, mas o que aconteceu nessas três novas linhas? Primeiramente usamos a palavra-chave def para definir nossa método initialize, vale dizer aqui que esse def define um método de instância da classe, quando vamos chamar um método de instância da classe o valor de self é uma instância da classe na qual o método foi declarado.

Bom, quando definimos uma initialize para uma classe, temos que saber que quando usamos o método new para criar um nova instância da nossa classe, ele chama automaticamente o método initialize para aquela instância, então todo e qualquer argumento que você passar para new irão ser passados para o initialize, então como nosso initialize está esperando dois argumentos devemos agora passar esses argumentos no momento em que criamos nosso objeto Matematica.

Pronto agora sim. Algo bacana que acontece internamente no Ruby é que o método intialize é PRIVATIZADO automaticamente. Ou seja um objeto por ele mesmo pode chamar esse método para fazer a inicialização de seus argumentos, mas você não pode fazer uma chamada explicita para por exemplo mudar os valores de inicialização.

O que temos dentro do método initialize é dois valores que passamos nas variáveis @x, e @y, em Ruby o que começar com @ é uma variável de instância, então podemos ter n instância de Matematica que cada um delas terá seus próprios valores para x e y.

Uma consideração sobre variáveis de instância é que elas somente podem ser acessadas pelos métodos de instância do Objeto. Ou seja se houver algum código que não esteja dentro de um método de instância não poderá ler ou modificar seu valor. Na verdade existe uma maneira de fazer isso usando algumas técnicas de reflexão(reflections)

Certamente se você esta pensando em Java ou outras linguagens estáticas ficou pensando em fazer a declaração das variáveis, se você fizesse isso podia até pensar estar fazendo a coisa certa mas não está, no Ruby as variáveis de instância são resolvidas todas em contexto self, no momento em que é invocado o método initialize o self mentém uma instânia de nossa classe(Matematica), ou seja, o código fora do initialize faz referência à definição da classe e não a INSTÂNCIA da classe, então quando a leitura das variáveis que você declara fora(como no Java, por exemplo) são totalmente diferentes daquelas dentro do initialize.

O quase sempre presente método to_s.

Isso é praticamente default em todas as classes que você fizer, isso para poder retornar uma representação da sequência do objeto.

Bem melhor que antes não:

Saídas

com to_s: (3,4)

sem to_s: #

Bom essa foi a primeira parte, logo logo eu posto mais, obrigado por ler