Below you will find pages that utilize the taxonomy term “symfony”
“Domain-Driven Design in PHP” (@dddbook) is finished
Today, Keyvan, Christian and me are very happy to announce that “Domain-Driven Design in PHP” book is 100% complete. 380 pages and around 1400 readers so far.
Thanks
Thanks, thanks, thanks.
Thanks to everyone that has supported us in this project.
Thanks to Christian and Keyvan. We don’t need words to understand each other.
Thanks to our families and friends. Love is what you need to keep pushing.
Thanks to Edd Mann for helping at the beginning with the language implementation details ;).
Thanks to Matthias Noback for his suggestions and his foreword.
Thanks to Vaughn Vernon for being pragmatic and inspiring.
Thanks to Ricard Clau, Albert Casademont, Victor Guardiola and Jordi Abad for your contributions.
Thanks to Natalye Childress for non stopping asking about uppercase or lowercase. With your work, the book can be read.
Thanks to everyone that committed fixes, you are great: Jonathan Wondrusch, César Rodríguez, Yannick Voyer, Oriol González, Henry Snoek, Tom Jowitt, Sascha Schimke, Sven Herrmann, Daniel Abad, Luis Rovirosa, Luis Cordova, Raúl Ramos, Juan Maturana, Nil Portugués, Nikolay Zujev, Fernando Pradas, Raúl Araya, Neal Brooks, Hubert Béague, Aleksander Rekść, Sebastian Machuca, Nicolas Oelgart, and Marc Aube.
Deploying Symfony (and PHP) apps with Ansistrano
For a long time, Capifony was, without any doubt, the facto option for deploying Symfony2 applications. Capifony is a ruby gem based in Capistrano v2, an open source tool for running scripts on multiple servers with a deployment flow built-in. It’s primary use is for easily deploying applications. While it was built specifically for deploying Rails apps, it’s pretty simple to customize it to deploy other types of applications. At that time, alternatives were shell scripting or Fabric. Now there’s a better one, Ansistrano.
Migrating progressively to Symfony without pain with StackPHP
In the previous post, I talked about how to migrated to Symfony without pain using Apache Dumper. The idea was to generate Symfony routes in an Apache configuration file or .htaccess so it can be included in your virtual host. By including a fallback route to your current framework entry point, you can create new routes in Symfony without touching your previous framework. You can develop normally your new Symfony app, just defining new routes or the same old ones and regenerating the routes file.
This approach has some small pitfalls. Each time a new Symfony route is created, the Apache configuration file with the routes must be regenerated. If you’re creating many routes, this can be annoying. As explained in the previous post, there is another option that fixes this issue and have more features, Stack. Now, it’s like in Atrápalo, let’s see how it’s working.
Migrating progressively to Symfony without pain
Atrápalo is a travel e-commerce website founded in 2000. Based in Barcelona, Spain, it sells flights, trips, tickets, booking restaurants, car renting, etc. to 10 different countries. It’s a 9000 world Alexa ranking and it’s running PHP. Since 2014, we are pushing hard in order to evolve technically using best practices, agile methodologies and distributed architectures. One of the key aspects is the framework.
We are currently migrating to Symfony in order to speed up the development process and reduce the maintenance costs. We are doing it progressively, step by step, without rewriting the whole application, no green-field project, without any dedicated team neither. All developers are involved in this process, and by policy, each new feature is developed using Symfony while the old features remain served by the old framework.
I would say this process is going quite smoothly, without pain. Based on some emails and tweets I have received, here are some tricks about how we are doing it. Hope it helps!
Remove non used PHP files in your project
When a project gets bigger, specially when using a framework, it’s mandatory to have some processes that help you in removing code that is not used anymore such as models, classes, template files, etc.
That is not an easy task, however the benefits or removing non used coded are tons (code coverage, development speed, bugs, etc.). But what’s the best approach to detect that a template file is not used anymore in your PHP project?