• IEEE-754浮点数那些坑:0.1加0.2不等于0.3!

    浮点数是计算机程序中最基本的数据类型,几乎所有编程语言都有浮点类型。但你或许不知道,浮点数可能有精度不足的问题,使用不当会酿成大祸。以 JS 为例,我们来看一个例子:

    1
    
    0.1 + 0.2 === 0.3 // false
    

    0.1 加上 0.2 居然不等于 0.3 ,那结果等于多少呢?

    1
    
    0.1 + 0.2 // 0.30000000000000004
    

    结果等于一个非常接近 0.3 的值,但不等于 0.3 !真是令人瞠目结舌!这是为什么呢?

    想要回答这个问题,我们得知道浮点数在计算机内部是怎么表示的。IEEE 754 是目前使用最广泛的浮点数表示和运算标准,从中即可找到问题的答案。不过想要学习它之前,我们得先掌握 科学记数法scientific notation )。

    阅读全文
  • 面向错误编程

    背景

    公司有一个应急系统,管理各种类型的应急策略,前端代码质量一言难尽。最近有新需求,领导要求梳理主机异常应急策略,为此我们给系统添加一种新的策略类型——主机异常应急策略。

    后端加上新类型后,您猜咋滴?前端好几个页面白屏了!只要数据里有新类型的策略就会!

    我看了看代码,您猜咋滴?问题出在策略类型标签上:类型字段后端为英文常量,前端将其展示成一个中文标签。由于类型有好几种,前端用一个字典来映射渲染函数,代码大致如下:

    1
    2
    3
    4
    5
    6
    7
    
    const strategyTypes = {
      Link: () => <Tag color="magenta">链接</Tag>,
      CheckList: () => <Tag color="orange">确认表</Tag>,
      Card: () => <Tag color="green">应急卡片</Tag>,
      Routine: () => <Tag color="cyan">常规应急操作</Tag>,
      Host: () => <Tag color="red">主机异常策略</Tag>,
    };
    
    阅读全文
  • 用Go语言模板引擎提取数据

    最近在开发一个通用消息通知工具,可以从 API 、数据库等数据源获取数据,然后根据数据渲染消息模板,然后通过企微、邮件、短信、电话语音等渠道推送消息。整个工作的设计思想,就是想提供一种低代码、配置化的消息通知解决方案。

    简言之,工具对日常消息通知开发场景进行抽象建模,让所有要素都支持配置:

    • 数据源
    • 消息模板
    • 通知渠道
    • 通知对象
    • 发送策略(手动触发或定时任务)

    那在开发的过程中,就不可避免要面对数据提取问题。比如,有个系统提需求说他们的变更单需要每天催一次,列表通过 API 给我,结构如下:

    1
    2
    3
    4
    5
    6
    7
    
    {
        "success": true,
        "data": [
          {"name": "变更①"},
          {"name": "变更②"}
        ]
    }
    
    阅读全文
  • 写于辛丑腊月廿九除夕日

    上周末收到公众号平台提醒,说小菜获得定制红包封面的机会。

    时间飞逝,又一年除夕佳节到了,在这先给各位老铁拜个年。

    还记得去年我特地看了能否自己定制红包封面,但没资格;所以收到通知时竟有一点小激动。

    微信应该是想鼓励原创,原来这一年小菜学编程上发表了 95 篇原创文章!我一直比较随意,有空就写没空就停,写写停停,但只要坚持还算有些收获。

    阅读全文
  • 谈谈我对Promise和异步函数的理解

    后端同学组织了技术分享,交流《Unix环境高级编程》读书心得,前端同学怎能落下?

    实际上,前端圈的分享会稍早前就开始组织了,只不过我没空将其中的点滴一一记录。

    作为项目的技术负责人,前端本不是我的主业。目前,前端团队无论从代码质量还是技术水平,都不太令人满意。我每周合并代码时,有时会瞟一眼,有些同学的代码真的堪忧。

    目前,前端团队都是初级工程师,功底较差,做出来的东西只是能用而已。他们既不会总结经验,形成最佳实践;做事又随便,总是机械地应付任务。我苦口婆心地劝他们要多看看书,思考代码要怎么写更好,但收效甚微。

    既然规劝没用,我就强制他们学习!我定的第一个课题是 TypeScript ,因为他们的代码质量很差,希望引入 TypeScript 后提升代码健壮性。前后端分享频率都是每周一次,但我有点忙不过来,后续改成双周一次。

    组织过好几次 TypeScript 学习后,有同学提议分享自己感兴趣的研究课题,我没反对。最近李同学在研究 Promise ,因此 Promise 便成了本周的分享主题。

    我是后端出身,虽然前端项目也是我在主导,但知识盲区还有很多。Promise 之前就一直没用对,真是贻笑大方。正好趁着这次机会,好好梳理下 Promise 的来龙去脉,故有此篇。

    阅读全文
  • 想不到写个cat命令都有这么多门道!

    《Unix环境高级编程》第一次读书分享会由廖同学主持,主要讲解 文件操作Unix/Linux 提供了这几个系统调用来操作文件:

    • open ,操作前先打开文件,获得一个 文件描述符file descriptor );
    • read ,从文件指定位置读取数据(传打开文件的描述符);
    • write ,将数据写到文件指定位置(传文件描述符);
    • lseek ,更新文件当前偏移量,偏移量决定 readwrite 读写位置;
    • close ,操作完毕后关闭文件,回收系统资源,并释放文件描述符;

    Unix/Linux 文件操作很简单,无非是打开、关闭、读写和指针移动( lseek ),对吧?尽管如此,简单的东西还是有很多需要考究的地方。

    为了提高学习效果,增强每位同学的参与感,我特地安排了课前作业。既然是学习文件操作,那就模仿着开发一个 cat 命令呗。

    cat 是一个非常简单的 Unix/Linux 命令,用于读取文件数据,并输出到标准输出。但就这么简单的一个作业,初学者还是很难写好。

    那么,实现 cat 命令背后都有哪些门道呢?简单的表象下,又暗藏哪些玄机呢?

    阅读全文
  • 带着新人刷《Unix环境高级编程》

    背景

    团队内来了不少年轻人,水平参差不齐,有些干了好几个年头还不知道什么是 进程间通信IPC )。

    当时在讨论一个后台服务的设计,它内部由若干协程组成,协程间需要传递一些数据,他想用 Redis 来做队列……我表示不解,在同一个程序内的通信,为什么要通过一个外部的 Redis 来进行呢?

    我很好奇,问他:你没学过 进程间通信IPC )吗?同一台主机下的进程进行通信,当然是首选操作系统提供的进程间通信机制,除非应用进程可能跨机器协作。但他一脸懵逼,表示没听过进程间通信……

    我当时有点震惊,一个干了好几年的后端,居然没听过进程间通信!这不是校招必考题吗?

    想当年没读《Unix环境高级编程》都不好意思去面试,而进程间通信就是其中一个主题。但他们可能起点较低,没认真学好这些基础课,也没经历过大厂面试的洗礼,因而功底比较薄弱。

    阅读全文
  • 给团队内的年轻人灌了一大碗鸡汤

    团队来了不少年轻人,水平却参差不齐,有些干了好几个年头还不知道什么是 进程间通信IPC )。

    最近突发奇想,准备搞一搞技术分享,带他们阅读一些经典的技术书。《Unix环境高级编程》是后端必读书目,我问了一圈竟无一人读过,因而被我选中。学习模式大致是这样的:大家轮流学习某个知识点,然后讲给其他人听,每周一次。

    第一次我原本准备亲自讲,给他们吹吹水,灌灌鸡汤。无奈这周身体抱恙,有点小感冒讲话不方便,遂写成文字分享给他们,乃有此篇。

    技术视野

    有本叫《性能之巅》的技术书很出名,作者在前言中引用美国国防部长拉姆斯菲尔德说的一句话,很有意思。他说世界上的事物可以分为三种:

    • A 已知的已知 ,比如我会 Go 语言;
    • B 已知的未知 ,比如我知道有一门语言 Rust 最近很火,但我不会;
    • C 未知的未知 ,……
    阅读全文
  • 数据库索引技术之B树索引

    前面我们介绍了 哈希索引LSM树索引 ,它们都基于日志结构式的数据文件。虽然工程界对这种索引的认可度正与日俱增,但还远不是最受欢迎的索引技术。

    那么,目前应用最广的索引技术又是什么呢?

    您可能早就有所耳闻——这就是本文要探讨的 B树b-tree )索引。B树可以说是数据库索引技术中的武林盟主,能够几十年长盛不衰,必定有它自己的独门秘诀。

    索引结构

    跟我们在 LSM树 一节中提到的 SSTable 一样,B树也是将数据组织成有序形式,因此支持范围查询。尽管如此,它们的底层结构却完全不同,B树有自己独特的设计哲学。

    阅读全文
  • 数据库索引技术之LSM树

    上次我们分享了采用哈希索引实现的存储引擎,它总是将写操作不断追加到数据文件,就跟写日志一样。这种日志结构式的存储引擎,数据记录顺序由写入时间决定,同一键的旧记录由新记录取代。

    SSTable

    由于数据在写入时,自动切分成一个个文件。数据库需要在后台对文件进行合并,以减少文件数,进而加快查询。如果待合并文件里的数据是有序的,我们就可以采用归并排序算法来提高合并效率。

    虽然这看起来会违背顺序写的原则,但也有办法解决,我们稍后介绍。

    现在,我们将数据文件格式改成这样:①文件中的所有记录,按照 key )来排序;②排序保证了每个键只在文件中出现一次,不会有重复的旧记录。姑且将这种格式叫做 排序字符串表sorted string table )简称 SSTable

    阅读全文