vonfry 最近的时间轴更新 vonfry 最近的时间轴更新 | vonfryV2EX 第 367302 号会员，加入于 2018-12-02 16:15:20 +08:00今日活跃度排名 2782 |
vonfry 最近回复了
7 天前 回复了 idblife 创建的主题 宽带症候群 奶昔订阅更新失败是啥情况？ |
五分钟自毁，之前我特意发邮件问过。说是防 ddos
16 天前 回复了 chman 创建的主题 程序员 大家在实现 AI Agent 的时候都用什么框架呢？ |
核心不是框架，是你的业务逻辑如何拆解成逐步执行的逻辑与分发。另外现在大部分框架都是做简单原型还行，但复杂需求都要东改西改，不如手搓方便。
36 天前 回复了 powersee 创建的主题 程序员 自定义 tree-sitter 的 grammar 真难 |
tree sitter 的语法不是基于 generalized LR 做的么？已经比 LR(1) 这种规则宽很多了。
如果觉得难，可能是不太理解 BNF 表达和 FSM 解析流程。可以先拿 yacc 这种写个简单的 parser 开始。或者阅读一下龙书（
如果觉得难，可能是不太理解 BNF 表达和 FSM 解析流程。可以先拿 yacc 这种写个简单的 parser 开始。或者阅读一下龙书（
63 天前 回复了 BigChengzi 创建的主题 Rust 如何看待 Rust？ |
@BigChengzi #44 我的观点是：你没拿 C/C++ 这种写过多线程并发、处理临界资源访问、内存分配管理的经验，直接上手学 rust 过不了编译很正常。但如果有相关经验其实就基本是无门槛了。
所以也是相对的，如果没有类似的需求用不用 rust 差别不会太大。
我个人而言，rust 是主流语言里，即有完善生态、有又较好的语法（糖）、又吸收了各类其它语言的优点（特别是一些函数式设计），写起来其实会很舒服。
不过现在 rust 其实也有一些问题，比如没有 C++ 的原地构造，想要做只能依靠编译器帮你优化，或者拿 unsafe 。
所以也是相对的，如果没有类似的需求用不用 rust 差别不会太大。
我个人而言，rust 是主流语言里，即有完善生态、有又较好的语法（糖）、又吸收了各类其它语言的优点（特别是一些函数式设计），写起来其实会很舒服。
不过现在 rust 其实也有一些问题，比如没有 C++ 的原地构造，想要做只能依靠编译器帮你优化，或者拿 unsafe 。
80 天前 回复了 unbinilium 创建的主题 程序员 记因 API 第一次挨同事骂 |
你有 leader ，也提了前身兼容这种要求。那么你应该和 leader 多沟通，确认技术细节。
另外开会说的东西遗忘还蛮正常的，毕竟那么多内容，一般都主要关心自己的部分。这种会后开工前要对接的，提供沟通会比较合适。
另外开会说的东西遗忘还蛮正常的，毕竟那么多内容，一般都主要关心自己的部分。这种会后开工前要对接的，提供沟通会比较合适。
80 天前 回复了 unbinilium 创建的主题 程序员 记因 API 第一次挨同事骂 |
> 前端页面下一个子组件对应到一个 endpoint ，不再分级，组件全部信息放在一个相同的 JSON schema 里就好
> 根据请求类型，后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段
听起来很像 graphql 的想法，如果要用 json 也有类似的框架。简单来说就是后端不把功能拆得非常细，而是由前端来控制数据的获取，这样其实对迭代会比较简单，后续维护很多需求可能都不用过后端。不过就是初期开发会有点成本，用框架的话会好一点。
> 一年前上司曾批评过我过度设计，效率低
我觉得得看人和项目。对很多企业来说，产品能跑就行，根本不关心内部质量。以技术角度来说我个人认为不可取，企业内，你自己想明白就行。我觉得满足自己最重要，再严重也就是丢份工作而已。
> 他自称写过很多爬虫，也写过前端（他本职做 AI 算法的，211 硕）
> 前端原型里部分组件 anti-pattern 的迹象很明显，一个模块里揉合状态信息、配置信息和控制指令，我倾向做 decomposition 拆到该 endpoint 的子路径里做（我很难接受前端把这种模式通过 API 扩散给后端）
和学历无关，身边统计学。国内前端、AI 出身的大部分不关注代码质量。另外做过什么并不能说明代码能力。何况爬虫这种又是调库为主的；并不是去维护了爬虫库，做了很复杂的反爬，或是有很好的性能调优或者架构。说明不了什么。
> 根据请求类型，后端自动去 request payload 里找需要的字段用或选择性更新 response body 里的部分字段
听起来很像 graphql 的想法，如果要用 json 也有类似的框架。简单来说就是后端不把功能拆得非常细，而是由前端来控制数据的获取，这样其实对迭代会比较简单，后续维护很多需求可能都不用过后端。不过就是初期开发会有点成本，用框架的话会好一点。
> 一年前上司曾批评过我过度设计，效率低
我觉得得看人和项目。对很多企业来说，产品能跑就行，根本不关心内部质量。以技术角度来说我个人认为不可取，企业内，你自己想明白就行。我觉得满足自己最重要，再严重也就是丢份工作而已。
> 他自称写过很多爬虫，也写过前端（他本职做 AI 算法的，211 硕）
> 前端原型里部分组件 anti-pattern 的迹象很明显，一个模块里揉合状态信息、配置信息和控制指令，我倾向做 decomposition 拆到该 endpoint 的子路径里做（我很难接受前端把这种模式通过 API 扩散给后端）
和学历无关，身边统计学。国内前端、AI 出身的大部分不关注代码质量。另外做过什么并不能说明代码能力。何况爬虫这种又是调库为主的；并不是去维护了爬虫库，做了很复杂的反爬，或是有很好的性能调优或者架构。说明不了什么。
Select Language