Yes, using custom tags. Example in Python, making the !join tag join strings in an array:

@path.yield_self(&File.method(:read)).yield_self(&Parser.method(:new)) ...

Why not use map, which we already have for collections? Generally speaking, the map function isn't just about collections (though that's usually how it's used in Ruby). map is more about putting an object in a context (a block in Ruby's case), modifying the object, and returning the modified object.

I use only a subset of ruby that makes sense to me and I find appealing. Thankfully one can use ruby just fine without having to use everything.

TylerRick commented

I ended up using a really poor hack, in my package.json, scripts: { ... "prebundle": "openapi bundle -o src/openapi.preprocessed.json spec/openapi.yaml --force --config .redocly.pre-processor.yaml 2>/dev/null && echo 'warning: errors from pre-processing step have been supressed'", "bundle": "openapi bundle -o src/openapi.json src/openapi.preprocessed.json ... }

I don't know about you guys but I like dots on the second line when combined with indentation : # Example 1 one.two.three .four # Example 2 my_array.select { |str| str.size > 5 } .map { |str| str.downcase }

They require the continuation to be present at precisely next line. (I.e. you cannot put more than one in-line comment in between.)

The order of these method calls may or may not matter. With leading dots, editing is a bit easier, particularly when you need to add a new method call or change the order.

(Similar to the javascript issue, you always have to remember to remove/add the trailing comma, so some developers prefer to put 'comma' in the beginning of each property.)

The Programmers Solid 3D CAD Modeller

Due to their lightweight nature, it is not uncommon to have hundreds of thousands of processes running concurrently in the same machine.

Spawn an Elixir process (not an operating system one!)

Do yourself and your peers a favor, write code with them in mind.

Writing Code for Humans — A Language-Agnostic Guide…because code which people can’t read and understand is easy to break and hard to maintain.

Also, the chances of breaking something are really high, because not even you remember how the code actually works.

Some people eventually realize that the code quality is important, but they lack of the time to do it. This is the typical situation when you work under pressure or time constrains. It is hard to explain to you boss that you need another week to prepare your code when it is “already working”. So you ship the code anyway because you can not afford to spent one week more.

your cognitive load increases with the level of indentation. 1 2 3 4 5 6 7 8 9 10 if r.Method == "GET" { if r.Header.Get("X-API-KEY") == key { // ok return nil }else{ return errors.New("Key is not valid") } } else { return errors.New("Invalid Method") }

Cognitive capacity is the total amount of information the brain is capable of retaining at any particular moment. This amount is finite, so we can say our total capacity is only ever 100%. How much of one’s cognitive capacity is being used towards a particular task at any given time is called the cognitive load

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

netstat -tn 2>/dev/null | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

To see if you are writing good code, you can question yourself. how long it will take to fully transfer this project to another person? If the answer is uff, I don’t know… a few months… your code is like a magic scroll. most people can run it, but no body understand how it works. Strangely, I’ve seen several places where the IT department consist in dark wizards that craft scrolls to magically do things. The less people that understand your scroll, the more powerfully it is. Just like if life were a video game.

it quickly becomes a mess of non related functions that anyone but the owner feels brave enough to import

A little copy paste is better than a little dependency.

Avoid indentation levels, If you find yourself with more than 3, you should create a function.

Code explains what and how Documentation explains why.

So make sure to write your documentation, but do not explain your spells.

This is so clear that you don’t even need comments to explain it.

Another type of comments are the ones trying to explain a spell.

Do not explain your spells, rewrite them.

Do you really need those lines? Isn’t it clear enough? Well, I still find comments like this in a lot of cases and it gets funnier when the comment is obsolete and the code is doing other things. Following the example, let’s imagine that another developer adds support for PUT method. I think that this is what would happen.

This code is much easier to understand as it do not add levels of indentation and follows the principle where the 0 indentation level is the principal path of the application where other paths are exceptions or rare cases.

people usually forgets about one of the greatest advantages of Open Source. YOU can fix the issue. You can download the source code and dig deep into the code allow you to keep moving. Also, you can merge this changes back to the original repository so others doesn’t have to fix it again. win-win relationship.

The rule of thumbs is, never use code that you do not understand.

:w saves.

I used to write code. I still do, but I used to, too.

I don't like the first syntax because then you have weird looking code due to all the leading whitespace, and you lose a lot of real estate.

Aligning everything with however long the method name is makes every indention different. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true Compared to the following, which all align nicely on the left. belongs_to :thing, class_name: 'ThisThing', foreign_key: :this_thing_id has_many :other_things, class_name: 'ThisOtherThing', foreign_key: :this_other_thing_id validates :field, presence: true

This one bugs me a lot, but honestly, I don't like either style of the "normal method calls" above. I'm definitely voting to change the rule, but I'd also recommend trying to use the following syntax. In my opinion, it's the best of both worlds. a_relatively_long_method_call( :thing, :another_thing ) Or, if there are a lot or arguments, or the arguments are long: a_relatively_long_method_call( :a_long_argument, :another_long_argument, :a_third_long_argument )

When I ask people about any part of their code, they usually say it's easy to understand. But when I open the code, it takes me a couple hours slapping to my face to keep myself alive to understand just a little part of their code.

The best book that I can recommend to any developer to shape up their attitude about programming.

But how much readability are enough?

In collusion, writing good code not only require knowledge but also require compassion. To understand people's pain and mistakes, to think about your teammate and to help everyone achieve a better life.

collusion

Think about how good it is if you can build a system at “2 half brain quality” and then people just need use 1 half of their brain to maintain it. You can fix bug in a blink of an eye, run tests and give it to tester, done. Everything will be done in a easiest way and fixing bug or refactoring can be easy like breathing. The most heavy task in programming is not about building application, but it’s about maintain them and if you wrote something you can’t understand, then you will suffer for the rest of your life.

they’re just too familiar with the code to think it's complicated

Write code for human, not for God

400 Bad Request is the status code to return when the form of the client request is not as the API expects.401 Unauthorized is the status code to return when the client provides no credentials or invalid credentials.403 Forbidden is the status code to return when a client has valid credentials but not enough privileges to perform an action on a resource.

Is there a problem or not?If there is a problem, on which side is it? On the client or on the server side?

I said I wanted begin..end to follow the same indentation principles as if..end because they are semantically related (both are expressions), and I stand by that opinion.

Hey, checking from a few months in the future here. Is there by chance an update on this issue?

Unfortunately, the conversation on both PRs died off (no hard feelings, people have other things going on in their lives).

The RuboCop way is to offer an opinion in the way of a good default, but to accommodate all reasonable style choices.

really begin/end is just a way to pass several expressions where you normally need to pass only one. In this way I think it's much closer to something like conditionals (e.g. if, than to do).

in my personal opinion, there shouldn't be a special treatment of do-end blocks in general. I believe that anything that starts a "block", i.e. something that is terminated by and end, should have the same indentation logic

The point of that line was, "I tried irrelevant things and they obviously didn't work." I ate a banana while trying it- should I include that in the steps as well? The other work I did was not relevant, therefore, not mentioned explicitly outside of "I'm frustrated and just trying rubbish at this point." I could have been more clear saying that I've tried each of the available options on the 3 relevant to no avail, you are correct.

I have a simple coding principle: write lines of code as though instructing a real person how to do the job. And that naturally expands to designing and modelling systems like real organisations with their own divisions, departments, branches, and all the various “job positions” that need to be filled. Make the whole system appear as human as possible.

Conventions are good, but they are very limited: enforce them too little and the programmer becomes coupled to the code—no one will ever understand what they meant once they are gone. Enforce too much and you will have hour-long debates about every space and colon (true story.) The “habitable zone” is very narrow and easy to miss.

concurrent-safe

The variable a is incremented thanks to the atomic memory primitives function addInt that is concurrent-safe. However, we assign the result to the same variable, which is a not a concurrent-safe write operation. This a careless mistake detected by the atomic analyzer.

The rules recorded in natural language are readable not only by humans but also by the computer and therefore no longer need to be programmed by a software developer. This task is now taken over by openVALIDATION.

openVALIDATION enables programming of complex validation rules using natural language, such as German or English.

"detail": [ { "loc": [ "body", "name" ], "message": "Field required" }, { "loc": [ "body", "email" ], "message": "'not-email' is not an 'email'" } ]

For example, let’s consider the type property. For most of the projects I am working on, it isn’t practical to have a webpage dedicated to each type of possible error.

For the instance property, the most practical way I’ve found of implementing this is to define a URN that encapsulates additional information regarding the error. Here is an example URN for reference. urn:companyname:api:error:protocol:badRequest:f29f57d7-e1f8-4643-b226-fa18f15e9b71

We decided to follow their rules to stay in their affiliate program, because that's how we are able to actually run the site (without any ads).And if you look on the issue from the usability point of view, not having their price history isn't that big of a deal, unless the game is sold only on Amazon - and most games aren't - so you always have other stores to compare the price to.

Hi L0ki,as we depend on retailers with affiliate programs to run the site without ads, and Amazon being one of them, yes, we are following their rules so we can use API and their affiliate program.As Tomas said, we are also trying to get the history back, though we noticed we aren't the only site being affected by this.As for ignoring their API and doing it the hard way - that could be possible I guess but really not preferable.And we also understand anybody not wanting to buy from Amazon anymore (as some already told us), but to be fair, if the game is available anywhere else (and I have yet to randomly find a game which is available only at Amazon), you can always check the game info on ITAD to compare the price to other retailers.

If it's not, it should be illegal for them to forbid you from showing price history. This is restricting access to information, and it's probably supposed to benefit them from shady sales (increasing the base price just before a sale, so that the "X % off" is higher).

"We are not allowed to show you Amazon history"? What prompted this? Fill me in if I missed something :).EDIT: Camelcamelcamel can still show Amazon price history, so a bit befuddled here.

I would be interested to know what the legality of this is either way. I mean, do they really have any legal right to compel you not to list their price history? However, just knowing that Amazon doesn't want you to do this will make me less likely to purchase from them in the future. Anti-consumer behavior pisses me off. Edit: If this is related to API access couldn't you just manually scrape prices off the site instead and hammer their server? Or is this more related to not wanting to bite the hand that feeds you so to speak related to the funding you can get through referral links?

"type": "https://example.com/problems/request-parameters-missing"

This specification reserves the use of one URI as a problem type: The "about:blank" URI [RFC6694], when used as a problem type, indicates that the problem has no additional semantics beyond that of the HTTP status code. When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on), although it MAY be localized to suit client preferences (expressed with the Accept-Language request header). Please note that according to how the "type" member is defined (Section 3.1), the "about:blank" URI is the default value for that member. Consequently, any problem details object not carrying an explicit "type" member implicitly uses this URI.

Consumers can use the status member to determine what the original status code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without HTTP information. Generic HTTP software will still use the HTTP status code.

Likewise, truly generic problems -- i.e., conditions that could potentially apply to any resource on the Web -- are usually better expressed as plain status codes.

For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.

Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree.

The media type specification and registration procedure is now a separate document, to make it clear that it is independent of MIME.

they allow resources to be referred to without the need for a continuously available host, and can be generated by anyone who already has the file, without the need for a central authority to issue them. This makes them popular for use as "guaranteed" search terms within the file sharing community where anyone can distribute a magnet link to ensure that the resource retrieved by that link is the one intended, regardless of how it is retrieved.

However, while URLs allow you to locate a resource, a URI simply identifies a resource. This means that a URI is not necessarily intended as an address to get a resource. It is meant just as an identifier.

pointer: type: string description: A string containing a JSON pointer to the specific field within a received JSON body that caused the problem, e.g. '/data/attributes/title' to refer to the `title` property within the `attributes` object that is a child of the top level `data` object. example: /data/attributes/title

ErrorResponse: description: Container object for one or more errors returned by the API. type: object required: - errors properties: errors: type: array items: $ref: '#/definitions/Error'

TylerRick commented

I think your issue is a bug (it's different from this issue which is a feature request about the split command). I opened this issue you may want to follow: #560

with the caveat that the split->bundle will be lossy with respect to YAML comments/format. I've thought about it more and think, "so what?" If it enables teams to be more productive, great.

It means it is split to an opinionated split structure.

I saw the repo previously, but missed the split functionality, I thought it was more like a template repo.

FetchErrorResponse: type: object properties: meta: $ref: '#/definitions/FetchMetaResponse' errors: $ref: '#/definitions/Error' example: { "meta": { "req_id": "d07c8b12-c95e-4a06-8424-92aac94bb445" }, "errors": [{ "code": "Unauthorized", "detail": "A valid bearer token is required", "status":"401" } ] }

This has moved to part of the monorepo:

There are also some advantages to a multi-file YAML format OpenAPI definition: Reuse schema objects to keep things DRY (don't repeat yourself) Smaller diffs compared to JSON (especially for markdown descriptions) Easier to navigate Easier to edit with confidence

Filter gives me the impression of inclusion... so if I filter by fruits, I expect to see apples, oranges, and bananas. Instead, this is more like filter out fruits... remove all the fruits, and you're left with the rest. Filter in/out are both viable. One means to include everything that matches a condition, and the other is to exclude everything that does not match a condition. And I don't think we can have just one.

I got stuck with tests here #443 and I need to switch to other more prioritised work. Maybe somebody will take over when time allows.

let's not mix code changes with prettier. This is a bad practise which complicates code review and history review. Let's apply prettier in a separate PR/commit.

The server possibly can send back a 406 (Not Acceptable) error code when unable to serve content in a matching language. However, such a behavior is rarely implemented for a better user experience, and servers often ignore the Accept-Language header in such cases.

x-ov-rules: culture: en rule: | the location of the applicant MUST be Dortmund

Warning: The client should not repeat this request without modification.

It is often the case that a group or "tree" of documents has been constructed to serve a common purpose, wherein the vast majority of URI references in these documents point to resources within the tree rather than outside it. Similarly, documents located at a particular site are much more likely to refer to other resources at that site than to resources at remote sites. Relative referencing of URIs allows document trees to be partially independent of their location and access scheme.

Relative referencing of URIs allows document trees to be partially independent of their location and access scheme.

Would you accept a PR for the suggested change?

There are so many movies where the directors go out and say this is a family movie, just like the whole cast of Salaam Namaste when they shouted out that its a movie for families too..but the ones that have seen it they know how Vulguar the movie was at times. But this movie is a true family movie, and Iam sure your family will enjoy it, mine did for sure.

However, links between resources need not be format specific; it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats.

To be fair, for a $30 asset I don't really expect that much support, but the problem here is that because of the lack of docs and hard to parse and modify codebase, folks are way more dependent on the developer than for other assets with proper docs, field tooltips, and maintainable code.

The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

You can tell the lint command to validate specific API definitions by using their names from the apis object, like in the following example: Copy Copied redocly lint core@v2

We do, You doThis tutorial is most effective when you follow along and complete the steps.

Rename the existing default branch to the new name (main). The argument -m transfers all commit history to the new branch: git branch -m master main

Unfortunately, Wiki depends a lot on HEAD ref for its functionality, such as versions management, file collision check, etc. That causes multiple quirky behaviors. The normal project repositories don't fall into such behaviors because GitLab (Gitaly actually) has a complicated heuristic to determine the current default branch, while Wiki repository does not.

The fix is to unify how Git repository accesses the data.

Further, all outbound communication from the FaxZero server is secured with either SSL or TLS.

Snail mail can be too slow, and email isn't secure. So that leaves us with the decades-old, but still reliable, fax.

A workaround you can use is to move additionalProperties to the extending schema and redeclare the properties from the extended schema.

Because additionalProperties only recognizes properties declared in the same subschema, it considers anything other than “street_address”, “city”, and “state” to be additional. Combining the schemas with allOf doesn’t change that.

It’s important to note that additionalProperties only recognizes properties declared in the same subschema as itself. So, additionalProperties can restrict you from “extending” a schema using Schema Composition keywords such as allOf. In the following example, we can see how the additionalProperties can cause attempts to extend the address schema example to fail.

In your scenario, which many, many people encounter, you expect that properties defined in schema1 will be known to schema2; but this is not the case and will never be.

When you do: "allOf": [ { "schema1": "here" }, { "schema2": "here" } ] schema1 and schema2 have no knowledge of one another; they are evaluated in their own context.

],

I'm not sure if there's a reason why additionalProperties only looks at the sibling-level when checking allowed properties but IMHO this should be changed.

This clearly violates DRY, which is the reason why OP asked this question in the first place

It appears redundant, and my goal of using $ref is to avoid repeating definitions.

It's unfortunate that additionalProperties only takes the immediate, sibling-level properties into account

additionalProperties applies to all properties that are not accounted-for by properties or patternProperties in the immediate schema.

additionalProperties here applies to all properties, because there is no sibling-level properties entry - the one inside allOf does not count.

Incidentally, I am also the author of the website you are referring to.

[author of the draft v4 validation spec here]

unevaluatedProperties is like additionalProperties, except that it can "see through" $ref and "see inside" allOf, anyOf, oneOf, if, then, else

Yes, I understand that it had probably been tried. My question was more, "Why didn't twiddling the knob work?”

I think the answer lies here: Cant see into oneOf or allOf etc. This, I think, is the distinguishing difference between additionalProperties and unevaluatedProperties.

that is the key difference

Everything else in this issue is just figuring out how to make that happen, which turns out to be rather involved.

understanding that was a big (and recent) moment for me too.

If anyone can completely refactor the JSON Schema description for OpenAPI v3.0 to accurately describe the schema in all its glory, without using this new keyword, then please do so, but I would kindly ask you to test the theory first.

Such schemas cannot easily be refactored without removing the benefits of sharing. Refactoring would require forking a local copy, which for schemas intended to be treated as an opaque validation interface with internal details that may change, eliminates the benefit of referencing a separately maintained schema in the first place.

PRs will introduce various mechanisms step by step. Some of these have issues already. A possible breakdown could be: Annotation collection using instance values (links also does this) Defining annotations to which multiple keywords contribute (this is new, see Need more details of annotation collection #530) Defining subschema and keyword processing results to include annotations Processing sequence for keywords that dynamically rely on the results of static keywords The actual definition of unevaluatedProperties An example of unevaluatedProperties

In particular, it allowed for organizing common traits (such as extensibility, or different ways of showing examples as schemas that can be mixed in to the main object definitions.

This means that when considering the "unevaluatedProperties": false in the root schema, "wheels" has not been evaluated, so unevaluatedProperties applies to it, and therefore validation fails because the false subschema fails by definition against any instance.

consider a situation where the branches of the oneOf are separate schemas owned by other entities (and therefore impossible to refactor without forking), which are intended to provide an opaque validation interface (and therefore may change internal details without warning, but without changing the desired validation outcome) and are included by $ref

However, unevaluatedProperties has dynamic behavior, meaning that the set of properties to which it applies cannot be determined from static analysis of the schema (either the immediate schema object or any subschemas of that object).

unevaluatedProperties is similar to additionalProperties in that it has a single subschema, and it applies that subschema to instance properties that are not a member of some set.

Please do not debate the annotation collection mechanism here in this issue. Please do debate it in #530.

We do not want to change or remove additionalProperties. Providing a clear solution for the above use case will dramatically reduce or eliminate the misunderstandings around additionalProperties.

This is a distillation of the results of 230+ comments on #515, not to mention the 300+ comments spread across several other older issues that fed into that one. I know it's long. Please don't complain unless you can offer a shorter write-up. :-)

This does work, but as can be seen in the PR, it raised serious concerns over the maintainability of the resulting schema due to all of the duplication.

This issue is for discussing the use case given in the next section, and the unevaluatedProperties proposal to solve it. If you want to discuss a different use case or a different proposal, you MUST file your own issue to do so. Any comments attempting to revive other lines of discussion from #515, introduce new problems or solutions, or otherwise derail this discussion will be deleted to keep the focus clear. Please file a new issue and link back to this one instead.

As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins.

Also, some Specification constraints cannot be represented with the JSON Schema so it's highly recommended to employ other methods to ensure compliance.

Does this mean that the schema is available now since the bug is closed?

OK, I am really, truly, for real working on this next week. Stay tuned... and feel free to mock me if I don't get anything done

Changing OAS to placate JSON Schema validators is definitely a tail-wagging-the-dog scenario.

I found your unevaluatedProperties proposal while trying to understand what's the problem with JSON Schema for OAS 3.x. It looks like OAS 3.x would not have used x- properties if it had to produce a JSON Schema at release time. Now, you are trying to fix OAS 3.x idiosyncrasies by pushing a change to JSON Schema in a tail-wagging-the-dog move. This is fascinating ;-)

The difficulties of producing an OAS 3.0 spec without it helped validate that the keyword was needed, and not (as some claimed) a solution looking for a problem. The best feedback is always real-world usage.

It is very excited to see JSON Schema and OAS 3.0 Schema efforts collide in such a very constructive way. I look forward to seeing the results of your very appreciated effort!

Nobody expects the v3 schema to be more of a perfect guarantee than the v2 schema (as said above, consider operationId). Just release a schema and let the dice fall where they may.

trying to break a year-long (and counting) logjam.

I hate when one developer don't want to implement a wanted and useful feature because some other developer might "use it wrong" according to their own "dogma".

It is important to remain respectful even when through disagreement in the open source community.

my use of the schema would have nothing to do with validation but generating typescript definition and having more accurate code editor completion/suggestions.

One of the reasons I initially pushed back on the creation of a JSON Schema for V3 is because I feared that people would try to use it as a document validator. However, I was convinced by other TSC members that there were valid uses of a schema beyond validation.

the errors that you get from JSON schema can sometimes be very confusing. I wanted to be able to generate errors that could easily be understood to speed up debugging time.

Maybe one day, JSON Schema would be able to express all the constraints in the OpenAPI spec, but I suspect some are going to be really hard.

Release early, release often! One out of two won't be bad :-)

without a schema, you do not have a spec, you have an aspiration.

When we do release a final version of JSON Schema, please do not use JSON Schema to guarantee an OpenAPI document is valid. It cannot do that. There are numerous constraints in the written specification that cannot be expressed in JSON Schema.

To keep it regular, I'd like to avoid hand-edits to the schema as much as possible

I'd also love to see a JSON schema along with the specification. I don't really trust myself to be able to accurately read the spec in its entirely, so for 2.0 I fell back heavily on using the included schemas to verify that what I'm generating is actually intelligible (and it worked, they caught many problems).

I hope this doesn't seem too much like a content-free +1, but

it's syntactically correct, but it will check that none parameters are valid, just because additionalProperties work at siblings level, and no enter inside of allOf

What I want is to use "additionalProperties: false" to validate a union of schemas, but it seems it isn't possible. I already tried with sevaral different combination, but I didn't make it works.

additionalProperties: false works on it, but not along with allOf, because only validate one schema or another.

allOf takes an array of object definitions that are validated independently but together compose a single object.

The latest (draft 2020-12) version of JSON Schema supports the unevaluatedProperties vocabulary (see here). This is quite a useful feature, and facilitates stricter validation while composing properties from multiple sub-schemas (using e.g. allOf) than would otherwise possible.

OAS 3.1 uses all of JSON Schema draft 2020-12 including unevaluatedProperties. You won't find direct references to unevealuatedProperties in the OAS spec because it links to the JSON Schema spec instead of duplicating it's contents.

This object is a superset of the JSON Schema Specification Draft 2020-12.

JSONPath contains verbiage that allows for an empty array to be returned in the case that nothing was found, but the primary return in these cases is false.

I had not thought about whether dropping means "defined but empty" or "not present at all"

I have refactored the schema to use allOf, oneOf, and unevaluatedProperties, which not only dramatically shrank the file (1500 lines down to 845) but allowed a different approach consisting of a number of "mix-in" schemas grouping commonly used fields, which are then referenced throughout a set of object schemas.

Multiple different people have been discussing multiple different problems, and asking for examples of the other problems, talking past each other and generally this thread got to an unreadable point due to this confusion.

The discussion here can get very fast-paced. I am trying to periodically pause it to allow new folks, or people who don't have quite as much time, to catch up. Please feel free to comment requesting such a pause if you would like to contribute but are having trouble following it all.