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
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.
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.
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.
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
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.
[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:
Aplicar os princípios YAGNI e KISS para:.
Faça um esforço para o código ser auto-explicativo.
user_count
é um nome melhor do que len
.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.
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.
find_by_ …
Todos os modelos devem ser organizadas usando o seguinte formato:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
OBS: Os comentários listados acima deve existir no arquivo para servir como um lembrete visual do formato.
É 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 |
|
full_name
que concatena first_name
e last_name
status
que
precisa olhar para vários outros modelos.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 |
|
Um processo é definido como uma operação multi-step, que inclui qualquer um dos seguintes itens.
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 |
|
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.
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 |
|
Todas as extensions e monkey patches deve estar em um diretório de extensões em lib.
1 2 3 4 5 6 |
|
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 |
|
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 |
|
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.
Coisas interessantes estão acontecendo no mundo dos frameworks frontend.
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.
]]>sudo
ou usuário root
e um editor de texto que pode ser o Vim. Vamos as configurações.
Para iniciar:
1
|
|
Para parar:
1
|
|
Para reiniciar:
1
|
|
É necessário adicionar seu domínio no arquivo /etc/hosts
, inclua a seguinte linha:
1
|
|
O domínio leandronunes.com é só como exemplo, no lugar pode ser o seu ;-P
Agora temos de fazer algumas configurações no próprio Apache.
Para habilitar o PHP, descomente a linha 117
1
|
|
Configure seu document root na linha 169
1
|
|
e na linha 196
1
|
|
Informe os arquivos default que o Apache irá ler na linha 231
1
|
|
Agora, descomente a linha 477 para incluir o arquivo de hosts virtuais
1
|
|
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 |
|
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
|
|
e acesse pelo browser http://leandronunes.com
Pronto, acredito que apareceu alguma coisa nesse momento. :-P
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 ;)
Vamos criar nossa app Blog.
1 2 |
|
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
|
|
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 |
|
Vamos criar nosso DB e executar as migrações
1 2 3 4 5 6 7 |
|
Observe que a tabela criada é prefixada pelo nome da Engine.
Com o scaffold criamos toda a estrutura para os testes.
Enfim, vamos aos 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
|
|
Ops! deu pau ;(
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 |
|
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 |
|
Agora rode os testes;
1
|
|
Ops! deu pau ;(
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 |
|
Agora rode os testes;
1
|
|
Ops! deu pau ;(
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 |
|
Agora rode os testes;
1
|
|
Ops! deu pau ;(
Vamos observar o arquivo de rotas, config/routes.rb
1 2 3 |
|
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 |
|
Agora rode os testes;
1
|
|
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.
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.
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 |
|
Para exemplificar, vamos validar um model User.
1 2 3 4 5 |
|
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 |
|
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
|
|
É 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.
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.
Como encontrei bastante material disponível na net, achei melhor mensioná-los aqui do que criar um novo tutorial.
A cada novo material descoberto irei adicionando à lista.
]]>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.
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
|
|
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
|
|
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.
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:
JY-MCU | Arduino |
---|---|
RX | PINO 3 |
TX | PINO 2 |
GND | GND |
VCC | 5V |
Agora é só plugar o cabo USB no Arduino e no PC, pronto, tudo conectado
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 |
|
SoftwareSerial mySerial(2, 3);
Serial.begin(9600);
mySerial.begin(9600);
Vá em frente e faça o upload para o Arduino :)
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”
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.
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:
Alternativamente se seu arquivo /etc/apt/sources.list estiver atualizado você pode faze a instalação dos pacotes executando:
1
|
|
ou
1
|
|
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.
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
|
|
Agora instale todas as dependências
1
|
|
Caso queira instalar somentes pacotes instáveis, retire a linha do arquivo source.list antes de executar este último comando.
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 |
|
Agora você já pode executar a IDE dando dois clicks no arquivo /opt/arduino-1.0/arduino ou via linha de comando
1 2 |
|
Caso queira adicionar o Arduino no menu de programas do Debian, leia este post “Adicionar programa no menu do Debian”.
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 |
|
Faça logoff e logon novamente para que as alterações tenham efeito!
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.
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
/opt/scilab-5.3.3/bin/scilab
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.
Acessem o site clicando aqui.. Na página inicial possuímos 5 passos para gerar um arquivo sources.list customizado, vamos seguílos.
Escolhemos de qual país serão nossos repositórios.
Para qual versão do Debian.
Repositórios disponíveis. Temos duas opções para cada um sendo que a que possui Sources Repository armazena código fonte para desenvolvedores.
O títudo é bem intuitivo!
Repositórios adicionados por terceiros. Esta lista é bem maior e varia de acordo com o release escolhido.
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
|
|
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!
1 2 3 |
|
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.
Para executar esta tarefa temos que verificar em nossa maleta de ferramentas se está presente:
Como citado, o Capistrano é um gem e com isso você pode instalar do jeito tradicional mesmo.
É, aquele fácil! Fazemos assim:
1
|
|
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
|
|
e depois executar o bundle install
em seu terminal.
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
|
|
Agora é só executar!
1
|
|
Com isso ganhamos dois arquivos em nosso projeto, são eles:
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!
1 2 3 |
|
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
|
|
com isso voltamos ao release que estava funfando.
1 2 3 4 |
|
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.
1 2 3 4 5 6 |
|
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 |
|
Agora é a hora! Vamos implantar nossa aplicação no servidor, começamos verificando se tudo está OK.
1
|
|
Tudo correndo bem, você será informado. Seguindo, criaremos a estrutura de pastas no servidor.
1
|
|
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.
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 |
|
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 |
|
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.
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 |
|
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:
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.
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.
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
|
|
Agora para encerrar e aguardarmos o próximo post digite:
1
|
|
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.
]]>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
|
|
2) Baixando o binário na versão do nosso sistema.
1 2 3 4 5 |
|
Vou seguir utilizando a verão para 64 bits.
3) Vamos descompactá-lo então
1
|
|
Pronto! Scilab instalado.
Para executá-lo é so digitar
1
|
|
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
|
|
Agora para encerrar e aguardarmos o próximo post digite:
1
|
|
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.
]]> –>
onde podemos executar comandos, instruções, carregar arquivos, configurar o path, iniciar outras janelas, etc…
Vamos conhecer alguns itens do menu que poderão ser úteis e a execução de algumas tarefas. Percorrendo o menu temos:
–>chdir(‘novaPasta’);
no prompt. –>pwd;
no prompt. –>clc;
no prompt –>Ctrl+C;
no prompt –>editor;
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 |
|
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.
Para os comandos não executados corretamente uma mensagem de erro será exibida. Exemplo:
1 2 |
|
Podemos exibir a lista de todos os erros gerados pelo Scilab
1
|
|
_
(underline) ou letra;Constantes especiais começam com %
1 2 3 4 5 6 7 8 9 10 |
|
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!
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
|
|
O comando help aceita um termo para pesquisar como parâmetro
1
|
|
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)
Este post foi uma passada rápida por um dos componentes mais utilizado. ;P
]]>