几个月前写了一篇赞美 Arc 文章：《Arc——一个颠覆传统的浏览器》，然而再好的东西用久了其不足的一面也会暴露出来。经过这么久的使用，大致总结了一些我认为不足的地方，有些也给他们提过反馈，希望在后续的版本中会有所改善吧。
这个不得不吐槽，Arc 的下载体验是真的垃圾，都不能用差来说了。下面列出几点不能忍的部分：
这些问题给他们反馈过，他们让我等待后续更新，这是 6 月 19 号的事了，现在还没有任何改进。另外还有一个问题是其媒体库显示的不是通过 Arc 保存的，而是所有的。
也可能最近才注意到这个事情，发现国内各大主流网站全部在滥用 a 标签的 target="_blank" 属性，我最近试了很多个网站，包括但不仅限于 哔哩哔哩、网易、新浪网、腾讯网、今日头条等。这个是相当烦人的，我在这些网站上点击任意一个连接，全部是打开新的标签页或者窗口，浏览下来不一会就全是标签页。我在想，国内的这些人一点都不注重用户体验吗？这么害怕用户从网页跳走吗？难道不知道如果用户想在新标签页打开可以在连接上按一下鼠标滚轮吗？不知道用户想在新标签页打开可以按住 Command + 点击 吗？真的觉得很多国内的厂商都是臭不要脸，类似于像开屏广告以及各个视频平台的广告一样，玩出各种花来，为的是从用户身上挖出剩余价值，什么用户体验，都是次要的，反正你有离不开我。
今天真是越想越气不过，花了点时间写了个油猴脚本来解决这个问题：
在日常使用电脑的过程中，经常会用到一些命令，并且可能要将一组命令结合才能完成自己想要的结果。如果常用的一些命令（组合）每次使用都重新敲的话，势必会影响效率。此时你可能会想到类似于 make 这样的工具，当然这也是一个选择，但是 make 的缺点也是显而易见的（有兴趣的可以通过 makefile 介绍 — 跟我一起写 Makefile 1.0 文档 来入门）。几个月前我无意中发现了just，感觉在日常使用中完全可以替代 make。
just 语法和 make 很类似，如果你有 make 基础的话，可以很快上手。下面简单介绍一下 just 的用法以及和 make 的一些区别（首先一个区别是 Makefile 中每个执行项叫做目标（target），而 just 中叫做配方（recipe））：
首先 just 和 make 一样，需要一个 Justfile（make 是 Makefile，just 这个文件的文件名可以是 Justfile、justfile 或者 .justfile 等），不区分大小写，可以在前面加个.来隐藏这个文件。just 会从当前目录向上查找 justfile 文件，而 make 不会。 这就意味着只有某一个父级目录存在一个 justfile 文件，那就可以执行该 justfile 里的相关的代码。
如果 Makefile 的在当前目录下存在一个文件，这个文件和某个 target 名称相同，则这个 target 就不会执行，并且打印出错误信息：make: xxx' is up to date.，此时你需要在 Makefile 文件中加上一样 .PHONY xxx 来防止此问题的发生，just 则没有此问题。
Makefile 中 target 可以对另一个 target 进行依赖（即先执行另一个 target，执行完毕后在执行当前的 target），just 也可以，而且 just 还有“后依赖”，例如：
1 | list_file := "formulae-list.json" |
今天突然想写篇博客，看了上一篇的发表时间，已经快接近三年半了，着实惭愧啊~。这篇文章主要介绍一下前段时间突发奇想写的一个管理 iOS 主题的开源小库：ThemeManager。
其实做一个方便管理和切换 iOS 主题的库的想法是好几年前的事了，在这期间脑补过很多实现方案，当想开始做的时候又由于想到了方案的不足再加上我对切换主题没有什么需求，导致一直搁浅。前段时间突发奇想，来了灵感，先在脑袋里打了个草稿，几周后着手开始做，加上一两天空闲时间做的实验，最终花了我一晚上的时间（下班后，包括代码 + Demo + README + 适配各种依赖管理工具(Swift Package, Carthage, CocoaPods，包括本地测试) + 传到 CocoaPods 上，最终两点多完成）终于把这个库做出来了。所以做这玩意纯粹是个人兴趣加上突发奇想。
由于业务需求，需要对两个（现在是三个了）中的一个 OpenGL 渲染的视图进行截图并增加模糊效果。开始用传统的方法进行截图，但是失败了（截取的是黑屏还是空白，忘记了。。。），后来意识到这个和一般的视图应该是不一样的，就到 Google 上搜了一下。由于没怎么玩过，又不怎么懂，就直接翻译成 Swift 了。开始是没发现什么问题的，都是但是到后来发现截图总是其中一个的（看那个先出来，基本上不是想要的那个），而不是想要的那个。
仔细研究后发现，OpenGL 的截图是根据 RenderBuffer 来截取的，由于没有指定 RenderBuffer 所以截取的图只是其中某一个。知道了这个也没用，由于这个 View 用的是第三方库，所以不知道这个 View 的 RenderBuffer。。。后果经过 Debug，发现这个 View 有个 _colorRenderBuffer 属性，这就好办啦~。经过改造后代码如下：
上周我讲自己的博客从 Octopress 迁移到了 Hexo，感觉还是很不错的，但是由于Octopress 和 Hexo 存在一些差别，所以导致了如下三个问题：
categories/xcode，现在是 categories/Xcode）今天就来说一下我是怎么解决这三个问题：
这一段时间一个Core Data数据迁移的问题快把我搞死了，上面给的压力也非常大。先说一下来龙去脉吧~
首先以我为主程的一个应用（绝大部分代码是我写的）由于之前数据库设计的不合理导致应用总是无规律可循的崩溃。这个问题一直存在了好几个月，怎么研究都是无果。后来直到看到Stack Overflow上Core Data: EXC_BAD_ACCESS accessing relationship的帖子（后来还看到这个Semantic Issue: Property’s synthesized getter follows Cocoa naming convention for returning ‘owned’ objects）才意识到自己的愚蠢和无知！我忘记了Objective-C的属性名（Core Data中包括属性名和关系名）不能以new打头，否则就违反了Objective-C的内存管理策略。
请记住：尽量不要使用以alloc、new、copy和mutableCopy等打头的属性名、关系名和方法名，如果必须使用请在声明中使用NS_RETURNS_RETAINED或NS_RETURNS_NOT_RETURNED，否则会导致内存管理问题！！！
几个月前无意中看到StackOverFlow上的一个帖子How to get suitable CGImage from combined TIFF for display scale了解到了ImageIO这个框架，看到它可以读取TIFF中的单张图片，当时就想能不能读取GIF中的图片呢？后来进一步研究后发现答案是肯定的。后来就想哪天细研究一下吧，顺便写篇博客记录一下。没想到我是这么的懒~，昨天才终于研究好了顺便写了个项目WYZGIFAnimationView开源到了Github上。