Quais as principais diferenças entre o Symfony2 e Symfony1 ?

11, agosto 2011   •   (Não há comentários)   •   Autor: Thiago Dieb

Estou de volta com um post direcionado à área técnica. O objetivo deste post é apresentar as principais diferenças da nova versão do Framework Symfony, com relação a versão anterior. O post se fez necessário, houve algumas mudanças bem relevantes.

Pra quem não conhece o Symfony1, ele tem uma abordagem muito parecida com o Zend Framework, com sua essência na arquitetura MVC. Um detalhe interessante é a abertura na camada de Model, permitindo o vínculo com outros Frameworks conhecidos por ORM`s, como: Propel e Droctrine.

Abaixo tenho um demonstrativo da relação dos principais itens técnicos sobre as duas versões:

symfony 1,4 Symfony 2,0
Estabilidade Estável Estável
Data de lançamento 11/2009 07/2011
Últimas 1.4.13 2.0.0
Apoio 3 anos n / a
PHP versão > = 5.2.4 > = 5.3.2
Versões ORM Propel: 1.4 
Doutrina: 1.2
Doutrina: 2.1
Fim da manutenção 11/2012 n / a
Documentação Documentação Documentação
Instalação Instruções detalhadas Instruções detalhadas
Repositório principal http://svn.symfony-project.com/branches/1.4 http://github.com/symfony/symfony.git

 

O salto da versão do Symfony não é por acaso, tanto sua estrutura quanto seu conceito foram afetados, e com certeza a forma de criação dos projetos. Então vamos lá.

Symfony2 vs Symfony1.

Ressalto que todas habilidades aplicadas para dominar um projeto no Symfony1 continuam a ser muito relevante no desenvolvimento em Symfony2.

Estrutura de Diretórios

Com uma pequena analise em uma projeto com Symfony2, percebemos que houve várias alterações em sua estrutura de diretórios. Suas mudança aplicam-se:

/app

No Symfony1, o projeto contém uma ou mais aplicações, e todos dentro do diretório/app. Por padrão no Symfony2, encontraremos apenas uma aplicação no projeto. Nesse diretório teremos configurações específicas para cache, logs e diretórios de templates, bem como uma classe Kernel (AppKernel), que será responsável por definir quais bundles serão utilizados na aplicação.

/src

Esse diretório é bem parecido com o diretório /plugins do Symfony1. Seu propósito foi de centralizar todos o códigos de uma determinada aplicação em um só lugar. No Symfony1, tínhamos vários apps, onde poderíamos compartilhar vários plugins e outros códigos PHP. Porém ficavam em diretórios separados. No Symfony2, a vida é muito mais simples porque todo o código deve estar em um pacote.

/vendor

O /vendor é equivalente ao diretório /lib/vendor do Symfony1, abrangendo todas as bibliotecas vendor e bundles. Por padrão, encontraremos nesse diretório os arquivos da biblioteca Symfony2, juntamente com várias outras bibliotecas dependentes, como Doctrine2, Twig e SwiftMailer.

/web

Quase não houve alterações nesse diretório. A diferença mais notável é a ausência dos diretórios /css, /js, /images. Isso é intencional. Como todos os códigos PHP devem ficar juntos, os ativos também devem estar dentro do mesmo pacote.
Com a ajuda de um comando de console, os arquivos do diretório Resources/public/ de cada pacote é copiado ou simbolicamente ligado ao diretório /web/bundles/.
Isto permite-lhe manter os ativos organizados dentro do seu pacote, mas ainda torná-los disponíveis ao público.

Autoloading

Autoloading mudou no Symfony2, agora é mais universal, mais rápido, e independente da necessidade de limpar o cache.
No Symfony1, autoloading foi feito através de pesquisas em todo o projeto para buscar os arquivos de classe PHP e incluía em cache estas informações em uma matriz gigante.
Quem lida com esse processo no Symfony2 é uma nova classe chamada : UniversalClassLoader. A idéia por trás do autoloader é simples: o nome da classe (incluindo o namespace) deve coincidir com o caminho para o arquivo que contém essa classe. Veja o exemplo:

namespace Sensio\Bundle\FrameworkExtraBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
// ...
class SensioFrameworkExtraBundle extends Bundle
{
// ...

Usando o Console

Com o Symfony1, o console está no diretório raiz do seu projeto e é chamado symfony:
php symfony

No Symfony2, o console é agora no sub-diretório app:
php app/console

Aplicações

Em um projeto Symfony1, é comum ter várias aplicações: uma para o frontend e outra para o backend, por exemplo. No Symfony2, só precisamos criar uma aplicação (uma aplicação de blog, um aplicativo de intranet, …). Na maioria das vezes, se quisermos criar uma segunda aplicação, podemos em vez disso criar outro projeto e compartilhar alguns pacotes entre eles.

Caso precisarmos separar a interface e os recursos de backend de alguns pacotes, criaremos sub-diretórios para os controladores, sub-diretórios para modelos, configurações de semântica, configurações de roteamento, e assim por diante.

Claro, não há nada de errado em ter várias aplicações em um projeto. A segunda aplicação significaria um novo diretório, por exemplo, /my_app, com a mesma configuração básica do diretório /app.

Bundles and Plugins

Um plugin no Symfony1 pode conter arquivos de configuração, módulos, bibliotecas PHP, ativos e qualquer outra coisa relacionada ao seu projeto. Em Symfony2, a idéia é que um plugin seja substituído por  ”pacote” (bundle). Um conjunto ainda mais poderoso do que um plugin.

Um plugin deve ser ativada dentro da classe ProjectConfiguration, isso quando utilizamos o Symfony1:

// config/ProjectConfiguration.class.php
public function setup()
{
$this->enableAllPluginsExcept(array(/* some plugins here */));
}

No Symfony2, os bundles são ativadas dentro do AppKernel:

// app/AppKernel.php
public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
// ...
new Acme\DemoBundle\AcmeDemoBundle(),
);
return $bundles;
}

Routing (routing.yml) e Configuração (config.yml)

No Symfony1, os arquivos de configuração routing.yml e app.yml foram carregados automaticamente dentro de qualquer plugin. O processo muda um pouco no Symfony2, roteamento e configuração da aplicação fica dentro de um pacote que devem ser incluídos manualmente. Por exemplo, para incluir um recurso de roteamento de um pacote chamado AcmeDemoBundle, faremos o seguinte:

# app/config/routing.yml
_hello:
resource: "@AcmeDemoBundle/Resources/config/routing.yml"

Isso irá carregar as rotas encontradas no Resources/config/routing.yml do AcmeDemoBundle. O especial @AcmeDemoBundle é uma sintaxe de atalho que, internamente, resolve para o caminho completo para esse pacote.
Podemos usar esta mesma estratégia para trazer na configuração de um pacote:

# app/config/config.yml
imports:
- { resource: "@AcmeDemoBundle/Resources/config/config.yml" }

 

Essas são as principais modificações, porém não acabamos por ai. Recomendo, caso queria inciar a criação de projetos utilizando Symfony2, não deixe de ler a documentação, isso é essencial.

Fico por aqui.

Fontes:
http://symfony.com/doc/current/cookbook/symfony1.html

Quais as principais diferenças entre o Symfony2 e Symfony1 ?

   •   (Não há comentários)   •   Autor: Thiago Dieb

Estou de volta com um post direcionado à área técnica. O objetivo deste post é apresentar as principais diferenças da nova versão do Framework Symfony, com relação a versão anterior. O post se fez necessário, houve algumas mudanças bem relevantes.

Pra quem não conhece o Symfony1, ele tem uma abordagem muito parecida com o Zend Framework, com sua essência na arquitetura MVC. Um detalhe interessante é a abertura na camada de Model, permitindo o vínculo com outros Frameworks conhecidos por ORM`s, como: Propel e Droctrine.

Abaixo tenho um demonstrativo da relação dos principais itens técnicos sobre as duas versões:

symfony 1,4 Symfony 2,0
Estabilidade Estável Estável
Data de lançamento 11/2009 07/2011
Últimas 1.4.13 2.0.0
Apoio 3 anos n / a
PHP versão > = 5.2.4 > = 5.3.2
Versões ORM Propel: 1.4 
Doutrina: 1.2
Doutrina: 2.1
Fim da manutenção 11/2012 n / a
Documentação Documentação Documentação
Instalação Instruções detalhadas Instruções detalhadas
Repositório principal http://svn.symfony-project.com/branches/1.4 http://github.com/symfony/symfony.git

 

O salto da versão do Symfony não é por acaso, tanto sua estrutura quanto seu conceito foram afetados, e com certeza a forma de criação dos projetos. Então vamos lá.

Symfony2 vs Symfony1.

Ressalto que todas habilidades aplicadas para dominar um projeto no Symfony1 continuam a ser muito relevante no desenvolvimento em Symfony2.

Estrutura de Diretórios

Com uma pequena analise em uma projeto com Symfony2, percebemos que houve várias alterações em sua estrutura de diretórios. Suas mudança aplicam-se:

/app

No Symfony1, o projeto contém uma ou mais aplicações, e todos dentro do diretório/app. Por padrão no Symfony2, encontraremos apenas uma aplicação no projeto. Nesse diretório teremos configurações específicas para cache, logs e diretórios de templates, bem como uma classe Kernel (AppKernel), que será responsável por definir quais bundles serão utilizados na aplicação.

/src

Esse diretório é bem parecido com o diretório /plugins do Symfony1. Seu propósito foi de centralizar todos o códigos de uma determinada aplicação em um só lugar. No Symfony1, tínhamos vários apps, onde poderíamos compartilhar vários plugins e outros códigos PHP. Porém ficavam em diretórios separados. No Symfony2, a vida é muito mais simples porque todo o código deve estar em um pacote.

/vendor

O /vendor é equivalente ao diretório /lib/vendor do Symfony1, abrangendo todas as bibliotecas vendor e bundles. Por padrão, encontraremos nesse diretório os arquivos da biblioteca Symfony2, juntamente com várias outras bibliotecas dependentes, como Doctrine2, Twig e SwiftMailer.

/web

Quase não houve alterações nesse diretório. A diferença mais notável é a ausência dos diretórios /css, /js, /images. Isso é intencional. Como todos os códigos PHP devem ficar juntos, os ativos também devem estar dentro do mesmo pacote.
Com a ajuda de um comando de console, os arquivos do diretório Resources/public/ de cada pacote é copiado ou simbolicamente ligado ao diretório /web/bundles/.
Isto permite-lhe manter os ativos organizados dentro do seu pacote, mas ainda torná-los disponíveis ao público.

Autoloading

Autoloading mudou no Symfony2, agora é mais universal, mais rápido, e independente da necessidade de limpar o cache.
No Symfony1, autoloading foi feito através de pesquisas em todo o projeto para buscar os arquivos de classe PHP e incluía em cache estas informações em uma matriz gigante.
Quem lida com esse processo no Symfony2 é uma nova classe chamada : UniversalClassLoader. A idéia por trás do autoloader é simples: o nome da classe (incluindo o namespace) deve coincidir com o caminho para o arquivo que contém essa classe. Veja o exemplo:

namespace Sensio\Bundle\FrameworkExtraBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
// ...
class SensioFrameworkExtraBundle extends Bundle
{
// ...

Usando o Console

Com o Symfony1, o console está no diretório raiz do seu projeto e é chamado symfony:
php symfony

No Symfony2, o console é agora no sub-diretório app:
php app/console

Aplicações

Em um projeto Symfony1, é comum ter várias aplicações: uma para o frontend e outra para o backend, por exemplo. No Symfony2, só precisamos criar uma aplicação (uma aplicação de blog, um aplicativo de intranet, …). Na maioria das vezes, se quisermos criar uma segunda aplicação, podemos em vez disso criar outro projeto e compartilhar alguns pacotes entre eles.

Caso precisarmos separar a interface e os recursos de backend de alguns pacotes, criaremos sub-diretórios para os controladores, sub-diretórios para modelos, configurações de semântica, configurações de roteamento, e assim por diante.

Claro, não há nada de errado em ter várias aplicações em um projeto. A segunda aplicação significaria um novo diretório, por exemplo, /my_app, com a mesma configuração básica do diretório /app.

Bundles and Plugins

Um plugin no Symfony1 pode conter arquivos de configuração, módulos, bibliotecas PHP, ativos e qualquer outra coisa relacionada ao seu projeto. Em Symfony2, a idéia é que um plugin seja substituído por  ”pacote” (bundle). Um conjunto ainda mais poderoso do que um plugin.

Um plugin deve ser ativada dentro da classe ProjectConfiguration, isso quando utilizamos o Symfony1:

// config/ProjectConfiguration.class.php
public function setup()
{
$this->enableAllPluginsExcept(array(/* some plugins here */));
}

No Symfony2, os bundles são ativadas dentro do AppKernel:

// app/AppKernel.php
public function registerBundles()
{
$bundles = array(
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
// ...
new Acme\DemoBundle\AcmeDemoBundle(),
);
return $bundles;
}

Routing (routing.yml) e Configuração (config.yml)

No Symfony1, os arquivos de configuração routing.yml e app.yml foram carregados automaticamente dentro de qualquer plugin. O processo muda um pouco no Symfony2, roteamento e configuração da aplicação fica dentro de um pacote que devem ser incluídos manualmente. Por exemplo, para incluir um recurso de roteamento de um pacote chamado AcmeDemoBundle, faremos o seguinte:

# app/config/routing.yml
_hello:
resource: "@AcmeDemoBundle/Resources/config/routing.yml"

Isso irá carregar as rotas encontradas no Resources/config/routing.yml do AcmeDemoBundle. O especial @AcmeDemoBundle é uma sintaxe de atalho que, internamente, resolve para o caminho completo para esse pacote.
Podemos usar esta mesma estratégia para trazer na configuração de um pacote:

# app/config/config.yml
imports:
- { resource: "@AcmeDemoBundle/Resources/config/config.yml" }

 

Essas são as principais modificações, porém não acabamos por ai. Recomendo, caso queria inciar a criação de projetos utilizando Symfony2, não deixe de ler a documentação, isso é essencial.

Fico por aqui.

Fontes:
http://symfony.com/doc/current/cookbook/symfony1.html

Usando push na web (Comet, Push Ajax e Ajax Reverso), veja como funciona !

26, julho 2011   •   (Não há comentários)   •   Autor: Thiago Dieb

Esse será meu primeiro post técnico. Não devo me aprofundar muito na parte da programação, pois o objetivo é demonstrar a tecnologia do Push em aplicações Web, de forma prática e simples.

Inicialmente temos que entender como funciona o processo de abertura de uma página Web. Na imagem abaixo fica mais fácil demonstrar o funcionamento das requisições entre os clientes -Navegadores de internet (Browser) – e os servidores – Computadores que hospedam os sites.

cliente-servidor

Para que tenhamos algum conteúdo em nosso navegador, temos que fazer uma requisição ao servidor, ou seja, um pedido. Ao receber esse pedido o servidor processa sua solicitação e responde assim o seu browser mostra o conteúdo. Destaco que esse é o procedimento normal feito pela grande maioria dos sites.

A  tecnologia de Push prevê uma pequena mudança no processo das requisições dos dados. Ela é conhecida por vários nomes, como: Comet, Server Push, Push ajax, Ajax Reverse e muitas outros. Sua implementação tem o intuito de não depender mais das solicitações vindas pelos clientes. O processo parte agora do lado do servidor, agora o servidor que envia os dados sem nenhuma solicitação vinda do cliente, no qual fica só recebendo as remessas enviadas pelos servidores. Observe na próxima imagem.

Temos várias ramificações no instante da implementação da técnica, a seguir listo as maneiras mais utilizadas:

  • HTTP Pull: É a forma mais tradicional, o cliente faz as requisições ao servidor em intervalos muito curtos.
  • HTTP Streaming: Este método consiste em transmissão de dados do servidor com uma conexão HTTP de longa duração.
  • Reverse AJAX: Como o próprio nome diz, é o processo inverso ao Ajax, permitindo ao servidor enviar dados para o cliente quando ocorre um evento, mesmo sem que o cliente tenha feita algum pedido.
  • Long Polling: Não fugindo da ideologia, esse processo é baseado em etapas de assinatura e publicação. O cliente assina um canal, conectando ao servidor, mantendo aberta por uma quantidade definida de tempo. Caso um evento ocorra, o servidor envia os dados para o cliente, caso o cliente tenham seu tempo limite expirado o servidor envia uma requisição para que o cliente se re-conecte.

Pra facilitar o entendimento fiz um vídeo que demonstra como funciona na prática esse tipo de tecnologia.

Note que utilizei vários browser diferentes com objetivo de simular clientes distintas.

O procedimento é simples, a cada alteração feita no servidor, os clientes recebem a informação que algo foi modificado. Destaquei alem disso o log do servidor para asegurar que não há nenhuma requisição feita enquanto o servidor não altera os dados.

O Projeto do vídeo está disponível para download, baixe e se divirta.
Download

Fico por aqui.

Fontes:
http://www.mindfiresolutions.com/Comet-Server-PushReverse-Ajax–Mindfire-Solutions-897.php
http://www.zeitoun.net/articles/comet_and_php/start
http://www.infoq.com/news/2007/07/pushvspull
http://en.wikipedia.org/wiki/Comet_(programming)

Bolha 2.0: Estamos cada vez mais próximos do estouro, será ?

11, julho 2011   •   (Não há comentários)   •   Autor: Thiago Dieb

Conceito antigo que volta a assombrar muitos investidores após uma Década. O valores exorbitantes nas avaliações dos capitais de diversas empresas causou grandes prejuízos, pois os valores eram puras estimativas.

Em meados de 1999 pra 2000 ocorreu um fato chamado “estouro da bolha da internet”, este acontecimento marcou a época das altas estimativas nas empresas virtuais nas bolsas de valores.
Grandes empresas da internet, como a Netscape, estavam abrindo seu capital para o mercado conhecido por IPO (sigla em inglês para oferta pública inicial de ações). Até aqui nada de incomum! Várias empresas fazem isso para capitalização de recursos. Porém a especulação dos valores dessas empresas eram irreais. Por exemplo, uma companhia que tinha seu faturamento média anual de US$ 1,5 milhão estava recebendo estimativa de US$ 70 milhões. Com isso muitas empresas com capitais bem menores estavam recebendo o mesmo tipo de especulação.

O problema da estimativa estava em relação aos lucros dessas empresas, a maioria estavam com pouco capital, consequentemente pouco lucro.
Foi nesse momento que houve o “estouro da bolha”. Várias empresas começaram a ter prejuízos, inclusive as pequenas, que não tinha um planejamento muito fortalecido e, assim, queimando todo o seu investimento que adquiriram. Como previsto, algumas entraram e estado de falência e outras divulgaram a venda por valores simbólicos.

Bolha 2.0 está próxima

Atualmente a bolha 2.0 não é uma ilusão, de acordo com vários especialistas estamos com alguns sinais muito parecidos com o estouro de 2000. Se analisarmos um pouco o mercado de hoje notaremos que esse mesmo tipo de negociação ou especulação nas empresas da internet estão voltando aos poucos. No início do ano o Facebook foi avaliado em US$ 50 bilhões. Sabemos que ainda não começou sua oferta de ações, mas antes disso já adquiriu esse valor! Agora imaginem quando abrir seu capital ?

Não perdendo tempo a rede social de currículos, a LinkedIn, fez seu IPO no mês de maio e adquiriu valores muito maiores que o previsto. No início do pregão suas ações estavam em torno de US$ 45 e subiram para US$ 122 e terminaram o dia com alta de 109%, a US$ 94. Resultado: a companhia está avaliada em US$ 8,9 bilhões.
Temos um furo nisso tudo, a rede social não estava com um faturamento muito bom. Em 2010 ela gerou US$ 15 milhões, isso significa que seu valor é quase 600 vezes de sua receita. No mercado da bolsa o valor médio de uma empresa ao abrir seu capital costuma ser o seu faturamento em dez anos. Observaram a discrepância ?
Ouvimos diversos rumores sobre o valor do Twitter, pelas especulações, seu valor poderia chegar a US$ 10 bilhões. Novamente não podemos deixar de lado a análise da receita anual, que poderá chegar a US$ 110 milhões em 2011. Notou como as contas não batem ? Outro ponto relevante nessa história é o plano de negócio da empresa em questão, que não é direcionado a lucratividade, hoje tentam implementar anúncios porém nada ainda que possa ter uma lucro que justifique essa avaliação.

Os fatores que simulam a chegada dessa nova bolha são muito comuns e nos fazem refletir e recuar nesse tipo de investimento. Por outro lado não temos como negar que existe um aumento significativo no mercado da tecnologia e possivelmente essas empresas mencionada podem ter um crescimento monstruoso em seus faturamentos, como o próprio Facebook, que a cada ano supera suas expectativas em torno de seu lucro.

De qualquer maneira, fiquem atentos ao crescimento dessa nova Bolha 2.0

Até a próxima.

Fontes:
http://www1.folha.uol.com.br/folha/informatica/ult124u19223.shtml
http://info.abril.com.br/noticias/blogs/trending-blog/mercado/linkedin-denuncia-a-nova-bolha-da-internet-2/
http://blogs.estadao.com.br/link/acoes-do-linkedin-formaram-uma-bolha/
http://oxenti.com/www/2011/01/10/facebook-uma-nova-bolha-na-internet/
http://www.midiatismo.com.br/comunicacao-digital/venda-do-twitter-e-a-nova-bolha-da-internet

Google+, já sabe como usar essa nova rede social ?

4, julho 2011   •   (Não há comentários)   •   Autor: Thiago Dieb

Semana passada tivemos o lançamento da nova Rede Social do Google chamada de Google+, pronunciada, Google Plus. Pra quem já está utilizando a nova rede social, pode se deparar com novos recursos, alguns bem diferentes em comparação com outras redes sociais. Por esse motivo pretendo listar o que o Google+ nos oferece.

Círculos

Muito fácil de entender, essa funcionalidade foi baseada em falhas encontradas no recurso de grupos do Facebook. Você colocar seus contatos em grupos chamados de Círculos de maneira muito rápida e fácil. Detalhe, os contatos não ficam sabendo em qual grupo você os adicionar, só que foi adicionado.

Stream

Como não poderia faltar a funcionalidade de compartilhamento de conteúdo, é bem parecido com o mural do Facebook. Aqui você pode compartilhar textos, fotos e vídeos. Além disso você pode publicar um conteúdo a um círculo específico e também desativar comentários sobre sua publicação. Outro aspecto bacana sobre esse recurso é a possibilidade de filtrar o Stream dos seus contatos.

Sparks

Esse recurso aparenta ser um teste, pois não mostra grande maneira de sociabilização. O objetivo é você ficar sabendo de novidades sobre alguns assuntos de seu interesse, exemplo: Ciclismo, Receitas Android e Robótica. Pelo visto aparenta se uma assinatura de feed, só isso.

Hangout

Creio que seja o recurso mais bacana do Google+, ele permite fazer videoconferência entre seus contatos, utilizando webcam e microfone.
Ainda pode fazer chamada para uma certo círculo e restringir o compartilhamento de conteúdo. Tem um detalhe, será necessário instalar um plugin em seu computador.





Chat

Nada demais, uma função padrão. Bate-papo com seus contatos, mesmo recurso disponível no Gmail, Orkut e no próprio Facebook.

Notificações

Creio que seja uma cópia do Facebook, mas tem uma diferença, o local, o Google+ colocou a parte de notificações na parte superior direita ao invés da esquerda como é no Facebook.

Fotos

Com certeza não poderia faltar o álbum de fotos. No Google+ o recurso é bem social, quando você acessa o link de fotos em seu perfil ele vai ilustrar as últimas imagens de seus contatos. Também deixei bem destacado o tipo de divisão de fotos em sua lateral esquerda, criando assim um agrupamento como: Fotos de seus círculos, Fotos do seu celular, Fotos com você e Seus álbuns.
A parte de visualização não mudou, a ilustração das imagens são feitas em miniaturas ou em tamanho normal como o do Facebook e Orkut, permitindo comentários.

Os internautas que ainda não estão usufruindo da novidade não precisam se desesperar, os convites para a nova rede social estão sendo distribuídos aos poucos e com certeza chegará sua vez!

Até a próxima.