V2EX › abcbuzhiming 的所有回复 › 第 76 页 / 共 105 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 72 73 74 75 76 77 78 79 80 81 ... 105

❮

❯

2018-06-30 10:36:08 +08:00

回复了 papertiger 创建的主题 › 程序员 › 程序员月薪 1w（只拿 12 个月，没别的钱了，不加班，一周五天，每天 8h）属于什么水平呢？

真心不错的，IT 这行是要算时薪的，实际每天工作小时的薪水，有些月入两三万的一算时薪其实没别你高多少（加班太狠）。年龄越大越发觉得自己的时间极其宝贵，靠加班的高薪越往后越不值得

2018-06-30 10:19:34 +08:00

回复了 xx19941215 创建的主题 › 问与答 › Web 消息中心怎么做

@wuxi317 你这个想法补充，我一直以来没想到怎么弄的问题就是在群发的时候需要插入很多条用户-信息关系记录的问题。你这个解决办法把插入过程延后，并分散到每个客户端登录的时候由他们来做。
但是你这个方法有个弱点，如果这条群发消息是用户在线的时候发的，那用户如果没有退出重新登录行为，就永远收不到这条消息了，所以这个方法似乎有点问题，我建议还是把“ copy 到用户自己的消息表中”这个行为放在客户端轮询时都有新消息的过程中做

2018-06-30 10:10:58 +08:00

回复了 xx19941215 创建的主题 › 问与答 › Web 消息中心怎么做

@misaka19000 它这个场景上 MySQL 还真有些问题，如果它说的几百万用户是真的。那么只要群发 10 次，用户与信息的关系表的记录会达到几千万，群发 100 次的时候这张表的数据会达到几亿这个级别。到这个级别的时候 MySQL 的查询速度也会大大的变慢，即使加了索引改善也不会很大，换别的关系数据库也不会有啥改善的。要么系统设计成按时间分割表，比如每个月（群发特别频繁的时候估计每周都得新建）新建一张用户与信息关系表，查询的时候 union 操作。要么就只有上大数据了。
另外这个场景还可能存在的一个问题就是几百万用的消息到达时间的差别拉的太长，单库群发一次，毕竟要一口气插入几百万条用户与信息关系数据，也是要时间的

2018-06-25 21:59:08 +08:00

回复了 Hstar 创建的主题 › 职场话题 › 今年是不是行情不好, 找工作拿到的 offer 都是 996 的?

降工资需求可破，找不到 965 说白了就是喊价喊高了，最近两年经济收缩你们没感觉吗

2018-06-25 09:43:37 +08:00

回复了 akakidz 创建的主题 › 问与答 › 现在入坑，只考虑发展前途，推荐前端还是后端？

前端入门容易，从发展的角度讲，从来没有什么程序员是老待在一个领域的，你迟早有一天会慢慢进化到前后端都涉及，如果你只停留在一个领域，你必然走不远。但是饭要一口口吃，步子大容易扯到蛋，先从最容易的进去

2018-06-25 09:40:39 +08:00

回复了 we000 创建的主题 › 京东 › 京东 HR 真的是这样的吗？

其实我觉得最奇怪的是，为啥这个京东 HR 能看见这个楼主的内容。这到底是什么渠道的信息，你们的私人信息都是直接公开的吗

2018-06-24 13:33:37 +08:00

回复了 xypcn 创建的主题 › 程序员 › golang 何时干掉 Java

@Monstercat 我 eclipse inteJ，VS 都用过，前两者是不错的 IDE，但是你想和 VS 比？