Regarding API serving, I'm planning on making it easier to use third party apps; the main obstacle is registering `includes` urls, which is doable at the moment but involves manually appending a path to `nanodjango.urls.urlpatterns`. I want to expand route registration to give a nicer internal api, then once that's in place Django Ninja should work pretty much out of the box - the only different should be how you register the url.

For me the two missing pieces were models and a path to migrate to a full project once it outgrew a single file, so I wrote nanodjango (https://github.com/radiac/nanodjango/, formerly django-flasky) - you can use the ORM and admin site, and I recently added a "convert" command to automatically break up a single page app into a full Django project structure.

I've been using it for a couple of years for prototyping/experimenting and putting together small apps, and with the new features this year feels like it's a really practical alternative to flask.

I have been a Python and Django specialist for over 15 years, working as a full stack developer for 20 years and as a hands-on CTO for four at one of the UK's leading Python and Django consultancies.

Core technologies: Python, Django, JavaScript, Linux and container-based ops.

Skills: Project scoping and implementation, team building and management, technical strategy.

Most of my career has been in consultancy/agency environments where every project is different, so I have production experience working in a wide range of languages, libraries, frameworks and platforms in both frontend and backend - including Wagtail and DRF, React and htmx, and Docker and k8s.

I am available for one-offs, part-time, or long-term contracts, in either development or advisory roles. Take a look at my open source projects for a sample of my work, or get in touch for my full CV.

https://radiac.net/hire/ | https://github.com/radiac | hn06@radiac.net

I have been a Python and Django specialist for 15 years, working as a full stack developer for over 20 years and as a hands-on CTO for the last four at one of the UK's leading Python and Django consultancies. I am immediately available for interviews, either for one-offs or long-term contracts.

Skills:

* Project scoping and estimating, team building, recruitment and resource management

* Directing technical strategies and solutions

* Implementation of anything from an MVP through to a production-ready deployment

* Advocating for code quality, linting, testing and documentation

* Comfortable working closely with clients

Technologies:

* Backend: Python, Django, DRF, htmx, Flask and FastAPI and more

* Frontend: JavaScript, TypeScript, Alpine, React, Vue, Tailwind

* Servers: Linux, AWS, GCE, Azure; CI/CD; PostgreSQL, nginx, Traefik, Docker, k8s

https://radiac.net/hire/ | https://github.com/radiac | hn05@radiac.net

I have been a Python and Django specialist for 15 years, working as a full stack developer for over 20 years and as a hands-on CTO for the last four at one of the UK's leading Python and Django consultancies. I am immediately available for interviews, either for one-offs or long-term contracts.

Skills:

* Project scoping and estimating, team building, recruitment and resource management

* Directing technical strategies and solutions

* Advocating for code quality, linting, testing and documentation

* Comfortable working closely with clients

Technologies:

* Backend: Python, Django, DRF, htmx, Flask and FastAPI and more

* Frontend: JavaScript, TypeScript, Alpine, React, Vue, PostCSS

* Servers: Linux, AWS, GCE, Azure; CI/CD; PostgreSQL, nginx, Traefik, Docker, k8s

https://radiac.net/hire/ | https://github.com/radiac | hn02@radiac.net

I found the main issue was maintenance. Once it was set up it didn't need too much poking, but I was still responsible for my own downtime and backup, and every few years I'd need to move it to a new server. I ran a secondary relay so at least migrating without downtime was relatively easy, but it was still a multi-day process while I moved configurations, rules and mail across, waited to trust DNS propagation etc. And in the back of my mind if someone didn't reply in a timely manner, I couldn't ever stop wondering if I'd missed a blacklist somewhere, or if a provider had just decided to spambin everything from my IP.

The other pain point was that as it was a necessary service rather than something that generated profit, I didn't want to put any serious time into improving things for myself. That meant I was using IMAP+Thunderbird with whatever shonky open source webmail-du-jour I'd set up on the server that year, combined with various shell scripts and notes in wikis about how to manage users, forwarding rules etc. It worked, but it was never easy, and was never slick.

After I took a job where we all used gmail, I got used to things being easy and slick, and decided to stop self-hosting and move my mail to dedicated mail providers (fastmail and sendgrid in my case, ymmv). Haven't looked back.

Self hosting you mail is something I'd recommend doing once for fun to see how it all works, but unless you have a clear and definite reason to go it alone, it's definitely worth paying someone else to do it for you.

And yes, the OS was starting to show its age (both graphically and with its cooperative multitasking) by the time Acorn was broken up, but at its peak it was miles ahead of the competition, and was definitely an under-appreciated pearl.

Comments URL: https://news.ycombinator.com/item?id=12298513

Points: 2

# Comments: 0

I wrote caman (https://github.com/radiac/caman), a bash script wrapper for openssl with what looks like a similar syntax to etcd-ca. I posted about it on HN a while back, but it now also supports SAN certificates and intermediate CAs.

In case it helps anyone, I wrote an openssl wrapper with a simple syntax to manage self-signed CAs: https://github.com/radiac/caman

I wrote caman because I could never remember what to type, so it has simple syntax - 4 commands, to add a new host, sign, revoke and renew; the only argument they take are the hostname. Configuration is a one-off when setting up your CA - there are two openssl config files with sensible defaults based on openssl best practice, with a few values for you to customise, and some basic templating for caman to fill out later.

Comments URL: https://news.ycombinator.com/item?id=10091532

Points: 26

# Comments: 6

The problem I envisage is that when you add 1.7 support to your app, you move your old migrations into south_migrations and start a clean migrations dir, as the instructions say - but what happens when your next release makes a database change? If you want to support all active versions (1.4, 1.6 and 1.7) you'd have to add a South migration and a 1.7 migration to support both groups of users - but then they no longer have a clean upgrade path from South to 1.7.

From reading the docs, it looks like 1.7 schema migrations may detect the changes have already been made and skip over them, but what will happen when you have data migrations too?

Does 1.7 figure out which operation you're up to by comparing your migrations to the database state, and starting migrations once the two match? What if at some point you return to an older set of model fields - does it match on the earliest or the latest?

I plan on avoiding the issue as long as possible: get my apps as feature complete as possible under South (with instructions for 1.7+ users for creating their own migrations), then bump the version when I switch from South to Django migrations. I'll then try to backport bugfixes to the South version (as long as they don't change the db) until support for Django 1.4 and 1.6 are dropped.

The way I could see it working though (without a significant change in OS UI) is by arranging your 2D desktop across multiple virtual 2D screens in 3D space, ie a bank of monitors angled towards you. You could use a conventional keyboard and mouse to navigate the 2D space (with perhaps mouse movement assisted or replaced by hand/head/eye tracking), and drag windows between screens, set programs to open on certain ones, with full screen clipping to screen edges - all basically as many OSes do already.

But because they're virtual, you could resize, split and merge screens, curve large ones, have ones which float in front of your vision to use for toolbar windows and HUDs. You could even use existing technology like VMs or VNC to use multiple OSes at the same time.

Mount your keyboard and mouse to a swivel chair which tilts, and you could comfortably have a 360 degree working area (assuming you can touch type) 4 or so screens deep, which would put traders' setups to shame (and at a fraction of the price). Throw in some panoramic backgrounds and you can move your office to a forest or a beach. Take it further you could even set up some sort of virtual office, being able to virtually get up from your desk and visit the workspaces of remote-working colleagues and friends to collaborate.

The exciting thing is that none of this is a massive leap from where we are now, and it would map pretty seamlessly to the software and UI we already use. The main thing holding it back would seem to be the resolution of 3D goggles, but with 4k rising, even that can't be too far off.

I think a lot of HN readers are missing the background to and context of this article though, which is that the author's talking about the UK secondary school system (11-18 year olds), which has been going through significant changes in the way computer science is taught.

When I learnt IT/CS at school, the correct answer to "How do you secure a computer" was "Make sure it isn't near the edge of a desk and there are no cables trailing across the floor" - answers involving passwords and firewalls were actually marked as incorrect. Formal education before university provided very little information which was actually relevant.

In the past year or so though, the government has changed the curriculum to be more practical and relevant. However, my understanding is that a lot of IT teachers didn't have a background in CS, so although they were happy at the level of tidying cables, they lacked the technical knowledge required to explain the new syllabus. That's insultingly simplified and generalised of course, but you get the idea.

Because the new syllabus was brought in in a rush following much political fanfare, questions were raised about how to bring these teachers up to speed in a short amount of time. I haven't followed the situation closely, but I believe that one solution which was pushed by government was that the industry should step in to save the day, despite the fact that they know sod all about teaching, and that their skill sets are often too topical and transient to be of any actual use to students. I don't want to put words into anyone's mouth, but I think that's a large part of what has led to this post, and re-reading the article in this context may shed a different light on it.

It also runs the risk that things will only get endorsed if they agree with commonly-held views, and I'll also be interested to see how it effects things like whoishiring.

Some sort of moderation is fine, but I think that in its current implementation, this is a rather ham-fisted approach which will have a detrimental effect on HN.