Last Thursday was rough. If I were to explain everything that went down both with my computer and my personal life, you’d think I was making the whole thing up.
It’d be like the adult equivalent of “my dog ate [the last month of] my homework.” Or something like that.
First, as far as my personal life is concerned, this has nothing to do with the well-being of my family. Just a local debacle of waiting two hours during the workday to get something handled. Irrelevant other than, you know, taking a hefty chunk out of a workday.
Secondly, the computer stuff can all be summed up easily: There was a completely pathetic series of unfortunate events that led to its demise. Essentially, “I killed the car.”
So I had to order a replacement in short order (which is not something I wanted to do), had to have to delivered the next day before noon (which is not something I like to pay for) nor is it something that I had planned as a business expense for at least another year or two.
But here we are.
And this leads me to write this post: It’s a walkthrough of the process I follow and of the applications I install whenever setting up a new machine and how I configure it.
It’s not going to be incredibly detailed, but it’s a starting place for if this ever happens again or for any developer looking to set up a new machine or repurpose an existing machine.
This weekend, I got a message from a fellow WordPress-developer whom I highly respect. In the note, Mario asked:
I was curious, do you follow other WP bloggers or have a go-to list for people still actively writing?
Which is a good question because, to be honest, there aren’t that many people I know in WordPress who blog regularly.
This isn’t to say there aren’t a lot of people in WordPress who are active on Twitter or actively sharing their stuff on other channels like GitHub, Slack, newsletters, etc., but there aren’t many people who are actively writing on their blogs.
And maybe it’s weird, maybe it’s not, but I’d assume that those involved in WordPress development of some sort would occasionally write on some place on the web.
Whenever there are holidays, I still publish a post about what’s going on simply because this blog has become a little more than just a place to talk about code. It’s also a place where I very occasionally share what is happening offline.
This week, my wife and I are finally taking a week-long trip with our daughters.
And we’re stoked.
Whenever we’re working on a project that requires some custom functionality, we still try to abide by the whole themes-are-for-presentation and plugins-are-for-functionality even if it’s not something that has any use outside of our projects.
This doesn’t mean we don’t use source control or anything like that, but it’s just that not everything that is open-source by its license is available for download because it has no applicability outside of a niche use case.
But that’s a discussion for another time.
All I’m saying is that even though we may be working on something just for us, we don’t abandon good development practices.
And there are times, say, where we may be sharing files, source code, or something via Slack that is not yet ready to either commit or to share any other way. In times like that, it’s helpful to be able to create a zip file, right?
But sometimes, we need to create a zip file with excluded files.
In earlier posts, I’ve talked a bit about Visual Studio Code the least of which not being the importance of debugging your code with Xdebug.
One of the questions I’ve received (and seen elsewhere around the web) is how to actually setup Visual Studio Code debug configuration. That is, you have Xdebug installed, you have the module specific in your PHP configuration file, but there’s no way to actually activate the debugger within the IDE.
Instead, you see something like this:
This is an easy fix.