- View: Also called a "template", a file that contains markup (like HTML) and optionally additional instructions on how to generate snippets of HTML, such as text interpolation, loops, conditionals, includes, and so on.
- View engine: Also called a "template library" or "templater", ie. a library that implements view functionality, and potentially also a custom language for specifying it (like Pug does).
- HTML templater: A template library that's designed specifically for generating HTML. It understands document structure and thus can provide useful advanced tools like mixins, as well as more secure output escaping (since it can determine the right escaping approach from the context in which a value is used), but it also means that the templater is not useful for anything other than HTML.
- String-based templater: A template library that implements templating logic, but that has no understanding of the content it is generating - it simply concatenates together strings, potenti
# codec: blocks | |
describe('articles.views.ArticleView'): | |
context('when user has permissions'): | |
it('should add new article'): | |
# some code | |
it('should delete existing article'): |
# stacktrace java as one message | |
multiline { | |
#type => "all" # no type means for all inputs | |
pattern => "(^.+Exception: .+)|(^\s+at .+)|(^\s+... \d+ more)|(^\s*Caused by:.+)" | |
what => "previous" | |
} | |
source :rubygems | |
gem 'json', '= 1.5.4' # knife/chef 11.0 and 11.20 is broken with json 1.5.5/1.7.7 | |
gem 'vagrant' | |
gem 'vagrant-hostmaster' |
#!/usr/bin/sudo sh | |
## ruby_revealer.sh -- decrypt obfuscated GHE .rb files. 2.0.0 to 2.3.1+. | |
## From `strings ruby_concealer.so`: | |
## | |
## > This obfuscation is intended to discourage GitHub Enterprise customers | |
## > from making modifications to the VM. | |
## | |
## Well, good, as long as its not intended to discourage *me* from doing this! |
// Needs a running Chrome Headless, eg: | |
// /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --headless --remote-debugging-port=9222 https://chromium.org | |
// Run with node, eg `node render.js output.html` | |
const CDP = require('chrome-remote-interface'); | |
const fs = require('fs') | |
CDP((client) => { | |
// Extract used DevTools domains. | |
const {Page, Runtime} = client; |
There are some monitors, in my case Dell U2413, that report having YCbCr support when plugged in over HDMI. My AMD Radeon RX 570 Series video card sees this YCbCr pixel format and then prefers that over the RGB pixel format. The result is that fonts, graphics and other visuals are pixelated and not smooth in Ubuntu.
This actually is not just a Linux problem. A similar problem exists on macOS with the same monitor hooked up over HDMI. In fact an article by John Ruble on the Atomic Object blog called Fixing the External Monitor Color Problem with My 2018 MacBook Pro attempts to fix the exact same thing.
All of the articles I could find exploring this topic advocate patching the EDID for the monitor. Unfortunately the macOS solution would not work here. Luckily I found a Reddit post that covered how to get it working.
This post was adapted from an earlier Twitter thread.
It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.
It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)
And then there's Rollup, which apparently requires ESM to be u