>> Chris: Hi, everybody. I'm Chris weber, a Drupal developer. Based in Chicago, Minneapolis, and also phoenix. I have given this talk at Midcamp a few times. I love giving this talk. It's about tools. This talk, I have cut all the way down to a half hour. There are a couple of other slides introducing myself that I cut out. So let me add those verbally here. I love development tools. I love eeking out the last bit of performance. I went through levels, kind of like these levels and learning and leveling up my skills because of the development tools. I started out as a dot net developer, worked visual studio. Started a company with a buddy of mine making websites with ASP.net, all because I had this fascination with learning how to make sites in no man's land. I didn't have a debugger and couldn't use the same things I was used to. And then I found development tools like PHP Storm that were able to give me back the things that I felt were my super power. And so that's one of the reasons I'm excited about giving this talk. If there were people out there that have untapped potential because they want to use the tools that are available to maximize their skill, then it's about time somebody reached out and helped try to show all the things that could be, things that you can add to your normal development daily life that could maximize your skill in solving problems.
These are the main four pillars of the talk. Things that we will talk to, things that could help your ability to discover things about your code. Things that can reduce the amount of time it takes to do a task, time and frustration savers. Things that can expand your ability to learn about your code. Digital detective skills, finding answers. And then finally, and I feel most importantly, making sure that you don't have to adopt to the tool, but making sure the tool adapts to you. Okay.
Before I really begin, I want to be sure that everybody in here knows that if you've got a question or if you want further clarification, if you've got something you want to add to the conversation, feel free to unmute, to type into the group chat, to raise your hand, to do whatever you need to do in order to get my attention and add that right then and there to the talk. We will have a lengthy question and answer at the end. If you want to wait until then that's totally fine, too. But feel free to make this an interactive talk. Thank you.
All right. Discovering your code. Modern IDEs like PhpStorm are seen as heavy, because they do a lot of work to index everything they can about your code. This is trying to gain an understanding of the landscape of your code and everything that's in it so when the time comes and you need to know something about something that's in your code, it can get that answer to you quickly. This indexing phase can be resource and time intensive. And for that reason, a lot of people like using more lightweight tools like VSCode. VSCode is a very great tool. And it can provide a lot of the same insights. One day there will be a version of this talk that includes all of his knowledge about VSCode. We will wait for that day to come. That indexing of the code can come in the form of Intellisense. That is a prompt that I pointed to in the screen shot. Can everyone see the screen shot? Yeah? No one said they haven't. Thank you, Walter! And when the Intellisense comes up, it is like here are all that are available to me in this method, in this context. And it knew about it because of the indexing phase. PhpStorm is known for the shift+shift shortcut to find anything anywhere. This prompt shows that you can specifically look for classes, files, what they call symbols, but really any method that is In there, even things in the IDE like the actions or preferences that are available or an action that is there.
Everything that the IDE knows how to do available in a prompt. If you want to specifically search for a kind of thing like just want to search for files or classes or methods, if you can have a keyboard shortcut for that, too. I am fond that Mac and PC Linux shortcuts, they are a little different for Mac versus Linux and PC. And one last thing, this prompt, you can toggle between the different tabs if you press the shift command square bracket on a Mac. That's a common way of switching between tabs for any prompt that's in PhpStorm.
Parameter hints. Hints are super great. If you've got a method and you don't know what type of variable you need for each one of the parameters, or if you're like, you type the first parameter and you forget, you can use parameter hints to tell you what to expect. And you can do that by pressing command or control key. In this case, I didn't know that account was AccountInterface. I should have known. I would have known if the variable was called AccountInterface, but I didn't know that and the hint was helpful.
Go to definition. Is this actually going to work? This has only worked once.
Wow. Oh my goodness. It works. This hasn't worked for years! Go to definitions is a very common operation. Any IDE worth its salt will have go to definition. In that video, and I can play it for you again and try to narrate it for you. I wanted to find out what code is in queue. And it was able to show me that whenever that queue function was found, that it's actually calling something from the container. And that should have been a hint for me to know that I could bring in that object through injection. And then I could get to that method, the get method for the queue. And all of that is adding to my knowledge of the code, you know, like if I had any function and I want to find out where the problem really is, I can step through the trade of complexity for my code. I can use command B or control B to get to the definition of the any method. And if I do that operation, and it doesn't know how to find the definition of that method, then perhaps I haven't defined it. Perhaps this is something I'm just coming back to code that I wrote. And I forgot, oh, the reason why my code is breaking is because I wrote this method thinking I was going to, like, write the definition of it later. And then I forgot to do that. And I just haven't set it up to know about the code. All things are clear signs there is a sum of a problem with the code. And unmasks the confusion that I'm having about what was going wrong. Next up. If that works, then maybe all of my videos work.
Find usages. We have go to definition where we were able to find a method and step into it. Find usages is kind of like the opposite where if you have a method, it looks like this queue method. I get this prompt at the bottom that shows me that the method was used in the aggregator module. So like ‑‑ so that can just add ‑‑ that's another detective skill that you can add. You're get an error. And that method is queue. And I don't know the story about what happened before that error call happened. Maybe the problem isn't actually the queue method, because queue is a part of Drupal core. Maybe I'm not giving it the right parameters. Where will I put the break point in order to find out what the heck is going wrong? And in order to find all the places where you could put that, you could put find usages in order to, you know, put a break point in every one of them. Or you can call stack to give you a hint on where you could put that break point.
So time and frustration savers can get you to solve your problem faster and give you a sense of confidence that you're not doing worthless stuff. You're not spinning your wheels on stuff that take up your time and try to get you going. Solving problems faster. So I'm an emacs user. I know there's a holy war. When I was in college, that's what we used. Everybody just had to learn those crazy keyboard shortcuts. Thank you, Roger. And so, we got some crazy super heroes in that room. People who were using it for calendars. There was like an AI psychiatrist BOT that somebody wrote. They had that there. They were able to read their e‑mail with it. All kinds of crazy stuff. But I started seeing very early that there are people that just never ‑‑ they really liked their tool. They never want to leave that one tool. They want to use that one thing for absolutely everything. There is a little bit of wisdom to that. In PhpStorm, they figured out a way to shoe horn a terminal into that. That, I was able to get to work not just for macs. It's very easy and clean in order to get that in. But also for windows where the terminal that you really want to use when you're doing Drupal development is like a post fix Linux‑like terminal. This is something that has its own preferences. And you are able to get it working right in the IDE. The benefit is many fold. You can hard code your get commands right in the terminal without having to switch your context from the code, without having to go out to another program. Still, many people like to have one program for one bit of work. But in my view, having everything in one thing saves time and frustration. Cleaning up code. We're having to do a lot of this. We're having to scan our Drupal 8 modules and get it ready for Drupal 9. There's a lot that we can do. Where everything pretty much starts is the knowledge with the IDE can have about your code and pointing out different things that are wrong. We see that a lot with the different color codings that show up in the right gutter. Many IDEs do this. If you want to get a detailed report of everything that could be wrong with your code, when you tell PhpStorm to reformat your code, it does it based upon the rules you set up. The Drupal extension sets those rules based upon the style. The linting files that are now included in the Drupal code base. This might be where I need to jump into the IDE in order to show this. Yep. So you can enable Drupal integration. When you do so, it is set up how the IDE is supposed to work. But with a Drupal specific PHP. One of the things that it will do is set the Drupal style. You can even do that manually if you were to go to PHP and set it to Drupal styles. But it will just know about all the different ways that Drupal likes to space code. I don't think that anyone is still keen on tabs. But yeah. And if you were to just write your program and then use the format function or reformat your code, it will automatically tell you. By the way, was everyone able to see my IDE when I flipped over? That's important. Thank you! All right.
I have no idea where every app does not have clipboard history. It is such a useful feature. If you were to copy multiple things to the clipboard, it won't just forget the last thing you copied. And if you press shift command V, you will see a list of all the things that you have copied to your clipboard and you're able to tell it which one you want to paste. The number of things that it contains is configureable. I think it's initially set to seven. But you can maximize that number as much as you want. So when you're working with your code, you can benefit from this clipboard history. And then there are all of PhpStorm's generators. Its ability based upon keyboard shortcut to just put in a whole bunch of code for you. Wait. That's not what this is. This is updating a doc block. I think I deleted the video here because I lost faith that I could ever make those videos work. So imagine, if you will, a method to add a new parameter. If you pressed option enter on a Mac or alt enter, you will get it to know what type of variable you are putting in there, properly type that variable as a parameter to your method, and basically do some good work for you. It will update both the method and the doc block. But, the IDE can help you make sure that your doc blocks are updated. I don't have faith in this one. Okay. Looks like now that I know that video can possibly work, I will try to redeem this one later. Oh wait A here it is! I used to work with somebody who would not use any tool unless it had a scratch pad. And a scratch pad is a file of code that you just want to paste something into, and if you have typed something that is improper or incorrect, so all of the code scanning rules and the roles apply to it. It is not actually a part of your project yet. It's not a real file. It's just in memory. And PhPStorm made it better. A scratch pad can make that in your project in this group of scratches and consoles. And once you create a scratch pad, you always have it until you delete it. I don't know what this was for. I think this was fiddling around with code. As you can see, it understands that the scratch pad is a PHP file. If I open up a different project and I have this scratch pad still, I have scratches from all kinds of stuff. You can rename these scratches so if there is something important that you want to find later, you can actually find it. You can even search your scratches if you want. The only weird thing is that the name for it is just super low effort in figuring out a naming algorithm. I could have named these whatever I wanted to when I created them. They just weren't important at the time of creation. They were important once I paste code into it and I figure out that it's something that will work well. So that's cool. I love scratch pads.
So complying with code standards. We talked about the Drupal extensions. The coding and formatting standards are there, which is great. The Drupal extension also allows you to dynamically search for something in the Drupal API. You can highlight a bit of code and then you can use the search in Drupal API method, and it will open a web browser to API.Drupal.org about that method. Which I find is ‑‑ it has been really helpful some of the time. As far as that search with Google, if it's like I'm trying to highlight a bit of code that isn't a part of the Drupal project, maybe it's a part of guzzle or something like that, it is super simple just to switch on over to your browser and copy and paste a method. But I don't know. I just find this nice. Knowing that your IDE is, you know, helping you out. So passive scans are a part of daily life when it comes to checking to see if your code is ready to connect. The IDE wants to make sure it's super clear. It also, on the right, they show basically a color map of the entire file in all the places that could be problematic. The ‑‑ when you hover over the different areas with colors ‑‑ I will answer your question as soon as I finish this up. So if you put your mouse over those colorful sections, it will give you a little summary of the error that it found of the warning that it found. So you're able to quickly filter out what things are important to what things really aren't important. Or what things are your fault. That's the way I found it.
So it has over 100 inspections that by default should be turned off. And if you want to go to preferences and search for inspections and there they are.
One of the things that I manually turn on is the code sniffer inspection. And I have to specifically make it work for Php and INC files. Cool. If you can tell me when you get it working, I am very concerned if you have it working or not. Doug is asking, is there a Drupal profile? I see what you're talking about. You're looking at profile at the top. And it says project default. So, I mean, this was just what they call a profile is really just a collection of different configuration items. They wouldn't have a Drupal‑specific profile unless you manually created one for yourself. It doesn't ‑‑ I think what you're asking, Doug, is does PhpStorm enable a Drupal extension, does it know which one of these to turn on and off? It doesn't really go to the level. It just does ‑‑ I guess the people don't see anything wrong with just having it turn on with standard stuff.
So what do you do with false positives? The main thing I wanted to show here was that if you manually enable Php code sniffer, there are a lot of things working for you. If you have a project that has the coder module, then it will automatically teach your project all of Drupal's specific code sniffer rule sets. And then you can enable Php code sniffer and tell it to process Php and other files. Php storm typically does not allow you to pick more than one rule set.
A way to hack it is to jump into the terminal. And then right here in root of your project, there will be a folder called idea. This is the folder that ‑‑ Php creates. I don't think they want to hide it, really. In that folder is the inspection profiles folder. And there is just one file called project default. If you look at that file, I don't know if ‑‑ do I need to make this text bigger? Can everyone see this? The line that we care about is right here where it defines the coding standard. And you have to manually edit this to be Drupal.Drupal practice. Thanks, Doug. With no space.
If you do that, then you force it to obey what you want being able to have more than one rule set. I'm laughing because this was very frustrating for me for a very long time. But once you get that running, you can press shift option command i to get an inspection name. And then stype sniff to find the code sniffer. And then you're able to tell it when it runs to run on the whole project, a custom scope, which we can talk about if you're interested. Type of file extensions to run it on and rule sets to run it on. Let's send that to the background and check on it later to see what it finds. Any questions about that?
Let me remind you, you can unmute and ask your question verbally if you want.
>> I do have a question about that.
>> Okay, Roger.
>> Is that somewhat redundant with the inspections in approximate PhpStorm.
>> I like how you use the word "somewhat," because yes. It is somewhat redundant in that PhpStorm can run general inspections on your code. But if you're using a project that use precommit hooks or use, like, code formatting sniffing, linting on your Php code through continuous integration build or processes or something like that, you don't necessarily care about if it's approximately the same kind of inspection. You want to know if you're running the exact same kind of inspection. Because the question you're really trying to answer is, if I commit this am I going to break the build because of that? Or is this ‑‑ is my pull request going to be rejected because it didn't pass the linting test? So you want to run the same inspection.
>> That helps. Thank you.
>> Yep. All right. Let's keep going. File health check. That's probably what I just showed. If you want to run all of the inspections that PhpStorm has on one file, you can run a health check by pressing shift option i or control alt i. And then let's do that. It doesn't even prompt me for anything. Oh wait. You do need Php CS. And if you have code brought into your project via Composer, I believe it does have a little dev dependency. It was able to tell me that I have a method that doesn't have a return statement. Probably the code declare that there is no return statement for this method. Everyone understand that? Run all the inspections at one time. Okay. Moving on. Never have to leave PhpStorm again. I mentioned how my eMacs training has made me have an affinity for never having to leave my tool. That is true with all of the get tools that are available in PhpStorm.
All right. Luckily I have a video, which I should make full screen. I should be able to do that. But in PhpStorm, I just did a command T to pull most recent changes here. And I was able to get
Probably the best thing about PhpStorm and where it is today is they have consolidated the window that shows up when you do a commit. You're able to have everything in one place here to see the files that you're committing, the place, the box where you can type in your commit message, and you're able to see the branch you're committing to. You can use the bottom right‑hand corner. So there is a local history. And it just gives a history of every individual file, whether you have committed that change or not. And you're able to go back to a bit of time where your code was. If you're like me and you just said, well, that's an idea that didn't work. Erase it all. And then you come back in the morning thinking about why did I get rid of that? I was going down the right path. You can go to your local history and find out what the code looked like before you removed it.
It is able to recognize this. All the NPM commands that are in there. If you have grunt to drive your build process. It can recognize those files. You tell it to see those tasks, and it opens a little panel on the side where you can just double click on it. Just run it right there in the terminal. And that can be helpful sometimes because if you're working on a project with really smart front‑end developers and they create all of that stuff for you, you don't have to bug them about tweaking that or how to run it. It just shows up and then you can run it.
Ah, favorites. Are we back? Or back? Okay! So favorites are super awesome. And I discovered them really late. But, just like creating bookmarks and your IDE, you can right‑click a file and say add this to my favorites. And then it'll show up ‑‑ there you go. So you would do this if you had a bit of code that you know to be problematic. I'm going to add it to my favorites so I can open it as quickly as possible. If you want to go back to that in the future, maybe fixed or whatever you're trying to fix. You don't want to hit that break point again. This is a really quick way to be a catch‑all. Here are all the files that I'm caring about right now. I want to not have to hunt for them again, so here they are.
Digital detective work. We have talked about this a little bit. But let's talk about the real core skill of detective work, and that is debugging. This was the reason I chose to use PhpStorm. I was trying like heck to get any debugger to work. And this is the first place I ever got it to work. I didn't get it to work with clips.
It is helpful because it has been for many years, good browser extensions that allow you to go to a web page and send a cookie that is supposed to trigger a debugger to work. What PhpStorm's documentation will tell you is all you need to do is get one of the browser extensions installed on your browser and find the phone and pick up the phone and you're done. That's what I want to talk about is the weird problems, the edge cases. If this works for you exactly like this, that's great. I'm happy for you. But I remember all of those times that didn't, and this is for those situations. The very first thing you need to see is if you're working with a code base or a Virtual Machine that knows that a debugger is working. So you would go to your PhP ‑‑ I'm pointing to the screen. I don't know why. A screen shot doesn't do it justice. So you just search for php. And should be able to go down to language and frameworks. And so this is what you typically see. This is basically the default setting. It defaults to php version 6. It informs all of the generic PHP code inspections. It already lists one that it found. Let's find out why it thinks that exists. It exists because this is my local PHP. That's great. But I'm not using local PHP. I am using one from my machine. It discovers a vagrant instance. It logs in and finds how to connect to it and where the PHP is there. So if I click okay, it should create a new CLI interpreter. And it does not think that it has a debugger working, which is weird for me. I thought it did. This is a clear sign that you need to log into the Virtual Machine and to get it working. I wonder if it's in the right one. It is able to tell which version of PHP it's got. Might as well set that and how to connect to it and all of that. So that is what this slide is about. Having to be able to tell your IDE how to communicate with your PHP. When it's doing debug actions, it needs to know, you need to know that you've got the debugger working.
>> Just one comment. PHPStorm does not talk to the debugger; the debugger talks to PHPStorm. And people need to understand that.
>> Oh, that's a really good point, Randall. Thank you. Yeah. PHPStorm is really just listening for those debugging messages. So I think that's what you mean, right?
>> Yes. XDebug is initiating connections to PHPStorm.
>> The browser, when it shoots off that cookie is basically telling it, hey, be vocal. And I think that makes the icon relevant. Because it's just a phone. Pick up trying to license to the debug messages. So...
Are there other very helpful things when you're trying to figure out if your debugger is working? You can tell the IDE to break at the first line of PHP scripts. If you put a debug point down in a specific point of code and it's not navigating, you should check to see if it's going to hit any break point. Okay. So this is where I would normally jump into and hit a break point. I got the warning from Doug that I've ogot ten minutes left. So I'm going to skip that for now. Although I really want to do it. And and make sure that I have got time for your questions. I was looking for a tool that could perform my queries and PhpStorm's database console can do that. You can highlight a bit of code and have it format based upon the rules that you set up. You can have it connect to your Drupal database that you're working with in your Virtual Machine or doc instance and setting up that CLI is also setting up how it communicates to your machine machine or Docker instance. I work with setting up telling it how to log into your machine. And another part, once it has connected to a Virtual Machine, how to log into the database server. So pretty much the same way that ‑‑ pretty much the same way that you you do it here.
And this is ‑‑ I don't know if you have been able to see it while we have been going along, but we were able to get a scan of all the tables that are in there. And have it refresh and you can go to key tables like node if you double click on that one, you're able to see all that the content you can have it have intellisense so it knows about the tables and columns that are in it. And then you can tweak your query until you have got something that you can really work with. Sometimes the problems you have to solve are directly with the data, so we have to go there sometimes.
All right. Adapting the tool to you. Who was it that was talking about keyboard shortcuts? You can tell it to have any kind of keyboard shortcut that you want, and that's part of the key map that you can find if you search the preferences for key map. And there you can search for any kind of keyboard shortcut you want. Run inspect code by name. See if you could do shift option command W for Walter. That's already assigned so something else, but who cares? Now I get the inspection prompt to come up. So that's super cool to me that it, you know, if I have a way of working, then I could have this is the most annoyingly helpful plugin I have ever found. The most annoying one is the first one, key promoter. If you do any kind of action of your IDE three times in a row with your mouse, then it will ask you if you want to create a keyboard shortcut for it. I just found myself doing that over and over again. You can also move the control panels around and where you are welcome to. If you like your terminal super vertical, you can move that over to the right. They give you a lot more options these days. That's an old screen shot. And I'm at the end. Randy, I'm reading what you wrote me now because you wrote a paragraph.
>> I would be happy to get people actually working with debug themselves.
>> Randy, you may not remember this, but many years ago you flew out to the twin cities and gave me so much knowledge about debugging Drupal. And here I am giving a talk glazing over debugging Drupal and I feel a little bit embarrassed.
>> You shouldn't feel embarrassed. The thing that I learned was about the scratch pad. I didn't know that was in there.
>> Yeah. Probably the best asset is that they're always with you. You create a scratch pad once and you have to actually get rid of it.
>> One other great thing I would like to say about PhpStorm is if you work in multiple languages, all the jetbrains tools are exactly the same. I work in Go all the time, but when I switch over to PhpStorm, everything's the same. I don't have trouble. VSCode is good that way, but not that good. It's amazing to be able to work in multiple languages and have the same expectation everywhere.
>> I was going to try my hand at using the ideaj or IntelliJ idea which is the thing that has all the things, which is super nice.
Kyle asks do debug break points work in twig? That works out great. I love sublime. But switching programs so ‑‑ is something I'm trying to avoid. It is a keyboard shortcut for creating a scratch pad, and that's shift command M. It's super quick and easy. There's no ‑‑ it's almost as fast as switching to a different application.
Doug, are we about done?
>> We have two minutes left. We do have a hard stop at five past, so if people don't mind, we can go to 12:05.
>> Okay.
>> Keep dropping that knowledge. I gave this talk in phoenix a month ago. Somebody brought up the fact that you can create your own generators. And that's a part of PhpStorm. He's not here to show. And I forgot to write it down. There's a lot of power in PhPStorm. On a daily basis, I'm looking at the there's also the report that the key map referenced that you can get right from the IDE. I think it's called the productivity guide. Okay. Roger has a question. At this time, can you show us what the result of the code sniffer inspection was? Probably would have been thousands of things. Because we ‑‑ Drupal code base does a good job of following its own code rules, but there are some things that are off, and there are false positives. One of the things that I do a lot, especially these days is you can use an inspection to scan and contribute that back to the module. It's still helpful. And there are other command line tools to scan Drupal 8 modules. The more we have ready by launch date, the better. I would like to thank everybody for adding to the comments. If you see this video recorded later, you probably won't see that text, but there are a lot of people offering a lot of helpful information. And thank you all for coming.