O que é Docker?

De forma resumida, o Docker é uma plataforma de código aberto, desenvolvido na linguagem Go e criada pelo próprio Google. Por ser de alto desempenho, o software garante maior facilidade na criação e administração de ambientes isolados, garantindo a rápida disponibilização de programas para o usuário final.

Quais são as funcionalidades do Docker?

O Docker tem como objetivo criar, testar e implementar aplicações em um ambiente separado da máquina original, chamado de container. Dessa forma, o desenvolvedor consegue empacotar o software de maneira padronizada. Isso ocorre porque a plataforma disponibiliza funções básicas para sua execução, como: código, bibliotecas, runtime e ferramentas do sistema.

Então, podemos dizer que o Docker é uma máquina virtual?

O Docker é algo parecido com uma máquina virtual extremamente leve, mas não se trata de fato de uma máquina virtual. O Docker utiliza containers que possuem uma arquitetura diferente, permitindo maior portabilidade e eficiência. O container exclui a virtualização e muda o processo para o Docker. Então, não podemos dizer que o Docker é uma máquina virtual. Veja na imagem abaixo as diferenças entre o Docker e uma virtualização.

Podemos ver que, na virtualização, temos um maior consumo de recursos, uma vez que para cada aplicação precisamos carregar um sistema operacional. Já no Docker, podemos ver que não existe essa necessidade de múltiplos sistemas operacionais convidados.

O que são esses containers?

Um container é um ambiente isolado. Um container contém um conjunto de processos que são executados a partir de uma imagem, imagem esta que fornece todos os arquivos necessários. Os containers compartilham o mesmo kernel e isolam os processos da aplicação do restante do sistema.

Por exemplo: se você está desenvolvendo uma aplicação para um cliente, você pode fazer suas configurações nessa aplicação… Mas, em um ambiente convencional, você precisará replicar estas configurações para os outros ambientes de execução. Com o Docker, você estará fazendo isso em um ambiente isolado e, por causa da facilidade para replicação de containers, você acaba criando ambientes padronizados, tanto em desenvolvimento como em produção, por exemplo. Assim, você pode disponibilizar essa arquitetura toda para seu cliente, onde ele estiver: basta replicar os containers, que serão executados da mesma maneira em qualquer lugar.

Como o container possui uma imagem que contém todas as dependências de um aplicativo, ele é portátil e consistente em todas as etapas de desenvolvimento. Essa imagem é um modelo de somente leitura que é utilizada para subir um container. O Docker nos permite construir nossas próprias imagens e utilizá-las como base para os containers.

Vale lembrar que, apesar do Docker ter sido desenvolvido inicialmente com base na tecnologia LXC (Linux Containers – sendo, portanto, mais associado aos containers Linux), hoje essa tecnologia tornou-se independente de sistema operacional: podemos utilizar o Docker em ambientes Linux, Windows e até mesmo MacOS.

Quais são os benefícios do Docker?

A grande vantagem no uso da plataforma é a rapidez em que o software pode ser disponibilizado — em uma frequência até 7 vezes mais rápida do que a virtualização convencional.

Outro benefício oferecido pela plataforma é a possibilidade de configurar diferentes ambientes de forma rápida, além de diminuir o número de incompatibilidades entre os sistemas disponíveis.

Além das vantagens citada acima, veja mais alguns benefícios oferecidos pela tecnologia:

Modularidade

A modularidade permite que o desenvolvedor desabilite uma parte do aplicativo. Dessa forma, podem ser realizadas atualizações de reparo ou até mesmo adição de funcionalidades, sem a necessidade de interromper todo o programa.

Outro ponto é a possibilidade de compartilhar processos entre diferentes aplicativos, de forma parecida ao SOA (arquitetura orientada a serviço).

Camadas e controle de versão de imagens

Um arquivo Docker pode ser formado por diversas camadas diferentes, onde se dividem em dois grupos:

  • Imagens: elas são formadas por diferentes camadas. Com a sua utilização, o usuário pode facilmente compartilhar um aplicativo ou um conjunto de serviços em diversos ambientes. Quando há alguma alteração na imagem, ou uso de um comando como executar ou copiar, é criada uma camada.
  • Containers: são formadas na reutilização das camadas. Um container é o local onde estão as modificações da aplicação que está em execução. É por meio dele que o usuário pode modificar uma imagem.

Reversão

Em algum momento você já realizou uma alteração em um sistema e, posteriormente, se arrependeu da modificação? Usando o recurso de reversão é possível recuperar a versão anterior.

Isso ocorre por conta das camadas criadas. O processo se mostra ainda mais eficiente por ser compatível com a abordagem de desenvolvimento ágil. Dessa forma, a equipe pode facilmente contar com as práticas de integração e implantação contínua, sem perder a eficiência no desenvolvimento da aplicação.

Implantação rápida

Grandes empresas de TI sabem o quanto é importante implantar a aplicação o mais rápido possível. Por esse motivo, o Docker surge como uma ótima opção. Como o tempo e desempenho da implantação ocorrem simultaneamente, uma implantação que levaria horas em outros métodos chega a levar apenas alguns segundos para ser concluída.

Para aumentar a eficiência no desenvolvimento de programas, as empresas buscam alternativas, como o Docker. Além de agilizar os processos, a plataforma dá ao desenvolvedor a possibilidade de rapidamente acessar uma versão anterior, caso encontre algum problema, trazendo maior produtividade e segurança para a equipe.

 

O que é o AMQP?

O AMQP é um protocolo de comunicação em rede, tal qual o HTTP, que permite que aplicações se comuniquem.

Soluções para mensageria existem desde a década de 1970 com a ideia de resolver os problemas de integração entre diversos fornecedores. Sem o uso de um middleware de mensagens, a integração heterogênea de sistemas provou ser um processo muito caro e complexo.

Por exemplo, soluções para mensagens, como o IBM Websphere MQ e o TibCO Enterprise Message Service, são muito caras e tendem a ser utilizadas apenas por grandes companhias, especialmente a indústria de serviços financeiros.

Além destes percalços, existem também problemas de interoperabilidade entre estas soluções. Fornecedores, para contornar este problema, criaram seus próprios protocolos para mensageria, logo notamos que não eram integrados com outros fornecedores, já que cada um criava a sua solução, isso se chamava de Lock-in de Fornecedor, que em nosso idioma soa como uma reserva de mercado ou reserva de nicho.

O AMQP tem muitas vantagens, mas duas são mais importantes: produzir um padrão aberto para protocolos de mensageria e permitir a interoperabilidade entre muitas tecnologias e plataformas.

Existem muitos sistemas rodando em muitos Sistemas Operacionais, que são desenvolvidos com múltiplas linguagens de programação, rodando em várias arquiteturas de hardware e máquinas virtuais. AMQP não só torna a integração dentre esses vários sistemas diferentes possível, como também permite que produtos diferentes que implementem este protocolo possam trocar informações e isso faz do AMQP o pioneiro bem como a evolução da mensageria.

O modelo do AMQP funciona da seguinte maneira: mensagens são publicadas pelos produtores e enviadas às exchanges. As exchanges distribuem as cópias das mensagens para filas utilizando regras que são chamadas de bindings no jargão do AMQP.

Então brokers AMQP enviam mensagens para consumidores que acessam, ou assinam, as filas, ou consumidores buscam e processam mensagens da fila sob demanda.

Quando publicam uma mensagem, produtores podem especificar vários atributos para ela, também chamados de metadados da mensagem. Alguns destes atributos podem ser utilizados pelo broker, contudo, outros atributos são apenas utilizados pelas aplicações que recebem a mensagem.

A importância dos sistemas de informações gerenciais para a administração financeira

Sabe-se que a origem de toda informação econômico financeira precisa ser confiável e está baseada em um sistema de informações financeiras e gerenciais desenvolvido e mantido pela empresa. Toda Organização moderna e realmente inserida em um mercado de capitais globalizado e altamente competitivo não pode prescindir de manter em sua estrutura administrativa uma equipa responsável por informações financeiras gerenciais confiáveis que garantirão a manutenção do negócio e a competitividade de suas operações em seu mercado consumidor.

Neste sentido, e conforme definido por Hoji (2008, p. 411), o Sistema de Informações Gerencial pode ser entendido como um conjunto de subsistemas de informações que processam dados e informações para fornecer subsídios ao processo de gestão de uma empresa. Onde os ‘dados’ são os elementos potencialmente úteis em sua forma bruta, mas não têm valor imediato analisados em separado, pois não transmitem a ideia clara de determinado fato ou situação. Enquanto que as ‘informações’ são o resultado de um dado ou um conjunto de dados adequadamente processados para que o usuário final consiga compreendê-las e possa tomar decisões a partir destas.

Sendo assim, sabemos que o mundo globalizado no qual as empresas encontram-se inseridas acaba por impor uma série de desafios aos administradores financeiros. E isto ocorre em razão do mercado exigir, a cada dia, e a todo instante, informações mais rápidas e mais precisas. Neste sentido, os dados e os números financeiros reportados precisam ser constantemente fornecidos aos agentes econômicos, mercado financeiro, acionistas e demais investidores com precisão e periodicidade.

Com isso a agilidade e a confiabilidade de um sistema de informações gerenciais são o resultado da qualidade e do grau de transparência e informatização da empresa analisada. Normalmente, os sistemas operacionais de controle das informações gerenciais permitem, a princípio, o registro de todas as transações efetuadas pela Administração em cada um dos sistemas específicos existentes nos diversos departamentos da empresa. Enquanto que a integração destes diversos sistemas é
que permite a conversão de informações aparentemente complexas e puramente matemáticas em dados perfeitamente utilizáveis pelos administradores na tomada de decisões gerenciais, gestão dos negócios, e demais demandas existentes no dia a dia das operações da empresa.

Os sistemas gerenciais presentes nas empresas foram projetados para permitirem o manuseio de diversas informações ao mesmo tempo, ou seja, de forma paralela e assim de forma integrada dar suporte às transações comerciais e seus efeitos contábeis, financeiros e gerenciais. Logo, vemos os sistemas gerenciais serem projetados para permitir a administração e a análise das informações por tipo de negócio (por exemplo, contas a pagar, contas a receber ou estoques), segundo as mais modernas práticas de geração de informações, e voltadas à melhor administração do negócio.

A Figura abaixo mostra um modelo de integração das informações que deve existir entre o Sistema da Contabilidade, o Sistema de Contas a Pagar, o Sistema de Contas a Receber e o Sistema da Tesouraria. Esta integração é necessária para que os dados gerados por cada um dos sistemas integrantes do Processo de Contas a Pagar e Contas a Receber, por exemplo, se ‘conversem’ dentro da empresa, e assim oferecendo bases para a geração de informações importantes e cruciais para o Sistema da Tesouraria.

figura-sistema

As vantagens desta integração entre os diversos sistemas captadores e geradores de informações contábeis, financeiras e gerenciais é a racionalização dos processos e agilização das informações obtidas em uma mesma base de dados.

React Native vs Flutter vs Ionic vs NativeScript vs PWA

Todas as quatro tecnologias permitem criar aplicativos móveis nativos reais para iOS e Android – sem a necessidade de aprender Swift, ObjectiveC, Java ou Kotlin!

Em vez disso, você usará JavaScript (para React Native, NativeScript e Ionic) e Dart (para Flutter). Portanto, você é capaz de criar aplicativos nativos para ambas as plataformas com um idioma em vez de dois – isso obviamente reduz o esforço de aprendizado necessário para criar muito o seu aplicativo móvel!

flutter.pngFlutter

O Flutter é um SDK (kit de desenvolvimento de software) e uma estrutura para o Dart – uma linguagem de programação desenvolvida pelo Google. O Flutter também é desenvolvido por uma equipe do Google.

A idéia por trás do Flutter é que você escreva o código Dart que pode ser compilado no código nativo que é executado no dispositivo de destino. Você usa o Dart + a estrutura Flutter para criar interfaces de usuário compostas pelos chamados widgets. O Flutter é enviado com vários widgets pré-configurados (botões, guias etc.) e você normalmente os usa para criar também seus próprios widgets mais complexos.

reactnativeReact Native

React Native é uma tecnologia / estrutura desenvolvida pelo Facebook.

Ele usa JavaScript e a biblioteca React para permitir a criação de belas interfaces de usuário compostas por componentes React.

Importante: diferente dos aplicativos React “normais” criados para o navegador, você não usará tags HTML. Em vez disso, você usará um conjunto de componentes pré-criados que serão compilados no código nativo pela cadeia de ferramentas React Native.

Você ainda pode usar pacotes como o Redux e, sabendo que o JavaScript e o React, é claro, também permite que você inicie rapidamente o React Native.

nativescriptNativeScript

O NativeScript também usa JavaScript para criar aplicativos móveis nativos. Ele vem em diferentes sabores – puro JavaScript / texto datilografado , com angular e com Vue.js .

Ele oferece a opção de trabalhar com estruturas diferentes, como você pode ver – as diferentes opções são desenvolvidas independentemente uma da outra. Portanto, você pode ter um tempo mais fácil ou mais componentes internos com a opção A do que com a B. Todas as opções estão em desenvolvimento ativo; portanto, é melhor simplesmente mergulhar nos documentos.

Como o Flutter e o React Native, o NativeScript também fornece vários componentes pré-criados que você usa para compor interfaces de usuário. Ele não funciona com HTML, mas com seus próprios componentes (como React Native).

ionicIonic

Com o Ionic, você ainda cria um aplicativo nativo real, mas faz isso criando um aplicativo Web (com HTML, JS e CSS) que será envolvido por um aplicativo nativo real que hospeda uma visualização na Web (basicamente um navegador oculto).

Como você cria uma página da Web no final, o Ionic é muito fácil de começar para desenvolvedores da web.

A partir do Ionic 4, o Ionic é basicamente um conjunto enorme de componentes que você pode usar (botões, cartões etc.) com qualquer estrutura de front-end (ou nenhuma).

O Ionic também fornece muitas ferramentas que facilitam o desenvolvimento de aplicativos móveis (por exemplo, um servidor de desenvolvimento para executar seu aplicativo em um emulador / dispositivo real com atualização ao vivo) e também agrupa o aplicativo em pacotes entregáveis. Além disso, a equipe da Ionic está envolvida no projeto Capacitor , que oferece muitos pacotes JavaScript que você pode adicionar a qualquer projeto da Web para acessar recursos nativos do dispositivo, como a câmera.

Comparações entre IONIC, Flutter, NativeScript, ReactScript,

Vemos resultados mistos.

  • Ionic: Incrível reutilização! O conceito de “aplicativo da Web empacotado” garante que você possa reutilizar seu código com facilidade – você está apenas criando um aplicativo Web empacotado no final. A excelente biblioteca de componentes adaptáveis ​​(ou seja, denominada automaticamente para a plataforma em que o aplicativo é executado) também ajuda.

 

  • Flutter: Também é ótimo para reutilizar. Os widgets fornecidos frequentemente não se adaptam à plataforma subjacente; em vez disso, você usa o Material Design nas duas plataformas por padrão. A equipe do Flutter está fornecendo cada vez mais componentes no estilo iOS. Você pode descobrir em qual plataforma está executando e trocar manualmente os widgets, mas é claro que isso é um pouco mais de trabalho do que o exigido pela Ionic. Se você precisar mudar o estilo da plataforma, mova a posição do Flutter no controle deslizante para a direita.

 

  • NativeScript: bastante semelhante ao Flutter, mas, por padrão, não aplica um sistema de estilos. Muitos componentes são compilados automaticamente com seus equivalentes nativos e, portanto, não precisam ser reformulados (a menos que você queira). Os componentes que não existem nas duas plataformas precisam ser gerenciados por você (ou seja, você precisa decidir qual componente renderizar em qual plataforma). No geral, o código pode ser reutilizado muito bem.

 

  • React Native: também compila os padrões nativos, mas fornece apenas um conjunto básico de componentes para começar. Você deve estilizar a maioria deles por conta própria; portanto, é necessário mais trabalho para obter estilos apropriados nas duas plataformas. Geralmente, o código pode ser reutilizado (já que você ainda usa apenas um idioma e bibliotecas como o Redux não precisam de ajustes).

 

  • Linguagens Nativas: obviamente você não pode usar Java com Android para desenvolvimento em iOS (ou o contrário). Portanto, a reutilização do código entre plataformas não existe aqui.

 

PWA OU APLICATIVO NATIVO? QUAL DOS DOIS INVESTIR?

Aplicativos se tornaram uma ferramenta essencial para qualquer empresa. Existe a necessidade de um app que proporciona uma excelente experiência e bons resultados. Nos últimos anos, houve um crescente suporte para um novo tipo de aplicativo – o Progressive Web App (PWA). Ele combina as funções de um app nativo e a acessibilidade de um website. E ao se deparar com isso surge uma pergunta “qual tipo de aplicativo é melhor para meu negócio?”

Download e instalação

A jornada de download e instalação de um aplicativo nativo é algo longo, pois primeiro o usuário tem que encontrar o aplicativo na App Store ou Play Store, depois baixá-lo e logo em seguida autorizar as permissões do aplicativo para só então usá-lo e muitas das vezes é pouco usado e logo desinstalado. E uma vez que um usuário desinstalar um app dificilmente voltará para o app.

Por outro lado, progressive web apps (PWAs) não precisam de App Store ou mesmo instalação. Direto do navegador, usuários são capazes de adicionar um atalho para o aplicativo em sua tela inicial, com apenas alguns toques. Uma vez adicionado, ele é capaz de enviar notificações e integrar com as configurações do sistema.

Além disso, aplicativos PWA não necessitam de muito espaço como um app. Com apenas uma URL, visitantes podem acessar e compartilhar o aplicativo com seus amigos. Também não há é preciso fazer updates, eles sempre mostram a versão mais recente ao carregar.

Mas afinal, qual dos dois devo investir?

Um dos maiores erros é achar um é concorrente do outro. Na verdade, os dois são complementares. Por mais que um PWA possa oferecer diversas vantagens, ele não vai proporcionar todas as interações que um app pode.

Não se trata de um ou outro, mas saber usar os dois como oportunidade de engajamento do seu cliente.

O PWA é uma excelente estratégia de contato inicial entre um potencial cliente com a sua marca, pois ele terá acesso ao conteúdo no mobile da melhor maneira possível sem precisar baixar nada e sem redirecionamento. Ele será impactado pelo seu conteúdo logo de cara.

Uma vez que ele perceba que a sua marca dialoga diretamente com ele, o cliente irá baixar o seu aplicativo e acessá-lo de maneira mais recorrente.

Dessa forma, você não perde nenhuma oportunidade de impactar o público com o conteúdo da sua marca.

Vantagens de se ter um PWA

  • Responsivo: se encaixa mais facilmente em qualquer resolução de tela.
  • Independente de conexão: com a tecnologia de Service Workers, o aplicativo pode funcionar até quando o usuário está offline.
  • Interações tão avançadas quanto de apps.
  • Sempre atualizado: o usuário não precisa “baixar uma atualização do app” de tempos em tempos. Como está tudo na web, na próxima vez que ele abrir o app a nova versão já estará lá.
  • Seguro: o conteúdo do app é servido com TLS (protocolo de segurança) para prevenir intrusos.
  • SEO-friendly: os mecanismos de busca conseguem encontrar o conteúdo dos aplicativos (o que consequentemente beneficia tanto os usuários quando as empresas).
  • Re-engajável (ops, tradução bizarra): os aplicativos web progressivos permitem enviar notificações aos usuários para trazê-los de volta à experiência com o passar do tempo.
  • Instalável: podem ser adicionados à home screen do celular, permitindo que os usuários “salvem” os aplicativos que eles considerarem mais úteis ou importantes.
  • Não ocupa espaço na memória do seu celular, pois o ícone salvo funciona somente como um hyperlink/deep-link para o conteúdo.
  • Linkável: mais fáceis de compartilhar conteúdo ao enviar o link para alguém.

Barreiras ainda existentes para se ter um PWA:

  • Nem todos os navegadores suportam esse tipo de aplicação.
  • Os usuários tendem a confiar mais em apps para disponibilizar informações para compraspode ser que as lojas de aplicativos evoluam tecnologicamente para que o processo de download e instalação dos apps torne-se mais fácil e integrado aos navegadores, sem precisar de redirecionamento
  • O PWA não tem acesso a todas as funcionalidades do celular, como Bluetooth, contatos, sensores de proximidade, NFC, etc.

Em performance ambos são bons, mas apps nativos são melhores

Comparado a um site responsivo, ou mesmo um site mobile, PWAs carregam muito mais rápido. No cerne de qualquer aplicativo PWA existe scripts executados em segundo plano e separados da página web. Isso permite ao usuário gerenciar solicitações off-line, fazer pré-buscas e armazenar, em cache, determinados recursos.

Além disso, PWAs podem sincronizar dados com um servidor remoto. Isso significa que, após ser adicionado a sua tela inicial, ele poderá ser usado off-line ou em condições de rede insatisfatórias.

Por outro lado, PWAs são aplicativos que funcionam a partir de um navegador, o que significa que existe latência e consumo de bateria maior que apps nativos. O aplicativo nativo podem ser vinculados ao sistema operacional. Ele pode acessar o hardware do dispositivo para fazer mais cálculos e oferecer melhor experiência aos seus clientes. A linguagem de programação de um app nativo é mais rápida e mais poderosa.

Funções e acesso ao telefone

Entre o aplicativo PWA e o nativo, existem algumas diferenças sobre o acesso do app às funções do telefone. São elas:

  • Notificações push: Ter notificações push aumenta as chances dos usuários engajarem com sua marca. Ambos possuem a função de enviar notificações push.
  • Geofencing: Geofencing é uma ferramenta de marketing (ou outras aplicações como jogos). Os desenvolvedores definem uma área, um local, quando o usuário entra naquele espaço seu celular recebe notificações push convidando-o para visitar (em casos de estabelecimentos) ou enviando promoções. Essa característica se encontra disponível apenas para apps nativos.
  • SEO: PWAs podem ser achados por meio dos mecanismos de busca. Os aplicativos, por outro lado, só podem ser encontrados em lojas.
  • Espaço no armazenamento: Os aplicativos PWA não necessitam de muito espaço no armazenamento do celular, o que é um ponto crucial para muitos usuários de dispositivos móveis.
  • Atualizações: enquanto em um app nativo é necessário fazer a atualização das novas versões e correções, o PWA atualiza sozinho e automaticamente.

Então, PWA ou Nativo?

Tanto o aplicativo nativo quanto o PWA têm seus pontos fortes e desvantagens. Ao escolher entre eles, você deve considerar os aspectos em que cada opção se destaca e como eles se encaixam na sua visão do aplicativo.

Você deve considerar PWA se:

  • Você acabou de entrar no mercado e deseja um app simples para seus usuários. O PWA não exige download e permite interagir com o usuário por meio de notificações push;
  • Você tem pouco tempo e dinheiro. PWAs levam menos tempo para desenvolver, por isso o custo é menor para ter um app publicado.
  • Você deseja melhorar seu alcance de marca e SEO. PWAs são similares a qualquer website e alcançam uma maior audiência.

Você deve considerar Apps Nativos se:

  • Você deseja construir credibilidade para sua marca. Ter um app publicado em lojas de aplicativos aumenta a confiabilidade e os aplicativos nativos têm mais opções de segurança;
  • Você deseja utilizar características avançadas dos smartphones. Se geofencing, smart lock ou mesmo o sensor de movimento são essenciais para a UX, ou se seu produto requer grande capacidade de processamento, os apps nativos oferecem soluções melhores.

Aplicativos nativo e PWA são duas opções para oferecer uma experiência perfeita para o usuário com diferentes pontos fortes e fracos. Ambos vieram para ficar, e a escolha entre eles deve ser baseada nos objetivos que você deseja para o seu projeto.

O que é Progressive Web App (PWA)?

Um PWA (Progressive Web App) é uma aplicação híbrida entre web e mobile. Imagine que ao acessar um site que você goste muito pelo smartphone você receba um aviso para adicionar o site à sua homepage de aplicativos.

Com o app instalado agora em seu celular, você pode ter a mesma experiência que tinha pelo browser agora sem nenhuma informação em tela além da aplicação, ou seja, toda interface do navegador como barra de endereço, botões, favoritos, etc, são removidos.

“Mas é igual um app nativo?” Não exatamente.

O PWA difere em muitos aspectos de apps nativos que passam pelas lojas de aplicativos como Google Play (Android) e App Store (iOS).

Vantagens do PWA

Alguns pontos a se destacar para quem está pensando em criar um PWA:

  • Poucas alterações no código do site;
  • Utilização de HTML/CSS/Javascript;
  • Acesso à API’s nativas como geolocalização, câmera, microfone, etc;
  • Envio de notificações push;
  • Aplicação muito leve (menos de 1MB geralmente);
  • Suporte à utilização offline;

Pontos fracos

Apesar de todas vantagens analisadas acima, os PWA’s ainda sofrem com algumas coisas:

  • Suporte cross-browser (existem muitos navegadores);
  • Sem acesso à vibração, sensores, comunicação com outros apps, etc;
  • Não é possível adicioná-los às lojas de aplicativos;
  • Interface web pode perder performance em aplicações mais pesadas;
  • Pode não passar a legitimidade de uma aplicação mobile;

Fonte: Rocketseat

Noções Básicas de Git

Enfim, em poucas palavras, o que é Git? Essa é uma seção importante para assimilar, pois se você entender o que é Git e os fundamentos de como ele funciona, será muito mais fácil utilizá-lo de forma efetiva. À medida que você aprende a usar o Git, tente não pensar no que você já sabe sobre outros VCSs como Subversion e Perforce; assim você consegue escapar de pequenas confusões que podem surgir ao usar a ferramenta. Apesar de possuir uma interface parecida, o Git armazena e pensa sobre informação de uma forma totalmente diferente desses outros sistemas; entender essas diferenças lhe ajudará a não ficar confuso ao utilizá-lo.

Snapshots

A maior diferença entre Git e qualquer outro VCS (Subversion e similares inclusos) está na forma que o Git trata os dados. Conceitualmente, a maior parte dos outros sistemas armazena informação como uma lista de mudanças por arquivo. Esses sistemas (CVS, Subversion, Perforce, Bazaar, etc.) tratam a informação que mantém como um conjunto de arquivos e as mudanças feitas a cada arquivo ao longo do tempo, conforme ilustrado na Figura 1.4.

FIGURA1.4

Figura 1-4. Outros sistemas costumam armazenar dados como mudanças em uma versão inicial de cada arquivo.

Git não pensa ou armazena sua informação dessa forma. Ao invés disso, o Git considera que os dados são como um conjunto de snapshots (captura de algo em um determinado instante, como em uma foto) de um mini-sistema de arquivos. Cada vez que você salva ou consolida (commit) o estado do seu projeto no Git, é como se ele tirasse uma foto de todos os seus arquivos naquele momento e armazenasse uma referência para essa captura. Para ser eficiente, se nenhum arquivo foi alterado, a informação não é armazenada novamente – apenas um link para o arquivo idêntico anterior que já foi armazenado. A figura 1-5 mostra melhor como o Git lida com seus dados.

 

FIGURA1.5

Figura 1-5. Git armazena dados como snapshots do projeto ao longo do tempo.

 

Essa é uma distinção importante entre Git e quase todos os outros VCSs. Isso leva o Git a reconsiderar quase todos os aspectos de controle de versão que os outros sistemas copiaram da geração anterior. Também faz com que o Git se comporte mais como um mini-sistema de arquivos com algumas poderosas ferramentas construídas em cima dele, ao invés de simplesmente um VCS.

Quase todas operações são locais

A maior parte das operações no Git precisam apenas de recursos e arquivos locais para operar — geralmente nenhuma outra informação é necessária de outro computador na sua rede. Se você está acostumado a um CVCS onde a maior parte das operações possui latência por conta de comunicação com a rede, esse aspecto do Git fará com que você pense que os deuses da velocidade abençoaram o Git com poderes sobrenaturais. Uma vez que você tem todo o histórico do projeto no seu disco local, a maior parte das operações parece ser quase instantânea.

Por exemplo, para navegar no histórico do projeto, o Git não precisa requisitar ao servidor o histórico para que possa apresentar a você — ele simplesmente lê diretamente de seu banco de dados local. Isso significa que você vê o histórico do projeto quase instantaneamente. Se você quiser ver todas as mudanças introduzidas entre a versão atual de um arquivo e a versão de um mês atrás, o Git pode buscar o arquivo de um mês atrás e calcular as diferenças localmente, ao invés de ter que requisitar ao servidor que faça o cálculo, ou puxar uma versão antiga do arquivo no servidor remoto para que o cálculo possa ser feito localmente.

Isso também significa que há poucas coisas que você não possa fazer caso esteja offline ou sem acesso a uma VPN. Se você entrar em um avião ou trem e quiser trabalhar, você pode fazer commits livre de preocupações até ter acesso a rede novamente para fazer upload. Se você estiver indo para casa e seu cliente de VPN não estiver funcionando, você ainda pode trabalhar. Em outros sistemas, fazer isso é impossível ou muito trabalhoso. No Perforce, por exemplo, você não pode fazer muita coisa quando não está conectado ao servidor; e no Subversion e CVS, você pode até editar os arquivos, mas não pode fazer commits das mudanças já que sua base de dados está offline. Pode até parecer que não é grande coisa, mas você pode se surpreender com a grande diferença que pode fazer.

Git tem integridade

Tudo no Git tem seu checksum (valor para verificação de integridade) calculado antes que seja armazenado e então passa a ser referenciado pelo checksum. Isso significa que é impossível mudar o conteúdo de qualquer arquivo ou diretório sem que o Git tenha conhecimento. Essa funcionalidade é parte fundamental do Git e é integral à sua filosofia. Você não pode perder informação em trânsito ou ter arquivos corrompidos sem que o Git seja capaz de detectar.

O mecanismo que o Git usa para fazer o checksum é chamado de hash SHA-1, uma string de 40 caracteres composta de caracteres hexadecimais (0-9 e a-f) que é calculado a partir do conteúdo de um arquivo ou estrutura de um diretório no Git. Um hash SHA-1 parece com algo mais ou menos assim:

24b9da6552252987aa493b52f8696cd6d3b00373

Você vai encontrar esses hashes em todo canto, uma vez que Git os utiliza tanto. Na verdade, tudo que o Git armazena é identificado não por nome do arquivo, mas pelo valor do hash do seu conteúdo.

Git geralmente só adiciona dados

Dentre as ações que você pode realizar no Git, quase todas apenas acrescentam dados à base do Git. É muito difícil fazer qualquer coisa no sistema que não seja reversível ou remover dados de qualquer forma. Assim como em qualquer VCS, você pode perder ou bagunçar mudanças que ainda não commitou; mas depois de fazer um commit de um snapshot no Git, é muito difícil que você o perca, especialmente se você frequentemente joga suas mudanças para outro repositório.

Isso faz com que o uso do Git seja uma alegria no sentido de permitir que façamos experiências sem o perigo de causar danos sérios.

Os três estados

Agora preste atenção. Essa é a coisa mais importante para se lembrar sobre Git se você quiser que o resto do seu aprendizado seja tranquilo. Git faz com que seus arquivos sempre estejam em um dos três estados fundamentais: consolidado (committed), modificado (modified) e preparado (staged). Dados são ditos consolidados quando estão seguramente armazenados em sua base de dados local. Modificado trata de um arquivo que sofreu mudanças, mas que ainda não foi consolidado na base de dados. Um arquivo é tido como preparado quando você marca um arquivo modificado em sua versão corrente para que ele faça parte do snapshot do próximo commit (consolidação).

Isso nos traz para as três seções principais de um projeto do Git: o diretório do Git (git directory, repository), o diretório de trabalho (working directory), e a área de preparação (staging area).

FIGURA1.6

Figura 1-6. Diretório de trabalho, área de preparação, e o diretório do Git.

O diretório do Git é o local onde o Git armazena os metadados e o banco de objetos de seu projeto. Esta é a parte mais importante do Git, e é a parte copiada quando você clona um repositório de outro computador.

O diretório de trabalho é um único checkout de uma versão do projeto. Estes arquivos são obtidos a partir da base de dados comprimida no diretório do Git e colocados em disco para que você possa utilizar ou modificar.

A área de preparação é um simples arquivo, geralmente contido no seu diretório Git, que armazena informações sobre o que irá em seu próximo commit. É bastante conhecido como índice (index), mas está se tornando padrão chamá-lo de área de preparação.

O workflow básico do Git pode ser descrito assim:

  1. Você modifica arquivos no seu diretório de trabalho.
  2. Você seleciona os arquivos, adicionando snapshots deles para sua área de preparação.
  3. Você faz um commit, que leva os arquivos como eles estão na sua área de preparação e os armazena permanentemente no seu diretório Git.

Se uma versão particular de um arquivo está no diretório Git, é considerada consolidada. Caso seja modificada, mas foi adicionada à área de preparação, está preparada. E se foi alterada desde que foi obtida, mas não foi preparada, está modificada.

Fonte: GIT Documentation