radiac

Mine certainly does - we lost so much when we killed off our cgi-bin/guestbook.pl

Thank you, it's great to have positive feedback!

Thanks! Yes definitely, I think it's a great fit for anything self-contained and limited scope that doesn't need a lot of code. I've certainly found having an easy way to run a single file using Django's ORM is pretty handy.

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.

Me too, I'm convinced it has a place - the number of single file projects over the past few years can't be a coincidence.

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.

SEEKING WORK | UK | Remote | Python developer for 15+ years

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

SEEKING WORK | UK | Remote | Lead developer/CTO contract

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

SEEKING WORK | UK | Remote | Lead developer/CTO contract

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 self hosted for myself and some clients for years. As long as you set up everything correctly it's fairly pain-free, but it's definitely worth getting on as many abuse notification lists as you can find - I wasn't doing anything remotely spam-related but still got blacklisted by hotmail twice and some other places a couple of times; as I remember it getting cleared was just a case of jumping through a few hoops, but I still needed to find out about the problem before my clients did, and find the hoops to jump through (which was never easy).

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.

Having an OS which boots from hardware is always a feature to me - no matter how badly you screw up your system, you just do a hard reset (boot holding R) and get a working OS and GUI. You can still patch it by defining a boot app, but the core system is always there, safe from mishap and malware.

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.

So did I: https://github.com/radiac/python-perl/

As you say, I'd prefer to run this sort of thing locally - half the point of running your own CA is that you have full control over it.

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.

Exactly - there's no need for a service like this when you can have self-signed certificates. Create a CA cert to distribute across your team, then use it to sign host, wildcard and SAN certs as needed. If you need to share your site with people who don't have your CA cert, it's time to get a real one.

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've added an experimental branch with SAN support, but I haven't had a chance to test it fully yet; any feedback would be appreciated.

I hadn't come across this when I wrote caman; from the looks of things caman is simpler to use, but missing a couple of features - alt hostname support for SAN certificates (which I'm adding at the moment and should be up later today) and ability to use a subsidiary certificate authority.

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.

How good are Django 1.7 migrations at detecting things which have already happened? In particular, can you safely maintain South migrations alongside Django ones, or do you have to force users to switch?

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.

As you say, it's an interesting tech demo (which looks like it would be even more fun if you coupled it with a physics engine btw), but not particularly practical.

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.

It may be of interest that the author actually has a degree in CS, as well as her postgraduate teacher training (I was at university with her). As you say, I think her point was that because she now works in education, she may not have kept up with the latest specific developments in the industry (new languages, libraries, tools etc), but she has a lot more knowledge about how to teach general CS skills to students, so that they are able to go out and learn modern specifics themselves (which of course will have changed significantly in the time they finish their education).

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.

But that's part of the problem - comments will only show up if there are enough people looking at it to do the endorsing. A single site-wide list of pending comments won't work either - surely the whole point is that comments should be endorsed in the context of the thread?

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.

The other type it could cause problems for are whoishiring.

Given they're no longer secret, that would seem safer than typing my e-mail address into an untrusted site to see if it has been compromised.

I agree. They're open source at the moment, and they've been my icon set of choice for some time - I use them in my open source RSS reader, django-yarr, for example. In fact I came to the comments to complain about how there is already an icon set with that name, before I realised it's the same guy.

I understand why they're going for commercial licensing on top of the kickstarter, but it's a real shame if the new icons never make it into the open source project. I'm more than happy to pay for them if I'm using them commercially, but it would have been good if one of their stretch goals had been setting a chunk of money aside to feed the new icons back into the open source version for people to use in their projects.

I feel exactly the same way - wherever possible I run my own services on my own servers, so I know where my data's going, and I'm not at the mercy of someone else changing or removing a feature I like, or shutting it down completely. If I fall out with the hosting company, I can just get another server elsewhere.

I only switched to self hosted for RSS recently though - when google announced they were shutting reader, I figured I'd write my own for an existing django site. Quick shameless plug: I released it on Sunday, in case anyone's interested - https://github.com/radiac/django-yarr

Which brings me on to my main exception for self-hosting: public repositories on github. The collaborative features they provide seem worth the loss of control - although their recent UI enhancements (making it harder to check issue counts, find repo addresses etc) does rather prove my point.

Author of django-yarr here; I'd also found the feedreader on bitbucket, as well as http://code.google.com/p/django-reader/ - I wanted to go in a slightly different direction, and neither of them had had much activity recently.

I'd be interested to hear if you have any feedback for yarr - I'll be working on it this week to try to add in the main missing features (managing feeds, timezone stuff etc), and if people think it's missing an important feature I'll do my best to add it.

I had only implemented n/p so far because that's all I used, but I've added j/k now. I'm aiming to match Google Reader's core functionality (except the social side), so I've made a note of its keyboard shortcuts, and will add more over time or as they're requested.

Thanks for your comments regarding the design! I'm going to try to keep it as minimal as possible mostly because that's how I like it, but also so that it can be drop into existing site designs without too much hassle.

Thanks for pointing that out - I'd noticed a few clashes after I'd started developing it, so its full name is django-yarr; I've changed the title to avoid any confusion.

While that is a valid general criticism of Steam, they do provide an offline mode, which the new Sim City does not. Personally I prefer Steam to the previous alternative of having to leave the CD in the drive, or using a dodgy no-cd patch - but that's getting off topic.

The DRM strategy in Sim City is not the same as Steam, and cannot really be compared. EA are forcing unnecessary always-online features into what most people expect to be a single player game, preventing it from being played offline at all, in a thinly veiled attempt to prevent piracy and resale. That would be bad enough, but what makes it utterly unacceptable is that they haven't provided the infrastructure to support it in the short term, and clearly don't have the business model required to support it beyond the first few years.

Why anyone would knowingly support this business practice at all is beyond me, let alone for a game which has had such dubious pre-release reviews and is now essentially unplayable.

A menu somewhere to select the current media type would be lovely - not least for checking print stylesheets. Perhaps a drop-down at the top of responsive mode?

A nice ui for cookie management stuff (edit, delete) would be good too. Even better would be a way to manage different sets of cookies on the same site - eg per-tab cookies, or an option to save/clear/restore - to make it easier to test as different users at the same time.

I had LASEK surgery. I had gone in for LASIK, but was told I wasn't suitable due to the shape of my eyes. Instead of cutting a flap and burning underneath, in LASEK they just melt off the front bit of the cornea, burn the exposed eyeball flesh, then let the cornea grow back after the operation.

LASEK has a longer recovery time, because you have to wait for the cells to grow back across the front of the eye - I was in agony for the first few days, mostly because they gave me the anaesthetic drops to take home with the words "You can take this if it hurts, but it'll probably slow your recovery", so I just left them in the fridge. Helpful. But after a week I had no pain, better than 20/20 eyesight, no noticeable halo effects and only very mild starbursts - noticeably better than the ones I had with glasses or contacts. The only thing that really suffered was my wallet.

I had this done about 3 or 4 years ago, and regret nothing. For the first year I did occasionally wake up with dry eyes - well, ok... without the sugar coating: I did occasionally wake up screaming and writhing in agony when the vulnerable tender cells on the front of my eyes had dried out and stuck to the inside of my eyelids, which I'd then brushed against a pillow and torn the cells off my eyeball. Yeah, I've got to admit, that wasn't pleasant. The problem was that my eyes never really had a chance to heal after the operation, because I needed to use the celluvisc drops for longer than they had initially recommended - once we realised that and I used it every evening for a couple of months, my eyes were able to heal fully, and it has been fine since.

Ultimately it's not going to be for everyone - it's expensive, and at times can be painful. But I hated wearing glasses (I was -6, so could only focus on things if they were touching my nose), I didn't get on with contacts, and I love being able to now do things that normal-sighted people take for granted - being able to walk into a warm shop in winter without needing to de-fog yourself, walking around in the rain without needing windscreen wipers, or slipping sunglasses on when you step into the sun. The novelty still hasn't worn off, and I can't recommend it enough.

I'm not saying that he should keep pumping out new features for ST2 - it's totally fair to draw a line under it on the day it leaves beta and say "no more features". My complaint is that he took ST2 out of beta while people were still complaining about bugs, and has subsequently only issued one bugfix release.

As both a user and a developer, I don't think it's unreasonable to expect paid software to get support and bugfixes for a while - at least until the next version leaves beta. "Pay an extra 50% and maybe I'll fix the bugs" doesn't seem fair.

Rather than what Silktide are saying, this change just seems to be bringing their own website into line with their last-minute clarification (or rather u-turn) on implicit consent.

The ICO spent a year banging on about how you need explicit consent, and lots of people ran around implementing various solutions that make people click buttons and are generally incredibly annoying. Then, about 12 hours before the law came into effect, the ICO said "Actually, you know what? Implicit consent is fine."

On the off-chance anyone is still interested in this sort of thing, I wrote a small implicit consent script after the ICO clarified their position: http://radiac.net/projects/cookieuse/