Desenvolvendo a criatividade colaborativa no ambiente de trabalho

No mês de agosto tivemos uma atividade diferente na Mobiltec, com o objetivo de estimular a criatividade dos colaboradores. Isso porque é da natureza do ser humano ser criativo. No mundo corporativo não poderia ser diferente. As empresas buscam inovar, atender o cliente de maneira diferente para encantá-lo, criar promoções, formas de pagamento, modos de fidelizar e de atrair novos clientes.

Com o desenvolvimento científico e tecnológico, em seu sentido amplo, o conhecimento tem se tornado obsoleto em um período muito curto de tempo, exigindo uma aprendizagem contínua e permanente. Como é impossível prever o conhecimento que será necessário no futuro, torna-se necessário o desenvolvimento de habilidades que ajudem as organizações a se adaptarem com facilidade ao novo e às circunstâncias marcadas pela mudança, pela incerteza e pela complexidade. É em razão deste contexto que a criatividade tem sido apontada como o recurso mais valioso que as organizações dispõem para sua sobrevivência no próximo milênio.

“Por mais que se invista em tecnologia, a fonte geradora de ideias não são as máquinas, mas o homem.” 

Um dos pontos que devemos tratar quando se fala de criatividade é desmistificar ela como algo inato, praticamente uma dádiva dos deuses. Nesse contexto, o Let’s talk de agosto buscou exatamente isso, mostrar que o processo criativo se apresenta de forma diferente para cada pessoa. Ninguém vira gênio de uma hora para outra e nenhum gênio tem ideias brilhantes todo santo dia.

Mas há muitos pontos em comum no comportamento de grandes mentes criativas, não importa a área, não importa quando viveram. E há explicações científicas para o funcionamento desses cérebros que parecem fontes inesgotáveis de ideias. E ter ideias é juntar os pontos. Para juntar pontos é preciso ter referências e neste ponto começamos a entender que não existe cultura inútil, que aquele livro ou filme que foi visto hoje, pode servir de insight no futuro para um problema e que viajar e conhecer novas culturas pode elevar isso para outros patamares. Também vimos que enquanto absorver a cultura ao nosso redor é o combustível da criatividade, a paixão pelo o que fazemos é o veículo que nos leva a criar maravilhas.

Após a apresentação das bases do processo criativo foi lançado o desafio para os participantes: Criar uma pintura abstrata para nossa exposição coletiva, sendo que cada um poderia usar apenas uma cor e com apenas 15 minutos para isto.

Durante a dinâmica as folhas que deveriam ser pintadas ficaram dispostas sobre a mesa e cada um deles ganhou um pincel e uma única cor distinta que poderia usar.

tintas

Preparação para o Let's Talk Criatividade Colaborativa

Para conseguirem cumprir a tarefa eles circulavam ao redor da mesa, indo de tela em tela, observando o que havia sido feito e dando sua contribuição.

E neste ponto vimos que não somos criativos sozinhos, que mesmo numa situação tão difícil como esta, a junção das cores que cada um poderia contribuir criaram não um quadro, mas dez pinturas abstratas lindas.

Abaixo, a montagem dos trabalhos coletivos em um único painel.

Como maior ganho, vimos que quando pensamos sozinhos, somos capazes de chegar a um resultado mais linear, porém previsível. Já quando o trabalho é somado às ideias de outra pessoa, o resultado passa a ser imprevisível, gerando algo que dificilmente poderíamos fazer sozinhos. A pintura foi apenas uma forma de ilustrar e permitir a vivência. Porém, percebemos nas situações do dia a dia como a criatividade colaborativa se faz necessária, não apenas para produzirmos resultados melhores, mas principalmente para gerarmos soluções inovadoras.

Escrito por Daniel Teixeira

Documentação Para ASP.NET Web API com Swagger-Swashbuckle

Apesar de extremamente importante, a documentação de APIs não costuma ter a atenção que merece. Uma documentação bem feita aumenta as chances da API ser adotada por outros desenvolvedores e diminui custos de suporte (já que o desenvolvedor-cliente terá mais condições de resolver eventuais problemas sozinho).

O Swashbuckle é um pacote para projetos WebAPI que faz a geração automática de documentação. Para isso ele utiliza a classe ApiExplorer e o framework para geração de documentação de APIs Swagger. A classe ApiExplorer gera meta-informações sobre os métodos de todos os ApiControllers do projeto enquanto o Swagger exibe estas informações em uma interface bastante amigável através do módulo Swagger-UI.

Utilizando o Swashbuckle

Para demonstrar o uso do Swashbuckle, criei um projeto ASP.NET Web Application chamado Swagger e selecionei a opção Web API. Este projeto possui um controller de exemplo chamado ValuesController que será utilizado para demonstrar como documentar a sua API. Depois de criado o projeto, instale o pacote Swashbuckle através do NuGet Manager ou diretamente pelo Package Manager Console com o seguinte comando:

Install-Package Swashbuckle

Apenas com a instalação deste pacote já temos uma versão inicial de nossa documentação pronta para uso. Compile o projeto e acesse a URL http://localhost:[PORTA]//swagger/ui/index. Você deverá ver algo como a figura abaixo:

Veja que todos os serviços de nossa API (definidos em ValuesController) podem ser analisados de forma fácil em uma interface agradável. Além disso, é possível fazer requisições de teste especificando-se os parâmetros adequados para cada tipo de serviço e clicando no botão Try it out!.

Melhorando a descrição de cada serviço

O Swagger pode utilizar comentários XML para complementar as informações mostradas na figura acima. Isto facilita a atualização da documentação pois assim que um serviço for modificado e seus comentários forem atualizados a documentação da API também estará atualizada. Fiz algumas modificações no método POST de ValuesController e adicionei comentários conforme pode-se ver na figura abaixo (não esqueça de remover o atributo [Authorize] aplicado à classe):

public class ValuesController : ApiController {
   // GET api/values
   public IEnumerable<string> Get()
   {
      return new string[] { "value1", "value2" };
   }

   // GET api/values/5
   public string Get(int id)
   {
      return "value";
   }

   /// <summary>
   /// Verifica se a PropriedadeA é um valor entre 0 e 100. Retorna a mensagem contida em PropriedadeB
   /// </summary>
   /// <remarks>A PropriedadeA com valor menor que zero é considerada inválida.</remarks>
   /// <response code="400">Bad request</response>
   /// <response code="500">Internal Server Error</response>
   public IHttpActionResult Post([FromBody]Value value)
   {
      if (value.PropriedadeA < 0)
         return InternalServerError();

      if (value.PropriedadeA > 100)
         return BadRequest();

      return Ok(value.PropriedadeB);
    }

    // PUT api/values/5
    public void Put(int id, [FromBody]string value)
    {
    }

    // DELETE api/values/5
    public void Delete(int id)
    {
    }
    }

Ao verificar novamente a página de documentação você observará que nenhuma mudança apareceu. Para que o Swagger possa utilizar os comentários na documentação é preciso configurar o Swashbuckle para que utilize comentários XML. Para fazer isso, abra o arquivo SwaggerConfig.cs (que foi criado na pasta App_Start durante a instalação do pacote) e remove os comentários da seguinte linha:

c.IncludeXmlComments(GetXmlCommentsPath());

Agora, edite esta linha para:

c.IncludeXmlComments(System.String.Format(@"{0}\bin\Swagger.XML",System.AppDomain.CurrentDomain.BaseDirectory));

Conforme explicado no próprio arquivo config, este comando indica ao Swashbuckle que leia os comentários do arquivo SwaggerXML que deverá estar dentro do diretório bin do nosso projeto. Para gerar este arquivo, acesse as propriedades do seu projeto e clique na aba Build. Na seção Output marque a opção XML documentation file e certifique-se de que o caminho do arquivo é bin\Swagger.XML.

Compile o projeto e acesse a documentação. Veja que agora o método POST possui novas informações obtidas dos comentários.

O Visual Studio vai exibir um warning para todos os métodos que não estiverem com comentários XML – Missing XML comment for pubicly visible type or member. Isto pode ser bem incômodo se o projeto já possuir muitos métodos. Para remover estes warnings acesse novamente as propriedades do projeto na aba Build. Na seção Errors and warnings insira 1591 no campo Suppress warnings. Será necessário compilar o projeto novamente para que os warnings desapareçam.

Conclusão

Com este tutorial você conseguirá gerar dinamicamente a documentação para sua API e ao mesmo tempo ter uma interface para criar requisições de testes. O Swashbuckle oferece diversas configurações avançadas que permitem integrar na documentação informações relativas ao método de autenticação/autorização utilizados e customização da página HTML gerada (veja a documentação completa na página no Git do projeto Swashbuckle.

 

Escrito por Rafael Companhoni

Um pouco mais de Knockout.js

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

Agora, o objetivo é apresentar um exemplo com mais elementos do Knockout. Vamos criar uma página para cadastrar contatos em uma agenda, exibindo os já cadastros na mesma tela. Não iremos implementar a operação de inserção em uma base de dados real, já que o exemplo é meramente ilustrativo.

Para começar, adicionamos o javascript da bilbioteca, como segue.

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

Nosso formulário irá conter três campos: nome, telefone e categoria. Os campos nome e telefone serão obrigatórios. O campo categoria será uma lista de categorias, como família e amigos.

Em seguida, vamos apresentar a estrutura criada na view-model. Inserimos uma lista de categorias, uma estrutura que irá armazenar os dados do novo contato e uma lista de contatos, que será utilizada para exibir na tela os contatos já cadastrados.

function ViewModel() {
      var self = this;

      self.categories = ko.observableArray([ "Família" , "Amigos" ]);

      self.newContact = ko.observable({
                             fullName: "",
			     category: "",
			     phone: ""
			});				

      self.contacts = ko.observableArray([]);
}

Também iremos inserir na view-model um campo para exibir uma mensagem de erro quando apropriado.

self.errorMessage = ko.observable("");

Em seguida, vamos criar o formulário, conforme segue.

<p>Nome Completo:
      <input type="text" data-bind="value: newContact().fullName"> *
</p>

<p>Categoria:
      <select data-bind="options: categories,
                         optionsCaption: 'Escolha...',
                         value: newContact().category">
      </select>
</p>

<p>Telefone:
      <input type="text" data-bind="value: newContact().phone"> *
</p>

Também precisamos inserir o botão para incluir o contato na lista, além da mensagem de erro, que está inicialmente vazia.

<button data-bind="click: addContact">Adicionar</button>

<p style="color: red"><span data-bind='text: errorMessage'/></p>

Na view-model, implementamos o método para inserir o contato da lista, incluindo a validação, que irá preencher a mensagem de erro quando apropriado.

self.addContact = function() {

      if (self.newContact().fullName == "" || self.newContact().phone == "")
            self.errorMessage("Campos marcardos com * são obrigatórios.");
      else
      {
            self.errorMessage("");

            self.contacts.push({
                 fullName: self.newContact().fullName,
 		 category: self.newContact().category,
		 phone: self.newContact().phone
	    });
      }

};

Para exibir os contatos já cadastrados, incluímos na view uma tabela, que será preenchida, através do binding, com uma linha para cada elemento da lista de contatos.

<h3 data-bind='visible: contacts().length > 0'>Meus Contatos</h3>

<table data-bind='visible: contacts().length > 0' border="1">
      <thead>
            <tr>
                  <th>Nome Completo</th>
		  <th>Categoria</th>
		  <th>Telefone</th>
	    </tr>
      </thead>
      <tbody data-bind='foreach: contacts'>
            <tr>
	          <td width="200px"><span data-bind='text: fullName'/></td>
		  <td width="200px"><span data-bind='text: category'/></td>
		  <td width="200px"><span data-bind='text: phone'/></td>
	    </tr>
      </tbody>
</table>

Por fim, aplicamos os bindings ao carregar a página.

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

O resultado é exibido na imagem abaixo, quando clica-se no botão “Adicionar”.

Quando algum campo obrigatório não é preenchido, a mensagem de erro aparece, conforme figura abaixo.

O objetivo desse post foi apresentar novos elementos do Knockout. Novamente podemos perceber os benefícios apresentados no post de introdução, como atualização dinâmica e o fato de não precisarmos de nenhuma outra biblioteca, além do Knockout. Então, o que achou? Qualquer dúvida ou sugestão, deixe nos comentários.

Escrito por Paula Burguêz.

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

Image

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

Confira abaixo:

Nomenclatura:

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

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

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

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

Funções:

- Funções geralmente devem conter um verbo.

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

Agora, observe este outro caso:

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

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

Módulos:

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

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

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

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

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

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

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

Ferramentas:

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

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

Escrito por Andrey Donelli e Fagner Carvalho

Retrospectiva Ágil: O Test-Driven Drawing

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

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

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

Desafio: Test-Driven Drawing

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

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

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

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

Análise dos resultados!

 

Primeira iteração

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

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

Um dos resultado da primeira iteração.

 

Segunda iteração

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

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

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

Um dos resultados da segunda iteração.

 

Momento Retrospectiva

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

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

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

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

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

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

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

Escrito por Eduardo Klein