This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<!-- not sure which one it is, so set both --> | |
<key>Ensemble</key> | |
<dict> | |
<key>Enabled</key> | |
<true/> | |
</dict> |
This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
⚠️ Note 2023-01-21
Some things have changed since I originally wrote this in 2016. I have updated a few minor details, and the advice is still broadly the same, but there are some new Cloudflare features you can (and should) take advantage of. In particular, pay attention to Trevor Stevens' comment here from 22 January 2022, and Matt Stenson's useful caching advice. In addition, Backblaze, with whom Cloudflare are a Bandwidth Alliance partner, have published their own guide detailing how to use Cloudflare's Web Workers to cache content from B2 private buckets. That is worth reading,
const semver = require('semver'); | |
const browserslist = require('browserslist'); | |
const polyFillService = require('polyfill-service'); | |
function browserVersionMatches(browsersListVersion, polyFillServiceVersion) | |
{ | |
// Do some quick and easy checks first | |
if (browsersListVersion === polyFillServiceVersion) return true; | |
if (polyFillServiceVersion === '*') return true; | |
if (browsersListVersion === 'all') return true; |
I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).
A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.
And it was a dream!
All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.
And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go
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.
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.
defmodule Config do | |
@moduledoc """ | |
This module handles fetching values from the config with some additional niceties | |
""" | |
@doc """ | |
Fetches a value from the config, or from the environment if {:system, "VAR"} | |
is provided. | |
An optional default value can be provided if desired. |
{ | |
"AWSEBDockerrunVersion": "1", | |
"Image": { | |
"Name": "<AWS_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/<NAME>:<TAG>", | |
"Update": "true" | |
}, | |
"Ports": [ | |
{ | |
"ContainerPort": "443" | |
} |