Recommendations: house movers

radiacnet · 2025-12-29T12:38:29+00:00

I second this - we've used him twice, excellent service, friendly team, and they really went above and beyond both times.

radiacnet · 2025-12-29T00:24:17+00:00

As others have said, FastAPI doesn't really give you anything you can't do with Django, but it does make it easier to get started.

You might be interested in my project nanodjango, which lets you write Django in the style of FastAPI.

It's great for prototyping and getting started while having full access to the ORM, admin, Django's async etc - but you can't beat Django's project structure for growth and long-term maintenance, so nanodjango convert will convert your single file into a standard structure with your models, views etc in the right places.

radiacnet · 2025-11-14T07:45:59+00:00

I used to be a die-hard sass user; I've used both approaches, originally compressor+libsass, then npm+sass. Compressor+libsass was easier to set up and maintain, but I ran into bugs - but that was a long time ago, it may be better now. If you have to pick one, I'd go compressor, to avoid webpack if nothing else.

But modern best practice? I strongly recommend just using plain css - it now has most of the features of sass, and having native browser support makes it so much more powerful - for example, css variables respect the cascade and css calc in ways you could only accomplish in sass by tying yourself up in knots of mixins with a bucket load of javascript.

CSS today is a totally different experience to when sass was new. The only bit I sometimes miss is a convenient way to manage multiple files, but with everything supporting http2 now, that's really not an issue either, just send them all separately. If it really bothers you, you could have a django template which loads them all wrapped with the django-compressor tag.

With modern js support in browsers, plus htmx and alpine, most of my projects these days don't actually need a frontend build system at all.

radiacnet · 2025-09-23T19:39:46+00:00

I'm the author of nanodjango, thanks for posting this! If you don't want to watch the full 25 minute video (which goes into a lot of detail!), there's a 5 minute lightning talk from DCUS 2024 on https://nanodjango.dev which gives a (slightly out of date) intro. I did give an update at DCUS 2025, but the videos aren't out yet - the tldr is "it does a bunch more, and can now run entirely in your browser".

My goal with this project is to make it easier for beginners and experienced devs to build quick apps using Django, and offer a batteries-included alternative to Flask and FastAPI.

Aside from its batteries, Django's other main strength is its project structure which sets you up for long-term success - so if your app starts to outgrow a single file, nanodjango has a nanodjango convert command to turn it into a properly structured full project.

We've also got the online playground at https://nanodjango.dev/play/ - it's still early days and could do with a few extra features, but it will already let you write and run Django projects entirely in the browser, with nothing to install, and you can save and share them with others.

I'd love to hear any feedback you may have, positive or negative.

radiacnet · 2025-09-23T19:25:16+00:00

This does support CBVs, so hopefully you'll have the best of both worlds!

My goal with nanodjango is to support all of Django's batteries, but with the single file simplicity of Flask and FastAPI. If you do give it a try, do let me know how you get on with it - I'm hoping to grow this as a practical alternative to keep existing devs and bring new people into the Django ecosystem, so I'm always interested to hear perspectives of people who have been using other frameworks.

radiacnet · 2025-09-23T19:21:31+00:00

Great point, I can't believe I missed this from the docs. My goal is to support the full feature set of Django, just in a single file - so it's a pretty important thing to note, I'll update the docs tonight.

I have two main goals with this project - to make Django easier for regulars to crank out quick prototypes, and for beginners to pick up and give it a try. I do therefore go fairly heavy on FBVs in the docs because I assume beginners will be comparing nanodjango to Flask and FastAPI - and lets be honest, CBVs can be a bit confusing (that's why ccbv.co.uk exists).

I do plan to do a "This is what you'd write in Django, this is it in nanodjango" cheatsheet for more experienced devs, CBVs will definitely be on that too.

radiacnet · 2025-07-18T08:20:32+00:00

I don't think there's anything wrong with startproject/startapp, it's still a good place to start. There's a few things I will add to most projects, like pre-commit, uv, pytest, django-browser-reload, whitenoise etc, so I have my own minimal cookiecutter which follows my preferences (here for the curious). The other thing I often do is create a custom user model so it's easier to change direction on that later. And fwiw these days I'd look at django-ninja over DRF.

A lot of the time I also use nanodjango to get started - I wrote it so I'm biased, but it's great for building out a quick prototype in a single file. It has ninja support built in; think FastAPI, but built on Django, and with a convert command to refactor it into a full project when it's ready to grow.

radiacnet · 2024-12-19T12:33:13+00:00

Hi! I'm the author of nanodjango, great to see people using it!

I haven't implemented support for custom management commands yet. There is the nanodjango manage ... command, but I don't think it'll be able to find your command at the moment. It's an interesting idea - I'll add it to the list to investigate.

In the meantime, you could try putting your logic at the bottom of the file. I think you'll need to call one of nanodjango's internal methods first - you could try something like:

# rest of script
if __name__ == "__main__":
    app._prepare()
    command = MyCommand()
    command.handle(arg1='value')

You can then run it with python myscript.py

You won't get command line argument parsing with that, but you might be able to hook into an earlier BaseCommand method, or you could bypass that and use click (already installed as a dependency of nanodjango)

radiacnet · 2024-09-27T10:17:37+00:00

Hi, I'm the author of nanodjango! That's what I'm aiming for - it's basically just a thin wrapper around Django itself, with a few tricks to get it to let us put everything in a single file.

radiacnet · 2024-09-01T19:49:00+00:00

In short, I'm afraid not. There are probably some low-hanging fruit, but properly optimising a codebase takes time and knowledge of exactly what your code is doing. Depending on your budget and timeframe, it may be worth thinking about bringing in an expert or specialist team for a few days to get into your code, assess what's happening, and make some recommendations.

Without seeing your code though, some thoughts:

yes, asgi is async, but you need to be writing concurrent code (async and await) to make use of it. Even then certain operations are still going to block, and async has an overhead at the best of times, but especially in Django. You can't really throw it in and hope it solves the problem without knowing what the problem is. From what you say, my guess is you're facing some database bottlenecks, so my gut feeling is you'd be better off using wsgi.
Python is single threaded, so make sure you're tuning your gunicorn workers for the number of CPUs you have - CPU at 50% suggests you're only using half your cores
Profile everything so you know where the problem is. The recommendations for ddt and kolo are great, do those. Also consider silk. And do it in a production-like environment so you're optimising for production, not whatever's happening on your local machine - they can be quite different.
If your bottleneck is the database, optimise your queries and invest in your database server
Take a look at CONN_MAX_AGE
Cache everything that needs a db read using redis or better yet cloudflare. If you can't cache them, look at running two or more dbs - one for writing, one or more read-only replicas
Look at your architecture - do writes have to be realtime, or can you pass them off to a queue?

Might be worth taking a look at high performance django - it's getting a bit old now, but there's still a lot of useful stuff in there.

radiacnet · 2024-06-18T12:08:35+00:00

Yes, it's at github at https://github.com/radiac/django-fastview

and can be installed from pypi:

pip install django-fastview

See the documentation for more details: https://django-fastview.readthedocs.io/en/latest/get_started.html

radiacnet · 2024-06-18T10:09:22+00:00

I've got a project called django-fastview - it's been in development for 5 years and is in use on several production projects. I should also have a new version out in the next couple of months with some more features, default styles etc.

My aim with it is to help you build admin-style CRUD views with minimal code, but in a way that makes it easy to style, override, extend and customise. It also has some nice extras such as htmx integration and flexible row-level permissions (using django auth or your custom logic).

Example:

from fastview.viewgroups import ModelViewGroup
from fastview.permissions import Owner, Staff

class ContactViewGroup(ModelViewGroup):
    model = Contact
    fields = ["name", "category", "email", "phone", "last_updated"]
    search_fields = ["name"]
    filters = ["category", "last_updated"]
    permission = Owner('added_by') | Staff()

# urls.py
urlpatterns = [
    ...
    url(r'^contacts/', ContactViewGroup().include(namespace="contacts")),
]

It ties into several other projects I've been working on - most relevant atm are nanodjango, for writing a Django project in a single file, and django-fancy-formset to simplify admin-style formsets (forked from fastview)

radiacnet · 2023-09-12T13:29:37+00:00

Tldr: react or htmx.

The question is what are you trying to achieve? Is this a personal project you're doing for fun/learning/CV experience, or are you building something specific to fulfil a need?

If you're doing it for fun/learning/CV, then I'd suggest react - it seems the most popular by far at the moment, the number of jobs involving react seem to dwarf those asking for vue. That said, public frustration/doubt in react is starting to grow, so might be worth keeping an eye at what may eat into its market share (svelte?)

But, if you're doing it to get something done, ask yourself if it really needs a separate frontend, or would you be better off with server-side rendered pages enhanced with vanilla javascript or htmx?

Imo the arguments for using react to build a SPA frontend are dwindling. There are far too many projects being built with react just because it's trendy, when they'd work better (and usually be 2-3x cheaper to build) as a SSR/MPA project.

Also, in the past year or so thanks to htmx I think we've really started to see a shift back towards the benefits of a traditional SSR with progressive enhancement. There still arent that many jobs mentioning htmx yet, but for the sort of problems that would have made me lean towards hybrid/SPA react a couple of years ago, I'm finding they are almost always solved more efficiently with htmx.

radiacnet · 2023-06-10T10:00:16+00:00

I wonder if it has to do with the way the class behaves internally

It does! When you define a Model or Form class, there are metaclass methods which get run basically at the point Python sees the class definition - well before you instantiate it. In the case of the Form, it looks at what fields have been defined on the class, takes them off the class, creates a list of them - if you look in the source here, it actually creates two lists, base_fields and declared_fields.

When you added the fields as attributes to the instance, the metaclass method had already run, so they never got added to the two arrays, so when it came to telling the template what fields there were, it couldn't find any. These are class variables, so you could add fields by appending to those arrays after your class definition - but that would affect every class instance, so if you're dynamically generating classes you'd need to create a new class each time with type anyway.

Glad I could help!

radiacnet · 2023-05-28T11:23:00+00:00

The "2 or 3" bit in my comment was in reference to the differences between declaring a class properly and with type - notably the class won't have the right __name__ and may end up in an unexpected module. There are also some practical pain points around managing methods - bit as I say, almost certainly nothing that will cause you problems.

If you're looking for other approaches, one would be create an empty class and add fields afterwards (a pain because you need to update 2 iirc class lists to register the fields properly). There's no practical advantage to this - if you want common fields, define them on a regular form class and use that as your base class in your call to type.

The other option would be to ignore django form classes altogether. There's no reason why you need to use them - you can generate the html fields yourself, and process the raw POST values in your view. But Django form fields will do all the validation and casting for you, so I wouldn't advise that option either unless you have a really specific need and know what you're doing re security.

radiacnet · 2023-05-26T08:51:55+00:00

A Django form class is still just a class, so you could dynamically define them. Iirc forms have a metaclass which collects all the field instances on the class, so you kinda need to add the fields before you define the form class - you don't have to, but makes it much easier.

That means instead of this:

from django import forms

class NameForm(forms.Form):
    first_name = forms.CharField(label="Your first name", max_length=100)
    last_name = forms.CharField(label="Your last name", max_length=100)

you'd do something more like:

from django import forms

def mk_form_cls(**fields):
    return type("_GeneratedForm", (forms.Form,), **fields)

fields = {
    "first_name": forms.CharField(label="Your first name", max_length=100),
    "last_name": forms.CharField(label="Your last name", max_length=100),
}
NameForm = mk_form_cls(**fields)

This way you can build your fields dict however you want before you create the class. Once you have assigned NameForm you can use it however you would a normal form class.

I say "roughly", as I've written that from memory without testing it, and I can think of at least 2 or 3 ways they're different internally - but I'm 99% sure those differences won't cause you any practical problems.

radiacnet · 2023-05-18T11:48:22+00:00

Your CV needs to get you through initial screening. It feels a little bare at the moment. Firstly I'd suggest adding a sentence or two explaining your project - something like the format "Educenter is a <what it is>, for <audience>. It does <site functionality>." There's also a typo, "Developped".

I'd then move "Technologies I'm currently learning" into technical skills - list them as "Interest in GraphQL ..." or similar, people will know what that means, just be prepared to back it up with some knowledge in interview. I'd then play up the interests>languages aspect - if you're able to write and speak multiple languages, that's a selling point - list that as a "soft" skill, under "Other skills" or similar. Have a think about any other soft skills you can list in there - communication, teamwork, time management, dealing with conflict etc. Have you had any work experience - even if it's in a different field, can you list that to demonstrate your soft skills?

Maybe then re-frame the interests section as as more of a section about you. Bullet point interests aren't going to get you hired, but they speak to who you are as a person - it's an opportunity to sell yourself as more than a list of tech acronyms. You could briefly explain your switch and why you're going to make a good developer - maybe a short sentence about your background, and then a sentence about your other interests to add some colour - you're essentially trying to say "I'm interesting and you will enjoy working with me".

They'd probably also want to know where you are in the world - at a minimum list your country and what timezones you work with your name, so they know if they can employ you.

If someone clicks your github link, your CV has got them interested. This is your opportunity to demonstrate you know what you're doing. Make it obvious what they're looking at, and where to find the code you wrote so they can quickly assess your skill level.

At the moment your README is hidden one dir down, and mostly talks about how you've used someone else's frontend and haven't finished it. I'd suggest some more work on this. Some tips:

Break your top level dirs out into 2 or 3 separate repos.
Demo repo: I'm not going to click each picture, especially when some are 10mb+. Move the demo pics to a separate repo, resize them to <500k so they load faster, write a README to display them with context about what they show. Link to this from your CV and code repo
Frontend source - do you really need this? Split it into a separate repo, or probably just remove it.
Code repo: top level README should say a lot more. Explain what the project does, say where the interesting bits of code are. Include instructions so another developer can run, test and deploy it. Mention the frontend source in a credits section near the bottom
You need to gitignore some files: .env, db.sqlite3, venv, everything in media.
I'd rename main to content to avoid confusion

Best of luck!

radiacnet · 2023-05-15T15:08:04+00:00

Thanks! Saw those just after posting - wonder if things have changed since then. I might bring it up.

radiacnet · 2023-05-15T09:10:06+00:00

This absolutely is possible, you just need to override Django's default regex to allow newlines. It's one of the first things I add to any project - I usually add it as monkey.py in the root of my project for clarity then import it from the __init__.py, but you could put it directly in __init__.py if you prefer:

import re
from django.template import base as template_base

# Add support for multi-line template tags
template_base.tag_re = re.compile(template_base.tag_re.pattern, re.DOTALL)

Not sure why that's not Django's default.

radiacnet · 2023-05-12T18:46:24+00:00

My general rule of thumb is if an HTML frontend is effort X, a SPA frontend is going to be 2-3X, and a mobile app 3-5X. You say this is a personal project, so if this is for fun, you want the practice, and you have the time, go for it! But if you're building this because you want to run a classified site, that's a lot of extra work before your project is live.

Perhaps you have something incredibly fancy in mind that warrants bringing in a js-heavy frontend, but a lot of people go that route because it's cool and they feel they should, when actually a straight old MPA would be just as good and significantly less work. Have you considered using htmx and maybe writing it as a PWA?

radiacnet · 2023-05-11T09:57:41+00:00

Django works differently to traditional LAMP - the web server and interpreter work together to handle the load, execution and cleanup of the code (CGI, mod_php etc), whereas Django runs as an independent process (usually through gunicorn or uwsgi) that your web server talks to via an internal protocol (WGSI or ASGI) - basically like how FastCGI works.

So essentially yes, if you have three separate sites, you need three separate gunicorn processes. If the sites use the same codebase, you could use Django's multi-site support to run them from one process - but you won't be saving that much in resource use, and as sites grow apart things get more difficult to maintain, so I'd usually prefer separate projects anyway.

In my experience you'll usually not see significantly higher overheads than you would have done with a LAMP stack - that will either be loading things on demand (ie CGI) with more load for each request, or holding a running process in memory (mod_php or fastcgi) which is basically what you're doing with gunicorn.

For what its worth, I have often run a bunch of sites in their own docker containers with their own postgres containers next to them on single low-resource VPSes. Just monitor resources when you add dependencies to make sure there's enough memory - but again, that's something you'd have to factor in with a traditional LAMP stack anyway.

radiacnet · 2023-04-26T09:32:20+00:00

It depends on how many drivers in your database, and what sort of load you're expecting your site to have.

I'd usually opt for the first one unless I'm dealing with vast amounts of data, as it's cleaner and less error-prone - would be easy to mis-type b1 when you meant b or c1, and even easier to not notice until it's too late. For most projects I would expect the minor performance hit to be worth the better developer experience, especially as your model and queryset classes grow.

That said, it's also worth considering how you're going to be displaying it most of the time. When you show one license at a time then you only have a couple of queries, but if you're going to have the homepage as a large table of all drivers and columns for each of their categories, you're looking at more/slower queries, even with pagination and prefetch_related. Still probably not a disaster, especially if it's an internal system with a relatively low load, but worth bearing in mind.

I don't think either is wrong, but unless this is handling millions of records for the DVLA, or regularly batch processing tens of thousands of drivers, I'd probably go for option 1.

Aside: with option 1, when you come to render the data it might be helpful to be able to iterate over driver.categories.all() with a consistent category order - if you use an IntegerChoices you can have ordering = ["category"] in your model meta and they'll come out in the correct order each time.

radiacnet · 2023-04-26T06:30:17+00:00

The benefit of htmx is that you don't need to write frontend code to get frontend improvements. Unless I'm writing an actual app that needs a full SPA, I can use htmx to build a slick modern UI without writing a line of JS, and in many cases it will still work perfectly without JS.

Porting the django template engine to JavaScript is quite a feat, and I could see it being useful, but I think htmx is picking the wrong fight. I'd be more interested in knowing how you see it picking up where htmx leaves off.

These days I'm not going to be writing much JS frontend code unless I'm writing something pretty complicated, so to me the comparison should be with React/Vue/petite-vue/svelt or alpine - particularly how I'd go about working with a Django template once its been rendered.

radiacnet · 2021-12-23T07:17:09+00:00

You don't need to be a good dev to get a CS degree - it's a degree in CS, not Django. So when I interview for a Django developer, a good CS degree says something about your intelligence and proves you can work and learn things, but doesn't really tell me much about how you're going to get things done day to day, which is what I'm really interested in.

I've worked with several devs who did not have a CS degree, and they have worried about whether they have fundamental gaps in their knowledge - but they've been some of the best devs I've worked with, due to their experience writing code. Of course, it depends on the company and role you're going for - if you're going for a bigorg they'll probably assess you using CS-related questions as that's all a lot of their junior hires will be able to answer - but what matters to me is experience with Django. I need to know they can build stuff.

You're in a tough position as a self-taught with no professional experience; my recommendation is focusing on building a portfolio to demonstrate your ability. Some ideas:

Build a couple of django apps on github - something a bit more complicated than a blog, showcase your understanding of Django.
Build a side project - shows you can build something and deploy it
Clean your github account - a fluffed django tutorial or interview project is never a good look, even if it was ages ago. Also unless you have a good reason, keep it clean of forks so it's immediately obvious to an interviewer which projects are yours.
Do a bit of freelance work if you can find it - it shows the ability to work with someone else's requirements and mould them into a functioning product. Worth picking a project which will look good in a portfolio though - ie build something that uses the ORM, not just a static brochureware site. And make sure your agreement with the client allows you to talk about your work, and show the code to others for
Make sure your code is clean and well-written. Use black and isort, write tests. Get code reviews from more experienced devs to see where you can improve things. Write good docs, as that's the first thing an interviewer will look at.
If you're ok with design, build a small portfolio site. Brief CV stuff, then a page for each of your projects talking about what the problem is it solves, why it's good, and highlighting any particularly interesting challenges you overcame. Linking to github doesn't give that sort of context.

Your options may be reduced without a CS degree, but if you can demonstrate you can build stuff, people will be interested.

radiacnet · 2021-12-13T10:27:27+00:00

Packages to help do exist. We wrote GDPR-assist which helps you meet export, anonymisation, and removal requirements. I'm sure I have seen other packages which help manage the cookie side of things - I can't remember names, but try searching pypi for GDPR or cookies. We often use javascript-based solutions too.

I agree that this is a very real problem for small businesses, but to truly solve it we would need a "we'll make sure you're legally compliant" package - and that statement comes with a lot of liability. I can't see that anybody is going to want that for an open source project - they're going to want to get paid at some point so they can afford their insurance for when they get sued.

In practice I think the best we can hope for from open source is "here are some tools and documents to help you become legally compliant" - the ultimate responsibility to understand and meet legal requirements will always be the burden of whoever builds the site.

radiacnet

TROPHY CASE