不需要服务器，免费搭建自己的博客网站

从 Typecho 迁移到 GitHub Pages 的完整记录

前言

我的云服务器到期了。上面跑着一个 Typecho 博客，文章不多，撑死几十篇。续费一年几百块，就为了托管一堆静态 HTML 页面 —— 怎么算都亏。

于是决定搬家。新方案的要求很简单：不花钱、不用维护服务器、写文章不费劲。

最终选了 GitHub Pages + Hugo。这篇文章记录整个迁移过程，踩过的坑和处理思路都写清楚。如果你也打算把自己博客从动态系统迁出来，直接照着来就行。

作为 PHP 开发者，我们迟早都会遇到一个瞬间：

代码没有报错，逻辑也没问题，但系统就是——慢。

不是慢一点，是那种

「明明只是检查 1000 个账号状态，却要跑半个小时」

「服务器 CPU 不高，但请求就是排着队等」

的慢。

最近搞项目刚好遇到了一个业务场景，多租户系统中，根据账号采集数据，采集前先要确认账号是否有效（就像根据IP代理爬数据一样，爬数据前先确认代理是否有效），于是我按照以往的经验，很自然的写了这样一条链路：

1. 循环取出一个账号

2. 检测状态

3. 拉数据

4. 账号异常，再换下一个账号，重复执行1、2、3

逻辑看似没问题，代码也很优雅。直到我测试的时候，跑了一次完整的任务。1000个账号，跑了30分钟还没跑完。我查看了CPU，内存也不高，但就是很慢。为什么呢？

问题不在算力，而在于PHP在大量IO等待中，被迫排队！

这个时候就是协程（Coroutine）大显身手的时候了。下文将结合业务和实战（编码）深入理解协程，并展示如何在Laravel中构建基于协程的高性能多租户采集系统。

我不是前端工程师。

但这次，我一个人完成了一个包含聊天窗口、WebSocket 实时推送、多语言翻译、复杂 UI 状态管理的前端项目。

说实话，如果没有 AI，这个项目我大概率会延期，甚至放弃一些体验上的细节。

一、前言

前端时间接了一个前端聊天+后端管理后台的项目，两个项目都是我自己一个人完成。

说起来后端还好，但是前端html+css那套我最开始入行的时候学了一点，但是后面正式工作后主要还是围绕后端语言来展开，前端的那套样式语法就渐渐地放下了；

但这次是一个全新的机会，也是一个新的挑战，需要自己写前端。那如何快速写前端项目，并快速交付呢？于是我想到了AI这个帮手，之前总拿它来排查问题，但是写一个项目行不行呢？ 我抱着怀疑的态度开始了这项“挑战”，并最终“有惊无险”的落地完成，顺利完成交付；

本篇文章，我想详细的复盘下这次经历：如何与AI沟通？ 如何合理利用AI完成代码的实现？以及举例一些聊天系统中实现的业务关键点！

前言

最近在家失业无聊，接了个单，其中有个项目就是关于后台管理系统的，发了几个模板样例给对方，有之前用过的后台框架fastadmin、laraveladmin，但是对方看了都觉得怎么跟他之前的后台一个样，要求换一个简洁一点的，于是我在网上搜了一下laravel还有哪些后台框架，于是看到了dcatadmin，把demo网站发给对方看过之后，觉得这个页面还好，比较简单，随交流沟通后，确定用这个后台。

话说dcatadmin

dcatadmin这个框架我还是第一次用到，之前用laravel的后台框架都是用的laravel-admin，相对来说比较熟悉一点，dcatadmin还是第一次听到（因为上份工作都是围绕yii框架来展开的，关于laravel的消息确实查看的不多）。

dcatadmin2.x文档- 简介 | 入门 |《Dcat Admin 中文文档 2.x》| Laravel China 社区

看完整体下来，dcatadmin重点需要了解的其实就是3个部分，也是后台系统中的组成：数据表格、表单、详情

但是还是有些地方没怎么看懂，尤其是关于工具表单、异步加载这块儿。时间有限，索性就在开发的过程中，再去搞清楚吧

因为现有文档描述不清，在开发过程中自己也是踩了不少坑，以下内容总结了在dcatadmin2.x中常用的几个功能，如有遇到类似疑问的开发者，可以少走一些弯路

一、前言

在工作的这么多年中，其实有很少能接触到挑战自我的项目。在小公司当个小组长，无非就是curd、部署项目、搭建gitlab、review同事代码等繁琐的工作，偶尔写写前端。大公司的话，工作内容其实就没这么繁琐了，部署项目有运维，页面有前端同事，review有部门leader，工作中80%的时间都是curd，当然会有一些小型的基于需求的项目来做，但都是能力范围之内的。

在我这短暂的开发生涯中，还真就遇到过那么一次让我觉得非常有挑战性的事，那就是从php转python，从0到1实现爬虫架构。从结果上来说，虽然达不到100%的爬取成功率，但整个过程也可以说是倾尽了全力，当然这也是我为数不多的我绞尽脑汁想完成的项目（主要是这个项目完成之后的绩效比较诱人，咳咳咳~），而且我对新东西、新事物都有种想挑战一下的心态。

今天就来讲一下我是怎么从0到1实现整个爬虫架构的。

首先声明：我是主导者、也是参与者，当然后期还有更专业的python同事一起加入，帮我调优，给我优化意见，最终才合力完成的这个项目，不是我一个人的功劳。

前言

众所周知，SQL文化博大精深，SQL优化那阵算得上百花齐放，啥样的优化方式都有。而我虽然天天干着CURD的工作，和SQL天天打交道，其实说句实话，对SQL优化确实所会不多，只能算的上是皮毛。

这不，什么不会就来什么，刚入职还在试用期的时候，老大派来一个任务

：“小陈，我们有个开户的流程，从其他平台迁移过来，你对接下”

：“好的，老大”

：“对了，还有一个开户的动作，特别慢，要半小时甚至更久才能完成，你顺便优化一下”

：“好的”

什么开户？什么流程？什么优化，刚接到这个问题的我也是一头雾水，后面再深入了解了一下，大概明白了这个问题的来龙去脉

一、引言

不管是在电商系统、还是物业系统中都会存在一个账单的东西，账单号是每一个账单的标识，这个标识是唯一的、且不可重复的。

在电商系统中，账单号就等同于订单号；在物业系统中，账单号就是每一次向业主催缴费的账单。

这个账单号一旦重复结果可以说是灾难级的，在物业系统中，收费的时候，明明不是这个业主的钱，怎么多算了；而另一个业主的钱甚至少算，或者该缴的费用被其他业主缴了等等，涉及到钱的问题那就是大问题了。

这篇文章，我们就来具体分析下这个问题，并给出解决方案。

一、前言

在我从事的工作经历中，其实接触的电商行业还挺多的，大概占经历的6、70%左右。

而在电商项目中，用到缓存的场景就很多了，像数据缓存、CDN缓存、页面缓存等等，redis是最常用的key-value数据库了，memechache虽然和redis同样都是内存数据库，但是使用的最多的还是redis。

在使用redis之前，先简单了解下redis的特点和数据结构吧；

有时候在安装PHP的时候，会漏掉一些平时不太常用的扩展，到以后再要去安装的时候，时常会因为版本不对出现各种问题，本文主要介绍一下通过简单几步安装扩展的方式。

2020已经过去快两个月了，才有（想）时（起）间（来）写一下过去一年的总结。其实在年初的时候，各大社区在做有关【2020总结】的时候就想参与一下，但是一直没有提起日程。对于过去一年的回顾以及新的一年的展望就从这篇文章开始吧。