davidsaccavino

@echo off
NET SESSION >nul 2>&1
IF %ERRORLEVEL% NEQ 0 GOTO ELEVATE >nul
GOTO ADMINTASKS

:ELEVATE
CD /d %~dp0 >nul
MSHTA "javascript: var shell = new ActiveXObject('shell.application'); shell.ShellExecute('%~nx0', '', '', 'runas', 1);close();" >nul
EXIT

Solessfir

#pragma once

/** Current Class and Line Number where this is called */
#define LOG_FUNC_LINE (FString(__FUNCTION__) + " (Line: " + FString::FromInt(__LINE__) + ")")

/**
* Usage:
* ADVANCED_LOG("Actor name is: {0}", AnyActorPointer);
* No need for GetName() or ToString(), etc. Type will be automatically deduced
*/

KingKrouch

Here's my biggest issues with Unreal Engine at the moment, and subsequently, games (especially UE games on PC) that use it:

• For starters, the default settings for Unreal projects are hilariously bad, some of which are exposed deep in the editor settings, the others requiring config tweaks on the developer's side.
  For example, every Unreal Engine project ships with Vert- FOV scaling by default (As a massive middle finger to ultrawide users, despite how trivial it is to fix), and also has mouse smoothing and sensitivity that scales based on the FOV enabled (resulting in mouse input feeling wonky, this was actually one big complaint people had with Atomic Heart's release). The former is a problem because it causes the FOV to zoom in the wider the resolution aspect ratio *(While keeping the intended horizontal space by ad

martinrue

const http = require("http");
const esbuild = require("esbuild");

const serve = async (servedir, listen) => {
  // Start esbuild's local web server. Random port will be chosen by esbuild.
  const { host, port } = await esbuild.serve({ servedir }, {});

  // Create a second (proxy) server that will forward requests to esbuild.
  const proxy = http.createServer((req, res) => {
    // forwardRequest forwards an http request through to esbuid.

nolanlawson

"Parens and Performance" – counterpost

Kyle Simpson (@getify) wrote a very thoughtful post decrying optimize-js, which is a tool I wrote that exploits known optimizations in JavaScript engines to make JS bundles parse faster (especially minified bundles, due to what could be reasonably described as a bug in Uglify).

Kyle lays out a good case, but I tend to disagree with nearly all his points. So here's my rebuttal.

nzakas

GitHub Pain Points

This is my feedback on using GitHub to manage a popular project (ESLint). Topics are presented in no particular order. In general, everything I say about issues also refers to pull requests.

For each problem I've suggested a solution. I realize that actually building out a solution is a complex process and my suggestions do not reach the level of detail sufficient for implementation purposes. It's just to give you an idea of the direction I'm thinking.

Problem: No good way to distinguish new issues from "accepted" issues

Users are opening new issues every day, and these issues automatically bubble to the top of the issues list by default. We do label issues that we're committed to doing as "accepted", but if there are enough new issues, you don't even see those until the second page of issues. Why is this a problem? In a word: distraction.

timoxley

JS Pop Quiz: How well do you know your functions?

Given an Array of Functions fns, what argument(s) can you pass to fns.forEach such that each function in fns will execute, in order, without creating any anonymous (or named) functions or invoking the Function constructor?

Conditions

• Do not use the function keyword, or arrow functions () => .
• Do not invoke the Function constructor.
• Do not use method definitions.
• Function#bind & friends on the Function.prototype are ok.

lawnsea

I have been watching the current discussions about running a virtual DOM in a web worker with a great deal of interest. In 2011, I built a research project, [Treehouse][] ([USENIX Talk][] ([DOMTRIS][] demo at 20:25), [paper][]), which ran a hacked-up version of jsdom in a worker. My goal was fine-grained containment of untrusted scripts, while still providing access to browser APIs that existing code expected.

Treehouse achieved a small amount of influence in academic circles, but it had problems and was ultimately unsuccessful. Virtual DOMs were not a widespread or well-understood idea at the time, so the advantages of running one in a worker

mattdesl

agnostic modules

Most of the modules I write are "agnostic" in that they should work in Node, browserify, webpack, Rollup, jspm... hell, even Unreal.js. It's just ES5, CommonJS and a few quirks like process.nextTick or require('path') (which browserify and webpack will shim).

Other modules are a bit trickier, and need to include a static asset like HTML, GLSL or another file.

In Node you might see this:

var fs = require('fs')

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't