remove more technical stuff
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
This commit is contained in:
parent
b29d3dda82
commit
83d21cf9b6
2 changed files with 31 additions and 25 deletions
3
.tokeignore
Normal file
3
.tokeignore
Normal file
|
@ -0,0 +1,3 @@
|
|||
public
|
||||
package-lock.json
|
||||
src/styles/fork-awesome
|
|
@ -13,24 +13,21 @@ time I made a surprising discovery -- many of them don't really use a calendar
|
|||
of any sort to manage their lives. Tracking something that happens more than a
|
||||
week into the future is generally out of the picture.
|
||||
|
||||
But I understand. Putting events into a calendar is kind of a chore. Calendars
|
||||
that are [standards-compliant][3] still primarily use email for the most part
|
||||
(sending invites, updating times, etc.) and calendars that aren't
|
||||
standards-compliant won't be compatible between different people unless they're
|
||||
using the same service.
|
||||
|
||||
[3]: https://datatracker.ietf.org/doc/html/rfc5545
|
||||
But I understand. Putting events into a calendar is kind of a chore. Traditional
|
||||
calendar apps still primarily use email for the most part (sending invites,
|
||||
updating times, etc.) and new-gen calendars suffer from the social network
|
||||
problem of having to get everyone on the same service.
|
||||
|
||||
The personal management story has always been kind of fragmented. Calendars are
|
||||
supposed to manage the entire picture of my personal schedule, yet they only see
|
||||
a small slice without more information. The only things calendars can see
|
||||
automatically with no intervention on my part are emails that happen to include
|
||||
.ics files.
|
||||
automatically with no intervention on my part are emails that are sent from
|
||||
airlines.
|
||||
|
||||
> I'm sure Google or Apple could probably ritz up their mail servers to scan text
|
||||
> and try to see if there's events without there being an actual .ics file, but
|
||||
> that's missing the point. The vast majority of people I associate with rarely
|
||||
> sends email events anymore.
|
||||
> I'm sure Google or Apple could probably ritz up their services to scan text
|
||||
> and guess events to put on your calendar, but that's missing the point. The vast
|
||||
> majority of people I associate with rarely coordinate events over email in the
|
||||
> first place.
|
||||
|
||||
## Journals
|
||||
|
||||
|
@ -60,9 +57,15 @@ die. But there's one important feature that I have started looking out for
|
|||
recently: the ability to attach arbitrary metadata to journal entries and be
|
||||
able to query for them.
|
||||
|
||||
I think the community is starting to realize that these journals are really just
|
||||
databases, and extracting structured fields is extremely important if you want
|
||||
any kind of smart understanding of what is being journaled.
|
||||
While new apps have been cropping up from time to time for a while now, I think
|
||||
something in common with the new ones these "journals" are really more like
|
||||
personal databases, and extracting structured fields is extremely important if
|
||||
you want any kind of smart understanding of what is being journaled.
|
||||
|
||||
For example, I could write "took the car in for repair today", but if I wanted
|
||||
to find previous instances of this or make any kind of history, I would have to
|
||||
essentially do a pure text search. However, with structured data this could be
|
||||
different.
|
||||
|
||||
[Logseq], the app that I've settled on, is backed by a [Datascript] store and
|
||||
exposes a lot of this functionality to you as a user. It allows you to query
|
||||
|
@ -84,22 +87,22 @@ particular and let me query on it later:
|
|||
|
||||
![performing a query in logseq](./logseqQuery.png)
|
||||
|
||||
I can write todo items inline in my journal and find them all at a time as well.
|
||||
As an example, here's all of the todo items that I've tagged specifically with
|
||||
#read:
|
||||
The query tool is very simple and easy to learn, and makes it easy to actually
|
||||
_use_ the information you wrote down, instead of just burying it into oblivion.
|
||||
|
||||
For example, I can write todo items inline in my journal and find them all at a
|
||||
time as well. As an example, here's all of the todo items that I've tagged
|
||||
specifically with the tag `#read`:
|
||||
|
||||
![reading list in logseq](./readingList.png)
|
||||
|
||||
The fact that it truly is a database means I can start piling things in here and
|
||||
automatically perform data extraction for a more complete picture of my daily
|
||||
life. In the future I'd like to do dumps for my sleep and health data as well
|
||||
and have Logseq be my ultimate source of truth.
|
||||
and have Logseq be my ultimate source of truth. I've started developing a
|
||||
[calendar plugin for Logseq][2] that will have the ability to display numerical
|
||||
data using various visualizations for this purpose.
|
||||
|
||||
I've also started developing a [calendar plugin for Logseq][2] that will have
|
||||
the ability to display numerical data using various visualizations by using the
|
||||
[D3] library.
|
||||
|
||||
[d3]: https://d3js.org/
|
||||
[2]: https://git.mzhang.io/michael/logseq-calendar
|
||||
|
||||
> Side note: this isn't sponsored in any way. While this post makes me sound
|
||||
|
|
Loading…
Reference in a new issue