jwngr

I clearly should've done some more user testing ;) I think that's a great suggestion and would be much better than showing an error message. I'll update that once I have some time when the server isn't crashing!

I'm definitely not the first to think of it or build a tool for it (lots of similar projects gave me inspiration), but I think I'm the first to make it really fast and with a nice usable UI. And to actually open source the code so others can build it themselves.

Can you tell me more about what you mean by filtering by mutual paths?

[copy of answer from below] The Wikipedia database doesn't differentiate links which appear in the main article versus in the sources or categories sections. It's possible one of the intermediate links is in there. You sometimes need to do a CTRL+f in "View Source" to find the link. Also, the latest Wikipedia dump is from February 2nd, so it's possible the link has been deleted since that date. I'll regenerate my database when the new dump lands in early March.

Yeah unfortunately I don't know of any way to differentiate the different types of links. Wikipedia's pagelinks database doesn't different them. I agree it's undesireable but I just cannot figure out how to cull them.

Unfortunately I'm not aware of a way to distinguish between the two. Wikipedia stores both types of links in the same database. I would love to cull out all the links in category boxes and sources. If anyone has any ideas, let me know!

I'll look into it. Interestingly, I'm using[1] one of the default d3 color scales, which I assumed would be color blind friendly out of the box.

[1] https://github.com/jwngr/sdow/blob/a2699dc95d884ec64a4641630...

Yes, Sthephen Dolan's project (along with others) was definitely an inspiration for me! Although, I like to think I made a lot of performance and design improvements over his work. I used to have an acknowledgements section in my README with his name in it, but I seemed to have destroyed that. I'll make sure to give credit where credit is due and list all my inspirations.

I considered this and may eventually add an option to ignore those kinds of pages, but I ultimately felt like the current mode remains more true to my goal for the project which is to traverse the links as any human would be able to. By the way, the two pages with the most incoming links are "Geographic coordinate system" (1,047,096 incoming links) and "International Standard Book Number" (955,957 incoming links).

Glad you found one of the Easter eggs :D

The graph visualization / performance is definitely not ideal. I spent a ton of time trying to make d3 more performant and layout the graph more nicely, but ultimately I just had to cut my losses and go with what I had. I do think there is room for improvement and I'll look into your suggestion, which is something I didn't consider. SVG export is also a great idea!

The Wikipedia database doesn't differentiate links which appear in the main article versus in the sources or categories sections. It's possible one of the intermediate links is in there. You sometimes need to do a CTRL+f in "View Source" to find the link. Also, the latest Wikipedia dump is from February 2nd, so it's possible the link has been deleted since that date. I'll regenerated my database when the new dump lands in early March.

I think this is going to be extremely computationally intensive. One of the big performance wins I got when designing the search algorithm[1] was visiting as few nodes in the graph as possible (which I did via a bi-directional breadth-first search). To find the most distant node, I'd need to traverse the entire graph, which consists of almost 6 million nodes. It can be done, but it would take minutes, hours, days, ...

[1] https://github.com/jwngr/sdow/blob/a2699dc95d884ec64a4641630...

Creator here. Six Degrees of Wikipedia is a side project I've been sporadically hacking on over the past few years. It was an interesting technical challenge and it's fun to play with the end result. Here's the tech stack:

  * Frontend: React (Create React App)
  * Backend: Python Flask
  * Database: SQLite
  * Web (frontend) hosting: Firebase Hosting
  * Server (backend) hosting: Google Compute Engine (it runs fine on a tiny f1-micro instance)

All the code is open source[1] and I'm happy to answer any questions about building or maintaining it!

[1] https://github.com/jwngr/sdow

Not a built-in way per-se, but you do have a handful of options. You can use a third party scheduling service like https://cron-job.org/. You could also use something like https://cloud.google.com/solutions/reliable-task-scheduling-... which uses Google App Engine and Cloud Pub/Sub. We actually have a sample that shows just this (HTTPS function using an external cron job service): https://github.com/firebase/functions-samples/tree/master/de...

(Firebase engineer here)

The old SDKs will continue to work! We worked extremely hard to make sure everything was backwards compatible with them. We most certainly do not want to break any existing customer apps. Check out the migration guides [1] to get your app updated to the new SDKs.

We understand migrating is not easy or always convenient. If you run into issues or something that used to work seems to be no longer work, please let us know. We will be giving you advanced warning if and when things get turned off.

[1] http://firebase.google.com/support/guides

That's what the Database Security Rules [1] are for. If you want to learn more, check out my I/O talk tomorrow called "The key to Firebase security" [2].

[1] http://firebase.google.com/docs/database/security [2] https://events.google.com/io2016/schedule?sid=af641ff7-0bef-...

Our iOS SDK can be used in both Objective-C and Swift: https://www.firebase.com/docs/ios