V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lmshl  ›  全部回复第 3 页 / 共 24 页
回复总数  465
1  2  3  4  5  6  7  8  9  10 ... 24  
2023-01-29 18:48:57 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@ximigou007 其实要求不高,如果让我自己招人的话,给我一年时间,我就能带出一只纯 FP 熟练工的团队来。
不需要任何前提条件,不需要清北复交藤校还是 985/211 ,我可以从大专里选拔。
也不需要什么大公司工作履历和手撕 leetcode hard ,有这些背景可能更难带。
就让我自己出题面试,应届生一年熟练 FP 搬砖毫无压力。
2023-01-29 11:33:51 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@house600 举个例子,比如在编写大批量数据导出接口的时候
数据一次性加载到内存中再写入磁盘或者 HTTP Response 都是不合适的,因为数据量可能超过内存总量,这时候就必然要使用流式处理。

1. 这个场景中上游的 Source 是 JDBC connection ,设定 fetchSize 以后每次只会加载这个 batch 到内存中,也就是 Source(connection.selectWithFetchSize(用户列表))
2. 根据业务决定是否需要 filter 或 transform ,是否还需要经过其他第三方微服务接口处理,也就是 Flow.filter(过滤隐藏用户).map(隐藏真实姓名).mapAsync(从其他服务获取用户额外信息)
3. 打包写入磁盘或通过 HTTP Response 发送,甚至还可以插入一些编解码与压缩算法,也就是 Sink.map(toJson).transducer(gzip).toFile(文件名)

整个过程编写下来是声明式编程,而不是传统命令式,同时也具备 Reactive 的基本优点,比如异步+背压,不会导致 OOM 。
2023-01-29 10:44:33 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@house600 随时随地都可以使用,任何可以流式处理的场景都可以用 reactive 来处理。
建议先把 map 、filter 、reduce 用熟练,然后根据你用的语言生态选 RxJS 、akka-stream 、kotlin flow api 、tokio stream 中的任意主流方案。
我在 kotlin compose 桌面项目中就在用 flow api
在 rust 写 cli 的时候就用 tokio stream
在写前端或者浏览器插件的时候就用 rxjs
但我主业是写 Scala 的,所以我对 Scala 生态的 Akka-stream 、fs2 、zio-stream 都比较熟悉,可以随意切换。

基本上你用熟了任何一个 stream 库以后,迁移到其他语言、生态都不会花太大功夫,因为基本语义上大家都是一样的。
找公有云买 Serverless k8s 集群,练的时候创建,练完了直接销毁。
一般管理是按小时收费的,计算资源是按量付费的。
只要你不是搞的规模很大,每小时几块钱,可能跟去网咖打游戏差不多成本。
2023-01-28 16:59:12 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@ximigou007 谢谢捧场。
全球范围内有不少,国内确实很少,Hulu 、TubiTV 有在国内招人,摩根也有不少 Scala 代码,北京也有位清华教授在用纯函数式做一些大数据医疗方面的项目。但总体看下来国内 fp 生存环境挺差的。
2023-01-27 11:46:59 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@wdwwtzy
朋友推荐面过腾讯,薪资没谈拢,加面后定级薪资还是比现在低就没去。
另一个朋友推过字节,一轮游,lc medium 写不出来 + 默写字典树有瑕疵最后挂了。
自己面过几家初创外企全栈,这个倒是薪资有涨。

总之,圈子过于小众也不好,大佬们都在国外,要么我润出去,要么留在国内接受现状。
2023-01-27 11:08:42 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@wdwwtzy 不存在的,该八股文+lc 伺候一项也不会落下
2023-01-26 23:40:18 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@chaleaochexist
@ebony0319
谢谢捧场
2023-01-26 23:39:44 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@fyooo 目前也是主攻口语,在积极看外企机会,之前也拿过另一家外企 offer ,全程英文面试的,和老外尬聊俩小时
2023-01-26 23:38:32 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@NathanInMac 过奖了,最近几年的这份工作离着年薪百万,达成率只有 50%多一点。
2023-01-26 17:01:19 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@unregister 我是几乎不加班的,其他同事按需加班,做业务的同事可能加班挺多的。
2023-01-26 15:57:29 +08:00
回复了 lmshl 创建的主题 求职 10 年资深全栈、架构求职 - 上海
@Hilong 十分不想带团队,就想写一辈子代码,然后不挑语言平台。
我对自己的定位就是软件工程师,而不是特定语言的码农。
2023-01-14 23:19:39 +08:00
回复了 Joker123456789 创建的主题 Java 为什么就是没有人愿意升级到最新的 JDK?
@roundgis 有用过一段时间,后来没再采用,因为要给每个用到的库编写 reflection 和 proxy 表,太费精力了,也不可持续。
后来还撞到了 native image 编译器的 bug ,回退到 20.x 可以编译,升级到 21.x 编译就会异常终止。
2023-01-14 20:20:12 +08:00
回复了 Joker123456789 创建的主题 Java 为什么就是没有人愿意升级到最新的 JDK?
@roundgis
GraalVM 有 G1GC 的
你说的应该是 native-image 当前只能用 serial gc 吧
2023-01-09 12:08:51 +08:00
回复了 Ranni 创建的主题 程序员 JSON 数据中,要将 value 转成特定的值,如何优雅的转换
@Vaspike kotlin 版随手写的,其实不安全,没有错误处理。按照生产级代码规范,应该多加 5 行的 data class 定义,做严格 ser/deser 。
同样的逻辑用 Scala 写会安全很多,Option/Either 签名的方法都是默认实现了,flatMap/getOrElse 过去就好。
2023-01-08 20:06:57 +08:00
回复了 Aaron7Amelia 创建的主题 程序员 对与设计模式始终都没有什么感觉
上大学时候我也曾迷信设计模式,还专门买了几本书学这个。结果每本书都没看过一半
现在工作十年了,对设计模式的需求几乎降到 0 了,反正没什么是现代函数式语言做不到的,硬套设计模式反而让代码变得难以维护。
2023-01-08 15:38:40 +08:00
回复了 Ranni 创建的主题 程序员 JSON 数据中,要将 value 转成特定的值,如何优雅的转换
2023-01-05 16:17:31 +08:00
回复了 MorningStar0 创建的主题 程序员 写了一些在 JS 里实践函数式编程的经验
建议理论部分可以参考《 SICP 》,实战部分多写点 RxJS 之类的。
以及不要讲 Monad ,就像现在这样

再就是拿实际业务举例,怎么用 map/filter/reduce 等替换掉 loop 部分,我觉得就足够了。
https://www.zhihu.com/question/570165038/answer/2784350974
2022-12-30 13:01:12 +08:00
回复了 VeryZero 创建的主题 程序员 Spring Cloud Stream 如何用函数式的方法处理下游返回的消息?
Promise 模式
任务开始时创建 Promise 和标识句柄,收到来自下游的任务结束,根据句柄找到 Promise 并标记为 Resolve/Completed
这样业务里看到 Promise 状态变更时,自动进入 then 逻辑继续后面的处理
2022-12-19 16:24:39 +08:00
回复了 aoxg2019 创建的主题 程序员 数据增量同步检验问题
我觉得业务层还是需要按照业务层的思路去解决,这和基础设施取舍不同。
比如按照做基础设施的思路来搞,那应该每一步都不可以出错,如果出错了就应该停在当前位置无限重试下去,以保证数据最终一致性。
但按照业务思路来做,因为一条数据出错而导致整个系统数据同步停机是不可接受的。

所以必然是以业务行( row )为单位,多次重试后记录错误并跳过,ES 也仅供搜索,业务事务依然由 RDBMS 保证,如此则需要引入就死信队列( DLQ )与纠错机制。

DLQ 能弥补一部分错误,但无法处理某些内部错误被当作正确处理跳过的场景。例如上游有 BUG ,请求账户积分失败时返回了 0 ,虽然锅是上游的,但修数据依然是下游要处理的。

所以还是需要有一种纠错机制来保证数据的最终一致性。我最近在考虑哈希树( merkle tree )不错,它是区块链用于校准的数据结构,可以快速对比不一致的数据块。
https://i.imgur.com/b4ccaPd.png

比如我们可以定时在闲暇对数据库做全量或部份 merkel tree 计算并对比两侧结果,最近数据多算,历史数据少算。这样对比出的不一致结果再通知给开发,找一下是哪里出的问题,以及手工对数据做补偿等等。
1  2  3  4  5  6  7  8  9  10 ... 24  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5479 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 01:35 · PVG 09:35 · LAX 18:35 · JFK 21:35
Developed with CodeLauncher
♥ Do have faith in what you're doing.