六月,你好。
我们最好的遇见,是现在这样的六月。我们最好的告别,是现在这样…… 没红眼。
我们最好的遇见,是现在这样的六月。我们最好的告别,是现在这样…… 没红眼。
通常情况下,我们采用 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 去做吧。 前面说的数据库采用单独的服务器,也是为了这个原因,不同的需求采用不同的数据库,跑在不同服务器。