Discover what Django can do.

Pinry: who can see a board?

Explore Pinry's project listing, then trace how its image-board API selects boards for the current user.

1. Open core/views.py. Find the boards router registration and BoardViewSet.get_queryset().
2. Follow filter_private_board() into core/serializers.py. Compare the authenticated and anonymous branches. Which boards does each exclude?
3. Read the private-board cases in core/tests/api.py. Check the signed-in user and assertions, not just each test's name.

Baby Buddy: follow a note request

Explore Baby Buddy's project listing, then follow its note list and add pages through familiar Django building blocks.

1. Find notes/ and notes/add/ in core/urls.py.
2. Open core/views.py at NoteList and NoteAdd. Follow their base classes; compare the model, form, permission, and success URL settings.
3. Read test_note_views() in core/tests/tests_views.py. Which requests and responses does it check?

Healthchecks: can HTTP 200 mean a failed job?

In Healthchecks' explicit failure-ping test, HTTP 200 acknowledges the request while the check becomes down. Explore Healthchecks' project listing, then trace that distinction in the code. No live monitoring endpoint is needed.

1. Find uuid_urls in hc/api/urls.py. The empty path and fail both call views.ping; what extra argument does the failure route supply?
2. Read ping() in hc/api/views.py, then Check.ping() in hc/api/models.py. Follow action to the model's status change, then return to the view's HTTP response.
3. Compare the response-code and check-status assertions in test_fail_endpoint_works() in hc/api/tests/test_ping.py: the response is 200, but the check is down. Why would checking only the response code miss the behavior?

Reading challenge: identify the recorded ping kind and status-flip reason in that same test. These assertions cover the explicit failure request; they do not prove an alert was delivered or cover every check configuration.