You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Excel/VBA Agentic Coding Guide (from a real build/debug session)
Purpose
This document captures practical lessons from building a non-trivial .xlsm with generated VBA modules, Excel COM automation, and iterative debugging.
It is meant for:
Expert Excel/VBA developers starting with agentic coding workflows
Prompt engineers directing coding agents on Excel/VBA tasks
It focuses especially on how to handle compilation errors fast.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In Fall 2023, Slack introduced an updated client with some unpopular UI changes. The tweaks in this document can be used to revert to the old client or hide the new side bar. These will reset every time you fully close Slack but they are easy to re-apply once you get the hang of it.
(Cross Platform) Open Dev Tools [Preferred Option]
To run any of these scripts, you'll need to open the Dev Tools (or Console). You can do this by typing /slackdevtools in a Slack channel or direct message. These are the same Dev Tools you'd get in Chrome if you hit F12. Along the top are tabs for Elements, Console, Sources, Network, etc. You'll want to paste these scripts into the Console tab at the > prompt.
If Slack disables this command, then you can open Dev Tools by setting a system-wide environment variable and using a keyboard shortcut to open the console. If /slackdevtools worked for you then you can skip these next two sections.
Goals: Add links that are reasonable and good explanations of how stuff works. No hype and no vendor content if possible. Practical first-hand accounts of models in prod eagerly sought.
As an example, lets assume we want to change / customize the following :
Change the Title of the GitBash window from default [MINGW64:/directoryName] to [Tushars Gitbash (Win64)]
Change the default prompt () to a customized prompt e.g [GitBash (Win64):> ]
👉 Note ($HOME/.bash_profile vs $HOME/.bashrc vs $HOME/.config):
The below described method only focusses on customizing the 'GitBash' prompt and NOT about customizing default 'Bash' prompt on Linux terminals. Hence this method uses the '$HOME/.config' folder for storing 'GitBash' prompt customization as per XDG Directory Specs. If you are looking for customizing default 'Bash' prompt for your Linux terminal you should be using '$HOME/.bashrc' for storing your customization and hence advised not to continue with this method.
Restores the 7 default libraries in This PC on Windows 10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I tried the WSL and it isn't quite seamless enough for me. I ran in to problems when editing in VSCode and having watchers on my files (ng serve, dotnet watch run, etc.). In addition, I kept running in to problems that only manifest themselves when running in WSL. For example, this issue with doing production builds and the terser plugin has made many a developer rage-quit on using WSL. Just figuring out that it was an issue with the WSL took a lot of time.
That terser plugin issue was never resolved and I ended up having to keep a git bash window open in addition to my WSL console window so I could do production builds. To make matters worse, my npm packages were platform-dependent so I couldn't use the same project folder. So, my procedure was: commit whatever changes to test branch, push to repo, git pull on my "windows" project folder, and do a production build there