Just a friendly reminder that PHP5.5 will stop receiving security support after the 10 July (17 Days at the time of writing).
It is advisable to upgrade to PHP 5.6 or PHP 7.0.
I would recommend you jump directly to 7.0 but it should be noted the support for PHP 5.6 has been extended to provide active support for an additional four moves and security fixes for additional 2 years. You can read more about the extended support of 5.6 in the PHP 5 Support Timeline RFC
We have discussed this for a very long time now internally and decided that Doctrine wants to drop out of the FIG. There are several reasons for this, one primarily is the lack of time we have to take part in the discussions and our lack of participation therefore in all of the standards that came after PSR-0 and also that we did not feel any of the PSRs after PSR-4 is worth implementing and standardizing on from our POV.
This is not to talk down the work that has been done here by participants isn’t valuable, we just feel our desire for standardization is mostly reached and everything on top is better solved by competition for the best solutions.
Jeremy, Michael, and I have discussed this for a while, and we feel that Guzzle no longer benefits from membership in the FIG. The existing PSRs have standardized what we need for interoperability, and Guzzle isn’t a framework.
We decided to leave PHP-FIG due to various reasons, mainly because we don’t have the time to participate in all those PSRs and debates. Personally, I’m also against some new stuff/PSRs that came up in the last months, so I actually can’t support nor justify PHP FIG anymore.
With a few of the other recent resignations (particularly Doctrine’s), Laravel will bow out as well. I must admit I very rarely ever read the e-mails and simply don’t have time to participate in any meaningful way.
I don’t wish to go place any blame or point any fingers at PHP-FIG as they have been doing a fantastic job PSR-1/2 Autoloading and logging. However people in the community feel some members are only members to vote and be listed on the website and most do not participate.
PSR7 unlike its previous PSR’s was a large and complex concept. Trying to standardise a large segment of an application (with the goal of making it better). This may be playing a factor in people decision to step down as the direction of FIG has changed.
The other issue which I think is obvious when you try and see what PHP-FIG is up to is the signal to noise ratio. Who can shout the loudest about the latest FIG. No real community input why should a small group of people decide for the rest. Don’t get me wrong I feel PHP-FIG has been a massive contributor to ‘modern’ PHP. However I feel they need to go back to there small PSR’s and not large segments of the system. Look at symfony HTTP request its used by a lot of developers and libraries/frameworks because it is good, not because it was voted that it was good.
I personally do not blame a project for leaving, PHP-FIG is just not the same. You’ve changed man. Does this mean FIG is going to implode, maybe maybe not depends how they go from here. Do the other projects bail, does FIG to back to the way it used to be. Does someone build a group were every php developer can vote?
Their pricing is very simple to understand now. If you had a small organization on the basic plan (under 5 users) you will be paying the same, expect you can now have unlimited private repositories.
This is a powerful move from the git hosting giant which I believe will help migrate people from bitbucket which has always based on a per user pricing modal. The per user modal works with customer success as a business who can afford to pay salaries can afford to pay $9 per user. The number of git repos you have was never a good marker of success for example Google only has one repo.
I don’t see it happening but I would love to see Github publish the number of conversions they now see.
Over at smoothphp this week I recorded another video about Building your first Aggregate using evening sourcing and how to get started with the SmoothPHP framework. If you missed the first one I recommend you watch that first as it shows you how to install.
My new project which I aim to get out before august this year (expecting a baby that month) is a SaaS for deploying git repos to servers.
There is plenty of competition in the marking I know, I know but this is really a scratch my own itch sorta product. I have a complex process to deploy projects which requires servers to be working in sync to deploy correctly. Bring down one instance and bring up another all in a defined order which some jobs able to work async.
I have used whats on the market and decided to go ahead and build my own. I have spotted some other areas for improvement to but one thing at a time.
So if your interesting in deployment of code to servers automatically have a look at my new product Auto Deploy.it and sign up for the newsletter.
I have been using/playing with event sourcing in PHP for about 9 months now. I have one site in production and two in development this is what I have learnt and what I am doing now.
When I first started with learning ES I created the setup myself, no packages and no real connection to an event store. Which was good for getting my head around the issue of event sourcing and really Domain Driven Design. From there I imported the Broadway Library. Which was great it took a heck of glue to get it to work with laravel for me. I also used the geteventstore.com for storing events.
Once I had learnt to delete projections and rebuild them from events I was laughing and the real power of ES came out. Its the number one feature for me no migrations!
I then swapped out geteventstore for a mysql version. The eventstore was another thing to manage and build and I had issues with it crashing. MySQL was perfect and I am still using that to sure my events.
But the last most was to write my own Event sourcing library. I have nothing against the broad way package, but it took alot of glue to get it to work and I did not want to keep doing that, So I spend the time and wrote SmoothPHP/CQRS-ES-Framework and a laravel driver for it. You can very easily spin up new applications with ES and get going.
I decided to record myself coding a new feature into my CQRS application. I have property events and wanted to create a event history view for landlords. This is often a feature that users ask for in application, but with CQRS this can be added afterwards using all past events to rebuild and create a new query model.
At the moment I am very new to CQRS and totally open to comments and advice. Hope you enjoy.