1 | var type = navigator.appName; |
文中截取lang的前2位字符,是因为浏览器语言返回值可能是:
lang | name |
---|---|
zh-cn | Chinese(PRC) |
zh-tw | Chinese(Taiwan Region) |
zh-hk | Chinese(Hong Kong SAR, PRC) |
zh-sg | Chinese(Singapore) |
en-us | English(United States) |
en | English |
1 | var type = navigator.appName; |
文中截取lang的前2位字符,是因为浏览器语言返回值可能是:
lang | name |
---|---|
zh-cn | Chinese(PRC) |
zh-tw | Chinese(Taiwan Region) |
zh-hk | Chinese(Hong Kong SAR, PRC) |
zh-sg | Chinese(Singapore) |
en-us | English(United States) |
en | English |
我个人是使用习惯是使用阿里云自带的 负载均衡SLB
服务,完成 反向代理
,负责均衡
,SSL证书
,域名解析
等操作,同时也推荐在Pord环境中使用,这样在后期在跟新的过程中更加灵活。
而在开发测试环境中,单机部署宝塔面板,可通过Ngix
的配置完成以上配置。
eg.以java项目为例,我们部署的到服务器上确保指定端口可访问,如 SERVER_IP:8080
但实际情况是,我们希望 api.xxx.com
这种域名的情况的下去访问该网站或者接口时,具体操作步骤如下。
域名解析,将 api.xxx.com
cname 指向到 SERVER_IP 上,注意这里在没有配置端口号的情况下默认端口为80,通过ping api.xxx.com
验证是否解析成功。
在宝塔面包中创建一个静态网站,如下图所示。
因为我们是java工程,只需要宝塔给我们做一个反向代理的功能,所以并不关注其他的有关php的配置,选择静态部署。
配置反向代理将服务请求转发至 SERVER_IP:8080
好,截止到目前为止,即可通过 api.xxx.com
访问到 SERVER_IP:8080
网站,反向代理的主要功能就是如此,说白了就是做了个端口映射。在此解决一台服务器通过不同的域名解决同一端口的地址映射关系。
如果是API服务,并且工程中并没有处理跨域的问题时,又不想通过代码的方式去解决,此时可以通过配置ngix解决此问题。
1 | #解决跨域问题 |
这个是宝塔官方出的一个管理工具,具体功能类似的pm2提供守护进程确保服务的稳定性,这也是我最近才开始用的。我使用其的目的主要是为了解决应用程序跟随服务器自启动。
环境池
中创建想要的启动命令,比如下面的java命令应用列表
中添加应用
最终其完整的启动命令如下:/usr/bin/java -jar /home/fanfq/apps/x.jar --server.port=8180 --downloadPath=/macshare
注意 中文乱码问题
/usr/bin/java -Dfile.encoding=UTF-8 -jar /home/fanfq/apps/x.jar --server.port=8180 --downloadPath=/macshare
如果启用了进程守护
那么此时可以通过各种方式停止服务,然后再观察该服务是否正常重启。这就是进程守护
的意义,btw我们经常所见的mysqld实际上就是mysql服务的守护进程,通常用后缀d命名。
这个功能也是常规用的比较多的应用,我的应用场景是当git仓库有新的push时会发送一个http请求给服务器,此时服务器会自动pull到最新版本,并自动完成编译,重启等操作。
此功能是比较简易话的完成自动构建的操作,在开发测试环境中特别适用。
1 | source /etc/profile |
后续只要接口地址获取到请求,即触发脚本执行。
注意
原本是打算用钉钉
实现该功能的,一看要做企业认证就放弃的。不得不说这种所谓的认证就拒绝了相当多的独立开发者,这一点绝对是受诟病的。
前端时间研究下Telegram
相关的开发,总体来说实现了想要得所有功能,但是在测试的过程中发现很多问题。主要是因为早期Tg的开放接口被滥用的问题导致的,从而想要实现一些功能是受限的以免接口滥用。
Telegram Bot 和绝大多数的IM通讯软件中的机器人是一样的,
直接在Tg中与@BotFather对话即可创建bot,比较有趣的是在Tg很多的交互式体验都是通过类似对话的方式。
将下面的链接的{TOKEN}
替换成所获取的token然后浏览器访问
1 | https://api.telegram.org/bot{TOKEN}/getUpdates |
返回数据,此时与机器人对话的内容均会在此显示出来
1 | { |
为了方便开发,已经有很成熟的三方sdk了。这里推荐 TelegramBots
趁此机会和大家介绍一下我做的机器人,其主要功能就是通过抖音的分享链接下载其不带水印版本的视频。
机器人体验地址 https://t.me/fast_dl_bot
1 | 今天是国际篮球日,你能#接住姚明的传球 吗? https://v.douyin.com/JbUn9qr/ 复制此链接,打开抖音搜索,直接观看视频! |
1 | https://v.douyin.com/JbUn9qr/ |
wm
即可得到不带水印的地址源。并通 agent 为手机客户端访问改地址,即可获取到不带水印的视频。
然后下载视频即可得到不带水印的视频
1 | https://aweme.snssdk.com/aweme/v1/play/?video_id=v0300f010000bvfv7l99jbbabl28o260&ratio=720p&line=0 |
采用 TelegramBots
实现,涉及三方软件可能会有争议,既不提供代码实现,本文仅分析原理。
1 | public class MyAmazingBot extends TelegramLongPollingBot { |
原本我以为我可以在周末的时间写出稿件,但实践证明这个太难了,我计算了一下仅仅周六上午半天的时间我给小朋友擦屁股累积超过10次以上,更多是中途的捣乱,姐姐有点粘我总是习惯性的试图在我工作的过程中坐到我的腿上,和我一起看着电脑屏幕,我和妻子都一致的观念在我们的家庭教育中尽可能的让小朋友减少对显示器的依赖。所以此时我不得不放下手头上的工作去陪伴她们。
我们家是绝对杜绝小朋友玩手机,平板电脑的,即便是电视每周只可以限制性的看一个小时,而我现在逐步的下载一些优质的动画电影陪伴她们一起收看。妹妹更喜欢“天猫精灵”因为更方便通过语音交互的方式切换她想收听的内容,常常早晨起来她独自一人坐在客厅听着天猫精灵里播放出来的故事。而姐姐视乎缺乏耐心基本不会长时间做在那里收听节目,即便是看电视她也会因为其他的事情中断她的观看兴趣。
这两人的性格,差别太大了。
所以,我可能要尝试调整一下我的工作流,让时间更加的效率。周末的时间更多的是陪伴小朋友,见证他们成长更多的是陪伴。实际上养娃的过程中琐碎的事情特别多,每当看到她们睡着的样子就特别的温馨。
这篇文章主要是要将的我工作流给记录下来,以免以后时间长了忘记了。
http://fm.fanfq.com 这个站实际上是我的podcast发布站,采用hexo
+next主题
+podcasts插件
,放在github
上托管,mp3等资源文件放在七牛CDN上托管。
实际上没有什么,主要是说下这个podcasts插件并不好用,我自己根据实际需求做了修改,以及增加了一个脚本获取mp3文件的数据。
podcasts插件主要是为了生成符合apple podcast rss feed 文件,貌似国外的主流的都是以rss订阅的方式发布的,这很好,不需要作者每个平台手动的发布,我这里的发布站也是为了解决这个问题。
有关podcasts插件修改内容看这个链接:(这要比较重要,一定要验证成功才有用)
https://github.com/fanfq/hexo-generator-podcasts
还写了python脚本为了获取mp3的参数:
https://github.com/fanfq/python-learning/blob/master/src/util/file/mp3_file_rename.py
mp3_file_name.py
这个脚本,目的是为了重命名文件。如下所示
1 | 用于podcast音频文件整理 |
然后就是写文章了,目前这个文章的结构是需要手动维护的,文章结构示例
1 | --- |
编辑好后直接发布到github上就可以了,然后等苹果的服务器自动同步。
1.编辑好的mp3文件发到mp3目录下
2.执行mp3目录下的 mp3_file_name.py
脚本,自动重命名以及上传到CDN
4.创建新的文档 hexo new post NAME
5.编辑 NAME.md
文件信息
6.hexo s
本地预览一下,看是否都正常,只要mp3能正常播放那问题不大
7.hexo clean
, hexo g
,hexo deploy
全套。
之前一篇文章《Creator WebSocket Protobuf整合之保姆级全攻略》大概的介绍了下有关protobuf的整合,首先我们认清一点protobuf仅仅是数据封装的模式,并没有加密功能,简单的来说将其理解成增强型json,以便于理解。
近期也看了一些服务器端的源码,总的来说protobuf算是比较主流的,老点的项目有用json的或者是body是json然后用LengthField加头的。不管如何我个人还是建议使用protobuf,其优势不再赘述了。
在阅读源码期间,偶然发现baidu的开源项目 [jprotobuf] (https://github.com/jhunters/jprotobuf) ,其主要的优势就是不需要再编写.proto的文件的直接在pojo类上加上注解即可,一定程度的简化了我们开发的流程提高的开发效率。但我个人观点还是需要.proto文件的,即便没有此文件也需要通过文档的形式列出所有通讯消息的结构体。随时时间的推移项目的迭代以及各种跨平台的客户端的开发,有一份清晰的文档往往事半功倍,这也算是我个人的偏执吧。
环境说明:
Cocos Creator : 2.3.0 学习的速度赶不上它更新的速度
protobuf3 https://developers.google.com/protocol-buffers/
protobufjs @6.8.9 https://github.com/protobufjs/protobuf.js
没错,这是目前最新版本。网上一大堆都是老的 v5 版本,对我来说太low。哈哈实际上我仅仅是为了用那该死的 pbts 啦!
服务器端:
websocket + protobuf3 这里就不具体展开说明了,因为此时我对服务器端没有什么兴趣。
我来告诉你,为什么选择protobuf作为网络的封装协议而为什么不用json?
1.首先我是google的粉丝
2.序列化与反序列化效率高于json,相比而言降低了客户端服务器的资源
3.传输体积小,对应的降低的数据流量
4.数据类型跨平台,这点很重要。也许你不在乎,等你做多客户端的时候就知道了。
5.一定程度脱敏,强调一下protobuf没有加密功能,仅仅是二进制难以阅读而已。本文不涉及加密的操作,先给留个坑如果读者有兴趣我会考虑做篇有关RSA,AES加密封装.
1 | #install |
如果是服务器安装,客户端是没法通过guest用户登录的,则需要创建一个新的用户并赋予admin权限,后续的操作均可通过网页管理。