Skip to content

Instantly share code, notes, and snippets.

I may be slow to respond.

Albert Yu nightire

I may be slow to respond.
View GitHub Profile
maxfierke / cancelable-fetch.js
Last active Jul 17, 2021
cancelableFetch Yieldable ember-concurrency
View cancelable-fetch.js
import { Yieldable } from 'ember-concurrency';
import fetch from 'fetch'; // i.e. ember-fetch. could also use native fetch too.
class FetchYieldable extends Yieldable {
constructor(url, opts = {}) {
this.url = url;
this.opts = opts;
fabiospampinato / build.js
Created May 23, 2021
Fast building + watching + starting + restarting. AKA how to throw TypeScript in the garbage bin for anything other than type-checking.
View build.js
/* IMPORT */
const esbuild = require ( 'esbuild' );
const {nodeExternalsPlugin} = require ( 'esbuild-node-externals' );
const monex = require ( 'monex' );
const path = require ( 'path' );
const {color, parseArgv} = require ( 'specialist' );
const Watcher = require ( 'watcher' );
gossi /
Last active Mar 19, 2021
Ember: Universal a11y helpers

Universal a11y Helpers

Given the WAI ARIA authoring practices tell you quite good how a particular widget shall behave. What - in case you are developing such a widget as a glimmer component - if you want to write tests for them? What if there is an already ready library of tests to use for them? If you as a developer did a good job and have all the markup done properly, the tests can entirely work on the accessibility tree on top of your markup. If not, the tests will fail anyway.

What about having an ember addon, that provides this a11y test library? In case you are developing a new component, you take that library and throw their tests at your code, without ever writing them yourself and be assured your component is a11y compliant. That library would do a service to the whole ember community.


Here is an example, I've just finished writing. It is the first iteration, I found it quite well and useful and lead me to writing this. Basically, I was

ClickerMonkey / types.ts
Last active Oct 14, 2021
Typescript Helper Types
View types.ts
// when T is any|unknown, Y is returned, otherwise N
type IsAnyUnknown<T, Y, N> = unknown extends T ? Y : N;
// when T is never, Y is returned, otherwise N
type IsNever<T, Y = true, N = false> = [T] extends [never] ? Y : N;
// when T is a tuple, Y is returned, otherwise N
// valid tuples = [string], [string, boolean],
// invalid tuples = [], string[], (string | number)[]
View LargestContentfulPaintBookmarklet.js
* A bookmarklet for viewing the largest contentful paint in a page.
* Will show each LCP after the bookmarklet is clicked.
* To install:
* 1. Copy the code starting from the line beginning `javascript:`
* 2. Add a new bookmark in Chrome, and paste the code in as the URL.
try {
Alonski / application.hbs
Created Feb 19, 2020
Ember.JS Ember Animated Route Transition Animations
View application.hbs
<AnimatedOrphans />{{outlet}}
lifeart / index.html
Last active May 24, 2021
GlimmerLite web components example
View index.html
<!doctype html>
<title>Glimmer Demo</title>
<script src="./app.bundle.js"></script>
<example-app />
aprilmintacpineda / NodeJS require local modules
Last active Nov 4, 2020
NodeJS require concept for local modules
View NodeJS require local modules

NodeJS require concept for local modules

The problem

As your NodeJS app grows bigger, the file structure tends to go 3 to even 5 layers deep. The problem now is as you require local modules you created, you'll have to write them in this way:

const myModule = require('../../../my/module');
lifeart / make-tracked.js
Created Sep 8, 2019
GlimmerX autotracked objects
View make-tracked.js
function makeTracked(obj) {
function shouldDeepTrack(value) {
return typeof value === 'object' && value !== null;
const value = obj[key];
tracked(obj, key);
if (shouldDeepTrack(value)) {
obj[key] = makeTracked(value);
} else {
jswny / Flexible Dockerized Phoenix
Last active Oct 12, 2021
A guide to building and running zero-dependency Phoenix (Elixir) deployments with Docker. Works with Phoenix 1.2 and 1.3.
View Flexible Dockerized Phoenix


I. Preface and Motivation

This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.

For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai