wangEditor 5

更别提如果用 .NET Core 这类技术栈的话, 大多数优化算法早就被 MSIL 类库跟 nuget 上的各类三方包所实现. 你并不太需要考虑所谓的更优算法的问题. 你调就是了. 当然, 你需要对各种算法有个大体的了解. 知道什么时候该调什么. 比如什么时候用 B 树 什么时候用红黑树. 否则就算这些类库摆在你面前你都不知道用哪个

本来 leetcode 就是毫无意义的事情.
除非你做的是基础设施方面的东西, 比如 K8S, 比如游戏引擎. 那确实用得着. 但是贵国有什么这种基础设施开发的岗位么? 有几个? 库洛米哈游之类的可能有游戏引擎研发岗位, 其他的基本都是 CURD. 业务逻辑复杂技术没啥难度的东西. 可能从立项到公司倒闭都用不上几个算法. 而且这些算法大多数你 google 一下都有现成的例子直接复制粘贴就行.

唯一普遍能用得到算法的就是面试. 所谓面试造火箭入职打螺丝. 实际上面试考算法也不是真说工作中能用的到. 这就只是个门槛. 用来快速筛选候选人的门槛. 不考算法也会拿什么星座 什么生辰八字 什么属相 甚至智商测验题来筛人...

所以本质上刷这玩意并没有实际意义.

AI 现阶段还远不到堪用的阶段.

额, 哥, 可以不用这么麻烦的. 你可以看下各种字幕文件的做法.
你做字幕的时候就可以完全按照时间来, hook video 的 ontimeupdate 事件.
然后至于字幕要显示到什么地方, 这更简单. 右侧不是你的字幕区么, 总高度你算得出来吧, 每一行字幕的高度是固定的吧? 一除就知道能显示多少行字幕吧?

那不就简单了, 把字幕依次排列进字幕列表里, 前面填充刚好满屏数量的空字幕. ontimeupdate 里得到当前帧对应的字幕, 然后 ``全部字幕 DOM 节点[字幕 Index - (显示多少行字幕 / 2)].scrollIntoView()`` 然后正中间正好就是你要显示的字幕. 你要加粗啊还是变色啊随你.

VLC 啊...

@xuanbg 本来就是这个意思.... 你这话表露出来的意思就是 "三脚猫的 DevOps 也可以 hold 住生产环境微服务架构"... 还 " 懂 '点', '会用' "...... 微服务那玩意没有个技术经验丰富的技术大牛把握的话根本就没法搞. 风险太大了. 而且 "因为公司一直没用使用过微服务架构, 所以从项目负责人到运维工程师到一线开发所有人对 DevOps 都不太了解" 这种事简直太常见了. 中厂小厂们基本都是这个样子. 而且就算是我们这种垃圾二线城市, DevOps 的工资都要 2.5W 以上, 普通 CURD 只要 1.5W~1.8W.... 团队负责人脑子抽了在没用微服务架构需求的情况下下这么大成本去招这么一号人?

@xuanbg 仅仅只是知道怎么部署, 怎么给各系统跑起来 知道个 kubectl run docker-compose up 就以为自己可以上微服务就敢往生产环境上上微服务的, 你的年终奖几天就扣光了.

@xuanbg 那就不是 "懂点运维，会用个 docker" 就行的. 想搞微服务, 起码要对整个一套微服务用到的所有组件全都要有相当丰富的运用经验. 知道报错之后大概要从哪里入手分析解决, 知道各组件的各种细节. 绝不是 "懂 '点' 运维" 就行的!!!

你以为 DevOps 工程师工资比 CURD 开发工资高出几倍是因为什么?????

原神. 希诺宁真好用!

@xuanbg 问题就是你只能看到结果是这样的。入参是这样的，中间流转不清楚是哪个环节出的问题。复现不了，又没法跟单体结构一样到处打 log ，没链路追踪你怎么排查？靠蒙是吧？那问题来了，不管是业务网关组件, ES, Skywalking, 还是 Kibana, K8s, 无论怎么说都是增加了系统的复杂度没错吧? 增加复杂度一定会增加出问题的概率你总不可能否认吧? 出问题了怎么解决? 你说重新创建容器就能解决, 看来你也就会这一招了啊. 如果重新创建容器都起不来了呢? 如果某一块核心子系统一直在报错呢? 搞不好就是因为子系统过多, 某个子系统的配置文件里少写了一个逗号导致各种报错呢? 你能在多长时间内发现并解决问题? 生产环境不等人, 一分钟的失效都是真金白银的损失. 你是准备拿你的年终奖赌这些周边系统以及业务子系统绝不可能发生这些事情?

@xuanbg 那我问你. 微服务生产环境发生了一个报错. 导致一个订单的附加订单错误结算. 请问你要怎么排查? 你是准备捋着代码挨个微服务去查是么? 是不是要部署 Skywalking? Skywalking 挂了又要怎么办? 日志分散在各子系统上, 日志收集分析是不是要上 ELK? Kibana 出问题了你知道怎么解决么?

@lvlongxiang199 你跟我说的场景根本就不一样. 我说的是业务系统, 你说的是底层组件. 底层组件本来就各模块相对独立. 业务系统逻辑往往是交织在一起, 宛如一张大网一般. 像我们公司的产品, 使用说明都可以写成一本书了. 基本上改哪块都是牵扯一大片. 所以必然是某个人负责一个功能就一杆子捅到底. 即便是抽象出接口, 也不可能分开写. 你接口实现好了, 别人没实现好呢! 一大堆 throw new NotImplementedException() 怎么搞? 调啥都是 NotImplementedException. 总不能调别人接口的地方都写成 mock 吧? 而且万一是 A 依赖 B 的功能, B 依赖 C 的功能呢? 测都没法测. 只能是等别人把功能做完了你才能动手. 要么就是全你自己搞.

至于单体架构的链路追踪, 你说的问题直接给记录入口参数, 时间, 返回内容, 调用堆栈就足够了. 你都知道调用堆栈了还看不出来问题么? 比如说有些竟态导致的 BUG, 其实模拟一下就能复现. 不行拿脚本跑. 游戏测试怎么做的你就怎么做呗. 游戏的逻辑更复杂, 你说的这种难以复现的问题更多. 你看哪个游戏还整链路追踪的? 搞复杂了兄弟. 哪怕实在不行到处埋点都比你直接上一套链路追踪好. 对于单体的链路追踪本质上就是 AOP. 多少会影响性能的.


"一个服务把其他服务串联起来算是面条代码吗 ?" 必然不是. 微服务中每一个服务都是状态无关的. 一个服务处理过程结束之后可以直接广播动作, 其他服务接收到广播就完成各自相应的动作. 中间没有调用关系, 互相不依赖. 而单体架构下往往是一个函数调另一个函数, 另一个函数再调另一个函数. 上下文一大堆. 所以为啥叫面条代码, 面条不就是挑一筷子一长溜一米多长么, 代码也是. 光调用链就几十层, 那可不跟面条一样!

@BruceFerrari 都玩不了. 原神跟星铁只能云. 绝区零连云都没有.

来，我要玩原神，星穹铁道，绝区零，绝地求生，老头环，糖豆人。。。。。。

在 Mac 上启动一个我看看

@tdb11039gg 对. 像成都那边现在, 活跃网络 (环汇集团), Seismic, Audatex (翱特), 西门子, Intel 等都还在的.

@rick13 这种一般都是在成都、武汉、西安这类的地方。工资相对比较低。你以为这帮外企做慈善呢 2333

目前已知的是有在华业务的大部分都在清场撤离.
有些外企是只有研发团队/客服团队在中国大陆. 在华没有业务. 这种基本不受影响.

@xuanbg 问题是不是说有多难, 而是没必要. 搭建这些没啥难度. 问题是怎么维护, 出了问题怎么解决. 环节越多, 出问题的概率越大. 这也就是为什么如非必要, 微服务是万万不可乱上的根本原因.