Given the official statements describe the process as
"Today (12/6) at 03:07 JST, as a result of the beacon direction search, the capsule landing point has been estimated. Now, we will search by helicopter."
and
"Today (12/6) at 04:47 JST, as a result of the helicopter search, we found a capsule in the planned landing area!"
I don't think the beacon "transmitted location" and the headline seems accurate.
Not to mention the region of the world selected has a seventy year history of searching and mostly finding stuff that falls from the sky, it's part of the globes largest (land area wise) long range weapons testing complex dating back to post WWII British testing.
In the event of unexpected beacon failures, etc. there's a pre existing network of interlinked upward facing cameras and tracking software designed to assist finding rockets, meteorites, or plummeting blue whales.
> I don't think the beacon "transmitted location" and the headline seems accurate.
From TFA:
> The capsule then began transmitting a beacon with information about its position.
It reads to me like it absolutely was transmitting its location (why wouldn't it? I have a GPS receiver in my watch with 1-metre accuracy). It just took an hour or two to retrieve it because they waited until it was light.
"However, a capsule on the ground in the dark will be very difficult to find. Therefore, we will search for the beacon signal, as mentioned in the previous article. Five antennas will be installed around the expected landing site, which will each record the direction of the signal. These directions will be reported to the headquarters and when plotted on a map, the intersection will reveal the position of the signal source (principal of triangulation). This method is the same as used for Hayabusa, but for Hayabusa2, considering the area we needed to cover and potential troubles, we decided to increase the number of stations by one and search with a total of five stations."
From memory they were looking at worstcase scenario of ±10km in a strip of search area. They were hoping to narrow it down with visual and other observations.
Guess we'll have to rely on other reporting to find out.
It seems like a very versatile framework, but nowhere I can find any recipe or guide of a very simple case - how to combine different types of charts in one? Like simple line chart overlaying the bar chart. It seems to be only possible by rendering them as completely separate charts and then overlaying one on top of each other in DOM? Which seems hacky.
D3 is pretty low level - geometry and binding data to create DOM elements. It’s not really a charting library - look for libraries built on top of it for abstractions like “composite chart” or whatever.
So yeah at the D3 level you would just draw one chart and then draw another chart on top, probably each wrapped in a <g> if you’re using SVG. Maybe they’d share X/Y scales.
Look into scales, you can put whatever you want in the same chart by positioning it using the same scales. https://github.com/d3/d3-scale
You can use that same scale to draw just one set of axis.
Need multiple Y axis?
Create two Y scales with the same range, one X scale.
Also I think it's good to understand that "chart" is not really a concept in D3. You just get all the elements of a chart which is why it is so awesome as you get to compose your own chart just the way you like it!
Can’t you just add both the bars and the path to the SVG you’re rendering to? (I assume it’s the same for a canvas context, although I’ve never used one with d3.)
From my experience, if you want standard charting (bar, line, pie, etc...) you’re better off using either a different library like Highcharts, or something higher-level that’s built on top of D3
It's a search engine that searches other search engines for you with a focus on privacy (e.g. provides direct links to results instead of Google-style tracking links, etc): https://en.wikipedia.org/wiki/Searx
"A metasearch engine (or search aggregator) is an online Information retrieval tool that uses the data of a web search engine to produce its own results."
Telegram has off-by-default E2E encryption with a less vetted algorithm that only works for 1:1 chats, and less focus on minimizing server knowledge. That's clearly not
Telegram is not opensource, Signal is...and yes you can setup your own server with Signal. Why trust a Closed-source-Software? Do you even know that it is encrypted?
The encryption takes place in the client though, which you can verify by looking at the client source code. I find your comparison with Facebook a bit lacking, a better one would have been by looking at the Firefox code to verify if https traffic is encrypted.
It looks like they want websites to do the following: whenever your website goes under a drastic change, serve the previous version of the website under a subdomain, and redirect all 404s on the newer version to the subdomain. More drastic changes in the future may potentially redirect 404s to previous subdomains/versions like a chain. At least that's my understanding of it.
It is poorly explained. I had to read the about page.
Instead of 404s, you redirect to a previous version of your webserver (that is still running), which then instead of 404s redirects to a previous version of your site (that is still running), and eventually it tries the wayback machine.
So never pull down a previous version of your website, and issue 302s to that?
I’d like to be able to show any eventual 404 from the current version of the site though, which means there may need to be a wrapper around the terminal site (or more reasonably, code that runs locally on the server to find the right page URL and 302 directly to that rather than a client round trip for every version searched).
You are not alone there. I tried multiple times to understand what the author tries to convey, without being really sure to grasp it.
At first I thought that it was simply some advocacy for taking the time to route legacy content using 302, but it also seems to be some sub-domain trick with years…?
The idea is to keep all old versions of your website, and when somebody requests an URL, try to find that URL on all versions of your websites (starting with the newest), and only return 404 not found if the URL does not exist on any of the archived versions.
In a nutshell it is simply allowing you the ability to present fallback content with 302s but with a more gentle redirect than a 301, which tells you it is permanently gone.
If it would be this straightforward, why doesn't Postgres do this directly?
There is the misconception that tuning Postgres is just about the memory and CPUs. It's also a lot about the usage patterns, whether you use or not a connection pooler in front (note: you should), about your OLTP-ish or OLAP-ish pattern, about the disk speed, disk technology, types of queries that you do.... it's, unfortunately, not simple at all.
And the problem is that it's easy to think "oh, even if I get it close to right and maybe improve performance by 20% instead of 50%, that's still ok". But the problem is that a bad tuning may decrease your performance significantly. So it's a matter not to take it lightly.
