• Org-Roam

    An Emacs library that recreates Roam (software that implements a Zettelkasten-like system) using org-mode.

    All notes are stored as individual files addressed by {timestamp}-{underscore_separated_title} and can be backlinked to create a graph of notes which can be generated using graphviz.

    Read the docs

    See also:

    NOTE: Many things have changed about org-roam in v2. Code snippets and issues are likely out of date.

    Problems with org-roam

    • Auto completion is finicky (case sensitive, not fuzzy matching)
    • Can’t search for content in the body of notes when adding backlinks
    • Synchronizing between mobile and desktop is difficult e.g. Beorg on iOS can’t support a template that doesn’t have a title (org-roam’s template just has a #+TITLE tag)
    • You can’t export to HTML in a built in way (looks like you need to use ox-hugo with a config header in each note which is ugly)
    • Buffers don’t wrap text by default
    • Distinguishes between backlinks and ‘cite backlinks’ which is confusing
    • Automatically changes the file name if you change the title (these should be decoupled if you plan to publish notes)

    org-roam v2

    V2 is less portable than v1 now that links use `org-id`.

    DONE Integrating org-roam [8/8]

    DONE Use helm-rg for fuzzy full text searching notes

    Add a keymap entry for it when in org-roam

    • Add an action to insert a file link to the highlighted result Use helm-add-action-to-source to add the action. See github.
    • Add link anchor words into it (maybe from title?)
    (use-package helm-rg
      :ensure t
      :config
      ;; Add actions for inserting org file link from selected match
      (defun insert-org-mode-link-from-helm-result (candidate)
        (interactive)
        (with-helm-current-buffer
          (insert (format "[[file:%s][%s]]"
                          (plist-get candidate :file)
                          ;; Extract the title from the file name
                          (subst-char-in-string
                           ?_ ?\s
                           (first
                            (split-string
                             (first
                              (last
                               (split-string (plist-get candidate :file) "\\-")))
                             "\\.")))))))
    
      (helm-add-action-to-source "Insert org-mode link"
                                 'insert-org-mode-link-from-helm-result
                                 helm-rg-process-source))
    

    DONE Toggle truncate lines in org-roam buffers

    Make org-mode always use wrapped lines (setq org-startup-truncated nil)

    DONE Set up exporting to html

    • Use ox-hugo to export to md and generate html using hugo Add #+HUGO_BASE_DIR: ~/Projects/zettel and #+HUGO_SECTION: ./ to the front matter of each note
    • Update the capture template to include hugo tags
    • Write a fn to batch export org files from a directory (since each note is it’s own file)

    https://github.com/alexkehayias/emacs.d/blob/master/init.el#L715

    DONE Cloud backup

    • iCloud is nice since all my devices could use it without any additional software, but you can’t symlink directories so an app can’t use the same data directory as another. This makes it difficult to use multiple apps as an input source to zettel notes.
    • Dropbox does sketchy things to desktops and used to cause random CPU spikes that would eat through laptop battery life. Not sure how much that’s changed.
    • Github might work, but once the number of files increases that might become unwieldy.
    • Decided to use icloud for now for syncing a file between Beorg to be processed into notes. On desktop, will use github to backup the exported notes until I can figure out something better for the underlying org mode files.

    DONE Ignore any notes from hugo export that are tagged as private

    https://github.com/alexkehayias/emacs.d/blob/master/init.el#L715

    https://github.com/alexkehayias/emacs.d/blob/master/init.el#L715

    DONE Update org-roam journal template to include private

    (setq org-roam-dailies-capture-templates
          (quote (("d" "Default" plain (function org-roam--capture-get-point)
                   "%?"
                   :file-name "%(format-time-string \"%Y-%m-%d--%H-%M-%SZ--journal\" (current-time) t)"
                   :head "#+HUGO_BASE_DIR: ~/Projects/zettel\n#+HUGO_SECTION: ./\n#+TITLE: %<%Y-%m-%d>\n#+ROAM_ALIAS:\n#+ROAM_TAGS: private\n"
                   :unnarrowed t))))
    

  • Richard Hamming

    Mathematician and computer scientist.

    Important ideas:

    • What matters is working on important problems or work on things that could lead to something important. Otherwise, why bother? He emphasized the need to work on the most important problems in your respective field–both knowing the problems and dropping everything to work on it when an approach to solving it emerges.
    • You don’t need to be a genius or the best–but you do need to work hard and learn what works so you can seize the opportunity when it arises.
    • To make important contributions you need to work on the right problem, at the right time, in the right way.

    See also:


  • Planning AI

    A sub field of artificial intelligence (AI) concerned with helping agents generate valid and coherent plans of actions to reach a goal.

    Approaches were divided into state space planners and planning space planners. State space would be something like ‘the door is open’ where plan space would be ‘open the door’. Generally plan space planners are faster (there tends to be fewer actions than states) to search when looking for a solution.

    One limitation is that problem domains for use with planning algorithms must be known in advance. This limits the applications to domains you can fully specify and isn’t resilient to change (e.g. the actions or effects change dynamically).

    Another limitation is searching for an answer tended to be slow. For example, in the least efficient case a search for a plan devolves to an exhaustive, brute force search. GraphPlan is a much faster approach that generates graph data structure that trims the search space.


  • My Morning Practice

    These days I wake up very early for the puppy ~5:45 AM so between getting the dogs ready and starting work I have about three hours.

    I begin with a new journal entry recorded which captures recent articles I’ve read, things on my mind, and anything else (it’s not very structured). I review my short term notes and cut new notes for anything I’m interested in recalling in the future. As I write the new note I flesh out the idea some more, often going back to the source material to make sure I really understand it. This is also when I add links to existing notes. I publish the notes to this site, it’s a great feeling to publish just a little bit every day.

    I do ~20 minutes of exercise, usually cardio (running or indoor biking) interspersed with low-impact yoga every two days or so. I need to do this every day to maintain my mental health and I have not missed a day in 6 months. Cardio clears my head and leaves me feeling like I did something good for myselfβ€”it’s a successful day even before I’ve done anything else.


  • Measuring UX

    User experience is subjective which makes improvements in UX difficult to calibrate since we need to rely more our collective taste and/or talking to users.

    Are there more empirical measures of UX?

    What are the nearest approximations that provide directional guidance in how to improve the experience? For example, if you lowered UX entropy would that reliably correlate with a better subjective user experience?


  • Improving the 'Hand Feel' of Software Engineering

    Similar to Neil Gaiman’s remarks about a fountain pen and writing there are ways that enhance the feeling of a craft.

    Examples:

    • A mechanical keyboard improves the typing experience with satisfying tactile feedback
    • Fast feedback loop of making a code change and observing the result
    • Tools for refactoring
    • A REPL that let’s you grow your program
    • Debug tools that let you better understand what’s going on

    The sum of the tools (hardware and software) used while writing code is the hand feel. We don’t spend enough time thinking about the hand feel and often view it through the utilitarian lens.

    What’s the fountain pen for enterprise software? Green field projects?

    See also:


  • Humans Are the Great Interop Layer

    So much of technology is solving the problem of inter-operating between disparate systems e.g. cpu architectures, operating systems, language runtimes.

    Humans provide the greatest interop layer unknowingly. We seamlessly work between different technologies without missing a beat. We interoperate between our desktops and mobile devices, weaving together broken legacy systems at work to operationalize a task, and speak different languages (and computer languages). We manage an enormous amount of complexity without thinking about it.


  • Fuzzing

    The process of generating a range input values based on some constraints to fully explore a programs handling. For example, fuzzing a function that takes a numerical value might reveal it does not properly handle negative numbers even though it’s an allowed value.

    Usage examples:

    • Detecting security vulnerabilities e.g. memory bugs

  • Entropy

    Disorder in a system that tends to increase over time until reaching an equilibrium. Factors of entropy include heat, time, and the number of things in the system.

    Entropy is measured by the number of macro states (e.g. arrangement of molecules) the system can be in where a value of 1 would be a single state (i.e. crystal structure).


  • Difficulty Discussing Social Issues

    The reason discussions of social problems and correctness are difficult is because there is no safe way to fail and learn from feedback about a point of view. When someone is called out, they tend to not engage in social issues for fear of backlash or become defensive and angry, strengthening their belief.


  • Deriving User Flows and Optimal Path to Goals From Events

    By analyzing frontend analytics events we can derive the ‘hot paths’–sequences of actions users often take. If we also know the user’s goals we can then calculate the state space and optimal path (e.g. A* pathfinding). With that we can calculate the frequency in which users choose an optimal path.

    What might the results of this kind of analysis mean for the user experience?

    • A high cardinality of unique paths to a goal might reveal there are too many ways to do the same thing
    • A large percentage of users on an suboptimal path could indicate an opportunity to help users perform an action faster

    See also: