Persephone Raskova percy-raskova

By default on Windows, conda saves new virtual environments to your C:/Users/<your username>/AppData/Local/conda/conda. (AppData is hidden by default, but you can see it in File Explorer by checking View > Hidden Items.)

conda environments can get pretty big, so if you're running low on hard disk space and have another drive mounted, you can easily move your environment to a directory on the other drive and create a symbolic link to the new location. This way, conda will look in its regular path for the environment and will find it just fine, despite the actual files having been moved elsewhere.

Let's say we want to move the environments to a separate drive, mounted as D:\. We'll put everything in D:\<your username>.

Open up Command Prompt, and then enter:

# First, move all the contents of your environments directory over to the new location:

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

Git Submodules - Basic Explanation

Why submodules?

In Git you can add a submodule to a repository. This is basically a sub-repository embedded in your main repository. This can be very useful. A couple of usecases of submodules:

Separate big codebases into multiple repositories.

	# The name of the pipeline, including the date and a revision number
	name: copa_$(Date:yyyyMMdd)_$(Rev:r)

	# This pipeline is not triggered automatically by any event
	trigger: none

	# This pipeline is not triggered automatically by any pull request
	pr: none

	# Parameters for the pipeline