dgeb

Worker Power!

Presentation by Dan Gebhardt at EmberCamp Chicago. September 16th, 2019.

Synopsis

Web workers bring a new layer of capabilities to web applications. Because workers operate on their own threads, they provide a way to perform processor-intensive tasks without affecting the responsiveness of an application. This talk will explore the different types of workers, including service workers and shared workers, and how to make the most of them in your Ember applications. We'll discuss the capabilities available to workers and explore different use cases, including progressive web apps.

Slides

sham1

Running X11 applications using Podman

This is a short tutorial on using podman to run X11 applications. This need often arises when one has to run X11 applications on distros such as Silverblue, when the application for instance has no Flatpak and one doesn't want to install the particular app on their host OS (for instance for Silverblue this process would result in the need to layer a package and then reboot, something which understandably would get quite irritating after a while).

jswny

Prelude

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

apaleslimghost

#!/usr/bin/env node

import logPromise from '@quarterto/log-promise';
import assertEnv from '@quarterto/assert-env';
import jiraCreateVersion from '@quarterto/jira-create-version';
import path from 'path';

const commit = process.env.SOURCE_VERSION;
const packagePath = path.resolve('package.json');
const {version, name} = require(packagePath);

toranb

import Ember from 'ember';
import hbs from 'htmlbars-inline-precompile';
import connect from 'ember-redux/components/connect';

var stateToComputed = (state) => {
  return {
    low: state.low,
    high: state.high
  };
};

christianalfoni

What is the difference between Cerebral and Redux?

Cerebral and Redux were built to solve different problems

Redux was developed to achieve hot reloading global state and state changing logic. To achieve that it was necessary for state changes to be run with pure functions and the state has to be immutable. Now you can change the logic inside your reducer and when the application reloads Redux will put it in its initial state and rerun all the actions again, now running with the new state changing logic.

Cerebral had no intention of achieving hot reloading. Cerebral was initially developed to give you insight into how your application changes its state, using a debugger. In the Redux debugger you see what actions are triggered and how your state looks after the action was handled. In Cerebral you see all actions fired as part of a signal. You see asynchronous behaviour, paths taken based on decisions made in your state changing flow. You see all inputs and outputs produced during the flow and you even

paulirish

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

vi

Cross-compiling Rust from Linux to Windows using Wine

🔴 Note: this article is obsolete. This cross-compilation direction may just work out of the box. 🔴

0. Ensure Rust works on Host

Let's create a dummy project for a test.

$ cargo new test

justmoon

'use strict';

module.exports = function CustomError(message, extra) {
  Error.captureStackTrace(this, this.constructor);
  this.name = this.constructor.name;
  this.message = message;
  this.extra = extra;
};

require('util').inherits(module.exports, Error);

nruth

Then /^show me the cookies!$/ do
  driver = Capybara.current_session.driver
  case driver
  when Capybara::Driver::Selenium
    announce_selenium_cookies(Capybara.current_session.driver.browser)
  when Capybara::Driver::RackTest
    announce_rack_test_cookies(get_rack_test_cookie_jar)
  else 
    raise "unsupported driver, use rack::test or selenium/webdriver"
  end