Avaliação do novo Ford Ka

The 2015 Ka hatch for Brazilian markets.Recentemente tive a oportunidade de avaliar por uma semana o novo Ford Ka. Esta oportunidade foi um dos prêmios que recebi por ter ficado em segundo lugar na Hackathon da Ford realizada durante a Campus Party 2015, como já relatei neste post.

Figura2_ka4

Eu não produzi nenhum vídeo sobre o uso do carro, mas para quem ficou curioso recomendo assistir ao pequeno review que os colegas da RedeGeek fizeram sobre o carro indicado abaixo.


Do ponto de vista do veículo, posso destacar alguns aspectos.

A direção hidráulica é boa e leve, permitindo a realização de curvas suaves e manobras sem esforço.

As portas possuem uma boa abertura com maçanetas grandes e de fácil manuseio.

O painel é claro e com boa iluminação. Sistemas eletrônicos (rádio, CD, integração painel-veículo, hora, tempo e conexões auxiliar e bluetooth) intuitivos e de fácil operação. Contudo, notei que existem muitos botões no computador de bordo. Apesar de serem práticos, creio que este aspectos de “árvore de natal” pode ser um pouco intimidador para quem não possui tanta experiência com interfaces lotadas de botões.

A conexão celular-veículo é automática e boa, mas a utilização do sistema de som por meio de bluetooth não foi localizada. Ainda que seja possível ouvir músicas pelo celular no sistema de som do veículo, a conexão não é de fácil acesso (se é que existe).

O sistema de ligação da lanterna e farol (baixo e alto) no painel lembra os modelos antigos, e não agradou. Preferível a ligação das luzes na alavanca de seta.

A ausência de iluminação interna no banco traseiro faz falta, bem como a colocação da iluminação interna dos bancos da frente distante dos passageiros de trás, pois os bancos traseiros permanecem na sombra mesmo com a luz acesa.

A abertura do porta malas por meio de dois toques na chave é eficiente, mas o fechamento deve ser feito com força, caso contrário a tampa permanece aberta e o sensor no painel permanece aceso. Quanto ao sensor de porta aberta, a luz do painel não indica qual a porta, dificultando o fechamento.

O veículo é confortável, os bancos são espaçosos, há porta-copos em grande quantidade evitando sujeira. Os comandos de abertura das janelas e travamento das portas é grande e visível.

O carro é alto e os bancos elevados facilitam a visão, fato complementado pela excelente visibilidade do para-brisas.

O motor é silencioso e potente comparado com um carro da mesma categoria.

A mudança de marcha apresenta dificuldade pela proximidade dos engates.

Em geral posso dizer que os aspectos “físicos” do veículo são muito bons, porém existem alguns detalhes que podem ser melhorados.

Novo-Ka-Ford-5Como sou desenvolvedor vou falar um pouco do processo para desenvolver aplicações mobile que se integram com o sistema de computador de bordo do carro. O sistema utilizado pela Ford é o Sync que, infelizmente, vai contra as iniciativas de unificação promovidas pelo Android Auto.

Do ponto de vista prático, eu me concentrei no desenvolvimento para a plataforma Android, apensar de também ter experiência com desenvolvimento na plataforma iOS há algum tempo.

Existe um portal para desenvolvedores mantido pela Ford, porém ele ajuda até certo ponto. Como já descrevi em um outro post ainda há muito o que fazer em termos de documentação, fomento à comunidade e recursos para tornar a tecnologia mais acessível para os desenvolvedores.

Um ponto que gostaria de destacar foi a dificuldade para obter certos dados do veículo. Assim como o que aconteceu na Campus Party, não consegui obter dados de velocidade, nível de combustível e o outros pelo sistema. Aparentemente é necessário uma autorização especial da Ford para obter tais dados, algo que não consegui obter. Neste caso em participar recebi uma mensagem de erro do tipo “access denied” ao chamar certos métodos e simplesmente tive uma exceção lançada sem maiores detalhes. Acredito que este tipo de barreira para desenvolvimento deve ser endereçada pela equipe técnica para que novas aplicações possa ser desenvolvidas.

No geral posso dizer que foi uma ótima experiência passar um tempo mais de perto com o carro e com o sistema de computador de bordo que se comunica via bluetooth. Fora alguns pontos que precisam ser revistos, a abordagem é interesse e eu realmente gostaria de ver esta tecnologia sendo adotada por mais pessoas e se popularizando.



Publicado em Programação, Uncategorized | Com a tag , , , , , | Deixar um comentário

Oi, sou uma API. Veja aqui como me usar melhor

Fonte: http://umbatman.deviantart.com/art/Cyborg-407404538

Fonte: http://umbatman.deviantart.com/art/Cyborg-407404538

Atualmente o desenvolvimento de aplicações Web envolve o conhecimento e uso de algum tipo de API. Neste post vou comentar sobre quais tipos de documentação e recursos são úteis para promover uma API e auxiliar o desenvolvedor que precisa aprender a usá-la.
Figura2_api
Já faz algum tempo que desenvolvo software de diferentes tipos e recentemente tenho participado de alguns concursos e Hackathons. Durante estas atividades geralmente preciso aprender alguma API nova para realizar alguma tarefa. Contudo, na maioria das vezes acabo me deparando com problemas de documentação e falta de informações necessárias para o uso da API.

Por causa desta frustação resolvi escrever este post com algumas recomendações e dicas para quem cria APIs. É importante destacar que não é só uma boa documentação que vai levar uma API ao sucesso de uso, ou seja, existem outros aspectos importantes para sua a adesão. Neste post vou me concentrar nos principais pontos que gostaria de encontrar sempre que tiver que aprender a usar uma API. Do ponto de vista prático, estes itens que vou citar funcionam como um checklist que os criadores da API podem seguir.

1) Exemplos. Exemplos para tudo quanto é lado

Figura3_
Muitos desenvolvedores preferem ir direto para exemplos de código e gastam pouco ou nenhum tempo estudando e aprendendo conceitos. Por isso é importante sempre fornecer diversos exemplos de uso de API. Isto quer dizer que é preciso ir muito além do básico “hello world”. Uma boa dica é fornecer pelo menos um exemplo para cada funcionalidade importante da API.

Também vale a pena disponibilizar exemplos em cada uma das principais linguagens/ambientes na qual a API vai ser utilizada e destacar como ela se comporta em determinada situações (falta de internet, limite de uso excedido e outros). Nota: os exemplos podem ser didáticos, porém quanto mais próximos da realidade e do objetivo no qual as pessoas vão usar a API mais adequado vai ser a utilidade do exemplo.

2) Tenha um playground/ambientes de testes

Figura4
O desenvolvedor que está começando a utilizar uma API certamente vai fazer diversos testes antes de colocá-la em um uso oficialmente (em produção). Devido a este comportamento, faz muito sentido que a API possa ser utilizada em um ambiente de testes ou avaliação, pois assim é possível “brincar” e descobrir o que é possível fazer com a API. Em certos casos, especialmente em APIs que envolvem o uso de valores monetários, vale a pena investir em versões de avaliação com algum tipo de limitação de uso por tempo ou funcionalidades.
Algumas APIs requerem diversos passos para serem utilizadas tal como cadastro, autorização, obtenção de token e validação. Apesar destas etapas serem importantes, elas acabam afastando alguns desenvolvedores que desejam realizar um teste rápido. Para estes casos recomenda-se a criação de um playground ou ambiente pronto para que o desenvolvedor possa ter um gostinho de como a API funciona sem ter que passar por diversos passos de configuração de ambiente e obtenção de recursos de autorização e autenticação.

3) Documentação além do básico

Figura5
A documentação é um recurso obrigatório para quem produz uma API. Existem diversos tipos de documentação, mas o que procuro quando estou aprendendo é algum que vá além de um simples JavaDoc ou algo gerado automaticamente. Procuro, em particular, diagramas, arquiteturas e algum tipo de informação visual que me permita entender os pré-requisitos, como é o fluxo de passos, as características e os detalhes necessários para que eu consiga realizar a tarefa que preciso com a API. Guias para iniciantes (Getting Started) também são ótimos pontos de partida para quem caiu de paraquedas no site da API e não tem ideia de onde e como começar a usá-la.

Um dos itens importantes de uma boa documentação é deixar claro onde a API pode e deve ser utilizada e onde não faz sentido empregá-la. Isso é importante para que o desenvolvedor saiba até onde é possível ir com ela e quais são os cenários e casos de uso em que ela não é recomendada. Também é muito útil destacar na documentação a lista atualizada de bugs para cada versão da API, pois não há nada mais frustrante do que perder muito tempo quebrando a cabeça com um bug para descobrir só depois que ele já foi arrumado em uma versão mais atual da API.

4) Um bom FAQ e RTFM

Figura6Eu gosto muito dos FAQs (Frequently Asked Questions ou Perguntas Frequentes) quando estou aprendendo a usar uma API. Este formato de perguntas rápidas e respostas me ajuda muito a compreender o objetivo e particularidades de uso da API. Sem contar que deste modo fica fácil descobrir o que outras pessoas estão tentando fazer com a API.

Contudo, não vale a pena colocar no FAQ informações antigas, desatualizas ou que não fazem mais sentido com tecnologias obsoletas. Também é importante adotar um tom mais leve, bem humorado e didático na escrita do FAQ em relação à documentação oficial, pois um texto mais amigável incentiva os desenvolvedores a trabalharem com a API. Por outro lado, deve-se evitar sarcasmo, tratar o desenvolvedor como idiota ou simplesmente mandar ele ler o manual indicando a sigla RTFM.

5) Um canal de comunicação com o desenvolvedor

Figura7_DeveloperToDeveloperCommunicationUma API de sucesso deve ter algum tipo de canal de comunicação com o desenvolvedor. Este canal pode ser um e-mail, twitter, formulário de contato ou qualquer outro meio que permita ao desenvolvedor que tem uma dúvida técnica ser ouvido. Destaco que indicar qual é o tempo médio de resposta nas comunicações assíncronas (como o e-mail) ajuda muito a ter aquela sensação de que o “cliente” é importante e que ele vai ser ouvido.

Em geral os canais de comunicação para desenvolvedores deve ser mais simples, curtos e rápido, pois quem cria software e chega ao ponto de entrar em contato com o criador de uma API provavelmente já fez diversos testes e encontrou uma barreira que o fez ficar parado e pedir ajuda. Por isso a comunicação deve ser direta e sem rodeios para que o desenvolvimento não seja atrasado ainda mais.

6) Deixe claro preços, tipo de acesso e limitações de uso

Figura8_1363963992391Muitas APIs tem em seu modelo de negócio a cobrança por uso de acordo com algum tipo de lista de funcionalidades, tempo ou número de chamadas. É extremamente importante deixar bem claro quais são os valores, tipos de uso (pacote gratuito, normal ou avançado), modos de pagamento e cobrança, e também como funciona o reembolso, troca de modalidade ou estorno de valores.

É comum que APIs inicialmente sejam gratuitas e, depois que atinjam um certo número de usuários, se tornem pagas. A princípio tal mudança do modelo de negócio pode frustrar e afugentar alguns desenvolvedores. Neste caso o que gostaria de ouvir é uma comunicação clara de como as coisas vão ficar uma vez que o serviço se torne pago, incluindo prazos, limitações, vantagens e desvantagens de como o serviço da API era e de como ele vai ficar no novo modelo de negócios.

7) Mantenha um histórico decente

Todo projeto de software que evolui a cada versão tem um histórico por trás. Este histórico é importante para mostrar não só a que passo o projeto anda, mas também para deixar claro o rumo que ele está tomando.

Diversas APIs sofrem modificações constantes de acordo com o ambiente como, por exemplo, nova versões de navegadores, recursos para torná-la mais rápida, modificações para suportar novas plataformas e adequações gerais à novas tecnologias e tendências do desenvolvimento Web. Portanto, saber indicar de forma adequada o histórico é importante para fornecer um contexto e deixar claro os motivos pelas quais a API está do jeito que ela é hoje.

8) Tenha um guia de troubleshooting

Figura10_Software-Developer É muito comum encontrar problemas e dificuldades quando se está estudando uma nova API ou quando certas condições do ambiente mudam. Nestas ocasiões é importante tem em mãos um guia de resolução de problemas (troubleshooting guide) que vai indicar, passo a passo, quais são os pontos que devem ser observados.

No caso de APIs um guia de troubleshooting deve dizer passo a passo como realizar um teste de conexão, quais parâmetros são necessários, que tipo de retorno é apresentado para cada requisição e como proceder se algum dos passos falhar. Este tipo de guia é muito útil quando se está debugando um problema e não se sabe qual dos componentes da solução está falhando. Nesta situação um guia de diagnóstico e instruções passo a passo são extremamente úteis para ajudar a primeiro entender o que está acontecendo e, sem seguida, tomar alguma atitudes para remediar o problema.

9) Invista em um roadmap e novas funcionalidades

Figura11_wXSbV
Um fator que o desenvolvedor leva em consideração quando está estudando e ponderando se vale a pena ou não utilizar uma API é a sua continuidade. Ou seja, vale a pena eu estudar, investir tempo e modificar a minha aplicação para usar a API se ela não vai me servir no futuro? Em outras palavras, ninguém quer utilizar um serviço que parece uma cidade do velho oeste abandonada…
Uma boa maneira de deixar claro como anda o projeto de uma API é fornecer um roadmap em um gráfico que mostra as última versões da API e quais é o planejamento para as próximas versões. Desta forma o criador da API mostra seu compromisso em manter este serviço no futuro e deixa claro que o projeto é sério e não simplesmente algo passageiro que tem um futuro incerto.

10) Destaque projetos que usam a API

Figura12_Triathlon-beginner-flexible-woman
Uma API geralmente faz fazer parte de um software maior, mesmo que este software seja apenas uma interface gráfica para seu uso. Se o design de uma API foi bem planejado e ela é algo realmente útil e flexível é normal esperar que diferentes tipos de projetos façam uso da API.

Destacar e dar ênfase a diferentes projetos que utilizam a API é uma ótima maneira de incentivar pessoas a utilizá-la e valorizar o serviço. Quando estou avaliando uma API e vejo diversos projetos que a utilizam tenho uma sensação de confiança, pois se alguém já está utilizando este serviço de alguma maneira isso me motiva a utilizá-lo também. Em particular me sinto incentivado ao ver projetos completamente diferentes utilizando um mesmo serviço, pois esta flexibilidade pode me ser útil no futuro.

11) Fomente a comunidade

Fonte: http://www.pocket-lint.com/news/132386-barclays-banking-on-code-playground-and-digital-driving-license-to-enhance-our-digital-skills

Fonte: http://www.pocket-lint.com/news/132386-barclays-banking-on-code-playground-and-digital-driving-license-to-enhance-our-digital-skills

Ninguém quer ser aquele convidado que chega primeiro na festa e percebe mais tarde que ele foi o único que apareceu. Isto quer dizer que fomentar uma comunidade é algum muito importante para que os desenvolvedores que usam a API não se sintam isolados e solitários.

Existem várias maneiras de lidar com a comunidade de uma API incluindo eventos próprios como Hackathons (maratonas de programação), dojos de programação, encontros onde pessoas se reúnem para fazer a tradução de outras linguagens ou produzir documentação, ou mesmo eventos sociais que os membros da comunidade saem para tomar umas e conversar sobre o projeto. Independente do formato do evento, vale a pena investir na comunidade de usuários para que seja possível aprimorar o serviço, ouvir como ele é utilizado e entrar em contato com quem realmente depende do serviço.



Publicado em Programação | Com a tag , , , , , , , , | 4 comentários

Como é a ‘cara’ de uma nova linguagem de programação?

Fonte: https://www.flickr.com/photos/jesper/252307864

Fonte: https://www.flickr.com/photos/jesper/252307864

É comum uma linguagem de programação evoluir e apresentar diversas mudanças significativas. Também não é raro encontrar novas linguagens de programação que desafiam as pessoas a aprenderem coisas novas. Neste post vou discutir um pouco sobre este processo de aprendizado de uma nova linguagem de programação.

Quem trabalha na área de programação deve estar acostumado a aprender novos conceitos, sintaxes, elementos e, em termos gerais, novas maneiras de resolver problemas com as linguagens de programação. Talvez isso não seja verdade para todos, pois sempre vamos ter o aquele tradicional cenário padrão COBOL onde as coisas não evoluem muito ou quando evoluem o fazem de maneira muito lenta.

Figura2_Cobol

Recentemente fiquei pensando um pouco sobre este processo de aprender algo novo em relação a uma linguagem de programação, especialmente no que diz respeito à sintaxe. O que me motivou para pensar sobre isso foi a atualização que muitos desenvolvedores vem enfrentando para gradualmente migrar do Objective-C para o Swift e também o estudo que fiz para criar a nova caneca com sintaxe para datas do DatabaseCast . Contudo, pelo que descobri este tipo de atualização é relativamente frequente em diversos cenários. Quer dizer, olha só o novo tipo de sugestão de estilo de programação desenvolvimento com o Java 8! Praticamente não se recomenda mais utilizar loops ou variáveis e sim depender muito de técnicas como métodos anônimos, lambdas e outros.

Figura3_why-lambda2-730x320

Quais são os recursos, técnicas ou recomendações para este tipo de atualização profissional?  Pensando em um contexto mais geral, qual é o tipo de ajuda fornecer para quem está aprendendo uma nova linguagem de programação? Sei que existem muitos recursos técnicos tradicionais como livros, cursos e outros para quem quer aprender algo do zero e se atualizar, mas será que não existem novas abordagens específicas para este tipo de atualização?

Por exemplo, uma forma muito comum de descrever a sintaxe de elementos de uma linguagem é através de diagramas de sintaxe também chamados de “diagramas de ferrovia” (RailRoad diagramas). As figuras abaixo mostram exemplos deste tipo de diagrama para a sintaxe de um comando condicional tipo IF e também um  diagrama para a sintaxe de um comando CREATE da linguagem PL/SQL.

Figura4_ebnfFigura5_FiagramaCREATEEste tipo de representação visual é interessante para quem desenvolve compiladores, parses e analisadores de linguagem. Contudo, muitos desenvolvedores preferem uma notação mais textual quando procuram a documentação como, por exemplo, a definição de uma gramática na notação BNF (Backus–Naur Form)

Figura6_FormaBNFDe qualquer maneira, estes recursos para apresentação de sintaxe são pouco amigáveis para quem quer identificar mudanças e novos elementos. Seria interessante se eles tivessem recursos como animações, cores diferentes e destaques que facilitassem a visualização do que efetivamente mudou, foi inserido ou é novo. Desta forma fica mais simples, rápido e fácil descobrir a nova ‘cara’ da linguagem ou o seu ‘jeitão’.

Outra abordagem interessante é a utilização de técnicas de visualização de dados para evidenciar mudanças. Por exemplo, que tal usar um TreeMap ou as famosas nuvem de palavras (tag cloud) para ver os elementos mais comuns em um código Object-C e Swift? A imagem abaixo mostra um exemplo disso. Figura7_TagCloud

Existem muitas outras formas que podem ser exploradas para facilitar a atualização de um profissional que deseja aprender o que foi modificado em uma linguagem ou se atualizar rapidamente. Mesmo sem um esforço adicional de quem fornece a linguagem de programação, acredito que investir neste tipo de recursos pode facilitar novos desenvolvedores a utilizar o que é novo e também incentivar a adoção que propostas diferentes para resolver problemas antigos ou novos. Isso vale tanto para sintaxe, novas linguagens e paradigmas (estou me referindo a você programação funcional!), versões de API e até recursos adicionais que envolvam novos conceitos fundamentais.



Publicado em Programação, SQL | Com a tag , , , , , , , , , , , , | 1 comentário

DatabaseCast 56: Sintaxe SQL

VitrineDatabaseCast56Olá, pessoal! Neste episódio do DatabaseCast, Mauro Pichiliani (Twitter | Blog), Wagner Crivelini (@wcrivelini) e os ouvintes Alex Zaballa (@alexzaballa) e Henrique Jardim (@henriquejardim) quebram a cabeça tentando descobrir o problema na sintaxe do comando SQL. Você também vai saber um pouco mais sobre o padrão SQL, descobrir por que fugir da álgebra relacional, evitar colocar hints de instrução na forma de comentários, odiar a sintaxe (+)= e =(+) e não dar ouvidos ao diabinho e ao anjinho que ficam em cima dos ombros.

LANÇAMENTO: Veja a caneca Datas SQL com a sintaxe para manipulação de datas no Oracle, SQL Server, Mysql e PostgreSQL.

MontagemCanecaDatabaseCast

Compre esta caneca clicando aqui!

Não deixe de nos incentivar digitando o seu comentário no final deste artigo, mandando um e-mail para  databasecast@gmail.com, seguindo o nosso twitter @databasecast, vendo informações de bastidores e as músicas do programa no nosso Tumblr e curtindo a nossa página no Facebook e no Google+.

feed-rss

Veja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio56Veja na tag cloud abaixo a contagem das palavras mais usadas nos emails, comentários e tweets do episódio anterior:TagCloudEp56

Livro Conversando sobre Banco de dados do Mauro Pichiliani (Impresso e PDF, EPUB e MOBI)

Você pode comprar a camiseta com estampa fractal Fluxo Matrix e Sonho Fractal diretamente neste link. Veja também:

Links do episódio:



Publicado em DatabaseCast, Podcast, SQL | Com a tag , , , , , , , , , | Deixar um comentário

DatabaseCast 55: Planilhas e bancos de dados

VitrineDatabaseCast55Olá, pessoal! Neste episódio do DatabaseCast, Mauro Pichiliani (Twitter | Blog), Wagner Crivelini (@wcrivelini) e o convidado Elton Rabello fazem as contas e fórmulas usando planilhas. Hoje você vai entender a dificuldade de usar planilhas no DOS, saber por que contadores adoram calculadores; quando vale a pena ou não trocar planilhas por banco de dados e vice-versa, aprender a convencer o usuário a largar a planilha e descobrir porque a rede fica lenta quando um documento é aberto.

Não deixe de nos incentivar digitando o seu comentário no final deste artigo, mandando um e-mail para  databasecast@gmail.com, seguindo o nosso twitter @databasecast, vendo informações de bastidores e as músicas do programa no nosso Tumblr e curtindo a nossa página no Facebook e no Google+.

feed-rss

Veja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio55

Veja na tag cloud abaixo a contagem das palavras mais usadas nos emails, comentários e tweets do episódio anterior:

TagCloudEp55Livro Conversando sobre Banco de dados do Mauro Pichiliani (Impresso e PDF, EPUB e MOBI)

CAPA_AMAZON_REDUZIDA_BLOG

cover_front_medium

Você pode comprar a camiseta com estampa fractal Fluxo Matrix e Sonho Fractal diretamente neste link. Veja também:

Links do episódio:




Publicado em DatabaseCast, Podcast | Com a tag , , , , , | Deixar um comentário