mirror of
https://github.com/foo-dogsquared/wiki.git
synced 2025-02-07 06:19:03 +00:00
Update the files for convention
Apparently, the convention (at least starting from 2018) is to make the keywords and block names to be in lowercase as stated from one of the following discussions at https://orgmode.org/list/87tuuw3n15.fsf@nicolasgoaziou.fr/. The files was updated with a one liner of shell. However, this is Emacs and org-mode does have an API to let you do stuff in your config and interact with the documents internally so it is not an elegant solution in any way.
This commit is contained in:
parent
f1b33f9440
commit
aea7015cd5
116
2020-04-12-10-24-25.org
Executable file → Normal file
116
2020-04-12-10-24-25.org
Executable file → Normal file
@ -1,15 +1,13 @@
|
||||
#+TITLE: Reproducible research: methodological principles for transparent science
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-12 10:24:25 +08:00"
|
||||
#+DATE_MODIFIED: "2020-10-06 14:55:12 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: moocs writing
|
||||
|
||||
|
||||
- Source :: https://www.fun-mooc.fr/courses/course-v1:inria+41016+self-paced/about
|
||||
#+title: Reproducible research: methodological principles for transparent science
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-12 10:24:25 +08:00"
|
||||
#+date_modified: "2021-03-31 19:21:10 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+roam_tags: moocs writing @fleeting
|
||||
#+source :: https://www.fun-mooc.fr/courses/course-v1:inria+41016+self-paced/about
|
||||
|
||||
|
||||
I'm not a researcher but I've learned so many things from this course that are applicable to general workflows: organizing your digital files for easy retrieval, creating reproducible notes, and setting out to create reproducible studies with open formats.
|
||||
@ -34,18 +32,20 @@ Anything to make it explicit as possible for other researchers who may want to t
|
||||
|
||||
** Brief history of notes (from a Western point of view)
|
||||
|
||||
Clay tablets are the first recorded form of note-taking.
|
||||
In a quick bullet form:
|
||||
|
||||
- Clay tablets are the first recorded form of note-taking.
|
||||
Then, wax tablets and scrolls superceded the clay tablets.
|
||||
|
||||
And then, codices (or books) existed and replaced the scrolls as a common option.
|
||||
- And then, codices (or books) existed and replaced the scrolls as a common option.
|
||||
Along the fact that codices solve the common inconveniences from using a scroll (e.g., text navigation is difficult, no hard breaks for the text).
|
||||
Furthermore, it enabled notes with navigational features such as adding table of contents, an index, and paragraph indications (such as rubrics).
|
||||
|
||||
Eusebius, a historian, created a document referred as the "Eusebian Canons" demonstrating the first use of cross-references.
|
||||
- Eusebius, a historian, created a document referred as the "Eusebian Canons" demonstrating the first use of cross-references.
|
||||
|
||||
As the use of paper note-taking took off, more methods of note-taking has arised such as index notes, logbooks, and post-it notes each with their pros and cons.
|
||||
- As the use of paper note-taking took off, more methods of note-taking has arised such as index notes, logbooks, and post-it notes each with their pros and cons.
|
||||
|
||||
However, devices such as computers and digital tablets are becoming a viable option with the use of the right technology.
|
||||
- However, devices such as computers and digital tablets are becoming a viable option with the use of the right technology.
|
||||
|
||||
|
||||
** Plain-text formatting languages
|
||||
@ -53,8 +53,8 @@ However, devices such as computers and digital tablets are becoming a viable opt
|
||||
Word processors such as Microsoft Word, Google Docs, and LibreOffice Writer enables you to create documents but it can only be opened by them.
|
||||
|
||||
Plain-text files avert this problem that it can be opened by any text editors.
|
||||
However, they lack the markup formatting (e.g., inserting text in boldface and italics, attaching files, inserting images and tables) that documents produced by word processed possess.
|
||||
This is where markup languages such as HTML come into play giving us the ability to format our text.
|
||||
However, they lack the markup formatting (e.g., inserting text in boldface and italics, attaching files, inserting images and tables) that the formatted documents possess.
|
||||
This is where markup languages such as HTML, Markdown, and PhpBB come into play giving us the ability to format our text.
|
||||
However, certain markup languages like the aforementioned HTML can be hard-to-read.
|
||||
|
||||
Thus, a new subclass of markup languages are born, lightweight markup languages.
|
||||
@ -67,7 +67,7 @@ Examples include Markdown, Asciidoctor, Org-mode, and reStructuredText.
|
||||
I've created a dedicated note (see [[file:2020-06-27-16-21-47.org][Search tools and techniques]]) on this as derived from this course.
|
||||
|
||||
With digital files comes digital tools (and some techniques) to help us in searching for our notes.
|
||||
These can vary from complex technologies to simple format-agnostic techniques that can make querying files with specific information to be a breeze.
|
||||
These can vary from complex technologies to simple format-agnostic techniques that can make narrow searching an easy task.
|
||||
|
||||
- Desktop search engines such as DocFetcher and Recoll are one of your most powerful options.
|
||||
It can search through text and metadata quite fast.
|
||||
@ -98,8 +98,6 @@ More factors include:
|
||||
|
||||
- Lack of technical documentation which is against the rigorous and methodical nature of science.
|
||||
|
||||
In this course, it introduced three platforms for reproducible research: Jupyter Notebooks, R, and Org-mode.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -108,7 +106,7 @@ In this course, it introduced three platforms for reproducible research: Jupyter
|
||||
- With reproducible documents come replicable analysis.
|
||||
Obviously, the concept of research reproducibility is not valid until others can replicate the research.
|
||||
|
||||
- Acquired data from other sources shouldn't be edited "manually" (e.g., text editor) and everything regarding it would have to be modified with code.
|
||||
- Acquired data from other sources shouldn't be edited "manually" (e.g., text editor, database editor) and everything regarding it would have to be modified with code.
|
||||
This is especially important if you've spotted a missing chunk of the data.
|
||||
|
||||
- That said, missing and/or dubious data are normal due to lack of data collection or an error in data processing.
|
||||
@ -119,26 +117,26 @@ In this course, it introduced three platforms for reproducible research: Jupyter
|
||||
|
||||
* Real-life reproducible research
|
||||
|
||||
With the creating reproducible documents and doing replicable analysis, the rudimentary toolset needed for reproducible research is complete.
|
||||
However, as always with real-life situations, there are factors that always intervene from the plan.
|
||||
With reproducible documents and replicable analysis, the rudimentary toolset needed for reproducible research is complete.
|
||||
However, as always in the real world, there are challenges ahead.
|
||||
|
||||
|
||||
** Data hell
|
||||
|
||||
The first problem when encountering gathering of data is more often they are not of similar origins and nature.
|
||||
Furthermore, they are not often heterogenous data meaning we cannot easily establish the relationship among them.
|
||||
First, gathering data is often not of similar origins and nature.
|
||||
Furthermore, the data is often not heterogenous which means we cannot easily establish the relationship among them.
|
||||
|
||||
As much as text formats are an attractive option, there are complications assoicated with it.
|
||||
Particularly, data are often big and text generally consume more memory since text has to be converted into binary format to be usable in our software.
|
||||
As much as text formats are an attractive option, there are some tradeoffs you need to keep in mind.
|
||||
Data are often big and text generally consume more memory since text has to be converted into binary format.
|
||||
If we want to take less, we can consider our data to be in binary in the first place.
|
||||
|
||||
Binary formats are good for performance but there's a factor to consider it which is the [[file:20200710233027-endianness.org][Endianness]].
|
||||
They can be read differently depending on the computer architecture so it is best practice to announce the endianness at the start.
|
||||
Binary formats are good for performance but there's a factor to consider it which is the [[file:2020-07-10-23-30-27.org][Endianness]].
|
||||
They can be read differently depending on the computer architecture so it is best practice to announce the endianness in your paper.
|
||||
|
||||
Text formats, however, has the upper hand of easily adding *metadata* to our data which is a must for reproducible research.
|
||||
To get around this solution, we could look into established binary data formats that easily lets us add it.
|
||||
To get around this solution, we could look into established binary data formats that attempts to tackle this problem.
|
||||
It also has the advantage of using standardized tools that other researchers also use.
|
||||
Certain established binary formats suc as [[http://fits.gsfc.nasa.gov/][Flexible image transport system (FITS)]] and [[https://www.hdfgroup.org/][Hierarchical data format (HDF)]] solve those problems.
|
||||
Examples include [[http://fits.gsfc.nasa.gov/][Flexible image transport system (FITS)]] and [[https://www.hdfgroup.org/][Hierarchical data format (HDF)]].
|
||||
|
||||
Data can be archived offline but it is hard to share and distribute the sources and the results to other researchers.
|
||||
One can host the data themselves but the discoverability suffers which is not really in the spirit of research.
|
||||
@ -151,14 +149,20 @@ Software can get complex at a fast rate when we try to scale up our data.
|
||||
This is also added with the factor that software does not stand in the test of time, surprisingly.
|
||||
|
||||
With our data and code becoming complex, the resources needed to calculate all of it is increasing as well.
|
||||
Not to mention the longer notes which can make navigation a bit of a pain.
|
||||
Not to mention the longer (reproducible) notes which can make navigation a bit of a pain.
|
||||
|
||||
Creating a well-structured document can help our readers for this but it does not avoid the problem when the document is becoming too long for an overview.
|
||||
Creating a well-structured document can help our readers but it does not avoid the problem when the document is becoming too long for an overview.
|
||||
Certain notebooks like Org-mode enables folding of the document and only unfolding the sections that we want to see.
|
||||
Having a long reproducible document can also have a performance problem.
|
||||
Certain notebooks like Jupyter offer the option of delegating the calcuations to a supercomputer.
|
||||
|
||||
A recommended solution is introducing a *workflow engine* that takes a *workflow* as input.
|
||||
Having a long reproducible document can also have a performance problem.
|
||||
Certain options are trying to get around this:
|
||||
|
||||
- Jupyter offer the option of delegating the calcuations to a supercomputer.
|
||||
|
||||
- As of 2021-03-31, the Emacs community is trying to bring the editor into native code which in turn improves the situation for Org-Mode.
|
||||
[fn:: Even though Org-Mode can be separated outside of Emacs, one cannot deny it is one of the major parts of Emacs at this point.]
|
||||
|
||||
Another solution is introducing a *workflow engine* that takes a *workflow* as input.
|
||||
A workflow is a language describes each step of the study into a digestible graph.
|
||||
It lets you process data in different programming languages and execute them in a linear way to prevent side effects.
|
||||
The process of creating reproducible documents can get complex therefore create a complex workflow but it has the added property of reusability for certain sections which then can be used by others.
|
||||
@ -171,14 +175,14 @@ The professors recommend to think through the process before using a tool.
|
||||
It is not bad to start with the notebooks first and as the study becomes increasingly complex, you can try to migrate to using a workflow.
|
||||
|
||||
The problems of software doesn't end there, however.
|
||||
For instance, under the popular software and libraries like R, [[https://www.scipy.org/][SciPy]], and [[https://matplotlib.org/][Matplotlib]] are full of abstractions which can mean they use a lot packages.
|
||||
For instance, under the popular software and libraries like R, [[https://www.scipy.org/][SciPy]], and [[https://matplotlib.org/][Matplotlib]] are full of abstractions which can mean they use a lot of packages.
|
||||
Most of the software should be able to let you know about the versions (and even the complete environment like the following R code block, for example).
|
||||
|
||||
#+BEGIN_SRC R :results output :exports both
|
||||
#+begin_src R :results output :exports both
|
||||
R.version
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
#+begin_example
|
||||
_
|
||||
platform x86_64-pc-linux-gnu
|
||||
@ -200,13 +204,13 @@ nickname See Things Now
|
||||
Even then, specifying versions explicitly can only do so little since most of these libraries depend on another (SciPy, for example depends on C).
|
||||
It could still "break" if your machine or the library has been updated which may or may not contain breaking changes.
|
||||
|
||||
To get around this, we have to capture the environment that our code run.
|
||||
To get around this, we have to capture the environment of our code.
|
||||
There are tools that specialize in this function.
|
||||
|
||||
- Self-contained bundling tools like [[https://github.com/VIDA-NYU/reprozip][ReproZip]] exists, allowing to easily freeze the environment and share it with your colleagues.
|
||||
- Self-contained bundling tools like [[https://github.com/VIDA-NYU/reprozip][ReproZip]] freezes the environment and share it with your colleagues.
|
||||
However, if there is an issue in your code or document, you may have to rebuild the bundle.
|
||||
|
||||
- A more complete solution is a virtual machine (e.g., [[https://www.virtualbox.org/][VirtualBox]], [[https://www.qemu.org/][QEMU]]) but it can be heavy in resources where certain factors are not important and included in the image like the operating system or the hardware used.
|
||||
- A more complete solution is a virtual machine (e.g., [[https://www.virtualbox.org/][VirtualBox]], [[https://www.qemu.org/][QEMU]]) but it can be heavy in resources where certain factors are not important like the operating system or the hardware.
|
||||
|
||||
- Lighter alternatives to virtual machines like containers such as [[https://www.docker.com/][Docker]] or [[https://singularity.lbl.gov/][Singularity]] are more suitable for software environments.
|
||||
They also offer mostly the same security as virtual machines in that the environment is isolated from the host meaning no system libraries or programs will be used;
|
||||
@ -215,13 +219,13 @@ There are tools that specialize in this function.
|
||||
- Certain package managers like [[https://nixos.org/][Nix]] and [[https://guix.gnu.org/][GNU Guix]] specialize in retrieving reproducible environments.
|
||||
|
||||
As mentioned before, software are fragile: they can easily evolve and break.
|
||||
This is especially true for fast-moving software and libraries like Python 3 and even Org-mode by the fact that it is majorly changed 9 times.
|
||||
This is especially true for fast-moving software and libraries like Python 3 and even Org-mode by the fact that it goes through major changes 9 times.
|
||||
These breaking changes can interrupt the workflow which is why it is important to look out for changes.
|
||||
Another solution is to force some rulings such as coding exclusively in C or only use certain libraries and reimplement anything else.
|
||||
Capturing the environments used for calculations is a matter of compromise and stability.
|
||||
|
||||
Software can also be fragile that it can be easily deleted.
|
||||
Just like how data has dedicated archives, certain platforms have dedicated missions to preserve software like [[https://www.softwareheritage.org/][Software Heritage]], [[https://hal.archives-ouvertes.fr][Hyper Articles en Ligne]], and [[https://archive.org/][Internet Archive]].
|
||||
Just like how data has dedicated archives, certain platforms have dedicated to preserve software like [[https://www.softwareheritage.org/][Software Heritage]], [[https://hal.archives-ouvertes.fr][Hyper Articles en Ligne]], and [[https://archive.org/][Internet Archive]].
|
||||
|
||||
|
||||
** Numeric hell
|
||||
@ -229,11 +233,11 @@ Just like how data has dedicated archives, certain platforms have dedicated miss
|
||||
In today's world where computers aids in research such as calculations, there are hidden factors looming in.
|
||||
For example, representing floating points is particularly difficult and has resulted in certain quirks like the following code in Python.
|
||||
|
||||
#+BEGIN_SRC python :results output
|
||||
#+begin_src python :results output
|
||||
print(0.1 + 0.2)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 0.30000000000000004
|
||||
|
||||
Not to mention, compilers can also affect the results by optimizing the code and may result in changing the order of the computations which is not a good thing for reproducible researches.
|
||||
@ -251,15 +255,15 @@ The seed is then computated to get the first state, then the output of the first
|
||||
To make our research reproducible, we have to hardcode the seed or at least refer to it somewhere.
|
||||
Here's an example of generating random numbers in Python with a fixed input.
|
||||
|
||||
#+BEGIN_SRC python :results output
|
||||
#+begin_src python :results output
|
||||
import random
|
||||
|
||||
random.seed(24)
|
||||
for i in range(5):
|
||||
print(random.random())
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 0.7123429878269185
|
||||
: 0.8397997363118733
|
||||
: 0.18259188695451745
|
||||
@ -268,19 +272,19 @@ for i in range(5):
|
||||
|
||||
If the same seed is used for pseudo-random number generating, we can then verify it.
|
||||
|
||||
#+BEGIN_SRC python :results silent :exports code
|
||||
#+begin_src python :results silent :exports code
|
||||
import random
|
||||
|
||||
random.seed(24)
|
||||
assert random.random() == 0.7123429878269185
|
||||
assert random.random() == 0.8397997363118733
|
||||
assert random.random() == 0.18259188695451745
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
|
||||
|
||||
#+LaTeX: \appendix
|
||||
#+latex: \appendix
|
||||
* Additional readings
|
||||
|
||||
- [[https://www.fun-mooc.fr/courses/course-v1:inria+41016+self-paced/info][The course link]] :: It is a great open course with great instructors, examples, and exercises to make the lessons stick with you.
|
||||
|
16
2020-04-12-11-20-53.org
Executable file → Normal file
16
2020-04-12-11-20-53.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Reproducible research
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-12 11:20:53 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 04:57:13 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Reproducible research
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-12 11:20:53 +08:00"
|
||||
#+date_modified: "2020-09-09 04:57:13 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Creating your research reproducible can create the following benefits:
|
||||
|
16
2020-04-12-13-07-20.org
Executable file → Normal file
16
2020-04-12-13-07-20.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Text Encoding Initiative
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-12 13:07:20 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:16:32 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Text Encoding Initiative
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-12 13:07:20 +08:00"
|
||||
#+date_modified: "2020-09-09 05:16:32 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Having your research stored as text files written in a lightweight markup language is great.
|
||||
|
16
2020-04-13-17-32-27.org
Executable file → Normal file
16
2020-04-13-17-32-27.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: File metadata
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-13 17:32:27 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:17:29 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: File metadata
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-13 17:32:27 +08:00"
|
||||
#+date_modified: "2020-09-09 05:17:29 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
File metadata is one of the most subtle requirements in [[file:2020-04-23-23-21-47.org][Personal information management]] (or at least, that's what I think).
|
||||
|
18
2020-04-14-18-28-55.org
Executable file → Normal file
18
2020-04-14-18-28-55.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Maintain your own digital library
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-14 18:28:55 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 23:28:48 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: pim
|
||||
#+title: Maintain your own digital library
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-14 18:28:55 +08:00"
|
||||
#+date_modified: "2020-09-14 23:28:48 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+tags: pim
|
||||
|
||||
|
||||
Having your own digital library can be one of the most valuable thing for your life.
|
||||
|
16
2020-04-15-14-35-55.org
Executable file → Normal file
16
2020-04-15-14-35-55.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Note-taking
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-15 14:35:55 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:17:29 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Note-taking
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-15 14:35:55 +08:00"
|
||||
#+date_modified: "2020-09-09 05:17:29 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
The practice of note-taking is universal — it is everybody's concern how to write their findings efficiently with the use of a [[file:2020-04-23-23-21-47.org][Personal information management]] system.
|
||||
|
16
2020-04-15-20-41-51.org
Executable file → Normal file
16
2020-04-15-20-41-51.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Add a desktop search engine for your digital library
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-15 20:41:51 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:09:41 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Add a desktop search engine for your digital library
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-15 20:41:51 +08:00"
|
||||
#+date_modified: "2020-09-09 05:09:41 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Desktop search engines adds a crucial thing for [[file:2020-04-14-18-28-55.org][Maintaining your own digital library]]: retrievability.
|
||||
|
78
2020-04-17-21-41-30.org
Executable file → Normal file
78
2020-04-17-21-41-30.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Org-mode: Babel
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-17 21:41:30 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-19 17:53:44 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTIES: header-args :session :exports both
|
||||
#+ROAM_TAGS: reproducible-research
|
||||
#+title: Org-mode: Babel
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-17 21:41:30 +08:00"
|
||||
#+date_modified: "2020-09-19 17:53:44 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+properties: header-args :session :exports both
|
||||
#+roam_tags: reproducible-research
|
||||
|
||||
|
||||
Org-babel is the framework that enables [[file:2020-04-20-16-51-40.org][Org-mode]] to insert output of the code from programming languages.
|
||||
@ -20,11 +20,11 @@ As of 2020-06-08, [[https://orgmode.org/worg/org-contrib/babel/languages.html][B
|
||||
|
||||
Here's an example of a code block executed with the shell.
|
||||
|
||||
#+BEGIN_SRC sh
|
||||
#+begin_src sh
|
||||
echo "HELLO WORLD"
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: HELLO WORLD
|
||||
|
||||
To execute the code block, simply run ~org-babel-execute-src-block~ (by default, this is mapped in ~<C-c> <C-c>~).
|
||||
@ -35,24 +35,24 @@ Each of the supported language may also have an exclusive option with each langu
|
||||
For example, with Python 3, you can pretty print it in accordance to Org-mode display.
|
||||
An array will create a table, for instance with ~:results value~ [[https://orgmode.org/manual/Using-Header-Arguments.html#Using-Header-Arguments][header argument]].
|
||||
|
||||
#+BEGIN_SRC python :results value
|
||||
#+begin_src python :results value
|
||||
[["Item", "Value"], ["Baseball bat", 123], ["Baseball glove", 25], ["Printed shirt", 42]]
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: None
|
||||
|
||||
You can also export graphics with tools such as [[http://gnuplot.info/][Gnuplot]], [[https://www.gnu.org/software/octave/][GNU Octave]], [[https://www.r-project.org/][R]], and even [[https://www.latex-project.org/][LaTeX]].
|
||||
With it, you can export the graphics into a file (commonly with ~:file <PATH>~).
|
||||
|
||||
#+BEGIN_SRC gnuplot :exports both :file wooosh.png
|
||||
#+begin_src gnuplot :exports both :file wooosh.png
|
||||
unset arrow
|
||||
unset label
|
||||
set grid
|
||||
splot x**2+y**2, x**2-y**2
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
|
||||
With Org-babel, you can share either the output, the code used to generate the output, or both.
|
||||
This is commonly set with the ~:exports~ header argument.
|
||||
@ -60,13 +60,13 @@ This is commonly set with the ~:exports~ header argument.
|
||||
|
||||
Here's an example where I decided to show only the output with ~:exports results~.
|
||||
|
||||
#+BEGIN_SRC gnuplot :exports results :file threeeeeeD.png
|
||||
#+begin_src gnuplot :exports results :file threeeeeeD.png
|
||||
set title "3D gnuplot demo"
|
||||
unset grid
|
||||
splot x*y with points
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
[[file:threeeeeeD.png]]
|
||||
|
||||
|
||||
@ -80,23 +80,23 @@ However, you can connect source code blocks (with the supported languages) in th
|
||||
Let's start with a simple example where we want to demonstrate some Python shenanigans.
|
||||
Here's one Python code block.
|
||||
|
||||
#+BEGIN_SRC python :results output :session python-example
|
||||
#+begin_src python :results output :session python-example
|
||||
x = 35
|
||||
print(x)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 35
|
||||
|
||||
Then here's another code block in the same session.
|
||||
|
||||
#+BEGIN_SRC python :results output :session python-example
|
||||
#+begin_src python :results output :session python-example
|
||||
for i in range(5):
|
||||
x += 5
|
||||
print(x)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 40
|
||||
: 45
|
||||
: 50
|
||||
@ -113,19 +113,19 @@ To correct this, simply execute ~org-babel-execute-buffer~.
|
||||
|
||||
You can also pass Org-mode variables (from ~#+NAME: <VAR>~) [fn:: Technically called an internal link (https://orgmode.org/org.html#Internal-Links).] into the source code blocks with the ~:var <NAMEC>=<DATA>~ (though, this may vary among Babel runtimes).
|
||||
|
||||
#+NAME: example_string
|
||||
#+name: example_string
|
||||
This is the string.
|
||||
|
||||
#+BEGIN_SRC python :var example=example_string :results value
|
||||
#+begin_src python :var example=example_string :results value
|
||||
example
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: None
|
||||
|
||||
This is the source code from the document, for reference.
|
||||
|
||||
#+BEGIN_SRC org :exports code :results silent
|
||||
#+begin_src org :exports code :results silent
|
||||
,#+NAME: example_string
|
||||
This is the string.
|
||||
|
||||
@ -135,24 +135,24 @@ example
|
||||
|
||||
,#+RESULTS:
|
||||
,: This is the string.
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
Org-mode variables does capture an element as its input.
|
||||
This has a lot of implications of passing data between different sessions and even different languages.
|
||||
|
||||
For example, we could still capture the ~x~ variable from the previous Python code blocks.
|
||||
|
||||
#+NAME: var_from_other_lang
|
||||
#+BEGIN_SRC python :results silent :session python-example :exports value
|
||||
#+name: var_from_other_lang
|
||||
#+begin_src python :results silent :session python-example :exports value
|
||||
x # Which should be 60 at this point.
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
Then, pass it to some other Org-mode blocks with the variable.
|
||||
(Since the captured variable are always going to be a string, we have to convert it into the appropriate type.)
|
||||
|
||||
#+BEGIN_SRC R :results output :var python_var=var_from_other_lang
|
||||
#+begin_src R :results output :var python_var=var_from_other_lang
|
||||
as.numeric(python_var) + 2
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: [1] 62
|
||||
|
18
2020-04-20-16-51-40.org
Executable file → Normal file
18
2020-04-20-16-51-40.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Org-mode
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-20 16:51:40 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:17:29 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: tools writing
|
||||
#+title: Org-mode
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-20 16:51:40 +08:00"
|
||||
#+date_modified: "2020-09-09 05:17:29 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+tags: tools writing
|
||||
|
||||
|
||||
At its core, [[https://orgmode.org/][Org-mode]] is a [[file:2020-04-23-23-21-47.org][Personal information management]] tool that deals with your tasks and schedules.
|
||||
|
30
2020-04-21-19-44-15.org
Executable file → Normal file
30
2020-04-21-19-44-15.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Org-mode as todo list manager
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-21 19:44:15 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:27:10 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+ROAM_TAGS: pim
|
||||
#+title: Org-mode as todo list manager
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-21 19:44:15 +08:00"
|
||||
#+date_modified: "2020-09-09 05:27:10 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+roam_tags: pim
|
||||
|
||||
|
||||
As previously stated, [[file:2020-04-20-16-51-40.org][Org-mode]] is first created as an outliner enabling you to manage tasks.
|
||||
@ -19,9 +19,9 @@ Here's some of the features you might be interested when using it as such.
|
||||
|
||||
Org-mode features [[https://orgmode.org/manual/Repeated-tasks.html][repeated tasks]] and it looks like the following.
|
||||
|
||||
#+BEGIN_SRC org :results silent
|
||||
#+begin_src org :results silent
|
||||
SCHEDULED: <2020-06-22 Mon +2d>
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
Any missed session will cause the agenda to keep overdued sessions and accumulate to repeat the tasks 'X' number of times with the number of overdued sessions.
|
||||
|
||||
@ -29,20 +29,20 @@ Some tasks does not work this way, however.
|
||||
You don't need to replace the batteries 5 times or brush your teeth 10 times to make up for it.
|
||||
For this, you can do the following.
|
||||
|
||||
#+BEGIN_SRC org :results silent
|
||||
#+begin_src org :results silent
|
||||
SCHEDULED: <2020-06-22 Mon ++2d>
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
One cool thing about it if you mark a task as done, it will simply create an entry of the task completed and update the base date.
|
||||
|
||||
#+BEGIN_SRC org :results silent
|
||||
#+begin_src org :results silent
|
||||
\* TODO Watch the lectures from Brian Harvey's SICP series (https://archive.org/details/ucberkeley-webcast-PL3E89002AA9B9879E?sort=titleSorter)
|
||||
SCHEDULED: <2020-06-24 Wed .+2d>
|
||||
:PROPERTIES:
|
||||
:LAST_REPEAT: [2020-06-22 Mon 22:01]
|
||||
:END:
|
||||
- State "DONE" from "TODO" [2020-06-22 Mon 22:01]
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
This will also integrate with certain features like the agenda views.
|
||||
You can see future entries along with the number of times you have to do to make up for the missed sessions.
|
||||
|
16
2020-04-23-23-21-47.org
Executable file → Normal file
16
2020-04-23-23-21-47.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Personal information management
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-04-23 23:21:47 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:17:10 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Personal information management
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-04-23 23:21:47 +08:00"
|
||||
#+date_modified: "2020-09-09 05:17:10 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Personal information management is self-explanatory as it is.
|
||||
|
18
2020-05-07-21-53-21.org
Executable file → Normal file
18
2020-05-07-21-53-21.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Evergreen notes
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-05-07 21:53:21 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 23:28:18 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: pim writing
|
||||
#+title: Evergreen notes
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-05-07 21:53:21 +08:00"
|
||||
#+date_modified: "2020-09-14 23:28:18 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+tags: pim writing
|
||||
|
||||
|
||||
My concept of evergreen notes is mainly inspired from [[https://notes.andymatuschak.org/z4SDCZQeRo4xFEQ8H4qrSqd68ucpgE6LU155C][Andy Matuschak's version]] in a way that focuses writing evergreen notes as a way of developing your knowledge.
|
||||
|
18
2020-05-09-12-48-23.org
Executable file → Normal file
18
2020-05-09-12-48-23.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Roam Research
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-05-09 12:48:23 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:17:30 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Roam Research
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-05-09 12:48:23 +08:00"
|
||||
#+date_modified: "2021-03-28 18:22:40 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Roam Research is a newly developing tool created by Conor White-Sullivan that focuses on creating a graph of notes instead of the traditional hierarchical system of most note-taking systems.
|
||||
@ -22,6 +22,6 @@ With the Zettelkasten-inspired system, you can use it to easily [[file:2020-06-0
|
||||
[fn:: Well, it is a glorified wiki with the focus for backlinks and knowledge graph.]
|
||||
|
||||
Roam is gaining popularity and more are considering to use it.
|
||||
However, it is closed source and thankfully open source alternatives like [[https://github.com/jethrokuan/org-roam][Org-roam]], [[https://github.com/andjar/dokuroam/][Dokuroam]], and [[https://github.com/athensresearch/athens][Athens]] started to fill our Roam-voided hearts.
|
||||
However, it is closed source and (thankfully) open source alternatives like [[https://github.com/jethrokuan/org-roam][Org-roam]], [[https://github.com/andjar/dokuroam/][Dokuroam]], and [[https://github.com/athensresearch/athens][Athens]] started to fill our Roam-voided hearts.
|
||||
|
||||
For seeing how Roam works, you can see the following videos by [[https://www.youtube.com/watch?v=RvWic15iXjk][Nat Eliason on using Roam to quickly outline an article]] and [[https://www.youtube.com/watch?v=vxOffM_tVHI][Thomas Frank covering the feature set of Roam]].
|
||||
|
16
2020-06-03-15-21-42.org
Executable file → Normal file
16
2020-06-03-15-21-42.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Computational processes
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-03 15:21:42 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:07:51 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Computational processes
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-03 15:21:42 +08:00"
|
||||
#+date_modified: "2020-09-09 05:07:51 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Just as a sorcerer needs spells, a programmer needs code to do its bidding.
|
||||
|
16
2020-06-04-21-32-23.org
Executable file → Normal file
16
2020-06-04-21-32-23.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Create evergreen notes with a digital garden
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-04 21:32:23 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:16:33 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Create evergreen notes with a digital garden
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-04 21:32:23 +08:00"
|
||||
#+date_modified: "2020-09-09 05:16:33 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
A [[https://github.com/MaggieAppleton/digital-gardeners][digital garden]] is a your space for creating carefully crafted notes (see [[file:2020-05-07-21-53-21.org][Evergreen notes]]).
|
||||
|
22
2020-06-09-06-21-37.org
Executable file → Normal file
22
2020-06-09-06-21-37.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: The overview of a programming environment
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-09 06:21:37 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:18:47 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: compsci
|
||||
#+title: The overview of a programming environment
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-09 06:21:37 +08:00"
|
||||
#+date_modified: "2020-09-09 05:18:47 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+tags: compsci
|
||||
|
||||
|
||||
The study of [[file:2020-06-03-15-21-42.org][Computational processes]] start with the study of a programming environment.
|
||||
@ -55,12 +55,12 @@ For this, a way to conditionally evaluate a value is a must for a programming la
|
||||
|
||||
Here's an example function of getting the absolute value of a number.
|
||||
|
||||
#+BEGIN_SRC scheme :results silent
|
||||
#+begin_src scheme :results silent
|
||||
(define (abs x)
|
||||
(cond
|
||||
((< x 0) (- x))
|
||||
(else x)))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
|
||||
|
26
2020-06-12-19-20-15.org
Executable file → Normal file
26
2020-06-12-19-20-15.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: File encryption with GPG
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-12 19:20:15 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:10:41 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+ROAM_TAGS: tools security
|
||||
#+title: File encryption with GPG
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-12 19:20:15 +08:00"
|
||||
#+date_modified: "2020-09-09 05:10:41 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+roam_tags: tools security
|
||||
|
||||
|
||||
GPG is mostly used for public-key cryptography, allowing you to publicly communicate with the recipient.
|
||||
@ -20,13 +20,13 @@ Using GPG boils to generating a key-pair, managing them, and signing and receivi
|
||||
A GPG key-pair is made up of two things: the public key and the private key.
|
||||
The public key can be shared... to the public while the private key should be guarded in secret.
|
||||
|
||||
#+BEGIN_SRC shell :results silent
|
||||
#+begin_src shell :results silent
|
||||
# List out the available keys.
|
||||
gpg --list-keys
|
||||
|
||||
# Generate a new key-pair.
|
||||
gpg --full-gen-key
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
|
||||
@ -35,13 +35,13 @@ gpg --full-gen-key
|
||||
|
||||
Encrypting and decrypting files are one of the main points of GPG.
|
||||
|
||||
#+BEGIN_SRC shell :results silent
|
||||
#+begin_src shell :results silent
|
||||
# This will encrypt a file and generate an obscured version of it at <FILE>.gpg.
|
||||
gpg --recipient <EMAIL> --encrypt <FILE>
|
||||
|
||||
# Decrypting is almost the same process.
|
||||
gpg --recipient <EMAIL> --output <FILE> --decrypt <FILE>.gpg
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
You can make more secured versions of encrypted file especially when you intended it to send it to a particular recipient.
|
||||
For example, you can encrypt your file with your private key and the public key of your recipient and only both of you know how to receive the file.
|
||||
|
16
2020-06-19-20-30-23.org
Executable file → Normal file
16
2020-06-19-20-30-23.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Writing clean code
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-19 20:30:23 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:19:39 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Writing clean code
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-19 20:30:23 +08:00"
|
||||
#+date_modified: "2020-09-09 05:19:39 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Code should be readable, simple, and concise.
|
||||
|
18
2020-06-24-14-33-42.org
Executable file → Normal file
18
2020-06-24-14-33-42.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: A good tagging system for files for reducing information overload
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-24 14:33:42 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 23:28:35 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+TAGS: pim
|
||||
#+title: A good tagging system for files for reducing information overload
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-24 14:33:42 +08:00"
|
||||
#+date_modified: "2020-09-14 23:28:35 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+tags: pim
|
||||
|
||||
|
||||
Nowadays, topics are starting to be viewed toward heterogeneity — they are a system of intra-related concepts.
|
||||
|
16
2020-06-25-12-37-23.org
Executable file → Normal file
16
2020-06-25-12-37-23.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Create a writing inbox to store your thoughts
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-25 12:37:23 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:16:33 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Create a writing inbox to store your thoughts
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-25 12:37:23 +08:00"
|
||||
#+date_modified: "2020-09-09 05:16:33 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
One of the best practices for [[file:2020-04-15-14-35-55.org][Note-taking]] is writing [[file:2020-06-25-13-12-09.org][Fleeting notes]] which are used to store essential information so that your brain doesn't have to.
|
||||
|
16
2020-06-25-13-12-09.org
Executable file → Normal file
16
2020-06-25-13-12-09.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Fleeting notes
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-25 13:12:09 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 04:58:41 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Fleeting notes
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-25 13:12:09 +08:00"
|
||||
#+date_modified: "2020-09-09 04:58:41 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Fleeting notes are a valuable scratchpad for our messy thoughts — it's natural to have a messy input since they are catered only to yourself.
|
||||
|
128
2020-06-25-23-24-24.org
Executable file → Normal file
128
2020-06-25-23-24-24.org
Executable file → Normal file
@ -1,12 +1,12 @@
|
||||
#+TITLE: Structure and interpretation of computer programs
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-02 12:41:43 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-12 01:21:36 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+ROAM_TAGS: @fleeting
|
||||
#+title: Structure and interpretation of computer programs
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-02 12:41:43 +08:00"
|
||||
#+date_modified: "2020-09-12 01:21:36 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
#+roam_tags: @fleeting
|
||||
|
||||
|
||||
This is just my personal notes on [[http://mitpress.mit.edu/sicp][Structure and interpretation of computer programs]].
|
||||
@ -35,7 +35,7 @@ A programming language often requires the following to have an effective way of
|
||||
A programming language lets us abstract procedures as a black box.
|
||||
Here's an example of implementing the square root given a number.
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (square x) (* x x))
|
||||
(define (improve guess x)
|
||||
(/ (+ guess (/ x guess)) 2))
|
||||
@ -54,9 +54,9 @@ Here's an example of implementing the square root given a number.
|
||||
(sqrt 4)
|
||||
(sqrt 100)
|
||||
(sqrt 45.65)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 2.0000000929222947
|
||||
: 10.000000000139897
|
||||
: 6.756478442187127
|
||||
@ -83,30 +83,30 @@ In order to learn about it, you need to know the key: *generalizing patterns*.
|
||||
|
||||
For example, say we have different functions for knowing the area of a shape.
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define pi 3.14)
|
||||
|
||||
(define (square-area r) (* r r))
|
||||
(define (circle-area r) (* pi r r))
|
||||
(define (hexagon-area r) (* (sqrt 3) 1.5 r r))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
|
||||
This could pass as a decent code if each area function is distinct from each other.
|
||||
However, all of the given area functions involves squaring the given parameter (~r~).
|
||||
We can separate that step in a function like the following.
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define pi 3.14)
|
||||
(define (area shape r) (* shape r r))
|
||||
|
||||
(define square 1)
|
||||
(define circle pi)
|
||||
(define hexagon (* (sqrt 3) 1.5))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
|
||||
|
||||
|
||||
@ -124,7 +124,7 @@ To make this possible, we have to separate the implementation of our data and th
|
||||
|
||||
** Exercise 1.2
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp :results silent
|
||||
#+begin_src racket :lang sicp :results silent
|
||||
(/ (+ 5 4
|
||||
(- 2
|
||||
(- 3
|
||||
@ -133,17 +133,17 @@ To make this possible, we have to separate the implementation of our data and th
|
||||
(* 3
|
||||
(- 6 2)
|
||||
(- 2 7)))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
** Exercise 1.3
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp :results silent
|
||||
#+begin_src racket :lang sicp :results silent
|
||||
(define (square x) (* x x))
|
||||
(define (sum-of-squares x y z)
|
||||
(define sum (+ (square x) (square y) (square z)))
|
||||
(- sum (square (min x y z))))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
** Exercise 1.5
|
||||
@ -161,31 +161,31 @@ Alyssa P. Hacker doesn't see why if needs to be provided as a special form.
|
||||
"Why can't I just define it as an ordinary procedure in terms of cond?" she asks.
|
||||
Alyssa's friend Eva Lu Ator claims this can indeed be done, and she defines a new version of if:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(define (new-if predicate then-clause else-clause)
|
||||
(cond (predicate then-clause)
|
||||
(else else-clause)))
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Eva demonstrates the program for Alyssa:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(new-if (= 2 3) 0 5)
|
||||
5
|
||||
|
||||
(new-if (= 1 1) 0 5)
|
||||
0
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Delighted, Alyssa uses new-if to rewrite the square-root program:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(define (sqrt-iter guess x)
|
||||
(new-if (good-enough? guess x)
|
||||
guess
|
||||
(sqrt-iter (improve guess x)
|
||||
x)))
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
What happens when Alyssa attempts to use this to compute square roots? Explain.
|
||||
#+end_quote
|
||||
@ -217,7 +217,7 @@ This is especially true with floating points arithmetics.
|
||||
|
||||
In implementing our improved square root implementation from the question, we start with editing the ~improve~ function.
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (square x) (* x x))
|
||||
(define (improve guess x)
|
||||
(/ (+ guess (/ x guess)) 2))
|
||||
@ -238,9 +238,9 @@ In implementing our improved square root implementation from the question, we st
|
||||
(sqrt 0.0001)
|
||||
(sqrt 0.00001)
|
||||
(sqrt 123456789000000)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 2.000000000000002
|
||||
: 1.0
|
||||
: 0.01
|
||||
@ -266,7 +266,7 @@ Use this formula to implement a cube-root procedure analogous to the square-root
|
||||
(In section 1.3.4 we will see how to implement Newton's method in general as an abstraction of these square-root and cube-root procedures.)
|
||||
#+end_quote
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (square x) (* x x))
|
||||
(define (improve guess x)
|
||||
(/ (+ (- x (square guess)) (* guess 2)) 3))
|
||||
@ -283,9 +283,9 @@ Use this formula to implement a cube-root procedure analogous to the square-root
|
||||
(cbrt-iter 1.0 x))
|
||||
|
||||
(cbrt 9)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 3.000163135454436
|
||||
|
||||
|
||||
@ -294,7 +294,7 @@ Use this formula to implement a cube-root procedure analogous to the square-root
|
||||
#+begin_quote
|
||||
Each of the following two procedures defines a method for adding two positive integers in terms of the procedures ~inc~, which increments its argument by 1, and ~dec~, which decrements its argument by 1.
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(define (+ a b)
|
||||
(if (= a 0)
|
||||
b
|
||||
@ -304,7 +304,7 @@ Each of the following two procedures defines a method for adding two positive in
|
||||
(if (= a 0)
|
||||
b
|
||||
(+ (dec a) (inc b))))
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Using the substitution model, illustrate the process generated by each procedure in evaluating (+ 4 5).
|
||||
Are these processes iterative or recursive?
|
||||
@ -312,7 +312,7 @@ Are these processes iterative or recursive?
|
||||
|
||||
For the first definition, the resulting evaluation would have to look something like the following:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(+ 4 5)
|
||||
(inc (+ 3 5))
|
||||
(inc (inc (+ 2 5)))
|
||||
@ -323,20 +323,20 @@ For the first definition, the resulting evaluation would have to look something
|
||||
(inc (inc 7))
|
||||
(inc 8)
|
||||
9
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Based from the visualization, it seems it is a recursive process.
|
||||
|
||||
As for the second definition, the resulting evaluation would look like the following:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(+ 4 5)
|
||||
(+ 3 6)
|
||||
(+ 2 7)
|
||||
(+ 1 8)
|
||||
(+ 0 9)
|
||||
9
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
As each iteration does not result in embedding procedures in one big procedure, I think it is considered as an iterative process.
|
||||
|
||||
@ -346,28 +346,28 @@ As each iteration does not result in embedding procedures in one big procedure,
|
||||
#+begin_quote
|
||||
The following procedure computes a mathematical function called Ackermann's function.
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(define (A x y)
|
||||
(cond ((= y 0) 0)
|
||||
((= x 0) (* 2 y))
|
||||
((= y 1) 2)
|
||||
(else (A (- x 1)
|
||||
(A x (- y 1))))))
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
What are the values of the following expressions?
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(A 1 10)
|
||||
|
||||
(A 2 4)
|
||||
|
||||
(A 3 3)
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Consider the following procedures, where A is the procedure defined above:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(define (f n) (A 0 n))
|
||||
|
||||
(define (g n) (A 1 n))
|
||||
@ -375,7 +375,7 @@ Consider the following procedures, where A is the procedure defined above:
|
||||
(define (h n) (A 2 n))
|
||||
|
||||
(define (k n) (* 5 n n))
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
Give concise mathematical definitions for the functions computed by the procedures ~f~, ~g~, and ~h~ for positive integer values of $n$.
|
||||
For example, ~(k n)~ computes $5n^2$.
|
||||
@ -383,7 +383,7 @@ For example, ~(k n)~ computes $5n^2$.
|
||||
|
||||
For the sake of completeness, here is the function in question along with the given example usage (and its results in the following block):
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (A x y)
|
||||
(cond ((= y 0) 0)
|
||||
((= x 0) (* 2 y))
|
||||
@ -394,9 +394,9 @@ For the sake of completeness, here is the function in question along with the gi
|
||||
(A 1 10)
|
||||
(A 2 4)
|
||||
(A 3 3)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 1024
|
||||
: 65536
|
||||
: 65536
|
||||
@ -416,14 +416,14 @@ The procedure can be rewritten so that the sum is performed iteratively.
|
||||
Show how to do this by filling in the missing expressions in the following definition:
|
||||
#+end_quote
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (sum term a next b)
|
||||
(define (iter a result)
|
||||
(if (> a b)
|
||||
result
|
||||
(iter (next a) (+ result a))))
|
||||
(iter a 0))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
|
||||
** Exercise 1.31a
|
||||
@ -439,7 +439,7 @@ Also use ~product~ to compute approximations to \pi using the formula.
|
||||
\end{equation*}
|
||||
#+end_quote
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (product term a next b)
|
||||
(if (> a b)
|
||||
term
|
||||
@ -465,9 +465,9 @@ Also use ~product~ to compute approximations to \pi using the formula.
|
||||
(wallis_prod 5)
|
||||
(wallis_prod 10)
|
||||
(wallis_prod 20)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: 1
|
||||
: 120
|
||||
: 3628800
|
||||
@ -511,7 +511,7 @@ If it generates an iterative process, write one that generates a recursive proce
|
||||
|
||||
Based from my answer in Exercise 1.31a, we can simply see whether we have created an iterative or recursive process simply with the ~trace~ function.
|
||||
|
||||
#+BEGIN_SRC racket :lang racket
|
||||
#+begin_src racket :lang racket
|
||||
(require racket/trace)
|
||||
(define (product total fn a b)
|
||||
(if (> a b)
|
||||
@ -523,9 +523,9 @@ Based from my answer in Exercise 1.31a, we can simply see whether we have create
|
||||
|
||||
(trace product)
|
||||
(factorial 5)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
: >(product 1 #<procedure:...v3/ob-PoMhn9.rkt:10:13> 1 5)
|
||||
: >(product 1 #<procedure:...v3/ob-PoMhn9.rkt:10:13> 2 5)
|
||||
: >(product 2 #<procedure:...v3/ob-PoMhn9.rkt:10:13> 3 5)
|
||||
@ -538,7 +538,7 @@ Based from my answer in Exercise 1.31a, we can simply see whether we have create
|
||||
With our implementation, we can see it is an iterative process.
|
||||
The following code block is its recursive equivalent along with the stack trace for comprehension.
|
||||
|
||||
#+BEGIN_SRC racket :lang racket
|
||||
#+begin_src racket :lang racket
|
||||
(require racket/trace)
|
||||
(define (product total fn a b)
|
||||
(if (> a b)
|
||||
@ -550,9 +550,9 @@ The following code block is its recursive equivalent along with the stack trace
|
||||
|
||||
(trace product)
|
||||
(factorial 5)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
#+RESULTS:
|
||||
#+results:
|
||||
#+begin_example
|
||||
>(product 1 #<procedure:...v3/ob-lY382a.rkt:10:13> 1 5)
|
||||
> (product 1 #<procedure:...v3/ob-lY382a.rkt:10:13> 2 5)
|
||||
@ -575,17 +575,17 @@ The following code block is its recursive equivalent along with the stack trace
|
||||
#+begin_quote
|
||||
Show that ~sum~ and ~product~ (exercise 1.31) are both special cases of a still more general notion called ~accumulate~ that combines a collection of terms, using some general accumulation function:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
#+begin_example
|
||||
(accumulate combiner null-value term a next b)
|
||||
#+END_EXAMPLE
|
||||
#+end_example
|
||||
|
||||
~accumulate~ takes as arguments the same term and range specifications as sum and product, together with a combiner procedure (of two arguments) that specifies how the current term is to be combined with the accumulation of the preceding terms and a null-value that specifies what base value to use when the terms run out.
|
||||
Write ~accumulate~ and show how ~sum~ and ~product~ can both be defined as simple calls to ~accumulate~.
|
||||
#+end_quote
|
||||
|
||||
#+BEGIN_SRC racket :lang sicp
|
||||
#+begin_src racket :lang sicp
|
||||
(define (accumulate combiner null-value term a next b)
|
||||
(if (> a b)
|
||||
term
|
||||
(accumulate combiner null-value (combiner (next a) term) (next a) next b)))
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
16
2020-06-27-16-21-47.org
Executable file → Normal file
16
2020-06-27-16-21-47.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Apply search tools and techniques for your digital library
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-27 16:21:47 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:09:41 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+ROAM_TAGS: pim
|
||||
#+title: Apply search tools and techniques for your digital library
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-27 16:21:47 +08:00"
|
||||
#+date_modified: "2020-09-09 05:09:41 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+roam_tags: pim
|
||||
|
||||
|
||||
With digital files comes digital tools (and some techniques) to help us in searching for our notes.
|
||||
|
16
2020-06-27-18-31-40.org
Executable file → Normal file
16
2020-06-27-18-31-40.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: When reading mathematical texts, write down the simplest possible example
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-27 18:31:40 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 04:58:42 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: When reading mathematical texts, write down the simplest possible example
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-27 18:31:40 +08:00"
|
||||
#+date_modified: "2020-09-09 04:58:42 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
On practice, writing down the simplest possible examples allows you to get started working on the definitions.
|
||||
|
16
2020-06-28-06-19-24.org
Executable file → Normal file
16
2020-06-28-06-19-24.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Bidirectional links
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-06-28 06:19:24 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:16:33 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Bidirectional links
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-06-28 06:19:24 +08:00"
|
||||
#+date_modified: "2020-09-09 05:16:33 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Ever since [[file:2020-05-09-12-48-23.org][Roam Research]] became a popular option for [[file:2020-04-15-14-35-55.org][Note-taking]], there has been interest in one of its popular features: bidirectional linking.
|
||||
|
16
2020-07-01-23-19-07.org
Executable file → Normal file
16
2020-07-01-23-19-07.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Information literacy
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-07-01 23:19:07 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:09:40 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Information literacy
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-07-01 23:19:07 +08:00"
|
||||
#+date_modified: "2020-09-09 05:09:40 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Information literacy is defined as the ability to search information, sort the results, verify for legitimacy, and share the information effectively.
|
||||
|
16
2020-07-06-03-47-52.org
Executable file → Normal file
16
2020-07-06-03-47-52.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Refer to advanced resources when skill-building for a solid short-term goal
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-07-06 03:47:52 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:09:40 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Refer to advanced resources when skill-building for a solid short-term goal
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-07-06 03:47:52 +08:00"
|
||||
#+date_modified: "2020-09-09 05:09:40 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
When starting out to build a skill like programming, 3D modelling, digital art, or cooking, you can look first for expert-created resources.
|
||||
|
16
2020-07-06-23-55-47.org
Executable file → Normal file
16
2020-07-06-23-55-47.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Deliberate practice
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-07-06 23:55:47 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:22:41 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Deliberate practice
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-07-06 23:55:47 +08:00"
|
||||
#+date_modified: "2020-09-09 05:22:41 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Unlike regular practice that involves mindless repetitions, deliberate practice involves purposeful sessions.
|
||||
|
16
2020-07-08-22-42-47.org
Executable file → Normal file
16
2020-07-08-22-42-47.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: When learning a new skill, begin with a specific end-goal to create a solid starting point
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-07-08 22:42:47 +08:00"
|
||||
#+DATE_MODIFIED: "2020-12-05 21:43:46 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: When learning a new skill, begin with a specific end-goal to create a solid starting point
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-07-08 22:42:47 +08:00"
|
||||
#+date_modified: "2020-12-05 21:43:46 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
This top-bottom learning approach (i.e., specific to general topics) is often used by self-learners.
|
||||
|
16
2020-07-10-23-30-27.org
Executable file → Normal file
16
2020-07-10-23-30-27.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Endianness
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-07-10 23:30:27 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:23:55 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Endianness
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-07-10 23:30:27 +08:00"
|
||||
#+date_modified: "2020-09-09 05:23:55 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- Tags :: [[file:2020-06-03-15-21-42.org][Computational processes]]
|
||||
|
16
2020-08-19-08-21-44.org
Executable file → Normal file
16
2020-08-19-08-21-44.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: GNU Guix
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-08-19 08:21:44 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-13 12:38:17 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Guix package manager
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-08-19 08:21:44 +08:00"
|
||||
#+date_modified: "2021-03-28 18:24:02 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
[[https://guix.gnu.org/][GNU Guix]] is a package manager that follows the footsteps of [[file:2020-09-04-16-07-47.org][Nix package manager]] in furthering [[file:2020-09-19-08-31-48.org][Functional package management]].
|
||||
|
16
2020-08-28-19-26-43.org
Executable file → Normal file
16
2020-08-28-19-26-43.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Linux drivers
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-09 05:27:17 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-18 03:06:06 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Linux drivers
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-09 05:27:17 +08:00"
|
||||
#+date_modified: "2020-09-18 03:06:06 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Linux drivers (also called as kernel modules) are software executed in the kernel.
|
||||
|
16
2020-09-04-16-07-47.org
Executable file → Normal file
16
2020-09-04-16-07-47.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Nix package manager
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-04 16:07:47 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:25:03 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Nix package manager
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-04 16:07:47 +08:00"
|
||||
#+date_modified: "2020-09-09 05:25:03 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
[[https://nixos.org/][Nix]] is a package manager that pioneered [[file:2020-09-19-08-31-48.org][Functional package management]] which addresses the criticisms of traditional Unix systems while making it as a specialized tool for [[file:2020-04-12-11-20-53.org][Reproducible research]].
|
||||
|
16
2020-09-04-19-57-06.org
Executable file → Normal file
16
2020-09-04-19-57-06.org
Executable file → Normal file
@ -1,8 +1,8 @@
|
||||
#+TITLE: Functional programming
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-04 19:57:06 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:25:37 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Functional programming
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-04 19:57:06 +08:00"
|
||||
#+date_modified: "2020-09-09 05:25:37 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
16
2020-09-11-04-08-34.org
Executable file → Normal file
16
2020-09-11-04-08-34.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Human-friendly color spaces
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-11 04:08:34 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-19 19:06:18 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Human-friendly color spaces
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-11 04:08:34 +08:00"
|
||||
#+date_modified: "2020-09-19 19:06:18 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- Tags :: [[file:2020-09-11-04-11-59.org][Computer graphics]]
|
||||
|
16
2020-09-11-04-11-59.org
Executable file → Normal file
16
2020-09-11-04-11-59.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Computer graphics
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-11 04:11:59 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-11 04:13:31 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Computer graphics
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-11 04:11:59 +08:00"
|
||||
#+date_modified: "2020-09-11 04:13:31 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Computing graphics is consists of (at least in my study):
|
||||
|
16
2020-09-13-19-42-06.org
Executable file → Normal file
16
2020-09-13-19-42-06.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Software packaging
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-13 19:42:06 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 00:15:26 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Software packaging
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-13 19:42:06 +08:00"
|
||||
#+date_modified: "2020-09-14 00:15:26 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
I've been dabbling with software packaging for a few days (as of 2020-09-13) and all I can say that it is a rewarding experience having to know different tools (e.g., build systems, version control systems).
|
||||
|
16
2020-09-14-05-54-45.org
Executable file → Normal file
16
2020-09-14-05-54-45.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Linked data
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-14 05:54:45 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 05:55:52 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Linked data
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-14 05:54:45 +08:00"
|
||||
#+date_modified: "2020-09-14 05:55:52 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- [[http://lab.cccb.org/en/wikidata-the-new-rosetta-stone/][Wikidata is the new Rosetta Stone]]
|
||||
|
16
2020-09-14-10-46-15.org
Executable file → Normal file
16
2020-09-14-10-46-15.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Reproducible builds
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-14 10:46:15 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 11:31:36 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Reproducible builds
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-14 10:46:15 +08:00"
|
||||
#+date_modified: "2020-09-14 11:31:36 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- [[https://reproducible-builds.org/][Reproducible builds]]
|
||||
|
20
2020-09-14-22-25-10.org
Executable file → Normal file
20
2020-09-14-22-25-10.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: GNU Guix packaging
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-14 22:25:10 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-14 23:53:35 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: GNU Guix packaging
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-14 22:25:10 +08:00"
|
||||
#+date_modified: "2020-09-14 23:53:35 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Practicing [[file:2020-09-13-19-42-06.org][Software packaging]] in [[file:2020-08-19-08-21-44.org][GNU Guix]] is pretty straightforward with several tools that the package manager provides.
|
||||
@ -24,9 +24,9 @@ This is a perfect use case for Guix with ~guix environment~ command.
|
||||
|
||||
The following is an example of an environment created with the Guix package manager:
|
||||
|
||||
#+BEGIN_SRC shell
|
||||
#+begin_src shell
|
||||
guix environment --pure guix --ad-hoc coreutils ripgrep neovim emacs
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
This creates a =virtualenv=-like environment with the packages listed with ~--ad-hoc~ (e.g., GNU Coreutils, Neovim, Emacs).
|
||||
|
||||
|
16
2020-09-15-03-08-22.org
Executable file → Normal file
16
2020-09-15-03-08-22.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Create package definitions for missing dependencies first before the package itself
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-15 03:08:22 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-15 03:18:37 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Create package definitions for missing dependencies first before the package itself
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-15 03:08:22 +08:00"
|
||||
#+date_modified: "2020-09-15 03:18:37 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Certain ecosystems like in [[file:2020-09-04-16-07-47.org][Nix package manager]] with [[https://github.com/NixOS/nixpkgs][nixpkgs]] or [[file:2020-08-19-08-21-44.org][GNU Guix]] within their own packages follow a standard (officially) [fn:: If not, you can freely ~make build~ all you want.] about making sure all dependencies are present first before building the package.
|
||||
|
24
2020-09-16-23-09-01.org
Executable file → Normal file
24
2020-09-16-23-09-01.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Use timestamps for effectively future-proofing your stuff
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-16 23:09:01 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-17 03:11:19 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Use timestamps for effectively future-proofing your stuff
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-16 23:09:01 +08:00"
|
||||
#+date_modified: "2020-09-17 03:11:19 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
One of the simplest ways to future-proof your documents with [[file:2020-04-13-17-32-27.org][File metadata]] is to create a timestamp.
|
||||
@ -21,10 +21,10 @@ Different files may be applied differently as long as we can create a unified in
|
||||
|
||||
Here's a special example with [[file:2020-04-20-16-51-40.org][Org-mode]] documents:
|
||||
|
||||
#+BEGIN_SRC org :exports none
|
||||
#+begin_src org :exports none
|
||||
\#+DATE: "2020-09-16 23:53:00 +08:00"
|
||||
\#+DATE_MODIFIED: "2020-09-17 10:33:42 +08:00"
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
Thankfully, Emacs has a [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Time-Stamps.html][time stamp]] feature that abstracts that for us.
|
||||
We can then attach the timestamp update with a [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Hooks.html#Hooks][hook]] that will occur before saving the file and voila!
|
||||
@ -32,7 +32,7 @@ Automated timestamp for our text documents.
|
||||
|
||||
Here's my (Doom Emacs) specific config as of 2020-09-17 for future references:
|
||||
|
||||
#+BEGIN_SRC elisp
|
||||
#+begin_src elisp
|
||||
(after org!
|
||||
(setq
|
||||
; Set a custom time-stamp pattern.
|
||||
@ -42,7 +42,7 @@ Here's my (Doom Emacs) specific config as of 2020-09-17 for future references:
|
||||
; Modify the time-stamp with each save.
|
||||
(setq time-stamp-format "%Y-%02m-%02d %02H:%02M:%02S%:z")
|
||||
(add-hook 'before-save-hook 'time-stamp)
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
This should be easily replicated to other editors.
|
||||
All you need from a text editor is the hooks and a search-and-replace feature [fn:: Maybe an option limiting the lines to be searched to prevent large search sessions as well.].
|
||||
|
16
2020-09-19-08-31-48.org
Executable file → Normal file
16
2020-09-19-08-31-48.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Functional package management
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-19 08:31:48 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-09 05:26:32 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Functional package management
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-19 08:31:48 +08:00"
|
||||
#+date_modified: "2020-09-09 05:26:32 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Functional package management (FPM) is the next step forward [[https://edolstra.github.io/pubs/nixos-icfp2008-final.pdf][pioneered by Eelco Dolstra]] with [[https://nixos.org/][NixOS]] as the living implementation.
|
||||
|
20
2020-09-19-18-43-07.org
Executable file → Normal file
20
2020-09-19-18-43-07.org
Executable file → Normal file
@ -1,11 +1,11 @@
|
||||
#+TITLE: Generating human-friendly color schemes
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-09-19 18:43:07 +08:00"
|
||||
#+DATE_MODIFIED: "2020-09-29 06:08:42 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Generating human-friendly color schemes
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-09-19 18:43:07 +08:00"
|
||||
#+date_modified: "2020-09-29 06:08:42 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Though we already have [[file:2020-09-11-04-08-34.org][Human-friendly colorspaces]], it doesn't mean that we can simply generate human-friendly color schemes.
|
||||
@ -15,7 +15,7 @@ Color spaces such as [[https://www.hsluv.org/][HSLuv]] and [[https://en.wikipedi
|
||||
We can simply generate colors with the aforementioned color spaces.
|
||||
Here's an example of a [[http://chriskempson.com/projects/base16/][Base16]] color scheme generation from [[https://terminal.sexy/][terminal.sexy]] ported to Rust.
|
||||
|
||||
#+BEGIN_SRC rust
|
||||
#+begin_src rust
|
||||
use std::error::Error;
|
||||
use std::collections::HashMap;
|
||||
use std::env;
|
||||
@ -131,7 +131,7 @@ fn main() -> Result<(), Box<dyn Error>> {
|
||||
println!("{:?}", result);
|
||||
Ok(())
|
||||
}
|
||||
#+END_SRC
|
||||
#+end_src
|
||||
|
||||
- [[https://www.hsluv.org/][HSLuv]]
|
||||
- [[https://www.kuon.ch/post/2020-03-08-hsluv/][This introductory article is a great resource on HSLuv]]
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Web annotations
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-10-30 00:49:22 +08:00"
|
||||
#+DATE_MODIFIED: "2020-10-30 01:04:35 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Web annotations
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-10-30 00:49:22 +08:00"
|
||||
#+date_modified: "2020-10-30 01:04:35 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- https://beepb00p.xyz/annotating.html
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Generate a color scheme based from a single color
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-11-05 17:21:58 +08:00"
|
||||
#+DATE_MODIFIED: "2020-11-19 19:32:26 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Generate a color scheme based from a single color
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-11-05 17:21:58 +08:00"
|
||||
#+date_modified: "2020-11-19 19:32:26 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
[[file:2020-09-19-18-43-07.org][Generating human-friendly color schemes]] has always been a disaster (for me) to figure out especially with no cursory knowledge whatsoever on color theory.
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Linguistics, style, and writing in the 21st century
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-11-14 22:07:13 +08:00"
|
||||
#+DATE_MODIFIED: "2020-11-15 03:17:44 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Linguistics, style, and writing in the 21st century
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-11-14 22:07:13 +08:00"
|
||||
#+date_modified: "2020-11-15 03:17:44 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
- talk :: [[https://youtu.be/OV5J6BfToSw][Linguistics, style, and writing in the 21st century]]
|
||||
@ -98,9 +98,9 @@ Passive voice offers a different way to order your thoughts.
|
||||
|
||||
* The curse of knowledge
|
||||
|
||||
#+BEGIN_QUOTE
|
||||
#+begin_quote
|
||||
Once you know something, it's hard to imagine from the perspective of a newcomer.
|
||||
#+END_QUOTE
|
||||
#+end_quote
|
||||
|
||||
The curse of knowledge — also known as hindsight bias, egocentrism, and mindblindness — is the tendency of the writer to not consider the background of the reader.
|
||||
This often makes the writing filled with unexplained jargon, abbreviations, and references that the reader may not know.
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Accounting basics
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "%![Error: (void-function user-mail-address)]"
|
||||
#+DATE: "2020-11-15 05:10:51 +08:00"
|
||||
#+DATE_MODIFIED: "2020-11-15 05:11:23 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Accounting basics
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "%![Error: (void-function user-mail-address)]"
|
||||
#+date: "2020-11-15 05:10:51 +08:00"
|
||||
#+date_modified: "2020-11-15 05:11:23 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
Accounting is knowing how much we have.
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: When beginning with 3D modelling, start with low-poly style
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-12-05 19:37:40 +08:00"
|
||||
#+DATE_MODIFIED: "2020-12-05 21:38:07 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: When beginning with 3D modelling, start with low-poly style
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-12-05 19:37:40 +08:00"
|
||||
#+date_modified: "2020-12-05 21:38:07 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
When you start with 3D modelling, you can start with low-poly style since it has the least amount of detail required thus get you efficient.
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Make personal backups effectively with the 3-2-1 rule
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-12-10 20:49:03 +08:00"
|
||||
#+DATE_MODIFIED: "2020-12-11 00:48:19 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Make personal backups effectively with the 3-2-1 rule
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-12-10 20:49:03 +08:00"
|
||||
#+date_modified: "2020-12-11 00:48:19 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
If you want to start good backup practices, the 3-2-1 rule is a good starting point.
|
||||
|
@ -1,11 +1,11 @@
|
||||
#+TITLE: Graphic design
|
||||
#+AUTHOR: "Gabriel Arazas"
|
||||
#+EMAIL: "foo.dogsquared@gmail.com"
|
||||
#+DATE: "2020-12-13 20:18:44 +08:00"
|
||||
#+DATE_MODIFIED: "2020-12-13 20:26:04 +08:00"
|
||||
#+LANGUAGE: en
|
||||
#+OPTIONS: toc:t
|
||||
#+PROPERTY: header-args :exports both
|
||||
#+title: Graphic design
|
||||
#+author: "Gabriel Arazas"
|
||||
#+email: "foo.dogsquared@gmail.com"
|
||||
#+date: "2020-12-13 20:18:44 +08:00"
|
||||
#+date_modified: "2020-12-13 20:26:04 +08:00"
|
||||
#+language: en
|
||||
#+options: toc:t
|
||||
#+property: header-args :exports both
|
||||
|
||||
|
||||
You see graphic design being used everywhere including in websites, movie posters, books (covers and everything), chocolate boxes, and glass cases.
|
||||
|
Loading…
Reference in New Issue
Block a user