Quem tem medo de JavaScript? Parte 1: É preciso achar o undefined.

Image

Ao longo do tempo em que trabalhamos com desenvolvimento, temos nos deparado com um denominador comum em quase todos projetos: undefined is not a function. Geralmente, JavaScript desperta um enorme pavor em qualquer desenvolvedor, principalmente quando tem que se resolver um problema de maneira rápida num emaranhado de código, que mais parece noruêgues arcaico. O passo inicial para um desenvolvimento mais fácil em JavaScript é uma boa legibilidade de código, mas como fazer isso? Nosso post de hoje tem o objetivo de trazer algumas dicas e exemplos para facilitar a vida de quem enfrenta esse tipo de problema.

Confira abaixo:

Nomenclatura:

- Use nomes sucintos (não abreviados) e que expliquem claramente o objetivo da variável/função.

Opte por uma nomenclatura mais descritiva e de fácil identificação. Abreviações geralmente confundem em códigos que costumam ser mais extensos como os de JavaScript.

- Variáveis em lista devem ser no plural ou devem descrever que são uma lista.

Se colocarmos no singular isto não nos dará uma ideia de lista, e ao percorrer um código modularizado precisamos que ele seja óbvio e evidente pois nem sempre a implementação estará no mesmo arquivo.

Funções:

- Funções geralmente devem conter um verbo.

LEMBRE-SE: Se o nome da função está muito grande provavelmente ela está fazendo demais. SRP (single responsibility principle). “Uma classe deve ter um e somente um motivo para mudar”, transpondo esse princípio para a realidade do JavaScript, significa que uma função deve ter somente uma responsabilidade. Imagine uma função chamada por um botão de registro de usuário como abaixo.

Agora, observe este outro caso:

Esta função evidentemente viola o SRP, pois ela tem três responsabilidades que são: validar, registrar o usuário e efetuar o login. O mais correto seria separar em três funções e encapsular as mesmas  - As funções nunca devem receber mais de dois parâmetros. Caso seja necessário mais dados, devemos encapsular ela em um objeto, como na imagem abaixo.

Para facilitar a legibilidade devemos sempre agrupar as propriedades em objetos comuns. A função acima poderia muito bem receber simplesmente um objeto User com todas as informações necessárias dentro.

Módulos:

Uma das facilidades para desenvolvimento em JavaScript é a divisão por módulos. Dividindo o código por módulos podemos criar objetos e reutilizarmos eles conforme necessário, aumentando assim o reuso do código e tornando o código mais limpo e conciso. Veja o código abaixo. Ele não ficaria mais legível e reaproveitável separado?

Para fazer a modularização do JavaScript existem diversas maneiras e ferramentas. amos conhecer algumas:

UMD (Universal module definition): O UMD é compatível com AMD e com a definição de variável global, permitindo uma compatibilidade maior sem dependências. Particularmente achamos essa maneira uma das piores em termos de organização de código. Ele fica muito ilegível e pouco claro ao contrário do código gerado com RequireJs/CommonJs.

AMD (Asyncronous module definition): O AMD consiste em definir módulos onde tanto o módulo quanto a dependência podem ser carregados assincronamente quando desejado. A sua modularização é voltada muito mais ao browser e uma das suas implementações mais usadas é o RequireJS. Hoje em dia é usado em projetos como o Dojo, jQuery, Firebug.

Common JS: O sucessor do RequireJS é o CommonJS, um sistema de módulos que procurou resolver todos os problemas que os módulos AMD tiveram e tornar a criação e referência modular muito mais fácil. O CommonJS foi criado inicialmente para ser usado apenas em código JavaScript do backend, mas em 2011 o mesmo foi portado para frontend com o nome de Browserify.

ECMAScript 6: Para a alegria de todos, em 2014 foi definida a sintaxe de como o ECMAScript 6 trabalhará com módulos. Particularmente, achamos a maneira mais sucinta e clara para se usar. Contudo, os browsers ainda não dão suporte a modularização e ES6. Uma das formas de se utilizar essa nomenclatura é através do transpilador Babel que torna o código ES6 compatível com ES5, a versão mais atual e estável do ECMAScript e que os principais navegadores suportam.

JSLint: JSLint é uma ferramenta para melhor qualidade de código em JavaScript. Ele verifica o código e dispara erros conforme suas verificações com a localização aproximada do mesmo. Ele ainda permite que as configurações possam ser personalizadas de acordo com a necessidade do usuário, por exemplo, suprimindo exceções e criando filtros para arquivos de terceiros em que não existe a necessidade de verificar por problemas.

Ferramentas:

Existem diversas ferramentas que podem aperfeiçoar o desenvolvimento de JavaScript, tais como transpiladores como o Babel, CoffeScript e TypeScript, Dart, que melhoram muito a simplicidade do código. Tem também frameworks focados primariamente para data binding como KnockoutJS e frameworks MVVM, que tendem a ser mais completos mas em compensação contam uma curva de aprendizagem maior, como AngularJS.

Existem ainda outras ferramentas de desenvolvimento que nos auxiliam no que chamamos de build frontend, para minificar arquivos, comprimir imagens e muito mais. Alguns exemplos são as task-runners como o Grunt, o Gulp e o Broccoli. Acompanhe o blog pois em breve continuaremos esse assunto, analisando as principais ferramentas que podemos usar junto com o JavaScript para tornar o desenvolvimento mais fácil e prático.

Escrito por Andrey Donelli e Fagner Carvalho

Retrospectiva Ágil: O Test-Driven Drawing

No dia 19 de fevereiro promovemos dentro da Mobiltec o Let’s Talk Learning Agile with Games! Pela primeira vez um Let’s Talk, que ocorre toda terceira quinta-feira do mês, contou com uma dinâmica Ágil.

O momento foi muito oportuno: Além de praticar com as equipes conceitos fundamentais dos Métodos Ágeis, de forma muito divertida, aproveitamos a oportunidade para integrar ao time o Riadh Mezzi, nosso intercambista tunisiano que veio passar uma temporada na Mobiltec.

Como desafio adicional, o Let’s Talk foi todo conduzido em inglês, para alívio do Riadh. :)

Desafio: Test-Driven Drawing

A dinâmica utilizada foi o Test-Driven Drawing, relatado no site TastyCupcakes.org, que tem como principal foco a relação entre Product Owner (PO) e Desenvolvedores dentro do ciclo do SCRUM.

A prática realizada mostra exatamente o que se vê nos casos reais de aplicação do SCRUM: Primeiro, por mais precisa que seja a descrição de escopo do PO, os requisitos estão sujeitos a diferentes interpretações por parte do time. Em segundo lugar, a elaboração de testes traz um conjunto de restrições adicionais que guiam o time de desenvolvimento a chegar a melhores resultados.

Levamos aproximadamente 40 minutos para execução da dinâmica, que é organizada em duas iterações.

Equipe trabalhando durante as iterações da dinâmica.

Análise dos resultados!

 

Primeira iteração

A equipe foi toda organizada em duplas (um PO e um desenvolvedor) e um trio (um PO e dois desenvolvedores). PO e desenvolvedor se sentam de costas um para o outro.

O PO ganha uma folha com um conjunto de figuras geométricas, enquanto que o desenvolvedor ganha uma folha branca para desenhar. Na primeira iteração, o PO descreve verbalmente o desenho para o desenvolvedor sem que este possa vê-lo. A partir das instruções, o desenvolvedor deve reproduzir o desenho em seu papel. Esta etapa dura de 3 a 5 minutos.

Um dos resultado da primeira iteração.

 

Segunda iteração

No início da segunda iteração, o PO recebe uma folha em branco onde pode escrever cerca de 5 casos de teste para a segunda iteração.

Nesta etapa cada PO trabalha com um novo desenvolvedor. A dinâmica é similar à da primeira iteração, mas agora o desenvolvedor recebe os casos de teste para guiá-lo enquanto realiza o novo desenho.

Com o apoio dos testes, a segunda iteração ocorrem com melhorias no processo.

Um dos resultados da segunda iteração.

 

Momento Retrospectiva

Ao término da dinâmica o grupo realizou um grande momento de retrospectiva, avaliando as situações ocorridas e comparando-as com situações reais.

Avaliamos a dinâmica do ponto de vista das expectativas do PO e do desenvolvedor. O que POs entendiam que os desenvolvedores poderiam ter feito diferente, para chegar a melhores resultados? E o que os desenvolvedores acham que os POs poderiam ter feito diferente? São questões extremamente pertinentes que nos levam a diversas reflexões, tais como:

  • POs vêem como necessário que os desenvolvedores devem buscar maior compreensão da atividade antes de sair executando.
  • Em contrapartida, desenvolvedores entendem que POs precisam explicar melhor as atividades.
  • Importante que os desenvolvedores prestem atenção constante aos casos de teste.
  • Mas desenvolvedores também questionam a qualidade dos casos de teste.

E quem vê estes problemas ocorrerem na prática, nos seus projetos também? Todos são unânimes em concordar, e acredito que você que nos lê também concorde com estas conclusões.

Indo além, percebemos que todos apontam OS MESMOS PROBLEMAS. O que muda é apenas o ponto de vista. A perspectiva de cada função. No fundo são problemas de comunicação, e ambas partes precisam buscar melhores práticas para aperfeiçoar esta comunicação. A geração de Histórias de Usuário, por exemplo, é uma prática que vale muito a pena (Um ótimo ponto de partida é http://historiasdeusuario.com.br).

A aplicação da técnica foi muito satisfatória! Prova disso é que o debate foi bastante profundo, e o pessoal saiu com várias pautas para as retrospectivas de seus times.

E você, o que achou desta técnica? Deixe seus comentários :)

Escrito por Eduardo Klein

Automatizando o deploy de aplicações ASP.NET com Octopus Deploy

Em um post anterior mostramos como criar e configurar um ambiente de integração contínua com Jenkis e Git. Neste tutorial faremos o deploy de nossa aplicação ASP.NET e, para isso, utilizaremos a ferramenta de automatização de deploy Octopus Deploy.

O Octopus Deploy permite a realização do deploy de aplicações ASP.NET (Web Forms, MVC e Web API) automatizando uma série de procedimentos durante este processo:

  • Atualização de arquivos de configuração: faz as devidas transformações nos arquivos .config de acordo com o ambiente (homologação, produção, etc).
  • Atualização do IIS: Automaticamente atualiza o website ou application pool do IIS.
  • Execução de scripts powershell: Possibilita que sejam incluídos scripts powershell para execução em diversos estágios do deploy (ex: um script para reinicialização de um serviço windows logo após o deploy). Não utilizaremos nenhum script post deploy neste exemplo.

Antes de começar a configuração do Octopus, vamos rever todo o fluxo que estamos criando:

Instalando o Octopus Server e Configurando o Nuget Feed

O Octopus consiste em dois módulos principais: Octopus Server e Octopus Tentacle. O Octopus Server é utilizado para o gerenciamento de todos os projetos e é onde iremos definir o Nuget Feed (diretório que contém os pacotes Nuget que devem ser descarregados no servidor-alvo). Os arquivos para instalação podem ser obtidos na página de downloads do Octopus.

  1. Instale o Octopus Server: Requer Windows Server 2008 ou superior. A instalação é intuitiva e nela você irá definir a URL para acesso ao painel administrativo e o usuário administrador. Você precisará do thumbprint gerado para identificar esta instância do Octopus Server no Octopus Tentacle (Configuration > Certifications).
  1. Configure o Nuget Feed: O Nuget Feed indica ao Octopus Server qual é o diretório do seu repositório de pacotes Nuget (que contém o conteúdo a ser descarregado no servidor web). No painel administrativo do Octopus Server, clique no menu superior direito em Configuration e, no menu esquerdo, em Nuget. Em seguida, clique em Add Nuget Feed e informe o caminho do diretório (ex: C:\Octopus\NugFeed\MeuProjeto).

Configurando Environment, Machine e Role

Antes de começar a configuração, precisamos conhecer estes três conceitos relacionados à forma como o Octopus Server gerencia os seus projetos.

  • Environment: O Octopus permite a criação de diversos environments – um para cada projeto a ser feito deploy. Cada um destes environments contém um conjunto de máquinas nas quais o deploy deverá ser feito. Você poderia ter em um mesmo environment duas máquinas – um servidor de homologação e um servidor de produção – por exemplo.
  • Machine: Cada máquina do ambiente deverá ter uma instância do Octopus Tentacle rodando (veremos mais adiante neste tutorial).
  • Role: Suponha que um ambiente possua duas máquinas. Como saber qual delas é a que será utilizada para homologação e qual será a de produção? Esta é a tarefa dos roles.

Vamos então criar um novo environment. Mais adiante iremos adicionar a máquina-alvo e configurar seu role.

  1. Adicionar um environment: Ainda no painel de controle do Octopus Server , clique em Environments, Add Environment e informe o nome e a descrição do novo ambiente.

Instalando o Octopus Tentacle

O Octopus Tentacle é um serviço windows que deve ser instalado no servidor onde você pretende fazer o deploy. Este serviço deve estar permanentemente sendo executado pois é ele quem recebe os comandos do Octopus Server e faz o deploy propriamente (assim como as demais tarefas como atualização do IIS e execução de scripts).

  1. Instale o Octopus Tentacle: No servidor onde você pretende fazer o deploy execute o instalador do tentáculo. Novamente, o instalador é bem simples e intuitivo. Assim que o processo for concluído será aberto o Tentacle Manager.

  1. Configurar o Octopus Tentacle: Assim que você clicar em Get Started será necessário completar uma série de etapas. Na figura abaixo vemos a etapa Listening Tentacle onde você pode indicar em qual porta o Octopus Tentacle espera receber as instruções do Octopus Server. É nesta etapa que deve ser informado o Octopus Server Thumbprint que anotamos anteriormente. Desta forma o Octopus Tentacle poderá identificar o Octopus Server quando receber instruções. Depois disso, basta finalizar a instalação.

  1. Anotar o thumbprint do tentáculo: Após a instalação terminar você verá a tela de administração. Nela você deve localizar e anotar o thumbprint gerado.

Adicionar uma nova máquina ao ambiente

Agora que o tentáculo está instalado e rodando no servidor temos de voltar ao gerenciador de environments do Octopus Server e adicionar uma nova máquina ao environment Exemplo.

  1. Adionar uma máquina ao ambiente: No painel de controle, clique em Environments e então em Add Machine para abrir a tela abaixo. Informe um nome para o servidor, a URL (a porta deve ser a mesma que foi configurada no tentáculo). Informe o thumbprint que anotamos durante a instalação do tentáculo. Observe que criamos um role chamado producao para esta máquina (basta escrever o nome do role e pressionar Enter).
  1. Check Health: Para verificar se o Octopus Server consegue se comunicar corretamente com o Octopus Tentacle, clique (no topo da tela de environments) no botão check health. Caso ocorra algum erro verifique as permissões de firewall do serviço Octopus Tentacle e se ambos os thumbprints foram informados corretamente.

Criar um novo projeto no Octopus Server

Vamos revisar o que temos até agora:

  • O Octopus Server está instalado e com o repositório de pacotes configurado (Nuget Feed).
  • O Octopus Tentacle está instalado no servidor-alvo e está se comunicando corretamente com o Octopus Server.
  • No Octopus Server criamos um environment que contém uma máquina. Esta máquina foi configurada com o thumbprint gerado no seu Octopus Tentacle.
Criaremos agora, no Octopus Server, um novo projeto. Um projeto consiste nos seguintes componentes:

  • Steps: O processo de deploy pode ser subdivido em diversas etapas. Você pode restringir um step para que atue em um determinado environment e ainda criar dependências entre os steps.
  • Variables: São configurações específicas do projeto e da máquina onde pretendemos fazer o deploy (ex: o nome do website no servidor IIS-alvo). Mais informações sobre variáveis podem ser obtidas aqui.
  • Releases: Uma release é o resultado da execução de todos os steps do projeto. O histórico de releases pode ser visto na aba Overview do projeto o que facilita muito quando se precisa retornar rapidamente para um release anterior.
  1. Criar um novo project group: Na tela administrativa do Octopus Server, clique em Projects e em seguida em Add project group. Não esqueça de informar o Environment criado anteriormente.

  1. Criar um novo projeto: Com o project group criado, clique em Add Project para visualizar a tela de criação de um novo projeto. Informe o nome e a descrição e clique em Add.
  1. Criar um novo step: Com o projeto criado, clique nele e em seguida na aba Steps. Clique em Add Step para adicionar. Na lista dropdown da tela seguinte, selecione a opção Deploy a Nuget Package.
  1. Configurar o step: Na tela de configuração informe o nome do step, o repositório de pacotes Nuget (criado anteriormente) e o nome do pacote que o Octopus deve utilizar (ele ainda não existe e será criado posteriormente – neste exemplo, chamei de MinhaAppMVC). Veja também que em Deploy to roles especificamos a role da máquina onde instalamos o Octopus Tentacle. As demais configurações não devem ser modificadas.
  1. Configurar as variáveis do projeto: Nosso projeto precisa apenas de uma variável chamada OctopusWebSiteName. Ela serve para informar ao Octopus qual o nome do web site no servidor IIS que desejamos que este projeto esteja vinculado. No exemplo o website foi criado com o nome Minha App. Veja que especificamos os campos Environment, Role, Machine e Step conforme o que foi criado anteriormente.

De volta ao Jenkins – criar pacote Nuget e executar o deploy

O Octopus Server está pronto para criar novas releases para o nosso projeto. Iremos agora criar um novo job no Jenkins e utilizar um script MSBuild para criar um novo pacote Nuget contendo o resultado do build feito anteriormente (ver este post para criar o job no Jenkins). Em seguida, o script fará uma chamada à API do Octopus para criar a release.

Antes de continuar, será necessário:

  • Fazer o download o Nuget.exe aqui. Ele será utilizado para compactar seu projeto em um .nupkg.
  • Criar um arquivo nuspec no diretório que pretende compactar (raiz da solução). O arquivo Nuspec serve apenas para conter metadados sobre o pacote (versão, autor, etc). Este arquivo deve ter o mesmo nome que foi informado no campo Nuget Package do step do projeto – no nosso caso, MinhaAppMVC.nuspec. Você pode encontrar exemplos de arquivos Nuspec aqui.
  • Obter a extensão do MSBuild MSBuildTasks aqui. Esta extensão permitirá que o MSBuild atualize o arquivo Nuspec a cada novo empacotamento.
  1. Criar novo job no Jenkins: Crie um novo job chamado Meu Projeto – Empacotamento e Deploy. Especifique dois scripts na seção Build – empacotamento.build e deploy.build.
  1. Criar novo script MSBuild chamado empacotamento.build: Este script cria um pacote Nuget (extensão .nupkg) do projeto previamente compilado. Observe as seguintes variáveis no script:
  • ProjectNuspec: caminho para o arquivo Nuspec da solução.
  • OctopusNugetFeed: o pacote Nuget resultante deve ficar no Nuget feed configurado no Octopus anteriormente.
  • Nuget: O caminho do executável Nuget.exe.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="Start">
  <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>

  <PropertyGroup>
    <ProjectNuspec>C:\MinhaApp\MinhaAppMVC.nuspec</ProjectNuspec>
    <OctopusNugetFeed>C:\OctopusNugFeed\MeuProjeto</OctopusNugetFeed>
    <Nuget>C:\Mobiltracker\Nuget\NuGet.exe</Nuget>
  </PropertyGroup>

  <!-- Target principal - executa demais targets na ordem correta -->
  <Target Name="Start">
    <CallTarget Targets="Init"/>
    <CallTarget Targets="Pack"/>
  </Target>

  <!-- Cria o repositorio de pacotes caso ainda nao exista -->
  <Target Name="Init">
    <MakeDir Directories="$(OctopusNugetFeed)" />
  </Target>

  <!-- Atualiza a versao no nuspec, compacta o projeto e envia para a pasta destino -->
  <Target Name="Pack">
    <XmlUpdate
		  Namespace="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"
		  XmlFileName="$(ProjectNuspec)"
		  XPath="/package/metadata/version"
		  Value="$(VersionNumber)" />

    <Exec Command="$(Nuget) pack $(ProjectNuspec) -OutputDirectory $(OctopusNugetFeed)" />
  </Target>
</Project>

Veja que atualizamos o arquivo Nuspec com a task XmlUpdate. Na propriedade Value utilizamos uma variável chamada $(VersionNumber) que você não irá encontrar declarada no script. Isto porque trata-se de uma variável de ambiente criada pelo Jenkins e acessível no script (veja abaixo onde ela foi criada na configuração do job).

No campo Version Number Format String utilizamos uma máscara que indica que o valor da variável será gerado dinamicamente a partir da data de criação do projeto (especificado em Project Start Date). Assim, teremos versões do tipo 3.1.20.1 (3 anos, 1 mês, 20 dias, 1º release do dia).

  1. Criar uma nova API Key no painel de controle do Octopus: Faremos uma chamada à API do Octopus a partir do script MSBuild. Para isso, será necessário informar a chave da API que pode ser obtida (no painel do Octopus Server) em My Profile > Generate New API Key

  1. Obter o Octo.exe (Command Line). Esta ferramenta permite que sejam executadas comandos a partir do script. Ela pode ser obtida aqui .
  1. Criar novo script MSBuild chamado deploy.build: Este script é responsável por fazer uma chamada para a API do Octopus para a criação de uma nova release (a partir do pacote gerado no script anterior). Observe as seguintes variáveis no script:
  • OctopusProject: Nome do projeto criado no Octopus Server.
  • Environment: Ambiente criado no Octopus Server que contém a máquina-destino.
  • OctopusNugetFeed: Caminho do repositório de pacotes nuget (onde já deve estar o pacote gerado pelo script empacotamento.build).
  • OctopusAPIEndPoint: URL do Octopus Server
  • OctopusAPIKey: chave gerada no painel do Octopus Server
  • Octopus: Caminho do executável Octo.exe
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="OctopusDeployToDev">
  <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>

  <!-- Propriedades globais -->
  <PropertyGroup>
    <OctopusProject>Exemplo</OctopusProject>
    <Environment>Exemplo</Environment
    <OctopusNugetFeed>C:\Octopus\NugFeed\MeuProjeto</OctopusNugetFeed>
    <OctopusAPIEndPoint>http://octopusserver:9090/api</OctopusAPIEndPoint>
    <OctopusAPIKey>XXX</OctopusAPIKey>
    <Octopus>C:\Jenkins\tools\Octo\Octo.exe</Octopus>
  </PropertyGroup>

  <!-- Executa API do Octopus para fazer deploy em ambiente de homologacao -->
  <Target Name="OctopusDeployToDev">
    <Exec Command="$(Octopus) create-release --project=&quot;$(OctopusProject)&quot; --version=$(VersionNumber) --server=$(OctopusAPIEndPoint) --apiKey=$(OctopusAPIKey)" />
    <Exec Command="$(Octopus) deploy-release --project=&quot;$(OctopusProject)&quot; --releaseNumber=$(VersionNumber) --deployto=&quot;$(Environment)&quot; --server=$(OctopusAPIEndPoint) --apiKey=$(OctopusAPIKey) --forcepackagedownload=true --force=true --waitfordeployment" />
  </Target>
</Project>

Se o job do Jenkins foi concluído sem erros um novo release foi gerado pelo Octopus e pode ser visualizado nos detalhes do projeto. Na saída do console do job você verá algo como:

  Finding project: Exemplo
  Handshaking with Octopus server: http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;:9090/api
  Handshake successful. Octopus version: 1.6.1.1718; API version: 2.0.0
  Finding environments...
  Finding steps for project...
  Resolving NuGet package versions...
    - Finding latest NuGet package for step: Deploy
  Release plan for release:    3.2.19.1
  Steps:
    #   Name      Version         Source
    --- --------- --------------- ------------------------------------
    1   Deploy    3.2.19.1        Latest available in NuGet repository

  Creating release...
  Release created successfully!
  C:\Jenkins\tools\Octo\Octo.exe deploy-release --project="Exemplo" --releaseNumber=3.2.19.1 --deployto="Exemplo" --server=http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;:9090/api --apiKey=XXX--forcepackagedownload=true --force=true --waitfordeployment
  Octopus Command Line Tool, version 1.1.17.62

  Finding project: Exemplo
  Handshaking with Octopus server: http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;/api
  Handshake successful. Octopus version: 1.6.1.1718; API version: 2.0.0
  Finding environments...
  Finding release: 3.2.19.1
  Successfully scheduled release 3.2.19.1 for deployment to environment Exemplo

Conclusão

Com os tutoriais mostrados neste post e em Integração Contínua de Projeto .NET com Jenkins você pode criar um sistema de continuous delivery simplificado mas pronto para melhoramentos como:

  • Criação de um pipeline no Jenkins que impeça o deploy caso os testes não passem.
  • Incluir o job de empacotamento e deploy no pipeline de jobs.
  • Criação de avisos por e-mail à equipe de desenvolvimento.
  • Condicionar o deploy à aprovação de um gerente.
  • Geração de relatórios.

Escrito por Rafael Companhoni.

Android Studio + Genymotion + Github – Ferramentas para Desenvolvimento de Software Android de Qualidade

Em dezembro de 2014, foi disponibilizada a IDE oficial da plataforma Android – Android Studio 1.0. Essa primeira versão estável da IDE traz uma série de melhorias em relação a IDE Eclipse (adotada por muitos anos para desenvolvimento Android), dentre as quais destaco o preview instantâneo de múltiplas telas enquanto editando o XML de layout do aplicativo e a geração de múltiplos apk’s (formato do arquivo de aplicativo Android) criados através de um único projeto Android com Gradle.

Contexto de Qualidade de Software (Android)

Em outubro de 2014, assisti uma palestra no TDC Porto Alegre do Edson Yanaga, o qual se autodenomina um artesão de software. Não conhecia o termo artesanato de software até então. Após assistir a palestra e ler mais sobre o assunto, uma frase valorizada pelo Manifesto do Artesanato de Software me chamou bastante a atenção:

Não apenas software em funcionamento, mas software de excelente qualidade

Boa aplicação de metodologias ágeis, boa gestão empresarial, qualidade dos desenvolvedores, boas ferramentas de desenvolvimento, etc, etc, etc… Esses e outros elementos guiam o rumo de um projeto de TI para a produção de software de qualidade. Qualidade não é só importante. É fundamental. Dentre vários possíveis porquês, cito principalmente que o software produzido por uma equipe é o resultado de meses de trabalho, mas o cliente só enxerga o resultado final do produto desenvolvido, ou seja, o software. Logo, ele ser de qualidade (sem bugs, de bom desempenho, com boa experiência de usuário, etc) e isso é primordial. Outro porquê, não menos importante, é a qualidade de software afetar diretamente a motivação de um time de desenvolvimento. Resumindo, um time de desenvolvimento deve ter a sensação de propriedade sobre o software sendo produzido. O time define como o software será construído por ele (com a escolha de ferramentas de seu interesse, inclusive), de modo que a qualidade do software não seja prejudicada pelo uso de ferramental ruim e, por consequência, esse padrão de qualidade não aja negativamente sobre o ânimo do time. Aliás, propriedade do time sobre o software em desenvolvimento é um dos pilares da metodologia de desenvolvimento XP – Extreme Programming (um bom livro sobre o assunto é Programação Extrema (XP) Explicada – Acolha as Mudanças, de Kent Beck).

O desenvolvedor de software mobile francês Cyril Mottier, reconhecido pelo Google como um “Google Developer Expert” (http://cyrilmottier.com/), defende a ideia que “Great applications come from great development environment”. Logo, reforçando a posição de Cyril Mottier e, como incentivo à produção de software Android de qualidade, serão explorados, em seguida, alguns contextos de uso tanto da IDE Android Studio, como também de ferramentas complementares que auxiliam o desenvolvedor na produção de bons aplicativos Android, dentre elas Genymotion e Github.

Instalando Android Studio

Esta seção, mostra a criação de um projeto-exemplo do qual será gerado um aplicativo Android através da IDE Android Studio e, em seguida, executado. Para o uso da IDE é realizado o download dela através do seguinte link:

http://developer.android.com/sdk/index.html

O instalador do Android Studio é executado. A seguinte tela de componentes a serem instalados é apresentada:

O primeiro componente é o SDK (Software Development Kit) Android. O segundo é um Android Virtual Device (AVD). Com esse componente selecionado, é pré-configurado um dispositivo virtual Android para que ele seja usado para testar aplicativos Android construídos em um emulador. Já o terceiro componente é formalmente conhecido como um “hardware-assisted virtualization engine”. Popularmente, mais conhecido por desenvolvedores Android como o “plugin da Intel”. A inicialização completa de um emulador Android é um processo muito lento (levando mais de um minuto, facilmente). O “plugin da Intel”, essencialmente, torna o processo de inicialização do emulador cerca de três vezes mais rápido. Porém, nem todos os computadores suportam esse plugin. O link abaixo apresenta uma descrição completa dos requisitos necessários para suporte ao plugin:

https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows

Em suma, geralmente, as máquinas com suporte ao “plugin da Intel” devem conter processadores Intel e terem desempenho acima de um Intel Core i5. Devido ao fato de muitas máquinas com desempenho abaixo do requerido para uso do “plugin da Intel” ainda serem usadas para desenvolvimento de soluções Android, será apresentado, em seguida, o Genymotion. O uso dele provém um “emulador” com desempenho acima do disponibilizado no SDK Android e não requer configurações de hardware avançadas para seu funcionamento.

Dando continuidade ao processo de instalação do Android Studio, a seguinte tela, solicita um diretório para instalação do Android Studio e outro diretório para instalação do SDK Android:

Passos depois, a instalação é finalizada. Então, ao ser iniciado o Android Studio, será mostrada a seguinte tela:

Genymotion no Android Studio

Genymotion é uma ferramenta que cria uma espécie de máquina virtual capaz de “emular” o sistema operacional Android.

Através de um plugin, é possível integrar Genymotion ao Android Studio de forma a possibilitar ao desenvolvedor uma melhor experiência de desenvolvimento para a plataforma Android. Para realizar o download da ferramenta Genymotion, em primeiro lugar, é necessário registrar-se no seguinte link:

https://www.genymotion.com

Em seguida, após realizar o download, é executado o instalador da ferramenta:

Será solicitado um diretório para instalar a ferramenta, como mostrado na ilustração acima.

Após concluir a instalação, Genymotion pode ser integrado a IDE Android Studio. Para isso, devem ser realizados os passos (após iniciar Android Studio), conforme explicitados nas ilustrações abaixo:

Botão direito do mouse sobre Genymotion, conforme mostrado abaixo:

Uma vez instalado, Android Studio deve ser reiniciado de forma que a instalação do plugin esteja completa.

Projeto-Exemplo no Android Studio

De forma a demonstrar as ferramentas abordadas neste post, será criado um projeto-exemplo. A sequência de passos para a criação do projeto é mostrada abaixo:

Uma vez o projeto criado, ele já está com todas as condições mínimas para ser executado no emulador (no caso, o Genymotion). Antes disso, é necessário finalizar a configuração do plugin do Genymotion referenciando o diretório onde ele foi instalado para o Android Studio. Para isso, é necessário clicar no ícone do Genymotion, conforme a ilustração abaixo:

Será solicitado o local onde o Genymotion foi instalado (por padrão, ele é instalado no diretório C:\Program Files\Genymobile\Genymotion).

Um dispositivo virtual, então, deve ser criado. Uma série de dispositivos virtuais já são definidos pelo Genymotion (inclusive, de dispositivos reais tais como Samsung Galaxy S3, por exemplo). Assim, é selecionado o mesmo ícone de Genymotion (da mesma forma como a imagem acima) e criado o dispositivo virtual conforme às ilustrações abaixo:

Uma vez criado o dispositivo virtual, ele é iniciado:

Após iniciado o dispositivo virtual Genymotion, é executada a aplicação:

Comitando Projeto para o Github com Android Studio

Github é um serviço de hospedagem compartilhado de projetos que usa sistema de controle de versionamento Git, usado por inúmeras empresas de TI no mundo.

De forma a explorar essa ferramenta através de Android Studio, será usado o projeto-exemplo criado na seção anterior comitando-o para o Github, conforme mostrado nas figuras abaixo (é assumido que o desenvolvedor já tenha criado uma conta no Github):

Conclusão

Esse post teve como objetivo mostrar brevemente o Android Studio 1.0, primeira versão estável dessa IDE. Além disso, apresentou a ferramenta Genymotion que “emula” o sistema Android com um desempenho acima do emulador disponibilizado pelo SDK Android. Por fim, também brevemente, mostrou o Github e sua integração com Android Studio.

Principalmente, esse post teve como objetivo explicitar a importância da escolha de boas ferramentas para produção de soluções para a plataforma Android e de que forma essa escolha afeta a motivação e produtividade de um time de desenvolvimento. As ferramentas abordadas foram escolhidas com base em pesquisa e em minha experiência acumulada como sendo as mais “confortáveis” e produtivas para desenvolvimento de aplicações Android. Porém, outro ferramental pode ser o melhor para outro desenvolvedor ou time de desenvolvimento. O importante é que as ferramentas não sejam um impedimento para a boa qualidade do software produzido para a plataforma Android.

Escrito por Roger Silva

Introdução ao Knockout.js

O Knockout.js é uma biblioteca JavaScript open source desenvolvida e mantida por Steve Sanderson, colaborador da Microsoft, cujo principal objetivo é oferecer suporte para criação de interfaces dinâmicas baseadas no padrão MVVM. A biblioteca auxilia na implementação de interfaces que precisam ser modificadas dinamicamente, como por exemplo, com atualizações dependentes da ação do usuário.

De acordo com a página oficial, os principais conceitos que compõe o Knockout são:

  • Bindings declarativos: sintaxe concisa para associar os elementos DOM ao modelo de dados;
  • Atualização automática da interface: a interface é atualizada automaticamente cada vez que o modelo de dados é modificado;
  • Rastreamento de dependências: criação de relacionamentos entre os dados do modelo de maneira implícita;
  • Templates: replicação de estruturas HTML através de templates.


Model-View-View Model

O MVVM, do inglês Model-View-View Model, é um padrão para desenvolvimento de interface que divide a implementação em três partes: view, model, view-model.

  • Model: camada que representa os dados da aplicação e as operações sobre esses dados;
  • View: camada responsável por apresentar os dados para o usuário;
  • View-model: camada que implementa a comunicação entre a model e a view.

Utilizando Knockout, a view é a página HTML com bindings que se conectam na view-model, enquanto a view-model é implementada em JavaScript. As operações de leitura e escrita na model são geralmente feitas através de chamadas Ajax ao servidor.

Benefícios

Alguns dos benefícios do Knockout são:

  • Biblioteca leve – 54kb minificada;
  • Sem dependências;
  • Suporta os principais browsers – IE, Chrome, Firefox, Opera, Safari;
  • Atualização automática da view quando a model é modificada e vice-versa;
  • JavaScript puro, funcionando com qualquer framework web.

Na prática

Vamos mostrar um pequeno exemplo utilizando Knockout. Primeiro, precisamos adicionar o JavaScript da biblioteca, conforme segue.

<script src="scripts/knockout-3.2.0.js"/>

Em seguida, criamos a view, que é o HTML da página com os bindings necessários. O usuário entra seu nome, que é atualizado no modelo com o valor da textbox. Dependendo se a checkbox é marcada ou não, o valor de checked no modelo é atualizado e utilizado para decidir se o próximo parágrafo é exibido ou não.

<p>Digite seu nome: <input type="text" data-bind="value: name"></p>

<p><input type="checkbox" data-bind="checked: checked">
    Marque para mostrar a mensagem.
</p>

<p data-bind="visible: checked">
    Hello, <span data-bind="text: name()"/>
</p>

Por fim, criamos a view-model, onde inserimos dois observables para os campos do modelo.

<script>
    function ViewModel() {
         var self = this;
         self.name = ko.observable("");
         self.checked = ko.observable(false);
    };
</script>

Além disso, deve-se utilizar o comando do Knockout para aplicar os bindings ao carregar a página.

<script>
    ko.applyBindings(new ViewModel());
</script>

O resultado é exibido na imagem abaixo.

Com esse pequeno exemplo, nosso objetivo é introduzir a utilização do Knockout.js para criação de uma página web baseada no padrão MVVM. Já é possível perceber seu principal benefício, que é a atualização da interface de maneira dinâmica. Também podemos perceber outras vantagens, como a simplicidade do código e o fato de que não é necessária nenhuma dependência para que a biblioteca funcione.

Escrito por Paula Burguêz.