@TestSmirk Google Arts

https://www.google.com/culturalinstitute/beta/asset/-QGe7_PTCnhjEA

@param 嗯也是种思路。不过缺点是图片作为字符串操作太大了，加密和解密太耗费计算资源（想象一下用户每请求一次，服务器就要对几 M 数据进行加密算法，当然也可以一次性加密好，但是这样存储加密后的数据也是成本），相比于对 4、5 张图片的位置数据进行加密要轻松多了。可以轻松做到每次访问都随机加密。

推荐用 Google 的…… Analytics

代码混淆，比如 facebook 这样

https://ws1.sinaimg.cn/large/97427833gy1fnafrv5iv3j21bs0zqaqo.jpg

如果是图片，在服务器端用某种算法拆开切图，然后在客户端拼起来

https://ws1.sinaimg.cn/large/97427833gy1fnaftfjn3dj21yc0zchdu.jpg

卧槽 已经发布了吗？为什么去亚马逊他们老给我看狗的照片？

https://ws1.sinaimg.cn/large/97427833gy1fn984c4gocj224m1aoati.jpg

https://github.com/tony/tmuxp

原生的 send-keys 写起来太难读了

你需要 https://www.omnigroup.com/more

github 不是支持跳转的嘛？ 我记得打开一个旧的项目给跳转到新的了

1. 天猫买 100T 硬盘
2. 寄到阿里云，开工单让阿里云拷到硬盘里寄回
3. 将数据拷贝到自建机房
4. 天猫申请 7 天无理由退货

（可耻，匿了）

ps4 + 21

@vwxyzjn 我知道你说的这种情况，但是真的我自己没遇到过…… 一般的包都会努力去兼容最新的依赖。

像你说的这个例子，我觉得根源不在包管理器上，而在设计的软件向后兼容上。这个问题不像是包管理器能解决的吧。就像 a.py 用的 python2 ； b.py 用的 python3，想要在一个程序 import a, b 怎么可能呢？

@vwxyzjn 用到了什么外部依赖就写什么呀，自己依赖的什么必须要清楚啊，总不能稀里糊涂把当前的环境的依赖都生成进去吧。既然是小型项目，那还要有多少外部依赖？

怎么可能漏？

基本不会冲突（我没遇到过），因为大家一般都是规定最低版本。如果真有两个包最高版本冲突，那说明其中有一个包太久不更新或者本身就存在问题，具体解决吧。

@vwxyzjn

> 其中提到很有意思的一个事情，也就是 python 不允许一个 library 存在两个版本。但假如说你有两个包，包 A 依赖包 [email protected]，包 B 依赖包 [email protected]。你用 pip 装完 A 和 B，你会发现包 C 是版本 1.1 *或者* 1.2 （看你安装的顺序）。

发生这种事情本来就是不科学的，不过我还没遇到过。好像 pipenv 在解决这个问题。

我还是坚持我的观点，如果用 requirements.txt 写依赖的话，应该是人工维护，可读，不写依赖的依赖。比如这个：

https://github.com/getsentry/sentry/blob/master/requirements-base.txt

@vwxyzjn

> 实在不知道您是如何得出这个结论的。依赖是 nested 的。也就是有依赖的依赖的依赖。你不用软件来记录这些 nested dependencies，最后的结果就是 inderterministic build.

你说的软件记录指的是 `pip freeze > requirements.txt` 吗？ 这样的确可以将所有包的版本准确导出。但是并不是推荐的做法。加入你只依赖了 requests，自动导出会将 requests 依赖的库（当前 pip 所有的依赖）都导出。你自己看到这个文件，都不知道哪些是项目依赖的，哪些是 requests 依赖的了。

我的观点是，Python 的 requirements.txt 应该是可读的。如果你的项目依赖了除标准库的 requests，那么就在文件里面写 requrests （指定最小版本或者不指定），requests 的依赖交给 requests 去搞定。这样不好吗？

@ivanlw 觉得高中或者大学里面学的东西都是渣，走上社会一点用都没有 +1

我王境泽在这里立一个 flag，我今天觉得大学学的东西一点用都没有，还要一辈子都觉得大学学的东西一点用都没有。

Python 的打包确实是比较复杂，你可以看看这个 template： https://github.com/kennethreitz/setup.py

但是你后面的结论就不对了：

> 配置文件居然是用 txt 文件来写的

不知道什么意思……文件要么二进制文件要么文本文件，txt 是什么？

> 二进制文件我用编辑器是无法打开的

这是你编辑器的问题。况且你为什么要用编辑器打开二进制文件？你期望看到什么？

> 然后用 git 也不能很好的版本管理

我假设你说的是管理依赖？一般写到 requirements.txt 里面，手动写更容易控制版本和依赖。

> pip install 是把包全都装在了全局

用 virtualenv，python 的环境可以非常干净的

> 打开用户目录，一大堆以点开头的文件夹

你说的点开头的文件是什么？就算装到系统里面，也是在 site-package 里面。

------

最后多说一句，少抱怨，多去 Stack Overflow 找找解决方案。我向你保证 Python 的依赖可以处理地很干净的。比起 JavaScript 来坑少很多了。

贴点资料： https://www.kawabangga.com/how-to-learn-python

@tylerdurden 是的已经解决了，证书没问题了。

curl -Iv https://t.tt
* Rebuilt URL to: https://t.tt/
* Trying 140.143.179.117...
* TCP_NODELAY set
* Connected to t.tt (140.143.179.117) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=CN; ST=BeiJing; L=BeiJing; O=Smartisan Technology Co.,LTD.; OU=IT Dept; CN=www.t.tt
* start date: Aug 24 00:00:00 2016 GMT
* expire date: Aug 24 23:59:59 2019 GMT
* subjectAltName: host "t.tt" matched cert's "t.tt"
* issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SSL CA - G3
* SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: t.tt
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Date: Wed, 03 Jan 2018 06:21:01 GMT
Date: Wed, 03 Jan 2018 06:21:01 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 178
Content-Length: 178
< Connection: keep-alive
Connection: keep-alive
< Location: https://www.smartisan.com
Location: https://www.smartisan.com
< Server: ARTWS/1.0
Server: ARTWS/1.0
< X-XSS-Protection: 1;mode=block
X-XSS-Protection: 1;mode=block

<
* Connection #0 to host t.tt left intact

@wwqgtxx cdn 也可以关闭 443 吧。我觉得“关闭来自 t.tt 的 443 ”比“把来自 t.tt 的 443 的请求转发到 www.smartisan.com 的 443 ”更合适一些吧？ 虽然两者都是错误……