It's notable that appcache is now deprecated [0]

It's been replaced by Service Workers, but those can get reallly hard to deal with if they start caching themselves (!)

Chrome's devtools has ways to delete old service workers and such, but I've found that on Firefox it's next to impossible to debug.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...

It's also notable that service worker adoption is only half way at best, whereas appcache is easier to deploy and supported in far more browsers.

Not to say service workers aren't the future, but implementing partially adopted features in web pages is poor practice.

http://caniuse.com/#feat=serviceworkers

We are aware and are ready to switch to a service-worker and appcache hybrid when that time comes that appcache is going to be removed.

But until then we wanted to keep it simple. Especially during development we don't want to have to deal with differences in SW and appcache.

The bar graphs were not designed to compare total amount of lines for each gender/age-range combination. Rather, they're meant to indicate how the percentage of lines for each gender is skewed older for male actors vs younger for female actors.

If they were to determine the length of each bar using amount of lines instead of percentage of lines, all that would be immediately clear is that females have less lines, a fact well established in the rest of the article, and the point would be lost.

author here. YESSSSS

What do you find misleading? The absence of 100%? Or the age ranges they chose?

The bar graphs might visually amplify the gap, but 1.1 million lines versus more than 5 million is a real gap, for example.

If anything, they gave us 2 different views on the data, and that double ;-) what we usually get.

The "whoosh" spelling is older than xkcd.

Euhh, I'm not sure I understand your use-case, but e-ink displays aren't especially "cheap", or such. They take a noticeable amount of time to update the display, so doing things like typing, or viewing output from top(1) would be less than ideal. (This seems to get better with firmware, and being "smart" about which places of the screen get updated, generally)

The appeal, at least to me, is that they can display information with little energy cost. For example you could have it monitor the system's health and have it update every half an hour, showing graphs and such, and it would be able to do that for a very long time with a smallish battery.

I feel like I'm missing something - why do you need it to run on battery if it's consistently monitoring a specific machine? Isn't their power pretty much anywhere you'd need something like this?

I edited my use-case after he replied - I think he would be A-OK with something that could be reliably powered from a USB port. I don't speak for him, but I think we've chatted on this topic before.

You can power a "Full HD" monitor off USB. These have been around for a while, but it's really fun to see someone set up with dual screens at a coffee shop running on batteries: https://www.asus.com/us/Monitors/MB168BPlus/

It's a service, of sorts, for registered users to know if any of their friends are in the vicinity, and if they are safe.

It also allows users to mark themselves as "safe" if they were in the affected area.

I'm unsure why this is downvoted.

I think he is saying that users can't be tracked between page-loads using this method, or your risk sending multiple users the same token. (which is true, at least with this implementation)

The time they spend on the website, latency, etc can all be used to add to a fingerprint, but there isn't something magic that makes this accurate, especially without JavaScript.

Edit: please don't mind me ghostposting kthx

Seems to have a pretty interesting attitude.

https://github.com/SirCmpwn/TrueCraft/issues/230

Considering the goal, which is stated very clearly in the README that's shown on the project page, that's not an out of line reply. Here's the first two paragraphs.

A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011). No decompiled code has been used in the development of this software. This is an implementation - not a clone. TrueCraft is compatible with Minecraft beta 1.7.3 clients and servers.

I miss the old days of Minecraft, when it was a simple game. It was nearly perfect. Most of what Mojang has added since beta 1.7.3 is fluff, life support for a game that was "done" years ago. This is my attempt to get back to the original spirit of Minecraft, before there were things like the End, or all-in-one redstone devices, or village gift shops. A simple sandbox where you can build and explore and fight with your friends. I miss that.

The goal of the project is to "freeze" a minecraft rewrite at beta 1.7.3

To add support for 1.8 is entirely out of the scope of the project.

The unofficial API community is also really great, and there are a plethora of libraries to choose from to get something working quickly.

https://blog.discordapp.com/the-robot-revolution-has-unoffic...

Here's a simple modification to get the random number between 1 and 10

    [:div
     [:p "Hit Run to get a random number:"]
     [:h1 (+ 1 (Math.floor (* 10 (rand))))]]

If you weren't previously familiar with the syntax I figured this might help.

I really want to add the ability to save/load content that can be built on. I think it would be awesome to share clever tricks!

You can use (rand-int 10)

I would consider NSFW ~2:45 into it