remove pages.

add analytics
2026-02-05 16:13:13 +08:00
parent 0894701e01
commit 01c98b2898
14 changed files with 10 additions and 482 deletions
--- a/.claude/settings.local.json
+++ b/.claude/settings.local.json
@@ -1,18 +0,0 @@
 {
  "permissions": {
    "allow": [
      "WebFetch(domain:github.com)",
      "WebFetch(domain:resume.liukersun.com)",
      "Bash(npm run dev)",
      "Bash(test:*)",
      "Bash(for file in makeblock.png hit.png bytedance.png xiasha.png neau.png)",
      "Bash(do if [ ! -f \"$file\" ])",
      "Bash(then cp me.png \"$file\")",
      "Bash(fi)",
      "Bash(done)",
      "Bash(ls:*)",
      "Bash(npm uninstall:*)",
      "Bash(npx knip)"
    ]
  }
 }
--- a/21
+++ b/21
@@ -1,21 +0,0 @@
 MIT License
 Copyright (c) 2024 Dillion Verma
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
--- a/README.md
+++ b/README.md
@@ -1,47 +0,0 @@
 <div align="center">
 <img alt="Portfolio" src="https://github.com/dillionverma/portfolio/assets/16860528/57ffca81-3f0a-4425-b31d-094f61725455" width="90%">
 </div>
 # Portfolio [![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Fdillionverma%2Fportfolio)
 Built with next.js, [shadcn/ui](https://ui.shadcn.com/), and [magic ui](https://magicui.design/), deployed on Vercel.
 # Features
 - Setup only takes a few minutes by editing the [single config file](./src/data/resume.tsx)
 - Built using Next.js 14, React, Typescript, Shadcn/UI, TailwindCSS, Framer Motion, Magic UI
 - Includes a blog
 - Responsive for different devices
 - Optimized for Next.js and Vercel
 # Getting Started Locally
 1. Clone this repository to your local machine:
   ```bash
   git clone https://github.com/dillionverma/portfolio
   ```
 2. Move to the cloned directory
   ```bash
   cd portfolio
   ```
 3. Install dependencies:
   ```bash
   pnpm install
   ```
 4. Start the local Server:
   ```bash
   pnpm dev
   ```
 5. Open the [Config file](./src/data/resume.tsx) and make changes
 # License
 Licensed under the [MIT license](https://github.com/dillionverma/portfolio/blob/main/LICENSE.md).
--- a/content/api-design-principles.mdx
+++ b/content/api-design-principles.mdx
@@ -1,33 +0,0 @@
 ---
 title: "REST API Design Principles That Stand the Test of Time"
 publishedAt: "2024-12-12"
 updatedAt: "2024-12-12"
 author: "John Doe"
 summary: "Learn how to design APIs that developers love to use and are easy to maintain."
 image: "https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&h=192&fit=crop"
 ---
 # REST API Design Principles That Stand the Test of Time
 Great APIs feel boring in the best way: predictable, consistent, and easy to reason about. When the surface area is simple, teams ship faster and clients break less often.
 This is a lightweight checklist you can keep in mind while designing new endpoints or reviewing an existing API.
 ## Core principles
 - Use clear, consistent **resource names** (think nouns).
 - Keep behavior aligned with **HTTP semantics** (read vs write).
 - Return **consistent response shapes** so clients don’t guess.
 - Prefer **sane defaults** with optional query parameters for filtering/sorting.
 ## A simple checklist
 1. Pick stable resource paths (plural nouns are a common convention).
 2. Use a small set of status codes consistently.
 3. Document pagination and what “next/previous” means.
 4. Be explicit about authentication and authorization requirements.
 5. Add brief examples in docs for the “happy path” and common errors.
 ## Wrap-up
 If you optimize for consistency first, your API will be easier to document, easier to test, and easier for others to adopt.
--- a/content/building-design-systems.mdx
+++ b/content/building-design-systems.mdx
@@ -1,146 +0,0 @@
 ---
 title: "Building Scalable Design Systems with React and Tailwind"
 publishedAt: "2024-12-01"
 updatedAt: "2024-12-01"
 author: "John Doe"
 summary: "A comprehensive guide to creating maintainable design systems that scale with your team and product."
 image: "https://images.unsplash.com/photo-1558655146-9f40138edfeb?w=800&h=192&fit=crop"
 ---
 Design systems are the backbone of consistent user interfaces. Here's how to build one that scales.
 ## Why Design Systems Matter
 A well-crafted design system provides:
 - **Consistency** across all products
 - **Faster development** with reusable components
 - **Better collaboration** between designers and developers
 - **Reduced technical debt** over time
 ## Core Principles
 ### 1. Start with Tokens
 Design tokens are the atomic values of your system:
 ```typescript title="tokens.ts"
 export const tokens = {
  colors: {
    primary: {
      50: '#eff6ff',
      500: '#3b82f6',
      900: '#1e3a8a',
    },
    neutral: {
      0: '#ffffff',
      100: '#f5f5f5',
      900: '#171717',
    },
  },
  spacing: {
    xs: '0.25rem',
    sm: '0.5rem',
    md: '1rem',
    lg: '1.5rem',
    xl: '2rem',
  },
  radii: {
    sm: '0.25rem',
    md: '0.5rem',
    lg: '1rem',
    full: '9999px',
  },
 } as const;
 ```
 ### 2. Build Primitive Components
 Start with the basics:
 ```tsx title="Button.tsx"
 import { cva, type VariantProps } from "class-variance-authority";
 const buttonVariants = cva(
  "inline-flex items-center justify-center rounded-md font-medium transition-colors",
  {
    variants: {
      variant: {
        primary: "bg-primary text-white hover:bg-primary/90",
        secondary: "bg-secondary text-secondary-foreground hover:bg-secondary/80",
        ghost: "hover:bg-accent hover:text-accent-foreground",
      },
      size: {
        sm: "h-8 px-3 text-sm",
        md: "h-10 px-4",
        lg: "h-12 px-6 text-lg",
      },
    },
    defaultVariants: {
      variant: "primary",
      size: "md",
    },
  }
 );
 interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}
 export function Button({ variant, size, className, ...props }: ButtonProps) {
  return (
    <button className={buttonVariants({ variant, size, className })} {...props} />
  );
 }
 ```
 ## Component Composition
 Build complex components from primitives:
 | Level | Examples | Purpose |
 |-------|----------|---------|
 | Tokens | Colors, spacing, typography | Foundation |
 | Primitives | Button, Input, Badge | Building blocks |
 | Patterns | Card, Modal, Dropdown | Common UI patterns |
 | Templates | PageHeader, Sidebar | Layout structures |
 ## Documentation is Key
 > "A design system without documentation is just a component library."
 Every component should include:
 1. **Usage examples** - Show common use cases
 2. **Props documentation** - Explain all options
 3. **Accessibility notes** - ARIA labels, keyboard nav
 4. **Do's and Don'ts** - Guide proper usage
 ## Versioning Strategy
 ```json title="package.json"
 {
  "name": "@company/design-system",
  "version": "2.1.0",
  "peerDependencies": {
    "react": "^18.0.0",
    "tailwindcss": "^3.0.0"
  }
 }
 ```
 Use semantic versioning:
 - **Major**: Breaking changes
 - **Minor**: New features (backward compatible)
 - **Patch**: Bug fixes
 ## Conclusion
 Building a design system is an investment that pays dividends in:
 - Developer productivity
 - Design consistency
 - User experience
 - Team collaboration
 Start small, iterate often, and document everything.
--- a/content/git-workflow-guide.mdx
+++ b/content/git-workflow-guide.mdx
@@ -1,38 +0,0 @@
 ---
 title: "Git Workflow Guide: From Chaos to Clarity"
 publishedAt: "2024-12-10"
 updatedAt: "2024-12-10"
 author: "John Doe"
 summary: "Master Git workflows that keep your team productive and your codebase healthy."
 image: "https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=800&h=192&fit=crop"
 ---
 # Git Workflow Guide: From Chaos to Clarity
 Git is powerful, but teams usually struggle because they don’t agree on a few basics. A simple workflow keeps history readable, reviews focused, and releases less stressful.
 This is a lightweight guide you can adopt in a day and iterate on later.
 ## A simple team workflow
 - Branch from `main` for every change.
 - Keep branches small and short-lived.
 - Open a pull request early and ask for review.
 - Merge back to `main` once tests pass.
 ## Commit message tips
 - Start with a clear verb (“add”, “fix”, “remove”, “refactor”).
 - Keep the first line short and specific.
 - Prefer multiple small commits over one giant “WIP”.
 ## PR checklist
 1. Explain what changed and why.
 2. Link the issue or describe the user impact.
 3. Add tests (or explain why not).
 4. Keep the diff small enough to review quickly.
 ## Wrap-up
 The goal isn’t “perfect Git” — it’s fewer surprises and faster collaboration. Start simple, write down the rules, and improve them as your team grows.
--- a/content/nextjs-performance-tips.mdx
+++ b/content/nextjs-performance-tips.mdx
@@ -1,56 +0,0 @@
 ---
 title: "10 Next.js Performance Tips for Production Apps"
 publishedAt: "2024-12-05"
 updatedAt: "2024-12-05"
 author: "John Doe"
 summary: "Practical optimization techniques to make your Next.js applications blazing fast in production."
 image: "https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&h=192&fit=crop"
 ---
 Performance isn't optional—it's a feature. Here are battle-tested tips for optimizing Next.js apps.
 # 2. Optimize Images
 Always use `next/image`
 ```tsx
 import Image from 'next/image';
 export function Hero() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero image"
      width={1200}
      height={600}
      priority // Load immediately for LCP
      placeholder="blur"
      blurDataURL="data:image/jpeg;base64,..."
    />
  );
 }
 ```
 ## 4. Implement Proper Caching
 | Strategy | Use Case | TTL |
 |----------|----------|-----|
 | `force-cache` | Static data | Forever |
 | `revalidate: 3600` | Semi-static | 1 hour |
 | `revalidate: 60` | Frequently updated | 1 minute |
 | `no-store` | Real-time data | Never cache |
 ## 5. Minimize Client Components
 Every `'use client'` directive adds to your JavaScript bundle. Keep client components small and focused:
 ## 6. Bundle Analysis
 ```bash title="terminal"
 # Install analyzer
 npm install @next/bundle-analyzer
 # Run analysis
 ANALYZE=true npm run build
 ```
--- a/content/remote-work-productivity.mdx
+++ b/content/remote-work-productivity.mdx
@@ -1,43 +0,0 @@
 ---
 title: "Mastering Remote Work: Productivity Tips from a Digital Nomad"
 publishedAt: "2024-11-25"
 updatedAt: "2024-11-25"
 author: "John Doe"
 summary: "Practical strategies for staying productive, focused, and balanced while working remotely, based on years of experience."
 image: "https://images.unsplash.com/photo-1521791136064-7986c2920216?w=800&h=192&fit=crop"
 ---
 # Mastering Remote Work: Productivity Tips
 Remote work is less about “working from anywhere” and more about building routines that protect your focus and your energy. A few small defaults go a long way.
 > Remote work works best when your day has clear starts, clear stops, and fewer context switches.
 ## Common challenges
 - Home distractions
 - Blurry work/life boundaries
 - Fewer casual social touchpoints
 - Async communication gaps
 ## Daily routine checklist (example)
 | Habit | Why it helps
 |------|--------------
 | Dedicated workspace | Signals "work mode"
 | Plan top 3 tasks | Reduces overwhelm
 | Deep work block | Protects focus
 | Walk / stretch break | Prevents burnout
 | Shutdown ritual | Creates a clear end
 ## Tools (keep it minimal)
 - [x] Pick one task tracker (e.g. Linear / GitHub Issues)
 - [ ] Pick one notes app (e.g. Notion / Obsidian)
 - [ ] Keep a single calendar (e.g. Google Calendar)
 - [ ] Turn on Focus / Do Not Disturb during deep work
 - [ ] Prefer async updates; use chat for blockers only
 ## Wrap-up
 Start with one routine change (workspace + “top 3 tasks”) and one boundary (a daily shutdown time). Once those stick, iterate.
--- a/content/testing-react-apps.mdx
+++ b/content/testing-react-apps.mdx
@@ -1,36 +0,0 @@
 ---
 title: "Testing React Applications: A Practical Guide"
 publishedAt: "2024-12-14"
 updatedAt: "2024-12-14"
 author: "John Doe"
 summary: "From unit tests to E2E—learn how to build confidence in your React applications with comprehensive testing."
 image: "https://images.unsplash.com/photo-1516116216624-53e697fedbea?w=800&h=192&fit=crop"
 ---
 # Testing React Applications: A Practical Guide
 Tests are your safety net — they let you refactor with confidence and ship changes without fear. The goal is not “as many tests as possible”; it’s <mark>confidence in the critical paths</mark>.
 If your test suite feels slow or fragile, it usually means you’re testing the wrong thing. In practice, you can ignore a lot of “perfect coverage” advice and focus on a few high-signal habits.
 ## What to test (a simple rule)
 - **Unit tests**: small, fast checks for logic and pure functions.
 - **Integration tests**: components + data + user flows (most value per test).
 - **E2E tests**: a few happy-path checks across the whole app.
 ## High-signal testing habits
 - Prefer user-facing assertions (what the user sees/does).
 - Use accessible queries first (roles, labels).
 - Mock at the boundary (network) instead of mocking implementation details.
 ## Things to avoid
 - ~~Testing internal component state~~ when behavior is what matters.
 - ~~Sprinkling test IDs everywhere~~ as a first choice.
 - Overusing snapshots that fail for harmless UI changes.
 ## Wrap-up
 Start small: one integration test for your most important flow, then add unit tests for tricky logic. Over time, your tests become living documentation that helps you move faster.
--- a/content/typescript-best-practices.mdx
+++ b/content/typescript-best-practices.mdx
@@ -1,41 +0,0 @@
 ---
 title: "TypeScript Best Practices for Clean, Maintainable Code"
 publishedAt: "2024-12-08"
 updatedAt: "2024-12-08"
 author: "John Doe"
 summary: "Essential TypeScript patterns and practices that will make your codebase more robust and easier to maintain."
 image: "https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=800&h=192&fit=crop"
 ---
 # TypeScript Best Practices for Clean, Maintainable Code
 TypeScript shines when it helps you model reality — not when it forces you to fight types all day. A few small defaults can make a codebase feel <mark>calmer, safer, and easier to refactor</mark>.
 <MediaContainer
  src="https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1200&fit=crop"
  alt="TypeScript code on screen"
 />
 ## Practical rules of thumb
 - Turn on strictness and fix the sharp edges early.
 - Prefer readable types over clever types.
 - Use unions for “one of these”, interfaces for “shape of this”.
 - Avoid `any` as a shortcut; it becomes ~~future debt~~ fast.
 ## One pattern worth memorizing
 ```ts
 type Result<T> =
  | { ok: true; value: T }
  | { ok: false; error: string };
 export function parseNumber(input: string): Result<number> {
  const n = Number(input);
  return Number.isFinite(n) ? { ok: true, value: n } : { ok: false, error: "Not a number" };
 }
 ```
 ## Wrap-up
 The best TypeScript code reads like good documentation: clear names, predictable shapes, and errors that point you to the fix.
--- a/package.json
+++ b/package.json
@@ -1,5 +1,5 @@
 {
-  "name": "porfolio",
+  "name": "resume",
  "version": "0.1.0",
  "private": true,
  "engines": {
--- a/src/app/layout.tsx
+++ b/src/app/layout.tsx
@@ -5,6 +5,7 @@ import { DATA } from "@/data/resume";
 import { cn } from "@/lib/utils";
 import type { Metadata } from "next";
 import localFont from "next/font/local";
 import Script from "next/script";
 import "./globals.css";
 import { FlickeringGrid } from "@/components/magicui/flickering-grid";
@@ -75,6 +76,12 @@ export default function RootLayout({
 }>) {
  return (
    <html lang="en" suppressHydrationWarning>
      <Script
        defer
        src="https://analytics.liukersun.com/script.js"
        data-website-id="4a439ee0-6a1e-45b4-a2d9-e8b1703a3b73"
        strategy="afterInteractive"
      />
      <body
        className={cn(
          "min-h-screen bg-background font-sans antialiased relative",
--- a/src/components/magicui/dock.tsx
+++ b/src/components/magicui/dock.tsx
@@ -32,7 +32,7 @@ const Dock = ({ className, children, magnification = DEFAULT_MAGNIFICATION, dist
  return (
    <DockContext.Provider value={{ mouseX, magnification, distance }}>
      <motion.div
-        onMouseMove={(e) => mouseX.set(e.pageX)}
+        onMouseMove={(e) => mouseX.set(e.clientX)}
        onMouseLeave={() => mouseX.set(Infinity)}
        className={cn("mx-auto w-max h-full flex items-end justify-center overflow-visible rounded-full border", className)}
      >
--- a/src/data/resume.tsx
+++ b/src/data/resume.tsx
@@ -23,7 +23,7 @@ export const DATA = {
  description:
    "全栈软件工程师，6年开发经验。热爱技术，活跃于Telegram。",
  summary:
-    "拥有6年软件开发经验的全栈工程师，曾就职于字节跳动 RTC 实验室、亚厦集团和 MakeBlock。擅长前后端开发、自动化测试、数据处理和办公自动化，做过C#项目与Swift iOS应用，精通Linux，具备代理节点搭建能力。",
+    "拥有6年软件开发经验的全栈工程师，曾就职于字节跳动 RTC 实验室、亚厦集团和 MakeBlock。擅长前后端开发、自动化测试、数据处理和办公自动化，做过C#项目与Swift iOS应用，精通Linux。",
  avatarUrl: "/me.png",
  skills: [
    { name: "Python", icon: Python },