微信公众号的文档以多错漏著称，这次遇到的是关于获得用户发送位置信息的事件
顺着惯性思维翻看官方关于事件的文档
https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140454

上报地理位置事件

用户同意上报地理位置后，每次进入公众号会话时，都会在进入时上报地理位置，或在进入会话后每5秒上报一次地理位置，公众号可以在公众平台网站中修改以上设置。上报地理位置时，微信会将上报地理位置事件推送到开发者填写的URL。

哇，这个不得了。发送之后就等于授权，每5秒都会在手机后台推送的吗？如果没有处理好可能会频繁轰炸用户消息的（误，并不会）
文档还附上了相应事件的xml原文

<xml>
  <ToUserName><![CDATA[toUser]]></ToUserName>
  <FromUserName><![CDATA[fromUser]]></FromUserName>
  <CreateTime>123456789</CreateTime>
  <MsgType><![CDATA[event]]></MsgType>
  <Event><![CDATA[LOCATION]]></Event>
  <Latitude>23.137466</Latitude>
  <Longitude>113.352425</Longitude>
  <Precision>119.385040</Precision>
</xml>

按照evnet: LOCATION 测试了之后却什么也捕获不到

原来我都搞错了，根本不是这个event，这个event是怎样触发的也是迷，对应的应该是消息类型的文档
https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140453
里的 地理位置消息

实验所得，得到的事件xml是类似

<xml>
<ToUserName><![CDATA[gh_9f025824da8c]]></ToUserName>
<FromUserName><![CDATA[oKzs50m0BFVm6X2sXc3lAzbrZUK8]]></FromUserName>
<CreateTime>1555092634</CreateTime>
<MsgType><![CDATA[location]]></MsgType>
<Location_X>22.*****5</Location_X>
<Location_Y>113.*****1</Location_Y>
<Scale>15</Scale>
<Label><![CDATA[广州市***地址马赛克***]]></Label>
<MsgId>22263574791840510</MsgId>
</xml>

其中并没有 event 元素， MsgType为小写 location。

经验证：取值是 GPS的 WGS84坐标系，不需要转换。
（调用百度地图的API时需要标点时需要转换为百度坐标系 bd09ll， 文档参考 http://lbsyun.baidu.com/index.php?title=webapi/guide/changeposition ）

不负责地猜测这些类似的坑的原因

  • 微信内部缺乏有效的机制去回归和核对不同版本更新后的文档是否正确
  • 故意为之，在文档甚至源码中挖下一些并非十分严重的坑，用来提高公众号开发的门槛确保实施方的实力和代码质量
  • 因为鹅厂内部血汗工厂996的关系，导致工程师身兼数职没有足够的时间精力兼顾文档的更新（猜测这个事件的文档部分大部分从js-sdk部分复制过来）

最近有个lbs相关的项目，要求向用户位置推荐周边的(DB中的)已有地标。数据取自GPS的坐标系经纬度。是个典型求两点距离最优解的命题。
（需求接近于“滴滴拉屎”，自行脑洞一下）

备选的实现方向有：

  1. 使用地图服务商（例如百度地图、腾讯地图）提供的测距API计算 —— 缺点：不适合进行大量的计算，依赖第三方API业务稳定性有不可控,有网络请求延迟；
  2. 在后端脚本中进行计算 —— 缺点：每次查询需要取出数据库中全部地标数据，还需要自行实现排序结构化计算结果
  3. 在数据库中进行计算排序 —— 缺点：加重DB负担

衡量利弊后，似乎#3是比较理想的方案，于是找到了以下这个

《mysql 下 计算 两点 经纬度 之间的距离》
https://www.cnblogs.com/u0mo5/p/4260382.html

算法如下

round(6378.138*2*asin(sqrt(pow(sin( (`lat1`*pi()/180-`lat2`*pi()/180)/2),2)+cos(`lat1`*pi()/180)*cos(`lat2`*pi()/180)* pow(sin( (`lon1`*pi()/180-`lon2`*pi()/180)/2),2)))*1000)

验证的demo

#113.348407,22.968607 //lat, lon
#113.333603,22.973731 //地图距离1.6km

SELECT round(6378.138*2*asin(sqrt(pow(sin( (113.348407*pi()/180-113.333603*pi()/180)/2),2)+cos(113.348407*pi()/180)*cos(113.333603*pi()/180)* pow(sin( (22.968607*pi()/180-22.973731*pi()/180)/2),2)))*1000) as dist_m
dist_m
1663

经过验证计算结果和地图上直接测距一致, 单位 米

补充
初期的地标库比较小只有一百多条，所以直接用上面的sql便可以满足。若今后地标数据扩大，也会面临计算量大mysql计算负荷重的问题（需要计算后再排序，索引对提升速度无效）。届时进行的优化措施可以把坐标点按经纬度划分成若干间距的网格，仅在用户坐标的网格内（或加上周边一共9个网格内）进行检索，可以有效缩减计算量。
毕竟，如果我在北京王府井人有三急，我知道阿姆斯特丹有豪华六星厕所也没意义（笑）

几个月前尝试给台mini升级系统才发现已经惨遭apple抛弃。

QQ截图20190407185719.jpg

之后便一直闲置在一旁，直到最近在油管偶然发现有民间大神自己写了个安装补丁，可以手动升级旧款机型到最新系统，不仅限于macmini 还有旧型号的macbook,mac pro等笔电和台式。
之所以要把OS升级上去是因为很多开发环境不跟进升级无法开发编译出与最新iOS兼容的app。好了废话不多说，以下是升级全程的流水账。

(大多数是按照补丁作者官网的教程和描述执行，所以下文打多是官网的翻译归纳加我的一些截图)

准备

  • 一个16G或以上的空U盘
  • 比对补丁网站的兼容列表确认你的设备可以升级
  • 确保你当前的系统硬盘剩余空间有100G以上(升级安装，如果是完全重装可忽略这个条件)
  • 下载安装补丁
  • 下载mac os的安装文件

操作流程

1.下载mac os安装镜像
打开补丁，工具栏选 tools 可以直接从appstore下载安装镜像，选择保存路径后等待漫长的下载，大约6.5G
QQ截图20190407194242.jpg

2.格式化U盘
等待下载镜像的同时进入 launchpad - 其他 - 磁盘工具 格式化U盘

QQ截图20190407191303.jpg

选择u盘，抹掉，格式 Mac OS 扩展(日志式)

QQ截图20190407191617.jpg

3.写入U盘
下载完后回到补丁工具的界面刷新选择写入的设备，选择刚格式的U盘，点 Start Operation... 开始写入和打补丁，由于我的macmini是机械硬盘加usb2.0过程非常漫长

4.重启安装
完成后重启，启动时按住 键盘的 Option 键(104布局windows键盘为 Alt 键) 出现选择启动设备，选U盘
QQ截图20190407212206.jpg

QQ截图20190407212227.jpg

引导后同意协议，选择写入的分区，选已有的mac OS的硬盘，一路next 和等待(超慢，大约3个多小时)
QQ截图20190407212148.jpg

5.打上补丁
再次重启进入U盘，这次执行macOS Post Install , 选择对应的机型和分区，点 Patch 打补丁，完成后再一次重启，拔掉U盘

选择机型时，补丁程序已经很贴心的代你检测了，如果不确定是哪个的话参考文末的apple macmini 产品列表链接

QQ截图20190407221357.jpg

最后一次的reboot 需要 rebuild cache 也是需要略长时间的。

QQ截图20190407231004.jpg
完成

附一张完全体的截屏，证明旧版系统的用户数据被完美保留了下来
QQ截图20190407231500.jpg

最后

这个补丁的作者真的太良心了，竟然还有后续的跟踪服务，如果apple有更新发现与老机器不兼容会有个补丁更新程序随版本更新，点10086个赞！
QQ截图20190407230930.jpg

注意事项

  • 如果你的设备很新直接appstore就可以升级，那请不要折腾请走官网
  • 如果你的设备很旧连这个补丁也无能为力(多数是2007年以前发布的机器)那请放弃，即便勉强升级了10年前的硬件估计体验也很糟糕吧？
  • 注意看补丁网站的changelog , 大意是如果安装 10.14.4 务必用最新版的补丁工具，旧版已不能使用。万恶苹果与良心大神的战争仍在继续..
  • 第4步，作者说只要选择当前系统相同的分区便是执行升级安装（注意预留足够的可用空间），如果需要完全重装则多一道工序安装之前用磁盘工具对分区进行抹除

参考链接

2019愚人节刚过，BTC毫无征兆下一夜跳涨16%(4100 → 4700)。 这个看似触底反弹的时间点，最近又炒火了一个概念 IEO。

先po个科普链接，什么是IEO (Initial Exchange Offering)

https://cryptopotato.com/what-is-an-initial-exchange-offering-ieo-and-how-it-differs-from-ico/

简而言之，和ICO类似而又不同的是。新币发行方委托交易所(Exchange) 实施募资。

据说带来的方方面面的好处是

  1. 规避了政策法规的禁区
  2. 同时又引入了来自(正规)交易所的监管和担保减少SCAM的发生..
  3. IEO的部分资金或代币(募集成功后)用作在该交易所上架的费用，也就是说让发行方同时解决了还要花钱上架交易所的问题

看起来可谓是一箭三雕百利无一害。

然而在我眼里. IPO、ICO、IFO、IEO 无论 I乜O ..说穿了就是项目方想空手套白狼韭菜想赌一把捡便宜。

懂我的人都知道，我是从来不赌的。 QNMD IEO.

  1. 1
  2. ...
  3. 43
  4. 44
  5. 45
  6. 46
  7. 47