After launching a couple PHP User Groups in Italy (Rome and Friuli), I started to feel kind of lost here in Dubai, a place that gathers together lots of talents but doesn’t have that much of knowledge-sharing culture.

Given this and the pro-active involvement of some of my colleagues from Namshi, I really wanted to see some sort of community raise in this desert.

In my last post I wrote about integrating Twig into your legacy code with a really wild approach.

Today I came up with a better solution that lets you take advantage of Twig full features without any hack (like the partial tag I was talking about in my previous post).

It might happen that you are working on a legacy code that is years old, with its own templating mechanism¹ that doesn’t really allow you to take advantage of the benefits that a structured and object-oriented engine like Twig.

In this situations, when a complete replacement would cost too much to your organization, you can take advantage of a wild integration between this advanced template engine and your existing code.

When you think in terms of Service Oriented Architecture one of the tricky things is to decide how to organize your development workflow in order to develop architecture, not a single application: for example, how would you configure deployments (when you need to deploy part of your architecture, not just a web application) or push cross-service features to your SCM?

One thing that is always difficult, enough to deserve its own book, is to secure HTTP API that interact with client-side applications: today, after a discussion about how to face the problem in our company, we bumped into the JOSE – JavaScript Object Signing and Encryption – specification.

Everyone knows that I am a big fan of the Symfony2 ecosystem, and going SOA with this framework was a very trivial decision for us at Namshi; all in all, besides personal preferences, there is a plethora of reasons to choose this framework among the others available in PHP, so I am going to list the most important factors that influenced our decision.

Believe it or not, all of the following factors matter first for the business, then for the developers.

Today I got one of those moments of pride when one of our developers, who is working since – roughly – a year, decided to send an email to the team after working on automated tests for the first weeks of his career:

Automated testing is great idea

If you have a ticket which requires a lot of changes (20 files, for example) Automated tests are very helpful and save your time, it saves about 30% of your time; even if it’s still not perfect, its good
For example look at this PR [link to a PR on Github], if i want to test all cases i need about half a day but it only took half an hour

A post in the doctrine-dev mailing list caught my attention last week, and I want to share its insights with you.

Today I had the opportunity to share with the people at the PHP.TO.START in Turin my 1-year experience in Namshi, one of Rocket Internet’s ventures in the Middle East.

I’m enjoying a relatively long – at least for me – 2 weeks “vacation” back in Italy, since I was missing my friends in Rome since exactly a year and the last time my parents saw me it was 6 months ago.