How to setup VSCode launch.json for Xdebug version 2

I had to make some maintenance on a web application using Yii 1.1.4 framework running on PHP 7 and for that, I set up an Ububtu 18.04 LTS Desktop on a virtual machine. 

After the usual bunch of "apt-get install" commands and a few configurations, I got the new development environment up and running having Visual Studio Code as my IDE.

But, almost as soon as I got it running, I got the need to step debug it. For that, I went to Xdebug, I installed it via "apt-get" and configured it, but it was not working as expected.
I check the configuration parameters and give it another try. No go. Xdebug was installed, PHP was recognizing it on both cli and web, but it was still not working.
After a few seconds, I spotted the issue: it was a Xdebug version 2!

A lot has changed between version 2 and 3 of Xdebug.

The thing was that I wanted to keep version 2, and for that I had to configure "launch.json" file and Xdebug in the appropriate way.

On PHP configuration file:

zend_extension=xdebug.so
xdebug.idekey=XDEBUG_VC
xdebug.remote_port=9003
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

 

And on "launch.json":

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
       
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 0,
            "runtimeArgs": [
                "-dxdebug.remote_autostart=yes"
            ],
            "env": {
                "XDEBUG_MODE": "debug,develop",
                "XDEBUG_CONFIG": "client_port=${port}"
            }
        },
        {
            "name": "Launch Built-in web server",
            "type": "php",
            "request": "launch",
            "runtimeArgs": [
                "-dxdebug.mode=debug",
                "-dxdebug.remote_autostart=yes",
                "-S",
                "localhost:0"
            ],
            "program": "",
            "cwd": "${workspaceRoot}",
            "port": 9003,
            "serverReadyAction": {
                "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started",
                "uriFormat": "http://localhost:%s",
                "action": "openExternally"
            }
        }
    ]
}

The default port is 9000, but I'm used to have Xdebug on 9003, so I reconfigured it. The remaining parameters are, basically, the version 2 way of activation the debugger on a request.

./M6

Debugging in PHP with XDebug

Debugging in PHP does not necessarily mean "print" or "log" debugging, even if one's using Lampp.

While checking out how to set up a good Joomla! 3 development environment, I've learned how to set up XDebug and configure it for PHP debugging.
Just check the correct XDebug version numbers and don't just "copy-paste" the settings.

./M6

Debug Email in Web Applications

Email debugging may be painless.

This simple technique shows how one can do it in a very simple way.
It aims at Django applications, but the first technique is actually a generic one that anyone can use if Python is installed in the development machine: Debugging email on Django application development

./M6

.Net Reflector

During a set of web systems migration, things went very wrong and a customer requested me help in setting the systems up again.
One of the systems was developed in the .Net platform, not one of my strongest technologies, and C#.
He was getting really desperate when I started helping, because there was already one technical person looking at it for almost two months...

We performed "pair debugging" in the production environment, since there was no development nor quality environment available.
One of the first things I've detected was that the application that did not work referenced another application, which was not available. Fortunately, that project was available as an assembly, so all that was required was to include the assembly in the configuration file and we were ready for the next challenge.

The next challenge was not easier to detect, since the errors reported mentioned a missing log directory. The problem, though, was not caused by the missing directory. Any error that occurred was logged, but since the log was not working, it reported a directory not found.
Scanning the configuration for the debug location, we tried "./debug", expecting that the debug directory to be relative to project. Unfortunately, that was not the case!
The debug was managed by the previously stated external project, so I needed to see the what the debug code was doing in order to understand how to solve the problem.
The solution came from .Net Reflector, a great tool that allows one to open a library and navigate through its source code.
After a while I was able to understand how the debug file was being written. The programmer that coded the open debug file function was lazy, in a pejorative sense, was did not account for a relative path, forcing one to configure the debug file location with a full path statement, which is not straightforward when one is using a common web hosting service...

Fortunately, soon after, I was able to discover the full path for the application, so we specified the debug path as "c:\..." and things start rolling.

If it wasn't for .Net Reflector, I would have taken a lot more time to find out why the "./debug" value was being ignored and the debug file was trying to be written in "c:\windows\...".
It's a great tool for all serious .Net developers, I truly recommend it.

./M6

Debug in R

Development in R usually is performed using JGR, or Tinn-R, editors and the R console.
Since these are no IDEs for R development, this is usually the best one can have.

So, how does one debug a program in R?
The usual answer is: with print.
But the correct answer is: using the browser()function.

The browser() function works as a break point marker.
Just write browser() where a break point is needed and run the program.
When browser() is interpreted, the program hang its execution and a new command line prompt will be provided, Browse[1]>.
This command line allows one to interact with the variables available in the scope where the program is temporary hanged.
This debug command line accepts the following debug commands:

• n: next, advances to the next line, allows step-by-step.
• c: continue, continues the execution, until the program ends or a new browser() function is found.
  
• traceback(), shows the stack trace function call.
• Q: quit, stop the program execution.
  

It does not look as cool as using the mouse to insert a break point on a line, but it works.

./M6