| eXtreme Go Horse (XGH) Process | |
| Source: http://gohorseprocess.wordpress.com | |
| 1. I think therefore it's not XGH. | |
| In XGH you don't think, you do the first thing that comes to your mind. There's not a second option as the first one is faster. | |
| 2. There are 3 ways of solving a problem: the right way, the wrong way and the XGH way which is exactly like the wrong one but faster. | |
| XGH is faster than any development process you know (see Axiom 14). |
| 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])) { |
Most active GitHub users (git.io/top)
The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.
Only first 1000 GitHub users according to the count of followers are taken. This is because of limitations of GitHub search. Sorting algo in pseudocode:
githubUsers
.filter(user => user.followers > 1000)
| import React, { Component } from 'react'; | |
| export default function withPropsChecker(WrappedComponent) { | |
| return class PropsChecker extends Component { | |
| componentWillReceiveProps(nextProps) { | |
| Object.keys(nextProps) | |
| .filter(key => { | |
| return nextProps[key] !== this.props[key]; | |
| }) | |
| .map(key => { |
I will maybe someday get around to dusting off my C and making these changes myself unless someone else does it first.
Imagine a long-running development branch periodically merges from master. The
git log --graph --all --topo-order is not as simple as it could be, as of git version 1.7.10.4.
It doesn't seem like a big deal in this example, but when you're trying to follow the history trails in ASCII and you've got several different branches displayed at once, it gets difficult quickly.
| // connect() is a function that injects Redux-related props into your component. | |
| // You can inject data and callbacks that change that data by dispatching actions. | |
| function connect(mapStateToProps, mapDispatchToProps) { | |
| // It lets us inject component as the last step so people can use it as a decorator. | |
| // Generally you don't need to worry about it. | |
| return function (WrappedComponent) { | |
| // It returns a component | |
| return class extends React.Component { | |
| render() { | |
| return ( |
I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.
But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.
Svelte is a language.
Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?
A few projects that have answered this question:
- Mobiledoc - github.com/bustle/mobiledoc-kit - framework to build editors with a standardized JSON structure
- ShareDB - github.com/share/sharedb - framework to sync any JSON document using operational transforms, add real-time collaborative editing to anything else
- Bangle.dev - github.com/bangle-io/bangle.dev - toolkit built for building editors, based on prosemirror
These use separate document structures instead of HTML, some are more modular libraries than full editors
The operators c, d, and y expect a motion, like w, e, etc. The second character in the following pairs is not a motion so it is a NOP and nothing is overridden if we use them in mappings.
cd cm co cp cq cr cs cu cx cy cz
dc dm dq dr ds du dx dy dz