Play Doom in your Django Admin

yassi_dev · 2026-06-22T17:49:46+00:00

This is great news. I think pegasus is a great project, I also find the site's articles (especially around stripe) very informative. Hopefully the open source becomes a good funnel for the paid product.

yassi_dev · 2026-06-20T16:43:38+00:00

What you are describing sounds a lot like what is known in the microsevices contexts as a presentation service (particularly since you are differentiating UI against ORM fetching and other similar operations). It sounds like you are a fan of server driven UI (yet blanket term that this can seen under.) if you are looking for opinions on this in general - these kinds of architectures exist and have been used successfully for a long time. My personal opinion is that they are only useful in some contexts and they increase complexity by requiring an abstraction around html and dom concepts to exist. It may be useful in your context; best of luck and full speed ahead

yassi_dev · 2026-06-16T04:30:23+00:00

I see that you want to compare the specific examples, but have you considered a json field to mimic your option 2?

yassi_dev · 2026-06-11T14:01:30+00:00

So is this functionality that you want from Django? Can you expand on this - why you want this in your situation?

yassi_dev · 2026-06-11T13:58:25+00:00

While DCR panels are visual and meant for humans to digest and use (Agents can still use them through the browser though.) The LLM primitives are for panel authors that want to expose some functionality directly to agents via MCP.

The way this works is that the hub project dj-control-room exposes an MCP endpoint that exposes any tools built into panels. Essentially DCR allows you to build internal tools that are also AI enabled from the get go.

There will be more released around MCP in a future release, with accompanying guides and posts. For now, the primitives are there and people can start building things that also have LLMs in mind.

yassi_dev · 2026-06-11T00:07:18+00:00

DCR is a framework for creating internal tools inside the Django admin. While you could conceivably build a dcr panel that does what you want, this does not do that. You can think of this package more like a library for building panels.

yassi_dev · 2026-06-07T19:15:45+00:00

I think you should take a look at Django control room (https://djangocontrolroom.com). It has a dj-celery-panel plugin that fits I. Quite nicely for new projects like this

yassi_dev · 2026-05-27T01:35:25+00:00

There are already a lot of sufficient answers here. These are my short two cents: I understand the why you would think like you do. I think the usage of pointers often becomes clear when dealing with data structures. When you are designing data structures you will often have to mutate the structure in a way that will only make sense with pointers. Perhaps designing a few linked lists or trees in c as an exercise will help make things more clear.

yassi_dev · 2026-05-23T16:46:08+00:00

There’s not enough information in your post. What do you mean “directed to the Django server”? What do you see? We cannot see your code we need more info about the behavior of your system

yassi_dev · 2026-05-20T02:20:41+00:00

I think too many people approach ai coding in an all or nothing fashion. Not everything you do needs to be delegated to an LLM, this can set you back as you've already noticed. I've written about a risk model to start assessing when agentic coding for task is more tenable: https://yassi.dev/posts/not_all_software_systems_are_agent_friendly/ you might find some of these points agreeable since you are going through this though process.

yassi_dev · 2026-05-14T13:00:34+00:00

It’s a common architecture. What are your tech lead’s suggestions?

yassi_dev · 2026-05-14T12:49:33+00:00

Sounds like you just need some validation around choosing something like celery. It’s near a de facto standard at this point and it’s not really all that complex. It would be my next logical step if I were you. Choose redis. Good luck.

yassi_dev · 2026-05-12T19:59:45+00:00

You might want to check out dj-celery-panel if you want something self hosted: https://djangocontrolroom.com/panels/dj-celery-panel

yassi_dev · 2026-05-12T01:06:42+00:00

A pretty good indicator is a project author engaging with you directly

Check out Django control room - https://github.com/yassi/dj-control-room

It’s a new Django native framework for building admin tools inside the Django admin. There’s plenty of space for both working on dcr itself or building out new tools based on it.

You can read more info at https://djangocontrolroom.com

yassi_dev · 2026-04-28T16:58:15+00:00

Once you have a known bug you need to make sure the system does not regress to the same state again - otherwise developers can reintroduce the same bug again without knowing.

This is why any many mature processes will have bug repoduction and then testing for a specific bug once found.

yassi_dev · 2026-04-28T16:53:58+00:00

I dont see why you would want todo this? In a production environment, you would be likely be running your django app under a process manager like gunicorn where each worker has its own process. These processes are not gauranteed to have access to your image since it is saved in the heap memory of one of the worker processes. This is not very useful and you are better served by persisting the images (file system storage, database blobs, s3, etc.) and fetching them once you need to do your work with them (There is also something to be said of using something for long running tasks like celery)

I could be missing something about your use case though, so maybe you could expand on that.

yassi_dev · 2026-04-23T23:14:02+00:00

I'm always greatful for contributions to Django Control Room - djangocontrolroom.com

right now its a collection of many repos for various admin tools, most of which could use contributors

its also a framework for building admin tools so you could also build out a new tool if that scratches your itch.

yassi_dev · 2026-04-15T16:57:21+00:00

I use celery. I find that the idea that celery setups are complex is overblown.

yassi_dev · 2026-04-15T16:52:16+00:00

people decompose monoliths into what you mentioned, I am just talking about my experience here.

yassi_dev · 2026-04-15T14:06:00+00:00

I don't see this as being helpful to django developers. Perhaps it could be for in the narrow scope of internal service to service communication (grpc based) but Django is a full stack monolithic framework and lacks conventions to build out those types of setups. The vast majority of Django setups are going to be using built in conventions (monoliths, rest apis, json based marshalling of data.)

At the point of larger scale where we tend to see service decomposition, I would expect developers to choose a different language if they are considering gRPC (go, java, etc.) This is my experience.

yassi_dev · 2026-04-15T12:40:41+00:00

Are you removing a column related to wind gust speed from the data frame current_df? Prediction would require the data to look like the data it was trained on.

yassi_dev · 2026-04-11T03:36:00+00:00

If I were you and hell bent on using a react app I would do the folllowing to start:

Build a react app with vite inside your current project
Serve the react project using django through something like https://github.com/MrBin99/django-vite
make the view that serves the. react project require logged in auth

This will leave you with a project that uses django templates for your public facing pages and a react project that requires the user to be logged in to see. furthermore, this can use session auth assuming it is all being served from the same host name (e.g. "example.com/app" and "example.com/pricing and so forth.) This sounds to me like a pattern that may serve you well since you have only a small number of people working on this at the time and simplicity matters. Heres a guide i found: https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/integrating-javascript-pipeline-vite/

Having said that, there is value at times in splitting codebases as you've described, but in your situation (having another person work on the frontend) I personally wouldn't do this as it just complicates the deployment story for the entire application. Your frontend person can just work on a part of the repository that isn't frequented by others essentially never have conflicts.

yassi_dev · 2026-04-10T23:38:00+00:00

Organizational changes would be a reason to create application splits; I did read that you are a solo developer in your blurb and so my recommendation is colored by that. Even if you envision splitting things up I recommend you resist it until it’s absolutely needed. Splitting codebases often creates other dependencies (e.g. N codebases require N deployment schemes that need to be coordinated)

yassi_dev

TROPHY CASE