关于中医等传统医学的一些思考
关于传统医学与现代医学的争论，包括知乎在内的国内各大互联网平台都有过各种争论，当然争口舌之快是没有意义的，医学诞生和发展的根源的是为了帮助病患缓解或者解除痛苦。那么，至关重要的一点便是“疗效”。
这里我们不想深入展开一些探讨，但是我希望能够引起一些思考且具有实际意义的案例是——2015年屠呦呦奶奶发现的青蒿素（今年老人家已经91岁啦，愿寿比南山）。
我们思考这样一些问题：
青蒿素的发现，得益于传统医学古籍的一些记载。但是在没有进行现代医学的加工和合成以前，单纯青蒿对于疟疾的疗效并不好，抑制率仅有12%，也就是疗效并不佳。而经过现代化学手段合成的青蒿乙醚的抑制率却达到100%。这能够给我们哪些启发？
根据问题1，我们能否武断或极端地对传统医学或现代医学做出评价？谈谈你的看法。
在引言中，我们的讨论中心在于”疗效“。从问题1的案例中，我们得知，经过现在医学的改进和加工，青蒿从仅仅存在于古籍中的，中医的治疗偏方——有一定疗效但不显著的普通药材，升级+Lv100%，成为了今天治疗疟疾备受赞誉的神药。
那么从这个意义上来说——青蒿素使得不可计数的饱受疟疾折磨的患者，得以解除痛苦，摆脱疾病。传统医学和现代医学的结合便是有意义的，医学目的得以圆满实现。
而假设我们将中西医割裂开来独立发展，也能取得这样的成功吗？
- ”不能为了发展医学而发展医学，医学是一门极具实际意义的学科，不论过程如何，能够让大量的患者免受疾病的折磨，才是医学的根本。对于传统医学，我们推陈出新、革故鼎新之处也立足于这个“根本”。继承和发扬无论形式如何，都应该呼应这个“初衷”，这也是本文开篇提到的，口舌的争论是没有任何意义的。如果我们不巧患病了，这些争论派不上任何用场“，你认为呢？
低维护成本的软件开发
本文转载
目标
没有技术债务。
软件的设计是容易理解的，需要修改软件时，将很容易找到相应的代码。
软件以可维护为最优先目标，开发者可以在忘记它的数年后回来继续改进它。
软件无限接近完成状态，直到因环境变更而落后或新的需求出现为止都令人满意。
可以自信地升级主版本相同的依赖项。
原则
实现低维护成本的软件开发的关键不在于少犯几个错误，而在于尽量把事情做对。
诚然，这是相当有难度的，因为大部分软件项目是生长出来的，不可能一开始就做到完美。
此处总结了一些有助于实现低维护成本的软件开发的一般原则：
摒弃所有非必要功能。
停止使用生态环境不健康的语言和工具链。
使用具有强表达力的语言，避免在编码过程中扭曲和偏离语言的常见模式。
停止将宏用于任何可能产生代码坏味道的目的。
只使用具有类型定义或类型标注的语言。
尽可能使用经过时间检验的技术，因为这些技术有希望存在更长时间。
全局性地思考问题，避免战术编程。
积极重构代码，允许大量的代码行修改以降低软件熵。
通过将复杂性转移给使用者来砍掉不那么必要的设计，因为人性化的设计往往是最难以维护的。
现实中类似的例子已经有很多了。
让我们考虑一下Markdown编辑器和所见即所得编辑器：
前者需要用户付出（极少量的）学习成本，而后者几乎没有学习成本，然而，后者在可维护性上要比前者差得多：
Markdown编辑器更容易编写出结构清晰，人类可读的纯文本文件。
所见即所得编辑器编写出的要么是难以迁移的内部文档模型，要么是完全陷入混乱的HTML。
Markdown文档在2050年还可以使用，Markdown编辑器往往是极简和可替代的。
所见即所得编辑器更容易过时，维持向下兼容性更困难，对开发者来说也更难维护，供应商在2050年很可能已经不复存在。
停止使用可能导致供应商锁定的大型软件框架。
当一个软件框架正在适配一切环境，或是企图提供一站式解决方案时，它不再是软件框架，而是一颗定时炸弹。
尽可能减少依赖低质量的软件包。
这意味着对依赖进行代码质量审查，幸运的是，坏代码风格很容易识别，往往不需要真正理解软件包的工作原理就可以下判断。
不为没有向下兼容性的平台编写软件。
除非软件功能单一，否则应该尽力避免让软件跨平台。
禁止使用云计算平台提供的专有服务。
禁止使用不能锁定子依赖项版本的包管理器，禁止使用Git仓库作为软件包的来源。
如非必要，不应迎合现存的标准和协议：
大多数标准和协议是垃圾，其中大部分甚至没有参考价值，迎合它们只会拖累软件的发展。
例如，你可能会不幸地遇到无法用这些标准和协议实现的需求，然后陷入进退两难的窘境。
那些非常流行以至于无法被忽视的标准和协议，其流行度大多来自于它们的先发优势，以及向后兼容的保证。
这使得它们在生产中的实现充斥着各种奇怪的边缘案例，收集和应付这些边缘案例会让人精疲力尽。
关注工具链的抽象水平，停止使用难以迁移或升级的工具链。
编写大量自动化集成测试，以提升依赖项升级时的安全感。
软件运行所需的环境应当是专用的，隔离的，而不是与其他项目共享的。
重视技术的自有化，尽可能剥离会受外部因素影响的依赖。
重新发明轮子
重新发明轮子是一种反模式，因为总是已经有一个或多个已经发明好的轮子等着你复用。
然而，对已有轮子的复用经常引发依赖管理问题。
这是因为最简单的道路往往是技术债务最重的道路。
甄别轮子够不够好是一项能力，背后需要经验的支持。
糟糕的第三方软件是普遍性的，就连大多数有一定规模的热门开源软件也是一座座屎山：
它们往往具有错误的抽象，糟糕的架构，可怕的API表面积。
缺乏令人信服的测试，没有得到积极维护，代码质量差，文档和实际代码不一致或掩盖了重要的细节。
太多的战术编码，太少的战略编码，为不存在的需求投入过多时间成本最终导致软件膨胀和腐烂。
除非社区里有能够以战略视角控制架构，并且严格执行代码审查的积极维护者或终身仁慈独裁者，
否则开源软件的参与模式天然会制造这种屎山，无论贡献者的水平有多高。
闭源软件也会有同样的问题，只是闭源软件的不透明性掩盖了这些问题，被扫到地毯下面不代表糟糕的部分消失了。
为了从技术债务中解脱，有时你只能戴上
NIH
帽子。
通过重新发明轮子，你可能会注意到，除了能让我们摆脱糟糕的第三方依赖以外，重新发明轮子还有一个鲜为人知的好处——
有可能会发明出更好的轮子。
当然，重新发明轮子应该评估其经济性，有一些轮子你显然是不想，也不应该重新发明的，比如游戏引擎，编译器，集成开发环境，文本编辑器等。
这些软件具有非常强的专业性，从外部侵入这些领域的顽固份子将耗费大量时间并且大多会以失败收场。
构建电池式依赖
一些编程语言和框架会声称自己包括电池（batteries included），这指的是它们内置了可以直接使用的高级功能。
这些“电池”的本质只是相对稳定的，极力避免暴露底层细节的高级API，正确的抽象和测试使得它们很少出现破坏性变更。
“电池”的概念完全可以套用到依赖管理上，可以建立这样一种“电池式依赖”：
这种依赖是实际使用依赖的项目与依赖项之间的中间层，它基于依赖项提供一套有序整洁的API，
从而允许避免让业务代码直接使用那些野蛮人发明出来的带有巨型或巨量参数的函数或类。
由于你只关注这些依赖项中使用到部分，你可以在中间层编写自己的测试代码，以确保在依赖项版本更新时，其行为仍然符合预期。
当未来依赖项失效时，你可以选择用旧版本的依赖项，更换依赖项，或是自己实现，之前编写的测试被用来保证重构时的有效性。
这便是自己构建的电池和他人构建的电池之间的关键区别，你总是可以给自己的电池充电或扩容，而对于他人的电池，通常你只能看着它慢慢没电。
由于形式上的相似性，可能会混淆电池式依赖和经过封装的业务逻辑，两者的主要区别在于它们与依赖项之间的距离。
电池式依赖通常距离依赖项很近，而业务逻辑通常距离依赖项很远。
只有在少数场合，例如业务逻辑直接建立在相关依赖上的情况下，两者才趋于相同。
电池式依赖似乎是解决依赖管理问题的圣杯，但仍然有几个问题：
1.
它毕竟是额外的中间层，当你需要新功能，或是进行破坏性变更时，都要比直接使用依赖项要麻烦些。
2.
建立正确的抽象很难。
在摸索正确抽象的道路上，有时不可避免会需要推倒重来。
人们对未来的需求也经常缺乏预见性，因此一时正确的抽象也可能在未来显得不正确。
人们害怕项目由于错误的抽象陷入反复修改的困境，所以宁可把自己卷进一个更大的漩涡里，至少在出错时怪别人总是更容易，很难反驳这种想法。
使用小型软件包
小型软件包是Unix哲学和语义化版本控制的共同体现。
软件包的粒度越小，单个包的功能就越少，功能越少就越稳定，改变代码会打破的东西也就越少。
小型软件包有时会带来一些新的问题，例如软件包数量激增带来的管理问题。
这类问题会很棘手，因为它们会随着日积月累变得越来越难以靠蛮力解决。
这种趋势最后会逼出一些专门的解决方案，例如Facebook的codemod之类的东西，但使用这些东西仍然很麻烦。
能帮我出一些sql语法的练习吗 要postgre的
当然可以，以下是一些基于PostgreSQL的SQL语法练习题：
创建表：
CREATE TABLE Employees ( id SERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL, age INT, department VARCHAR(50), hire_date DATE );插入数据：
INSERT INTO Employees (name, age, department, hire_date) VALUES ('John Doe', 30, 'Sales', '2020-01-01'), ('Jane Smith', 28, 'HR', '2019-05-15');查询所有员工信息：
SELECT * FROM Employees;根据部门查询员工：
SELECT * FROM Employees WHERE department = 'Sales';统计各部门员工数量：
SELECT department, COUNT(*) AS employee_count FROM Employees GROUP BY department;查询年龄大于30岁的员工：
SELECT * FROM Employees WHERE age > 30;更新员工信息：
UPDATE Employees SET department = 'IT' WHERE name = 'John Doe';删除某个员工记录：
DELETE FROM Employees WHERE id = 1;使用JOIN查询（假设有一个Departments表）：
SELECT E.name, D.department_name FROM Employees E JOIN Departments D ON E.department = D.department_id;子查询：找出每个部门中最早入职的员工。
SELECT E1.name, E1.department FROM Employees E1 WHERE E1.hire_date = ( SELECT MIN(E2.hire_date) FROM Employees E2 WHERE E1.department = E2.department );
以上这些练习涵盖了基本的CRUD操作以及一些进阶的SQL查询技巧。你可以根据实际情况调整表结构和字段以适应你的数据库环境。
[查看全文]
浏览器里面要如何使用sse（Server-Sent Events）
Server-Sent Events（SSE）是一种让服务器向浏览器客户端推送实时更新的技术。在浏览器中使用SSE，通常需要通过JavaScript的EventSource对象来实现。
以下是一个基本的使用步骤：
// 创建一个新的EventSource对象，URL指向提供SSE服务的端点
var source = new EventSource('your_sse_endpoint_url');
// 当接收到服务器发送的消息时触发的事件处理器
source.onmessage = function(event) {
// event.data 包含了服务器推送的数据
console.log('Received message:', event.data);
};
// 当连接打开时触发
source.onopen = function(event) {
console.log('Connection opened');
};
// 当连接关闭或发生错误时触发
source.onerror = function(error) {
console.error('Error occurred:', error);
};
// 如果需要手动关闭连接
source.close();
在上述代码中，your_sse_endpoint_url应替换为你的服务器提供的SSE数据流地址。服务器端会以特定格式（如"data: some-data\n\n"）持续发送数据，客户端的onmessage事件处理器就会被触发，并处理这些数据。
注意：SSE要求服务器端支持并正确设置Content-Type为"text/event-stream"。
[查看全文]div如果有背景，滚动条部分会有一个白条，有办法让它透明吗
在CSS中，可以设置滚动条的样式以实现透明效果。以下是一个示例：
div::-webkit-scrollbar {
width: 10px; /* 定义滚动条宽度 */
}
div::-webkit-scrollbar-thumb {
background-color: rgba(0, 0, 0, 0.3); /* 这里设置滚动条滑块的颜色和透明度，你可以调整最后一个参数（这里是0.3）来改变透明度 */
border-radius: 5px; /* 可选，定义圆角 */
}
div::-webkit-scrollbar-track {
background-color: transparent; /* 这里设置滚动条轨道（也就是你说的白条部分）为透明 */
}
这段代码是针对Webkit内核浏览器（如Chrome、Safari）的滚动条样式的设置。对于Firefox等其他浏览器，可能需要使用不同的前缀或者更复杂的解决方案。
请注意，Internet Explorer浏览器不支持自定义滚动条样式，因此在IE上无法直接实现此效果。另外，对于非Webkit内核的现代浏览器，你可能需要查询并应用相应的CSS样式规则。
对了，两个冒号是什么意思
在CSS中，两个冒号 :: 用于表示伪元素选择器。与单个冒号 : 用于伪类（如:hover、:active等）不同，双冒号 :: 主要用来区分新的伪元素和旧的CSS1时代引入的伪元素。
例如：
::before和::after用于在元素内容的前后插入额外的内容（通常通过content属性定义）。::-webkit-scrollbar、::-webkit-scrollbar-thumb和::-webkit-scrollbar-track是Webkit内核浏览器特有的伪元素，用于自定义滚动条样式。
这种双冒号语法在CSS3中被推荐使用，以明确区分伪类和伪元素，尽管大多数现代浏览器对两者都支持单冒号形式。但在某些情况下，为了确保兼容性和明确性，建议使用双冒号 ::。
那我如果写的是行内样式，怎么办，不支持伪选择器
行内样式（即HTML元素的style属性）不支持伪元素选择器，因为它们只能设置单个元素的基本样式，而无法影响到元素内的伪元素或伪类。
对于滚动条样式的自定义，由于其需要用到伪元素选择器，所以无法通过行内样式实现。你必须在CSS文件或者HTML文档 *HTML标签不可使用噢* 标签中编写CSS规则来改变滚动条的样式。
如果你确实需要在行内样式中控制某个元素的滚动条样式，那么很遗憾，目前的标准和浏览器实现都不支持这样的做法。你只能将样式移到外部CSS文件或内部样式表（*HTML标签不可使用噢*标签）中进行定义。
关于喵宅苑的设计、文化、和未来
喵宅苑的诞生想法我在12月签到的前言部分已经简要介绍啦，今天来聊聊喵宅苑的视觉设计。
起初我的想法很简单，并没有刻意地去精心设计各种各样的元素，而是为了减少编程的工作量。以避免在视图设计上浪费大量的时间。于是，对所有的视觉对象都进行了抽象成为了我的当务之急。在经历了片刻的头脑风暴后，“盒子组件”诞生了。它们可以随时调用，以便于我将更多的精力倾注在代码逻辑的组织上。
虽然今天的喵宅苑和最初判若两人，丰富了些许设计，但是若仔细观察，初代喵宅苑特征依然显赫于目。各元素虽不尽相同，但也大同小异。毕竟派生自相同的组件嘛！
从代码设计的角的角度，高度抽象的组件可以高效的完成各种功能……
But, But, But
I think I'm a designer.
设计相关专业走出来的我，怎么可以容许喵宅苑只有程序员的设计哲学呢。
于是，在不破坏原有的“盒子组件”的基础上，我进行了些许优化。为了保留程序方向的设计哲学，我没有对喵宅苑进行大刀阔斧、天马行空的再创造。而是着眼于细节，对一些部分精心加工。
圆角
期初的圆角是定义在3px左右的；但是后来，...
紧急反馈通道（二期）（请回复本帖子）
请按格式回复，错误回复范例：
x 邀请码无效
x 想要找回密码
x 购买后没有邀请码
正确的回复格式：
机型：魅族pro5/华硕XXX/联想XXX
浏览器： 360安全浏览器/QQ浏览器/Chrome
时间： 2022年5月15日
起因：需要找回技术宅密码
经过：尝试使用找回密码功能，但是一直没有收到验证邮件，页面提示信息如下：XXXXXX，尝试过使用不同邮箱，以及在邮箱的垃圾箱查找邮件，依然无法收到邮件。
结果：希望寻求帮助，技术宅用户名xxx、绑定的邮件地址:XXXXX@xxx.com、联系QQ:1234567
关于注册和登录
喵空间反馈问题需要快速注册一个喵空间账号。
戳开导航栏的用户栏目，输入账号密码即可注册。
注册完后需要再点一次按钮，进行登录。
输入用户名和密码，按照提示即可快速注册(请使用英文用户名)，注意喵空间账号与技术宅社区账号不互通，创建的是独立的、便于快速反馈的新账号。
反馈相关格式
登录后在此处回所遇到的问题，请按照事件的三要素：
起因→经过→结果
必要时候提供：
时间→地点→角色
接着请 评估 管理员的可能的需求，提供必要的信息：
- 用户名
- 所绑定的QQ
- 所绑定的邮箱
- 帖子的URL
如果有遇到不同平台的特殊情况，还请提供所在的平台代号：
- 安卓系统
- ios系统
- Windows系统
- Linux系统
- MAC系统
通常不需要精确到版本号，及其特殊的情况除外。
若在不同浏览器环境中有不同的问题的话，还请提供下浏览器名称，甚至于版本号（如果你认为必要）
[查看全文]
懒人用户组说明
购买后即可获得存档网络5000宅币兑换券。（参考本文文末使用说明）
用户组可以升级至序章（解锁所有权限）
邀请码获取 重要♂说明
因为近期发现注册了大量的僵尸账号（也就是注册后就丢在那里再也没有登录过的账号），导致数据库占据了大量的无意义的用户数据，以及拦截恶意广告的客观需要，同时也为了过滤一部分和技术宅价值观完全不符的圈外朋友，所以我们不得重新开启了邀请注册机制，必须花费3元购买邀请码才可以继续注册。
旧用户の相关说明
如果你以前开通过【懒人】，或者是已经注册过账户无法登录，请前往以下链接反馈：
https://www.o-o.space/lite#!/home/148
Duang，这里是第一步、【邀请码】获取流程，请仔细查看
- 戳开导航栏的用户图标
- 输入用户名和密码，注册一个保存邀请码的喵空间账户（首次使用即为注册）
【！注意！】跳转出去后会如何返回本页？
点击导航栏最左边的胖胖的小箭头，可以返回上一页
因为流程比较反锁，你可以随时使用这个功能返回本页面哦。
登录账户
前往【地带】中的【商店】，【购买】物品【技术宅社区邀请码】——参考附件截图
如果积分不足，根据提示充值即可，邀请码需要66玉韘积分
>> 点击前往商店购买邀请码前往【地带】中的【物品】，【使用】刚才购买的物品——参考附件截图
前往【个人中心】=>【点卡】，即可看到获取到邀请码——参考附件截图
返回继续注册，点击链接快速返回：（特别提示：技术宅需要用中文用户名注册）
>> 点击填写邀请码，继续注册
【注意，这一步跳转出去可能就回不来了，所以请先看完下面的部分。】
参考截图
- 如何前往地带和商店
- 如何购买邀请码
- 如何查看已经购买的邀请码
最后亿步
成功注册后，技术宅的新手任务也将在喵宅苑完成，为了避免不必要的跳转，你不用关闭本页面，
前往【地带】=>【委托中心】，根据任务提示完成【新宅导航】系列任务（这个任务很快可以做完）
完成任务后，你可以获取到1000积分兑换券，成功激活兑换券后，你可以在【存档网络】获取资源和进行日常交流。
兑换券如何使用在委托中心的每一步已经给出了详细说明，这里就不再赘述。
我好懒啊，可以跳过任务和阅读上面繁琐的步骤吗？
当然可以，如果你仔细权衡了耗费时间和耗费金钱所带来的收益的不同价值，其实做任务还是挺快的啦。同时也为了赞助技术宅，那么在【商店】中你还可以选择购买直接升级【序章】用户组所需的5000宅币兑换券
限时10元（原66.6）。
【注意】如果你希望购买用户组跳过任务流程，你仍需耗费3元购买邀请码，所以你会购买2个物品【邀请码】和【用户组】
购买图示：
使用图示：
购买后的点卡使用说明参考图：
社区账号丢失补偿登记册（有效期：截止2022年5月7日）
上次有公告过账号丢失的补偿相关事宜，请在本帖内登记，以便提供补偿。
通过QQ群注册的用户，且没有【喵宅苑账号】，请前往登录处注册一个，同时在登录后绑定邮箱
就是通过【喵宅苑账号】注册【主站账号】的用户请直接用当初注册的账号回复
本次补偿包含20000宅币，将以积分兑换券形式在回复内发放
第一步：回复本帖，发帖后将权限设置为（仅上级楼主可见），提供以下内容：
注册渠道：喵空间或QQ群（其它渠道注册的用户不在本次补偿范围内）
当初获取到的邀请码：
喵空间注册用户，请前往https://www.o-o.space/#!/invite 查看
QQ群注册用户，此处改为填写QQ号
4.备注：原主站的用户名，可不填写
第二步：新注册一个主站账号，用于【领取和使用积分兑换券】
前往主站 设置=>>积分=>>充值=>>充值卡充值
别发帖完就忘记了哈，记得回来查看cdkey
[查看全文]我之前在技术宅社区的账号没有了，是被注销了吗？一直登陆不上，试了一下注册，发现之前的用户名可以注册
[查看全文]