diff --git a/content/links/20200420.md b/content/links/20200420.md
new file mode 100644
index 0000000..1a819a5
--- /dev/null
+++ b/content/links/20200420.md
@@ -0,0 +1,76 @@
++++
+title = "Links for 2020-04-20"
+date = 2020-04-20
+
+[taxonomies]
+tags = ["links", "c", "csp", "async", "django", "ddd", "org-mode", "blog",
+"optimization", "technical specs", "apple", "amazon", "zoom", "meetings"]
++++
+
+Async C, DDD + Django, From Org-Mode to Blog, Optimizable Code, Writing
+Technical Specs, Apple and Amazon, Zoom and Meetings.
+
+<!-- more -->
+
+# [Libcsp](https://libcsp.com/)
+
+Yes, C is pretty bad and such, but _holy cow_, this is pretty: a library for
+async function calling in C on the communicating sequential processes (CSP)
+model, which is the same used by Go.
+
+And, personally, the code looks _prettier_ than Go.
+
+# [Doing Domain Driven Design with Django](https://slides.com/mafinarkhan/ddddd#/)
+
+Slides to a presentation about doing DDD with Django. Although it's a
+presentation and, thus, this means is has to be short and not specific, but
+it does a good job in explaining DDD and how does it relate (or not) to the
+Django architecture.
+
+# [How to blog with Emacs Org mode](https://opensource.com/article/20/3/blog-emacs)
+
+In pushing the "everything plus the kitchen sink" of Emacs features, this post
+explains how to write things in Org-Mode and publish it into HTML, making it
+easier for someone to write posts in Org-Mode and then publish.
+
+(Hey, this blog is written in Markdown and them published in HTML, so that's
+not that weird!)
+
+# [Optimizable Code](https://deplinenoise.wordpress.com/2013/12/28/optimizable-code/)
+
+The great question about optimization. Sure, not do it prematurely, but this
+boils down to memory alignment. This post gives some tips about it.
+
+# [A practical guide to writing technical specs](https://stackoverflow.blog/2020/04/06/a-practical-guide-to-writing-technical-specs/)
+
+A roadmap on how to write a spec. While I don't agree with the front matter
+part -- why the heck do you need to know who wrote it, when it was created and
+when it was updated? -- it gives the general template for writing a spec.
+
+# [How to Provide Test Fixtures for Django Models in Pytest](https://realpython.com/django-pytest-fixtures/)
+
+While I'm not a huge fan of Pytest -- unittest is there already, even if it is
+that panacea of methods -- this explains pretty well how to integrate Pytest
+into Django, specially since it takes the road from the original unittest, the
+one you learn when reading the Django documentation, and turns into Pytest.
+
+# [Apple, Amazon, and Common Enemies](https://stratechery.com/2020/apple-amazon-and-common-enemies/)
+
+This is a point about Apple doing what every monopoly does: If it can take
+something from whoever needs you, you take. But don't think this is exclusive
+to Apple: Google does that, Amazon does that, and so on.
+
+# [Zoom Is Not the Problem – Our Meeting-Centric Workflow Is](https://blog.nuclino.com/zoom-is-not-the-problem-our-meeting-centric-workflow-is)
+
+This feels, initially, another of those "shut up and let me work" kind of
+posts, but once again there is the call for "async communication" -- a.k.a.
+"write a doc and send an email".
+
+Personally, I saw both sides of this coin: Either we have a lot of emails
+floating around, which made really hard to follow everything that was going
+on, or we had too many personal talks and nothing was being saved for future
+reference. I believe what you really need to have things written down, even if
+they are preliminary and prone to change, but you also need a direct
+discussion about some points from time to time, beyond the simple daily
+"Yesterday, I did this, that and that, and that's it", which does not explain
+the reason for doing this, that and that.