## Added old /journal entries to /log

This closes #66, get /journal entries into /log.

### Notes on ObservableHQ

I did it in ObservableHQ [here](https://beta.observablehq.com/@stevekrouse/parse-and-join-journal-to-commits), which was really fun and fustrating, both!

* It took me 5ish to do this task in JS in ObservableHQ, when it wouldn't have taken more than 1 hour to do by hand (as there were only 68 elements).
* I both hate and also love ImmutableJS. It provides an API like lodash which is great. It's annoying because the values don't [yet](https://talk.observablehq.com/t/custom-representation-for-object-in-the-output-cell/412/3) display well and I needed to add lots of printLine statements below my code `someImmutableValue.toJS()` just to see what was happening. Also I'd sometimes forget about it and use the old syntax and things would silently break: very fustrating! Also a bit annoying when you're doing `a.something(b)` and you want to switch the arguments - lots of typing! Probably lost an hour on ImmutableJS alone, but it was definitely worth it for the API, speed, and not having to worry about mutability ever.
* I found the way that code was hidden by default (unless you pinned it open) was counter to what I wanted most of the time. I think I'd probably prefer the reverse: to collapse code when I'm done with it.
* I lost another hour trying to use [simple-markdown](https://github.com/Khan/simple-markdown) which was waaaay more than I needed, given that all I needed was to split the string on a simple regex. Another hour or so gone there.
* Maybe a half an hour was lost screwing up with momentjs, which would fail silently on me. So annoying! Give me an error goddamn it!
* But the most fustrating loss of time came from writing functions: you can't see intermediate values and the debugging support is lack-luster. So the main benefits of a reactive tool is lost the second you want to abstract over a list! I was constantly creating a function and testing in on various elements, and then changing the index one at a time to see how it worked: `someFunction(someLIst.get(5))`. What's the point of putting my code in cells a whole function is just one cell?! You loose all the benefits of the cells and intermediate results because functions are just a textbox! Not entirely sure how I'd fix this but I have an intuition that it should be possible within this paradigm.
* I really wish I could've also hid the output of a computation, for example the text of the journal which was really long.
* You can't search through the code with ctl-f because it's mostly hidden.
* You can't see (without reading) which cells depend on which other ones.
* You can't drag cells into other orders.
* It's a bit annoying navigating object hierarcy trees - it'd be better if it defaulted to a table or something maybe.

It's interesting to note how few operations I used:

* A TON of `map`, `filter`, `some`, `max`, `find` and other Immutable list and map operators
* regex
* date parsing and diffing (momentjs)
* importing the file over HTTP
* downloading the result JSON as a file

For regex, I used [regexr.com](https://regexr.com) to live show me the output right on the data I was using. 

For date parsing and diffing, I was constantly screwing this up and had to instrument my own code by hand to figure out in which ways. It definitely feels like there should be a regexr-like environment for this too. 

Ditto for the list operations: no reason that any of these shouldn't show you the results in a more immediate way, and where you can see the intermediate values too of course. As said above, not 100% sure how to do this but I feel like it's not too tough.

As for importing and exporting data, not difficult once you find the example somewhere. I think those sorts of primitives should be easy at hand.

Speaking of easy at hand, I spend a TON of time switching tabs (ObservableHQ doesn't work great in half-screen) to look at the Immutable, Moment, simple-markdown, and various other documentations. It was annoying. They really need autocomplete on variable properties -- but also with documentation, preferably with examples!

And of course, I think everything would've been beeter with stronger types. I wasted so much time thinking that everything was OK when it wasn't and banging me head against the wall. I want to know when things fail!

And if you can do it with no syntax errors, that's pretty amazing too!

#### Project idea: functional, immutable, strongly-typed notebook?

This all makes me think that there's a neat prototype opportunity here. All my prior protyotype ideas in this space have been very visually-focused, almost like spreadsheets. Very much like Glen's [FlowSheets](https://tinyletter.com/Flowsheets/archive). But what if we don't need the interface to be a spreadsheet (because variables (as opposed to column and row reference) and nested data structres are nice), but just a vertical series of cells (and cells within cells within cells for nested levels of abstraction)? Syntax errors aren't so bad (considering I haven't yet met a projectional editor I prefer, maybe save Scratch), but let's definitely get some strong types, solid primitives (data structure, string, date, HTTP, importing), and inline documentation.

Author: Steve Krouse