Sem a fiscalização apropriada, companhias que fazem gadgets e aparelhos que registram nossos movimentos e comportamentos podem compartilhar nossos hábitos secretos com nossos chefes, seguradoras e bancos. E em muitos casos, não existem leis que possam impedi-los.
Isso soa como um romance distópico. Mas a Comissão Federal do Comércio dos Estados Unidos (FTC) reporta que coletores de dados podem juntar informações o suficiente para nos fazer perder empregos ou inflacionar o valor de apólices de seguro, por exemplo. A FTC aponta quão ampla esta coleta pode ser:
“De acordo com um participante, pesquisadores afirmam que sensores presentes em celulares podem ser usados para deduzir o humor do usuário; seus níveis de estresse; seu tipo de personalidade; traços bipolares; demografia (por exemplo seu gênero, estado civil, atual emprego, idade); se fuma; o quanto se exercita; e tipos de atividade física e movimentos que executa.”
E isso tudo coletado só de smartphones! Como aparelhos conectados à internet geram ainda mais dados sobre o que usuários fazem dentro de suas casas, eles se tornam ferramentas ainda mais poderosas para coletar informação e criar perfis sobre os usuários. O relatório da FTC é um documento importante, pois existe a necessidade de que mais regras sobre o uso indevido de dados pessoas sejam criadas. Estes aparelhos e gadgets que compramos podem ser usados contra nós, se tornando pequenos espiões eletrônicos que podem ferrar com a nossa vida:
“Um pesquisador coloca a hipótese de que dados de gadgets e aplicativos de exercício físico, como a pulseira Fitbit e o aplicativo Nike+, que coletam dados relacionados ao bem estar dos usuários, poderiam ser usados para inflacionar preços de planos de saúde ou seguros de vida, ou ainda, definir se o usuário é adequado a um emprego (por exemplo, um usuário que se exercita pode ser tido como alguém que não corre tanto risco de morte ou um bom empregado)”
Isto significa que os exercícios físicos que você não pratica, conforme determinado por uma pulseira que companha suas atividades ou a uma academia conectada à internet, poderiam ser determinantes na hora de decidir se você é merecedor de um aumento ou até na manutenção do seu emprego próprio emprego, dependendo do que o seu empregador levar em consideração (e sabemos que eles podem ser bem malucos). Significa também que, caso você decida comprar um carro que se conecta à internet por questões de segurança, todas as vezes que você precisar dar uma freada brusca serão compartilhadas com a seguradora.
Agora, muitas das empresas que vendem aparelhos conectados já informaram que não venderão seus dados para outras companhias – a BMW e sua nova safra de carros conectados à internet é uma das que promete privacidade. A Nest pede permissão antes de compartilhar seus dados. Assim, seu chefe não teria nenhuma informação para usar contra você. E a Lei de Justa Informação de Crédito (Fair Credit Reporting Act – FCRA) impõe alguns limites às empresas que vendem este tipo de aparelhos. Mas a lei não é muito abrangente:
“A Lei de Justa Informação de Crédito exclui apenas terceiros do processo de coletar informações de consumidores; desta forma, fabricantes que produzem seus próprios produtos que se conectam à internet ficam livres destas restrições. A lei também não cobre empresas que coletam dados diretamente de aparelhos conectados para usá-las para aprovação de créditos, seguros e outras decisões que necessitam de elegibilidade — algo que pode se tornar bastante comum com o crescente número destes aparelhos.”
Sem leis limitando o poder das empresas de analisar e compartilhar dados, usuários estarão perpetuamente sob o risco de que os seus aparelhos se transformem em equipamento de espionagem de grandes corporações. E mesmo que concordemos em compartilhar nossos dados, nós os quantificamos e os compartilhamos com a ideia de que isso nos ajudará em nosso aperfeiçoamento, não para viver em um mundo digital de julgamento e punição. [FTC]
O DevOps não está matando os desenvolvedores – pelo menos não todos os desenvolvedores que conheço. Mas está matando o desenvolvimento, ou a maneira como a maioria de nós pensa em como devemos construir e entregar software. O Agile carregou a arma. O DevOps está puxando o gatilho.
A escala e o foco do desenvolvimento continuam diminuindo e o mesmo acontece com o prazo para a tomada de decisões e para executar o trabalho. Fases, marcos e revisões de projeto para sprints e reviews de Sprint para controles Lean além de limites WIP e a otimização de nível de tarefa. O tamanho das entregas: do que uma equipe de projeto pode entregar em um ano para o que uma equipe Scrum pode fazer em um mês ou uma semana, para como um desenvolvedor individual pode começar a trabalhar na produção em alguns dias ou algumas horas.
A definição de “Feito” e “Software Funcionando” muda de algo que é codificado, testado e pronto para demonstração, para algo que está trabalhando na produção – agora (“Concluído Significa Lançado“).
Porque o DevOps aproxima muito mais os desenvolvedores da produção, riscos operacionais tornam-se mais importantes do que os riscos do projeto, e as métricas operacionais tornam-se mais importantes do que as métricas do projeto. O funcionamento do sistema e o tempo de ciclo para produção substituem o valor agregado ou a velocidade. O estresse de alcançar os prazos é substituído pelo estresse de combater incêndios na produção e estar de plantão.
DevOps não é sobre a entrega de um projeto ou mesmo fornecer recursos. Trata-se de minimizar o tempo necessário e maximizar o fluxo do trabalho para a produção, reconhecer e eliminar o trabalho sucata e os atrasos e transferir, aumentar a confiabilidade do sistema e reduzir os custos operacionais, a construção de loops de feedback da produção para etapas do desenvolvimento, da padronização e automatização o máximo possível. É mais sobre o controle de fabricação do que processo de engenharia.
DevOps também mata produtividade do desenvolvedor
DevOps também mata a produtividade do desenvolvedor.
Se você tentar medir a produtividade do desenvolvedor por LOC, pontos de função, pontos de recurso, Story Points, velocidade ou alguma outra medida do quanto de código é escrito, menos codificação é feita, porque os desenvolvedores estão gastando mais tempo em trabalhos ops e lidando com interrupções, e menos tempo escrevendo código.
Tempo de aprendizado sobre a infraestrutura e plataforma e compreensão sobre sua configuração, certificando-se de que é a configuração correta. Construir pipelines de distribuição contínua e implementação contínua e mantê-los em funcionamento. Ajudar ops a investigar e a resolver problemas, respondendo às solicitações urgentes de clientes e às perguntas, olhando para problemas de desempenho, monitorando o sistema para certificar-se de que ele está funcionando corretamente, ajudando a realizar experiências A/B, forçando alterações e correções… tudo rouba tempo do desenvolvimento e impede que eles pensem sobre requisitos, design, codificação e testes (o trabalho para o qual os desenvolvedores são treinados e são bons em fazer).
O impacto de interrupções e multitarefas
Você não pode proteger os desenvolvedores de interrupções e alterações nas prioridades em DevOps, mesmo que utilize Kanban com limites WIP estritos, e você não quer. Os desenvolvedores precisam ser responsivos às operações e aos clientes, reagir aos comentários de produção, mergulhar nos problemas e ajudar a detectar e a resolver falhas o mais rápido possível. Isso significa que todos, especialmente os seus colaboradores mais talentosos, precisam estar disponíveis para ops na maioria do tempo, se não o tempo todo.
Os desenvolvedores se juntam aos ops de plantão após o horário, o que significa carregar um pager após o dia de trabalho. E o tempo desperdiçado em ligações de suporte para problemas que acabam não sendo problemas reais, longas noites e fins de semana no combate a incêndios e rastreamento de problemas de produção e ajudando a recuperar de falhas, chegando cansado no dia seguinte para passar mais tempo esgotado em incidente e testes de falhas e recuperação de avanço e roll-back e participando de pós-mortem e sessões de análise de causa raiz quando algo dá errado e a falha ou roll-forward ou roll-back não funciona.
Você não pode planejar as interrupções e os problemas operacionais, o que significa que os desenvolvedores vão perder seus compromissos com mais frequência. Então, por que assumir compromissos? Por que se preocupar com planejamento ou estimativa? Use a priorização just-in-time, em vez de se concentrar na coisa mais importante que os ops ou o cliente precisam no momento, e entregue o mais rápido possível – a não ser que algo mais importante venha à tona e se antecipe a isso.
Até mesmo o próprio loop de feedback da implementação contínua é uma interrupção no fluxo de um desenvolvedor.
Depois que um desenvolvedor verifica o código, executar os testes unitários em funcionamento na integração contínua deveria ser rápido, levando alguns segundos ou minutos para que eles possam seguir em frente com o seu trabalho. Mas para implementar imediatamente na produção significa executar por meio de um conjunto mais amplo de testes de integração e de sistemas e outras verificações na distribuição contínua (mais testes e mais verificações levam mais tempo), então execute as etapas até a implementação, e então faça o monitoramento da produção para se certificar de que tudo funcionou corretamente, e vá fundo se alguma coisa der errado. Mesmo que a maioria das etapas seja automatizada e otimizada, tudo isso tira tempo e atenção do desenvolvedor para trabalhar no código.
Otimizar o fluxo de trabalho dentro e fora das operações significa sacrificar o fluxo do desenvolvedor, e retardar o trabalho de desenvolvimento.
Expectativas, métricas e incentivos têm que mudar
No DevOps, a maneira como os desenvolvedores (e ops) trabalham e a maneira como eles precisam ser gerenciados mudam. Também é fundamental mudar as expectativas, as métricas e os incentivos para os desenvolvedores.
O sucesso de DevOps é medido por métricas operacionais de TI, e não pelo cumprimento das metas de entrega escopo do projeto, cronograma e custo, nem pelo cumprimento das metas de lançamento ou compromissos Sprint, ou até mesmo o cumprimento das metas de design de produtos.
Quão rápido o time pode responder às mudanças e aos problemas importantes: alterar tempo de entrega e tempo de ciclo para produção em vez de entregar milestones ou velocidade
Quantas vezes eles forçam as alterações para a produção (que ainda é a métrica com a qual a maioria das pessoas está mais animada – quantas vezes por dia, hora ou minuto Etsy, Netflix ou Amazon implementam mudanças)
Custo da mudança – Operações gerais e os custos de suporte
DevOps é mais sobre Ops do que Dev
À medida que mais softwares são entregues mais cedo e com mais frequência para a produção, o desenvolvimento se transforma em manutenção. O gerenciamento de projetos é substituído pelo gerenciamento de incidentes e de tarefas. O planejamento de horizontes fica muito mais curto – ou o planejamento é substituído por priorização da fila e triagem just-in-time.
Com a infraestrutura como código, Ops se tornam desenvolvedores, projetando e codificando infraestrutura e mudanças de infraestrutura, pensando pensando sobre a reutilização e a facilidade de leitura, duplicação e refatoração, a dívida técnica, a capacidade de teste e a construção em TDD para implementar TDI (Test Driven Infrastructure). Eles se tornam mais e mais Agile, fazendo pequenas mudanças com mais frequência, mais tempo de programação e menos em trabalho burocrático.
E os desenvolvedores começam a trabalhar mais como ops, assumindo responsabilidades de operações e suporte, colocando riscos operacionais em primeiro lugar, preocupando-se com a infraestrutura, construindo ferramentas de operações, encontrando formas de equilibrar as demandas imediatas de curto prazo para apoio operacional com objetivos de projeto de longo prazo.
Nada disso será uma surpresa para quem já vem trabalhando em um negócio online há algum tempo. Uma vez que você oferece um sistema e os clientes começam a usá-lo, as prioridades mudam, tudo sobre a maneira como você trabalha e plano têm que mudar também.
Essa forma de trabalhar não é, necessariamente, melhor ou pior para os desenvolvedores. Mas é fundamentalmente diferente de como muitos desenvolvedores pensam e trabalham hoje. É mais frenético e baseado em interrupções. Ao mesmo tempo, é mais disciplinado e mais improdutivo. Mais transparente. Exige mais responsabilidade e prestação de contas. É menos sobre desenvolvimento e mais sobre o lançamento, a implementação, as operações e o apoio.
Os desenvolvedores – e seus gestores – precisarão se acostumar a fazer parte do panorama geral de executá-lo, o que é muito mais do que projetar aplicativos, escrever e entregar o código. Esse pode ser o futuro do desenvolvimento de software. Mas nem todos os desenvolvedores vão gostar, ou ser bom no que fazem.
Em vez de lutar contra a nuvem, as empresas devem se livrar dos hábitos antigos para assimilar novos. Cloud Computing deve se tornar ponto fundamental do projeto de segurança e um fator que acelera a implantação de inovações como sistemas de análises, computação móvel e software como serviço (SaaS).
Mais de 85% dos CISOs (Chief Information Security Officers) afirmam que suas empresas estão movendo seus negócios para a nuvem. Contudo, 50% acreditam que um provedor cloud deverá registrar algum incidente em breve, revelou o estudo realizado pela IBM com esses profissionais.
Quando uma nuvem híbrida (enterprise, nuvens públicas e privadas, e dispositivos móveis) é implantada, não podemos esperar que as estratégias tradicionais de proteção funcionem, pois não há mais um perímetro limitado para se defender.
Se a companhia era um castelo que protegia seu tesouro com muros altos e fossos profundos, a abrangência dessa fortaleza cresceu e se estende por continentes, o que cria brechas por onde os oponentes podem entrar e causar estragos se não houver proteção adequada.
Em outras palavras, o modelo de computação em nuvem ultrapassou os limites de defesa de uma empresa, criando áreas de vulnerabilidade que as estratégias tradicionais são incapazes de proteger.
A relutância que alguns executivos de segurança têm para migrar para o novo se dá pelo fato de muitos manterem a mentalidade de “parede e fosso” e não terem as ferramentas, estratégias e/ou especialização em segurança para lidar com esse novo ambiente de TI. Para mudar esse cenário, as equipes devem focar em quatro áreas:
Quem, onde e o quê?
De um lado, os profissionais de TI em nuvem estão preocupados com o acesso não autorizado ou o vazamento de dados confidenciais. Na outra ponta, funcionários exigem o acesso imediato a recursos na nuvem, mas essa “necessidade por velocidade” não pode colocar os bens em risco.
As equipes precisam olhar para os protocolos de gerenciamento de acesso e adotar uma abordagem mais focada em nuvem, o que permitirá controlar melhor quem tem acesso ao que, seja no escritório, na estrada ou do outro lado do globo. Assim, a entrada a todas as áreas é monitorada e controlada sem incomodar o usuário.
Bloqueie antes que seja tarde
As empresas devem ser capazes de descobrir, classificar e avaliar dados sensíveis onde estiverem de modo a monitorar a atividade e garantir sua integridade. Este mesmo nível de proteção deve ser estendido às aplicações baseadas na nuvem.
Porém, a maioria dos aplicativos é criada por desenvolvedores que não têm a competência e conhecimento de como identificar vulnerabilidades em seu código, o que resulta em aplicações que podem ser facilmente exploradas por crackers. A análise de apps para identificar falhas de segurança deve ocorrer antes deles serem colocados em produção ou disponibilizados nas lojas de aplicativos.
Ajuste o foco
Atualmente, cerca de 75% das violações de segurança não são descobertas em dias, semanas ou até mesmo meses após ocorrerem. Se as empresas não têm visibilidade em tempo real de seu ambiente de TI agora, o que vai acontecer quando elas mudarem para uma nuvem híbrida, onde as coisas ficam ainda mais complexas?
As análises sofisticadas contornam esse impasse ao garantir visão clara de todos os sistemas. Desta forma, é possível colher insights sobre onde infrações e violações de conformidade ocorrem.
Não trabalhe sozinho
O Ponemon Institute aponta que uma média de 25.180 dispositivos, entre desktops, laptops, tablets e smartphones, estão conectados às redes e/ou sistemas empresariais. A adoção da nuvem em ascensão faz com que esse número cresça na velocidade da luz, superando as habilidades das equipes de segurança.
Como resultado, há um déficit de competências neste mercado que faz com que as empresas não “embarquem nesta viagem” sozinhas, mas que aproveitem a experiência de outros usuários para melhorar o tempo de resposta às ameaças na nova fronteira.
As festas acabaram – pelo menos até o carnaval. Para muitos, 2015 já começou… e será um ano com tendência a ser complicado (especialmente no Brasil). O contexto é uma razão a mais para “economizar dinheiro” ser uma boa resolução para por em prática nos próximos 12 meses.
Uma maneira fácil de cortar custos é reavaliar o pacote de softwares pelos quais você está pagando, e porque você está pagando por eles. Há muitas alternativas nessa frente que podem ser cortadas ou substituídas por versões mais baratas ou até gratuitas. Por que não experimentar?
Eis aqui quatro sugestões de software livre listadas pela PC World que podem ajudá-lo no brainstorming para que crie sua própria lista de medidas que permitam cortar custos com software. Um conjunto mais abrangente de soluções está disponível no site da publicação norte-americana (em inglês).
Segurança
Pagar por software antivírus há 10 anos era uma necessidade. Desde então, no entanto, uma série de suítes AV gratuitos têm aparecido. Vale ressaltar que algumas dessas versões grátis trazem também um pacote de aborrecimentos, como alguns anúncios durante o processo de instalação e o constante pedido para que o usuário migre para versões premium.
Dá para contornar isso usando apenas o que a Microsoft oferece gratuitamente. Caso esteja rodando Windows 7, faça o download do Security Essentials para antivírus e proteção contra malwares. Para as versões 8 e 8.1 do sistema operacional há uma ferramenta incorporada chamada Defender, que faz praticamente o mesmo que o MSE, acrescentando um reforço no rootkit e proteção bootkit.
Experimente-o por um tempo, pois, embora a ferramenta da Microsoft não seja tão cheia de recursos quanto a de fabricantes de segurança, trata-se de uma solução que pode dar conta do recado naqueles usuários que seguem “práticas inteligentes” de segurança. Caso não fique satisfeito, há sempre a possibilidade de testar outra suíte grátis ou partir para uma versão paga.
Edição de imagem
Graças a oferta de subscrição do Adobe Creative Cloud é possível ter o Photoshop e o Lightroom pagando US$ 10 por mês. É possível, ainda, economizar US$ 120 por ano se você recorrer as imensas ofertas grátis disponíveis. Se você gosta de apps de desktop, avalie o GIMP, o leve Irfanview ou o meio termo Paint.net. Caso goste de editar imagens online, poderá se surpreender com o Pixlr ou o Canva.
Gerenciamento de senhas
Dependendo do software que você escolher, pode gastar pouco (US$ 12 ao ano) para um gerenciador de senhas que funciona tanto em desktop e quanto em dispositivo móvel. Mas se você não quer pagar nada, experimente KeePass, uma opção grátis de código aberto que funciona em múltiplos aparelhos. A desvantagem da ferramenta é que você tem que ser responsável pelo seu próprio banco de dados de senha criptografada, enquanto que soluções superiores muitas vezes fazem esse trabalho para você.
Produtividade
A menos que você precise de uma tonelada de armazenamento no OneDrive, requer funcionalidades avançadas ou está preocupado com possíveis questões de compatibilidade – pagar pelo Office, independente da versão – talvez não faça muito sentido (pelo menos para uso pessoal).
Existem inúmeros pacotes de produtividade robustos e grátis. Nomes como o LibreOffice e OpenOffice. A suíte de produtividade Google Drive é muito poderosa para usuários casuais e agora embala funcionalidade off-line bem decentes.
Às vezes, pagar por software é a única opção se você tiver necessidades específicas, mas para o uso mais geral, alternativas livres podem servir tão bem quanto. Teste as alternativas sem custo… talvez, fazendo isso, você não tenha muito a perder. Certo?
Atualmente, é muito comum encontrar desenvolvedores, programadores e demais profissionais que aprenderam a programar sozinhos. Neste artigo vou comentar um pouco sobre os tipos de vícios e manias que acabo vendo em profissionais com este perfil.
Para começar, gostaria de destacar que fiz questão de não utilizar a palavra autodidata. O motivo é que este termo certamente não tem mais a mesma conotação e peso que tinha há algum tempo atrás. Isso se deve à necessidade de sempre aprender coisas novas da área e à grande quantidade e facilidade de acesso às informações disponível na Internet, especialmente para desenvolvedores. Sendo assim, não acredito que utilizar o termo autodidata contribui para expressar o tipo de pessoa que possui os comportamentos que vou descrever aqui. Afinal de contas, somos todos autodidatas em algum nível e isso não torna necessariamente alguém melhor ou pior que outra pessoa.
Outro aspecto que é importante citar antes de descrever os vícios e manias, é que tenho noção do fato que nem todo mundo que aprendeu a programar sozinho pode ter os vícios e manias que citei aqui. Sim, eu sei que muita gente passa longe das atitudes descritas, mas, infelizmente, durante a minha experiência profissional, tenho visto muitos perfis comprovando que, de fato, o aprendizado individual acaba fortalecendo vícios nada adequados para o ambiente de trabalho profissional com programação. Destaco também que não tenho nada contra quem aprende programação sozinho, até porquê sou um forte incentivador e produtor de conteúdo para este público.
Dificuldade no trabalho com uma equipe
Quem aprende a programar sozinho está acostumado a passar horas e horas isolado ou com pouca interação com outras pessoas. Enquanto este isolamento auxilia na concentração e esforço mental, ele possui um efeito colateral: a falta de entrosamento e a pouca aptidão para se trabalhar em equipe. Esta dificuldade envolve muitos pontos, mas vou me concentrar em apenas três: dificuldade de comunicação, desprezo por opiniões divergentes e atritos no relacionamento com superiores.
A comunicação é uma das mais importantes habilidades (soft skills) quando se trabalha com programação em uma equipe. É preciso saber avisar o que foi feito, pedir opiniões, comunicar problemas, descrever cenários, solicitar tarefas, negociar prazo e mais uma série de outras atividades que não podem ser feitas sem boas habilidades comunicativas. Contudo, as pessoas que aprendem a programar desenvolvem um vício que chamo de economia verbal, pois na mente destas pessoas quanto menos palavras forem ditas, melhor. É complicado conversar com um profissional com este vício em uma reunião, por exemplo, pois ele está tão aplicado em seu pensamento que praticamente despreza e dá o mínimo de atenção à comunicação.
Muitos programadores que conheci possuíam uma resistência e desprezo pelas sugestões, opiniões ou comentários relacionados aos códigos que eles escreveram, especialmente quando se cita alguma falha, problema ou possível melhoria. Estas atitudes mostram que há um forte senso de propriedade (algo como “o código é meu e eu sei o que faço!”) e falta de traquejo social para aceitar que nem sempre suas “crias” são as mais bonitas ou funcionam da melhor maneira possível. A provável razão deste comportamento é que quando a programação é realizada por uma pessoa que aprendeu sozinha, ela não recebeu críticas, aconselhamento, opiniões, revisão e outros inputs durante seu aprendizado. Esta falta de um par extra de olhos acaba levando o programador a adotar atitudes defensivas e, às vezes, até agressivas quando ele se depara com o que outras pessoas acham do seu código.
O aprendizado individual acaba reduzindo a noção de que durante o trabalho provavelmente teremos algum tipo de hierarquia, onde uma ou mais pessoas vão assumir papéis de liderança. Quando se aprende sozinho, o aprendiz é o seu próprio chefe e a cobrança é dele para ele mesmo. Contudo, no mundo real as coisas são um pouco diferentes, pois superiores (gerentes de projeto, supervisores, coordenadores e outros) possuem formas diferentes de pedir tarefas, cobrar resultados, trocar prioridades e gerenciar pessoas. Este conflito acaba levando a situações onde há algum nível de insubordinação que pode levar a ações punitivas. Na melhor das hipóteses, o aprendiz reconhece que ele deve ficar quieto, ouvir e obedecer. Na pior das hipóteses, pessoas abandonam equipes e juram que nunca mais vão trabalhar sob a supervisão de outros profissionais.
Falta de padronização na codificação
Quem aprende a programar sozinho presta pouca ou nenhuma atenção a detalhes como, por exemplo, a padronização dos nomes de elementos do programa. Se, por um lado, esta tarefa requer mais esforço e consome um pouco mais de tempo na codificação, por outro lado ela facilita muito a manutenção do código.
Apesar de muitos materiais didáticos, cursos, vídeos e outros recursos de ensino de programação recomendarem o uso de padrões de codificação, ainda é muito comum encontrar profissionais que ou fogem destas práticas ou as implementam de forma parcial. Este tipo de comportamento acontece com todo mundo durante a carreira, mas tenho visto uma tendência muito forte ao desrespeito aos padrões de codificação para nomes de variáveis, classes, métodos, funções, procedures, interfaces e outros elementos de programação em profissionais que aprenderam a programar sozinhos.
Em alguns momentos, a coisa ficou tão comum que já tive a impressão que estava perante uma epidemia de nomes ruins utilizados em variáveis, métodos, funções e procedures. A vacina? Revisão de código e regras que forçam certos padrões ao ponto do código fonte não ser utilizado por ter uma qualidade abaixo do mínimo aceitável para que outra pessoa trabalhe com ele no futuro – mesma se esta pessoa for o autor original deste código e que o programa esteja atendendo os requisitos funcionais.
Falta de conhecimento de ferramentas do mercado
Quem está aprendendo a programar geralmente escolhe alguma linguagem, ambiente, plataforma ou tecnologia para “pegar o jeito da coisa”. Agir desta maneira é OK, mas é preciso lembrar que uma coisa é como você está aprendendo e outra é como o mercado e as empresas usam esta tecnologia.
Por exemplo: durante o aprendizado básico de criação de CRUDs raramente são citados aspectos de controle de transação para situações, onde há a possibilidade de operações conflitantes. Já na realidade, é relativamente comum encontrar problemas clássicos como deadlocks, phanton records e outros que vêm de reboque quando um sistema começa a ter muitos usuários e alguma atitude para atender a escalabilidade já foi tomada.
Outro exemplo clássico é a falta de conhecimento e uso de sistemas de controle de versão. Afinal de contas, quem aprendeu sozinho não se depara com a necessidade de compartilhar seu código com outras pessoas. Esta falta de conhecimento e uso de ferramentas de controle de versão (GitHub, CVS, Mercurial, Team Foundation e outras) é tão notória quanto o desconhecimento de ferramentas de automação de build como o ANT, Maven e Gradle. Devido à necessidade de uso destas ferramentas nas empresas, é praticamente obrigatório um treinamento de novos colaboradores nestas tecnologias (o que acaba consumindo tempo e recursos valiosos que poderiam ser empregados em outras tarefas mais nobres).
Por fim, a prática de revisão de código (code review) soa como algo alienígena para quem estuda sozinho, afinal de contas por que eu pediria para alguém revisar o meu código enquanto estou aprendendo? Bem, sem entrar mais detalhes, basta dizer que sessões de revisão de código não podem mais ser consideradas um luxo, uma vez que seus benefícios já foram largamente comprovados em diversos estudos e situações reais.
Não investir na documentação
A documentação de código pode assumir vários formatos e, independente de como ela exista, é muito importante investir na sua criação. Esta documentação não é útil apenas para ajudar a esclarecer aspectos técnicos, mas também para organizar e gerenciar o trabalho de todos os profissionais envolvidos em um projeto de software, seja no presente ou no futuro.
Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item obrigatório em qualquer projeto, servindo a vários propósitos. Contudo, por questões culturais e outros motivos tradicionalmente o brasileiro não é conhecido pelas suas habilidades de organização e documentação.
Novamente, uma forma de traçar a origem deste sério problema é analisar quem aprende sozinho. Neste cenário, a tarefa de investir na criação de documentação recebe prioridade, pois o pensamento é que quem criou o código sempre vai se lembrar dele no futuro. Já escrevi um pouco sobre isso com foco no DBA, mas acredito que as lições e tipos de artefatos apresentados naquela ocasião ainda são válidos e podem ajudar quem dá pouca ou nenhuma atenção à documentação.
Foco na implementação e não no design
Durante o período de aprendizado, é comum gastar mais tempo tentando resolver os problemas do que analisando suas características. Isso já foi destacado no artigo que escrevi aqui no blog, onde discuti e apresentei recomendação sobre como focar no problema, ao invés da solução.
Quando me deparo com pessoas que aprenderam a programar sozinhas, na maioria das vezes fica claro o padrão de comportamento representado pela dificuldade de analisar, conceber e pensar no design da solução e como este design deve ser separado da implementação do código. A avidez por sair codificando e utilizando os recursos de produtividade das plataformas de desenvolvimento mostra que o design e arquitetura acabam ficando de lado perante aspectos de implementação.
Tal atitude também fortalece e favorece o trabalho customizado, no sentido de que a cada novo problema a maneira de resolvê-lo vai ser diferente da anterior. Este modo de trabalho ad hoc pode ser bom para cenários altamente voláteis e com requisitos imprevisíveis (algo raro) que tornam a previsão da próxima necessidade impossível de ser conhecida. Não obstante, geralmente o trabalho no dia a dia requer um nível alto de sistematização das atividades onde processos e práticas comuns são largamente empregadas sem muito desvio.
Este tipo de trabalho sistematizado, previsível e altamente compartimentalizado é visto com bons olhos na programação profissional, pois ele permite que sejam feitas previsões e que metas sejam completadas com sucesso dentro do prazo. O que quero dizer aqui é que o vício do modo cowboy de programação (também chamado de heróico) é muito comum em cenários onde o programador tem a convicção de resolver tudo sozinho e que sem sua “mágica” nada vai funcionar corretamente. Contudo, agir desta maneira pode acabar sendo contraproducente quando é preciso encarar a programação de modo profissional.
Muita duplicação de código e pouca reusabilidade
Quando analiso o código de outras pessoas, fico atento a um dos principais indícios que me permite identificar se estou lidando com alguém que aprendeu sozinho: o abuso dos recursos de copiar e colar representado pela alta taxa de duplicação de código e quase nenhuma usabilidade.
Os recursos de copiar e colar estão entre os principais truques que aumentam a produtividade de quem programa. E pela facilidade destas operações é quase uma consequência observar que tanta gente acaba duplicando de forma inadequada o código ao invés de utilizar técnicas adequadas de reusabilidade.
O abuso das técnicas de copiar e colar e códigos fontes é tão disseminado que uma vez conversando com um colega ele sugeriu uma atitude radical: a criação de um “polícia do copy & paste”. Esta polícia seria responsável por detectar, julgar, sentenciar, punir e criar novas leis para erradicar e obliterar o uso bizarro de copiar e colar em código fonte. Acho que não preciso dizer que este meu colega era responsável por dar manutenção em código fonte legado e não conhecia ou não praticava algumas das técnicas descritas para manipular código legado descritas em outro artigo meu.
Aqui vale a pena investir em design patters, refatoração, componentização, uso de frameworks e o tão negligenciado olhar focado no design através da boa modelagem de classes, relacionamentos, interfaces e outros elementos.
Para fechar este artigo, gostaria de terminar com um tom otimista: todas as pessoas que trabalham com programação possuem um ou outro hábito, vício ou mania ruim que pode ser melhorado. Isso faz parte do jogo. Mas acredito que nunca é tarde para para tentar reduzir o impacto que este hábito ruim pode trazer na vida profissional de um desenvolvedor.
No seu livro “O Dilema da Inovação”, Clayton Christensen categorizou três tipos de inovação: a que ele chamou de “melhorias de performance”, que substitui antigos produtos por modelos novos e melhores; as “inovações de eficiência”, que faz com que produtos já estabelecidos sejam vendidos melhores e por maiores preços; e, por fim, as inovações “market-creating”, que transformam produtos caros e complicados tão radicalmente que acaba criando uma nova classe de consumidores, ou um novo mercado. A partir dessas definições e dos principais cases de sucesso na área de tecnologia, podemos fazer algumas hipóteses sobre de onde vem a inovação, organizadas livremente em escolas de pensamento:
Emocional, de Marty Cagan: o criador do Silicon Valley Product Group chamou seu livro de “Inspired: How to develop products costumers love”, ou seja, “como desenvolver produtos que as pessoas amam”. De acordo com ele, as pessoas irritadas definem o futuro da tecnologia. Quanto maior o nível de raiva ou frustração que o setor causa ao cliente (como telecom, bancos, burocracia, empresas aéreas, planos de saúde etc), maior a chance de sucesso do produto que resolva esses problemas.
Mecanicista, de Steve Blank: o foco do pesquisador norte-americano está na startups e, neste contexto, ele diz que a inovação não é apenas implementar uma ideia criativa, mas procurar uma forma de transformar algum aspecto da ideia em alguma coisa que os consumidores querem tanto que pagariam para ter. Para ele, portanto, a ideia é irrelevante. Blank traz uma visão de empirismo extremo, na qual existe um processo sistemático de experimentos e validação de hipóteses que fará com que você chegue a alguma coisa de sucesso, se você estiver em um mercado suficientemente grande. O problema é que você pode ficar sem dinheiro antes de terminar esta trajetória e chegar na validação do seu modelo de negócio. Para atacar este tema, Eric Ries trouxe o movimento Lean (traduzido como enxuto) para estender o trabalho de Blank. A ideia é que você deve ser o mais enxuto possível para ser eficiente nesta busca e conseguir chegar ao ajuste produto x mercado antes que o dinheiro acabe.
Financeira, de Steve Denning: se apoiando no trabalho de Christensen, Denning afirma que a raiz do problema da falta de inovação de mercado é que as variáveis pelas quais os executivos são avaliados são relacionadas a lucros de curto prazo, e não sobre ROIC ou ROA (Retorno sobre Capital Investido e Retorno sobre Ativos). Para o autor, a falta de inovação é uma interpretação errada do papel da firma, que causa foco no curto prazo. A falta de atenção no longo prazo fez com que o retorno médio sobre ativos de 1965 a 2009 em toda economia americana caísse de aproximadamente 7% para 1,3% (segundo o índice Shift da Delloite). A falta de inovação de mercado e a busca de ganhos de curto prazo faz com que se precise de cinco vezes mais capital para ter o mesmo retorno financeiro. Se medimos a coisa errada, induzimos o comportamento errado e temos o resultado errado.
Cultural, de Mark Zuckerberg: quando dizemos que o Facebook tem uma “Cultura de Hacking” a ideia não é que os funcionários ficam invadindo sistemas para se divertir. Hackear um sistema, segundo o Facebook, é entender a diferença entre realidade percebida – ou o que as pessoas acham que são as regras – e a realidade – as regras reais que explicam o sistema. Neste contexto, a inovação aparece quando você hackeia o sistema e faz produtos que entrem nessa brecha. No prospecto do IPO do Facebook, o próprio Zuckerberg definiu o “Hacker Way” como construir algo rápido ou testar os limites do que pode ser feito (“hacking just means building something quickly or testing the boundaries of what can be done”).
Dinâmica, de Eric Schmidt: no livro “Como o Google Funciona”, o fundador da gigante junta dois fatores para a inovação: a busca por mudança com o uso de talento criativo. Em um mundo no qual as mudanças são cada vez mais numerosas e rápidas, as inovações vêm das próprias pessoas, que o Google chama de “smart creatives”, ou talento criativo. Para esta escola, o problema das empresas atuais é querer minimizar riscos ao invés de maximizar a liberdade e a velocidade. A única forma de inovar, segundo Schmidt, é atrair talentos criativos e criar um ambiente no qual eles possam prosperar com escalabilidade. Para eles, a inovação não pode ser apropriada ou determinada, mas permitida.
Radical, de Peter Thiel e Elon Musk, integrantes da “Máfia do PayPal”: para Thiel, um negócio inovador deve responder a sete questões: “você tem uma tecnologia que é um avanço?”; “seu “timing” está certo?”; “alguém mais faz isso?”; “você tem as pessoas certas?”; “você pode vender seu produto?”; “seu produto ainda estará disponível em dez anos?”; e, por fim, “você sabe de algo que ninguém mais sabe?”. Segundo eles, quanto mais respostas para essas sete perguntas o seu negócio tiver, mais chance de sucesso ele tem. Mas se você não consegue responder a maior parte das dúvidas, a maior chance é de fracasso.
Para terminar, destaco que as “escolas de pensamento” foram livremente criadas por mim, não há nenhum documento que as classifique como tal. Também é importante dizer que inovação em startups é um problema diferente de inovação em uma empresa estabelecida. Entretanto, precisamos observar como grandes nomes do mercado enxergam a questão de inovação e ideias no setor de tecnologia, e a simples reflexão de todos esses pensamentos pode ajudar, e muito, você a encontrar seu próprio caminho.
Tim Berners Lee propôs, em 1994, em uma conferência no CERN (European Organization for Nuclear Research), em Genebra, uma evolução da Web. Com desenhos não muito bonitos, mas em linguagem muito clara, o criador da Web defendeu em sua apresentação que a Web deixasse de ser só um índice de nodes linkados para ser um reservatório de significados. Algo que pudesse trazer para a Internet a complexidade e a beleza das relações entre humanos e máquinas. Assim, o conceito de Web dos Dados, uma rede de significados que se correlacionam, apareceu pela primeira vez. Para dar significado às coisas na Web é preciso ensinar às máquinas como ler estes significados. Já sabemos que o browser lê o que está escrito em linguagem humana por causa da mais famosa linguagem de marcação do mundo: o HTML. É ele quem diz para o browser o que o browser está apresentando e o que você está colocando na Internet através dele. Entretanto, o HTML não conseguia definir o significado e a relação entre os recursos. O W3C criou um domínio, ou uma força tarefa, para desenvolver tecnologias da Web Semântica: o W3C Semantic Web Activity.Desse grupo surgiram melhorias e padrões para evoluir a Web dos Dados de maneira concisa e também vários exemplos da Web Semântica aplicada. Em 2013, o grupo foi fechado e substituído pelo Data Activity, destinado a construir a Web dos Dados.
As principais funções da Web Semântica, conectar, descrever e entregar dados, foram cobertas por tecnologias simples: conectar com URIs (identificadores), representar ou descrever dados com modelos RDF e o SPARQL para extrair dos bancos de dados relacionais as respostas às perguntas que se quer responder quando construímos aplicações semânticas.
O modelo de descrição de recursos na Web, ou RDF, funciona descrevendo para as máquinas as relações e desambiguando os significados de cada node. Assim se formam as triplas, que são pequenas “frases” que os computadores conseguem entender e representar a partir dos recursos que colocamos na Web. Esses recursos, conectados pelos significados, vão formando gradualmente uma grande nuvem de recursos conectados, como na figura abaixo:
Web Semântica
No começo, os esforços se centraram no desenvolvimento de vocabulários, necessários para desenvolver as tags que os computadores entendem. A iniciativa do Linked Data Vocabularies, ou Vocabulários para Linked Data, foi muito importante nesse contexto porque ofereceu um ecossistema que cresce organicamente oferecendo uma grande variedade de vocabulários para descrever recursos. Esses vocabulários, quando em conjunto, formam as ontologias, que são conjuntos destinados a oferecer significados concisos para assuntos específicos. A existência de ontologias garante a interoperabilidade entre bancos de dados semânticos. Se interoperabilidade existe, é possível cruzar dados e experimentar trocas entre streamings de dados dinâmicos com menos esforços e recursos. A evolução desses calendários resultou na força tarefa liderada pelo Google que reuniu um monte de buscadores, entre eles o Bing, Google, Yahoo! e o Yandex para criar um esquema com “microdata” (não confundir com metadados!). Aqui tem um artigo bem bacana sobre o assunto para serem inseridos no markup, buscando melhorar os resultados de busca e fazendo com que os usuários tenham mais facilidade em encontrar o que querem na Web.
A Web Semântica também é chamada de Web de Dados conectados porque se apoia em uma miríade de recursos e tecnologias em desenvolvimento para retirar valor desses dados. Muitos grupos se esforçam para trazer essa realidade para a Web, seja com recomendações de como usar, seja abrindo o código de suas aplicações, seja se reunindo para desenvolver padrões novos que possam beneficiar os desenvolvedores com simplicidade e tecnologias maduras. Nesse sentido, as iniciativas de uso experimental dessas tecnologias são muito bem-vindas. Por exemplo, recentemente o JSON-LD foi lançado para ajudar desenvolvedores a conectar dados e dar significado à eles. Que tal testar?
O W3C Brasil lidera hoje, junto com a IBM e o governo britânico, o Working Group de Melhores Práticas para colocar Dados na Web, carinhosamente apelidado pelo acrônimo de #dwbp. Para se juntar às reuniões do grupo você precisa ser filiado ao W3C, mas para participar das discussões assíncronas pela lista de e-mails, basta mandar uma mensagem para public-dwbp-wg@w3.org com suas opiniões sobre o andamento das discussões do grupo.
Para saber mais, navegue pelos links abaixo e boa sorte!
Aqui na empresa, a cada ano, juntamos nossos cérebros para analisar as tendências que esperamos ver no próximo ano. Nossas previsões para 2014 incluíam os dados se movendo das mãos dos especialistas para pessoas comuns, a integração do business intelligence com a nuvem e o crescimento do NoSQL. O que 2015 nos reserva? Veja abaixo nossas 10 principais tendências para o mercado de inteligência empresarial em 2015.
1. Autoatendimento na análise cria novas práticas de governança de dados.
Como o panorama de inteligência empresarial se transformou da criação de relatórios estáticos em autoatendimento de dados interativos, a governança também deve passar por essa transformação. Atitudes como isolar todos os dados empresariais não funcionará por muito tempo – nem a abordagem de acabar com os processos. As organizações começarão a investigar o que significa a governança em um mundo de análise de autoatendimento. Os novos processos e as práticas recomendadas surgirão para manter os dados protegidos enquanto os executivos recebem respostas deles.
2. Publicitários e vendedores transformarão inteligência social em estratégias mais eficientes.
Em 2014, vimos que as organizações começaram a analisar os dados sociais com determinação. Em 2015, a liderança começará a se beneficiar de suas capacidades. Acompanhar conversas em escala social permitirá que as empresas descubram quando um assunto vai virar tendência e sobre o que os clientes estão conversando. A análise social abrirá a porta para a otimização ativa de produtos. E a vantagem decorrente disso fará os concorrentes sentirem que essas empresas possuem uma estranha capacidade de prever o futuro.
3. As competências de análise estarão em toda a organização.
O analista de dados de hoje pode ser um gerente de operações, o executivo de uma cadeia de fornecimento ou até mesmo um vendedor. Tecnologias novas e que oferecem análise fácil de usar e baseada em navegador permitem que as pessoas respondam a questões comerciais ad-hoc. Enquanto ainda haverá Analistas e Cientistas de Dados para o trabalho pesado, a análise de dados sofisticada se traduzirá em atividades rotineiras. As empresas que reconhecem isso como uma vantagem estratégica começarão a oferecer suporte a analistas com dados fáceis de se obter, ferramentas e treinamento para ajudá-los a desempenhar sua função.
4. As comunidades para usuários de software serão determinantes.
A consumerização da TI não é mais teórica; é um fato. As pessoas usam produtos que gostam de usar, e com o software de análise não é diferente. Elas gostam de participar e aprender com outros usuários, dentro e fora da empresa. As empresas cujos produtos inspiram e capacitam estão vendo suas comunidades florescerem. E os potenciais clientes também analisarão o funcionamento e a satisfação de comunidades de produtos como importantes pontos em mercados concorridos.
5. As soluções de análise devem integrar-se a outras ferramentas para tornarem-se o padrão.
Os últimos 10 anos nos mostraram uma enorme quantidade de inovação em todo o espaço de dados, resultando em ambientes mesclados para tudo, desde armazenamento de dados até análises para aplicações comerciais. Não veremos uma volta à era dos sistemas monolíticos. Entretanto, as empresas estão perdendo paciência com múltiplos logins e processos pesados para movimentar e gerenciar dados. Em 2015, veremos mais organizações adotando sistemas como logon único, e menos espaço para aplicações que não funcionam bem em um ecossistema mais amplo. As pessoas não aceitarão mais integração manual e problemas na qualidade de dados. A integração rápida que utiliza interfaces simples se tornará o padrão.
6. A análise em nuvem não será apenas para dados em nuvem.
Em 2015, começaremos a ver o primeiro uso importante da análise em nuvem: para dados no local. Até agora, a análise em nuvem tem sido usada principalmente para dados em aplicativos em nuvem. Em 2015, as empresas começarão a escolher a nuvem quando for viável para a situação comercial, não apenas porque os dados estão lá.
7. Narrativas com dados substituem painéis estáticos.
Estamos começando a entrar em uma era em que os dados são acessíveis e interativos o bastante, tanto que se tornam a espinha dorsal de uma conversa. Agora que as pessoas dispõem de ferramentas de análise bastante rápidas e flexíveis, elas podem analisar dados rapidamente, combiná-los com outros e projetá-los novamente para criar uma nova perspectiva. As reuniões podem ser mais participativas quando as pessoas exploram dados juntas, em vez de se arrastarem em um conjunto de slides e deixarem as ações para mais tarde. E como um resultado dessa colaboração, as organizações receberão mais informações a partir de seus dados.
8. Dados e jornalismo completam a combinação.
A chegada do Vox e o crescimento contínuo de sites como fivethirtyeight.com forçarão mais redações a integrarem análises de dados em sua presença online. Os leitores não ficarão mais satisfeitos apenas com o texto. Gráficos interativos e histórias guiadas estão se tornando mais essenciais para a geração móvel, e um ano importante de pré-eleição nos EUA acelerará o interesse das pessoas por dados. Essa tendência terá um efeito cascata desde a esfera pública até as organizações, incentivando as empresas atrasadas em análises a se atualizarem.
9. As análises móveis amadurecem.
Os trabalhadores estão passando menos temo em suas mesas. Mas isso não significa que devem estar menos informados por dados; de fato, eles precisam muito mais de dados do que nunca. As soluções móveis para muitas análises surgiram há anos e finalmente estão alcançando um nível de maturidade que significa que os trabalhadores móveis podem fazer análises simples em movimento. E a ênfase na mobilidade forçou fornecedores a oferecerem mais interfaces naturais e intuitivas de modo geral.
10. As capacidades de análise mais profundas serão acessíveis para leigos.
Avanços em modelagem gráfica e intuitiva significam que os usuários comerciais podem começar a usar análises preditivas sem a necessidade de consulta ou criação de scripts por especialistas. Conforme as análises de autoatendimento se tornam mais comuns e mais avançadas, a previsão básica se tornará uma atividade mais corriqueira e menos problemática. Produtos fortes permitirão a modelagem de autoatendimento e agregarão feedback intuitivo, que oferece aos usuários informações suficientes para compreender as armadilhas dos seus modelos.
O resultado é que esperamos ver cada vez mais pessoas, desde estudantes a executivos e jornalistas, tornando os dados uma parte de suas vidas. A maneira como as pessoas interagem com dados está mudando de forma rápida e, na maioria das vezes, para melhor.
O Twilio é um serviço totalmente baseado em sua API. De uma maneira simples, ele possibilita que empresas criem aplicações de voz e SMS de maneira confiável e escalável. Com uma infraestrutura de telefonia web, permite que desenvolvedores integrem ligações (fazer ou receber) em tempo real às suas aplicações – tudo isso com um modelo de cobrança “pay-as-you-go”. Com certeza uma das APIs mais legais de testar, não só pela utilidade e variedade de uso, mas também pela simplicidade.
Sendgrid
Área: envios de e-mails
O Sendgrid fornece infraestrutura escalável para envios de e-mails, incluindo toda a parte de Analytics de aberturas, cliques etc. Sua API possibilita o acesso a essas informações em tempo real, a criação de sub-contas e plugins, revenda e muito mais.
Dropbox
Área: armazenamento e sincronização de arquivos
A API do Dropbox permite que desenvolvedores não só criem, acessem e atualizem arquivos no Dropbox de usuários, como também disponibiliza a Datastore, uma estrutura de dados que permite a apps em diversas plataformas salvar dados dos usuários. Com milhões de usuários, é quase mandatório que um app (em qualquer plataforma) integre-se ao Dropbox.
Evernote
Área: anotações e lembretes
O Evernote, através de sua API, possibilitou a criação de um ecossistema riquíssimo de apps em torno dele, elevando seu potencial a níveis fantásticos. Desenvolvedores externos podem acessar a mesma API que é utilizada pelo time interno do Evernote, incluindo a possibilidade de criar, excluir, atualizar e ler notas, cadernos e tags. Além disso, o Evernote investe bastante esforço na divulgação de apps externos para seus usuários.
Zapier
Área: integrador de apps
O Zapier é uma aplicação que integra aplicações, permitindo que usuários escolham gatilhos de envios de dados e atualizações entre apps. Com sua API, desenvolvedores conseguem disponibilizar integração ao seu app e aos apps já disponíveis no Zapier. É a integração na nuvem funcionando magicamente.
Financeiro
Moip
Área: pagamentos online
O Moip é um serviço brasileiro de pagamentos online que possui grande proximidade junto à comunidade de desenvolvedores. Sua API dá a possibilidade de integração de pagamento Moip em diversos níveis, desde o check-out transparente (sem sair do website principal) até uma integração direta com o carrinho.
Credit Agricole
Área: banco
O CA (Credit Agricole), um dos maiores bancos franceses, foi o primeiro banco gigante a expor APIs, resultando em mais de 40 aplicações (em sua App Store para clientes). Isso propiciou a seus clientes uma gama muito maior de ferramentas para ajudá-los na organização de suas finanças, contas bancárias e cartões de crédito.
Este foi o primeiro resultado de uma nova onda no mundo financeiro, a tendência Open Banking.
PayPal
Área: pagamentos online
Similar ao Moip, o Paypal é uma gigante americana que também trabalha com pagamentos online. Um dos precursores do movimento de APIs abertas, as interfaces do Paypal incluem funcionalidades de transações, gerenciamento de invoices e contas, entre outras.
E-commerce
Marketplaces do Extra.com.br
Área: comércio eletrônico (marketplace)
Imagine colocar os produtos da sua loja para serem vendidos dentro de um dos maiores e-commerces do Brasil? Com certeza é uma ótima opção para lojistas expandirem suas vendas e para plataformas de e-commerce oferecerem como diferencial.
Buscapé
Área: comparação de preços e sistema de afiliados
Através de seu portal para desenvolvedores, o Buscapé dá acesso à sua API de comparação de preços e de seu sistema de afiliados (Lomadee). Dessa maneira, desenvolvedores externos podem usar sua base de produtos, ofertas e serviços publicitários em aplicações, sites, plugins etc. O Buscapé tem, inclusive, um programa de monetização para o desenvolvedor, baseado em CPA ou CPC.
Best Buy
Área: comércio eletrônico (catálogo)
Uma das gigantes do varejo americano, a Best Buy expõe APIs com informações de mais de 700 mil produtos, 400 marcas e 1 milhão de avaliações. Dessa forma, é possível construir apps que promovam uma melhor experiência de compra ao consumidor final. E, como não poderia faltar, há o programa de monetização por resultados gerados.
Public
Transparência Brasil
Área: política
A Transparência Brasil, uma ONG de combate à corrupção, disponibiliza APIs com as informações que ela coleta sobre políticos para que desenvolvedores criem apps que ajudem a população não só a votar com maior consciência e com base em dados, mas também a fiscalizar os políticos do congresso nacional.
Health
Fitbit
Área: saúde e exercícios (wearables)
O Fitbit é um dispositivo de coleta de informações de seus usuários relacionadas à saúde, peso, sono e atividades. Sua API dá a desenvolvedores acesso aos dados fornecidos pelos sensores. Assim, é possível que outros aplicativos relacionados à saúde, como apps de corrida, dieta e até prontuários eletrônicos, possam saber o quão ativo fisicamente um determinado usuário tem sido.
MyFitnessPal
Área: saúde e dieta
MyFitnessPal ajuda usuários a controlarem sua alimentação e exercícios, e sua API possibilita a desenvolveres não só integrarem apps a ele, mas também criarem novas aplicações com essas informações.
Internet das Coisas (IoT)
Ford
Área: automotiva
Com o boom dos carros conectados, a Ford foi uma das primeiras a criar um programa para desenvolvedores. Inicialmente, utilizando o AppLink e o Sync by Ford, é possível integrar aplicações de smartphones aos veículos. Mas lembre-se: só são aceitos apps que não tirem os olhos do motorista da estrada e as mãos da direção. E isso é só o começo.
Nest
Área: automação residencial
O Nest tem sensores e objetos inteligentes que se adequam à vida e aos costumes dos moradores da casa, como o Termostato e o Nest Protect (sensor de qualidade do ar e fumaça). Sua API permite a criação de aplicações que interagem com esses objetos.
SmartThings
Área: automação residencial
Com a plataforma SmartThings, é possível controlar objetos físicos como fechaduras e luzes. A API possibilita que essas funções sejam integradas a novos apps.
Xively
Área: Internet das Coisas (plataforma)
O Xively funciona no modelo PaaS (plataforma como serviço), facilitando a conexão entre objetos, informações, pessoas e lugares através de funcionalidades como troca de mensagens, arquivamento de dados, fornecimento e diretório de serviços. É exatamente através da API do Xavely que essas funções são oferecidas.
Variedades
YouTube
Área: vídeos online
A API do YouTube fornece um conjunto muito poderoso de funções, dando a desenvolvedores a opção de inserir toda a experiência do portal de vídeos dentro de suas aplicações. Além disso, é possível dar acesso a informações de usuários, possibilitando a personalização da experiência e de ações do usuário, como comentários e upload de vídeos.
Absolut Vodka
Área: bebidas
A fabricante de vodcas Absolut, como forma de incentivar o consumo de seus produtos, expôs em APIs receitas de drinks e outras informações sobre suas vodcas. Dessa forma, outras aplicações conseguem utilizar esses dados para melhorar sua experiência de uso e, de quebra, divulgar ainda mais o produto.
Marvel Comics
Área: entretenimento com super-heróis
Talvez uma das mais inusitadas, as APIs da Marvel Comics fornecem metadados do universo Marvel: criadores, personagens, histórias, crossovers e muito mais. Com certeza um prato cheio para desenvolvedores de apps de entretenimento.
Spotify
Área: música
O serviço de streaming e assinatura de música expõe um conjunto de APIs que inclui desde os gostos musicais de usuários e informações sobre músicas e artistas até funções como “seguir” no navegador e tocador de música. Informações e funções úteis não só para apps focadas no consumidor final, mas também em aplicações para artistas se divulgarem.
Yelp
Área: indicações de estabelecimentos comerciais
Com uma base dados extremamente rica, o Yelp ajuda usuários a encontrarem os serviços e lugares que melhor podem lhe atender localmente. Todas essas informações ficam disponíveis através de suas APIs para o enriquecimento de outras aplicações – alguns dos dados disponíveis: avaliações, comentários, endereços, números de telefone, fotos etc.
SaaS
Salesforce
Area: CRM online
O programa de desenvolvedores da Salesforce é uma das referências no mundo, não só pelo conjunto de serviços e informações expostas via APIs, mas também pelo engajamento criado através de ações como o “Hackathon de U$ 1 milhão”. As APIs ajudam desenvolvedores a criarem novas aplicações com base nas informações da empresa que estão no Salesforce ou sobre suas funções. Com certeza um dos mais completos espectros possíveis de ação para desenvolvedores externos.
Superlógica
Área: gestão financeira
A Superlógica é uma aplicação brasileira de gestão financeira empresarial. A API expõe as funções da ferramenta, possibilitando a criação de novas aplicações turbinadas por elas, ou mesmo de ERPs completos.
Com o “boom” das estratégias digitais em mobilidade, cloud computing, mídias sociais e os dispositivos inteligentes da Internet das Coisas, muitas empresas estão desenhando e expondo REST APIs – desde jovens startups até grandes empresas.
Em setembro deste ano aconteceu, no evento Tech Crunch Disrupt, em San Francisco (EUA), a batalha das startups (Battle of Startups), competição que reúne algumas das startups mais badaladas do mundo. O ponto aqui é que praticamente todas expõem e/ou consumem APIs freneticamente para concretizar sua proposta de valor. Além disso, o Gartner lançou recentemente um estudo intitulado “Hype Cycle For Open Banking, APIs, APPs, APP Stores”, no qual determina de forma inequívoca que o mercado financeiro está passando por uma revolução, e essa revolução está sendo impulsionada pela exposição de APIs.
Ou seja, nanicos e mamutes estão no jogo das APIs.
A relevância do assunto para a comunidade de desenvolvedores também pode ser vista pela lente da última edição da revista. Foram 4 matérias com grande destaque para o assunto API:
API nativa para gerenciamento de senhas
Device agnostic
É hora de programar a sua casa
Apiary, fazendo muito mais que documentar
Muito se comenta sobre a estratégia mobile-first, ou seja, desenhar as soluções com foco em dispositivos de tela e capacidades computacionais mais reduzidas se comparadas aos desktops. Isso certamente nos obriga a enfatizar a simplicidade. Entretanto, quando você combina o pensamento mobile-first com “device agnostic”, “internet of things” e também “open source”, pronto, você já não sabe mais quem será o usuário da sua solução e muito menos em que tipo de dispositivo ela será usada.
Por isso, vem crescendo a estratégia API-first, que prega a separação de responsabilidades entre o front e o backend e a elegância das interfaces de, além das mensagens trocadas entre os dispositivos e seus servidores.
Se a sua empresa irá expor APIs para parceiros e desenvolvedores externos, é muito importante considerar seriamente aspectos de segurança, escalabilidade e design já no momento da sua construção.
Quer tornar sua API sensacional? Veja alguns atributos abaixo:
Batom em lábio de porco
Tudo começa com a proposta de valor da API. Se ela não trouxer valor real para o público-alvo e não tiver ligação com os objetivos de negócio da empresa, será como embelezar um porco, ou seja, não adiantará portal para desenvolvedores com documentação linda, pois, no fundo, continuará sendo um porco. Então, ela precisa trazer informações ou transações úteis que possam atacar necessidades reais para atrair outras empresas e seus desenvolvedores.
O correto design RESTful
Muitas implementações de APIs não têm aplicado os princípios básicos de design RESTful, dificultando o entendimento dos desenvolvedores que devem consumir as APIs e causando problemas de escalabilidade, segurança, interoperabilidade, entre outros.
O uso correto das operações do HTTP, a formação dos recursos, versionamento, paginação, caching, entre vários outros, influenciam de forma decisiva a facilidade de entendimento e de uso da API. Mesmo que as regras de negócio sejam complexas, as APIs devem ser modeladas tendo como mote a simplicidade.
A (in)segurança dos dados abertos
Seja sua API privada (usada por apps desenvolvidos por sua própria equipe), ou pública (acessível por qualquer desenvolvedor), há aspectos críticos em segurança que devem ser observados. APIs “ligeiramente escondidas” não são seguras o suficiente. As soluções vão desde um simples HTTPS, passando por tokens de aplicação, e chegando a modelos um pouco mais sofisticados, como o OAuth 2.0.
Toda a glória aos desenvolvedores
“Geek is the new sexy”, dizia uma camiseta que vi na última Campus Party, em São Paulo. Atualmente, os bons desenvolvedores, designers e empreendedores em high-tech são disputados pelas empresas que desejam construir ecossistemas digitais plugados à sua plataforma através de APIs. Então, o mínimo que se espera é que a empresa dedique um site aos desenvolvedores (que tal http://developers.[suaempresa].com.br?), no qual são oferecidas documentação técnica, chaves de acesso e sandbox para testes das APIs, além de ferramentas especiais, SDKs e suporte diferenciado?
Keeping it always ON
Se a proposta de valor for bacana, o design primoroso, os dados trafegarem de forma segura e os developers tiverem destaque na estratégia, o sucesso virá e é só relaxar que tudo vai funcionar maravilhosamente bem, certo? Claro que não! Você sabe: seus servidores ficarão lentos sem qualquer explicação, sua API vai cair no fim de semana, você vai quebrar os clientes que te encherão de tickets e tudo pode afundar.
A dica aqui é pensar em soluções de API Management que poderão colocar mecanismos de proteção dos sistemas de backend, rate limiting, garantia de SLAs e monitoração de desempenho. O ponto é: saiba dos problemas antes dos clientes e mantenha uma política transparente de comunicação.
O risco e o potencial dos dados abertos
Usar APIs abertas de outras empresas traz um risco considerável para seu negócio. Quem garante que a API vai cumprir o SLA de desempenho? Ou que o provedor não vai mudar a interface e quebrar sua aplicação? Quem garante que a empresa ainda estará por aí amanhã? Essas já são dúvidas suficientemente críticas. Não torne a vida do desenvolvedor ainda mais infernal: ajude-o a gostar de você!
Uma estratégia de APIs abertas tem o potencial incrível de dar mais capilaridade, aumentando o alcance dos seus dados e soluções. Como forma de inspiração, veja a pesquisa que traz diversos exemplos de empresas que construíram APIs sensacionais – ela está nas páginas seguintes a este artigo na revista. A maioria, como era de se esperar, é de empresas internacionais, mas repare também que já temos brazucas abusados!
Vamos além das já desbravadas APIs sociais do Facebook e Twitter, claro. Alguns segmentos vêm se destacando na exposição de APIs, como empresas de e-commerce, Internet das Coisas, Saúde e Bem Estar, Serviços Utilitários e Serviços Financeiros.
Já os dados abertos governamentais merecem um capítulo à parte. Ainda de forma tímida, muitas prefeituras e órgãos de Governo têm organizado hackathons para que a comunidade de desenvolvedores possa criar aplicações inovadoras que melhorem a qualidade do serviço público e a vida das pessoas nas grandes cidades. Muitos desses hackathons, entretanto, acabam não usando dados vivos disponibilizados via API, e sim trabalhando apenas com download de planilhas e PDFs estáticos. Há um grande potencial a ser explorado aqui.
Pudemos ver um exemplo desse potencial quando a Transparência Brasil, ONG de combate à corrupção, lançou sua API em agosto deste ano e, menos de 15 dias depois, durante o hackathon para promoção dos dados, anunciou que o portal de developers já contava com mais de 800 desenvolvedores cadastrados, cerca de 250 aplicativos e mais de 20 milhões de calls. Incrível, não?
Se os seus dados são relevantes, torne-os acessíveis e eles chegarão a lugares que você nunca imaginou. As startups mais badaladas e as empresas gigantes mais conectadas já perceberam. Se sua empresa ainda não expõe, está um passo atrás.
