deploy: fab68f3

.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 46421a9d75358c648baa084ccfcd7b60
+tags: 645f666f9bcd5a90fca523b33c5a78b7

CNAME

@@ -0,0 +1 @@
+falco.oluwatobi.dev

_sources/changelog.rst.txt

@@ -0,0 +1,9 @@
+:description: falco release history
+
+Changelog
+=========
+
+.. changelog::
+    :changelog-url: https://github.com/Tobi-De/falco/releases
+    :github: https://github.com/Tobi-De/falco/releases
+    :pypi: https://pypi.org/project/falco-cli/

_sources/codeofconduct.rst.txt

@@ -0,0 +1,5 @@
+Code of Conduct
+===============
+
+.. include:: ../CODE_OF_CONDUCT.md
+   :parser: myst_parser.sphinx_

_sources/contributing.rst.txt

@@ -0,0 +1,136 @@
+============
+Contributing
+============
+
+Contributions are welcome, and they are greatly appreciated! Every little bit
+helps, and credit will always be given.
+
+You can contribute in many ways:
+
+
+The Guides
+----------
+
+Contributions to the guides should be made via `GitHub Discussions <https://github.com/Tobi-De/falco/discussions>`_. Any
+contribution is welcome, even for typos and grammatical errors. If a contribution requires a complete rewrite of a section or
+an entire guide, or adds new insights (similar to an article review), proper credits will be given at the bottom of the relevant guide.
+I will not accept any pull request that directly changes a guide without prior discussion on the topic, except for minor typo fixes.
+
+
+The CLI
+-------
+
+Contributions to the CLI are more open. You can fix issues, suggest new commands, or propose improvements to existing ones.
+
+Types of Contributions
+^^^^^^^^^^^^^^^^^^^^^^
+
+Report Bugs
+***********
+
+Report bugs at https://github.com/Tobi-De/falco/issues.
+
+If you are reporting a bug, please include:
+
+* Your operating system name and version.
+* Any details about your local setup that might be helpful in troubleshooting.
+* Detailed steps to reproduce the bug.
+
+Fix Bugs
+********
+
+Look through the GitHub issues for bugs. Anything tagged with "bug" and "help
+wanted" is open to whoever wants to implement it.
+
+Implement Features
+******************
+
+Look through the GitHub issues for features. Anything tagged with "enhancement"
+and "help wanted" is open to whoever wants to implement it.
+
+Write Documentation
+*******************
+
+falco could always use more documentation, whether as part of the
+official falco docs, in docstrings, or even on the web in blog posts,
+articles, and such.
+
+Submit Feedback
+***************
+
+The best way to send feedback is to file an issue at https://github.com/Tobi-De/falco/issues.
+
+If you are proposing a feature:
+
+* Explain in detail how it would work.
+* Keep the scope as narrow as possible, to make it easier to implement.
+* Remember that this is a volunteer-driven project, and that contributions
+  are welcome :)
+
+Get Started!
+^^^^^^^^^^^^
+
+Ready to contribute? Here's how to set up `falco` for local development.
+
+1. Fork the `falco` repo on GitHub.
+2. Clone your fork locally::
+
+    $ git clone git@github.com:your_name_here/falco.git --recurse-submodules
+
+3. Install your local copy into a virtualenv. Assuming you have hatch installed, this is how you set up your fork for local development::
+
+    $ cd falco/
+    $ hatch env create
+
+4. Create a branch for local development::
+
+    $ git checkout -b name-of-your-bugfix-or-feature
+
+   Now you can make your changes locally.
+
+4. Install pre-commit hooks for linting and code formatting before every commit::
+
+    $ pre-commit install
+
+5. When you're done making changes, check that your changes pass tests including testing other Python versions::
+
+    $ hatch run test
+
+6. Commit your changes and push your branch to GitHub::
+
+    $ git add .
+    $ git commit -m "Your detailed description of your changes."
+    $ git push origin name-of-your-bugfix-or-feature
+
+7. Submit a pull request through the GitHub website.
+
+Pull Request Guidelines
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Before you submit a pull request, check that it meets these guidelines:
+
+1. The pull request should include tests.
+2. If the pull request adds functionality, the docs should be updated. Add the
+   feature to the list in README.md.
+3. The pull request should work for Python 3.10, 3.11 and 3.12. Check
+   https://github.com/Tobi-De/falco/pulls
+   and make sure that the tests pass for all supported Python versions.
+
+Tips
+^^^^
+
+To run a subset of tests::
+
+$ pytest tests/commands/test_htmx.py
+
+
+Deploying
+^^^^^^^^^
+
+A reminder for the maintainers on how to deploy.
+Make sure all your changes are committed (including an entry in HISTORY.rst).
+Then run::
+
+$ hatch version patch # possible: major / minor / patch
+$ git push
+$ git push --tags

_sources/guides/avoiding_god_models.rst.txt

@@ -0,0 +1,14 @@
+:image: https://raw.githubusercontent.com/Tobi-De/falco/main/assets/falco-logo.svg
+:description: A guide on how to avoid the god object or god class anti-pattern and organize your business logic in django.
+
+Business logic in django
+========================
+
+.. warning::
+
+    Work in progress. To receive updates `subscribe to this discussion <https://github.com/Tobi-De/falco/discussions/39>`_ or
+    follow me on `x <https://twitter.com/tobidegnon>`_ or `mastodon <https://fosstodon.org/@tobide>`_.
+
+
+Proxy models
+------------

_sources/guides/database_tips.rst.txt

@@ -0,0 +1,58 @@
+:image: https://raw.githubusercontent.com/Tobi-De/falco/main/assets/falco-logo.svg
+:description: A guide on some common database pattern and strategies and how to use them with django.
+
+Database Tips: Backup, Scaling, Triggers, and More
+==================================================
+
+.. warning::
+
+    Work in progress. To receive updates `subscribe to this discussion <https://github.com/Tobi-De/falco/discussions/39>`_ or
+    follow me on `x <https://twitter.com/tobidegnon>`_ or `mastodon <https://fosstodon.org/@tobide>`_.
+
+django-pgtriggers
+-----------------
+
+Database backup
+---------------
+
+Whenever possible, take advantage of a fully managed database solution, they usually offer automatic backup of your databases.
+In my opinion, this is the best option if you don’t want to deal with the hassle of managing your own database.
+
+-  `Amazon RDS <https://aws.amazon.com/rds/>`__
+-  `Linode Managed Databases <https://www.linode.com/products/databases/>`__
+-  `DigitalOcean Managed Databases <https://www.digitalocean.com/products/managed-databases>`__
+-  `Heroku postgres <https://www.heroku.com/postgres>`__
+
+For specific postgresql options, see their `hosting support page <https://www.postgresql.org/support/professional_hosting/>`__.
+
+However, if for some reason you want / need to manage your database yourself and just want an automatic backup solution
+then `django-dbbackup <https://github.com/jazzband/django-dbbackup>`__ is what you need. You can use one of the scheduling
+packages discussed above to periodically run the backup command.
+
+Scaling strategies
+------------------
+
+This is mostly a buzzword, people use that term to represent an app that can handle thousands or millions of requests per second.
+Scalability is a problem you want to have (that means you've made it), but people are out there solving scalability issues for
+apps that have not even been shipped, like a `classic chicken and egg <https://en.wikipedia.org/wiki/Chicken_or_the_egg>`_ problem.
+I don't have enough personal experience here to give good advice, but I'll try to provide some pointers based on what I've read and
+the little experience I have (apps I've seen even if I haven't worked on them).
+I put this section here (in the databases guide) because it seems that more often than not, the database is the bottleneck, or at least
+before Django or Python become a bottleneck for you, your database will be the first to become a bottleneck. Maybe not the database itself at
+first, but how you access it and how your queries are written. For more on that, check out the `database optimization section </guides/optimizing_database_access.html>`__.
+Both of these sections are complementary.
+
+For most of these strategies, I'll assume you are using PostgreSQL because that's what I know best, but most of these strategies can be applied to other databases.
+
+
+Offload work from the database
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Table partitionning
+^^^^^^^^^^^^^^^^^^^
+
+Read replicas
+^^^^^^^^^^^^^
+
+Sharding
+^^^^^^^^