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

 

Anúncios

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

Seis Frases que você nunca deve dizer ao colega de trabalho

coisas-deve-dizer-trabalho-noticiasSe você costuma falar o que bem entende a quem quer que seja, inclusive no ambiente corporativo, talvez seja o momento de parar um pouco para pensar no efeito que algumas frases podem ter sobre a sua imagem no trabalho. Isso porque algumas frases feitas, daquelas que todo mundo fala aqui e ali, nem sempre são tão inofensivas quanto podem parecer. Veja alguns exemplos descritos pela consultora de imagem Renata Mello.

1 – “Bem-vindo ao inferno!”

A situação não é rara. Um funcionário antigo recebe um novo contrato com essa pérola. É o tipo de frase que não faz bem para ninguém, mesmo quando dita em tom de brincadeira. Quem está chegando certamente perde parte de seu entusiasmo com ela, além de ficar com aquela pulga atrás da orelha. “Por que ele disse isso?” Já quem fala com certeza corre riscos. Afinal, falar mal da empresa, seja no tom que for, prejudica a imagem de todo profissional. Sem contar que nunca se sabe quem mais estará ouvindo e compartilhando o que ouviu, não é?

2 – “Prepare-se porque nosso supervisor é um mala sem alça!”

Julgar o chefe em voz alta também é um risco e tanto para a sua carreira. Dizer isso para alguém que foi recém contratado como seu par, então, é um risco muito maior. E se o colega foi indicado pelo seu supervisor? E se eles se tornarem melhores amigos? Não tinha pensado nisso? Então, da próxima vez, pense muito bem antes de falar qualquer coisa.

3 – “As coisas aqui são assim mesmo, tudo é muito demorado!”

Tudo bem que essa seja de fato a sua opinião, mas o que não vale é ficar compartilhando o que você pensa com qualquer pessoa. Apenas criticar a empresa em que você trabalha só vai piorar o ambiente de trabalho e prejudicar sua carreira lá dentro.

4 – “Vou até o banheiro fazer um ‘pips’ e já volto.”

Ops… você tem certeza que alguém precisa saber disso? Provavelmente não, né? Então, o melhor a fazer é não abrir tanto a sua intimidade. Todo mundo vai agradecer, você vai ver.

5 – “Quanto você pagou?”

“Essa pergunta pode ser extremamente inconveniente se você estiver falando com alguém com quem não tem intimidade”, diz Renata. Lembre-se de que perguntas que envolvem dinheiro são especialmente complicadas de fazer – para qualquer pessoa, em qualquer situação.

6 – “Hoje eu não estou pra ninguém!”

Segundo a consultora, achar que você pode não estar para ninguém por si só já é um erro. Dizer isso ao colega, então, é um erro dobrado. Se você está na empresa, precisa estar disponível para ela e para quem precisar de você. Ou não?

Texto retirado de: vagas.com.br

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

O que são Cron Jobs

Cron JobsO que são e como usar as Cron Jobs?

Hoje precisei criar uma rotina que em determinado horário ele executa um script em php automaticamente para mim todos os dias no mesmo horário, portanto em pesquisa descobri o Cron Job.

O que são as Cron Jobs?

As Cron Jobs são como as Tarefas Agendadas do Windows: são tarefas executadas automaticamente de X em X tempos… Fazendo uma analogia à vida real é quando você tira o lixo pra fora ou arruma seu quarto, provavelmente você faz isso seguindo sempre um mesmo intervalo de tempo… De 2 em 2 dias, de 1 em 1 semana e por ai vai.

O termo “Cron Job” (também só chamado de cron) está mais ligado a sistemas UNIX do que Windows mesmo… Por isso o que vou falar aqui só se encaixa no Linux. Se você usa Windows é só dar uma olhada nas tarefas agendadas que você vai ter uma interface completa para trabalhar com as Tarefas Agendadas.

Pra que usar uma Cron Job em um site/sistema online?

Acho que o propósito mais comum de uma Cron Job seja a rotina de backup… Scripts que rodam diariamente (ou até mais demorados) e que fazem o backup do site e do banco de dados.

Você pode criar uma cron para quase qualquer coisa, mas geralmente são para atualização, limpeza, backup e etc.

Como criar uma Cron Job?

Se o seu site roda em algum servidor especializado e você tem um painel de controle como o cPanel recomendo que dê uma olhada lá pois existe uma interface web prontinha para gerenciar as crons… se você não tem esse painel ou não tem acesso à ele vai ter que ir direto ao shell / terminal do seu servidor e começar a gastar o dedo.

A definição de uma cron job consiste em uma linha com 6 valores separados por espaço, assim:

minuto hora dia mes dia-da-semana linha-de-comando

Vamos a alguns exemplos de configuração de tempo antes de criar a cron em si:

Cron Job que rode todo dia as 06:00am

0 6 * * * linha-de-comando

Cron Job que rode as 12:30am de segunda e sexta

30 12 * * 1,5 linha-de-comando

Cron Job que rode a meia-noite de três em três dias

0 0 */3 * * linha-de-comando

Cron Job que rode todo dia a cada duas horas

0 */2 * * * linha-de-comando

A linha-de-comando

É um comando que você usaria normalmente para iniciar um script ou chamar um wget. :)

Instalando suas Cron Jobs

Agora é só salvar o conteúdo das suas crons, uma por linha em um arquivo chamado cron.txt e colocar uma linha assim no começo (primeira linha) do arquivo:

MAILTO=meuemail@meudominio.com

Isso fará com que os erros sejam enviados para o e-mail determinado.

Depois é só ir no terminal/shell e chamar o comando:

crontab cron.txt

Se nada der errado a cron foi instalada com sucesso e você pode vê-la na lista de crons que estão rodando:

crontab -l

Otimizações na Web e o carregamento assíncrono

Ao preocupar-se com otimizações Web, o uso de ferramentas como o PageSpeed ou YSlow é muito importante, mas ainda mais crucial é executar testes frequentes e analisar os tempos. A ferramenta WebPageTest, é excelente para esse fim.

Um post aqui do Blog sobre otimização de performance na Web mostrou 7 práticas simples e altamente recomendadas para melhorar sensivelmente a performance de qualquer página Web, como usar GZIP, agrupar e comprimir CSS e JavaScript, colocar CSS no topo e JavaScript embaixo da página, entre outras. Mas há muitas outras práticas interessantes, como o carregamento assíncrono de JavaScript e componentes não essenciais à página.

Carregamento assíncrono de JavaScript

Carregamento assíncrono de JavaScript

Carregamento assíncrono de JavaScript

Colocar arquivos JavaScript no <head> ou espalhado no meio do HTML é má prática há anos. A boa prática é sempre jogar para antes do </body>, uma das regras principais analisadas pelo YSlow. Mas será que jogar o JavaScript para o fim da página é suficiente?

Muitos navegadores não suportam download em paralelo de arquivos JavaScript quando usamos a tag <script>, independentemente da posição em que apareça. E não apenas navegadores antigos como IE6 ou 7; Chrome, Opera, Firefox3 e outros engrossam essa lista. Steve Souders, papa de otimizações Web, sugeriu diversas técnicas em seu livro Even faster Web Sites. Começaram a surgir então ideias e bibliotecas com objetivo de carregar JavaScript em paralelo assincronamente, como LABjsHeadJS e ControlJS, do próprio Steve.

Estou estudando sobre otimização de páginas web portanto, utilizarei o o LABjs, mas independentemente de framework, o importante é carregar assincronamente seus arquivos JavaScript, principalmente se vários arquivos são usados na página. Além do download paralelo, o evento onload dispara mais cedo, executando os callbacks associados a ele e dando uma medida melhor de performance da página.

É preciso tomar cuidado, porém, com a ordem de execução dos scripts caso haja dependências entre eles (muito comum ao usar um framework como JQuery). As ferramentas citadas possuem suporte para manter a ordem de execução. Um outro problema é quando há uso do document.write, algo que é má prática há muito tempo mas infelizmente ainda muito usado.

Usar o LABjs é bastante simples:

// carrega 3 scripts em paralelo mas mantém ordem de execução$LAB.script(‘jquery.js’).wait()    .script(‘plugin.jquery.js’).wait()    .script(‘app.js’); 

// carrega e executa outro script em paralelo, com callback

$LAB.script(‘sem-dependencias.js’).wait(function() {

   alert(‘Callback executando quando script carrega’);

});

O HTML5 especificou um novo atributo async na tag <script> mas poucos browsers suportam. O IE possui um atributo proprietário defer há muito tempo, com propósito parecido. Enquanto não há uma solução padrão e portável, o uso de algum framework de carregamento assíncrono é recomendado.

Adiando o carregamento de conteúdo secundário

Além de JavaScripts assíncronos, é possível melhorar bastante a performance deixando para carregar certos componentes mais tarde, apenas quando necessários. A Caelum tem fotos grandes com chamadas principais rotacionadas. É um efeito muito comum atualmente, mas um grande desafio de performance, já que essas imagens costumam ser grandes e pesadas.

A primeira implementação da Caelum consistia em um HTML simples com tags <img> apontando para cada imagem, um pouco de CSS para mostrar apenas uma imagem por vez e um código JQuery para alternar as imagens com um efeito legal. É uma implementação usada por muitos Sites e plugins do JQuery.

Mas colocar as <img> direto no HTML fazia o navegador carregar todas essas imagens conforme ia lendo o HTML, mesmo que 3 das 4 imagens só fossem aparecer para o usuário muito tempo depois. Era gasto um tempo precioso do carregamento da página, que podia ser usado carregando outros componentes mais essenciais para a renderização inicial, como outras imagens do layout e scripts.

A solução foi carregar assincronamente, via JavaScript, as imagens secundárias, deixando inicialmente apenas a primeira imagem com HTML normal. Usamos os data attributes do HTML5 para criar atributos próprios no HTML que referenciam os endereços das imagens secundárias:

<ul>

<li>

<p>Conheça os cursos de Java da Caelum</p>

<img alt=”Cursos Java” src=”banner_01.jpg” width=”960″ height=”330″ />

</li>

<li data-img-src=”banner_02.jpg”>

<p>Veja os projetos da Caelum</p>

</li>

<li data-img-src=”banner_03.jpg”>

<p>Baixe as apostilas gratuitas</p>

</li>

</ul>

Repare como apenas o primeiro banner possui a <img> direto no HTML. Os demais apenas declaram os caminhos em atributos data- que não são interpretados pelo navegador. Uma função JavaScript pode, então, ler esses valores e gerar as tags <img> de forma assíncrona, depois que a página foi carregada:

$(function() {

setTimeout(function(){

$(‘li[data-img-src]’).each(function(){

var src = $(this).attr(‘data-img-src’);

$(‘<img>’).attr(‘src’, src).appendTo(‘ul’);

});

}, 600);

});

Usando JQuery, selecionamos todos os <li> que possuem o atributo data-img-src. Criamos, então, um novo elemento <img> com o src apontando para o endereço da imagem. Repare que tentamos adiar esse carregamento o máximo possível, já que a segunda imagem só aparecerá para o usuário depois de vários segundos. No código acima, agendamos o script para rodar 600 milissegundos após o carregamento da página.

Observe no gráfico de conexões HTTP ao longo do tempo como o primeiro banner é carregado no início junto com o restante da página e os demais são carregados bem depois:

primeiro banner é carregado no início junto com o restante da página e os demais são carregados bem depois

Uma preocupação possível com essa prática é com usuários com JavaScript desabilitado ou navegadores limitados. É preciso pensar bem nesse caso e oferecer uma boa experiência para o usuário em todas as situações. Mas as imagens rotativas dependem de JavaScript para funcionar; logo, mesmo sem o carregamento assíncrono das imagens secundárias, o efeito não funcionaria e apenas a primeira imagem (em HTML e CSS puros) seria mostrada. Portanto, não há impacto para o usuário em usar a solução JavaScript para carregamento das imagens. Um impacto possível é que os buscadores não enxergam mais as imagens secundárias e, portanto, estas não serão indexadas. Não é um problema no nosso caso, mas pode ser um detalhe importante em outros cenários.

Widgets externos assincronamente

Outro bom exemplo para carregamento assíncrono é dos widgets do Facebook, usados na home de muitos sites e blogs com um Like Button no topo e um Like Box no corpo da página. Onipresentes hoje na Web, esses widgets são importados na página com um <iframe>. O <iframe> tem a vantagem de carregar paralelamente com a página, mas ainda trava o onload da página até que acabe de carregar – e os widgets do Facebook são gigantescos, com mais de 50 requests, 250 KB e 5 segundos para carregar mesmo em navegadores modernos.

Steve Souders mostrou que a tag <iframe> é o elemento mais caro a ser criado no DOM, ordens de magnitude mais lento, mesmo vazio. Mas o principal problema é o onload da nossa página passar a depender do onload do widget, que é grande e lento. Devemos otimizar o tempo que o onload dispara, pois isso dispara os callbacks de onload (bastante comuns) e porque o indicador de carregamento do navegador para de girar após o onload (dando a sensação de rapidez pro usuário).

A melhor estratégia é carregar o <iframe> após o onload via JavaScript, ainda mais se não é algo crítico, como o widget do Facebook. O código é bastante simples:

$(window).load(function(){

$(‘#facebook_like_box’)

.html(‘<iframe src=”https://www.facebook.com/plugin…></iframe>’);

});

Esse carregamento assíncrono do Facebook foi o responsável pela maior parte da otimização final mostrada no vídeo do início do post. Repare no gráfico a seguir como o carregamento todo dos widgets é feito apenas após o onload e, apesar de grande e lento, não afeta a performance do restante da página:

1

Como o widget demora bastante para carregar, o resto da página (já bastante otimizada) aparecerá rapidamente mas o widget bem depois. Para minimizar esse efeito, o header da página da Caelum carrega primeiro um botão like de mentira, com uma imagem simples copiando o visual do widget do Facebook. Quando o widget acaba de carregar, ele é inserido no lugar dessa imagem falsa com precisão, a ponto de ser quase imperceptível para o usuário. Se o usuário clicar na imagem falsa antes do widget carregar, será levado para o Facebook da Caelum; mesmo comportamento se o JavaScript estiver desabilitado. É um truque simples que traz a sensação de alta performance ao carregar a imagem falsa logo, apesar de ser tudo assíncrono e demorado.

 FONTE: Caleum