开始只是想集中备份所有apple设备上的照片，后来发现windows上各种方式都比较麻烦。事实证明只有icloud才是唯一一种可以持续保持手机备份更新的途径。因为云上贵州的原因，现在下载速度基本不是问题了。

我有四万七千张照片，别问我为啥有那么多照片，手机更新了，但是每次都是恢复以前的一切，但是照片庞大到传统的各种导出很无力，特别是使用了icloud也是。这里icloud一定要用微软商店中的版本，老版本就是有个安装包的那个可以点击下载所有文件，问题是不会自动下载最新的，然后下载还容易中断。最新版本会再本地出现一个icloud挂载文件夹，也是windows10最新支持的，出于备份的目的我需要有的不仅仅是镜像而是真正的下载我的拷贝。可以右击资源管理器中的icloud标识选择“Always keep on this device”，他就会自动下载所有文件。

还好我开始准备这件事，已经发现了数个文件和照片不可恢复！！！

本来应该分开单独写的，太久没写东西懒惰了干脆一次写完吧。

有了nas后一直在试着挖掘它的潜力，这里不得不提zerotier这个东西，完美的解决穿透和跨网的加密问题，实在是家庭nas必备。走的是udp，除了第一次连接略有延迟外速度都不错也很稳定，现在属于self-host基石中最重要的一个了。

nas玩了好多年，现在稳定使用的事赛扬的cpu和六块大硬盘。系统使用的是windows server 2019，为啥没用黑群辉，为啥没用linux。作为母系统来说win绝对是最好的，个人nas经常要解决的就是长期运行、不可间断的，比如百度网盘，长时间跑脚本的数据，这些都要求系统跟pc有很大的兼容，所以应用上win胜出。win server还提供了block级别的重复数据，所以省心的给你节省空间。这块其实专门写个专题都有必要。

好了回到主题的服务上，当然肯定都是泡在linux，宿主在windows下毫无违和感，运行的很棒。首先最重要的服务莫过于文件管理，之所以使用Seafile那是因为他的稳定和高效，请记住，php的东西都很吃资源，所以尽管nextcloud生态很好我也放弃了，如果我是大的cpu可能会考虑吧。稳定第一，nas本来就是比较耗费时间的事情，所以所有服务我都希望一次配置终生享受，或者很简单的维护，seafile配置好后同步非常稳定，很好的默默无闻的在后台工作。效率排到第二是因为cpu是赛扬，属于小功率的u，如果本来十几天的事情能通过效率在一天解决那为什么要花十几天呢。这里不得不提，所有跟php有关的服务都会效率低下，所以如果配置php相关的要留心。这里要说下只要go的服务，目前为止效率都很高！！！比如后面说的photoprism和msysgit。seafile不是go的，内核是c写的，效率就更别说了。

Seafile提供webdav服务，可以很高效的提供给joplin支持，joplin效率不高，但是它的重点在笔记体验和检索上。

最后Photoprism，最惊艳了，说说相比其他相册和文件服务没有的优点吧：

• 最爱：go写的，无处都能感受到异步的存在，就是事情在做，还能给你的操作反馈，不会让你觉得它崩溃了，joplin在导入我的evernote笔记时就崩溃了。
• 不更改现有的文件结构，也不用导入，直接挂在现有的图片库即可。扫描后会在目录中放入一些缩略等数据。对于有洁癖的人来说，还提供导入文件夹的模式，就是会自动将导入文件夹的图片提取出来，也不会动未识别的文件，这一块目前只有看套他这么做了的。
• AI标签，很多相册都陆续支持这个功能了，但是photoprism做的最好，它能在很弱的设备商正常工作，效率还不低。应该是在识别的时候自动调节了识别参数，这个就很注重细节了，同样体验就非常好。
• 在上面的这些原因下，在索引和扫描时你就能实时看到扫描的成果，然后你就很有耐心等下去。充分利用了多核的优势，go的速度真的是非常快，让照片的浏览急速无比。

开始都放弃了，但是每次去拿fm药都很麻烦，于是一查真有个up主做到了。

这里要说一的是如果你是牺牲毁怎么样都过了，如果跟我一样懒得洗天赋那么就要注意了。我是暗毁，跟up主一样，前面up说的很仔细也都很顺利，最后boss却死去活来几次都没过，我才发现，up主抓的那个荒野萨特tmd居然是56的jy，我找遍了一个fb都是55的，哎，这就是命。最后测试猎人萨特发现一次就过了，比up主轻松多了。抓了lr就无所谓技能了，怎么打都能过，最后我的萨特还剩三千六血。。。。[呲牙]，希望对后面刷小鬼的有帮助，食谱有望了

wtform可以非常友好的管理好表单的交互以及服务端验证。最近开始使用postgres，发现也能非常友好的支持enum类型，但是在实际的操作中发现了一个bug。这里我们使用form.populate_obj方法从form中更新字段到obj，使用form.process（obj）方法从obj更新到form。sqlalchemy使用枚举类型定义的字段，form中使用selectfiled或者其子类。

修改了好多回，反反复复跟踪后才明确这个问题，在第一次给form赋值时无错，第一次保存时也无错，bug出在form的存储数据上，就是对field.data的操作。原来在wtform中会判断field.data是否是filed.choices中的值，源代码如下：

file:core.py    
def pre_validate(self, form):
        for v, _ in self.choices:
            if self.data == v:
                break
        else:
            raise ValueError(self.gettext('Not a valid choice'))

self.data有时候是form中选中input的value值，有时候是枚举类型，要修复这个bug就要在所有枚举类型的基础类BaseEnum上改写eq和hash两个内置函数，使得双等“==”操作既能比较字符串，也能比较枚举类型，修改后修复。

之前一直在用gunicorn，这次折腾新项目突发奇想来对比下flask run \gunicorn\uwsgi的性能。不是非常严谨的测试，希望也能有一定的参考意义，结果也很有意思。

gunicorn很火，uwsgi以前用的人多，但是现在少了感觉不怎么听到，这东西是用c写的，带了光环的。flask run这里只是作为基准参考，压力测试工具为ab test,前置了nginx把静态文件剥离了，两者都使用unix domain socket通信隔离了http微乎其微的影响，两者都是用了2process+2thread，压力为100-1000。下面是三种方式的结果：

#基准flask run 100-1000
Server Software:        nginx
Server Hostname:        xxx
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path:          /
Document Length:        6223 bytes
Concurrency Level:      100
Time taken for tests:   7.418 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      6489000 bytes
HTML transferred:       6223000 bytes
Requests per second:    134.81 [#/sec] (mean)
Time per request:       741.790 [ms] (mean)
Time per request:       7.418 [ms] (mean, across all concurrent requests)
Transfer rate:          854.27 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5   47  69.2      6     296
Processing:   231  662 186.7    679    1736
Waiting:      231  662 186.7    679    1736
Total:        241  709 159.6    702    1742
Percentage of the requests served within a certain time (ms)
  50%    702
  66%    735
  75%    788
  80%    821
  90%    881
  95%    958
  98%   1111
  99%   1178
 100%   1742 (longest request)

# uwsgi result
Server Software:        nginx
Server Hostname:        erp.ljmold.cn
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path:          /user/login
Document Length:        6223 bytes
Concurrency Level:      100
Time taken for tests:   9.741 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      6489000 bytes
HTML transferred:       6223000 bytes
Requests per second:    102.66 [#/sec] (mean)
Time per request:       974.096 [ms] (mean)
Time per request:       9.741 [ms] (mean, across all concurrent requests)
Transfer rate:          650.54 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5  130 246.7      9    1750
Processing:     4  533 732.3    437    7584
Waiting:        4  533 732.3    437    7584
Total:          9  664 765.4    473    7742
Percentage of the requests served within a certain time (ms)
  50%    473
  66%    656
  75%    751
  80%    858
  90%   1272
  95%   1719
  98%   2526
  99%   4081
 100%   7742 (longest request)

#gunicorn 100-1000
 Server Software:        nginx
Server Hostname:        erp.ljmold.cn
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /user/login
Document Length:        6223 bytes

Concurrency Level:      100
Time taken for tests:   9.678 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      6489000 bytes
HTML transferred:       6223000 bytes
Requests per second:    103.33 [#/sec] (mean)
Time per request:       967.779 [ms] (mean)
Time per request:       9.678 [ms] (mean, across all concurrent requests)
Transfer rate:          654.79 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        4   82 233.2      6    2275
Processing:     4  584 891.2    306    7272
Waiting:        4  584 891.4    303    7272
Total:         10  667 907.5    389    7278

Percentage of the requests served within a certain time (ms)
  50%    389
  66%    573
  75%    682
  80%    868
  90%   1487
  95%   2506
  98%   3374
  99%   4788
 100%   7278 (longest request)

1. 总共耗时上差的微乎其微，这点差别不能说明什么；
2. 两者都完成了所有请求，这里说一下，之所以选1000就是因为2000两种方式都会崩溃；
3. 平均时间uwsgi胜出，这里差别不明显，但是也说明总体性能上uwsgi做的彻底；
4. 连接时间上，两者明显在1000下都吃力了，但是uwsgi表现更好，除了c我觉得使用uwsgi自己的协议也有关系；
5. 最后也是最重要的，在高并发下，明显uwsgi的表现更好一点，很有意思的是在80%以下的正常流量范围内反倒gunicorn更好，而且效果显著，100ms还是比较可观的，我想这才是大家都用gunicorn的主要原因吧。

最后别人说的总归是片面，还是自己动手对性能有更全面的了解。顺便说一下对flask自带的小服务器刮目相看

没买房的人都亏了。

背景：作为本地人多少都有房子的，所以很长时间里我的观念中就是不要参合买房大战，房奴过的都很艰辛。买房的念头就是从户口问题开始的，孩子过一年就要上小学了，户口于是打算迁到城里，没成想今年开始政策不允许了，因为迁户口用的房子性质有问题，哎，政府的锅为什么要让老百姓买单，气。周围问了一遍，发现不买房上学真的是个问题。

看房：本来我们这是个小县城，随着经济快速发展我也从市中心一次次往外搬，出于对老城区的感情和学区的要求看的都是绣湖区块。正好碰上拆迁潮，新小区没有几个，还都是期房，价格超出预算很多，只能放弃。如果不买老城区心里有受不了住的比现在还远的落差，于是开始看二手房。

二手房：一直知道二手房坑多，看房的时候中介啊朋友啊说了各种故事。好在表哥刚刚买了二手房，可信的咨询就比较多了。作为二手房价格肯定比新房便宜多了，但是比新房多出几个成本：中介费、过户契税、营业增值税、土地出让金（如果是安置房，我买的就是这种）。然后作为二手房也有他的好处，比如学区稳定，不会像期房开始各种承诺，后面各种问题落实不了，甚至有的证件齐全却发不下房产证，本来买房就是为了入学，所以二手房是更好地选择。

中介：二手房避不开中介，哪怕你跟房东认识也必须邀请有执业资格的中介签订第三方契约。中介费就是个头疼的问题了，特别是高价的房子，因为中介费是按照百分比算的，比如义乌最大的中介坐标大概是2%，上海大概1.5左右。200万的房子中介费就是四万了。托表格的福，他花了很多时间找到了私人中介按照固定费算。有的中介带你看房后会要求签署一个协议，这个协议会锁定你半年左右时间，这段时间里哪怕你跟别人交易用的其它中介也要付中介费给协议方，要小心哦。

出让金：这个大多出现在安置房中，我觉的这个挺流氓，集体土地低价变成国有土地后居然还要交钱，无语了。这一项最重要的是用房产证来实际计算，因为变数很大，很多中介会把四五十万的出让金粗算成三十多万，就是为了促成成交。作为大头之一，直接影响到最后总的预算。

契税：这个倒是固定的，项目可能多，但是不会有变数。

营业增值税：这个是为了防止炒房出台的，一般购买时问清楚房东持有的年限就好，大城市这个影响比较大，义乌只限两年，碰到的比较少。

按揭：这是我最大的痛，如果有公积金一定要公积金贷，便宜很多很多，平常看不出来，累积起来能省三分之一。一般都是四大行操作，利率都是国家标准，打听好再去办。现在还会附带保险要求，这个就有点耍流氓，而且跟你卡绑定，逃都逃不掉。

车位：很重要，特别老城区的车库都炒到天价了，这次买的并没有车位，略有遗憾，幸好周围有新建的停车场还能自我安慰下。二手房大多老小区，所以停车一定要计划好，当然好的停车位房价总价自然也是高的。最好能有两个车位，毕竟现在车便宜了。

买房决心的因素：大概位置和学区一般开始就能定下来，预算一看便知。那么最后下决定买哪套我觉得跟心理预期最重要，简单说就是自己满意就好。

• 小区的东南角，采光和视野应该是最好的；
• 中间楼层，太低采光不好和蚊虫多，也不够安静，太高风大，不坐电梯就太可怕了；
• 靠近公园，适合晚饭后散步、孩子们玩耍，近了去的才会多，城里我一直认为公园是最宝贵的，也是这套我最满意的地方；
• 商场在小区的西面，大概几百米吧，正好吵不到，购物也方便；
• 幼儿园在马路对面，可惜这几年不去住，否则午餐回家吃都妥妥的；
• 小学大概1km，走路可及；
• 离市政府不远，主要是考虑保值，涨价就不去想了，也不打算再卖；
• 租赁：原先租户是一个单位，价格高出市场价40%，相当满意，打算多租两年，让财务缓一缓；
• 总价比预期高了一点，这还是在房东砍价后的，可能买房时间不好吧，跟大量拆迁户正面作战；

好久不写文章了，两天弄了个携程的脚本，发现网上大多都是18年以前老版的做法现在已经没有借鉴的意义，于是记录攻略如下，希望能帮助到其它爬虫党。最近出国好多，查找机票价格特别烦，这次又准备买了，正好折腾一下。

网上现有脚本之所以不能执行除了页面改版外还因为携程加入sign签名使得爬取携程的难度大大上升，几乎搜不到可用的脚本，第一次真正写爬虫也希望能贡献给他人做参考。

• 我的需求

对机票得有一个大概的认识，某一天的最低价各大网站都有提供了，所以我们这里比较的是时间段内的最低价，另外比如一周内的机票铁定贵，不太可能去买两个月以上的机票，当然跟这个脚本没关系。给出搜索后携程会推送最低价的机票，那么需求就变成在我计划出行的时间范围内哪一天走最便宜。本来的有网站提供类似时间段的搜索服务，不知道为啥现在没了。

• 控制台分析和XHR回放

在入手前先看看难度，之前已经搜索了好多携程爬取的文章，发现可以用它的api直接取到航班json，控制台翻找后发现batchFlight这个地址就是，并且通过xhr可以回放。这点很重要，不是携程故意的漏洞，因为没登录也可以查机票，所以如果不让回放服务器就有压力了。既然可以回放那么思路就明确了，构建此XHR即可。

• 测试脚本构建

XHR是一个Post请求，参数放在payloads中，啥都不说，先来个测试方法，用python来回放。如果回放成功说明我们需要的元素都在这里了，有洁癖的在这一步就可以试着缩减传送参数只传必要的。

def test_sample_request():
session = requests.session()
session.headers = {"hearders": random.choice(agents)}
base_url = "https://flights.ctrip.com/international/search/api/search/batchSearch"
url = base_url
payload = 'xxx payload json data'
headers['user-agent'] = random.choice(agents)
response = requests.post(url, headers=headers, params=params, data=payload.encode('utf-8'))
print(response.status_code)
print(response.content)



确定sign和transactionid


经过上面的代码可以确定的是sign和transactionid缺一不可。transactionid很快发现就在主页的head标签中，通过bs4可以很容易找出来。


sign的破解


sign就比较麻烦了，通常的做法分为两种，一种是调试js破解sign的算法，需要大量精力明显不适合我，但是效率高，另一种是selenium模拟浏览器请求把sign拿出来。这里其实有点背道而驰，高手在模拟请求时就可以获取到所有数据才对，但是发现目前最新版的chrom对于子请求并不能获取到数据，从75版本开始不再记录response的数据。这里有的同学会考虑在selenium前面架设proxy，我也试了一下，发现等待子请求完成不是一件确定的事，反倒是模拟请求中获取sign基本没有缺失过，那么稳定为先，获取sign后用request获取json更好，把更多的时间用来分析返回的json上。
代码：
下面附上参考文献地址：https://github.com/today4king/daily-scripts/tree/master/flight-tickets

抓包代理：http://oss.theautomatedtester.co.uk/browsermob-proxy-py/
selenium获取所有自请求的数据：https://stackoverflow.com/questions/53286828/how-to-get-browser-network-logs-using-python-selenium
同上，目前chromedriver有bug：https://stackoverflow.com/questions/53049026/selenium-chrome-performance-logs-not-working/56536604
通过注入js脚本的方式获取所有xhr数据，没尝试成功：https://www.quora.com/Is-there-a-way-to-find-out-which-function-triggered-the-AJAX-request-e-g-on-Tumblr-infinite-scrolling
完整的爬虫教程，适合我这种第一次爬的新手：https://www.jianshu.com/p/0391b2d4f590
同上：https://cuiqingcai.com/2599.html
超牛的网站，能把curl命令转为各种语言的脚本，什么？还不懂？这意味着chrome控制台里的任何请求也可以直接翻译为脚本，真是爬虫好帮手啊：https://curl.trillworks.com/

					

brew安装了node，但是发现已经有更新版本的，这个时候不妨使用brew的link命令:

brew link –overwrite node

此命令会覆盖当前的老链接

这个程序自动集成在微软的Windows SDK中，安装vs时自动附带。单独下载地址：https://github.com/blackrosezy/gui-inspect-tool