知鸦日报2022-09-07

2021年底，一家产品正式上线仅6年、团队规模200人不到的 SaaS 工具公司，凭借其出色的产品力、上千万的全球用户数融资2.5亿美金，达到投后估值103亿美金，它就是 Notion。

那么，Notion 究竟是什么产品？为什么其增长能如此迅猛？其增长趋势是否又能得到长期保持？本篇文章将围绕这3个问题，对 Notion 的产品及增长策略进行详细地分析，并在最终给出其增长是否可持续的答案。

可视化大屏设计中，如何根据需求制定设计方案？

知识付费是内容赛道的一块高地，有着上百亿的市场规模。而作为设计师，如何通过结构性思维助力产品获得用户洞察和业务策略思考，希望通过这篇文章给大家一些参考。

来自作者：its.dezinx 的分享，涉及到按钮、对话框、列表、搜索等常用组件的设计规范，间距、尺寸、字号等信息。

本文将基于典型案例，系统分析、分享 iOS 发热降频的基本概念与处理经验，希望能够解决大家对 iOS 发热降频的疑惑，帮助大家遇到类似问题时知道如何分析问题、发现证据、解决问题。

只编写一份proto定义，就可以自动生成client，自动生成API文档，自动做版本管理的方式你造吗？

来也科技是一家业务涉及ToB和ToC领域的智能自动化公司，ToB业务是我们的战略重点，企业服务的本质在于了解客户的真实业务诉求，并为其提供优质的产品与服务，帮助其走出复杂商业环境中的发展困境。BI为了解用户、优化产品提供了参考。

来也科技的产品除了提供在线SaaS服务外还支持客户本地化部署，所以我们BI系统的技术选型也会考虑两种情况，本文对这部分内容亦有所涉及。

来也科技自主研发的代码片段插件，可让这个团队共享代码。

去哪儿旅行 UI 自动化系统 TARS 于 2020 年 3 月启动，到 2020 年底达成一期预计目标。覆盖公共、机票、酒店等多个部门接入，月版发版30多次，回归执行自动化上百次，200多个项目发布执行 400 多次，发版无 P1、P2 故障，节省人力近千 pd 。

In our first post we discussed the need for a near real time Safe Deploy system and some of the statistics that power its decisions. In this post we will cover the architecture and engineering choices behind the various components that Safe Deploys comprises.

Designing a near real-time experimentation system required making explicit tradeoffs among speed, precision, cost, and resiliency. An early decision was to limit near real-time results to only the first 24 hours of an experiment — enough time to catch any major issues and transition to using comprehensive results from the batch pipeline. The idea being once batch results were available, experimenters would no longer need real time results. The following sections describe the additional design decisions in each component of the Safe Deploys system.

作为一种展示结构化数据的常用手段，表格随处可见。比如：信息收集、商品明细、企业年报等。

随着无纸化办公的流行，企业或个人经常需要将纸质报表上的信息按图片中表格的样式原样生成xls文件，再转录到各自系统中去。

即便可以用OCR（Optical Character Recognition，光学字符识别）技术辅助提取纸张上面的文字，但若要提取表格结构，就需要人工创建表单再将文本一个个复制到单元格中，这可是不小的工作量。

表格识别应运而生。

表格识别的任务是：识别图片中的表格结构，如表格的行数、列数、每个单元格的位置、所在行列及跨行跨列等信息，再辅以OCR的识别结果，还原表格的内容。

作为超级自动化的代表公司，来也科技推进的许多自动化解决方案中，需要OCR（光学文字识别）的能力，经过持续的积累和创新，目前来也自研的通用OCR识别在60多个复杂的中文测试集合上近70万的字符上，综合F1指标已经接近97%，远超国内大多数竞品公司。

虽然综合指标上已经取得非常好的成绩，但是因为视觉深度学习OCR模型的天生缺陷，在一些长尾问题上依然识别准确率不高，典型的有以下场景：

1. 污渍干扰如红章、墨迹
2. 形似字 如 “戍”与“戌、成、戊”
3. 图像变形引起的字体变形

智能文档处理（IDP）可帮助企业实现日常文档处理工作的自动化，在文档识别、分类、信息抽取和比对等各个方面，为企业工作人员提供帮助。印章识别是智能文档处理中一种重要的识别能力，广泛应用在合同比对，出入库审核以及发票报销等场景。以往这些工作环节中需要人工对印章图像进行核对校验，流程繁冗，而使用OCR技术进行印章自动识别则可为企业有效节省用工成本。

DDD里提到的Event指的是对系统状态产生改变的现实事件，同样我们在Event Sourcing的系统中存储的也是会导致系统状态改变的事件。似乎这两种不同的软件开发思想，对Event的认识有着不谋而合的默契。

MySQL等值查询，可能并不是你想的那么简单，还跟校对规则有对，具体细节且听本文娓娓道来。

JavaScript 单元测试如今对于前端开发来说并不陌生，前端工程化之后项目的代码质量越来越受到重视，单元测试无疑是一种衡量代码质量的重要手段，而测试覆盖率则是衡量测试完整性的一种手段：通过已执行代码的覆盖率，用于评测代码的可靠性和稳定性，可以及时发现没有被测试用例执行到的代码块，提前发现可能的逻辑错误。

伊斯坦布尔（以下简称 Istanbul）是一个基于 JavaScript 的测试覆盖率统计工具，目前绝大多数测试框架比如 jest mocha 等都是使用 Istanbul 来统计覆盖率的。伊斯坦布尔有一个比较老的版本 istanbul.js（已不再维护）和一个新的版本 nyc。虽然使用 Istanbul 的人很多，但是几乎没有介绍其实现原理的文章，那么 Istanbul 计算和统计测试覆盖率的整个流程是怎样的呢？

你是否在为如何制定前后端协作规范而发愁？干货来啦，一文带你了解我们团队内部沉淀并践行已久的前后端协作规范。

某天工作中，突然接收到了用户对于内部测试环境上java进程服务日志乱码异常的反馈，经过查看相关文件，发现中文字体无法正常显示，严重影响到了用户的日常工作，因此开始处理该问题。

C++是一门古老的语言，但仍然在不间断更新中，不断引用新特性。但与此同时 C++又甩不掉巨大的历史包袱，并且 C++的设计初衷和理念造成了 C++异常复杂，还出现了很多不合理的“缺陷”。

我们的后台系统，大部分的表格都带有分页和loading，为了不做重复的工作，基于element-ui封装了一个自带分页与loading的组件，下面大致介绍一下我的设计思路。

Apache Flink作为Google Dataflow Model的工业级实现，经过多年的发展，如今已经成为流式计算开源领域的事实标准。它具有高吞吐、低时延、原生流批一体、高一致性、高可用性、高伸缩性的特征，同时提供丰富的层级化API、时间窗口、状态化计算等语义，方便用户快速入门实时开发，构建实时计算体系。

古语有云，工欲善其事，必先利其器。要想让大规模、大流量的Flink作业高效运行，就必然要进行调优，并且理解其背后的原理。本文是笔者根据过往经验以及调优实践，结合京东实时计算平台（JRC）背景产出的面向专业人员的Flink流作业调优指南。主要包含以下四个方面：

• TaskManager内存模型调优
• 网络栈调优
• RocksDB与状态调优
• 其他调优项

本文基于Flink 1.12版本。阅读之前，建议读者对Flink基础组件、编程模型和运行时有较深入的了解。