remysharp

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

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

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

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.

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.

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!

File an issue, and I'll add that - and yeah, even better, if you can do a pull request it saves me writing it :)

I used to try to do that with my projects, but I found keeping the gh-pages branch in sync with my master just enough of a pain that it quickly got neglected. I'm not saying you shouldn't, and personally, I'd rather there be a hosted example of the repo - I just made 5minfork for those ones that (I often found) didn't have the live example.

If you don't mind, I'll pinch that and whack it on the index.html page.

It's been mentioned, but the Khan editor gets around the problem because its a close environment - and I can't run the code the user submits in to a worker easily.

The while problem has been raised before, and there is a tiny bit of protection (we parse the code line you're on, and if its a while loop, it's supposed to ignore live execution - though clearly that's not enough). It's true to say I'm still looking for a solution :)

That all said, you dont lose your work if you hit this kind of loop and it hangs the UI. The reason is two fold: 1) jsbin, since it was released in 2008 always saves code to localStorage, but more importantly, 2) it's saving your code to the server AS YOU TYPE - so you hit refresh, and you get you bin back (and the correct URL and saved in your history if you're signed in, etc).

I'll reply about the while stuff separately, but jsbin shouldn't and doesn't prompt anyone to create an account. The only two features you don't have access to is the history, and the /[user]/last shortcut.

Everything else, including saving, is available as a non registered and anonymous user.

Just spotted an increase in pull requests and auto-generated user pages from the curl command and spotted HN had found this project.

Thought I'd chime in an reply to a few of the comments here.

1. Will it be online in 10 years? Yes - .org domains can only be registered up to 10 years in advance (though we've had donations going up to 2032). Check `whois mit-license.org | grep Expiration` and you'll see 16-Oct-2021 (I need to add this year).

2. "This is bizarre...just Host All The Things!". Partially you're right, but if you read the very first line of the README.md I explain why I wanted to host it:https://github.com/remy/mit-license

TL;DR: because I nearly always forget to include the file, and if I do, I usually forget to change it from project to project, and from year to year (also why I don't like to the opensource.org url - the date is a placeholder).

This would let me include just the url in my script headers (and someone else noted, and you're right on, what if you're offline? Arguably, the "mit-license.org" part of the URL should help the reader know what the license is - even if they can't read the contents).

Like I said, just chiming in. I'm not saying anyone here is wrong or right - it's just something I made for myself, and figured it might be useful to more than just me.

It was down for about 20minutes whilst I upgraded and ran some diagnostics on the database.

Stylus and LESS are being rendered on the client side - so there's no round trips just to render your HTML in the page. SASS and SCSS was on my list (or SASS was) but there's no client side solution. Feel free to contribute here, I'm definitely interested in adding those processors: https://github.com/remy/jsbin/issues/176

Not yet, but there will be. For the moment, anything you can set in CodeMirror's config ( http://codemirror.net/doc/manual.html#config ) you can set via `jsbin.settings.editor.[key] = [value]` and it'll apply it to the JS Bin editors.

There's a couple of others, and docs will be coming soon. In addition, there's an exposed API that allows you to point JS Bin to a JSON file and it'll load in and save those settings - which is useful for starting a class for teaching where you want the editor in the same mode across all the students.

It's called "the spike", but it's nothing more than EventSource triggering an event to refresh or inject.

The client code (for both remote rendering & codecasting): https://github.com/remy/jsbin/blob/master/public/js/spike.js

The server side: https://github.com/remy/jsbin/blob/master/lib/spike/index.js

Very simple, but requires an event based server - so Node was the obvious choice for JS Bin.

Yeah, for some reason the url posted was just a full page bin, ie. the output of my saved code. So I've tweaked the page a little so it'll redirect to the /edit version so you can actually see JS Bin.

I thought I'd post here with some of the features jsbin (version 3) comes with. There's a blog post being prepared too, but pending that.

The big change in jsbin is the live aspect:

* Start typing, your code is saved and continues to save as you type.

* As you type the live output is updated automatically.

* Open the the full preview url (without /edit) in any other window - be it browser or mobile phone, and that will update in real-time too. So you can edit on your desktop, and the rendered output will appear on you mobile devices.

* If you share the url with /watch on the end, people can watch what you type in real time.

More detail will be in the post later today. I'll try to answer more questions here if they come up.

It also continues to be completely open source: http://github.com/remy/jsbin - so welcoming any contributions :)

Download will only be downloaded in the initial state of jsbin - i.e. if there's nothing to download. When you type, it'll save your bin and you can download that. You can also directly access each panel on the url, like jsbin.com/abc.css or jsbin.com/abc.less, etc.

It's a setting in CodeMirror which jsbin and jsfiddle both make use of.

However, if you open the devtools console in your browser, and run: `jsbin.settings.editor.smartIndent = false` it'll disable the indenting. The setting is sticky, so you it should remain whilst the data is stored against the browser.