LawrenceHwang

GitHub Copilot Customization Architecture

Instructions · Skills · Custom Agents · Hooks · SDK

Best Practices for Engineers ｜ Principal Engineer Perspective

February 2026

---

Table of Contents

1. Architecture Overview — Five Core Components and Their Relationships

kostysh

I want you to act as a Senior full stack Typescript developer. Once I provide the TypeScript code, your task is to develop a comprehensive suite of unit tests for a provided TypeScript codebase. Follow these guidelines for an effective testing process:

1. Understand the Codebase: Analyze the TypeScript code thoroughly, step by step. Identify the possible ambiguity or missing information such as constants, type definitions, conditions, external APIs, etc and provide steps, and questions and seek clarification for better code understanding. Only proceed to the next step once you have analyzed the codebase fully.

2. Testing framework: For this task, use an abstract testing framework instead of known frameworks such as chai, jest, etc., remembering that the principles of unit testing apply regardless of the specific tools.

3. Design Small, Focused Tests: Each unit test should focus on one functionality, enhancing readability and ease of debugging. Ensure each test is isolated and does not depe

n1snt

Note

I’ve written a newer optimized 2026 version of this guide with a faster setup using Zinit + Starship and improved plugin loading.

This version avoids slow shell startups and works better with modern Zsh setups.

Updated guide: https://gist.github.com/n1snt/2cccc8aa5f7b645a7628d3512c70deb6

Oh my zsh.

fworks

Steps:

1. Download the latest zsh package: https://packages.msys2.org/package/zsh?repo=msys&variant=x86_64

Example:

zsh-5.7.1-1-x86_64.pkg.tar.xz

gvenzl

LOCATION=$(curl -s https://api.github.com/repos/<YOUR ORGANIZTION>/<YOUR REPO>/releases/latest \
| grep "zipball_url" \
| awk '{ print $2 }' \
| sed 's/,$//'       \
| sed 's/"//g' )     \
; curl -L -o <OUTPUT FILE NAME> $LOCATION

for example:

rspeer

kayousterhout

Generating Flame Graphs for Apache Spark

Flame graphs are a nifty debugging tool to determine where CPU time is being spent. Using the Java Flight recorder, you can do this for Java processes without adding significant runtime overhead.

When are flame graphs useful?

Shivaram Venkataraman and I have found these flame recordings to be useful for diagnosing coarse-grained performance problems. We started using them at the suggestion of Josh Rosen, who quickly made one for the Spark scheduler when we were talking to him about why the scheduler caps out at a throughput of a few thousand tasks per second. Josh generated a graph similar to the one below, which illustrates that a significant amount of time is spent in serialization (if you click in the top right hand corner and search for "serialize", you can see that 78.6% of the sampled CPU time was spent in serialization). We used this insight to spee

fdv

These are the snippets I use most of the time when administrating my ES cluster

To be updated

Settings to change before you do something

Before restarting a data node

curl -XPUT 'http://escluster:9200/_cluster/settings' -d '{

feynmanliang

import org.apache.spark.ml.feature.{CountVectorizer, RegexTokenizer, StopWordsRemover}
import org.apache.spark.mllib.clustering.{LDA, OnlineLDAOptimizer}
import org.apache.spark.mllib.linalg.Vector

import sqlContext.implicits._

val numTopics: Int = 100
val maxIterations: Int = 100
val vocabSize: Int = 10000

gccpacman

#Protecting the Docker daemon Socket with HTTPS

HOST-IP:172.17.42.1 VM-IP:172.17.0.2

openssl genrsa -aes256 -out ca-key.pem 2048
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem ```Common Name:  172.17.42.1```
openssl genrsa -out server-key.pem 2048
openssl req -subj "/CN=172.17.42.1" -new -key server-key.pem -out server.csr

echo subjectAltName = IP:172.17.42.1, IP:172.17.0.2, IP:127.0.0.1 > extfile.cnf