DEV Community: Connor

Quick tips for Powershell scripters

Connor — Wed, 30 Mar 2022 20:24:01 +0000

Here's some quick and dirty help if you've gotten rusty with Powershell or otherwise aren't sure quite how to do things.

1: Modules are your best friend

Chances are that whatever you're trying to do inside a Microsoft environment has a module either written or trusted by Microsoft already at Powershellgallery. Don't reinvent the wheel.

2: MS Docs are your first and best reference

Microsoft's documentation actually doesn't suck when it comes to Powershell. It's not going to hold your hand all the way, but if you've got even a mite of experience doing scripting that touches environment variables and networked services (like AD, O365, Exchange) then you'll be able to pick up on the examples and concepts the documentation offers pretty easily. Don't be afraid to dig a few links deep into your questions.

3: Powershell has two major versions

Powershell 5.1 comes installed by default on Win10, and I think it's still the default on Win11 as well. This version of Powershell is written in .NET Framework, which is Windows-native. This is by far the most common option, as opposed to Powershell 7, which is written in .NET Core. Core is inherently cross-platform. If you run Powershell on a *nix system like Linux or Mac, it's v7 running on .NET Core. This is important because not all assemblies and modules are usable on both platforms. A notable difference here is MSOnline, which depends on cryptography dependencies inside Powershell 5 that are not available in 7; and therefore MS now encourages you use the MS Graph API and other Azure-based modules as a replacement for the old MSOnline module.

4: Iterate, iterate, I T E R A T E

One of the most powerful combos in Powershell is the combination of If-Else flow control and a ForEach loop walking over every complex object inside a data container like an Array, ArrayList, or HashTable.

You can use this to:

Grab a specific user group using Get-ADGroupMember, put all the user objects in an array, and then grab all of their usernames. You can pipe those usernames into other commands, or just use it as a simple way to dump out a list of who's in what groups.
Make bulk changes to Exchange accounts by pulling out all accounts on a specific Filter, and then running a set of commands ForEach. Anyone who's spent a lot of time in the Exchange console GUI can probably agree that it takes a while to do stuff by hand.
Check and even change the MFA status of users in your tenant in order to fix security holes, get info for audits, and more.

I've got a handful of sample scripts at GrinnyLib on Github. I just recently started putting scripts I use regularly there, that I've written myself. You'll probably recognize that some of these examples can be used for concepts I mentioned in this post.

If any of these helped you out, leave a comment!

Tiny Programs 1: docshund-rs

Connor — Fri, 25 Mar 2022 15:21:45 +0000

Long story short, I've wound up starting work on a small Tesseract OCR program. I call it docshund-rs, because it finds things in documents like a dachshund finds gophers in holes, and it's written in Rust. I'm intensely creative.

It took me longer to remember how Rust does Result<> type returns and accordingly unwrap the results of the tesseract-rs calls than it did to get the program working.

Though, all things told, it's already pretty cool. It can successfully scan image files like JPEG, PNG and TIF with a reasonable degree of accuracy.

Ultimately I think docshund-rs will be a program that can take a PDF file, turn it into images, and then process a bunch of those pages concurrently before barfing the output back out into a searchable PDF, or at least just a text file dump.

This is also subject to my interest level in the project, which usually varies wildly.

Though I think I'll keep a running tab of Tiny Programs and link it all together as a series, regardless.

Title photo by James Watson on Unsplash

Hi again. Where did the time go?

Connor — Wed, 16 Mar 2022 04:19:24 +0000

Long story short I posted here in like 2019 once and I got thousands of views on that post.

Still tickles me pink to this day.

That post was all about being a web developer and how crazy it is, furthermore, to be a full stack dev of any sort. From how I understand it the industry has only continued to grow in that direction. Cue thoughts, rants and controversy about Web3, and what it likely means for developers who make things for browsers and mobile devices.

But since that post I have left that corner of the tech industry behind and I'm pretty okay with that.

At this point I'm actually a senior systems administrator in a department of about two dozen people. I have little or nothing to do with web development anymore beyond talking with internal software and and devops folks on how their new in-house deliverables will integrate with our standing systems.

Nowadays when I'm programming at work it's usually some .NET-heavy PowerShell and maybe some C# if I actually need a fully compiled application, and not just a PSSession full of .NET assembly calls and NuGet modules.

At home I'm messing around with Rust for fun and building a Discord bot with a friend. I'm slowly unlearning my hatred for finicky systems-level programming instilled by learning C++ as a first language.

Frankly I'm posting here again because Twitter's a cesspool and Fediverse often feels like I'm standing between groups of people with signs and bullhorns; probably arguing about something Big Tech said or did. I'm not about that vibe.

So uh, hi? Again?

Photo by Stephanie LeBlanc on Unsplash

Being A Full Stack Web Dev is Kinda Crazy

Connor — Fri, 22 Nov 2019 19:49:07 +0000

Last night I was reviewing the skills I've gained since starting my journey as a developer.

I realized something: as a loose estimate, you need a firm grasp of no less than 11 different systems or syntax models just to carry a modern web app from backend to client, from indev to production on your own.

I'm not joking, and that's no small feat.

The List

This is a brief example of a full stack dev's possible code languages and other systems that they would use at some point in the full stack devops cycle.

All 3: HTML5/CSS3/JS
These should be obvious for anyone in web dev.

At least one each of:

SQL distro - for database
Java/Python/C# - for serverside logic
React/Angular/Vue/etc - for frontend
Bootstrap/Bulma/etc - CSS design
Apache or other webserver - for hosting
Node.js - for package management
Webpack, Browserify, Parcel - build scripts and cross compiling
LINUX - because I guarantee you will use it at some stage, if not develop all of your work in a Linux distro already.
probably other stuff I forgot

And Even More

This list doesn't even touch on details of:

design principles
version control
networking
hardware

and the deluge of standards and specific knowledge for each. Usually it's required to have at least passing knowledge in those areas as well.

So What?

If you were to follow the requirements of that list your list of skills could be something like this:

HTML5/CSS3/JS
Oracle SQL
Java
Vue
Bootstrap
Apache
Node.js
Webpack
Debian (& Bash)
Git
Adobe XD for design/wireframe
And maybe a bit of firewall/netsec stuff.

Personally, it's so satisfying to know I can do most of that list already. I'm learning more every day. It's been a long road but compiling that list makes it so much cooler to see my own progress.

It also humbles me considerably. I'm reminded that people who really know their stuff in this field are worth respecting. Because it takes a lot of work to get there.

If you're ever feeling a bit of impostor syndrome, if "I can't do this" keeps creeping into your head...

Stop and think about what you already know. We have to do a lot in this field to be competitive. Not convinced?

That list is an impressive one for anyone else on the planet: imagine people's reaction if you told some random passerby that was curious that you know 10 programming languages and use them all at work. Their heads might explode. I know plenty of great people who are very knowledgeable in their fields that look at me like I'm Hackerman for knowing that the Developer Tools in Chrome even exist.

But for us, that kind of portfolio is just "par for the course." It's easy to get caught up in that viewpoint and forget that we're already specialists in a field that can be really opaque to a lot of people. Remember that. And stay humble about it.

TL;DR

Don't compare. Just improve yourself. Give yourself some credit. List your accomplishments to yourself.

And next time you question if your web developer friend is crazy (or if you are) for doing what we do..

Yes. I'm pretty sure we're all crazy.