jareware

⇐ back to the gist-blog at jrw.fi

Advanced SCSS

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

jareware

Server-Sent Events Demo

Server-Sent events is a specification for implementing server-side-push for web frontend applications, through plain-old HTTP.

It is best contrasted with WebSockets, which offer a full-duplex messaging channel over a custom protocol, operating within a single TCP connection (with an HTTP-compatible handshake).

Trying out the demo

1. Clone this gist
2. node server.js

jareware

premiere-subtitle-convert

Conversion script between the TTML & SRT subtitle formats. This is particularly useful with Adobe Premiere, as it doesn't understand the SRT format (which is joyously simple and interoperable). TTML-XML is probably the most straightforward subtitle format it does understand, hence this tool.

Note that due to the simplicity of the SRT format, this conversion is extremely lossy for all the bells and whistles supported by TTML. Not like you'd want fixed-pixel font sizes etc in your subtitles anyway, but you've been warned.

jareware

<button id="enter-full-screen">Enter full screen</button>

<style>
  #enter-full-screen {
    display: block;
    margin: 60px auto;
    padding: 30px 70px;
    background: #464545;
    border: 1px solid #636363;
  }

jareware

⇐ back to the gist-blog at jrw.fi

Project-specific lint rules with ESLint

A quick introduction

First there was JSLint, and there was much rejoicing. The odd little language called JavaScript finally had some static code analysis tooling to go with its many quirks and surprising edge cases. But people gradually became annoyed with having to lint their code according to the rules dictated by Douglas Crockford, instead of their own.

So JSLint got forked into JSHint, and there was much rejoicing. You could set it up to only complain about the things you didn't want to allow in your project, and shut up about the rest. JSHint has been the de-facto standard JavaScript linter for a long while, and continues to do so. Yet there will always be things your linter could check for you, but doesn't: your team has agreed on some convention that makes sense for them, but JSHint doesn't have an option

jareware

Important: At the time of writing (2019-11-11) Immutable.js is effectively abandonware, so I can no longer recommend anyone to follow the advice given here. I'll leave the article here for posterity, since it's still getting some traffic.

Understanding Immutable.Record

Functional programming principles and with it immutable data are changing the way we write frontend applications. If the recent de-facto frontend stack of React and Redux feels like it goes perfectly together with immutable data, that's because it's specifically designed for that.

There's several interesting implementations of immutable data for JavaScript, but here I'll be focusing on Facebook's own Immutable.js, and specifically on one of i

jareware

⇐ back to the gist-blog at jrw.fi

Simple, semi-anonymous backups with S3 and curl

Backing stuff up is a bit of a hassle, to set up and to maintain. While full-blown backup suites such as duplicity or CrashPlan will do all kinds of clever things for you (and I'd recommend either for more complex setups), sometimes you just want to put that daily database dump somewhere off-site and be done with it. This is what I've done, with an Amazon S3 bucket and curl. Hold onto your hats, there's some Bucket Policy acrobatics ahead.

There's also a tl;dr at the very end if you just want the delicious copy-pasta.

Bucket setup

jareware

Document your target environment with:

"engines": {
  "npm": ">=3.3.12 <4",
  "node": ">=5.5.0 <6"
},

Then install this:

"devDependencies": {

jareware

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # This is kinda ghetto, but the simplest way to print a message to the user
  puts "\nNOTE: After the box boots, your app will be available at e.g. http://192.168.50.1:8080"

jareware

Transparent boot2docker on OS X

This is how you can autorun boot2docker on boot, so that you can use docker as you would on Linux, without ever* knowing that the daemon's not running locally.

1. Install VirtualBox & boot2docker (obviously)
2. Create a startup script with Automator
3. Put in /usr/local/bin/boot2docker up && /usr/local/bin/boot2docker shellinit > ~/.boot2docker-shellinit.sh
4. Add echo "export DOCKER_IP=$(boot2docker ip 2>/dev/null)" >> ~/.boot2docker-shellinit.sh if you want the non-standard but very-convenient DOCKER_IP env-var as well (thanks for the suggestion @city41!)
5. Update your .profile or equivalent file with source ~/.boot2docker-shellinit.sh
6. Reboot your machine