几年前，也许是在我参加工作的第一年。 那时候，亚马逊还没有退出中国。最大的阅读买书的应用是亚马逊书城，最方便的读书会员会员是kindle unlimit。 买kindle的unlimit的会员，就可以借阅亚马逊书城里几乎所有的书。 那一年，我为了增加自己的知识与眼界，也为了消磨一些无聊的时间，我买了kindle pw4。 我给自己制定了一个小的读书计划。 每天至少读一本书的1%，每天读至少五本书。 我当时还用excel记录了每天，每本书的阅读进度。这种习惯持续了半年左右，直到我做手术时才终止。 当我回首那段读书时间后，在不知不觉中，我竟然读完了一百多本书。 半年时间我读的书，要比我大学四年读的书还要多。 分析原因，则总结出以下三点 1. 量化 量化：每次读书，至少要读百分之一。当然这只是一个理论值，最低的限度是至少翻一页。因为有些非常厚的书，即使是百分之一，一天之内也是很难读完的。例如《权利的游戏全集》英文版，我几乎每天都看，看了一周之后，再看看进度，还是不足百分之一。 2. 观测 观测：就是需要记录读书的进度，因为只有能观测到阅读的进度，才会比较容易发现时间的累积效果，才会有目标。简单的方法你可以用个excel, 每天记录进度。 例如如下表格： 书名 08-04(周一) 05 06 07 08 09 10 三体 5% 6% 百年孤独 20% 22% 3. 放弃 放弃：人在选书，书也在选人。有时候，一本书读了一小部分，发现读之无味，不读又觉得不该中途放弃。这时候，你应该放弃继续读这本书，把它放到一边，选择其他的书来看。 4. 坚持 坚持：一件事情，即使再困难，只要能坚持两周以上，就会形成习惯。一旦形成习惯，困难度就会显著降低。 以前我学车的时候，每天都要五点起床，去驾校学车。刚开始第一天，五点起床，被窝里仿佛是个黑洞漩涡，而我必要要有一个逃逸速度才能不被黑洞拉进去。 然而坚持一周之后，学车结束了，开始正常上班，我发现我也能很自然的在五点起床。 所以，不要以为百分之一很小，也不要以为阅读很难，自己先试试，看看两周之后的结果。 5. 针对性 对于不同类型的书，读书方法也不同，这里推荐大家看看《如何阅读一本书》

总结 第二份工作快到一年了，我最近申请离职了。 同事问我离职原因，我说被领导骂了，感觉自尊受辱，索性不干了。 实际上被领导骂只是压死骆驼的最后一根稻草，我也不是那种会心血来潮说干就不干的。 这份工作，我做了不到一年，大部分的时间我是做的不开心的。 所以离职是一直在心里酝酿。 为什么会工作不开心？ 主要原因有以下四点： 行业前景暗淡：S公司处在行业的中游，上游受到运营商管控，下游在客户层面话语权也不大。这是一个资源限制型的行业，行业的命脉就在运营商，可能运营商有个风吹草动，整个行业就要翻江倒海。 自研能力薄弱：S公司大部分业务都是购买的第三方的软件，各种变更都受到制约，添加一个小功能都要付费升级。自研能力弱的一个原因可能就是前些年赚钱太容易了，投资研发哪有赚快钱来的舒服呢。同时也是这个原因，多个第三方软件之间也造成了数据割裂，运行维护困难。 家族企业制约：S公司大部分人员都是老板的亲朋好友，家族式企业的优点是内聚力强，但是包容性弱。之前也有一些大厂进来的员工，没多久就辞职了。 我曾经也跟老板沟通过，似乎老板也有心做些变革。但是变革哪有那么容易，要变革不早都变了，还要等到现在？ 短期主义：似乎S公司没有什么具体的愿景，唯一感觉到的愿景就是赚快钱。一旦发现投入的回报太少，就立即切换目标。 企业关怀差：说实在，我没有感觉到多少员工关怀。在S公司的工作和在地主家做短工也没啥区别，老板想什么都要管，但是即管不了那么多，又管的不好。所以给人的感觉就是东一棒槌，西一榔头，看起来很卖力，实际上并没有什么产出。几乎每个月都有人离职，对员工都吝啬，不考虑员工的自尊，员工怎么可能对公司有归属感。 工作压力大：受限于资源收紧、产品优势小，老板想提高营业额的方法是提高员工的服务水平。说实在，这真是杯水车薪。不想着从底层系统的解决问题，只想着通过给员工压力、通过加班来解决问题，只会造成工作压力大、人员流失大。 所以，我的离职，实际上也是考虑再三的一个选择。 当然，我在S公司也不是什么收获都没有。 收获总结 深入了解了行业的运行原理、客户、资源、政策等信息 对于数据分析方面有了较大的进步，毕竟我做了40+个数据报表来分析运行数据 深入学习了python, 主要用来做数据分析。数据分析方面的协议栈主要有pandas、duckdb、doris(MySQL)、grafana来组成 深入学习了python的GUI开发，主要用到的框架是wxPython，开发的两个工具分别给到运维人员和客服去使用，来提高运行效率

安装tesserocr-windows_build 到tesserocr-windows_build release页面下载对应的whl文件 如下载 tesserocr-2.6.2-cp312-cp312-win_amd64.whl， 下载之后用pip安装 pip install tesserocr-2.6.2-cp312-cp312-win_amd64.whl 安装ocr windows exe程序 在这个页面，有对应的exe程序，https://digi.bib.uni-mannheim.de/tesseract/ 例如下载这个exe文件 https://digi.bib.uni-mannheim.de/tesseract/tesseract-ocr-w64-setup-v5.3.0.20221214.exe 下载完成之后点击安装，一般我们不需要修改他的安装位置，默认的安装位置是C:\Program Files\Tesseract-OCR 我们将C:\Program Files\Tesseract-OCR\tessdata下的所有文件，复制到C:\Program Files\Tesseract-OCR\目录下 参考 https://github.com/simonflueckiger/tesserocr-windows_build/releases https://digi.bib.uni-mannheim.de/tesseract/ https://tesseract-ocr.github.io/tessdoc/Downloads.html https://blog.csdn.net/Yuyh131/article/details/103880585

counter类型的变化率 rate, irate, increase counter类型一般是只增不减的累积值，例如系统累计的http请求数量, 累计的话单数量。 counter类型的指标变化率一般使用三个函数来计算，rate, irate, increase 指标每隔15s采样一次数据, A列是采集的指标值，B列是对应的采集时间。 demo_api_request_duration_seconds_count{instance="demo-service-0:10000",path="/api/bar",status="200",method="GET"}[1m] 序号 A B 1 294401976 1710549816.105 2 294402185 1710549831.105 3 294402393 1710549846.105 4 294402599 1710549861.105 rate是计算每秒的变化率, rate 计算方案 (A4-A1) / (B4-B1)， 这里选择了首尾两个值的差值，除以时长秒 irate 计算方案 (A4-A3) / (B4-B3) , 这里只选择里最后两个点的差值，除以时长秒 increase 计算方式 (A4-A1) / (B4-B1) * 60, 这里的60是1m, 其实increase就是rate() * windows_seconds的语法糖 guage 296164749 @1710648381.105 296165055 @1710648396.105 296165364 @1710648411.105 296165668 @1710648426.105 296165978 @1710648441.105 296166186 @1710648456.105 296166505 @1710648471.105 296166826 @1710648486.105 296167151 @1710648501....

我知道ts支持范型，但是因为几乎用不到，所以对于范型对我来说往往蒙上一层神秘色彩。 最近我才真正的体会到范型的真正威力。 下面就介绍我的使用场景。 在和后端接口交互的时候， 后端接口返回的数据都是如下的类型。 interface XData { success: boolean total: number result: any[] } 这里我把result定义为any类型，因为它的具体类型是由接口确定的。 比如查话单的接口是话单的结构类型，查订单的接口返回的是订单的类型。 interface CDR { id: number creatAt: string } interface Order { id: number } 在不用范型的时候，我们要么定义如下两个interface interface XDataCDR { success: boolean total: number result: CDR[] } interface XDataOrder { success: boolean total: number result: Order[] } 在使用axios的时候，对于响应体的data, 可以使用如下的方式声明data function getCDR (id) { return axios.get<XDataCDR>('/api/xxx' + id) } 但是，如果我们稍微修改一下XData的类型声明，加上范型。 就不需要用到XDataCDR和XDataOrder两个接口。 interface XData<T> { success: boolean total: number result: T[] } function getCDR (id) { return axios....

前言 最近我在开发一个demo程序，为了加速开发，我觉得直接用js要比用typescript更快，而且这只是一个demo程序，杀鸡焉用牛刀。 而且一旦我要用typescript开发，避免不了要各种配置，例如typescript, ts-node, nodemon之类的，很是繁琐。而且ts也必须要经过编译后才能运行。 然而，直到遇到一个bug, 我排查了半天，才发现是一个对象的属性写错了。本身这个对象是没有这个属性的，js没有任何错误提示。我只能一步一步缩小代码的范围，最终才定位到是属性拼写的错误。 这个拼写的错误，应该是vscode的智能补全，给出的提示词，我直接回车确认了。 这件事给我一个教训：以后所有代码都要用ts去编写。 直接用js去编写虽然看起来写的快，但是代码调试太痛苦了。 这种拼写错误，ts的智能提示会直接告诉你错误的地方，但是如果去排查js文件，花费的时间是无法估量的。 但是我又不太想去配置各种ts的执行环境，就想起来之前曾经用的bun这个ts执行工具。 虽然bun这个工具才刚刚发布1.0版本，但是在开发环境使用也是足够了。 我的设想是在开发环境用bun, 在生产环境用nodejs执行bun编译后的js代码。 这个demo程序用bun去运行的时候，没发现任何兼容问题。 这也让我有了继续研究下去的信心。 bun的开发环境 我之前看过deno, 但是看多deno的官方文档后，发现并不符合我的胃口。 但是bun的文档写的很好。 任何工具的第一步都是安装，但是bun似乎在windows上执行并不太好，所以我是用windows的linux子系统，或者在mac上安装的bun。 具体的安装步骤可以参考，https://bun.sh/docs/installation 项目初始化 bun init bun init helps you get started with a minimal project and tries to guess sensible defaults. Press ^C anytime to quit. package name (quickstart): entry point (index.ts): Done! A package.json file was saved in the current directory. + index.ts + .gitignore + tsconfig.json (for editor auto-complete) + README....

我以前看过一部电影，叫做《入侵脑细胞》，这部电影提供一种可能性。类似的电影还有《盗梦空间》，都是将一种思想植入别人的思想中。 这两部电影虽然提供了可能性，但是却无法提供实际可操作的方案。 最近在阅读的一本书也于此有关，叫做《对不起，我操控了你的大脑》，是一个叫做剑桥分析、曾轰动世界的公司，利用基于大数据、算法、人工智能、心理学来做思想植入的。常见的领域如操纵大选，并且提供成功的案例。 但是作为普通人，大规模的思想植入似乎里我们还是比较遥远。 但是真的那么遥远吗？ 昨天我爸来看我，之前他总是抱怨手机流量不够用。我给他换了每个月180G的流量卡，才过没两三天，他说已经用了20多G了。按照这个速度，180G的流量也不够用一个月。 我问：“你怎么会用那么多流量！，你用手机看视频的吗？” 爸说：“我经常刷抖音，刷好久，刷的眼疼” 我说：“你还是少刷点手机吧”，虽然这只是苍白无力的 一句关心。 我爸生于70年代，没怎么读过书，小学文凭。现在年近五十，经常带着鸭舌帽，依然遮不住后脑勺斑白的头发。虽然他经常用手机，但是很多东西依然搞不明白，需要找身边的年轻人来帮忙设置手机。 一个50多岁的人，人生过了大半。面对现在飞速发展的社会，很多东西都已经无法适应。对于他自己来说，也基本上无法改变自己。从第七次人口普查的数据中可以看出，在2020年60+的人口已经占比接近14亿人口的20%了，随着时间的推移，这个占比只会增大。 对于我爸这类的人，即使刷的眼睛疼，也无法控制自己，还是一直不停的刷。 由此可见，像这种大公司，制作的超级App有多可怕。能够一直持续的让大脑保持短期兴奋。这种超级App，背后都是心理学家、计算机学家、数据科学家等。 这些专家对待普通大众，就像哥伦布对待印第安人。 因为我发现他们没有什么信仰，也没有任何崇拜的形象，人们又都很温和，他们无邪得不知道什么是邪恶，从不侵害别人，也不懂得偷窃，没有打斗，特别的温顺 《哥伦布日记》 或许几十年以后，大部分人的大脑已经退化，也不需要有思考能里。只需要机械的按照刺激->反应去行动。 这种进化是一种潮流，绝大多数人都难以幸免。作为一个独立思考的人，我只能尽量避免被影响，远离社交网络。

我在系统的环境变量设置里，用户和系统中，都加入了ELECTRON_MIRROR=https://npmmirror.com/mirrors/electron/这个环境变量。 单独打开windows Terminal应用，使用 env | grep ELE 是能搜到我设置的环境变量的。但是在vscode中，这个环境变量不存在。 我尝试了以下几个方法 重启电脑，无效 配置"terminal.integrated.persistentSessionReviveProcess": "never", 然后重启电脑，无效 在终端直接执行code ., 在终端打开vscode, 依然无效 因此，我想起了之前配置的pwsh的配置文件。 可以使用code $PROFILE, 打开pwsh的配置文件。 然后再配置文件中设置环境变量， 之后重启vscode, 环境变量就正常能读取到了。 # 文件名 Microsoft.PowerShell_profile.ps1 $env:ELECTRON_MIRROR="https://npmmirror.com/mirrors/electron/" 参考 https://www.zhihu.com/question/266858097

今天遇到一个奇怪的问题，react-router的路径匹配无法正常工作，反而向vite的dev server发送了GET请求，这个请求报错404。页面直接无法访问。 按理说这种前端路由的框架应该不需要向后段发送请求的。 后来我怀疑是不是代理的问题，但是只是部分页面无法访问，所以排出这个选项。 随后我的系统又收到一条测试数据，这条测试数据却能够正常跳转。 我仔细的对别了两个不同的url，发现有问题的那个url包含了一个英文字符., 所以我怀疑是react-router的路径匹配有问题。 /call/2023-11-09/nlLBs32pp.2oXhnY6xzmYBCnjhYUkc7Z /call/2023-11-09/fYqZKTGHBFVCz4iC5irulFc83giH9bsa 我的第一反应是react-router对于动态的路径，是有字符要求的。翻阅官方文档后，没有发现类似的描述。 然后我在react-router的issue列表上查找有没有人提出类似的问题，发现了 [Bug]: paths with dynamic parameters do not work correctly when there is a dot in the url, 紧接着有人分析，说这个问题并不是react-router上的，而是出在vite上。 vite的项目上也有对应的issue反应这个问题。 解决方案 方案1: 升级vite 到5.x， 由于当前稳定的还是4.x的vite, 所以这个方案改动太大，放弃 方案2: 在匹配路径最后加上/, 也就是原本的/a.b要改成/a.b/, 我试了这个方案，是有效的。 方案3: 使用这个专门用来解决这个问题的插件， https://github.com/ivesia/vite-plugin-rewrite-all 深入分析 路径带有点，一般可能认为是一个静态资源，例如a.js, b.css之类的，所以vite会把符合这个模式的路径直接向后段发送请求，去获取静态资源，而不是去匹配一个组件。 参考 https://github.com/remix-run/react-router/issues/8389 https://github.com/vitejs/vite/issues/2415 https://github.com/vitejs/vite/issues/11282 https://github.com/vitejs/vite/issues/2628 https://github.com/vitejs/vite/pull/2191/files https://github.com/bripkens/connect-history-api-fallback

购买选择 我的kindle pw4已经用了快三年了，机器性能有些不足，电池也有些不够用了。正逢双十一之际，我觉得可以买一个开放系统的电纸书来用用。 买开放系统的另一个原因是自从亚马逊退出中国后，我用微信读书比较多，也买了微信读书的会员。 开放系统基本上都是基于安卓系统定制的，可以选择的厂商比较多。 最终筛选下来，我选择了汉王clear7和文石leaf3， 我下单了两个，觉得先体验一下，然后在退一个。 然而用了不到两天之后，我还是决定把两个机器都给退了，继续用我的kindle pw4。 选择因素 就我个人而言，电子书最为重要的选择因素有以下三点。 显示效果: 说实在的，现在的电子书基本上都是carta1200、300ppi、冷暖光。基本上从显示效果上来说，各大厂家都是半斤八两。就我自己体验而言，我并没有发现汉王的显示效果和文石leaf3有何不同。 握持手感: 外观影响握持手感，外观一般分为两类，一类是就是平板设计，像kindle paperwhite系列。另一类就是书脊式设计，握持更舒适，像kindle os3, 汉王clear7之类的。 简洁系统: 电子书并不是手机，不需要太多的功能，功能太多反而成为累赘 稳定性: 点子产品难免被摔、或者淋水，对于这些意外情况，如果产品非常脆弱，那么很大可能会损失大笔的金额。 续航 文石的缺点 文石和汉王的两款产品，拿到手开机不到一小时，我就决定先退了文石。 原因有以下几点 显示效果文石和汉王差不多，没啥突出亮点 握持手感文石肯定比不过汉王的书脊式设计, 并且汉王更轻 文石的系统太复杂，设置太多，甚至还有个iphone类似的小白点设计，小白点点击之后展开很多图标，每个图标我都不知道做什么的 掉电速度，文石的电量肉眼可见的在不断减少 汉王的缺点 微信读书功能阉割, 这不是汉王的问题，而是微信读书自身的问题。例如书架页面，书籍只有一个排序的顺序，就是按照最近阅读的排序。而无法像ios或者安卓app一样能够按照阅读进度排序，另外也没有阅读时长分析的功能。 另外我也注意到，微信读书电纸书版，扫码登录的有效期是24小时，我不知道这是不是意味着24小时之后我又要重新扫码。 触感光滑，汉王的背板的触感让人感觉非常光滑，感觉稍不注意就会滑下去的样子。完全没有kindle pw4那种拿在手机，就粘在手上的感觉。所以我觉得，买汉王，就必须要买一个保护套，但是官方卖的保护套也太贵了吧，居然要110多块，这点有点像割韭菜。什么保护套能卖那么贵，都快赶上十分之一的电纸书的价格了。 词典缺陷，汉王的词典也是我要吐槽的功能之一，只能把单词的原型加入到单词本，单词来个复数或者过去分词，就不能加入单词本了。kindle的生词本，所有单词，无论什么形式都能加入单词本。 掉电速度, 从昨晚五点多开机，到今天早上，基本上没到一天，电池已经掉电接近40%了 自动关机, 为了省电，汉王在2小时不使用后，会自动关机。然而这个开机时间就有点久，你可设想一下，每天早上，你想看书的时候，你都要等几十秒的开机时间，那你能受得了吗？ 按钮反馈，松松垮垮, 触感没有一致性体验 结论 目前而言，国产的电纸书系统，除了开放的系统之外，其他各个方面还是存在与kindle有较大的差距。 当然，如果你从未使用过kindle系列的产品，国产的电纸书还是值得买的。