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

Anúncios

O que é Node.js?

nodejs-logoNode.js é uma plataforma construída sobre o motor JavaScript do Google Chrome para facilmente construir aplicações de rede rápidas e escaláveis. Node.js usa um modelo de I/O direcionada a evento não bloqueante que o torna leve e eficiente, ideal para aplicações em tempo real com troca intensa de dados através de dispositivos distribuídos.

Na JSConf 2009 Européia, um programador jovem chamado Ryan Dahl, apresentou um projeto em que estava trabalhando. Este projeto era uma plataforma que combinava a máquina virtual JavaScript V8 da Google e um laço de eventos. O projeto apontava para uma direção diferente das outras plataformas em JavaScript que rodam no servidor: todos I/O primitivos são orientado a evento. Aproveitando o poder e a simplicidade do Javascript, isso tornou tarefas difíceis de escrever aplicações assíncronas em tarefas fáceis. Desde quando foi aplaudido de pé no final do seu discurso, o projeto de Dahl tem recebido uma popularidade e uma aprovação sem precedentes.

Que problema o Node pode resolver?

Node estabeleceu o objetivo número um que é “fornecer uma maneira fácil para construir programas de rede escaláveis”. Qual é o problema com os programas servidores atuais? Vamos fazer os cálculos. Em linguagens como Java™ e PHP, cada conexão cria uma nova thread que potencialmente tem anexado 2 MB de memória com ela. Em um sistema que tenha 8 GB de RAM, isso põe o número máximo teórico de conexões concorrentes a cerca de 4.000 usuários. E quando o número de usuários aumenta, se você quer que sua aplicação web suporte mais usuários, você tem que adicionar mais e mais servidores. Somado a estes custos também podem haver possíveis problemas técnicos: um usuário pode usar diferentes servidores para cada requisição, então cada recurso compartilhado deve ser compartilhado para todos os servidores. Por todas estas rações, o gargalho em toda a arquitetura de aplicações web (incluindo velocidade de tráfego, velocidade do processador e velocidade da memória) é o número de conexões concorrentes que o servidor pode manipular.

Node resolve esta questão trocando a maneira como a conexão é tratada no servidor. Ao invés de criar uma nova OS thread a cada conexão (e alocar a memória anexa a ela), cada conexão dispara um evento executado dentro da engine de processos do Node. Node afirma que nunca vai dar deadlock, já que não há bloqueios permitidos, e ele não bloqueia diretamente para chamadas de I/O. Node também alega que um servidor rodando ele pode suportar dezenas de milhares de conexões simultâneas.

Então, agora que você tem um programa que pode manipular dezenas de milhares de conexões simultâneas, o que você pode realmente fazer com o Node? Seria incrível se você tivesse uma aplicação web que necessitasse desta quantidade de conexões. Este é um daqueles tipos de problema: “se você tem um problema, não é mais um problema”.

O que Node definitivamente não é?

Sim, Node é um servidor de programas. Entretanto o produto base do Node definitivamente não é como o Apache ou o Tomcat. Estes servidores são basicamente servidores ready-to-install e estão prontos para instalar aplicativos instantâneamente. Você pode subir e rodar um servidor em um minuto com estes produtos. Node definitivamente não é isso. Parecido com como o Apache pode adicionar um módulo PHP para permitir desenvolvedores criarem páginas da web dinâmicas, e um módulo SSL para conexões seguras, Node tem o conceito de módulos que podem ser adicionados no núcleo do Node. Há literalmente centenas de módulos para rodarem com o Node, e a comunidade é bastante ativa em produzir, publicar e atualizar dezenas de módulos por dia.

Como o Node funciona

O Node roda em uma JavaScript V8 VM. Mas espere, JavaScript no servidor? Isso, você leu certo. JavaScript no lado do servidor pode ser um conceito novo para todos que trabalharam exclusivamente com o JavaScript no lado do cliente, mas a idéia em sí não é tão absurda – porque não usar a mesma linguagem de programação no cliente que você usa no servidor?

O que é V8? O motor JavaScript V8 é o motor que a Google usa com seu navegador Chrome. Poucas pessoas pensam sobre o que realmente acontece com o JavaScript no lado do cliente. Bem, a engine JavaScript realmente interpreta o código e o executa. Com o V8 a Google criou um ultra-rápido interpretador escrito em C++, com um outro aspecto único: você pode baixar a engine e incorporá-la em qualquer aplicação desejada. Isso não está restrito em rodar em um navegador. Então Node atualmente usa o motor JavaScript V8 escrito pela Google e propõe que seja usado no servidor. Perfeito! Para que criar uma nova linguagem quando há uma boa solução já disponível?

Programação orientada a Evento

Muitos programadores foram ensinados a acreditar que a programação orientada a objetos é um modelo de programação perfeito e a não usarem nada mais. Node utiliza o que é chamado modelo de programação orientada a evento.

Programação orientada a evento no lado do cliente com jQuery:


// jQuery code on the client-side showing how Event-Driven programming works

// When a button is pressed, an Event occurs – deal with it

// directly right here in an anonymous function, where all the

// necessary variables are present and can be referenced directly

$(“#myButton”).click(function(){

     if ($(“#myTextField”).val() != $(this).val())

         alert(“Field must match button text”);

});


O lado do servidor na verdade não é diferente do lado do cliente. Claro que não há botões sendo pressionados e não há campos de texto sendo escritos, mas em um nível mais alto, os eventos estão ocorrendo. Uma conexão é feita – evento! Dado é recebido através da conexão – evento! Data parou de chegar através da conexão – evento!

Por que é que este tipo de configuração é ideal para o Node? JavaScript é uma excelente linguagem para programação orientada a evento, porque ela permite funções anônimas e encerramentos, e o mais importante, a sintaxe é familiar para quase todos que já programaram na vida. As funções de callback que são chamadas quando um evento ocorre podem ser escritas no mesmo lugar onde você captura o evento. Fácil para desenvolver, fácil para manter. Sem frameworks complicados de Orientação a Objeto, sem interfaces, nenhum potencial para o excesso de arquitetura de qualquer coisa. Basta escutar um evento, escrever uma função de callback, e o Node toma conta de tudo.

Artigo retirado de: NodeBR

O que de fato é o Composer?

logo-composer-transparentVamos entender um pouco o que realmente é o Composer e qual sua utilidade! Inclusive porque todos os frameworks atuais estão utilizando esse tal de Composer.

O Composer nada mais é que um instalador de dependências!

Mas espera, como assim dependências? Que raios são dependências?

Um framework é uma série de lib’s(Library ou bibliotecas de códigos) com ferramentas e camadas de abstrações no qual você pode se utilizar para aumentar a segurança, facilidade de manutenção, velocidade de desenvolvimento e homogenização do seu aplicativo.

Tá, mas e o que o Composer tem haver com isso?

Atualmente os frameworks web cresceram muito, então as suas lib’s acabam ficando pesadas e elas são atualizadas constantemente. Pensando nisso o Composer é uma ferramenta na qual você instala e atualiza lib’s de um determinado framework ou ferramenta.

Vamos agora trazer essa ideia de dependências para o Laravel 4.

Para iniciar um desenvolvimento você não precisa baixar o Laravel 4 inteiro, com todas as lib’s. Basta apenas baixar a estrutura de arquivos padrão e iniciar seu desenvolvimento, quando for necessário interpretar/compilar o código para ver o resultado então você baixa as lib’s do Laravel usando o Composer porque elas são necessárias para interpretação/compilação do código.

Para fazer isso tudo o Composer se utiliza de um arquivo ‘.json‘ no qual ele verifica quais lib’s devem ser instaladas ou atualizadas.

Podemos por exemplo ver o Composer.phar ou Composer.php na pasta raiz de muitos frameworks. Então para você instalar as lib’s deste framework sabendo que ele usa o Composer basta mandar o comando no terminal:

1
php Composer.php install

Para atualizar o próprio composer:

1
php Composer.php self-update

Caso existam atualizações no seu framework e você gostaria de atualiza-lo (Lembrando que você precisa ter instalado ele primeiro):

1
php Composer.php update

Mas e se uso Windows? Como vou fazer para interpretar/compilar esse arquivo do Composer? Bom meu amigo, você deve instalar o PHP no seu Windows e configura-lo para chamar a função de interpretação/compilação no prompt de comando do Windows!

Para quem usa Windows isso fica bem difícil mesmo, então indico instalarem uma VMWare (VMWare Player é FREE) com o Linux!

Fonte: Laravel Brasil

 

Hack e PHP: Usando as Linguagens em aplicações Web

Hack e PHP: Usando as Linguagens em aplicações WebO aprimoramento dos processos de desenvolvimento, a necessidade de otimização de recursos e a possibilidade de aumentar a influência e participação no mercado de software tem estimulado grandes companhias a lançar suas próprias linguagens de programação. Isso aconteceu com a Microsoft, o Google, a Apple e agora também o Facebook. Diante do rápido crescimento e a necessidade de uma tecnologia capaz de proporcionar eficiência no desenvolvimento e no processamento, mas ao mesmo tempo permitir a adoção de forma progressiva a companhia criou uma linguagem derivada e que mantém uma relação simbiótica com o PHP, por ser essa a base de seu software web responsável pela rede social de mesmo nome. A linguagem Hack apresenta vários recursos típicos de linguagens compiladas e com tipos estáticos, mas ao mesmo tempo permite o uso e convivência com variáveis, retornos e parâmetros com tipos dinâmicos, típicos de linguagens interpretadas. As técnicas para permitir essa convivência harmônica demonstram ser bastante eficazes, apesar da complexidade adicional que agregam. Realizaremos a comparação entre as linguagens PHP e Hack e analisamos as características, vantagens e desvantagens da novíssima linguagem, que foi anunciada em 2014.

Histórico

Em 2010 um tradutor e compilador PHP chamado HipHop Compiler (HPHPc, na abreviação em inglês) foi anunciado pela equipe do Facebook depois de dois anos de desenvolvimento. Essa ferramenta traduzia códigos em PHP para C++ e depois os compilava num processo que era executado de forma antecipada, em oposição ao comportamento usual do servidor PHP que realiza a compilação no momento que a página/funcionalidade é chamada. Ainda em 2010 uma extensão com pequenas mudanças na linguagem PHP foi criada pela equipe do Facebook para diminuir o tempo de desenvolvimento e permitir que o PHP fosse capaz de compreender fragmentos de documentos XML, conforme o exemplo da Listagem 1. Essa extensão foi chamada de XHP e além de facilitar o desenvolvimento e manutenção da camada de apresentação pelos desenvolvedores front-end também auxiliava em dificultar ataques cross-site scripting.

Listagem 1. Código XHP

 <?php

  if ($_POST[‘name’]) {

    ?><span>Hello, {$_POST[‘name’]}</span><?

  } else {

  ?> echo

      <form method=”post”>

        What is your name?<br />

        <input type=”text” name=”name” />

        <input type=”submit” />

      </form>;

  <?

  }

Todos esses esforços em desenvolver melhorias tanto para a linguagem quanto para o processo de compilação dos softwares em PHP do Facebook têm sido empregados com o intuito de reduzir o overhead derivados da ineficiência em relação ao custo de processamento da forma original de compilação das aplicações desenvolvidas em PHP. Continuando com esses esforços a equipe do Facebook trabalhou no desenvolvimento de um compilador nativo para o PHP, que fosse capaz de gerar binários a partir de código PHP, mas com eficiência superior ao processo de compilação tradicional da linguagem. Nesse sentido, a equipe anunciou em 2012 que estava realizando testes com uma nova máquina virtual chamada HipHop (HHVM, na sigla em inglês) e em 2013 completaram a migração do processo de compilação da HPHPc para a HHVM.

Apesar de ter demonstrado ganhos de eficiência de até 11, 6 vezes com o uso da máquina virtual HipHop dificuldades no processo de desenvolvimento e testes inerentes à ausência de tipos da linguagem PHP motivaram a equipe do Facebook a criar uma nova linguagem, baseada em PHP, que permitisse a inferência de possíveis falhas de programação ainda em tempo de desenvolvimento.

A linguagem Hack

A Hack é uma linguagem de programação lançada em 2014, de código aberto, sob licença BSD, para a máquina virtual HipoHop e que interopera sem problemas com PHP. A Hack concilia o ciclo de desenvolvimento rápido da PHP com a disciplina provida pela definição de tipos de forma estática e permite emprego gradual, adicionando muitas características comumente encontradas em outras linguagens modernas.

A Hack foi criada a partir da extensão da linguagem PHP, introduzindo tipos definidos estaticamente através do conceito de anotação de tipos (type annotation, em inglês). Devido aos tipos definidos o analisador da máquina virtual HipHop pode detectar erros de programação durante o processo de checagem de código ainda em tempo de desenvolvimento.

Essa etapa de checagem de código, conforme a Listagem 2, permite que o analisador verifique todas as dependências de um trecho do código em todos os arquivos do projeto que estão relacionados e permite que se saiba se uma alteração tem reflexos em outros trechos do código da aplicação e informa onde essas alterações impactaram e como.

Listagem 2. Código Hack

 <?hh

  class MinhaClasse {

    public function alpha(): int {

      return 1;

    }

   public function beta(): string {

      return ‘olá teste’;

    }

 }

 function f(MinhaClasse $minha_inst): string {

    //corrija-me!

    return $ minha_inst->alpha();// o analisador detecta um erro aqui

  }

Devido ao fato de a PHP ser uma linguagem com tipos definidos dinamicamente e a Hack ser uma proposta de conversão gradativa e evolutiva as premissas do projeto da linguagem definiram que seria necessário suportar características de PHP que não são comuns em linguagens de tipos definidos de forma estática. Se não fosse adotada essa premissa, os projetos atuais em PHP que fossem ser migrados para a linguagem Hack teriam de ter grande parte dos códigos existentes em PHP reescritos, e essa não é a proposta do Facebook.

Apesar de ser definida pelo Facebook como uma nova linguagem a Hack é uma mistura de extensão do PHP com adição de recursos e mudanças de paradigmas, mas mantendo a compatibilidade com código PHP nativo. A extensão dos arquivos de código continua sendo .php (opcionalmente podendo ser .hh) e o conceito de ligação entre os arquivos de código que compõem um projeto continua sendo através de inclusão (include e require).

Para suportar a característica de falta de escopo léxico a Hack implementou o conceito de tipo não resolvido (unresolved type, em inglês). Isso significa que o verificador adia o momento no qual deduzirá o tipo de uma variável ou do retorno de uma função. O momento no qual se deduzirá o tipo de uma variável será quando houver uma chamada de função ou algum tipo de anotação que determine especificamente que tipo é esperado.

A Máquina Virtual HipHop e a linguagem Hack

A HHVM é uma máquina virtual projetada para executar programas escritos em Hack e PHP e utiliza uma abordagem de compilação JIT para alcançar uma eficiência superior em quanto mantém a flexibilidade de desenvolvimento que o PHP provê. O Facebook alega que o objetivo dessa linguagem é adicionar novas características, mas manter a convivência com o PHP, assim como investir esforços para fazer com que a nova linguagem continue sendo compatível com sua predecessora, conforme as duas evoluam. Essa estratégia de compatibilidade foi implementada através de três conceitos importantes na avaliação do código pela HHVM: tipos por anotação (annotation types, em inglês), modo do hack (hack mode, em inglês) e na combinação de tipos não resolvidos (unresolved types, em inglês) e tracelet.

A HHVM infere sobre tipos latentes (ainda não resolvidos) através da estruturação do JIT vinculado ao conceito de tracelet, que é um bloco básico especializado para um conjunto particular de tipos descobertos em tempo de execução para os valores de entrada. O tracelet permite que a HHVM eficientemente conheça os tipos do programa através da observação do mesmo.

O tipo por anotação permite que seja acrescentada uma definição do tipo na assinatura do método ou na declaração de uma variável ou classe. Como essa definição de tipo é um recurso adicional, caso não seja definido o analisador considerará o código como um PHP tradicional. Entretanto, essa convivência pode gerar conflitos quando uma função define seu tipo de acordo com condições dinâmicas, mas o objeto ou função que venha a chamá-lo em algum momento espere um retorno de um determinado tipo. Para esses casos é invocado o conceito adiamento de definição (unresolved type, em inglês) e tracelet. O analisador continua com a verificação até que em algum trecho do código o tipo não resolvido seja utilizado como se fosse de um determinado tipo e nesse momento ele verifica a compatibilidade de tipos.

Para resolver questões como essa é possível ainda que o programador assuma o controle da verificação e determine que um trecho de código não deva ser analisado considerando tipos. Nesses casos é possível definir o modo da linguagem, informando o nível de análise crítica que a HHVM deve fazer do trecho do código. Com as definições, por exemplo, //partial ou //unsafe é possível criar exceções de blocos de código que fogem à regra geral de tipos definidos estaticamente da Hack.

Com o uso da HHVM o código continua sendo transformado em código nativo somente quando necessário, não sendo necessário um ciclo de compilação anterior, já que essa etapa é feita por um compilador em tempo de execução (JIT Compiler, em inglês).

A HHVM pode ser integrada a IDEs para que a checagem de tipos ocorra de forma automática e transparente para o usuário. Para a plataforma Linux já existem plug-ins para softwares de desenvolvimento (Emacs e Vim). Para permitir essa checagem a máquina virtual disponibiliza um serviço que pode ser chamado pelo comando hh_client, que varrerá o diretório especificado e analisará as dependências e tipos de todos os arquivos PHP do projeto. Esse serviço não só valida o código como aponta onde há erro e qual o erro que deve ser corrigido.

Arquitetura da Máquina Virtual

Foi concebida sabendo da necessidade de uma IDE que seja capaz de fazer a checagem de erros em tempo de desenvolvimento. A solução foi criar um servidor que funciona como um serviço, que mantém o rastreamento das dependências entre os arquivos, classes e métodos e faz checagem de tipo de todos esses arquivos, recalculando os tipos quando alguma coisa é alterada. O monitoramento das mudanças ocorre quando um arquivo é salvo, já que o processo escuta os eventos do kernel de alteração de arquivo em disco.

Os requisitos

Uma das grandes características do PHP é que o desenvolvedor poder alterar parte do código diretamente no servidor, pressionar F5 no navegador e visualizar a alteração imediatamente. A Hack e a HHVM mantêm essa característica e por isso foram determinadas restrições em relação ao desempenho da checagem, como uma latência muito baixa, sendo menos de 200 milissegundos para reavaliar o contexto quando houver mudança em arquivos num cenário de operação cotidiana e alguns segundos quando for feita uma operação de versionamento. Uma segunda premissa foi a de que a HHVM deveria ser capaz de funcionar com controle de versão e ser estável, e por isso testes consistentes foram conduzidos antes de migrar o sistema do Facebook para essa tecnologia, segundo a equipe que desenvolveu a tecnologia.

Outro aspecto importante que foi considerado como condição para o projeto foi a escalabilidade e isso foi resolvido empregando paralelismo de tarefas, cache e execução de tarefas de forma incremental. As checagens de tipo são feitas pontualmente de acordo com a mudança feita, sem verificar tudo novamente, mas sim o que foi alterado (que é monitorado constantemente).

Hack versus PHP

O principal argumento da equipe do Facebook para a criação da linguagem Hack foi a ausência de tipos estáticos e a consequente dificuldade para se automatizar testes de checagem de código. Já a criação da HHVM visou incrementar a eficiência, diminuindo o custo de processamento, e permitir que checagens de código automatizadas fossem feitas em tempo de desenvolvimento, aumentando a produtividade dos programadores através da identificação mais rápida de defeitos. O anúncio da linguagem Hack traz uma séria de recursos que auxiliam na identificação de erro, mas também um novo paradigma para o universo de desenvolvedores PHP, apesar de manter a compatibilidade com códigos legados através de um modelo de convivência entre as linguagens.

O Facebook adotou a linguagem PHP para o desenvolvimento do software da sua rede social e a utiliza desde a sua criação em 2003. Com o crescimento a rede social tem relatado problemas de eficiência e produtividade ao atingir larga escala em desenvolvimento e uso da tecnologia e talvez por isso venha trabalhando no que considera um aperfeiçoamento do PHP, seguindo no sentido de tornar a tecnologia menos flexível para atingir uma melhor eficiência e produtividade. Mesmo o modelo de transição apresentado pela linguagem sendo necessário para a migração gradual de softwares existentes e trazendo flexibilidade e liberdade ao desenvolvedor a convivência entre os paradigmas de tipos dinâmico e estático na mesma linguagem traz complexidade adicional, tanto para o desenvolvedor que deseja aprender a tecnologia quanto para a máquina virtual, que tem de lidar com múltiplos cenários (tipos estáticos, dinâmicos e uma mistura entre os dois em alguns casos). Outro aspecto importante a ser considerado é a falta de suporte ao sistema operacional Windows e a ambientes de desenvolvimento integrado (IDEs) populares no mercado, como PhpStorm, Sublime e NetBeans, já que somente estão disponíveis plug-ins para as ferramentas de desenvolvimento Emacs e Vim, ambas disponíveis somente para Linux e Mac OS.

Apesar de a linguagem PHP suportar oito tipos primitivos (boolean, integer, float, string, array, object resource e null) não é possível definir o tipo de retorno de um método, de uma variável ou de um parâmetro. A exceção ocorre a partir da versão 5.0 e 5.1, nas quais é possível utilizar o conceito de indução de tipo definido pelo usuário ou de um vetor, respectivamente. Entretanto, nos dois casos, a linguagem aceita, nesses casos, receber um parâmetro com valor nulo. Já na linguagem Hack é possível definir os tipos de membros de classe, parâmetro de funções e retorno de funções. Todos os outros tipos são inferidos pela HHVM.

Para permitir a convivência com código PHP tradicional a linguagem Hack introduz o conceito de modo (hack mode, em inglês), que é a definição do nível de rigor ou flexibilidade que deve ser aplicado à checagem. Os modos disponíveis são:

  • strict – Todo o código deve ser no padrão Hack (com tipos anotados) e tudo deve ser checado pela HHVM.
  • partial – O verificador deve checar tudo que for possível, decidindo isso de forma automática e ignorando o que não for possível checar.
  • decl – Nada deve ser checado. Significa que o desenvolvedor deseja usar o PHP nativo.
  • UNSAFE – significa que deve ser criada uma exceção no modo de checagem até que termine o bloco seguinte.

O modo strict não permite o uso de funções que não sejam declaradas/importadas pelo arquivo que está sendo checado. Isso significa que funções que deveriam ser visíveis devido aos includes e requires realizados em etapas anteriores não serão analisadas e consideradas válidas. É possível ainda que haja trechos de códigos (retorno de método, parâmetro ou membro de classe) sem tipo definido. Para isso deve ser usado o modo partial ou decl ou ainda definir um bloco com UNSAFE.

A falta de tipos estáticos em PHP demanda que o desenvolvedor conheça detalhes da implementação ou leia comentários do código (que eventualmente pode não existir ou estar desatualizado) para ter ciência exata dos tipos aceitos e retornados por classes e métodos. Essa questão torna-se ainda mais importante quando vários desenvolvedores trabalham em paralelo no mesmo projeto. Isso pode gerar maior necessidade de comunicação e documentação ou facilitar a inserção de códigos com defeito. Essas demandas, no entanto, podem ser compensadas pelo fato de ser necessário se escrever menos código para executar as mesmas funções do que se escreveria em linguagens com tipos estáticos.

A inferência de tipos realizada pela HHVM, conforme o exemplo da Listagem 3, ocorre através da verificação do uso dos valores de um objeto ou variável e não necessariamente da declaração. Esse conceito é aplicado, por exemplo, a vetores. É possível criar um vetor somente com valores inteiros e adicionar um uma string na posição seguinte. O verificador permitirá isso por que na verdade esse não é um vetor de inteiros, como poderia parecer, mas um vetor de inteiros ainda não resolvido, que parece ser de inteiros, mas ainda não é. Na Hack há um tipo chamado mixed, e nesse caso o verificador infere que esse é o tipo do vetor em questão. Entretanto no momento que for tentado usar o vetor citado como um vetor de inteiros (por exemplo, retornando-o numa função que está declarada tendo como retorno um vetor de inteiros) o verificador vai invalidar o código. Na Tabela 1 comparamos os tipos suportados por cada linguagem.

Listagem 3. Inferência de tipos em Hack

 <?hh

 class MinhaClasse {

    public function fazer_algo():

        Vector<int> {    $v = Vector {1, 2};

        $v[] = “a”;   

         return $v; //neste ponto o verificador aponta erro

    }

 }

Tipo PHP Hack
Boolean sim sim
Integer sim sim
Float sim sim
String sim sim
Array sim sim
Object sim sim
Resource sim sim
Null sim sim
(deve ser definido explicitamente)
Nullable (?int, ?myclassname) não sim
Mixed não sim
Touples não sim
Closures não sim
Collections não sim
Generics não sim
Constraints não sim
Type não sim
Aliasing não Sim

Tabela 1. Tipos suportados pelo PHP e Hack

Na Listagem 4 vemos o uso do aliasing para redefinir o tipo existente (semelhante a função alias no PHP) e dos tipos genéricos (parecido com o que acontece nas linguagens Java e C#) que o PHP não suporta.

Listagem 4. Uso de aliasing e tipos generics

  // Uso de aliasing

  <?hh

 type MyInt = int;

  function foo(MyInt $mi): void {

   //fazer alguma coisa

  }

 //exemplo de uso do tipo generics

  <?hh

  class Box<T> {

    protected T $data;

    public function __construct(T $data) {

      $this->data = $data;

    }

    public function getData(): T {

      return $this->data;

    }

  }

  Box<int> $my_box = new Box<int>();

Características da PHP não suportadas na Hack

Apesar da linguagem Hack ser uma extensão da PHP há características nativas da linguagem original não suportadas na nova linguagem. Entretanto a máquina virtual HipHop suporta todos os recursos nativos do PHP e por isso se o código for aberto pela tag <?php tais recursos podem ser utilizados, mas não estará em uso a linguagem Hack e por consequência nenhum dos recursos da nova linguagem estará presente. Entre os recursos desativados alguns dos mais significativos são o uso de variáveis globais, passagem de valores por referência e marcação para silenciar erros que poderiam ser lançados por uma função.

A linguagem Hack traz características típicas de linguagens com tipos estáticos aliadas a um modelo de convivência com códigos PHP tradicionais, que visivelmente foi mantido para permitir uma transição gradual dos softwares do Facebook. Esse novo paradigma demanda projetos de software e implementações distintas da que a comunidade de desenvolvedores PHP está habituada.

A característica de conceito de tipos definidos em tempo de desenvolvimento requer mais linhas de código e estrutura arquitetural mais rígida e devido à consequente disciplina requerida pode fazer com que haja uma resistência por parte dos programadores pelo fato disso exigir que se abra mão de certa flexibilidade. Por outro lado, acrescenta grande capacidade de automatização de testes e ajuda a evitar erros durante a programação. Devido a incompatibilidades específicas vários softwares livres e proprietários devem demonstrar serem incompatíveis com a nova linguagem no seu modo strict, apesar de poderem ser executados usando a máquina virtual HipHop.

O fato de ser desenvolvida, apoiada e testada por uma empresa de destaque a área de software facilita no convencimento da sua viabilidade e confiabilidade, mas por ser muito recente requer acompanhamento para averiguar se será adotada em larga escala, pela comunidade em geral. Por se tratar de uma mudança de paradigma e apesar do modelo de convivência e das opções de modos da linguagem a mesma aponta mais para uma ruptura gradual com o PHP do que uma evolução em conjunto. A possibilidade de se programar “misturando” as duas linguagens é adequada para permitir uma maior aceitação da mesma no início, mas mesmo o Facebook afirmando que empreenderá esforços para fazer com que a nova linguagem continue sendo compatível com sua predecessora essa convivência tende a ser abandonada a logo prazo e o modo strict tende a se tornar padrão, dada as vantagens que a definição de tipos de forma estática apresenta.

Esperamos que esse artigo tenha lhe ajudado na compreensão das novas tecnologias propostas pelo Facebook e provoque uma reflexão sobre o futuro da linguagem PHP quando confrontada com suas vantagens e desvantagens considerando produtividade, eficiência e o paradigma de tipo que é adicionado pela Hack.

Retirado de:  Hack e PHP: Usando as Linguagens em aplicações Web

O que são Gateways de Pagamentos ?

Lógica de uma compra Web

Lógica de uma compra Web

Gateways de Pagamento são interfaces utilizadas por empresas de e-commerce que servem para a transmissão de dados entre clientes, comerciantes e seus bancos. Os Gateways de Pagamento são utilizados pelas empresas que fazem negócios online para processar pagamentos com cartão de crédito, e também podem ser equipados para serem utilizados em pagamentos via telefone. Um grande número de companhias oferecem tais serviços, a taxas que podem variar dependendo das políticas da empresa e os tipos de serviços que oferecem.

Um Gateway de Pagamento funciona basicamente como um terminal de cartão de crédito visto em lojas tradicionais de varejo. Quando um cliente envia informações de seu cartão de crédito, a informação é codificada e transmitida através do Gateway de Pagamento. A interface envia as informações para o banco do cliente, confirmando se o cartão é válido e se existem fundos suficientes disponíveis ou de crédito para que se processe o pagamento, enviando a aprovação caso tudo esteja correto. Esta informação é armazenada, permitindo que o comerciante apresente uma listagem de todas as transações realizadas a seu banco, para posteriormente receber os fundos.

Os Gateways de Pagamento permitem que os comerciantes processem cartões de crédito com segurança e praticidade. Ele protege os comerciantes contra cartões roubados, falsificados ou sem fundos suficientes para realizar uma transação. Eles também oferecem segurança aos consumidores, uma vez que os comerciantes não têm acesso aos dados financeiros, como o número do cartão, protegendo-os de criminosos que atuam na internet.

Ao utilizarem Gateways de Pagamento, os comerciantes geralmente almejam segurança, que seja compatível com sua plataforma de e-commerce e bancos, e que haja um suporte ágil e eficiente em caso de necessidades. Há diversos pacotes que incluem o Gateway de Pagamento junto com outras soluções para empresas de e-commerce.

O que é Design Patterns ?

Design Patterns

Design Patterns

Os Design Patterns ou Padrões de Projeto, como são conhecidos, são conceitos ou modelos orientados a objetos visando solucionar problemas no desenvolvimento de softwares. Estes padrões possuem finalidades particulares que podem ser aplicadas para controlar a estrutura, a criação e o comportamento das classes e dos objetos em uma aplicação. Dependendo da situação em que esses projetos forem aplicados, é possível notar uma redução considerável na complexidade do software em virtude da reutilização de código-fonte e de componentes.

Apesar de existir 23 padrões de projeto, é praticamente inviável implementar todos eles em uma única solução, afinal, utilizar padrões de projeto sem um propósito é uma má prática. É preciso haver um motivo real para a implementação, ou seja, uma situação em que se pode comprovar de que o padrão de projeto será uma solução adequada para o problema. Caso contrário, a implementação pode aumentar a complexidade do programa e afetar também o desempenho da aplicação.

Uma das dúvidas mais frequentes relacionadas a padrões de projeto é saber onde, quando e como utilizá-los. Em primeiro lugar, o engenheiro de software deve ter sólidos conhecimentos em Programação Orientada a Objetos e um bom nível de abstração, ou seja, a Orientação a Objetos é a base essencial para compreender os padrões de projeto. Em segundo lugar, é necessário conhecer o objetivo principal de cada padrão de projeto para que seja possível fazer um estudo da viabilidade para solucionar um problema no software. No entanto, mesmo com esse conhecimento técnico, é comum alguns engenheiros não conseguirem identificar as situações ou os módulos que devem receber a implementação dos padrões. Portanto, em terceiro lugar, o profissional também deve ter um domínio satisfatório da regra de negócio do cliente. A consolidação de todas essas experiências é o que permite a seleção e a aplicação consciente dos padrões de projeto no desenvolvimento do software.

Fonte: Profissionais TI

Desenvolvimento de Software AD HOC

Quem gerencia projetos, ou já contratou empresas para executar projetos, sabe que uma das maneiras de se diminuir custos e prazos de entrega é diminuir a qualidade do produto, não utilizar processos definidos, não gerar documentação, não executar fases previstas no desenvolvimento de software e não planejar e executar testes apropriados.

É justamente aqui que se está se armando uma grande armadilha. Os envolvidos podem não estar cientes das consequências geradas da entrega do sistema desenvolvido sem ter sido dada a devida atenção à qualidade. Todo numerário economizado no desenvolvimento poderá e será gasto na geração de novas versões corrigidas que deverão ser entregues ao cliente, além de termos um custo imensurável ligado a imagem do produto e da própria empresa.

Outro efeito da falta da utilização de processos definidos e da engenharia de software é a geração de sistemas não amigáveis para uso, apresentando informações consideradas não fidedignas e com erros de funcionamento. Neste cenário, nenhum usuário se interessará em utilizar o sistema desenvolvido, fazendo que o projeto fracasse e que seja perdido todo o investimento realizado.

Imagine o cenário de um sistema de cobrança bancária, para o qual você poderia estar participando de um processo de manutenção corretiva, sem ter documentação do sistema e sem ter conhecimento das regras de negócio implementadas. Imagine também que está manutenção está relacionada à correção de informações, que estão sendo geradas incorretamente. Agora, para finalizar, imagine que o sistema possui milhares de linhas de código e você é novo na equipe, sendo que os programadores que implementaram o sistema não estão mais na empresa.

Por mais que este cenário seja assustador, podemos encontrá-lo neste exato momento em diversos lugares, enquanto você lê este artigo.

O que faltou no projeto de desenvolvimento deste tipo de sistema?

Tecnicamente, poderia citar:

  • Engenharia de Software e utilização de processos definidos
  • Utilização de metodologia de desenvolvimento de sistema alinhado ao paradigma associado ao projeto
  • Utilização de Design Patterns quando apropriado
  • Documentação adequada
  • Planejamento e execução de testes adequados

Do lado humano, poderia citar:

  • Participação no projeto de profissionais com conhecimento dos itens técnicos acima relacionados
  • Falta de percepção do patrocinador do projeto, do valor e benefícios de se utilizar os itens acima relacionados
  • Falta de conhecimento dos envolvidos no projeto, das melhores práticas de mercado para desenvolvimento de software e de seus benefícios

Já tive a oportunidade de presenciar de empresários e executivos, o seguinte comentário:

Prefiro o desenvolvimento de software sem utilizar Orientação a Objetos e processos de desenvolvimento, pois é mais barato e mais rápido de se disponibilizar o sistema para os usuários.

Desenvolver código baseado nesta ideia pode gerar as seguintes consequências:

  • Implantação de sistemas cheios de erros, constantemente entrando em manutenção;
  • Sistemas que podem não atender às expectativas dos Stakeholders;
  • Softwares com alto custo de manutenção;
  • Softwares difíceis de serem utilizados, não atendendo às necessidades dos StakeHolders;
  • Grande insatisfação dos usuários;
  • Fracasso do projeto.

O desenvolvimento de sistema sem utilizar processos, AD HOC, acaba custando muito mais caro, gerando insatisfação.

Já presenciei várias vezes, pessoas que simplesmente não queriam e não utilizavam sistemas disponibilizados pela empresa, por pelo menos um dos seguintes motivos:

  • Não confiavam nos dados por eles apresentados
  • Porque não atendiam a suas expectativas e necessidades do dia a dia
  • Porque tinham usabilidade ruim
  • Porque viviam apresentando problemas de funcionamento

O detalhe mais triste é que as empresas onde estas pessoas trabalhavam, investiram dinheiro e tentaram disponibilizar sistemas para melhorar a produtividade e diminuir custos das mesmas. O resultado foi exatamente o contrário, além de não diminuir custos, nem aumentar a produtividade, as empresas perderam todo o investimento realizado e o sistema caiu em desuso, literalmente, sendo jogado fora.

Bibliografia

Artigo Retirado de Profissionais TI