@necomancer 没错，pandas 第一个搞了 0 出来。你不说我还没注意。

@necomancer
其实感觉这么搞，适用性的确不高。
如果数据内部想标清楚点，用 dict 来记录每一条，写起来更长，的确嵌套起来不大好读。
pandas 在这种地方还是挺好的。

以前都是简单表格直接 prettyTable，感觉 pandas 还是值得深入搞搞。

@necomancer
df = pd.DataFrame(data, columns=['time', 'volume'])
df['volume'] = df['volume'].diff()
df['volume'].fillna(0, inplace=True)
df['volume'] = df['volume'].astype(int)
print(df)

diff 可以应用在单独的 series，就是它不打 0 而是用 nan，还要再转一下。

@necomancer 搜了下，看到 pandas 有个 diff 方法。
[pandas.DataFrame.diff — pandas 0.25.3 documentation]( https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.diff.html)

顺便给一串测试数据好了，里面是排序后的 tuple。
[('2019-12-09 19:40:03', 412), ('2019-12-09 20:10:58', 4136), ('2019-12-09 20:41:00', 6634), ('2019-12-09 21:11:22', 9090), ('2019-12-09 21:41:23', 11636), ('2019-12-09 22:11:27', 14597), ('2019-12-09 22:41:32', 17506), ('2019-12-09 23:11:43', 20315), ('2019-12-09 23:41:44', 22926), ('2019-12-10 00:11:46', 24749), ('2019-12-10 00:41:55', 26133), ('2019-12-10 01:11:58', 27021), ('2019-12-10 01:42:06', 27574), ('2019-12-10 03:08:38', 28333), ('2019-12-10 03:38:48', 28435), ('2019-12-10 04:08:58', 28527), ('2019-12-10 04:39:01', 28608), ('2019-12-10 05:09:23', 28680), ('2019-12-10 05:39:32', 28754), ('2019-12-10 06:09:46', 28841), ('2019-12-10 06:39:51', 29006), ('2019-12-10 07:09:57', 29320), ('2019-12-10 07:40:05', 29755), ('2019-12-10 08:10:51', 30309), ('2019-12-10 08:40:59', 30902), ('2019-12-10 09:11:08', 31454), ('2019-12-10 09:41:21', 31977), ('2019-12-10 10:11:48', 32555), ('2019-12-10 10:42:04', 33137), ('2019-12-10 11:12:30', 33749), ('2019-12-10 11:42:45', 34279), ('2019-12-10 12:12:55', 34964), ('2019-12-10 12:43:05', 35904), ('2019-12-10 13:13:27', 36774), ('2019-12-10 13:43:49', 37375), ('2019-12-10 14:13:56', 37803), ('2019-12-10 14:44:08', 38222), ('2019-12-10 15:14:40', 38589), ('2019-12-10 15:44:51', 38937), ('2019-12-10 16:15:04', 39311), ('2019-12-10 16:45:37', 39707), ('2019-12-10 17:15:53', 40081), ('2019-12-10 17:45:55', 40520), ('2019-12-10 18:16:05', 40991), ('2019-12-10 18:46:48', 41481), ('2019-12-10 19:17:01', 41999), ('2019-12-11 03:23:55', 47926), ('2019-12-11 05:24:01', 48053), ('2019-12-11 07:24:05', 48245), ('2019-12-11 09:24:18', 48742), ('2019-12-11 11:24:28', 49315), ('2019-12-11 13:24:41', 50181), ('2019-12-11 15:24:51', 50767), ('2019-12-11 17:24:52', 51305), ('2019-12-11 19:24:54', 52048), ('2019-12-11 21:25:34', 52911)]

@necomancer 好像是 zip 这步有点问题，py3.7。
TypeError: <lambda>() takes 2 positional arguments but 55 were given
还是 map 的调用方法问题？
我要试试，这两个方法不大用到。

@katoyu 他们之前魔都办公室在八号桥的时候，就在我办公室隔壁。的确名气很大。
但我今天试了试，坐深，坐高，腰托和颈托，这四个点我比较看重。它家颈托不是要靠第三方补丁的嘛？
宜家的马库斯和另一个高背的，背部和脖子 ok，基本正坐也能靠到脖子。但坐深还是浅了点，最低高度又高了点。
打算明天去家具卖场逛看看。

联谊的话这样好像也挺通常的。
50 块平台也不赚啥钱，就算都给平台算个组织费用也还行吧。
对女孩子大方一点，不吃亏的。

我有点介意的是 女士 或 学生，还是 女士 且 学生。

@MonoLogueChi 行，我再看看，好多术语都搞不明白。

@imn1 非常具体且有实际价值，很需要你这样亲历者的体验分享。感谢。

公司名和品牌名可以分开的，不用太介意。
现在折腾半天，到时候工商查重通不过其实没啥意义。
找个差不多能接受的，再去掉常用词换一个同音字，比较好通过。

@MonoLogueChi
硬盘本身应该没问题，因为在另一台电脑上好的。
然后主板也是，去掉一块硬盘，新的硬盘及接口就认了。
所以综合下来看还是电源问题的可能性比较大。

不过因为那几块盘上的数据不大读，访问频度不高。内置的话一直给电给访问权限好像也不是最优。
所以现在有点倾向于外接。

@stille
嗯，目前就是在建项目多盘云同步+部分项目 git。
然后定期手动整理备份，totalcmd 比较后同步。
冷备份一部分是 bitlocker 锁掉，然后离机盘也有。

NAS 我学习了解了一下，感觉几个推荐功能我用不上，或者共享文件夹就解决了。没感觉出 NAS 特别的优势。

硬盘盒不靠谱的话，我主力这台电脑现在不认更多的盘了。
单独那台闲置的电脑老开着当文件服务器又觉得不太有必要。
其实现在主要需求，就是让主力电脑能方便地访问所有硬盘。同时高速啦，稳定啦，减少不必要的能耗啦。就寻求一个较优的方案。

硬盘盒是不稳定还是别的问题？因为之前用奥瑞克之类的产品，的确是感觉不太稳定，多盘的话就感觉更悬了。
但现在可能是为了提高价格还是咋的，产品都设计得很“重”，多盘高端一点的，都直接带系统了，我又感觉不是很有必要。

@ScotGu
看了一下 NAS 的功能，还是不大懂。
访问局域网文件这些，好像直接 windows server 访问共享文件夹也可以。

至于手机 pad 啥的，因为家里一般都是功放出声投影看片，也不大直接用移动设备播放。
功放和投影都直接连到常用的台式机上了。
移动端常用的 vlc 和 good reader 那些，也都能访问局域网文件。

远程访问的需求也不高，常用项目 dropbox 同步，偶尔 teamviewer。

备份的话，也就进行中的项目定期备份。习惯是理清文件夹，然后 totalcmd 比较文件，确认后归档。
想了解下 NAS 的备份原理，等会儿我再看看。

感觉 NAS 更像是一套软件服务？

@netnr 回去试试看，不过我记得是磁盘管理里也看不到盘。

@ScotGu 网线是六类，路由也是千兆，但还是感觉比不过直接插 USB。
正在看硬盘盒，感觉好像这个比较适合我。

@CEBBCAT
如果是供电问题，请问怎么解决？换电源？

网速慢是指内网传输的速度，因为都是视频剪辑的素材之类的，PSD 也是单个文件几百兆那种，拷起来用网线还是慢。

另外，请问 FreeNAS 这类是系统吗？相比直接用 windows，有什么优势吗？

是不是原本它是加了个事件以便于监听。
但我给 history 加了一个非标准名称的新方法，然后导致了一些变化？

@gesse
@cheeto
@codehz

js 小白，不是很懂原理，但想请教新遇到的一个现象。
let _wr = function(type) {
let orig = history[type]
return function() {
let rv = orig.apply(this, arguments),
e = new Event(type)
e.arguments = arguments
window.dispatchEvent(e)
return rv
}
}
history.pushState = _wr('pushState')
window.addEventListener('pushState', function(e) {
console.log(e)
});

先是用上面这个方法实现了监听。

但是后来发现，如果在不同油猴脚本都调用同样的代码，会导致监听重复激活。
于是就把_wr 传入的 type 名后面加了一个 uniqueId，就比如：
history.pushState = _wr('pushState_scriptname')

这样一来，好像在原本 pushState 的地方，页面像被刷新了一样，油猴脚本倒也重新被加载了，监听也就不用加了。

不过不大明白原理，不知道各位高手能不能给说说。