正在开发的 Web 项目需要获取使用者的位置信息,而使用者主要通过移动端访问此 Web 服务。位置信息需要精确到区。在腾讯位置服务的定位解决方案里想要搜索可用的 JavaScript 库,只看到了服务端的 IP 定位和移动端的几个 SDK 包,甚异之。
终于在不起眼的地方找到了前端定位组件,适用于浏览器进行定位操作。
本文基于 Nuxt.js 实现前端定位功能。
它能做什么
组件旨在优化纯 HTML5 Geolocation 定位能力弱,定位成功率不高的问题,提供简单、易用的接口帮助业务层获取用户当前的位置信息(需用户授权),以降低开发成本,提升定位精准度。
除了常规的经纬度坐标以外,它返回的结果里还包含了 city
和 district
项,非常方面。
问题描述
在 CentOS 环境下执行 yum update
和 ldconfig
命令时都出现提示警告,节选内容如下所示:
1 | ldconfig: /OSM/lib/librdmacm.so.1 is not a symbolic link |
错误分析
进入到对应目录下查找可以发现,这里的 librdmacm.so.1
与 librdmacm.so.1.1.17.4
实际上是相同的动态库文件,而非我们期望的符号链接和动态库文件。
1 | [root@xxx ~]# cd /OSM/lib |
哪位代码人不希望自己的代码总有统一优美的风格,不会因为合作开发项目而杂乱呢?
在最开始写项目代码的时候我就用起了 ESLint 和 Prettier,再装一堆预设的配置,便跑了起来。令人沮丧的是,用 ESLint 修复了代码质量问题,还是会在编译器里看到红色波浪线,提醒还有些代码风格需要修复。直到这一次,我才忽然意识到 ESLint 和 Prettier 其实分工了不同领域,协同使用体验极好。
本文基于 Nuxt.js + VSCode 阐述如何配置并实现 ESLint + Prettier 检查并规范代码质量与格式。
ESLint 与 Prettier
ESLint 是一个开源的 JavaScript 代码检查工具,Prettier 是一款代码格式工具。它们的功能侧重如下所示:
- ESLint:主要负责代码质量的校验,其次包含代码风格的检验。
- Prettier:主要负责代码风格的校验。
在开发 NetUnion 的官网页面时,有这样一个需求:读取本地目录下的新闻和博客文件,并在前端渲染,其中文件均为 Markdown 格式。
与全栈开发直接调用后端数据库不同的是,没有数据表字段来记录文件的不同属性,例如文件的题目、作者、撰写日期等,因此这些属性需要记录在 .md 文件当中。
这样的撰写方式是不是很熟悉?没错,不就是我正在写的 Hexo 博客中 .md 文件的编写格式嘛!
自动导入本地的 .md 文件
当然,首先要读取某个目录下已经撰写好的 .md 文件,才能对内容进行预处理。
但如果每撰写好一个新的新闻或博客文件,就得在代码中 require
出来,太过于麻烦且不现实,因此就需要自动导入的方法。
这是我撰写的第一篇与 Github Actions 有关的博客,那么就首先对 Github Actions 做一个简短的介绍吧。
Github Actions 是 Github 于 2018 年 10 月推出的持续集成服务(CI)。
大家知道,持续集成由很多操作组成,比如抓取代码、运行测试、登录远程服务器,发布到第三方服务等等。GitHub 把这些操作就称为 actions。
很多操作在不同项目里面是类似的,完全可以共享。GitHub 注意到了这一点,想出了一个很妙的点子,允许开发者把每个操作写成独立的脚本文件,存放到代码仓库,使得其他开发者可以引用。
如果你需要某个 action,不必自己写复杂的脚本,直接引用他人写好的 action 即可,整个持续集成过程,就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。
—— GitHub Actions 入门教程
不过在 Github Actions 的发展的过程中,它早已不局限于 CI 等功能,还可以用于各种自动化操作,例如百度贴吧自动签到(注:已失效。Github 官方会对此类利用服务器实现签到功能的仓库进行封禁打击,还是不要使用了吧)等。
持续集成与部署 Hexo 博客
在搭建自己的 Hexo 博客那篇文章的最后,我们使用的是 hexo-deployer-git 一键部署到仓库的方式,实现手动构建个人博客网页并通过脚本推送部署到自己的 Github Pages.