Maharshi-Pandya

You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis.

## Core Principles

1. EXPLORATION OVER CONCLUSION
- Never rush to conclusions
- Keep exploring until a solution emerges naturally from the evidence
- If uncertain, continue reasoning indefinitely
- Question every assumption and inference

malerba118

"use client";

import * as React from "react";
import * as TabsPrimitive from "@radix-ui/react-tabs";

import { cn } from "@/lib/utils";

function createPropsTunnel<TunneledProps extends Record<string, any>>(
  defaultProps: Required<TunneledProps>
) {

gd3kr

/*
the twitter api is stupid. it is stupid and bad and expensive. hence, this. 

Literally just paste this in the JS console on the bookmarks tab and the script will automatically scroll to the bottom of your bookmarks and keep a track of them as it goes. 

When finished, it downloads a JSON file containing the raw text content of every bookmark. 

for now it stores just the text inside the tweet itself, but if you're reading this why don't you go ahead and try to also store other information (author, tweetLink, pictures, everything). come on. do it. please?
*/

cgsdev0

#!/usr/bin/env bash

function house_builder() {
  # floors,rooms,has_garage
  echo "0,0,0"
}

function set_field() {
  local f r g
  IFS=, read f r g

kamilogorek

mitchellh

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

djiwandou

Postmortem: Flashsale Grey Screen Problem

Flashsale grey screen in homepage, product list, product detail

Date: 2022-06-21

joelstransky

sizeFormatter = new Intl.NumberFormat([], {
  style: "unit",
  unit: "byte",
  notation: "compact",
  unitDisplay: "narrow",
});

(_bytes) => {
  const units = { B: " bytes", KB: " kb", MB: " mb", GB: " gb", TB: " tb" };
  const parts = sizeFormatter.formatToParts(_bytes);

diegohaz

import {
  queryByLabelText,
  queryByRole,
  queryByText,
} from "@testing-library/dom";
import type { ByRoleOptions, Matcher } from "@testing-library/dom";

const roles = [
  "alert",
  "alertdialog",

markdalgleish

Someone asked me about the spacing scale in Braid and I thought I'd share my thoughts here. For reference this is what they were referring to: https://github.com/seek-oss/braid-design-system/blob/ecdd7f3060cab2a6675cde7dd45bcd510caa268b/packages/braid-design-system/src/lib/themes/baseTokens/apac.ts#L166-L175

I could maybe have turned this into a blog post, but I'm just dropping my rough thoughts here instead.

In practice, the T-shirt size scale felt like indirection because our designers didn't think in those terms so it actually got in the way of developers and designers communicating.

The names also weren't really semantic in the sense that we couldn't confidently change them later without breaking a lot of layouts.

It also made it difficult to name new values to the scale, e.g. if we needed to add a value between "small" and "medium", what would we call it? I've seen things like "xmedium" in other systems before which shows how awkward this can get.