| -- | |
| -- Configuration file for XMonad + MATE | |
| -- | |
| -- Usage: | |
| -- * Copy this file to ~/.xmonad/ | |
| -- * Run: $ xmonad --recompile | |
| -- * Launch: $ xmonad --replace | |
| -- [Optional] Create an autostart to command with "xmonad --replace" | |
| -- | |
| -- Author: Arturo Fernandez <arturo at bsnux dot com> |
| {"lastUpload":"2018-07-01T16:18:58.169Z","extensionVersion":"v2.9.2"} |
| //@flow | |
| import * as React from 'react' | |
| import axios from 'axios' | |
| type JsonType = number | string | { [string]: JsonType } | JsonType[] | null | |
| type Props = { | |
| uri: string, | |
| children: React.ComponentType<{ loading: boolean, error: boolean, data?: JsonType }>, | |
| transform: JsonType => JsonType, |
My first experience with default arguments was from Python, where there are dire warnings of the dragons you will encounter if you supply mutable values as default arguments. The concern is in Python, these arguments are initialized at the time that the function is created, which can give you some very surprising results.
def greeter(greetings={}):
print(greetings.get('hi', 'No such greeting')
greetings['hi'] = 'Hello World!'
| import axios from 'axios' | |
| import config from '../../config' | |
| const searchUrl = '/library/search?q=' | |
| const libraryCoursesUrl = '/library/courses/' | |
| const debounce = (func, wait, immediate) => { | |
| let timeout | |
| return (...args) => { | |
| const later = () => { |
The primary reason that results seem like they might be returned out of order is because there is a random element to the rank that we give each search document. This allows us to expose courses that might otherwise have been buried too far down the list to be seen, which both helps authors get exposure and improves the feedback that we get because we see users interact with more courses.
The randomness added to the query is seeded by the user id, so each time an individual user searches for something the results will be in the same order. However, if two different users attempted the same search, they might see results in different orders. This sort of behavior is fairly common among searches on marketplaces, like ecommerce websites, because it helps prevent [winner-t
We frequently use pydantic at Pluralsight to validate data at the edge of a well typed domain. I've been trying to sell my coworkers on using hypothesis for testing, and thought it might go easier if they could generate test data from existing pydantic schemas. I found that it was almost trivial for data classes, but BaseModel subclasses (which are unfortunately much more common in our code) don't play as nicely, and deeply nested schemas can get you into trouble. If anyone has any advice on how to get around the errors that come from the last test, I'd be super greatful.
| (* | |
| * A linear algebra approach to the problem described here: | |
| * https://alexnixon.github.io/2020/01/14/static-types-are-dangerous.html | |
| *) | |
| type currency = (* Currencies as a simple enum *) | |
| | GBP | |
| | USD | |
| | JPY |