关键词是一个大文件.
日志默认应该是在时间上连续的,所以无论文件有多大,当前应该只处理 60 秒的数据.不应该有切割文件的操作.
如果是判断自然分钟,就是从 0 开始读取,读取到下一个分钟结算一下当前分钟的数据,给出达标结果,再继续处理下一个分钟的数据.
如果是连续 60 秒的话,这个还挺麻烦的,因为 24 小时的不同窗口从 1440 个一下子变成了 86400 个了,会麻烦不少.

以相亲为目的的相亲产品没什么看头.不愿意.

@ihciah 这是新手的问题吗?
问问题不能出现最基本的谬误,关公战秦琼就算了,问秦叔宝和青龙偃月刀谁厉害就不合适了吧,这是对所有能看到问题的人的不尊重.

jvm+java=go
jvm+java+docker = go+docker

主流 3a 之类的.

4k 游戏压力太大了吧?1066 肯定不行.

基本都有吧
https://www.vultr.com/promo/windows-vps-hosting

就说你外包吧
从前是登录客户提供的机器自己配置环境,装依赖,跑项目,写 crontab,可能还有别的.
这还是好的,起码让你连服务器.
不让你连的话,你就得教别人用,当然不排除沟通很顺畅的情况,但是大部分是....你懂得

如果用 docker 的话,在已经部署了 docker 的机器上会方便很多,可能能做到 git clone&docker-compose up 直接跑起来,哪怕对方是 Windows 系统.

我觉得这就算是对个人开发者比较大的意义了.

估计低级 bug 出现的概率无限接近于 0 吧，还没到五年，但是现在已经基本不会出了。
方法就是拿出一半时间写单元测试。

怎么就我觉得这注释合并进去也没什么问题吗

主页文章标题的字体也太大了吧...

我这里是验证指纹,感觉还 ok 的,为什么你是密码...

JAVA 系的东西是很吃内存呀

@alexmy 谷歌家的地址是白名单模式,只有个别的给你放出来,其他通杀呗

*下面 => 文件

我问一下,是不是这样

1.**前端**根据接口数据生成 EXCEL
2.上传到服务器,服务器返回下载地址
3.前端调用下载

如果是这样的话,那我估计真的是不会,这个设计问题很大.

第一次做类似需求之前,我也以为前端不能直接生成下面保存到本地,实际上是可以的.所以我现在设计的报表下载只有两个方向

- 前端直接根据开放接口请求数据,自己塞到表里,保存到本地.
- 前端发送过滤条件,后端直接在内存里生成 EXCEL 之后不保存直接返回.这个对资源的消耗比较不可控,所以在筛选条件上往往做一下限制,避免运营大神一次下全表.

其他的办法也有,但是我司业务体量目前不需要专门跑个 worker 去异步处理,所以就这两种就行了.
但是无论如何万万不会有前端生成再上传下达一次的设计.

因为 vscode remote,我昨天把台式机 N 年的 win7 升级了.顺畅的体验让我对工作笔记本选 linux 这个行为,产生了怀疑.
我认真想了一想,如果开发环境能在 wsl 里隔离出来,用 Windows 真的比 linux 强不少.

Office 365 个人版
¥398.00/年