aristolochic 最近的时间轴更新 aristolochic 最近的时间轴更新 |
aristolochicV2EX 第 503859 号会员，加入于 2020-08-14 21:24:10 +08:00 |
aristolochic 最近回复了
2022-05-14 18:55:38 +08:00 回复了 tolking 创建的主题 › 分享创造 › 写了个 js 玩具来模拟操作符重载，大佬们觉得这个主意怎么样 |
如果不关心 TypeScript 的话，或许可以用 Babel ？
比如说可以在希望支持+的 class 里面写一个[Symbol.for("+")]方法，然后编译时用 Babel 转一下。
当然 TypeScript 也能用，就是编辑时 IDE 支持不太好（大概
比如说可以在希望支持+的 class 里面写一个[Symbol.for("+")]方法，然后编译时用 Babel 转一下。
当然 TypeScript 也能用，就是编辑时 IDE 支持不太好（大概
2022-03-13 15:30:03 +08:00 回复了 darklinden 创建的主题 › 程序员 › PHP 原来是这么神奇的语言吗？ |
所以……就是 https://en.wikipedia.org/wiki/Autovivification ？
应该是 Perl 带起来的概念吧。
应该是 Perl 带起来的概念吧。
2021-11-28 13:23:41 +08:00 回复了 iqoo 创建的主题 › 程序员 › nodejs 有哪些好用的增删改查框架？ |
硬要说的话 Nodejs 或者说 JavaScript 生态感觉就都不怎么擅长干这种元编程的事情，它的宏能力基本全靠社区实现的 acorn / Babel 之类的了。我找了好久都没找到和 Ruby on Rails 生态的 inherited_resources / responders 类似的东西。要说参数自动校验的话，JOI 肯定算一个，还有 Fastify 也鼓励开发者写参数校验（用的是 JSON Schema ），中间件也还算轻量。
至于说数据库执行，我认为都用 JavaScript 了用一个比较正常的 Secure by Default 的 ORM 还是很必要的，没有特殊需要还是别手动生成 SQL 比较好。很久以前我用过 Sequelize ，不过现在的大一统选择或许是 Prisma 吧，尤其 Prisma 基于 Data Mapper 同时还靠 Schema 文件生成 Client 减少样板代码的设计，让受够 Sequelize 用 Active Record 模式的我十分喜欢（我觉得 Active Record 只有 Rails 这样提倡 Fat Model 的才合适，Sequelize 也是但是太丑了）。
至于说数据库执行，我认为都用 JavaScript 了用一个比较正常的 Secure by Default 的 ORM 还是很必要的，没有特殊需要还是别手动生成 SQL 比较好。很久以前我用过 Sequelize ，不过现在的大一统选择或许是 Prisma 吧，尤其 Prisma 基于 Data Mapper 同时还靠 Schema 文件生成 Client 减少样板代码的设计，让受够 Sequelize 用 Active Record 模式的我十分喜欢（我觉得 Active Record 只有 Rails 这样提倡 Fat Model 的才合适，Sequelize 也是但是太丑了）。
2021-11-21 12:31:31 +08:00 回复了 xpyusrs 创建的主题 › Vue.js › 浏览器打印网页的时候, 图片在当前页放不下, 被挤到下面去了, 然后破坏了样式 |
@xpyusrs 那我不觉得你这个提问方式是真心想得到答案的，或许只是想吐槽。
第一轮你只是说浏览器打印有问题，那我只能假定你要用浏览器默认行为 Ctrl+P ；
第二轮你说用插件，还没有提插件的名字和地址，给出了猜测的原因和图片。有些许进步，但是潜在知道答案的人还是无从入手；
RTT 太多了，会让人失去耐心的。
作为参考，我觉得如果在网上提问时一次性给出的信息量，比问你身边的人说的第一句话还要少的话，就该想想是不是提问的姿势不对劲（ x
本来想说最理想的话还得加上最小可复现 demo ，不过目前来说或许要求还是有点高了。
第一轮你只是说浏览器打印有问题，那我只能假定你要用浏览器默认行为 Ctrl+P ；
第二轮你说用插件，还没有提插件的名字和地址，给出了猜测的原因和图片。有些许进步，但是潜在知道答案的人还是无从入手；
RTT 太多了，会让人失去耐心的。
作为参考，我觉得如果在网上提问时一次性给出的信息量，比问你身边的人说的第一句话还要少的话，就该想想是不是提问的姿势不对劲（ x
本来想说最理想的话还得加上最小可复现 demo ，不过目前来说或许要求还是有点高了。
2021-11-20 18:16:09 +08:00 回复了 xpyusrs 创建的主题 › Vue.js › 浏览器打印网页的时候, 图片在当前页放不下, 被挤到下面去了, 然后破坏了样式 |
2021-11-14 21:14:57 +08:00 回复了 foam 创建的主题 › 分享创造 › 给我的图床上传插件（Alfred）加上了压缩功能 |
或许干脆支持 S3 是不是会更好一些呢？毕竟有很多都兼容，七牛也是。这样的话支持一些别的免费对象存储也毫无压力了。
2021-11-05 17:50:58 +08:00 回复了 saviourdog 创建的主题 › 奇思妙想 › 有什么办法判断是否是脚本输入图形验证码登录的 |
@lakehylia 我记得有一个电子论坛就是这么干的，出模电数电题那种
2021-11-05 15:20:24 +08:00 回复了 saviourdog 创建的主题 › 奇思妙想 › 有什么办法判断是否是脚本输入图形验证码登录的 |
社死型生物检测：
1. 在网上收集查寝合影段子，如模仿名画、JOJO 立等
2. 训练人工智能模型
3. 要求用户登录时拍摄指定姿势
4. 希望用户没有健身且与你没有物理接触可能 /用户没有 GAN 相关知识
1. 在网上收集查寝合影段子，如模仿名画、JOJO 立等
2. 训练人工智能模型
3. 要求用户登录时拍摄指定姿势
4. 希望用户没有健身且与你没有物理接触可能 /用户没有 GAN 相关知识
2021-11-05 15:13:50 +08:00 回复了 saviourdog 创建的主题 › 奇思妙想 › 有什么办法判断是否是脚本输入图形验证码登录的 |
武力威慑型客户端 Rate Limit：
1. 做一个 Yubi Key 和 USB Killer 融合怪
2. 加一个持久化计数器
3. 平常是 Yubi Key ，要求用户登录时插上，每登陆一次计数器加一
4. 当计数器超过阈值时切换成 USB Killer
1. 做一个 Yubi Key 和 USB Killer 融合怪
2. 加一个持久化计数器
3. 平常是 Yubi Key ，要求用户登录时插上，每登陆一次计数器加一
4. 当计数器超过阈值时切换成 USB Killer
2021-11-03 13:47:50 +08:00 回复了 nanxiaobei 创建的主题 › React › 20 年前的 React Server Components |
与其认为是回到了 PHP 或者认为和 Rails 生态的 Hotwire 很像的，不如去看看 Phoenix LiveView ，这个才是完全一致。
不管是 Phoenix LiveView 还是 React Server Component 还是微软在搞的一些，都要求通过 WebSocket 实现双向的状态共享，也即客户端的状态要么需要在服务端保存完整的镜像并通过 hash 校验检测一致性（状态和 UI 部件），要么通过 ID 作为更新的凭据。这既不是传统 HTTP 那样是服务端到客户端被动单向传输，也不是 Hotwire 用 WebSocket 实现主动单向传输，PHP 的 Laravel 和 Rails 的 Hotwire 因为不愿意实现高效大规模 WebSocket 连接，才要么轮询（ Laravel ）要么只推数据不维护状态（ Hotwire ）。尤其是 Hotwire ，意境上就是以前的 Stimulus+Turbolink 改名+现代版 iframe ，这套在以前就没火起来（当然 Turbolink/pjax 用的还是不少的），加上 WebSocket 能推数据了也不比以前的玩法更有革命性。
明确声明了自己受到 Phoenix LiveView 启发的有一些，比如可以把 Hotwire 中的 Stimulus 改造成 StimulusReflux （早在把 Stimulus 并入 Hotwire 之前就有了），甚至连 Haskell 都有类似的。
重点还是只靠后端就能在前端实现（稍微）富客户端的应用，如果 All in Live 的话会有问题，比如在 Phoenix LiveView 0.6 之前想要实现回车提交表单（比如做一个即时通信应用的输入框），那么要想自动清空，就需要把输入框中的值也引入前后端共有的状态中，这样用户每敲一个字都会产生一条 WebSocket 消息（当然也做了开箱即用的节流），然后写提交成功后清空这个状态字段的逻辑，要么就得写 JavaScript 钩子。现在倒是能够用后端写 JavaScript 逻辑了，不过还没发布。
不管是 Phoenix LiveView 还是 React Server Component 还是微软在搞的一些，都要求通过 WebSocket 实现双向的状态共享，也即客户端的状态要么需要在服务端保存完整的镜像并通过 hash 校验检测一致性（状态和 UI 部件），要么通过 ID 作为更新的凭据。这既不是传统 HTTP 那样是服务端到客户端被动单向传输，也不是 Hotwire 用 WebSocket 实现主动单向传输，PHP 的 Laravel 和 Rails 的 Hotwire 因为不愿意实现高效大规模 WebSocket 连接，才要么轮询（ Laravel ）要么只推数据不维护状态（ Hotwire ）。尤其是 Hotwire ，意境上就是以前的 Stimulus+Turbolink 改名+现代版 iframe ，这套在以前就没火起来（当然 Turbolink/pjax 用的还是不少的），加上 WebSocket 能推数据了也不比以前的玩法更有革命性。
明确声明了自己受到 Phoenix LiveView 启发的有一些，比如可以把 Hotwire 中的 Stimulus 改造成 StimulusReflux （早在把 Stimulus 并入 Hotwire 之前就有了），甚至连 Haskell 都有类似的。
重点还是只靠后端就能在前端实现（稍微）富客户端的应用，如果 All in Live 的话会有问题，比如在 Phoenix LiveView 0.6 之前想要实现回车提交表单（比如做一个即时通信应用的输入框），那么要想自动清空，就需要把输入框中的值也引入前后端共有的状态中，这样用户每敲一个字都会产生一条 WebSocket 消息（当然也做了开箱即用的节流），然后写提交成功后清空这个状态字段的逻辑，要么就得写 JavaScript 钩子。现在倒是能够用后端写 JavaScript 逻辑了，不过还没发布。
Select Language