![\"Creative](\"https://i.creativecommons.org/l/by-nc-nd/3.0/88x31.png\")
\n\t\t\t\t\t{{ post.summary }}\n\t\t\t\t
\n\t\t\t{% endif %}\n\t\t\t\n\t\t\t\t\n\t\t\t
\n\t\t\t{% if post.tags %}\n\t\t\t\t\n\t\t\t\t\t{% for tag in post.tags %}\n\t\t \t\t\t{%- if tag != \"post\" -%}\n\t\t \t\t\t\t{% set tagUrl %}/tags/{{ tag }}/{% endset %}\n\t\t \t\t\t{{ tag }}\n\t\t \t\t\t{%- endif -%}\n\t\t\t\t\t{% endfor %}\n\t\t\t\t
\n\t\t\t{% endif %}\n\t\t\n\t{% endfor %}\n \n\n\t\t\t\t\t{{ page.data.summary }}\n\t\t\t\t
\n\t\t\t{% endif %}\n\t\t\t\n\t\t\t\t\n\t\t\t
\n\t\t\t{% if page.data.tags %}\n\t\t\t\t\n\t\t\t\t\t{% for tag in page.data.tags %}\n\t\t \t\t\t{%- if tag != \"post\" -%}\n\t\t \t\t\t\t{% set tagUrl %}/tags/{{ tag }}/{% endset %}\n\t\t \t\t\t{{ tag }}\n\t\t \t\t\t{%- endif -%}\n\t\t\t\t\t{% endfor %}\n\t\t\t\t
\n\t\t\t{% endif %}\n\t\t\n\t{% endfor %}\n\n\t\t\t\t\t{% for tag in post.data.tags %}\n\t\t \t\t\t{%- if tag != \"post\" -%}\n\t\t \t\t\t\t{% set tagUrl %}/tags/{{ tag }}/{% endset %}\n\t\t \t\t\t{{ tag }}\n\t\t \t\t\t{%- endif -%}\n\t\t\t\t\t{% endfor %}\n\t\t\t\t
\n\t\t\t{% endif %}\n\t\t\n\n {% for tag in tags %}\n {%- if tag != \"post\" -%}\n {% set tagUrl %}/tags/{{ tag }}/{% endset %}\n {{ tag }}\n {%- endif -%}\n {% endfor %}\n
\n {% endif %}\n\n\n Next: \n {{ nextPost.data.title }}\n
\n {% endif %}\n {% if prevPost.url %}\n\n Previous: \n {{ prevPost.data.title }}\n
\n {% endif %}\n\n\n${entry.getIn([\"data\", \"summary\"], \"\")}
\n\n ${\n entry.getIn([\"data\", \"tags\"], []).map(\n tag =>\n html`\n ${tag}\n `\n )\n }\n
\n|-|—|\\n/g, '');\n //remove repeated spaces\n result = result.replace(/[ ]{2,}/g, ' ');\n // remove most emoji\n result = result.replace(/([#0-9]\\u20E3)|[\\xA9\\xAE\\u203C\\u2047-\\u2049\\u2122\\u2139\\u3030\\u303D\\u3297\\u3299][\\uFE00-\\uFEFF]?|[\\u2190-\\u21FF][\\uFE00-\\uFEFF]?|[\\u2300-\\u23FF][\\uFE00-\\uFEFF]?|[\\u2460-\\u24FF][\\uFE00-\\uFEFF]?|[\\u25A0-\\u25FF][\\uFE00-\\uFEFF]?|[\\u2600-\\u27BF][\\uFE00-\\uFEFF]?|[\\u2900-\\u297F][\\uFE00-\\uFEFF]?|[\\u2B00-\\u2BF0][\\uFE00-\\uFEFF]?|(?:\\uD83C[\\uDC00-\\uDFFF]|\\uD83D[\\uDC00-\\uDEFF])[\\uFE00-\\uFEFF]?/g, '');\n \n let match;\n while (match = regex.exec(result)) {\n const emoji = match[0];\n result = result.replace(emoji,' ')\n }\n \n return result;\n }\n\n return index.toJSON();\n};"
},
{
"path": "loader.js",
"content": "if (localStorage.getItem('password')) {\n insertPlainHTML(atob(localStorage.getItem('password')))\n} else {\n document.getElementById('staticrypt-form').addEventListener('submit', function(e) {\n e.preventDefault();\n insertPlainHTML(document.getElementById('staticrypt-password').value);\n });\n}"
},
{
"path": "manuscript/Book.txt",
"content": "why.md\nrules.md\nprocess.md"
},
{
"path": "manuscript/manuscript.json",
"content": "{\n \"layout\": \"layouts/page.njk\"\n}\n"
},
{
"path": "manuscript/process.json",
"content": "{\n \"title\": \"The Writing Process\",\n \"eleventyNavigation\": {\n \"key\": \"The Writing Process\",\n \"order\": 3\n }\n}"
},
{
"path": "manuscript/process.md",
"content": "# The Writing Process\n\nMany people are under the impression that writing is a mystical\n-- or at least mysterious --\nactivity, governed entirely by inspiration.\nWhile it is true that some authors work this way,\nwaiting for inspiration to strike isn't a common strategy among professional writers,\neven novelists.\n\nFor programmers and others writing non-fiction in a business context,\nthere is a simple process that yields quality results.\n\n1. Determine the goal\n2. Determine the audience\n3. Choose a suitable structure\n4. Build an outline\n5. Turn the outline into prose\n6. Revise obvious weaknesses\n7. Obtain feedback\n8. Revise based on feedback\n9. Publish\n\nIn this chapter, we will walk through what each of these steps entail.\n\n## 1. Determine the Goal\n\n### Why am I writing this, anyway?\n\nEvery time you start writing something,\nask yourself, \"Why?\"\nSometimes the answer is obvious,\nbut often it's not.\nAnd even on those occasions when it is obvious,\nasking the question helps keep you focused on the goal.\n\nIt's important to remember that we're trying to find the purpose of the document,\nnot your personal motivation for writing it.\nIf your answer to \"Why am I writing this?\" includes the words \"I\" or \"me,\"\nit is worth evaluating whether you're really thinking of the document's goal.\n\nFor instance, if the answer to why you are writing a tutorial is,\n\"So that I can get a raise,\"\nyou're thinking of the wrong thing.\nIt's not that the motivation is _wrong_.\nIt's just _irrelevant_ to producing a good tutorial.\nA better answer is,\n\"To help others improve their game's performance.\"\n\nBecause this answer is focused on what the audience receives,\nit is actually useful for guiding your writing efforts.\n\n### Keep asking why.\n\nOften, the first goal we come up with will be superficial.\n\"Teaching others how to use object pools,\"\nmay be accurate,\nand even somewhat useful,\nbut a bit more context can be even more useful.\n\nThere is a technique for root cause analysis called [5 Whys][],\nthe premise of which is that you need to ask \"Why?\" multiple times to find the root cause of a problem.\nThis technique also works well for determining a useful goal for writing.\n\nSuppose the first goal that occurs to you is\n\"Teach developers how to use object pools.\"\nThat is a perfectly clear and useful goal.\nBut if you write only to that narrow goal,\nyour readers won't know why the technique is useful.\nSo ask yourself, \"Why object pools?\"\n\nPerhaps the answer is \"To improve performance.\"\nBut again we can ask \"Why?\"\nAnd our answer is something like, \"To keep gameplay smooth.\"\n\nAt this point we can state the goal as:\n\"Teach game developers how to keep their games running smoothly by using object pools.\"\n\nWith this more robust goal in mind we're more likely to communicate,\nnot just the technique,\nbut also its importance and trade-offs.\n\n## 2. Determine the Audience\n\nOnce we understand the goal of the document,\nwe have enough information to start considering our audience.\nOur first question, though, takes a step back from the goal.\n\n### Who will be reading this?\n\nOften the readership of documents is wider than we would initially expect.\nA framework's website will be read by developers, of course,\nbut perhaps also:\n\n* Architects evaluating technology choices\n* Managers trying to keep abreast of what their team is using\n* Technical recruiters trying to understand the skillset they are hiring for\n* Designers trying to understand technical constraints on their designs\n* Sysadmins figuring out the framework's deployment features\n\nTake time to list the different types of potential readers.\nDoing so will help draw out whether additional supporting material is needed.\n\n### Which readers are primary?\n\nOnce you have the list of potential readers,\nrefer back to the goal to decide which readers are most important.\nIn most cases there will be a single group of readers who constitute your primary audience.\n\nContinuing the previous example:\nthe primary audience of a framework website is developers.\nOthers are important, but secondary to that audience.\n\n### What is their relation to the subject?\n\nAt this point we have our primary audience,\nbut haven't given much detail about them.\nSo it's time to consider their relation to the subject.\n\nOne important axis to consider is their current level of expertise.\nAre they absolute beginners,\nworld class experts,\nor somewhere in between?\nThe answer to this question drives\nwhich sorts of things can be assumed\nand which need to be explained in great detail.\n\nAnother axis is the readers emotional relationship with the subject.\nAre they intimidated, enthusiastic, or something else?\nA developer who fled Java for Ruby will have a very different attitude toward Haskell than a brand new developer.\nThey may both be fearful,\nbut about different things.\nThose emotional concerns also need to be addressed.\n\n### What is their relation to you?\n\nIn addition to the subject,\nwe must also consider how the audience is related to you,\nthe author.\nAre they coworkers?\nThen you can make certain assumptions about their familiarity with the business.\n\nAre you on friendly terms or is some of the audience hostile?\nYou may need to focus more on your logical case for the latter.\n\nAre you part of the same culture/subculture?\n\"Corporate suits\" probably won't find image macros as amusing as your 22-year-old developer buddy.\n\n[5 Whys]: http://en.wikipedia.org/wiki/5_Whys\n\n## 3. Choose a Suitable Structure\n\nNow that we know the goal and the audience\nwe can consider how to structure the document to serve them.\n\n### Choosing a structure based on the goal\n\nGoals can generally be placed on a spectrum between purely informational and purely persuasive.\nOn one end of the spectrum,\ntopical hierarchies are great at communicating lots of information efficiently.\nThe hierarchy conveys the big picture while also supporting scanning through subtopics.\n\nAt the other end of the spectrum,\nnarrative is particularly effective at persuading people by engaging our natural sense of empathy.\nTelling a child that \"Lying is a bad idea,\" is less likely to change their behavior than hearing _The Boy Who Cried Wolf_.\nFor an example closer to our industry, consider _The Phoenix Project_:\nit vividly illustrates the problems of bureacratic IT departments\nas well as the benefits of embracing the DevOps movement.\n\n### Choosing a structure based on the audience\n\nYour structure also needs to be suited to your audience.\n\nIf your primary audience is developers with deep experience in your topic,\nthen you may want to address them with an equally deep and detailed hierarchy of topics.\nA beginner, however, would likely benefit from a shallower step by step \"recipe\" guide.\n\nThe reader's level of interest factors into which structure is best suited.\nA highly motivated reader may want to get right to the heart of the matter.\nBut a distinterested reader\n--who is only looking at your document because his boss made him--\nmay need to be enticed with a joke or anecdote explaining what is in it for him.\nThat sort of reader will probably also need frequent positive reinforcement.\n\nThe audience's relationship with you also makes a difference.\nIf they are familiar with you and trust your judgment,\nthey are more likely to be patient waiting for a payoff.\nBut if they don't know anything about you,\nthe internet is only a click away.\n\n### Mixing and matching\n\nMost writing structures are relatively flexible\nand can be combined with other structures as warranted by the goal and the audience.\n**Don't be afraid to mix and match them.**\n\nFor example, suppose that you need to convince business leaders that\nit is worthwhile to break your large monolithic application into several separate services.\nYou'd probably start with a Problem-Solution structure like this:\n\n* Problems with the current architecture\n* Proposed solution\n\nIn order to help the businesspeople make a decision, you'd probably extend it with a Pro-Con analysis as well.\n\n* Problems with the current architecture\n* Proposed solution\n* Costs and risks of change\n* Costs and risks of not changing\n\nA simple factual elaboration on that outline may win intellectual assent,\nbut is unlikely to elicit wholehearted support from non-technical leaders.\nWhy?\nBecause they lack experiential knowledge of the problems, solutions, and risks.\n\nBut parables and other metaphorical narratives can impart a degree of experiential knowledge without requiring actual experience.\nWhat sort of narrative would work in this case?\n\nPerhaps a story of a military building a single gigantic ship.\nIt is powerful,\nbut difficult to maneuver,\nand if it somehow fails then its entire arsenal is useless.\n(Business books are fond of military metaphors for some reason.)\nThen contrast this with building a fleet of small independently maneuverable ships.\n\nRevising the outline to incorporate this narrative gives us:\n\n* Problems with the current architecture\n * Parable of the dreadnought\n * Supporting factual details\n* Proposed solution\n * Parable of the fleet\n * Supporting factual details\n* Costs and risks of change\n * Refer to parable\n * Supporting factual details\n* Costs and risks of not changing\n * Refer to parable\n * Supporting factual details\n\nCombining these three structures creates a much more powerful and persuasive account than any of them alone.\n\n## 4. Build an Outline\n\nWith a structure\n(or set of structures)\nchosen for your project,\nit is time to build an outline.\nSome structures,\nlike API documentation,\nmay come with an outline template to follow.\nBut many others,\nlike the inverted pyramid,\ndo not.\n\nThis phase is all about taking your chosen structures\nand combining them with the details of your subject\nto produce the skeleton of your document.\n\nThe outline itself is a simple hierarchical list of\nthe things you want to communicate\nand the approach you want to take at each step.\nParticularly for smaller projects,\nthe line between choosing a structure and outlining can be rather blurry.\n(Evidenced by the the section on choosing structures ending with an outline!)\nBut an outline should show in detail **how** you intend to implement your chosen structure.\n\n### How detailed should an outline be?\n\nThis will likely vary from person to person,\nbut I prefer to outline in enough detail that\neach low level bullet point corresponds to one or two paragraphs in the final text.\nThis gives me sufficient guidance that I don't get lost,\nbut also gives me enough flexibility to expand on some points without deviating from the outline.\n\n### How do you actually create the outline?\n\nThere are two basic approaches:\ndepth-first\nand breadth-first.\nA depth-first approach starts at the top\nand explores all the way down to the details one point at a time.\nA breadth-first approach starts at the highest level\nand only becomes more detailed after all the higher level points have been filled in.\n\n**Partially completed depth-first outline**\n\n* Point 1\n * Point 1.1\n * Point 1.1.1\n * Point 1.1.2\n * Point 1.1.3\n\n**Partially completed breadth-first outline**\n\n* Point 1\n* Point 2\n* Point 3\n* Point 4\n* Point 5\n\nBreadth-first generally produces better results,\nbecause it provides more overall context each time we step down a level of detail.\nThat extra context makes it much less likely that we will get stuck on trivia.\n\n### Evaluate and revise\n\nOnce you've drafted your outline,\nbe sure to evaluate it with your goals and audience in mind.\nIt is much easier to move or edit a few bullet points\nthan to revise entire sections of your document.\n\n## 5. Turn the outline into prose\n\nEverything we've talked about so far has been aimed at preparing you for this part of the process.\nYou should know your goal, audience and structure.\nAnd your outline gives you a game plan.\nNow it's time to turn all that into something for others to read.\n\n### Putting flesh on the bones\n\nRight now what you've got is a skeleton.\nIt's vaguely in the shape you want,\nbut if it tried to walk around it would quickly fall apart.\nThere are two principle things that it is lacking:\nmuscle to give it strength,\nand ligaments to hold things together.\nLet's start with the muscle.\n\nBare statements of fact rarely carry much weight with readers,\nregardless of how important those facts might be.\nThey have to be elaborated on\nand placed into their proper context.\nAnd usually the most important context for a reader is the answer to \n\"Why do I care about this?\"\nA reason to care gives your prose strength.\n\nConsider this example:\n\n> Continuous integration improves the development process.\n\n> Continuous integration improves the development process by helping us detect defects sooner.\n> That means fewer late night calls to debug production.\n\nThe latter includes more supporting detail about _how_ it helps,\nas well as a reason for developers to care about it.\n\nIn addition to muscle we need ligaments.\nThe ligaments are what actually connects one bone to another.\nThe prose equivalent is a transition.\n\nSudden jumps from one topic to another\n(even closely related)\nare jarring.\nTransitions serve to smooth that over by\nclearly signaling the close of one topic,\nthe introduction of the next,\nand possibly how they are related.\n\nA transition can be a simple phrase.\nIt can be an entire sentence.\nIt can be a paragraph.\nOr multiple paragraphs.\nIt all depends on the size of the pieces you're transitioning between.\n\nFor an example, take a look at the paragraph that started this section (#5) above.\n\n### It's not necessarily exposition\n\nWhen working from your outline,\nbeware of always choosing the most direct expansion of your points.\nSimple exposition is the most common way of describing things,\nbut it isn't always the best.\nUsing other forms of expansion will give your prose variety and help maintain reader interest.\n\nEspecially in a longer text,\nincluding the occasional story, joke, or anecdote\ncan make the difference between a pleasant read or an unbearably boring one.\n\nWhatever you choose to use,\nit should be integrally related to the points you're trying to make.\n\nThere is a story about a high school student who had to give a book report.\nWhen he stood up in front of the class he yelled,\n\"Sex! Sex! Sex!\"\nthen continued,\n\"Now that I have your attention,\nI'd like to talk to you about The Complete History of World War II.\"\n\nDon't be like the high school student.\n\n## 6. Revise\n\nAt this point you have a fleshed out draft,\nso now it is time to fix the gaps and rough edges.\n\n### Evaluate\n\nStarting at the beginnning, read each unit of your work.\nDepending on the length of your document, that unit might be a paragraph, section, or chapter.\nAs you read, ask yourself the following questions:\n\n* Does this advance the goal?\n* Is it clear?\n* Is it concise?\n* Is it well organized?\n* Is it scannable?\n\nYou'll likely want to read the unit multiple times to answer these questions.\nFor a longer unit, one read per question -- or even more -- may be appropriate.\n\n> #### Tip: Try different contexts\n>\n> Reading in a different context than you usually write in can help you to see things differently and spot problems more easily.\n> For example, if you usually write at a computer,\n> try printing your document out on paper,\n> or even reading it out loud.\n\n### Plan your corrections\n\nTake notes on each thing that needs to be improved,\nbut don't make corrections right away.\nIntroducing a slight delay between identifying the problem and attempting to fix it\nwill give your mind a chance to work on the problem,\nand often arrive at a better solution than the first one you thought of.\n\nYour notes can take many forms:\na separate text file,\nusing Track Changes in Microsoft Word,\nand so on.\nI tend to prefer annnotating a physical paper with pen or pencil,\nbut you should experiement and find what works best for you.\n\nAfter you have a list of all the corrections you plan to make,\nyou may be able to spot common patterns for future improvement.\nBut the immediate task is to begin making corrections.\n\n### Make your corrections\n\nProceed through your notes from beginning to end,\ncorrecting each problem.\nIf you get stuck on something,\nleave it to the side for now.\nYou'll come back to it later.\n\nOnce you've completed all the corrections you were able to make,\ntake another look at any you left behind.\nYou may know how to fix them now.\nIf so, go ahead.\nIf not, we'll leave them for the next stage of the writing process: feedback.\n\n## 7. Get feedback\n\nUp to this point everything has come from you,\neven thinking about the audience.\nBut this is where you actually engage with other people for the first time.\nBrace yourself,\nbecause feedback from real people is almost certain to suprise you,\nregardless of whether it's positive or negative.\n\n### Sources of feedback\n\nGenerally you will be getting feedback from one of three types of readers:\nmembers of the target aurdience,\nexperts on the subject,\nand friends/coworkers.\nEach of these groups has strengths and weaknesses.\nGetting feedback from all three is ideal,\nand occasionally the groups overlap,\nbut feedback from any of them is useful for checking your assumptions.\n\n#### Target audience\n\nMembers of the target audience are extremely valuable\nbecause they can tell you whether your writing is achieving the intended goal.\nUnfortunately, they often can't tell you why.\nAnd even if they do offer a reason,\nit shouldn't always be taken at face value.\n\nTo help overcome this issue,\nit can help to supply a list of specific questions for them to answer.\nFor example:\n\n* By the end did you think that it is worth investigating the new technology I described?\n* If not, was there a specific point where I lost you?\n* Did any of my supporting evidence seem questionable?\n\nUnfortunately, it can be difficult or impossible to get feedback from the audience.\nAfter all, when drafting an email to your boss's boss,\nyou can't very well ask them to proofread it.\n\n#### Experts\n\nExpert feedback can also be very useful,\nparticularly for identifying inaccuracies and mistakes.\nOne issue to watch out for, though,\nis that experts may not remember what it was like to be a beginner.\nSo if beginners and non-experts are in your target audience,\nbe careful of suggestions to includes lots of additional details which they won't have the context to understand.\n\n#### Friends and coworkers\n\nFriends and coworkers are often the easiest reviewers to obtain.\nUnfortunately, they are often the least reliable in providing needed correction.\nNo one wants to hurt the feelings of someone they like.\nBut they are often excellent at providing encouragement,\nand when working on a large writing project,\nthat can be invaluable.\n\n### Evaluating feedback\n\nWhen evaluating the feedback there are a few principles to keep in mind.\n\nFirst, _readers are always right about their reactions_.\nIf a reader says that they were confused by a certain point,\nthen they were,\nno matter how clear it may appear to you.\n\nSecond, _a reader's negative reaction does not automatically lead to revision_.\nIt is your responsibility to evaluate\nwhether issues raised are actually problems for your target audience\nand serious enough to require addressing.\n\nThird, _a reader's proposed solution may not be correct_.\nSometimes readers will suggest solutions without explaining the problem they identified.\nFor example, \"I think you need a fancy graphic right here.\"\nThis suggestion might be a good one,\nbut you should work to understand the underlying problem.\nPerhaps the text became boring,\nor perhaps a diagram would help with clarity.\nWhatever the case may be,\ndon't just take the suggestion at face value.\n\nFinally, _a reader's feedback should be weighted differently based on who they are and what area their feedback is in._\nAn expert's feedback regarding correctness should be prioritized over a beginner's,\nand an audience member's feedback regarding readability should be prioritized over the expert's.\n\n### Compile the feedback into revision notes\n\nAfter taking all of this in,\nyou should have a list of changes to make.\nAnd you may also have a list of positive points which you should try to retain.\nDespite the focus on improving problems,\nyou also don't want to edit away something that is working.\n\n## 8. Revise based on feedback\n\nJust like with your first revision notes,\nyou will go back through and make your changes one at a time,\nevaluating the criteria of clarity, concision, organization, scannability and goal focus.\nBy the time you are done,\nyou should have a pretty solid draft.\n\nAs you revise, make changes one at a time,\nassessing clarity, concision, organization, scannability, and goal focus.\nPay attention to common themes in the feedback you receive.\nThose are the ones most likely to require revision.\n\nRemember to prioritize the most significant changes first.\nTackle issues like organization or persuasiveness before minor details like grammar.\nGetting something grammatically correct is a waste of time\nif that entire section will be reworked or removed.\nThroughout revision, continuously review your goals and audience,\nand be prepared for multiple rounds of changes.\n\nAfter you've revised, seek additional feedback,\nboth to verify initial concerns are addressed\nand to ensure no new problems have been introduced.\nConsult with both original and new readers to get different perspectives.\nRemember, continuous revision is crucial for producing a polished and effective piece of writing.\n\n## 9. Publish\n\nPublishing your work is usually the most critical part of the writing process,\nbut remember, it can happen at any point, depending on the project.\nIn some cases, publishing might be part of an ongoing process,\nwith updates and revisions made after the first release.\nThis is especially true for things like wiki-based technical documentation\nor presentations that are given multiple times and need tweaks based on audience feedback.\n\nBefore you publish, think about the context and the level of polish your writing needs.\nNot every situation calls for super polished writing.\nA quick email to a coworker won't need the same level of refinement as a formal report for the big boss.\nAdapt the level of polish to the context so you strike the right balance between quality and getting things done.\n\nBefore hitting that publish button,\ngive your work a once-over for any errors or inconsistencies,\nand make sure your formatting looks good,\nbased on what's required in your situation.\nThis final check is crucial for presenting your writing in the best light.\n\nAfter publishing, don't forget to spread the word.\nShare your work with the people who need to see it,\nwhether that's passing a report to colleagues,\nposting a blog on social media,\nor presenting your findings at a conference.\nKeep in mind that publishing doesn't mean you're done with revisions.\nBe open to feedback even after your work is out there,\nand be ready to make updates or corrections as needed.\nEmbracing this back-and-forth will help you keep improving your writing skills\nand adapt to the needs of your audience in all kinds of situations.\n\n## Summing it up\n\nThe writing process is all about striking the right balance between the formal process and the needs of the situation.\n\nFrom setting goals and figuring out who you're writing for,\nto making an outline,\nrevising,\nand hitting that publish button,\neach step is important.\nBut not equally important.\n\nKeep an eye on your context and switch things up as needed,\nwhether it's the level of polish or the amount of feedback and revision you're going for.\nDon't forget, the process can and should be trimmed down when it makes sense for the situation,\nhelping you focus on what's most important in each specific context.\nThe more you work at it, the better you'll get at writing and connecting with your audience.\n\nWriting takes time, practice, and being open to learning from both the things you nail and the things you, well, don't.\nAs you gain experience as a writer,\nyou'll find that this whole process starts to feel more natural,\nand your ability to get your point across will only get better.\nJust keep writing, learning, and tweaking your process to fit each unique writing situation you find yourself in."
},
{
"path": "manuscript/rules.json",
"content": "{\n \"title\": \"General Rules\",\n \"eleventyNavigation\": {\n \"key\": \"General Rules\",\n \"order\": 2\n }\n}"
},
{
"path": "manuscript/rules.md",
"content": "# General Rules\n\nRules.\nThe very word can trigger skepticism.\nAnd understandably so.\nWe are often confronted with seemingly arbitrary rules\nwhich make our lives harder for no apparent reason.\n\nIn this chapter I will give you rules to follow,\nbut I will also explain each rule's rationale.\nSo if you find yourself in a situation beyond the scope of the rule,\nyou'll be equipped to make intelligent decisions about how or if to apply it.\n\nIt is also important to acknowledge the limits of these rules.\nThey are targeted principally at writing within a professional business context.\nIf you are writing a novel,\nthese rules will be of limited use.\nAnd if you are writing poetry,\nthey will probably be entirely useless.\nBut if you need to communicate ideas to your coworkers,\nthen these rules will serve you well.\n\nNow that we've set the appropriate context, let's look at those rules.\n\n## 1. Be goal oriented.\n\n> \"In my end is my beginning.\"\n> \n> -- T.S. Eliot\n\n### Everything you write has a goal\n\nSuppose a boss or client came to you and said they needed you to build a web application.\nYour first question would probably be,\n\"What is the application for?\"\nThe very idea of writing an application without knowing its purpose is ridiculous.\nYet when it comes to writing prose,\nwe too often fail to ask the obvious question.\n\nEverything you write has a goal,\nwhether explicit or implicit.\nThose API docs?\nThe stated goal is to inform other developers how to use your library.\nThat weekly status report you email your client?\nThe unstated goal is reassuring them that their money is being well spent.\n\nThe goal of a document isn't always obvious,\nbut in the next chapter, we'll look at some tools to figure it out.\n\n### Knowing the goal equips you to fulfill it.\n\nLet's go back to our hypothetical web application above.\nSuppose you did try to build it without actually knowing its purpose?\nYou are just given a list of features and told to start building.\nWhat would happen?\n\nYou'd have no way to evaluate how well or poorly the application was doing.\nAnd that's not just a problem at the end.\nAll along you'd have questions about how best to build each feature.\nBut without knowing the application's purpose,\nyou'd have no way of choosing between the alternatives.\nThat kind of uncertainty is crippling.\nAnd I suspect that is why many people avoid writing.\n\nBut when you do know the goal you are writing toward,\ndecisions are easier,\nand it is simpler to tell whether your writing succeeds in achieving its end.\n\n### The structure of goals\n\nWe've talked about goals a lot,\nbut so far we haven't really clarified what kind of goals we're talking about.\nIt's all about the document.\n\nIn this book,\nwhen I talk about goals,\nI mean the purpose intrinsic to the document[^telos],\nnot the author's personal motivations.\nFor instance,\nyour goal in writing API docs may be to keep your tech lead from bugging you about it yet again.\nBut the purpose of the docs themselves is to assist users of the API.\n\nA document's goals will generally fall into one of two categories:\nto inform or to persuade.\nMost documents will include a bit of both,\nbut one will be primary.\nTo go back to the API docs example,\nit may help persuade people to use your library,\nbut the primary purpose is just to inform them about how to do so.\n\n[^telos]: If you're familiar with ancient Greek philosophy,\nthis is what Aristotle would call the document's _telos_.\n\n## 2. Be concise.\n\nIn a professional context,\neveryone is pressed for time.\nBeing concise is about respecting your readers' time.\nDon't force them to read a page when a paragraph will do.\n\nConciseness also helps you achieve your goal.\nThe more time investment your text requires,\nthe more reluctant readers will be to give it to you.\nSo we should do our best to keep the required investment to a minimum.\n\nAt the same time, conciseness does not mean being excessively terse.\nConciseness means saying the exact amount necessary to achieve the goal:\nno more and no less.\n\n## 3. Be Clear\n\n### Avoid ambiguity\n\nHuman language is rife with ambiguity.\nTake as an example my first title idea for this book:\n\"Writing for Developers.\"\nOnly three words,\nyet it could be read in two totally different ways.\nThat title could have meant\n-- as I intended --\n\"A book for developers on the subject of writing.\"\nBut another equally reasonable interpretation was,\n\"A book on writing for an audience of developers.\"\n\nAmbiguous language is useful in art and poetry,\nbut not when we are trying to communicate as efficiently as possible.\n\n### Avoid jargon\n\nIt is also wise to avoid unfamiliar terms and jargon.\nOf course, this is dependent on your audience.\nTo a developer, this sentence makes perfect sense:\n\n> \"Hoth is a lightweight MVVM framework\n> which leverages dirty checking\n> and immutable data structures for performance.\"\n\nTo a non-developer,\nit sounds more like this:\n\n> Hoth is a lightweight magic framework\n> which leverages scary magic\n> and scarier magic for performance.\n\nFor readers unfamiliar with the terminology it communicates next to nothing.\n\n### Narrow the scope of your words\n\nWe love to speak in generalities.\nPerhaps because it is difficult to definitely prove a generality wrong.\nThe problem is that the more general a statement is,\nthe more difficult it is to understand and apply.\nConsider this example:\n\n> Object-oriented programming is terrible.\n\nIt's not completely meaningless,\nbut it is extremely broad,\nand the implications are unclear.\nShould readers avoid all object oriented languages?\nIt's hard to tell what the author is thinking.\n\nContrast with this:\n\n> Class-based inheritance tends to make code unnecessarily complex.\n\nThis version has narrowed the scope in two ways.\nIt has narrowed from all object-oriented programming to class-based inheritance.\nAnd it has narrowed from \"terrible\" to \"tends toward unnecessary complexity.\"\nAs a result,\nthis sentence is much easier to understand and evaluate.\n\nGiven the choice between the specific and the general, choose the specific.\n\n## 4. Be organized.\n\nFor many people this is the most difficult part.\nThey know the goal.\nThey can write clear, concise sentences.\nBut they have a hard time putting those pieces together into a coherent whole.\n\nIn the next chapter we'll look at how to do it.\nFor now let's explore why.\n\n### Structure aids comprehension\n\nThe human mind is built for pattern matching.\nAnd it is pretty good at its job,\notherwise we'd have all been eaten by tigers long ago.\n\nConsider two different lists:\n\n* Apple pie\n* Blueberry pie\n* Cranberry pie\n\n* Wrench\n* Justice\n* Puppy\n\nThe first list is much more memorable and comprehensible.\nWhy?\nBecause it is organized into a structure that our minds can easily extract.\nEach item in the list was a pie.\nEach of the pies was fruit-based.\nAnd the pies were alphabetically ordered.\nBut the second list had no unifying organizational structure.\n\n### Structure is fractal\n\nWriting structures are simultaneously high level and low level.\nThey encompass everything\nfrom your three main points\nto that sub-sub-sub-point in paragraph 45.\nAnd if you've chosen your structure well,\nthe micro and macro levels will tend to mirror each other.\nFor example, consider this outline for an article on the Hoth Framework.\n\n> * Intro to Hoth\n> * Immutable data structures\n> * Intro\n> * Benefits\n> * Examples\n> * Dirty checking\n> * Intro\n> * Benefits\n> * Examples\n> * Example application\n> * Conclusion\n\nBoth of the main sub-points follow the same structure as the outline as a whole.\nThe mirroring isn't always this obvious,\nbut it is generally present.\n\n### Projects may come with built-in structure\n\nCertain kinds of projects come with ready-made,\nvery detailed structures,\nsimply because of how common that type of project is.\nAPI docs,\nfor example,\nmay vary a bit by language,\nbut will generally look pretty close to this.\n\n* Modules\n * Name\n * Description\n * Classes\n * Name\n * Description\n * Methods\n * Name\n * Arguments\n * Return value\n * Description\n\nNot every predetermined structure is that specific, though.\nLibrary websites have several things they need to include,\nlike language,\npurpose of the library,\nand how to install it,\nbut they also have more flexibility.\n\n### General purpose structures\n\nIn addition to these very specific structures,\nthere are also many general purpose structures.\nThese are things like the inverted pyramid, objection-response, etc.\n\nTypically you will pick two or three of these general purpose structures\nand use them as the organizing principle of the project.\n\n## 5. Be scannable.\n\nWhile the previous rule was about the conceptual structure of a text,\nthis rule is about the visual typographic structure.\nThe point of scannability is to allow readers to locate important information at a glance,\nrather than reading every word on the page.\nEven for readers that do read every word,\nscannable typography makes it easier to refer back to key ideas in the text.\n\n### Break text into bite-sized pieces\n\nHave you ever read a paragraph that took up an entire printed page?\nThey are no fun to read.\nWith no visual breaks,\nit is difficult to keep track of where you are,\nmuch less follow the flow of ideas.\n\nTo maximize scannability,\ntext should be broken into bite-sized units of thought.\nParagraphs, for example, should generally be 2-5 sentences long.\nMuch longer and it becomes difficult to read.\nShorter and you may want to use a heading instead.\n\n### Divide and conquer with headings\n\nThe primary purpose of headings is to make your text's conceptual structure explicit.\nHowever, they also have two important scannability implications.\n\nFirst, headings provide a visual anchor allowing readers to locate where a concept is discussed.\n\nSecond, headings breaks the text into units of progress which help the reader stay motivated to continue.\nThis is part of the reason list posts are such a popular article format.\nEach time the reader reaches the next heading,\nthey get to cross something off their mental checklist.\n\n### Use lists for your lists\n\nWhile not as common as paragraphs,\nthe humble list is one of the author's most helpful tools.\nIt provides:\n\n* Visual attraction for the list\n* Visual attraction for each item in the list\n* A break from the monotony of paragraphs\n* A sense of progress\n\nYou can, of course, embed lists directly into your sentences and paragraphs.\n\n> While not as common as paragraphs,\n> the humble list is one of the author's most helpful tools.\n> It provides:\n> visual attraction for the list,\n> visual attraction for each item in the list,\n> a break from the monotony of paragraphs,\n> and a sense of progress.\n\nHowever, doing so relegates the list contents to a secondary status.\nIn general,\nusing typographic lists\n(bulleted, numbered, etc.)\nfor your conceptual lists makes sense if the exact contents are worth emphasizing.\n\n### Emphasize key ideas with bold or italics\n\nOrdinary paragraphs are the parts of a text most likely to be skipped over.\nBut sometimes important ideas only make sense as part of a paragraph.\nThat's where typographic emphasis comes in.\n\nHighlighting important ideas with bold or italics allows readers to see key ideas at a glance.\n\nHowever, there are some rules of thumb to keep in mind.\n\n* Only highlight one phrase or sentence per paragraph.\n* Don't highlight something in _every_ paragraph.\n* **Never** highlight something with both bold and italics.\n\nGo beyond these limits and readers are likely to feel that you are shouting at them."
},
{
"path": "manuscript/why.json",
"content": "{\n \"title\": \"Why should developers study writing?\",\n \"eleventyNavigation\": {\n \"key\": \"Why should developers study writing?\",\n \"order\": 1\n }\n}"
},
{
"path": "manuscript/why.md",
"content": "# Why should developers study writing?\n\nIf you've picked up this book, then you're probably a software developer.\nFurthermore, you're someone who cares about your career.\nYou've probably spent countless hours\nstudying manuals,\nreading library docs,\nlearning how to write clean code,\nand otherwise mastering your craft.\n\nBut you may be skeptical.\nThere are a thousand other things you could learn.\nWhy spend the time studying writing?\nLet's walk through some of the things you might be thinking.\n\n## I'm paid to code, not to write.\n\nIn most cases, developers aren't paid to code.\nWe are paid to produce working software that solves a business problem.\nIn order to do that we may need to:\n\n* Email a product manager to clarify a requirement\n* Instant message a designer to verify the color and placement of a call-to-action button\n* Document the details of an internal REST API\n* Submit a patch to an open-source project you use\n* File a bug report about a part of the software developed by another team\n* Provide explanatory notes about that spike in server errors on the 14th\n* Tweak the wording of some UI text that is confusing users,\n since the designer is unavailable\n\nAll of these things are run of the mill tasks for a software developer.\nAnd every single one of them is a form of writing.\n\n## I already know how to write. I did well in school.\n\nUnfortunately, literacy,\neven at college or university level,\ndoesn't guarantee the ability to write effectively.\nMany degree programs place little emphasis on writing.\nAnd those that do emphasize it often encourage an academic style which doesn't mesh well with most developer's jobs.\n\nAcademic writing tends to value a kind of distant objectivity which can manifest as:\n\n* Unnecessary jargon\n* Verbose and indirect prose\n* Extreme formality\n\nIn contrast, most developers would benefit from making their prose clear, direct, and concise.\n\n## But I could be studying the Hoth framework instead. It's so cool!\n\nYes, no matter which topic you decide to study,\nyou will be passing up something else.\nBut writing deserves special consideration.\nWhy?\n**Because writing is a durable skill.**\n\nTechnology changes quickly.\nIf you're not careful,\nyou can easily invest a lot of time and energy into a technological one hit wonder.\nWriting, though, will never be rendered obsolete by the fickle winds of technology or fashion.\n\n**Writing is also a transferable skill.**\nIf you decide to change careers and become a\nrealtor,\nlandscape artist,\nor -- God forbid! -- a manager,\nyour expertise in the Hoth MVVM framework will be of limited use.\nBut writing will remain.\n\n## But what will I get out of studying writing?\n\n### Less back and forth\n\nWe've all experienced out of control email threads.\nIt starts with a vague question,\nis usually followed by an ambiguous answer,\nand before you know it,\nsomeone in another department is freaking out about a non-existent problem.\n\nWhat if you could step in and make people understand?\nEven better, what if you could prevent the issue from escalating in the first place?\nThat's the power of clear and effective writing.\n\n### Fewer bugs and less rework\n\nSometimes we run across frustratingly mysterious bits of code.\nPerhaps we've even written some ourselves.\nBut what's even more frustrating\nis when the code is accompanied by an equally mysterious comment like,\n\"fixes IE bug.\"\n\nWhat IE bug? And which version of IE?\n\nA developer working on this code, now needs to:\n\n* Talk to the original programmer,\n who won't remember anything.\n* Manually test to see if there are obvious bugs related to that line,\n which he probably won't catch.\n* And perhaps make changes anyway,\n without knowing what he broke.\n\nA clearly written comment would have prevented all of that.\n\n### Protect your development flow\n\nTalking face to face is a valuable and necessary part of our jobs.\nBut not every face to face conversation is valuable.\n\nIf you find yourself explaining certain things over and over again\n(perhaps because you're an expert in a particular subsystem)\nthen you should write it down in a public location like a team wiki.\nIf your explanations are clear and easy to understand,\nyou'll have fewer interruptions messing with your development flow.\n\n### Recognition of your expertise\n\nPerhaps you have a different problem.\nYou have a deep knowledge of some tool, library, or system,\nbut no one realizes it.\nWriting guides, tutorials, and presentations\ncan help you achieve greater recognition,\nboth inside and outside your company.\n\n### Greater trust from managers\n\nWatching a software development project from the outside can be a frustrating experience.\nThis is doubly true if you are on the hook when something goes wrong.\n\nA developer who can clearly articulate the state of the project,\nwithout getting bogged down in technical details,\nis invaluable.\n\nIf you are that developer,\nyou will quickly earn the trust of your manager and non-technical colleagues.\n\n### Improve your own understanding\n\n> \"How can I tell you what I think till I see what I say?\"\n> \n> -- E.M. Forster, _Aspects of the Novel_\n\nThe process of writing takes our often fuzzy and unformed ideas,\nand shapes them into something clear enough to communicate to others.\nThis makes writing an excellent way to deepen our own understanding of a subject.\nSometimes the improvement comes from research,\nbut often it comes simply due to organizing our own thoughts.\n\n## What now?\n\nHopefully by this point you can see why studying writing is worthwhile.\nIn the next chapter,\nwe'll launch into some general rules you can use to improve your writing."
},
{
"path": "netlify.toml",
"content": "[build]\n publish = \"_site\"\n command = \"npm run build\"\n #command = \"npm run build && set -e && find ./_site -type f -name '*.html' -exec staticrypt -f password_template.html {} $PASSWORD -o {} \\\\;\"\n functions = \"functions\"\n\n# REDIRECT and HEADERS examples\n\n# Redirect rule example\n# For more information see:- https://www.netlify.com/docs/netlify-toml-reference/\n\n#[[redirects]]\n# from = \"/*\"\n# to = \"/blog/:splat\"\n\n# The default HTTP status code is 301, but you can define a different one e.g.\n# status = 302\n\n# Headers rule example\n# For more information see:- https://www.netlify.com/docs/netlify-toml-reference/\n\n#[[headers]]\n# Define which paths this specific [[headers]] block will cover.\n# for = \"/*\"\n\n#[headers.values]\n# X-Frame-Options = \"DENY\"\n# X-XSS-Protection = \"1; mode=block\"\n# Content-Security-Policy = \"frame-ancestors https://www.facebook.com\"\n\n# Redirects and headers are GLOBAL for all builds – they do not get scoped to\n# contexts no matter where you define them in the file.\n# For context-specific rules, use _headers or _redirects files, which are\n# applied on a PER-DEPLOY basis.\n"
},
{
"path": "outline.md",
"content": "# Prose for Programmers Outline\n\nChecked boxes indicate that the initial draft of a section is complete.\n\n## [Why should developers learn to write?](manuscript/why.md)\n\n- [x] Objections\n - [x] Paid to code, not write\n - [x] Laundry list of writing developers have to do\n - [x] Coding is writing\n - [x] I already know how to write. I did well in school.\n - [x] Literacy, even college level, doesn’t mean your writing is good\n - [x] Academics can even foster bad writing habits\n - [x] But I could be learning technology X instead\n - [x] Writing is a durable skill\n - [x] Writing is a transferable skill\n- [x] Benefits\n - [x] fewer back and forth emails/chats\n - [x] Fewer bugs due to misunderstood code/docs\n - [x] Fewer interruptions from coworkers with questions (keep flow)\n - [x] More understanding/empathy from managers\n - [x] Recognition of your knowledge\n - [x] Increase your own understanding\n\n## [General Rules](manuscript/rules.md)\n\n- [x] Be goal oriented\n - [x] Everything you write has a goal or purpose\n - [x] may be implicit or explicit\n - [x] Understanding the goal promotes better writing\n - [x] Structure of goals\n - [x] 2 types\n - [x] inform\n - [x] persuade\n - [x] Most writing serves both to one degree or other\n - [x] But most writing has a primary goal, with others as secondary\n- [x] Be concise\n - [x] Not short or terse\n - [x] Everything contributes to the goal\n - [x] Avoids wordiness for the sake of the goal\n- [x] Be clear\n - [x] Avoid unfamiliar or unnecessary jargon\n - [x] Avoid ambiguity\n - [x] Be precise\n- [x] Be organized\n - [x] Human mind uses patterns to extract meaning\n - [x] Structure is fractal: macro and micro mirror each other\n - [x] Projects may come with built-in structure (API docs)\n - [x] Several general purpose structures available\n- [x] Be scannable\n - [x] Typographic structure to direct attention to ideas\n - [x] Break up text into digestible chunks\n - [x] use headlines\n - [x] use lists\n - [x] Make use of bold and italic to highlight points\n\n## [The Writing Process](manuscript/process.md)\n\n- [x] Determine the goal\n - [x] Why am I writing this?\n - [x] Purpose of doc\n - [x] Not personal motivations\n - [x] Keep asking why\n- [x] Determine audience\n - [x] Who will be reading this?\n - [x] Given the goals, which readers are the primary audience?\n - [x] What is their relation to the subject?\n - [x] What is their relation to you?\n - [x] Examples of how audience affects writing\n- [x] Choose a suitable structure\n - [x] Different structures are suitable for different goals\n - [x] Hierarchical structures are often good for informational\n - [x] Narrative is good for persuasive\n - [x] Different structures for different audiences\n - [x] Expertise in topic\n - [x] Shallow bullet points\n - [x] Deep information hierarchy\n - [x] Level of interest\n - [x] Relationship\n - [x] Can mix and match\n - [x] Examples\n- [x] Build an outline\n - [x] Structure may come with an outline template (API docs)\n - [x] List of the ideas you want to communicate\n - [x] Evaluate outline based on goal and audience\n - [x] Revise outline\n - [x] Revising earlier is cheaper\n- [x] Turn outline into prose\n - [x] Put flesh on the bones\n - [x] Muscles: human connection/emotion for strength\n - [x] Connective tissue: transitions between ideas\n - [x] Not necessarily exposition\n - [x] Stories\n - [x] Jokes\n- [x] Revise\n - [x] Evaluate\n - [x] Does this unit advance the goal?\n - [x] Is it concise?\n - [x] Is it clear?\n - [x] Is it organized?\n - [x] Is it scannable?\n - [x] Plan a correction\n - [x] Make corrections\n- [x] Get feedback\n - [x] Types of readers\n - [x] Target audience\n - [x] Experts\n - [x] Friends\n - [x] Evaluating feedback\n - [x] Readers are always right about their reactions\n - [x] Readers may be wrong about the problems and solutions they identify\n - [x] Bear in mind what kind of reader this is\n - [x] Produce a list of problems to address and good points to keep\n- [x] Revise based on feedback\n - [x] See previous\n- [x] Publish\n - [x] May be done at any point (depending on project)\n - [x] Can be part of an iterative process\n - [x] Tell people about it\n - [x] Not the end of revision\n- [x] Conclusion\n - [x] Abbreviate process as appropriate\n\n## Writing Structures\n\n- [ ] General Structures\n - [ ] Inverted Pyramid\n - [ ] what it is\n - [ ] why it is useful (time saving)\n - [ ] high level\n - [ ] low level (topic sentences)\n - [ ] List\n - [ ] Sequence\n - [ ] Q & A ?\n- [ ] Informational Structures\n - [ ] Hierarchy\n - [ ] Examples\n - [ ] Textbooks\n - [ ] API Docs\n- [ ] Persuasive structures\n - [ ] Objection - response\n - [ ] Persuasive version of Q&A\n - [ ] Problem - solution\n - [ ] Story\n - [ ] Syllogism\n - [ ] Juxtaposition (attention grabbers)\n- [ ] Combine as appropriate\n - [ ] Examples\n\n## Audience\n\n- [ ] Aspects of audience\n - [ ] Expertise in subject\n - [ ] Relationship to you\n - [ ] Motivation for reading\n - [ ] Emotional state\n - [ ] Level of caution/skepticism\n- [ ] Common audiences for developers\n - [ ] Other developers\n - [ ] Somewhat similar outlook on the world\n - [ ] Not necessarily the same as you\n - [ ] Experience\n - [ ] Different technologies\n - [ ] Corporate vs startup\n - [ ] QA & testers\n - [ ] Designers\n - [ ] Teammates\n - [ ] Non-technical peers\n - [ ] Your boss\n - [ ] Management\n - [ ] Ops/SysAdmin\n - [ ] Users\n - [ ] Clients\n - [ ] Customers\n\n## Genres\n\n- [ ] Genres\n- [ ] Email\n- [ ] Docs\n- [ ] Code Comments\n- [ ] Blog posts\n- [ ] Chat?\n- [ ] Project site\n- [ ] Case for new technology\n- [ ] Requirements\n- [ ] Bug reports\n- [ ] Error messages\n- [ ] Help articles\n- [ ] UI text\n- [ ] Commit messages\n- [ ] Code review\n- [ ] Code?\n- [ ] Talks/presentations?\n\n## Other Resources\n\n- [ ] Books\n - [ ] The Elements of Style by Strunk & White\n - [ ] The Economist Style Guide\n - [ ] Steering the Craft by Ursula K. Le Guin\n - [ ] On Writing Well by William Zinsser\n - [ ] Writing That Works by Ogilvy?\n - [ ] Team Geek?\n- [ ] Applications & Tools\n - [ ] Workflowy\n - [ ] Writeroom\n - [ ] Writemonkey\n - [ ] IA Writer\n - [ ] Hemingway?\n - [ ] write-good npm library?"
},
{
"path": "package.json",
"content": "{\n \"name\": \"spacebook\",\n \"version\": \"1.0.0\",\n \"description\": \"A simple site generator based on Eleventy, Tailwind 2.0, and Alpine.js\",\n \"scripts\": {\n \"start\": \"eleventy --serve & postcss styles/tailwind.css --o _tmp/style.css --watch\",\n \"build\": \"ELEVENTY_PRODUCTION=true eleventy && NODE_ENV=production postcss styles/tailwind.css --o _site/style.css && ./node_modules/.bin/cleancss -o _site/style.css _site/style.css\",\n \"watch\": \"npx eleventy --watch\",\n \"debug\": \"DEBUG=* npx eleventy\"\n },\n \"repository\": {\n \"type\": \"git\",\n \"url\": \"git+https://github.com/broeker/spacebook.git\"\n },\n \"author\": \"Tim Broeker 🔒 Enter a password to unlock!\n \n \n \n"
},
{
"path": "postcss.config.js",
"content": "module.exports = {\n plugins: [\n require(`tailwindcss`)(`./styles/tailwind.config.js`),\n require(`autoprefixer`),\n ],\n};\n"
},
{
"path": "robots.md",
"content": "---\ntitle: Robots \npermalink: /robots.txt\nlayout: layouts/robots.njk\n---\n"
},
{
"path": "search-index.json.njk",
"content": "---\npermalink: /search-index.json\n---\n{{ collections.results | search | dump | safe }}\n\n\n"
},
{
"path": "styles/tailwind.config.js",
"content": "const autoprefixer = require('autoprefixer');\n\nmodule.exports = {\n important: true,\n future: {\n removeDeprecatedGapUtilities: true,\n purgeLayersByDefault: true,\n },\n purge: {\n enabled: true,\n content: [\"_site/**/*.html\"],\n options: {\n safelist: [],\n },\n },\n darkMode: 'class',\n theme: {\n container: {\n center: true,\n },\n extend: {\n typography: {\n DEFAULT: {\n css: {\n maxWidth: '100%',\n a: {\n color: '#1D4ED8',\n '&:hover': {\n color: '#1E3A8A',\n },\n },\n '.prose a.edit, .tag a': {\n color: '#333',\n 'text-decoration': 'none',\n },\n 'ul.footer-nav': {\n '::before': {\n display: 'none',\n 'text-decoration': 'none',\n }\n },\n 'ul.contains-task-list': {\n '::before': {\n display: 'none',\n }\n },\n 'ul.spacelog': {\n '::before': {\n display: 'none',\n }\n },\n },\n },\n }\n },\n }, \n variants: {},\n plugins: [\n require('@tailwindcss/typography'),\n require('@tailwindcss/forms'),\n ],\n}"
},
{
"path": "styles/tailwind.css",
"content": "@tailwind base;\n@tailwind components;\n@tailwind utilities;\n\n@layer base {\n \n /* Set up some default image behavior for nicer images */\n img {\n @apply w-auto shadow-md border-2 border-transparent !important\n }\n img:hover {\n @apply border-2 border-gray-100\n }\n /* Overrides for Tailwind Typography prose class */\n .prose a {\n @apply dark:text-gray-400\n }\n .prose a:hover {\n @apply dark:text-gray-500\n }\n .prose h1, .prose h2, .prose h3, .prose h4, .prose h5, .prose h6 .prose hr, .prose strong {\n @apply dark:text-gray-400\n }\n .prose h2, .prose h3, .prose h4, .prose h5, .prose h6 {\n scroll-margin-top: 3.5em;\n }\n .prose pre code {\n @apply overflow-x-auto !important \n }\n .prose .footer-nav a {\n @apply no-underline !important\n }\n .prose ul.contains-task-list,\n .prose ul.spacelog {\n @apply list-none -ml-6 !important;\n }\n .prose ul.contains-task-list .task-list-item,\n .prose ul.spacelog {\n ::before {\n @apply hidden !important;\n }\n }\n\n /* Define blockquotes and some standard callout blocks */\n blockquote {\n @apply rounded-lg p-4 bg-gray-100 dark:bg-gray-500 border-gray-200 border-l-8 dark:border-gray-700;\n }\n .callout {\n @apply px-8 py-4 mb-4 rounded-lg bg-yellow-50;\n }\n .callout, .callout strong, .callout em {\n @apply dark:bg-gray-400 dark:text-gray-900;\n }\n .callout-blue {\n @apply px-8 py-4 mb-4 rounded-lg bg-blue-50;\n }\n .callout-blue, .callout-blue strong, .callout-blue em {\n @apply dark:text-gray-200 dark:bg-blue-900;\n }\n .callout-pink {\n @apply px-8 py-4 mb-4 rounded-lg bg-pink-50;\n }\n .callout-pink, .callout-pink strong, .callout-pink em {\n @apply dark:text-gray-200 dark:bg-pink-900;\n }\n .callout-green {\n @apply px-8 py-4 mb-4 rounded-lg bg-green-50;\n }\n .callout-green, .callout-green strong, .callout-green em {\n @apply dark:text-gray-200 dark:bg-green-900;\n }\n .warning {\n @apply px-8 py-4 mb-4 rounded-lg bg-red-800 text-gray-50;\n }\n .warning, .warning strong, .warning em {\n @apply text-gray-50 dark:bg-red-900 dark:text-gray-200;\n }\n\n /* Overrides for nav/Table of Contents block */\n nav ul {\n @apply ml-0 text-gray-500;\n }\n nav ul ul {\n @apply ml-6 text-gray-500;\n }\n nav ul li a {\n @apply mb-1 pt-2 pr-4 pb-1 pl-2 w-full block text-gray-500 dark:text-gray-500;\n }\n nav ul li a:hover {\n @apply text-gray-900 dark:text-gray-400;\n }\n nav ul li a.active {\n @apply font-semibold;\n }\n nav.toc ol li {\n @apply pt-2 !important\n }\n nav.toc ol li li {\n @apply pt-2 ml-4\n }\n nav.toc ol li a {\n @apply text-gray-500\n }\n nav.toc ol li a:hover {\n @apply text-gray-900\n }\n .prose .footer-nav a:hover {\n @apply dark:text-gray-400 !important\n }\n\n/* Utilities and misc */\n .adjust p img, .adjust img, .adjust p iframe, .adjust iframe, .twitter-tweet {\n @apply shadow-md ml-auto mr-auto p-2 !important\n }\n .adjust p img:hover, .adjust img:hover {\n @apply shadow-xl \n }\n .adjust img.button {\n @apply w-auto shadow-none !important\n }\n .text-align-center {\n @apply flex justify-center; \n }\n .icon-spacer {\n width: \"24px\";\n }\n input {\n @apply dark:text-gray-400\n }\n}\n\nblockquote p::before {\n content: '' !important;\n}\n\nblockquote p::after {\n content: '' !important;\n}\n\nblockquote>p:first-child {\n margin-top: 0;\n}\n\nblockquote>p:last-child {\n margin-bottom: 0;\n}"
}
]\n \n \n \n\n
\n\n \n