Fix image links

content/post/deploying-discord-bot-kotlin.md

@@ -138,7 +138,7 @@ To ensure that the Heroku application has been created, run the `git remote -v`
 repository. Should your application have been created successfully, you will see a new remote added linking to a Heroku
 Git remote.
 
-![Results of git remote -v](./post/deploying-discord-bot-kotlin/git-remote.png)
+![Results of git remote -v](post/deploying-discord-bot-kotlin/git-remote.png)
 
 With the Heroku application created, we can begin configuring our repository to deploy to Heroku.
 

content/post/odd-broadway-1.md

@@ -73,7 +73,7 @@ these lines to be worked on.
 
 For your use case, the flow of data will look something like this:
 
-![Sample scenario flowchart](./post/open-source-deep-dive/broadway/pipeline.jpg)
+![Sample scenario flowchart](post//open-source-deep-dive/broadway/pipeline.jpg)
 
 So how does Broadway achieve all of this?
 
@@ -99,7 +99,7 @@ Messages are created and delivered to these queues by **producers** and taken fr
 consumers.** These messages can vary from something as simple as plain information to more complex structures like
 requests or — in our case — transaction information.
 
-![Message queue architecture](./post/open-source-deep-dive/broadway/message_queue.png)
+![Message queue architecture](post//open-source-deep-dive/broadway/message_queue.png)
 
 Message queues are useful for **decentralising the communication mechanism of large systems** by acting as a medium for
 exchanging events between systems which allows for systems to be easily scaled and distributed.
@@ -125,7 +125,7 @@ models.
 Each process communicates via **asynchronous message passing**. Think of a process as a mailbox of sorts; it has a "bin"
 to receive incoming messages and it possess an "address" for other processes to identify it by.
 
-![Actor concurrency model visualisation](./post/open-source-deep-dive/broadway/actor_concurrency_model.png)
+![Actor concurrency model visualisation](post//open-source-deep-dive/broadway/actor_concurrency_model.png)
 
 The unique aspect of this model is the **lack of shared mutable state** that other concurrency models rely on. Rather,
 state is exclusive to each process.
@@ -196,13 +196,13 @@ how it does what it does!
 
 # Pipeline architecture
 
-![Pipeline architecture](./post/open-source-deep-dive/broadway/architecture.jpg)
+![Pipeline architecture](post//open-source-deep-dive/broadway/architecture.jpg)
 
 It is at this juncture where it would be important to clarify the term "producer". In both message queues and GenStage,
 a producer is a creator of messages or events. However, in Broadway, a producer is both a consumer of messages and an
 emitter of events.
 
-![Terminology clarification for Broadway producer](./post/open-source-deep-dive/broadway/terminology.jpg)
+![Terminology clarification for Broadway producer](post//open-source-deep-dive/broadway/terminology.jpg)
 
 For the rest of the article, the following definitions for the following terminology will be used:
 
@@ -216,7 +216,7 @@ Broadway.
 Each component is a separate process and they are dynamically generated as different topologies (architectures) can be
 designed. The order of initialisation for a typical pipeline looks something like this:
 
-![Order of initialisation](./post/open-source-deep-dive/broadway/order_of_initialisation.jpg)
+![Order of initialisation](post//open-source-deep-dive/broadway/order_of_initialisation.jpg)
 
 The producers and processors are both created using interesting conventions that is will be explored now. Other
 components will be discussed later on as they tie into other features Broadway has.

content/post/odd-broadway-2.md

@@ -169,7 +169,7 @@ Processes can be [linked](https://hexdocs.pm/elixir/Process.html#link/1) to one
 exit signal — which can occur when the process is terminated forcibly or when it receives an exit signal propagated from
 its parent — it will propagate the exit signal to the linked process and that process will terminate as well.
 
-![Process linking](./post/open-source-deep-dive/broadway/linking.jpg)
+![Process linking](post//open-source-deep-dive/broadway/linking.jpg)
 
 However, these exit signals can
 be [trapped](https://crypt.codemancers.com/posts/2016-01-24-understanding-exit-signals-in-erlang-slash-elixir/) instead.

content/post/odd-hound.md

@@ -69,7 +69,7 @@ on [Selenium](http://selenium.dev), [PhantomJS](https://phantomjs.org/),
 and [ChromeDriver](https://chromedriver.chromium.org/) as the interfacing systems to perform the "dirty" work of
 coordinating requests/responses to/from the browser.
 
-![Hound's architecturel](./post/open-source-deep-dive/hound/general-architecture.png)
+![Hound's architecturel](post//open-source-deep-dive/hound/general-architecture.png)
 
 This introduces a larger question, what exactly is Selenium, PhantomJS, and ChromeDriver? More importantly, in fact,
 
@@ -117,7 +117,7 @@ there are two components to a web driver:
 In essence, a web driver is comprised of an API and a browser driver. Ideally, the API should be able to work with
 different browser drivers for different browsers.
 
-![Web driver architecture](./post/open-source-deep-dive/hound/web-driver-general-architecture.jpg)
+![Web driver architecture](post//open-source-deep-dive/hound/web-driver-general-architecture.jpg)
 
 > The remote end must also provide an **HTTP compliant wire protocol** where each endpoint maps to a command for the
 > browser.
@@ -142,7 +142,7 @@ the [JSON Wire Protocol](https://github.com/SeleniumHQ/selenium/wiki/JsonWirePro
 protocol to communicate with the browser driver. Note that the documentation provided by Selenium (for the JSON Wire
 Protocol) has been obsoleted in favor of the one defined in the specification.
 
-![Selenium architecturel](./post/open-source-deep-dive/hound/selenium-general-architecture.jpg)
+![Selenium architecturel](post//open-source-deep-dive/hound/selenium-general-architecture.jpg)
 
 ### How does Selenium differ from PhantomJS?