remove pages.
add analytics
This commit is contained in:
@@ -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)"
|
||||
]
|
||||
}
|
||||
}
|
||||
21
LICENSE
21
LICENSE
@@ -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.
|
||||
47
README.md
47
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 [](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).
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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
|
||||
```
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "porfolio",
|
||||
"name": "resume",
|
||||
"version": "0.1.0",
|
||||
"private": true,
|
||||
"engines": {
|
||||
|
||||
@@ -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",
|
||||
|
||||
@@ -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)}
|
||||
>
|
||||
|
||||
@@ -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 },
|
||||
|
||||
Reference in New Issue
Block a user