diff --git a/.claude/settings.local.json b/.claude/settings.local.json
deleted file mode 100644
index bdf5683..0000000
--- a/.claude/settings.local.json
+++ /dev/null
@@ -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)"
- ]
- }
-}
diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index f709ac2..0000000
--- a/LICENSE
+++ /dev/null
@@ -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.
diff --git a/README.md b/README.md
deleted file mode 100644
index d25feab..0000000
--- a/README.md
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-# Portfolio [](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).
diff --git a/content/api-design-principles.mdx b/content/api-design-principles.mdx
deleted file mode 100644
index f4f15cd..0000000
--- a/content/api-design-principles.mdx
+++ /dev/null
@@ -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.
diff --git a/content/building-design-systems.mdx b/content/building-design-systems.mdx
deleted file mode 100644
index 01ff2e8..0000000
--- a/content/building-design-systems.mdx
+++ /dev/null
@@ -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,
- VariantProps {}
-
-export function Button({ variant, size, className, ...props }: ButtonProps) {
- return (
-
- );
-}
-```
-
-## 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.
diff --git a/content/git-workflow-guide.mdx b/content/git-workflow-guide.mdx
deleted file mode 100644
index b67cbf4..0000000
--- a/content/git-workflow-guide.mdx
+++ /dev/null
@@ -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.
diff --git a/content/nextjs-performance-tips.mdx b/content/nextjs-performance-tips.mdx
deleted file mode 100644
index 9be22be..0000000
--- a/content/nextjs-performance-tips.mdx
+++ /dev/null
@@ -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 (
-
- );
-}
-```
-
-
-## 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
-```
\ No newline at end of file
diff --git a/content/remote-work-productivity.mdx b/content/remote-work-productivity.mdx
deleted file mode 100644
index b265c46..0000000
--- a/content/remote-work-productivity.mdx
+++ /dev/null
@@ -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.
diff --git a/content/testing-react-apps.mdx b/content/testing-react-apps.mdx
deleted file mode 100644
index 24a7d6d..0000000
--- a/content/testing-react-apps.mdx
+++ /dev/null
@@ -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 confidence in the critical paths.
-
-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.
diff --git a/content/typescript-best-practices.mdx b/content/typescript-best-practices.mdx
deleted file mode 100644
index f1cded8..0000000
--- a/content/typescript-best-practices.mdx
+++ /dev/null
@@ -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 calmer, safer, and easier to refactor.
-
-
-
-## 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 =
- | { ok: true; value: T }
- | { ok: false; error: string };
-
-export function parseNumber(input: string): Result {
- 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.
diff --git a/package.json b/package.json
index 29552ba..355bf83 100644
--- a/package.json
+++ b/package.json
@@ -1,5 +1,5 @@
{
- "name": "porfolio",
+ "name": "resume",
"version": "0.1.0",
"private": true,
"engines": {
diff --git a/src/app/layout.tsx b/src/app/layout.tsx
index 221ba50..7b93a15 100644
--- 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 (
+
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)}
>
diff --git a/src/data/resume.tsx b/src/data/resume.tsx
index f99511a..0d6ef95 100644
--- 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 },