Total Pageviews

Sunday, 19 July 2026

搭建基于nextjs的静态博客程序nmby


首先fork此项目https://github.com/qlawmarq/next-markdown-blog-YoRHa,我fork后,得到的项目地址是https://github.com/brightmann/nmby
访问https://github.com/brightmann/nmby/tree/master/contents/blog,在此处新建源帖(即add file),我新建了源帖fh.mdx,内容为:
---
title: '战马'
date: '2026-06-13T13:31:00'
language: 'en'
tags: ['misc1', 'misc2', 'misc3']
draft: false
description: '这是一篇文章'
---

此处写正文或html codes.


( 详见https://github.com/brightmann/nmby/blob/master/contents/blog/fh.mdx?plain=1) 

然后,访问vercel.com/new ,导入项目https://github.com/brightmann/nmby

  Build Command栏填入npm run build
 Install Command栏填入npm install

然后点击底部的deploy按钮,等待部署完成。部署完成后,我得到网址:
https://nmby.vercel.app/

项目地址:
https://github.com/qlawmarq/next-markdown-blog-YoRHa
https://github.com/brightmann/nmby

演示博客:

https://nmby.vercel.app/

https://nmby.vercel.app/blog/fh 能显示视频

用 Cloudflare 打造你的临时邮箱

---------------------

 

CloudFlare free temp domain email 免费收发 临时域名邮箱 支持附件 IMAP SMTP TelegramBot

 
 
技术架构详情(点击收缩/展开)

系统架构

  • 数据库: Cloudflare D1 作为主数据库
  • 前端部署: 使用 Cloudflare Pages 部署前端
  • 后端部署: 使用 Cloudflare Workers 部署后端
  • 邮件转发: 使用 Cloudflare Email Routing

技术栈

  • 前端: Vue 3 + Vite + TypeScript
  • 后端: TypeScript + Cloudflare Workers
  • 邮件解析: Rust WASM (mail-parser-wasm)
  • 数据库: Cloudflare D1 (SQLite)
  • 存储: Cloudflare KV + R2 (可选 S3)
  • 代理服务: Python SMTP/IMAP Proxy Server

主要组件

  • Worker: 核心后端服务
  • Frontend: Vue 3 用户界面
  • Mail Parser WASM: Rust 邮件解析模块
  • SMTP Proxy Server: Python 邮件代理服务
  • Pages Functions: Cloudflare Pages 中间件
  • Documentation: VitePress 文档站点

提醒

  • 在Resend添加域名记录时,如果您域名解析服务商正在托管您的3级域名a.b.com,请删除Resend生成的默认name中二级域名前缀b,否则将会添加a.b.b.com,导致验证失败。添加记录后,可通过
nslookup -qt="mx" a.b.com 1.1.1.1

进行验证。

from  https://github.com/dreamhunter2333/cloudflare_temp_email

 

Dragon Blade(不错的片子)

 

Saturday, 18 July 2026

利用 GitHub Codespaces容器环境,手动挡搭建一个高速 VLESS 连接点

 

这种方法抛弃了冗余的一键脚本,不仅响应速度更快,而且配置极其透明、安全。

为什么选择 GitHub Codespaces?

GitHub Codespaces 是微软提供的云端开发环境。它不仅拥有极高的带宽(通常是千兆对等),而且稳定性极佳。相比于传统的 VPS 搭建,这种方法不需要你购买域名或服务器,只需一个 GitHub 账号即可起飞。


核心搭建流程

GITHUB官网:【点击前往】


第一步:创建一个新的仓库 (Repository)

Codespaces 必须依托于一个仓库才能运行。
  1. 在 GitHub 首页(右上角),点击加号 + 图标,选择 New repository。

  2. Repository name: 随便起个名字,比如 my-cloud-vps。

  3. Public/Private: 建议选 Private(私有),这样别人看不到你的服务器配置。

  4. 勾选 Add a README file(这能确保仓库不是空的,方便直接创建空间)。

  5. 点击底部的绿色按钮 Create repository。


第二步:启动 Codespace 环境

仓库创建好后,你会进入仓库主页。

  1. 找到绿色的 <> Code 按钮并点击。

  2. 在弹出的菜单中,选择 Codespaces 选项卡。

  3. 点击底部的 Create codespace on main。

  4. 提示:GitHub 会开始初始化环境,这可能需要 30 秒到 1 分钟。完成后,你会看到一个和 VS Code 一模一样的网页版编辑器。


第三步:进入终端操作

  1. 环境启动后,你会看到屏幕下方有一个 Terminal(终端) 窗口(如果没有看到,按快捷键 Ctrl + ` 即可呼出)。

  2. 接下来你就可以执行之前提到的安装命令了:

  3. 输入:

    sudo su 

    获取 root 权限。

    按照我之前给你的步骤安装 PufferPanel 或其他脚本。

    第四步:环境初始化(下载发动机)

    首先,我们需要在 Codespaces 的终端中下载官方的编译程序。这一步相当于把“发动机”搬进我们的服务器。

     1. 下载 sing-box 官方程序包
    wget https://github.com/SagerNet/sing-box/releases/download/v1.10.1/sing-box-1.10.1-linux-amd64.tar.gz


    2. 解压安装包
    tar -zxvf sing-box-1.10.1-linux-amd64.tar.gz

    3. 进入程序目录
    cd sing-box-1.10.1-linux-amd64

    第五步:精准配置(对准连接暗号)

    为了确保连接的唯一性和安全性,我们需要手动写入配置文件。这里我们直接锁定 UUID 和 传输路径,避免了脚本随机生成导致的不确定性。

    把这里的UUID修改成自己的。

    cat <<EOF > ./config.json
    {
    "log": { "level": "info" },
    "inbounds": [{
    "type": "vless",
    "tag": "vless-in",
    "listen": "::",
    "listen_port": 8080,
    "users": [{ "uuid": "4ee06e75-4605-4cbd-896a-c88e7751cbbb" }],
    "transport": { "type": "ws", "path": "/vless" }
    }],
    "outbounds": [{ "type": "direct", "tag": "direct" }]
    }
    EOF
     

    第六步:正式点火启动

    运行以下命令,让服务在后台跑起来:

    ./sing-box run -c ./config.json

    第七步:打通最后一公里(关键权限设置)

    这是最重要的一步!GitHub 默认端口是私有的,我们需要手动公开:

    点击底部的 Ports 标签页。找到 8080 端口对应的 Local Address(或者右键点击端口选择 Copy Local Address),这才是填入客户端的“地址”。在 Visibility 那一列,右键点击并将 Private 改为 Public。

     

    配置参数对照表(以 v2rayN 为例):

    地址 (Address): 填你的 GitHub 预览域名 (不带 https://)

     端口 (Port): 443 (核心重点!)

     用户 ID (UUID): 4ee06e75-4605-4cbd-896a-c88e7751cbbb(你自己的UUID)

     传输协议 (Network): ws

     伪装类型 (Header type): none

     路径 (Path): /vless

     底层传输安全 (TLS): tls

    SNI: 填你的 GitHub 预览域名

     

    快速复活小技巧:

    如果发现连接点失效,登录 GitHub 进入项目,点击底部的 Terminal,按键盘“向上箭头”找回命令 ./sing-box run -c ./config.json 回车即可,无需重新配置。

     核心避坑指南(干货必看)

        端口陷阱:虽然我们在 Codespaces 内部监听的是 8080 端口,但由于 GitHub 的转发层强制加密,大家在客户端填写时,端口务必填 443,传输协议选择 WS,并开启 TLS。

        连接验证:一旦客户端配置正确并点击连接,你的终端会立刻跳出绿色的 connection accepted 字样。看到这个日志,就说明你已经成功免费试用到了微软的高速网络!

        休眠机制:请注意,Codespaces 在无操作一段时间后会自动休眠。如果发现连不上了,记得登录 GitHub 重新启动该容器即可。

    结语

    通过这种手动配置的方式,我们不仅绕过了繁琐的脚本报错,还深刻理解了连接点运行的底层逻辑。这种利用云端资源的方式非常适合临时办公和技术研究。

mkdocs-blog-plugin(静态网站程序mkdocs的博客插件)

 This plugin for MkDocs allows to keeps a really simple blog section inside your documentation site. 

 

Blogs for MkDocs » (MkDocs-Blog-Plugin)

This plugin allows you to host a tiny blog section in your MkDocs site.
Move away, WordPress... well, not really.

https://raw.githubusercontent.com/fmaida/mkdocs-blog-plugin/master/screenshot.png

How does it work ?

It's quite simple. 90% of the work is already done by MkDocs itself.
Each time you will build your MkDocs site or serve it, this plugin will try to find a specific directory in your documentation folder. If it finds it, every document and every subdirectory nested in it will be listed in reverse on the navbar. Plus, if you will have too many documents to be listed at once, the plugin will try to organize your remaining documents in subfolders.

How can I install it ?

You can install it through pip with this command:
pip install mkdocs-blog-plugin
Then, open your mkdocs.yml configuration file and add these lines:
plugins:
    - blog
Last but not least, enter you docs folder and create a new subfolder and name it blog. This plugin will try to find blog articles inside this directory.

Then you are ready to begin.

How can I add new articles to my blog section ?

Inside docs/blog create a folder for each year you are planning to add new articles. Then, inside each year folder create twelve folders, numbered from 01 to 12 for each month. Finally, in each month folder for each day create a corresponding folder but remember to add a leading zero (for example: 08, 09, 10, ...) Now, for every article you will go inside the corresponding `year/month/day folder and you will create a new file there. While it is not necessary that you keep this strict naming convention, this will help the plugin to understand when your article was made.
For example, this is how I manage my blog folder:
docs
├── blog
│   ├── 2019
│   └── 2020
│       ├── 01
│       │   ├── 20
│       │   │   └── first-article.md
│       │   └── 26
│       │       └── second-article.md
│       ├── 02
│       │   ├── 01
│       │   │   └── third_article.md
│       │   └── 09
│       │       └── fourth-article.md
│       └── 03
│           └── 16
│               └── fifth-article.md
└── index.md

Customizing the plugins

You can customize this plugin by adding some parameters in the mkdocs.yml file, like this:
- plugin:
      - blog:
          format: "(%m/%d/%y)"
          text-align: "right"
Here is a brief list of every parameters supported by the current version of the plugin:

folder

This is the section / folder in which we'll try to build our blog
Default value: "blog"

articles

How many articles do we have to display on our blog at once? More articles will be displayed in the corresponding subsection
Default value: 6 articles

more-articles

Let's allow our user to slightly customize the "previous articles" section. How do we have to name this section if it will contains more articles? Remember to put a percentage character wherever you want this plugin to insert the number of available articles.
Default value: "More articles (%)"

pagination

Which name do we have to give to each subsection inside our "more articles" section? Remember to put two percentage characters wherever you want this plugin to insert the actual number page and the total amount of pages made.
Default value: Page % of %"

display-more-articles

Can we display the previous articles section, or is it better if we hide it?
Default: True

display-article-date

Can we display the article date in the navbar, or is it better if we hide it?
Default: True

format

How we have to display an article publication date on our navbar?
You can use these placeholders inside your string:
  • %d = Day
  • %m = Month
  • %y = Year (2-digits)
  • %Y = Year (4-digits)

Default value: "[%d/%m]"

text-align

Do we have to display an article publication date on the left side ("left") or on the right side ("right")?
Default value: "left"

from  https://github.com/fmaida/mkdocs-blog-plugin

-----

相关帖子:

在linux vps上,搭建基于python的静态网站程序-mkdocs

 

a laravel-blog-app

 https://github.com/ajaymarathe/laravel-blog-app

mbonat_site

 

This is my (old) personal website. I built it in Ruby on Rails with Haml and other tools. Includes: portfolio section, resume, speaking, and blog with the most recent blog post on the home page. It's open source feel free to fork it.

This is the personal website for Michelle Bonat, built by her (me).

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

  • Postgres (OSX users can run brew install postgresql)
  • bundler (gem install bundler)
  • Ruby 2.2.2
  • Any environment variables you prefer to setup and use

Installing

  • bundle install
  • (start your Postgres db)
  • rake db:create (TODO: create seed data)
  • (remember to migrate which in a Rails 4 app is rake db:migrate)

To create an initial admin user, fire up rails c and do the following:

u = User.create(username: "Whatever", password: "foo123456", email: "me@domain.org", password_confirmation: "foo123456")
u.activate!
u.is_admin = true
u.save

Running the server

  • rails s

Running the tests

There are pre-seeded rspec tests. To run these it is 'rspec spec' from your command line.

More about the tests

These pre-seeded tests are based on factories for posts and users, and include feature, model, and policy tests. See the RSpec folder for details.

Deployment

Since this is a Ruby application, deploying it to Heroku is easy.

Built With

  • Ruby
  • Rails 4

And the usual suspects including:

  • Html
  • CSS
  • Javascript

from  https://github.com/michellebonat/mbonat_site