224 karma · joined April 12, 2015
You know what I hate more than "JS fatigue" - it's ppl complaining about "JS fatigue". Software evolves, and I'm always looking to bring a better experience for my users - and then means replacing components sometimes when there are clearly better alternatives, whether that is for developer experience, smaller bundle sizes, etc.
I authorized the car to my home's WiFi in hopes that there would be updates. Instantly regret. :/
Do I dare even turn it on now?
What struck me was the [ t a b ] stuff as well as the Latex reference, which looks to be embedded img in src, so there must be some sort of preprocessor?
Asking for a friend...
/s
I'm about 7 deep at the moment.
Seems like a dev w/ a new certificate could post a build of said application to a dev-friendly space to "bootstrap" the process.
Certainly not practical in many scenarios, but that's why I was curious about how many it takes.
https://www.youtube.com/channel/UCJq3cq9N6xYF0fAvTgpwoBg/vid...
Edit: here's the build breakdown video: https://youtu.be/gDy10Wy4vw4?t=57
Url is https://rbitr.github.io/ChartS.css/
It refers to itself as C:greenheart:SS.css (what?)
Aka ChartSS.css - clever, but neither descriptive or memorable.
Edit: The fact that I can't even rag on the name in the comments due to the emoji makes me feel more justified in my original assessment. :P
In general the defaults are pretty good I think. There is a one page production deployment guide: https://www.rabbitmq.com/production-checklist.html that I followed to replace our handbuilt cluster w/ a new automated deployment, plus a few other niceties like docker logs & rmq metrics to cloudwatch and then auto clustering via autoscaling groups lookup.
I thoroughness of the docs can perhaps seem daunting, but I see it as a badge of quality and especially if you are growing it's usage organically it should "just work".
> Twice as fast as other Javascript parsers (sic) written in JavaScript.
But are we technologists, or what? Figure out the behavior and suggest a solution.
I find that it happens to throw street names close to major intersections, which happen to be offscreen due to panning. Seems to me that there could be a change to detect when a street name is not present on the screen and make an adjustment to do the same. In other words tweak the heuristic for showing names +- zoom level. They do have _a lot_ of data.
I think it's really popular to hate on Google right now for a myriad of reasons—but I also think that people who work on Gmaps want to improve their product.
Y'all know how to file bug reports. Expected behavior, current behavior, steps to reproduce, etc. Stop complaining about a service that is free, or else—don't use it.
BTW; agree w/ the majority of OP's points regarding contacting humans & lack of features / price etc for API. That's valid feedback.
Heh, didn't see this comment before I left a novel up the tree. Seems we have similar ideas about state management.
I think the default RR API is straight React, and that is by design.