HN user

Juerd

22 karma
Posts1
Comments6
View on HN

"Hackerspaces tend to be (...) spaces that tend to overlook fire, health/safety, and disability building compliance."

I think that's not very relevant to this specific occasion, because the fire did not start at the hackerspace. The first flames and smoke were on the opposite side of the huge open warehouse, of which the hackerspace was just a relatively tiny part.

Pixelbar was a small free standing two-storey building within the very large warehouse. I don't know if the hackerspace was built to code, but I think it wouldn't have mattered much in this case. By the time the fire reached that building-within-a-building, it must have already been a nigh unstoppable inferno. The fire safety of the surrounding warehouse may have been questionable, but you can't really blame the the hackerspace for that.

To me, foo.where(...) looks a bit cleaner than a function call such as filter(..., foo). But writing foo.skip(4) instead of foo[4:] is just silly.

This library consists of very thin wrappers around functionality that's available out of the box in Python. Are these wrappers worth an extra dependency? I think a cheat sheet for people coming from .NET would be more useful than implementing a similar API.

The same question is answered by my own "study", a typing speed website that has been collecting data since 2008. It uses only simple words to avoid becoming a reading test (or worse, a typing torture test).

Halfway down the page at https://typing-speed-test.aoeu.eu/ there's a histogram of the statistics, built out of 46 million completed tests.

Because of the immense sample size, I've tried to keep the test compatible over time. Based on referrer logs I think the user base is incredibly diverse, although I have no specific statistical data on the participants.

Unfortunately, the database (small SQLite file available on request) is aggregated and I don't have any data on the development of the statistics over time.