Why? Because until recently, I was notorious for leaving Write-Debug statements everywhere. I mean, just take a look at my local git folder.
My code was just littered with these after practically every logical operation…just in case I needed to pause my code here at some point in the future. Actually, someone could look at my code in the past and every Verbose or Debug cmd was basically a place that I got stuck while writing that cmdlet or script. I mean, using the tools is not wrong, but it always felt like there should be better ways to do it.
Recently, I have learned of a much better way and I want to share it with everybody.
Why not use Write-Debug?
Write-Debug is wrong and if you use it you should feel bad
I’m just kidding! You know, to be honest, something really gets under my skin about those super preachy posts like you always find on medium that say things like ‘You’re using strings wrong’, or “You’re all morons for not using WINS” or something snarky like that.
It’s like, I might have agreed with them or found the info useful, but the delivery is so irksome that I am forced to wage war against them by means of a passive aggressive campaign of refusing to like their Tweets any more as my retribution.
That being said, here’s why I think we should avoid Write-Debug. It ain’t wrong, but you might like the alternative better.
While I’m working on some longer posts, I thought I’d share a quick snippet I came up with this weekend as I was backing up a number of old DVDs of family movies.
FFMPeg has the awesome ability to join a number of video files together for you, but the syntax can be kind of strange. Once I learned the syntax, I sought to make sure I never had to do it again, and created this cmdlet.
In this basic version, it will join every file in a directory, giving you Output.mkv. Be sure your files in the directory are sequentially ordered as well, to control their position.
Ensure that FFMpeg’s binaries are available in your Path variable as well.
Later on, I may add the ability to provide which specific files you want to join, if desired 🙂
Around the time I was celebrating my 100th post, I made a big to-do about opening my own subreddit at /r/FoxDeploy. I had great intentions, I would help people in an easier to read format than here in the comments…but then, I just kind of, you know, forgot to check the sub for four months.
But no longer! I decided to solve this problem with the only tool I know…code.
A few months ago, I went to ‘The Red Shirt’ tour with Scott Guthrie in which he talked all about the new Azure Hotness. He covered Functions, an awesome headless, serverless Platform as a Service offering which can run a variety of languages including C#, F#, Node.js, Java, and of, course, Best Language, PowerShell.
I was so intrigued by this concept when I first learned of it at an AWS event years ago in Chicago, where they introduced Lambda. Lambda was cool, but it couldn’t run bestgirl language, PowerShell. Continue reading →
Hey y’all. There are a lot of guides out there to installing PowerShell on Linux, but I found that they expected a BIT more Linux experience than I had.
In this post, I’ll walk you through installing PowerShell on a RHEL 7 machine, assuming you are running a RHEL 7.4 VM on Hyper-V. There are a couple stumbling blocks you might run into, and I know, because I ran into ALL of them.
Much like Microsoft’s approach to ISO access, Red Hat greedily hordes their installer dvd’s like a classic fantasy dragon. Continue reading →
We’re all adventurers. That’s why we wake up in the morning and do what we do in our fields, for that feeling of mastery and uncovering something new. Some of us chart new maps, cross the great outdoors, or climb mountains.
And some of us explore code.
In this post, I’ll outline my own such PowerShell adventure, and show you the tools I used to come out the other side with a working solution. We’ll meet in basecamp to prepare ourselves with the needed gear, plan our scaling strategy and climb the crags of an unknown PowerShell module. We’ll belay into treacherous canyons, using our torch to reveal the DLLs that make Windows work, then chart new ground using DotPeek and eventually arrive on the summit, victorious and armed with new tools.