This blog post has been written after some concerns expressed on Twitter and Reddit about how SensioLabs manages the Symfony trademark. If you want to read the details about the Grafikart issue, scroll to the end; reading the whole post is recommended though if you want to understand the whole story.

Unlike many other Open-Source projects, I chose a name for my little framework late in the game: just before open-sourcing it and more than a year after working on it. "SensioFramework" was its name when it was used internally for SensioLabs customers. But when I decided to open source the code, I wanted to find a different name: one that would help the framework have a life on its own, along side SensioLabs. I wanted to experience the "true" Open-Source adventure. The framework would have its own community. Its own rules. Its own agenda. Symfony was released in October 2005. And I'm proud of what we achieved; I would never have imagined what it would become.

Symfony is a great name, but as with many great names, it is used by many companies around the world (the fact that I chose to replace "ph" by "f" does not have any impacts in terms of trademarks; it just gives Symfony its own little personality; it makes you a little uncomfortable the first time you read it, but feels like your family name after a little while).

I learned a lot during the symfony 1 era. But problems began to surface with the growing popularity of the framework. Technical ones of course, but also administrative ones; trademark ones.

Symfony is a generic name used by many big corporations around the world; like "IBM Lotus Symphony". Remember when Firefox was named Phoenix? Phoenix was renamed to Firebird and then to Firefox due to trademark issues.

2010 was a key year for Symfony. Symfony version 2 was in the works, we migrated to Git and we were working on a new website for the framework. But what about the name? A new major version is the ideal time in the life of a project to change its name. Instead, I decided to double-down on Symfony. I started the long process of registering the trademark to protect the name; I wanted to be sure that nobody would ever be able to force us to rename the framework to something else - a process that would be very damaging to the entire project. Unfortunately, this is when issues began.

Registering a name means that companies with similar trademarks get notifications. And of course, they start to fight you. IBM was not the problem. But a small US service company was able to block our registration in the US and in Europe. At this point, I had registered the trademark in France only. But for how long? I remember meeting at this very moment with several key community members during a SymfonyLive conference in Cologne. I told them the whole story: the prohibitive cost of lawyers, and more. They were all very supportive and I decided to fight. I decided to do whatever it took to defend our brand. But I also made another decision back then: I would be the one responsible for ensuring "good" usage of the brand. It took me years to win, but I won. I bought the "symfony.com" domain name from a guy who "squats" many "valuable" domain names. I got "symfony.net" for free from its previous owner (a broker) as I had the French trademark (thank you). And I was never able to get any replies from the owner of "symfony.org", too bad.

I unveiled the symfony.com website during the most memorable SymfonyLive international conference in Paris ever. And it already had the Trademark and Logo Policy page. As mentioned at the top of the policy, I did not write it, I just customized the "Ubuntu trademark policy", which is published under the CC-BY-SA license.

Why do we have a trademark policy? I'm a French engineer... and like many of my peers, I like processes, I like perfection, I like rules... I don't like surprises, I don't like uncertainty. That is probably one of the reasons why Symfony got processes early on: the predictable release process, the security issue resolving process, the backward compatibility promise, a maintenance plan, ... and the trademark policy. All these documents govern the fundamental ways in which Symfony operates. The way we work together. The way we can on-board people more easily. The way we can grow the community with confidence.

I mentioned Ubuntu, but many Open-Source projects have such trademark policies with very similar restrictions:

• Node.js: "You need express permission if you plan to host a public commercial event or a conference that uses a Node.js trademark [...]"

• WordPress: "We will grant permission to use the WordPress name and logo if your project is non-commercial in nature (it

Truncated by Planet PHP, read more at the original (another 8999 bytes)

It was not that long ago that Christopher Pitt wrote an excellent article about writing and running PHP code on an iPad. After reading it, I thought to myself "It would be really cool to do the same on Android": being able to write and edit code on the fly, for example while traveling, and not having to take the laptop everywhere. So I've decided to do some research and see what I could come up with.

For this article, you can use any type of Android device. I've done it on my phone, but an Android tablet with a Bluetooth keyboard would probably be the ideal setup.

There are a couple of different shell apps for Android. For this tutorial we will use one called Termux.

Termux combines both a powerful terminal emulation and an extensive Linux package collection. It is also completely free and easy to use.

After installing Termux from the Play Store, the first thing to do is to run the apt update command. As per the documentation: "This command needs to be run initially directly after installation and regularly afterwards to receive updates."

Now for the fun part. The first two commands I want to talk about are the apt list and apt list --installed commands. The first one will list all the available packages for Termux. We can see that it has support for a lot of different programming languages, text editors and has some useful utility packages like zip, tar and so on. The second command will list all the installed packages. As we can see Termux already comes with some packages like apt and bash pre-installed.

My goal when testing Termux was to see if I could assemble a proper* PHP development environment, so I started by installing a text editor. I prefer Vim, but there are some more options available, like Emacs and Nano. Vim has a bit of a learning curve to it, but it gets very comfortable when you get past the basics of it. You can get Vim with the apt install vim command.

If you want to learn more about vim, there's this very good article or, alternatively, after installing it, type vimtutor to use the built-in tutorial.

If you are testing this on your Android phone, running vim will bring the first set of problems. How can I hit the Escape button? Termux has a large list of shortcuts that be used to simulate the buttons that are not available on the Android keyboards:

Now that we have our editor up and running, it's time to install the packages we'll need: PHP, Git and Composer.

apt install php
apt install git

This will install the latest PHP and Git packages.

For Composer, we n

Truncated by Planet PHP, read more at the original (another 2161 bytes)

So, here's a bit of a personal blog post for once.

Symfony trademark policy

I saw this tweet:

Suite à une mise en demeure, j’ai retiré les tutoriels qui concernent Symfony du Site. Il n’y aura pas de futures vidéos sur le Framework.

— Grafikart (@grafikart_fr) March 11, 2017

Meaning: "Following a formal notice, I removed the tutorials that are related to Symfony from the Site. There will be no future videos on the Framework."

I got mad. I had heard of other people having trouble with Sensiolabs' trademark policy and I once had difficulty getting permission to use "Symfony" in my "Hexagonal Symfony training tour" (which became the "Hexagonal Architecture training tour"). So I tweeted about it:

A big problem of the @symfony/@sensiolabs ecosystem if you ask me. https://t.co/RRCge5g1gm

— Matthias Noback (@matthiasnoback) March 11, 2017

I thought it would be good to speak up. It's a really scary thing to do anyway. It's not in my nature to voice criticism publicly like this. I know that doing so will make things harder, and close certain doors.

Regret

However, not long after the initial tweet by @grafikart_fr, Fabien Potencier (lead maintainer of Symfony) tweeted:

I’ve given 12 years of my life to Open-Source and #symfony. Every. single. day. since. 2005. Investigating @grafikart_fr story internally.

— Fabien Potencier (@fabpot) March 11, 2017

And also:

Very sad day for me. I can tell you.

— Fabien Potencier (@fabpot) March 11, 2017

This made me feel really bad about myself. I don't want to play a part in someone's sad day. Of course.

As you know I’ve always been a big fan of Symfony and Fabien's work on it. I have learned a tremendous amount of things from using it, documenting it and creating open source tools for it. So: dear Fabien, I'm sorry for my act of public shaming. It isn't good style.

Here's the lesson I'm trying hard to learn in my life: voicing criticism isn't equal to saying that everything you are, do or create sucks. In fact, my girlfriend warns me about this when she gives me feedback and I "cringe": "I'm not saying that your personality sucks, I love you, don't forget that." I think that this somehow applies in this situation too. Fabien, please don't feel rejected.

Earning money with open source

An interesting perspective on this topic was brought up Jordi Boggiano:

@matthiasnoback it's a challenge when OS projects become too big to be hobby projects.. Making money around OS is not as easy as many think.

— Jordi Boggiano (@seldaek) March 11, 2017

It was interesting because I didn't consider it to be relevant at first. It has never occurred to me that Fabien didn't earn enough money to justify all his open source work. Well, maybe he has, but that doesn't matter. Working on open source and earning money with that is something that's rather hard to accomplish. Examples of these are Jordi's own experiences with maintaining Composer. And I can very much relate to this too. Many people, including rich people, and many companies, including very successful ones, assume they can demand a lot of free work from open source maintainers. Starting to ask money for essentially the same thing, is often met by outrage (or silent neglect), so it's really hard to run an "open source" business.

For the past few months I've been trying to pick up what you could call my "master plan". I hope to organize workshops and do freelance programming jobs, thereby financing all the unpaid "open source" work that I love to do, like blogging, speaking at meetups and conference, and open source programming. I've learned two things already:

Truncated by Planet PHP, read more at the original (another 1654 bytes)

Software is playing an ever bigger role in how companies compete across a broad range of industries. Large organizations are finding that their current approaches to managing software are limiting their ability to respond as quickly as business requires. Continuous delivery helps with this.

Understanding continuous delivery, a now already long-standing buzzword, is not a problem, but implementing it in the right way has been a challenge for quite a few of us, and one we'll discuss in this post.

Getting Started

We can easily upload our files to a server using an open source desktop client like Filezilla. Those who have used this are aware that this process is cumbersome and irritating as it doesn't let us automate the deployment process, and we always end up having to upload the whole project, even if we have modified only a part of it. Alternatively, we could do a git pull on the server and our application is instantly in its latest state, but this workflow doesn't work in today's world where we have to continuously deliver software to our end users bug-free.

In this article, we will cover the process of deploying a Laravel application on a Digital Ocean server through a continuous delivery pipeline using Semaphore. The source code for the application is present on Github.

Set up a Project on Semaphore

First, create a Semaphore account. After signing up, we see a page to create a new project.

We then have to select the account where our repository is present. If you haven't connected your source code repository provider with Semaphore, you can do so in this step. Semaphore natively supports Bitbucket and Github.

If you forked the aforementioned repo, you can select it in this step:

Continue reading %Crash Course: Continuous Deployment with Semaphore CI%

I'm happy to share with you the first chapter of my new book, Microservices for everyone. I'm still in the process of writing it and intend to release parts of it during the next weeks. If you're interested, sign up on the book's landing page and receive a 25% discount when the first chapter gets released.

If you're curious about the table of contents so far: you'll find it in the PDF version of the introduction.

Introduction

Scepticism

I can almost hear you think: "Bah, microservices. Nothing good could come from that!"...

We replaced our monolith with micro services so that every outage could be more like a murder mystery.

— Honest Status Page @honest_update

I am absolutely certain that this a solvable problem, but nonetheless, it may scare you away from considering a microservice architecture as a viable choice for your company. Especially since you already receive reminders of what a bad choice that may be on a daily basis (at least if you're on Twitter):

If one piece of your web of microservices suffers an outage and your whole system crashes and burns, then you have a distributed monolith.

— Matt Jordan

Which makes me wonder: how does this differ from when we have a single application? If something goes wrong in a monolith we usually throw an exception, and let it crash the application, right? Is it even possible to make our system as resilient as gets depicted here? When the disaster is too big, there may be nothing we can do to recover from it. Still, I'm certain that with a few simple implementation patterns we can make our microservice system much more resilient than any monolith we have encountered so far.

If your microservices must be deployed as a complete set in a specific order, please put them back in a monolith and save yourself some pain.

— Matt Stine

This sounds like good advice though. One of the main design goals of microservices is that services can be created and removed on-the-fly and other services shouldn't produce any failures because of that. If this is not the case, indeed we should get back to our monolith. But not too fast! There are some good solutions available.

Microservices without asynchronous communication are as good as writing monolith app.

— Ajey Gore

Asynchronous, event-driven communication is one way to approach the dependency problem. But it is not the one and only solution. In fact, as we will see later on, synchronous communication is still a viable solution. It needs a bit of extra work though. And as soon as you find out how to solve things in an asynchronous fashion, you'll be looking for other places where you can switch from synchronous to asynchronous communication.

I'm sure there are plenty of teams that have decided to make their next project a microservices project, which took a lot of research and a lot of work and the project may have ended up in quite a bad shape after all. There are many reasons for this. Probably most of those reasons are the same as for any other kind of software project: the regular problems related to estimations, deadlines, budgets, etc. Or, as often happens, developers were eager to try something new, to escape from the suffocating work on the "legacy system", seeking their salvation in a microservices architecture. Or, they were able to run their services on their own machine, but had trouble getting the whole system up and running, monitored and all, in an actual production environment.

Optimism

While still surrounded by microservice negativism the tech community has in fact been floating on a wave of microservices hype. Trusting on my built-in "tech radar" and "mood calculator" though, it feels like we're almost past this hype. If I look around me, we're more in the assess phase: "This could be something for us, let's find out." And I agree, it's time to prove that this can work. It's my current belief that we need the following ingredients for that:

• We need to put a lot of focus on our domain and create (but also continuously refine) a suitable model for it. In order to do so, we need to

Truncated by Planet PHP, read more at the original (another 15808 bytes)

This year was the 6th edition of the DrupalDay Italy, the main event to attend for Italian-speaking drupalists.

Previous editions took place in other main Italian cities like Milan, Bologna and Naples.
This time Rome had the privilege to host such a challenging event, ideally located in the Sapienza University Campus.

The non-profit event, was free of charge.

A 2-days event

Like most development-related events these days, the event spanned over 2 days, March, 3rd and 4th.
The first day was the conference day, with more than 20 talks split in 3 different “tracks” or, better, rooms.
In fact, there was no clear separation of scopes and the same room hosted Biz and Tech talks, probably (but this is just my guess) in an attempt to mix different interests and invite people to get out of their confort zone.

The second day was mainly aimed at developers of all levels with the “Drupal School” track providing courses ranging from site-building to theming.
The “Drupal Hackaton” track was dedicated to developers willing to contribute (in several ways) to the Drupal Core, community modules or documentation.

The best and the worst

As expected, I’ve found the quality of the talks a bit fluctuating.
Among the most interesting ones, I would definitely mention Luca Lusso’s “Devel – D8 release party” and Adriano Cori’s talks about HTTP Client Manager module.
I was also positively surprised (and enjoyed a lot) the presentation about “Venice and Drupal” by Paolo Cometti and Francesco Trabacchin where I discovered that the City of Venice has an in-house web development agency using Drupal for the main public websites and services.

On the other hand, I didn’t like Edoardo Garcia’s Keynote “Saving the world one Open Source project at a time”.
It seemed to me mostly an excuse to advertise his candidature as Director of the Drupal Association,

I had the privilege to talk about “Decoupled frontend with Drupal 8 and OpenUI 5“.
The audience, initially surprised by the unusual Drupal-SAP (the company behind OpenUI) association, showed a real interest and curiosity.
After the presentation, I had chance to go into the details and discuss my ideas with a few other people.
I also received some critics, which I really appreciated and will definitely make me improve as a presenter.

Next one?

In the end, I really enjoyed the conference, both the contents and the ambiance, and will definitely join next year.

Almost 10 years ago in 2007, I started a project called sabre/dav. I originally was looking to scratch an itch and solve a real problem we had in our company.

A lot of people ended up being pretty excited about it. In 2010 I got to a point where doing consulting around this project allowed me to travel around the world, working for various companies and get paid enough to not have to do any other jobs. Life was pretty good! One of these gigs actually brought me all the way to a beach in Australia! (Thanks Ben!)

In 2012 plenty of businesses relied on this project for either a side-feature, or at the heart of their product, including various ISP’s, product companies and open source vendors like Owncloud.

At this point I started working with Dominik Tobschall and we opened the doors to a business named fruux in Munster, Germany. We got a bunch of funding and we would try to build a consumer and small-business product. Fruux also used sabre/dav at it’s core for synchronization and became the owner of the project.

I also started working with CalConnect to help drive forward the actual calendaring and scheduling standards that sabre/dav and many other vendors implement. It was really awesome to work directly with the people behind Apple’s iCal and iCloud, Mozilla’s Lightning (hey Philipp!), Google Calendar and many other industry leaders. Instead of just being disgruntled about a bug (or feature) I could just ask the developers directly and work things out together!

We were unable to grow fruux quickly enough, so in 2014 we made a pivot and try to focus on professional services around sabre/dav. We got burned with the incredibly long sales cycles, so later in 2015 we had to wind this business down and find alternative income streams while still passionately working on this project.

Pictured above: the original fruux team

Unfortunately over time the alternative income streams slowly became the main ones leading me to September 2016, in which I started a new full-time job at a company in Toronto called Turnstyle. It’s a great change of pace after having worked remotely and contracting for half a decade.

This leads me to today. I recently read a blog post titled “What it feels like to be an open-source maintainer” by Nolan Lawson, which kind of hit home. This made me realize that after nearly 10 years, my work on this project has turned from something I was very excited about into something a bit more like a chore.

I’m not really using my own project(s) anymore. I don’t get paid, but I’m really the only maintainer. Lots of businesses depend on it, there are lots of open bug reports, feature requests and pull requests but I can’t find the time and motivation to work on it. According to packagist, it’s been downloaded 27000 times in the last 30 days. I think I would still love it if it were my full-time job and I had coworkers also working on it, but it all comes down to me.

This has caused two big effects:

1. I feel constantly guilty that I don’t work on these things. There’s people waiting on me and making reasonable requests, but I just can’t seem to get it done.
2. This guilt is preventing me from starting new things that excite me, because I feel bad starting the next thing if I haven’t finished the last.

It was a gut-feeling that took a while to sink in from around January. I finally realized that I need to make a change. This is pretty personal and emotional and it sucks to have to make this decision.

So, starting today:

• I resigned 100% from fruux
• I resigned from CalConnect
• I’m shutting down the sabre/dav mailing list (go to github instead)
• I’m looking for new maintainers

The affected projects are:

• sabre/dav
• sabre/vobject
• sabre/http
• Baikal
• davclient.js.

I’ll continue to maintain the following three projects because they are simple and small:

• sabre/xml
• sabre/event

Truncated by Planet PHP, read more at the original (another 1263 bytes)