aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2020-10-13 10:08:36 -0300
committerEuAndreh <eu@euandre.org>2020-10-13 10:08:36 -0300
commita45c0929daac4075e9d1705398ed7e7c969a651c (patch)
tree8345dcaf2f10bf3ca321cb95387b7541c723caff
parentExtend article on feature flag (diff)
downloadeuandre.org-a45c0929daac4075e9d1705398ed7e7c969a651c.tar.gz
euandre.org-a45c0929daac4075e9d1705398ed7e7c969a651c.tar.xz
s/etc./*etc.*/g
-rw-r--r--_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md4
-rw-r--r--_articles/2019-06-02-stateless-os.md2
-rw-r--r--_articles/2020-08-31-the-database-i-wish-i-had.md12
-rw-r--r--_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md4
-rw-r--r--_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md2
5 files changed, 12 insertions, 12 deletions
diff --git a/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md b/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
index a9a605b..34b0c63 100644
--- a/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
+++ b/_articles/2018-12-21-using-youtube-dl-to-manage-youtube-subscriptions.md
@@ -25,7 +25,7 @@ privacy](https://staltz.com/what-happens-when-you-block-internet-giants.html):
> full control of how much they can know about me. I don't want to be in
> autopilot mode. (...) Which leads us to YouTube. While I was able to
> find alternatives to Gmail (Fastmail), Calendar (Fastmail), Translate
-> (Yandex Translate), etc, YouTube remains as the most indispensable
+> (Yandex Translate), *etc.* YouTube remains as the most indispensable
> Google-owned web service. It is really really hard to avoid consuming
> YouTube content. It was probably the smartest startup acquisition
> ever. My privacy-oriented alternative is to watch YouTube videos
@@ -254,7 +254,7 @@ without filling your disk with gigabytes of content all at once.
The `download_playlist` function could be aware of the specific machine
that it is running on and apply specific policies depending on the
machine: always download everything; only download videos that aren't
-present anywhere else; etc.
+present anywhere else; *etc.*
## Conclusion
diff --git a/_articles/2019-06-02-stateless-os.md b/_articles/2019-06-02-stateless-os.md
index 2614b44..eae470a 100644
--- a/_articles/2019-06-02-stateless-os.md
+++ b/_articles/2019-06-02-stateless-os.md
@@ -125,7 +125,7 @@ manager](https://nixos.org/nix/) (not the whole NixOS) on your current
distribution (it can live alongside any other package manager).
If you have experience with declarative Emacs package managements, GNU
-Stow or any similar tool, etc., [I'd like some
+Stow or any similar tool, *etc.*, [I'd like some
tips](mailto:eu@euandre.org). If you don't have any experience at all,
[I'd still love to hear from you](mailto:eu@euandre.org).
diff --git a/_articles/2020-08-31-the-database-i-wish-i-had.md b/_articles/2020-08-31-the-database-i-wish-i-had.md
index 004a558..a134e2c 100644
--- a/_articles/2020-08-31-the-database-i-wish-i-had.md
+++ b/_articles/2020-08-31-the-database-i-wish-i-had.md
@@ -48,7 +48,7 @@ Let's go over what I mean by each of those aspects one by one.
I think the server-side database landscape is diverse and mature enough for
my needs (even though I end up choosing SQLite most of the time), and what I'm
after is a database to be embedded on client-side applications itself, be it
-desktop, browser, mobile, etc.
+desktop, browser, mobile, *etc.*
The purpose of such database is not to keep some local cache of data in case of
lost connectivity: we have good solutions for that already. It should serve as
@@ -84,13 +84,13 @@ that would have to be emulated~~[^posix-sqlite].
page. SQLite still is an implementation of a update-in-place, SQL,
table-oriented database. It is probably true that cherry-picking the
relevant parts of SQLite (like storage access, consistency, crash recovery,
- parser generator, etc.) and leaving out the unwanted parts (SQL, tables,
- threading, etc.) would be better than including the full SQLite stack, but
+ parser generator, *etc.*) and leaving out the unwanted parts (SQL, tables,
+ threading, *etc.*) would be better than including the full SQLite stack, but
that's simply an optimization. Both could even coexist, if desired.
SQLite would have to be treated similarly to how Datomic treats SQL
databases: instead of having a table for each entities, spread attributes
- over the tables, etc., it treats SQL databases as a key-value storage so it
+ over the tables, *etc.*, it treats SQL databases as a key-value storage so it
doesn't have to re-implement interacting with the disk that other databases
do well.
@@ -107,7 +107,7 @@ Node.js. However I want a tool that can be deployed anywhere, and not limit its
applications to places that already have a JavaScript runtime environment, or
force the developer to bundle a JavaScript runtime environment with their
application. This is true for GTK+ applications, command line programs, Android
-apps, etc.
+apps, *etc.*
[pouchdb]: https://pouchdb.com/
[couchdb]: https://couchdb.apache.org/
@@ -133,7 +133,7 @@ This would allow the database to adapt to where it is embedded: when targeting
the browser the IndexedDB storage API would provide the persistence layer
that the database requires, and similarly the POSIX filesystem storage API would
provide the persistence layer when targeting POSIX systems (like desktops,
-mobile, etc.).
+mobile, *etc.*).
But there's also an extra restriction that comes from by being embedded: it
needs to provide and embeddable artifact, most likely a binary library object
diff --git a/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md b/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
index 7960b8b..dad4334 100644
--- a/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
+++ b/_articles/2020-10-05-swift2nix-run-swift-inside-nix-builds.md
@@ -119,7 +119,7 @@ Instead a much saner approach could be:
filesystem layout with dependencies (i.e. exposing what the package manager
expects to find), let's call it `local-registry.json`;
4. if a `local-registry.json` was provided, do a build using that. Otherwise
- generate its own, by downloading the dependencies, arranging them, etc.
+ generate its own, by downloading the dependencies, arranging them, *etc.*
The point is just making what the package manager requires visible to the
outside world via some declarative data. If this data wasn't provided, it can
@@ -185,7 +185,7 @@ Package managers should provide exact dependencies via a data representation,
i.e. lockfiles, and expose via another data representation how they expect those
dependencies to appear on the filesystem, i.e. `local-registry.json`. This
allows package managers to provide an API so that external tools can create
-mirrors, offline builds, other registries, isolated builds, etc.
+mirrors, offline builds, other registries, isolated builds, *etc.*
"\*2nix" tools should build simple functions that leverage that
`local-registry.json`[^local-registry] data and offload all the rest back to the
diff --git a/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md b/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
index 4a0e4a0..320f3ab 100644
--- a/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
+++ b/_tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md
@@ -8,7 +8,7 @@ ref: send-emails-using-the-command-line-for-fun-and-profit
Here are a few reasons why:
1. send yourself and other people notification of cronjobs, scripts runs, CI
- jobs, etc.
+ jobs, *etc.*
2. leverage the POSIX pipe `|`, and pipe emails away!