标签：#tutorial

Quando voce cria um container e depois outro, eles podem nao se enxergar. O motivo quase sempre e a rede. Entender os tipos de rede que o Docker oferece resolve isso de uma vez. Comece listando as redes que ja existem no seu Docker. docker network ls A rede bridge e a rede host vem de fabrica. Nenhuma delas oferece resolucao de nomes entre containers. Para isso voce precisa criar a sua propria rede. docker network create minha-rede Agora os containers que entrarem nessa rede conseguem se comunicar pelo nome do container. docker run -d --name app1 --network minha-rede nginx docker run -d --name app2 --network minha-rede alpine sleep 3600 Teste a comunicacao. docker exec app2 ping app1 -c 2 O ping funciona. O DNS interno do Docker resolve app1 para o IP interno do container. Isso resolve 90% dos problemas de comunicacao. A rede bridge padrao nao tem esse recurso. Crie sua propria rede sempre que precisar que containers se enxerguem. Agora a rede host. Ela elimina o isolamento de rede. O container usa a placa do host diretamente, sem NAT e sem mapeamento de porta. docker run -d --name web-host --network host nginx O nginx fica acessivel em http://localhost:80 direto. Sem -p 80:80. Mas so um container pode usar cada porta, porque a porta e a do host de verdade. Para ambientes com mais de uma maquina, existe a rede overlay. Ela precisa do Docker Swarm ou de um cluster. docker swarm init docker network create -d overlay rede-overlay docker service create --name api --network rede-overlay --replicas 3 nginx Os containers em maquinas diferentes se enxergam pelo nome como se estivessem na mesma maquina. No dia a dia, a rede bridge personalizada resolve quase todo caso de uso. Host e para performance ou casos especificos. Overlay e para quando voce escala para mais de uma maquina. That's all for now. Thanks for reading!

The Complete TypeScript Mastery Guide Navneet Verma Navneet Verma Navneet Verma Follow Jul 10 The Complete TypeScript Mastery Guide # typescript # webdev # systemdesign # tutorial 5 reactions Add Comment 54 min read

Learn TypeScript From First Principles to Senior/Staff-Level Production Engineering If you searched for how to learn TypeScript properly — not just the syntax, but the thinking behind it — this guide is built for that. Most TypeScript tutorials stop at "here's an interface, here's a generic." This one goes further: it's a single, exhaustive TypeScript tutorial and reference that walks through the type system, object-oriented programming, generics, async programming, design patterns, SOLID and DRY principles, error handling, testing, and the tooling that real production teams run in CI — the same TypeScript best practices used at top-tier engineering organizations. Whether you're a beginner looking for a structured TypeScript for beginners path, or an experienced JavaScript developer making the jump to advanced TypeScript and system design, you can read this end to end or jump straight to the section you need using the linked table of contents below. Table of Contents 1. Introduction — What Is TypeScript & Why It Exists 2. Installation, Setup & tsconfig.json Deep Dive 3. Variables & the Complete Type System 4. Functions — Every Form, Overloads, this , and Best Practices 5. Arrays & Tuples 6. Objects & Type Aliases 7. Interfaces 8. Enums & Literal Types 9. Union, Intersection & Discriminated Unions 10. Type Narrowing, Assertions & Type Guards 11. Classes & Object-Oriented Programming 12. Generics — Basic to Advanced 13. Modules, Namespaces & Project Structure 14. Asynchronous Programming — Event Loop to Production Patterns 15. Advanced/Utility Types & the Type-Level Programming Toolkit 16. Design Patterns in TypeScript 17. SOLID, DRY, KISS, YAGNI — Principles Applied With Real TS Code 18. Error Handling Strategies 19. Testing TypeScript 20. Tooling, Linting, Build Systems & CI/CD for Production TS 21. Performance, Compiler Internals & Scaling Large Codebases 22. Interview Cheat Sheet (Expanded) 23. One-Page Quick Revision Sheet 1. Introduction — What Is TypeScript & W

Here we're going to cover the installation steps of Browsers in Linux - specifically, Debian GNU/Linux . We're covering the procedural steps for this in Debian Testing (Forkey), which is already beginning the gleanings of what will become Debian 14. At the time of writing,the current kernel version is 7.0.13+deb14-amd64. Daily drivers will likely be along the lines of Vivaldi, Firefox, Lagrange, and Brave Browser, and in no particular order. Any others will be mostly for particular reasons like, testing, curiosity, Etc., but some specialized products like the Tor browser, which focus on privacy are also covered. This list is by no means complete, but there's a bunch of them we cover, so let's jump right in! I can haz #Cheezburgerz? 🍔 🍟 Well, let's see... First up is the first rate and fully featured Vivaldi, built on top of the open source Chromium, as are so many others in this list. Vivaldi Manual setup of the Vivaldi Linux repos - According to their website, "you no longer need to do this. After downloading a Linux package and installing it our Linux update repositories will be configured automatically for you to receive updates." That's awfully nice, so visit the download page above and get the .deb package: ~# mkdir -pv /usr/local/packages/vivaldi ; cd /usr/local/packages/vivaldi ~# wget https://downloads.vivaldi.com/stable/vivaldi-stable_8.1.4087.48-1_amd64.deb ~# apt install ./vivaldi * .deb That's it! You're ready to go now. Next up... Firefox ~# apt update && apt install firefox-esr There's none of this messing about anymore with softforks and trying to remember their names...'IceCat?', 'IceWeasel?'. The Trademark issues over branding have been resolved (and that's a good thing). The one thing you might want to look into is SeaMonkey , which combines the Browser with an email client (like Thunderbird), an RSS Reader, IRC client, and a few other goodies. Brave Browser ~# apt install curl ~# curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg ht

Two months ago I picked up a ticket that looked routine: a job that reads mailbox data from Microsoft 365 through EWS, running fine for over a year, started failing on a subset of mailboxes in one tenant. Same app registration, same code path, same service account. The error in the logs pointed at throttling, so that's where the admin had already spent three days looking. Wrong direction. The actual cause had nothing to do with throttling budgets. This mix-up happens constantly right now, and it's worth understanding why, because the fix for one problem does nothing for the other, and chasing the wrong one wastes days. TL;DR: if your EWS failures don't scale with request volume, stop tuning throttling and go check your Application Access Policy scope groups instead. What EWS throttling actually looks like Exchange Online throttles EWS the same way it always has: budget-based. Every account gets a policy (the default is EwsDefaultThrottlingPolicy , but plenty of tenants layer custom ones on top) that tracks a slowly-refilling budget rather than a simple call count. When you overspend it, you get back a 503 or 429 with an X-MS-Diagnostics header telling you which budget got exhausted, usually the connection count or the concurrent-request limit. The tell for real throttling is consistency. It scales with load, correlates with concurrency and batch size, and clears up within minutes once you back off. If you graph failure rate against request volume, you'll see a clean relationship. If you double your batch size, failures increase. If you throttle yourself proactively (respecting Retry-After , staying under EWSFindCountLimit for FindItem calls), it mostly goes away. That correlation is the whole diagnostic test. If your failures don't scale with volume, you're not looking at a throttling problem, no matter what the error message on the surface says. What actually changed Over the past year or so, Microsoft tightened enforcement in two places that both produce errors ea

Understanding Observability with the LGTM Stack From "what happened last night?" to "here's exactly what happened and why" — in under 5 minutes Table of Contents Introduction What Is Observability? The Three Pillars of Observability Metrics Logs Traces Why You Need All Three Together The LGTM Stack Architecture: How It All Fits Together OpenTelemetry: The Instrumentation Standard The OTel Collector: The Brain of the Pipeline Loki: Log Aggregation Tempo: Distributed Tracing Mimir: Metrics at Scale Grafana: Connecting the Dots Conclusion Introduction Let me tell you a story that probably sounds familiar. It's 2 AM on a Sunday. Your API is slow. Users are complaining. But you're not at your desk — you're in a Sleeping, or just living your life. You have no idea it's even happening. The next morning you walk into the office and your boss meets you at the door. "Hey, the API was really slow yesterday around 2 AM. What happened?" And you're stuck. Completely stuck. You pull up the server logs — it's a wall of unformatted text. Maybe the issue already fixed itself. Maybe the container restarted overnight and the logs are gone. You weren't there, and your system left no trail. So you say the thing every developer dreads saying: "I don't know. I'll look into it." Now imagine the exact same situation — but this time you have observability set up. You open your dashboard, set the time range to yesterday 2 AM, and within two minutes you can see everything. Response times spiked to 4 seconds. The database connection pool got exhausted. And it started the exact moment a scheduled batch job kicked off and hammered the DB with hundreds of queries at once. You have a graph. You have traces. You have the exact log line that caused it. You walk back to your boss with your laptop: "Here's what happened and here's the fix." That's observability. Your system tells its own story — even when you're not watching. That's what this blog is about. I'll walk you through what observability actua

An interactive guide to the architecture behind modern language models. Instead of predicting the next word, this Transformer predicts the next move in a game of fading Tic-Tac-Toe—making every step of the model easy to visualize and understand. Play the game, inspect every matrix multiplication, and watch tokens flow through the network in real time. What's covered Tokenization and embeddings Learned positional encoding Self-attention (Q, K, V) Multi-head attention Causal masking and softmax Residual connections and layer normalization MLP (feed-forward network) Unembedding and sampling Model ablations (no positional encoding, no causal mask, no MLP, no residual stream) Includes interactive visualizations for every stage of the Transformer pipeline - from input tokens to the final prediction. https://sbondaryev.dev/articles/transformer

One common issue on WordPress websites with a large number of posts is that the Rank Math XML Sitemap can become slow to load. This happens because the sitemap is generated dynamically every time a visitor or search engine bot requests it. A simple solution is to use a static sitemap cache , allowing the web server to serve pre-generated XML files directly without executing PHP for every request. This significantly reduces server load and improves crawling performance. Benefits of Using a Static Sitemap Using a static sitemap cache provides several advantages: Faster sitemap loading times. Lower CPU and PHP worker usage. Improved crawling efficiency for Google and other search engines. Ideal for websites with thousands or even millions of URLs. Reduced server load when search engine bots frequently request sitemap files. 1. Setting RankMath Sitemap Cache The first step is to enable static sitemap generation using the Rank Math Sitemap Tweak plugin. The plugin automatically creates static copies of your XML sitemaps and stores them in the following directory: /wp-content/uploads/rank-math/ Instead of generating the sitemap dynamically through WordPress, your web server can serve these static files directly. 2. Configure Apache (.htaccess) If your website is running on Apache , add the following rules to your .htaccess file. # ========================== # XML cache # ========================== RewriteCond %{REQUEST_METHOD} GET RewriteCond %{QUERY_STRING} ^$ RewriteCond %{HTTP:Cookie} !wordpress_logged_in RewriteCond %{DOCUMENT_ROOT}/wp-content/uploads/rank-math/%{HTTP_HOST}%{REQUEST_URI} -f RewriteRule ^(.*)$ /wp-content/uploads/rank-math/%{HTTP_HOST}/$1 [L] These rules check whether a cached sitemap file exists. If it does, Apache serves the static file immediately without loading WordPress. 3. Configure Nginx If your server is using Nginx , add the following configuration inside your server block. # # Static cache # location / { try_files \ /wp-content/uploads/rank-

The problem every self-hoster hits You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN. The moment you want someone outside to reach it, the fun begins: Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP. VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page." Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live. What most people actually want is simpler: take this one local port, give it a public address, done. That's exactly what FRP does. What FRP is FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years. The model is clean — two pieces: frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty). frpc (the client) — runs on your local machine, the one with the service you want to expose. The client opens an outbound tunnel to the server. The server listens on a public port and forwards traffic back through the tunnel. NAT and firewalls don't matter because the connection is initiated from inside . [Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080] That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day. The catch: config files FRP works great. The friction isn't the protocol — it's the workflow . To run frpc , you write a TOML/INI config file: serverAddr = "203.0.113.10" serverPort = 7000 auth.token = "your-secret-key" [[proxies]] name = "my-web" type = "tcp" localIP = "1

One of the most important performance metrics for a WordPress website is Server Response Time, commonly measured as Time to First Byte (TTFB). While caching plugins like WP Rocket significantly improve performance, many server configurations still route every request through PHP before serving the cached page. In reality, cached HTML files can be delivered directly by the web server (Apache or Nginx), completely bypassing PHP and WordPress. This approach reduces CPU usage, lowers the PHP-FPM workload, and improves overall server response time. This guide explains how to optimize both Apache (.htaccess) and Nginx so they can serve WP Rocket's static HTML cache directly. Why Is This Optimization Important? By default, a typical WordPress request follows this flow: Visitor │ ▼ Apache/Nginx │ ▼ PHP │ ▼ WordPress │ ▼ WP Rocket Cache │ ▼ HTML Response Even when a page has already been cached, the request still passes through PHP before the cached content is returned. With the following configuration, the request flow becomes: Visitor │ ▼ Apache/Nginx │ ▼ WP Rocket HTML Cache │ ▼ HTML Response PHP and WordPress are only executed when a cached file does not exist. Benefits Lower Time to First Byte (TTFB) Reduced CPU usage Less PHP-FPM processing Better performance during traffic spikes Ideal for VPS and dedicated servers Improved scalability with minimal configuration changes Apache (.htaccess) Optimization If your server runs Apache, insert the following block inside the WordPress rewrite section, immediately after: RewriteBase / and before: RewriteRule ^index\.php$ - [L] The resulting configuration should look like this: # BEGIN WordPress # Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind # dynamisch generiert und sollten nur über WordPress-Filter geändert werden. # Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben. < IfModule mod_rewrite.c > RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Autho

Disclosure up front: I'm Oded, co-founder of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build - so this is a vendor writing about his own product. That said, the three Base44 mechanics below are documented Base44 surfaces, and they work with any external payments API, not just ours. The wall Tell Base44 "add payments" and it installs Stripe or Base44 Payments (powered by Wix), plus Tranzila/Max for Israel. Both main options are solid if you qualify: Stripe is excellent infrastructure with first-class docs, and the Wix-powered option is native to the platform. The fine print is where builders hit a wall: Stripe live mode needs verified business and banking information before you can take a real payment. Base44 Payments requires "a business and bank account based in one of the supported countries" (their docs). The top payments request on Base44's own feedback board is "a way to setup other payment providers other than Stripe" - precisely because not every country is supported. Base44 webhooks only fire while someone is actively using your app, so 3am subscription renewals, retries and dunning silently don't run. If you have a registered company in a supported country and mostly sell one-off purchases, use the built-in Stripe path. It's the smoothest. The rest of this post is for everyone else. Base44 gives you three documented ways to wire in an external provider. I tested all three with paas.build. Here's each, and when it fits. Insertion point 1: custom MCP connection (build-time) In Base44: Settings → Account → MCP connections → Add custom MCP . Name: paas.build Server URL: https://paas.build/sse Auth: API key (your paas.build key) That's the legacy SSE endpoint Base44's form takes; streamable HTTP lives at https://paas.build/mcp for agents that support it. Base44's AI treats MCP connections as tools it can call when your request needs external data or actions. So in the editor chat you can say "use paas.build to create a live merchan

What Is Data Masking? Data masking is a technique that replaces sensitive information with realistic but fictitious data, preserving the format and structure of the original while removing its identifiable meaning. The goal is to keep data usable for development, testing, analytics, or sharing — without exposing real personally identifiable information (PII). Common masking techniques include: Substitution — Replace a real value with a plausible fake (e.g., Alice Smith → Jane Doe ). Masking (partial obscuring) — Show only a portion of the value (e.g., 4111-1111-1111-1234 → ****-****-****-1234 ). Redaction — Remove the value entirely. Hashing — Replace with a cryptographic hash. Irreversible, but deterministic when salted. Data masking is widely used in non-production environments, analytics pipelines, data marketplaces, and any scenario where real PII is not needed but structural fidelity is. What Is Dynamic Data Masking? Static data masking (SDM) applies transformations to data at rest — you clone a production database, mask it, and ship the masked copy to a lower environment. The masking happens once, and the result is a permanent dataset. Dynamic data masking (DDM) applies transformations on the fly , at query or API time, based on who is asking. The original data stays untouched; the masking rules are applied in the response layer. This means: Different roles see different levels of detail (e.g., support agents see the last 4 digits of a credit card; auditors see the full number). No masked copies to maintain — one source of truth, many views. Masking policies are centralized and enforceable without application changes. Veramask implements a DDM-style model over an API: you send a request with payload and settings, and receive back the transformed result in real time. No data is persisted on the server — each call is independent and stateless. Anonymizing PII with the Veramask API Veramask exposes two endpoints for dynamic PII masking: Endpoint Input Use Case PO

This is a cross-post — the original (and any updates) live at broke2builtai.com . The first time I watched Claude Code reach for a skill I hadn't told it to use — read a folder, run the script inside it, and hand back the finished thing — the difference from a slash command finally landed. A slash command waits for you to type it. A skill waits for the situation . Claude decides. That one shift is the whole feature, and building one takes about five minutes once you know where the file goes. Here's the entire thing end to end, including the one gotcha that decides whether your skill ever actually fires. What a Skill actually is A Skill is a folder with a SKILL.md file inside it. The Markdown holds instructions; the YAML frontmatter at the top holds a name and a description . That description is doing the most important job in the whole file: Claude reads it to decide, on its own, whether the current task warrants invoking the skill. Nothing else you write matters if the description doesn't get you picked. That's the mental model to hold onto: a custom slash command is a prompt you trigger by typing /name ; a skill is a procedure Claude triggers when the context matches. Same reusable-instructions idea, opposite trigger. Where the file goes Two locations register, exactly like commands and subagents : Project skill — .claude/skills/<skill-name>/SKILL.md inside the repo. Committed, so your whole team gets it. Personal skill — ~/.claude/skills/<skill-name>/SKILL.md in your home directory. Follows you across every project on your machine. Each skill is its own folder, and the folder name should match the name in the frontmatter. A loose SKILL.md sitting somewhere else won't be picked up. The minimum viable skill Create the folder and the file: .claude/skills/pytest-runner/SKILL.md Then write the two-part file — frontmatter, then body: --- name : pytest-runner description : " Run, generate, or debug pytest tests for this project. Use when the user asks to run the test su

Yes, you heard it right, you can now run a Dockerfile on Vercel. Vercel was the go-to place where...

I’ve been thinking about a small image-processing problem lately: how to reduce an image to a limited palette without making it look muddy. This comes up in a lot of places: pixel art tools printable pattern generators low-color previews LED matrix displays icons and small thumbnails craft or grid-based workflows The easy version is: pick the nearest color for every pixel. The hard version is: keep the important shapes readable after the palette gets much smaller. Nearest color is only the baseline A simple nearest-color pass usually works like this: Take each pixel. Compare it with every color in the target palette. Pick the closest one. Replace the pixel. That gives you a valid output, but not always a good one. The problem is that closest is local. It does not know whether the whole image still reads well. A face can lose warm midtones. A shadow can turn into a flat dark blob. A small highlight can disappear. Skin, fur, fabric, and background colors can collapse into the same bucket. So palette reduction is not just a color problem. It is also a structure problem. RGB distance can be misleading A common first attempt is Euclidean distance in RGB: function rgbDistance(a, b) { return Math.sqrt( (a.r - b.r) ** 2 + (a.g - b.g) ** 2 + (a.b - b.b) ** 2 ); } This is easy to implement, but it does not match human perception very well. Two colors can be numerically close in RGB and still feel different. Other colors can be farther apart numerically but visually acceptable. A better approach is to compare colors in a more perceptual color space, such as Lab or OKLab. You still have to be careful, but the distance metric starts closer to what the eye notices. Dithering helps, but it changes the style Error diffusion, like Floyd-Steinberg dithering, can preserve gradients and perceived detail with fewer colors. That is useful when the output is meant to look like a low-color image. But dithering is not always desirable. In grid-based outputs, it can create scattered single-p

A fintech RAG pipeline poisoned its own vector store and the LLM-as-a-judge validator approved every hallucination. The fix: gate writes with code.

Filingrail now ships a first-party MCP server on PyPI: pip install filingrail-mcp . One install, one config block, and Claude Desktop — or Cursor, or Continue, or any MCP-compatible client — can query SEC filings as tools. No glue code. That's worth naming directly. Most SEC-data APIs ship a REST endpoint and stop. You write the agent integration yourself: parse the response, wire up the tool schema, handle auth headers. Filingrail ships the integration as a maintained package with the same update cadence as the underlying REST API. This post covers the setup, what you can ask once it's wired in, and the honest limits. I built both the API and the MCP server — I'll be upfront about that throughout. This post covers a data API that returns SEC-registered financial information. Nothing here is investment advice. Two ways to wire it in Option 1 — pip install filingrail-mcp (recommended) Install the package, add one block to your Claude Desktop config, restart. Filingrail's endpoints appear as tools. No separate service to run, no background daemon. Option 2 — RapidAPI MCP Playground tab (no local install) The Filingrail listing on RapidAPI has an MCP tab that generates a ready-to-paste config block. Same endpoints, same auth, zero install step. Either path gives Claude the same tools. Pick the one that fits your setup. Setup — the pip install path You'll need Python 3.10+ and a RapidAPI key. 1. Subscribe to Filingrail Go to the Filingrail RapidAPI listing and subscribe. Free tier is 50 calls/day, no credit card. Copy your X-RapidAPI-Key from the RapidAPI dashboard. 2. Install the server pip install filingrail-mcp 3. Add Filingrail to your Claude Desktop config On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%\Claude\claude_desktop_config.json { "mcpServers" : { "filingrail" : { "command" : "filingrail-mcp" , "env" : { "RAPIDAPI_KEY" : "your_rapidapi_key_here" } } } } 4. Restart Claude Desktop Filingrail's endpoints appear a

I built an LED Strip Tetris game — without writing a single line of code. No keyboard mashing. No debugging at 2 AM. No reading 500 pages of datasheets. Just natural language prompts, an AI agent, and a Tuya T5 AI Core board. Here's the full breakdown of how it works 👇 🧩 What Is LED Strip Tetris? LED Strip Tetris is a DIY hardware game built entirely through natural language prompts using TuyaOpen IDE and Claude Code. It runs on a Tuya T5 AI Core development board with a WS2812 LED strip (72 LEDs) and three color-matched buttons — red, green, and blue. Colored LEDs fall from the top of the strip; players press the matching button to shoot a colored LED upward and eliminate the falling one on contact. The entire game — firmware, game logic, hardware wiring, sound effects, compilation, and flashing — was generated by AI. Zero manual coding. 🔌 The Hardware (Ridiculously Simple) Component Role Tuya T5 AI Core Board Main MCU — runs game logic, drives LED strip and buttons WS2812 LED Strip (72 LEDs) Display — colored LEDs fall and get eliminated 3 Push Buttons (Red / Green / Blue) Input — shoot matching color upward to clear falling LEDs Speaker Sound effects on button press That's it. No custom PCB. No complex wiring harness. Just four components plugged into a dev board. 🤔 Why This Is a Big Deal Here's what building a hardware game normally looks like: Step Traditional Approach Vibe Coding with TuyaOpen IDE Dev environment setup Install toolchain, configure SDK, fight dependencies Copy a workflow link, paste into Claude Code, click confirm Game logic Write C code from scratch, design state machines Describe the game in one sentence, AI generates the code Hardware config Read datasheets, look up GPIO mappings, manually configure Tell AI which pins you're using, it handles the rest Sound effects Write audio decoding code, integrate codecs Give AI the file path, it decodes and compiles Debugging Serial logs, oscilloscope, hours of trial and error AI self-diagnoses compile

Introduction My zsh profile is over 1000 lines at this point. A lot of that is functions I asked AI to generate for me, since it's fast, portable, and saves me a ton of typing. Here's the thing though: the shortcuts that save me the most time aren't the clever ones. They're the dumb ones. Things like clone instead of git clone && cd , or dir instead of mkdir -p && cd . Each one only saves a second or two, but I run them so often that it adds up fast. These are in no particular order, just the ones I reach for constantly. Git aliases for common commands A few one-liners I have set up as plain aliases: alias gcp = "git cherry-pick" alias git-append = "git commit --amend --no-edit -a" gcp is self-explanatory. git-append amends the last commit with your currently staged (and unstaged, thanks to -a ) changes without touching the commit message. Great for fixing up a commit you just made before you push. Create a branch or switch to it if it already exists One of my most-used functions. Normally you have to remember whether a branch exists before deciding between git checkout <branch> and git checkout -b <branch> . This just does the right thing either way: gb () { if git rev-parse --verify --quiet " $1 " > /dev/null ; then git checkout " $1 " else git checkout -b " $1 " fi } Nuke all local changes to reset the working tree When an experiment goes sideways or I just want to throw everything away and start clean, I run nah : nah () { git reset --hard git clean -df if [ -d ".git/rebase-apply" ] || [ -d ".git/rebase-merge" ] ; then git rebase --abort fi } This resets tracked changes, removes untracked files and directories. No confirmation prompt, so use it carefully. Print recent commits as ready-to-paste cherry-pick commands Useful when you need to cherry-pick a batch of commits from one branch onto another in order: logs () { if [[ -z " $1 " || " $1 " = ~ [ ^0-9] ]] ; then echo "Usage: logs <number_of_commits>" return 1 fi git log -n " $1 " --reverse --pretty = format: "g

This is the second stage of my CodeAlpha Full Stack internship — two projects, built in a deliberate order so the patterns from the first carry forward. First was a project management tool (auth + real-time updates with Socket.io). This one is a store: products, cart, orders. Same stack — Express, Prisma, PostgreSQL, JWT — but the interesting part isn't the CRUD, it's the order-placement flow, which is the first genuinely transactional piece of logic in the whole internship. I'll walk through the schema decisions, the auth changes from project one, and then spend most of the time on the part that actually matters: making sure an order can never be created without correctly and atomically updating stock and clearing the cart. The schema model User { id String @id @default(cuid()) name String email String @unique password String role String @default("USER") createdAt DateTime @default(now()) orders Order[] cartItems CartItem[] } model Product { id String @id @default(cuid()) name String description String price Float image String? stock Int @default(0) category String createdAt DateTime @default(now()) cartItems CartItem[] orderItems OrderItem[] } model CartItem { id String @id @default(cuid()) quantity Int @default(1) user User @relation(fields: [userId], references: [id]) userId String product Product @relation(fields: [productId], references: [id]) productId String @@unique([userId, productId]) } model Order { id String @id @default(cuid()) status String @default("PENDING") total Float createdAt DateTime @default(now()) user User @relation(fields: [userId], references: [id]) userId String items OrderItem[] } model OrderItem { id String @id @default(cuid()) quantity Int price Float order Order @relation(fields: [orderId], references: [id]) orderId String product Product @relation(fields: [productId], references: [id]) productId String } Two decisions worth explaining, because they're easy to get wrong if you're building this for the first time. OrderItem.price is a