Marco Pereirinha desenvolveu os seus primeiros projectos com WordPress em 2009, mas, como ele próprio diz, só começou a “fazer vida” em 2011. Durante quase um ano foi trabalhar para a Metronet, na Noruega. De regresso a Portugal continua a desenvolver para esta grande empresa de produção de software. Tem desenvolvido temas e plugins específicos para clientes governamentais, privados e ONGs.
No ano passado foi um dos organizadores do primeiro WordCamp do Porto. É um entusiasta da comunidade. Quisemos saber um pouco mais sobre como trabalha.
Quando estás a desenvolver um projecto WordPress quais são as tuas ferramentas principais, em termos de aplicações, serviços?
Vão havendo variáveis, mas actualmente estas são a ferramentas que uso:
Stack
No passado tive alguns dissabores por trabalhar com diferentes versões PHP localmente e nos servidores. Por isso, tenho usado vagrant como ambiente de desenvolvimento, em particular a configuração desenvolvida pela 10up especialmente para o WordPress, a Varying Vagrant Vagrants (VVV). Este cenário garante-me que tenho as mesmas condições nos diferentes ambientes.
Editor
Depois de ter experimentado vários editores, acabei por aterrar no Sublime Text 2. É muito rápido e existe uma comunidade que o expande através de diversos pacotes, muitos deles gratuitos.
Compilador
Até há pouco tempo usei o CodeKit para compilar as styles sheets, minificar os javascripts e comprimir imagens. Contudo, recentemente testei o gulp.js que, a estas features, acrescenta a possibilidade de gerar icon fonts baseadas nos svg atirados para determinada pasta. Todavia a gestão dos erros não é espetacular, os erros de sintaxe javascript são confusos e quando tens um erro num ficheiro LESS ou SASS o processo watch salta fora.
Controlo de versões e Deploy
Uso o Tower para controlo de versões que trabalha de forma integrada com o Beanstalk para fazer deploy para os servidores. Nos projectos pessoais, tenho uma VPS apenas para fazer deployment, pois acaba por ser um investimento mais reduzido.
Browser testing
O BrowserStack é usado para testar tudo o que seja browser.
Task Manager
Os projectos e respectivas tarefas são geridas com o Jira.
Podemos conhecer o teu processo de trabalho, o teu ‘workfow’, ou os métodos habituais?
Tem sido politica da empresa envolver os developers desde muito cedo nos projectos a fim de despistar eventuais bottle necks. Assim, são-me apresentados os protótipos em Axure e, numa fase mais avançada, as mockups no Invision. Após fecho do design gráfico — que raramente é o fecho pois, à semelhança da empresa anterior, em todos os projectos há sempre qualquer coisa a mudar posteriormente — chegam-me às mãos os PSD’s. É iniciado o processo do desenvolvimento do back e front-end.
Paralelamente preparam-se o servidor de desenvolvimento e o ambiente local. Temos ensaiado vários cenários e, ultimamente, tem vingado o controlo de versões apenas do tema. A base de dados é única (com ligação através de SSH tunnelling, ainda que isso traga um lag enorme). Falta encontrar uma forma elegante de lidar com a sincronização dos assets e dos plugins.
O commit do código é feito para o servidor de staging, onde o cliente pode acompanhar o desenvolvimento e até produzir os conteúdos. Uma vez concluído o desenvolvimento, é feito o setup e migração para o servidor de produção. Na fase madura do ciclo de vida do projecto, os commits são sempre feitos primeiro para o servidor de staging e, somente após a aprovação do cliente, para servidor de produção.
Experimentas novas aplicações e serviços com regularidade ou permaneces fiel às tuas preferidas?
Sou muito curioso e em quase todos os projectos experimento algo que ouvi falar, ou li algures. Algumas experiências são bem sucedidas e a tecnologia fica, outras vezes não me adapto, ou é um passo atrás no método anterior e então deixo cair.
Quando o risco é grande, os teste são feitos em pequenos projectos pessoais. A título de exemplo, a minha próxima experiência será testar o compilador PHP HHVM.
Trabalhas apenas com WordPress ou utilizas outros sistemas de gestão de conteúdos?
Longe vai o tempo do PereirinhaCMS, um CMS que desenvolvi usando uma arquitetura MVC. Contudo, o sistema encontrava-se a léguas da perfeição e a cada novo projecto havia sempre a necessidade de refactoring no código. Farto disso, decidi fazer um levantamento do que havia no mercado OpenSource e percebi a oferta alargada. Tinha que escolher um para começar a testar e foi o facto de haver uma comunidade tão vibrante, também em Portugal, que me fez colocar o WordPress no topo da fila. No inicio não me pareceu a escolha mais acertada, e o facto de WordPress correr processos em pipeline não me pareceu a melhor solução.
Primeiro estranha-se, depois entranha-se! E passada a fase de adaptação, já não voltei à lista para testar os restantes CMS. Não me arrependo, já que ainda não encontrei desafio a que o WordPress não tenha respondido.
Há pouco mais de um ano trabalhavas numa pequena e média empresa. Agora trabalhas, sobretudo, para uma grande empresa de desenvolvimento. Que diferenças encontraste? Só em termos de organização ou também na forma como é feito o desenvolvimento de software?
A principal diferença que encontrei foi na estrutura da organização. A pequena empresa em que estava, onde era responsável pela área de negocio do desenvolvimento Web, pela escassez de recursos, obrigava-me a estar envolvido em todas as fases do negócio. Isso não é muito bom pois temos que nos dividir em vários papeis, uns mais confortáveis do que outros. Agora concentro-me essencialmente naquilo que considero ter mais talento e que me dá mais gozo, o desenvolvimento de back e front end. Sou envolvido nas discussões de UX e em diversas fases do design gráfico, mas não é da minha responsabilidade a tomada de decisão.
O facto de trabalhar numa das empresas listadas no directório da Code Poet permite-me trabalhar junto de developers muito talentosos, com diferentes backgrounds e várias origens, com os quais tenho partilhado experiências e, assim, enriquecido a minha forma de trabalhar.
Olhando para trás, as maiores alterações na forma de trabalhar são o uso constante de controlo de versões e o de VPS. De resto, se tiveres presente o Codex — ou o novo Code Reference — e os WordPress code standards, então não é muito diferente trabalhar numa empresa maior.
Nos últimos meses tem crescido o debate sobre a “economia WordPress”. Em concreto sobre os preços de desenvolvimento de websites, o preço dos temas, plugins, os salários dos profissionais da área. Podemos saber o que pensas sobre a política de preços?
Bem, esta é uma guerra com várias frentes e sem fim à vista, certo? A principal razão que me fez sair de Portugal for precisamente a insustentabilidade de uma pequena empresa de desenvolvimento Web no mercado nacional.
O mercado é pequeno, e até assimétrico entre os grandes Norte e Centro. Sendo o WordPress tão fantástico, e pela sua génese de fácil adoção, é frequente competirem empresas com soluções à medida, com freelancers que recorrem a uma theme shop e a um punhado de plugins para um mesmo projeto. Atenção que o inverso também acontece, e talvez não seja menos frequente. Contudo, os valores envolvidos são necessariamente diferentes e frequentemente os clientes são mais sensíveis ao resultado da soma das partes, do que ao valor de cada uma das partes que o compõe. E com isto, nem coloquei na equação o sobrinho do Freitas da contabilidade. Todas estas condições concorrentes fazem com que, à semelhança do que acontece com quase todas as áreas de negócio em Portugal, as condições de trabalho e de remuneração não sejam as mais atraentes.
Virando o bico ao prego, e saindo do de 1 para 1, para o de 1 para muitos, o desenvolvimento de temas e plugins trazem esse potencial do mercado global que é teoricamente apetecível. O busílis está na distribuição. Ou te lanças na promoção do teu produto, e corres o risco de dispersão de esforços (promoção, desenvolvimento, suporte, etc.) ou entregas-te a uma webshop que rapa uma parte substancial do valor da venda e do teu suor. Pessoalmente acho que os valores andam nivelados por baixo, talvez resultantes da percepção generalizada do OpenSource como gratuito (uma leitura interessante do Peshev sobre o assunto).
Quais achas que devem ser os próximos passos do WordPress como CMS, aquilo que gostarias que tivesse e ainda não tem?
Não há muito que possa apontar ao core do WordPress como estando a faltar. Contudo, e por trabalhar com projetos de dimensão considerável, sinto que a gestão de media é uma das áreas que precisa ser repensada. A situação atual é permeável a redundância de recursos, e a organização dos mesmos precisa de revisão sob o ponto de vista da UX.
Alguma sugestão a quem está agora a começar a trabalhar com WordPress?
Atendendo à quantidade de perfis que o WordPress permite satisfazer, desde os produtores de conteúdos, passando pelos assemblers de temas e plugins, até aos developers (front e back-end), os caminhos vão vários.
Aqueles que entram no WordPress tendo em vista trabalhar enquanto developer têm que ter presente que é importante explorar cada um destes perfis de forma a ter uma melhor perceção do global. É também importante um bom background em PHP e JavaScript, mas também conhecer as ações, filtros e API’s que o core do WordPress oferece. Dissecar os temas que são fornecidos por defeito pelo WordPress, bem como os plugins presentes do repositório, ajuda a perceber a mecânica.
Quando estiverem confortáveis, partilhem o código que escreveram. Procurem feedback junto de outros developers. A aprendizagem torna-se mais rápida.
Mas mais importante que tudo isto, é talvez aparecer aos vários meetups e aos WordCamps que são organizados e trocar experiências com a malta que lá está. Quase sempre ganhamos mais do que aquilo que damos.
Perfil em The Loop é uma rubrica do WP-Portugal. Procuramos conhecer, de forma breve e descomplexada, detalhes e opiniões de pessoas que trabalham com WordPress. As entrevistas tanto podem ser em texto, como em vídeo. É como nos apetecer. A nós e ao entrevistado.
Obrigado pela entrevista e partilha de conhecimento 🙂