Posts

汤婆婆给千寻签订了契约，之后千寻的名字被抹去了，每个人都叫千寻小千，甚至千寻自己，也忘记了自己原来的名字。 但是只有白先生告诫千寻，一定要记住自己的名字，否则再也无法回到原来的世界。而白先生自己，就是那个已经无法回到原来世界的人。 最重要的是记住自己的名字 名字要有意义 不要使用缩写，缩写会让你忘记自己的原来的名字 没有工作的人，会变成妖怪的 没有用的变量，会变成垃圾 别吃得太胖，会被杀掉的 别占用太多内存，会被操作系统给杀掉的

Photo by Blair Fraser on Unsplash 从头开发一个软件只是小儿科，改进一个程序才显真本事。《若为自由故 自由软件之父理查德·斯托曼传》 每个人都有从零开发软件的处女情结，但是事实上我们大多数时候都在维护别人的代码。 所以，别人写的代码如何糟糕，你再抱怨也是无意义的。 从内心中问自己，你究竟是在抱怨别人，还是不敢面对自己脆弱的内心。 老代码的意义 廉颇老矣，尚能饭否。 老代码的有很多缺点，如难以维护，逻辑混乱。但是老代码有唯一的好处，就是老代码经过生产环境的洗礼。这至少能证明老代码能够稳定运行，不出问题。 东西，如果不出问题，就不要动它。 老代码可能存在哪些问题 老代码的问题，就是我们重构的点。首先我们要明确，老代码中有哪些问题。 模块性不强，重复代码太多 逻辑混乱，业务逻辑和框架逻辑混杂 注释混乱：特别要小心，很多老代码中的注释都可能不知道祖传多少代了。如果你要按着注释去理解，很可能南辕北辙，走火入魔。按照代码的执行去理解业务逻辑，而不是按照注释。 配置性的硬代码和业务逻辑混杂，这个是需要在后期抽离的 如果你无法理解，请勿重构 带着respect, 也带着质疑，阅读并理解老代码。取其精华，去其糟粕。如果你还不理解老代码，就别急着重构它，让子弹飞一会。 等自己能够理解老代码时，再去重构。我相信在理解基础上重构，会更快，也更安全。 不要大段改写，要见缝插针 不要在老代码中直接写自己的代码，应该使用函数。 在老代码中改动一行，调用自己写的函数。 几乎每种语言中都有函数这种组织代码的形式，通过见缝插针调用函数的方式。能够尽量减少老代码的改动，如果出现问题，也比较容易调试。

基于python # 基于python2 python -m SimpleHTTPServer 8088 # 基于python3 python -m http.server 8088 基于Node.js https://github.com/zeit/serve https://github.com/http-party/http-server

上传文件 import requests headers = { "ssid":"1234" } files = {'file': open('yourfile.tar.gz', 'rb')} url="http://localhost:1345/fileUpload/" r = requests.post(url, files=files, headers=headers) print(r.status_code)

变量不要使用缩写，要见名知意。现代化的IDE都提供自动补全功能，即使是VIM, 也可以用ctrl+n， ctrl+p, ctrl+y, ctrl+e去自动补全。 变量名缩写真是灾难。

使用HTTP仓库 默认docker不允许使用HTTP的仓库，只允许HTTPS的仓库。如果你用http的仓库，可能会报如下的错误。 Get https://registry:5000/v1/_ping: http: server gave HTTP response to HTTPS client 解决方案是：配置insecure-registries使docker使用我们的http仓库。 在 /etc/docker/daemon.json 文件中添加 { "insecure-registries" : ["registry:5000", "harbor:5000"] } 重启docker service docker restart # 执行命令 docker info | grep insecure 应该可以看到不安全仓库 存储问题 有些docker的存储策略并未指定，在运行容器时，可能会报如下错误 /usr/bin/docker-current: Error response from daemon: error creating overlay mount to 解决方案： vim /etc/sysconfig/docker-storage DOCKER_STORAGE_OPTIONS="-s overlay" systemctl daemon-reload service docker restart

语雀官方的Graphviz感觉太复杂，我还是写一个简单一点的吧。 两个圆一条线 注意 graph是用来标记无向图，里面只能用–，不能用->，否则无法显然出图片 digraph用来标记有向图，里面只用用-> 不能用–, 否则无法显然出图片 graph easy { a -- b; } 连线加个备注 graph easy{ a--b [label="你真漂亮"] } 你真漂亮，要大点，红色显眼点 graph easy{ a--b [label="你真漂亮", fontcolor=red, fontsize=34] } 两个圆，一个带有箭头的线 注意，这里用的digraph， 用来表示有向图 digraph easy { a -> b; } 如何画虚线呢？ digraph easy { a -> b [style=dashed]; } 椭圆太单调了，有没有其他形状？ shape box 矩形 polygon ellipse circle 圆形 point egg 蛋形 triangle 三角形 plaintext 使用文字 diamond 钻石型 trapezium 梯形 parallelogram 斜的长方形 house hexagon octagon doublecircle doubleoctagon tripleoctagon invtriangle invtrapezium invhouse Mdiamond Msquare Mcircle none record Mrecord graph easy { node [shape=box] a -- b; } 形状也可以直接给节点定义。...

如何学习网络协议？ 大学时，学到网络协议的7层模型时，老师教了大家一个顺口溜：物数网传会表应。并说这是重点，年年必考，5分的题目摆在这里，你们爱背不背。 考试的时候，果然遇到这个问题，搜索枯肠，只能想到这7个字的第一个字，因为这5分，差点挂科。 后来工作面试，面试官也是很喜欢七层模型，三次握手之类的问题，但是遇到这些问题时，总是觉得很心虚。 1. 协议分层 四层网络协议模型中，应用层以下一般都是交给操作系统来处理。应用层对于四层模型来说，仅仅是冰山一角。海面下巨复杂的三层协议，都被操作系统给隐藏起来了，一般我们在页面上发起一个ajax请求，看见了network面板多了一个http请求，至于底层是如何实现的，我们并不关心。 应⽤层负责处理特定的应⽤程序细节。 运输层运输层主要为两台主机上的应⽤程序提供端到端的通信。 网络层处理理分组在⽹网络中的活动，例例如分组的选路 链路层处理理与电缆(或其他任何传输媒介)的物理理接⼝口细节 下面重点讲一下运输层和网络层 1.1. 运输层的两兄弟 运输层有两个比较重要的协议。tcp和udp。 大哥tcp是比较严谨认真、温柔体贴、慢热内向的协议，发出去的消息，总是一个一个认真检查，等待对方回复和确认，如果一段时间内，对方没有回复确认消息，还会再次发送消息，如果对方回复说你发的太快了，tcp还会体贴的把发送消息的速度降低。 弟弟udp则比较可爱呆萌、调皮好动、不负责任的协议。哥哥tcp所具有的特点，弟弟udp一个也没有。但是有的人说不清哪里好 但就是谁都替代不了，udp没有tcp那些复杂的校验和重传等复杂的步骤，所以它发送消息非常快，而且并不保证对方一定收到。如果对方收不到消息，那么udp就会呆萌的看着你，笑着对你说：我已经尽力了。一般语音而视频数据都是用udp协议传输的，因为音频或者视频卡了一下并不影响整体的质量，而对实时性的要求会更高。 1.2. 运输层和网络层的区别 运输层关注的是端到端层面，及End1到End2，忽略中间的任何点。 网络层关注两点之间的层面，即hop1如何到hop2，hop2如何到hop3 网络层并不保证消息可靠性，可靠性上层的传输层负责。TCP采用超时重传，分组确认的机制，保证消息不会丢失。 从下图tcp, udp, ip协议中，可以发现 传输层的tcp和udp都是有源端口和目的端口，但是没有ip字段 源ip和目的ip只在ip数据报中 理解各个协议，关键在于理解报文的各个字段的含义 1.3. ip和端口号的真正含义 上个章节讲到运输层和网络层的区别，其中端口号被封装在运输层，ip被封装到网络成， 那么端口号和ip地址到底有什么区别呢？ ip用来用来标记主机的位置 端口号用来标记该数据应该被目标主机上的哪个应用程序去处理 1.4. 数据在协议栈的流动 封装与分用 当发送消息时，数据在向下传递时，经过不同层次的协议处理，打上各种头部信息 当接受消息时，数据在向上传递，通过不同的头部信息字段，才知道要交给上层的那个模块来处理。比如一个ip包，如果没有头部信息，那么这个消息究竟是交给tcp协议来处理，还是udp来处理，就不得而知了 2. 深入阅读，好书推荐 《http权威指南》 有人说这本书太厚，偷偷告诉你，其实这本书并厚，因为这本书的后面的30%部分都是附录，这本书的精华是前50%的部分 《图解http》、《图解tcp/ip》这两本图解的书，知识点讲的都是比较通俗易懂的，适合入门 《tcp/ip 详解 卷1》这本书，让你知其然，更知其所以然 《tcp/ip 基础》、《tcp/ip 路由技术》这两本书，会让你从不同角度思考协议 《精通wireshark》、《wireshark网络分析实战》如果你看了很多书，却从来没有试过网络抓包，那你只是懂纸上谈兵罢了。你永远无法理解tcp三次握手的怦然心动，与四次分手的刻骨铭心。

什么是呼叫中心？ 呼叫中心又称为客户服务中心。有以下关键词 CTI 通信网络 计算机 企业级 高质量、高效率、全方位、综合信息服务 呼叫中心历史 1956年美国泛美航空公司建成世界第一家呼叫中心。 阶段 行业范围 技术 功能与意义 第一代呼叫中心 民航 PBX、电话排队 主要服务由人工完成 第二代呼叫中心 银行、生活 IVR(交互式语音应答)、DTMF 显著提高工作效率，提供全天候服务 第三代呼叫中心 CTI(电脑计算机集成) 语音数据同步，客户信息存储与查阅，个性化服务，自动化 第四代呼叫中心 接入电子邮件、互联网、手机短信等 多渠道接入、多渠道统一排队 第五代呼叫中心 接入社交网络、社交媒体(微博、微信等) 文本交谈，音频视频沟通 呼叫中心分类 按呼叫方式分类 外呼型呼叫中心（如电话营销） 客服型呼叫中心（如客户服务） 混合型呼叫中心 （如营销和客服） 按技术架构分类 交换机 板卡 软交换（IPCC） 【交换机类型呼叫中心】

2008-2018 十年，往事如昨 2018年已经是昨天，今天是2019的第一天。 2008年已经是10年前，10年前的傍晚，我走在南京仙林的一个大街上，提着一瓶矿泉水，擦着额头的汗水，仰头看着大屏幕上播放着北京奥运会的开幕式。 10年前的夏天，我带着一步诺基亚手机功能机，独自一人去了南京。 坐过绣球公园的石凳，穿过天妃宫的回廊，吹过阅江楼的凉爽的江风，踏着古老斑驳的城墙，在林荫小路的长椅上，我想着10年后我会在哪里？做着什么事情？ 往事如昨，而今将近而立，但是依然觉得自己还是10年的那个独自出去玩的小男孩。 2018 读了10年都没有读完的书，五味杂陈 2018年，在我做手术前，我觉得自己出了工作的时间外，大多数时间都在看书。2018年这一年看的书，要比2008到2018年这十年间的看的书都要多。这都归功于我对每天的看书都有定量的计划，一旦按照这个计划实行几个月，积累的效果还是非常明显的。 2018年，手机几乎成为人的四肢之外的第五肢。对大多人来说，上厕所可以不带纸，但是不能不带手机。 各种APP, 都在极力的吸引用户多花点时间在自己身上 信息流充斥着各种毫无营养，专门吸人眼球的垃圾新闻，但是这种新闻的阅读量还是蛮大的 各种借钱，信用卡，花呗等都像青楼的小姐，妩媚的笑容，说道：官人，进来做一做 共享单车，在今年退潮之后，才发现自己都在裸泳 比特币，挖矿机。不知道谁割了谁的韭菜，总希望有下一个傻子来接盘，最后发现自己可能就是最后一个傻子 AI，人工智能很火，放佛就快要进入终结者那样的世界 锤子垮了，曾经吹过的牛逼，曾经理想主义终于脱去那又黑又亮的面具 图灵测试（The Turing test）由艾伦·麦席森·图灵发明，指测试者与被测试者（一个人和一台机器）隔开的情况下，通过一些装置（如键盘）向被测试者随意提问。 进行多次测试后，如果有超过30%的测试者不能确定出被测试者是人还是机器，那么这台机器就通过了测试，并被认为具有人类智能。图灵测试一词来源于计算机科学和密码学的先驱阿兰·麦席森·图灵写于1950年的一篇论文《计算机器与智能》，其中30%是图灵对2000年时的机器思考能力的一个预测，目前我们已远远落后于这个预测。 最后说一下图灵测试，在AI方面，这个测试无人不知。一个机器如果通过了图灵测试，则说明该机器具有了只能。但是三体的作者大刘曾经说过一句话，给我一种醍醐灌顶的感觉，假如一个机器人有能力通过图灵测试，却假装无法通过，你说这个机器是否具有人工智能。所以大刘的这种说法才更加让人恐惧。机器人能通过图灵测试，只说明这个机器人具有了智能。但是现阶段的智能只不过是条件反射，或者是基于概率计算的结果。后者这种能通话测试，却假装无法通过的智能。这不仅仅是智能，而是机器的城府。 有智能的机器并不可怕，有城府的机器人才是真正的可怕。 如果梦中更加幸福快乐，为什么要回到现实 火影的最后，大筒木辉夜使用无限月读将世界上的所有人都带入梦境，每个人的查克拉都被吸取，并作为神树的养料。 如果真的存在大筒木这样的上帝，那么时间就是查克拉。人类唯一真正拥有过的东西，时间，将作为神树的养料，从每个人身上提取。 各种具有吸引力的术，其实可以理解为无限月读，让人沉醉于梦幻中。 如果梦中更加幸福快乐，为什么要回到现实中承受压力与悲哀呢？ 目前我无法回复自己的这个问题，期待2019年我可以得到这个答案。 工作方面 2019年，我会在做一些后端方面的工作，努力加油吧。