https://bot.sannysoft.com/
这个网站可以检查是否有不同于正常浏览器的爬虫特征. 如果要爬取网站数据则要非常注意了.
参考文章https://cloud.tencent.com/developer/article/1755512

之前对分页和瀑布流的理解比较简单, 就是手机滑动更适合瀑布流而电脑点击更适合分页. 今天才发现自己想简单了.
确实, 电脑上鼠标拖拉和滚动都不如手机上的手指滑动操作方便.上滑就特别适合加载新的数据.
但是,数据呈现的目的是不同的,两种方式各有优劣. 虽然瀑布流在手机上发扬光大, 但两者不是以手机或电脑来区分的.
我最近做的小程序, 需要呈现很多数据, 并且这些数据还需要增删改查. 因为是手机用, 我想当然认为瀑布流体验更好(当然实现难度也大), 就选择了用瀑布流.
然而近期发现一些问题, 用户反馈有时候数据会乱, 常常是重复. 查了下不是数据库的问题, 而是界面呈现的问题. 当然这种情况重新进入小程序也能解决. 我增加了一些控制, 在从数据库取数据的时候禁止用户操作, 但只解决了一部分问题.
最近打算用js面向对象的方法重构这部分代码, 写到增删改查的时候想到了这个问题: 在UI设计中, 瀑布流的方式是否适合呈现有大量数据的增删改查的页面?
如果增加了一个数据, 需要考虑这个数据增加的位置. 如果增加的数据排在前面已经显示的数据中, 那么就要重新请求已显示的数据. 但数据库的查询是按分页进行的, 我应该请求哪些分页? 似乎从数据增加位置之后的分页都要请求. 那么新数据增加在第几页? 需要计算,且计算结果必须和数据库自己的排序计算结果一致. 如果请求这之后的所有分页,有可能数据量非常大. 而且界面现在显示了N页, 增加1条数据变成了N页+1条, 而数据库是按页请求, 这样又不对齐了, 显示的最后一条数据要么从显示中删除, 要么再请求一整页.
删除有同样的问题. 修改操作如果修改的是排序的依据, 也存在新数据排到了哪儿的问题, 新旧位置之间的数据都要更新,或者用算法保持与数据库端一致.
这个逻辑就会变得复杂. 根源是: 数据库是按照分页方式请求的, 前端的增删操作导致前端数据和数据库数据无法对齐. 需要大量操作使两端对齐, 耗费本地计算和带宽, 感觉很不经济.
用分页就解决了, 非常简单, 增删改查后, 只要再次请求当前页就好了!即便是删除数据导致当前页消失, 也很容易计算到最近还存在数据的页是第几页.
这个问题抛给了metaso和gpt4o,两者都给出了否定的回答, 都指出分页更适合.
根据metaso给出的链接参考: https://blog.csdn.net/weixin_64051447/article/details/129420444, 其中有一个引文很重要:

滚动是延续，而点击是决定。—— Josh Porter

瀑布流就是为了不断地让用户看新的东西(新数据不断延续没有终点), 而点击是用户自己决定要看哪一部分东西.
所以瀑布流适合给用户不断地灌输新的数据, 而分页适合让用户管理数据.
贴一下gpt4o的回答, 我觉得总结得挺好

gpt4o的回答

在UI设计中，瀑布流（也称为无限滚动）是一种常见的布局方式，尤其适用于展示大量内容，例如图片库、社交媒体动态等。然而，这种布局方式在某些场景中可能并不合适，特别是在需要对大量数据进行增删改查（CRUD操作）的页面上。

瀑布流布局的优势：

1. 用户体验：用户可以不间断地浏览内容，不需要经过分页的过程。
2. 视觉吸引力：对于展示图像、视频等多媒体内容时，瀑布流能够更好地利用屏幕空间，看起来更加美观。
3. 加载效率：通过懒加载技术，可以动态加载内容，从而减少初始加载时间，提高性能。

在增删改查页面中使用瀑布流可能的问题：

1. 可查找性差：当用户需要查找特定数据时，瀑布流不如分页结构直观。无限滚动让定位特定记录变得困难。
2. 数据管理复杂：频繁的数据增删操作可能导致数据的顺序和显示出现问题，需要复杂的逻辑进行维护。
3. 浏览状态难以保存：用户在进行编辑后需要返回列表时，不容易恢复到之前的浏览位置，这会影响用户体验。
4. 性能问题：随着数据量增加，长时间滚动会占用更多内存，可能导致性能下降。

适合增删改查页面的替代设计方案：

1. 分页设计：

   • 每页显示固定数量的数据，便于管理和查找特定记录。
   • 提供清晰的导航条，让用户能够快速跳转到不同页码。

2. 列表视图和表格视图结合：

   • 使用表格视图提供清晰的数据结构显示，便于排序和筛选。
   • 提供简单直观的数据操作按钮，例如新增、编辑或删除。

3. 搜索和筛选功能：

   • 提供强大的搜索栏和筛选条件，让用户能够快速找到所需数据。
   • 动态更新结果，提高交互效率。

4. 分区加载：

   • 结合懒加载技术，仅在用户需要时才加载更多内容，但采用明确的分段结构，而非无限滚动。

综上所述，对于有大量数据且涉及频繁增删改查操作的页面设计来说，更建议采取分页设计、结合列表和表格视图，以及提供强大的搜索和筛选功能来提升用户体验。瀑布流布局虽有其独特优势，但在这种场景中并不是最佳选择。

jest也是微信官方推荐的.
最简单的方式: jest安装后, 在目录下运行jest就可以. 它会搜索当前目录和所有子目录,并运行*.test.js结尾的所有测试,并汇总.
对于微信中的一些全局模块如wx, 需要mock. 在测试目录下建立__mocks__/目录, 所有要mock的都放在这儿. 如放个wx.js
在*.test.js中, 对全局的wx赋值global.wx=require('__mocks__/wx.js').
wx.js使用module.exports导出即可.
除了自己直接写mock模拟的函数外(如写一个wx.cloud.database = function mockFunc(){}的mock函数), 还可以用jest的mock函数const mockFunc = jest.fn(函数体);wx.cloud.database = mockFunc. 这样被mock的函数就会自带统计和记录功能.
如:

• 统计mock函数被调用的次数 mockFunc.mock.calls.length
• mock函数第n次调用时的第x个参数值 mockFunc.mock.calls[n][x]
• mock函数第n次调用的返回结果 mockFunc.mock.result[n].value
• mock函数最后一次调用的第一个参数 mockFunc.mock.lastCall[0]
• 对class的mock, 同样可以使用new const myMock1 = jest.fn();const a = new myMock1();
• mock函数定义每一次的返回值,并且尅循环调用 mockFunc.mockReturnValueOnce(10).mockReturnValueOnce('x').mockReturnValue(true)
• mock模块的异步Promise返回值

import axios from 'axios';
jest.mock('axios'); 
const users = [{name: 'Bob'}];
const resp = {data: users};
axios.get.mockResolvedValue(resp);

• mock一个模块的部分函数和值

五块金牌是留给勇敢者的, 智慧者的, 发挥最好的人才配得上.

阅读理解: 勇敢和智慧, 即胆识. 主观的胆识才能遇到和抓住客观的机遇. 发挥最好, 也就是说能力最强并不能拿到冠军, 要临场发挥最好. 也就是说, 我们自己每个人恃才傲物, 觉得自己能力很强, 但只有在实战中发挥出来, 才能赢.

你面面俱到, 练得没有漏洞是不可能的, 只是在这些当中, 能够提炼出重点, 把这些得分手段精益求精, 把短板,把对手抓你的地方有所突破, 有所改善.

阅读理解: 面面俱到没有漏洞等于不可能. 所以没有人是完美的, 不要完美主义. 那要怎么做? 要把重点的得分手段去精益求精, 把短板(是指对方攻击自己的点)有所突破和改善. 这和木桶理论有一点矛盾, 或者说, 和用木桶理论作为解释一切的手段有矛盾. 木桶理论说最短的木板决定装水的容量, 所以要把所有的短板都补长, 所以要方方面面每个木板都做高, 做完美. 木桶理论有什么问题? 木桶是装水的, 不让静态的水流失的手段,所以木桶理论仅仅是防御静止的成果流失的手段, 只守而不攻, 并且是不去区分地防守. 个人资源是有限的, 环境是动态变化的, 而完美是不可能的, 把所有资源都投入防守, 面对动荡变化的环境, 最后只会成果越来越少,就像拎着装水的木桶在疾驰在颠簸路面上疾驰, 木桶上下翻滚, 然后我们的精力却全部放在修补木桶的短板上. 回到刘教头的话, 短板只能是有所突破和改善就很好了, 并且要补对手攻击自己的短板, 如果自己知道的弱点而别人不知道, 无法攻击也就无所谓去弥补. 面面俱到不可能, 要加强得分手段, 也就是要攻击对方, 要得分, 要开源, 而不是只是固守现有的成果. 所以, 强调木桶理论很容易故步自封陷入完美主义, 防御不存在的假想敌. 开源节流, 不能只节流不开源. 并且要突出自己的优势去开源, 去最大可能地发挥优势主动去抢夺(市场/资源/分数). 对于短板的修补要有针对性, 争取突破改善, 而不是要把短板做到最好. 短板之所以是短板, 就是自己天生或习惯弱于对方的, 补短板是事倍功半, 要补, 但要在自己有限的资源下看性价比.

会打球和会赢球是两码事

阅读理解: 能力强和能成功是两码事. 自己很强, 会很多事情, 很勤奋, 但就能成功吗? 两码事. 所以不要总是想着自己多强,或者把资源都投入让自己变强. 是不是很反传统? 除了变强,还要去赢. 强为什么不等于赢? 还是因为"强"是静态的,是此时此刻的一个状态, 而"赢"是动态的, 是竞争,是争取, 是随机应变. 如果不能随机应变,发挥自己的强, 适应竞争的环境,打败现实的对手(而不是想象的不存在的对手).

在赛场上的时候, 侥幸和犹豫, 想赢怕输, 这是失败的根本.宁肯坚决地错,也不犹豫地对. 因为你坚定下来的东西一定是你的认知.

阅读理解: 坚决地错, 很反传统. 传统有道是"三思而后行",但这未必是对的. 坚决地错和犹豫地对有什么根本区别? 坚决就是出自自己的认知, 犹豫就是混杂了别人的想法. 因为对别人的想法理解不通透, 所以即使是对也不知道为什么对, 又因为与自己想法的冲突, 因此犹豫.但在赛场上, 在战场上商场上, 一是没有时间给你犹豫, 二是没有足够的信息给你犹豫, 在那一刻必须做出尽快的决定, 无论对错. 如果是错的, 也是事后有了结果,有了充足的时间再去分析, 然后纠正的改善的是自己的认知, 而不是去简单听从别人的意见.所以, 坚决地错, 就是坚定执行自己的认知, 即便是错误的, 也是改善自己认知的机会. 如果没错过, 也就不可能提升自己的认知.

如果你在犹豫的时候,其实你怀疑的是自己,把位置摆低,去拼这五个项目,而不要去守.

阅读理解: 去拼,不要去守. 是换个方式讲上面说的得分手段精益求精. 得分就是要进攻, 进攻才能开源, 开源才有节流的资本, 才有能守的对象. 然而, 在激烈的竞争中, 主动进攻胜于被动防守. 被动防守总是容易消极的, 盯着自己的错误而不是别人的错误, 只能防止资本的减少而不能增加资本.

实现梦想,不留遗憾, 相信自己,相信团队.

阅读理解: 这句话虽然是末尾的一句祝福打气话, 但是也是再一次强调了前面说的话. 实现梦想不留遗憾, 也就是要去拼, 做自己想做的. 相信自己也就是要坚定和实践自己的认知. 相信团队, 做很多事情都不是一个人能完成的, 如果是一个团队去做, 要彼此信任才能减少不必要的内耗.

默认的导航栏NavigationBar不支持触摸事件, 需要自定义导航栏. 官方社区有个文档可以参考https://developers.weixin.qq.com/community/develop/article/doc/000a8c989307888cbe1abbf675f413

以下是gpt4o的回答.

在微信小程序中，原生的导航栏（通过 navigationBarTitleText 等配置项定义的顶部标题栏）本身不支持直接添加点击事件。不过，你可以采用一些变通的方法来实现类似的效果。

自定义导航栏

你可以通过自己编写一个自定义导航栏组件来实现点击事件。这通常涉及隐藏原生导航栏，并在页面顶部放置一个自定义视图组件。

隐藏原生导航栏

在 app.json 或单个页面的 json 文件中，将 navigationStyle 设置为 "custom"。

{
  "navigationStyle": "custom"
}

创建自定义导航栏

创建一个自定义组件，例如 custom-navbar:

custom-navbar.wxml

<view class="navbar">
  <view class="navbar-title" bindtap="onTitleClick">{{title}}</view>
</view>

custom-navbar.wxss

.navbar {
  height: 40px;
  background-color: #fff;
  display: flex;
  justify-content: center;
  align-items: center;
}

.navbar-title {
  font-size: 18px;
}

custom-navbar.js

Component({
  properties: {
    title: {
      type: String,
      value: '默认标题'
    }
  },

  methods: {
    onTitleClick() {
      // 自定义逻辑，比如跳转或者弹出提示等
      wx.showToast({
        title: '标题被点击了',
        icon: 'none'
      });
    }
  }
})

在页面中使用自定义导航栏

page.wxml

<custom-navbar title="我的标题"></custom-navbar>
<view class="page-content">
  <!-- 页面内容 -->
</view>

这样一来，你就可以在自定义导航栏中处理各种点击事件，完全掌控其行为和样式。此外，自定义导航栏组件可以反复使用，还能根据需要灵活调整。

先是介绍了newrank 新红网站, 可以搜索小红书的一些数据. 和小红书官方的蒲公英类似. 注意不是千帆, 千帆是卖家订单管理.
新红虽然是非官方, 数据刷新肯定不如官方及时, 但是比蒲公英的数据肯定更全面的. 蒲公英的目的是要推荐商家与博主合作, 并且管理自己与博主合作的笔记, 所以像是笔记版的1688, 包括筛选博主, 筛选笔记,管理合作的笔记. 所以是没有全局的数据的, 比如某一个类别的整体数据表现. 当然单个博主的数据还是挺全面的. 包括其笔记内容和粉丝画像等.

新红和蒲公英对比

课程内容

这一节说定位和赛道,我认为本质还是降本(成本维度)增效(变现维度),另外看自身能力(能不能做)和优势(做的比别人好).
除了上面的优势外, 还有所谓养成号,如挑战减肥多少斤第N天.
赛道: 主题 .
三类赛道:

• 观点: 心理学,情感等,输出价值观
• 类目: 类似电商类目的选择
• 人设: 经营自己,相对较难
  变现: 广告/咨询/社区/群聊

评估广告变现能力:

• 不同赛道的含商量, 大牌不太在乎变现, 可能只想种草. 对应一个垂类市场变现能力就强

定义含商量: 商业笔记数量/种草达人数量 种草大盘
如 影视综: 6345/63110 = 0.1商业笔记(报备)/种草达人.
科技互联网 0.03, 美妆: 0.3 健康养生:0.4 职场: 0.01 旅游: 0.05 家居家装: 0.1 运动健身: 0.08 摄影摄像: 0.01 情感星座: 0.1 科学科普: 0.04 母婴 17w/79w=0.23 美食: 0.05 生活: 0.08 交通工具 <0.01 教育 0.03
小博主主要走非报备. 报备:非报备=1:1

• 对标账号的变现能力分析
  举例账号: 内在小孩关爱计划
  teacher账号 阿言roy(地方的MCN) 挪威Talk
  其他 魏知新(No1 麻瓜MCN)

搭建人设
个人优势转化为他人价值(1. 利他; 2. 观点引发共鸣)
个人简介: 1. 介绍成就; 2. 经历; 3. 账号主要内容; 4. 联系人/Slogan

小红书主页经营:
头像/背景/介绍/打卡瞬间/封面 (这些都是告知算法自己是什么账号)
深耕.不单单是重复,还要做深.
商家倾向于投中小博主(1~5W)

红人搜索:作者类别

维系微信和小红书群。小红书群用于转发点赞，微信群用于聊天。
图文还是视频？答：从图文转视频。
知识类成本<非知识类的成本
单一场景<多场景
xx 100个系列
数码赛道抽奖比较容易提升点赞
标题反复强调相同的点，形成强化
呈现形式带植入点（产品植入）就容易变现广告
利用社会资源降低成本
要判断选题吸引观众的原因：是标题文字还是封面图片？
笔记分为两种：冲流量和粉丝的笔记（未来隐藏）和长期呈现的
笔记要写得扎心
观众为什么要点进来形成流量？奔着热点话题.
一开始不要打造差异化，先形成足够的用户（做好模仿），再去差异，筛选出用户。

小红书选题策略

• 流量选题
• 人设选题
• 商业选题
  选题需要挖掘而不是去凭空想

自动化：在发现页找选题：点赞高的题目->搜索->看其中有多少点赞高的->看点赞高的作者粉丝数是否低->给出评分。最后要排除封面太好看点进来的。
点赞高有三个原因：1选题好，2粉丝多，3封面靓。要去排除2和3，找到仅因为选题好而获赞的选题。(粉丝少但流量高）
新鲜度：区分是最近的流行爆款（一个月内）还是长期的爆款（年年有）
建立选题库

通过tag寻找。点击tag->筛选->最热->回到上面的路径，找低粉高赞的选题。

通过笔记灵感寻找。小红书“创作服务平台“->笔记灵感->最热。有点接近于笔记灵感

同样的选题反复讲。 看到还有个区别是内容更加真诚更容易吸引人。

新红查找法（付费的）。新红中按互动量排名搜索。
还可以按爆款笔记排行榜查。

火过的选题还会再火，过段时间再次做。

JS中存储JSON只要简单的将object stringify以后写入文件就可以. 反过来读取就是读入文件为字符串再parse.
C语言如何实现配置文件呢? struct当然是最像json的了, 保存就用Flash.
这儿需要注意struct和flash的麻烦之处.
struct的成员变量无论是什么类型,都需要内存地址对齐. struct变量所占内存是连续的, 且大小可以整除最大的变量类型大小. 比如 struct{char a; long b;}x; 那么sizeof(x)不是1+8=9,而是16. 这样如果flash寸土寸金就会显得浪费, 此时可以都用char存储. 这样存储时为了提高内存访问效率, 可以看这篇文章的解析, 有图示.
另外,struct类型的变量名不是地址, 如上面的x,要访问这个变量的地址需要加&,如&x. 这和数组就很不一样. 数组的变量名就是数组的地址. struct变量名其实更像普通变量.
flash 在前面讲过了, 每次写入需要擦除, 擦除需要整个扇区.
简单的做法, 就是把struct转为空指针, 并按大小存储到flash中. 读取也是同样.

存储数据必然有读和写. Flash当然也有. 但是, Flash的写是非常特殊的, 会引出一系列问题.

1. 首先, Flash数据只能从1改为0, 那就意味着写以前必须得先把要写的字节都变成0xFF. 还好, 一般都会提供一个erase擦除的函数.
2. 然而, 擦除操作必须要擦除整个sector! sector(一般翻译为扇区)是flash的最小单位, 具体多大看设置, 从512B到4K不等. BL2028N上有一个_MAX_SS和_MIN_SS的宏定义, 默认为512, SS是Sector Size的简称.
3. 所以如果你要写, 那么你需要擦除整个扇区的数据. 如果你不擦除, 那么你写的结果事实上是和当前扇区上的值相与的结果
   参考这个STM32 Flash读写的说明, 写数据要经过解锁-擦除-写入-上锁四个步骤.

所以正常来说还是用一个flash的库比较好, 比如easyFlash.EasyFlash在2019年v4.0以前只支持字符串值的读写. BL2028N使用的easyFlash正好是2018年的, 只能读写字符串.

感谢AI给出答案啊, 非常有用, 尤其是在第三方文档跟一坨屎一样的时候,还不如直接看原始代码.

var obj = {
name: "John",
age: 30,
city: "New York",
myFunction: function() {
        console.log ("Hello");
}
};

// 自定义replacer函数
function replacer(key, val) {
if (typeof val === 'function') {
        return val.toString ();
}
return val;
}

// 转换为JSON字符串
var jsonString = JSON.stringify(obj, replacer);
console.log (jsonString);

输出的json复制到vscode里格式化一下, 就能读了

linux上有很多, 但几乎都不支持js. 包括:lynx elinks links w3m w3m-img等
links使用特殊的编译模式从源码编译的话, 可以支持JavaScript http://links.twibright.com/user_en.html#ap-javascript . 但是links没有默认支持js的原因也是bug太多.
然后就出现了这个神器: browsh, 不但能运行JavaScript, 甚至还能显示图片看视频!
windows上支持得有问题. 可以用docker: docker run -it browsh/browsh
需要firefox在后台运行. 原理其实是将图片和视频转换为最接近的字符. 不过也超级牛X了.
快捷键: https://www.brow.sh/docs/keybindings/
但是对中文的支持有很多问题. 很多文字缺失了.仔细看了下, 都是只显示奇数而不显示偶数, 如"下载百度APP"只能显示为"下百APP"

上次辞职的是谪仙人

谪仙人就是李白，你猜到了吗
李白四十岁左右到了长安，这个称号是贺知章给他起的。贺知章这时候年纪已经很大了，马上也要辞职：不过是告老还乡。他看了李白的文章惊为天人，给他送个外号：谪仙人，也就是被贬下凡间的神仙。李白诗仙的名号大概就是从这时候来的。贺知章告老还乡前给唐玄宗李隆基推荐了李白，李老板先是给他翰林院供奉的职位做着，主要就是做做文宣写写稿子。有一天李老板坐在沈香子亭里，忽然情绪来了，召集李白来应景谢谢文章，谁知道把李白弄过来，他喝多了还没醒。给凉水洗把脸弄清醒了，李白下笔成文，皇帝惊为天人。又有一次，李白又又又跟着皇上喝多了，结果让高力士给子脱鞋。高力士哪受得了这个，后来就通过杨贵妃说李白坏话。后来李老板要给李白升个官，杨贵妃就给拦着。李白也生气，就辞官了。隆基老板还是豪爽，给了好些金子。辞官离开长安这期间，写了《东武吟》，一是用诗赠别好友，二是纪念在皇帝身边这些个日子，三是感叹世事无常，人情冷暖。想着自己能力了得，不输世间英雄豪杰，如今却只能学古人归隐山林。
写这个话题，是想现在爆火的大厂离职文学，腾讯阿里华为字节，进得了大厂自然各个身手了得。一朝离职，一时爽快，后话如何，未来怎样？没有人知道。网上各位吃瓜群众自然是看个热闹，借他人离职宣泄自己的情绪，大概也不会关心后来会怎样。然而太阳底下无新事，大厂离职这些桥段，历史上也必然一次次发生过。与其一时宣泄情绪，不如看看历史。说严肃点儿是以史为鉴，说轻松点儿是找点故事读读，说功利点儿是还能学点老祖宗的知识，享受一点文章诗词的熏陶，岂不是比天天上滑这些看过就忘的笔记帖子要好？至少这历史其中多是真的，那网上说自己如何如何，真真假假还不知怎么分辨呢。
附新唐书李白辞官相关情节。
天宝初...故白亦至长安。往见贺知章，知章见其文，叹曰：“子，谪仙人也！”言于玄宗，召见金銮殿，论当世事，奏颂一篇。帝赐食，亲为调羹，有诏供奉翰林。白犹与饮徒醉于市。帝坐沈香子亭，意有所感，欲得白为乐章，召入，而白已醉，左右以水颒面，稍解，授笔成文，婉丽精切，无留思。帝爱其才，数宴见。白尝侍帝，醉，使高力士脱靴。力士素贵，耻之，擿其诗以激杨贵妃，帝欲官白，妃辄沮止。白自知不为亲近所容，益骜放不自修......恳求还山，帝赐金放还。

职场不开心，竟然被老板娘排挤，从顶级大厂离职，准备回乡下隐居！
没照片！没照片！没照片！
老板姓李，国内顶级大厂！辞职不干了！注意，厂子绝对是顶级中的顶级，我不说，用小拇指都能猜到！不是吹，我文字功底特别好，我有个老大哥姓贺，夸我些文章写得好，跟神仙下凡一样！贺大哥在李老板的厂里多年，就跟李老板推荐我去给他写文章，我就这么老板直接面试进厂了！文章好大家就愿意看，给厂子外面的人讲讲我厂的好事说说李老板的好话，厂子的经营业绩大大提高，老板当然也特别高兴啊！我到了厂子在文宣部，时不时和老板一起喝酒。有一次喝多了，就有些狂了，让老板的高秘书帮我脱鞋。高秘书天天伺候老板家，就感觉我在侮辱他，哪知道我只是喝多了！结果听人说高秘书私下里给老板娘打小报告，老板要给我升职老板娘就挡着不让！我向来性格直，受不了这些气，不让我干我还就不干了！跟李老板辞职了，老板发了笔钱给我。今天就跟几个要好的兄弟姐妹告别了，回乡下隐居去了！最后写篇文章，在这儿发个帖纪念一下。文章就叫《东武吟》吧。
还没猜出来什么厂？唐厂！
以上参考《新唐书》卷二百二列传第一百二十七。评论区猜猜是谁😁😁😁

体验了宁联眼科的雾视屏2天. 说下体验.
先说下原理和结构. 远视屏有一个Android手机,1个屏幕灯, 两个摄像头,一个主体结构组成.
主体结构有点像一个17寸的显示器,上部放屏幕灯和两个摄像头.摄像头一个对人, 一个对桌面. 主体结构内部是一对拉远镜, 内部下侧放着安卓手机, 屏幕感觉在5~6寸. 屏幕灯的开关是独立的. 主体结构右侧有音量加减/信号切换/亮度/开关键. 后侧有1个hdmi,2个USB-A口, 1个type-c电源口. 电源是最大输出12V 3A.
功能上, 可从HDMI输入显示, 也可以切换内部安卓系统显示(通过信号切换键), 内嵌了一些护眼应用和学习应用.
主要原理就是把安卓屏通过拉远镜拉远.
拉远镜中的图形有一些畸变. 像是看投影在球体内侧的图像一样.
长期使用有些头晕的感觉.
拉远镜中的虚像应该是比较远, 是不是平行光不太清楚.感觉好像很大, 但用相机靠近主体结构同时拍虚像和原安卓屏幕, 发现大小竟然是一样的.
但是距离主体结构不同的距离, 在相机中所占的比例是相同的, 而不是像正常景物,随着距离增大而变小. 也就是虚像的视角大小几乎不变.
个人感觉是顾此失彼. 这个屏幕视角宽度, 只有我看我14寸笔记本的1/3大. 小点的字根本看不清. 比如用ps或blender中都有很多小字体,没法看. 也即是虽然睫状肌放松了,但看起来却费力了.

原文链接
十大趋势:发疯文学,精神远方,游戏人间, 审慎消费, 玄学药方, 悦己, 新型陪伴, 热衷标签, 小众运动, 慢生活.
这些趋势似乎描述了这样的人: 心情压抑苦闷, 生活忙碌单调, 努力换不回好的回报, 命运无常, 经济拮据, 孤独无助, 无人倾诉, 向往更好的生活体验, 对未来不再抱有幻想, 将目光从幻想中美好的未来收回到当下可以立即获得的新鲜快乐.

小程序端支持css动画. 虽然应用了@keyframes会报一条警告, 但事实上又可以使用

/* 定义动画 */
@keyframes spin {
  from {
    transform: rotate(0deg);
  }
  to {
    transform: rotate(360deg);
  }
}
/* 应用于特定元素，例如类名为 spin-element 的元素 */
.spin-element {
  display: inline-block;
  /* 设置旋转的中心点 */
  transform-origin: center;

  /* 应用动画 */
  animation: spin 2s linear infinite; /* 动画名称、持续时间、动画曲线、无限循环 */
}