De volta ao Velho Continente
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.
Como escrever artigos técnicos (melhores) em 10 passos
Blogs. A internet nos últimos anos tem visto o crescimento disparado destes sites, desde o desenvolvedor que escreve no finais de semana até o colunista que ganha para fazer isso. E não é por menos, eles são sim uma ótima ferramenta para divulgar seu trabalho e agregar valor ao seu nome no mercado, porém apenas se utilizado de forma correta. Vou me restringir obviamente a falar de blogs sobre tecnologia e desenvolvimento, embora outras áreas tenham muitas historias de sucesso desta plataforma também. Eu realmente não saberia como comentar por exemplo o mercado de esmaltes e como escrever artigos sobre eles.
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.
Como foi palestrar na Campus Party 2011
Este ano tive a oportunidade de voltar a Campus Party e mais uma vez palestrar na área de Desenvolvimento. Antes de mais nada, obrigado ao David Ruiz e ao Ricardo Martins pela oportunidade novamente.
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.
Usando o PHP-SDK para rodar FQL na API do Facebook
Desde a migração do Facebook para a nova Graph API e o protocolo OAuth 2.0, sua documentação para desenvolvedores virou uma grande confusão, sem eira nem beira, de artigos depreciados, e isso se eu for otimista. O problema é que muitos artigos antigos ainda apontam para práticas não mais recomendadas e muitos deles não possuem alertas sobre estas mudanças, em casos extremos funções que em breve serão removidas da API ainda não possuem equivalentes nas novas APIs.
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.
Como a Microsoft esta facilitando o desenvolvimento com PHP
Recentemente tive a oportunidade de conversar bastante com a Microsoft, junto com outros membros da comunidade PHP. Fomos recebidos por Josh Holmes (Evangelista de Arquitetos / EUA) e Rogério Cordeiro (Evangelista de Desenvolvedores / Brasil) na sede da Microsoft aqui em São Paulo, e fomos encaminhados ao auditório onde iniciamos uma conversa informal, mas muito interessante, por algumas horas. A ideia básica por trás da visita: nos mostrar algumas de suas novas ferramentas e receber um retorno e opiniões do que nós desenvolvedores pensamos de suas ferramentas, o que falta, o que esta quebrado e como arrumar.
A minha impressão sobre as novas ferramentas foi bem clara, ele cuidaram de problemas muito importantes, mas mais que isso, problemas que foram citados no Microsoft Web Developer Summit (MSWDS) que pude participar em 2009, foi muito gratificante perceber isto, pois significava que eles estavam prontos para escutar e realmente estavam levando nossas opiniões em consideração, tornando esta reunião muito mais importante e mostrando que temos uma parcela de participação no assunto (obviamente não longe o bastante para afetar o plano de negócios deles).
Então, como a Microsoft esta facilitando o desenvolvimento com PHP?
Montar uma pilha LAMP (Linux, Apache, MySQL, PHP) completa em um servidor linux é algo relativamente simples se você possui conhecimentos básicos de Linux a da linha de comando, mas aqui no Brasil temos uma grande parcela de programadores PHP usando Windows como seu primeiro ambiente de desenvolvimento, especialmente se analisarmos o nível mais iniciante da comunidade (desenvolvedores experientes geralmente estão em linux ou mac hoje em dia). Isso significa que no nível de entrada a primeira experiência de um programador com PHP é em uma pilha WAMP (Windows, …). Sem dúvida você pode usar soluções como o XAMPP ou WAMP Server para instalar a pilha completa, mas convenhamos Apache e PHP no Windows é no máximo horrível, e isso deixa uma má impressão nos desenvolvedores. Qual é a solução? Bem, é o IIS, mas levanta a mão ai os iniciantes que tem a mínima idéia de gerenciamento de IIS ou configuração, ou até mesmo quem quer saber disso. Estou chutando, mas aposto que poucas mão estão levantadas agora.
Entra em cena o Web Plataform Installer, lançado alguns anos atrás ele resolve este problema muito bem, instala a pilha e aplicações como Drupal ou WordPress ou qualquer software relacionado e configuração necessária. Ele ataca diretamente na raiz o problema de se ter uma pilha funcionando, e ele faz isso muito bem na versão 2.0. O que vimos na reunião me fez acreditar que isso vai melhorar ainda mais: WebPI 3.0, atualmente em beta.
Esta versão também marca o lançamento do PHP Manager que faz a tarefa de configurar e gerenciar instalações de PHP mamão com açúcar, e ainda nos dá outra possibilidade muito bacana, ter múltiplas versões de PHP rodando lado a lado na mesma máquina, cada site rodando em uma versão, isso significa que você pode hospedar sua aplicação legado e ter uma novinha em folha rodando PHP 5.3 na mesma máquina. Isso é realmente bom para aquele perfil de iniciante que agora pode ter em suas mãos muito poder e com uma curva de entrada muito baixa. Isto também ajuda outra camada de desenvolvedores, os criadores de frameworks a aplicações, pois isso torna muito fácil o processo de subir máquinas virtuais com Windows e testar seu novo release em diversas versões do PHP, quantas vezes você já sofreu pra fazer isso?
Outro pacote bem interessante é o WebMatrix, que fornece um ambiente de desenvolvimento completo com todos os pacotes “Express” e inclui uma IDE leve e simples para trabalhar com código. Mas a parte mais legal é que ele também cuida de um problema que todos nós no MSWDS falamos em coro, “fazer deploy para servidores Windows é doloroso”. É a função “publicar” que permite conectar sua máquina com um servidor Windows e fazer o deploy completo direto da ferramenta, um simples apertar de botão, que tal isso para facilitar a vida?
Ainda falando de WebPI outra funcionalidade muito bacana: Galeria de Aplicativos. Imaginem um feed com centenas de aplicativos a um simples clique de uma instalação completa, isso é muito bom para aquelas rotinas diárias e simples, como subir uma instancia de WordPress para sua vó. Mas ela vai muito além disso para aquela parcela de desenvolvedores que baseia sua carreira em vender aplicativos comerciais ou gratuitos. O motivo é simples, se você entra em programas como o Website Spark, você pode colocar seu sistema/aplicação lá, a um clique de distancia do seu público alvo. Que tal isso para espalhar sua aplicação?
A Microsoft também foi além e deu a nós programadores PHP uma solução de “cloud”, já que o Google fez cara feia no Google App Engine, podemos olhar melhor para o Azure, mas deixarei isso para um post dedicado.
Como uma pessoa que participou da iniciativa da Microsoft de extender a mão para a comunidade PHP e que teve a oportunidade de apontar os erros deles e aplaudir seus sucessos, eu realmente queria compartilhar esta mensagem com vocês, pois acrdito que chegamos a um ponto “divisor de águas” onde o Windows se torna um jogador titular na pilha PHP, junto do Linux, como o Rasmus mesmo falou.













