Borja Paz Rodríguez borjapazr

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

~~Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.~~

Create Root CA (Done once)

Create Root Key

Attention: this is the key used to sign the certificate requests, anyone holding this can sign certificates on your behalf. So keep it in a safe place!

openssl genrsa -des3 -out rootCA.key 4096

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

Follow standard conventions.
Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
Boy scout rule. Leave the campground cleaner than you found it.
Always find root cause. Always look for the root cause of a problem.

Design rules

HTTP redirects with Angular Server Side Rendering

This service assumes that you followed the SSR receipt at ng-cli (i.e. you use the '@nguniversal/express-engine' package).

HOWTO: Create Your Own Self-Signed Certificate with Subject Alternative Names Using OpenSSL in Ubuntu Bash for Window

Overview

My main development workstation is a Windows 10 machine, so we'll approach this from that viewpoint.

Recently, Google Chrome started giving me a warning when I open a site that uses https and self-signed certificate on my local development machine due to some SSL certificate issues like the one below:

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages

	<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.yourpackage</groupId>
	<artifactId>parentartifactofeverything</artifactId>
	<version>1.0-SNAPSHOT</version>
	<modules>
	<module>module1</module>
	<module>module2</module>

	#!/bin/bash

	case $# in
	0)
	echo "Usage: $0 {start\|stop}"
	exit 1
	;;
	1)
	case $1 in
	start)

	# http://phl.upr.edu/library/notes/SETIChallenge

	use strict;
	use warnings;
	use GD;

	my @seti;

	my $in = 'SETI_message.txt';
	open S, "<$in" or die "Failed to open $in";

	#!/usr/bin/env bash

	# REF: https://github.com/cloudflare/cfssl

	# Change working directory
	cd -- "$(
	dirname "${0}"
	)" \|\| exit 1

	readonly CA_ROOT_CERT_KEY="ca-root"