- Download and install VirtualBox.
- Download the CoreOS ISO
- Create a new VM in VirtualBox
- For the OS, Other Linux, 64-bit should be fine
- Give the VM 1gb of memory, like your physical hardware has.
- Create a disk of whatever size you want. I made a VMDK file that could expand dynamically up to 8gb.
- Mount the ISO in the VM
- Right click on the VM and click settings
- Go to the storage tab
| import { Component } from "React"; | |
| export var Enhance = ComposedComponent => class extends Component { | |
| constructor() { | |
| this.state = { data: null }; | |
| } | |
| componentDidMount() { | |
| this.setState({ data: 'Hello' }); | |
| } | |
| render() { |
| /* bling.js */ | |
| window.$ = document.querySelector.bind(document); | |
| window.$$ = document.querySelectorAll.bind(document); | |
| Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
| NodeList.prototype.__proto__ = Array.prototype; | |
| NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
| { | |
| "env": { | |
| "browser": true, | |
| "node": true, | |
| "es6": true | |
| }, | |
| "plugins": ["react"], | |
| "ecmaFeatures": { |
| console.log('Loading function'); | |
| const https = require('https'); | |
| const url = require('url'); | |
| // to get the slack hook url, go into slack admin and create a new "Incoming Webhook" integration | |
| const slack_url = 'https://hooks.slack.com/services/...'; | |
| const slack_req_opts = url.parse(slack_url); | |
| slack_req_opts.method = 'POST'; | |
| slack_req_opts.headers = {'Content-Type': 'application/json'}; |
The idea is to combine the best bit of global styling (reuse, small payload) and local styling (total isolation, first-class React syntax)
This is combined with the concept of traits: you can think of them as permitted property/value pairs. Instead of every component being able to have every CSS property available to it, you can reduce your permitted set to X font families, Y font-size + line-height pairs, Z foreground/background colour pairs, W padding amounts. This is based off my work using amcss on real projects — traits were the single key feature that kept me using AM.
The one-sentence explanation: A site defines a set of permitted visual features, all components are simply a combination of those features
I've been converting the web client part of an application I'm developing for a client from plain old JavaScript to React and Flux. (Because this is closed-source client work, I will be a bit vague about what the application is and does.)
Something about my data, my use case, and how I've implemented things, or some combination of those three, doesn't fit the Flux pattern well. So I am writing this to explain my problem and hopefully get some interesting feedback on it. (If you're reading this: thanks.)
I have a Python server which talks to a PostgreSQL database and provides data in JSON format over a REST-ish API (not pure REST, more RPC-style).
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.
elem.offsetLeft,elem.offsetTop,elem.offsetWidth,elem.offsetHeight,elem.offsetParent
Can't share the complete code because the app's closed source and still in stealth mode, but here's how I'm using React Router and Redux in a large app with server rendering and code splitting on routes.
- Wildcard Express route configures a Redux store for each request and makes
an
addReducers()callback available to thegetComponents()method of each React Router route. Each route is responsible for adding any Redux reducers it needs when it's loaded. (This isn't really necessary on the
Also posted here: http://18pct.com/sending-bash-and-zsh-commands-to-syslog/
Your bash/zsh history is great if its complete, but it doesn't capture commands across all users, sudo's, root commands etc. In particular with test environments, someone may perform a "one-off" procedure and then months later it needs to be repeated. It would be nice to be able to look up what the user did at the time, and searching through multiple, possibly truncated history files is a pain.
Tools like typescript are great if you're actively documenting, but not something you would use all the time in practice and capture more than just a history of your commands. There are third-party tools like rootsh and Snoopy that can accomplish this, but third-party tools can be overkill if all you want is a quick reference in a re