PHP for Coder

Prazo é o que o contratante adora exigir e o programador odeio dar. Acho que depois da elicitação de requisitos, estibular prazo é a tarefa mais difícil na Engenharia de Software.
Mas porque é tão difícil dar um prazo? Simplesmente porque não sabemos ao certo o que temos que fazer e/ou quanto tempo levamos para realizar o trabalho.
Se o profissional não for precavido prazos podem se tornar coleira ou chicote para faze-lo trabalhar como um louco. Prazo também é como a história da corrente, sempre estoura no elo mais fraco, ou seja, o desenvolvedor.
E como lidar com este problema? Bem, dar prazos exatos é muito dificil, pra não dizer impossível, em desenvolvimento de software. Mas com experiencia passamos a aproximar cada vez mais as estimativas do valor real. O que aprendemos na verdade é lidar com especificações mal feitas e deixamos de aceitar requisitos de software ambiguos, inconsistentes, incompletos, e etc. Aprendemos a ler uma especificação de requisitos e sacar que ela não define bem o escopo nem oferece o subsidio necessário para desenvolver o software. Nestes casos o pior pecado que um programador pode cometer é presumir as coisas. Nossa cabeça nunca pensa como a do cliente e este tempo perdido com uma presunção errada não será pago.
Outra coisa que aprendemos a fazer é calcular o tempo médio de desenvolvimento de algumas rotinas base. Eu por exemplo sei quanto tempo eu levo para fazer um CRUD (Create, Retrieve, Updade e Delete) do zero com as diferentes frameworks e com determinados números de campos no banco de dados. Também sei quanto tempo eu levo para montar um front-end simples, quanto tempo levo para trabalhar com upload de arquivos e imagens, e etc. Este ‘time’ a gente pega com o tempo ou com mensuração. Mensurar estas coisas é o ideal. Sente no computador e cronometre o tempo que você leva para iniciar uma determinada rotina até termina-la, contando o tempo de pesquisas e tudo mais (só na vale ficar no MSN nem no Orkut). Depois jogue uns 30% de acrescimo.
Para facilitar, divida as rotinas em blocos menores de desenvolvimento. Por exemplo um cadastro de usuários poderia ser dividido em criação/consistencia do formulário front-end, depois a consistencia server-side, a persistencia do banco de dados e o tratamento dos erros. Cada etapa pode levar um X horas.
Outros comportamentos podem auxiliar não na estimativa, mas na preservação dela. Por exemplo, negar ou registrar interrupções no seu trabalho para realizar outras tarefas, registrar ou informar sempre que determinada rotina depender de informações do cliente, registrar ou negar mudanças de escopo, e ter em mente que você nunca vai trabalhar 8 horas por dia 5 dias por semana no código e que nem tudo depende de você, servidores podem sair do ar, HDs podem queimar, pode ter feriados na semana, reuniões gerenciais, etc.
Então, quando alguém lhe pedir um prazo da próxima vez, não dê a resposta no ato, a menos que esteja bastante confiante. Peça alguns dias e reflita sobre o caso. Seu chefe pode reclamar, mas diga que você não incorre em erro pedindo mais tempo para avaliar, mas pode comprometer a imagem da empresa estourando um prazo mal dado.

A maneira mais simples de evitar ataques por XSS é não permitir que códigos HTML não desejados sejam interpretados em suas páginas PHP. Para isto nós temos 3 funções muito úteis: htmlentities, htmlspecialchars e strip_tags

Toda vez que uma informação vier de fontes externas não confiáveis é importante codifica-las usando htmlentities ou htmlspecialchars, que transformam os caracteres especiais em código ASCII, ou usar strip_tags que retira as tags HTML.

Exemplo:

<?php
$new = htmlspecialchars(”<a href=’test’>Test</a>”, ENT_QUOTES);
echo $new; // &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;
?>

<?php
$str = “A ‘quote’ is <b>bold</b>”;

// Outputs: A ‘quote’ is &lt;b&gt;bold&lt;/b&gt;
echo htmlentities($str);

// Outputs: A &#039;quote&#039; is &lt;b&gt;bold&lt;/b&gt;
echo htmlentities($str, ENT_QUOTES);
?>

<?php
$text = ‘<p>Test paragraph.</p><!– Comment –> <a href=”#fragment”>Other text</a>’;
echo strip_tags($text);
echo “\n”;

// Allow <p> and <a>
echo strip_tags($text, ‘<p><a>’);
//Test paragraph. Other text
//<p>Test paragraph.</p> <a href=”#fragment”>Other text</a>

?>

Mas as vezes queremos deixar passar algumas tags que não possuem código malicioso. Esta classe abaixo foi retirada do framework CodeIgniter e além de validar as informações vindas de GET, POST e COOKIE, ainda faz aquela validação $x = (isset($_POST/$_GET['x']))? …. É muito simples de usar. Salve o código num arquivo .php, por exemplo, validation.php, faça um include da classe em seus códigos e instancie a classe CI_Input.

Baixar CI_Input

<?php

require_once(’validation.php’);

$validation = new CI_Input();

//Se vier um parâmetro via GET: www.seudominio.com?x=valor

echo $validation->get(’x');

//imprime ‘valor’;

//Se vier parâmetro via POST: $_POST['name']

echo $validation->post(’name’);

//Se vier via COOKIE: $_COOKIE['info']

echo $validation->cookie(’info’);

?>

Mais informações

XSS – Cross-Site Scripting

Cross-site scripting (XSS) é um tipo de vulnerabilidade de segurança tipicamente encontrada em aplicações Web as quais permitem “injeções de código” por usuários web maliciosos dentro de páginas vistas por outros usuários. Exemplos de tais códigos incluem scritps client-side.

A expressão “cross-site scripting” originou do fato que sites maliciosos podiam “carregar” outros sites dentro de frames ou janelas e então usar javascript para ler ou escrever informações neles. A definição gradualmente mudou para significar a injeção de HTML e javascript dentro de páginas Web, o que causou certa confusão visto que o nome não reflete a última definição. Também já foi chamado de CSS, mas para evitar confução com Cascading Style Sheets estaterminologia foi depreciada.

XSS ultrapassou buffer overflow para tornar-se  a vulnerabilidade mais comum reportada publicamente nos dias atuais, e pelo menos 68% dos websites são suscetíveis a ataques XSS de seus usuários.

Ataques XSS são escritos em uma linguagem de script client-side, mais freqüentemente um dialeto de ECMAScript (por exemplo JavaScript, JScript), algumas vezes incluem alguma linguagem de marcação como HTML ou XHTML.

Há três tipos de vulnerabilidades XSS : Não-persistente, Persistente e DOM-based (que pode ser tanto persistente como não-persistente);

Não-Persistente

A abertura para Cross-Site scripting não-persistente é também chamada como vulnerabilidade refletida, e é de longe o tipo mais comum. Esta abertura aparece quando informações fornecidas por um cliente Web é usada imediatamente pelo script Server-side para gerar uma página de resultado. Se informações não validadas fornecidas pelo usuário são incluídas em uma página sem codificação HTML, isto permitirá códigos client-side serem injetados dentro de páginas dinâmicas.

Persistente

A vulnerabilidade XSS persistente é também chamada como uma vulnerabilidade armazenada ou de segunda ordem, e permite o mais poderoso tipo de ataque. Este tipo de vulnerabilidade XSS existe quando informações fornecidas para uma aplicação Web por um usuário é primeiro persistida dentro do servidor (em um banco de dados, filesystem, ou outro tipo de local), e mais tarde mostrada para usuários em páginas Web sem serem codificadas usando HTML entities. Um exemplo clássico disto é com quadro de mensagem ou fóruns online, onde usuários são autorizados a postar mensagens formatadas com HTML para outros usuários lerem;

Dom-Based

A vulnerabilidade DOM-based , também chamada como cross-site scripting local, é baseada sobre o Document Object Model (DOM). Com as vulnerabilidades cross-site scripting DOM-based, o problema existe dentro do próprio script client-side da página. Por exemplo, se uma parte do javascript acessa um parâmetro de uma requisição HTTP e usa esta informação para escrever algum HTML na própria página, e esta informação não é codificada usando HTML entities, uma abertura para XSS será criada, já que esta informação escrita pode ser re-interpretada pelo browser como HTML que pode incluir scripts client-side adicionais.

Cenários de ataques

Atacantes tentando explorar vulnerabilidades cross-site scripting podem aproveitar cada classe de vulnerabilidade diferentemente. Para cada classe, um ataque específico será descrito aqui, mas é óbvio que existem muito mais.

Ataque de persistência simples

1. Darth posta uma mensagem em uma rede social;
2. Quando Alice lê a mensagem, o XSS de Darth rouba o cookie de Alice;
3. Darth pode tomar a sessão de Alice e personificar Alice;

Ataque DOM-based

1. Darth envia a URL de um site construído maliciosamente para Alice, usando e-mail ou outro mecanismo;
2. Alice clica sobre o link;
3. O javascript do site malicioso abre uma página HTML vulnerável instalada localmente dentro do computador da Alice;
4. A página HTML vulnerável contem javascript que executa localmente no computador da Alice;
5. O script malicioso de Darth agora pode rodar comandos com os privilégios que Alice detém sobre seu próprio computador;

Ataque Não-persistente

1. Alice freqüentemente visita um site especifico, que é hospedado por Bob. O site do Bob permite Alice logar-se com um par login e senha e armazena informações particulares, tais como de pagamento;
2. Darth observa que o site de Bob contém uma vulnerabilidade de XSS não-persistente;
3. Darth cria uma URL para explorar a vulnerabilidade e envia para Alice um e-mail, encorajando ela a clicar sobre o link para a URL;
4. Alice visita a URL fornecida por Darth enquanto esta logada dentro do site de Bob;
5. O script malicioso embutido na URL executa no browser de Alice, como se ele viesse diretamente do servidor de Bob. O script pode ser usado para enviar o cookie de sessão de Alice para Darth. Darth pode então usá-lo para roubar as informações particulares disponíveis de Alice (dados de autenticação, informações de pagamento, etc) sem o conhecimento de Alice;

Prevenção

Evitar XSS requer ações por parte do usuário. Defesa contra XSS também é assunto para desenvolvedores de conteúdo e aplicação Web, além de fabricantes de navegadores. Usuários podem desabilitar os scripts, diversas boas práticas existem para desenvolvedores, aplicações Web podem ser testadas e revistas antes de serem lançadas, e alguns browser hoje implementam um pouco de controle de segurança;

Este post tentou apresentar uma visão geral sobre este tipo de ataque, o conteúdo foi retirado daqui. Nos próximos posts entrarei em detalhes em como nós, desenvolvedores, podemos nos prevenir e como podemos testar nossas aplicações, fornecendo vários exemplos de ataques já conhecidos.

Este teste não pretende demonstrar qual é a melhor documentação, mas pode servir como indicativo para a complexidade da curva de aprendizado de uma destas linguagens.

É um teste simples. A metodologia não é muito cientifica, mas vou tentar não ser parcial. Escolherei um comando em cada linguagem, provavelmente algum correspondente ao ‘echo’ do PHP e partirei do Google. Farei uma busca pelo nome da linguagem, em seguida buscarei entre os resultados o site oficial e digitarei na caixa de busca o nome do comando.

Vamos lá:

PHP – echo

1. Google: PHP – Primeiro site da lista é a Wikipedia, é óbvio que não é o site oficial. O segundo é o php.net, é possível que seja o oficial, logo vou entrar.
2. Busca: Achei o botão de busca, digitei ‘echo’ e obtive o resultado que esperava, a definição do comando, em português, de forma objetiva.
3. 

Java – print (System.out.print)

1. Google: Java – O primeiro site da lista é o java.com/pt_BR, possui grandes chances de ser o site oficial, então entro nele;
2. Busca: Digitei print no campo de busca e recebi a página “Como posso obter uma captura de tela no Microsoft Windows?”
3. Google: Java – Obviamente o resultado anterior não era o que esperava. Como sou um programador esperto, deduzi que não acharia a documentação do Java em java.com, então voltei para o Google digitei novamente java e fui para o quarto link do resultado java.sun.com
4. Busca: Digitei print e mandei buscar. O site me retornou 130.000 resultados. Dando uma olhada na primeira página de resultados, com 10 itens, não achei nenhum que fosse parecido com System.out.print, então vou tentar outra abordagem. Busquei por ‘out’ e no oitavo item da página de resposta apareceu um ‘System’, acho que encontrei. Clico nele e o que me aparece é isto:
5. Busca: Não era exatamente o que eu queria, mas talvez aqui possa achar algo. Dou umas giradas no scroll do mouse e desisto de procurar manualmente, clico em Ctrl+F e busco por ‘print’. Encontro finalmente um print, mas é println. Resolvo clicar num link perto que me parece bastante promissor “PrintStream.println()”. Já dá pra entender o que print deve fazer, mas quero chegar na definição do método. Dentro do PrintStream.println() acho finalmente o print depois de uns giros do scroll. Acho que é o mesmo que System.out.print, apesar de não estar explicito;
6. 

.Net C# – WriteLine (System.Console.WriteLine)

1. Google: C# .Net – Primeiro resultado no google é o msdn.microsoft.com, parece-me promissor então entro nele.
2. Busca: WriteLine – Assim que digitei WriteLine abriu-se uma lista de sugestões abaixo da caixa de busca e um dos itens era justamento system.console.writeline. Cliquei nele e fui direcionado para uma página de resultados com 50 itens de 22.200 encontrados, felizmente  o primeiro da lista é Console.WriteLine Method (System), parece o que estava procurando.
3. 

Ruby – puts

1. Google: Ruby – O o primeiro resultado da busca é ruby-lang.org/pt, parece-me ser o site oficial.
2. Busca: Digitei puts no campo de busca e esperei, depois de quase um minuto de espera recebi um erro HTTP 500. Tentei de novo. Novamente erro HTTP 500.
3. 

Python – print

1. Google: Python – Achei o site oficial de cara, é o primeiro item da lista de resultados;
2. Busca: Digitei print e mandei buscar. Fiquei assustado porque voltei para o Google. A ferramenta de busca do site é baseada no Google. Achei 13.800 resultados, mas o primeiro da lista é “The print statement”, provavelmente o que procuro. Clico nele e acho sua definição.
3. 

Conclusão

Ter uma boa ferramenta de suporte, com um conteúdo simples, objetivo e acessível pode fazer a diferença durante o aprendizado de uma linguagem. Também pode ser essencial em problemas que demandem recursos pouco usados no dia-dia do programador. São minutos que vão se somando e fazem a curva de aprendizagem ser grande ou o estudo de determinada solução ser demorado.

Quem desenvolve a algum tempo já deve ter se deparado com a dúvida: Qual framework escolher?

Eu conheço 5, que talvez sejam as mais utilizadas. São elas a ZendFramework, CakePHP, Symphony, PradoPHP e CodeIgniter. Destas, já tive a oportunidade de usar em projetos profissionais a CakePHP, ZendFramework e CodeIgniter. As outras eu estudei durante alguns projetos.

Existe um fator importante neste assunto que é afinidade. Além de todas as características técnicas que diferem uma da outra ou que as tornam melhores ou piores em algumas situações, a afinidade costuma ser um ponto decisivo para a escolha. Afinidade que digo é o quanto você se sente a vontade usando a arquitetura que a framework oferece, os seus padrões e a sua documentação.

Depois de usar estas frameworks acabei optando pela CodeIgniter. Além da afinidade que criei com ela, gostei muito de sua simplicidade. Sua curva de aprendizagem é pequena, rapidamente se aprende a desenvolver código robusto com produtividade. Sua documentação é bem organizada e traduzida para o português (apesar de eu preferir a versão em inglês). Ela  não exige mudanças no servidor Web ou módulos adicionais no PHP. Não lhe obriga a seguir muitos padrões nem possui muitos arquivos de configuração. É leve, rápida e extremamente flexível.

Muita gente pergunta sobre a ZendFramework. A Zend, empresa por trás do PHP, esta investindo muito dinheiro e tempo no aperfeiçoamento da tecnologia e na sua divulgação. Uma das suas qualidades esta na quantidade de módulos para acesso a serviços na Internet, como Google, Delicious e Flickr, e na sua integração com outras tecnologias como o Adobe Flash e o LDAP. Mas na minha opinião, o que pesa contra ela é sua complexidade. Ela exige o módulo PDO no PHP, possui uma arquitetura MVC onde o Model só esta tomando forma de umas versões para cá. Não acho a ZendFramework produtiva, me pareceu que a Zend esta querendo flertar com um tipo de filosofia parecida com a do Java. Não que isto seja ruim, mas pessoalmente não gostei.

Contra a CodeIgniter só tem a falta de alguns recursos nativamente, como suporte a SOAP e REST, também há uma classe que controla a sessão baseada em COOKIE (particularmente ruim), mas nada que não possa ser adicionado/mudado com facilidade.

Mas para você poder tomar uma decisão, não fique lendo artigos na Internet. Eles ajudam, com certeza, mas podem ser parciais. As pessoas muitas vezes criticam o que não conhecem direito. Então a melhor forma de escolher uma framework é baixando ela para o seu servidor local e utilizando-a numa aplicação simples, um formulário de cadastro, com opção de edição e exclusão de registros. Teste, leia a documentação, veja como ela trabalha, o quanto ela carrega o servidor e principalmente se é possível para você criar afinidade com ela. Pode ser ruim no começo, você irá gastar algumas horas, ou dias, fazendo testes. Mas irá me agradecer no futuro quando estiver no meio do desenvolvimento de um software e perceber que escolheu uma ótima ferramenta para lhe apoiar.

Gostaria de compartilhar um pouco do que eu já vivenciei no mercado trabalhando com PHP. Estas informações não são “padrões” ou “verdades” do mercado de forma alguma.

Salário é uma dúvida comum, principalmente para quem esta começando na profissão e tem pouca experiência. Salário de um profissional, qualquer que seja, varia de acordo com uma série de fatores. Na minha opinião os mais significativos para um programador PHP são: Competência, Localização e Tamanho.

• Competência:  Numa entrevista de emprego, geralmente é medida pelo tempo em que trabalha na área, pela quantidade de empresas que já passou, pelas funções que exerceu em cada emprego, pelo seu nível de formação acadêmica e conhecimentos adicionais de processos, metodologias, etc.
• Localização: Cidades do interior pagam menos na maioria dos casos, cidades cujo foco seja industria ou comércio também não tem boas perspectivas de salários altos. Isto se deve mais por causa do tamanho do mercado de serviços delas. As capitais costumam ter um mercado muito maior de serviços o que aumenta a demanda por profissionais da área e faz subir seus salários;
• Tamanho: Neste caso é o tamanho da empresa que esta trabalhando ou pretende trabalhar. Empresas maiores possuem melhores condições de oferecer salários bons, mas isto não é verdade sempre. Além do tamanho depende de quão importante é seu trabalho lá dentro.  Logo, algumas empresas de médio e pequeno porte podem oferecer salários tão bons e até melhores que grandes empresas, mas não é a regra.

Trabalhando com PHP eu já vi CLT variando de R$400 (interior de São Paulo, profissional junior) à R$4500 (Capital, profissional sênior) e PJ/Freelancer de R$4 à R$30 por hora. Talvez existam pessoas ganhando mais, talvez ganhando menos.

Interessante ver também como variam o valor/hora das empresas que trabalham com PHP. Já vi empresas cobrando de R$90 à R$50 por hora na capital, no interior já vi até a R$25 por hora. Quanto maior a empresa, mais caro será seu valor hora, são mais impostos, mais funcionários e mais propaganda.

Para saber exatamente quanto você precisa ganhar é necessário fazer alguns calculos e não pesquisar valores no mercado. Tanto profissionais quanto empresas precisam saber quanto vale seu “custo de vida”. Aluguel, telefone, água, seguro saúde, transporte, refeições são alguns dos custos que deve conhecer. Some tudo o que você gasta, depois adicione quanto você gostaria de “lucrar” (ou você quer trabalhar só para pagar as contas?), por fim adicione a carga tributária (INSS, ISS, etc…). Quando chegar a um valor divida por 160 horas e saberá quanto deverá ser seu valor/hora para viver como quer.