nikandaoleshenme 最近的时间轴更新 nikandaoleshenme 最近的时间轴更新 |
nikandaoleshenmeV2EX 第 387037 号会员，加入于 2019-02-25 17:13:19 +08:00 |
| 各位大佬们做的都是很（gao）厉（bi）害（ge）的项目么？（一听名字就觉得很厉害的那种） 程序员 • nikandaoleshenme • 2019-07-31 10:28:39 AM • 最后回复来自 sc2yml | 24 |
nikandaoleshenme 最近回复了
@dandelion911
现在是 2%的人拥有 120%的财富，剩下 98%的人负债 20%
现在是 2%的人拥有 120%的财富，剩下 98%的人负债 20%
2020-12-04 10:31:09 +08:00 回复了 rodrick 创建的主题 › JavaScript › 关于 instanceof 的疑问 |
万物皆对象？
2020-12-01 14:17:33 +08:00 回复了 lc1450 创建的主题 › 程序员 › 如何保证单实列服务高可用 |
换个稳定的主机，比如这台 uptime 14:12:31 up 398 days, 3:59，近 400 天，没停机，上面的服务也没有宕机
服务器没有你想的那么重要，当然也没有你想的那么弱不禁风，说故障就故障了
服务器没有你想的那么重要，当然也没有你想的那么弱不禁风，说故障就故障了
初次下载完后，将生成的新文件上传到 OSS，下次碰到相同的请求重定向到 OSS 上去
2020-08-25 13:41:13 +08:00 回复了 jsonfork 创建的主题 › 程序员 › API 日志分析统计什么架构比较好？ |
0，自己动手写一个
1，日志有明确的格式
2，编写一个程序（ shell 、py 、亦或你最拿手的语言 java 、go ），定时读取日志，然后解析格式（解析规则取决于日志格式），入库
3，库可以是 es，甚至 mysql 、 建议文档数据库 mongodb，简单易用，方便后续的聚合查询
4，工作量：一个人全心投入，一个下午即可出一个 简版来
5，注意事项：日志解析需要细心，大文本读取策略，内存溢出，
6，开始行动 或者 pass
1，日志有明确的格式
2，编写一个程序（ shell 、py 、亦或你最拿手的语言 java 、go ），定时读取日志，然后解析格式（解析规则取决于日志格式），入库
3，库可以是 es，甚至 mysql 、 建议文档数据库 mongodb，简单易用，方便后续的聚合查询
4，工作量：一个人全心投入，一个下午即可出一个 简版来
5，注意事项：日志解析需要细心，大文本读取策略，内存溢出，
6，开始行动 或者 pass
2020-08-24 17:02:57 +08:00 回复了 gzk329 创建的主题 › Java › 接口实现类的实例化对象 不可以强转成接口类型嘛？ |
2020-08-11 13:30:56 +08:00 回复了 yazinnnn 创建的主题 › Java › 请教一下并发串行化的情况 |
1，数据接收方决定了服务上限，
2，我也有过与硬件设备通讯的场景，也是带着互联网程序开发的思想去开发硬件，也碰到了这些问题，慢，慢，慢，甚至还得程序主动休眠停顿一下才继续处理，后来想明白了，硬件设备也是微型计算机，它的计算能力只有那么多，出厂就设定好了，
3，后面竟然联想到了人生😂......
2，我也有过与硬件设备通讯的场景，也是带着互联网程序开发的思想去开发硬件，也碰到了这些问题，慢，慢，慢，甚至还得程序主动休眠停顿一下才继续处理，后来想明白了，硬件设备也是微型计算机，它的计算能力只有那么多，出厂就设定好了，
3，后面竟然联想到了人生😂......
2020-08-11 13:17:44 +08:00 回复了 zhdsuperm 创建的主题 › 程序员 › 想请教下大家序列化都用什么库，怎么保存时间格式的？ |
1，序列化方案取决于业务场景，通常的文本数据传输使用 json 格式，不能使用 json 格式的就需要私有协议和自定义序列化规则
2，对于计算机来说，时间只是一个数字，所以存储、传输、计算 时间操作最优解肯定是数字格式，但对于自然人来说就不是了，建议：若程序服务的用户都在一个 行政时区 内，那使用当地时区时间格式无疑是最为方便的，对于程序也是一致的。若不是，使用数字格式最为通用，最终的时间格式展示只需要转换为当地时间即可
2，对于计算机来说，时间只是一个数字，所以存储、传输、计算 时间操作最优解肯定是数字格式，但对于自然人来说就不是了，建议：若程序服务的用户都在一个 行政时区 内，那使用当地时区时间格式无疑是最为方便的，对于程序也是一致的。若不是，使用数字格式最为通用，最终的时间格式展示只需要转换为当地时间即可
2020-02-15 13:33:07 +08:00 回复了 monkeyWie 创建的主题 › GitHub › github 头像服务被墙了吗，看的好难受 |
PS C:\Users\hp> ping github.com
正在 Ping github.com [13.250.177.223] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。
13.250.177.223 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，
PS C:\Users\hp> ping gitee.com
正在 Ping 3074413c.dayugslb.com [180.97.125.228] 具有 32 字节的数据:
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=25ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=26ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43
180.97.125.228 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 24ms，最长 = 26ms，平均 = 24ms
正在 Ping github.com [13.250.177.223] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。
13.250.177.223 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，
PS C:\Users\hp> ping gitee.com
正在 Ping 3074413c.dayugslb.com [180.97.125.228] 具有 32 字节的数据:
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=25ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=26ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43
180.97.125.228 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 24ms，最长 = 26ms，平均 = 24ms
2020-01-21 14:14:39 +08:00 回复了 links123cn 创建的主题 › 酷工作 › 远程还是云 Team--求擅长优化 build 并压缩 js 的前端 |
jq 不香么
Select Language