Skip to content

Instantly share code, notes, and snippets.

@icook

icook/notes.md

Last active October 23, 2018 18:10
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save icook/94d83238a9a5bccebad489b45b298ec7 to your computer and use it in GitHub Desktop.
Save icook/94d83238a9a5bccebad489b45b298ec7 to your computer and use it in GitHub Desktop.
Download ZIP
Bismuth Notes
Raw
notes.md

These are just general thoughts I've had as I read through Bismuth, get familiar etc.

  1. WIP code not intended for production use should be developed on its own branch as to not polute the codebase.
  2. Old deprected no longer used code should be removed. It's always in the git history if you need it in the future.
  3. Scripts should probably be in their own subfolder, with a clear opening comment about their intended use case
  4. Ideally the core would be made into actual installable module (w/ setup.py), and dice, explorer etc setup as co-modules (ie, bismuth.explorer, bismuth.core). This could still be done in the same repo. This would be very helpful for integrators since right now it's difficult to import for instance keys.py methods to use in my own scripts unless I put my code in the root directory as well.
  5. There shouldn't be potentially executable code (.py) in static/ folder. Not a big deal.
  6. All node persistence data should be stored in a dedicated folder making it easy to purge (reset) or backup/sync. I'm sure there's a reason for it being put in static/, but it muddies the waters on what is ephemeral/git tracked, etc.
  7. The config file should have some comments. See postgres's config for a great example.
  8. I would prefer to see proper logging used. Ideally there would be no print usage. Levels and module labels are extremely useful for debugging complicated issues in large codebases.
  9. In a perfect world node.py would be refactored into a self contained class. This would allow easier network simulation testing, etc.
  10. Moving towards pep8 compliance would be good. imports are the most negative violation that I see. Some lines are excessibvely long and difficult to read.
  11. There's a lot of code duplication I see. Ideally classes for major groups of functionality would allow better re-use. For instance, keys.py and essentials.py seem to have very similar functionality.

I think this project is really cool, and I would love to see it become easier to work with and better documented to encourage growth of the developer community that has already grown around it. Addressing some of these issues should help push it in that direction.

Missing things that I will need in some shape or form:

  1. Working Dockerfile
  2. Settable config values from Env variables
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment