It can't! But after the first time it's been contacted, when you contact it again HSTS will enforce HTTPS (from the client itself - much stronger than a redirect).
This will leave your users vulnerable to man-in-the-middle attacks. If I control the router between their computer and the Internet, I can serve back a HTTP page which doesn't redirect, and trick them to enter their password (for example).
It doesn't have to be expensive, either in financial terms, opportunity cost or other people's time. That's exactly the problem we've solved with Skiller Whale - we make good training easy.
Form a limited company and run the site from that. If you're prepared to shut the site down anyway, then that remains the worst thing that can happen for non-compliance.
There's no need to shut the thing down just in case someone sues you when that hasn't happened yet.
On the other hand, there's a good reason to shutter your site because you don't have time to make it respectful of people's privacy. By all means, shut down your site because the GDPR makes you realise that! But that's not what OP is saying.
It seems like more research into GDPR could have prevented this.
Firstly, there's nothing this site does that is so unusual. If the user gives explicit and informed consent for their data to be used in this way, then you are likely to be covered.
Secondly, it's looking unlikely that the rules will be enforced that strictly in the near term, especially against a small, hobby website. IANAL but you likely have a couple of years until you have any chance of being on the ICO's radar (ICO is the UK's enforcer). And even then, you can reasonably expect the find to be << €4M.
Thirdly, if you run this site from a limited company (about £100/year to maintain), then the very worst case would be that you are investigated under the GDPR in the future, and you can fold the site then at which point your liability ends. No need to do it now, in fear of something that may never happen.
I hope it's not too late to change your mind about shutting down!
Have you ever tried a touchscreen computer?
Was it better than when you use a mouse?
Why?
Which interface do you prefer - your computer or your phone?
Why?
Show me how you would go to www.altavista.com on your PDA.
It looked like it was hard to find the browser - is it often hard to find the right application on your PDA?
When you bought this PDA, were there cheaper PDAs you could have bought?
How much more did you spend on this PDA because it was better?
Do you have lots of VHS videos at home?
When did you last watch one?
Do you have a lot of DVDs?
How are they stored?
Is it a problem that you have them? Would you rather not have to store them, and why?
Have you ever watched a YouTube video?
Is it easier to find something on YouTube or to watch a DVD?
"I’ve rarely encountered discussions of contagion."
This surprised me: contagion is a good metaphor because it is a compounding measure of the growth of the problem. Just like an interest rate (a compounding measure of the growth of debt).
Most senior developers I've met have considered the interest rate of the debt, which seems like it has been renamed here as contagion. Maybe I've been lucky to just know smart people!
From the point of view of explaining these concepts, I'd suggest keeping the metaphors consistent. Tech debt should have an amount owed and an interest rate, tech infection (?) should have a potency and a contagion level.
I'm working on a product like this at the moment to solve exactly those problems. On Twitter @h_carver if you want to chat more! Or if you want to wait 6 months and find out why I shouldn't have been pursuing it ;)
Yeah, the UK National Curriculum says children need to learn a visual language (like Scratch) and then a text based one (like Python). Your kids should be doing visual coding in school from Key Stage 2.
Depends whether you want to teach code or computer science (and code).
I wrote a book to teach 7-11 year olds to code in Python and Scratch and teach them some computer science along the way - I read a few other books out there first, and there's a lot of "just copy out this code and things will happen", which is exactly what I tried to avoid in this book.
Hey, you should try this book which Scholastic published www.goodreads.com/book/show/28232614-coding-unlocked#other_reviews
It's available as an ebook as well as in paper. Short pitch: don't just learn to code by typing out existing code, learn how to think algorithmically and write your own code instead. Learn Scratch and Python side by side, seeing the same Computer Science concept in one and then the other. As well as the reviews, I've heard great anecdotal feedback.
Full disclosure: I wrote it. If I could get you a discount, I would, but I don't have that kind of sway with the publisher.
"Most startup failures were caused by building the wrong product, or lacking strong sales skills, or not having a viable business model" <- the first one of these is the biggest cause of startup failure, and is technical.
Startup technical diligence needs to check for a minimum level of ability and beyond that, ability to find the right direction to build in.
The idea that what product you build is not the responsibility of the technical team is almost certainly why you think there's no point in doing technical diligence.
This looks like the same article: https://dev.to/martinheinz/ultimate-guide-to-python-debuggin...