Ioncube decoder and SourceGuardian decoder service
A feature that we really needed to make our fiber integration complete is the cancellation of them. Or to be more
precise, the cancellation any awaited promise yielding operations in that fiber and as a consequence the fiber that
those are awaited in. This post goes into detail how different cancelation scenarios work for
the PR introducing it, and was originally part of that PR’s documentation
but was replaced by a simpler section.
One of the things that came up while upgrading packages is PSR-3’s new v2 and v3 releases. They add type hints to
methods and return type hints. For packages implementing this means that they can’t support all 3 versions. For
packages only consuming psr/log all 3 versions can be used as you don’t have to build classes on them.
However, for packages implementing PSR-3 this suddenly became more complex. All of a sudden you need 3 major versions
if you want to support all PSR-3 versions. For a package that only implements PSR-3 this isn’t so much of an issue, but
when the implementation is embedded inside another package you all of a sudden reach dependency hell. And one thing I
learned while upgrading my packages is how deep our dependency on psr/log goes these days.
The mistake I’ve made with at least one PR in the past few weeks is miss that a consumer of psr/log is also an
implementer, and I missed that. So now I get to get back and make a new PR resolving that mess I introduced.
Cal Evans hosts WordPress community leader David Bisset as they talk about the WordPress community.
The post David Bisset talks about WordPress community appeared first on Voices of the ElePHPant.
In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday after the 5th of each month. I am late this month. Sorry.
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 January, I spend my time triaging issues, and planning for this year.
I spend most of my time reflecting on what I can do to make Xdebug even better in 2022, and I have come to the conclusion that this is going to be done through multiple improvements.
Creating an Xdebug Course: explaining in great detail how Xdebug works, how you use it, how you can get the most out of it, and many scenarios on how to set-up debugging in different environments. This needs to go beyond referential documentation pages, and will hence become a combined set of videos and tutorials, with examples and work-along exercises.
Developing an set-up-free debugger: A new tool that can be used through Xdebug Cloud, that would allow you to debug without IDE.
Xdebug Recorder and Player: A new feature in Xdebug which would allow for a full request to be stored in a file, including every intermediate state. Combined with a player, which would allow for replaying the request and interrogating every variable at every point during the execution of said script, through the debugging protocol and interacting with your IDE. The recorded files would be self contained, without needing access to the (original) source code. Besides “step over” it would also have a “step back”, and perhaps even a slider to slide back and forwards through time.
Rewriting Xdebug’s Profiler: so that it is more lightweight, and so that it can be enabled for specific parts of an application/request. In addition to this I am looking at sending the profiling data over the debugging protocol, so that visualisation tools do not need to find and read files.
Creating a profile analysis tool: To automatically analyse profiling files and apply logic so that it can point to the most likely cause of bottlenecks.
Let me know which one of these interests you most, and whether you would be willing to pay for such a tool.
Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release. Packages start at £49/month.
If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.
I did not create any new Xdebug videos this month on my YouTube channel. But as I mentioned earlier, I am working on a more comprehensive course. Stay tuned!
In January, one new business supporter signed up:
Thank you!
If you, or your company, would also like to support Xdebug, head over to the support page!
Besides business support, I also maintain a Patreon page and a profile on GitHub sponsors.
Cal Evans hosts WordPress community leader David Bisset as they talk about the tech of WordPress.
The post Interview with David Bisset appeared first on Voices of the ElePHPant.
Join host Cal Evans as he talks with PHP 8 author and trainer Doug Bierer about PHP 8, Doug’s new book, and all things happening with Doug.
The post Interview with Doug Bierer appeared first on Voices of the ElePHPant.
Last year I had a video call with Tomas Votruba, creator of Rector, who kindly took the time to explain a lot of things about this project. We finished the call and I couldn’t wait to tell my partner how nice it was. I said to her: we should have recorded it, I’m sure it would be useful for other people too. She replied: this is so typical; millennials having a nice conversation and then they want to let the world know about it.
This definitely triggered something. Looking at it like this, she’s right; it’s somewhat of a weird impulse. But then, is it bad? I’m in the business of sharing. Am I doing this because I think it’s somehow important that people know what I think or experience? Honestly, the answer is “no”. It’s just that I see value in code, conversations, and written words and I don’t want that value to be only available for me. So I try to put it in a shareable form and publish it on GitHub, here, or as a talk or workshop. I’ve spent countless hours doing this, and I stand behind this.
Recently I realized though that there are different types of sharing, and that I made some mistakes in sharing certain things as well. Things I now feel really uneasy about.
A short history: I started blogging here in 2011, writing about the then still fresh symfony 2. Back then, there wasn’t a lot of documentation, and I blogged to fill some gaps. Later I published a number of documentation chapters as well. I gained some followers on Twitter, and loyal readers too. I feel silly to admit it, but I had put so much effort in this; I was very disappointed not to win the Best Blogger award back at SymfonyCon Warsaw in 2013.
In that same year I published my first book: “A Year with Symfony”. It was a very honest book. It was based on my experience with Symfony in the past year (fun fact: its original title was “More than a month with Symfony”). The last chapter in that book is called “Being a Symfony developer” where I try to convince the reader to write code that is reusable, beyond the current fashion:
“[…] developing software for reusability has proven to be quite a difficult task in itself. Luckily, there are many principles you can adhere to.”
Therefore, what came next was “Principles of Package Design”, heavily based on Robert Martin’s work on the SOLID principles and the lesser known package design principles. An important step in my own development as a programmer. I was using these principles in my then-current project, to separate utility packages from domain-oriented ones. Packagist was quite young, and people were publishing packages with a real dependency mess (they still do), so I thought it would be good to share those design principles with others. I’m still happy about it, although I’m not a “believer” in those principles anymore. But that’s maybe something for another post.
Something went wrong when I started working as a CTO at Ibuildings. With less and less time spent on programming and working on actual projects, I started organizing workshops as a way to keep learning. Those were great, but I made the mistake of not rooting them in experience. I kept doing this after I left the company, and I even wrote a new book that had the same underlying issue: “Microservices for everyone”. It was a research book, not based on experience in the field. Still, I was very honest about this in the foreword:
“It’s crucial to note though that so far I have not had the opportunity to work on a large microservice system.”
I still think it’s a good book, but I didn’t realize that its implicit message is: this guy knows everything about microservices and now he wants to tell us how to do it too. I think that’s really problematic. And it made me realize my own big mistake here.
“God, give me the confidence of a mediocre white dude” — Sarah Hagi
I started out so humble, ready to put “more than a month” in a book title. I wonder where I got the superfluous amounts of confidence from. Maybe because:
In my humble opinion, none of these things are ever to be considered a sign that “you’re doing something right”. Well, only if your goal is to be an influencer. It doesn’t have a lot to do with experience, or a dedication to learning and teaching. It’s mostly marketing. Well then how do you know you’re doing something right?
For me, the question is: how do I judge advice provided by others? Where do I find good advice?
Truncated by Planet PHP, read more at the original (another 1840 bytes)
ZendPHP for Windows is here, marking the first commercial distribution of PHP for the Windows platform. Get the full release details in our blog.
The one simple trick to do a better job as a programmer is to git commit as if your commit could be accidentally deployed (and it wouldn’t break the production environment…)
Why would this improve your work? Because it pushes for improvements in several areas.
If a commit needs to leave the project in a working state, you need to:
To practice with the latter, I recommend learning about the Mikado method. It makes it easier to recognize prerequisites for the change you want to make, and then forces you to enable the real goals by implementing the prerequisites first.
This process is also known as “making the change easy, then making the easy change”. An amazing result of applying this process is that after some practice you’ll be able to make many, much smaller commits during the day. Each of those commits will leave the project in a working state. To me this always feels great because:
As a consultant I apply this “trick” to trigger improvement of the development process. I like to work with development teams on one of their real programming tasks, as an ensemble. We use a pomodoro timer, and we establish a goal for the “pomodoro” (25 minutes). Reflecting at the end of the pomodoro we often conclude two things:
During all this time we don’t feel safe at all. We don’t have a sense of accomplishment either. Realizing this turns out to be a great starting point for improving the development process.
