kamilogorek

aweary

import { z } from "zod";
import { zodToTs, printNode } from "zod-to-ts";
// Replace with your `openai` thing
import { openai } from "../openai.server";
import endent from "endent";


function createJSONCompletion<T extends z.ZodType>({
  prompt,
  schema_name,

threepointone

On implementing a client for feature flags in your UI codebase

This document isn't an explainer on Feature Flags, you can find that with my amateur writeup, or literally hundreds of better writeups out there.

This document is also agnostic to the choice of service you'd use: LaunchDarkly or split.io or optimizely or whatever; that's orthogonal to this conversation.

Instead, this document is a list of considerations for implementing a client for using Feature Flags for User Interface development. Service providers usually give a simple fetch and use client and that's it; I contend that there's a lot more to care about. Let's dive in.

To encourage usage, we'd like for the developer experience to be as brutally simple as possible. So, this should be valid usage:

sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

enricofoltran

package main

import (
	"context"
	"flag"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"

fralalonde

Metrics are a contract

An application's metrics names and types make up an implicit contract which consequences of ignoring can be serious.

Humans depend on Metrics

Metric are used by systems admins to configure monitoring systems. Good metric names accurately and consistently convey meaning of the associated metric data. Admins should not have to look at the application code to understand what each metric represents. The name of a metric is often the only documentation available. Critical human decisions may have to be quickly made based on metrics, in these situations, their names should be as helpful and trustable as possible.

Machines depend on Metrics

Dashboards and alerting systems entirely depend on the metrics applications provides them. Changing the identifiers or meaning of the metrics will break these downstream applications, negating the very reason to emit metrics in the first place :

• Alarms that shouldn't have gone off will go off

slavafomin

Here's how you could create custom error classes in Node.js using latest ES6 / ES2015 syntax.

I've tried to make it as lean and unobtrusive as possible.

Defining our own base class for errors

errors/AppError.js

EtienneR

package main

import (
	"database/sql"
	"gopkg.in/gorp.v1"
	"log"
	"strconv"

	"github.com/gin-gonic/gin"
	_ "github.com/go-sql-driver/mysql"

bobbygrace

Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets

---

Trello CSS Guide

“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”

You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?

jopotts

module DefaultValues

  def has_default_values(default_values = {})

    class_attribute :default_values
    self.default_values = default_values

    after_initialize :assign_default_values

    include InstanceMethods