Goals: Add links that are reasonable and good explanations of how stuff works. No hype and no vendor content if possible. Practical first-hand accounts of models in prod eagerly sought.

<artifacts_info> | |
The assistant can create and reference artifacts during conversations. Artifacts are for substantial, self-contained content that users might modify or reuse, displayed in a separate UI window for clarity. | |
# Good artifacts are... | |
- Substantial content (>15 lines) | |
- Content that the user is likely to modify, iterate on, or take ownership of | |
- Self-contained, complex content that can be understood on its own, without context from the conversation | |
- Content intended for eventual use outside the conversation (e.g., reports, emails, presentations) | |
- Content likely to be referenced or reused multiple times |
any
: magic, ill-behaved type that acts like a combination of never
(the proper [bottom type]) and unknown
(the proper [top type])
never
is assignable to any
, and any
is assignable to anything at all.any & AnyTypeExpression = any
, any | AnyTypeExpression = any
unknown
: proper, well-behaved [top type]
unknown
. unknown
is only assignable to itself (unknown
) and any
.unknown & AnyTypeExpression = AnyTypeExpression
, unknown | AnyTypeExpression = unknown
any
whenever possible. Anywhere in well-typed code you're tempted to use any
, you probably want unknown
.const webpack = require('webpack'); | |
require('dotenv').config({ | |
path: process.env.NODE_ENV === 'production' ? '.env.production' : '.env' | |
}); | |
module.exports = { | |
webpack: config => { | |
const env = Object.keys(process.env).reduce((acc, curr) => { | |
acc[`process.env.${curr}`] = JSON.stringify(process.env[curr]); |
Picking the right architecture = Picking the right battles + Managing trade-offs
In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.
At the moment GraphQL allows 2 types of queries:
query
mutation
Reference implementation also adds the third type: subscription
. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
/* | |
Infix to postfix conversion in C++ | |
Input Postfix expression must be in a desired format. | |
Operands and operator, both must be single character. | |
Only '+' , '-' , '*', '/' and '$' (for exponentiation) operators are expected. | |
*/ | |
#include<iostream> | |
#include<stack> | |
#include<string> |
# Copyright (c) 2013 Georgios Gousios | |
# MIT-licensed | |
create database stackoverflow DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; | |
use stackoverflow; | |
create table badges ( | |
Id INT NOT NULL PRIMARY KEY, | |
UserId INT, |
// The Babylonian Method | |
// http://en.wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method | |
// @param n - the number to compute the square root of | |
// @param g - the best guess so far (can omit from initial call) | |
function squirt(n, g) { | |
if (!g) { | |
// Take an initial guess at the square root | |
g = n / 2.0; | |
} | |
var d = n / g; // Divide our guess into the number |