Legacy

我们最好的遇见，是现在这样的六月。我们最好的告别，是现在这样…… 没红眼。

通常情况下，我们采用 TCP Socket 与智能硬件进行通信。外网环境中，有无数种解决方案：Swoole（PHP），Node.js，SuperSocket（.NET）…… 而在政企事业单位的内网环境，事情或许就不那么好办了。 0x01 目的 接收来自硬件的数据，并在 Web 端展示。 通过 Web 端操作，将指令下发至硬件。 0x02 限制 浏览器需要支持 IE 等老版本浏览器。 服务端需要支持 Windows Server 虚拟机（最低版本 2008）。 纯内网环境，无法访问外网源，无法使用各类包管理器（其实可以自己搭建内网源，但过于复杂，人力成本太高）。 0x03 思路 目前公司 Web 后端语言均为 PHP，所以以下思路全部围绕 PHP 开展。

自己挖的坑，哭着也要填完。/笑哭脸 2018-03-11 修复图片本地化造成大量无用附件问题。 2018-03-09 修复缩略图比例拉伸问题，逻辑重构。 2018-02-21 根据 Lighthouse 建议修复部分问题。 修复移动端一处 CSS 样式问题。 2018-02-18 修复每日图片未采用 HTTPS 问题。 优化 CDN 缓存规则，加快访问速度。 2018-02-15 新增「Bing 每日图片」缓存功能，降低访问延时。 2018-02-14 因原「一言」接口失效，故调整为「Bing 每日图片」。 修复导航栏浮动效果异常。 2017-11-20 调整右侧边栏模块字体大小。 2017-11-17 修复一处因加载 HTTP 协议资源引起的警告。 2017-11-15 新增支持原生 Markdown 存储。 2017-11-11 启用新域名「jootu.

不知不觉搭建技术博客已经过去半年，半年来自己和团队共同进步成长，也带动网站内容水准越来越高；在此小结一下半年来深度使用 Z-Blog 体会到的优缺点，希望能够给予后来者一定参考。 0x00 说到博客，不得不提起两个链接： 关于本站 填坑之路 的确，时间过得很快。 0x01 如上，在选用 Z-Blog 时，奔着这几点去的：

在前端开发过程中常见路径，在一般情况下，同站点强烈建议使用相对路径，这里简单总结一下相对路径的写法。 ./***，「.」用来表示当前目录，此写法用于引用和本页面相同目录下的其他文件。 ../***，「..」用来表示上级目录，即父目录。以此类推，可以使用../../来表示上级目录的上级目录。 /****，「/」表示同站点跟目录。无论本页面目录是在哪，此写法都能引用到根目录，常见用法例如 favicon。 //****，「//」表示相同协议。此写法与绝对路径的区别就在于不指定协议，具体协议将跟随当前页面，常见用法例如全站 HTTPS。 有过 Linux 功底的同学应该会发现，如上的路径写法都是标准的 URI，Linux 的文件路径也同样遵循了 URI 的标准。具体例子在这里不再详叙，随便开个百度、淘宝的页面一抓一大把，自己实践一下也是不错的学习方式。

在各类交流群，甚至多数老一辈程序员的眼里，认为 PHP 是「轻量的」、「不完善的」、「性能难以优化」的，而这么多年来一直坚挺的 Java 却成了开发「XX 系统」的后端首选语言。为此，本篇文章将尽量从非技术角度告诉大家：Why PHP？ 现状 其实，从 Java 和 PHP 的历史不难看出。在 Java 开始盛行的年代，PHP 还是个“毛头小子”，只是个普普通通的脚本语言罢了，甚至连面向对象的基本概念——类，都没有支持。 鉴于 PHP 历代升级以来坚守的向下兼容性，至今还可以看到不少用「当年的」原生函数写出来的产品代码可以运行，透过命名规则我们也可以看出当年的 PHP，好像的确「不够完善」。

正则表达式(regular expression)描述了一种字符串匹配的模式（pattern），可以用来检查一个串是否含有某种子串、将匹配的子串替换或者从某个串中取出符合某个条件的子串等。—— 菜鸟教程 [*] Part 1 是什么？ 用途？（搜索、替换、提取、验证、格式化、Rewrite 等） 怎么用？ 常见正则引擎（PCRE / DEELX …）。 常见正则测试工具（Deelx Regex Match Tracer / Regex 101 / RegExr / Cyrilex / For PHPer: PHP Live Regex） 一个简单的例子（.

9.20 updated: 今天检查多家公司的管理端页面时发现，居然其他公司可以看到我们的测试数据，遂检查数据库，并不存在测试数据，又去翻配置 env 文件，数据库配置正常，又排除 rsync 同步了 config 缓存的可能之后，最终发现是 nginx 配置引起的反向代理全部进了 demo 服务器。。。 不过这也引起了我的重视：由于 laravel cache 驱动为 file，而 rsync 同步列表并没有排除bootstrap/cache/config.php，这样会导致执行php artisan config:cache缓存命令后，全部公司都连接同一个数据库！

今天沈同学来问 c# 读 ic 卡的问题，我第一反应是想到了 windows 提供的智能卡驱动 API，之前用 c++实现过一套。 reference：https://docs.microsoft.com/zh-cn/previous-versions/windows/desktop/secsmart/smart-card-api-portal 可只有英语，对于没有阅读过原版 MSDN 的实习生来说有一定难度，即便有复杂的 c++源码参照，估计也要研究个几天。 so，用 c# 写 windows，要的就是它的轮子多。遇到这种情况，果断网上搜一下先，但结果不尽人意，大多都是专门用于某个型号读卡器的厂家提供的 SDK。 于是果断去微软官方的包管理器 nuget 里找，（keyword：smart card）……

此处不考虑硬件，我们做 PaaS。 首先云服务，负载均衡 + 2 到 3 台服务器，其中文件上传下载采用对象存储，这样可以大量节省服务器带宽，外面再套一层 CDN，可以保证秒开；数据库采用独立的数据库服务器，云服务提供商大多在底层实现了热备，出问题的概率很小；另外，在上面的基础上再加上前后端分离，前端代码也全部跑在对象存储里，Web 服务器可以达到只“计算”的目的，也就是说只提供接口服务。 另外为了防止攻击，可以套三层防御，一层在 DNS 解析，挂掉了立马解析到第二台，第二层在云服务提供商，购买单独的防御服务，第三层在 WEB，监测到攻击的时候自动对某一个 IP 返回 502。 然后再来说数据库、语言和框架。 数据库采取优势互补，MongoDB 适合日志，但是不适合关键数据的存储，Redis 适合做某些数据的缓存，例如消息队列、热度 Top10 等，而 MySQL/MariaDB 则是作为最终的数据存储，为啥我前面直接把 MyISAM 砍掉了，就是因为 MySQL 在这个架构里本身就是做为“最终 boss”存一些关键数据的，要尽最大可能保证不出问题，而要追求效率、数据一致性相对来说无关紧要的日志这些就交给 MongoDB 去做吧。 前面说的数据库采用单独的服务器，也是为了这个原因，不同的需求采用不同的数据库，跑在不同服务器。