Upgrading PHP upgrades – Larry Garfield

Upgrading PHP upgrades

PHP 8.2 was released on 8 December, to much fanfare. And, as always, to much wailing and gnashing of teeth about how the PHP language is evolving too quickly and breaking everyone’s code. More specifically, it was the earlier, twin announcement that PHP 7.4 reached end-of-life on 28 November, as that has, somehow, forced everyone to suddenly rewrite their entire code base in a hurry.

And… while I sympathize with some of the complaints, I am once again left wondering “how?”

Continue reading this post on PeakD.

Larry
9 December 2022 – 3:50pm

Xdebug Update: November 2022 – Derick Rethans

Xdebug Update: November 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 45% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend 30 hours on Xdebug, with 24 hours funded. Sponsorships are declining, which makes it harder for me to dedicate time for maintenance and development.

Xdebug Videos

I have published one new videos:

I have continued writing scripts for videos about Xdebug 3.2’s features, and am also intending to make a video about “Running Xdebug in Production”.

You can find all previous videos on my YouTube channel.

Goodbye Twitter – Matthew Weier O’Phinney

This is a long, personal post.

tl;dr: I’m leaving Twitter.
You can find me in the Fediverse as @matthew@mwop.net.

In the beginning

I started using Twitter because of ZendCon 2007.
Cal Evans had the idea that if folks attending the conference were to tweet about it, those who were unable to attend would get an idea of what the conference was about, get links to slides if speakers posted them, and more; it would both feed FOMO, and respond to it.
(It also became an unofficial way for many of us to organize non-conference events during the evenings.)

Once the conference was done, I wasn’t quite sure what to do with it.
There was a bit of engagement, but not a ton.
Hash tags, replies, retweets, quote tweets — none of these existed yet.
Hell, even direct messages were just a specially formatted tweet, and heaven forbid you get the initial character sequence wrong!
We started creating conventions, many of which later became codified into Twitter itself.

Over the next year or two, I found it became my “virtual watercooler.”
Being somebody who worked remotely, from home, I didn’t have office conversations.
A few of my colleagues and collaborators were on IRC, but back then, that was about it.
If I wanted to talk to a larger group, or somebody not in my regular channels… Twitter became that place.

I made friends.
I got job offers.
I learned about places to visit on my travels.
When abroad, I could coordinate meet-ups with friends.

When I realized folks couldn’t spell my handle, I reached out on Twitter to see if I knew somebody at Twitter, or if somebody had a friend at Twitter, to see if I could change my handle, as somebody was squatting on “mwop”.
A friend of a friend made it happen — and I made a new friend in the process.

That was the honeymoon period, it seems.

The start of the fall

Sometime in the early 2010s, I began seeing the ugly side of Twitter.
You know the folks, the ones who slide into your mentions or DMs when you post an opinion, the ones who ask for receipts and links or push whatabout-isms nonstop until you give in or stop replying (which they also take as victory).
The ones who treat your lived experience as invalid, because it does not match theirs.
The ones who cannot even imagine a valid experience outside their own.
The ones who would not even allow another person’s beliefs, body, heritage, circumstances to exist if they had their way.

Before muting and blocking existed on Twitter, the service was quickly becoming somewhere I did not want to engage.
Somewhere I only felt comfortable posting non-revealing content about things like my open source projects, or retweeting work-related content.
(I haven’t posted anything about my family in years.)
When Twitter allowed you to limit DMs to people you mutually followed, that helped a bit.
But even then, I’d get folks in my mentions arguing or trolling; I cannot tell you how many times I was told the projects I worked on were crap, should die in a fire, that I should be embarrassed to even share them, that I should quit and get a different job, preferably in a different field.
And this is only a fraction of what I see in the replies to women, people of color, LGBTQ+, people with accessibility issues — where the very act of existing as who they are is evidently an egregious offence.
It’s easy to see why so many leave the service, even though it can be hugely powerful at connecting you to others in your chosen community.

With muting and blocking, the service became more bearable, but only barely.
I’d still get the tweets, replies, and quote tweets, but now the first time somebody spewed vitriol at me, it would be their last.

But I still had to see them at least once.

Crumbling

And then 2016 came along.

I am a liberal.
My wife and I laugh at the assertion that you become more conservative with age.
If anything, we’ve become more liberal.

And the run-up to the 2016 US elections broke us.

On Twitter, I was seeing either tons of right-wing hate spewed by folks, or reactions from others to that hate.
The few times I addressed it were horrible; the amount of vitriol in my mentions shocked me.
Some people have the energy and mental reserves to fight back.
I’m not one of those; I internalize the attack, and it replays in my mind over and over.
It tears me apart.

So following the election, I started pulling back.

I created a couple lists that I’d check daily, mostly those of authors or artists I like and admire.
This created a little oasis for me, and made things somewhat manageable.

But here’s the thing: we are all political.
Living in a society means we engage with politics.
And this meant that, even following creators, I was still seeing politics; the po

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

PHP 8.2.0 RC7 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.2.0, RC 7. This is the seventh release candidate, continuing the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.2.0, RC 7 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the production-ready, general availability release, planned for December 8th 2022. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

Dealing with technical debt during the sprint – Matthias Noback

It’s quite ironic that my most “popular” tweet has been posted while Twitter itself is in such a chaotic phase. It’s also quite ironic that I try to provide helpful suggestions for doing a better job as a programmer, yet such a bitter tweet ends up to be so popular.

Twitter and Mastodon are micro-blogging platforms. The problem with micro-blogs, and with short interactions in general, is that everybody can proceed to project onto your words whatever they like. So at some point I often feel the need to explain myself with more words, in an “actual” blog like this one.

Waste in scrum processes

Hypothesis: the moment a team adds the requirement that each PR/commit should be related to a Jira issue, it will start accumulating even more tech debt than before.

We notice that one of the dependencies of our project has been marked as “abandoned” and we need to upgrade/switch to something else. When helping a new co-worker join the team, we find out that some crucial steps aren’t documented in the README. The test framework hasn’t been updated for some time, and upgrading means we have to rewrite some test setup code.

These are things that just happen to our projects from time to time. Many developers won’t go ahead and make the necessary changes. Being part of a “scrum process” they will:

  • Create an issue in the backlog
  • Bring the issue to the attention of the decision maker
  • Wait for the decision maker to assign it to a future sprint

Finally, once the issue has been assigned to a sprint, it needs to be refined. So a group of people that is often too large starts to talk about and describe what needs to be done. Why? Because scrum tradition prescribes that every person on the team should be able to pick up the issue. I don’t think that’s true at all; we’re just wasting time explaining everything to everyone, while often only 2 people are going to pick it up.

In the end we have to vote for the number of story points that we’re going to assign. This magic number has no specific meaning. If we try to describe what such a point represents, we get different answers, even within the same team:

  1. “It’s definitely not how much time we spend on it” (because we don’t want it to be an estimate)
  2. “It’s how complex we think this is” (unfortunately we all have different ideas about what “complexity 3” means)
  3. “We can do about 50 points of these in each sprint” (so it is an estimate after all; given we have two weeks, we can do 50 of them, so each point represents 2 weeks divided by 50 of our time)

Don’t get me wrong, it’s good to think about how much time something will likely take and use a rough estimate to decide if you want to start working on it. It’s just that we are guessing, and we can have huge surprises while we are actually doing the work. Or the opposite happens: we are over-complicating things in the refinement stage and it turns out the actual work was so easy, we get 5 points for the price of 1…

In both cases, a big part of the preparation phase is just a waste of time and energy. I’m certain that many scrum teams could do much, much more if they would let go of wasteful practices like those that “official scrum” or similar project management techniques prescribe.

How to deal with technical debt in a sprint

Back to the original point about technical debt. From time to time developers will notice something about the code base that really needs to be improved, something that is not part of any feature anybody is working on, just “general maintenance” or “developer experience”, and so on. Developers need to do this work because they have to battle the forces pulling the project downward. If they do not continuously do that, one day the project will be beyond repair. Yet, the scrum process prescribes that no work be done in the sprint that is not on the board. So an issue has to be created, and we jump back into the project management waterfall.

At this point a developer have several options, each of which appeared several times in the comments to my bitter tweet:

  • They can follow the process because they have to. There are strict requirements, maybe an ISO-standard, that have to be enforced. No way around it. So first they create an issue, and wait for it to be assigned to a sprint.
  • In some teams they wouldn’t have to wait, they can pick it up inside the sprint. But only if it’s small, “a 1” or “a 2”, because more would “endanger” the sprint.
  • They can play the process, and do general improvements as part of the current ticket they are working on (but these are now unrelated changes).
  • They can commit t

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

PHP 8.2.0 RC 6 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.2.0, RC 6. This is the sixth release candidate, continuing the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.2.0, RC 6 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the seventh release candidate (RC 7), planned for Nov 24th 2022. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

Xdebug Update: August, September, and October 2022 – Derick Rethans

Xdebug Update: August, September, and October 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 45% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

I did not find the time to write this report in the last two months, sorry for that. So today I present you with a report for the last quarter.

In the last three months, I spend 63 hours on Xdebug, with 77 hours funded.

Xdebug Videos

I have published two new videos:

I have started writing scripts for videos about Xdebug 3.2’s features, and am also intending to make videos about “Running Xdebug in Production” and “Debugging Worker Tasks with xdebug_connect_to_client()”.

You can find all previous videos on my YouTube channel.