月度归档:2016年01月

retina macbook pro 15的两个display port都接了显示器后wifi不可用

前天,我把自己的retina macbook pro 15的两个thunderbolt口都接上了4k的显示器,然后,显示器接上后,wifi突然不可用了,表现形式为,wifi符号显示已经连接上,然而,无论如何都上不了网,访问任何网站都是time out错误,如果把其中一个显示器断开的话,就可以上网了。

我到网上搜索了一下,发现了这个thread

https://discussions.apple.com/thread/4155096?start=30&tstart=0

标题写的是“My wifi drops when I plug in an external monitor through the thunderbolt port”。

里面提到

If hooking up a thunderbolt output for a display and your wifi stops working try the following.

If your using an apple airport express go to the finder.

1. Type in airport, then open airport utility.

2. Click on Base Station.

3. Click Edit.

4. Click Wireless.

5. Open Wireless Options tab.

6. Where you see the 2.4GHz Channel listed change it to 4.

7. where you see 5GHz Channel Change it to 149

8. Click save and apply.

 

That should do the trick.

总结下来,就是5GHz的wifi的channel设置为149,2.4GHz的wifi的channel设置为4。

我这样设置后,果然也成功了,接上两个4k显示器后,wifi连接也一切正常。

 

免费的SSL证书:https://letsencrypt.org/

今天想着给自己的blog加上ssl证书,最开始想的是用免费的,结果最后发现了https://letsencrypt.org/,不仅免费,而且部署自动化,非常方便。

letsencrypt提供了一个命令行工具,它需要在服务器上运行,然后在你的Web的根目录下创建一个特殊名称的文件,如.well-known/acme-challenge/aaaa11111,假设你的域名是www.abc.def,letsencrypt会尝试下载www.abc.def/.well-known/acme-challenge//aaaa11111,如果下载成功,则代表你是网站和域名的所有人。

我在使用letsencrypt的时候,发现由于nginx默认禁止访问”.”开头的资源了(防止黑客下载.htaccess, .htpasswd文件),所以总是认证不成功,最后修改了访问权限,允许了.well-known的访问。

 

我的新blog: https://huang.sh

再思考是否将CocoaPods生成的Pods/目录加入到代码库

CocoaPods是一个流行的Cocoa依赖管理工具,Mac和iOS的开发团队几乎都在使用CocoaPods。我们只需要编写Podfile,并在之中指定依赖的库,然后在命令行运行pod install,CocoaPods就会从自动安装上各种依赖,并生成Pods/目录和Podfile.lock,其中,Pods目录包含了工程所依赖的各种库的源文件或者二进制lib文件(库的作者有可能选择发布已经编译好的二进制文件而非源文件,如PayPal SDK),Podfile.lock则包含了所安装的库的版本信息,这包括版本号和hash值。

我们必须把Podfile.lock和Podfile添加到版本库,这样,别的团队成员check out工程的时候,同时也会得到Podfile.lock和Podfile,这样,他/她再次运行pod install的时候,CocoaPods就可以确保安装同样版本的库。

对于是否将Pods目录加入到代码库,一直以来都没有固定的结论,CocoaPods官方文档本身也针对添加到代码库和不添加到代码库的两种情形都给出了相应的操作文档。

两种方式其实都各有利弊。如果添加到代码库的话,最大的问题就是代码重复,因为依赖的库都是可以从网络下载的,再次添加到代码库是一种代码冗余,同时,很多库发布的是二进制版本,如PayPal SDK,这些库通常都很大,所以你会发现一个工程的源代码还没写多少,代码库就已经几个GB大了。这个问题其实挺严重的。

如果不添加到代码库的话,另外一个问题就会非常严重,那就是很多Pod可能会消失,即CocoaPods的master repo还有对应的pod spec,但是pod spec指向的地址已经404 not found了,我不止一次看到这样的情形了。所以,很有可能出现的问题就是,两三年前的版本你已经无法重新编译了。

还有一个麻烦的事情就是切换分支的时候,常常会需要pod install,否则就是this sandbox is not in sync with错误。如果pod install需要下载一些比较大的framework,那就需要开发人会员等待很长时

基于以上考虑,我个人的建议是,保险起见,把Pods目录一起加入到代码库中,代码库膨胀得快一些也可以接受了。

如果不想把Pods加入到代码库,那么,考虑到大多数的开源库都是放在github上,我建议还是要在github上及时fork这些库到公司内部的代码库中,并及时同步,但不要同步delete操作,防止有一天原作者因为各种原因把github上的工程给删除了。不过,一些知名的库,如AFNetworking,我们应该还不需要担心这个,但,如果你用了一些个人作者的库,那一定要fork一份,切不可不fork。