Julio Biason
5 years ago
1 changed files with 76 additions and 0 deletions
@ -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. |
Loading…
Reference in new issue