What's in the bag? Behind the scenes at vBrownBag.com
- What’s in the bag? Behind the scenes at vBrownBag.com
- Part 2 of “What’s in the bag?” Behind the scenes at vBrownBag.com
- Part 3 of “What’s in the bag?” Behind the scenes at vBrownBag.com
- Part 4 of “What’s in the bag?” Behind the scenes at vBrownBag.com
- Part 5 of “What’s in the bag?” Behind the scenes at vBrownBag.com
- Part 6 of “What’s in the bag?” Behind the scenes at vBrownBag.com
- Automating the vBrownBag with AWS Serverless
In Part 2, we covered the Meatgrinder process flow. In this post, we’ll cover the development environment and change management tools.
I decided to write this Lambda function on my Windows 11 machine because I’d started this effort by writing code to “catch up” the website & the podcast RSS file, and naively thought that I could just move the code from Windows to Lambda. While it’s mostly true that the code is cross-platform there are some differences, such as case-sensitivity for paths/filenames/variables on Linux vs Windows’ case-insensitivity. Having the benefit of hindsight, I should’ve developed in an environment that resembles where the code was running as I probably would’ve had fewer portability issues.
That being said, here’s the environment I ended up with:
- Primary development on Windows 11 running PowerShell 7 and Visual Studio Code, connected to a GitHub repository and using GitHub Copilot
- Amazon Linux running in WSL2.
- This was a multi-step process, as I spun up a Ubuntu distro on WSL, then installed Docker.
- After Docker was setup, I installed Amazon Linux in Docker, then exported the filesytem and imported into WSL as the default distro. Instructions here. Note, I could’ve installed Docker on Windows to perform the import/export, but I didn’t.
- The default Amazon Linux image runs a minimal set of packages, so I used yum to groupinstall “Development Tools”, and installed wget to help pull down the rest of what I needed.
- Both operating systems run the dotnet 8 SDK, aws.lambda.tools for dotnet, PowerShell 7, the modular AWS PowerShell modules, and the AWS Lambda Tools for PowerShell.
- Other PowerShell modules I’m using include PSAuthClient for handling OAuth2 tokens and Posh-SSH to move a file from Lambda to vbrownbag.com.
I prefer the modular AWS PowerShell modules as I can limit the module groups that are loaded into my Lambda function vs the monolithic AWS PowerShell module that includes everything but add unneeded start times to the function.
The dotnet 8 SDK is a requirement for packaging Lambda functions on any platform. The aws.lambda.tools for dotnet are very helpful in creating new dotnet projects that will run on Lambda. The AWS Lambda Tools for PowerShell are effectively wrapper cmdlets that simplify packaging of a function that lives in a single script, or is part of a bigger project.
Thoughts on GitHub Copilot
First off – Copilot is darn near magical at times. Being able to have a conversation about code, solving specific problems, or even getting answers to things like “why am I getting this error?” is simply amazing.
That said, it’s certainly not perfect. In fact, there have been a few times that I swear Copilot was drinking on the job. Sometimes it would answer in circles, give me bad ideas on how to solve things, forget the context of our conversation, or start using the “I’m just an AI” response when I asked it broader questions about my code, which is nearing about 1000 lines at this point. One time in particular stands out to me where it suggested a block of code that repeated a line twice. When I asked “why did you suggest doing this twice?” it denied that it did. When I said said that it absolutely did suggest it to me, it remembered that it did and then apologized about it.
I think it would be helpful if there was clearer communication that Copilot can’t “see” everything you’re working on because it isn’t always clear. Its responses will say that it’s referencing lines of code, but why it chooses those lines isn’t obvious if it’s based on cursor position, the question itself, or what’s in the VS Code view port. Copilot also doesn’t ask clarifying questions; often it will just give an answer that’s not appropriate in context of the code being written or where it’s running.
All of that said, I’m really excited to see where Copilot is headed. Having a tool like this one lowers the barrier to entry for everyone as Copilot can explain unfamiliar code, help translate from one type of code to another, and even translate into another spoken language. If you’re curious about trying out Copilot, as of this writing there’s a 30 day free trial for individual use.
Coming up next
I’ve spent a lot of time detailing what I want to do and the tools I’m using to do it. Next up in the series, let’s start looking at code with specific examples. Talk to you then!