@wellhome #9 加油吧兄弟，我不知道你比我大还是比我小，最近我也正在经历这样的危机。#5 发那句话的本意是想鼓励鼓励。说自己的能力的时候，能把英语放到技术前面的，说明应该不差，可以考虑找找对英语有要求的工作岗位。

年龄老了并不可怕。可怕的是自己认为自己老了，就放弃自己最擅长的事情，想走捷径，想走偏门。

python3-xhtml2pdf/stable 0.2.5-3 all
A library for converting HTML into PDFs using ReportLab (Python 3 module)

想起来有一种格式叫 shtml ，支持服务器端 include ，这样你的页头页尾等等就可以不用重新编译，只需编译内容页后，include 了

@harrozze #51 你想让第一个用户访问的时候也很流畅的话，就自己做真正的第一个用户。发布完 md 就去访问一下

可以考虑 用户第一次访问时才转换 md =>html ，并且程序检测 两个文件的更新时间，发现 md 更新的时候，重新转换。这样你的 php 负载很小，大部分都可以 redirect 到 html 文件的 url 去。

都树莓派了，有个 idea 就是用它控制家里的电器，再配合点其他嵌入式小卡片机之类的。

@coderxy #6 以前做过你在 #5 说的方式，用 python 做一个论坛的过滤还是能行的。DFA 是一种方式，还有一种方式是分级处理。如果 OP 也是要做敏感词过滤的话。也就是说，对于非卡脖子的敏感词，用先发后审的方式分布式处理。

我知道了，发评论的时候看不到空行，回来看就有了

@wcao #6 另外是，你可以预先设定 下一个 和 下下一个 里程碑，这样其实每次完成一个里程碑，也只需要增加一个"下下一个“。issue 或 pr ，也并不是每次都会包含在下一个版本的，甚至有可能包含在 1.0=>2.0 的升级中？

另外。。。你中间的空行怎么打出来的…… 😂

@wcao #6 先创建里程碑是项目管理流程里要求的，通常是先把完整需求进行拆分，由于大项目通常耗时比较长，而超过两周（我不记得具体理论里说是多久了）的一个项目基本上时间预估就不靠谱了，所以用里程碑的方式同时达到 大项目分拆成若干小项目 和 对小项目建立检查点 的目的。当然，你可以不用考虑对完成时间的约束，只用来表示某个自洽功能集完成，就可以发新版了。对于现在的小步快跑的开发模式也同样适用，先设定一个时间跨度相对较短的功能或任务集目标，作为下一个里程碑（时间要求并不强制），然后分拆具体任务，分拆到估计工时和实际工时基本相等的颗粒度即可。

我是习惯这种先计划后开工模式的，所以不觉得先设定 milestone 会增加麻烦。如果有那种还没考虑到底放到哪一期实现的功能，可以先不写属于哪个里程碑，定期回顾和排期（里程碑归属）即可。

@wcao #3 明白你说的了，确实是这样。不过创建里程碑的频率应该不会高于创建 issue 或者 project 里的 item ？

@wcao #3 我看不到你发的图 😂 不过我猜应该是我说的那个。一般是先创建好 milestone ，然后创建 issue 的时候就可以直接选了。我是在 gitea 里用的，等我去 github 上看看操作流程。

@harrozze #1 project 的视图里，也可以再加一列 milestone 的

issue 里有 “Milestone No Milestone” 的设置，你没用起来。不然 issue 列表的视图本身就可以用 milestone 做聚合

@julyclyde #24 对，监控文件改动就去执行的方式，缺点就是缺乏一个明确的信号，容易漏，容易出错误（比如，如果不知道需要把所有指令一次性写入的话，有可能会一行甚至半行式的增加文件内容）导致非预期的结果。

如果你打算继续走开发这条路，那么技术是你的核心竞争力，对业务的理解能力是你的增强型能力。就是说，能够比较容易和透彻的理解业务，会对需求有更深的理解，从而在做技术实现的时候能更好地配合业务展开。

@harrozze #67 而且服务器再跳服务器，跳来跳去也可以这么配

@DinnyXu #65 .ssh/config 里设置配置一下别名，host1, host2, .... host27 。而且服务器再跳服务器，跳来跳去也可以这么配