Bookmarklets, little snippets of JavaScript that you keep around as a bookmark, are useful. They let you execute some JavaScript to perform almost any action you want on a website.

Some bookmarklets I use on my desktop browser include:

1. A collection of bookmarklets that let you change the playback speed of most embedded videos.
2. A bookmarklet to manipulate the URL of the page you're visiting.
3. A bookmarklet to save the current page's URL to pinboard.in.

For years, I thought I was restricted to only using bookmarklets in my desktop web browser. I hadn't effectively used mobile bookmarks before and thought that clicking them would be a huge pain.

It turns out, I was wrong! I recently learned that if you start typing a bookmark's title into your mobile browser's location bar, it will let you select the bookmark. This means you can easily execute a bookmarklet just by starting to type its name and clicking it when it appears. This "search for bookmark in location bar" technique works with at least Google Chrome and Brave running in Android.

Below are the two bookmarklets I use regularly on my phone. They exist to bypass paywalls.

This one prepends http://archive.is/ to the current URL:

javascript:(function() {window.location="http://archive.is/"+window.location.toString();}())

This one changes theatlantic.com to theatlantic.com. (though it no longer gets around their paywall):

javascript:(function() {window.location=window.location.href.replace(/theatlantic.com/, 'theatlantic.com.');}())

To get them onto my phone, I added them a bookmarks on my laptop's Chrome and synced them to my mobile phone. Once in my mobile Chrome, I edited the bookmark in mobile Chrome, copied the code, and pasted it into a bookmark in Brave.

I type three characters into my mobile browser's location bar before I can select either of these bookmarklets. That is quicker than editing the URLs by hand and has improved the experience of reading articles on my phone.

I was recently adding a feature to an internal web UI that caught all unhandled JavaScript errors and reported them to the backend service. The implementation went smoothly with most of the effort spent figuring out how to test the code that was reporting the errors.

If the error reporting failed, I didn't want to trigger reporting another error or completely lose that error. I decided to log a reporting error to the console. I wanted to write a test showing that errors reporting errors were handled so that a future me, or another developer, didn't accidentally remove this special error handling and enable a never ending cycle of of reporting failed reporting attempts.

It took me a while to figure out how to do this. I searched the web and found various articles about using Jasmine to do async tests. They were helpful but I also wanted to mock out a function, console.error, and assert that it was called. None of the examples I found were explicit about doing something like this. I forget how many different approaches I tried, but it took a while to figure out the below solution.

Here is the code I wanted to test.

function reportEvent(event) {
  return fetch('/report-event', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({name: 'ui name', ...event})
  }).catch(function(e) { console.error('Problem reporting event:', e)});
}

It takes an incoming event object and merges it with a default value and posts that to the backing service. fetch returns a Promise and the code handles errors by calling catch on it and logging.

Below is what I eventually came up with for testing the error handling feature of reportEvent.

describe('reporting events', function() {
  it('logs errors', (done) => {
    spyOn(console, 'error').and.callFake(() => {
      expect(console.error).toHaveBeenCalled();
      done();
    });
    spyOn(window, 'fetch').and.returnValue(Promise.reject('error!'));
    reportEvent({level: 'WARN', msg: 'ERROR!'});
  });
});

This uses spyOn to mock out fetch and console.error. The fetch call is told to return a rejected Promise. The console.error spy is a bit more interesting.

The console.error spy is told to call a fake function. That function asserts that the console.error spy has been called. More importantly, it also calls a done function. That done function is a callback passed to your test by Jasmine. Calling done signals that your async work is completed.

If done is never called then Jasmine will fail the test after some amount of time. By calling done in our console.error fake, we're able to signal to Jasmine that we've handled the rejected promise.

You don't actually need the expect(console.error).toHaveBeenCalled(); as done won't be called unless console.error has been called. If you don't have it though then Jasmine will complain there are no assertions in the test.

So there we have it, an example of using some of Jasmine's asynchronous test features with spies. I wish I had found an article like this when I started this task. Hopefully it saves you, and future me, some time.

I've read Ben Rady's Serverless Single Page Apps twice now. As an early technical reviewer, I was able to watch and take part in the book's evolution. The early draft was good but the most recent near-final draft was better.

Serverless Single Page Apps walks you through building a low-cost, highly-available, serverless single page web application. It does this on top of various Amazon web services (DynamoDB, Cognito, Lambda, API Gateway, S3). If you follow along you'll end up with a simple web application with authentication.

The book is very enjoyable. The examples are clear and the book is well written. The book uses JavaScript to implement the serverless application. For the user interface it uses plain JavaScript with a bit of jQuery and for the AWS Lambda functions you dip into some Node.js. Serverless doesn't distract you from learning about serverless applications by forcing you to learn new JavaScript frameworks or libraries.

One of my favorite parts of the book is Ben's use of test driven development. The examples provided give the reader a decent taste of the benefits of test-first development. Having the tests helped me when I made some silly mistakes in later parts of the book.

Overall I'd recommend this book to developers who are interested in learning what a serverless application might look like. If you follow along you'll know how to build one by the end and will have a good starting point for diving deeper into the topic.