FULLSTACK API – Ou o que aprendi com o MEAN.

Muito se ouve falar de API’s, e termos como API First, ou Offline API. É um conceito muito bacana, do qual não vou entrar em detalhes aqui pois basta você pesquisar um pouco e achará centenas de artigos falando sobre isso, em Portuguêsem Inglês, ou qualquer outra língua. Não só porque tem muito material já disponível, mas porque esse material disponível já descreve muito bem sobre isso, então eu só quero detalhar um pouco do que eu aprendi, sabendo que talvez não acrescentará em nada, mas pode ajudar quem esteja começando, assim como eu.

Eu sou uma pessoa que estuda pouco, porém sobre muitas coisas, e só entro em mais detalhes quando preciso. Então muita gente me acha inteligente, mas sou apenas curioso, e foi assim que, há um tempo atrás eu precisei/quis aprender NodeJS e AngularJS. Foi quando eu descobri a STACK (conjunto de tecnologias para se desenvolver determinada solução) MEAN (MongoDB, ExpressJS, AngularJS e NodeJS).

Esse termo (MEAN) é muito conhecido, basta você “googlar” e verás. Mas o que está por trás dessa ideia, eu (e creio que todo mundo que estudou o MEAN) descobri rapidinho: trabalhar com API. Mas que diabos é trabalhar com API? Também não vou entrar em detalhes, mas basicamente, nesse contexto que estamos inseridos, ao trabalhar com API, você cria um conjunto de rotinas/funções/métodos padrão, e isso vai ser o núcleo (core) do seu sistema. A partir de então, você desenvolve um elo entre o usuário e o core do seu sistema, esse elo é chamado de Cliente. Se sua API está online (de novo, no contexto desse artigo, presumiremos que sim), então você pode fazer vários tipos de clientes para acessá-la, como, cliente web, para Android, iOS, para Windows, Linux etc.

api first

Esse negócio de se trabalhar com API começou com grandes softwares. Eu vi, pela primeira vez, em redes sociais, como Twitter e Facebook. Isso foi testado e aprovado por programadores, que foram passando essa experiência ao longo dos anos e hoje em dia é uma tendência altíssima trabalhar dessa forma. Sendo assim, vamos somente recapitular, alguns benefícios de se construir o seu software no formato API:

  • Multiplataforma: também pode ser entendido como generalismo. É muito mais fácil criar uma versão de seu software para uma outra plataforma, pois o core do seu software já está pronto, de forma genérica, basta criar o cliente na plataforma desejada, para conversar com ele.
  • Consistência: Existe um padrão, único, no seu software, e todos os objetos e a arquitetura do seu software já estão bem definidos.
  • Modularidade: É muito mais fácil dividir seu software em módulos, ou em níveis de acesso, e distribuir essa divisão entre os clientes, pois você praticamente alterará somente um lugar

Voltando ao MEAN, você acha facilmente artigos para aprender essas tecnologias, eu particularmente gosto desse artigo da Caelum. Mas se você parar para pensar, o que é o MEAN?

  1. Um banco de dados (MongoDB)
  2. Uma biblioteca para obtenção, tratamento, roteamento etc, das requisições dos clientes (ExpressJS)
  3. Uma biblioteca para se construir seu cliente, nesse caso, web (AngularJS)
  4. Um servidor web (NodeJS)

Então porque o MEAN ficou tão famoso? Pelo fato de que, ao se trabalhar com qualquer uma dessas tecnologias, você só precisa ter conhecimento JavaScript, pois tudo o que mencionei é baseado nessa linguagem. Mas para trabalhar com API, não necessariamente você precisa pegar uma STACK pronta, você pode adaptar o que você já está acostumado à ideia de API.

Pensando nisso, eu peguei as tecnologias mais comuns (LAMP – Linux, Apache, MySQL e PHP) e adaptei à ideia de API. Transcrevendo a ideia do MEAN, o Apache preenche o item 4, o PHP preenche o item 2, o MySQL preenche o item 1 e o item 3 pode ser preenchido por qualquer biblioteca cliente que você quiser, inclusive o próprio AngularJS. Então meu MEAN virou um MPAA (MySQLPHPAngularJS, Apache).

Nessa ideia, eu criei uma webapp que faz a mesma coisa que o exemplo do artigo da Caelum, e disponibilizei para qualquer um poder estudar e aprimorar a ideia. Segue os links:

  1. Exemplo de aplicativo usando MEAN;
  2. Exemplo de aplicativo usando MPAA;

Espero que esses links possam ajudá-lo nos seus estudos.

 

VirtualBox não abre no meu linux, e agora?

Esses dias eu tentei abrir o Virtualbox no Linux e me deparei com um erro que dizia mais ou menos isso:

# VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen(“/usr/lib/virtualbox/VirtualBox.so”,) failed: /lib/libQtOpenGL.so.4: undefined symbol: _ZNK14QWidgetPrivate17hasHeightForWidthEv

Resolvendo o problema:

1- Pode ser problemas de permissões no arquivo Virtualbox.so. Tente alterar as permissões que na maioria das vezes já resolve o problema. O arquivo fica na pasta: /usr/lib/virtualbox/

2- Se você usa um eToken, e o instalou no seu Linux, talvez ele crie alguns links do libQt na sua pasta de bibliotecas. Remova os links e tente abrir novamente o VirtualBox.
Geralmente os links simbólicos são criados na pasta: /usr/lib/eToken/

3- Se nenhuma das opções acima funcionou, tente resolver o problema reinstalando o Virtualbox e/ou o qt-x11.

😉

A vida sem o ambiente gráfico – Chat.

Hoje em dia a vida é uma maravilha com esses visuais estupendos que vemos  por ai, não é? Mas nesse post veremos o outro lado da moeda,  o lado sem os gráficos bonitinhos, o lado negro e “sem cor” do Linux.

Mas pra quê, né!? Bem, nunca se sabe o dia de amanhã. Imagine se você quer montar um servidor de arquivos, que seja, mas está sem grana para isso. Ou simplesmente por querer mostrar para os seus amigos que você não depende da parte gráfica do Linux. Na verdade, verdade mesmo, existem várias desculpas para se usar isso hoje em dia. Vamos lá, então? Continuar lendo A vida sem o ambiente gráfico – Chat.