同事在公司服务器里搭建了一个服务，我们可以用浏览器图形界面来执行一些原来只能命令行（打印无数无用信息）来做的事情。该服务器必须通过登陆专门服务器后ssh到。同事能通过端口映射来把http请求通过ssh通道实现。我看了也想试一下。然而同事的是mac电脑，我的是windows，他的设置不能copy。所以我就股沟着想办法。一般这样的功能，两个平台都有方案的。
然而我上班花了不少时间试没成功，还带电脑回家研究，有两天一直到很晚不睡还不成功，没解决就上床睡觉的感觉挺绝望的。（我日记里写，甚至有那时拔牙前的绝望情绪。我这么敏感情绪化，真不像一个技术人员。）上周有一天早上，忽然想试一种方案，结果成功了。
回想一下，基本上是这么个流程：
- 我有一个本地服务也是通过端口映射实现的，我仿造它的配置设置了一下，没成功。股沟：怎么设置端口映射
- 按照好几篇设置来看，我的设置并没有问题。股沟：怎么看putty的log；
- 搞了半天putty的log，发现那个log的功能是把屏幕output同时存到log里；
- 仔细揣摩之前一篇设置的文章里说log的意思。摸来摸去摸到了putty的event log；
- 对比成功的端口映射和不成功的端口映射的log，发现不成功的那个并没有port forwarding to XXX:YY的log；
- 傻眼了，叫我再看什么啊
- 求助那个同事。他看了以后，也一下子不知道怎么搞。
- 晚上心事重重，回家后洗澡的时候忽然想到，我本地并没有处理浏览器请求的服务啊！另外一个利用端口映射的是java程序访问的，我完全不知道它怎么访问的。估计就算看了代码也不懂吧。那个同事可以说是full stack开发，肯定在本地装了Apache之类的，完全不会想到要提醒我们这些后端装Apache；
- 本来想早点去公司研究的，结果没睡好还是准时上班。路上想起来windows server可以用IIS。股沟了windows 10上如何打开IIS服务；
- 打开IIS服务，IE浏览器可以显示local host但Chrome不能。重启windows后Chrome也可以打开IIS的localhost页面。至今不知为何。然而！访问映射的端口还是不成功！！！
- 看到putty有“forwarding to XXX:YY”的log了，但是过一会儿会返回一个connection refused / time out；
- 股沟：怎样看端口有没有开放。（很多命令是我没权限执行的，但能执行的看来没问题）；
- 股沟：怎样模拟TCP/IP请求——用wget——试了一下不行。中间服务器和目标服务器似乎只能ssh，别的链接方式都会失败；
- 之前股沟出的一个结果是，scp也可以用端口映射来通过ssh通道直接访问bastion服务器背后的真正的服务器。所以我又花了一点时间试了试以保证我设置并没有太大问题。结果成功了。。鬼知道为什么另一个不可以；
- 思来想去，寝食难安（。）。感觉我还有一个可能性没试过，但我没抱什么希望。那个可能性是multi hop。跳一下不成功，跳多下不是失败的几率更大吗。。。
- 可能目标server只能ssh访问。我试了从开发server可以ssh到目标server。
- 出于死马当活马医的心理试了multi hop。没想到——成功了。最终的姿态是：local -> bastion -> dev server -> target server。local设置了到dev server的通道，dev server设置了某个端口映射到目标server的通道。关键好像是mac下的proxycommand的功能，windows没有；还有我dev server可以设置无密码ssh链接到目标server。
我想起来前一阵听的Talk Python to Me的一集Geeking out in the golden years，嘉宾Phillip Guo收集了一个60岁以上的学代码的人的问卷。主持人和他在聊这问卷里发现的一些东西。说到老年人学代码自己觉得的一些困难。其中一项困难是遇到error没有解决问题的能力。主持人说，这个问题不仅是老年人会遇到的啊。下面是他的原话（原来这podcast还有transcription）：
00:25:29 Michael Kennedy: You know, I find, I interact with people and I’m not sure if this is an age thing or not, but certainly people say, “Oh Michael, you solve this problem, you’re really good at computers,” and I had, I used no skill, all I did was just randomly try variations with the piece of software they’re trying to get to work, until the thing just gave in and worked, right? It’s not like I used some great skill or something, I was just persistently pushing through, and I was just willing to play with whatever the people brought to me with their computers, “Can you fix this?” and I’m like, I don’t really know about that, but I’ll try, you know, and I wonder if that’s something about growing up with computers, like, we didn’t have a lot of good sources to learn, so you just try variations until it works, and maybe that’s something that comes to you easier when you grow up with it, and you’re not learning when you’re 60? I don’t know.
唉，还是挺高兴看到一个开着python教程的作者这么说。coding这个东西，layer很重要，所以不要觉得越过layer看代码学习原理才是解决问题的根本办法。不然的话，why stop at software？我上一份工作是在沟通很不好的环境下做支持，所以我好像总是要求自己去看代码找问题。固然有它的好处（即：在很toxic的环境里不被人欺骗和欺负）。但是并不是绝对必要的。
===分割线===
上周有了这个工具后，效率还是很低。还不知怎么评价效率怎么这么低（知乎体）。我们写了一堆不需要产品化但需要手动重新使用的脚本。所以写的时候也不太注意（时间赶，而且不是产品）。重用的时候就各种问题：表存储并不在我们想的地方，所以数据不对；有的表需要实体化所以语法不一样没有改；数据导在同一个目录下导致数据double；两批数据格式不一样所以不管怎么建表都报错。。。
要在被“要照顾那么多细节”paralyze的情况下行动起来get it done，然后使用的时候还是有很多问题。需要行动&反思结合。