Here's how I configured a GitHub Action so that a new version issued by GitHub's release interface will build a Dockerfile, tag it with the version number and upload it to Google Artifact Registry.
Before you attempt the steps below, you need the following:
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <link href='https://fonts.googleapis.com/css?family=Manrope' rel='stylesheet'> | |
| <link rel="shortcut icon" type="image/png" | |
| href="https://yt3.ggpht.com/ej3kSN0C9GiHS5wa2zNQ3Pd59UcnpFeYjnGGBJEub1Nagwl6vpoe21oIJKWjBjzqvHDYtUONCw=s68-c-k-c0x00ffffff-no-rj" /> | |
| {%- auth0:head -%} | |
| <style> |
It's quite easy and the same process applies to all Firebase features with minor changes.
In order to deploy you'll need a deployment token (I named it FIREBASE_TOKEN) and it can be
acquired by using the following command
firebase login:ci
| const trackTime = timing => { | |
| const now = performance.now(); | |
| if (!timing.startTime) timing.startTime = now; | |
| const elapsed = now - timing.startTime; | |
| const {duration} = timing; | |
| if (duration != null && duration <= elapsed) timing.startTime = null; | |
| return elapsed; | |
| }; | |
| const delay = (callback, duration) => { |
| // create an IAM Lambda role with access to dynamodb | |
| // Launch Lambda in the same region as your dynamodb region | |
| // (here: us-east-1) | |
| // dynamodb table with hash key = user and range key = datetime | |
| console.log('Loading event'); | |
| var AWS = require('aws-sdk'); | |
| var dynamodb = new AWS.DynamoDB({apiVersion: '2012-08-10'}); | |
| exports.handler = function(event, context) { |
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.
| // array utils | |
| // ================================================================================================= | |
| const combine = (...arrays) => [].concat(...arrays); | |
| const compact = arr => arr.filter(Boolean); | |
| const contains = (() => Array.prototype.includes | |
| ? (arr, value) => arr.includes(value) | |
| : (arr, value) => arr.some(el => el === value) |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
