V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  BeautifulSoap  ›  全部回复第 5 页 / 共 110 页
回复总数  2186
1  2  3  4  5  6  7  8  9  10 ... 110  
@povsister 所以你说这么多,不反倒更加证明问腾出?你因为眼界只局限在国内(你 13L 和 14L 回复里也是一直只说国内),我就提醒你一下 serverless 在国外非但没遭到冷遇反倒在国外应用是越来越多的。你解释再多国内为什么遭到冷遇也改变不了你最开始对 serverless 在国外应用有错误认识这个事情啊。。。。

然后“何况日本 IT 啥水平就不用大家讲了吧”, “serverless 本质上是重前端轻后端快速迭代的路子” 有的自己不熟悉的方面我觉得还是别多发表意见比较好,会更加暴露自己的问题
@povsister 眼界不太够,放宽下视野,不要把视野局限在国内。国外(甚至日本)这几年 serverless 的应用都非常多了。我在的公司很多新项目技术选型的时候,serverless 基本都是和 aws ecs 一个等级的备选项。最终很多项目都是选的 serverless 。光我自己参与的项目,整个项目完全跑在 apigateway+lambda+dynamodb/aurora 的就好几个了,还都是有较大用户数量的项目
lz 应该问还有什么图片浏览器不是绿色的吗?
100 天前
回复了 beiwarm5 创建的主题 Amazon Web Services aws 配置起来真麻烦吧
没经验的个人开发者用毛线的 aws ,它那些功能基本都是面向企业的。等你开始搞公司项目的时候就明白 aws 那些玩意的确挺好用的。能把 aws 用熟了的都可以考证了,aws 的那些证在找工作的时候可是有含金量的哦
@ztm0929 兄弟,我这贴是在谈给 RSSHub 开发源的问题,RSSHub 的源你以为都是凭空长出来的?都是各种开发者自己贡献写的,你作为终端用户当然看不懂我这贴在写什么东西。毕竟终端用户只管用就行了,自然不会去在乎后面开发源的人要受多少苦

@mark2025 所以你到底是怎么把这段话和黑产联系起来的?不好意思你的思维太过跳跃我有点没法理解。能解释下吗
102 天前
回复了 dhuzbb 创建的主题 宽带症候群 局域网内优雅的访问家庭内网服务
这个方案两个比较麻烦点
如果通过 wireguard ,tailscale 之类组网的话

1. dns 是通过局域网 dns 解析的,在家庭局域网外无法正确解析。不如买个域名直接设定域名解析到 192.168.0.8
2. 每次新增服务都要配置 Nginx 反代。

所以我现在都是直接用 ip 加端口,然后搞个简单面板凑活用了,常用服务端口记得住,不常用的从面板进去。
@mark2025 有点搞笑,我头一次听说网络请求帮忙自动处理 cookie ,给个速率控制就能被黑产盯上的
@DIYgods 作者你好,我不太理解网络请求部分的复杂度该如何通过 ci 进行简化。如果可以的话你能提供相关讨论或构想的链接吗?

至于参与项目,说真的我不太确定 RSSHub 到底对项目变化的接受程度到底如何。
我虽然写第三方源(也就是 router )才一天不到,但已经发现了非常多缺失的功能,如经由 RSSHub 接管的网络请求接口,完全自动无感的 cookie 处理,对请求速率之类进行控制的池,cookie 的持久化,数据的持久化之类。这些功能并不是特别复杂的功能,但我不确定我真写了代码后这些改变能否被 RSSHub 接受
@nielinjie 嗯嗯,你说得似乎有点道理,但你说的内容和我这帖子想说的内容似乎并没啥关系。。。。。。看我 7L
@WildCat @amlee

哥们,你们似乎阅读理解的方向错了?我这贴只是来发个牢骚告诉大家给 RSSHub 写源有多坐牢,又不是来质疑 RSSHub 为什么这么火的。
世上火的项目千千万,里面实际代码写成一坨屎的也非常多。每个项目火都有自己的一些原因。莫觉得我就没法理解这种事
markdown 格式

光这一点 lz 你就除了 obsidian 之外没得选的了
那还用问?那肯定是先学 javascript 再学 typescript 。不用抬杠,各位推崇的 typescript 官方文档就明确推荐你要学 ts 先学 js 了

https://www.typescriptlang.org/docs/handbook/intro.html

> If you are coming to TypeScript without a JavaScript background, with the intention of TypeScript being your first language, we recommend you first start reading the documentation on either the Microsoft Learn JavaScript tutorial or read JavaScript at the Mozilla Web Docs.

> 如果你没有 JavaScript 背景,计划将 TypeScript 作为你的第一门编程语言,我们建议你先阅读 Microsoft Learn 或 Mozilla Web Docs 上的 JavaScript 教程。
prettier 的换行是完全强制的无法关闭,要么上面的特定忽视要么忍

如果为了解决问题将 line wide 设置成 99999 ,那么你又会惊喜地发现,所有手动换了行地地方又全都被强制整形成了一行

只能说 prettier 是真的难用。如果可以迁移地话建议迁移到 eslint stylistic
@Pencillll 兄弟,建议重新捋顺一下整个话题逻辑。如果你还无法发现问题所在那我就在这帮你捋一下:

首先再次重申一遍,我已经在一开始就明确地表明了我的观点没有任何隐瞒,我的观点总结起来就
a. js 因为长年历史包袱语言缺陷,导致多年来积年累月的各种写法尾大不掉残类至今,并且为了兼容,语言功能也极多各种机制极其复杂。虽然语言各自有自己风格,但 js 这方面的问题比其他语言严重不知道多少倍
b. js 目前保留的非常多和大量写法功能残留在我眼里都是非常奇奇怪怪的,让人辣眼
综上所述,我认为 js 作为一门语言,对于初学来说初学的心智负担非常大

我这么给你总结后清晰了吗?然后问题回到和我对线的 @shintendo 兄弟,他从头到尾都一直只是在抓着我上面观点中的 b 进行攻(对)击(线)。是的,b 是一个攻击我观点的着力点,关于 b 的对线我是愿意奉陪的,但请问我的观点的核心是依赖 b 吗?我的核心观点依赖的是 a 。
你可以和我大战三百回合,假设最极端的我被说服了撤回了 b ,但这只反过来证明了 a 中我说 JS 的各种庞杂复杂的内容是客观存在的事实。
所以我才一而再再而三地要求亮观点,因为我无法理解,只对我 b 做攻击的人,到底是想从什么角度来驳倒我的观点,
@shintendo 还是那句话,请摆出你的观点。网上聊天反驳别人论据是可以的,但当一个讨论(对线)话题变得逐渐冗长话题原来越散时,一个人连自己观点都不摆出来那么我就觉得完全没有和这种人讨论的必要了。这也是我没有接着回复你反驳我的那个回复。因为我根本看不出来你到底想干嘛,所以对于该怎么继续这个话题也毫无头绪
@shintendo 你有没有发现一个问题,你越是反驳我,越是在证明“初学 JS 的心智负大”这点?我再在这问你一个问题,你反驳我究竟是在反驳什么?
我的观点很简单,JS 长久历史以来,语言本身缺陷,历史包袱,为了兼容,导致形成的各种奇奇怪怪风格和大量的语言功能至今都消解不掉,还必须去学去了解,对初学者造成了心智负担

而你在这反驳却在反驳什么,你反倒一个劲在为这些写法是正常的,没必要取消的做解释。对,这正是我想看到的,你越是卖命解释,就越是证明 JS 里这些奇奇怪怪的写法都是存在在,在你们 JS 程序员眼里这些都是利索当然的。也就越是在证明我上面提出的观点。“初学 JS 的心智负大”

JS 为了前端兼容,所以历史包袱非常沉重,这是前端特性决定的,所以“初学 JS 的心智负大”有问题么?所以我再问你,你在这反驳我到底是在反驳什么
@78786381 来,你倒是说说我给别人扣了什么帽子?
@shintendo

> 初学 JS 的心智负担在于 JS 作为一个 30 来年的语言,而且为了兼容各种浏览器的,几十年前老的写法用法依旧还保留着,而且很多写法你还不能不学,因为很多写法很多人都在用。然后几十年积累下来各种奇奇怪怪的写法,用法,功能,还有各种奇奇怪怪的符号能让初学的人学到头炸

看仔细了么, 我的观点都写得这么清晰了:“ (初 学 JS 的心智负担不在于语言本身缺陷或像 rust 那样设计到多深奥的知识),而在于源于各种历史包袱下大量的约定俗写法用法功能导致的心智负担”
都写的这么清楚了,我之后列举的所有槽点也都是围绕着我的观点进行的,所以我也就没多提 js 本身的缺陷,我这里说的都是初学 JS 的问题。so ,有问题?

的确像上面有人说的换一种语言相当于换了一种写法,不习惯会有压力这是正常的。但任何事都有个度,什么叫“语言改进了,但是我需要看旧代码”?只在旧代码里看到这些我就无所谓了,可是当年 JS 因为历史原因和缺陷,那些旧的写法、知识、用法随着语言改进,这么写的人越来越少了吗?
像我说的 const foo = () => {}; 还有 (function() {})(); 这种经典的为了规避问题的 JS 写法随着 strict 模式出现不用这么写了而绝迹了吗?并没有。现在不一堆人还在写这样的代码,而且可以预见的未来也不会消失。这不是光去看旧代码的问题,而是已经没有大量使用必要了还必须要了解适应当年为了规避问题养成的习惯写法。新的程序员更喜欢 function 等写法,夹杂着用旧写法的人,堪称美丽

再一个 async/awawit 出现后,喜欢 Promise.then().catch() 以及 Promise 里套 Promise 的人消失或者很少见了吗?虽然有时候的确有必要鼓捣 Promise 但很明显 js 程序员里,对 Promise 和 async/await 的选择并不是源于所谓的各自的使用场景

再一个 class ,ES6 里引入之后鼓捣 prototype 实现继承的人数难道消失了?虽然 class 本质是 prototype 套皮,的很明显后来有其他语言经验的人必定更适应 class 的写法,而另一部分人则更喜欢 prototype 。class 的写法和 prototype 两种截然不同的风格今后也会长期永久并存下去。你必须都会写都要了解

再一个 js 常年累月积累的各种语言特性和功能,上一次初学一门语言让我有种记不过来的情况还是 kotlin 。虽然 kotlin 也算得上是大量语法糖构成的语言,但在语言功能的记忆点上和 js 一比也是小巫见大巫

等等等等

这就是我说的,JS 学习上的心智负担
@DOLLOR 说得很好,这就是 js 程序员
1  2  3  4  5  6  7  8  9  10 ... 110  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2803 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 00:29 · PVG 08:29 · LAX 16:29 · JFK 19:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.