Right, the travel-time metric is not compatible with a Euclidean R² metric. You can imagine three subway stations in a triangle loop, such that it's a shorter trip to do a full loop on the subway then to walk to a point in the interior.
There's no way to continuously deform a map so that it represents travel times as distance in a plane.
Oh yes, unfortunately, you can't do this perfectly. There are some graphs that cannot be embedded in Euclidean space in any number of dimensions, e.g. a 4-cycle with distance measured by path length. It's a good-enough approximation for visualization purposes, though.
Not really - you have to wait for the subway, it also takes a finite time to travel, and it frequently stops. It can avoid traffic, but the actual MPH can be slower than a car when you include both those things.
Isn’t the point that you have a way to get to a point far away faster than you can get to a point in between? The worm hole thing ist because you can only exit at discrete points so it pulls a single point far away, and it’s sorrounding, closer to the starting point. That’s probably hard to map to a 2D map because there would be some overlap between the different „islands“ starting from subway stations
It has expired. A nice example for why shorter lifetimes encourage a healthier approach to renewals with better monitoring and so on.
Krebs has a (now expired) certificate from Sectigo (were Comodo CA) but with a long lifetime. There's a good chance that it was so long ago nobody remembered it needs to be periodically renewed.
I had to step away from using electron because I encountered segfaults like `Received signal 11 SEGV_MAPERR 000000000060` just on visiting cnn.com and clicking one of their nav links (without much going on otherwise, which I found kinda crazy).
Electron also only recently added support for PDFs, and it's still a little buggy. I was able to get around most of these with pdf.js.
I ended up using a combination of chrome extension for injecting stuff into webpage + rpc to a local node.js server running inside an electron app (for convenience). I only made this for personal use, so I'm ok with <arbitrary_caveat>s.
> because I encountered segfaults like `Received signal 11 SEGV_MAPERR 000000000060` just on visiting cnn.com and clicking one of their nav links (without much going on otherwise, which I found kinda crazy).
Yeah, web browsers have so much compatibility code this does not surprise me...
Js_of_ocaml [1] is a good alternative to BuckleScript for standard OCaml (non-Reason).
For example, it works well with Core_kernel [2] and Async_kernel [3] to provide high-level functionality that is cross compatible between Unix applications and browser applications.
Didn't realize this system used a CVT-like system to generate electicity. I've generally been curious how this system seems to be significantly more complex yet more reliable than many modern internal combustion engine drivetrains. (My personal perception, haven't done much research to look it up).
I also wonder why Apple allows some apps to accept payments via credit card yet others need to use the built in payment solutions?
EDIT: some research later indicates that it's possible allowing a user to sign up outside the app (and outside a webview initiated by the app) skirts around the policy [1], since the user can return to the app and log in, then use their account for payments.
Apps are allowed to use external payment methods for "real world" goods and services.
All digital content (premium features, game coins, file storage, music or video libraries) accessible within the app must be charged through Apple, and the user must not be able to find an alternative payment method from within the app.
> EDIT: some research later indicates that it's possible allowing a user to sign up outside the app (and outside a webview initiated by the app) skirts around the policy, since the user can return to the app and log in, then use their account for payments.
Depending on the precise details of your signup page, this may or may not get banned by Apple if they notice it. It's allowed to sign up users and accept external payments outside the app - but then you must not have links to this payment page from within the app. If the user already has an external paid account, then they can use it, but any first-time users must only see IAP or nothing.
Some time ago Apple threatened to ban Dropbox, because they had a webview for signups, and it was possible to upgrade to a premium account within that webview.
Only certain classes of app's are allowed to do this. From a comment on your linked article, it seems Apple only allows you to do so for physical and non-digital items.
It's just a matter of whether your content is delivered via the app. Netflix, for example, must have users pay via Apple (or outside the app), because they deliver the content in the app. Ebay doesn't require that, since you're just buying something that's going to be delivered to you.
How does it work? Searching for book store (https://www.closient.com/?q=book_store the underscore was autocompleted) gave me results that were 1200+ km away from my current location. Other queries did the same.
I work on Google Search. Having one search engine per country doesn't seem like the correct approach to the problem.
> Every country has a mammoth collection of valid results for your query.
Having seen the corpus of content available from each language, this is categorically false. Consider Wikipedia, which is a fairly ubiquitous information source on the web that provides answers to tons of searches. English documents: 5.4M, Romanian documents: 376k.
Perhaps the solution to the OP's woes is more tools for filtering. This post conflates the ideas between language and country. Search typically returns to you results and search features that are in the query language. Today's solution where filtering is done through query refinement and query operators seems to cover a lot of use cases already.
Further, by having an integrated product, ML models can learn behaviors specific to certain locales where those behaviors differ from region to region, and balance with more universal behaviors that apply to more than one region.
A server made out of Lego probably would not have been seen as the correct approach to the problem by an engineer at AltaVista a few years ago. Search engines by country is just a way of expressing the abstractions that are involved in chunking up search in a way that is orthogonal to building a service chunked around advertizing revenue, English, and Silicon Valley political philosophies.
Or to put it another way, 376k Wikipedia documents in Romanian is about 50% more than the number of articles in the last print version of Encyclopedia Britannica. The dismissal of their significance may express a worldview bubble that is endemic of Google and its business model.
Just because 376k Romanian documents is not enough to train a data center in how to sell chia pets to Bucharestians, doesn't mean that it is not a significant repository of information for actual human beings.
Are you guys working on removing the websites who somehow manage to be on top when you search for an entire class of queries? They are practically empty, they contain 10+ affiliate Javascripts (with which they supposedly make money from clicks?) and are basically a search query aggregators, yet Google haven't removed them yet.
Sorry I can't give examples, but these sites are out there and IMO should be outright banned. They bring zero value to customers and I'd argue that a good part of them are bringing zero value to Google as well -- they utilize some "SEO secrets" to get to the first page of Google without paying a penny.
Agree and, as I work for Seznam, especially agree on the ability to train models properly to satisfy local users. Not to mention that the user can choose what should be the language of the results.
Location: Minneapolis, Minnesota
Remote: Yes.
Willing to relocate: No.
Technologies: Python, Node.js, Meteor, HTML5/CSS3/JS (lots of past frontend work
with SCSS, Rails, Flask, PostgreSQL, MySQL, Mongo).
Some Scala, Java, and Go as well.
Résumé/CV: https://wheat.co
Email: hello@wheat.co
