最近将用了一年又两个月 iPhone 6s 送修了，我的 6s 因电池问题而导致的频繁的关机现象，同时屏幕左上角还存在暗角问题。整个过程共计 8 天，算有点折腾，写文章给大家参考参考吧。现象我是 2015 年 9 月第一批 iPhone 6s 用户，当时还买了 AppleCare+。手机一年用下来，主要有这些问题：电池问题：常常在 30% ~ 40% 电量的情况下就会自动关机，此时环境温度至少有 10 度；屏幕问题：左上角有一个暗角，在晚上尤其明显，强迫症表示无法接受；外壳斑点问题：背面有一些因铝氧化而导致的斑斑点点，有点难看。电池问题是这两个月来发生的比较频繁，而后面两个问题存在有一段时间了。图 1：屏幕暗角问题图 2：外壳的斑点问题积累了这么多问题，于是这次趁着苹果的电池更换计划上门了。Apple Store 上门本来是想约天才吧的，然而天才吧一直预约不上，我又不想把身份信息提供给黄牛然后花钱预约，于是就决定直接去店里排队碰碰运气。上周周二的中午，我就去西湖 Apple Store 排队了，那会来排队的基本上全是因为电池问题拿着 6s 过来的用户。但是只排了一会，Apple Store 的店员就表示今天的服务已满名额，处理不过来了，要求我们上网去预约，或者找授权服务商。郁闷之余，我当场尝试预约并且给店员看，还是没有名额，店员也表示无奈，说挑个时段再预约。心实在是太累了，不想再通 ...继续阅读 (75)

今天 Manico 2.2 正式审核通过，已经登录 Mac App Store 了。这个版本除了修复一些可能导致崩溃的 Bug 以外，还加入了一个「用量」功能，即：统计你每天使用 Manico 的次数。打开新版本的「首选项」，在「关于」边上，你可以看到「用量」这个标签。点击它后可以看到一个图表和相关统计信息，显示着最近几天你每天使用 Manico 的情况。目前该功能只统计每天激活和切换 App 的次数，以后应该还会增加一个显示被切换最多的 App 的视图吧。这个功能目前只在 macOS 10.12 上可用，本来在 10.11 上，我通过条件判断语句会显示一行「该特性在 10.11 上不可用」等字样的，哪知真实的情况是会 Crash。不知道是我写的不对呢，还是 Swift Runtime 的问题。总之在这里对仍在 10.11 的用户们说声抱歉，该功能暂时不可用，待我解决问题后再发新版本。做完这个功能后，我看到自己平均每天用 Manico 上百次。如果按每次使用节省几秒来算，每天也因此节省成百上千秒，也是以小时来计的。所谓效率型工具，是更方便同时更便捷的达成目的工具，所以 Manico 算是一个合格的效率型工具吧，尽管它解决的是一个小问题。总之，增加这么个小功能，希望所有用户都能更清楚的知道自己有多依赖 Manico。点击此处前往 Mac App Store 免费体验 Manico，或 ...继续阅读 (87)

今天 Manico 2.2 正式审核通过，已经登录 Mac App Store 了。这个版本除了修复一些可能导致崩溃的 Bug 以外，还加入了一个「用量」功能，即：统计你每天使用 Manico 的次数。打开新版本的「首选项」，在「关于」边上，你可以看到「用量」这个标签。点击它后可以看到一个图表和相关统计信息，显示着最近几天你每天使用 Manico 的情况。目前该功能只统计每天激活和切换 App 的次数，以后应该还会增加一个显示被切换最多的 App 的视图吧。这个功能目前只在 macOS 10.12 上可用，本来在 10.11 上，我通过条件判断语句会显示一行「该特性在 10.11 上不可用」等字样的，哪知真实的情况是会 Crash。不知道是我写的不对呢，还是 Swift Runtime 的问题。总之在这里对仍在 10.11 的用户们说声抱歉，该功能暂时不可用，待我解决问题后再发新版本。做完这个功能后，我看到自己平均每天用 Manico 上百次。如果按每次使用节省几秒来算，每天也因此节省成百上千秒，也是以小时来计的。所谓效率型工具，是更方便同时更便捷的达成目的工具，所以 Manico 算是一个合格的效率型工具吧，尽管它解决的是一个小问题。总之，增加这么个小功能，希望所有用户都能更清楚的知道自己有多依赖 Manico。点击此处前往 Mac App Store 免费体验 Manico，或 ...继续阅读 (63)

昨天半夜看到一封邮件《Announcing Server APIs work group》，让我激动地去发了一条微博。简单地说，Swift 官方成立了一个Server APIs Work Group，这个小组的目标是在当前 Swift 的基础上，做一套纯 Swift 的、跨平台的、专门面向 Server 的底层库，提供给 Web Framework/Backend 的开发人员使用。也就是说，Swift 官方携手社区，正式进军 Sever-Side 开发领域了。Server APIs 的由来话说 Swift 从诞生之初就定目标为一个通用的编程语言，到了不久前 Swift 3.0 正式发布，不仅已经正式支持了 Linux 平台，社区和企业也萌现了一堆 Web 相关的架构，比如 IBM 的 Kitura、创业公司 Perfect，来自社区的 Vapor 和 Zewo。可以说这个生态已经渐渐起来了，尽管还比较早期和稚嫩。那么 Swift 官方成立 Server APIs Work Group 的意义是什么呢？在我看来，就是起到「催化剂」作用。如果你研究过当下 Kitura, Vapor, Zewo 等基于 Swift 开发的 Web 框架，就会发现他们各种去实现或者包装了一堆非常底层或者常用的库：底至 HTTP 协议、WebSocket、SSL，高至 JSON、XML 的解析。这是因为 S ...继续阅读 (57)

昨天半夜看到一封邮件《Announcing Server APIs work group》，让我激动地去发了一条微博。简单地说，Swift 官方成立了一个Server APIs Work Group，这个小组的目标是在当前 Swift 的基础上，做一套纯 Swift 的、跨平台的、专门面向 Server 的底层库，提供给 Web Framework/Backend 的开发人员使用。也就是说，Swift 官方携手社区，正式进军 Sever-Side 开发领域了。Server APIs 的由来话说 Swift 从诞生之初就定目标为一个通用的编程语言，到了不久前 Swift 3.0 正式发布，不仅已经正式支持了 Linux 平台，社区和企业也萌现了一堆 Web 相关的架构，比如 IBM 的 Kitura、创业公司 Perfect，来自社区的 Vapor 和 Zewo。可以说这个生态已经渐渐起来了，尽管还比较早期和稚嫩。那么 Swift 官方成立 Server APIs Work Group 的意义是什么呢？在我看来，就是起到「催化剂」作用。如果你研究过当下 Kitura, Vapor, Zewo 等基于 Swift 开发的 Web 框架，就会发现他们各种去实现或者包装了一堆非常底层或者常用的库：底至 HTTP 协议、WebSocket、SSL，高至 JSON、XML 的解析。这是因为 S ...继续阅读 (56)

昨天看了 Swift 官方发出的这篇《Whole-Module Optimization in Swift 3》，了解了一些 Whole-Module Optimization 的原理。简单地说，Whole-Module Optimization（全模块优化，以下简称 WMO），即在编译项目时，将同属于一个 Module（可以理解为一个 Target、一个 Package）的所有源代码都串起来，进行整体的一个分析与优化，区别于 Single-File Optimization（单文件优化，以下简称 SFO），WMO 可以更好的统筹全局，去 inline 函数调用、排除死函数（即写了却从不调用的函数）等等，大幅优化最终目标文件，使性能提升 2~5 倍。我对性能的提升没有疑议，但对其中提到的「编译时间（Compile Time）」的优化产生好奇。既优化性能，也同时减少编译时间？于是我做了一个实验了解了不同的编译器优化选项的不同效果。实验：测试 Optimization Level 在 None（不优化）、SFO、WMO 下分别对编译速度的影响实验对象：基于 Swift 3 的奇点 for 微博，约 24,000 行代码实验方式：在 Debug 模式下分别选择一档优化，编译测试时间。Xcode 配置：显示编译时间： defaults write com.apple.dt.Xcod ...继续阅读 (62)

昨天看了 Swift 官方发出的这篇《Whole-Module Optimization in Swift 3》，了解了一些 Whole-Module Optimization 的原理。简单地说，Whole-Module Optimization（全模块优化，以下简称 WMO），即在编译项目时，将同属于一个 Module（可以理解为一个 Target、一个 Package）的所有源代码都串起来，进行整体的一个分析与优化，区别于 Single-File Optimization（单文件优化，以下简称 SFO），WMO 可以更好的统筹全局，去 inline 函数调用、排除死函数（即写了却从不调用的函数）等等，大幅优化最终目标文件，使性能提升 2~5 倍。我对性能的提升没有疑议，但对其中提到的「编译时间（Compile Time）」的优化产生好奇。既优化性能，也同时减少编译时间？于是我做了一个实验了解了不同的编译器优化选项的不同效果。实验：测试 Optimization Level 在 None（不优化）、SFO、WHO 下分别对编译速度的影响实验对象：基于 Swift 3 的奇点 for 微博，约 24,000 行代码实验方式：在 Debug 模式下分别选择一档优化，编译测试时间。Xcode 配置：显示编译时间： defaults write com.apple.dt.Xcod ...继续阅读 (56)

今天早上，我发布了奇点 2.2 版本。这算是一个有里程碑意义的版本，因为它新增了一个「精选收藏」功能。这是我提供的一个独立于微博官方的一个特色功能，想借此做一点有意思的尝试。正如字面意思，「精选收藏」是一些精选的收藏，是一个将诸多奇点用户所收藏的内容精选出来的一个内容。如果你是奇点的老用户，一定知道从 1.0 版本开始，「收藏」这个 Tab 一直是放在比较重要的第三个的位置，而现在因为有 5 个 Tab，则是位于中间这个显眼的位置。一直以来都有用户问我：为什么奇点把「收藏」功能做的这么明显？这时我通常会回一句：「微博的 Web 版本也是把收藏放在很显眼的位置的。」如下图：当然官方这么做不是我这么做的理由，毕竟微博移动版本是把收藏功能做的很深的，我不太理解 Web 和移动这么不统一的原因，但是我知道我这么做的理由：微博之于我是一个信息平台，我看到有用的内容就会收藏、整理并再次回顾它，我想要突出这个功能，所以收藏功能在奇点里是一个核心功能。但是在之后我用数据去跟踪用户使用情况时，我却发现「收藏」是用户点的最少的一个的 Tab，如图：主页有 80% 的点击量，订阅有 10% 的点击量，而收藏仅 3%。显然这个占据着主要位置的 Tab 并没有好好利用起来。于是我结合了之前的一个 idea，就做了这个「精选收藏」功能。这个功能简单来说两张截图可以说完：首先在中间收藏的这个 Tab 里，有两块 ...继续阅读 (53)

今天早上，我发布了奇点 2.2 版本。这算是一个有里程碑意义的版本，因为它新增了一个「精选收藏」功能。这是我提供的一个独立于微博官方的一个特色功能，想借此做一点有意思的尝试。正如字面意思，「精选收藏」是一些精选的收藏，是一个将诸多奇点用户所收藏的内容精选出来的一个内容。如果你是奇点的老用户，一定知道从 1.0 版本开始，「收藏」这个 Tab 一直是放在比较重要的第三个的位置，而现在因为有 5 个 Tab，则是位于中间这个显眼的位置。一直以来都有用户问我：为什么奇点把「收藏」功能做的这么明显？这时我通常会回一句：「微博的 Web 版本也是把收藏放在很显眼的位置的。」如下图：当然官方这么做不是我这么做的理由，毕竟微博移动版本是把收藏功能做的很深的，我不太理解 Web 和移动这么不统一的原因，但是我知道我这么做的理由：微博之于我是一个信息平台，我看到有用的内容就会收藏、整理并再次回顾它，我想要突出这个功能，所以收藏功能在奇点里是一个核心功能。但是在之后我用数据去跟踪用户使用情况时，我却发现「收藏」是用户点的最少的一个的 Tab，如图：主页有 80% 的点击量，订阅有 10% 的点击量，而收藏仅 3%。显然这个占据着主要位置的 Tab 并没有好好利用起来。于是我结合了之前的一个 idea，就做了这个「精选收藏」功能。这个功能简单来说两张截图可以说完：首先在中间收藏的这个 Tab 里，有两块 ...继续阅读 (62)

最早知道IGListKit这个库是在try! Swift NYC这个会议上，这是由 Instagram 开发的应用在自身 App 上的一个 UI 组件库。当时 Twitter 上的@janlay还提了一个问题：「话说都 Swift 写了，为啥还要带 IG 前缀…」今天这个库正式开源，一些问题也将得到解答，我想也趁这个机会聊聊我所了解的当下的 iOS 开发趋势。首先，IGListKit 并不是由 Swift 开发的一个库，它依然使用了 Objective-C 为主要语言开发。我想是因为 Instagram 作为已经五年以上的 App，也就是一定是一个 Objective-C 项目。它运作良好，没有特殊原因没必要用 Swift 重写。所以它的核心 UI 组件库 IGListKit 依然是 Objective-C 也是正常的。其次，尽管 IGListKit 不是 Swift 写的，但是你不得不忽视 Swift 在这个库中的存在感，列举一二：IGListKit 对 Swift 项目提供完整支持，简单来说，nullable/nonnull、genercis 的采用会让你用它时感受不到背后是 Objective-C 还是 Swift 在提供支持；IGListKit 的 demo 是 100% Swift 写的；IGListKit 的文档的示例代码也是 100% Swift 代码。综上所述，IG ...继续阅读 (43)

最早知道IGListKit这个库是在try! Swift NYC这个会议上，这是由 Instagram 开发的应用在自身 App 上的一个 UI 组件库。当时 Twitter 上的@janlay还提了一个问题：「话说都 Swift 写了，为啥还要带 IG 前缀…」今天这个库正式开源，一些问题也将得到解答，我想也趁这个机会聊聊我所了解的当下的 iOS 开发趋势。首先，IGListKit 并不是由 Swift 开发的一个库，它依然使用了 Objective-C 为主要语言开发。我想是因为 Instagram 作为已经五年以上的 App，也就是一定是一个 Objective-C 项目。它运作良好，没有特殊原因没必要用 Swift 重写。所以它的核心 UI 组件库 IGListKit 依然是 Objective-C 也是正常的。其次，尽管 IGListKit 不是 Swift 写的，但是你不得不忽视 Swift 在这个库中的存在感，列举一二：IGListKit 对 Swift 项目提供完整支持，简单来说，nullable/nonnull、genercis 的采用会让你用它时感受不到背后是 Objective-C 还是 Swift 在提供支持；IGListKit 的 demo 是 100% Swift 写的；IGListKit 的文档的示例代码也是 100% Swift 代码。综上所述，IG ...继续阅读 (46)

今天下午，我提交了基于 Swift 3.0 的奇点2.1.1 版本，主要是适配了 Swift 3.0 + 一些 Bug 修复。在适配 Swift 3.0 的过程中，我记录了一些常见的问题，相信所有在适配过程中的朋友都会遇到，于是总结这么一篇文章分享一下。前言奇点项目是一个小型的纯 Swift 的 iOS 项目，十余个第三方库 + 超两万行代码。它是我在 2014 年一开始就接触 Swift 以来的一个 Objective-C 项目用 Swift 重写的实验作品，后来把它做成了产品推出来。所以它存在的价值之一就是为了适配新一代 Swift 😂所以 Swift 3.0 出来后，我咬咬牙，就决定立即开始适配它了。大概花了约一个晚上+一个白天的时间我就完成了对适配工作，同时淘汰了一些不兼容 Swift 3 的三方库，可以说是神清气爽。那么下面我就开始一一列举适配 Swift 工作中遇到的问题和一些新习得的概念吧。Any vs AnyObject将项目里的 AnyObject 转成 Any 可能是大家遇到的第一件适配大事。如何解释这个变化呢？在 Swift 3 之前，我们可以写完一个项目都只用 AnyObject 来代表任何类型，几乎不用与 Any 类型打交道。在 Swift 3 当中，你会发现你不得不与 Any 类型打交道了。这是因为 Swift 3 针对 Any 和 AnyObject ...继续阅读 (49)

今天下午，我提交了基于 Swift 3.0 的奇点2.1.1 版本，主要是适配了 Swift 3.0 + 一些 Bug 修复。在适配 Swift 3.0 的过程中，我记录了一些常见的问题，相信所有在适配过程中的朋友都会遇到，于是总结这么一篇文章分享一下。前言奇点项目是一个小型的纯 Swift 的 iOS 项目，十余个第三方库 + 超两万行代码。它是我在 2014 年一开始就接触 Swift 以来的一个 Objective-C 项目用 Swift 重写的实验作品，后来把它做成了产品推出来。所以它存在的价值之一就是为了适配新一代 Swift 😂所以 Swift 3.0 出来后，我咬咬牙，就决定立即开始适配它了。大概花了约一个晚上+一个白天的时间我就完成了对适配工作，同时淘汰了一些不兼容 Swift 3 的三方库，可以说是神清气爽。那么下面我就开始一一列举适配 Swift 工作中遇到的问题和一些新习得的概念吧。Any vs AnyObject将项目里的 AnyObject 转成 Any 可能是大家遇到的第一件适配大事。如何解释这个变化呢？在 Swift 3 之前，我们可以写完一个项目都只用 AnyObject 来代表大多数实例，好像不用与 Any 类型打交道。但事实上，Any 和 AnyObject 是有明显区别的，因为 Any 可以代表 struct、class、func 等等几乎所有 ...继续阅读 (52)

继九月初奇点 2.0 变成「免费+内购」的 App 之后，奇点一下子多了很多用户，大家都很喜欢这个版本。可以说过去一个月的努力有了成果。过去半个月，我再接再厉，今天，我隆重宣布：支持 iPad 和 iOS 10 的奇点 2.1 正式发布啦！一直以来，大家喜欢奇点的的原因都是干净、清爽。而很多用户都有一个作为一个强大的生产力工具——iPad，他们也想要在 iPad 上也有干净、清爽的微博阅读工具。我一直没动力开发 iPad 版本，一是自己没 iPad Pro 这种能 Split View 的工具，二是适配 iPad 工作不想简单的拉宽，要做就稍微好一点，需要很多工作量，就一直没动手。这次奇点 2.0 发布，又有用户向我提了类似需求，于是我一鼓作气，乘着适配 iOS 10，一下子也把 iPad 的支持给做了。如你所见，奇点 2.1 完整支持 iPad 的横屏、竖屏，还有多任务的 Split View。也就是你可以一边在 iPad 上刷微博，一边做其他事情。好了，具体不多说了，总之，从这个版本开始，奇点成为了一个 iPhone/iPad 通用 App，获得了包括 Slide Over、Split View 和快捷键在内的完整 iPad 支持。此外还有其他数项体验上的更新：完美支持 iOS 10，修复在 iOS 10 下的一些问题；支持时下热门的「哆啦A梦」系列表情；支持将 GIF 图片存 ...继续阅读 (73)

继九月初奇点 2.0 变成「免费+内购」的 App 之后，奇点一下子多了很多用户，大家都很喜欢这个版本。可以说过去一个月的努力有了成果。过去半个月，我再接再厉，今天，我隆重宣布：支持 iPad 和 iOS 10 的奇点 2.1 正式发布啦！一直以来，大家喜欢奇点的的原因都是干净、清爽。而很多用户都有一个作为一个强大的生产力工具——iPad，他们也想要在 iPad 上也有干净、清爽的微博阅读工具。我一直没动力开发 iPad 版本，一是自己没 iPad Pro 这种能 Split View 的工具，二是适配 iPad 工作不想简单的拉宽，要做就稍微好一点，需要很多工作量，就一直没动手。这次奇点 2.0 发布，又有用户向我提了类似需求，于是我一鼓作气，乘着适配 iOS 10，一下子也把 iPad 的支持给做了。如你所见，奇点 2.1 完整支持 iPad 的横屏、竖屏，还有多任务的 Split View。也就是你可以一边在 iPad 上刷微博，一边做其他事情。好了，具体不多说了，总之，从这个版本开始，奇点成为了一个 iPhone/iPad 通用 App，获得了包括 Slide Over、Split View 和快捷键在内的完整 iPad 支持。此外还有其他数项体验上的更新：完美支持 iOS 10，修复在 iOS 10 下的一些问题；支持时下热门的「哆啦A梦」系列表情；支持将 GIF 图片存 ...继续阅读 (43)

刚好四个月没有更新，今天奇点 2.0 带着一些改进正式发布了。如你所见，这个版本之所以称为 2.0，最大的变化是：免费试用。确切地说，从 2.0 版本开始，奇点正式变成了一个「免费+内购」的 App。任何人都可以随时从 App Store 免费下载并体验奇点，但是会有部分功能的使用受到限制，如奇点特色的「订阅」功能，此外还有主题与字体等个性化定制。总之，免费版本的奇点依然有着比较完整的体验，待用户体验满意后可以再解锁「全功能版」，目前仅需 18 元。需要补充的是，所有 1.x 版本时候购买的老用户都将自动解锁全功能版，相当于免费升级，不需要再花一次钱。那么，对于已经使用奇点很久了的老用户们，奇点还有什么吸引人变化？当然有。本着带来更流畅的使用体验、更个性化的阅读体验，以下是 2.0 版本引入的新特性：「订阅」支持刷新了：很多用户告诉我，订阅能像主页一样刷新就好了。现在，在订阅页下拉刷新，行为和主页刷新是一样的了，如果你只想分门别类地看订阅。只需在此刷新即可；「显示与字体」处支持细体字：除了调整字体大小以外，现在你可以设置是否显示细体字了；划动图片回去的手势支持（Swipe to dismiss）：现在在看图的时候，可以用向下、向下划的动作离开看图界面了，这是一种更流畅的体验；增加「自动进入阅读器」的选项；增加支持评论并转发和转发并评论功能。此外，还修复了一些小问题：加回上个版本「丢 ...继续阅读 (52)

刚好四个月没有更新，今天奇点 2.0 带着一些改进正式发布了。如你所见，这个版本之所以称为 2.0，最大的变化是：免费试用。确切地说，从 2.0 版本开始，奇点正式变成了一个「免费+内购」的 App。任何人都可以随时从 App Store 免费下载并体验奇点，但是会有部分功能的使用受到限制，如奇点特色的「订阅」功能，此外还有主题与字体等个性化定制。总之，免费版本的奇点依然有着比较完整的体验，待用户体验满意后可以再解锁「全功能版」，目前仅需 18 元。需要补充的是，所有 1.x 版本时候购买的老用户都将自动解锁全功能版，相当于免费升级，不需要再花一次钱。那么，对于已经使用奇点很久了的老用户们，奇点还有什么吸引人变化？当然有。本着带来更流畅的使用体验、更个性化的阅读体验，以下是 2.0 版本引入的新特性：「订阅」支持刷新了：很多用户告诉我，订阅能像主页一样刷新就好了。现在，在订阅页下拉刷新，行为和主页刷新是一样的了，如果你只想分门别类地看订阅。只需在此刷新即可；「显示与字体」处支持细体字：除了调整字体大小以外，现在你可以设置是否显示细体字了；划动图片回去的手势支持（Swipe to dismiss）：现在在看图的时候，可以用向下、向下划的动作离开看图界面了，这是一种更流畅的体验；增加「自动进入阅读器」的选项；增加支持评论并转发和转发并评论功能。此外，还修复了一些小问题：加回上个版本「丢 ...继续阅读 (55)

本篇文章实战演示如何把一个使用 MySQL 的经典 Django 项目的数据库迁移到更省心的 PostgreSQL 上。起因上周，我的 Manico 网站后台收到了一个网站崩溃的报告，这个崩溃是名叫「Yale」的用户通过「联系我」这个表单给我反馈 Manico 的问题，他在反馈中打了三个 emoji，然后点击了「发送」按钮…然后，我的网站就 500 了。这是因为 MySQL 默认的 utf8 字符集并不支持存储 emoji 这样四个字节的字符，于是就会在数据保存的时候引发「Incorrect string value」的错误，进而导致网站 500 。解决办法也很简单，把 MySQL 的字符集配置成 utf8mb4 就可以了，但是要去改旧数据库的表格、可能需要迁移旧数据…不太喜欢这种方式。另外，不仅仅是 Manico 的网站用的是 Django + MySQL 的组合，本站 IMTX 也是，所以我在文章中从来就不能用 emoji（当然现在可以了😅）。所以我真的忍不了了，要换掉用了近十年的 MySQL，换成 PostgreSQL，当是练习一个经典项目的数据库迁移，也当是熟悉另一个数据库了。于是迁移就这样开始了…准备 PostgreSQL 环境我的 Server 是 Ubuntu 16.04，可以安装当前最新的 PostgreSQL 9.5：sudo apt-get install po ...继续阅读 (50)

本篇文章实战演示如何把一个使用 MySQL 的经典 Django 项目的数据库迁移到更省心的 PostgreSQL 上。起因上周，我的 Manico 网站后台收到了一个网站崩溃的报告，这个崩溃是名叫「Yale」的用户通过「联系我」这个表单给我反馈 Manico 的问题，他在反馈中打了三个 emoji，然后点击了「发送」按钮…然后，我的网站就 500 了。这是因为 MySQL 默认的 utf8 字符集并不支持存储 emoji 这样四个字节的字符，于是就会在数据保存的时候引发「Incorrect string value」的错误，进而导致网站 500 。解决办法也很简单，把 MySQL 的字符集配置成 utf8mb4 就可以了，但是要去改旧数据库的表格、可能需要迁移旧数据…不太喜欢这种方式。另外，不仅仅是 Manico 的网站用的是 Django + MySQL 的组合，本站 IMTX 也是，所以我在文章中从来就不能用 emoji（当然现在可以了😅）。所以我真的忍不了了，要换掉用了近十年的 MySQL，换成 PostgreSQL，当是练习一个经典项目的数据库迁移，也当是熟悉另一个数据库了。于是迁移就这样开始了…准备 PostgreSQL 环境我的 Server 是 Ubuntu 16.04，可以安装当前最新的 PostgreSQL 9.5：sudo apt-get install po ...继续阅读 (49)

有大半年没有更新 Manico 了，大家没有忘记 Manico 吧？今天，修复一系列问题、同时带来一些新特性的 Manico 2.1 版本正式发布，相信里面一定有你期待过的新东西。更新概要临时禁用/启用 Manico 的功能正式回归；重新设计配置功能的界面，使逻辑更清晰、更易扩展；「切换器」模式带来「过滤」功能，可以把不需要显示在列表里的 App 过滤掉了；问题修复修复在多个桌面之间切换时，主界面可能会冒出来的问题；修复在更改激活键后，Dock 和切换器模式下的快捷键没有更新的问题；修复在多屏幕模式下，首次启动立即进「首选项」后，主界面无法被呼起的问题；修复 Dock 模式下排满 26 个会出现两个 D 的问题；修复通过 Option 键去启动 Firefox 时会进入安全模式的问题；图1：重新回归的临时禁用/启用 Manico 的功能经常在写代码、写文章等沉浸模式中工作的话，这个方便快捷的临时禁用功能是非常必须的。图2：重新设计的配置界面，Dock、切换器、自定义三个模式更加清晰和便于使用其中「切换器」模式增加了「过滤」功能，可以把不需要显示在里面的 App 过滤掉，保持只显示自己常用的目标。更新注意事项长久以来，Manico 一直是通过官方版本和 Mac App Store 两边同步发行的，因为通过一套代码来管理两个版本的复杂度，在 2.0 版本全新发布的时候，我犯一一个大错误 ...继续阅读 (69)

今日杭州细雨，屋里待着闷热，想到好久没去晓风书屋了，就踩着自行车去逛了。晓风书屋是我在杭州最喜欢去的两家书店之一，另一家自然是枫林晚了。我去书店的频率不高，一月或数月才会一去，常常是在闲时想到，因而我不敢称自己是一个「读书人」。一方面是我认为自己是一个数字时代的阅读者，拥有 Kindle，很多阅读都也都会在手机上完成，另一方面是，平常还是看各类资讯、杂文较多，能完整消化掉的书是越来越少了——相应的，屯的实体书也少了，电子书却变多了。回到正题。今天一进门晓风书屋的门，我就在正对眼的书架上看到了一本近期我关注过的书——《民国老试卷》，翻了翻，内容不错，还确认了当时为数不少的教会大学出的试卷，如之江大学、上海圣约翰大学等等。稍后，我在其他区域也翻了一些书，其中在一个角落看了很久的《我们的敌人：国家》，是美国保守主义的书，也是十分有意思。最后，我在小说区域扫书架，突然看到一本《软件体的生命周期》，咦，这是什么？为什么会出现在小说区域里面。由于这本书封着皮，无法直接翻阅，于是简单地通过手机查询了一下，是讲人工智能的小说，还获过雨果中篇小说奖，看起来不错！于是还没看仔细看内容，我就拿着这本新书去柜台购买了。这本书我还没看，但是我相信我的感觉，我觉得我又碰到了一本只能在书店里巧遇到的书。如果在网上或各类阅读型 App 瞎逛，要么是千篇一律的畅销榜，要么是按个性推荐来反复的那几本书，很少看到能入眼 ...继续阅读 (77)

更新：写这篇文章时没注意到Gov-Takedowns这个项目，所以下面所述的「协议」是公开的。文章有待扩展…今天知道了一件事情，让我觉得现在的网络环境是越来越复杂了。这件事情就是 GitHub 维护了一个「Chinese Internet Blacklist」，如图：简单地说，GitHub 维护了一个和 Repostiory 有关的黑名单，如果是中国地区的 IP 访问这些 Repository，就会收到这样的消息，而如果是国外 IP 则无任何访问问题。显然，GitHub 与审查方达成了一些协议，以此保证了在绝大多内容访问不受影响的情况下，杜绝了「不和谐」内容的传播。这件事情既不新鲜又新鲜，说不新鲜是因为这样的审查有点类似于 Google.cn 时期的内容审查，说新鲜是因为 Github 并不在中国有服务器，却也配合了这边的审查。不知道背后有什么样的故事，总之是十分微妙的。现在可以确定的事情是：GitHub 不会被墙：毕竟有 Blacklist 在，只要不出差错，双方应该都能相安无事；自我审查者可以停止动作了：积极主动的自我审查者们不必再费心费力担心或以其他各种形式表达对 GitHub 上的不和谐内容的不满了，毕竟 GitHub 自己做了这件事情。这时，我想到 2012 年的时候我写过一篇《2012年，我们的网络环境，变得如何了？》，那会引用的数据还是来自 Google 的…想到今天 ...继续阅读 (60)

上周工作，我与同事讨论之余提到了 Django，然后我突然意识到，我是在 2006 年接触了 Django，是其启蒙了 Web 开发，距今已有十年之久。IMTX 背后的这个 Blog 系统也已运作了 8 年：它正是我在 2008 年用 Django 写成，替换了当时的 WordPress。坚持是一件不容易的事情，不论是维护该 Blog 系统，还是写 Blog 本身。精力早已不在 Web 开发上，本系统老旧的设计和落后的 HTML 富文本编辑模式，让我既没有动力去更新升级系统，又没有动力去更新文章。十年来，我已经放弃了一个 Ubuntu Tweak，我还要放弃这个 Blog 吗？这时，前天发生的一件事情刺激到了我，我在微博上发了与这天有关的一本书的截图，后来该微博不允许再转发了。在这个敏感的日子，微博没被删除当然已经算幸运了，但是，我是不是更应该多在自己的领地自由地写点东西呢？于是，这个周末，我一鼓作气，大刀阔斧地重构代码，删除了大量用不到的特性，把 IMTX 的 Django 版本从 1.7 一路升级到 1.9 版本，不仅彻底换了一个新主题（非常朴素的主题，来自lepture），支持了移动端浏览，而且让 Blog 支持了 Markdown 编写。现在样式和功能方面还有一些问题，容我后续再完善。现在这篇文章，是我在 Ulysess 上写成，然后粘贴进 Blog 的后台发表的。非常方便 ...继续阅读 (78)

如果你是 Manico 的用户，可能会知道 Manico 是一个双平台发布的 Mac App，即自有平台（官方版本）和 Mac App Store 平台。其中官方版本通过 Sparkle 工具来做自动更新，两个版本共享同一套代码库，通过 Xcode 的双 Target 来实现。但是在去年年底的时候，Manico 发布了 2.0 版本时，紧接一周后发布了一个 2.0.1 版本，出现了一个比较严重的问题：即 2.0 版本无法通过 Sparkle 的自动更新升级到 2.0.1 版本，每次更新升级均失败。需要手动下载新版本再覆盖。每次当客服我也是这么回复给用户。今天我终于解决了这个困扰了几个月的问题，竟然是 Sandbox 引起的。more是这样的。Manico 的 Xcode 项目一套源码 + 双 Target，一个叫 Manico，即官方版本，因为要通过 Sparkle 来支持自动更新，所以不能启用 Sandbox（Sparkle 不支持 Sandbox），另一个叫 Manico-MAS，去除了 Sparkle 等相关东西，但是有 IAP 支持，是用于提交给 Mac App Store。具体代码里就是用具体的宏来控制编译和相关功能了。之前 Manico 1.0 的版本我也是这样用一套代码达到目标的，2.0 版本因为用 Swift 重写了，我就新开了一个库。就这样在重新配置的过程中出了点 ...继续阅读 (61)

如果你是 Manico 的用户，可能会知道 Manico 是一个双平台发布的 Mac App，即自有平台（官方版本）和 Mac App Store 平台。其中官方版本通过 Sparkle 工具来做自动更新，两个版本共享同一套代码库，通过 Xcode 的双 Target 来实现。但是在去年年底的时候，Manico 发布了 2.0 版本时，紧接一周后发布了一个 2.0.1 版本，出现了一个比较严重的问题：即 2.0 版本无法通过 Sparkle 的自动更新升级到 2.0.1 版本，每次更新升级均失败。需要手动下载新版本再覆盖。每次当客服我也是这么回复给用户。今天我终于解决了这个困扰了几个月的问题，竟然是 Sandbox 引起的。more是这样的。Manico 的 Xcode 项目一套源码 + 双 Target，一个叫 Manico，即官方版本，因为要通过 Sparkle 来支持自动更新，所以不能启用 Sandbox（Sparkle 不支持 Sandbox），另一个叫 Manico-MAS，去除了 Sparkle 等相关东西，但是有 IAP 支持，是用于提交给 Mac App Store。具体代码里就是用具体的宏来控制编译和相关功能了。之前 Manico 1.0 的版本我也是这样用一套代码达到目标的，2.0 版本因为用 Swift 重写了，我就新开了一个库。就这样在重新配置的过程中出了点 ...继续阅读 (56)

在manico.im购买过 Manico 的朋友可能遇到过 License 邮件发送到垃圾邮件夹的情况，这是因为我是直接通过 Ubuntu 的 postfix 发送邮件的，配置各种不规范，难免被判断成垃圾邮件。长久以来我也「勤奋」地去回复用户的邮件或微博，告诉他们先检查下垃圾邮件夹。久而久之，我觉得这个效率太低、方式也落后，得从根源上解决问题。于是今天注册了 Mailgun 服务，配置在 manico.im 上面，成功地替换了原有用 Ubuntu 的 postfix 直接发邮件的过程。简单地记录一下过程：moreManico.im 用的是 Django（现在是 1.8.x，我得找时间升级到 1.9），Django 提供了比较灵活的方式用来配置各种 EMAIL 发送后端，我使用的是 django-anymail （https://github.com/anymail/django-anymail） 这个组件，因为这个当前在积极的开发当中。集成和使用过程不多说了，一步步根据向导填入域名和 API，重启一下 web server，新的邮件就会通过 Mailgun 的服务发过来啦。这里，我作为一个 Mail.app 的用户学习到一个小技巧，选中邮件并按下 CMD+Option+U 可以查看 Mail 的源文件（即 raw 格式）。我在微博和Twitter宣布了这件事情后 ...继续阅读 (74)

在manico.im购买过 Manico 的朋友可能遇到过 License 邮件发送到垃圾邮件夹的情况，这是因为我是直接通过 Ubuntu 的 postfix 发送邮件的，配置各种不规范，难免被判断成垃圾邮件。长久以来我也「勤奋」地去回复用户的邮件或微博，告诉他们先检查下垃圾邮件夹。久而久之，我觉得这个效率太低、方式也落后，得从根源上解决问题。于是今天注册了 Mailgun 服务，配置在 manico.im 上面，成功地替换了原有用 Ubuntu 的 postfix 直接发邮件的过程。简单地记录一下过程：moreManico.im 用的是 Django（现在是 1.8.x，我得找时间升级到 1.9），Django 提供了比较灵活的方式用来配置各种 EMAIL 发送后端，我使用的是 django-anymail （https://github.com/anymail/django-anymail） 这个组件，因为这个当前在积极的开发当中。集成和使用过程不多说了，一步步根据向导填入域名和 API，重启一下 web server，新的邮件就会通过 Mailgun 的服务发过来啦。这里，我作为一个 Mail.app 的用户学习到一个小技巧，选中邮件并按下 CMD+Option+U 可以查看 Mail 的源文件（即 raw 格式）。我在微博和Twitter宣布了这件事情后 ...继续阅读 (61)

本以为我已经彻底抛开了这个项目，哪知最近因为 Ubuntu 16.04 的发布，收到了至少 5 封来询问我如何让 Ubuntu Tweak 运行在 Ubuntu 16.04 下的英文邮件，我才意识到，我根本没有正式地宣布过一次这个项目的终止，无论在它的Blog上、Github 项目上还是Launchpad 项目，甚至主站（ubuntu-tweak.com）本身也是好好的运行着。确实不像是彻底放弃的样子。对于这个自己曾经倾注了大量心血的工程来说，决定放弃这个项目确实不是那么容易，背后经历的心路历程，现在回忆也能感受到当时的万般纠结。时间应该能抚平这一切，现在我确实能更果断地处理这些了。于是我回复了这些询问我的邮件，告诉他们我不再维护这个项目，同时将 Github、Launchpad 上的工程主页的项目描述处，都加上一行：This project is no longer under maintenance，最后彻底关闭了 Blog 和 主站 ubuntu-tweak.com，现在已经无法访问了，再过一年，域名我也会停止续费，很快这些将会消失在浩瀚的互联网海洋当中。只要我自己还记得，我自己做过的这一切，就够了。more附图：截止目前为止，Ubuntu Tweak 的官方网站每天仍有 4000 上下的点击量…本站架设于Linode 东京机房，同 ...继续阅读 (49)

本以为我已经彻底抛开了这个项目，哪知最近因为 Ubuntu 16.04 的发布，收到了至少 5 封来询问我如何让 Ubuntu Tweak 运行在 Ubuntu 16.04 下的英文邮件，我才意识到，我根本没有正式地宣布过一次这个项目的终止，无论在它的Blog上、Github 项目上还是Launchpad 项目，甚至主站（ubuntu-tweak.com）本身也是好好的运行着。确实不像是彻底放弃的样子。对于这个自己曾经倾注了大量心血的工程来说，决定放弃这个项目确实不是那么容易，背后经历的心路历程，现在回忆也能感受到当时的万般纠结。时间应该能抚平这一切，现在我确实能更果断地处理这些了。于是我回复了这些询问我的邮件，告诉他们我不再维护这个项目，同时将 Github、Launchpad 上的工程主页的项目描述处，都加上一行：This project is no longer under maintenance，最后彻底关闭了 Blog 和 主站 ubuntu-tweak.com，现在已经无法访问了，再过一年，域名我也会停止续费，很快这些将会消失在浩瀚的互联网海洋当中。只要我自己还记得，我自己做过的这一切，就够了。more附图：截止目前为止，Ubuntu Tweak 的官方网站每天仍有 4000 上下的点击量…本站架设于Linode 东京机房，同 ...继续阅读 (58)

前天，也就是 2016 年 1 月 30 日，是奇点诞生一周年的日子。一年前的这天，奇点 0.9 版本悄悄进入了 App Store，并在十天后正式发布。今天，我想借奇点 1.9 版本发布之际，记录一下关于奇点的方方面面。more过去的一年，奇点从一款我的「填坑之作」，渐渐成长为了一款特色鲜明、拥有一些忠实用户的的第三方微博客户端。在当下这个时间点、在微博官方收紧对第三方权限的背景下，做一款第三方微博客户端是一件很不「经济」的事情。但是我乐在其中，并将其作为我没有压力的一个业余爱好。一年下来，奇点不但拥有首创「订阅」阅读功能，还具备快速回复、3D Touch 快速发图、更换主题等新潮功能，同时依然保持着当初的纯粹和干净。另一方面，奇点的用户量也是非常少，截止目前，它的日活用户仅 150 上下，月活用户 650 上下，可以说是小众至极的一款 App 了。对于一款满一周岁的 App 来说，这样的用户量自然是失败的且低于我预期的。这其中有不可抗力：权限缺失导致基础功能的缺失，使其无法成为一款全功能的第三方微博客户端，也有我刻意为止：从当初的 6 元涨价至 18 元并保持至今。于是奇点一直维护着非常小的用户量，同时也是非常忠实的一群用户。对我而言，目前的状态是一个比较舒适的状态，我会以一个月、二个月为更新周期来更新奇点，一边服务于这些种子用户反馈给我的建议，一边在上面试验我的新想法、操练新 ...继续阅读 (65)