Próximo de completar 4 anos trabalhando na SWATminha jornada chega a um final. Neste tempo posso garantir que esta foi a melhor e mais incrível experiência profissional que já tive. Comecei a trabalhar na SWAT como um líder de um pequeno grupo e usuários e saio como um palestrante internacional, contribuidor de projetos Open Source e lider de um incrível grupo de usuários.Chegou a hora de mudança, os anos estão se acumulando sobre mim e esta na hora de botar o meu plano de vida de volta nos trilhos. Neste tempo da SWAT as oportunidade que me foram oferecidas me permitiram expandir minha rede de contatos desde os EUA até as Filipinas.

Tive a oportunidade de trabalhar com pessoas incríveis durante meu tempo na SWAT, e aprender com pessoas como o CEO da SWAT, Jacques van Niekerk. Dentro e fora do trabalho conheci pessoas de todas comunidades como a galera da WebCo e as incriveis cabeças do time SWAT Brasil, que me mantiveram acordado e aprendendo.Ao final deste ano, assumo uma nova posição na WEBClusive em Amsterdam, Holanda. Vai ser uma mudança radical, mas uma que eu e minha esposa planejamos e pensamos cuidadosamente antes de decidir. Muito tempo atrás eu e minha esposa decidimos que iríamos passar um tempo fora do Brasil, aproveitar novas culturas, viajar, aprender e expandir nossas vidas profissionais e pessoais, e agora a oportunidade bateu na porta. Este é um momento para mim profissionalmente, de voltar a ser um peixe pequeno e um grande lago, e aprender de novos grandes profissionais. Aproveitar o momento do PHP na Europa onde grandes mudanças do PHP e dos Frameworks estão começando.

Além disso tenho a oportunidade de encontrar e interagir mais com meus colegas da Europa e EUA, aproveitar esta rede de contatos que construi nestes anos. Eu agradeço muito a todos com quem interagi neste tempo em São Paulo, a SWAT pelos incríveis anos de trabalho e a Comunidade PHP do Brasil, que vi crescer e pude contribuir com este crescimento, e é hoje uma comunidade de respeito muito bem conhecida fora do país.

Aos que interessar estarei vendendo muita coisa para a mudança, fiquem de olho por aqui e no meu twitter para novidades. Farei de novembro e inicio de Dezembro meu mês de despedidas, então fique de olho nisso também.

Nota: Porque “de volta ao velho continente”? Fato pouco conhecido, sou cidadão Alemão (por direito não nascimento) e morei 3 anos durante minha infância na Alemanha.

Recentemente tenho esbarrado com alguns artigos que me deixam na dúvida se seus autores realmente entendem o que é o papel de um blog e de artigos técnicos, ou se o foco deles seria menos honrado e apenas uma forma de atrair mais visitas. Sim, falo do que já conhecemos hoje na internet como ‘flame-baits’ ou seja, iscas para discussões (negativas). São geralmente posts polêmicos, sem embasamento, movidos por uma opinião pessoal e carregados de termos clichê e piadinhas. Menos mal se estes posts fossem apenas ferramentas de autores de blogs pessoais, muito pior quando aparecem em grandes “veículos” de comunicação ou sites especializados.

Dois exemplos me passaram pelo browser recentemente, um artigo gringo sobre PHP x Python, cujo embasamento completo era um tirinha XKCD, um pato e um pedaço de código ilegível. O segundo, brazuca, intitulado PHPog, uma questão de design, publicado recentemente na iMasters. O grande centro do artigo é uma comparação entre PHP OO e Java OO, como as coisas deveriam ser feitas no PHP, e a grande reação dos leitores foi a de que certas coisas no PHP são diferentes e isso não é negativo (tem mais, mas vamos resumir assim). O questionamento é válido, e as discussões sobre a implementação de OO do PHP também, porém o artigo vai além disso, usando temos como o POG (programação orientada a gambiarras) para descrever a implementação e outras formas pejorativas de tratar a linguagem e seus programadores.

Neste ponto mora o problema. Ao agredir a linguagem com piadinhas o resultado esperado pelo post não é mais uma discussão séria sobre o assunto, e sim atrair milhares de fãs sedentos por sangue para defender sua linguagem e retribuir palavras não carinhosas ao autor do artigo. Este foi exatamente o resultado de ambos artigos, sim eles tiveram muitas visitas, sim tiveram muitos comentários, mas isso realmente é bom? Compare 1000 visitas de xiitas revoltados com 200 visitas de pessoas querendo mostrar um ponto de vista diferente sobre um assunto, com qual você aprenderá mais? E a imagem de sua empresa/sua pessoa, como ela vai ficar após esse barulho todo? Pra mim os resultados de ambos artigos poderiam ser muito mais instrutivo, foco na discussões técnicas e menos barulho de “extremistas” e “ativistas” além de exaltarem a imagem dos sites envolvidos por iniciarem discussões de alto nível.

Por isso, uso este meu espaço para ponderar sobre o assunto, e tentar mostrar minha opinião sobre o que seria um artigo técnico bem escrito.

Como escrever artigos técnicos melhores?

1. Evite usar tirinhas cômicas. Sim é divertido, e vai “quebrar o gelo”, mas se você precisa quebrar algum gelo, repense suas intenções com o artigo, elas podem já estar erradas.

2. Fuja de palavras polemicas e pejorativas. Evite usar termos como o POG citado acima, se o artigo fosse chamado “Aplicando Design Patterns usando PHP: qual a melhor forma?” a discussão final teria se focado muito mais em discutir as implementações de OO do PHP do que comentários como “Como se POG existisse só no PHP”, ou “< ?php print “Calma galera” ?>” e até “Nunca vi tanta ignorância incorporada em um único texto.”. Você pode discordar da linguagem e de como algo foi implementado, deve!, porém faça isso com o devido respeito e seriedade.

3. Expresse sua opinião, mas deixe isso claro. Cal Evans uma vez falou que um desenvolvedor só pode ser considerado Sênior, se o mesmo souber se expressar, ou seja, escrever artigos e mostrar seu trabalho e seu raciocínio através disso. Porém ele deve saber também defender suas ideias e mais importante ainda, saber quando admitir o erro. Lembre-se disso, sempre ˜haverá opiniões contrárias, as vezes todas corretas em sua forma, mas as vezes você realmente estará errado, saiba aceitar isso. Atualize o post se for o caso.

4. Pesquise. Estude. Pesquise. Escreva. Mesmo que sempre que você for falar de um assunto o artigo não passe de sua interpretação sobre o mesmo, é sempre uma boa ideia se precaver. Portanto pesquise muito sobre o assunto, procure opiniões contrárias e analise de outros pontos de vista. Caso esteja aberto a admitir o erro depois lembre-se das regras acima, elas irão potencializar uma resposta positiva e o aprendizado.

5. Referências == credibilidade. Se o que você quer explicar se baseia em algum material que leu, faça sempre referências ao material, aponte de onde ele veio, isso trará para o seu conteúdo mais relevância e agregará os argumentos do outro autor aos seus.

6. Quantidade não significa Qualidade. Ter 1001 visitas não significa que seu artigo é bom, ou ruim. Artigos polêmicos, ou sem embasamento e agressivos acabam atraindo muitas visitas, pessoas que querem ver pra acreditar, ou deixar um comentário agressivo. Se o seu objetivo é ter muitas visitas isso realmente funciona, porém qual foi a impressão que as pessoas tiveram de você ao sair de lá? Agora um artigo que deveria divulgar seu trabalho e te projetar como profissional, acabou de mudar a opinião de pessoas para não mais te considerar para uma possível vaga.

7. Não critique, compare. Respeite. Muitas vezes vejo artigos escritos apenas para debochar ou ridicularizar algo, ou a forma como alguém fez algo. Quer fazer algo construtivo? Faça uma comparação sobre como o artigo foi escrito e como ele poderia ser escrito, talvez até de umas dicas de como melhorar. Além de tudo, respeite o profissional que escreveu ou criou aquilo que é alvo de seu artigo, nem todos concordamos em tudo, mas isso não é motivo para chacota e desrespeito.

8. Exemplos práticos. Nem todo tema é passível de um exemplo prático, mas em se falar de tecnologia e desenvolvimento isso geralmente é possível, então faça! Anexe um código, aponte um repositório, um diagrama de classes ou um ERM. Ilustre seu artigo com exemplos e gráficos, a leitura fica mais agradável e coerente.

9. Começo, meio e fim. Pense e planeje seu artigo. Todo artigo tem um objetivo. Para chegar nele o artigo precisa de um começo ou uma introdução, um meio ou o desenvolvimento do tema, e um fim, a conclusão. Isso se aplica a todos artigos, mas também vale pra artigos técnicos. Por exemplo: Descreva o problema que vai resolver, mostre como resolver e conclua se foi ou não uma boa escolha. Garanto que se o seu artigo passa 5 parágrafos contanto a historia do John Armless e no final não explica onde ele se encaixa no tema nem porque, seus leitores vão ficar confusos, e indignados.

10. Don’t be a douchebag. Eu gosto desta frase em inglês por ela ser a forma mais ofensiva sem ser ofensiva de se dizer, não seja um chato. Acalme o ego, baixe a crista, seja sério e respeitoso, receba comentários bem, mesmo os mal educados.

Bem, seguindo minha própria receita, esta é minha opinião, assim são construídos os artigos que eu respeito e gosto de comentar e discutir. Posso estar errado, então por favor comente sua visão do assunto nos comentários, faltou alguma regra? Espero que este artigo possa inspirar artigos melhores de valor técnico e que discussões possam brotar destes.

A matéria sobre segurança procurava informar o usuário da internet como evitar problemas de segurança e emails de “phishing”. O termo descreve ações onde usuários mal intencionados enviam email falsos, com links para sites que imitam, com intuito de roubar informações da vítima.

As dicas foram bem simplórias e de forma geral corretas, porém aos 2:15 da matéria o Sr. Jeferson D’Addario (@jefebrasil), especialista em segurança convidado pelo jornal comete um grave deslize, a frase:

“… quando for .php, pode ser em grande maioria, um virus …”

Esta informação, especialmente no contexto que foi dada é extremamente incorreta, e causa alarde desnecessário.

O PHP se trata de uma linguagem de computação utilizada para criar sites na internet, linguagem na qual trabalho a 12 anos já. Estima-se que mais de 26 milhões de dominios na internet sejam feitos com PHP (fonte, fonte 2007), dentre esses grande sites como o Facebook e a maior parte dos blogs, que utilizam a plataforma WordPress, escrita em PHP.

Com isso a afirmação do Sr. Jeferson de que podemos identificar um virus pela extensão .php é absurda e pode causar danos a muitos sites.

Exemplo usado na matéria

No exemplo dado, que aparece acima a verificação da URL fraudolenta pode ser feita pelp dominio apresentado “nyamphande.com” que não pertence ao Serasa. Este mesmo ataque pode ser feito com arquivos de extensão .asp, .py até .html ou se o ataquende desejar, .css, .js .globo, .qualquercoisa . Pois esta extensão é configurada no servidor.

É pratica comum no PHP utilizar configurações para ocultar este suffixo “.php”, porém muitos sites não utilizam esta pratica e nem por isso são sites de Phishing. Muito menos a “maioria” destes sites é malicioso.

Espero que este artigo rápido esclareça a dúvida criada pelo profiossional, e que a extensão .php que pode ser usada pelo seu site favorito não seja motivo de alarde.

UPDATE:

Após publicação deste artigo pude acompanhar a repercursão do assunto na internet, inclusive em sites como o Twitter onde a hashtag #phpvirus foi para os Trending Topics rapidamente. Programadores PHP e de diveras linguagems demonstraram indignação pela desinformação prestada na matéria. Foi possivel também ver tirinhas como esta do ProgramadorReal.

Poucas horas depois estava no ar um abaixo assinado feito pela comunidade de programadores PHP pedindo uma retratação. Faça sua parte, aguardaremos a Rede Globo se manifestar.

UPDATE 2:

Neste sábado o jornal hoje apresentou nota corrigindo a citação acima e deixando claro que páginas terminadas em .php não são geralmente ameaças e sim parte comum da internet. Aproveito para agradecer o jornal hoje por corrigir a matéria e por soltar esta nota hoje. Veja o video

No ano anterior minha palestra foi uma introdução ao PHP, este ano tive o prazer de apresentar a palestra “Trilhando o caminho PHP”, de longe minha palestra favorita. Eu gosto dela pois não é uma palestra técnica e embora todos exemplos sejam geralmente voltados ao PHP ela é uma palestra que pode se aplicar a todo profissional da área de TI e até mesmo de outras áreas. Nela eu procuro apresentar ideias e sugestões de caminhos a serem tomados para o crescimento e sucesso profissional, como aumentar seu conhecimento, divulgar seu nome, conhecer as pessoas certas e eventualmente empregos melhores. Ela nasceu inspirada em minha carreira, mas foi se transformando ao longo do tempo com inputs de diversos profissionais da área e da comunidade, trazendo novas dicas e historias de sucesso.

Por esses motivos foi um prazer palestrar no evento, ver a platéia cheia e a presença de não-phpzeiros e especialmente o feedback pós-palestras, as perguntas e as conversas que se seguiram foram muito legais e eu senti que refletiram a mensagem passada na palestra. Mas a Campus Party me trouxe algo diferente este ano, além da presença de minha esposa e meu irmão na platéia, por ser um ambiente de extrema produtividade social ou sei lá como descrever isso acabei por poder assistir um video que comentava minha palestra. A Juliana Santos Flor Moreira estava na platéia conferindo a palestra e no dia seguinte postou um video onde fazia sua considerações sobre a palestra, o feedback foi excelente para mim, enquanto tentava explicar para outros o conteúdo da minha palestra foi possível ver exatamente quais pontos marcaram ela durante a palestra e já me deram ideias de como melhorar ela e fazer com que a mensagem fique mais clara.

Se ainda não participou de uma Campus Party, não deixe de participar no futuro, é um evento incrível e maluco ao mesmo tempo, com um pouco de maturidade e foco é possível dar um bom gás em sua vida profissional e aprender muito.

Please specify a Flickr ID for this gallery

As novas bibliotecas, ou SDKs, seguem o velho ditado do “filho de peixe, peixinho é”. Embora estejam novas e com cheirinho de carro novo, a documentação de como utlizar elas eficientemente está vaga, ausente ou espalhada em diversos blogs, como este, em posts de usuários que querem compartilhar a informação com futuros sofredores desenvolvedores ou apenas ter a anotação para uso posterior.

Então isto se trata de um exemplo desta situação, tenho usado os novos recursos e as novas bibliotecas e tenho tido diversas dificuldades, portanto decidi começar a colocar algumas destas coisas em meu blog, por dois motivos: espalhar a informação, e ter anotações pra eu me lembrar depois.

Como posso executar queries em FQL usando a nova SDK?

FQL é a alternativa do Facebook para o SQL, permitindo que você busque dados como se estivesse acessando um banco de dados gigante, esta documentação felizmente ainda esta atualizada e você pode ver uma lista de “tabelas” de onde pode buscar informações, o restante dos truques você vi aprendendo enquanto usa.

Na biblioteca antiga, baseada na API REST, era bem simple rodar uma FQL:

$facebook->api_client->fql_query("SELECT uid, pic, pic_square, name FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = 111111111)");

Porém isto (e muitos outros métodos) não está mais disponivel na nova PHP SDK então eu demorei um bucado de tempo para descobrir como poder enviar uma requisição de execução de uma FQL, já que o único método disponível era o api(), um método polimorfíco e não-documentado. Eu finalmente achei a resposta em um blog semelhante ao meu, com alguém que teve a mesma experiência. A requisição é feita assim:

<?php
	//Get Facebook SDK Object
	$config = array(
	  'appId'  => APP_ID,
	  'secret' => API_SECRET,
	  'cookie' => true,
	);

	$facebook = new Facebook($config);

	//Create Query
	$params = array(
	    'method' => 'fql.query',
	    'query' => "SELECT uid, pic, pic_square, name FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = 111111111)",
	);

	//Run Query
	$result = $facebook->api($params);
?>

Uma vez que você finalmente descobre que deve passar o parametro “method” para definir o método da API que pode ser executado, e ai descobre que deve passar sua busca em um parametro chamado “query”, você tem a faca e o queijo na mão. Não preciso nem dizer que isso pode demorar um pouco mais do que esperado.

No meu ponto de vista este pedaço de código porém é horrivel, não gosto de criar arrays para poder passar parametros para uma função, cada vez que for rodar ela. Então decidi que para usar essa SDK corretamente eu ia precisar extender ela e implementar algumas correções, neste caso um Helper Method para FQL. Veja como ficou:

<?php

namespace App\Facebook;

include_once \ROOT_PATH . 'library/vendor/facebook/facebook.php';

class Client extends \Facebook
{
    private $config;
    private $reqPerms;

    /**
     * Runs a FQL query agains the API
     *
     * @param string $query
     * @return array
     */
    public function fql($query)
    {
        $params = array(
            'method' => 'fql.query',
            'query' =>$query,
        );

        return $this->api($params);
    }

}
$config = array(/* insert config here */);

//Using client
$fb = new App\Facebook\Client($config);

$query = "SELECT uid, pic, pic_square, name FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = 111111111)";
$result = $fb->fql($query);

?>

Isso faz chamar uma FQL rápido e simples, além de te dar a vantagem de ter a SDK embrulhada dentro do seu próprio namespace e, de bonus, ter uma forma mais simples de mockar e testar código relacionado, isso porque temos agora um método para mockar e não mais nos preocupar com paramentros passados.

Eu dei um passo além e aproveitando que o SDK esta no GitHub, comitei esta alteração em um pull request. Ele ainda não foi aceito, mas espero que ele seja em breve e que mais pessoas possam se beneficiar com ele.

Espero que gostem e que isso lhe dê mais ideias de como melhorar o uso da nova SDK e eu voltarei em breve com mais dicas.