道远日暮时不存

这里是一些常见的 MIME 类型，按类别分类： 文本文件 text/plain: 普通文本文件 text/html: HTML 文件 text/css: CSS 文件 text/javascript: JavaScript 文件 text/csv: CSV 文件 text/calendar: iCalendar 文件 图像文件 image/jpeg: JPEG 图像 image/png: PNG 图像 image/gif: GIF 图像 image/svg+xml: SVG 图像 image/bmp: BMP 图像 image/vnd.microsoft.icon: 图标格式 音频文件 audio/mpeg: MP3 音频 audio/wav: WAV 音频 audio/ogg: OGG 音频 audio/aac: AAC 音频 audio/midi: MIDI 音频 视频文件 video/mp4: MP4 视频 video/webm: WebM 视频 video/ogg: OGG 视频 video/x-msvideo: AVI 视频 应用程序文件 application/oc ...

背景最近, 由于托管到jsdeliver网站的全球免费的静态资源域名cdn.jsdelivr.net在国内突然访问被限速(甚至某些地区打不开)。 造成在cdn.jsdelivr.net托管的css、js等文件也无法流畅访问, 进一步造成了 hexo博客框架下butterfly主题加载缓慢甚至有的内容无法正常加载。如下图: 对本博客最直接的影响就是, 加载时间延长, 很多主题内容无法流畅显示, 比如: cdn.jsdelivr.net下托管的fontawesome图标无法正常显示(显示方框很长时间后,才能加载出正常对应的图标)。 那么本文就以fontawesome图标为例, 讨论此类情况的整体解决方案, 其他类似问题都可参考本文解决。 解决方案整体有两种方案 1、切换其他部署有所需目标资源的域名地址优点: 省事儿, 省流量 缺点: 受外部影响 操作过程: 以fontawesome图标资源为例,其默认地址如图 先找到一个可以代替此地址的,部署有fontawesome的域名地址 自己找,本站不提供 将获得的地址,配置到主题bufferfly下的_config.yml文件中 ...

前言从21年8月份的新工作至今已有七八个月了, 工作的开发主力机是公司安排的windows10, 为了尽量使命令行操作更接近与linux, 用上了gitBash, 并通过配置window终端和vscode终端默认使用gitBash来满足自身需求。 不过这两个客户端的快捷键可配置项不尽如人意, 无法做到完全一致的自定义配置。于是在此总结下自己的最终配置, 并等待它们的更新, 看什么时候它们俩的配置项可以做到完全一致的快捷键配置。 为何我说两者无法达成一致 从快捷键支持来看, vscode终端更强: windows终端不支持多个快捷键的设置, 只能支持常用的 ctrl+字母、alt+字母、ctrl+shift+字母…等之类的(比如ctrl+字母 ctrl+字母的快捷键, 就无法支持)。 不过vscode支持如ctrl+字母 ctrl+字母的快捷键 从终端支持的配置来看, window终端更强 windows终端支持单终端标签(vscode中称为终端组)内, 多个终端窗格(vscode中称为终端)间的创建(vscode中称为拆分)和移动(vscode中称为聚焦), 且上下左右 ...

Gin Quick StartContents Gin Quick Start Contents Build tags Build with json replacement Build without MsgPack rendering feature API Examples Using GET, POST, PUT, PATCH, DELETE and OPTIONS Parameters in path Querystring parameters Multipart/Urlencoded Form Another example: query + post form Map as querystring or postform parameters Upload files Single file Multiple files Grouping routes Blank Gin without middleware by default Using middleware Custom Recovery behavior How to write log fi ...

前言docker用的多了, 偶然用一次linux的命令竟然忘记了, 虽然这类东西搜索下就可以很快得到答案, 但毕竟不常用, 懒得每次都搜索, 所以这次就随便找一篇转载整理上来吧, 万一又用的时省点事(少大一个字是一个字)。 Linux如何后台运行服务如何开启1、nohup用途：不挂断地运行命令。 语法：nohup Command [ Arg … ] [　& ] 　　无论是否将 nohup 命令的输出重定向到终端，输出都将附加到当前目录的 nohup.out 文件中。 　　如果当前目录的 nohup.out 文件不可写，输出重定向到 $HOME/nohup.out 文件中。 　　如果没有文件能创建或打开以用于追加，那么 Command 参数指定的命令不可调用。 退出状态：该命令返回下列出口值: 　　126 可以查找但不能调用 Command 参数指定的命令。 　　127 nohup 命令发生错误或不能查找由 Command 参数指定的命令。 　　否则，nohup 命令的退出状态是 Command 参数指定命令的退出状态。 2、&用途：在后台运行 一般两个一起用 ...

分析日常开发中, 往往有这样一直需求 – 解析文件。针对文件的解析工作, 有两种场景让人头疼: 单个文件过大, 如 5G 以上甚至更大。 -> 常见于年久失修的 log 日志。 I/O 瓶颈 是一个无法逾越的鸿沟, 因此 对于此种情况的常用处理方式 通常会利用 linux的tmpfs这个内存挂载, 也就是 这个路径目录 -> /dev/shm/ 整体文件夹大小过大, 但内部都是些小文件组成的, 也就是需要解析的文件数量过多, 通常一个解析文件夹中就包含了成千上万个文件, 但是单个文件小, 通常不到10M。 -> 常见于 测试报告之类的报告集合。 虽然也存在I/O瓶颈, 但由于单个文件过小, 往往根本无法触及 I/O 瓶颈, 达不到其吞吐量, 因此利用 内存文件系统 对其进行操作的意义不大, 存在较大的优化空间, 可以利用多线程来磨平I/O瓶颈, 是其瞬间吃满吞吐量, 从而保证读取文件的速度。 此种情况下, 是否利用 linux的 tmpfs内存挂载, 意义已经不大了, ...

介绍一、临时对象池(pool)的设计目的是用来保存和复用临时对象，以减少内存分配，降低CG压力; 同时, 利用对象还实现了临时对象的复用, 从而降低某些场景下重复申请内存所消耗的时间。 想感受下对象池的威力的话, 就一起看一个简单的例子吧: 123456789101112131415161718192021222324252627282930313233343536373839404142package mainimport ( "fmt" "sync" "time")type structR6 struct { B1 [100000]int}var r6Pool = sync.Pool{ New: func() interface{} { return new(structR6) },}func usePool() { startTime := time.Now() for i := 0; i < 1 ...

以下是一个详细的 ping 命令示例： 1ping -n 10 example.com 这个命令会向 example.com 发送 10 个 ICMP 请求。你可以将 example.com 替换为你要测试的 VPS 的域名或 IP 地址。 运行这个命令后，你会看到类似以下的输出： 12345678910111213141516Pinging example.com [93.184.216.34] with 32 bytes of data:Reply from 93.184.216.34: bytes=32 time=30ms TTL=54Reply from 93.184.216.34: bytes=32 time=29ms TTL=54Reply from 93.184.216.34: bytes=32 time=31ms TTL=54Reply from 93.184.216.34: bytes=32 time=30ms TTL=54Reply from 93.184.216.34: bytes=32 time=28ms TTL=54Reply from 93.184.216 ...

讲解Github上的 Merge pull request 提供了 3 种 merge 方法(注意没有平常使用时快进式的merge)： Create a merge commit：GitHub 的底层操作是 git merge –no-ff。feature 分支上所有的 commit 都会加到 master 分支上，并且会生成一个 merge commit。这种方式可以让我们清晰地知道是谁做了提交，做了哪些提交，回溯历史的时候也会更加方便。 --ff(fast-forward): 是快进式合并, 也是我们日常使用merge的默认合并方式。 (缺点是如果删除分支, 就会丢失分支信息, 比如你在分支上的stash链表)。 --no--ff: 是非快进式合并, 也就是不使用快进式合并的意思, 也就是为什么单一的线上分支中会发现一些相同内容的不同提交的原因。 因为它是非快进式的, 在合并时是一定会产生一个新的提交的 (也就是说, 如果你pr中有多个commit, 他会将分支的所有commit都加到线上分支中, 然会生成一个pr中所有commit的squash提交记录)。 这种方式可以 ...

前言最近在项目中用到了sync.Pool来复用我的结构体, 但遇到了点问题。 我的结构体中有几个切片, 并且这几个切片的最终size是比较大的, 但是我的项目中有不稳定因素, 因此这里无法使用固定长度的数组来代替。 可是我使用sync.Pool的目的就是为了复用这些 size, 从而降低GC的压力, 但 对于sync.Pool的使用中, 我必须在 Put 前, 重置某些可能影响复用的字段, 当然, 这些字段中就包含我的这两个切片, 我尝试用 nil切片(nil slice)->即赋值为’nil’ 或是 空切片(empty slice)->即赋值为 ‘[]string{}’ 或 ‘make{[]string,0,0}’ 来对其进行重置, 可由于这种重置过程, 改变了切片底层指针字段指向的地址, 进而造成 原有底层数组 失去引用, 被GC标记给干掉。 于是乎, 我的 我的sync.Pool 实际上只复用了我的结构体对象所占用的size, 并没有复用到 对象中 字段所 指向的 原有堆空间地址(如切片的底层数组), 最终不光没有降低GC的压力, 反而伴随sync.Pool的引入还 ...