Issue 3: Terminal tips & tricks, DevTools + Service Worker Updates, Add-to-Homescreen Emulation, Google Compute Engine, Web Push
Totally Tooling Tears is a new companion to Matt and Addy’s YouTube show Totally Tooling Tips. It’s a raw weekly brain-dump of notes, issues and workarounds we’ve found building apps and libraries over the last 7 days.
Chrome DevTools Updates
Service Worker Debugging
Last week we shared some frustration about there being three different places you can debug Service Workers in Chrome (Resources, Sources and about:serviceworker-internals). As of today, that’s improved! Yay.
The `Force update..` Service Workers on reload checkbox has now been moved from the Sources panel..
Over to Resources > Service Workers with the rest of our SW debugging. It’s also been renamed the simpler `Update on reload`.
In addition, some other minor tweaks have been made like removing the debug on start option from this panel and applying some text adjustments to the labelling. Contrast the above newer view to what we have in stable today:
Emulating “Add to homescreen”
When you’re building a Progressive Web App, you’ll find yourself using a Web Application manifest — a JSON file that allows you to control how your user might see your app in areas like the phone homescreen.
Until now, our team have used tools like Mounir Lamouri’s Web Manifest Validator (which is excellent btw) for making sure our manifest doesn’t contain invalid entries. This is useful, but half the time I totally forget to check it. This gets painful when you’ve deployed your app, are checking it out on your device and your `add to homescreen` action results in…none of your custom icons being picked up.
What might be even more low-friction is having something directly in the DevTools that helps keep you on the right track. Canary now includes a “Trigger add to homescreen” emulation option, available via the menu in Device Mode:
If you happen to have a manifest that doesn’t meet the expected criteria, you might get an exception like the following in your Console:
If however you do have a valid manifest and everything’s sitting pretty, you’ll get the ‘Add to shelf’ prompt on desktop that looks like this:
This is already so useful and we’re glad it’s been added directly to the tools themselves. Thanks DevTools team ❤
Built-in screenshot support..what?
If you’ve been paying attention to the other screenshots, you might have also noticed that there’s a work in progress feature called ‘Capture screenshot’ in the Device Mode menu. Our designer Max tells me that this still has a bunch of work to go, but does currently export non-high res images of your current view. It looks a little like this (we have a Preview window open in the back showing the exported image):
For the last few months I’ve been manually using OS-level screenshot tools for grabbing shots from Device Mode and this might come in handy.
Command-line Tips
Earlier this week, Wes Bos shared a great terminal tip about using curly brackets to rapidly create multiple files with similar names. This is better known as brace expansion and I’d completely forgotten it was a thing:
One of the neat things about it is that it can easily be integrated into workflows for other tools, like installing modules using your package manager, creating directories, expanding the alphabet for filenames etc:
If this type of thing interests you, also do look up parameter, pathname expansion and arithmetic expansion as they’re all super interesting too.
A few other useful tips:
- Run a command with the arguments from a previous one using !!:*. Imagine creating a new directory with `mkdir /path/to/thing`. `cd !!:*` will cd into this directory by piping the second argument back through. Less useful is also !!:p which will just print the last command you ran back out.
- !string will execute the last command starting with the keyword “string”. So, !npm would find the last instance of npm you ran and run it with whatever arguments you supplied it.
Terminal utilities
Besides our text editors and browsers, the terminal is one of those places we spend a lot of our time in. Something I’ve been struggling with is how much time I’d actually save by moving more of my workflow from things like Finder or the browser directly into the terminal. Some thought experiments:
You could use ranger on OSX with iTerm2 and imgcat to get a file browser:
You could use `curl -4 http://wttr.in` to get a summary of the weather:
or tools like hn-cli to view Hacker News in your terminal:
Again, whether replacing more of your GUI apps with terminal equivalents makes sense really depends on how you prefer to consume content. I’m still figuring out what works best.
Deploying Ember.js + FastBoot apps to Heroku
First, we have to give props to Tom Dale for the excellent new Ember FastBoot user guide docs — they’re well thought out, cover lots of questions we ran into last week and are worth checking out.
After EmberConf, it was exciting to see Heroku also offer up a FastBoot compatible buildpack for deploying apps built with Ember’s CLI. It was straight-forward to deploy their getting started project and even new CLI projects with the buildback set could be deployed without issue.
For the Ember Progressive Web App I’ve (Addy) been building..it sadly wasn’t quite as straight-forward. I wanted to try getting gzip (ember-cli-deploy-gzip), HTML minification and a few other basic web performance optimisations added and deployed on top of my Ember CLI + FB project. Unfortunately, this ended up costing me a day with numerous failures in my Heroku logs that didn’t provide much useful insight. I don’t blame Ember for this as all of my local FB builds ran without issues.
I’m still debugging what went wrong, but one thing I would love to see is a buildpack (or guide) that does include additional deploy-time optimisations working with FastBoot on Heroku. Until then, I was able to deploy a version of my app without these optimisations in place. Better luck next week!
Matt’s Google Compute Engine experiences
Works, but Very DIY
I’ve been toying around with getting Docker to work for the deployment of my site. I’ve already using it at the moment but it’s super rough around the edges to the point where I hate updating my site — hence a revisit.
Won’t lie, I was hoping Google Compute Engine would have added some new features to make this a bit easier but alas, no joy.
Docker Containers
Docker hub is awesome, it builds my docker container and publishes it on it’s registry when ever I push to github.
The next step would be to take this update and auto-deploy to production (obviously with some tests etc to ensure it’s all healthy). To me this would be GCE’s job — but I can’t find a way to do it out of the box and as a result there are few things I’ll have to do:
1. Pick a VM instance, start it up on GCE, then right a startup shell script to tell it what container to install and run
2. Write some logic that will detect a change to the docker container and update all of the VM’s. The most basic solution is a daily cron job. The “proper” way to do this would be to set up docker web hooks to ping an endpoint that can get a list of VMs and update them accordingly
These two things aren’t necessarily hard, but it’s cumbersome and feels pretty boilerplate.
Anyway, onwards and upwards.
Lets Encrypt
I’ve been thinking about how to manage SSL certs for my site. At the moment it’s all very manual since they update once a year and I want to move to Let’s Encrypt.
The real issue is that, once I get certs, I need to store them somewhere. Once they are renewed, I should probably store the update and when there are multiple VM’s they should all get the update and they should all pull from the same place.
What I was hoping for was a way to set up the certs on a load balancer and this is something that you can do on GCE with a HTTP load balancer. However, I think the HTTP load balancer only works with “Group Instances”, which seems to require a minimum of 3 instances. I only need one of the
small instances.
Ultimately it’s looking like I’ll have to stash certs in Google Cloud Storage, have a cron job that regularly checks for expiration and / or updates and hope that nothing bad happens . . . .
Ideal scenario? I can add a load balancer that handles HTTPS certs and there is a one click button to get certs for my site enabled.
No Environment Variables
This is a little weird. I wanted to share some data with my VM’s which you can do with metadata. But all this does is make it such that you can use curl
to a special internal API on the VM to get the values out.
This is a slightly pain but you basically have to write code to pull these values and use them as you wish.
Great if you want some fields accessible but not to the environment, but not sure how often that is a concern and flip side, if they could be added as
environment variables just for the start up script that would have covered my use case and may be a tad more secure.
The UX for the Dashboard
The UX for GCE is … difficult.
There are two drawers:
..and the favicon changes depending on the current section you are in, something I didn’t think I’d care about until my tab bar gets overloaded and I only see the icons….which keep changing:
..and I’m not sure what icon I’m looking for anymore.
Push on the Web
There was an interesting discussion raised by @sil on why is it that Facebook doesn’t support push on Firefox.
I don’t know the answer to that question, but it got me thinking about the general state of push on the web and I wanted to throw in a mini update from how I see it.
The Client Side API
The client side JavaScript API to subscribe a user to push messaging is the same across Chrome and Firefox (In stable on both). The one difference is Chrome, unfortunately, needs a proprietary property in a web app manifest.
But for arguments sake, you can write the same JavaScript and it’ll work.
This is going to change soon — to VAPID.
VAPID is essentially a way of registering a web app to a push service. I don’t know much about it tbh, but I’m hoping it’ll replace the need for the GCM parameter and we will be identical on both Firefox and Chrome.
(That’s 1 difference)
Server Side
At the moment the server side is a tad tricky.
Firefox is using the right API to send a push message from a server to a users device. They are using the Web Push Protocol.
Chrome is relying on GCM to send push messages and as a result requires developers to user the proprietary GCM API. There are enough differences here that it’s two distinct code paths, but it’s pretty manageable.
Chrome + GCM will hopefully be moving to supporting the web push protocol in the future, but it’s not there yet.
(That’s 2 differences)
Push Payloads
Payloads in Push are the latest hotness in push and as with anything that’s the latest hotness on the web, there are some gotchas. Push payloads need to be encrypted and the spec has gone through several revisions as the encryption process has been ironed out.
Firefox has been implementing push payloads as the spec has progressed, which has no doubt resulted in super useful feedback, but it does mean there are multiple versions of payload support across versions of Firefox.
Chrome only supports the latest spec. (That’s 3 differences — and debugging push encryption isn’t easy either)
My Point?
The push API is awesome and having Firefox and Chrome work on these early implementations has lead to incredibly useful feedback from developers and users.
But it comes with the cost of inconsistencies and for that’s where I’d have concerns if I was asking a business to full steam ahead with push until they were certain they could commit to following changes and making the required updates.
FF Profile Setting
I was super excited when I found this nifty trick on the web-push library that marco-c has been working on over Mozilla. First the back story. I’ve been wanting to find a way to test the push API on browsers, especially
on Travis. the one problem with that is preventing the permission dialog for
notifications.
Marco uses a set of user preferences and API’s (which I can’t find much
info on) to do this on Firefox.
HSTS + Fetch != HTTP -> HTTPS Upgrade
Along with my push testing, I’ve been testing sw-toolbox across a range of
browsers and I noticed a difference between Chrome and FF Beta.
If I made a fetch request for ‘http://developers.google.com/', on Firefox
that fetch would appear in SW ad ‘httpS://developers.google.com'. Notice the HTTPS.
Turns out Chrome isn’t making use of HSTS headers to upgrade requests through fetch whereas Firefox is — Sad face. Raised a bug on this and hopefully it’ll get looked at soon.
Sweet reads / tips from Twitter this week
- DevTools: Line Level Profiling — Find out how long a piece of JavaScript took to execute (Umar Hansa)
- Developers can run Bash Shell and user-mode Ubuntu Linux binaries on Windows 10 (Scott Hanselman) — We were lucky enough to get a preview of this at Microsoft a while back and are stoked to see it finally shipping!
- IndexedDB: the good parts (slides — Nolan Lawson)
- Get faster `git status` by upgrading to git 2.8.0 and run `$ git config — system core.untrackedCache true`(Sindre Sorhus)
- A blog post on how to get rid of annoying GitHub notifications and activity feed items (Nicolás Bevacqua)
- GitHub: Saved replies have launched. Now you can save your most commonly used replies (Big props to Monica who wrote an extension predating this shipping)
- Safari Technology Preview — a new way to try features and fixes that are coming to Safari that’s a lil more streamlined than the WebKit Nightlies.
New Totally Tooling Tips
In case you missed it, we also published a new TTT mini-tip on caching files offline with Service Worker and the sw-toolbox library.
