Category: pt-br

UFSCar DW EES

Está página é para os alunos da UFSCar Campus Sorocaba, especialização em Engenharia de Software EES, disciplina desenvolvimento Web (DW) com Node.js.

1 – Slides da Aula 1

Link

2 – Códigos Fontes da Aula 1

https://github.com/klebercarvalho/UFSCar-DW-EES/

3 – Acordo Avaliação (Prova, Trabalho, Apresentação)

Link

4 – Lista dos Grupo do Trabalho

Link

5 – Node CRUD Mongo – Tutorial

Link

6 – Node CRUD Mongo – github

Link

7 – Node API Mongo

Link

8 – Node API Mongo – github

Link

9 – Node REST API Auth

Link

10 – Node REST API Auth – github

Link

10 – Top REST API Best Practices

11- Exercícios – Estilo e potenciais perguntas para a prova

Link

12- TDD Node Mocha Chai

Link

13- TDD Node Jest

Link

14 – Prova

Link

Front-end stack

O processo de desenvolvimento web pode se dividir em três categorias: design, front-end e back-end. Na minha opinião, a categoria que tem mais processos manuais e repetitivos é sem duvida o front-end.

Pare pra pensar: o core do trabalho do front-end se resume em duas partes:

  • implementação do layout: produção da primeira camada de código, onde replicamos o layout criado em algum programa gráfico, para código estático em HTML, CSS e JS.
  • integração com API: depois (ou junto, tanto faz) de feito o código estático, a interface é integrada com a API, que geralmente carrega boa parte da lógica, já que essa mesma API é usada para alimentar outras plataformas como mobile, robôs etc.

As outras “responsabilidades” que orbitam em volta do front-end como acessibilidade, SEO, performance, compatibilidade entre browsers, código semântico, entre outras coisas que você pode julgar serem de responsabilidade de um front-end são um mero apetrecho. Elas podem existir ou não em um projeto. Mas um projeto não sobrevive sem o código front-end do layout e sem o conteúdo integrado à interface.

Um observação: acessibilidade é algo que as máquinas podem fazer muito melhor que um ser humano. Embora eu tenha colocado como algo que possa existir ou não em um projeto, é importante demais que você faça um esforço para que todos os seus projetos sejam acessíveis. Eu sei que isso não é a realidade até hoje no mercado e provavelmente nunca será até que esse processo seja automatizado.

Existem uma série de tarefas manuais que nós delegamos para ferramentas criadas afim de economizar parte do nosso tempo evitando a execução de tarefas repetitivas, automatizando o workflow do front-end. Só para citar algumas:

  • Pre-processadores CSS: Sass, Less, Stylus
  • Task runners: Gulp, Grunt , Make, NPM Scripts
  • Scaffolding: Yeoman, Slush
  • Dependências/Module Bundles: Bower, NPM, Yarn, Webpack, Duo, RequireJS, Browserify, JSPM, Rollup
  • SPA/Libraries/Frameworks: React, Angular, Vue.js, Backbone, EmberJS, todomvc, Polymer, Lodash, Aurelia, MeteorJS
  • CSS Frameworks/Libraries: SemanticUI, Bootstrap, Foundation, UiKit, YUI, Susy
  • JS Test: Mocha, Jasmine, QUnit, Ava, Tape, Jest
  • JS Templates: Underscore, Mustache, Handlebars, DoT, Dust, EJS

Mas mesmo com todas essas ferramentas, o core da responsabilidade de um front-end ainda continua sendo implementar layout original e integrar a interface com o back-end. Você ainda continua replicando o layout que alguém passou dias desenhando e integra o conteúdo que está numa API, que outra pessoa criou. Seu dia se resume em alternar entre as janelas do Sublime / Sketch / Browser / Sublime / API / Browser / Sublime.

“Automation isn’t about being lazy. It’s about being efficient.” — Addy Osmani

Esse processo se torna tedioso e a lista de requisitos para tentar tornar o trabalho de front-end eficiente só aumenta. Toda tarefa mecânica, repetitiva e manual tende a ser automatizada e na minha opinião, em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.

Okay, respira. Isso é a minha opinião. Dado que o front-end é a parte mais operacional de todo o processo, mais cedo ou mais tarde todo o trabalho executado no front-end vai ser automatizado. A parte mais difícil são essas duas tarefas que nós fazemos desde os primórdios. Contudo, elas já podem estar com seus dias contados.

Trabalhando com dados reais direto no Design

Você pode não ser designer, mas há uma premissa no mundo dos designers que diz que você deve trabalhar sempre com conteúdo real. Isso quer dizer que entregar um layout com texto em Lorem Ipsum Dolor é coisa de designer júnior.

“If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source.” — Jason Fried

A ideia é que você crie um layout da forma mais fiel possível usando os termos, palavras, nomes, datas etc, a fim de chegar mais perto da experiência do usuário.

Atualmente a maioria dos programas visuais utilizados para criar layouts para web tem alguma feature ou plugin que permite a integração com alguma fonte de dados que contenha o conteúdo real.

Por exemplo o Sketch, que é o programa de criação visual mais querido do momento, conta com plugins que permitem a integração direta entre API e layout. Veja por exemplo o vídeo abaixo demonstrando a utilização do plugin Craft (também disponível para Photoshop):

Ou essa demonstração que usa a API do Stackoverflow:

Em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.

O ponto aqui é: nós só precisamos criar o layout uma vez, usando o programa desejado (Sketch/Photoshop/Figma/Adobe XD etc) e pronto. Não precisamos de uma pessoa para refazer esse layout com HTML/CSS/JS de forma alguma. Isso nos leva para uma segunda discussão: mesmo com o design pronto, usando dados reais de uma API, nós ainda precisamos que ele seja acessível pelos browsers. Como resolvemos isso?

Obs.: E aquele movimento do “Design in the Browser”? Esse é um movimento criado exatamente para evitar o trabalho de produzir duas vezes o mesmo layout. Mas é MUITO melhor fazer um design usando um programa visual do que escrever direto no código. IMHO.

 

https://tableless.com.br/carreira-de-front-end-vai-morrer/

IBM Compra Red Hat

A IBM  comprou a Red Hat US$ 34 bilhões

https://www.tecmundo.com.br/mercado/135646-ibm-anuncia-compra-red-hat.htm

Para entender esse mercado é preciso entender o mercado Cloud hoje:

 

 

Veja que cada dia que passa, a Amazon nada de braçada nesse mercado cloud.  Isso significa que empresas tradicionais e startup estão criando sua infraestrutura em Cloud ao invés de ter uma solução em um data center tradicional, conhecida como on premise.

A Microsoft segue na segunda posição, principalmente porque fez duas belas aquisições o LinkedIn (maior rede social profissional do mundo) e  Github (maior rede social de codigo do mundo. Se você acha pouco isso, imagine o poder de análise de dados que a Microsoft pode fazer analizando os dados dessas duas empresas para descobrir tendendência na área de Ti. Não é pouco né?

Minha experiência em startup fora do Brasil mostra que Amazon é líder, mas vejo uma forte tendência na nuvem do Google também. Vejo a Microsoft muito forte em empresa que usam .NET, mas pode ser uma perspectiva equivocada minha. A Microsoft é vice líder, porque tem trabalhado duro para a comunidade open source e merce respeito.

A IBM compra a Red Hat

A IBM comprar a Red Hat significa um excelente movimento da Big Blue. A Red Hat tem um dos líderes de Linux em servidores, junto com o Canonical Ubuntu, o Red Hat Linux, e a Red Hat tem uma pilha de produtos baseado no modelo Open Source de sucesso. Lembrando que a Red Hat comprou a JBoss e soube integrar muito bem essa nova empresa dentro da Red Hat. O mesmo não aconteceu quando por exemplo a Oracle comprou a Sun.  O desenvolvimento Java ficou lento, e Oracle e Sun, tinham muitos produtos semelhantes para a mesma finalidade.

Espero que a IBM tenha aprendido lições com essa junção de Red Hat e JBoss, e Oracle e Sun e não cometa os mesmo erros. No press release deles, a ideia e manter as empresas separadas no modelo que a Microsoft fez com o LinkedIn e Github.

A Red Hat por ser um empresa mais enxuta, tem entregado um modelo open source e comercial mais eficiente neste momento. Compare o desempenho de lucro da Red Hat e IBM nos ultimos anos.  O Cloud da Red Hat não está bem posicionado ainda no mundo Cloud comparada com a Amazon, por isso um junção entre IBM e Red Hat vai ser boa para as duas empresas.

Histórico de ações da IBM nos últimos 5 anos

Histórico de ações da Red Hat nos últimos 5 anos

Histórico de ações da Amazn nos últimos 5 anos

A Red Hat é uma empresa admirada no mundo open source, assim com a IBM, mas ambas precisam juntar forças para não deixar Amazon nadar de braçadas no mundo Cloud.

Torço pelo sucesso de junção entre IBM e Red Hat. Se a junção for bem feita, tenho certeza que será um sucesso.

 

 

O que é Design Thinking

 

 

 

 

O que significa design thinking? Quais são suas etapas?

A primeira informação que deve ficar clara é que não é uma metodologia, e sim uma abordagem. Isso porque, quando pensamos em método, criamos a expectativa de ter às mãos uma fórmula matemática que se aplique indistintamente em qualquer situação. Não é o caso.

É uma abordagem que busca a solução de problemas de forma coletiva e colaborativa, em uma perspectiva de empatia máxima com seus stakeholders (interessados): as pessoas são colocadas no centro de desenvolvimento do produto – não somente o consumidor final, mas todos os envolvidos na ideia (trabalhos em equipes multidisciplinares são comuns nesse conceito).

O processo consiste em tentar mapear e mesclar a experiência cultural, a visão de mundo e os processos inseridos na vida dos indivíduos, no intuito de obter uma visão mais completa na solução de problemas e, dessa forma, melhor identificar as barreiras e gerar alternativas viáveis para transpô-las. Não parte de premissas matemáticas, parte do levantamento das reais necessidades de seu consumidor; trata-se de uma abordagem preponderantemente “humana” e que pode ser usada em qualquer área de negócio.

A razão de sua existência é a satisfação do cliente (interno ou externo), dádiva que só pode ser alcançada quando conhecemos em profundidade suas necessidades, desejos e percepções de mundo.

As etapas do design thinking podem, em geral, ser resumidas pelos seguintes passos:

1- Identificar onde encontrar oportunidades de inovação

“Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você se conhece, mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota. Se você não conhece nem o inimigo nem a si mesmo, perderá todas as batalhas”. Este é um trecho de “A Arte da Guerra”, do filósofo chinês Sun Tzu, e que diz muito sobre o ponto que estamos abordando.

Descobrir onde encontrar caminhos para inovar envolve conhecer a si mesmo e ao ambiente externo. Conhecer seus pontos fortes, as fragilidades da concorrência, as condições macroeconômicas, etc. Análise SWOT, benchmarking, pesquisas de mercado e reuniões multidisciplinares te conduzirão às respostas para esse ponto.

2- Descobrir a Oportunidade de Inovação

Consequência direta do ponto anterior, aqui, pesquisas qualitativas e trabalho com soluções de Big Social Data podem indicar, muito além do setor, qual é, de fato, a oportunidade que o mercado desenha ao seu negócio.

3- Desenvolver a Oportunidade de Inovação (Produto ou Serviço)

O design thinking começa a tomar corpo nessa etapa. Aqui, iremos desenvolver o produto ou serviço partindo, não de pressuposições ou análises estatísticas frias (algo comum no mercado), mas a partir das necessidades e percepção de valor do cliente. Nesta etapa, poderemos lançar mão do Processo Heurístico para descobrir o diagnóstico e o Processo Criativo para gerar as possibilidades de produtos.

4- Testar as ideias — protótipos

Um MVP – Minimum Viable Product é uma bela dica do que se pode fazer nesse item. Para quem não sabe, MVP (muito usado em startups) é a versão mais simples de um produto, que pode ser lançada em período de testes, para verificar, sem grandes gastos, se sua ideia realmente atinge as necessidades do seu consumidor final.

5- Implementar a solução

Após testes com respostas positivas acerca de seu produto, ele já está pronto para ser lançado “aos leões”. É importante entender que o processo de desenvolvimento do produto é contínuo e incremental, ou seja, sua ideia irá ser melhorada permanente através um processo de copartipação entre todos os seus stakeholders (clientes, fornecedores, colaboradores internos, etc.).

Domain Driven Design

Domain Driven Design

Por Eric Evans

Todo software corporativo resolve problemas de negócio. E nada melhor do que o código fonte falar a mesma linguagem dos negócios em vez de tentar reinventar a roda com jargões e termos que não serão compreendidos pelas pessoas de negócios. Este livro ensina a criar uma linguagem comum entre desenvolvedores e usuários, e a pensar no design do código de uma maneira que favoreça o entendimento e a evolução do software através de padrões que colocam em primeiro lugar o domínio de negócio.

Versão em Inglês http://amzn.to/2DYqGe6 ou Português http://amzn.to/2Ds1EmJ

Domain-Driven Design – Resumo

Filosofia – filo (amor), sofia(sabedoria) – O software tem que ser importante para você.

Tracking complexity – O software não precisa ser complexo.

Heart of Software / Core Domain – O que faz as pessoas usarem o seu software e não usarem outro.

Domain – Tudo que compreende o software. Alinhamento com o negócio. Isolamento entre domínio. Reutilização. Mínimo acoplamento. Independente de tecnologia.

Modelo – é um gráfico

Domain model – A representação de uma domain.

Modelar um domínio – abstrair o que não é necessário, e focar no que é interessante.

Problemas de Comunicação – Fazemos presunções o tempo todo. Você acha que entendeu, mas não entendeu.

Ubiquitous Language – Existem um vocabulário em cada mercado. Por exemplo em um imobiliária.

Literate Programming –  When/Given/Then – BDD

Status quaestionis – Public request (PR), commit message etc.

Os Melhores Livros sobre Arquitetura e Design de Software

Neste post gostaria de fazer algumas recomendações de Livros sobre Arquitetura e Design de Software para programadores, desenvolvedores de software, arquitetos de software, e engenheiros de software que trabalham em times ágeis.

Estes Livros sobre Arquitetura e Design de Software tratam de assuntos boas práticas de programação, design, arquitetura, testes e requisitos não funcionais como performance, segurança e escalabilidade.

Para facilitar, procurei deixar links para as versões em português e inglês dos livros, muito embora, eu recomendo, sempre que possível que você leia versão original em inglês.

1) Working effectively with legacy code (Trabalho Eficaz com Código Legado)

É mais fácil escrever código novo do que dar manutenção em código legado, e quase todos os desenvolvedores que conheço preferem trabalhar num projeto novo ou em uma nova funcionalidade do que dar manutenção em código legado. Mas na vida real, boa parte do trabalho dos desenvolvedores é fazer melhorias e alterar código legado. Por isso considero esse livro é fundamental para todo desenvolvedor. O livro trata de padrões e técnicas para que você possa evoluir o código legado sem ter que reescrever tudo, e com fazendo testes de unidade para evitar quebrar alguma funcionalidades pré-existente, mesmo nos casos mais desafiadores em que o design do código não facilita a testabilidade.

Versão em Inglês http://amzn.to/2DYW4Jv ou Português: http://amzn.to/2DYbgXc

 

2) Clean Code (Código Limpo)

Por Robert C. Martin

Este livro vai te ensinar a escrever código fácil de se entender, tanto para você mesmo quando para o os demais membros do seu time. É um livro realmente transformador. Depois de ler esse livro, você vai mudar completamente a maneira que codifica, e pode ter certeza que vai gerar um grande impacto na sua própria produtividade bem como na produtividade da sua equipe com um todo.

Versão em Inglês http://amzn.to/2DXsX9n ou Português http://amzn.to/2DCvRCA

3) Patterns of Enterprise Application Architecture

Por Martin Fowler

A linha entre o que é Design de Software e Arquitetura de Software é muito tênue e difícil de se definir mesmo para os maiores estudiosos da área. Martin Fowler, sem dúvida, é uma das principais mentes no Design e Arquitetura de Software, e nesse livro ele explora uma série de padrões que vão te ajudar a construir aplicativos corporativos complexos com boas práticas para performance, escalabilidade, segurança e manutenabilidade.

Versão em Inglês http://amzn.to/2DYCIUM ou Português http://amzn.to/2DAa2DJ

 

4) Domain Driven Design

Por Eric Evans

Todo software corporativo resolve problemas de negócio. E nada melhor do que o código fonte falar a mesma linguagem dos negócios em vez de tentar reinventar a roda com jargões e termos que não serão compreendidos pelas pessoas de negócios. Este livro ensina a criar uma linguagem comum entre desenvolvedores e usuários, e a pensar no design do código de uma maneira que favoreça o entendimento e a evolução do software através de padrões que colocam em primeiro lugar o domínio de negócio.

Versão em Inglês http://amzn.to/2DYqGe6 ou Português http://amzn.to/2Ds1EmJ

5) Refactoring: Improving the Design of Existing Code

Por Martin Fowler

A Refatoração é uma das principais técnicas ágeis de engenharia de software, e fundamental para a evolução profissional de sistemas. Este livro explica detalhamento os principais conceitos e explora as melhores práticas para que você possa melhorar constantemente o código sem alterar a funcionalidade do software.

Versão em Inglês: http://amzn.to/2F3EYtd ou Português: http://amzn.to/2Dz4mKm

6) Growing Object-Oriented Software

Por Nat Pryce, Freeman Steve

Este livro vai unir alguns conceitos dos livros citados anteriormente como Refatoração, Test Driven Development (TDD), Design Patterns e Testes Unitários e te ajudar a juntar todas as peças para aplicar tudo isso em conjunto no seu dia-a-dia.

Versão em Inglês: http://amzn.to/2F4vFtc ou Português: http://amzn.to/2DCzwR6

7) The Pragmatic Programmer

Por Andy Hunt, Dave Thomas

De todas as recomendações esse livro é o menos técnico, e mais conceitual, mas de forma alguma é menos importante. Ele vai trabalhar o seu mindset para que nunca deixe se aprender, de se desafiar, e vai te trazer conceitos de muita maturidade profissional, que talvez você levaria anos para conquistar sozinho.

Versão em Inglês: http://amzn.to/2E30hfr ou Português: http://amzn.to/2DDVraJ

8) Clean Architecture

Por Robert C. Martin

Esse livro vai te ensinar conceitos importantes para entender os diferentes paradigmas de programação (programação orientada a objetos, programação funcional e programação estruturada) além de abordar princípios para um bom design como o princípio da responsabilidade única, o princípio da substituição de Liskov, e injeção de dependências.

Versão em Inglês: http://amzn.to/2DtsHhz

9) Building Evolutionary Architectures: Support Constant Change

Por Neal Ford, Rebecca Parsons, Patrick Kua

Depois de anos atuando como consultor em diferentes projetos de empresas de todos os tamanhos, Neal Ford, compartilha nesse livros as principais lições aprendidas para a construção de sistemas que nunca podem parar de evoluir.

Versão em Inglês: http://amzn.to/2DAcRoj 

10) Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Por Jez Humble, David Farley

O ritmo da inovação tecnológica vem aumentando cada vez mais, e por isso, fazer deploy de novas versões deve ser fácil rápido e sem perda de disponibilidade, porém, para que isso seja possível é preciso que código e arquitetura do software seja projetada para atender esses requisitos. Nesse livro você vai aprender as mais importantes técnicas, princípios e ferramentas para fazer entrega contínua em seus projetos.

Versão em Inglês: http://amzn.to/2Dznd7Z
Versão em Português: http://amzn.to/2E073T7

11) Beyond Software Architecture: Creating and Sustaining Winning Solutions

Autor Luke Hohmann

Esse livro traz uma visão interessante sobre coisas importantes a serem levadas em consideração que vão além da codificação, testes, design e arquitetura de software, coisas como licenciamento, entrega (deploy), instalação, configuração, e suporte.

Versão em Inglês: http://amzn.to/2E0ehXc

12)  97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

Autor Richard Monson-Haefel

Com participação de grandes ícones do mundo da engenharia de software esse livro traz lições muitos interessantes e valiosas que podem evitar que você e sua empresa paguem por erros que outros já comeram como colocar seu currículo ou suas tecnologias de preferência na frente dos requisitos do sistema em desenvolvimento, subestimar problemas não técnicos, não desenvolver habilidades de comunicação efetivas, não dar a devida importância a interface de usuário, deixar a performance de lado na hora de desenvolver.

Versão em Inglês http://amzn.to/2G3Hdy9

13) Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Autores Gregor Hohpe, Bobby Woolf

Este foi o livro que deu origem ao Camel um dos principais frameworks de integração de softwares corporativos no mundo. Sabemos que quase nenhum software funciona isolado. O ERP precisa buscar dados de clientes do CRM para faturar, e integrar com o banco para consultar o saldo da conta bancária, o CRM conecta nas redes sociais para verificar o engajamento dos clientes, o software de forecasting conecta no Canal do Tempo para verificar se o Supermercado vai vender mais cerveja do que no próximo final de semana. Este livro vai te dar uma base forte sobre Integração de Software para que você construa sistemas que conversam melhor com o mundo externo de forma segura, escalável, interoperáveis e com alta disponibilidade.

Versão em Inglês: http://amzn.to/2G7BMxW

Comparing AWS Lambda performance

Comparing AWS Lambda performance when using Node.js, Java, C# or Python
How differently does a function perform when using the different programming languages supported by AWS Lambda?
https://read.acloud.guru/comparing-aws-lambda-performance-when-using-node-js-java-c-or-python-281bef2c740f

Comparing AWS Lambda performance of Node.js, Python, Java, C# and Go
An updated runtime performance benchmark of all five programming languages supported by AWS Lambda
https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581

API Gateway vs API Manager

API Gateway
API Gateway cria um ponto único de acesso, filtrando quem acessa suas APIs. Considere um API Gateway como uma ferramenta para redirecionamento e filtragem de tráfego de terceiros.

API Manager
Este tipo de produto de fornece uma camada de gestão para API Gateways. Além de definir o comportamento do API Gateway, o API Manager lida com análises de cada requisição, insight corporativos através das análises, implementação de controle de versão, criação de dashboard de acesso, possibilidade de monetização e etc.

Ainda não ficou claro? Então vamos nos aprofundar um pouco mais.

O que é um API Gateway?

A tradução para o português da palavra “Gateway” é Portão. A nomenclatura não é por acaso, já que este produto de API opera de forma semelhante. Essa Interface de Programação de Aplicação serve para filtrar os tipos de solicitação que vão acontecer com a API.

Essa tecnologia já é adotada por diversas companhias no mundo, e são disponibilizadas por diversas empresas. Veja algumas funções de API Gateway:

  • Ponto único de acesso à todas as APIs, se colocando entre suas APIs e seus respectivos usuários.
  • Filtragem de dados na entrada, podendo redirecionar o chamado à API para o local correto, baseado nos mais diferentes parâmetros de entrada, e, até mesmo, ignorar a requisição caso seja desejado, sem levar tráfego à sua API. É o sentinela do seu portão.
  • Mecanismos de segurança, que incluem autenticação de usuário e logs de acesso.
  • Limitação de acesso baseada em usuário, que permite limitar o acesso do usuário a determinado recurso baseado nas mais diversas premissas, como números de requisições no mês ou nos últimos 10 segundos.

Essas funções presentes no API Gateway permitem as mais diversas vantagens para as empresas que os adotam. Um único ponto de acesso, por exemplo, significa uma redução de esforço em administrar as “portas de entrada” dos seus serviços na web, podendo focar seus esforços em único local.

Além disso, a combinação das outras funções do gateway citadas nos tópicos acima, permite que todo esse tratamento seja realizado fora da sua API, reduzindo a complexidade da mesma. Isso proporciona a redução de custos em mantê-las no ar, abrindo portas para o desenvolvimento de ainda mais APIs.

Para reduzir ainda mais o custo de expor diversas APIs no ar é comum que API Gateways unifiquem o acesso a APIs internas, quer sejam oriundas de sistemas legados ou de micro-serviços mais dinâmicos. Para implementar micro-serviços recomendamos a utilização do Docker, sobre o qual você pode saber mais no artigo Por que você precisa adotar Docker agora mesmo.

E o que é um API Manager?

O API Manager é um software que implementa uma camada de gestão sobre um API Gateway (ou mesmo embute dentro de si o API Gateway), incluindo recursos para facilitar o seu gerenciamento e possibilitando a visualização de dados de negócio. Isso proporciona a geração de estatísticas de uso, gerenciamento de ciclo de vida da API, dentre outros vantagens.

Além das funções do Gateway, o API Manager pode oferecer as mais diversas possibilidades com o intuito de alavancar seu conjunto de APIs:

  • Insights corporativos das APIs através de Dashboards.
  • Controle do ciclo de vida das APIs.
  • Prototipação de API, versionamento das APIs.
  • Possibilidade de monetização das APIs.

Gerenciando múltiplas versões Java no Mac

A partir da versão 7, a Apple parou de gerenciar o JDK para Mac OS. Essa responsabilidade agora é da Oracle. Até a JDK 6, a Apple trazia como default o Java instalado, acredito que além de uma questão política das empresas, deve ter relação com o fato que de tempos em tempos sempre é publicado uma vunerabilidade da JVM em sites de segurança.

Porém, como desenvolvedor, pode ser necessário você trabalhar com várias versões de JDK e ai que entra a parte interessante da dica.

Na pasta ” /Library/Java/” do Mac OS estão todas as instalações do Java da sua máquina. Lá existem três pastas (Extensions, Home e JavaVirtualMachines). Na pasta JavaVirtualMachines é possível checar todas jdk instaladas, pois é salvo um arquivo, como “jdk1.7.0_21.jdk”.

Caso esteja testando o Jdk 8, e precise manter o 6 e o 7 configurado, é possível dinamicamente setar o JAVA_HOME, através de um simples comando, configurado no arquivo .bash_profile.

O arquivo bash_profile fica no caminho ~/.bash_profile e pode ser editado com qualquer editor do terminal, como vi, por exemplo.

Com o editor aberto, adicione as seguintes linhas ao arquivo:

export JAVA_HOME=$(/usr/libexec/java_home -v 1.6)

export JAVA_HOME=$(/usr/libexec/java_home -v 1.7)

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)

E para definir o comando que seta a JAVA_HOME atual, crie as três linhas abaixo:

alias setjdk16=’export JAVA_HOME=$(/usr/libexec/java_home -v 1.6)’

alias setjdk17=’export JAVA_HOME=$(/usr/libexec/java_home -v 1.7)’

alias setjdk18=’export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)’

Para definir qual jdk é a default, basta chamar o comando do alias.

Exemplo para setar JDK 6, executar setjdk16 e testar com javac -version ou java-version. O mesmo para as outras versões.