[HN Gopher] The Tools I Use to Write Books (2018)
___________________________________________________________________
The Tools I Use to Write Books (2018)
Author : benhoyt
Score : 66 points
Date : 2022-05-16 08:37 UTC (2 days ago)
(HTM) web link (thorstenball.com)
(TXT) w3m dump (thorstenball.com)
| akeck wrote:
| Note that it looks like Amazon pulled KindleGen off the web
| awhile back.
| Mizza wrote:
| I wrote a screenplay using a Markdown-based language called
| "Fountain" designed and implemented by the guy who wrote Tim
| Burton's screenplays, who I guess is apparently also a
| programmer. It's a great language and makes the barrier to
| getting started extremely low.
| chipotle_coyote wrote:
| Fountain is pretty cool.
|
| I used Highland, the writing app developed by the same fellow
| (John August), to work on a screenplay a couple years ago. It's
| good, but quirky, especially for non-screenplay applications.
| The advantage of Fountain, of course, is that it goes anywhere
| plain text does.
| yboris wrote:
| Maybe relevant to those interested: _The Snowflake Method_
|
| https://www.advancedfictionwriting.com/articles/snowflake-me...
|
| The gist (might work better for fiction, unsure): write a single
| sentence summary, then, three sentences to describe what major
| things happen, then fractal it out - keep expanding. This way,
| from the start, you have a cohesive story with a planned-out arc.
| john-tells-all wrote:
| I've used this identical technique to write hourlong talks --
| it works well!
|
| The first sentence is the _core_: you write and rewrite this a
| lot, because the entire talk builds up to it. Next three
| sentences are the major supporting ideas for your core. They
| also get rewritten a lot, because again they're really
| important, they flesh out your core idea. Then you write a lot
| of detail, one chunk per idea.
|
| I'm glad to know the name for this technique, it works really
| well!
| cobbaut wrote:
| The link in the article to the pp tool is no longer active. Find
| it here https://github.com/CDSoft/pp
| barnacled wrote:
| I am at the start of writing a book and had some major freeze at
| the start before, much like the author here, realised that all
| that matters is that I write the damn thing.
|
| I love how LaTeX lays things out, so I'm using LaTeX. I'd like to
| have a web version possibly but I can think about that later.
|
| And now, I better get back to it...
| WoodenChair wrote:
| I've written 4 technical books including the Classic Computer
| Science Problems Series (https://classicproblems.com). I agree
| with what Thorsten said at the end--none of this really matters--
| or it's marginal at most. Most people who say they want to write
| a book lack the motivation to do it. It's not the tools getting
| in the way.
|
| Apress used Word templates back in 2013 when I did my first book
| with them. Manning let you use asciidoc or Word templates when I
| worked with them. I wrote my first book with them in markdown and
| translated to asciidoc using pandoc. There were so many
| formatting issues and I found the tools for asciidoc so immature
| that I ultimately went to using their Word templates on my next
| two books with them despite preferring purely text formats.
|
| Now I'm working on my next book and I think I'm going to try self
| publishing. I'm liking leanpub's use of a markdown like format.
| But again none of this really matters. You can fix formatting
| later. You have to sit down and write!
|
| PS Thorsten's "Writing an Interpreter in Go" is great:
| https://amzn.to/3yLTJjE
| littleweep wrote:
| Curious, what are your habits for writing a book?
| srvmshr wrote:
| I just wanted to add that I really liked your 'Classic CS
| Problems in Python' book. I found it much better than following
| university course notes (e.g. CS 61 A/B etc).
| WoodenChair wrote:
| Thanks so much. Really appreciate it. Hearing anecdotes like
| that makes writing worthwhile.
| mdaniel wrote:
| the non-affiliate link: https://www.amazon.com/Writing-
| Interpreter-Go-Thorsten-Ball/...
| mprovost wrote:
| Totally agree about not obsessing over tools. That's an easy
| rabbit hole to go down and distract yourself from producing the
| actual content of the book. I deliberately chose to use Google
| Docs because the formatting options are so limited. But I also
| found it motivating to have a WYSIWYG interface so it felt like
| I was looking at something resembling the finished product.
|
| In the end gdocs turned out to be a great choice because it's
| so easy to collaborate. All of the articles talking about
| markdown seem to assume that you're the only person that's
| going to work on it, or that everyone else is going to figure
| out this diagram and your git workflow. It's so easy to email
| someone a link and let them comment on it, or suggest edits.
|
| For producing the final PDF I found a plugin that embeds the
| doc directly from Google into InDesign so I can typeset it into
| something that looks pretty great. Then I just upload the PDF
| to Leanpub.
|
| The tool that had the biggest impact though was Beeminder,
| which has a hook into Docs and measures your progress by
| counting the number of words in the book every day. If you
| don't make progress you have to pay! It's a great way to make
| yourself accountable. I kept a 100+ day streak for the final
| push.
| tunesmith wrote:
| As a counterpoint, I'd wanted to write a book for years, and
| felt overwhelmed by the production process. asciidoc, docbook,
| word, it's kind of overwhelming. After I finally put together a
| good markdown->pandoc->latex->KDP flow, it was a huge relief,
| and I've printed two books since then (one by me, one by me and
| some co-authors). It's super-fun to receive an author proof in
| the mail and it motivates me to write more.
| humps wrote:
| For my pixel art book with No Starch, they insisted on Word
| templates and it worked out well for a couple of reasons. The
| first being because their editing team was so used to using the
| template for feedback. It was easier for me to adapt to the
| publisher than the other way around, and the whole process was
| smoother and quicker.
|
| The second reason was to do with a change in format as the book
| was nearing completion. It's aimed at kids (8+) and adults, but
| we decided having an open and lay flat printed edition made the
| most sense because it makes following the tutorials easier.
| This resulted in the layout needing to be tweaked for a couple
| of hundred pages, which the publisher handled because we used
| their template system.
|
| So while it may be annoying for a writer to have to change
| their methods, it can save you a hell of a lot of work because
| things change unexpectedly (and in my case for the better).
| markwisde wrote:
| If it's interesting to someone I have a similar pipeline I used
| to write and deploy my book The Security Engineer Handbook [1].
|
| I basically wrote everything using markdown files, and a
| pdf/epub/mobi is automatically generated from the folder using a
| Github Action. The action will also modify the date of the last
| update on the webpage, which gets deployed via cloudflare pages
| (although github pages could have been used). On the other side
| Stripe handles the payments (No server side code for me) and
| zapier detects new customers and sends the artifacts by email.
|
| It's magical :) the next time I want to write a book I'll focus
| purely on the content and everything else will be taken care of
| automagically.
|
| [1]: https://securityhandbook.io/
| xnacly wrote:
| I find the flowchart visualizing the pipeline very intriguing,
| can someone link me a tool I can use to create similar charts?
|
| For reference:
| https://thorstenball.com/images/book_tool_pipeline.svg
| tekknolagi wrote:
| I think Thorsten uses Monodraw.
| drhayes9 wrote:
| I've used Mermaid for that before: https://mermaid-
| js.github.io/mermaid/#/
|
| Not sure what the author used.
| [deleted]
| [deleted]
___________________________________________________________________
(page generated 2022-05-18 23:00 UTC)