首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  libook  ›  全部回复第 1 页 / 共 49 页
回复总数  963
1  2  3  4  5  6  7  8  9  10 ... 49  
一般有物理随机会比较让人信服,比如主持人嘉宾喊滚动和暂停。

总的思路是最好放在内存数据库中,提升读数据的实时性;有条件的话可以先对数据库里的数据做随机排序;如果数据库有游标 Cursor 之类的功能的话,可以创建一个遍历所有数据的游标,前端下令开始滚动就从游标上遍历取数据,喊停就暂停,然后喊继续就再继续;前后端用 WebSocket 通信,比如 Socket.io ,前端与服务器一次连接就可以,持续到抽奖结束;前端以 WebSocket 事件的形式来控制后端,后端实时返回数据。
21 天前
回复了 XCG0000 创建的主题 问与答 大家对骚扰电话有强烈的反感情绪吗?
手机系统自带骚扰拦截,漏网之鱼随手举报+黑名单。现在很少接到骚扰电话了。
21 天前
回复了 Mr0C 创建的主题 宽带症候群 买新的路由器有必要选择 wifi6 吗
这个时间买 WiFi6 有点尴尬,价格、生态都还没到合适的程度。

要是接受 2-3 年换新网络设备的话就先不搞 WiFi6。
21 天前
回复了 vevlins 创建的主题 Node.js nodejs 中最常用可靠的沙箱技术
VM,容器,WebAssembly,自研沙盒。
21 天前
回复了 ubuntugx 创建的主题 Node.js node 模块小问题
不同的模式用不同的解释过程,这个你想了解细节还真得去看 Node 源码。

不过 Node 是要求必须有地方能明确指出你当前文件到底是 ESM 还是 CommonJS,要么是通过文件扩展名,要么通过当前模块目录下的 package.json,目前看来 Node 是无法在同一文件内同时兼容两种模块语法的。
21 天前
回复了 cl903254852 创建的主题 程序员 nodejs 如何做分布式?
做分布式和语言引擎框架关系不大。
一种思路是去状态化,即不需要在服务器上保存会话状态,然后每个请求处理过程 就是一个简单的面向当前请求的处理过程。

分布式服务连接同一个数据库的话,可以使用数据库事务来保障数据操作的一致性。
要是使用微服务思想的话可以把服务按照功能领域拆成若干微服务,每个微服务有独立的服务、集群、数据库,微服务之间通过稳定的 API 互相调用。

你要想了解细节就得提出细节问题,比如需求是什么,遇到的具体问题又是什么,单讲分布式的话是个超大的概念。
技术是用来解决问题的,没有问题没必要硬上,会事倍功半。
微前端确实是从后端微服务思想衍生过来的,但是并不是说一定要和后端微服务一起用,只是个思想借鉴。
B/S 和 C/S 是非常古老的概念了,自从富前端、单页面应用出现之后,B/S 和 C/S 就没有区别了,它是由浏览器端和服务端构成的,但是同时又是按照客户端与服务器端的思路来开发的,将浏览器上的页面与服务器功能进行解耦。

后端微服务解决的问题主要是降低系统复杂度、性能隔离、混合多种技术栈,那么微前端是不是也有相似的问题要解决。

比如一个有 5 年历史的后台管理系统,5 年间功能一直都在增加,最一开始用的是 Angualr 框架的第 1 个版本,但是五年后的今天 Angular 已经出了第 9 个大版本了,功能和设计以及使用方式都发生了翻天覆地的变化,那么摆在你面前的有两个方案,1. 把旧功能全部用最新版 Angular 重写。2. 新功能也用 Angualr 旧版本继续开发。
以及有的时候需觉得两个功能之间并没有啥关系,而有一部分适合用 React,另一半部分更适合用 Vue,以及一些简单的页面适合直接用原生 JS 或 JQuery。

那么第 3 个方案就是用微前端技术,将复杂的前端系统按照对应的领域拆分成不同组件,可以分开开发、设计以及用不同的技术,最后用微前端技术整合成一个网站。
手腕问题,靠轨迹球恢复了,预算不高可以试试罗技 M570,预算充裕可以上 MX ERGO。
同样是手腕问题换了人体工学或分体式键盘,之前用微软的人体工学键盘,后来办公桌子小,就换了 UHK 分体式键盘。
对蓝光屏蔽产品保留怀疑态度,如果感觉不适,请看医生,另外建议将重点放在健康的工作习惯上,比如定时休息一下,之前用了个喝水 App,定时提醒喝水,形成习惯的话也挺不错的。
从小学三年级开始基本上是每天玩 6 小时电脑,作为一个曾经的“熊孩子”想说,“网瘾”只是表面现象,实际上还是得从孩子生活状况上找原因。

之前看过一篇文章讲从事游戏制作行业的家长是如何对待孩子和游戏的,感觉说得非常有道理,感兴趣可以看看 https://zhuanlan.zhihu.com/p/37910229
@Kagari 我的意思并不是说 WiFi6 技术实现上有难度,我的答案也一直都是围绕市场经济供求关系来说的,这是关于市场策略的问题。

会打纸牌的人都知道“俩王带四个二”的问题,核心在于战略资源的利用效率。

设备厂商每年都有 KPI 要完成,假设 2020-2021 年的 KPI 靠 5G 来作为主要市场策略,促使消费者换一批设备,预计可以达到近两年的 KPI 要求,那就没必要引入额外卖点,没准到了 2021 年 5G 市场达到饱和,2022 年销量开始下降,那么 2022-2023 年的 KPI 还可以靠 WiFi6 作为主要卖点来完成。可能技术和成本上厂商完全可以在 2020 年就和 5G 一起推出 WiFi6 特性,但一方面市场需求小、面向 KPI 的而利用率低,另一方面发现两年后没有新卖点来冲销量了,继续做 5G+WiFi6 难以让前两年买了产品的消费者再掏腰包。

一个典型案例就是“牙膏厂”Intel,技术早就成熟了,就是不上市,有计划地、持续地让消费者掏腰包。

我这些也都是预测,未来没有人说得准,要是还是无法理解,可以随时了解一下市场情况。
如果是当地人的话,酒、茶比较有地区特点,可以打听一下当地人比较钟爱的酒、茶种类。
渔具确实太具有专业性了,而且针对不同水域、不同鱼有不同的渔具,要是是在不了解也不要勉强,买错了比较尴尬。
再找些礼盒装的零食饮料,附近买点水果啥的,凑个 4 样以上就差不多了。

关键点还是在于见面,过年的话免不了见其他亲戚,建议提前做做功课。
76 天前
回复了 zivyou 创建的主题 Node.js 动态 require js module
运行肯定是可以运行的,功能也能满足要求,ESLint 规则只是建议,并不一定代表程序一定有问题。

动态 require 的问题可能有:
1. 如果你用 Webpack 等打包工具分析代码依赖的时候,无法妥善处理动态 require 的代码,只能处理静态引用。
2. 如果引用的文件有被替换或篡改的可能性(如上传功能),或如果引用的路径有被篡改的可能性,那么在文件第一次被 require 之前,可能会被攻击,并最终导致运行恶意代码。

暂时想到的只有这么多,如果你的使用场景不具备以上风险的前提条件,就可以用。
如果用户体验对公司运营目标有影响的话,那么 KPI 的制定应该包含用户体验相关指标,如果没包含的话,说明 KPI 的制定有问题。

但假设 KPI 的制定是合理的,此时没有包含用户体验相关指标的话,就说明用户体验对于公司运营目标没有影响。

创业公司的创业阶段绝大多数靠投资吃饭,投资是有烧完的一天的,所以要在投资烧完前达成承诺投资人的各项目标,履行承诺的同时公司可以盈利,或者让投资人看到发展前景愿意继续投资。所以有取舍是必然的。

楼主直接拒绝个人认为是错误的决策,不利于自己和公司的发展,如果可以的话,建议做一些调研,以论据说服 KPI 的制定者考虑用户体验,或者让自己理解当前用户体验确实不重要。
76 天前
回复了 monsterj 创建的主题 问与答 IDEA 这么吃 CPU,上 3600x 还是 3700x
都比 8400 性能高很多,选哪个都行,看你的场景是核心密集还是主频密集的,主频密集的话这两个差不多买便宜的,核心密集的话买核心多的。
76 天前
回复了 Archeb 创建的主题 Chrome Chrome 将淘汰 UA,怎么办?
个人一直都觉得 UA 不可靠,支持使用可靠、安全的方式来检测兼容性,不过浏览器厂商有点不尊重开发者。
@Kagari 5G 基站是国家任务,这个不受市场经济的控制,反而 5G 基站的普及会促进 5G 手机以及相关生态的市场增长。
而 WiFi6 路由器的购买是个人交易行为,遵循市场经济供求关系的原理。

简而言之:运营商建 5G 基站是不在乎花多少钱的,但你买 WiFi6 路由器是在乎的;两者不能一概而论。
WIFI6 还没普及,最近 WIFI6E 就出来了。

网络设备的市场需求主要来源于相应通信技术的终端设备的普及程度,所以得看应用相应技术的手机、电脑、电视等终端设备什么时候成为市场主流。

现在手机厂商的主要精力是完成 5G 任务,5G 预计两年内完成普及,之后才会有精力搞 WIFI6 等其他技术,所以可能 WIFI6 的普及还要等 3-4 年。目前的情况是,华为、小米、Oppo 旗舰机还没有 WIFI6,iphone 仅 11 系有 WIFI6 ;等中端手机标配 WIFI6 的时候,相关网络设备的价格应该就比较便宜了。
Assembly 就是汇编,往往代表直接以机器码形式呈现的程序,你可以想想以往的汇编语言的特点是什么,WebAssembly 是在浏览器端(严格来说是引擎端)的一种具备汇编特点的技术。

举个例子:浏览器上往往只支持 JS、CSS、HTML 三种语言,这些都是以源码的形式由浏览器实时解释运行的语言,浏览器内部实现了这些语言的语法、API 的细节,对计算机底层机器码进行了功能上的封装,特点是人类友好、性能较差;而 WebAssembly 是直接运行机器码,虽然是在 VM 或沙盒上运行的,但开销极低,特点是人类不友好、性能较强。

实际上用 WebAssembly 来做开发也不是直接写 WebAssembly,依靠 LLVM 编译器的强大功能,可以将很多语言的程序编译成 WebAssembly,比如 C/C++、Rust、C#/.Net 、Java、Python、Go,以往 C 语言是直接编译成机器码跑在硬件或操作系统上,WebAssembly 可以让 C 语言编译成 WebAssembly、转化成 WebAssembly VM 或沙盒机器码运行、VM 或沙盒在硬件或操作系统上,由于中间 VM 或沙盒的开销极低,所以可以让程序的性能与直接跑在硬件或操作系统上相近。

既然是 Web 开头的技术,那么还有一个很大的特点就是可以和 JS 互操作。

应用场景基本就是在浏览器端有强性能需求的场景,比如 AI、视频编解码器、图形引擎,或者仅仅是想把桌面软件迁移到浏览器上( AutoDesk 将 AutoCAD 迁移到了浏览器上)。
1  2  3  4  5  6  7  8  9  10 ... 49  
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1121 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 19:33 · PVG 03:33 · LAX 12:33 · JFK 15:33
♥ Do have faith in what you're doing.