The "24 Days in December" project has returned this year, sharing opinions and insights from members of the PHP community, one article posted each day. They've been running since December 1st and there's some great content in this year's batch already:

• How to become a good maintainer
• https://24daysindecember.net/2018/12/09/finite-resources-vs-infinite-knowledge/
• Open Source and Squeegee Men
• A love letter to legacy projects
• How a user group can change your live
• PHP and the secrets of emergent architecture

...and many more. Be sure to check out the full list and keep checking until December 24th of this year for more great articles from this year's 24 Days in December project.

In a new post to his site Tomas Votruba shares his opinions on project structure and when he sees it appropriate to use a "monorepo" and when to use packages to compose your application.

Recently I gave a few talks about monorepo in PHP and how to integrate it to companies in a useful way. I'm very happy to see many people already use it and know what problems it solves.

Before monorepo hype takes over private PHP projects, I think you should know about its limits: When is the best time for you to go monorepo? When you gain less complexity while integrating it? How can you make the transition better? Is it really needed?

He starts off by describing some of the most common application structures including the monorepo, many-repository, and local package approaches. He sees each as an evolution on the previous and shares when he thinks the evolution makes the most sense (hint: it's about value). He ends the post by sharing a few final thoughts about monorepos and when they make sense for private projects versus public, open source projects.

php[architect] magazine has released their latest issue for November 2018: Generics and Project Success. In this issue they feature articles like:

• "The Case for Generics in PHP" by Chris Holland
• "Maintaining Laravel Applications" by Jason McCreary
• "Getting Started With Php? Let’s Start the Right Way!" by Junior Grossi
• "How to Knock Down Any Project in Ten Steps" by Pawe? Lewtak

The usual columns are all returning including Joe Ferguson continuing his series on creating packages, Eric Mann covering five security risks to look for in a code review, and James Titcumb with some resources you can use to continue "leveling up" in your development career.

If you want to "try before you buy", they're also offering a free article, "The Case for Generics in PHP" by Chris Holland. You can pick up a copy of your own directly from the php[architect] site or subscribe to their print or PDF versions!

In a recent post on their own site, thePHP.cc has shared some of their own perspectives about the recent future of Zend announcement. For those that aren't aware, the company that acquired Zend several years ago - Rogue Wave - announced their decision to discontinue their support of the Zend Framework project.

Last week, Zeev Suraski, Matthew Weier O'Phinney, Enrico Zimuel and Dmitry Stogov, all well-known members of the international PHP community, announced that they will leave Zend, which has been part of Rogue Wave since 2015.

The stated reason is Rogue Wave's strategic decision to focus on the development of Zend Server. If you read between the lines, this implies that Rogue Wave is not going to continue or support the development of the Zend Engine (the core of PHP responsible for compiling and executing code), their IDE Zend Studio, and Zend Framework.

Of course, it is perfectly valid to make money off an Open Source project. This, however, implies at least a moral obligation to give back to said project. Rogue Wave, it seems, will now terminate the symbiotic relationship between PHP and Zend.

The author (Stefan Priebsch) talks about "lip service" not being enough when a company wants to make money from customers but aren't willing to help with the development of the underlying software. He also mentions several other Zend-related products that have a bit more quietly gotten the axe over the years since the acquisition. He wonders about the "downsizing" this could cause in the PHP community given ZF's impact and how, despite this being a large setback for the project, he sees its future as promising given the people involved and the projects around it.

On the CoderWall site they've posted a tutorial that's a sort of reaction to the recent Laravel Nova administration dashboard release. In it they point out another project, the Laravel Admin Panel (LAP) that handles a lot of the same kind of functionality.

I have been working on this product on opensource for about 8 months now, and the project has become quite successful. People are actually using it and we are making our goal to make it more developer friendly. [...] According to my experience with people who have used our admin panel and its feature to create a module instantly, they are aloof of the details beneath that architecture and are constantly in need of help if anything goes wrong.

If new developers are made to use some super smart software which just creates everything for them, they are just not very aware of the happenings and end up not knowing anything of how the project works.

The post introduces the project and what kind of functionality it provides including:

• user/role/permissions management
• "page" management
• menu management

...and their "star of the show", the Module Boilerplate Generator that allows for the quick and easy generation of all code required to add a new module to the application (models, controllers, request handling, views, migrations, etc). You can find more information on the GitHub repository for the project.

On the Symfony blog there's a post covering some of the recent improvements in the framework that can help to make creating and updating Symfony projects faster via some recent changes speeding up the Composer installation.

A few years ago, we introduced the Symfony Installer as the fastest way to create new Symfony projects. While Composer took up to several minutes to create a new project, Symfony Installer did the same in less than ten seconds.

The trick was that the installer downloaded a ZIP archive with all the dependencies required by the specific Symfony version you were installing, so it was not necessary that Composer resolved the project dependencies.

However, with the release of Symfony 4 we deprecated the Symfony Installer in favor of Composer, because we wanted to use standard development tools as much as possible. Sadly this made creating new Symfony projects slower and, in some cases, it triggered "out of memory" exceptions while Composer was resolving the dependencies.

The post talks about the changes they made to the Composer installation process, mentioning the two major changes: including a composer.lock to prevent version resolution and removal of all legacy Composer tags. They also share some benchmarks for the installation both before and after the changes showing a jump of at least ten seconds post-changes.

Tomas Vortuba has a new post to his site sharing a few reasons why he thinks that Doctrine isn't dead and is still "alive and kicking" with things still changing in the project.

Almost 1,5 year ago I wrote Why is Doctrine Dying. I didn't use dead, because it's is just state of time being. Open-source projects - like people - tend to find themselves on the top, being stuck or struggling with the right path from time to time. It's a completely normal process of evolution.

I don't know if that post helped it, but since then many things changed for better in Doctrine project. Saying that this post deprecates my old view and celebrate changes.

May this be an inspiration for open-source projects that find themselves stuck and the maintainers that find themselves unhappy.

His list includes reasons like:

• Bump PHP 7.1 Without Waiting for Major Release
• Cut the Weight to Save Yourself
• From Talks and Post Evangelization to Code Improvements
• New Release as a Baseline

For each point, he provides a little clarification and background from commits to the code and statistics about the community around the project.

Joe Watkins has a post on his site sharing a project he has been working on to create a debugger for PHP applications that can be installed easily and understood by those already having knowledge of PHP.

We already have several options for debugging code within the PHP ecosystem. XDebug is extremely mature software, and phpdbg has been slowly gaining traction also, if for no other reason than it's very fast to collect code coverage compared to XDebug.

[...] Debugging is a necessary part of writing code; If you disagree with this statement, then I don't know what you are talking about. [...] Using a debugger is like having an army of nano bots at your disposal, each one trained exquisitely in a top nano-bot-training-camp, they live to kill cockroaches, some of them also have mean looking tattoos, chew tobacco, and spit on the ground at the start of every sentence ...

He goes on to talk about why he made the choice to write the debugger with a PHP interface. He then gets into some of the specifics of debugging needs and links to the krakjoe/inspector repository for the tool. The README has more information about the interface and functionality than the blog post does, so if you're interested to read more, head over there.

As a maintainer of an open source project there are things that can help to make your role easier. One of them is encouraging useful issues being filed on the project with good information about the problem or suggestion. In this post to his site Sebastian De Deyne shares a few helpful hints on what can make for a good issue.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

His suggestions include:

• as much detail as possible ("X is broken" isn't useful)
• having a single point or suggestion per issue
• being polite (remember, open source maintainers aren't often paid for this work)

His last point might be the most important: making a human connection. Sometimes it's easy to forget that there's a real person on the other end of the line. If you work with the person reporting the issue rather than just focusing on the technical parts it can make it an easier and more pleasurable process for all involved.

In a new post to his site Junior Grossi shares some of his thoughts about Open Source and how it's less about "free software" and more about sharing and giving back.

Maintaining an open source project – even a small one – is not an easy task. The open source ecosystem is about sharing and contributing, about giving and receiving. You scratch my back and I will scratch yours.

He suggests that working in Open Source is less about the actual software that's being written as it is a lifestyle. For him, the goal is to make someone else's life better by working on something you're sharing (instead of working on something commercial). He includes a quote from Fabien Potencier (of Symfony) about Open Source developers being exploited for their free software and how, despite the gift of time and work spent on the code, some people don't appreciate the work and just complain.

Instead of complaining about features or bugfixes, do it yourself, and show your gratitude for people that spent their free time working on something to help your life. They could be with their family but no, they were doing open-source. And you should thank them for that.

He finishes with a few thoughts about giving back to the projects you use and enjoy. It doesn't always have to be about code too - you can submit bugs, contribute to documentation or even just write up a tutorial to share your own knowledge of using the package.