Brandon Rhodes is a Python developer and speaker who writes about code structure and astronomy, and created the PyEphem and Skyfield libraries.
HN commenters praise the Skyfield library for its pleasant API and recommend him as an excellent speaker on structuring Python code.
I was going to write that I don't have a good pointer, but actually I think the idea is basically the "onion architecture" or "clean architecture". I don't recall if I watched all of this talk, but in general I like Brandon Rhodes' PyCon talks :
https://www.youtube.com/watch?v=DJtef410XaM
http://rhodesmill.org/brandon/slides/2014-07-pyohio/clean-architecture/
I don't come from a Java background, but I think that many of these ideas originated in the Java community. They came to Python later (if at all), and it's a little funny to see Go struggling with the same thing.
I think I came at it from more of a functional programming perspective, and the style gradually converged with what people were thinking about OOP. I'm not actually of all the details about "clean architecture" and "onion architecture", but they are definitely related to dependency injection.
Basically all your effects and state can be instantiated on the "outside" in main() and passed INWARD. But I don't believe it necessarily has to be pure. I encapsulate all my state, but I don't encapsulate all my side effects, like printing to the screen.
Some people appeared to like this comment, which is somewhat related:
https://news.ycombinator.com/item?id=11841893
I'm not sure how much this will help, but here is 12K+ lines of code I wrote with zero globals:
https://github.com/oilshell/oil
The main directories to look at are core/ and osh/. The main program imports a lot of stuff and wires it…
Regarding writing "one-sentence-per-line", I've noticed that style before in LaTeX. While I don't use that style, one advantage that I like is the ability to include comments on the sentence level in LaTeX.
So instead of this:
First sentence. Second sentence. % Comment on first sentence.
I can write:
First sentence. % Comment on first sentence.
Second sentence.
(Of course, one could define a new TeX macro that doesn't display anything to add comments anywhere in-line. That's not as readable, though.)
I've also read that one-sentence-per-line works better with diff programs, but I haven't had any problems with the program meld, so this isn't convincing to me. The advantage the linked article mentions in terms of rearranging sentences also is worth considering, though I haven't found the normal way to be that bad so I'm not convinced by that either.
Some other links on this coding/writing style:
https://rhodesmill.org/brandon/2012/one-sentence-per-line/
https://news.ycombinator.com/item?id=4642395
http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-editing-thinking-with-line-breaks/
Oh wow! I've worked on turning PAIP (Paradigms of Artificial Intelligence Programming) from a book into a bunch of Markdown files, but that's "only" about a thousand pages long, compared to the roughly 27000 pages long of all those volumes. I have advice, possibly helpful, possibly not.
Getting higher quality scans could save you some headaches. Check the Internet Archive. Or, get library copies, and the right camera setup.
Scantailor might help; it lets you semi-automate a chunk of things, with interactive adjustments. I don't know how its deskewing would compare to ImageMagick. The signature marks might be filtered out here.
I wrote out some of my process for handling scans here - https://github.com/norvig/paip-lisp/releases/tag/v1.2 . I maybe should blog about it.
If you get to the point of collaborative proofreading, I highly recommend Semantic Linefeeds - each sentence gets its own line. https://rhodesmill.org/brandon/2012/one-sentence-per-line/ I got there by:
* giving each paragraph its own line
* then, linefeed at punctuation, maybe with quotation marks and parentheses? It's been a while
It turns out that there is a lot of discourse out there about "semantic newlines", under a few different names. So far the names I've seen are:
- One Sentence Per Line (OSPL) - Semantic Line Breaks (SemBr) - Semantic Linefeeds - Ventilated Prose - Semantic newlines
Reading through the pages below was helpful in getting a better idea of what language people use to discuss this. They're mostly historical retrospectives or arguments for the merit of semantic newlines.
https://rhodesmill.org/brandon/2012/one-sentence-per-line https://ramshankar.org/blog/posts/2019/semantic-line-breaks https://vanemden.wordpress.com/2009/01/01/ventilated-prose https://discuss.python.org/t/semantic-line-breaks/13874 https://discuss.python.org/t/one-sentence-per-line-for-peps-and-more/13920 https://sembr.org https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line
(Actually I think one-sentence-per-line denotes something slightly different from semantic-line-breaks, not that I know what that difference is).
Probably, the issue is that there's reflection of the double_ish_but_not_really_this_is_new_zealand glazed glass. Also, I take a ruthless approach to "fun" on small side projects and rather it works than is perfect. I did try putting a box around it but it wasn't really that workable as it sits in the corner of the lounge and I don't want it to be too bulky.
What sort of colour settings would you tweak?
p.s. if any other pi-timelapse people are out there, I would be quite keen at some point to open up the API so that you can post links to your videos too.. then we can have a google map to all the timelapses and it'd be just great! :D
p.p.s. did have fun using the python http://rhodesmill.org/pyephem/ to calculate the "Nautical Sunset - who knew?" so that it will properly adjust rather than the crude approach of a cron-job with a large enough bracket!
Love side projects :)
The part of about line-based diff tools caught my attention at first, too.
In the section "Hints for Preparing Documents" in Unix for Beginners[1], Brian W. Kernighan writes, "Make lines short,
and break lines at natural places, such as after commas
and semicolons, rather than randomly." At the time he was writing that, around 1978, the unix editor was ed, a line-based editor.
As Derek Sivers notes in his post,
there are many other reasons for semantic linefeeds[2],
and over time I've found those reasons more important.
1 https://web.archive.org/web/20130108163017if_/http://miffy.tom-yam.or.jp:80/2238/ref/beg.pdf
2 https://rhodesmill.org/brandon/2012/one-sentence-per-line/