A versão atual do PHP é a 5.3 mas o núcleo de desenvolvimento da linguagem já trabalha na versão 6. Da versão 4 para a 5 da plataforma ocorreram modificações profundas, tanto que muitos scripts deixaram de funcionar. Isso ocasionou uma série de transtornos para desenvolvedores, prestadores de serviço e usuários da linguagem. E, principalmente, um atraso muito grande na adoção da versão 5. É comum, quando se contrata um servidor de hospedagem, encontrar suporte ao PHP4 e ao PHP5 (este último normalmente em suporte Beta) pois existe uma preocupação dos prestadores de serviço em suportar os scripts mais antigos, que ainda são maioria.

A versão 6, que gera muitas discussões nas listas de desenvolvimento oficiais do PHP, pode retirar muitas características da plataforma em uma operação de enxugamento para torná-la mais prática de ser usada. O problema, novamente, é a compatibilidade legada. Com as características que devem ser abandonadas muitos scripts escritos para as versões 4 e 5 podem, outra vez, parar de funcionar. Enquanto a equipe que desenvolve o PHP está obviamente preocupada em tornar a linguagem mais profissional fica a dúvida se essas modificações constantes podem afetar a credibilidade e a adoção do PHP como ferramenta de desenvolvimento.

A notícia de que mudanças no PHP6 poderiam criar incompatibilidade com o legado das versões 4 e 5 surgiu de um dos desenvolvedores da linguagem, Derick Rethans. Ele afirmou publicamente que, entre outras coisas, o PHP6 dará suporte ao Unicode. Isso tornaria as aplicações escritas em PHP mais internacionalizáveis, aumentando a flexibilidade do que pode ser escrito com a plataforma. Entretanto, ao contrário dessa modificação, as outras propostas retiram características que, quando usadas por scripts de outras versões, podem ocasionar em erros de execução paralisando os serviços. Entre o que está planejado para mudar no PHP6 aparece:

1- Remoção completa de register_globals Desde a versão 4 do PHP fala-se em abandonar essa característica assim programadores mais experientes já produzem código sem usá-la. Ainda que aplicativos escritos por desenvolvedores menos preocupados possam deixar de rodar na versão 6 o impacto disso dever ser pequeno sobre os aplicativos profissionais.

2- Remoção de magic_quotes_* Boa parte dos programadores PHP sequer as usa e seu abandono já era discutido há muito tempo. Deve ocasionar pouco impacto sobre a plataforma.

3- O PHP6 deve incluir um mecanismo para que os desenvolvedores desliguem opções do ambiente que o administrador do site tenha deixado ligadas por padrão, e vice-versa. Aqui vemos luzes vermelhas, pois os usuários não deveriam poder alterar opções do sistema sem o uso de um mecanismo que limite o que pode ser alterado, nos moldes do Apache. Não há indicação de que esse sistema vá existir o que pode gerar a situação incômoda do desenvolvedor administrar mais o sistema do que o próprio administrador. É apenas uma suspeita de nossa equipe que essa característica vá trazer problemas, mas a possibilidade está em aberto.

4- Remoção do safe_mode e foco no uso de open_basedir O open_basedir é mais restritivo que o safe_mode e por isso permite uma flexibilidade maior, entretanto em servidores que armazenem diversos sites distintos (que é o caso mais comum na internet) o compartilhamento de scripts pode tornar-se problemático. Ponto para a segurança, mas os administradores de sistemas com PHP6 terão que suar um pouco mais a camisa.

5- Remoção de tudo que foi marcado como desatualizado desde o PHP 3/4 Muitos scripts, principalmente os mais “antigos” vão parar de funcionar definitivamente, exigindo que o código seja revisado e reescrito. Somando à isso o fato de querer aproveitar as novas funcionalidades vai haver muita gente decidindo que a migração não vale a pena ou que é melhor escrever a aplicação do zero do que ficar tapando buracos em código legado.

6-Tornar os identificadores sensíveis à caixa do texto Aqui haverá um problema para desenvolvedores de Windows, que podem não estar acostumados com essa característica já existente em diversas outras linguagens, como o C/C++, por exemplo. Desenvolvedores UNIX não sentirão diferença pois nessa classe de sistema operacional a sensibilidade à caixa é padrão. Nesse aspecto os hábitos antes alimentados pelo PHP podem exigir adaptação de parte dos desenvolvedores. Além disso, scripts escritos com pouco cuidado podem parar de funcionar.

7- Remoção de vários aliases de funções Scripts que fazem uso desses aliases não irão funcionar na nova versão do PHP. É uma simplificação boa, já que é melhor ter apenas um nome para cada coisa, e vai reduzir a complexidade do desenvolvimento. Mas outra vez os desenvolvedores terão que optar entre permanecer com uma versão antiga da linguagem ou trabalhar para modificar o código existente.

Essas são as principais modificações propostas para a versão 6 do PHP, que irão exigir cuidado dos profissionais que decidam pelo upgrade em seus servidores. Entretanto não são as únicas, mmuitas outras propostas e suas conseqüências podem ser observadas aqui. Certamente elas devem atrasar a adoção da nova versão, como aconteceu com o PHP5. Na versão 5 muito foi feito no sentido de tornar a linguagem orientada à objetos. Isso permite que os programadores escrevam aplicações mais complexas e maduras, mas as incompatibilidades com o legado das versões 3 e 4 do PHP foram um grande obstáculo para a adoção do PHP5. De tal sorte que o PHP5 ainda não tornou-se o padrão para as aplicações PHP no mundo, havendo uma forte presença do PHP4 no mercado.

O fato do cPanel demorar cerca de 6 meses para retirar do estágio Beta qualquer modificação na plataforma PHP irá atrasar a migração de boa parte dos usuários. Muitos scripts livres e gratuitos que são usados por uma parte grande do mercado, cujos administradores não são programadores e usam código de terceiros, podem demorar para serem migrados para o PHP6 paralisando ainda mais o movimento de migração para a nova versão. As mudanças da versão 4 para a 5 obrigaram muitos desenvolvedores a reescrever seus scripts do zero e as quebras de suporte legado propostas para a versão 6 irão deixar muitos programadores descontentes.

Ainda que os aplicativos desenvolvidos para o PHP4 que não tenham recebido adaptação para a versão 5 possam ser reescritos ou adaptados diretamente para a versão 6 é impossível negar que os programadores ficarão desconfiados. Começar os trabalhos para levar seus scripts para a versão 6 valerá a pena? Haverá outra quebra de suporte legado em uma futura versão 7? Essas perguntas agora encontram-se atrás de uma cortina de fumaça e devem levar algum tempo para serem respondidas. Talvez o mercado só comece a migrar realmente para o PHP6 quando o grupo que desenvolve a linguagem comprometer-se a manter suporte para uma nova versão. Podem se passar 2 ou 3 anos até que uma migração forte para a nova versão 6 seja verificada no mercado e até lá provavelmente poucos decidirão investir tempo e dinheiro para adaptar scripts antigos para a versão 5, dando uma sobrevida inusitada ao PHP4.

Essas mudanças na plataforma PHP que causam falta de compatibilidade com aplicações legadas são reflexos de um projeto pouco estruturado. A mudança de foco do PHP, desde seu nascimento até hoje, também contribuiram para que mudanças tão profundas fossem levadas à cabo. E é indiscutível que esse tipo de acontecimento abala o respeito que o mercado tem por dada solução. Essas guinadas bruscas demandam retrabalho de profissionais cuja hora de serviço não é das mais baratas. Produtos de empresas consolidadas, como Microsoft, Oracle, e outras, raramente colocam seus clientes em posições tão desconfortáveis em tão curto espaço de tempo. Esse panorama deixará muitos tomadores de decisão avessos ao PHP ainda que as mudanças efetuadas sejam reconhecidamente necessárias e bem vindas pelos profissionais técnicos.

Em uma análise mais profunda esse tipo de situação pode servir para o pessoal do Software Livre repensar um pouco mais a forma como grandes projetos é manejada. Não são raros os casos de projetos livres que obrigaram seus usuários a passarem pelo mesmo tipo de situação que o PHP.

Fonte: Meiobit

Então é necessário simular estas tags com a ajuda de hacks em CSS e JavaScript. Basicamente para estas tags, a única coisa que você precisa fazer é setá-las como display:block. Veja abaixo um exemplo de css hack para aticle, footer, section e header:

<style>
article, footer, section, header {
display:block
}
</style>

Simples assim. Primeiramente, nós adicionamos as tags que não são suportadas pelos navegadores, então setamos os atributos display para block.

Ok, o hack de CSS é realmente bem simples, mas infelizmente não funciona em todos os navegadores, como por exemplo o Internet Explorer. Para solucionar este problema também no IE, precisamos criar também um hack em JavaScript.

Vamos ao código:

<script type="text/javascript">
  (function () {
    var elements = [
      'article', 'content', 'footer', 'header', 'nav', 'section'
    ];
 
    for (var i = 0, j = elements.length; i < j; i++) {
      document.createElement(elements[i]);
    }
  })();
 
</script>

Note que o código acima deve ser adicionado logo abaixo às tags <link> e <style>. Caso contrário, não irá funcionar.

Basicamente é isto, agora você pode utilizar o HTML5 em todos os principais browsers.

Caso você não tenha sido abduzido e ter ficado os últimos 2 anos fora da Terra, sabe que a Microsoft e Yahoo, estão namorando a um bom tempo uma aquisição, fusão ou parceria. E depois deste tempo todo, a parceria finalmente saiu.

Na última quarta-feira a Microsoft anunciou que fechou um acordo com o Yahoo, onde o Bing se tornaria o buscador padrão de todas as páginas do Yahoo e filiados. Mais precisamente o acordo inclui os seguintes termos:

• Duração de 10 anos, podendo ser prorrogado por mais 10.
• A Microsfot terá acesso a tecnologia do Yahoo Search enquanto o acordo for vigente, e poderá usar quaisquer tecnologias no Bing.
• O Bing será o único algoritmo de search e anúncios dos sites do Yahoo.
• Os Links patrocinados serão gerenciados pelo Microsoft AdCenter.
• Cada empresa manterá usa marca e equipes atuando separadamente.
• A Microsft destinará parte da receita dos anúncios patrocinados ao Yahoo, sendo que nos primeiros 5 anos este percentual será de 88%.
• O acordo protege a privacidade do consumidor, limitando os dados compartilhados entre as empresas ao mínimo necessário para operar e melhorar a plataforma.

Com este acordo muito se discute, sobre o que irá acontecer com mercado de busca. Como pode demorar até 24 meses para que a integração seja concluída, não veremos seus resultados de imediato, mas alguns analistas apresentaram suas ideias:

• Vale investir em SEO no Bing, pois suas buscas são mais ricas e organizadas, o que deve atrair os usuários.
• Apesar do pequeno market share (atualmente em 8% nos EUA, pode chegar a 28% com a parceira), o Bing gera mais conversões e cliques nos anúncios.
• Com a parceria e o aumento de market share, o Bing pode atrair mais spam, o que pode afetar usa relevância.
• Espera-se que muitos anunciantes comecem a utilizar o Bing.
• Agora todos começam a explorar as ferramentas de análise SEO do Bing (Bing Webmaster Tools)
• O registro de negócios locais no diretório Bing se torna importante já que o buscador destaca as listas locais em suas buscas.
• O Bing passa a contar com a valiosa base de dados do Yahoo para customizar seu serviço por segmento-alvo e tipo de usuário.
• Muitos usuários e clientes do Yahoo! nos EUA temem que a empresa desative recursos de busca como diretório, Delicious, maps, etc.
• Como o Yahoo! manterá certa independência, especula-se que a sua busca siga critérios um pouco diferentes das buscas feitas via Bing.

Se isto realmente irá acontecer não sabemos, mas a dica do momento é preste mais atenção ao Bing e veja no que ele pode ser útil para você.

Até a próxima!

Como todos já devem estar cansados de saber, o futuro da internet é a Web Semântica. O Google já tem pretensões e planos de criar uma busca mais semântica, na verdade ele já fez algumas coisas neste sentido. E para não ficar atrás a Microsoft lançou o “bing” (não foi nós que escolhemos este nome XD), seu novo buscador que já está disponível desde ontem. E o Stephen Wolfram lançou no mês passado o novo buscador Wolfram|Alpha, onde o intuito não é destronar o Google, mas criar um novo conceito em busca.

Com todos estes investimentos, não estamos errados em prever que o futuro da internet é a Web Semântica. E não foi só nos que pensamos assim (Obvio!), desde 2004 a W3C, criou com algumas empresas, como Apple, Mozilla, Opera, e vários desenvolvedores, o WHATWG (Web Hypertext Application technology Working Group). O intuito do WHATWG é criar as especificações do HTML 5, já que o HTML 4 estava ultrapassado, por que sua última versão é datada de 1999.

De 2004 até hoje já saíram alguns rascunhos do HTML 5, o que se pode notar é que ele será focado na semântica, onde todas as tags terão significados, não será necessário criar vários divs, por que teremos tags para cada elemento da página. Para entender melhor o que estamos dizendo aqui, tem um exemplo que ilustra as diferenças entre o html4 e o html 5.

Com as tags mais intuitivas, também é esperado que o desenvolvimento web se torne mais simples e rápido. Ainda é cedo para vermos todo o potencial deste novo HTML, mas vamos ficar atentos, qualquer coisa nova lhe avisamos.

Até a próxima!

Como no C# não existe uma função para fazer isto, é necessário criar um método que irá capitalizar nossas strings, ou seja, irá converter para maiúscula os primeiros caracteres de cada palavra. Pode ser usado em nome de formulários, por exemplo.

Primeiro método

private string CapitalizeWords(string value)
{
   if (value == null) throw new ArgumentNullException("value");
   if (value.Length == 0) return value;
 
   System.Text.StringBuilder result = new System.Text.StringBuilder(value);
   result[0] = char.ToUpper(result[0]);
 
   for (int i = 1; i < result.Length; ++i)
   {
      if (char.IsWhiteSpace(result[i - 1]))
      {
         result[i] = char.ToUpper(result[i]);
      }
   }
   return result.ToString();
}

Segundo método

private string CapitalizeWordsCulture(string value)
{
   return System.Globalization.CultureInfo.CurrentCulture.TextInfo.ToTitleCase(value);
}

Os dois métodos fazem exatamente a mesma coisa, sendo que o segundo método é melhor por ser menor (rimou =).

Bom proveito e até a próxima!

Para quem não sabe , a função header do PHP envia e altera informações do header http do browser.

Vamos ao tutorial:

1 – O header do http permite enviar varias informações para o browser, como um redirecionamento da pagina:

<?php
header("Location: http://www.treinaweb.com.br/blog");
?>

Neste caso o browser será redirecionado assim que começar o carregamento da pagina. É recomendado sempre utilizar urls completas, porque alguns browsers (antigos) não suportam urls relativas.

2 – Também é possível mudar o content type do documento.

<?php
header("Content-Type: text/css");
?>

Agora você pode apontar para o arquivo css.php, como se fosse um arquivo css. Com isto é possível criar dinamicamente arquivos css, sendo útil ao projetar css para funcionar em qualquer browser e resolução.

3 – É possível forçar o browser a exibir a janela de download e ter um nome recomendado para o arquivo.

<?php
header("Content-Type: image/jpeg");
header("Content-Disposition: attachment; filename=imagem.jpg");
?>

Com isto o browser mostrará a janela de download, com o nome do arquivo sendo imagem.jpg, independente do nome do arquivo php.

4 – Você também pode enviar erros específicos ao browser.

<?php
header("HTTP/1.0 404 Not Found");
?>

É importante não esquecer as diferentes mensagens de erro e o que elas significam.

5 – Finalizando, gostaríamos de sugerir, que sempre utilize o exit para ter certeza que nada depois do código será executado, a menos que o código seja utilizado para trazer uma imagem ou informações necessárias para o arquivo.

<?php
header("Location: http://www.treinaweb.com.br/blog");
exit;
?>

Se você quiser se aprofundar mais na função header, ou estes exemplos não atendem suas necessidades, sugerimos que leia documentação oficial e na integra da função, que pode ser encontrada aqui.

Até a próxima!

Basta criar um arquivo html com o nome de app_offline.htm com uma mensagem qualquer de manutenção no diretório raiz do site e pronto!

A presença deste arquivo fará com que o IIS entenda que para toda requisição realizada, seja exibido esse arquivo, ou seja, não é necessário parar o serviço web ou remover qualquer arquivo.

Pode parecer o contrário, mas este não é um serviço do servidor web IIS, é realmente mais uma facilidade do ASP.NET (versão 2 ou superior).

Até a próxima!

É possível verificar que as aplicações feitas em Flash oferecem ao usuário uma experiência muito mais robusta, na qual a produtividade é envolvida pela facilidade de uso e interatividade em tempo real, impossível conseguir isto no HTML. Desenvolver aplicações com o Flash torna-se estranho, no início para alguns programadores, pelo fato do Flash utilizar uma linha do tempo (timeline), o que facilita o trabalho dos designers. Já o Flex remove esta timeline, fornecendo aos programadores um novo caminho de desenvolvimento de RIAs.

Linguagem MXML

Os arquivos desenvolvidos em Flex possuem a extensão MXML, o como o XML do nome sugere é mais uma linguagem de marcação baseada no XML. Para visualizar uma aplicação MXML o usuário faz uma requisição pelo seu servidor, o servidor recebe a requisição, o servidor do Flex compila o arquivo MXML para SWF (formato do Flash), e este será rodado no Flash Player como uma aplicação Flash normal.

Flex SDK

Flex SDK é o compilador em modo caractere do Flex, com ele é possível desenvolver as aplicações em Flex, ele é distribuído gratuitamente pela Adobe, e você pode usar qualquer editor de textos para escrever seus códigos.

A Adobe também comercializa o Flex Builder, que é um framework que oferece várias facilidades ao usuário, que está “embutido” em uma suíte de desenvolvimento. A grosso modo podemos comprara-lo ao Delphi, pelas facilidades e os recursos que ambas as suítes possuem, só que o Flex Builder é voltado para o desenvolvimento web.

Nos próximos artigos mostraremos alguns exemplos de aplicações desenvolvidas em Flex.

Até a próxima!

Sem executar, diga-nos: Qual é o resultado dos dois IFs abaixo?

       if ("6 Galinhas" + "4 Patos" == "10 Aves") {
                echo "Expressão Verdadeira!";
       } else {
                echo "Expressão Falsa!";
       }
 
	if ( 0 == "Não Encontrado")
	{
		echo "Expressão Verdadeira';
	}else{
		echo "Expressão Falsa!";
	}

Se dissermos que ambos irão retornar verdadeiro como resultado, você acreditaria? OK, pode testar, não somos muito malucos.

Ainda não acredita? ou acha que não é PHP? Veja a explicação lógica para isto:

No primeiro exemplo, quem programa em PHP deve saber, que o operador ‘+’ é somente para expressões aritméticas (para concatenação, utiliza-se o ‘.’- ponto), então o PHP reconhece o primeiro digito das strings “6 Galinhas”, “4 Patos” e “10 Aves”, converte a string para o tipo inteiro e assim ignorando as palavras e deixando somente os números, resultando em 6 + 4 == 10, sendo assim o resultado será verdadeiro.

Já no segundo caso, o PHP irá reconhecer o número 0 e tentará converter a string “Não encontrado” para o tipo inteiro, pelo fato de não haver número na string a tentativa irá falhar e retornará Falso, como falso em PHP é 0(zero), então a pergunta será se 0(zero) == 0(zero), que também irá retornar verdadeiro.

Pode ser algo simples, mas quem está começando, pode perder alguns minutos até encontrar este “problema”que não ocorreria  em outras linguagens.

Até a próxima!

Se você se surpreendeu com o Chrome Experiments, se prepare porque agora você irá cair pra atrás, pois surgiu uma função para gerar PDFs, isto mesmo, você não ouviu errado. A biblioteca chama-se jsPDF (que original!) e gera PDF em Javascript puro. É um projeto open source, e atualmente só funciona no Firefox 3, Safari (até o do Iphone) e Opera, mas o suporte ao IE está a caminho.

Por enquanto ele gera PDF só com texto, mas o suporte a imagens, links e fontes está previsto nas próximas versões.

Até a próxima!