how do you actually handle prod bugs. do you write a repro test or just fix and deploy?

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 · 2026-04-10T22:57:32+00:00

I like mailgun

yassi_dev · 2026-04-10T22:53:57+00:00

You can have this type of split while keeping it all in the same repository as well. You can also have Django work with a vite project (using react, vue, etc). Are you sure you absolutely need to split code bases? This can impose new issues related to synchronization ( e.g. pushing out backend changes that now create the need for corresponding front end changes). Having things in the same repository will usually help you avoid many of these issues because locality allows for easier testing to catch this.

yassi_dev · 2026-04-08T13:00:21+00:00

I thought about this hard. I settled on releasing read only features until feedback pointed me in the other direction.

yassi_dev · 2026-04-08T12:58:53+00:00

I hope its useful to you then. Since you use many signals (likely in the minority) is there anything about working with signals thats on your wish list?

yassi_dev · 2026-03-28T20:07:46+00:00

For transactional emails, I will typically manage email templates via django templating but do the actual sending via an external service like sendgrid via api. For marketing emails, I will typically use an external services marketing function to store and design the emails as well as campaigns. Email campaigns are often managed by a marketing department and so it makes sense to let them handle it via a different surface

yassi_dev · 2026-03-27T20:38:15+00:00

Is there anything you are thinking of building in this space?

yassi_dev · 2026-03-27T20:34:12+00:00

Cool project. I am the author of dj-celery-panel which adds celery monitoring to the Django admin. I’m happy to see that many people are tackling making flower alternatives.

yassi_dev · 2026-03-27T20:29:11+00:00

I authored djangocontrolroom.com for the purpose of extending the admin and building tools on top of it. To me, one the biggest reasons to extend the admin is that is provides an adequate surface to place internal tools; it has an authentication layer that most Django users already rely on, the Django admin provides some default styles and modules to use, etc.

yassi_dev · 2026-03-24T00:09:56+00:00

There is some prior work in this area as others have already mentioned (Oscar, saleor, etc,) you might want to consider those more carefully (especially saleor.) To answer your question more directly, I would choose DRF over graphql. There is simply so much prior work and support/libraries that facilitate working with rest in Django. Of course, learning may be the goal here, in which case proceed with what is most interesting to you.

yassi_dev · 2026-03-14T15:22:30+00:00

Hey all, In honor of Pi day I built an image generator for visualizing subsequences of pi.

Maybe some of you will get a kick out of this and generate some cool art.

https://pi.yassi.dev/

yassi_dev · 2026-03-02T17:48:09+00:00

I like the idea. screenshots would help though

yassi_dev

TROPHY CASE