ronancremin

I did the same thing for running routes e.g. https://routespinner.com/@52.516247,13.379374,15z#route=cbp_...

> But you don't gain much, there's not a lot of weight to slow down with an ebike so regen gives you very little back.

But by the same token there's not a lot of weight to accelerate either, right? So while a moving bike has much less potential energy to recoup than a car, it needs much less to get back going again also.

So IMHO regen on a bike should be as useful as it is on a car, no?

DeviceAtlas has a displayPpi property for this purpose and has a NodeJS API.

https://deviceatlas.com/resources/available-properties

I forgot to mention that it supports MP3, FLAC, or WAV files.

I’m surprised that nobody has mentioned Web MiniDisc yet. This combines the best of web (WASM) and MiniDisc, allowing you to write content to discs from the comfort of your web browser and dispense with all of the awful Sony software.

https://stefano.brilli.me/blog/web-minidisc/

Web MiniDisc has added new life to the format. It lets you manage the contents of a MiniDisc ..from a web browser, thanks to WASM. Add MP3s, FLACs etc.

https://stefano.brilli.me/webminidisc/

I agree that the Firefox change is recent, but not Safari. Safari has had 3rd party cookies disabled for many years now.

The irony of Google purporting to protect users' privacy while at the same time:

- Chrome is still shipping with 3rd party cookies turned on by default (Safari and Firefox have them off, by default)

- Chrome usage stats are sent to Google including button clicks. This is admitted in the Chrome privacy policy.

- Chrome on mobile automatically shares your location with your default search engine i.e. Google

- Chrome sort of forces a login …which shares browser and user details history with Google

- Google redirects logins through the youtube.com domain to enable them to set a cookie for YouTube as well as Gmail or whatever, every time you login. Naughty stuff.

So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on.

It amazes me that more people aren't calling Google out on this.

I can't believe nobody has mentioned VisiData. It's like Vim, but for structured data.

https://VisiData.org

Tweet author here. Note at all of the responses from the site had a cryptomining script added, presumably due to a compromised machine. Our firewall just happened to notice the favicon first. So the favicon thing is just a coincidence and the browsers don't actually run the code in them (I checked this).

Tweet gives wrong picture, but only noticed afterwards when people replied. The site was mining Coinhive, but it wasn't the favicon that caused it.

https://twitter.com/xbs/status/964117597708079104

This is true but bear in mind that you can retain a view of the traffic with any of the web analytics plug-ins supported by AMP (all of the major analytics providers are supported).

I think that AMP as technical standard is OK in that it gives developers a format to follow that insulates them from the worst loading time issues that open-ended HTML can cause (JavaScript libraries and large images in particular). The performance gains are really significant e.g. 10x quicker load times on some sites.

The issue is how Google favours AMP results in search (with the lightening bolt and tag) and doesn't make it easy for users to get to the site hosting the page. We're sleep-walking into a kind of walled garden. More here: https://mobiforge.com/news-comment/sleepwalking-into-a-walle...

According to Steve Gibson (SQRL's inventor) tiQr is quite different:

"It superficially appears to offer a user experience similar to SQRL. However, as is every other such system, what's going on is actually far more complex and involves/requires establishing “shared secret” account credentials with the authenticating website. As they explain on their technical page, TiQr is based on the OATH (open authentication) OCRA protocol suite, which was standardized by RFC6287."

https://www.grc.com/sqrl/other.htm

Speaking for DeviceAtlas in particular I can assure you that detection reliability is better than most assume. The stated 99% detection accuracy rate isn’t marketing speak—it is continously verified on real traffic from all around the world.

We measure two main aspects of performance:

- Per-request detection overhead: Willy’s preferred way to measure impact on HAProxy performance is the per request overhead added. DeviceAtlas adds a few µs per request. Typically this does not cause much of an issue. Example: if a load balancer is serving 20,000 requests per second with 80% CPU, that's 40µs of CPU time per request on a machine that can go up to 50µs. If we add 4µs to that we reach 88% of CPU under the same load, and the end user performance is not degraded in any meaningful way.

- Memory footprint: DeviceAtlas lets you configure the per-device property set to tailor the memory and performance impact. The resulting memory impact ranges from about 12MB to 100MB.

Original Tweeter here. If you want to read more about page weight here are some articles I've written on the subject:

If anyone wants to check the math here are the data points (taken from http://httparchive.org):

https://docs.google.com/spreadsheets/d/1ag3KlStPARROp03IWZN1...

If you're interested in the problem of page weight you can read more here:

https://mobiforge.com/research-analysis/understanding-web-pa...

https://mobiforge.com/design-development/measuring-page-weig...

Confusing but not an oxymoron. From the point of view of the ICE the transmission is CVT because the road speed can vary (thanks to the electric motors) whilst keeping the ICE running in the same speed band.

The trick is not to do it yourself, this is a complex enough problem that it's worth leaving to others to do if it really matters to you.

https://github.com/OpenDDRdotORG/OpenDDR-Resources http://deviceatlas.com

Worth remembering the Yogi Berra quote: "Not all who wander are lost."

I think he meant it more generally than just walking around, but a nice reminder nonetheless.

Here's a Google cached FAQ from Microsoft about the technology behind it. http://webcache.googleusercontent.com/search?q=cache:_b9bZ5U...

The author reaches a trite conclusion uninformed by facts. The user agent string is used by at least 90+% of the Alexa 100 to improve user experience.

There is a silent evidence problem here. Successful use of the user agent string improves the user experience but goes unnoticed; failures are very apparent.

From the article:

"user agent string was a complete mess, and near useless"

vs.

https://etherpad.mozilla.org/uadetection-usecases

His conclusion is a bit like saying "I don't see why I need ABS in this car because I've never skidded since I got it."

Yes.

The user agent (UA) string is used by almost every major web brand for one or more of the following purposes:

- To serve different levels of experience to different classes of browsers. This is necessary if you want global coverage i.e. all classes of devices and connectivity. The payload of desktop version of Google is fully 140x bigger than the lightest mobile version, Facebook is similar (check this on http://prism.mobiforge.com). RWD can't do this (many RWD sites simply don't load at all on lower-end phones).

- Serving different experiences to different types of devices e.g. desktop / mobile / TV etc. Don't think this is necessary? Try some of the sites mentioned with a different UA strong and see how it feels.

- Analytics. Google Analytics, Omniture etc. all rely on the UA string to identify types of devices/browser.

- To offer links to the correct app stores for the various mobile OSes

- To make sites faster/lighter for lower end devices. This is important for low-speed connections, faster page loads, metered data plans.

Why? Because it can help improve the user experience (page payload, image sizes etc). There's a good reason why Google, Facebook, Netflix, eBay, Yahoo, BBC, Amazon etc. do it. It's also part of RFC 1945 (HTTP 1.0) and RFC 2616 (RFC 1.1). Not exactly a hack -- it's designed into the HTTP protocol since 1996.

Rumours of it's death are premature. It's used by over 80% of the Alexa top 100 sites. http://mobiforge.com/designing/blog/server-side-device-detec... Why? Because it can help tailor the user experience, reduce page payload etc.

You can test whether a site is using UA detection here: http://hydra.mobiforge.com

Low-end devices are still important in some territories. Part of the reason JavaME is so popular (http://tech.fortune.cnn.com/2012/01/01/if-android-is-so-hot-...) is Opera Mini, but also the Nokia S40 browser.

This is worth a look also: http://www.slideshare.net/yiibu/adaptation-why-responsive-de...

For a web design to be truely responsive and mobile friendly you need to do more than just move pixels about and change the size and layout of DIVs with media queries. A truely mobile-friendly site will serve a more contextually sympathetic experience to a person holding a mobile device, an experience that avails of all the additional contextual hints that you have available to you on mobile: location, heading, device orientation etc.

You can ignore all of this and create something that will render on a small screen, and say your mobile site is "done" but to do so is to miss out on the opportunities that mobile web presents. Doing this right is much harder of course, but there's a reason why almost all of the Alexa top 100 sites serve entirely different HTML to mobile devices, rather than taking a media queries approach.

There's a summary of all the ways to achieve these goals here: http://mobiforge.com/starting/story/mobile-web-content-adapt...

Some care is warranted here:

Advice item #1 is plain wrong (when possible, serve the same content to all browsers). If you do this, the site will not work on the vast majority of the world's phones unless it is supremely lightweight.

There's a good reason why the best mobile sites out there use UA sniffing (Google, Facebook, Yahoo! etc) — it's the approach that gives the best experience for your visitors.

If all you care about is Android and iPhone user then fair enough.