你这个“为了”，实际需求只是异地，你只需要将备份盘放到另一个不会同时受灾的地方就足够了

任何云端依据法律要求都会扫内容的，就是说一切取决于对方的良心，这里的“对方”包含法人和不定多数的自然人（临时工）

不是给你建议，而是给孩子建议，让他选

告诉他语言的优点，不用细致，分大类讲述
python, php, powershell...这些属于脚本语言，适合什么场景，例如快速写完执行、改动频繁……等等
C,C++,Go,Java...这些属于编译语言，追求的是运行效率
web 开发又如何……

server/client 的区别，cli/gui/webui 的区别等等
反正不要太功利，不要联系什么语言好找工作、前景大好之类，孩子如果不是神童，离大学毕业进入社会还有 10 年呢，你想想自己十年前选的语言和现在呢？年纪越大越难判断将来的创新点在哪，想想自己有没有埋怨过父母当年为自己选的路

向淘宝学习

其实就是他自己写的东西，自己也没做到

@huxins #2
除了 new window 外，全部都是 off
应该 cookies 也存了，下次进 setting 都是 off ，跟上次设的一样

@inostarling #3
现在最下面是个 "more results"，没有页码

@codehz #1
不知道，扩展好多，很难排查，但显示了 more results ，我觉得是 google 的设置

有 web 基础的话，做界面不难
qt 可以用 qss ，和 css 有 90%相似，web 前端应该上手很快

难在交互
webUI 和传统客户端 GUI 的区别
1. webUI 是一次提交，GUI 看上去也是一次提交，但实际可能每个控件都有交互，例如 单选按钮可能都要做一次小交互
2. qt 交互需要信道，界面控件发送信号（可以理解为参数），后端接收并处理，所以前后端都要懂，一次交互可以简单理解为一个 xhr （当然这样说不严格），qt 的信号槽要学好
1) webUI 是从提交到界面变化顺序执行，没有界面冻结的概念； GUI 则是界面和程序同时执行，如果顺序执行的话，界面会“冻结”不能操作，俗称“卡”，所以还要懂多线程操作，qthread 算是基础
2) webUI 可以全页面刷新，全换掉也行，GUI 一般只是数据刷新，很少换界面结构，如果界面布局全变一般是切换而不是刷新，就是预作多个界面，切换 focus
3) webUI 的“等待”，用户是可以理解的，一般都默认在等网络传送； GUI 的“等待”，用户是不能理解的，他们默认却是“死机”了，所以做长时间的数据处理时，界面要添加“小动作”，例如滚动条或状态栏定时提示，消除用户的不耐烦
3. webUI 事件很少，一般都是点击、下拉； GUI 事件很多，很复杂，例如比较难的有拖放，树控件操作

建议顺序
1.界面控件 widget 和布局 layer ，不用急着弄整齐漂亮，反正可以 qss 完成(各个控件有名字和 class 属性，以后补上就是了)
PS: 初学时，见到名字是 View 结尾或者 Abstract 开头的控件，一律避开，这些属于自定义控件，没有基础就算看文档都会一团乱麻
2.主窗口的关闭、程序的退出（注意在 QT 这是两件事）
3.控件的 connect ，就是发送信号，以及函数怎么接收
4.qthread ，后台线程，先做简单的，例如接收 a ，直接返回 b 就够了，重点是搞清楚进出流程和信号的收发

先做只有一两个 widget 窗口，完成一件事，例如点击按钮在另一个控件显示文字
复杂的界面，就是上述 1/3/4 的组合，当然也有多个 1+一个 3/4
插入、显示图片这些可以先放一放，先学好纯文字，图片这些某角度看，属于媒体文件，qt 需要做一些相关处理
表格、树这些都是复杂的控件，它们之间甚至可以互相引用（混用），因为里面的每个单元格也是一个小型控件，也有相关的点击、选择、按键、拖放……等等，而且数据刷新也复杂（排序之类），整体思路和其他基础控件不同，不要急着搞
qtweb 相关的东西，虽然形式上也是个控件，但实际是个浏览器内核，显示出来倒是简单，但处理其中的网页数据就要另外专门学了，涉及网络、html 分析……
子窗口、新开窗口就更加不用说了，我至今都能避则避，以后有时间再说
界面和数据之间的桥梁 proxy ，我至今没学会

qt 的状态机可以在搞懂布局和信号之后学，初级的状态机不难学，就是预设好一堆参数而已，这东西很好用，有些固定的状态，设好每个状态的参数，扔进去靠它控制；例如，几个单选按钮，引起界面的小变化（不涉及计算，例如颜色变化），就把这些小变化不同的值扔进状态机，各自标记为某个状态，单选按钮用 connect 发信号(状态的标识)给这个状态机让它来换状态就行了

暂时想到这些……

这里有 chm 格式的文档（非官方，但也是用官方文档网页版打包的）
https://github.com/vzhd1701/qt-documentation-chm-autoupdated

我就俩，potplayer 兼容各种格式，特别是老旧视频，lazy-mpv 是杜比视界专用，这个在 potplayer 偏色搞不定

@NoOneNoBody #68
秀逗了，长度 len 可以用这个，但匹配不能用这个，逻辑不对

abcdef vs abdf 结果是 ab
过滤后 abdf vs abdf 结果是 abdf
就不正确了

算了，今天到此为止，脑子都打结了，去娱乐一下

真的很多人乐此不彼地做密码管理
其实这种产品最重要的点是信任

营销要分人，去其他地方怎么说都行，在技术社区，要另外写文案，少点宇宙宣言，“极简主义”用在这里就对了

@blueboyggh #65
我这边测还是自己写的快

把
l = len(s)
前面重新加上
s = ''.join([x for x in s if x in ss])

这个看样子是不能省略的，因为这个逻辑是，原 s 所有和 ss 包含的字符连起来，过滤了不能匹配的字符
意味着最大匹配长度不会超过这个新字符串的长度，而且连续匹配的子串也一定在这个新的字符串内
这样会大幅度降低后面的循环次数 range(l - minlen + 1)

PS: 用这个分别过滤 s 和 ss 后，正则的方式就快了很多了……我这里测试反而正则变成最快的方法

more_itertools 有个有趣的东西

more_itertools.substrings(iterable)

Yield all of the substrings of iterable.

>>> [''.join(s) for s in substrings('more')]
['m', 'o', 'r', 'e', 'mo', 'or', 're', 'mor', 'ore', 'more']

不过也是完全穷举，字符串越长应该效率越低

@blueboyggh #63
就此题来说，@szdosar #49 帖的代码足够好了，你是用这个测出最短时间的吧？
我现在只是翻翻 more_itertools 有没有可用的东西，如果没有，也就不会写出更高效率的了

https://stackoverflow.com/questions/66668405/python-sliding-windows-of-a-list
这里有个关于 moving window （移动窗口）的例子，感觉也差不多

@voxmachina #6
前端我是“老白”，以前学的不是忘了就是过时了，现在能想到的只是去找找有没有油猴脚本

以前的或者可以，那是真的 hide ，css 改改就能显示
现在多数都是 xhr ，提交回复后再返回隐藏内容，除非有自动回复的 bot

呵呵，发现自己有点钻牛角尖了，不追求 yield 和去叠加就没必要再轮询一次，可以少好多行代码

而且 itertools.accumulate 是先生成后比较，概率上无效的肯定更多，比起滑动跳过无效的，工作量更多
嗯，重练一遍

@szdosar #49
滑动思路没有错，只是 window 的尺寸不定，从 min 到 length 都有，离不开每个 window 尺寸轮询
itertools.accumulate 在这里的作用就是自动生成不同 window 尺寸的切片，省了轮询的时间

如果尺寸固定，例如只找连续 4 个字符的匹配，5 个、6 个……都忽略，那用 pandas.series.shift 是对应最简单的思路
可惜 python 没有移动 window 概念，需要手写切片[start:end]

其实 @Pipecraft #12 写的利用正则贪婪匹配的思路是最精彩，虽然实际运行速度不如理想，但我还是忍不住要赞一个

我花了不少时间在这个上面，这个看上去是字符串问题，但实际是队列问题，如果能找到一个非常高效的方法的话，在 pandas 是非常有用的，大数据中快速寻找连续等值的片段用途多得很，所以我才写了个看上去跟字符串无不相干的 pandas 方案

@blueboyggh #48
你是全部用了 #45 的代码吧？
他最后一句是用 next ，这个只返回第一个，改为 list(gg)是全部返回
如果想按长度排序（倒序），用 sorted(gg, key=len, reverse=True)

@blueboyggh #41
不对
1.交换 s/ss 那行缩进多了，但不影响
2.从 sss.reverse()开始到结束，都是在第一个 for 内部的，所以全部需要再增加缩进一层