精子最近在 第一届烧火节 中体验了钻木取火,并制作了第一个 Vlog。

加湿器选购指南

我从小一直生活在湿度很低的北方,常年鼻子和咽喉不舒服,经常流鼻血,但因为从小如此,也没觉得有什么不对劲。而来到苏州之后,我就觉得苏州湿润的空气真是好呀,鼻炎和咽炎的症状几乎没有了。但等到冬天开空调的时候就觉得无法再回到那么干燥的环境了,于是开始疯狂地买加湿器,这么多年下来,应该买过差不多十个加湿器了。

加湿原理

超声波 加湿器使用超声波将水打散成为非常小的小液滴,然后用风扇吹出,小水珠通常会在落地之前蒸发为水蒸汽,溶解至空气中。超声波加湿器是使用最普遍、价格最低、同价位加湿量最大的加湿器类型。其主要缺点是超声波会将水中的固体颗粒物和溶解物一起吹出,且容易有颗粒较大的液滴未能在落地之前完全溶解到空气中。虽说超声波加湿器被认为并没有耗材,但实际上其核心组件雾化片的寿命只有两年左右,且难以更换。

冷蒸发 加湿器使用风扇将空气吹过吸水的多孔材料,加速水的蒸发。冷蒸发是近一段时间中被高端的加湿器所采用的技术,不会有固体颗粒物进入空气,加湿量随湿度变化有一定自我调节的能力。其主要缺点是单位价格加湿量较低(且加湿量和噪音成正比),用于吸水的多孔材料作为耗材需要定时更换。

热蒸发 加湿器简单地通过加热水来产生水蒸汽。热蒸发加湿量较大(和功率成正比),同样没有固体颗粒物进入空气。其主要缺点是耗电较多,会增加室内温度(冬天倒是不要紧),且高温蒸汽遇到低温物体会产生水珠凝结。

类型 价格 水珠凝结 耗电 耗材和使用寿命 固体颗粒物 加湿量(同价位)
超声波 无耗材 寿命短
冷蒸发 有耗材
热蒸发 中等 无耗材 中等

在加湿原理上面我觉得很难一概而论,需要具体情况具体分析。但如果你不知道怎么选的话,可以先买个性价比最高的超声波加湿器试试看。

湿度

我们通常说的湿度其实是指相对湿度,即相对于当前空气中能溶解水蒸汽的最大量来说的湿度。人在不同的温度下对于同一相对湿度的感受是完全不同的,在 28 度下 40% 的相对湿度会比较舒适,而在 22 度下则需要 60% 的相对湿度才能达到相同的感受。

于是我找到了一个单一指标来衡量体感湿度 —— 露点,露点描述的是在当前温度和相对湿度的条件下,空气中的水蒸汽遇到多冷的物体时会凝结成小水珠,综合了温度、相对湿度和大气压力的影响。

对于我而言我觉得理想的露点是在 13 度左右,也就是我前面说的 28 度下 40%、22 度下 60%。如果你不像我这么喜欢湿润的空气,可以调低一点,例如 10 度左右。

加湿量

首先我们根据房间容积(这里以我家客厅 90 立方米计算)、目标温度和目标湿度来计算所需要的加湿量。我这里的计算并没有扣除家具所占用的空间,主要是考虑到家具本身(尤其是织物)也是会吸水的,所以综合考量下来不加也不减。

先计算不开空调和加湿器时的基准值,按室外温度 10 度,相对湿度 60% 计算,查表可得每立方米有 5.63g 的水蒸汽,总共就是 90m^2 * 5.63g = 506.7g,相当于我们房间里本来就有这么多水。

然后按照目标温度 24 度,目标露点 13 度,算出目标相对湿度是 50%,查表可得每立方米有 10.85g 的水蒸汽,总共就是 90m^2 * 10.85g = 976.5g,相当于我们的目标是房间里有这么多水。

这意味着我们需要补充差不多 500g 的水到空气中,但需要注意的是房间并不是密闭的,房间里的空气一直在和外界进行着交换,水蒸汽会流失到外界,也会在低温物体(如玻璃)上凝结为小水珠。以我个人的经验,如果你需要补充 500g 的水到空气中的话,那差不多你就需要一个加湿量 500ml/h 的加湿器 —— 相当于每小时房间里的水分都会流失掉一遍。如果加湿器的加湿量不够的话,就会出现即使一直开到最大,湿度也升不上去的情况。

500ml/h 已经算是加湿量比较大量的加湿器了,你需要考虑是使用多个加湿器还是单个加湿器。多个加湿器的话维护成本会比较高,你需要单独为每个加湿器加水、进行清洗和维护;单个加湿器的话则要考虑如何增加空气的对流,让整个房间保持相对均匀的湿度,例如冬天开空调的话,可以把加湿器放在空调可以直接吹到的地方。

功能

在购买加湿器的时候需要留意这些功能:

  • 上加水 极大地提升了加水的便利性,直接关系到使用体验。
  • 水箱 注意确认容量是否足够、水箱的形状是否容易清洗。
  • 通电自动启动 有些加湿器在接通电源后还需要触摸按键才能启动,这样便无法与智能插座配合使用。
  • 出雾高度和方向 出雾方向是否可调,这会影响加湿器放置的灵活性。
  • 紫外线除菌 见后面「固体颗粒物」小节。

可有可无的功能:

  • 红外线遥控 可以和智能家居组件配合使用。
  • 指示灯 如果是放在卧室的话,需要确认指示灯的亮度以及是否可以关闭,否则可能关灯后会显得太亮。
  • 智能控制 大多需要专门的应用,难以和既有的智能家居一同工作,不如用智能插座或红外遥控来解决。
  • 恒湿 位于机器本体上的湿度传感器非常不准确,效果有限(尤其对于超声波加湿器)。

不太需要关注的功能:

  • 静音 大多数超声波加湿器都没多大差别。
  • 缺水保护 所有加湿器都有的功能。

没什么用的功能:

  • 银离子 效果要比紫外线差很多,而且需要耗材。
  • 净水滤芯 本来加的都是干净的水,没有必要过滤,而且需要耗材。
  • 负离子 并没有可靠的资料表明这个功能有什么作用。

关于大雾量加湿器:

单个超声波雾化片可以提供 300ml/h - 400ml/h 的加湿量,再大的加湿量就需要考虑多个雾化片的加湿器了。

固体颗粒物

超声波加湿器会将水打成小液滴,这会导致家用的固体颗粒物传感器瞬间爆表,但实际上家用的传感器是无法区分小液滴和真正的固体颗粒物的,因此这个传感器的数值并不能说明有多少固体颗粒物进入到了空气中。

但我们仍有必要考虑微生物在加湿器内滋生并随着小液滴进入空气的情况,市场上目前有紫外线和银离子两种方案来解决这一问题。

经过我的调查,紫外线的除菌效果要远优于银离子,且不需要耗材:

  • 紫外线被标注为「除菌」,而银离子被标注为「抑菌」
  • 网络上一些细菌培养实验显示紫外线的除菌效果更好
  • 高端的加湿器通常采用紫外线除菌

下一个问题就是加湿器中到底应该加什么水呢?

一派观点认为自来水中的余氯有助于减少加湿器中的细菌;另一派观点认为有条件加纯水当然应该加纯水,可以减少被超声波打入空气中的溶解物数量(尤其一些地区自来水的 TDS 非常高),也可以延长超声波雾化片、冷蒸发的多孔材料、热蒸发的电热管的使用寿命。

所以综合考虑,建议大家选择有紫外线除菌功能的加湿器,然后向加湿器中添加净水器产生的纯水来避免自来水中的溶解物进入空气。

参考资料

2019 年度小结(技术方面)

Redis 的工程价值

今年一开始先是完善了去年的 任务队列,为了让它真正地被用起来,我将之前由另外一个服务实现的定时任务系统也合并进了这个任务队列,让它有了一些固定的流量,以便我来发现性能上的问题,进一步完善它。

这项工作最后取得了还不错的效果,开始有了用户使用任务队列的功能。我也写了一篇文章来介绍 用 Redis 来实现定时任务,当然这篇文章中介绍的是一种经过极度简化的范式,实际上实际的代码要复杂的多,例如序列化、错误处理、结果查询、限流、统计等额外的特性。

这个项目让我再度增加了对 Redis 的好感,这次我用到了比较大量的 Lua Script 来保证分布式架构下的一致性(Redis 的Lua Script 会被独占地执行)。在将一致性需求限制到单个 Redis 实例可以容纳的范围(Redis 只使用一个线程)并且 Redis 运行相对稳定的情况(故障切换会丢失数据),Redis 为业务层提供了一个非常「够用」的高性能的、有一致性保证的数据同步方案。这并不是说 Redis 提供的方案有多么完美,而是在性能、功能、一致性、可靠性上提供了一个非常好的这种,更具有工程价值。

Golang 的表达能力

我还尝试了为 LeanCloud 写一个 Golang 的 SDK(后来因时间安排的关系暂停掉了,目前还未发布),就像之前我为 DeployBeta 写 ORM 一样,同样遇到了 Golang表达能力不足的问题。问题主要在于 Golang 中并没有能让 Struct 继承方法的机制(数据字段则可以通过内嵌匿名 Struct 的方式来继承)。

所以当用户定义一个「继承」自 ORM 基类的 Struct 时,我们无法向用户定义的 Struct 上添加例如 Save、Set 之类的方法,无法有效地追踪用户对于数据对象的改动。

经过几个版本的改动,我最后选择了一种将所有基本类型(string、int)包装为 Struct 的方案:

type Todo struct {
  orm.ObjectMeta

  Name     orm.String `orm:"name"`
  Priority orm.Number `orm:"priority"`
}

todo := Todo{
  Name:     orm.NewString("test"),
  Priority: orm.NewNumber(1),
}

err = orm.Save(&todo)

todo.Name.Set("test")
todo.Priority.Incr(1)

err = orm.Save(&todo)

fmt.Println(todo.Name.Get(), todo.Priority.Get())

这个方案可以做到不以字符串的形式传递字段名(可以得到编译期的类型检查),可以追踪对每个字段进行的修改(包括 Incr 等运算)。我将 Set 添加到了基本类型的封装类型上,将 Save 作为了一个全局方法,避开了 Golang 对于继承的限制。带来的问题则是用户需要通过我们的封装方法(Get)来访问字段的值;同时今后设计嵌套对象时也需要更大的工作量。

所以并不是如 Golang 的支持者说的那样,更少的特性意味着更简单的设计。当业务逻辑确实复杂,语言表达能力又非常匮乏的情况下,会逼着开发者做出一些不优雅的、不易理解的、反常规的设计,这些代码往往非常容易出错(例如反射、代码生成、强制类型转换等),而本来这些需求(如继承)在其他语言里是可以非常轻易地解决的。

TypeScript 的胜利

之前因为对 CoffeeScript 的喜爱,我的 TypeScript 使用经验非常少,终于今年我也不得不去接受 TypeScript 了。今年我用 TypeScript 开发了两个新的后端项目,也更深入地学习了 TypeScript,经过进一步的了解,我逐渐地发现了 TypeScript 的闪光点,之后我会单独写一篇文章来介绍 TypeScript。

TypeScript 有着一个先进的类型系统,这种先进并非是学术意义上的先进,而是工程意义上的先进。它几乎可以为所有 JavaScript 中常见的范式添加静态约束,得益于强大的类型推导,在大部分情况下并不需要自己添加类型标注,但却能在编译期提前发现错误、配合 Language Server 得到准确的代码补全和类型提示信息,完全没有前面提到的 Golang 中的那种束缚感。

因为 TypeScript 并不打算创造新的范式,而是尽可能将 JavaScript 社区中已有的范式用静态类型的语义描述起来。这样最大程度上地降低了 JavaScript 开发者学习的成本,提高了与标准 JavaScript 代码的互操作性,我认为这也是 TypeScript 能够取得成功的关键。

同时我也不得不接受 Atom 的市场已经几乎完全被 VS Code 取代的现实,切换到了对 TypeScript 支持更好的 VS Code。现在想想 Atom 失败的原因一方面是在 CoffeeScript 已经表现出没落的时候选择了 CoffeeScript;另一方面是希望依靠社区的力量,但又缺乏对社区的引导。例如对于插件的 GUI 改动引导不够导致界面卡顿,对于代码补全、调试等常见需求没能建立统一的标准等等。

Kubernetes 的阴谋

今年其中一个新项目是开发一个数据库调度平台,在 Kubernetes 上运行数据库容器,这和我之前在 DeployBeta 实现的原型非常相似,只不过这次是真的要上线的项目。

在去年和今年对 Kubernetes 的了解过程中我逐渐对 Kubernetes 由粉转黑。我现在认为 Kubernetes 是以 Google 为首的三大云计算巨头的垄断工具,他们开发出了一个如此复杂的系统,并引导其作为行业标准。虽然 Kubernetes 是开源并由社区维护的,但真正能够独立搭建好 Kubernetes 及其插件的公司是极少数,甚至可以说除了三大巨头之外,其他的云计算公司都不能提供稳定可靠的 Kubernetes 集群。最后大家在尝试过自己搭建之后,还是不得不购买三大巨头的 Kubernetes 云,毕竟这是行业标准嘛。

今年看过觉得最好的书是「数据密集型应用系统设计(DDIA)」,它给我的数据库调度平台带来了很多启发。书中介绍了分布式架构对于数据库的挑战,包括数据模型、复制、分区、事务、分布式共识等等,以及各个数据库在面对这些挑战时采取的解决方案,只有理清这些思路,才能在面对复杂的业务的时候采用一种或几种合适的数据库。

我的理解是当数据存在于两台或更多的计算机之上时(原因可能是容量或可用性要求),就可以称作「大数据」了。因为从一台到两台是一个质的变化,而从两台到更多只不过是量的变化。就如书中所说,在单机条件下,所有的称作都是确定的,一个操作要么成功要么失败(可能伴随着程序或系统的崩溃);但在分布式条件下,对于经过网络的操作会引入成功和失败之外的第三种情况 —— 网络延迟,你无法预测一个操作会在下一秒完成还是永远都不会完成。所以分布式系统需要被设计成可以在容忍一定的错误(部分失效)的情况下继续运行。无论是一个分布式数据库还是一个分布式的容器平台,其实都在与这种不确定性的超时进行对抗。

写不下去的业余项目

现在我愈发认识到软件开发不是一个人的单打独斗,之前在做一些业余项目的时候还会有一些幻想,幻想自己能长期维护下去、能吸引到其他的贡献者、能建立起一个社区。但现在想想还是以内容作为主要的输出更有可行性。同时因为我对现在的工作非常满意,在工作中基本完全满足了我对于写代码和团队协作的欲望,所以我可以将业余时间放在其他的输出形式上,在接下来一年中输出更多的文章或视频,这样我的经验和知识会给读者带来更大的价值。

2019 年度小结

转眼又一年过去了,今年我将更多的时间放在了除了编程之外其他的业余爱好上面,例如太空探索、开车、乐高、视频拍摄和剪辑、无人机、游戏、记账等等。

在今年年初和蛋黄一起去 体验了一次游轮 —— 一种不需要做计划、自助吃喝、走几步路就可以回到室内、再多走几步就能回到房间的「佛系旅行项目」,不喜欢出门的蛋黄对此表示非常满意。

在 2018 年末我和蛋黄一起报名了驾校,在 6 月拿到驾照的当天,我们就租了一辆共享汽车上路了,然后第二天就开去了上海,第三天就出了一次不大不小的事故 —— 蛋黄开着车误上了上海的高速路,在下闸道时减速不及撞到了护栏。

2019/2019-accident.png

在驾驶生涯的初期遇到这样一个不大不小的事故其实也算是一种幸运,可以让我们更直接地认识到驾驶本身的危险性、提高安全意识,避免之后更严重的事故。

在之后的半年里我们也经常开着共享汽车出去玩,加起来可能开了两、三千公里的样子,不过大多还是短途,最远也就是苏州和上海。目前我的驾驶经验绝大部分是在电动汽车上,想想我可能算是第一代直接接触电动车的驾驶者了。我们今年还去了南京、大连和沈阳,我们都分别在目的地租了车,以一种不同于以往的方式在其他城市旅行。

确实掌握了开车这项技能之后就像打开了新世界大门,占据了城市大量面积的公共道路其实是为汽车而设计的,坐在驾驶位去看到道路的设计、道路上的标识标线,有一种完全不同的感受。也认识到了汽车确实是最伟大的发明之一,极大地拓展了人类的活动空间、活动的自由性。

2019/2019-driving.png

今年比之前投入了更多的时间在游戏上面,首先是年初突然发现我曾在 Steam 中买过一个叫坎巴拉太空计划的游戏,恰逢当时对 太空探索 重拾兴趣,于是便一发不可收拾,目前已成为我 Steam 上游戏时间第二的游戏。

2019/2019-kerbal.jpg

在 2017 年我曾从朋友那里借过一台 Switch,但因为他并非任天堂粉丝,机器里也仅有一款任天堂的游戏,所以当时并没有对 Switch 产生兴趣。今年我开始在一些游戏相关的自媒体了解到业界对于任天堂极高的评价,于是在 8 月时入手了一台 Switch,接触到了 赛尔达传说:旷野之息、马里欧:奥德赛、喷射战士 2、健身环大冒险这样的任天堂第一方游戏,这些游戏的设计和制作水平让我完全成为了任天堂的粉丝,不由得有一种过去十几年的游戏都白玩了的感觉。

在今年一月时我决定用复式记账的方式记一年的帐,来和 2016 年的年度支出分析 做一个比较。复式记账用账户之间款项的转移代替了单纯的支出流水帐,可以更好地体现投资、货币兑换,也可以更好地进行回溯和纠错。

但因为现在我和蛋黄的支出都是混在一起的,所以需要连着她的帐目一起记,否则这个账就没什么意义了。因此每次记账我都需要去翻她的交易记录,确认一些款项,导致记账这件事情经常拖延很久,到现在也只把帐目清理到了今年 7 月。后面我会尽力把这一整年的帐目整理完,来写一篇日志,但之后可能就不会再这样记完整的账目了,可能会考虑退回之前每个月记录一次个账户快照的方式。

2019/2019-accounting.png

在今年中,偶尔几次会有一种通过视频来记录和展示生活中有趣的瞬间的冲动。我用去年买的小蚁微单和今年买的无人机拍摄了不少素材,也录制了一些游戏实况,做了一些尝试,但实际的产出的视频很少。

和文字内容不同,视频的拍摄是不能轻易重来的,需要后期将素材剪辑成作品。而且和之前我录制的播客相比,视频的素材要更加非线性,剪播客更多的是将「不想要的部分剪掉」,而剪视频则是「将想要的部分挑出来」,后者的难度要高出不少。

同时视频的制作对设备的要求也更高,不过我想着还是不要一下子买太多设备,不如每产出几个视频就升级一样设备,这样可能会让我的视频播主之路变得更有趣,有一种逐渐升级的感觉。

2019/2019-pidan-doufu.png

皮蛋豆腐还是一如既往。

12380

精子生于 1995 年,英文 ID jysperm.

订阅推送

通过邮件订阅精子的博客日志、产品和项目的最新动态,精子承诺每一封邮件都会认真撰写(历史邮件),有想和精子说的话也可以直接回复邮件。

该博客使用基于  Hexo  的  simpleblock  主题。博客内容使用  CC BY-NC-ND  授权发布。最后生成于 2020-03-18.