东航(上航)空中互联(机上WIFI)首次体验

背景 应该是2017年开始,国内很多航空公司也陆续开始部署机上WIFI,目前应该是根据民航总局的规定未开放收费,所以如果班次有WIFI部署到的话,可以进行免费试用。此次试用东航的WIFI,其服务名称是「空中互联」,号称卖258元。目前看服务和价格差的有点远,显然不值。 体验 东航机上WIFI的SSID名叫「CEAIR-WIFI」,扫描看到是一个5G的频段,这点还算不错,至少内网的比较有保证。 连上后他们的Portal页面是自家的各种介绍和机上商店,不同于一般外面免费WIFI的Portal页面的是,他们的验证上互联网的链接稍微藏的有点深,需要再寻找点击进入。目前试用阶段验证的凭证是座位号-证件号后4位-验证码,三号对应就可以上网了。验证码是事先从东航申请试用名额时短信发送的。 网通后,过了一下网络查看的常规套路: 看看出口在哪里通过卫星连接后,出口还是先绕回中国电信的网络。我本次连接的出口IP是:36.110.115.35 看看是否依然需要过我们的强国大滤网由上基本可以判定滤网肯定还是有过的。毕竟先绕回了电信。检测结果确实如此 网速如何大概就是512Kbps的最早的ADSL的速度 看看卫星连接导致的延时如何600ms+ 的延时,并且由于飞行位置的关系,时而会断开网络 是否有进一步的限制:比如限流量,限内容航空公司、或者说是合作的电信这边对内容肯定是做了进一步的限制的。比如一些网站在视图访问时就会重定向你到如下页面。我觉得目前东航对于机上WIFI有部署HTTP的深度包检测,同时有域名黑白名单的限制。此外对于视频类的大流量站也会限制访问。对于部分IP地址也有直接的限制,比如我试了1.1.1.1就直接无法ping通,在内网阶段就被咔断。 总结 应该是卫星连线成本的关系,所以机上WIFI的速度对于现在我们用惯4G移动网络的人来说都会显得比手机上网还慢,更不用说和普通固网的宽带WIFI比了。这点可能暂时也无法有很大改进,可以理解。但是网速不够可以其他方面来补么,但是目前给我感觉是其他地方又人为的加上了重重枷锁,至少给普通想上网的用户感觉基本不能干什么了(难道真的是给土豪收个邮件这样子吗?258元?)最后我发出此文的时候是在39000英尺的上空,所以这算是有新人生成就解锁了(获得了超高海拔上网发文徽章)

苹果iOS app审核经验谈——IPv6

背景 最近有一个产品需要在Apple AppStore 上架,算是所谓首审(initial review)。一直听说上架过程中有很多麻烦事,也确实看到过很多国内外开发者鲜活的被拒实例,各种吐槽审核机制的严格。由于苹果app审核流程这种「宗教和神」(可能言之有过)一般的存在,同时也衍生出了很多所谓中介帮快速过审的服务(类似黄牛代拍沪牌)。 这次主要谈一下审核过程中的遇到的一个问题,以下是苹果审核团队就此问题的邮件回复原文: We discovered one or more bugs in your app when reviewed on iPad/iPhone running iOS 11.2.2 on Wi-Fi connected to an IPv6 network. 大意就是在IPv6网络下,审核的人发现会出现问题。同时还可以获取到其文中所指的问题的体现截图,从截图看,确实是当时有需要联网获取的内容无法获取(或者还未获取到)导致的无法显示。 解决方案 如果你也收到了类似问题反馈,并且通过搜索引擎找到的本文,想要快捷的答案和解决方案而并没有太多耐心看完下文的话,那么我先在这里表述这个问题的正确解决方案: 根据文后参考文档中第一1、第二2篇检查自己的app实现,确定没有使用IPv4的IP显式建立IPv4的TCP,UDP socket的情况。因为在NAT64环境下,操作系统会将你的目标IPv4地址如 114.114.114.114 转换为 64:ff9b::114.114.114.114 发送到macOS模拟的节点,你写死了他就不干,具体有空请研读文后参考文档中的思科白皮书3和RFC文档4。另外检查通讯实现或者所用的第三方通讯库确实是使用了苹果推荐的高层级API:NSURLSession和CFNetwork中的API。最后使用第二篇中提及的IPv6 NAT64搭建方法搞一套测试环境确认app可用。 需要尝试从美国访问你的服务所在网络,测试可达性和性能如何。 千万不要听信国内很多坊间破解文去搭建真的IPv6 only的互联网服务5,你可能可以花费一些时间和费用搞出让纯IPv6环境用户也可以访问的服务,但是这并不是目前苹果要审核的内容,目前(2018年1月)苹果绝不会通过纯IPv6的互联网出口去测试访问你的服务并且要求可达。 以上是你真正需要去做的内容。 苹果提及的IPv6到底是怎么回事 IPv6网络从2011年、2012年那会儿谈及IPv4地址耗尽的事时开始就一直在大肆宣传要迭代转变,但是实际商用层面的转变速度非常慢,国外的很多ISP和IDC虽然在Infrastructure层面脚步更快一些,但是路离铺到用户家门口还会有一长段时间。根据思科的白皮书,目前我们可以接触到IPv6环境的方式大概有3种类型: Dual stack这种方式下你的接入商给了你同时支持IPv4和IPv6协议栈的网络, 针对有IPv6支持的服务,可以走v6,针对大部分还只支持v4的服务依旧走v4的协议。这种类型目前的普及率还很低,在国外部分ISP接入下已经实现,国内有些大学提供的互联网接入也是这样的。注意:此模式并非苹果测试审核环境的要求 Tunneling除了以上的第一种是纯ISP接入给用户时就提供有IPv6支持外,这里的Tunneling和下面的Translation都不需要ISP支持。从图示可以简单理解为即使ISP提供给你的是v4的接入,但是只要有其他第三方tunneling服务提供商给你提供4转6(6in4)的隧道服务,那么我们可以通过在即有的v4协议栈下模拟出v6的高层级协议栈(道理和VPN一样)。由此,如果提供此服务的那一头所连接的是整个实际互联网的IPv6世界的话,相当于让只有IPv4接入的你进入了纯IPv6的互联网(虽然那边目前犹如北极南极般荒凉)。注意:此模式并非苹果测试审核的要求,但是有些国内坊间误导文就让你一步步干这事 Translation这种模式也就是苹果在其开发者文档中提及的让你用macOS系统可以自己简单搭建一套纯IPv6的内网环境。你的macOS电脑作为NAT64地址转换和路由角色,一头(通常用有线)连接IPv4可以通向整个IPv4的互联网, 一头(通常用WIFI开hotspot)所谓的纯IPv6内网连测试iOS设备。既然如此,其实苹果的审核测试项也就是让通讯数据在iOS设备到macOS电脑这段跑在IPv6协议栈上而已,通过macOS的NAT64后一直到真正的服务所在设备该还是IPv4的大环境下还就是如此。事实上苹果的官文中也就这点特意很明确的表达过了: If you have a… Continue reading 苹果iOS app审核经验谈——IPv6

MySQL中sql_mode、隐式类型转换、5.6/5.7的默认配置引发的问题

先介绍下标题中的三个锅 sql_mode 以下是MySQL官网文档原文: The MySQL server can operate in different SQL modes, and can apply these modes differently for different clients, depending on the value of the sql_mode system variable. DBAs can set the global SQL mode to match site server operating requirements, and each application can set its session SQL mode to its own… Continue reading MySQL中sql_mode、隐式类型转换、5.6/5.7的默认配置引发的问题

关于 MAC OSX El Capitan 10.11 中 引入的安全机制和非签名内核扩展

背景 升级最新的MAC OSX El Capitan已经有段时间了,事实上最近系统已经更新到了10.11.2,也就是该大版本的第2个update。我有一台2011年的老Macbook Pro 15,我相信应该是其做工的问题,蓝牙信号很不好。拿去当地天才吧看过,确认了这个问题,但是告知我这款机器是将蓝牙天线集成在屏幕中的,如果要解决这个问题就需要连屏幕一起换了,于是我就算了。我需要在这台机器上使用蓝牙耳机,于是单独买了一个USB的蓝牙dongle(El Capitan直接支持一些外接USB蓝牙适配器,Broadcom 20702A1芯片,0a5c:21e8这款是大路货),这个问题也就算曲线解决了。但是我是一个不升级最新版本不舒服的人,也因为这点后面问题来了。 MAC中蓝牙驱动固件机制 大部分的Broadcom蓝牙设备使用一种叫RAMUSB的系统机制,这种机制允许系统把该设备的固件即时上传,但是每次关机或者重启就会丢失。在Broadcom提供给windows的驱动中,broadcom的驱动做法是每次开机就会上传一次最新的驱动。但是Mac OSX中不是这样的。所以针对我这款USB蓝牙适配器,虽然即插即用,但是固件版本是v4096(后续更新后可以到v5555)。那么自然就需要把类似windows中的做法也在mac中实现就可以了 BrcmPatchRAM 这方面老外总是早早的就有了想法,并且有了proof of concept的实现。BrcmPatchRAM就是这样一个可以帮我完成上节问题的开源项目,放在github上。实现方法大概如下: 以Mac OSX的内核扩展形式在每次开机时加载一次,将从windows驱动中提取出来的zhx格式固件上传,这样设备就可以用新版固件运行。 签名的内核扩展 好东西是有了,但是新问题又来了。早在OSX 10.8的时候,苹果就以安全为名义引入了需要签名的内核扩展,意思就是说不是随随便便的就可以写一个kext,放到系统中让系统在启动时一起加载的。OSX系统需要审查!只有获得苹果签名的kext才可以正常加载。而这类实用的野路子kext是肯定不会获得苹果的签名的。幸好在桌面系统上,苹果并没有严格到将以上规定设计成绝对。事实上一直以来都留了一个官方的开关,允许用户主动关闭这种审查。当然后果就是给恶意代码也开了方便之门。到了El Capitan,苹果将这个开关变了个法子,引入了所谓的SIP机制。一直到El Capitan的DP8之前,其实SIP是有明显的漏洞的。根据Pike的说法,他找到了在DP8之前根本不需要关闭SIP就可以随便植入不签名的kext的玩法。有兴趣的可以自翻看那篇博客,内容很是干货。 植入未签名kext 不管是SIP还是之前的kext-dev-mode,其实从安全性角度是很有必要打开的,确实我们平时实际使用中,针对弹出的要sudo权限的密码窗口,基本是直接给的。真的碰上一些恶意软件也是麻烦。截至目前10.11.2,苹果是允许你暂时关闭SIP,然后将未签名的kext复制到/System/Library/Extensions(俗称/S/L/E)。重启机器,这样osx系统会根据最新的改动,重新生成/System/Library/PrelinkedKernels/prelinkedkernel这个文件。然后我们可以将SIP重新打开,后续只要prelinkedkernel没有变化就没问题(一般在系统update时这个文件肯定会变。所以未签名的kext在系统小版本号更新后都会失效,需要重新开关SIP重启系统)。

Macbook Pro 15 inch Early 2011 保修记

机器说明(Spec) MacBook Pro (15 英寸, 2011 年初机型) 型号标示:MacBookPro8,2 Model Numbers: MC723 官方的Spec说明 上市日期:2011年2月24日 上市苹果官方定价 $2199(未含税) 购买于2011年4月,港行 使用习惯,频率 重度用户,机器基本长期处于开机状态,不是开机也是处于睡眠状态,不关机。电池充电周期449次,习惯外接显示器或者电视机,游戏较少,高清视频较多,主要用于程序开发。 自定义硬件改动 购入后没多久内存换成8G(4Gx2),后来又换成16G(8Gx2),2012年中换了256G SSD,没有双硬盘。2014年末尝试从某宝购入特殊渠道的该机型适配蓝牙4.0模块以支持Yosemite的handoff等功能,某宝上东西太不靠谱,未遂。 故障出现,诊断 3年多来,有偶尔的几次屏幕变花现象出现,重启后都能恢复。羊年初某天在看美剧Scorpion,外接的电视机,到某精彩时刻突然黑屏,第一反应觉得可能是视频文件下载有问题,准备查看时发现机器已经毫无反应,伴随风扇狂转,任何操作都没用,只能强关。再开,开机白底画面出现横条纹,无法进入OS。想起该机型一直以来都在网上有很多显卡缺陷的负面报道,初步认定我也中招了。 类似故障集体信息 想着机器也用了近4年了,此时坏了也不是特别不爽,只是时间不对,尚处于Apple可能会不久更新mac产品线之际,遂上网看看有啥临时再拖延拖延的法子。仔细一查,网上各种故障案例在此机型特别集中,2012年和2013年无数网友中招,多是过保的机器,有些去官方花了4K左右的大洋修了,有些便宜些自己找其他奸商搞定了。虽然如前所述早有耳闻,但是这时候看到这些报道就会看得特别认真啊。#算了,说多了都是泪。Facebook有专门的Page,change.org也有专门的请愿Apple更换或者免费维修这类问题。看着这些报道,此时对Apple产生了极大的仇恨啊。 集体诉讼 逛着逛着,发现一则报道说2014年10月已经有律师行正式以几个原告名义向Apple提起集体诉讼了,一纸诉状上写明这款机型的这个问题是因为当时为了满足欧盟法规,Apple使用了无铅焊接工艺,律师认为该技术不成熟,在温度变化明显的时候就会脱焊,于是这种情况时间长了显卡就从主板上虚焊了。欧洲以外地区并没有这个规定,Apple为了节约成本就在全球一并使用该焊接工艺,于是就悲剧了。该诉讼几周前判了,Apple败了。于是这厮不得不正式严肃的面对这个产品缺陷了。 苹果公告 Apple败诉后,在2月19日外媒报道Apple对此机型有延长保修计划了,再往后一看,2015年2月20日在美加实施(心想难道美加人民又特权了?) 再往后一看,其他国家地区2月27日开始受理,一直到2016年2月有效。瞬间豁然开朗,但是对于其中细节媒体和Apple都没有详述,如何维修,换的主板是否还会有这类问题?2016年后再出问题怎么办?(祈祷吧) 维修 随即约了27号的GeniusBar,下午去的,说肯定不能当天拿机器的,具体哪天可以取机当时也不能确定,后续等电话吧。卸了SSD带回,机器就留给他们了。后来通知我3月2日取机器,到此维修结束。问题暂时解决。Apple官方的保修单子上说本次保修涉及的费用是4110人民币,如果没有这次延长保修计划,来官方维修就是这个价格。好在之前苹果公告说以前因为此问题而花钱维修了的可以退回那些冤枉的费用。 利益关系说明 本人没有在Apple极其附属公司就职,没有持有Apple相关有价证券。习惯使用Apple产品及其相关生态环境。

独立软件开发者的日子

前些天看了一篇独立软件开发者写的自身2014年的概况,原文在此。作者是Mac以及iOS上的一款著名API手册软件Dash的开发者。下面将原文内容先大致介绍下: 年收入 这里年收入是指从Dash这一款软件得来(估摸作者还干些别的活,没算在这里),包括App store以及直接从其网站购买的都算。税前27万刀。其中App store有18万刀多。(说明有7万刀给苹果拿了) 作者还给出了每月的收入情况,最多的接近4万刀,最少的也大于1.5万刀。 工作量 看了收入情况,那么我们再来看看作者的工作时间。作者给出的统计数据只包括周一到周五的,想必也是比较悠闲的开发者,周末应该不怎么码字。最多的是2月,平均每天工作了10小时,因为2014年2月作者发布了新版的Dash 2.0。其余平均分布在1-7小时间。真心算的上悠闲。或者也说明了开发者本身功力深厚。 部分细节披露: 2月: 为Dash 2.0 赶工 5月: 基本在玩暴雪的游戏炉石传说 8月: 度假3周 9-10月: 搞了Dash for iOS的版本 11月: 度假2周 12月: 又基本在玩炉石 总开销 这位开发者的网站是放在Linode 上的,大概每月要走掉20TB流量(估摸所有的API文档都是放在了自己虚机上了),全年的Linode虚拟机开销是2400刀。然后还有一个网站uptime监控服务($130)和一个crash sdk的第三方sdk监控其app的crash情况汇报($100),都是可以忽略不计的成本了。 作为一个独立开发者,自由的时间获得如此的收入情况在美帝也算是很不错了。我认为很大程度应该还是其app真的有帮到很多开发者,要知道这款app是一款API手册查询工具,所有买单的用户应该基本也都是开发者,我也买了这款$20的Mac版本,事实上这款软件你不付费也可以使用(每次查询需要等8秒才显示结果,其实这个设置挺二货的我觉得),是Freemium的盈利模式。你不用这款app本身也可以查询到很多文档,这款app只是帮助你更好的统一的离线获取开发资料。而这些资料本身并非作者的,同时本来就可以在线免费获取到。考虑到以上种种,这样一款非刚需的参考手册型app的表现真的很不错。最后我还是想说这款app本身做的很好,响应速度快,用起来很顺手,又可以和几乎所有的常用IDE或者编辑器结合。  

iMessage垃圾消息报告

如果你是一个苹果产品的使用者,无论是Mac电脑,iPhone或者是iPad,你会感觉到苹果自带的iMessage服务是很不错的,尤其是在更新到iOS8以及Yosemite后,iMessage增加了发送音频视频以及地理位置的功能。但是和国内手机号码绑定的iMessage服务我之前是不敢打开的,其原因是因为每天5-10条甚至更多的垃圾短信。最近换了iPhone 6 plus后又捉摸着想打开iMessage服务试试,刚开2天,各种赌场,发票等信息又蜂拥进来。心想苹果到底有没有好好管管这样的服务滥用情况呀。于是Google了一把苹果对于iMessage spam的整治策略。 苹果出招 根据苹果官方网站的介绍:http://support.apple.com/en-us/HT202747 ,目前苹果对于iMessage的滥用情况只能通过用户投诉的形式协助解决。用户需要将以下内容一并发送到苹果官方的投诉专用邮箱:imessage.spam@icloud.com 垃圾短信截图(按住Power + Home键可以截图) 发送者的邮箱地址或者手机号码(苹果懒,其实这个信息截图中应该有,还要我们用文本发送) 你接收到信息的日期和时间(建议加上时区 CST, 如果你在大陆的话) 其中,注意:给苹果报告的垃圾短信必须要是经由iMessage服务发来的(一般iMessage服务器的垃圾短信都是以邮箱地址作为发送者ID,当然以上官网链接中也有很明确的截图示意如何判别垃圾短信来源),如果是经由运营商发来的垃圾短信还请向当地运营商投诉。 另外,虽然苹果官方没有说明会如何处理遭到投诉的iMessage ID,但是从其他渠道了解到苹果对于核实为滥用iMessage服务的Apple ID封杀还是比较给力的,因为其不光会封锁这个Apple ID,连同对应的iOS设备也会一并封杀(不知道针对从Mac电脑上发出的情况怎么处理),也就是说那台iPod Touch或者iPad就无法在发送iMessage了(应该不会有人壕到用iPhone来发垃圾短信吧?),贩子要再继续就要买额外的二手设备。 众包反垃圾 所以让我们一起努力来让iMessage变得更加干净吧,只需要每次接收到垃圾的iMessage信息时,截个图,人肉识别出图中的ID和接收到的时间,给 imessage.spam@icloud.com 去个邮件,相信至少这个ID以及其背后的设备几天后就没法再骚扰任何人了,如果举报的人越多,贩子的损失也就越大,其发送垃圾短信的成本就会越来越高,最后发现得不偿失自然就没人干了。  

哪些是程序员常说的谎言

程序员一般所说的谎言主要是以下这些或者其变种: 这个做法确实不太好, 我稍后会修复的。 这任务很容易。 我马上就要做好了。 就算是有bug,也不可能在我写的那部分代码里。 我会在下一版中把单元测试补上。 我稍后会把代码中的注释和文档补上。 这不是一个bug,功能本来就是这样的。 马上就要做好了,我会在今天晚上前搞定的。 在我的机器上是好的。 差不多90%已经好了。 我在深入调研需求,稍候就开始开发工作。 这只是一种临时解决方案,不会被用在最终的生产环境 我会把它加入到待办事项列表中 我觉得这是浏览器有问题吧。

程序员应该如何写周(日)报

你是否在一家需要写周报或者日报的公司?这占用了你平均每天一刻钟甚至半小时的时间吗? 恩…没错,听着确实有些痛苦。至少我是这么觉得的。事实上目前我也正处在这样的处境下,那么就让我们看看如何来有效使之变得容易一些。 以下的内容主要是针对程序员的,或者说是所有使用主流版本控制软件的工作人员。下面主要讲解我使用过的2个CVS工具的方法:SVN 和 Git 开练: 首先需要你有很好的提交习惯,使工作有序: 比如你需要先将今天需要完成的工作列个To Do list,假设如下: 隐藏导航栏 把某个按钮从红色变成蓝色 纠正主页面的字体显示问题 重构某个类 加入twitter支持 一个一个任务都列清楚,并且当你在把按钮从红色变成蓝色的时候,千万不要去碰导航栏。也就是一个一个任务的完成,不要交叉或者同时。当你确认一个任务完成后,立即提交(COMMIT),并且在你的COMMIT MESSAGE里填上详尽的完成内容。这一步就是帮你自动生成周报或者日报内容的关键。 如此,你一个个任务的完成,所有COMMIT MESSAGE的累积就是你当天的日报了。 导出 下面我们看看如何从Repository中导出生成: SVN #!/bin/bash # SVN Log export script for the current day # This script is made to make your job easier and feel free to use / modify it. # Written by @supermarin |… Continue reading 程序员应该如何写周(日)报

自由的公司环境是造就优秀程序员的摇篮

优秀的程序员都有什么共同之处?工作经验?薪水待遇?完成任务花的时间的多少?事实证明,跟这些都不相关。 很奇怪,来自同一个公司的程序员们的表现都基本上处在同一水平。为什么? 这最重要的因素是他们所处的工作环境能给他们提供的舒适程度:“… 最能干的程序员所工作的公司几乎都能给他们最大的隐私权,最大的个人空间,最大的控制他们的物理空间的自由度,最少的外界干扰。” 来自: 《Quiet: The Power of Introverts in a World That Can’t Stop Talking》: 为了证明这些,DeMarco和他的同事Timothy Lister设计了一个称之为“Coding War”竞赛的研究计划。这个竞赛的目的是要能清楚最好的程序员和最烂的程序员都有哪些特征;大约有来自92个公司的600名程序员参加了竞赛。他们每个人都要设计,开发,测试一个程序,在上班时间,在他们平时工作的地方完成。每个参与者都有一位来自同一个公司的同伴。然而,他们之间相互独立,没有任何的联系。后来证明这是这个竞赛的一个至关重要的特点。 当结果出来后,这些人的编程能力被证明有着巨大的差距。最优秀的和最差的之间的效能比是10:1。顶级程序员比中等水平的程序员也要高出2.5倍。当 DeMarco 和 Lister 试图解开是什么导致这样惊人的差距时,那些他们以为可能的因素——比如工作阅历,薪资待遇,甚至完成竞赛题花去的时间长短——这些都跟这样的结果关系不大。具有10年工作经验的程序员并不比只有2年经验的表现的优秀。有一半处于中上等水平的程序员的收入比余下一半处于中下等水平的程序员的收入要少10%——尽管前者比后者的能力有的要高出两倍。那些编写出“零错误”程序的程序员相较于那些程序中有错误的程序员,他们完成竞赛题所花的时间更少,而不是更多。 这是一个迷,但是他们发现了一个很有意思的线索:来自相同公司的程序员或多或少都处在同一能力水平,即使是他们并不在一起工作。这是因为那些顶级程序员所工作的公司几乎都能给他们最大的隐私权,最大的个人空间,最大的控制他们的物理空间的自由度和最少的外界干扰。最有效率的程序员中有62%的人说他们的公司尊重他们的隐私,而相对的那些表现最差的程序员中只有19%这样说。最差的程序员中有76%的人说经常被没必要的因素干扰,而那些最优秀的程序员中只有38%这样说。