Talk in English - UK at PHPSW: Turbocharged Development, November 2020
Short URL: https://joind.in/talk/11eb3
(QR-Code (opens in new window))
My name is James, and I have a confession to make: I’ve been a var_dump()er my whole life. I tried Xdebug once years back, but a chance brush with social media from it’s author prompted the question: is Xdebug still relevant? Is it hard to set up?
In a modern developer world of Docker containers, code quality tooling, CI pipelines and advanced IDE’s, it was time to revisit how we go about writing Software at Jump24 - in this talk I’ll set up Xdebug on a test project and show you how you can turbocharge your development like we did.
Comments
Comments are closed.
Good talk, and more people should use xdebug.
Couple of suggestions for improvements.
The 'how to setup Xdebug' section might work better as a blog post, and youtube video. The problem is that even if you convince someone to setup xdebug, they're unlikely to remember all the steps from this talk, and would need to list en to it again...so you could do a really high quality version of those instructions, and refer people to them.
I think there are two things that could make the 'examples of using xdebug' section be easier to follow.
First, give a list of things you're going to cover, like: 1) Inspecting variables 2) Stepping through code 3) Doing performance analysis.
Then for each of the sections be really explicit and say "okay, now I'm going to talk about inspecting variables" at the start of that bit, and then at the end of that bit say "okay, that was how you inspect variables", and then take a pause ofa few seconds. Having a clear break from talking allows people to 'reset their brain', and makes it easier to follow the talk. Currently each bit flows into each other, which is tiring. Just a few seconds reset makes it easier to avoid fatigue.
Second, people remember stories more than they remember tech. For each of the capabilities of what Xdebug can do, it could be good to say a little story of what would be happening that would cause you to choose a particular technique to debug it.
So for example, if you said something like "I got a report of a bug, and I could see that the bug was coming from a particular controller, and I can even reproduce the symptoms of the error, but I had no idea what was causing it. I could go through and put var_dumps everywhere, but this is a good place to step through code. As I know which controller has the problem, I can put a breakpoint here and then step through the code" then go through what/how stepping through the code works.
I think people would find it easier to remember, "if you know which controller has the problem, setting a breakpoint and stepping through is the thing to do", even if they don't remember exactly what 'stepping through code' means when they encounter a problem suitable for it.
Minor point, it might be worth making a docker repo with non-framework examples for each of the different things. I found the references to framework specific stuff a little confusing, as I've not much experience of those. And giving people example problems they can practice on, is more likely to get them using it, rather than if they can only practice using Xdebug when they encounter a problem at work, when they would be under time pressure to get stuff done.
Oh, also I think you might need your microphone closer to your mouth....volume was fine, but the sound was a little harsh at times.
Er, that is probably enough words.