correct spelling

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "cSpell.enabled": true
+}

src/pages/uploadz/python-virtual-environments.md

@@ -63,7 +63,7 @@ Python virtual environments isolate projects, letting you use different Python v
 
 You may want to use a virtual environment if you are working on multiple python projects that require different versions of python or different versions of python packages.
 
-Another more prescient need in my view is to maintain a clean build environment for any given project. In order to do so, it is often a chosen pattern to isolate each project in such a way as to be easy to reproduce elesewher be it for other developers or for deployment to production.
+Another more prescient need in my view is to maintain a clean build environment for any given project. In order to do so, it is often a chosen pattern to isolate each project in such a way as to be easy to reproduce elsewhere be it for other developers or for deployment to production.
 
 One, very common way to do this for python is to use `virtualenv` or `venv` which is a built in module in python.
 
@@ -119,23 +119,23 @@ This is a common pattern for moving around python projects and is often used in
 
 There are several other ways in which we can control python environments but more generally, any environment can be controlled with Docker. Docker is a containerization technology that allows us to create a container that has all the dependencies we need for a project and then run that container on any system that has Docker installed.
 
-When used in conjuction with VSCode and the Remote Containers extension, we can create a container that has all the dependencies we need for a project and then VSCode will automatically connect to that container and allow us to edit the code and run it from within the container.
+When used in conjunction with VSCode and the Remote Containers extension, we can create a container that has all the dependencies we need for a project and then VSCode will automatically connect to that container and allow us to edit the code and run it from within the container.
 
 Prerequisites are to have Docker installed and the Remote Containers extension installed in VSCode. This may pose a challenge more than the virtual environment approach but it is a very powerful way to manage environments and is becoming more popular. 
 
 ## Getting started with VSCode and Docker
 
-For a new project, create a named repo in github, choose a .gitignore and license so as to initialise the repo.
+For a new project, create a named repo in github, choose a .gitignore and license so as to initialize the repo.
 
 With Devcontaiers extension installed, in VSCode, open the command palette with 
-CNTRL+SHIFT+P ( winoows / Linux ) or CMD+SHIFT+P ( mac ) and type `DevContainers` then choose to 'Clone Repository in Container Volume'.
+CNTRL+SHIFT+P ( windows / Linux ) or CMD+SHIFT+P ( mac ) and type `DevContainers` then choose to 'Clone Repository in Container Volume'.
 
 
 Pick a git repo - the one we just created and its main branch. This will download and boot a container - vsc-volume-bootstrap:latest
 
 
 you can view logs when it says its starting by clicking on its link
-click 'show all definitions' in the next prompt and pick an appropriate one for your purposes. One such is labelled as python 3 by Microsoft - which I use that has the fully named continer reference of `mcr.microsoft.com/devcontainers/python:1-3.12-bullseye`. More general purpose ones are available such as "Default Linux Universal" - `mcr.microsoft.com/devcontainers/universal:2-linux` and this is the image that Github uses in its 'codespaces'. This is a much larger image and takes a lot longer to download and boot but is a more general purpose environment. 
+click 'show all definitions' in the next prompt and pick an appropriate one for your purposes. One such is labelled as python 3 by Microsoft - which I use that has the fully named container reference of `mcr.microsoft.com/devcontainers/python:1-3.12-bullseye`. More general purpose ones are available such as "Default Linux Universal" - `mcr.microsoft.com/devcontainers/universal:2-linux` and this is the image that Github uses in its 'codespaces'. This is a much larger image and takes a lot longer to download and boot but is a more general purpose environment. 
 
 
 
@@ -164,7 +164,7 @@ When for example the general purpose image has been downloaded and we open a she
 	  codespace ➜ /workspaces/vscode-dev-container-002 (main) $ 
 ```
 we can see that we are user `codespace` - this is the same / similar environment that we get in github codespaces of this name and is why it took so long to download
-basically we have a comprehensive virtual environment that we can use locally and when done, can open exactly the same in codespaces using the git repo that this is stored to to get the same eperience anywhere we can get to a competent browser. this is quite significant, perhaps even a reason for some degree of jubilation.
+basically we have a comprehensive virtual environment that we can use locally and when done, can open exactly the same in codespaces using the git repo that this is stored to to get the same experience anywhere we can get to a competent browser. this is quite significant, perhaps even a reason for some degree of jubilation.
 
 So long as you commit any code you write back to the Git repo, you can pick up where you left off using the same environment or one that is created by checking out this repository and choosing to `Clone Repository in Container Volume` using the same VSCode extension.
 
@@ -184,18 +184,18 @@ mkdir -p ~/miniconda3
 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh
 ```
 
-this downloads what looks like a shell script, which you can take a look at if you prefer to see what it does before running it, but it is essenntially a script with a binary embeedded.
+this downloads what looks like a shell script, which you can take a look at if you prefer to see what it does before running it, but it is in essence a script with a binary embedded.
 
 ```bash
  ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
  rm -rf ~/miniconda3/miniconda.sh
 ```
-and the above now runs the downloaded script / exectuble then clears out the downloaded file.
+and the above now runs the downloaded script / executable then clears out the downloaded file.
 
 ```bash
  ~/miniconda3/bin/conda init
 ```
-to initialise the shell environment.
+to initialize the shell environment.
 
 ```bash
 ~/miniconda3/bin/conda init bash
@@ -235,5 +235,5 @@ which removes the path name of your current environment from your system command
 
 # Conclusion
 
-Whichever method you choose to virtualise Python environmetns, it is important to be able to reproduce your environment for your project. This is important for development and for deployment. There is currently no 'one size fits all' solution and having an awareness of more than one approach to virtualising Python environments will be necessary when working on different projects and for different clients.
+Whichever method you choose to virtualize Python environments, it is important to be able to reproduce your environment for your project. This is important for development and for deployment. There is currently no 'one size fits all' solution and having an awareness of more than one approach to virtualizing Python environments will be necessary when working on different projects and for different clients.