V2EX › kkfnui 的所有回复 › 第 5 页 / 共 8 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8

❮

❯

2018-01-07 11:23:46 +08:00

回复了 lcj2class 创建的主题 › 程序员 › 后端程序员们，你们写自己的项目时，前端用的是什么技术？

同楼主。
以前自己写，费劲，不好看了，交互还不好。

用现成，学习成本也不高，不深入的那种，但是效果好。

以后写个功能再也不用自己去操作数据库了，封装个接口，拼一个页面，由运营和编辑去操作吧……

2018-01-07 11:15:11 +08:00

回复了 kkfnui 创建的主题 › Go 编程语言 › golang 数据库配置管理

可以用懒加载的方式，解决显式初始化的问题

2018-01-04 17:05:17 +08:00

回复了 kkfnui 创建的主题 › 全球工单系统 › [钉钉] 没有任何操作，自己莫名其妙的 “被加入”一个公司

还有个笑话
刚才打电话给客服

客服：先生你好，请问你贵姓
我：可以根据我的手机号码查到
客服：这是你的个人隐私信息
我：就一个手机号码，就可以被拉倒其他公司，**还有啥隐私可言**

2018-01-04 16:49:40 +08:00

回复了 kkfnui 创建的主题 › 全球工单系统 › [钉钉] 没有任何操作，自己莫名其妙的 “被加入”一个公司

@sea516

韩国：屈原你是韩国人
屈原： …………

2017-12-26 14:14:17 +08:00

回复了 ch3nOr 创建的主题 › 求职 › 坐标深圳，求个 Python 坑

做过什么项目？

2017-12-25 10:43:03 +08:00

回复了 kkfnui 创建的主题 › 问与答 › 定时任务监控轮子？

@fjkfwz406
@mpich

看了下确实大部分都能够满足，但是对于运行时间过长的任务，希望能够报警(但是不杀死任务)，应该怎么做？
没有看到类似 trigger

2017-12-22 15:44:52 +08:00

回复了 kkfnui 创建的主题 › 问与答 › 定时任务监控轮子？

@Livid 语言不仅仅是 python，我先了解下

2017-12-22 15:35:03 +08:00

回复了 kkfnui 创建的主题 › 问与答 › 定时任务监控轮子？

@mpich 我看看，学习学习

2017-12-22 15:12:38 +08:00

回复了 kkfnui 创建的主题 › 问与答 › 定时任务监控轮子？

第二种，可能还想夹带私货。
在 job 运行完成后，附带上报该 job 的一些附带属性。

- 更新了多少条 mysql 记录
- 耗时多少

2017-12-17 21:19:36 +08:00

回复了 oldcai 创建的主题 › 问与答 › 犹豫了 25 天，终于鼓起勇气，敲开隔壁的们，告诉了她

被标题吸引过来的

2017-12-14 13:32:34 +08:00

回复了 johncang 创建的主题 › 问与答 › 玩客云是假盘吧，挂大半天只有用 30m 流量

@hnbcinfo

星域 CDN 技术上难度很大，相反阿里云这样的 CDN 会更容易做些，服务质量更容易得到保障。
如果只是单纯的将玩客云看成 CDN，那么他的竞争力其实还是不如阿里云的。

目前星域 CDN 应该还是赔本卖吆喝的阶段。如果星域 CDN 的技术能够完善好，那么竞争力可以提升上来。不过迅雷做星域 CDN 也有 4、5 年了，技术的提升空间应该不大。
后面，主要还是看产品如何转型吧~

2017-12-14 13:18:48 +08:00

回复了 kkfnui 创建的主题 › 问与答 › Python 缓存库， LRU, max, timeout

@mooncakejs 恩，还是自己写了一个。

2017-12-14 13:18:26 +08:00

回复了 kkfnui 创建的主题 › 问与答 › Python 缓存库， LRU, max, timeout

@Kilerd 这个不支持 timeout 吧

2017-12-14 13:17:47 +08:00

回复了 kkfnui 创建的主题 › 问与答 › Python 缓存库， LRU, max, timeout

@billion
异步模型成本更高

1. 需要修改现在业务逻辑，时间成本高
2. 复杂度、心智负担都会提高

不是万不得已，一般的业务逻辑还是不要采用异步模型

2017-12-14 10:35:51 +08:00

回复了 kkfnui 创建的主题 › 问与答 › Python 缓存库， LRU, max, timeout

@cabing 多谢。

业务逻辑决定了要多次访问 redis。
redis 现在内存量级对应我们的硬件来说是比较大的，慢查询也会出现十几毫秒的情况。

现在是短平快的解决思路