maxresdefault

A Quarta do Wear

Eu e o Moto 360

Quem me acompanha nas redes sociais já sabe de minha saga para comprar um Moto 360! E você pensa que eu queria comprar ele só para dizer que tenho um? É, tudo bem, admito que foi por isso também. :) Mas como bom desenvolvedor nerd e sempre fã das tecnologias do Google, eu queria programar nessa plataforma e não tem motivação maior e melhor do que ter um dispositivo em mãos, certo? Claro que sim!

O que eu acho dos Wearables?

Os Wearables são, em minha humilde opinião, um caminho sem volta. Muita gente criticou os smartphones e/ou tablets, alegando que eram uma moda passageira. Como todo mundo viu, quebraram a cara feio. Vejo muita gente criticando os smartwatches, com alegações do tipo “sem utilidade”, “desnecessário”, “funcionalidades bobas”, “só pra tirar onda”… e vão quebrar a cara da mesma maneira. O mais engraçado é que algumas desses críticos já usaram ou usam um relógio cuja única funcionalidade é mostrar as horas. haha! :P

Eu admito que nunca usei relógios de pulso e o motivo era bem simples: depois dos smartphones, passei a encarar os relógios como apenas um acessório estético. A partir dos smartwatches, entretanto, isso tende a mudar, pois agora não é apenas uma questão de olhar as horas. Os smartwatches lhe trazem informações relevantes, contextualizadas e de forma extremamente prática, sem necessidade de puxar um celular do bolso.

Vamos Desenvolver?

Bom, mas porque cargas d’água eu fiz esse post cheio de blá blá blá? É para convidar você, caro amigo desenvolvedor que reside em Salvador e RMS, para estudar o desenvolvimento de aplicativos para Android Wear junto comigo. No dia 26 de novembro de 2014 estaremos eu e Wilson no Salvador Shopping no bar Chalezinho, às 19:00, esperando por você. Vamos conversar um pouco sobre essa plataforma, instalar o ambiente de desenvolvimento, compartilhar ideias de aplicativos e, quem sabe, já iniciar a desenvolver alguma coisa?

Eu e Wilson já estamos com um Moto 360 em mãos e levaremos para lá. Aos curiosos, podem ir lá dar uma sacada e conversar junto com a gente. Não será nada formal. Ao contrário, será totalmente informal. Sem planejamento. Vamos sentar na mesa, bater um papo e trocar ideias! Estão todos convidados para o primeiro Quarta do Wear, que será contínuo! Espero vocês lá! Não perdaum!

restinpractice1

API RESTful

A onda de desenvolvimento de APIs está com força total, já observou? O assunto está em alta e muita gente está tentando entender o que é uma API, como desenvolver uma, quais as melhores práticas, qual a melhor linguagem, qual o melhor framework… Mas, por que APIs está tão em alta assim? Em minha humilde opinião, dois fatores são muito importantes para isso. O primeiro motivo são os dispositivos móveis, que ganharam uma força tremenda e praticamente todo sistema, por mais simples que seja, precisa ter uma versão mobile.

Neste cenário, é óbvio que não vamos construir um sistema “auto-contido” no dispositivo móvel. Todo bom desenvolvedor mobile sabe que esse tipo de aplicativo é apenas uma “casca”, uma interface para um sistema que está rodando em um backend, provavelmente na nuvem. O aplicativo móvel, então, se comunica com esse backend através de uma API, exibindo ou atualizando dados. O segundo fator são as redes sociais, exatamente porque elas são parte de nossas vidas e quase todo aplicativo desenvolvido hoje em dia requer algum tipo de interação mínima com uma rede. E essa interação é feita sempre através de APIs. Juntando esses dois fatores e, obviamente, muitos outros, temos de volta esse hype de APIs. Eu disse de volta?

Claro! Ou você não sabia que API é só um jeito diferente de chamar Web Services? Esse nome lhe lembra de algo? Talvez SOAP? Talvez RMI? Pois é. Nada de novo no quadrante! A única coisa que de fato é nova em tudo isso é a forma como as atuais APIs são construídas. Deixe-me lhe explicar um pouco: antes essas mesmas APIs eram construídas usando, por exemplo, o protocolo SOAP. Entretanto, o SOAP é um protocolo extremamente pesado. Ele define sua própria sintaxe e semântica e usa o HTTP apenas para transportar seu próprio pacote para um destino.

O SOAP também se baseia na ideia de RPC – Remote Procedure Call e, por isso, tem uma semântica diferente das APIs atuais. No SOAP, você imagina que existem objetos remotos e que você quer chamar métodos desses objetos, diferente das APIs RESTful, onde você tem recursos e operações executadas nesses recursos.

Enfim, o SOAP é um exemplo prático da má utilização do protocolo HTTP, que se torna um mero burro de carga. O SOAP, e muitos outros protocolos, não usam o HTTP ao máximo, com todas as suas propriedades e possibilidades. Resulta que o SOAP não é ideal para a comunicação com dispositivos móveis. Aliás, é horrível. Experiência própria.

Uma resposta às APIs SOAP são as APIs RESTful, que seguem, ou tentam seguir, os princípios REST descritos por Roy Fielding. APIs RESTful são mais leves e se encaixam perfeitamente no mundo Web. Elas usam as características do HTTP em sua plenitude. APIS RESTful não definem um protocolo próprio, pois o HTTP é só o que elas precisam. As APIs RESTful se moldam ao mundo Web, onde temos recursos (uma página, um arquivo, uma música, um vídeo…) e operações sobre esses recursos (visualizar, editar, apagar…). APIs RESTful são simples, fáceis de usar e criar, seguras, leves e elegantes.

Caso você esteja apenas iniciando neste mundo, sugiro que leia inicialmente o livro REST in Practice – Hypermedia and System Architecture. Link para a Amazon. É um excelente livro e que vale cada centavo gasto!

journodevswap

Comunidades de Desenvolvedores

“Tem tanta tecnologia, não sei o que estudar!”. Eu já ouvi essa frase um montão de vezes e vinda quase sempre de estudantes de computação que estão preocupados com a enxurrada de siglas e possibilidades que existem na nossa área. Enquanto estamos cursando a faculdade, já estamos também nos preocupando em como vamos nos inserir neste mercado. Estudo Java para conseguir um emprego legal? Será que Ruby tem mercado? Será que é importante eu aprender como usar a Nuvem da Amazon? Por que não Python? Android ou iOS?

Infelizmente, em minha humilde opinião, esse cenário é agravado ainda mais pelo nosso modelo de ensino vigente, que nos impõe a escolha de uma profissão exatamente no momento de nossas vidas em que temos mais dúvidas! Já foi difícil escolher em qual faculdade entrar e, agora que escolhi computação e desenvolvimento, você ainda me diz que tem Java, Python, Frameworks, Nuvem, Android, iOS, Mobilidade, J2EE, Ruby, API, Mainframe… aaaaaaaahhhhh! É, meu caro, no início isso é desesperador mesmo. Eu já passei por isso e também fiquei tonto em ver tantas siglas e possibilidades de carreira.

Só que no decorrer desses quase 20 anos de “militância” no mundo da tecnologia, algumas coisas começaram a ficar mais claras para mim. Aprender uma tecnologia é importante. Tornar-se referência em algo também. Mas tem algo que acho ainda mais importante e que gostaria de compartilhar com vocês.

A dica é simples: dê mais atenção às comunidades de desenvolvedores de sua região. Dê mais atenção aos eventos em sua área, principalmente aqueles feitos por pessoas compromissadas em desenvolver a comunidade local. Quando você está em contato com pessoas inteligentes e focadas, você tende a crescer junto, absorvendo os conhecimentos dessas pessoas. Só que mais importante que absorver, é também ser um difusor de conhecimentos. Isso é importante para que você não apenas seja um sanguessuga, mas um potencial “broadcaster” desses conhecimentos que você adquire.

Mesmo em nossa área, onde temos que trabalhar diariamente com máquinas, as pessoas ainda são o fator mais importante. É com pessoas que você forma sua rede de contatos. É com pessoas que você adquire conhecimentos de forma mais rápida, divertida e agradável. É com gente que você marca aquela cervejinha e lorota após um evento sinistro onde você aprendeu um monte de coisa legal. É nesses eventos que você se mantém atualizado, mesmo que por alto, sobre o que está acontecendo. É nesses eventos e comunidades que você encontra tecnologias que pode se tornar um Jedi de forma mais fácil, divertida!

As comunidades são um fator chave, de extrema importância, para o ecossistema de desenvolvedores de uma região. É nos eventos que essas comunidades fazem que você forma amizades. É nesses eventos que você faz seu networking, demonstra suas habilidades para o mercado, torna-se conhecido, torna-se um difusor de ideias e alguém que todos querem ouvir. Dê mais atenção a nossas comunidades locais! Sério! Isso é importante não só para você, mas para a seu estado, cidade, bairro, rua…

ruby

APIs RESTful com Grape – Parte 1

Não é novidade para ninguém qual é a minha linguagem de programação favorita ultimamente. Ruby, oras! Provavelmente, também não é mais novidade para ninguém que venho focado em um único assunto: desenvolvimento de APIs RESTful. Inclusive, fazendo palestras aqui em Salvador. Então, como juntar esses dois mundos (Ruby + APIs)? A resposta é Grape! Um framework espetacular, que provê uma DSL muito simples e que facilita brutalmente a vida dos desenvolvedores de APIs.

Entretanto, percebi um probleminha! Não encontrei um tutorial sequer na Internet, sobre esse assunto, escrito em português ou espanhol. Péssimo! Portanto, meu objetivo aqui é escrever uma série de publicações sobre como instalar, configurar e usar o Grape para criar suas APIs. Primeiro, será um post em português, depois, me arriscarei a escrever em espanhol também. Será duplamente útil, porque terei a oportunidade de por em prática meus estudos de espanhol. :)

API do Bebum

Nosso projeto será uma API para um sistema que disponibilizará informações sobre cervejas. Começaremos com apenas dois modelos: Cerveja e Tipos de Cervejas. Futuramente, poderemos avançar, incluíndo mais modelos e incrementando nossa API! Todo o código que vocês verão aqui estará no Github, no endereço https://github.com/marloncarvalho/bebum-api.

Preste atenção que estamos seguindo rigorosamente (ou o máximo que pudermos) o modelo REST para a criação de APIs. Observe também que estou criando Tags no repositório com os nomes das partes de cada artigo. Por exemplo, teremos a Tag Parte 1, Parte 2 e assim por diante!

Montando seu Ambiente

Sou fã de Mac de longa data, portanto, vou focar basicamente nesta plataforma. Mas, como Mac é um *NIX, a maioria das coisas que farei aqui são replicáveis em um ambiente Linux. Quanto aos usuários Windows… bom, aí não tenho muito a ajudar, pois já tem 10 anos que não uso esse ambiente. Inicialmente, você precisa ter o interpretador Ruby instalado. No meu caso, eu uso o RVM – Ruby Version Manager para esta tarefa. O RVM instala e gerencia as versões do Ruby que você tem em sua máquina. Sugiro fortemente usá-lo!

Instalando o Ruby com o RVM

Para instalar o RVM, conforme descrito na página deles, basta digitar no console:

\curl -sSL https://get.rvm.io | bash -s stable

Depois disso, vamos instalar o Ruby na versão 2.1.2 usando o comando:

rvm install 2.1.2

Com o Ruby instalado, vamos agora instalar o Gem do Grape digitando no console:

sudo gem install grape

Pronto, seu ambiente está montado para nosso primeiro projeto com Grape. Fácil, não?

Estrutura do Projeto

Eu poderia começar com uma estrutura extremamente enxuta, mas seria simplista demais e já existem dezenas de artigos em inglês ensinando a usar o Grape que já fazem isso, então… Nosso próximo passo agora é montar a estrutura do nosso projeto. Crie um diretório qualquer em sua máquina e monte uma estrutura de diretórios semelhante à da imagem abaixo. Você também tem a possibilidade de baixar essa estrutura direto do nosso repositório.

Estrutura detalhada de diretórios do nosso projeto.

Estrutura detalhada de diretórios do nosso projeto.

Esta é uma estrutura que eu sugiro, mas não significa que você deve utilizá-la sempre. Fique à vontade para modificá-la, conforme suas necessidades. Outro detalhe digno de nota é que ainda faltam alguns diretórios nessa estrutura. Por exemplo, ainda precisamos dos diretórios db e spec, mas faremos isso nos próximos artigos.

Nesta estrutura, o diretório app conterá todas as classes relacionadas ao negócio da nossa aplicação. Este diretório é subdividido em api models, onde api manterá somente as classes responsáveis em manter a lógica da nossa API RESTful e models conterá as classes de modelo, onde estarão, de fato, nossas regras de negócio.

Já o diretório api é subdividido em outros dois subdiretórios, chamados v1 v2. Esta divisão é interessante para facilitar a criação de novas versões da nossa API. Observe que tanto dentro de app, como dentro de v1v2, existe um arquivo chamado base.rb. Eles estão aí para unir em um único ponto todas as APIs que disponibilizaremos. Não se preocupe se ainda está confuso, pois detalharemos esses arquivos com cuidado a seguir. Dentro dos diretórios v1 v2 ainda temos uma pasta entities, que será responsável em manter as classes que irão expor os dados do nosso sistema em um formato de recursos.

Finalizando, o diretório model não tem nenhum subdiretório. Todos os demais arquivos são velhos conhecidos de todo programador Ruby e não vou detalhá-los aqui!

Modelos

Vamos nos focar agora na pasta models, onde temos, até este momento, apenas um arquivo chamado model.rb. Este arquivo contém as nossas classes de modelo. Obviamente, você pode, caso prefira, separar as classes em arquivos distintos. Talvez façamos isso no futuro, entretanto, para simplificar, vamos deixar em apenas um arquivo.

module Models

   # Cervejas.
   class Cerveja
      attr_accessor :id, :nome, :tipo
   end

   # Tipos de Cervejas
   class Tipo
      attr_accessor :id, :nome
   end

end

Observe que são duas classes extremamente simples, ainda sem nenhuma lógica de negócio associada e também sem as informações de persistência. Vamos incrementá-las no futuro, entretanto!

Estrutura Geral da API

Vamos agora fazer nossa primeira API funcional. Vamos iniciar analisando a pasta api. Observe o arquivo base.rb. Ele é extremamente simples, pois serve apenas para agrupar TODAS as versões que estamos disponibilizando da nossa API. É óbvio, entretanto, que normalmente liberamos apenas duas versões por vez. Mas, caso seja necessário, esta estrutura nos permite disponibilizar quantas versões acharmos necessárias.

require 'api/v1/base'
require 'api/v2/base'

module API

   class Base < Grape::API
      mount API::V1::Base
      mount API::V2::Base
   end

end

Este arquivo tem um módulo chamado API e dentro dele há uma classe chamada Base que estende de Grape::API. Logo em seguida, montamos as APIs que queremos exibir. No nosso caso serão API::V1::Base e API::V2::Base. Como você deve estar imaginando, essas classes estão definidas nos arquivos /app/api/v1/base.rb /app/api/v2/base.rb. São duas versões da mesma API!

Agora, vamos bisbilhotar o arquivo /app/api/v1/base.rb. Ele tem um pouco mais de informações. Inicialmente, continuamos criando o módulo API, mas agora temos outro módulo dentro dele, chamado V1. Depois, definimos a classe Base, que monta as APIs de Cervejas e Tipos. Essas duas APIs estão definidas nos arquivos api/v1/cervejas.rb api/v1/tipos.rb.

Também definimos algumas informações importantes sobre essa API. Definimos que a versão da API será obtida através do cabeçalho Accept do HTTP. Para que esta versão da API seja invocada, o cabeçalho Accept deverá estar escrito assim: application/vnd.alienlabz-v1+json. Isto é um padrão, não se preocupe em entender os motivos de ele estar definido assim. Obviamente, caso queira acessar outra versão da API, basta trocar o v1 por v2, por exemplo.

Não entraremos em detalhes da estrutura do diretório v2, pois ele está exatamente da mesma forma que o v1, já que ainda não temos nenhuma intenção de lançar uma versão 2.0 da API.

API de Tipos de Cervejas

Analisemos agora o arquivo /api/v1/tipos.rb. Ele inicia, como deveria ser, com a definição dos módulos APIV1 logo em seguida cria a classe Tipos herdando de Grape::API. Agora a mágica começa a acontecer. Observe a definição do bloco resources. Usamos o símbolo :tipos para criar o bloco de recursos referentes ao recurso tipos. Isto significa que teremos uma URL do tipo http://localhost:port/tipos. Seguindo, definimos outro bloco, agora chamado de get.

module API
   module V1
      class Tipos < Grape::API
         resources :tipos do
            # Obter uma lista de Tipos de Cervejas
            get do
               tipo = Models::Tipo.new
               tipo.id = 1
               tipo.nome = 'Pilsen'
               [tipo]
            end
         end
      end
   end
end

Já entendeu? É isso mesmo. Estamos dizendo que o recurso na URL http://localhost:port/tipos responderá a requisições GET e retornará uma lista com um objeto do tipo Models::Tipo. Nossa primeira API RESTful com Grape está quase pronta!

Configurando o config.ru

Ainda precisamos configurar o arquivo config.ru para conseguirmos rodar nosso projeto. Este arquivo contém os requires mais genéricos, necessários para rodar nosso projeto, como o graperubygems e rack. Depois, usamos o CORS para liberar as requisições cross-origin para todos os métodos HTTP (GET, POST,…). No final, rodamos a API com run API::Base. Observe que só precisamos de um require de módulos de nosso projeto: require ‘api/base.rb’.

$:.unshift "./app"

require 'rack/cors'

require 'rubygems'
require 'grape'
require 'rack'
require 'grape-entity'

require 'api/base.rb'

use Rack::Cors do
   allow do
      origins '*'
      resource '*', headers: :any, methods: [:get, :post, :put, :delete, :options, :patch]
   end
end

run API::Base

Feito isto, agora vá no seu console e digite rackup. Sugiro instalar o Chrome junto com o plugin Postman. É um excelente plugin para executar chamadas a APIs RESTful. Veja abaixo como chamar nossa API na versão 1.

Usando o Postman para chamar nossa API.

Usando o Postman para chamar nossa API.

 Pronto, meu caro, já temos nossa primeira versão da API executando! Não acredita? Testa aí! Nos próximos artigos, vamos fuçar mais o Grape, usando mais features dele. O objetivo deste primeiro artigo foi criar a estrutura e colocar uma primeira API simples executando!

ruby

Rundown on Grape Related Articles

My journey on API development started last year when I had to develop an API for a startup that I was involved with. Since then I’ve been intensively studying it through reading lots of articles and books. I built my first API using Java, even though it’s not my favorite language. To be honest, these days I’ve been shying away from projects where Java is the main language, however it was a great experience because I was able to learn lots of good practices for creating RESTful APIs.

And what’s my favorite language? If you’re following me on Twitter, you know that it’s Ruby. It was about three years ago when I was first introduced to Ruby, and since then I’ve been using it for most of my projects. Why Ruby? Because it’s the most elegant and beautiful language ever created. The worst thing about being a Ruby enthusiast is that everybody thinks you’re a Rails expert. I’m not. In fact, I have never used Rails.

Having said that, you might be wondering what I’ve been using to create my APIs. The answer is Grape: a simple and straightforward DSL that enormously simplifies the API developer’s life. This is not a step-by-step article on how to create APIs using Grape. Instead, I’m going to briefly lay out and comment on some articles and blog posts I’ve came across during these last months. I’m really surprised by the fact that there are only a few articles about Grape available on the Internet, and this is my motivation for writing this post.


Official Grape’s Site
https://github.com/intridea/grape

You haven’t ever heard of Grape? Then the first thing you should read is its official documentation. Every article I’m going to list from this point forward will be based on the assumption that you already know how to set up your Ruby and Grape environments. For this reason, it’s really important that you start reading it first if you’re new to this world. The documentation is simple and easy to understand.


Introduction to building APIs with Grape
http://codetunes.com/2014/introduction-to-building-apis-with-grape/

If you’ve already gotten the hang of programming in Ruby, and you know how to install Grape, then it’s time to read more specific and detailed articles. This one was published by Codetunes and describes how they built their API using Grape. It’s a good article despite the fact that they’re using some conventions that I personally don’t like, such as putting the API versioning information into the URI.

You must take into account, however, that they’re using Grape alongside Rails. Still, it’s not mandatory, and in my opinion you shouldn’t do this if the API which you’re planning to build doesn’t require all of the features and resources provided by Rails.


Build REST APIs with Grape
http://code.tutsplus.com/courses/build-rest-apis-with-grape

It’s a series of fourteen video lessons explaining how to build REST APIs with Grape. I haven’t watched every lesson, but it seems to be a very detailed step-by-step tutorial. Unfortunately, they provide only the first two videos for free.


Building RESTful API using Grape in Rails
http://funonrails.com/2014/03/building-restful-api-using-grape-in-rails/

A simple but useful article written by Sandip. Sandip doesn’t waste your time with misleading concepts and unnecessary explanations on how Grape works. He dives into the code in the first lines of his article. Again, take into account that he’s using Grape alongside Rails.


The 10 Minute API: Getting an API Up and Running in 10 Minutes with 3scale, Grape and Heroku
http://www.3scale.net/2012/06/the-10-minute-api-up-running-3scale-grape-heroku-api-10-minutes/

This is a 10 minutes hands-on video explaining how to build and deploy Grape based APIs on Heroku, one of the leading cloud host solutions on the market. I have some APIs running there and I strongly recommend their services. And no, they’re not paying me to write this, ok? :)

 The last thing worth mentioning about this article is the fact that they’re using their own API Management solution to authenticate each API call. Have you ever heard of the term API Management? I won’t explain it in this post because it deserves its own article. Instead, take a look at this article.


Building Modular APIs with Grape and Rails
http://priyaaank.tumblr.com/post/34018821171/building-modular-apis-with-grape-and-rails

This is the most detailed and interesting article out of all which I’ve listed so far. Priyank Gupta have written a detailed post explaining how he built his API using Grape, Rails and MongoDB.

facebook_banner-youtube

Estudo de Idiomas

Não é novidade para meus amigos e familiares que eu gosto de estudar idiomas. Entender o idioma de um povo é ser capaz de entender sua forma de pensar e, porque não, de agir também. Em minha humilde opinião, um idioma molda uma nação de diversas formas. A existência ou não de uma palavra para descrever um objeto, sentimento ou fenômeno pode acarretar em uma maneira totalmente distinta de ver o mundo e compreender as pessoas. Desde o ano passado passei a investir pesado em meu aprendizado de idiomas, com cursos e aulas online.

Comecei resolvendo um problema antigo: apesar de ler facilmente textos técnicos em inglês, a língua coloquial e os textos de jornais eram um horror para mim. Conversação, então, nem comento. Resolvi iniciar meus estudos focando neste aspecto e comecei estudando métodos para resolvê-lo. Invariavelmente, todos os métodos tinham um quesito que estava sempre no topo: não se aprende uma língua sem praticá-la com um nativo. Inicialmente, eu achei que era possível, sim, mas quebrei a cara.

Apesar de entender muito bem o que nativos falavam, eu não conseguia disparar uma conversa fluida, pois meu cérebro não estava preparado para isso. Ele estava preparado para ouvir e entender, mas o trabalho de formar frases inteiras e verbaliza-las é totalmente diferente e eu comprovei isso na prática. Foi aí que eu tomei vergonha na cara e comecei a ter aulas via Skype.

Minhas primeiras aulas foram com uma brasileira que vive em New York. Foram excelentes classes, mas fiz apenas 7. Depois disso, encontrei o site italki. Por lá, passei a marcar classes com professores nativos da Inglaterra, Estados Unidos e Espanha. Sim, também estou aprendendo espanhol! A diferença foi enorme. Conversar com um nativo é, de diversas formas, diferente de conversar com um brasileiro fluente em inglês. A conversa vem carregada de um histórico cultural que enriquece substancialmente sua vida.

Você aprende o idioma e junto leva de brinde um montão de informações culturais e forma de pensar de um nativo. Não é só que vale a pena, eu digo que é a forma mais eficiente e vibrante de se aprender um idioma. Já tenho planos para aprender francês, alemão e mandarim. Tudo em seu tempo!

Para finalizar esse texto, lhes convido a estudar idiomas também. É fascinante, juro! E fica a dica do italki, onde você encontra diversos professores mundo à fora. Ah! Se for usar o italki, na moral, clica nesse link aqui! A cada crédito que você coloca lá, eu ganho mais 50 aqui. Ajuda seu amigão aqui a aprender todos os idiomas do mundo! Por favor! :P

t

Revista Tema

Uma postagem rápida e caceteira de autopromoção para me promover a mim próprio! A Revista Tema, uma publicação do Serpro, de agosto de 2014, conta com um artigo escrito por mim, Ronaldo Agra e Viviane Malheiros. O artigo é sobre a Análise de Redes Sociais no âmbito do Governo. O artigo começa na página 27 e você pode conferir na própria página da revista. Leiam, porque se tem meu nome no artigo, então é porque é bom! :P

http://tema.serpro.gov.br/pub/serpro/?numero=224

aliendroid-serpro

AlienDroid no SERPRO

Já publiquei aqui sobre o AlienDroid, um framework de persistência de objetos que fiz para Android. Inclusive, publiquei sobre o prêmio no SBSI 2013 que ganhei com a publicação de um artigo sobre ele. Então, para que mais uma publicação sobre ele aqui, lindão? Bom, em primeiro lugar, para me gabar, é claro, e em segundo lugar, para dizer que ele ganhou holofotes aqui no Serpro recentemente.

Não lembro se já havia comentado, mas o AlienDroid foi utilizado em algumas soluções internas do Serpro, como o aplicativo Pessoa Física, e isso foi divulgando internamente, o que me levou a apresentá-lo internamente para a empresa. Bom, não tão internamente assim, pois a apresentação era pública através do Assiste Serpro. :) Já saíram algumas matérias nos meios de comunicação do Serpro e agora saiu mais uma. Seguem os links:

AlienDroid é uma das Soluções Inovadoras do Serpro
https://www.serpro.gov.br/noticias/aliendroid-e-uma-solucoes-inovadoras-do-serpro-1

Mobilidade Garante Premiação no SBSI 2013
https://www.serpro.gov.br/noticias/mobilidade-garante-premiacao-no-sbsi-2013

Também encontrei o artigo publicado na internet, inteiro e de forma oficial. Segue o link:
http://www.lbd.dcc.ufmg.br/colecoes/sbsi/2013/0034.pdf

O Medo da Morte

Mais um talk no TED que eu achei muito bom. Você tem medo da morte? Caso sim, já parou para pensar que esse medo é injustificado? A morte não é algo que experimentamos, de fato. Uma vez morto, não há mais o que temer. Normalmente, tememos a aniquilação do nosso ser. Tememos uma escuridão eterna. Mas esse medo não faz muito sentido, uma vez que estando morto, não há mais vida (lógico) e, portanto, não há dor, tristeza, contemplação e nada.

Enfim, você não vai experimentar a morte, de fato, pois quando sua morte chegar, você já estará morto. Difícil de entender? Talvez o Stephen Cave consiga lhe fazer entender melhor! A versão do TED conta com legendas e esta neste link:

http://www.ted.com/talks/stephen_cave_the_4_stories_we_tell_ourselves_about_death