Using progressive enhancement, unrot∙link will check for link rot in real-time, and fall back to the Internet Archive to restore broken links.

See the web site for details on how it works, and the source code if you wish to host your own implementation.

Goodreads' data is…not good. So I've returned to one of the oldest tricks in the book: good old scraping - and actually end up with pretty decent data.

Hey there \o. original author of said hubba article :)

Just wanted to offer some missing bits you might find interesting, specifically, the third function you don't recognise is the random function from the original Tetris on the NES. It comes from the article[0] that went through all the asm of the NES Tetris cartridge.

And yup, that first one is quite quite terrible for random - it came from some of the first results in StackOverflow intentionally looking for something that was overly simple and "bad" at random.

But really the article was about testing and visualising how your own random functions might be.

[0]: https://meatfighter.com/nintendotetrisai/#Picking_Tetriminos

I've put a working copy up on https://www.isthe.link/browser/ (I worked on the JavaScript that replicates the browser).

We're (the team) are waiting to hear from the Ops folk at CERN to get the server to stop 503'ing. Until then, you can try it out above.

The source code will be available too once we get the go ahead.

Server should all be back, and surviving HN hugs. No need to use this URL anymore

Great work! Already celebrating at 501? :)

PUT, DELETE, etc were part of HTTP/1.1. The WorldWideWeb browser (later called Nexus) was created during the time of HTTP 0.9 (or rather the versionless HTTP).

I spoke to a few of the people involved in the original 1990s project and one big issue was authentication into servers was way too complex.

The simulation (I wrote the JavaScript for it), writes to local browser storage (IndexedDB), the original WorldWideWeb would write to disk (networked or local).

This doesn't work for everyone, but if you find allow yourself time, trying to solve specific problems you face (asking: could I automate this? Could this be simpler?) is a great way to get better - and how I learnt my way through bash.

I recently released https://terminal.training (paid course for 4 hours) which is just for this kind of question, but I've also started a free mini email course (same URL) that tries to share some of the CLI shortcuts I've come to rely on over the years.

<3 there's a "keep me honest: donate" button at the bottom of my blog.

Done. And I stipulate that you spend at least some of the money on a beer. Cheers.

Let me suggest you move it to a more prominent position.

/unsolicited advice

Playing devil's advocate:

PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.

FastBoot, I suspect, will dictate how I code my application/server side logic.

On the surface, it looks like the cost of FastBoot is higher.

The benefits are, I suspect, are higher though: single code base, reusable views, etc.

Why not, instead, show an ellipsis in place of the majority of the subdomain leading up to the domain and increase opacity of the domain compared to subdomains and the pathname.

This is similar to what happens when the path is too long for the omnibox, but simply the effect of putting the domain as far left (in the omnibox) as possible.

i.e. instead of seeing:

[ www.mybank.com.credicards.wt3_segment_secure.login.html.evil-site.com ]

You see:

[ ...html.evil-site.com/ ] (where "...html." are semi-opaque).

I mocked up what I'm suggesting here: http://remysharp.com/2014/05/04/on-chrome-hiding-urls-to-pro...

It's something I did give a little thought to, but it's simply that all new subdomains create a new router that only allow for static content and directory listings. So nothing's being executed server side.

A gave a little thought outside of that, but not much. I'm all ears if I've accidentally opened up a bag of worms!