Merge pull request #393 from carpentries-incubator/anenadic-links

Fixes links

Author: anenadic

_episodes/32-software-architecture-design.md

@@ -237,7 +237,7 @@ responsibilities and think about the kinds of information different parts of the
 {: .challenge}
 
 We have been developing our software using the **Model-View-Controller** (MVC) architecture,
-but MVC is just one of the common [software architectural patterns](/software-architecture-extra/index.html)
+but MVC is just one of the common [software architectural patterns](../software-architecture-extra/index.html)
 and is not the only choice we could have made.
 
 ### Model-View-Controller (MVC) Architecture
@@ -301,7 +301,7 @@ but the Model stores it using a `Date` object rather than its string representat
 
 > ## Reusable "Patterns" of Architecture
 > 
-> [Architectural]((https://www.redhat.com/architect/14-software-architecture-patterns)) and 
+> [Architectural](https://www.redhat.com/architect/14-software-architecture-patterns) and 
 > [programming patterns](https://refactoring.guru/design-patterns/catalog) are reusable templates for 
 > software systems and code that provide solutions for some common software design challenges. 
 > MVC is one architectural pattern. 

_episodes/34-code-refactoring.md

@@ -273,7 +273,7 @@ from CSV to JSON, the bulk of the tests need not be updated
 > Some programming languages, such as Haskell or Lisp, support writing pure functional code only.
 > Other languages, such as Python, Java, C++, allow mixing **functional** and **procedural** 
 > programming paradigms. 
-> Read more in the [extra episode on functional programming](/functional-programming/index.html)
+> Read more in the [extra episode on functional programming](../functional-programming/index.html)
 > and when it can be very useful to switch to this paradigm 
 > (e.g. to employ MapReduce approach for data processing).
 {: .callout}
@@ -301,14 +301,14 @@ and provide varied approaches to structuring your code -
 each with certain strengths and weaknesses when used to solve particular types of problems. 
 In many cases, particularly with modern languages, a single language can allow many different 
 structural approaches and mixing programming paradigms within your code.
-Once your software begins to get more complex - it is common to use aspects of [different paradigm](/programming-paradigms/index.html) 
+Once your software begins to get more complex - it is common to use aspects of [different paradigm](../programming-paradigms/index.html) 
 to handle different subtasks. 
-Because of this, it is useful to know about the [major paradigms](/programming-paradigms/index.html), 
+Because of this, it is useful to know about the [major paradigms](../programming-paradigms/index.html), 
 so you can recognise where it might be useful to switch. 
 This is outside of scope of this course - we have some extra episodes on the topics of 
-[procedural programming](/procedural-programming/index.html), 
-[functional programming](/functional-programming/index.html) and 
-[object-oriented programming](/object-oriented-programming/index.html) if you want to know more.
+[procedural programming](../procedural-programming/index.html), 
+[functional programming](../functional-programming/index.html) and 
+[object-oriented programming](../object-oriented-programming/index.html) if you want to know more.
 
 > ## So Which One is Python?
 > Python is a multi-paradigm and multi-purpose programming language.

_episodes/35-software-architecture-revisited.md

@@ -299,16 +299,16 @@ in the usage section of the help page.
 
 ### Additional Reading Material & References
 
-Now that we have covered and revisited [software architecture](/software-architecture-extra/index.html) 
-and [different programming paradigms](/programming-paradigms/index.html)
+Now that we have covered and revisited [software architecture](../software-architecture-extra/index.html) 
+and [different programming paradigms](../programming-paradigms/index.html)
 and how we can integrate them into our architecture,
 there are two optional extra episodes which you may find interesting.
 
 Both episodes cover the persistence layer of software architectures
 and methods of persistently storing data, but take different approaches.
-The episode on [persistence with JSON](../persistence) covers
+The episode on [persistence with JSON](../persistence/index.html) covers
 some more advanced concepts in Object Oriented Programming, while
-the episode on [databases](../databases) starts to build towards a true multilayer architecture,
+the episode on [databases](../databases/index.html) starts to build towards a true multilayer architecture,
 which would allow our software to handle much larger quantities of data.
 
 ## Towards Collaborative Software Development

_extras/persistence.md

@@ -25,7 +25,7 @@ keypoints:
 
 > ## Follow up from Section 3
 > This episode could be read as a follow up from the end of
-> [Section 3 on software design and development](../35-refactoring-architecture/index.html#conclusion).
+> [Section 3 on software design and development](../35-software-architecture-revisited/index.html#towards-collaborative-software-development).
 {: .callout}
 
 Our patient data system so far can read in some data, process it, and display it to people.
@@ -354,9 +354,7 @@ class PatientSerializer(Serializer):
 > We've now got some code which we can use to save and load our patient data,
 > but we've not yet linked it up so people can use it.
 >
-> Just like we did with the `display_patient` view in
-> [Section 3](../36-architecture-revisited/index.html#mvc-revisited),
-> try adding some views to work with our patient data using the JSON serialiser.
+> Try adding some views to work with our patient data using the JSON serialiser.
 > When you do this, think about the design of the command line interface -
 > what arguments will you need to get from the user,
 > what output should they receive back?