一楼总是把答案说了, 后面的人怎么回...

以前觉得硕士没啥用, 后来发现也很有用...

主要还是看你之前背景... 闭着眼推荐没道理

非程序员学 Python 和 JS, 有 C/Java 基础的可以学 go(但是找工作还是前面俩), 跳槽拿来当饭吃的话, 现学有点不靠谱, 非应届生基本不怎么管你语法熟不熟而是问你"都有啥绝活"

同样看了 DDD 才发现自己是个 DD, 以前 OOP 都写的太普通了, 早点读这些书少写不少屎山

只看前言部分已经启发很大, 似乎是那种非强范式但是可以部分参考的思考方式

@Rocketer

声明纯讨论不抬杠

1. JS 亲儿子听过听多次, 之前 Serverless 特别火的一个主题就是帮助很多纯前端无痛变全栈. 这个确实挺香

2. 无状态确实是绝大多数分布式计算的捷径, 很早以前听说有个 Serverless 举例是拿来做 session, 这种算有状态的不, 印象里 lambda 最久留 15 分钟, 一般也足够短效会话用一下, 比如限时聊天室啥的, 有没有想过那种是怎么保证每次请求处理者是同一个实例的, 还是说建立连接以后保持住. 对后端不太熟练, 纯好奇, 似乎有调用时候共享运行时状态或者什么机制

3. 看定价策略, 似乎是一个函数调用完了 return 以后就不再计费, 这时候如果有个多线程后台驻留跑着, 会不会扣费呢, 还是说这个容器直接冻结了 CPU 不让分配给这个进程? 之前只见到每个实例启动以后最久保留 5 ~ 15 分钟, 这段时间会不会有没关彻底导致的额外计费呢

@ch2

之前调研并上线了 Lambda 的代码, 怎么跟你说的不大一样, 还是 lambda 比较特殊么. 纯讨论, 不是挑刺哈, 实在对这个领域特别感兴趣, 想多了解一些以后看有没有机会 all-in

1. go 看起来确实香, 但是作为 FaaS 想导入 function handler 时候也并不方便, 还要导入 lambda 库写 handler, 但实际体验在我这边不如可以"依赖代码隔离"以及指定某个函数名字(不用具体写入口函数) https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html

2. 前面提到依赖代码隔离, Python 那边可以放比较重的不常变的依赖(一般把依赖也打包到 zip 代码里有些浪费) 到 Layer 里面导入就行了, Java 也是可以的, 所以依赖锁到 Layer 上面, 具体代码实际就一点点, 上传流量很小, 对 go 来说上传整个编译程序反而会大了一些, 而且解释型语言调试阶段(没自动上线)在后台直接改代码就发布运行了...

3. 现在 lambda 貌似支持直接部署一个 Docker 了, 不过底层本质是不是 Docker 我不确定, 没注意到

4. JVM 看起来确实冷启动不友好, 不过据说做了各种优化, 以及预热实例相关能满足, 所以之前看到的结论是 Java 在 Serverless 领域其实并不稀少(美团那边也发了博客说 Java 实践), 冷启动以后的 Java 调用速度还是很可观的, 毕竟编译了的

5. 有关内存数据库 Redis 做持久化或者有状态这方面, 之前也是这么想来着, 不过当时看了提到需要 VPS 凑内网, 这个似乎会导致成本上升, 如果走外网, 流量又会很高, 白名单的话 IP 不固定, 所以最后不得不妥协改造成了事件驱动的. 用 Redis 有什么建议解决上面提到的问题么

6. 提到 Serverless 数据库, 以前只听说过具体不太了解, 那个 CAP 放弃的是 P 么, 这个主要卖点是快还是便宜啊? 产品化遥遥无期那还是不期待了...

不太复杂的小项目 git flow 感觉有点复杂, Github flow 就够用了

rebase 吧, 你的基被人往前推了, 那就变基到跟线上一致提个 PR, 主线分支光溜溜一根挺好的.

之前买了云鲸 1, 随便说一下(给老人家买的, 没见过几次)

1. 扫地模式风还挺大, 灰尘如果多的话, 那个风有可能会扬尘, 跟平时用吸尘器吹的到处是有点像, 平日基本不用扫地模式...
2. 拖地模式重油污得自己搞定, 但是擦灰尘和猫毛啥的貌似确实有用, 单拖就够了

自如保洁用的刮玻璃那种感觉挺神奇的, 先用绒布那种擦一遍, 然后一刮挺干净. 总体来说, 对机器人期待不要太高

我妈以 100% 的态度告诉我, TX 是国企... 查了下, 似乎真有这个说法, 难怪她那么羡慕邻居孩子在里面上班

有些事情道理其实都是明摆着的, 那一位本身也曾是厉害的开发者, 不是不明白, 是不得不糊涂, 毕竟: 程序员要求的是高内聚, 资本下的命令是紧耦合

同 9 楼

load average 貌似和你任务对系统 CPU 的需求, 不是实际使用情况, 堵的越惨这东西越高. 而容器外面限制资源使用, 该堵的是不是还在那等着

看个人情况, 经常熬夜的人如果有频繁心悸之类的感觉, 趁早就医

至于我自己, 昨天期待了很久的游戏终于发售, 一开始心脏也碰碰小激动, 到家下载一玩, 一路闪退差点给我心脏骤停

只能举个例子, 我一朋友(真不是我...), 985 在制造业国企待两年, 然后裸辞在家学半年日语过了 2 级, 猎头介绍直接进 2 线 500 强日企, 现在被周围的混子恶心的难受. 不过他当时才 24 不算年纪大

总结起来就是现在二线以下城市的部分日企要求比较低, 重视语种大于能力, 可以考虑一下, 至于英语不一定好使, 现在普及率这么高如果仅仅日常交流读写, 不说有嘴就会也不太容易产生竞争差异

话说咱这行业不是越老越妖么, 为啥会被卷

省流一句话:
self.xxx 从对象作用于里找 xxx 属性 /方法, 没找到, 去类作用域里面找, 找到了; self.xxx 赋值以后, 从对象作用域里找到了, 就不去类作用域找了

如果是个稍微正经点的方式, 肯定是 systemd

所以我选 tmux

之前被推荐看 时间旅行者的妻子

然后对时空穿越类型的电影一发不可收拾, 珍藏的片单找不到了, 感兴趣可以搜知乎之类的 "类似蝴蝶效应的电影" 吧

在屎山里自由泳, 每次换气都要了小命. 准备找个清水池子了

现代项目管理经验里对时间观念的严格要求是吃过很多很多年亏总结出来的, 纯粹开发日志的话不是一码事就别用同样的工具了, 随便找个文档或者笔记就够了, 或者 commit 记录合并起来打 tag. Github 上的一个个 milestone 或者 product 都是为了避免一些事情无限期延长下去, 导致投入产出不成比例盲目努力

比如 scrum 里提到的一个个 sprint, 如果不定一个个小冲刺, 长时间没有正反馈没有小成果, 人会疲的

最近在关注领域驱动的玩意, 不确定会不会解决 /避免标题里的问题

就之前的经验来说, 如果是很专业的开发团队, 这种问题就不会提出来; 如果连需求都不明确的团队情况, 搞好自己的事情吧, 规范或者优化改进在大领导眼里都是无法产生利润的额外工作量. 不管专业不专业, 一切以文档为准, 轻易修改不光违反开闭原则, 还可能导致从上到下信息不对称, 徒增烦恼

说的有点像读取百万小碎文件时候的瓶颈如何解决的事情, 联想到现公司被一句 cat /xxxxx/xxxxxxxxx/**/* |gzip -d 处理二十万碎文件整的真叫死去活来了

多进程把 n 个核心都用上(而不是每个文件开一个进程, 那切换开销大到吓人)有点用, 多线程流式读文件应该也有点用毕竟从磁盘读入内存 IO 瓶颈也挺大. 脑子里蹦出 HDF5 / mmap / 零拷贝 啥的, 但是想不起来有没有关系

@skysuhey 这不欺负老实人么... 算了