Design Patterns são soluções reutilizáveis para problemas comuns no desenvolvimento de software. Todo programador já encontrou várias vezes problemas semelhantes que pediam soluções parecidas, essas soluções são os Padrões de Projetos (Design Patterns).

Toda linguagem tem várias dessas soluções reutilizáveis criadas pela sua comunidade. É por causa dessa experiência combinada de vários desenvolvedores que os padrões de projetos são tão úteis, eles nos ajudam a produzir um código otimizado ao mesmo tempo que resolvem nosso problema. Outra grande vantagem é que por serem comuns desenvolvedores diferentes conseguem entender com facilidade os códigos uns dos outros.

Os maiores benefícios dos padrões de projetos são os seguintes:

• São soluções que funcionam: Como são usados por vários programadores, você pode ter certeza de que funcionam. E não é só isso, como foram usados muitas vezes, várias otimizações foram sendo feitas ao longo do tempo.
• Facilmente reutilizáveis: Padrões de projeto são soluções reutilizáveis que podem ser facilmente adaptadas a problemas particulares, elas não se limitam a um único problema.
• São expressivas: Padrões de projeto conseguem explicar uma solução grande de forma elegante.
• Elas facilitam a comunicação: Programadores familiares com padrões de projeto conseguem conversar de forma mais fácil a respeito das soluções.
• Diminuem a necessidade de refatoração: Quando você escreve uma aplicação tendo padrões de projeto em mente, fica mais fácil de ter um código limpo mais rápido. Assim, acabamos fazendo menos refatorações.
• Eles diminuem o tamanho da código: Porque padrões de projeto normalmente são soluções otimizadas, elas costumam precisar de menos código para serem implementadas.

Com tudo isso você já deve estar com vontade de começar a usar os padrões de projeto, mas acho importante revermos alguns conceitos de JavaScript primeiro.

Uma Breve História do JavaScript

Hoje em dia JavaScript é a linguagem de programação mais popular para web. No começo ela era só uma “cola” entre vários elementos HTML, uma linguagem de scripts para rodar no cliente para um dos primeiros navegadores, o Netscape. Naquela época os navegadores só conseguiam renderizar páginas HTML estáticas, o surgimento do JavaScript levou a uma guerra entre os grandes da época, Netscape e Microsoft.

Cada uma das grandes empresas do início dos anos 90 queria usar sua própria implementação para uma linguagem de scripts, Netscape com JavaScript (criado por Brendan Eich em 1995) e a Microsoft com o JScript. Essa foi a primeira Browser’s War.

Como você pode imaginar, as diferenças entre elas eram enormes e cada site precisava ser feito para um navegador específico, sempre com um sinal de “melhor visto em…”. Logo ficou claro que era preciso de um standard, uma linguagem cross-browser que unificaria o processo de desenvolvimento e simplificaria a criação das páginas web. O resultado disso tudo foi a criação do ECMAScript.

ECMAScript é uma especificação para uma linguagem de script que todos os navegadores tentam suportar, e existem várias implementações do ECMAScript. A implementação mais popular de todas é o JavaScript. Desde seu lançamento o ECMAScript padronizou várias coisas importantes - para os curiosos existe uma lista de todos os detalhes na Wikipedia em inglês. O suporte para a versão 6 do ECMAScript (ES6) e as mais novas ainda está incompleto, por isso precisam ser transpiladas para ES5 antes de funcionarem em (quase) todos os navegadores.

O Que Então é JavaScript?

Para entendermos completamente os padrões de projeto deste post, vamos ver uma introdução a alguns aspectos importantes da linguagem que precisamos estar cientes antes de nos aprofundarmos nos padrões de projeto. Podemos definir JavaScript mais ou menos assim:

JavaScript é uma linguagem leve, interpretada, orientada a objetos com funções de primeira classe mais conhecida como uma linguagem para páginas da web

Essa definição serve para dizer que JavaScript tem uma pegada pequena na memoria, é de fácil uso, fácil de aprender e tem uma sintaxe similar a linguagens mais populares como C++ e Java. É uma linguagem de scripts, o que significa que seu código é interpretado e não compilado. Tem suporte a programação procedural, orientada a objeto e funcional, o que a torna muito flexível (e também é a causa de vários problemas).

Até agora, nós só vimos características semelhantes a várias outras linguagens de programação. Vamos dar uma olhada no que tem de específico no JavaScript e a destaca no meio das outras. Eu vou listar algumas características e dar o meu melhor para explicar o porque delas merecerem uma atenção especial.

JavaScript Suporta Funções de Primeira Classe

Essa é uma característica que pode ser difícil de compreender para quem vem de linguagens como C e C++. Dizer que JavaScript trata funções como cidadãos de primeira classe significa que você pode passar funções como parâmetros a outras funções como uma variável qualquer. Quase como se funções fossem objetos.

// Mandamos uma função para ser executada
// dentro da função que faz a chamada
function performOperation(a, b, cd) {
    var c = a + b;
    cd(c);
}

performOperation(2, 3, function(result) {
    // result vai ser 5
    console.log("O resultado da operação é " + result);
});

JavaScript é Baseada em Protótipos

Como qualquer outra linguagem orientada a objetos, JavaScript suporta objetos (ó…), e umas das primeiras coisas que nos vem a mente quando falamos em objetos são classe e herança. E é aqui que a porca torce o rabo, JavaScript não suporta classes na sua linguagem mais básica, mas usa uma herança baseada em protótipos (também conhecida como instancia).

Só no ES6 que classes formais foram introduzidas, o que significa que muitos navegadores ainda não suportam essa feature (a última versão do ECMAScript completamente suportada pelos principais navegadores é a 5.1). Mas é importante lembrar que embora a palavra class tenha sido introduzida ela é só maquiagem, por baixo dos panos, JavaScript ainda usa sua herança baseada em protótipos.

A programação baseada em protótipos é um estilo de programação que constrói sua reutilização de comportamentos (a herança) através de um processo de reuso de objetos já existentes que funcionam como protótipos. Nós vamos rever a herança baseada em protótipos na seção sobre padrões de projeto, essa é uma característica muito usada nos design patterns.

Loops de Eventos em JavaScript

Se você já programou em JavaScript, com certeza é familiar com o termo callback. Para quem não está familiarizado, um callback é uma função passada como parâmetro que será executada quando um dado evento for disparado. Eles são geralmente usados para inscrição em eventos como click do mouse ou quando um botão é apertado.

Cada vez que um evento que tenha um listener (ouvinte?) é disparado, uma mensagem é enviada para uma fila (queue) que é processada de forma síncrona, do tipo FIFO (first-in-first-out). Isso é chamado de loop de eventos (event loop).

Cada mensagem na queue tem uma função relacionada a ela. Sempre que uma mensagem sai da fila, a função é executada por completo antes de qualquer outra mensagem ser processada. Ou seja, se a função contem outras chamadas a outras funções, eles são todas feitos antes de uma nova mensagem da fila ser processada. Isso é chamado run-to-completion.

while (queue.waitForMessage()) {
    queue.processNextMessage();
}

A queue.processNextMessage() espera por novas mensagens de forma síncrona. Cada uma das mensagens sendo processada tem o seu próprio stack e é processada até que o stack esteja vazio. Uma vez encerrado o processamento, uma nova mensagem é lida da fila, enquanto houverem mensagens na fila.

Também é comum ouvir dizer que JavaScript é não bloqueante, o que significa que quando uma operação asíncrona está sendo realizada o programa pode continuar processando outras coisas, como receber novos inputs, sem bloquear a thread principal. Essa é uma propriedade muito útil do JavaScript e de fato muitas pessoas optam por usar a linguagem fora do navegador justamente por isso. Esse é um tópico muito amplo e merece um artigo só para ele, acabei deixando de fora desse post.

O Que São Design Patterns?

De novo, padrões de projeto são soluções reutilizáveis para problemas comuns do desenvolvimento de software. Vamos ver as categorias de padrões de projetos.

Proto-padrão

Como se cria um padrão? Digamos que tu reconheceu um problema recorrente e tem uma solução única para esse problema, que ainda não foi globalmente reconhecida e documentada. Você usa essa solução sempre que encontra o mesmo problema e acredita que é uma solução reutilizavel e que toda a comunidade de desenvolvimento se beneficiária disso.

Tua solução vira imediatamente um padrão? Por sorte, não. É comum que uma pessoa com boas práticas de desenvolvimento apenas confunda algo que parece um padrão com o que , de fato, não é.

Como você pode saber se o que encontrou é realmente um padrão de projeto?

Descobrindo a opinião de outros desenvolvedores a respeito, sabendo o processo de criar o padrão e se familiarizando com os padrões já existentes. Existe uma fase pela qual o padrão precisa passar antes de ser reconhecido, a chamada proto-padrão.

Um proto-padrão precisa ser usado e testado por vários desenvolvedores antes de ser tornar um padrão de verdade. Tem um grande trabalho de documentação a ser feito para tornar um padrão reconhecido e usado pela comunidade.

Anti-padrão

Assim como um padrão de projeto representa uma boa prática, um anti-padrão (anti-pattern) representa uma má prática.

Um bom exemplo de anti-padrão é modificar o protótipo Object. Praticamente todos os objetos do JavaScript herdam de Object (lembre-se que JavaScript usa herança baseada em protótipos) então imagine que você tenha alterado esse protótipo. As mudanças em Object seriam vistas em todos os objetos que herdam desse protótipo — o que seria quase todos os objetos do JavaScript. Um desastre esperando para acontecer!

Outro exemplo é modificar objetos que você não conhece. Uma modificação em um método de um objeto usado em vários pontos da aplicação poderia causar uma grande confusão, em um time grande seria pior ainda. Você rapidamente teria colisões de nomenclatura, implementações compatíveis e um pesadelo na manutenção. Com sorte os testes te salvariam a tempo.

Da mesma forma que é importante conhecer boas práticas, também é legal conhecer as más. Essa é a única forma de perceber os erros e evitá-los antes que seja tarde demais.

Categorias de Padrões de Projeto

Padrões de projeto podem ser categorizado de várias maneiras, mas as mais populares são as seguintes:

• Padrões de projeto criacionais
• Padrões de projeto estruturais
• Padrões de projeto comportamentais
• Padrões de projeto de concorrência
• Padrões de projeto arquiteturais

Padrões de Projeto Criacionais

Esses padrões lidam com a geração de objetos de uma forma que otimize a criação quando comparado com a forma mais básica. Quando a forma padrão de criação de objetos poderia adicionar complexidade ou problemas ao código os padrões criacionais podem resolver o problema. Alguns padrões populares dessa categoria são (em inglês para facilitar as buscas no Google):

• Factory method
• Abstract factory
• Builder
• Prototype
• Singleton

Padrões de Projeto Estruturais

Esses padrões trabalham com os relacionamentos entre objetos. Ele garantem que se uma parte do sistema muda, mais nada precisa mudar com ela. Os padrões mais populares dessa categoria são:

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Padrões de Projeto Comportamentais

Esse tipo de padrões reconhecem, implementam e melhoram a comunicação entre objetos do sistema. Eles ajudam a garantir que partes desconexas da aplicação tenham a informação sincronizada. Exemplos populares são:

• Chain of Responsibility
• Command
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Visitor

Padrões de Projeto de Concorrência

Esse tipo de padrões de projeto lida com programação em várias threads (multi-threaded programming). Alguns mais populares são:

• Active object
• Nuclear reaction
• Scheduler

Padrões de Projeto Arquiteturais

Padrões de projeto que são usados na arquitetura do sistema. Alguns mais famosos são:

• MVC (Model View Controller)
• MVP (Model View Presenter)
• MVVM (Model View ViewModel)

Na próxima seção iremos dar uma olhada em alguns desses padrões, com exemplos para melhor entendimento.

Exemplos de Padrões de Projeto

Cada padrão de projeto representa uma solução para um tipo de problema. Não existe um conjunto universal de padrões que vai solucionar todos os problemas que você ira encontrar. Precisamos entender quando um dado padrão vai ser útil e quando ele vai entregar valor de fato. Uma vez que estejamos familiarizados com os padrões de projetos e os cenários nos quais eles se encaixam, seremos capazes de determinar qual padrão podemos usar e se ele serve para resolver o problema em questão.

Lembre-se, aplicar o padrão errado pode levar a efeitos indesejados, como complexidade desnecessária, perda de performance até criar um anti-padrão.

Essas são todas coisas importantes a serem consideradas quando estamos pensando em aplicar um padrão de projeto em nosso código. Vamos olhar alguns padrões de projetos que eu acho mais úteis para JavaScript e todo desenvolvedor JavaScript sênior deveria conhecer.

Constructor Pattern

Quando pensamos na implementação clássica de linguagens orientada a objetos, um construtor é uma função especial de uma classe que inicializa uma série de valores default e/ou valores recebidos.

Três formas comuns de criar objetos em JavaScript são:

// Qualquer uma dessas maneiras pode ser usada
// para criar um objeto em JavaScript
var instance = {};
// ou
var instance = Object.create(Object.prototype);
// ou
var instance = new Object();

Depois de criarmos um objeto, temos quatro maneiras de adicionar propriedades a eles. Elas são as seguintes:

// A partir do ES3
// a notação .
instance.key = "valor";

// A notação de colchetes
instance["key"] = "valor";

// A partir do ES5
// Definindo uma propriedade com Object.defineProperty
Object.defineProperty(instance, "key", {
    value: "valor",
    writable: true,
    enumerable: true,
    configurable: true
});

// Definindo multiplas propriedades com Object.defineProperties
Object.defineProperties(instance, {
    "firstKey": {
        value: "valor da primeira chave",
        writable: true
    },
    "secondKey": {
        value: "valor da segunda chave",
        writable: false
    }
});

A forma mais comum de criação de um objeto é usando chaves e para adicionar propriedades a notação ponto ou colchetes. Por isso recomendo que esses sejam os métodos usados, vai facilitar o entendimento por outros programadores e teu eu do futuro.

Nós mencionamos antes que JavaScript não suporta classes nativas, mas suporta construtores através da palavra chave new prefixada a uma chamada de função. Dessa forma podemos usar uma função como construtor e inicializar as propriedades da mesma maneira que faríamos em uma linguagem tradicional.

// Definimos um construtor para os objetos do tipo Person
function Person (name, age, isDeveloper) {
    this.name = name;
    this.age = age;
    this.isDeveloper = isDeveloper || false;

    this.writesCode = function() {
        console.log(this.isDeveloper ? "Essa pessoa escreve código" : "Essa pessoa não escreve código");
    }
}

// Cria uma Person com as propriedades name: Bob, age: 38,
// isDeveloper: true e um método writesCode
var person1 = new Person("Bob", 38, true);

// Cria uma Person com as propriedades name: Ana, age: 32,
// isDeveloper: false e um método writesCode
var person1 = new Person("Ana", 32);

// Escreve: Essa pessoa escreve código
person1.writesCode();
// Escreve: Essa pessoa não escreve código
person2.writesCode();

Porém, ainda podemos melhorar esse código. Se você lembrar, eu falei antes que JavaScript usa uma herança baseada em protótipos. O problema com o exemplo anterior é que o método writesCode é redefinido para cada instancia do construtor Person. Podemos evitar isso adicionando o método no protótipo.

// Definimos um construtor para o objeto Person
function Person(name, age, isDeveloper) {
    this.name = name;
    this.age = age;
    this.isDeveloper = isDeveloper || false;
}

// Extendemos o prtótipo da função
Person.prototype.writesCode = function() {
    console.log(this.isDeveloper ? "Essa pessoa escreve código" : "Essa pessoa não escreve código");
    }
}

// Cria uma Person com as propriedades name: Bob, age: 38,
// isDeveloper: true e um método writesCode
var person1 = new Person("Bob", 38, true);

// Cria uma Person com as propriedades name: Ana, age: 32,
// isDeveloper: false e um método writesCode
var person1 = new Person("Ana", 32);

// Escreve: Essa pessoa escreve código
person1.writesCode();
// Escreve: Essa pessoa não escreve código
person2.writesCode();

Agora ambas as instancias de Person podem acessar uma instancia compartilhada de writesCode().

É como se no primeiro exemplo a gente tivesse uma função diferente para cada Person, ou seja, cada Person aponta para sua função. No segundo exemplo não, todas as Persons vão apontar para a mesma função, o mesmo pedaço de código com a função.

Module Pattern

Apesar de ser orientada a objetos, JavaScript faz isso do seu próprio jeito peculiar. Como não possui propriamente classes ela também não tem limitadores de acesso aos componentes da classe. Em uma linguagem como Java ou C++ você pode definir os direitos de acesso para os membros de uma classe (private, protected, public, etc.), por isso, JavaScript tem uma maneira de emular esse comportamento.

Antes de entrar nos detalhes do module pattern, vamos ver melhor o que são closures. Uma closure é uma função com acesso ao scope do pai, mesmo depois que a função pai já foi encerrada. Ela nos ajuda a emular o comportamento dos limitadores de acesso. Vejamos um exemplo:

// Nós usamos uma função invocada imediatamente
// para criar uma variada privada counter
var counterIncrementer = (function() {
    var counter = 0;

    return function() {
        return ++counter;
    };
})();

// Imprime 1
console.log(counterIncrementer());

// Imprime 2
console.log(counterIncrementer());

// Imprime 3
console.log(counterIncrementer());

Como você pode ver, nós amarramos a variável counter a uma função que foi chamada e encerrada mas ainda pode ser acessada pela função filha que faz o incremento. Como não podemos acessar a variável counter de fora da função, na pratica nós a tornamos privada através da manipulação do escopo.

Usando closures podemos criar objetos com partes públicas e privadas. A isso damos o nome de modulos e são muito úteis quando queremos esconder partes de um objeto e expor somente uma interface para o usuário do módulo. Vamos ver um exemplo:

// Através de uma closure vamos expor um objeto
// como uma API pública que faz a gestão de suas
// partes privadas
var collection = (function() {
    // private
    var objects = [];

    // public
    return {
        addObject: function(object) {
            objects.push(object);
        },
        removeObject: function(object) {
            var index = objects.indexOf(object);
            if (index >= 0) {
                objects.splice(index, 1);
            }
        },
        getObjects: function() {
            return JSON.parse(JSON.stringify(objects));
        }
    };
})();

collection.addObject("Bob");
collection.addObject("Alice");
collection.addObject("Franck");

// imprime ["Bob", "Alice", "Franck"]
console.log(collection.getObjects());
collection.removeObject("Alice");

// imprime ["Bob", "Franck"]
console.log(collection.getObjects());

A maior utilidade desse padrão é ter uma separação clara entre partes publicas e privadas de um objeto.

Como nem tudo são flores, esse padrão tem alguns problemas. Quando queremos mudar a visibilidade de um membro, precisamos alterar todo o código em que ele é usado, porque a forma de acesso é diferente para partes publicas e privadas. Outro problema é que métodos adicionados depois do objeto ser criado não podem acessar os membros privados.

Revealing Module Pattern

Esse padrão é uma evolução do module pattern descrito acima. A principal diferença é que escrevemos toda a lógica do objeto no escopo privado e então expomos as partes que queremos através de um objeto anônimo. Também podemos trocar o nome de membros privados do objeto quando os mapeamos aos membros públicos.

// Escrevemos toda a lógica do objeto como membros privados
// e expomos um objeto anônimo que mapeia os métodos que queremos
// expor aos seus membros públicos correspondentes
var namesCollection = (function() {
    // membros privados
    var objects = [];

    function addObject(object) {
        objects.push(object);
    }

    function removeObject(object) {
        var index = objects.indexOf(object);
        if (index >= 0) {
            objects.splice(index, 1);
        }
    }

    function getObjects() {
        return JSON.parse(JSON.stringify(objects));
    }

    // membros públicos
    return {
        addName: addObject,
        removeName: removeObject,
        getNames: getObjects
    };
})();

namesCollection.addName("Bob");
namesCollection.addName("Alice");
namesCollection.addName("Franck");

// imprime ["Bob", "Alice", "Franck"]
console.log(namesCollection.getNames());
namesCollection.removeName("Alice");

// imprime ["Bob", "Franck"]
console.log(namesCollection.getNames());

O revealing module pattern é uma das maneiras pelas quais podemos implementar um module pattern. As diferenças entre o revealing module pattern e as outras variantes é principalmente a maneira como os métodos públicos são referenciados. Como resultado, o revealing module pattern é muito mais fácil de ser usado e modificado, mas pode se provar frágil em certos cenários, como quando usamos os objetos em uma cadeia de heranças. As situações mais problemáticas são as seguintes:

1. Se nós temos uma função privada que faz referência a uma função pública, não podemos sobrescrever a função pública. A função privada vai continuar a referenciar a implementação privada da função e isso pode levar a bugs.
2. Quando temos um membro público apontando para um membro privado e tentamos sobrescrever o membro público de fora do módulo, as outras funções ainda vão fazer referência ao valor privado da variável, introduzindo bugs.

Singleton Pattern

Quando precisamos que exista uma única instância de uma classe, usamos o padrão singleton. Por exemplo, quando temos um objeto de configurações, não queremos criar um novo objeto cada vez que ele é chamado, mas que retorne sempre o mesmo.

var singleton = (function() {
    // valor privado do singleton inicializado uma vez

   var config;

    function initializeConfiguration(values){
        this.randomNumber = Math.random();
        values = values || {};
        this.number = values.number || 5;
        this.size = values.size || 10;
    }

    // Exportamos o método centralizado para retornar
    // o valor do singleton
    return {
        getConfig: function(values) {
            // inicializamos o singleton uma única vez
            if (config === undefined) {
                config = new initializeConfiguration(values);
            }

            // e retornamos sempre o mesmo valor
            return config;
        }
    };
})();

var configObject = singleton.getConfig({ "size": 8 });

// imprime number: 5, size: 8, randomNumber: someRandomDecimalValue
console.log(configObject);

var configObject1 = singleton.getConfig({ "number": 8 });

// imprime number: 5, size: 8, randomNumber: same randomDecimalValue // como no primeiro config
console.log(configObject1);

Como fica claro no exemplo, o número aleatório gerado é sempre o mesmo, assim como os valores de config recebidos.

É importante notar que o ponto de acesso para retornar os valores do singleton é único e precisa ser bem conhecido.

Observer Pattern

O Observer Pattern é muito útil quando queremos otimizar a comunicação entre partes separadas do sistema. Ela promove uma integração entre as partes sem que elas fiquem acopladas.

Você vai encontrar várias maneiras de implementar esse padrão, mas a mais simples é onde temos um emissor e vários observadores (observers, saca?).

O emissor vai executar todas as operações a que os observadores estão inscritos. Essas operações podem ser, inscrever um observador a um tópico, desinscrever um observador de um tópico e notificar os observadores sempre que algo é publicado em um tópico.

Uma das variantes desse padrão é o publisher/subscriber pattern, que é o que nós vamos ver nesse texto.

No padrão Observer, o emissor fica com todas as referências aos observadores e chama os métodos diretamente nesses objetos. No formato publisher/subscriber, nós temos canais que servem de comunicação entre o publisher (publicador) e os subscribers (assinantes). O publisher dispara um evento e simplesmente executa o callback enviado para esse evento.

Esse é um pequeno exemplo do padrão publisher/subscriber.

var publisherSubscriber = {}

// Nós passamos um objeto container para gerenciar inscrições
(function(container) {
    // o id representa uma inscrição única ao tópico
    var id = 0;

    // os objetos se inscrevem em um tópico ao
    // enviar um callback a ser executado quando
    // o evento é disparado
    container.subscribe = function(topic, f) {
        if (!(topic in container)) {
            container[topic] = [];
        }

        container[topic].push({
            "id": ++id,
            "callback": f
        });

        return id;
    }

    // cada inscrição tem seu próprio ID, nós vamos
    // usá-lo para remover a inscrição
    constainer.unsubscribe = function(topic, id) {
        var subscribers = [];
        for (car subscriber of container[topic]) {
            if (subscriber.id !== id) {
                subscribers.push(subscriber);
            }
        }
        container[topic] = subscribers;
    }

    container.publish = function(topic, data) {
        for (var subscriber of container[topic]) {
            // quando executamos um callback é sempre bom
            // ler a documentação para saber quais argumentos
            // são passados pelo objeto que dispara o evento
            subscriber.callback(data);
        }
    }
})(publisherSubscriber);

var subscriptionID1 = publisherSubscriber.subscribe("mouseClicked", function(data) {
    console.log("Eu sou o callback de um evento mouseClicked e esses são meus dados: " + JSON.stringify(data));
});

var subscriptionID2 = publisherSubscriber.subscribe("mouseHovered", function(data) {
    console.log("Eu sou o callback de um evento mouseHovered e esses são meus dados: " + JSON.stringify(data));
});

var subscriptionID1 = publisherSubscriber.subscribe("mouseClicked", function(data) {
    console.log("Eu sou outro callback de um evento mouseClicked e esses são meus dados: " + JSON.stringify(data));
});

// Quando publicamos um evento, todos os callbacks
// devem ser chamados e você verá três logs
publisherSubscriber.publish("mouseClicked", {"data": "data1"});
publisherSubscriber.publish("mouseHovered", {"data": "data2"});

// Nos desincrevemos de um evento
publisherSubscriber.unsubscribe("mouseClicked", subscriptionID3);

// agora só teremos 2 logs
publisherSubscriber.publish("mouseClicked", {"data": "data1"});
publisherSubscriber.publish("mouseHovered", {"data": "data2"});

Esse padrão de projeto é especialmente útil quando queremos responder a um único evento em vários lugares diferentes. Imagine que você precisa fazer vários requests a uma API e dependendo das respostas fazer outras chamadas. Você teria que aninhar vários callbacks o que te levaria ao callback hell. Usando o publisher/subscriber você resolve a situação de uma maneira muito mais simples.

O problema deste padrão são os testes. Acaba sendo difícil testar o comportamento do publisher e das listeners.

Mediator Pattern

Um padrão muito útil para sistemas desacoplados é o mediator. Quando temos várias partes diferentes de um sistema que precisam se comunicar de forma coordenada um mediador pode ser a melhor opção.

Da mesma forma que na vida real, o mediador é um objeto que vai ser o ponto central de comunicação entre os objetos.

A primeira vista os padrões mediator e publisher/subscriber parecem muito parecidos. E, de fato, os dois servem para gerenciar a comunicação entre elementos. A diferença é que o publisher/subscriber joga os eventos ao vento e esquece, enquanto o mediador vai cuidar para que cada inscrito lide com a mensagem.

Um bom exemplo de uso do mediator é um wizard. Digamos que você tenha longo processo de cadastro no seu sistema. Normalmente é uma boa ideia quebrar em passos um processo que requer muitos dados do usuário.

É uma forma de facilitar a manutenção do código ao mesmo tempo que o usuário não fica soterrado em um formulário gigantesco. Um mediador poderia gerenciar todo o wizard mostrando para o usuário passos diferentes de acordo com o que é imformado em cada etapa do processo de inscrição.

O benefício óbvio desse padrão de projeto é a melhoria na comunicação entre as diferentes partes do sistema. Da mesma forma que em um debate o mediador garante que cada um tenha sua vez de falar e o faça na hora certa.

Por outro lado, o mediador é um ponto crítico de falha, se ele parar, todo o sistema para.

Prototype Pattern

Como já falamos várias vezes, JavaScript não suporta classes na sua forma nativa. A herança é feita através de protótipos.

Nós podemos criar objetos que serão usados como protótipos dos objetos a serem gerados. O protótipo é um projeto para os objetos que o construtor cria. Quase da maneira como diferenciamos classes e objetos em Java.

Vejamos um exemplo simples desse padrão.

var personPrototype = {
    sayHi: function() {
        console.log("Oi, meu nome é " + this.name + ", e eu tenho " + this.age);
    },
    sayBye: function() {
        console.log("Tchau!");
    }
};

function Person(name, age) {
    name = name || "Fulano";
    age = age || 26;

function constructorFunction(name, age) {
        this.name = name;
        this.age = age;
    };

    constructorFunction.prototype = personPrototype;

    var instance = new constructorFunction(name, age);
    return instance;
}

var person1 = Person();
var person2 = Person("Beltrano", 38);

// imprime Oi, meu nome é Fulano, e eu tenho 26
person1.sayHi();

// imprime Oi, meu nome é Beltrano, e eu tenho 38
person2.sayHi();

Note que a herança por protótipos acaba trazendo uma melhoria em performance também, porque os dois objetos tem uma referência ao mesmo método que é implementado no protótipo, ao invés de ser implementado em cada um deles.

Command Pattern

O Command Pattern é usado quando queremos encapsular uma chamada como um objeto. É uma maneira de manter separados os contexto de quem chama e de quem é chamado.

Digamos que tua aplicação tenha várias chamadas para uma API. Imagine agora que a API mude. Teríamos que mexer em todos os pontos que interagem com a API.

É aqui que entra uma camada de abstração separando os objetos que chamam a API dos objetos que dizem quando chamar. Dessa maneira não precisamos fazer uma alteração tão grande na aplicação, porque só precisamos mudar a chamada para a API que vai ser um lugar só.

Um problema desse padrão é que como ele cria uma camada de abstração adicional, pode impactar a performance da aplicação. É preciso saber balancear performance e facilidade de edição do código.

// O objeto que sabe executar o comando
var invoker = {
    add: function(x, y) {
        return x + y;
    },
    subtract: function(x, y) {
        return x - y;
    }
}

// o objeto usado como camada de abstração quand executamos
// comandos; ele representa uma interface para o objeto
// invocador
var manager = {
    execute: function(name, args) {
        if (name in invoker) {
            return invoker[name].apply(invoker, [].slice.call(arguments, 1));
        }
        return false;
    }
}

// imprime 8
console.log(manager.execute("add", 3, 5));

// imprime 2
console.log(manager.execute("subtract", 5, 3));

Facade Pattern

o padrão Facade é usado quando queremos criar uma camada de abstração entre o que é mostrado publicamente e a implementação interna. Ele é usado quando desejamos ter uma interface mais simples.

Um bom exemplo desse padrão são os seletores para manipulação do DOM em frameworks como JQuery, Dojo e D3. Essas bibliotecas tem seletores muito poderosos, que permitem a escrita de queries complexas de forma bem simples.

jQuery(“.parent .child div.span”)

Esse tipo de funcionalidade parece bem simples, mas esconde uma complexa lógica de seleção por baixo dos panos.

Aqui de novo, sempre que temos uma abstração acima do código, acabamos tendo uma perda de performance. Na maioria dos casos essa perda é irrelevante, mas é sempre bom considerar.

Conclusão

Padrões de projeto são ferramentas primordiais de qualquer desenvolvedor JavaScript. Elas colaboram muito na hora de dar manutenção ao código, por deixarem tudo mais simples e fácil de entender.

Esse post já está bem longo, se você quiser saber mais sobre os padrões de projeto eu recomendo o clássico Design Patterns: Elements of Reusable Object-Oriented Software da Gang of Four e também o mais moderno Learning JavaScript Design Patterns de Addy Osmani. Os dois livros são muito bons e valem a leitura.

Me segue no twitter, para saber quando vai sair o próximo post 😀

Vamos supor que tu esteja no mercado com uma lista de compras. Para cada item da lista, tu coloca ele no carrinho e risca da lista. Tu consegue colocar a lista em uma folha até um dado tamanho, mas e se a lista tiver 10000 itens? E se ela for infinita?

A memória do computador é limitada, ali vão caber listas de alguns megas ou alguns gigas, mas listas muito grandes ou que você não sabe o tamanho podem quebrar a memória. Estruturas como arrays, listas e dicionários ficam armazenadas na memória, e por isso são limitadas pelo espaço disponível. Um gerador fica armazenado em outro lugar (em disco ou em banco, por exemplo) e por isso só coloca na memória o elemento que está sendo trabalhado no momento.

Geradores

Vamos análisar um problema que vai nos ajudar a entender os geradores.

i = 0
while True:
    print(i)
    i+=1

Temos um loop infinito que a cada iteração vai incrementar i em 1.

def run_till_end():
    i = 0
    while True:
        return i
        i+=1

Agora, temos uma função. Quando rodarmos run_till_end() ela vai retornar 0 e encerrar. Mesmo com o loop infinito ela encerra com o return , mas nós queremos todos os valores!

def run_till_end():
    i = 0
    while True:
        yield i
        i+=1

Usando o yield para retornar os valores, cada vez que chamarmos a função ele vai andar um passo. A cada chamada ela inicia a execução do ponto onde parou na chamada anterior. A grosso modo, funções com yield são chamadas de geradores.

run = run_till_end()
print(type(run))
print(next(run))  # 0
print(next(run))  # 1

Se rodarmos esse código, o tipo da função será generator. O primeiro print vai retornar 0 e o segundo vai retornar 1.

O mesmo pode ser feito com listas.

def run_list():
    lst = ['foo', 'baz', 'bar']
    for i in lst:
        yield i

run = run_list()
print(next(run))  # foo
print(next(run))  # baz

Mas e se chamarmos next 4 vezes na run_list ?

Na quarta chamada vamos ter o erro StopIteration . Essa exeção é jogada sempre que o gerador tiver iterado por todos os itens.

Existe outra maneira de criar geradores, quase como um list comprehension, o generator comprehension.

quadrados_list = [n**2 for n in range(5)]  # cria uma lista
quadrados_gene = (n**2 for n in range(5))  # cria um gerador

Quando você roda esse código, quadrados_list será uma lista e quadrados_gene será um gerador.

Lembrando:

• List comprehension usam colchetes [ ]
• Generator comprehension usam parenteses ( )

Análisando a memória e velocidade

Vamos análisar o uso de memória e o desempenho de listas e geradores. Para isso vamos criar os quadrados de 1 milhão de números.

No quesito memória os geradores ganham com tranquilidade, a lista ocupou 8697472 bytes enquanto o gerador apenas 128.

Como você pode ver, em termos de desempenho as coisas se invertem. Como a lista já está armazenada em memória, ela acaba sendo mais rápida (0,009 segundos) do que o gerador (0,347 segundos).

Concluindo

Demos uma olhada nos geradores (ou generators) do Python. Vimos como eles se comportam e com podem ser usados para iterar sobre listas muito grandes ou que não sabemos o tamanho total.

Além dos exemplos que usamos aqui, os generators podem ser usados também para iterarmos sobre arquivos e bancos de dados.

Eu coloquei um Jupyter Notebook no Github com os exemplos para quem quiser rodar eles online, acesse aqui.

Me segue no Twitter!

Ele usa uma linguagem simples de markdown para formatação de texto e permite o uso de várias linguagens de programação além do Python. Ele é muito bom se você quer executar código de maneira interativa, por isso é muito usado no processamento exploratório de dados, simulações numéricas, modelagens estatisticas e até machine learning.

Como o Jupyter Notebook permite essa facilidade de rodar código e tomar notas, é uma baita ferramenta para quem está aprendendo a programar em Python.

Vamos ver então como você pode usar o Jupyter Notebook com o Python na sua máquina local.

Instalando o Jupyter Notebook

Comece acessando o site do projeto jupyter.org e encontrando o botão Install the Notebook (a Jupyter oferece também o Jupyter Lab, mas não é ele o nosso foco no momento). No site você encontra a opção de acessar o Jupyter Notebook online, sem precisar instalar nada, mas com menos controle tambem.

É possível fazer a instalação de duas maneiras, via pip ou com o Anaconda.

Pip é o package manager oficial do Python, através dele você pode instalar vários outros pacotes e dependencias que vão ser necessárias nos teus projetos. Se você jpa tem o Python instalado e configurado na sua máquina, basta usar o comando pip install notebook que já vai estar funcionando.

Anaconda é um kit de ferramentas para data science que já te entrega o Python junto com várias outras ferramentas comumente usadas nessa área. Se você é novo no Python e ainda não tem um ambiente funcional, essa é uma forma fácil de ter acesso a muitas das coisas que você vai acabar usando. Acesse o site de download da Anaconda e siga as instruções lá.

Rodando o Notebook

Depois de instalado, para rodar o Jupyter Notebook apenas digite o seguinte no seu terminal

$ jupyter notebook

Você vai ver uma resposta semelhante a essa

O servidor do Jupyter Notebook vai ser iniciado e no seu navegador default você deve estar vendo uma tela como a abaixo. Se não abrir o seu navegador, tente navegar para http://localhost:8889/tree

Essa é a página inicial do seu notebook, ela é separada em 3 abas: Files, Running e Clusters. A aba default é a Files, é nela que você vai visualizar, abrir e criar notebooks.

Criando um Notebook

Criar um Jupyter Notebook é bem fácil, basta clicar em New no canto direito e selecionar Python 3 do menu. O notebook vai ser criado e abrir em uma nova aba, você deve ver algo similar a:

Seu notebook está criado, mas ainda sem título. Clicando em Untitled, no topo da página, você pode mudar o título do notebook. Quando trocar o nome dele seu notebook será salvo e será criado um novo arquivo com o mesmo nome do notebook e a extensão .ipynb. Na tela inicial do Jupyter Notebook você poderá ver o seu novo notebook com o status running.

Selecionando o notebook na aba Files aparecem algumas opções no topo, como Duplicate, Shutdown e Delete. Duplicate vai criar uma cópia do seu notebook, Shutdown para de rodar o notebook e delete apaga.

Trabalhando com o Jupyter Notebook

O Notebook é composto por diferentes células, elas ficam uma sobre a outra e podem ser de dois tipos, código e markdown.

Essa é uma célula do tipo código e você pode começar a codar diretamente em Python 3 nela. Por exemplo, escrevendo 1 + 2 e apertando ctrl + enter você vai ver aparecer o resultado logo abaixo.

Se ao invés de ctrl + enter você usar shift + enter além de mostrar o resultado, o notebook vai posicionar o teu cursor em uma nova célula do tipo código e é só continuar programando.

Para trocar de código para markdown, basta usar o menu do topo ou usar a tecla de atalho: m para mudar para markdown e y volta para código.

Uma vez em modo markdown você pode começar a digitar os textos explicativos usando código de markdown semelhante ao que usaria em um README do Github por exemplo. Aqui a IBM fez uma ótima referência com a marcação que você pode usar.

Dando o comando para executar o texto ele troca para o formato compilado. Um duplo-clique no texto e ele volta ser editável.

Modos de Edição e de Comando

A célula que você seleciona pode estar em dois modos, edição e comando. Quando você clica em uma célula, ela entra automaticamente no modo de comando e isso fica evidente pela borda azul no lado esquerdo da célula. Se você clicar na área de código a célula muda para o modo de edição e a borda esquerda fica verde.

Apertando esc no mode de edição te leva para o mode comando.

Se você quiser ver todas as teclas de atalho disponíveis no Jupyter Notebook, pode navegar pelo menu em Help → Keyboard Shortcuts.

Checkpoints

Além de salvar o notebook na última versão, você pode criar checkpoints com o estado atual do notebook e depois voltar para esses pontos quando necessário. Os checkpoints são muito úteis para testar coisas novas sem medo de estragar o que está fazendo.

Para criar um checkpoint vá em Save and Checkpoint no menu File. Para reverter para um checkpoint salvo, clique em Revert to Checkpoint no mesmo menu.

Concluindo

Agora tu já aprendeu a usar os Jupyter Notebooks e pode usar eles para rodar teus códigos Python. Muito usados em projetos de análise de dados com bibliotecas como numpy, pandas e matplotlib, os notebooks também são muito úteis para testar e validar vários outros projetos. Um uso bem interessante pode ser válidar os endpoints de uma API chamdo as funções internas direto pelo notebook.

Espero que esse tutorial te ajudado a entrar no mundo dos notebooks. Se ficou com alguma dúvida pode colocar nos comentários que eu respondo o mais rápido possível.

Me segue no twitter @pedrofullstack

Porque o Timeboxing Funciona

Existe uma coisa chamada temporal motivation theory, criada por Piers Steel e Cornelius J. König ela tenta explicar como a motivação de alguém para fazer alguma coisa muda ao longo do tempo. Por exemplo, se você tem que limpar a casa para uma festa no final de semana, segunda-feira é muito mais interessante ficar no Netflix, mas conforme a sexta se aproxima a sua motivação para começar a faxina vai aumentando até superar a vontade de ver mais um episódio de Stranger Things e te tirar do sofá.

Existe até uma formula que explica o funcionamento da motivação (e da procrastinação também):

Onde Motivation é o desejo de se atingir um resultado, Expectancy é a probabilidade de sucesso, Value é a recompensa pelo resultado, Impulsiviness é a sensibilidade do individuo ao atraso e Delay é o tempo até a realização.

No timeboxing a busca é otimizar essa equação para alcançar o objetivo de forma rápida e eficiente. Para isso é preciso adicionar um passo a mais que é a definição exata do resultado esperado, a famosa definição de pronto, DOD do inglês. Então definimos o que fazer, em quanto tempo e o que é a entrega.

Timeboxing nos eventos do Scrum

Como parte do Scrum todos os eventos geram um ou mais artefatos, essas são as definições de pronto. Eles também têm um tempo específico para acontecerem conforme a duração da sprint, veja:

Sprint

Por definição o sprint é um timebox de um mês ou menos em que o time deve entregar as tarefas definidas na planning. O tamanho do sprint vai servir de base para definir a duração dos outros eventos.

Sprint Planning

Durante a planning o time vai definir o que será entregue no final da sprint. Para sprints de 1 mês a Scrum Guide define que a planning deve durar no máximo 8 horas, para sprints menores podemos definir tempos proporcionais. Essa regra não é definitiva, o time em que trabalho usa sprints de duas semanas com plannings de duas horas, pela regra deveríamos ter plannings de 4 horas.

Daily

Independentemente do tamanho da sprint, a daily é um timebox de 15 minutos para cada período de 24 horas. Dentro da daily, os membros do time vão ter a oportunidade de acompanhar o desempenho do time e o quanto do planejado na planning vai ser realmente entregue.

Sprint Review

Um encontro para apresentar o que foi realizado na sprint, essa é uma oportunidade para reavaliar o backlog com base no feedback recebido dos stakeholders. Para sprints de um mês o tempo padrão é de 4 horas.

Sprint Retrospective

Fundamental para o aprimoramento do time a retrospectiva é um timebox de 3 horas para um sprint de um mês. No final da retro devem ser definidas ações para melhorar a qualidade do produto e do time.

Timebox Para Tarefas de Final Aberto

Uma tarefa com um final aberto pode bagunçar todo o andamento de uma sprint. Uma spike para entender um novo sistema de pagamento, por exemplo, pode ser rápida ou pode exigir o contato com outros times e até empresas terceiras para entender como tudo funciona.

Para manter esse tipo de tarefa sob controle, podemos definir um prazo para sua realização e um artefato a ser entregue no fim. Seguindo nosso exemplo do sistema de pagamento, podemos definir que a spike deve durar no máximo 6 horas e no final deveremos ter uma POC da integração.

Se ao final das 6 horas não tivermos a POC funcionando, teremos pelo menos uma indicação forte de onde conseguir as informações que ainda faltam. A sprint atual não será afetada, mas teremos novas tarefas no backlog para serem executadas na próxima sprint.

Conclusão

Entendo melhor como funciona nossa motivação em relação ao tempo e como o timebox funciona no Scrum, podemos criar usos para a ferramenta. De uma forma geral, o timebox vai te ajudar a realizar mais em menos tempo.

Não tenha medo de testar para coisas que você precisa fazer na vida. Desde limpar a casa até trabalhos para a faculdade, no Master Chef os pratos são feitos dentro um timebox e alguns ficam maravilhosos.

Quer mais conteúdo? Me segue no Twitter também :D

Eu poderia ter montado o ambiente todo em Windows, mas como todo o time já usava o Linux para o desenvolvimento iam ser necessárias muitas adaptações para tudo rodar de forma lisa. O WSL funciona muito bem no lugar de uma VM ou do Docker nesses casos, porque é mais nativo e fácil de acessar.

Instalando o Ubuntu dentro do Windows com WSL

O primeiro passo para criarmos nosso ambiente é a instalação do Ubuntu via WSL. Como o Windows Subsystem for Linux é uma feature opcional do Windows 10, vamos ter que habilita-la em nosso sistema.

Abra o Powershell como administrador (de um clique direito em cima do ícone e escolha rodar como administrador, ou algo do tipo) e rode o seguinte comando:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Seu sistema vai reiniciar, tenha paciência e depois volte para cá.

Com o WSL habilitado basta acessar a própria Windows Store e no campo de busca procurar por Linux, você vai ver todas as opções de distros disponíveis na loja.

Escolha a distro de sua preferência, Ubuntu no nosso caso, e faça a instalação. Depois de instalado é preciso abrir o terminal do Ubuntu para que ele conclua a instalação criando seu usuário e senha para o Linux, ele pode ser diferente do que você usa no Windows.

Instalação do Node.js

Para o Angular funcionar ele precisa do Node.js e eu acho que a melhor forma de instalar ele no WSL é usando o nvm. Para instalar o nvm basta rodar o comando:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

Depois disso feche e abra de novo o terminal do WSL e o nvm estara instalado, para confirmar rode

command -v nvm

E se o output for nvm ele foi instalado com sucesso.

Instale o GIT

apt-get install git

Depois de instalar o GIT, rodar nvm ls-remote vai mostrar todas as opções de versões para o npm, escolha a mais recente (hoje é 10.16.0) ou a que o seu projeto usa:

nvm install 10.16.0

Rodar node -version vai confirmar que a versão escolhida foi instalada com sucesso.

Enfim, o Angular

Agora estamos prontos para instalar o Angular. Nada é melhor do que seguir o próprio tutorial do Angular, como fazemos a seguir.

Instale o Angular cli rodando

npm install -g @angular/cli

A rigor o Angular já está instalado e pronto para ser usado. Para testar podemos criar uma aplicação básica e ver se tudo funciona como esperado.

Use o cli para criar o app rodando o comando

ng new my-app

O ng new vai te pedir varias informações a respeito do seu app, basta aceitar o default apertando enter.

Para rodar a aplicação e ver tudo operando como deve, entre na pasta do app e peça para o Angular servir a aplicação

cd my-app
ng serve -open

Se tudo correu bem o -open vai fazer o seu navegador abrir uma página no http://localhost:4200 com a aplicação padrão do Angular aberta.

VS Code Para Editar seu Código

Meu editor favorito para o Windows é o VS Code e como você vai precisar de algum editor mesmo, aqui vai o passo a passo para a instalação.

1- Comece baixando e instalando o VS Code no próprio Windows. Importante, mantenha ativa a opção de adicionar o VS Code ao PATH.

2- Depois baixe e instale o pack de Remote Development

3- No WSL rode o seguinte comando para evitar problemas com CLRF/RF no finais das linhas

git config — global core.autocrlf input

Agora se você for na pasta de sua aplicação de teste do Angular e escrever

code .

ele vai abrir o VS Code com a pasta do app aberta e pronta para suas edições.

Concluindo

Espero que você tenha conseguido acompanhar até o fim esse tutorial, em caso de dúvidas deixe sua pergunta nos comentários ou me procura no Twitter, prometo que respondo!

Abraço!

Recentemente o time em que eu trabalho foi incumbido de desenvolvo toda uma parte Novo para o sistema da empresa. Essa foi uma oportunidade muito massa de trabalhar em uma coisa do zero, envolvendo back, front, banco e serviços. A coisa ainda mais interessante que fizemos de diferente foi o user story mapping.

A maioria do povo que trabalha com desenvolvimento com certeza já ouviu falar de história do usuário, ou user Story, em inglês, mas o conceito se expande muito quando pensamos no processo de mapeamento da aplicação (ou feature) como um todo.

A ideia é a seguinte, quando queremos explicar alguma coisa para alguém, fica muito mais fácil da pessoa entender através de uma história. Então se falarmos sobre um sistema como uma sequência de acontecimentos podemos pensar em cada um desses acontecimentos como uma história separada.

Por exemplo, uma visão simplificada do Spotify nos dá o seguinte cenário, o sujeito entra no app, escolhe a música que quer ouvir e ela começa a tocar. Podemos quebrar isso em três partes:

1. Entrar no app
2. Escolher a música
3. Ouvir a música

Claro que o Spotify é bem mais complexo que isso, mas nosso exemplo fica só nessa parte.

Se fôssemos montar um mapa disso, colocaríamos em post its cada uma dessa etapas e as colamos na parede da esquerda para direita. Depois de concordar sobre a sequência das três, em baixo de cada uma podemos colocar mais detalhes, na primeira vamos ter que preencher um login e senha, etc.

No final do processo teríamos uma visão geral do comportamento do app. Em cima a histórias gerais e na segunda linha as etapas um pouco mais aprofundadas.

Nesse ponto podemos começar a pensar em caminhos alternativos, se eu não tenho cadastro, a música que eu gosto não está disponível, e outras possibilidades. Cada uma dessas alternativas precisa ir para o mapa, vamos colocando esses novos post its em baixo do “caminho feliz” que definimos no começo.

Por fim, vamos definir o que é mais importante. Traçando linhas horizontais que servirão de corte para o que será feito primeiro (não são ainda as sprints, mas uma indicação de prioridade). O resultado vai ser mais ou menos assim:

Pra que serve isso afinal?

O primeiro motivo para o uso do user story mapping parece ser o de visualizar toda a aplicação, e ele ajuda muito nisso, mas o principal é a construção de consenso. Uma das coisas mais difíceis de se ter em um projeto é consenso a respeito do que está sendo construído, cada pessoa tem uma ideia de como vai ficar no fim.

Na hora que a gente pega um post It, cola na parede e começa a debater, a ideia que cada um tem do resultado vai encontrar a dos outros e aí elas vão se unir na solução final. Quando os caras inventaram as histórias de usuário foi justamente para gerar conversas dentro do time e aparecer esse consenso, por isso elas vão num espaço tão pequeno.

O mapa de história do usuário, vai levar o time a ter, ao mesmo tempo, uma visão do todo e do resultado esperado. Isso vai dar trabalho, mas o resultado compensa.

O que vai numa história de usuário?

As histórias de usuário têm uma estrutura clássica: Eu como <pessoa que vai usar> Quero <o que quer fazer> Para <o objetivo>

A ideia dessa estrutura é mostrar de maneira simples quem é o usuário final do que vai ser desenvolvido, o que precisa ser desenvolvido e qual o objetivo final de quem vai usar aquilo. Ela pode ser adaptada de diferentes formas, mas é importante que o foco no usuário se mantenha, porque no fim das contas é ele quem vai usar o software.

Problemas nessa estrutura aparecem quando pensamos em funcionalidades que atendem partes do sistema e não um usuário, ou quando a história serve um membro da equipe como um teste de carga ou algo do tipo.

No primeiro caso, basta pensar nas partes do sistema como usuários, você pode ter um banco de dados “usando” um de-para.

O segundo caso é mais complicado, porque ele vai realmente exigir uma quebra do script. Mas ainda podemos pensar em termos de quem, o que e para que.

Não esqueça de adicionar critérios de aceitação da tarefa. São eles que vão definir se a história esta entregue ou não.

Como foi nossa experiência

Para ser sincero tivemos duas mudanças no nosso processo. No mesmo Sprint em que fizemos o user story mapping para as novas features também paramos de definir quem faria as tarefas durante a planning, deixando para fazer isso durante as dailys.

O resultado foi excelente, o mapa ajudou a espalhar o conhecimento pela equipe. A necessidade de alguém mais sênior explicando as tarefas diminuiu. Realmente floresceu a auto organização do time.

Não sei se posso falar aqui, mas esse foi o primeiro Sprint desde que eu entrei no projeto em que fechamos todas as tarefas. E muito do tempo que economizamos foi justamente com explicações que já ficaram claras para todo mundo durante a construção do mapa de histórias do usuário. E tudo fica mais legal se consideramos que teve um feriado e um dia inteiro de mapping nessa sprint.

Experimente que não vai se arrepender

Vale muito a pena testar está ferramenta. Se seu time está dependendo de algumas pessoas que detém o conhecimento, se não tem um consenso sobre o que exatamente está sendo feito ou precisa otimizar a ordem de entregas o user story mapping ajuda muito.

Nós usamos para um novo desdobramento do sistema, mas isso pode ser usado para coisas pequenas, como uma feature, e grandes, como um app inteiro. Não tem desculpa para não usar!

Se você já usou ou usa essa o User Story Mapping deixa tua experiência nos comentários, vamos conversar um pouco mais sobre isso.

Me segue no Twitter também, eu posto mais coisas de Agile lá, quando não estou reclamando da vida.

A maioria dos sites de ecommerce que conheço e em que trabalhei são construídos em cima de um arquitetura do tipo monolito. Isso significa que todo o código é construído em uma estrutura única com componentes interdependentes e interligados, é a arquitetura tradicional de frameworks como Laravel e WordPress.

Microsserviços, por outro lado é uma arquitetura de código que segue a ideia de ter as diferentes partes da aplicação funcionando como unidades independentes. Dando um passo adiante das arquiteturas modulares, aqui cada serviço pode funcionar como uma aplicação separada.

As duas opções são radicalmente diferentes, mas os micro serviços vem ganhando cada vez mais espaço junto a CTOs e gestores de produto. Isso se deve às vantagens de ter uma arquitetura que funciona com sistemas distribuídos, como escalabilidade e facilidade de colocar novos programadores no time.

Porque usar Microsserviços

É importante frisar que micro serviços não são uma tecnologia, mas um padrão de projeto. Nele cada serviço é uma unidade de lógica de negócios completamente independente, podendo inclusive ser implementada em uma linguagem diferente do resto do código. Todos os serviços são unidos por APIs versionadas e (esperasse) documentadas.

Como cada serviço é uma aplicação separada, muitos dos problemas enfrentados por ecommerces são resolvidos. Você pode, por exemplo, aumentar o número de cópias de um serviço que estão rodando para atender a demandas maiores em determinadas épocas. Outro exemplo é adicionar um novo membro à equipe de desenvolvimento, essa nova pessoa só precisa entender um pequeno serviço, e não todo o sistema, para começar a ser produtiva.

Mas nem tudo são flores

Microsserviços são como um iceberg, no topo temos os serviços bonitinhos funcionando como queremos, mas por baixo d’água existe uma infraestrutura robusta para manter tudo rodando. Coisas como, testes de integração, versionamento de código e API, autenticação, falhas na rede, logs, etc. precisam ser feitas para garantir que o sistema como um todo vai funcionar como esperado.

Por esse trabalho e custo adicionais que é preciso pensar bem se esta é a arquitetura mais indicada para o seu site. Veja que ecommerce pequenos podem ser muito bem atendidos por um monolito e conforme crescem migrar para microsserviços.

É melhor ou não é?

Lógico que eu não posso responder essa pergunta, cada caso é um caso e nenhum ecommerce é igual ao outro. Existem sites que se beneficiam muito dessa arquitetura (Amazon, por exemplo) já outros preferem manter seus monólitos.

O que você acha que funciona melhor no seu caso? Qual sua experiência com cada um?

Para mais conteúdo sobre arquitetura e desenvolvimento de software, me segue no Twitter

São diversas estratégias que levam as pessoas até você, aqui está um compilado de algumas. São cinco atitudes que você precisa tomar para começar a crescer no Instagram. Muito mais pode ser feito, mas fazer essas cinco já te coloca na vantagem.

1. Transforme seu Perfil em Comercial

Todo perfil no Instagram tem a opção de ser pessoal ou comercial. O perfil pessoal tem a vantagem de que as postagens tendem a ter um alcance maior, mas só isso. O perfil comercial, por outro lado, te da acesso a ferramentas de análise, permite colocar botões para contato e você pode impulsionar publicações para alcançar ainda mais pessoas.

O acesso aos dados da análise é crucial para montar sua estratégia. Ali você pode ver os melhores horários para postar, quais conteúdos tiveram melhor desempenho, o que o público mais gostou. A partir dessa informação você vai aprimorar o seu comportamento na rede, otimizando seu crescimento.

2. Conhece o teu Público

Isso serve para tudo, conhecer o público é chave para o sucesso. Quem é a pessoa que compra da sua marca? Quem consome seu conteúdo? Qual a idade deles? Quais são os interesses? Falam biscoito ou bolacha?

Quanto mais informação você tiver a respeito do seu público alvo melhor você vai conseguir engajar com ele. Não só nas redes sociais mas em todo o contato que a pessoa tem com a sua marca.

3. Siga os seguidores dos teus concorrentes

Uma experiência interessante é buscar pelos perfis da sua concorrência e entrar no perfil das pessoas que estão seguindo eles. Você pode seguir estas pessoas e interagir com elas para que elas eventualmente visitem o seu perfil e acabem te seguindo também.

É importante ter o cuidado de ter um perfil atrativo, porque quando as pessoas forem visitar o teu Instagram elas precisam se interessar pelo conteúdo.

Uma maneira comum de fazer isso é utilizando bots para automatizar o processo. Eu escrevi sobre isso neste post e explico os prós e contras dessa abordagem.

4. Não se esqueça das hashtags!

As hashtags do Instagram são uma das melhores maneiras de atrair novos seguidores. Uma boa seleção de hashtags ajuda seu conteúdo a se destacar e aparecer em buscas na rede.

Quanto ao número de hashtags, tente manter entre 5 e 10 por postagem. Muitas hashtags e o Instagram vai penalizar seu alcance por considerar spam e muito poucas vai limitar o teu alcance.

Que hashtags usar? Aqui, de novo, o principal é conhecer o seu público. Veja o que eles mais gostam, quem seguem, quais hashtags eles usam.

5. Parcerias com Influencers

Durante suas pesquisas de público você vai encontrar perfis que muitos dos seus clientes seguem. Fazer parcerias com esses perfis pode alavancar o seu sucesso no Instagram.

Comece por identificar perfis que tem grande abrangência entre as pessoas que você quer atingir. Siga esses perfis e comece a interagir com as publicações deles, se apresente no privado como marca para iniciar uma relação.

Você pode, por exemplo, pedir para que eles escolham um item que você vende e mandar para eles. Eles vão receber o item e fazer uma postagem a respeito, levando os seguidores deles a conhecer sua marca (lembre-se de compartilhar a postagem deles).

Outro ponto importante com o marketing de influencers é que a sua marca vai ficar associada com aquela pessoa. Por isso você tem que escolher com sabedoria com quem fazer a parceria.

Conclusão

Essas foram as cinco dicas para que você comece com o pé direito a crescer sua base de seguidores. O Instagram oferece um mundo grande de possibilidades para atingir o teu público alvo, mas é importante conhecer o público e ir atrás dele.

Uma dica bônus é seguir meu perfil no Instagram @pedrohenriquemkt

Eu também escrevo sobre marketing digital aqui :D

Durante muito tempo as pessoas que se preocupavam com a automação da força de trabalho eram os trabalhadores manuais. É muito mais fácil imaginar uma máquina substituindo uma pessoa em uma linha de montagem do que um advogado, mas hoje temos algoritmos fazendo a análise de documentos de forma infinitamente mais eficiente que advogados.

O que falta para os ChatBots fazerem mágica?

Falar que a maioria das tarefas podem ser automatizadas já é trivial o que vai ser o pulo do gato é poder falar para o computador fazer essas tarefas. Imagine simplesmente pedir para o computador fazer coisas e ele fazer exatamente o que você quer. “Computador, envie um email para o fulano dizendo …”, pode ser algo comum em um futuro muito próximo.

Na verdade, a tecnologia para que isso aconteça já esta disponível o que falta é a visão de como fazer isso da melhor maneira. Por isso que começar a pensar em termos de conversas ao invés de apps é muito importante, o número de downloads de aplicativos vem caindo, mas o uso de ferramentas de chat só cresce (olha o WhatsApp).

Combinar essas duas tendências é o passo que falta para termos bots trabalhando ao nosso lado da mesma maneira que Tony Stark trabalha com J.A.R.V.I.S.

A mudança de paradigma é muito interessante, ao invés de pensarmos o que o usuário vai fazer e como o sistema vai responder precisamos pensar na história que o usuário vai experimentar. A interação através da fala pede um nível mais refinado de UX do que estamos acostumados, mas aproxima mais os participantes.

Nosso colega o ChatBot

Estão começando a aparecer em diversas frentes iniciativas de trazer assistentes robôs para o local de trabalho. A primeira vista parece só mais um passo no sentido de automatizar os processos, mas a diferença é que agora tudo acontece de forma assíncrona.

A pessoa não fica interagindo com o bot, ela da a ordem e vai fazer outra tarefa enquanto o robô faz o que foi pedido (veja os bots de redes sociais, por exemplo). Não estamos criando ferramentas para fazer o que já fazemos mais rápido, são ferramentas para fazer mais coisas ao mesmo tempo.

Conclusão

Ainda não chegamos no momento que o bot é capaz de substituir o ser humano por completo, somos os únicos capazes de fazer o “algo a mais”. Por mais avançada que esteja nossa tecnologia ela ainda se restringe ao que está programada para fazer e segundo alguns teóricos essa vai ser sempre uma restrição.

Se queremos nos manter trabalhando em um mundo cada vez mais dominado pelas máquinas precisamos aprender a colocar esse fator humano no que fazemos. Não basta desempenharmos nossas funções como robozinhos, temos que dar o próximo passo, enquanto o bot fica fazendo o trabalho chato e automatizável temos tempo de olhar para as pessoas ao nosso redor e estender a mão.

O que você acha disso tudo? Comenta aí em baixo que nosso bot te responde (brincadeira, isso eu faço questão de fazer).

públicado primeiro no blog ;)

A Inevitabilidade dos ChatBots was originally published in Pedro Henrique on Medium, where people are continuing the conversation by highlighting and responding to this story.

Outro dia eu estava conversando com um amigo no WhatsApp e ele me contava que queria começar a fazer lives no Facebook. Lives são uma maneira ótima de gerar engajamento e ter mais pessoas olhando teu conteúdo, tanto no Facebook quanto no Instagram.

Perguntei para ele o que estava faltando para começar e ele disse que estava se preparando para comprar uma GoPro por R$2.000,00. Minha resposta foi: “Tu tá bebendo!? Como tu vai pagar 2 mil em uma câmera para fazer lives que tu ainda nem sabe são vão dar resultados de verdade?”

O que ele queria era fazer uma live com “qualidade profissional”, atingir um padrão arbitrário que ele mesmo definiu com o equipamento que ele acha que precisa. O pior é que como ele não pode comprar a GoPro agora, o projeto vai ficar engavetado e talvez nunca saia do papel.

Vai lá e Faz!

Me incomoda muito esse tipo de pensamento porque muita gente esbarra nesses padrões de qualidade e acabam nunca fazendo nada. Não faz sentido ficar buscando a perfeição em um mundo em que as coisas duram no máximo 24h.

Tu está fazendo um post não um filme de milhões de dólares!

Imagina a quantidade de boas ideias que não são executadas porque as pessoas ficam esperando o momento ideal, a maneira ideal, que tudo esteja perfeito para colocar em prática.

Não estou dizendo que é tudo bem fazer de qualquer jeito. A qualidade do conteúdo ainda é importante.

Fazer uma live com o celular funciona perfeitamente, mas o que tu vai dizer nessa live tem que valer a pena. As pessoas não assistem porque foi bem filmado, mas porque tem conteúdo.

O Conteúdo é rei

O que vai ser dito ou mostrado tem que ser importante para tua audiência. É o conteúdo que vai manter as pessoas engajadas e consumindo o que tu produz.

Essa parece ser a parte mais difícil, pensar no que vai falar, mas na verdade não é. Tu ja conheces teu negócio, sabe como as coisas funcionam porque tu estás fazendo. Se tu é corretor de imóveis, por exemplo, já conhece o mercado e alguns imóveis, então pode falar com facilidade a respeito.

Mesmo quem está começando, essa é a oportunidade de estudar um pouco mais o mercado em que está iniciando e conhecer mais os detalhes para poder passar adiante. Inclusive mostrar que está começando e convidar a audiência para aprender junto pode ser uma coisa poderosa.

Conclusão

Tu não precisa ir atrás do equipamento perfeito para fazer teus vídeos, tirar fotos, etc… O que importa é ter conteúdo que valha a pena ser consumido. Pensa nos teus clientes e pensa no que eles gostariam de ouvir, depois vai lá e enrtega isso para eles.

Sempre mantém a tua própria voz, tem que ser autentico. Pensa na audiência, eles que precisam gostar. O resto é dale!

Meu amigo da história acabou desistindo da GoPro e comprou uma webcam full HD por R$100 para começar com as lives. Ele ainda não colocou em prática, mas com certeza está bem mais perto que antes.

Este artigo saiu primeiro em nosso site, dá uma conferida lá para ver outras públicações :)

Feito é Melhor que Perfeito was originally published in Pedro Henrique on Medium, where people are continuing the conversation by highlighting and responding to this story.