Este artigo foi escrito como requisito da matéria Seminário de Computação e Informática do curso de Ciência da Computação. Clique aqui para ver o original

1. Introdução

Com a globalização e o aumento ao acesso a banda larga, o mundo vive uma interação em tempo real. Ideias, tendências, necessidades, informações, dentre outros, navegam de continente à continente em uma velocidade jamais imaginada, tendo o software como parte fundamental desse processo. Desenvolver software nesse cenário requer um processo onde uma ideia na mente do cliente vire código funcional e esteja disponível para o usuário final de maneira rápida e confiável. O tempo para efetuar esse processo, denominado como tempo de ciclo, pode determinar o rumo dos negócios junto a concorrência.

Desde 1980, autores como Kent Beck, Martin Fowler, Paul Duvall, Ron Jeffries e Dave Thomas, estudam melhores práticas de desenvolvimento com o objetivo de poder fornecer ao mundo uma alternativa às metodologias pesadas e altamente dirigidas por documentação que estão em uso até hoje [5]. Conforme os dos 12 princípios do Manifesto Ágil [6], o software em funcionamento tem maior valor do que uma documentação abrangente e software funcional é a medida primária do progresso. Software não gera lucro ou valor até que esteja nas mão de seus usuários [4].

Este artigo demonstra boas práticas das metodologias ágil de desenvolvimento para efetuar entrega contínua de software de valor ao cliente, descreve os passos de como detectar erros mais cedo através da prática da integração contínua, permitindo que se desenvolva software coeso mais rapidamente [2]. Demonstra o padrão pipeline de entrega, capaz de permitir automatização desde o desenvolvimento do software até sua entrega final. Conforme Duval [1], o pipeline de entrega é um processo no qual diversos tipos de tarefas são executadas com base no sucesso da tarefa anterior.

Com a automatização dos processos, a entrega de software se torna confiável, previsível, com riscos quantificáveis e bem entendidos, garantindo que quando for preciso fazer alguma modificação, o tempo para realizá-las, colocá-las em produção e em uso, seja o menor possível e, que problemas sejam encontrados cedo o bastante para que sejam fáceis de corrigir.

O pipeline envolve atividades de todos os interessados pela entrega de software, amplia as taxas de implantação e fomenta práticas do movimento DevOps, criando um relacionamento colaborativo entre as equipes de desenvolvimento, qualidade e de operações. Automatizar os processos de forma que todos os envolvidos possam executar tarefas (que até então são manuais) de forma assíncrona, melhora produtividade e a quantidade de entregas de valor dentro de tempo de ciclo, permitindo implantar o sistema para qualquer ambiente instantaneamente, refletindo as mudanças de uma forma eficiente e com baixo custo.

2. Metodologias Ágeis de Desenvolvimento

Os processos das metodologias tradicionais não acompanharam a evolução do tráfico de informações. Conforme Humble e Farley [4], o principal problema enfrentado pelos profissionais da área de desenvolvimento de software é como fazer para transformar uma boa ideia em um sistema e entregá-lo aos usuários o quanto antes.

Em busca de valorizar a importância da interação entre os envolvidos e a entrega de software de valor ao cliente a curto prazo, em 2001, 17 pensadores de desenvolvimento de software se reuniram e concordaram que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Esses princípios foram reunidos no Manifesto Ágil [6].

Kent Beck definiu um conjunto de valores, princípios e práticas que resultou em um trabalho denominado Extreme Programming (XP). Segundo Sato [9], a XP foi uma das primeiras metodologias ágeis que revolucionou a forma como os softwares eram desenvolvidos e, além de se basear em valores para guiar o desenvolvimento, tais como a comunicação clara entre os envolvidos, a simplicidade em fazer o suficiente para atender as necessidades, o feedback para direcionar o produto e a coragem de efetuar mudanças, trazem uma serie de práticas, como a integração contínua (IC), o desenvolvimento guiado por testes e a refatoração. Práticas que quando aplicadas, contribuem para uma entrega de qualidade e eficiente de software.

Ken Schwaber definiu o Scrum, um conjunto de práticas como o objetivo de manter o gerenciamento do projeto visível aos usuários. Uma metodologia ágil para gestão e planejamento de projetos de software, onde o desenvolvimento é dividido em iterações com período de duas a seis semanas, chamadas de Sprints.

Outra metodologia ágil que vem sendo utilizada para dar apoio ao Scrum é o Kanban. Kanban é um termo de origem japonesa e significa literalmente “cartão”, criado por Taiichi Ohno para indicar o andamento do fluxo de produção em empresas de fabricação em série. Tipicamente usa-se um quadro em branco com post-its (Quadro Kanban) para mapear o fluxo de valor das atividades relacionadas ao desenvolvimento de software.

A implementação de metodologias ágil proporciona o desenvolvimento cooperativo, onde baseiam-se mais nas pessoas e suas iterações em vez de grandes esforços de planejamento e processos rígidos. Segundo Pressman [7], em essência, os métodos ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da engenharia de software convencional.

3. Pippeline de Implantação

O processo de levar a funcionalidade da mente do cliente até o usuário final envolve várias etapas, dentre elas, a etapa de desenvolvimento. O desenvolvimento é composto de vários processo além da codificação e podem ser mapeados através da modelagem do mapa de fluxo de valor. O mapa de fluxo de valor possibilita uma visão mais holística, de ponta a ponta do processo de entrega. O objetivo do fluxo de valor é mapear uma solicitação do cliente, do momento em que ela chega até que ela esteja disponível em produção [8].

No desenvolvimento, é necessário juntar o código produzido ao código principal, testar esse código para certificar que não foram adicionados defeitos ao projeto, configurar ambientes para instalação do software e efetuar a implantação nesses ambientes, proporcionando demonstrações, testes exploratório e a disponibilização para o usuário final. O pipeline de implantação modela esse processo, e sua inversão em uma ferramenta de integração contínua, de gerência de versões e a utilização da prática de desenvolvimento guiado por teste como o TDD, é o que permite que uma equipe veja e controle o processo de cada mudança à medida que ela se move em direção a entrega.

Para Humble e Farley [4] o pipeline de implantação é uma manifestação automatizada do processo de levar o software do controle de versão até os usuários. Cada mudança passa de forma consistente no percurso de entrega através da automatização. A automatização torna passos complexos e suscetíveis a erros em passos repetíveis e confiáveis. Fowler [3] acrescenta que o pipeline é para detectar quaisquer mudanças que levem os problemas para produção e para permitir a colaboração entre os envolvidos, possibilitando a visibilidade de todo o fluxo de mudanças juntamente com uma trilha para uma auditoria completa.

4. Entrega de software automatizada

Metodologia ágeis valorizam a entrega de software de valor a curto prazo. Com elas, tem-se um conjunto de boas práticas para o desenvolvimento de software incremental (ou iterativo), onde o sistema começa a ser implantado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. Isso exige que os processos de entrega sejam executados diversas vezes no decorrer de uma Sprint.

Para a definição de um pipeline de entrega, é necessário ter uma visão de todos os processos. O quadro Kanban auxilia nessa tarefa. A Figura 01 demonstra um exemplo do fluxo de entrega. Modelar um pipeline de implantação exige entender seus processos de entrega e balancear o nível de feedback que você quer receber [9]. Projetos anteriores podem servir como base para um novo projeto.

Após a definição das funcionalidades, elas são adicionadas na coluna “Solicitações” e ficam aguardando o planejamento para a próxima Sprint. No planejamento, as solicitações que irão ser desenvolvidas na Sprint, são movidas para a coluna “A Fazer”. Ao iniciar a codificação da funcionalidade, o desenvolvedor atualiza o status da funcionalidade movendo-a para a coluna “Fazendo”, até que seja concluída. Até esse momento, o processo se deu de forma manual.

Figure 01. Movimentação das funcionalidades no quandro Kanban.

A entrada do pipeline inicia-se com o check-in no sistema de controle de versão. Um dos sistemas de controle de versão mais utilizado é o Git. Nessa etapa do processo, uma ferramenta de IC como o Jenkis, o Go, ou até um serviço de integração contínua nas nuvens como o TravisCI, pode ser configurada para monitorar o repositório a cada alteração e mover a funcionalidade nas três etapas seguintes.

De acordo com a tecnologia utilizada pela aplicação, é possível fazer uso de ferramentas como o RSpec e o JUnit para escrever os testes automatizados. A alteração que tenha sido validada com sucesso vira uma nova versão do software (uma versão candidata a ir para produção). Cada estágio de teste avalia a versão candidata de uma perspectiva diferente e a cada teste que ela passa, aumenta a confiança em sua implementação. O objetivo desse processo é eliminar as versões candidatas que não estejam prontas para produção o quanto antes e obter feedback sobre a falha o mais rápido possível [4].

Quando a versão candidata passa pelo estágio de teste de aceitação automatizados, ela se torna algo útil e interessante, não sendo mais prioridade da equipe de desenvolvimento. É preferível que os estágios de implantação para os ambientes de aceitação e produção não executem automaticamente. Os testadores devem ser capazes de ver quais versões candidatas passaram com sucesso e implantar o sistema em um ambientes configurado com um simples apertar de botão. Para a automatização do processo de implantação, ferramentas como a Capistrano e a Mina, podem ser utilizadas.

Com a adoção dessa abordagem, não é permitido efetuar implantação do sistema em produção sem que a versão seja apropriadamente testada. Regressões são evitadas ao se fazer correções, elas passam pelo mesmo processo que quaisquer mudança. Um aumento da automação de processos leva a uma maior eficiência e amplia as taxas de implementação com relação as metodologias tradicionais, conforme a Figura 02.

Para a criação dos ambientes de aceitação e de produção, existem uma série de ferramentas de provisionamento no mercado, delas destacam-se: Ansible, Chef, Puppet e Salt. O processo de provisionamento é um conjunto de passos executáveis que podem ser aplicados em uma imagem inicial do sistema operacional para ter tudo configurado corretamente [10].

Figure 02. Ciclo de entregas de software

5. Conclusão

Este trabalho teve como foco demonstrar conjunto de boas práticas de desenvolvimento de software, testadas e validadas por diversos autores. O objetivo está em permitir efetuar a entrega de software com maior qualidade em um curto período e promover a comunicação com um ciclo de feedback constante entre todos os interessados.

Com isso, muda-se o conceito de “pronto”, fazendo com que uma funcionalidade só esteja pronta quando ela está em produção, fazendo o que tem que fazer e entregando valor aos seus usuários. Em Startups, esse ciclo de entrega contínua é constantemente utilizado, geralmente se tem pouco recurso e é necessário pensar em automatização desde o início. É preciso entregar valor ao usuário para continuar vivo e, esperar a próxima madrugada para subir a nova funcionalidade pode causar um grande impacto nos negócios.

A qualidade da aplicação está relacionada também com o ambiente onde ela está implantada. Deve-se tratar as configurações da mesma forma que o código fonte. Ao seguir a política de que nada é modificado em um ambiente a menos que esteja em um script com versão, automatizado e faça parte de um caminho único para a produção (o pipeline de entrega), é possível determinar melhor a causa raiz dos erros mais rapidamente, acelerando a correção e diminuindo a probabilidade de que pequenos erros se transformem em grandes dores de cabeça no futuro.

6. Referências

[1] DUVAL, Paul. (2012) “Agile DevOps: O Achatamento do Processo de Reliase de Software”

[2] FOWLER, Martin. (2006) “Continuous Integration”

[3] FOWLER, Martin. (2013) “Deployment Pipeline”

[4] HUMBLE, J.; FARLEY, D. (2014) “Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável”. Porto Alegre: Bookman

[5] LOPES, Camilo. (2012) “TDD na Prática. Rio de Janeiro: Ciência Moderna

[6] MANIFESTO ÁGIL. (2001) “Manifesto Para o Desenvolvimento Ágil de Software”

[7] PRESSMAN, R. S. (2006) “Engenharia de Software”. São Paulo: McGraw-Hill

[8] POPPENDIECK, Mary; POPPENDIECK, Tom. (2011) “Implementando o Desenvolvimento Lean de Software: Do Conceito ao Dinheiro”. Porto Alegre: Bookman

[9] SATO, Danilo. (2013) “DevOps na Prática: Entrega de Software Confiável e Automatizada”. São Paulo: Casa do Código

[10] TAVARES, B. (2013)” Puppet e Vagrant: Como provisionar máquinas para seu projeto

[11] TELES, Vinícius M. (2004) “Extreme Programming. São Paulo: Novatec Editora Ltda

Pensando nesses conceitos, encontrei o artigo Rails 3.2 Development Standards Guide do Nathan Hopkins que baseando-se em princípios como o YAGNI e KISS elaborou alguns padrões a seguir quando se desenvolve em Rails, achei bastante interessante e resolvir compartilhar. Vejamos:

Introdução

Aplicar os princípios YAGNI e KISS para:.

• Arquitetura Geral
• Produtos e Recursos da API
• Implementações Específicas

Arquivos

• Deve ser usado espaços e não tabs
• Tabs devem ser iguais a dois espaços
• Finais de linha no padrão Unix (\n)
• Usar UTF-8 encoding

Documentação

Faça um esforço para o código ser auto-explicativo.

• Prefira nomes descritivos em seu código. Por exemplo user_count é um nome melhor do que len.
• Use comentários YARD quando a documentação do código for considerado necessária.
• Evite comentários no método quando ele for muito complexo; refatoração é melhor.

Diretrizes Gerais

Essas diretrizes são baseadas nas regras de programação de Sandi Metz introduzidas no Ruby Rogues. As regras são propositalmente agressiva e são projetadas para dar-lhe uma pausa para que o seu app não corra solto. Espera-se que você vai quebrá-las por razões pragmáticas … muito. Veja a nota na YAGNI e KISS.

• Classes não podem ter mais de 100 linhas de código.
• Métodos não podem ser maior do que cinco linhas de código.
• Os métodos podem ter no máximo 4 parâmetros.
• Controllers só devem instanciar um objeto.
• Views só devem ter acesso a uma variável de instância.
• Nunca diretamente referêncie uma outra classe/módulo de dentro de uma classe. Estas referências devem ser passado por parâmetros.

Seja atencioso ao aplicar estas regras. Se você está lutando contra o quadro (no caso de Scrum, Kaban, etc..), é hora de ser um pouco mais pragmático.

Models

• Nunca use finders dinâmicos. por exemplo find_by_ …
• Seja atencioso sobre o uso de callbacks e observers que podem levar ao acoplamento indesejado.

Todos os modelos devem ser organizadas usando o seguinte formato:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class MyModel < ActiveRecord::Base
  # extends ...................................................................
  # includes ..................................................................
  # security (i.e. attr_accessible) ...........................................
  # relationships .............................................................
  # validations ...............................................................
  # callbacks .................................................................
  # scopes ....................................................................
  # additional config .........................................................
  # class methods .............................................................
  # public instance methods ...................................................
  # protected instance methods ................................................
  # private instance methods ..................................................
end

OBS: Os comentários listados acima deve existir no arquivo para servir como um lembrete visual do formato.

Implementação de Models

É geralmente uma boa idéia isolar diferentes obrigações em módulos separados. Recomendamos o uso de Concerns como descrito neste post do blog.

1
2
3
4
5
6
7
8
9

|-project
  |-app
    |-assets
    |-controllers
    |-helpers
    |-mailers
    |-models
      |-concerns <-----
    |-views

Orientações

• Operações CRUD que estão limitados a um único modelo deve ser implementada no modelo. Por exemplo, um método full_name que concatena first_name e last_name
• Operações CRUD que ultrapassam este modelo devem ser implementadas como uma Concern. Por exemplo, um método status que precisa olhar para vários outros modelos.
• Operações simples não CRUD, devem ser implementadas como uma Concern.
• Importante! Concerns devem ser isolados e independentes. Eles não devem fazer suposições sobre como o receiver é composto em tempo de execução. É inaceitável que uma concern invoque métodos definidos em outras concerns, no entanto, invocando métodos definidos no receiver pretendido é permitido.
• Operações complexas multi-step devem ser implementadas como um processo. Veja abaixo.

Controllers

Controladores devem higienizar parâmetros antes de realizar qualquer outra lógica. A solução preferida é inspirada por esta essência do DHH.

Aqui está um exemplo de higienização de parâmetros.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class ExampleController < ActionController::Base
  def create
    Example.create(sanitized_params)
  end

  def update
    Example.find(params[:id]).update_attributes!(sanitized_params)
  end

  protected

  def sanitized_params
    params[:example].slice(:expected_param, :another_expected_param)
  end
end

Processos

Um processo é definido como uma operação multi-step, que inclui qualquer um dos seguintes itens.

• Uma transação com uma tarefa complexa está sendo realizada.
• Uma chamada feita para um serviço externo.
• Qualquer interação no nível do sistema operacional é executada.
• O envio de e-mails, a exportação de arquivos, etc ..

Em uma tentativa de gerir melhor os processos, nós seguimos vagamente alguns princípios de Domain Driven Development (DDD). Ou seja, nós adicionamos um diretório processes em app para realizar implementações de nossos processos.

1
2
3
4
5
6
7
8
9

|-project
  |-app
    |-assets
    |-controllers
    |-helpers
    |-mailers
    |-models
    |-processes <-----
    |-views

Recomendamos o uso de uma ferramenta como o Hero para ajudar a modelar esses processos.

Importante: Não use model ou controller callbacks para invocar um processo. Em vez disso, invocar processos diretamente do controlador.

Logging

Nós usamos a gem Yell para registro. Aqui está um exemplo de configuração.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# example/config/application.rb
module Example
  class Application < Rails::Application
    log_levels = [:debug, :info, :warn, :error, :fatal]

    # %m : The message to be logged
    # %d : The ISO8601 Timestamp
    # %L : The log level, e.g INFO, WARN
    # %l : The log level (short), e.g. I, W
    # %p : The PID of the process from where the log event occured
    # %t : The Thread ID from where the log event occured
    # %h : The hostname of the machine from where the log event occured
    # %f : The filename from where the log event occured
    # %n : The line number of the file from where the log event occured
    # %F : The filename with path from where the log event occured
    # %M : The method where the log event occured
    log_format = Yell.format( "[%d] [%L] [%h][%p][%t] [%F:%n:%M] %m")

    config.logger = Yell.new do |logger|
      logger.adapter STDOUT, :level => log_levels, :format => log_format
    end
  end
end

Extensions & Monkey Patches

• Seja pensativo sobre monkey patching e procure primeiro soluções alternativas.
• Use um inicializador para carregar extensions e monkey patches.

Todas as extensions e monkey patches deve estar em um diretório de extensões em lib.

1
2
3
4
5
6

|-project
  |-app
  |-config
  |-db
  |-lib
    |-extensions <-----

Use módulos para estender objetos ou adicionar monkey patches. Isto fornece alguma consistência quando você precisa para rastrear bugs.

Aqui está um exemplo:

1
2
3
4
5
6
7

module CowboyString
  def downcase
    self.upcase
  end
end
::String.send(:include, CowboyString)
String.ancestors # => [String, CowboyString, Enumerable, Comparable, Object, Kernel]

Dependências de Gems

Dependências de gems deve ser fixadas antes de implantar no aplicativo de produção. Isto vai garantir a estabilidade da aplicação.

Recomendamos o uso de gerenciadores de dependência. Ao utilizar um gerenciador de dependência, certifique-se de especificar pelo menos as versões maiores ou menores. Aqui está um exemplo.

1
2
3
4
5

# Gemfile
gem 'rails', '3.2.11' # GOOD: exact
gem 'pg', '~>0.9'     # GOOD: tilde
gem 'yell', '>=1.2'   # BAD: unspecific
gem 'nokogiri'        # BAD: unversioned

Bundler’s Gemfile.lock resolve o mesmo problema, mas nós descobrimos que as atualizações indevidas do pacote podem causar problemas. É muito melhor ser explícito no Gemfile para garantir a estabilidade do aplicativo.

This will cause your project to slowy drift away from the bleeding edge. A estratégia deve ser empregada para garantir que o projeto não se desvie muito do comportamento da versão da gem. Por exemplo, atualizar as gems regularmente (a cada 3-4 meses) e ser vigilantes sobre os patches de segurança. Serviços como Gemnasium pode ajudar com isso.

Uma nota sobre Frameworks frontend

Coisas interessantes estão acontecendo no mundo dos frameworks frontend.

• Backbone
• Ember
• Angular
• Knockout
• e muitos outros …

Ser cuidadoso sobre a decisão de usar um framework frontend. Pergunte-se se existe complexidade em manter e se a decisão é certa. Muitas vezes existem soluções melhores e mais simples.

Leia os seguintes artigos antes de decidir. No final, você deve ser capaz de expressar por que sua decisão é a certa.

How Basecamp Next got to be so damn fast without using much client-side UI Rails in Realtime Rails in Realtime, Part 2 Em ambos os casos estar atento a “layout thrashing”, conforme descrito aqui.

Habilitando o Apache

Para iniciar:

1

sudo apachectl start

Para parar:

1

sudo apachectl stop

Para reiniciar:

1

sudo apachectl restart

Adicionando seu domínio

É necessário adicionar seu domínio no arquivo /etc/hosts, inclua a seguinte linha:

1

127.0.0.1 leandronunes.com

O domínio leandronunes.com é só como exemplo, no lugar pode ser o seu ;-P

Arquivo httpd.com

Agora temos de fazer algumas configurações no próprio Apache.

Para habilitar o PHP, descomente a linha 117

1

LoadModule php5_module libexec/apache2/libphp5.so

Configure seu document root na linha 169

1

DocumentRoot "myPath"

e na linha 196

1

<Directory "myPath">

Informe os arquivos default que o Apache irá ler na linha 231

1

DirectoryIndex index.html index.php

Agora, descomente a linha 477 para incluir o arquivo de hosts virtuais

1

Include /private/etc/apache2/extra/httpd-vhosts.conf

Criando um host virtual

Vamos adicionar nosso host no arquivo /private/etc/apache2/extra/httpd-vhosts.conf, ficando dessa seguinte forma:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

NameVirtualHost *:80

<VirtualHost *:80>
  ServerAdmin seuemail@email.com
  DocumentRoot "/Users/leandronunes/"
  ErrorLog "/private/var/log/apache2/error_log"
  CustomLog "/private/var/log/apache2/access_log" common
</VirtualHost>

<VirtualHost *:80>
  ServerAdmin seuemail@email.com
  DocumentRoot "/Users/leandronunes/blog"
  ServerName leandronunes.com
  ServerAlias www.leandronunes.com
  ErrorLog "/Users/leandronunes/blog/log/error_log"
  CustomLog "/Users/leandronunes/blog/log/access_log" common
</VirtualHost>

Testando

Primeiro, dê um restart no Apache, isso já foi mostrado mais acima. Adicione um arquivo index.php na raíz de seu projeto com o conteúdo.

1

<?php phpinfo(); ?>

e acesse pelo browser http://leandronunes.com

Pronto, acredito que apareceu alguma coisa nesse momento. :-P

Conclusão

Dessa forma simulamos os paths reais da aplicação em produção e eliminamos muitas dores de cabeça, principalmente para quem cria blogs em wordpress. ;-/

Como não era somente um bug para corrigir e não achei um post relacionando todos, depois da garimpada na net, resolvi juntar tudo e postar aqui.

Vou fazer um exemplo de execução de testes em uma Engine para exemplificar melhor. Nossa mega Engine vai se chamar Blog (nesse momento estou inspirado), vamos lá então.

Não vou entrar em detalhes sobre Rails Engine, se você não tem noção nenhuma do que seria isso pode começar aqui: http://www.akitaonrails.com/2010/05/10/rails-3-introducao-a-engines#.UIqn32lUMzE - (Sto. @AkitaOnRails).

Futuramente (quando a faculdade deixar) pretendo fazer um exemplo para documentar também, ai coloco o link aqui ;)

Criando uma Rails Engine

Vamos criar nossa app Blog.

1
2

rails plugin new Blog --mountable
cd Blog

Vimos que criamos uma Engine isolada, dessa forma nossas classes serão englobadas no namespace Blog e criadas dentro de pastas nomeadas pelo namespace.

Agora vamos gerar um Scaffold para ter o que testar ;P

1

rails g scaffold Post title body:text

Em uma Engine, temos tarefas rake específicas prefixadas com “app”, as que nos interessam nesse momento são as relativas ao banco de dados

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

rake -T db

rake app:db:create # Create the database from config/database.yml for the current Rails.env (use db:create:all to create all dbs in the config)
rake app:db:drop # Drops the database for the current Rails.env (use db:drop:all to drop all databases)
rake app:db:fixtures:load # Load fixtures into the current environment's database.
rake app:db:migrate # Migrate the database (options: VERSION=x, VERBOSE=false).
rake app:db:migrate:status # Display status of migrations
rake app:db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n).
rake app:db:schema:dump # Create a db/schema.rb file that can be portably used against any DB supported by AR
rake app:db:schema:load # Load a schema.rb file into the database
rake app:db:seed # Load the seed data from db/seeds.rb
rake app:db:setup # Create the database, load the schema, and initialize with the seed data (use db:reset to also drop the db first)
rake app:db:structure:dump # Dump the database structure to db/structure.sql. Specify another file with DB_STRUCTURE=db/my_structure.sql
rake app:db:version # Retrieves the current schema version number
rake db:create # Create the database from config/database.yml for the current Rails.env (use db:create:all to create all dbs in the config)
rake db:drop # Drops the database for the current Rails.env (use db:drop:all to drop all databases)
rake db:fixtures:load # Load fixtures into the current environment's database.
rake db:migrate # Migrate the database (options: VERSION=x, VERBOSE=false).
rake db:migrate:status # Display status of migrations
rake db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n).
rake db:schema:dump # Create a db/schema.rb file that can be portably used against any DB supported by AR
rake db:schema:load # Load a schema.rb file into the database
rake db:seed # Load the seed data from db/seeds.rb
rake db:setup # Create the database, load the schema, and initialize with the seed data (use db:reset to also drop the db first)
rake db:structure:dump # Dump the database structure to an SQL file
rake db:version # Retrieves the current schema version number

Vamos criar nosso DB e executar as migrações

1
2
3
4
5
6
7

rake app:db:create
rake app:db:migrate

== CreateBlogPosts: migrating ================================================
-- create_table(:blog_posts)
-> 0.0015s
== CreateBlogPosts: migrated (0.0016s) =======================================

Observe que a tabela criada é prefixada pelo nome da Engine.

Com o scaffold criamos toda a estrutura para os testes.

Enfim, vamos aos erros.

ERROS

O scaffold já cria os testes funcionais para CRUD, veja o arquivo test/functional/blog/posts_controller_test.rb, dessa forma já podemos executar os testes e ver se está tudo funfando.

1

rake test

Ops! deu pau ;(

1) NoMethodError: undefined method `posts’ for #<Blog::PostsControllerTest:0x007f942c045ed0>

Esse error acontece devido nosso controller tentar carregar as fixtures do post que não foram carregadas/criadas, veja:

1
2
3
4
5
6
7

module Blog
    class PostsControllerTest < ActionController::TestCase
        setup do
            @post = posts(:one)
        end
     end
end

Você precisa explicitar isso para o ActiveSupport::TestCase, abra o arquivo test/test_helper.rb e adicione: ActiveSupport::TestCase.fixtures :all no contexto onde as fixtures são carregadas.

1
2
3
4
5

# Load fixtures from the engine
if ActiveSupport::TestCase.method_defined?(:fixture_path=)
    ActiveSupport::TestCase.fixture_path = File.expand_path("../fixtures", __FILE__)
    ActiveSupport::TestCase.fixtures :all
end

Agora rode os testes;

1

rake test

Ops! deu pau ;(

2) ActiveRecord::StatementInvalid: Could not find table ‘blog_posts’

Esse error é devido as convenções não funcionarem aqui, se você reparou o path das fixtures está setado para raiz da pasta fixtures, então vamos alterar.

1
2
3
4
5

# Load fixtures from the engine
if ActiveSupport::TestCase.method_defined?(:fixture_path=)
    ActiveSupport::TestCase.fixture_path = File.expand_path("../fixtures/blog", __FILE__)
    ActiveSupport::TestCase.fixtures :all
end

Agora rode os testes;

1

rake test

Ops! deu pau ;(

3) ActiveRecord::StatementInvalid: SQLite3::SQLException: no such table: posts: DELETE FROM “posts”

Como convenção, a fixture post tenta utilizar a tabela post, mais como vimos, estamos “namespaceados” pelo nome da engine, então precisamos novamente explicitar para o ActiveSupport::TestCase que o objeto utilizado pela fixture post é Blog::Post, dessa forma o ActiveRecord referencia a tabela correta.

Então adicione mais uma linha no seu test_helper.rb

1
2
3
4
5
6

# Load fixtures from the engine
if ActiveSupport::TestCase.method_defined?(:fixture_path=)
    ActiveSupport::TestCase.fixture_path = File.expand_path("../fixtures/blog", __FILE__)
    ActiveSupport::TestCase.fixtures :all
    ActiveSupport::TestCase.set_fixture_class :posts => Blog::Post
end

Agora rode os testes;

1

rake test

Ops! deu pau ;(

4) ActionController::RoutingError: No route matches {:id=>”980190962”, :post=>{:body=>”MyText”, :title=>”MyString”}, :controller=>”blog/posts”, :action=>”update”}

Vamos observar o arquivo de rotas, config/routes.rb

1
2
3

BlogTest::Engine.routes.draw do
   resources :posts
end

Realmente não temos a rota ‘blog/posts’ criada e não devemos criar, pois quando montamos nossa Engine em uma App mãe, essa rota será criada devido nossa Engine ser isolada (–mountable), então a App precisa diferenciar a requisição ao controller post da Engine da requisição do controller post dela mesma (caso tenha).

Não sei se expliquei bem, mais é só para justificar o porquê de não alterar esse arquivo.

Para resolver isso, vamos disponibilizar diretamente ao controller_test as rotas. Em test/functional/blog/posts_controller_test.rb adicione:

1
2
3
4

setup do
    @post = posts(:one)
    @routes = Engine.routes
end

Agora rode os testes;

1

rake test

Congratulation!

Agora nossa suite de teste esta rodando, já podemos trabalhar. :P

Tentei explicar as correções de forma que quem esteja começando no mundo Rails possa entender o que está acontecendo e não simplesmente copiar e colar o código para correção. Lembrando que também sou um aspirante Rails e estou aberto para correções neste post caso cometi alguma gafe.

Referencias

• https://github.com/rails/rails/issues/4971
• https://github.com/rails/rails/issues/6573

Mais sobre Engine

• http://edgeguides.rubyonrails.org/engines.html

Pensando nisso e aproveitando a estrutura do Rails que já possui a pasta /lib para armazenar nossos códigos customizados, criei um module “ER” para ir colecionando os patterns rotineiros.

Neste post estou mostrando uma solução que encontrei pois ainda desconheço se o Rails possui alguma convenção para essa tarefa.

Vamos ver a ideia!

Na pasta /lib criei um arquivo er.rb que será nosso “repositório de ERs”.

1
2
3
4
5
6
7
8
9
10
11
12

module ER
  # Pattern para validação de e-mail
  EMAIL = /^[^@][\w.-]+@[\w.-]+[.][a-z]{2,4}$/i
  # Pattern para validação de data no padrão 99/99/9999
  DATE = /^(([012][0-9])|(3[01]))\/(0[1-9]|1[012])\/\d{4}$/
  # Pattern para validação de data no padrão 9999-99-99
  DATE_DB = /^\d{4}-(0[1-9]|1[012])-(([012][0-9])|(3[01]))$/
  # Pattern para validação de horas sem os segungos no padrão 99:99
  TIME_H_M = /^(([01]\d)|(2[0-3])):([0-5]\d)$/
  # Pattern para validação de urls, permitido os protocolos http e https
  URL = /^(http|https):\/\/[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(([0-9]{1,5})?\/.*)?$/ix
end

Utilizando

Para exemplificar, vamos validar um model User.

1
2
3
4
5

require 'er'
class User < ActiveRecord::Base
  attr_accessible :email, :full_name
  validates :email, presence:true,  format:{with: ER::EMAIL}
end

Perceberam a chamada do pattern? :P

Para validação em front-end utilizando o atributo pattern do HTML5, podemos reaproveitar nossos patterns, só que precisamos de um passo a mais devido o padrão ser ER crua sem estar contida em “//” (barras).

Criei então um Help para fazer essa tarefa e as View continuarem fazendo apenas seu papel. No arquivo app/helpers/application_helper.rb incluir:

1
2
3
4
5
6
7

def er_for_html(er)
  begin
    ER.const_get(er.upcase.to_sym).source
  rescue NameError => exc
    "A expressao solicitada nao existe"
  end
end

Notem que usei Module#const_get para pegar a referência da constante informado e no fim o Regexp#source que retorna a string original que está envolvida por “//”
Ficando no formulário:

1

<%= f.text_field(:email, :class => :span3, :pattern => er_for_html("email"), :type => :email, :required => true, :title => "E-mail" ) %>

Concluíndo

É isso ai, a intenção é só para mostar uma possibilidade de organizar as coisas, claro que deve possuir outras, dessa forma, aceito sugestões e dicas. :)

Para uma consulta rápida sobre metacaracteres o Aurélio disponibiliza um guia rápido http://piazinho.com.br/download/expressoes-regulares-3-tabelas.pdf.
Para se aprofundar, leia o livro Expressões Regulares - Uma abordagem divertida.

Durante o curso de Circuitos Digitas, os alunos deverão simular todos os circuitos antes de irem ao laboratório, dessa forma, conhecer o funcionamento da ferramenta facilitará bastante.

Download

A versão atual disponível no site não é livre. É demoware e impede versões de demonstração do software, de abrir arquivos criados por outras cópias do demo. No entanto, possui uma versão disponível mais antiga que não tem tais limitações e pode ser baixada aqui.

Tutoriais

Como encontrei bastante material disponível na net, achei melhor mensioná-los aqui do que criar um novo tutorial.

• Intro to Digital Works (inglês)
• Sistemas Digitais - Miguel Tavares
• Tutorial Digital Works - Leandro M. Crescencio
• Digital Works - Anderson Royes Terroso
• Macros no Digital Works - Marcelo Brunoro

A cada novo material descoberto irei adicionando à lista.

Downloads

Se você está interessado também em Computação em Nuvem, conhecer os conceitos básicos sobre virtualização, estou disponibilizando o Arquivo em PDF da pesquisa e abaixo o slide da apresentação.

É claro que existem muitos outros conceitos por trás dessa tecnologia. Espero que este trabalho desperte a curiosidade e insentive suas pesquisas.

Recentemente comprei um módulo de Bluetooth para Arduino, o módulo adquirido foi o “JY-MCU V1.02” Confira aqui!!!, então, fui à luta para fazer funfar no Debian (lembrando que sou novato no Debian e Arduino também) ;) , a briga foi boa!!!
Gostaria de agradecer nosso amigo/professor Marcelo Brunoro por ter mostrado que a placa realmente funciona (utilizando outro OS), antes que eu desistisse heheheh.

Requisitos para o Debian

O Debian 6 é instalado com o pacode de ferramentas gnome-bluetooth para manipular dispositivos Bluetooth utilizado inteface gráfica, porém, esse pacote não possibilita o mapeamento de uma porta serial para o dispositivo, e a comunição com o Arduino se dá via porta serial que, neste caso, utilizaremos como exemplo a biblioteca SoftwareSerial. É preciso então a instalação do pacote Blueman, vamos lá então…

1

sudo apt-get install blueman

Depois da instalação o programa se encontra em System -> Preferences -> Bluetooth Manager

Antes de plugar o módulo, é preciso instalar mais um software, o “CuteCom”, para monitoramento da porta serial, ele será útil para enviar e receber dados da porta destinada ao módulo de Bluetooth.

1

sudo apt-get install cutecom

Para finalizar, é preciso que sua IDE do Arduino seja a 1.0.1 ou superior, caso contrário a biblioteca SoftwareSerial irá bugar, para fazer esse trabalho de atualização é só seguir os passos neste post Instalando Arduino No Debian Squeeze trocando a versão da IDE.

Ligando os componentes

O módulo JY-MCU V1.02 possui 4 pinos (RX, TX, GND E VCC) e já vem com um cabo.

A ligação no Arduino se dá da seguinte forma:

Agora é só plugar o cabo USB no Arduino e no PC, pronto, tudo conectado

Codando nosso exemplo

Na IDE do Arduino existe vário exemplos de códigos para iniciar projetos, vamos utilizar um para testar nossa conexão, vá em File -> Exemples -> SoftwareSerial -> SoftwareSerialExemple

Com algumas modificações o código ficou assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX

void setup()
{
 // Open serial communications and wait for port to open:
  Serial.begin(9600);
   while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }


  Serial.println("Goodnight moon!");

  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
  mySerial.println("Hello, world?");
}

void loop() // run over and over
{
  if (mySerial.available())
    Serial.write(mySerial.read());
  if (Serial.available())
    mySerial.write(Serial.read());
}

O que foi mudado

• Os pinos utilizados SoftwareSerial mySerial(2, 3);
• A taxa de rate na linha Serial.begin(9600);
• A taxa rate do módulomySerial.begin(9600);

Vá em frente e faça o upload para o Arduino :)

Detectando o módulo de Bluetooth no PC

Agora abra o Bluetooth Manager, clique em Search e o módulo será listado como “linvor”, clicando com o botão direito, selecione “add Device”

Novamente como botão direito clique em “Pair”, será pedido o PIN, no nosso caso digite “1234”.
Novamente como botão direito clique em “Dev B”, ufa! chega de botão direito, já estar conectado.

Em baixo na tarja amarela, visualizamos a porta que está sendo utilizada “/dev/rfcomm0”

Monitorando

Abra o CuteCom e no campo “Device:”, clique e digite o caminho da porta, depois é so clicar em “Open device”

Voltamos na IDE do Arduino e abrimos o Serial Monitor, a mensagem “Goodnight moon!” será exibida

No CuteCom será exibido “Hello, world?”

Pronto, agora o que voce digitar no campo “input” do CuteCom será exibido no Serial Monitor e vice-versa, neste caso os dispositivos estão pareados.

Então…

Ufa! O módulo de Bluetooth JY-MCU V1.02 está conectado e conversando com o Arduino.
O módulo de Bluetooth não estando pareado ele aceita uma série de comando como descrito por Byron, vale a pena dar uma conferida, vou deixar para outro post.
É isso ai, espero ter fornecido informações importantes para a continuação dos estudos. Até a proxima!!!!!

O Arduino esta dividido em dois pacotes:

• Arduino: Que é a IDE em Java para desenvolvimento e contém algumas biblioteca.
• Arquino-Core: Ferramenta mínima para interagir via linha de comando sem dependências do Java, usando Makefile Martin Oldfield.

Alternativamente se seu arquivo /etc/apt/sources.list estiver atualizado você pode faze a instalação dos pacotes executando:

1

sudo apt-get install arduino

ou

1

sudo apt-get install arduino-core

Atualize seu arquivo lendo o post Tornando ninja o arquivo sources.list do Debian

Como eu não tinha certeza que a última versão está disponível nos repositórios do Debian e não queria testar,
fiz a instalação baixando o pacote no site oficial http://arduino.cc/en/Main/Software.

Dependencias

Usuários do arduino Uno precisam instalar o pacote brxtx-java versão 2.2pre2-3 ou superior Então edite seu arquivo /etc /apt /sources.list (ou use seu gerenciador de pacotes favorito gui) e adicione:

deb http://ftp.us.debian.org/debian/ squeeze main contrib non-free
Feito isso, execute:

1

sudo apt-get install librxtx-java

Agora instale todas as dependências

1

sudo apt-get install gcc-avr avrdude gcc avr-libc libantlr-java libecj-java libjna-java liboro-java openjdk-6-jdk

Caso queira instalar somentes pacotes instáveis, retire a linha do arquivo source.list antes de executar este último comando.

Fazendo o download

Baixe o binário para linux de 32 bits (ou 64 bits, se for preciso) clicando no link http://arduino.cc/en/Main/Software e extraia o arquivo .tgz para a pasta de sua preferência.
Vou baixar a versão para 64bits na pasta onde irei efetuar a instalação via linha de comando.

1
2
3
4

cd /opt/
sudo wget http://arduino.googlecode.com/files/arduino-1.0-linux64.tgz
sudo tar zxvf arduino-1.0-linux64.tgz
sudo rm arduino-1.0-linux64.tgz

Executando

Agora você já pode executar a IDE dando dois clicks no arquivo /opt/arduino-1.0/arduino ou via linha de comando

1
2

cd arduino-1.0
sh arduino

Caso queira adicionar o Arduino no menu de programas do Debian, leia este post “Adicionar programa no menu do Debian”.

Dando permissão

Você vai notar que não pode selecionar uma porta serial no menu ferramentas. Isto é provavelmente porque você precisa adicionar o usuário para alguns grupos. Você também tem que conectar o Arduino UNO para poder selecionar uma porta serial.

Para um teste rápido, você pode executar arduino como root com: sudo sh arduino. Você deve ser capaz de selecionar uma porta serial agora.

Claro que você não quer estar executando o IDE Arduino como root, então adicionar seu usuário ao grupo tty e dialout assim:

1
2

sudo usermod -a -G tty yourUserName
sudo usermod -a -G dialout yourUserName

Faça logoff e logon novamente para que as alterações tenham efeito!

Então..

Isso é o começo para iniciar os teste com arduino e impressionar os vizinhos.
Para mais detalhes sobre instalação em outros ambiente visite o blog do Renato Aloi, uma ótima referência de estudos também! Mais informações de instação leia o site oficial http://arduino.cc/playground/Linux/Debian

Nesse tutorial vamos instalar o Scilab. Para outros aplicativos somente precisamos trocar o path do executável e do ícone.

Adicionando…

1) Clique com o botão direito na barra de menu e escolha a opção Edit menus

2) Na tela que se abre, ecolha na aba Menus no lado esquerdo onde irá inserir o programa e depois clique em New Item.

3) Agora vamos inserir as informações necessárias

• Type: Application
• Name: Scilab
• Command: /opt/scilab-5.3.3/bin/scilab
• Comment: Qualquer coisa

4) Para trocar o ícone, clique nele e selecione uma imagem em /opt/scilab-5.3.3/share/scilab/icons

Por default o Debian abre na paste de ícones padrão.

5) Pronto! está lá nosso atalho para o Scilab inserido no menu. Acesse e confira pois o Debian não deixou eu dar um print screen com o menu aberto. :P

Quando utilizamos essas ferramentas para instalar pacotes, elas fazem uma consulta no arquivo sources.list que geralmente estar em /etc/apt/ e este arquivo possui uma lista de repositórios onde irá ser efetuada a busca atrás do pacote solicitado.

Vamos então adicionar mais repositórios neste arquivo para que nossos amigos (APT e APTITUDE) achem o que precisamos com maior facilidade.

O Jonhnatha Trigueiro mantem o site Debian Sources List Generator que é uma mão na roda para esta tarefa. Vamos ver como tudo funciona.

Selecionado repositórios

Acessem o site clicando aqui.. Na página inicial possuímos 5 passos para gerar um arquivo sources.list customizado, vamos seguílos.

1 – Select your country

Escolhemos de qual país serão nossos repositórios.

2 – Select your release

Para qual versão do Debian.

3 – Debian Branches

Repositórios disponíveis. Temos duas opções para cada um sendo que a que possui Sources Repository armazena código fonte para desenvolvedores.

4 – Debian Updates

O títudo é bem intuitivo!

5 – 3rd Parties Repos

Repositórios adicionados por terceiros. Esta lista é bem maior e varia de acordo com o release escolhido.

Gerando o arquivo

Depois das escolhas, clique em Generate List Uma lista com todos os repositórios escolhidos é gerada, então abra o arquivo sources.list e substitua seu conteúdo.

1

sudo vim /etc/apt/sources.list

Para os repositórios de terceiro é necessário adicionar a chave publica ssh para que seja efetuada a busca, observe a lista que o comando para esta tarefa já está incluído.

É só copiar e executar no terminal!

Atualizando a distro!

1
2
3

sudo apt-get update
sudo apt-get upgrade
sudo aptitude update

Espero que estas informações sejam úteis, principalmente para os que como eu, estão começando. Dêem uma navegada em Debian Sources List , temos a possibilidade de adicionar repositórios também e contribuir para a comunidade open source.

O Capistrano é uma gem para implantar (deploy) aplicações web. Inicialmente desenvolvida para Rails, tem a finalidade de enviar seu código fonte para um servidor web e permitir o versionamento, ou seja, te dando super poderes para voltar a versão anterior do seu código caso algo dê errado na versão atual. Com um pouquinho de configuração o Capistrano pode ser utilizado para outros framework/linguagem.

Vamos adimitir que você já tenha conhecimento em Sistemas de Controle de Versão (Git, SVN, etc) e que seu ambiente de desenvolvimento esteja funfando com a aplicação.

Hoje foi o meu primeiro contato com o Capistrano, abaixo segue minhas descobertas.

Requisitos

Para executar esta tarefa temos que verificar em nossa maleta de ferramentas se está presente:

• Ruby
• Uma aplicação (no meu caso em Rails)
• Servidor Web com suporte a SSH
• Terminal (bash, sh, etc…)
• Um repositório (No meu caso GIT)

Instalação

Como citado, o Capistrano é um gem e com isso você pode instalar do jeito tradicional mesmo.
É, aquele fácil! Fazemos assim:

1

gem install capistrano

O capistrano adiciona alguns utilitários de linha de comando, o cap e capify iremos conhecer mais abaixo. Também é possível adicionar esta gem no arquivo GemFile do seu projeto.

1

gem 'capistrano'

e depois executar o bundle install em seu terminal.

Iniciando

Agora utilizamos o capify , nosso amigo de linha de comando para fazer com que o Capistrano monitore nossa work area e nos dê opções para configurá-lo. Primeiramente temos que estar na raiz do diretório do nosso projeto.

1

cd /app_rails/

Agora é só executar!

1

capify .

Com isso ganhamos dois arquivos em nosso projeto, são eles:

• capifile –> Possui referências as bibliotecas usadas pelo Capistrano e é responsável em carregá-las.
• config/deploy.rb –> Este possui todas diretrizes para configurar sua implantação, geralmente precisamos editar apenas este.

Confirgurações

O Capistrano precisa de algumas informações para que tudo funcione conforme esperamos e isso fazemos editando o arquivo config/deploy.rb. Estou usando um projeto fictício apenas para exemplo, fique atendo as informações que devem ser substituidas conforme as suas configurações.
Vamos lá então!

A) Informações do projeto

1
2
3

set :application, "app_rails"       # O nome do projeto
set :keep_releases, 5               # Isso guardar os 5 últimos deploys
set :rails_env,     "production"    # O ambiente em que o Rails irá atuar

Toda vez que adicionarmos uma nova funcionalidade ao projeto iremos implementá-la no servidor para que outros tenham acesso e nesse processo, o Capistrano faz o versionamento mantendo seu release anterior. Na linha 2 dizemos que será mantido as 5 últimas atualizações, assim caso algo saia errado neste novo release, podemos usar um comandinho salvador da pátria.

1

cap rollback

com isso voltamos ao release que estava funfando.

B) SCM (source code manager)

1
2
3
4

set :scm, 'git'
set :repository,  "git@github.com:LeandroSNunes/app_rails.git"
set :branch, 'master'
set :deploy_via, :remote_cache

No meu caso uso Git como repositório e informo na linha 1. A linha 4 é informado ao Capistrano que ele não precisa pegar todo repositório toda vez que subirmos um novo release, ele somente irá buscar as modificações.

C) Informações do servidor

1
2
3
4
5
6

default_run_options[:pty] = true
ssh_options[:forward_agent] = true
set :user, "leandro"
set :use_sudo, false
server "leandronunes.com.br", :web, :app, :db, :primary => true
set :deploy_to, "/www/app_rails.leandronunes.com.br/#{application}"

Na linha 2 permitimos que o SSH carregue nossa chave para o servidor para que de lá seja acessado o github.
O usuário informado precisa ter permissões de escrita no servidor.
Alguns comandos por default são executados com sudo, porém se tiver usando um servidor compartilhado e que não tiver acesso de superusuário, informe para não utilizar o sudo como na linha 4.
O Capistrano entende que sua aplicação irá fazer muito sucesso e que seja preciso distribuí-la em vários servidores, no meu caso estou enviando tudo para o mesmo lugar então a linha 5 é uma forma otimizada de informar isso.

Caso precise redirecionar serviços para outros servidores, você pode substituir a linha 5 por:

1
2
3

role :web, 'dominio'
role :app, 'dominio'
role :db,  'dominio', :primary => true

Ops! Executando.

Agora é a hora! Vamos implantar nossa aplicação no servidor, começamos verificando se tudo está OK.

1

cap deploy:check

Tudo correndo bem, você será informado. Seguindo, criaremos a estrutura de pastas no servidor.

1

cap deploy:setup

O que fizemos? Com isso será criado duas pastas (release e shared) e ainda um link simbólico chamado current apontando para o último release. Na pasta releases é criado uma pasta para o deploy efetuado. A pasta shared serve para armazenar arquivos que serão compartilhados entre os releases, como logs, imagens, arquivos de configuração, etc…

Quando trabalhamos com Rails, Git e mais de um desenvolvedor é de prática adicionar nosso arquivo database.yml ao .gitignore, fazendo com que este não seja monitorado e conseguentemente não enviado para o repositório, assim configuramos um único arquivo de banco de dados e colocamos na pasta shared para que todos releases compartilhem a mesma configuração. Mais abaixo vamos adicionar uma tarefa pra fazer isso.

A) Criando tarefas para o Capistrano

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

namespace :deploy do
#   task :start do ; end
#   task :stop do ; end
   task :restart, :roles => :app, :except => { :no_release => true } do
     run "touch #{current_path}/tmp/restart.txt"
   end
   task :database, :roles => :app do
     run "cp #{deploy_to}/#{shared_dir}/database.yml #{release_path}/config/"
   end
   task :permission, :roles => [:web, :db, :app] do
     run "chmod 755 #{release_path}/public -R"
   end
end

namespace :assets do
    task :symlink, :roles => :app do
      assets.create_dir
        run <<-CMD
         rm -rf  #{release_path}/public/images/upload &&
         ln -nfs #{shared_path}/upload #{release_path}/public/images/upload
       CMD
    end
      task :create_dir, :roles => :app do
        run "mkdir -p #{shared_path}/upload"
      end
end

after "deploy:assets:symlink", 'deploy:database'
after "deploy:update_code", 'deploy:permission'

Ao concluir o deploy é necessário reiniciar o servidor para que as novas configurações entrem em vigor, podemos fazer isso simplesmente atualizando o arquivos tmp/restart.txt, percebam na tarefa restart.

Acima adicionamos nosso arquivo database.yml em nossa pasta shared então precisamos adicioná-la dentro do release corrente após o deploy, a tarefa database faz exatamente isso.

Na tarefa permissions setamos as permissões necessárias para pasta public.

Depois, resolvemos o problemas de aquivos de imagens adicionados pelos usuários (podemos supor um cadastro de produtos). As tarefas dentro de assets criam uma pasta upload dentro de shared e um link simbólico em public/imagens apontando para esta pasta.

Por fim vamos executar o tão esperado deploy.

1
2

cap deploy:cold
cap deploy

Rodamos o cap deploy:cold primeiro para colocar os arquivos no servido, depois efetuamos o deploy.
A partir da segunda implantação não é necessário rodar cap deploy:cold
Se precisar migrar seu banco utilize cap deploy:migrations
Alguma coisa fugiu do controle? volte ao release anterior com cap deploy:rollback
Para mais informações cap -T para visualizar todas as tarefas do Capistrano.

Juntando tudo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# Projeto
set :application, "app_rails"       # O nome do projeto
set :keep_releases, 5               # Isso guardar os 5 últimos deploys
set :rails_env,     "production"    # O ambiente em que o Rails irá atuar

# SCM
set :scm, 'git'
set :repository,  "git@github.com:LeandroSNunes/app_rails.git"
set :branch, 'master'
set :deploy_via, :remote_cache

# Servidor
default_run_options[:pty] = true
ssh_options[:forward_agent] = true
set :user, "leandro"
set :use_sudo, false
server "leandronunes.com.br", :web, :app, :db, :primary => true
set :deploy_to, "/www/app_rails.leandronunes.com.br/#{application}"

#Tarefas
namespace :deploy do
#   task :start do ; end
#   task :stop do ; end
   task :restart, :roles => :app, :except => { :no_release => true } do
     run "touch #{current_path}/tmp/restart.txt"
   end
   task :database, :roles => :app do
     run "cp #{deploy_to}/#{shared_dir}/database.yml #{release_path}/config/"
   end
   task :permission, :roles => [:web, :db, :app] do
     run "chmod 755 #{release_path}/public -R"
   end
end

namespace :assets do
    task :symlink, :roles => :app do
      assets.create_dir
        run <<-CMD
         rm -rf  #{release_path}/public/images/upload &&
         ln -nfs #{shared_path}/upload #{release_path}/public/images/upload
       CMD
    end
      task :create_dir, :roles => :app do
        run "mkdir -p #{shared_path}/upload"
      end
end

after "deploy:assets:symlink", 'deploy:database'
after "deploy:update_code", 'deploy:permission'

Então…

Isso foi minha colheita em um dia de deploy aqui na empresa e basicamente quando for efetuar um deploy da sua aplicação você vai estar neste ciclo novamente:

• Adicionar seu último release em um repositório
• Iniciar o monitoramento do Capistrano no diretório de sua aplicação
• Editar o arquivo de configuração do Capistrano
• Fazer um confere das configurações no servidor
• Montar a estrutura de pastas no servidor
• Fazer deploy de sua aplicação
• Configurar o ambiente de produção
• Cruzar os dedos e atualizar seu navegador

Algumas informações tive acesso dando umas googladas e dois blogs que usei de referências foram Unix and Me e Objetiva, acessem para visualizarem o conteúdo completo.

Para mais informações https://github.com/capistrano/capistrano/wiki/_pages

Clique em download para baixar a versão de 32bits ou selecione Other Systems para baixar para a versão de 64bits ou para outro OS.

Instalação

1) Ao terminar o download, execute o arquivo para iniciar a instalação. Na tela que se abre, clique em Run.

2) Agora escolha o idioma que será utilizado durante a instalação.

3) Chegamos no assistente, então, clique em avançar.

Daqui pra frente, segue-se o modo de instalação padrão do windows: avançar, avançar e avançar.
4) Após a instação o Scilab abrirá o seu Console:

Este iremos estudar no próximo post.

Finalizando

Como de costume após uma instação, vamos imprimir a famosa frase “Alô Mundo” e testar se está tudo ok, para isso, no pronpt do console –> digite o seguinte comando:

1

disp("Alô Mundo");

Agora para encerrar e aguardarmos o próximo post digite:

1

exit

Informações Úteis

Para saber como instalar o Scilab em ambiente windows clique aqui. No site do Scilab existe versões de instalação para MacOSX, Linux e Windows ambas de distribuição free, lembrando que seu uso está sobre a licença CeCILL (GPL compatible). Você pode usar, modificar e / ou redistribuir o software sob os termos da licença.

Instalação

Temos versões do Scilab para 32bits e 64bits. A instalação é igual mudando apenas o link para o download. Fazemos assim:

1) Acessando a pasta onde queremos efetuar a instalação, no meu caso /opt

1

cd /opt

2) Baixando o binário na versão do nosso sistema.

1
2
3
4
5

# 32 bits
wget http://www.scilab.org/download/5.3.3/scilab-5.3.3.bin.linux-i686.tar.gz

#64 bits
wget http://www.scilab.org/download/5.3.3/scilab-5.3.3.bin.linux-x86_64.tar.gz

Vou seguir utilizando a verão para 64 bits.

3) Vamos descompactá-lo então

1

tar fzxv scilab-5.3.3.bin.linux-x86_64.tar.gz

Pronto! Scilab instalado.

Utilizando

Para executá-lo é so digitar

1

/opt/scilab-5.3.3/bin/scilab

Para facilitar, podemos adicionar o Scilab no menu do Debian, é só dar uma olhada aqui para saber como.
Com o Scilab em execução, vamos imprimir a famosa frase “Alô Mundo” e testar se está tudo ok, para isso, no pronpt do console do Scilab –> digite o seguinte comando:

1

disp("Alô Mundo");

Agora para encerrar e aguardarmos o próximo post digite:

1

exit

Informações Úteis

Para saber como instalar o Scilab em ambiente windows clique aqui. No site do Scilab existe versões de instalação para MacOSX, Linux e Windows ambas de distribuição free, lembrando que seu uso está sobre a licença CeCILL (GPL compatible). Você pode usar, modificar e / ou redistribuir o software sob os termos da licença.

Conhecendo o console

Vamos conhecer alguns itens do menu que poderão ser úteis e a execução de algumas tarefas. Percorrendo o menu temos:

• File:
• Execute: Executa arquivos de scripts e com instruções de comando
• Open a File: Carrega arquivos de textos criados no ambiente do Scilab (.sce e .sci)
• Change Current Directory: Muda o diretório atual do ambiente para um novo local, comando: –>chdir(‘novaPasta’); no prompt.
• Display Current Directory: Mostra o diretório atual, –>pwd; no prompt.
• Edit
• No menu editar temos as opções padrão que dispensa comentários.
• Preferences
• Clear Console: Limpa o console mais não apaga os dados da memória, podemos executar esta função de outras duas formas: a) Apertando a tecla F2 ou b) digitando –>clc; no prompt
• Control
• Resume: Continua a execução após um pause ou um stop
• Abort: Interromp a execução
• Interrupt: Entra no modo de pause, podemos fazer –>Ctrl+C; no prompt
• Applications
• SciNotes: O editor de textos, podemos chamá-lo via prompt com o comando –>editor;
• ?
• Scilab help: Abre o componente de ajuda.
• Scilab Demonstrations: Exibe a janela de demonstrações de comandos do Scilab

Digitando comandos

Comandos são palavras-chave do Scilab que executam determinadas tarefas e instruções são um conjunto de palavras-chave em ordens digitadas no prompt e finalizadas com .

1
2
3
4
5

y=ode(1.e-8*[1;1;1],0,0:0.005:50,'loren');
# O console permite várias instruções na mesma linha 
# separadas por ponto e vírgula.
a = 10; b = 5; c = 4+3
# O console sempre retorna  o valor do último processamento

O uso de ; (ponto e vírgura) no final de cada instrução é opcional, a diferença é que se usarmos a saída será omitida.

Muitas vezes quando trabalhamos no editor e executamos um script, percebe-se que não aconteceu nada e aparentemente o Scilab está travado, na verdade, o console pode estar esperando uma interação sua para continuar a exibir as informações, isso ocorre devido que o retorno de algumas funções ultrapassam a area visível do console.

então é sempre bom fazer uso do ; (ponto e virgula) no final de cada instrução.
Caso não lembre o nome do comando, você pode utilizar Ctrl+Espaço que aparece uma lista de comando similares.

Conhecendo erros

Para os comandos não executados corretamente uma mensagem de erro será exibida. Exemplo:

1
2

!--error 4
Undefined variable: e

Podemos exibir a lista de todos os erros gerados pelo Scilab

1

help error_table

Considerações sobre variáveis

• O Scilab é case sensitive, isto é, difere maiúscula de minúscula;
• Tem tipagem dinâmica, ou seja, a variável que recebe o tipo de dados numérico poderá posteriormente receber uma string sem problemas;
• Em nomes de variáveis não são permitidos caracteres especiais;
• O nome de uma variável pode ter no máximo 24 caracteres e começar com _ (underline) ou letra;

Considerações sobre constantes

Constantes especiais começam com %

• %f – Valor lógico false
• %t – Valor lógico True
• %eps – Precisão da máquina virtual para números reais
• %pi – 3.1415927…
• %e – Base dos logaritmos naturais
• %inf – Infinito
• %nan – not a number (não é número)
• %i – parte imaginária de númeors complexos

Comandos básicos

1
2
3
4
5
6
7
8
9
10

pwd         #exibe o diretorio atual ,
home        #exibe o diretorio atual
chdir       #muda o diretorio de corrent
mkdir       #cria diretórios
dir         #exibe o nome dos arquivos no diretório corrent
clc         #limpa toda area de trabalho e coloca o cursor no inicio
clc(n)      #limpa n linhas acima da linha atual
clear       #limpa as variáveis da memória
who         #exibe  as constantes especias e as variaveis atuais na memória
whos        #exibe os nomes, os tamanhos e os tipos de dados de todas as variáveis na memória

É isso ai

Conhecemos um pouco do ambiente do Scilab, ficar atento ao “;” pode poupar tempo na execução de scripts.
Para saber mais sobre o console você pode acessar a documentação clicando aqui!

Meios de acesso ao help

Podemos acessar o help de 4 formas:

1) Pelo menu principal:

2) Pela tecla F1

3) Pelo ícone na barra de ferramentas:

4) Pelo comando help executado no prompt

1

help

O comando help aceita um termo para pesquisar como parâmetro

1

help plot2d

CONHECENDO A INTERFACE

Ao abrir a janela de help podemos na coluna da esquerda navegar pela relação de todos os grupos dos elementos, começando com o manual da ferramenta e a classificação por assunto dos itens. A cada grupo, o sistema mostra a relação de itens que o compôem.

Também temos uma aba para buscas.

Do lado direito temos a descrição do item selecionado a esquerda.
Reparem na parte dos exemplos, existe dos botões muito úteis.

O da esquerda executa o código do exemplo direto no console.
O da direitra abre o código no editor (SciNotes)

Concluíndo

Este post foi uma passada rápida por um dos componentes mais utilizado. ;P