Já faz alguns anos que venho trabalhando em empresas que adotaram a Cultura Ágil (desde 2011), cultura que muda a forma como uma empresa cria e orienta os seus times para PENSAR EM PRODUTO e não apenas em PROJETO.

Bom, mas o que isso tem a ver com MVP?

Exatamente tudo a ver, MVP — Minimum Viable Product ou Produto Mínimo Viável, consiste em testar uma hipótese com o menor investimento possível.

Você ainda deve estar se perguntando, mas o que isso tem a ver com a Cultura Ágil?

Para isso vou dar introdução sobre MVP e Cultura Ágil, e na sequência qual a correlação.

Cultura Ágil, é um conjunto de práticas que levam como base o Manifesto Ágil (http://www.manifestoagil.com.br/principios.html), ele é a base de muitos outros conceitos e frameworks como o Scrum.

MVP, uma prática que permite realizar um conjunto de testes primários sejam feitos para validar a viabilidade do negócio. Nessa prática deve-se trabalhar com o mínimo de recursos possíveis, ele precisa manter sua função de solução para a qual foi criada e entregar valor ao cliente. Além de permitir que você aprenda o mais rápido possível qual o produto ideal para seu cliente, ficando claro se o produto entrega valor ou não.

Entendendo a correlação entre MVP e a Cultura Ágil

Vou trazer alguns trechos do Manifesto Ágil e em seguida explicar a sua correlação com as práticas do MVP.

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor;
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas;
• Entregar software funcionando com frequência, mas não na escala de semanas ou até meses, mas sim em períodos mais curtos e constantes;
• Simplicidade é a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Então vamos correlacionar, MVP consiste em testar hipóteses com o menor investimento, certo, e o Manifesto Ágil tem como prioridade inicial é satisfazer o cliente através da entrega adiantada e continua (menor investimento para se ter valor adiantado). Além disso o Manifesto Ágil aceita mudanças de requisitos para que os clientes possam tirar vantagem competitiva disso, ou seja, uma hipótese pode estar OK ou não, necessitando testar novas hipóteses de maneira continua.

Quando dizemos que o MVP busca o menor investimento possível, isso também está relacionado com o tamanho do time e o tempo de desenvolvimento do Produto, tudo isso traz custos, quanto mais rápido é o Feedback de um cliente em relação ao Produto que está sendo testado, mais rápido eu valido as minhas hipóteses. Consequentemente, menor será o impacto financeiro disso.

Além dos pontos anteriores, com a maior velocidade, se atinge uma maior maturidade, isso ajuda a dimensionar melhor o tamanho e as divisões dos times (cultura do TWO-PIZZA TEAM). Com essa cultura o time trabalha orientado em testar as hipóteses em períodos curtos de tempo, se permitindo a possibilidade de hipóteses que não mostrem resultados positivos.

Então um time que trabalhe com a prática do MVP junto da cultura Ágil, caminha naturalmente para a cultura do FAIL FAST e CONTINUOUS LEARNING.

• Imagine ficar meses criando e desenvolvendo hipóteses, e só testá-las no final de um grande período, e só então descobrir que o Produto não atende as necessidades do seu cliente?
• Ou descobrir que o seu concorrente fez algo mais inovador e está alcançando o seu público antes de você?

Seguem algumas dicas para evitar armadilhas

Seja científico na hora de criar e validar as suas hipóteses!

Para isso, além de pesquisar e analisar a sua idéia, tenha uma boa forma de medir o Feedback, gerar dados e capturar as impressões, os sentimentos, a experiência e ter números relevantes. Se falarmos de um App Mobile, Website, Dispositivo IoT ou um Software em geral, fica ainda mais fácil, vamos falar sobre alguns exemplos:

• Faça o uso de Analytics e tenha o máximo de dados atualizados.
• Tome decisões com base em dados e evidências (Data-Driven)
• Faça Teste A/B, crie hipóteses de maneira científica, ou seja, teste e compare.
• Seja o máximo de Customer Centric possível, faça algo que o seu cliente precisa, no canal, formato e a comunicação certa para eles. Por exemplo, no lugar de desenvolver um Super Mega Mobile App, muitas vezes um simples chatbot por WhatsApp resolveria o problema da melhor maneira.
• Entenda o seu consumidor (Consumer Behavior), estude quando e porquê, como e onde eles decidem consumir/utilizar seu produto. Combinando elementos da psicologia, sociologia, economia e antropologia social. Tendo como objetivo compreender o processo de tomada de decisão, tanto individualmente como em grupo.
• Monitore continuamente o seu produto, garantindo a sua estabilidade, defina métricas e mantenha elas com ótima performance.
• Acompanhe o seu cliente de perto, fique atento ao que eles dizem e, nunca ignore a opinião e os sentimentos deles, lembre-se sempre de que o produto foi feito para eles.

E aqui temos a cereja do bolo

Sempre ouça e aceite a realidade, muitas vezes nós mesmos testamos e validamos o produto que estamos criando. E é nessa hora que achamos tudo muito intuitivo, fácil, bonito, funcional e prático. Porém o seu cliente pode não achar o mesmo, então trabalhe o orientado ao cliente, estando atento e aberto para receber as críticas, reclamações e as sugestões.

Por isso, quanto mais formos científicos e orientado a dados, mais rápido se toma decisões assertivas, permitindo uma maior adaptação para que se desenvolva produtos que atendam as reais necessidades do cliente.

Espero que esse texto possa te ajudar a seguir em frente, isso foi o que aprendi sobre MVP de maneira prática. Apenas não acredito em formula mágica para se ter sucesso, mas sim no compartilhamento de ideias e experiências, esses dois pilares permitem a evolução em massa através da cultura colaborativa.

Referências:

• Manifesto Ágil:
  http://www.manifestoagil.com.br/principios.html
• Two-Pizza Team:
  https://www.bizjournals.com/bizjournals/how-to/human-resources/2016/11/jeff-bezos-two-pizza-rule-for-building-productive.html
• Fail Fast:
  https://en.wikipedia.org/wiki/Fail-fast
  http://www.iinterativa.com.br/infografico-fail-fast-acolhendo-fracasso-para-uma-inovacao-permanente/
• Continuous Learning:
  https://www.linkedin.com/pulse/7-reasons-why-continuous-learning-important-amit-nagpal/
• Cultura Colaborativa:
  https://chiefexecutive.net/commitment-to-continuous-collaborative-innovation/
• Customer Centric:
  https://www.surveymonkey.com/resources/report-customer-centric-culture-happier-employees/
• Consumer Behavior:
  https://en.wikipedia.org/wiki/Consumer_behaviour

Essa semana (15/set/2017), tive a oportunidade de participar de um Hackathon no escritório do Google, onde formamos um squad para representar o Carrefour Ecommerce Brasil com pessoas dos mais variados skills em desenvolvimento ágil, sendo Front-End, Back-End, DevOps com muito foco na criação de produtos escaláveis, veja o nosso time:

Durante o evento, todos fizemos de tudo, melhorias de performance no HTML+ CSS + JS, subimos uma aplicação em Node.js utilizando streams, criamos container com Docker, infraestrutura com soluções em Kubernetes e CDN, processo de SCM com BitBucket e Jenkins. Na minha opinião, tudo isso foi possível pelo espírito de equipe e a boa sinergia/energia entre todos do time.

Sobre a motivação desse Hackathon

Uma pesquisa realizada pelo Google apontou que 74% dos usuários abandonam sites mobile que levam mais de 5 segundos para carregar. A missão é otimizar para chegar nos 5 segundos.

Sobre a organização do evento

Pré-Evento

Antes do evento acontecer, os times passaram por algumas etapas que se dividiram em 5 passos:

O Evento

Durante o evento, os times de desenvolvedores terão a oportunidade de trabalhar com foco total em performance para mobile, tendo o suporte dos engenheiros do Google para eventuais dúvidas. Ao final do evento, os times serão convidados a apresentar seus projetos e as melhorias realizadas.

MÉTRICAS / REGRAS:

Será considerado vencedor o competidor que conquistar mais pontos nos seguintes critérios

1 O menor Speed Index*;
1.2 Maior porcentagem de diminuição do Speed Index*;
1.3 O projeto/solução mais votado pelos participantes;
1.4 Melhorias feitas que foram publicadas em produção
* Métrica de velocidade do site WebPage Test — www.webpagetest.org

Como foi organizado o dia

A nossa solução

Criamos uma aplicação em Node.js utilizando os pacotes http-proxy, trumpet, streaming e html, tudo isso possibilitou a edição do html em tempo real por Streams, otimizando as páginas com a aplicação de práticas de compressão e melhorias no código, onde é alterado a estrutura do html, css, js e imagens. Além disso, disponibilizamos essa aplicação como microservice utilizando container com deploy automizado em um processo de continuous deployment (BitBucket + Jenkins), tudo isso utilizando um cluster de Kubernetes na Cloud + CDN. Veja como ficou a solução:

Resultados

Nós escolhemos a página de produto para ser otimizada, pois essa página tem o maior número de pageviews e ela é decisiva no funil de vendas, nela o usuário decide se adiciona o produto no carrinho e segue com o processo de checkout.

O time do Google mediu a nossa página antes do evento e registrou o tempo de carregamento dessa com 14.9 segundos, após o evento finalizamos com os seguintes números:

• O tempo de carregamento passou de 14.9 para 9.1 segundos, obtendo 39% de redução de tempo de carregamento da página;
• O tamanho passou de 3.5 para 1.5 megabytes, obtendo 58% de redução no tamanho da página;
• A quantidade de requests passou de 240 para 124 requests, obtendo 49% de redução na quantidade de requests da página.

Veja alguns gráficos que facilitam o entendimento

• Cascata durante o carregamento da página, onde alguns itens são sequenciais e outros são paralelos:

para o gráfico acima tivemos as técnicas e práticas de compactação de html + css + js, LazyLoad e remoção de scripts de Tag Management sendo utilizados de forma indevida.

• Progresso de carregamento visual onde tivemos uma pequena perda no First Byte Start, porém conseguiremos resolver isso com ajustes do cache de CDN (foi corrido amigo, rs), sendo a legenda Azul (antes) e o Vermelho (depois):

• Comparativo detalhado do tempo de carregamento, sendo a legenda Azul (antes) e o Vermelho (depois):

• Redução da quantidade de requests, sendo a legenda Azul (antes) e o Vermelho (depois):

• Redução de tamanho por tipo de arquivo que compõe a página, sendo a legenda Azul (antes) e o Vermelho (depois):

Os números foram expressivos, o nosso time conseguiu entender o problema e a missão, e entregar um produto que permita otimizar o site de forma ágil e continua (todos os times conseguiram atingir números expressivos). O Google além de compartilhar conhecimento e incentivar a criatividade, provou que criar um time focado + ambiente certo, só pode resultar em muito foco e inovação!

Algumas fotos do nosso time durante o evento

Obrigado time! Obrigado Google!

Um gerenciador e orquestrador de tarefas e rotinas que permite criar fluxos de execuções, essas podendo ser organizadas por etapas onde cada etapa pode prosseguir ou interromper toda a tarefa baseado em sucesso ou falha. Outra feature interessante é permitir a configuraração de triggers podendo ser por eventos (Webhook) e/ou agendamentos (schedule).

Essa solução é 100% Open Source e orientada a plugins, o que fomenta ainda mais o jeito colaborativo de se desenvolver um produto, tem sido bem adotada pela comunidade de DevOps para uso em ambientes de Cloud e Data Center, pois ela facilita a comunicação entre o time, gerando o conceito de atendimento através de rotinas e tarefas que podem ser acessadas por interfaces Web com formulários, APIs ou Command Line Tool (CLI Tool). Seu diferencial está na organização das etapas de uma tarefa, que são organizadas em fluxos lógicos (uma tarefa pode ser composta por outras tarefas).

Outros pontos que se destacam:

• Controle de acesso de usuários, controlando por grupo de usuários e regras
• Controle de execução das tarefas podendo ser Single-Thread ou Multi-Thread, evitando execuções simultâneas indesejadas (imagine dois usuários tomando a mesma decisão de forma simultânea e resolvem executar uma tarefa de Scaling manual, com o Single-Thread a tarefa fica bloqueada até que seja finalizada)

Saiba mais:

• Site: http://rundeck.org/
• Projeto: https://github.com/rundeck/rundeck (Java + Spring + Grails + Bootstrap)

PoC

Desenvolver um projeto no Rundeck que permita a interação com:

• interaja com a API de um servidor Git

Com finalidade de promover automação na criação de repositórios para prover CI com o máximo de automação.

Primeiros passos

Ler a documentação

http://rundeck.org/docs/

Download e Instalação

http://rundeck.org/docs/manual/getting-started.html#download-and-installation

Vou usar a versão “Self Contained Launcher Install”

Coloque o arquivo jar no seguinte local:

~/rundeck

Execute:

java -jar rundeck-launcher-2.9.3.jar

Após isso, acesse http://localhost:4440 e veja a tela de login:

No primeiro acesso utilize as credenciais:

• user: admin
• pass: admin

Criando um projeto

Agora já podemos criar um projeto!

Basta preencher o formulário e seguir a documentação http://rundeck.org/docs/manual/getting-started.html#project-setup

Criando um Job

Após criar um projeto, onde nessa PoC foi criado o projeto git-automation basta clicar em em JOBS → New Job

Agora vamos entender a configuração de um Job:

Existem muitas opções na criação de um Job, como notificação, criar um workflow de etapas de scripts, mas para a nossa tarefa ficou algo bem simples, onde foram definidas as ações de input de dados que em seguida são usadas em num template para preencher dados do nosso script. Nesse caso um comando CURL que faz uma requisição HTTP POST para a criação de um repositório no BitBucket.

Job definition

Todo Job (tarefa) gera um Job Definition, que serve de template para a criação de outros jobs, veja o YAML gerado automaticamente após a criação do nosso Job:

- description: ''
  executionEnabled: true
  id: 87cafb96-f417-461b-bc13-d9815e747643
  loglevel: INFO
  loglimit: 1MB
  loglimitAction: halt
  loglimitStatus: '''failed'''
  multipleExecutions: true
  name: bitbucket-repository-create
  nodeFilterEditable: false
  notification:
    onfailure:
      email:
        attachLog: true
        recipients: denissys@gmail.com
        subject: Criação de ${option.repository-name} falhou
  options:
  - name: auth-user
    required: true
  - name: auth-pass
    required: true
    secure: true
    valueExposed: true
  - name: team
    required: true
    value: ecommerce2steps
  - name: project
    required: true
    value: RDECK
  - name: repository-name
    required: true
  retry:
    delay: 5s
    retry: '1'
  scheduleEnabled: true
  sequence:
    commands:
    - description: curl create repo
      plugins:
        LogFilter:
        - config:
            color: red
            replacement: '[SECURE]'
          type: mask-passwords
      script: 'curl --user @option.auth-user@:"@option.auth-pass@" -X POST -H "Content-Type:
        application/json" -d ''{ "scm": "git", "project": { "key": "@option.project@"
        }, "is_private": true}'' https://api.bitbucket.org/2.0/repositories/@option.team@/@option.repository-name@'
    keepgoing: false
    strategy: node-first
  timeout: 10s
  uuid: 87cafb96-f417-461b-bc13-d9815e747643

O nosso Job de criação de repositório no Bitbucket

Basta preencher o formulário, executar o Job e depois acompanhar o resultado da execução. O job possui um mini dashboard com sumário e histórico das execuções, podendo explorar o log de cada execução (essa opção é configurável, como decidir armazenar apenas os logs de execuções que falharam). Outra opção interessante é poder executar um Job em modo debug, isso permite que seja pausada cada etapa do Job, onde você pode analisar o log de cada etapa e avançar manualmente.

SCM — Controle de versão de Jobs

Já sabemos que o rundeck cria projetos e que um projeto pode ter Jobs, no nível de Projeto temos a feature SCM onde podemos vincular o projeto a um repositório Git para fazer Import e Export dos Jobs, ou seja, sempre que eu criar ou alterar um Job ele será versionado, e através de algumas interfaces podemos controlar as revisões e até fazer rollback de alguma alteração. Vamos ver como isso funciona na prática:

Export Job

Escolha um projeto, vá no meu Project → Setup SCM…

Em SCM Export clique no botão Setup

Preencha o campo Git URL com o endereço SSH ou HTTPS do seu repositório Git onde os Jobs serão versionados, alem de escolher a branch e mais algumas opções (todas tem um Tool Tip com explicações)

Agora precisamos configurar a autênticação da aplicação, para isso precisamos criar um arquivo com a senha e passar o caminho do arquivo no campo Password Storage Path

!! Essa foi a parte díficil, pois não encontrei nada na documentação que explicasse sobre o arquivo de senha deve estar relativo ao diretório do Rundeck, e numa árvore especifica !!

Após criar o arquivo de senha e preencher o campo Password Storage Path, basta clicar em Setup para finalizar

Pronto, seus Jobs do projeto em questão estarão aptos a ser versionados

Import Job

O import Job serve para restaurar os Jobs em um projeto, você pode selecionar os Jobs e associar ao seu projeto, a configuração é exatamente igual a de Export Job, repita os mesmos passos para configurar.

Versionando um Job

Após fazer alguma alteração num Job, você verá um Warning “Created, Changed”, ao passar o mouse um Tool Tip apresentará a mensagem sobre qual ação de SCM está pendente.

Clique em Action → Commit Changes to Git

Adicione um comentário, marque Push Remotely para fazer o remote push e clique no botão Commit

Em seguida clique na seta alteral do seu Job (menu opções do Job) e escolha a opção View Commit Info

Veja que já foi criada uma timeline representando a árvore de commits do Job

Aqui podemos ver detalhes de quem alterou, o que foi alterado

E para finalizar, vá no seu servidor de Git Repository, abra o repositório e veja que já foi criado o arquivo do Job e os commits já refletem

Plugins

Tudo no Rundeck, pratícamente é um plugin, desde a construção de um projeto, como o processo de SCM e Flows. Veja um exemplo do que ele faz baseado na lista de plugins padrão:

Além de uma vasta lista de plugins adicionais como Chef, Puppet, Google Cloud Platform, AWS, Telegram, Nexus, veja a lista completa: http://rundeck.org/plugins/index.html

Impressões

A primeira impressão foi ótima, pois foi extremamente fácil instalar e configurar a ferramenta, a documentação é bem rica e organizada, as releases do produto são constantes, assim como o lançamento de novos plugins. Uma das minhas preocupações era em relação a camada de persistência dos Jobs, porém todos os Jobs geram arquivos de configuração (YAML ou XML) que podem ser persistidos em disco local e versionados num servidor Git, isso por meio de uma interface de configuração de SCM da própria ferramenta. Ele conta com um banco local que pode ser facilmente alterado em um arquivo de configurações.

No geral superou as minhas expectativas, a ferramenta é completa, expõe Interfaces Web (Mobile first), APIs e CLI, é bem segura e organiza aquele monte de scripts de servidor, e elimina o desenvolvimento de aplicações que se tornam gateway para chamadas de APIs que são usadas em processos de integração continua quando se quer fazer automação.

Dicas uteis

• Rodando rundeck em Container: https://hub.docker.com/r/jordan/rundeck/

É certo que em todo curso ou disciplina de algoritmo nós sempre aprendemos o arroz com feijão da linguagem de programação a ser estudada, isso para que possamos desenvolver a estrutura básica de qualquer algoritmo. Por isso resolvi criar um programa que converta um valor numérico de String para Float, nele teremos a oportunidade de explorar pontos importantes da linguagem Go.

Segue o fluxo do nosso programa:

• Entrada: Recebe um valor obrigatório como argumento de entrada;
• Processamento: Deve validar esse valor e se for possível, convertê-lo em um número;
• Saída: Exibir uma mensagem dizendo se o valor é numérico ou não.

Apenas com esse simples algoritmo poderemos aprender 5 coisas importantes da linguagem Go, sendo elas:

1 — Trabalhar com argumentos e operações do sistema operacional;

2 —Entender listas;

3 — Tomar decisões com o operador condicional IF;

4 —Usar uma função de conversão;

5 — Tratamento de erro em Go.

O nosso programa:

package main

import (
  "fmt"
  "strconv"
  "os"
)

func main() {
  checkNumber(getValue())
}

func getValue() string {
  if len(os.Args)-1 < 1 {
    fmt.Println("One arg is requerid for this program")
    os.Exit(1)
  }
  value := os.Args[1]
  return value
}

func checkNumber(value string) {
  fValue, err := strconv.ParseFloat(value, 64)
  if err != nil {
    fmt.Printf("The value <%s> is not a number\n", value)
    os.Exit(1)
  }
  fmt.Printf("The value <%f> is a valid number\n", fValue)
}

GitHub: https://github.com/denissys/go-tutorial-converter

Crie o arquivo de código-fonte no seu workspace, no meu exemplo vou chamar de floatconv.go:

../go/workspace/src/converter/floatconv.go

Acesse o diretório src do seu workspace, e vamos fazer algumas execuções passando valores numéricos válidos para o nosso programa:

go run converter/floatconv.go 1
go run converter/floatconv.go 22.4
go run converter/floatconv.go 13567788.22220921

Para os cenários válidos, teremos as seguintes saídas no terminal, indicando que são valores numéricos:

The value <1.000000> is a valid number
The value <22.400000> is a valid number
The value <13567788.222209> is a valid number

Agora vamos testar sem nenhum argumento e também passando valores não numéricos:

go run converter/floatconv.go
go run converter/floatconv.go asdf
go run converter/floatconv.go false

Para os cenários com erros, teremos as seguintes saídas no terminal, indicando o argumento obrigatório e em seguida que os valores não são numéricos:

One arg is required for this program
exit status 1

The value <asdf> is not a number
exit status 1

The value <false> is not a number
exit status 1

Entendendo o nosso programa por partes

1 - Trabalhar com argumentos e operações do sistema operacional

Repare que importamos o pacote "os", esse pacote tem funções importantes para interagir com o sistema operacional onde seu programa está hospedado. Esse pacote facilita a execução do seu programa em plataformas diferentes, ou seja, permite que ele seja multiplataforma. No nosso caso, usamos o pacote "os" para utilizar a função que captura o argumento passado na execução do nosso programa por linha de comando, podendo interagir com esse valor em nosso código por meios de algumas funções. Repare que na linha de comando, após o nome do arquivo do programa floatconv.go, nós passamos um valor numérico 123, esse é o argumento:

go run converter/floatconv.go 123

E no código abaixo, nós utilizamos a função Arg do pacote "os" para recuperar o valor 123 que foi passado como argumento, esse valor é atribuído na variável value:

value := os.Args[1]

Observe no código acima que na atribuição do valor na variável value não foi necessário especificar o tipo da variável (os.Args sempre recebe os valores como string pela linha de comando), para resolver o tipo da variável value o compilador saberá atribuir o tipo correto com base no dado (string, int, float, bool …).

Além disso, nós usamos a função Exit do pacote “os”, no nosso código o Exit interrompe a execução do programa nos casos onde determinamos um erro.

if len(os.Args)-1 < 1 {
    fmt.Println("One arg is requerid for this program")
    os.Exit(1)
}

A instrução os.Exit(1) recebe o valor 1 como argumento, isso indica para o sistema operacional que o programa foi finalizado com erro, se o valor do argumento fosse zero, indicaria uma execução finalizada normalmente (seguindo os padrões de programas Unix, leia mais aqui).

2 - Entender listas

Em Go existem dois tipos de listas, podendo ser um array que é uma lista de tamanho fixo, ou slices que são listas dinâmicas onde seu tamanho pode aumentar ou diminuir.

Obs.: Mais para frente farei um tutorial explorando e explicando com detalhes a diferença entre array e slices.

No nosso caso usamos o os.Args que é um slice, nele são armazenados os argumentos que foram passados por linha de comando na execução do nosso programa.

Usando a função len() nós conseguimos obter o tamanho da nossa lista len(os.Args), é importante saber que a primeira posição da lista tem o índice 0.

if len(os.Args)-1 < 1 {
  ...
}

Na instrução os.Args[1] nós usamos colchetes seguido da posição do índice para obter o valor armazenado nessa posição da lista.

value := os.Args[1]

Obs.: No nosso programa a posição 0 (zero) está ocupada com a informação da execução do programa que foi executado por linha de comando (os.Args[1] => /var/folders/fv/p7vn4fts1153tqh5956f40940000gn/T/go-build933283485/command-line-arguments/_obj/exe/floatconv), já o dado que passamos como argumento está na posição 1 (um) do índice da lista, ou seja, a nossa lista tem 2 elementos.

3 - Tomar decisões com o operador condicional IF

Nós usamos o operador condicional IF duas vezes no nosso código, sendo:

if len(os.Args)-1 < 1 { ... )

if err != nil { ... )

Em Go apenas expressões do tipo bool, ou seja, expressões do tipo verdadeiro ou falso (true/false) podem ser utilizadas no operador condicional if, podendo receber uma variável ou função.

4 - Usar uma função de conversão

Para converter o valor do argumento que é string para float, nós usamos a função ParseFloat do pacote "strconv" (string conversion), esse pacote fornece muitos outros tipos de conversões de string para outros tipos de dados como decimal, float, bool.

fValue, err := strconv.ParseFloat(value, 64)

5 - Tratamento de erro em Go

Repare na instrução abaixo:

fValue, err := strconv.ParseFloat(value, 64)

Viu que além de declarar a variável fValue, foi declarado junto a variável err (erro de conversão), ou seja, a função retorna dois valores. Isso pode parecer confuso, estranho, diferente, mas temos que lembrar que Go é uma linguagem funcional e com novos paradigmas, e esse é um de seus bons recursos. Nesse casso a variável err pode retornar um nil (nulo), se isso ocorrer é porque a conversão não retornou nenhum erro, caso contrário é porque um erro ocorreu na conversão do valor.

fValue, err := strconv.ParseFloat(value, 64)
if err != nil {
  fmt.Printf("The value <%s> is not a number\n", value)
  os.Exit(1)
}

Em particular, achei ótimo a maneira Go de tratar erros, não precisamos lidar com dezenas de formas de trabalhar com uma ou mais exceções, no inicio pode até parecer verboso, mas pelos códigos que estou desenvolvendo e também os que venho acompanhando, se torna mais simples de lidar com erros em Go. No Java por exemplo, sempre dedico um certo tempo para entender a arquitetura de tratamento de erros que cada um definiu em seu projeto, como também devemos ficar atentos quando é usada uma RuntimeException.

O próximo passo será fazer o teste unitário em Go:

Código bom tem que ter cobertura de teste unitário, isso não é diferente em Go, então leia o próximo tutorial onde aprenderemos a testar o nosso algoritmo conversor numérico: <assim que eu finalizar o tutorial publicarei o link aqui>

Instalando Go

Precisamos instalar as ferramentas da linguagem Go para começar a brincadeira, vamos lá:

• Para MacOS e Linux

No MacOS você pode usar o Installer ou fazer por linha de comando igual no Linux, baixe o installer ou o pacote compactado direto do site de distribuição do Go (o nome deve ser semelhante a este go1.8.x.linux-amd64.tar.gz), acesse aqui e baixe https://golang.org/dl/

sudo tar -C /usr/local -xzf go1.8.x.linux-amd64.tar.gz

Pronto, as ferramentas da linguagem go estão disponíveis no diretório

/usr/local/go

Vamos configurar a nossa variável de ambiente para que possamos usar facilmente as instruções das ferramentas do go pelo terminal:

export PATH=$PATH:/usr/local/go/bin

PS: Se tiver duvida sobre variável de ambiente, segue um tutorial: https://www.vivaolinux.com.br/artigo/O-que-e-PATH-como-funciona-e-como-trabalhar-com-ele

Agora validaremos se a configuração deu certo testando um comando go no terminal:

go version

O resultado deverá ser semelhante a este:

go version go1.8.3 darwin/amd64

Criando uma Workspace para organizar nossos programas

A workspace será o nosso diretório padrão de trabalho, e todos os nossos programas estarão nessa workspace, nela teremos a seguinte estrutura de diretórios:

• src: contém o código-fonte dos códigos que escrevemos, como também o código-fonte de pacotes de terceiros importados em nossos programas;
• pkg: contém objetos referentes aos pacotes;
• bin: contém arquivos executáveis gerados pelos programas que compilamos.

Chega de configuração e vamos ao primeiro código em Go!

Use um editor de texto de sua preferência que suporte o encode UTF-8, caso use outro encode "perdeu playboy", seu código não será interpretado pelo compilador :P

Vá no seu diretório de workspace, e dentro do diretório src ../workspace/src crie um diretório primeiro-codigo-go e nesse diretório crie o arquivo meucodigo.go e escreva o seguinte código:

package main

import "fmt"

func main() {

     fmt.Println("Sou um programa em Go, eu existo!")

}

Agora utilizando a ferramenta go vamos executar o comando:

go run workspace/src/primeiro-codigo-go/meucodigo.go

Então, o texto “Sou um programa em Go, eu existo!” será exibido no seu terminal.

Vamos entender a estrutura do nosso código-fonte Go

Todo código-fonte em Go segue uma estrutura simples, que basicamente é dividida em três seções:

Seção 1: A package é a definição do nome do pacote;

Seção 2: O import é onde são importados os pacotes externos, como o de formatação "fmt" que usamos no nosso primeiro código;

Seção 3: Área de código, onde serão implementos as suas funções e algoritmos do seu programa.

Explorando o código Go

Quando instalamos e configuramos o Go na nossa máquina, trouxemos todo o código Standard junto, como vimos, nós usamos a função "fmt" no nosso primeiro código Go. Abra o seguinte diretório /usr/local/go/src/fmt e explore os códigos-fonte contido nele, como o format.go e print.go, essa é uma boa forma de aprender, pois todo o código Standard está a sua disposição.

Conclusão sobre o nosso primeiro programa

Todo código Go deve ter uma package, e todo programa deve ter uma package main e uma função main() para ter um ponto de partida de inicialização do seu programa.

É isso, por fim, fizemos o nosso primeiro código Go, vamos seguir em frente e entender mais sobre essa linguagem, seus conceitos e paradigmas.

Veja o próximo capítulo:

Tutorial — Conversor numérico em GoLang

The programming languages are tools like a Swiss Army Knife, the more languages you know, more problems you can solve with the correct programming language. This analogy comes to explain that all programming languages are good and each has its function, so let's stop the war!

Nowadays, if you know only one programming language, you are like Rambo with your combat knife, can you solve anything? Yes, you can, but it will be very difficult and you will end this war with many blood. You need to understand that each language is better to solve specific problems in different situations and contexts, that's why you can and should have your opinion and make your comparison among the programming languages, however you should use the correct comparison criteria in the correct context.

Example, in my opinion you shouldn’t use Java to create automation in one server as create tasks to automate routines, Java run in a JVM, the JVM is a heavy process into operation system and requires a lot of memory, the Java depends of frameworks to support Shell and have complex process to compile the code. So we have to use a script language such as Python, that give easy support to Shell and the operation system will easily interpret your script code, besides requires little memory to manage this process into operation system. Other strong factor, the DevOps community adopt python for automation in your script codes.

Well, now that you became a more adaptable developer and promoter of peace, I believe that you’ll create a creative and productive environment among the developers that you know!

Tip: stay updated about rank and trends:

• Rank: https://www.tiobe.com/tiobe-index
• Trends: https://www.thoughtworks.com/pt/radar/languages-and-frameworks

See ya!

Denis Santos