hywel

Right now, this site is suffering a hug of death.

This looks like the same article: https://dev.to/martinheinz/ultimate-guide-to-python-debuggin...

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).

HSTS is designed to prevent this.

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.

<plug> http://skillerwhale.com </plug>

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.

The ICO has a tiny staff and is already underfunded. The grace period is a pragmatic one not one enshrined in law!

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!

Some questions I'd ask, off the top of my head:

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.

The reviews: http://www.goodreads.com/book/show/28232614-coding-unlocked#...

The book: https://www.amazon.com/gp/product/B013R4OFVA/ref=x_gr_w_bb?i...

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 is my favourite kind of post to read: a tool I don't know well, and someone using it enthusiastically to solve a real-world problem.

BridgeU | London, UK | Onsite

What: bringing intelligence and analytics to the process of applying to universities around the world.

We're a scalable EdTech company, already sold to secondary schools in 25 countries, raised large seed round from big-name VCs last summer: http://techcrunch.com/2015/11/16/bridgeu-raises-2-5m-to-fix-...

Hiring for a Product Manager: https://angel.co/bridgeu/jobs

This article is totally on-point. MVPs are the minimal viable test for confirming your hypotheses.

While running a startup consultancy, the idea that MVP is a thing you make once before going on to make the 'real' product, was one of the two biggest misconceptions I saw. The other one was "lean means cheap".

I ended up realising that most startup resources explain these crucial things with misleading terms and a confusing way. Really, the whole process should mirror the scientific method - I started teaching my clients based on that, telling them to forget what they'd already heard. I'm writing a book at the moment about this (working title: The Rational Startup) but that's a subject for another HN submission :)

Error page from the UK

Google cache of this page: http://webcache.googleusercontent.com/search?q=cache:LQ2p32k... (the actual site is currently down)

Although obviously there's still a preprocessing step to make that possible.

It doesn't actually use bitfields, it describes an alternative to them that was a better choice in this specific instance.

Huffman would have been much slower to access, which would have been unacceptable for the use case (iterating 100 million data points multiple times a second).

The actual rating is a tiny part of the data per movie, so there's not much saving there. And clustering would have to be done instead of indexing by movie / user, so it would probably make performance worse overall.

Indexing by movie / user is done exactly for the reason of using the cache efficiently. Unfortunately, you have to iterate through both movies and users, so you either store the sparse matrix twice (once movie-indexed, once user-indexed) OR you deal with lots of cache misses half the time.

And, yes, all the values are stored 0-based for exactly that reason :) It's an even bigger saving for storing timestamps.

Not sure what you mean about the prime solution not scaling well - 3 primes of ~2^20 can be stored in ~2^60 (i.e. within 8 bytes) as opposed to within 3 4-byte integers.

When it really sucks is when you're storing lots of small integers, e.g. 20 things in [0,1,2,3] - that gets very inefficient fast, and it'd be much more efficient to use normal bitfields.

Kind of. The Chinese Remainder Theorem tells that you that there exists a number that satisfies, and that the number is unique, but it doesn't tell you how to calculate it.

The standard way is to do it recursively - you can see my implementation here: https://github.com/hcarver/Netflix/blob/2136aa5d28a209f902d4...

That'd be hard for a compiler to suggest for this case - it requires knowing the range of each value that you're storing in the struct (and not just the number of bits).

But if you're happy to do that, there's no reason it couldn't be offered by a compiler. However it's only useful for an unusual use case, when you have data that could just fit in memory, but doesn't fit in memory without the bit-packing.

Yeah, definitely aware that it's slower - I was severely bounded my memory when I came up with this, as I was trying to get my training data and all the variables in my model into 8GB of RAM for a machine learning project. Without the trick, swap was killing the speed; with the trick everything sailed along :)