| -- Based off IETF draft, https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/ | |
| create or replace function uuid_generate_v7() | |
| returns uuid | |
| as $$ | |
| begin | |
| -- use random v4 uuid as starting point (which has the same variant we need) | |
| -- then overlay timestamp | |
| -- then set version 7 by flipping the 2 and 1 bit in the version 4 string | |
| return encode( |
With the release of Node 6.0.0, the surface of code that needs transpilation to use ES6 features has been reduced very dramatically.
This is what my current workflow looks like to set up a minimalistic and fast microservice using micro and async + await.
Make writing asynchronous code easier by having a consistent way of propagating "context" across related asynchronous operations. Have the "context" be responsible for async-local-storage, allowing the execution before and after hooks, and "context"-local error handling. Finally make sure that the "context"s are composable.
This feature needs to be part of the platform so that library and framework authors can relay on a common well know API, otherwise adoption will be limited.
| [Unit] | |
| Description=supervisord - Supervisor process control system for UNIX | |
| Documentation=http://supervisord.org | |
| After=network.target | |
| [Service] | |
| Type=forking | |
| ExecStart=/bin/supervisord -c /etc/supervisord/supervisord.conf | |
| ExecReload=/bin/supervisorctl reload | |
| ExecStop=/bin/supervisorctl shutdown |
| import * as React from 'react'; | |
| import { Component } from 'react'; | |
| export default function HOCBaseRender<Props, State, ComponentState>( | |
| Comp: new() => Component<Props & State, ComponentState>) { | |
| return class HOCBase extends Component<Props, State> { | |
| render() { | |
| return <Comp {...this.props} {...this.state}/>; | |
| } | |
| } |
npm users sorted by the monthly downloads of their modules, for the range May 6, 2018 until Jun 6, 2018.
Metrics are calculated using top-npm-users.
| # | User | Downloads |
|---|
| function logClass(target: any) { | |
| // save a reference to the original constructor | |
| var original = target; | |
| // a utility function to generate instances of a class | |
| function construct(constructor, args) { | |
| var c : any = function () { | |
| return constructor.apply(this, args); | |
| } |
| function mapValues(obj, fn) { | |
| return Object.keys(obj).reduce((result, key) => { | |
| result[key] = fn(obj[key], key); | |
| return result; | |
| }, {}); | |
| } | |
| function pick(obj, fn) { | |
| return Object.keys(obj).reduce((result, key) => { | |
| if (fn(obj[key])) { |
| { | |
| // http://eslint.org/docs/rules/ | |
| "ecmaFeatures": { | |
| "arrowFunctions": false, // enable arrow functions | |
| "binaryLiterals": false, // enable binary literals | |
| "blockBindings": false, // enable let and const (aka block bindings) | |
| "classes": false, // enable classes | |
| "defaultParams": false, // enable default function parameters | |
| "destructuring": false, // enable destructuring |
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
