Everybody is organizing their own PHP conference these days. It's impossible to "catch 'em all". There's conferences clashing, conferences too far away, conferences too much like other conferences, etc.
Then there's conferences that have never been there before, are quite original and are therefore spark everyone's imagination. One such a conference is the Symfony Catalunya conference. This "international Symfony event" is being organized by the generally awesome and friend of the community Marc Morera. The concept seems to be pretty simple:
- 2 days, only 8 speakers
- never-before seen presentations!
- community sponsors
- very cheap tickets (50 euro early bird ticket)
It will take place in sunny Barcelona on July 22-23, 2016.
Programming with Cmdr. Chris Hadfield
I'm proud to be a part of the conference myself and because I had to come up with something I had never done before, I hereby announce a new talk - a "soft" one so to say - inspired by the book "An Astronaut's Guide to Life on Earth", written by ex-International Space Station commander Chris Hadfield.
At age 9 a Canadian boy called Chris Hadfield witnessed the landing of Apollo 11’s lunar module on the moon.
That night he decided he wanted to be an astronaut. Every time he had to make some decision in life, he picked the option that brought him closer to fulfilling that dream.
He actually became an astronaut and is now quite famous for his work as commander of the International Space Station (ISS). Being an astronaut is a lot of work.
It’s life-endangering, physically demanding and mentally exhausting. You need to make the right decisions under high pressure and live with people in cramped rooms.
Compared to this, the life of a programmer seems easy peasy lemon squeezy.
Yet there’s a great number of things that we, developers, can learn from Chris’s perseverance, his optimism, his way of life and the rules and procedures he applies to prevent major incidents.
See you in Barcelona for Symfony Catalunya!
- I won't update A Year With Symfony anymore.
- The e-book is now freely available.
My first book, A Year With Symfony, was well received when I first published it on September 4th. At the time it seemed to be a welcome addition to the official Symfony documentation.
A lot of water has passed under the bridge since then. Several new Symfony components were released and we have now arrived at the next major version, 3.0. In the meantime I published one update of the book: a new chapter about Annotations.
One year after the initial release I announced some big plans for a partial rewrite and a new chapter. I started working, but never finished it.
The content of the book is not outdated yet, not even after the arrival of a new major Symfony version. Most of the code samples still work. Only some parts of "quoted" Symfony code has been changed in the meantime.
If I were to write this book today, it would be different in several ways. I wouldn't focus so much on reusability in the final chapter. I would still write about separating "library code" from "framework glue code". But I would also promote the use of everything that Symfony has to offer in terms of Developer eXperience. If part of your codebase lives close the the framework, I'd advise you to "fully embrace the framework" in that code.
Finally, I would remove the "Project structure" chapter and replace it with something about application architecture. This is a topic about which I've learned a lot since writing this book. What's in the "Project structure" chapter is mostly a mistake (at least the part about form handlers). The sections on request and context data and passing it along instead of injecting it is still very important to be aware of.
Because of my current more or less full-time job at Ibuildings I don't see any options for a big update/rewrite. By writing this post I want to make it clear that I won't be changing, adding to or updating A Year With Symfony anymore. You could say it is "End of Life". However, the book has proven to be valuable for many people (about 2000 books have been sold so far!), so I still want to offer it to potential readers. From now on you can download it for free! The printed edition is still available on Amazon for the usual price.
Thanks for your ongoing support! This was a great adventure, an interesting experience and I've learned a lot!
Leaving Qandidate, off to Coolblue
After I had a very interesting conversation with the developers behind the Broadway framework for CQRS and event sourcing the day wasn't over for me yet. I walked about one kilometer to the north to meet Paul de Raaij, who is a senior developer at Coolblue, a company which sells and delivers all kinds of - mostly - electrical consumer devices. Their headquarters are very close to the new and shiny Rotterdam Central station. The company itself is doing quite well. With 1000+ employees they keep needing more office space.
Paul showed me around all departments and offices, which nowadays span three floors. There's developer teams everywhere. It's not a PHP-only company. Though PHP is well represented, there are also .NET and Delphi developers. Coolblue runs on quite a lot of software and hardware.
Developers at Coolblue have learnt to call the legacy software they maintain "heritage". "Legacy software" often has a negative sound to it, while in fact, it's what enables the company itself to be so successful, so it doesn't really deserve that negative image. I don't fully agree with this approach since most of the relevant literature about this subject speaks of "legacy software", which, to me personally, doesn't mean anything bad. I'm well aware that anything I write today will be "legacy" tomorrow, because, literally, other people inherit that piece of code and need to maintain it. In my dictionary, "legacy software" isn't a bad thing (though I know that it often is, so I understand this little play of words).
New things: microservices
Paul mentioned that there is an ongoing struggle amongst developers who rather want to try "new" things, while they feel stuck in the "old" way of doing things. Paul argues that it's always possible to try something "new" in an older project as well. The infrastructure may not be there for it yet, but introducing it might therefore be even more challenging, as well as more satisfying. I fully agree with Paul on this, and I also like to work on an older code-base and introduce new concepts to it. Anyway, in my personal experience, thinking that you're better off working on a green-field application, because you can do everything "the right way", often turns out to be quite a fallacy. I'm sure you'll recognize this sentiment as well.
At Coolblue, "new things" currently means event sourcing and microservices. They have introduced several microservices so far. Microservices are one of these things Coolblue developers have been wanting to introduce for quite some time. It turned out to be not that hard, but, according to Paul, the key was to keep it small at first. They started by extracting several smaller and less crucial parts from the main application into microservices. You can read about some of their experiences on devblog.coolblue.nl.
New things: event sourcing
Paul and others have done quite some research with regard to event sourcing as well. They haven't taken the step yet to implement it in their software. Take a look at this slide deck to get an impression of what it might look like for them when they do.
Paul made an interesting observation with regard to "new things": there is often a mismatch between what a developer thinks of themselves, and what that same developer thinks of other developers. When listening to meetup or conference talks, you may start thinking that you're way behind on current developments in the world of (PHP) software development. Paul at first felt the same, but noticed that when you actually talk to developers about what you're doing, it might just as well turn out that you're doing fine.
Developer teams at Coolblue are separated based on the features they work on. There is a team working on "pre-cart", i.e. everything related to the presentation of the products, their categories, etc. Then there's a "post-cart" team, which works on actually making the sale, payment, etc. Paul himself is moving from team to team mostly, helping everyone solve any issues that they may be facing. This way, he gets a nice overview which enables him to take knowledge from each team to other teams. This also helps preventing the same mistakes from being made in different teams.
Walking through the corridors, we pass a lot of "team rooms". Walls are made of glass, but each team is still nicely separated from the others. They can see, but not hear each other, meaning that they can focus on what they're working on, while still feeling part of the organization. It appears that each team consists of about 6 people. This is the right amount, according to Paul; when you add more people to a team, it doesn't become any easier. Each team has a nice poster attached to the outside wall, showing the passer-by what the goals of this team are for the current quarter.
Although Coolblue has an "operations" department, developers are supposed to take responsibility for the deployment and functional correctness of the work they deliver. Pull requests need to contain any changes required for configuration management (Puppet) as well as logging and monitoring. Developer teams monitor the runtime performance of the software and any problems that occur in production environments.
Paul says that gradually the organization is moving towards a "devops" culture, where developers are fully able to deploy and configure the code they produce. I'm curious how this works out. I think it's a great idea. However, I've also noticed that many developers are quite reluctant to learn all the subtleties of all the available "operations" tools. They may prefer to do what they're already good at: developing software (for which they already have to learn so many tools).
On the other hand, creating a working software product doesn't end with merging the pull request. It has to work on a production server as well, so you have to think about what's required to run the software and keep it running. So it's definitely justifiable to ask from developers to learn about "servers" as well.
My current hypothesis is that growing a devops culture is easier when the tools have been selected, and you don't have to learn to work with Ansible and Puppet, Linux and Windows, etc. It looks like Coolblue is lucky to be in this situation: its developers only need to learn to work with a small number of operations-related tools.
Learning and sharing
Coolblue regularly hosts "behind the scenes" meetups. Paul himself and Victor Welling regularly speak at these as well as other meetups and conferences. Developers are also encouraged to participate in public speaking, but when they don't want to, there are also regular opportunities to present something internally only. I agree with Paul that this is very valuable for development teams, and of course it's good for the "attraction factor" of the company. Coolblue itself is growing very fast and that's why they currently use the slogan "Looking for 100 Developers". To me this sounds like a pretty big effort, since every company I know of struggles with attracting and keeping new (and good) developers. I wish them the best of luck of course, knowing that developers will be in good hands.