Analisando a frequência cardíaca (BPM)

Figura1_capaA frequência cardíaca medida por meio de Batimentos por Minuto (BPM) é uma das métricas que vem sendo muito utilizadas por diversos dispositivos, incluindo os wearables. Neste post vou falar um pouco sobre que tipo de análise e o que é possível fazer com estes dados.

Figura2_apple-watchAssim como diversos outros tipos dados coletados por sensores, os dados fornecidos por um medidor cardíaco tal como um smartwatch ou uma cinta específica para quem faz exercícios aeróbicos podem ser analisados e utilizados de diversas maneiras. Portanto, o que vou comentar neste post é útil tanto para os dados de BPM como para outros tipos de sensores que produzem dados mais ou menos no mesmo formato, sejam eles coletados em projetos que envolvam wearables ou iOT (Internet of Things).

Print

Do ponto de vista técnico, os dados de BPM coletados são tratados por meio de uma disciplina chamada de processamento digital de sinais, ou DSP. Existem muitas teorias, algoritmos e técnicas desta área que podem ajudam quem deseja lidar com este tipo de dado. Recomendo para quem se interessar por isso procurar se aprofundar nesta área, pois existe muita coisa legal que pode ser feita a partir da quantidade de conhecimento acumulada sob a sigla DSP.

Considerando que já obtemos os dados brutos de BPM a partir de um sensor, a primeira coisa que precisamos fazer é uma limpeza para obter somente dados válidos e, por exemplo, eliminar valores negativos ou que estejam muito fora da escala esperada para um batimento cardíaco humano. O segundo passo, dependendo de algumas característicos do conjunto de dados, é considerar algum tipo de tratamento tal como um filtro de Kalman ou semelhante. Depois destes passos podemos pensar em começar a analisar mais de perto os dados.

Apesar da métrica se chamar BPM é comum os dispositivos e sensores coletarem os dados em uma frequência menor como, por exemplo, uma mediação por segundo. Uma vez que os dados já tenho sido processados e armazenados adequadamente recomenda-se dar uma olhada por cima em sua distribuição através de um gráfico de linha onde coloca-se no eixo X a unidade de tempo e no eixo Y o valor BPM obtido. Observar os dados desta maneira ajuda a compreendê-los melhor, nem que seja apenas uma parcela do total de dados.

Figura4_healthy-hrUma das primeiras análises que pode ser feita nos dados BPM é descobrir onde estão os picos mais altos e os valores mais baixos. Isso pode ser associado com algum tipo de evento que aconteceu no mesmo momento e, inclusive, diversas aplicações usam esta abordagem para criar gatilhos ou ações quando certo patamar ou pico de dados for alcançado. Por exemplo: regras do tipo “se o BPM for maior que 120 emitir aviso de ‘faça uma pausa de 5 minutos’” são comuns em aplicações, considerando que uma alta frequência cardíaca pode estar relacionada a um alto nível de nervosismo ou stress. Sem contar a análise para exercícios que indica a faixa adequada de BPM.

Depois da análise de picos também é importante obter medidas de centralidade como a média, mediana, moda e calcular a variância. Tais medidas gerais pode sem acompanhadas de teste de distribuição (especialmente a distribuição normal) para ajudar a compreender os dados. A partir deste ponto já é possível utilizar técnicas de análises um pouco mais avançadas.

Uma técnica de mineração de dados para classificação automática em grupos, tal como o K-means, pode ser muito útil para identificar, por exemplo, quanto tempo por dia a pessoa está com uma alta frequência cardíaca. A figura abaixo, obtida a partir dos dados coletados no meu experimento com o Android, mostra como foi classificada uma série de dados BPM em três categorias (baixo BPM, BPM médio e alto BPM) representadas pelo uso de cores diferentes nos pontos do gráfico.

Figura5_DadosClusterizados

Outra análise possível é identificar se há uma certa repetição (padrão) na frequência. Neste ponto já estamos entrando em análises de séries temporais (time series) que já contam com diversos algoritmos da literatura para análise, classificação e predição.

Figura6_TiposSerieTemporal

Existem alguns algoritmos que permitem identificar um ou mais motifs, que nada mais são do que padrões para a série temporal. No caso do BPM este tipo de padrão pode ser associado com outros dados como, por exemplo, a atividade que a pessoa estava realizado ou o local por onde ela passou (obtido por dados de um GPS).

Além da descoberta de padrões também é interessante classificar a série temporal de dados BPM em uma sequência de caracteres, tal como o resultado do algoritmo iSAX. Com diversas séries temporais representadas por uma sequência de caracteres é possível empregar outros algoritmos de machine learning (Apriori, Clustering, LCS, etc) que permitem comparar uma série com outra. Tal comparação pode indicar, por exemplo, se a hora de ida ao trabalho (6h -> 7h) é tão estressantes quanto o horário da volta (18h -> 17h).

Figura7_sax

A partir dos dados de BPM é possível gerar a quantidade de calorias gastas. Para isso geralmente é preciso contar com algum tipo de modelo representado por uma equação, tal como esta aqui. O cálculo deste tipo de dado derivado também requer a idade, o peso, o sexo da pessoa e o tempo total medido. De qualquer forma, a análise de calorias permite comparações e indicações para dizer, por exemplo, que o tempo que a pessoa ficou em uma reunião foi o suficiente para gastar a quantidade de calorias equivalentes às calorias ingeridas pelo consumo de um bombom.

Por fim, também é possível utilizar a série de dados BPM para gerar previsões, apesar deste tipo de análise não ser comum devido aos diversos fatores externos que podem tornar a previsão não tão interessante. Por exemplo, usando as ferramentas de API do Eureqa é possível gerar um modelo de dados prevendo (baseado nos dados históricos) que na próxima semana o usuário vai ficar muito nervoso ou estressado pelo menos um dia da semana e recomendar algum tipo de atividade para aliviar ou amenizar este stress.



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

DatabaseCast 57: Alta disponibilidade na prática

VitrineDatabaseCast57

Olá, pessoal! Neste episódio do DatabaseCast, Mauro Pichiliani (Twitter | Blog), Wagner Crivelini (@wcrivelini) e os convidados Nilton Pinheiro (@nilton_pinheiro) e Marcelo Fernandes (@marcelodba) colocam a alta disponibilidade para funcionar.

Saiba como o planejamento faz toda a diferença, porquê alinhar a tropa, esperar pelo GO ou NO GO, investir em hardware, configurar um cluster pelo assistente e pela linha de comando e se lembrar de vestir a cueca da sorte no dia D.

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-rssVeja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio57

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

TagCloudEp57

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 | Com a tag , , , , | 1 comentário

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.  Quando realizei testes no veículo pensei que ele tinha direção hidráulica, mas na verdade ele possui direção elétrica. De qualquer maneira, o volante é fácil de manusear e não requer muito 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 , , , , , | 1 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