This does not appear to be a total outage. I cannot reach any of our sites, and Pingdom also reports we are down, however, I can see normal looking traffic reaching our servers (via heroku logs --tail). In addition, members of our team are reporting via Slack that some can reach our Heroku-hosted sites, others cannot. It seems to be ISP-related. Two people within 1 block of each other on different ISPs see different results.
We proxy some services through Cloudflare to gain IPv6 support, and all of those are down, which suggests the Cloudflare -> Heroku network route is broken.
This site: https://whynoipv6.com/country/us -- provides a "wall of shame" summary of sites that do not yet fully support IPv6, in order of Alexa rank. It is definitely surprising, even shameful, that so many top sites make this list.
That Twitter and Amazon don't have full IPv6 support yet blows my mind.
It's also worth noting that IPv6 networks definitely DO exist in the real world.
My tiny startup provides software to run sports teams (mostly swim teams) and we've run into several cases where new wifi gets installed at a neighborhood pool, and the network is IPv6 only. So far, the pattern seems to be cases where AT&T is the ISP in the Houston area. To troubleshoot these issues via phone support, we ask if the customer can reach amazon.com or twitter.com. If not, it's a pretty good sign they are on a IPv6 only network.
Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store (although, in practice, this requirement is not consistently checked).
See: https://developer.apple.com/support/ipv6/
[Edit] To clarify, I'm not affiliated with the Why No IPv6? site. I just found it to be a useful resource. The site credits https://crawler.ninja/ as the source of its data.
[Edit 2] Added link to Apple's IPv6-only support policy.
> Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store
It really doesn't. It requires that the iOS apps work on IPv6 networks with DNS64/NAT64/whatever it's called. It meerly suggests that you might want to have server side IPv6, since your iOS apps need to support it anyway.
I run an ipv6-only local network for fun, so I can tell you the name you're looking for is 464XLAT. In this style of setup, IPv4 packets are translated into IPv6, routed over the IPv6-only network, and translated back to IPv4.
NAT64 and DNS64 are not the same thing as 464XLAT.
It's been a number of years since I had to work on this at a previous company, but my recollection is that Android relies 464XLAT to make sure that all android apps will work properly on ipv6-only mobile networks that use carrier grade NAT.
Apple on the other hand demands that your app actually natively works with ipv6. I didn't have access to an ipv6 network when I was working on solving this issue in our networking libraries, so I used this https://www.jool.mx/en/ to set up NAT64 and I used bind9 to do DNS64 in order to create an ipv6 network for testing ipv6 functionality.
No, the iOS requirement is for DNS64/NAT64. The server can be IPv4, the app has to work with an IPv6 address provided by DNS64. If 464XLAT were the deployed, the app could continue to speak IPv4, but it can't. Nothing to poster you replied to said contradicted that, so I'm not sure where you got it from that they speak about 464XLAT?
Maybe I misinterpreted the original poster's comment, my understanding was they were referring to IPv6-only carrier networks.
In the US (unsure about other countries but they may work the same), the IPv6-only carrier networks mostly (all?) use 464XLAT and not DNS64.
My comments are intentionally devoid of talking about what Apple's requirements are because I don't know then and as far as I know the other posters are correct there.
Indeed, IPv6 has existed for 26 years yet here we are in 2022 still having issues using it. Sites/apps are still deployed IPv4 only, consumer equipment is not ready for IPv6, and very few ISPs are even providing customers with native IPv6 addresses.
Mine is, luckily, so I've been able to set my network up, but I'm struggling to see how the world is gonna make this transition in the near future tbh. My guess is we'll be stuck with carrier grade NAT for a long time.
My ISP is dual stack (cox), as is AT&T fiber -- but that is only for residential. Almost all consumer gear is IPv6 compatible, much of Cisco Meraki's still isn't or is limited.
Just because the equipment can do it, doesn't mean it's ready. I was trying to get my home network setup for IPv6, but the DSL modem would reboot if a fragmented packet was sent, so that's not really ready. The replacement modem didn't reboot, but had severe induced latency, so I went in a different direction and still don't have IPv6.
What a strange layout - the sidebar, which cannot be manually collapsed, covers up page content at moderate widths, until the page is quite wide. When the window gets narrow enough, some of what's in the sidebar can't be accessed at all.
Reddit ipv6 was enabled before Christmas but got disabled because of issues with the Android app and square’s okhttp lib I think. Namely that it didn’t support happy eyeballs.
Frankly, given the peering issues and lack of support from major peers it's not going to happen soon...
And the mess that is v6 when things go wrong...
I'm going to say it again. Private v6 and a powerful v6<->v4 NAT if you insist on using v6 only on devices, we're nowhere near the point where people can't afford a single v4 address and if the phone companies can do it at huge scale so can others...
Edit:
"Adding support via cloudflare" ??? doesn't that mitigate pretty much 90% of all of the advantages of v6 in the first place? that's just implementing it for tech-point scoring...
It's not about tech point scoring, it's about quickly solving a problem. Specifically how can my customers on IPv6-only networks reach my service hosted on Heroku (which does not support IPv6)? Cloudflare is a practical and relatively easy solution to that problem.
I'm working on a project with some offline data synchronization needs, but haven't started implementation yet. I've been following CRDTs with interest. I also saw many of the same downsides mentioned in the OP, e.g. bloat (which apparently are being addressed remarkably well). Beyond OT, another approach I've run across that looks very promising is Differential Synchronization[1] by Neil Fraser. While it also relies on a centralized server, it allows for servers to be chained in such a way that seems to address many of the downsides of OT. I wonder why I rarely ever see Differential Synchronization mentioned here on HN? Is it due to lack of awareness or because of use-case fit issues or some fatal flaw I haven't seen? Or something else?
This is a good time to point out Micro.blog, an independent publishing platform designed to empower publishers and protect privacy. (Not my work, but I'm a fan)
I'm pretty bad at remembering names, but my wife and I have worked out a system. If we're in a social setting together and I start to introduce her "have you met my wife..." she will jump in and introduce herself directly to the other person "hi, I'm Colleen...", which prompts the other person to directly introduce themselves to her (and thus taking me off the hook). As a result, if someone is introducing me to someone else, I tend to do the same thing -- hijack the introduction and introduce myself directly -- just in the case the person making the introduction needs an assist. Of course, if they've already greeted the other person by name, then no need.
In my college days we were brutally honest when we had forgotten someone’s name. It was such a large school that if you simply stepped outside every day you met someone new all the time, one way or another. Many people you would only meet once and then never see them again. So it was common to hear some version of “It’s good to see you again! Sorry I haven’t gotten your name down yet, I remember you but I’ve got to meet someone like 5 times before their name sticks” and it was no big deal because the other person would say the same thing back.
I like to think that in the real world being honest about forgetting someone’s name doesn’t hurt, but then again remembering someone’s name is way more impressive.
One method I personally adopted in my professional life is delaying the usage of pronouns until the day I personally believe I memorized the names properly. In a setting where I can say "She can do that.", I instead say "Jenna can do that." until I'm satisfied with my memory.
haha this was also one of my tactics. Even when I’d speak to someone one on one I’d slip their name into the conversation.
I think most people like hearing their name being said so even when I slipped their name into things that people normally say without using names it didn’t come off as too creepy, at least I don’t think.
This is a much better tactic than the worst thing you can do, which is pretend you know and then use a wrong name. I lost a decent retail account by calling an owners friend ‘Ashley’ when she was really ‘Melissa’ when I met them at a party 3 months after initially meeting them at a trade show.
Yeah, I struggle with this. Often when I see someone my brain doesn't present single name match, more often I have a list of potential matches in my head. e.g. "Scott or Rob" -- so I'm forced to just go with one, or avoid saying any name at all. I've gone for it and botched a name before and it was truly embarrassing. Often given a few seconds I can recall with certainty. It's the one-the-spot instant name recall that is difficult for me.
Harsh. I've seen this happen many times and on every occasion it's been taken light-heartedly/no offence/whatever. I think you were incredibly unlucky.
Yes, these individuals turn out to be rather snobby, you could say. Not people I’d endorse as friends or business partners on a personal level, but, it’s business and it’s worth knowing how to not lose customers, even if not means coddling them.
I almost always hijack to introduce myself. People often mis-hear my name so introducing myself gives me an opportunity to state it multiple times and give them a mnemonic device to help them remember.
I worked on a project that required some pretty standard line charts, but with the addition of an overlaid set of horizontal "benchmark" lines -- and some callouts. After struggling (and failing) to get what we wanted out of two different off-the-shelf graphing libraries (one of which was built on top of D3), we finally bit the bullet and just built the charts we wanted in D3 "from scratch". Once I wrapped my head around the model, it was such a pleasant experience. D3 is soooo nice and well thought out. You mayneed to level up in SVG, but it is so freeing to be able to bind data and display it basically any way you want. In hindsight, I wish we started with D3 from the beginning and I would not hesitate to pick it up for even simple charts again. It really is worth climbing the learning curve, which isn't as big and scary as it appears at first sight.
I had a project with the same requirements and settled on echarts[0] (version 2 at the time, now on 4). Its adoption was, at that time, very diminished due to everything being in Chinese. Its base graphics library, zrender[1], still suffers this issue. Were it to become more introduced to westerners, it could take the place of d3 for many of these use cases since its API is much easier to grok. Granted it's all canvas, but most uses don't care how it's rendered.
Edit: well, browsing zrender's source, I see svg logic too
I could not agree more with you. So many folks here seem to be missing the actual utility of D3 and why it still remains relevant and useful in todays JS/Web landscape.
If you need standard stuff, there are plenty of awesome plotting libraries that utilize D3 on the back-end while abstracting the complexity away from you. Some even try to give you some amount of flexibility and composability to customize them, but they are always going to have limitations compared to the raw power and flexibility you have if you roll your own D3 visualization.
You can't have it both ways, and that's something a lot of people don't seem to understand. If you're absolutely sure that a visualization library can support all your requirements, then it is absolutely the easier way to go about doing things. But you just have to be really sure that your requirements aren't going to change past the limitations of the visualization library of choice.
D3 gives you a diff algorithm for free. That handles adding new items to your visualization, updating existing ones, and removing them. You implement the enter, exit, and update (update may have been deprecated). That makes it easy to take your data and handle changes. It will handle animations in a very easy way for each of those cases as well.
In data visualization, creating a scale based on the domain of your data (the range of your data) is annoying. This is handled for you by utility libraries in d3. It also can draw the line ticks of the scale without issues.
Also placing labels is not too easy. D3 does that nicely.
The truth is you can do all of that yourself, but if I were to try it, I would go over the d3 utilities first just to see how complicated some of the visual aspects you haven’t thought of but will need are.
The drawing part of d3 (SVG, canvas) are not so hard to do on your own, but the way d3 isolates the context of what you are coding is very helpful. I’ve only run through the examples and read the d3 book as well as several other charting books, but I don’t use d3 on a day to day.
But let’s go over a more realistic example. In one of my books, the author writes about simple line charts and displaying the quartiles (made by standard deviations) of the data. None of my charting libraries handle that. Rolling my own would be very time consuming. Doing this in d3 would be more feasible than the alernatives.
Not OP, but a someone who uses D3 every day, it gives you (almost) total freedom. You can decide where to put your x and y axes, legends, labels, etc. You can decide how data determines not just how something appears on the screen (like a bar chart of y height) but how the underlying data determines its classes and styling, etc.
D3 is awe-inspiring in its scope, and learning to use it has a steep learning curve. But for anything beyond trivial use cases the freedom it affords you is worth the effort.
I must be missing something, this doesn't answer the question at all. Literally everything you said is true for just building the graph in JS/SVG. What does D3 give on top of that?
Maybe this will help, it creates an SVG graphic by default.
Consider how much JS you'd have to write to even start creating all the frameworks to build in native SVG structures... a lot.
I created html graphs with tables in the late 90s, made Flash graphs in 2000s, upgrades to numerous JS based charting libraries after this, building custom graphs the whole way.
I had looked at D3 so many times over the years when it first showed up online. But it "looked" complicated, no obvious "chart" library, etc...
Finally, when I tried D3, I was like "why the f didn't I start with this?"
Maybe I'm missing something, but it's literally impossible to achieve something with D3 that you can't achieve with JS+SVG, since D3 is a JS library that emits SVG. The question is how much work you can afford to do. You can always roll your own. But you're going to have to a lot of fussing around with things like figuring out where to put tick marks or grid lines, maybe you need to parse some CSV, or figure out how to label dates. There are also things like Voronoi diagrams which are, if not tricky, at least tedious and annoying to implement yourself. And then there's simple statistical operations like making histograms or calculating medians or other quantiles that, well, you can always implement those yourself.
Basically, D3.js strikes a good balance between ease of use and expressive power, that leans pretty far towards expressive power, while still being far, far less work than rolling your own.
If you do it yourself in straight JS, you'll very quickly start building the common tools of D3: various scaling mechanisms mapping the domain to the pixels, data binding against a set of DOM elements, converting an array of data values to the co-ordinates for the d attribute of an SVG path, etc.
Somewhere else someone described D3 as a hammer, and that's a good analogy, because if you don't start with a hammer, it's the first tool you'll make for yourself when you need to pound nails.
D3 particularly excels at graph animations and data transforms (as might be helpful to facilitate graphing). Its one of the most comprehensive graphing libraries around. Well written code that uses it looks like pure elegance. Its amazing how much functionality you can get out of so little code. It does take some time and a solid understanding of javascript and scope.
It's an API for building custom charts. It's a huge step up from having to fully 'roll your own'. If you have to do any kind of vis that isn't available in the various off the shelf libraries, you can put it together with D3 easier than you could if you fully DIY a solution. It's well thought out but you have to use it for that to be more obvious. This book (by the D3 author) got me started, it's worth the hassle of learning [0].
So d3 is actually a _set_ of libraries, of various kind, most of which happen to be useful for data visualisation. Through its richness, there's a good chance that at least _some_ of those libraries will fit your use case well enough. There's nothing stopping you from not using it, and in fact my most recent work was with Canvas, and the only thing I used was d3-scale, which aids mapping datasets into number ranges and selecting ticks.
In another case I might not care about it, but use d3-selection, a mechanism for creating a data-driven DOM tree — but it's pretty clear that you can achieve similar mechanics with React.
Importantly, you don't have to pull the whole thing into your dependencies just because you use a bit of it, and it's light on own dependencies. So just using a small subset of functionality is "cheap."
It gives you a well defined set of primitives to work with. It's also a well established library, so there are a number of good resources on it (and it's seems to be mostly bug free).
Go to https://beta.observablehq.com and dive in: just start forking other people’s examples and fiddling and looking up stuff in the docs or asking for help whenever you get stuck.
do you have any recommendation on resources on d3 for beginners? Personally I find d3.js very challenging, there is tons of example out there and simple tutorials, but I don't think there are tutorials that bridge those harder examples for beginners.
d3 has a lot of really useful libraries baked in. You can even use them independently and roll your own svg using its components as utilities. I find this super helpful when using d3 as a whole isn't really a good option (as part of a React/React-Native app for example).
That's not really a fair comparison. Just because something is "baked in" doesn't mean you can't get similar functionality from other libraries in a more ala-carte fashion.
The last thing I did in D3 probably would have taken several times more effort with raw SVG and JS, I expect. I couldn't find a higher level graphing library that would let me do what I really wanted at all (a custom radial graph that had fairly complex user interaction), and D3 was a perfect sweet spot I think.
It gives you a whole lot of helper functions that really speed things up, data binding, animations, transitions, etc.
For the vast majority of data visualizations that are of the standard type, d3 is a not a scalable way to do it. The lack of high level abstractions means developers can't be as productive can be, and the code base implemented for one svg visualization is likely not usable for another, unless you put abstraction wrappers around it, which is basically nvd3, or other d3 wrapper libraries..
Yeah, but then you just end up making another charting library which is less flexible and limited by the constraints forced by your abstractions. There is a fundamental reason why D3 has remained relevant for so long in an ever-changing JS/Web landscape.
If you want reusability, build your abstractions or use a charting library, but recognize that this will in-turn limit the flexibility of your reusable code.
You can't have your cake and eat it too. It's the very reason why D3 is still so relevant today.
you basically re-iterated what I said... the d3 wrapper libraries are likely sufficient for 85% of the use cases out there. For the others, you either do everything in D3, or you extend those wrapper libraries to give you what you need.
Not exactly. "Extend those wrapper libraries" is not at all trivial or easy because when the wrapper library / charting library creates abstractions, it also places some limitations on the overall customizability. So when the wrapper or charting lib isn't cutting it, trying to shoe-horn the feature you need is not always easy and usually involves ugly hacks that reduce the overall simplicity of the code if you had just rolled your own D3 implementation from scratch.
The difference is between tweaking the wrapper library or write everything from the ground up because one can not deal with tweaking the wrapper library.
I had a similar experience, off the shelf didn't do what the customer wanted, so I delved into D3, which to be fair has the strangest API on first glance.
After learning how it works, and more importantly why, it's more obvious why it's useful. It's a chart building toolkit, not a chart builder, and you can dream up all sorts of interesting things with it.
The upside is that the author has a huge library of examples you can build from [0]. It's a great tool!
SVG is tied closely to CSS, so you can go in your CSS and create a style for your D3 graphs and do things like:
.chartline { stroke-width: 3px; color: red; }
D3 has some convenience functions in JS for creating SVG, but you don't have to use them, you could write SVG just like HTML, it will look more like this in the DOM:
Sounds like an issue for the board of directors. Do you have a board of directors? If so, I suggest reaching out directly to board members one-on-one to raise these issues with them.
We don't have one. I need to either find a way to fix it or quit. I've taken a lot of the advice on here and I'm actually feeling hopeful for the first time in a long while.
Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010.
And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork.
In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come.
For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3]
- your own blog on a domain you control
- effortless crossposting to bluesky, mastodon, threads, linkedin, and others
Then micro.blog is a great solution!
It follows the POSSE principle: Publish on your Own Site, Syndicate Elsewhere.
see: https://micro.blog/about/crosspost