move <img> render markup to render hooks

content/blog/three-steps/index.md

@@ -78,7 +78,7 @@ designer. For example, you can use a rapid wireframing tool like
 quickly without spending time on minor visual details. Or, use a whiteboard or
 good old pencil and paper. Any sketch is better than nothing.
 
-[![Low-fidelity Balsamiq wireframes](balsamiq.png)](balsamiq.png)
+![Low-fidelity Balsamiq wireframes](balsamiq.png)
 *Low-fidelity [Balsamiq](https://balsamiq.com) wireframes*
 
 And if you're building an API or a command-line interface, your design would be
@@ -119,7 +119,7 @@ diagram. ER diagrams are arguably the most useful part of the UML
 specification. You may skip everything else in UML, but if you're working with
 relational databases, don't skip ER diagrams :)
 
-[![ER diagram example](dbdiagram.png)](dbdiagram.png)
+![ER diagram example](dbdiagram.png)
 *Credit: [dbdiagram.io](https://dbdiagram.io)*
 
 ## Summary

content/blog/why-go-full-stack/index.md

@@ -33,7 +33,7 @@ reload to interact with the server. And it felt fast! Trello was very popular,
 thanks to its good design and a generous free plan, so many people tried it
 and are still using it.
 
-[![The rise of frontend frameworks](the-rise-of-frontend-frameworks.png)](the-rise-of-frontend-frameworks.png)
+![The rise of frontend frameworks](the-rise-of-frontend-frameworks.png)
 
 Trello wasn't the very first SPA, of course. Another famous example is GMail
 which was introduced in 2004. However, Trello was built on a frontend
@@ -50,7 +50,7 @@ showcasing the capabilities of JS frameworks.
 
 Simultaneously in the 2010-s there was an explosive growth of APIs:
 
-[![Growth in web APIs](growth-in-web-apis.png)](growth-in-web-apis.png)
+![Growth in web APIs](growth-in-web-apis.png)
 
 *Source: [Programmable Web](https://www.programmableweb.com/news/apis-show-faster-growth-rate-2019-previous-years/research/2019/07/17)*
 
@@ -66,7 +66,7 @@ Frontend frameworks were hot in the 2010-s. People were talking about them at
 conferences. At that time, the joke about "X days without a new JavaScript
 framework" wasn't so much of a joke.
 
-[![Days without a new JavaScript framework](days-without-new-javascript-framework.png)](days-without-new-javascript-framework.png)
+![Days without a new JavaScript framework](days-without-new-javascript-framework.png)
 
 Some web developers were excited about these innovations, but others... not so
 much. Previously, CSS and JavaScript were already perceived by many as a mess.
@@ -75,7 +75,7 @@ JavaScript hacks were required to get things working consistently in all
 browsers. Now, another layer of complexity had been added – frontend frameworks,
 JS bundlers, and package managers, and they were young and still in flux.
 
-[![How did your hackathon go](how-did-your-hackathon-go.png)](how-did-your-hackathon-go.png)
+![How did your hackathon go](how-did-your-hackathon-go.png)
 
 And so, some developers started to specialize in this area and call themselves
 frontend developers. It seemed reasonable because the industry was moving
@@ -105,7 +105,7 @@ reasons outlined in the next section.
 
 ## What problems do full-stack developers solve
 
-[![Why go full-stack](why-go-full-stack.png)](why-go-full-stack.png)
+![Why go full-stack](why-go-full-stack.png)
 
 Not everyone has hopped on that backend-frontend separation train, though.
 Simultaneously with frontend developers, a competing role emerged – full-stack

content/blog/why-public-chats-are-better-than-direct-messages/index.md

@@ -33,7 +33,7 @@ We explain why and try our best to ensure a smooth transition.
 
 ## Why?
 
-[![Boost team performance](rocket.png)](rocket.png)
+![Boost team performance](rocket.png)
 
 Simple: **it boosts team performance - a lot.** Of course, it takes some
 adaptation effort for new team members, but the effect is so significant that

content/blog/zero-downtime-DB-migrations/index.md

@@ -27,14 +27,14 @@ Let's take a look at a simplified deployment process for a typical web
 application. Most applications these days rely on load balancing and container
 orchestration:
 
-[![A typical web app](a-typical-web-app.png)](a-typical-web-app.png)
+![A typical web app](a-typical-web-app.png)
 
 What happens when we need to deploy a new version of an application? The
 deployment process replaces app instances one by one. It excludes them from the
 cluster first, replaces app instances with newer versions, and then puts them
 back in the cluster:
 
-[![Deployment process](a-typical-deployment-process.svg)](a-typical-deployment-process.svg)
+![Deployment process](a-typical-deployment-process.svg)
 
 As shown in the animation above, the application version 2 gradually replaces
 previous version 1 without any service interruption for end users.
@@ -50,7 +50,7 @@ correctly, the database must be upgraded before putting any instance of
 application v2 into production. Therefore, a deployment process that includes
 a database upgrade should look like this:
 
-[![Deployment process with the DB upgrade](deployment-process-with-DB-upgrade.svg)](deployment-process-with-DB-upgrade.svg)
+![Deployment process with the DB upgrade](deployment-process-with-DB-upgrade.svg)
 
 ## How to run the DB migration script
 
@@ -115,7 +115,7 @@ Let's say we're building a new feature — user avatars. After registration,
 every user will get a randomly generated avatar with an option to upload their
 own. To implement this, we need to add the `avatar` column to the `Users` table:
 
-[![Adding a table column](adding-a-table-column.png)](adding-a-table-column.png)
+![Adding a table column](adding-a-table-column.png)
 
 How can we upgrade the database from v1 to v2 in this case? Our database
 migration script should include the following operations:
@@ -184,7 +184,7 @@ it back. There will be no more user avatars, so we want to remove all
 application functionality related to it and also remove the `avatar` column
 from the DB:
 
-[![Removing a table column](removing-a-table-column.png)](removing-a-table-column.png)
+![Removing a table column](removing-a-table-column.png)
 
 As with the previous example, if we just naively push everything to production,
 including the DB migration script, it will cause downtime.
@@ -231,7 +231,7 @@ existing data to the new format by transforming file names into full URLs.
 Lastly, it is a good idea to rename the column from `avatar` to `avatar_url`
 to better reflect its new purpose:
 
-[![Replacing a table column](replacing-a-table-column.png)](replacing-a-table-column.png)
+![Replacing a table column](replacing-a-table-column.png)
 
 In this case, the data migration script includes:
 
@@ -315,7 +315,7 @@ already upgraded in the previous phases.
 Surprisingly, renaming a table is more straightforward than renaming a column.
 Imagine we'd like to rename the `Posts` table to more generic `Content`:
 
-[![Renaming a table](renaming-a-table.png)](renaming-a-table.png)
+![Renaming a table](renaming-a-table.png)
 
 If we don't take any precautions, such a rename would cause downtime during the
 deployment. The previous app version, which still runs in production, will try
@@ -361,7 +361,7 @@ migration cases, but they should help you understand the main idea. If you get
 the idea and know how your deployment script works, you can develop solutions
 for other cases yourself.
 
-[![Deployment process with the DB upgrade](deployment-process-with-DB-upgrade.svg)](deployment-process-with-DB-upgrade.svg)
+![Deployment process with the DB upgrade](deployment-process-with-DB-upgrade.svg)
 
 Quick recap:
 

layouts/_default/_markup/render-image.html

@@ -1 +1 @@
-<img src="{{ .Destination }}" alt="{{ .Title }}">
+<a href="{{ .Destination }}"><img src="{{ .Destination }}" alt="{{ .Title }}"></a>