Repository navigation
Antora Documentation for Event Sourcing #14
Description
Activity
I expect it to be on the repo as suggested by Peter. I don't know yet how it will work to be separated from the main repository and how/if it gets integrated into the main documentation.
Yes, would be good to have the docs in each repo. There are some things to set up for this. I expect that we'll start with something simple, where each language support can publish docs into the main site as needed (it won't be one navigation tree for the docs though, separate doc sites, like for akka modules). I'll try to make some progress this week. For now, feel free to just add into the main documentation, and then we move later.
Reacted by Marcel LanzPR #35 adds a starting point to have user documentation within the user language support.
- linked a pull request that will close this issueAdd setup for building and publishing docs #35
on Jun 2, 2020 @marcellanz should I pick this to complete the documentation? Or are you working on it?
@chomnoue please pick it and use it. I do not work on it right now and I hve no progress othr than I merged Peters PR. Thanks for picking it up :)
9 remaining items
Thank you for your feedback and insights. I'm looking forward to catching up with the talk once online.
While using that many blank lines between definitions seem to be normal by the "PEP 8 -- Style Guide for Python Code":
Surround top-level function and class definitions with two blank lines.
and even more blank lines can be used sometimes, the non-intended members are no members at all, and I have to ask @sleipnir or @chomnoue why the shopping cart is implemented that way.
Hi! @marcellanz @sean-walsh As the extra lines can be used sparingly to separate logical associations, I think that was an intention. But we can remove and work with just a blank line to return functions.
Marcel, I'm going to take a look at the documentation branch and try to continue from there. Obviously we will review together, the more reviewers the better
If the blank lines represent the normal convention it's fine.
I vote to remove them
I'd vote to retain them.
Linters (pycodestyle, pep8) and as an example PyCharm by default use 2 blanklines between top-level functions. Why would we remove them when it's recommended by the python style guide?
If we mandate any formatting and style by th eproject, I'd propose to add a formatter/linter that formats the code, same as we use
scalafmtorgo fmt. We'd have to argue a good case for deviating from PEP8 or anything settled as a standard I think.(this is one thing I really like with Go, there is no discussion when it comes to formatting Go code :), not that I dislike any discussions about style)
> pycodestyle shopping_cart_entity.py ... shopping_cart_entity.py:81:1: E302 expected 2 blank lines, found 1 ... >
- I think each example should be idiomatic for its language. Formatting included. -- Cheers, √
I'd vote to retain them.
Linters (pycodestyle, pep8) and as an example PyCharm by default use 2 blanklines between top-level functions. Why would we remove them when it's recommended by the python style guide?
If we mandate any formatting and style by th eproject, I'd propose to add a formatter/linter that formats the code, same as we use
scalafmtorgo fmt. We'd have to argue a good case for deviating from PEP8 or anything settled as a standard I think.(this is one thing I really like with Go, there is no discussion when it comes to formatting Go code :), not that I dislike any discussions about style)
> pycodestyle shopping_cart_entity.py ... shopping_cart_entity.py:81:1: E302 expected 2 blank lines, found 1 ... >
I thought you were referring to the spaces at the end of the functions
We might have misunderstood each other :)
We speak about the "two blank lines" surrounding top-level function and class definitions IMO.
shopping_cart_entity.pyhas no other blank/whitespace lines I think?Lines 73 and 74, and 80 and 81 here:
Okay. If we use an appropriate formatting tool this will not be a problem anymore.
@sean-walsh @sleipnir @chomnoue the video of Seans' EuroPython 2020 talk dropped today: https://youtu.be/Swl9tUnGGGE?t=6695 Cool stuff :)
@sleipnir can you remember why handlers were implemented as non-member functions. see also #14 (comment) above.
- changed the title
[-]Paradox Documentation for Event Sourcing [/-][+]Antora Documentation for Event Sourcing [/+]on Oct 16, 2020
