分类目录归档:Try

在Mac上简易设置Oh-My-Zsh的BulletTrain主题

起因

近期有了一台新的MacBook,自然少不了基本的装机过程,其中Homebrew和Oh-My-Zsh作为生产力工具算是必装的软件。

不过Oh-My-Zsh的默认主题看久了仍然还是觉得有些枯燥,动了想要更换主题的念头,于是有了后面的步骤。

步骤

安装Vim

常规的Homebrew安装和Oh-My-Zsh不需多言,而这次选定的Bullet Train主题却需要Vim的Powerline插件支持。而Powerline需要正常显示则需要安装已Patch了特殊字符的字体,如果使用iTerm2还需要设定显示字体为已Patch的字体……

由于Powerline需要Python支持,那么安装vim可以按照如下方式进行安装:

安装已Patch的字体

针对一些譬如手写对勾和叉以及git分支之类的符号,需要安装已Patch的字体,按照说明安装即可。

由于个人比较喜欢Monaco字体,对Monaco字体进行了Patch。

安装powerline

由于一直使用Vundler管理vim插件,通过Vundler安装这一插件十分方便,在~/.vimrc中添加:

为了启用这一插件的美化效果,则需要在~/.vimrc中添加如下配置:

之后在vim中执行:BundleInstall即可,还没有使用Vundler的可以一试。

具体参考了setup-vim-powerline-and-iterm2-on-mac-os-x

设置iTerm2

iTerm2个人一直在使用,需要将显示字体设定为已Patch的字体。

iterm2-set-display-patch-font

vim能够显示三角、分支等特殊字符即说明已然设置完毕。

fancy-vim

安装Bullet Train for oh-my-zsh

Oh-My-Zsh的主题安装一直都是很简便,直接wget对应的插件到~/.oh-my-zsh/themes即可,启用则是在~/.zshrc中设定ZSH_THEME="bullet-train"即可。

default-theme-effect

定制显示颜色

默认的显示颜色感觉略微的不和谐,好在这一主题可以通过在~/.zshrc中设置颜色等属性完成设定。

首先这里要保证iTerm2使用的是xterm-256color终端方式(在iTerm2的Preference->Profiles->Terminal中可以查看),后续显示使用的颜色会设定成这256色中一种。

定制颜色主要分为前景色,即字体的显示颜色,以及背景色。

这一主题的箭头标部分主要显示的是时间、目录、当前目录git信息,所以主要设定的是这三个部分的颜色以及参数:

阅读主题源码后了解到对于颜色直接对属性值赋予256色对应的颜色值即可。

颜色与数值的对应关系可以参考下图:

256-colors

最后

历经这一过程,终于完成了一些简单的修改,工作的时候可能也会更愉悦吧

theme-effect

以上。

从Pelican到Hexo

起因

用Pelican在GitHub上搭blog有段时间了,一直想要更清爽简单的blog解决方案,之前使用的Pelican算是满足了我的需求,但是还想尝试一下其他的系统,同时从视觉效果上来说Hexo+Next主题目前更让我觉得满意,于是决定从Pelican迁移到Hexo。

问题

搭建、使用Hexo的教程google一下就能找到,这里主要说一下自己迁移过程中遇到的一些小问题。

文档迁移

Pelican本身也是支持Markdown的的文章写作方式,其实需要修正的地方主要是头部的部分属性。

首先可以将Pelican的content目录下的所有Markdown文件复制到Hexo目录下的source/_posts/目录下。

Pelican通过DateTitleCategoryTagsSlug来表征写作时间、标题、分类、标签、Url等信息,例如:

而Hexo也是类似:

可以简单使用sed完成转换:

关于sed -i后的参数问题,参见stackoverflow上关于在Mac OS X下的sed使用问题

Git设置

允许Git添加非ASCII文件

hexo deploy过程中会在Git中在添加非ascii文件,所以需要在选项中开启这一设置。

Git中文文件名

某些情况下文章使用了中文tag,而生成Tag时会生成中文文件名的目录文件,Git需要关闭对中文文件名的转码。

GitHub CNAME问题

使用GitHub部署的情况下,绑定自定义域名的方法自然是添加一个CNAME文件,最简单的方法可以使用插件来完成。

最后

以上

使用QtCreator配置C++ 11开发调试环境

编译lwan的时候顺道看了下MinGW,发现64位版本也更新到了4.9,感觉自己很久没更新过Windows下的C++环境了,也想体验一下C++ 11,顺手升级了一下。

自己一直使用QtCreator作为C++开发环境,这个IDE个人很喜欢,自动补全功能相当方便,之前在开发Qt程序的时候这几乎是最好的选择,现在也开始出现了收费版本,但是仍然有社区版可用。目前CLion还没有放出正式版本,VS感觉又太重,QtCreator感觉还是一个很不错的选择。

QtCreator的是支持CMake的,正好自己想要学习CMake,于是打算选用CMake作为构建部分的工具。

以下是简要的配置步骤:

1.安装MinGW64

MinGW现在使用安装器的形式进行安装,下载完成一个很小的安装器后进行安装,期间可能是比较漫长的下载过程。不再多说。

2.安装CMake

一样是常规的安装步骤。

3.QtCreator配置

首先是配置编译器路径信息:

工具->选项中进行配置:

配置编译器

之后配置GDB路径信息:

配置GDB

还需要配置上CMake路径信息:

配置CMake

上述步骤完成之后根据之前起好的别名(即上图中的Name字段),选择组成构建套件:

配置构建套件

4.项目级配置

首先自然是常规的新建项目了:

新建项目

在项目类型这里,需要选择使用CMake构建的纯C++项目:

新建使用CMake的纯C++项目

建立完成之后选择好保存的位置

确定项目保存位置

确认项目信息

之后开始配置Debug构建目录

配置Debug构建目录

之后生成CMake相关文件,这里需要指定构建版本为Debug版本,即在参数中指明-DCMAKE_BUILD_TYPE=Debug:

设置CMake参数为Debug构建模式

之后项目会生成一个main.cpp和一个CMakeLists.txt文件:

新项目文件

CMakeLists.txt文件中增加如下配置,告知检查编译器是否支持C++ 11。

之后可以对项目这一构建模式由默认的all重命名为Debug,重新对项目执行CMake操作。

重命名为Debug

重新执行CMake操作

完成上述操作之后,Debug对象的构建配置工作基本完成,可以通过如下代码检验是否能够支持C++ 11的语法:

编辑代码

之后可以尝试构建Debug对象(点击左下角锤子图标):

构建Debug对象

尝试运行:

运行Debug对象

发现能够成功运行,那么至少配置Debug对象这一步就没有问题了。

5.调试

既然生成了Debug对象,那么调试功能自然不能少,尝试打一个断点:

断点调试

可以看出,在断点处查看局部变量等核心调试功能已经能够正常工作,单步、步入等功能也都可以正常工作。

6.发布程序

构建了Debug对象,那么作为生成产物的Release对象自然也不能少。

可以在添加一个构建模式:

添加Release构建模式

Debug对象与Release对象会通过CMake生成不同的配置,需要将二者放到不同的目录中:

配置Release构建目录

CMake参数上的区别在于需要指明-DCMAKE_BUILD_TYPE=Release:

配置CMake的Release参数

之后的构建运行同Debug。

构建运行Release对象

(CentOS下升级GCC参考了这里)。

以上。

CentOS6.5尝试lwan

这些天看到了lwan官网上号称作者历经三年打造的高性能轻量级可扩展Web Server,号称具备了低内存占用、最小化的系统调用次数、对静态文件根据大小智能的处理,预缓存目录信息以及7200行主体代码等特点,到今天(2014年12月26日)为止,Github已经收集到了2000+个star。

其中最吸引我的就是静态文件能达到18w qps,加上它较小的代码体积,于是想要试用一下。

阅读Github上的说明可知,这一软件需要用cmake,无碍,自己手上这台CentOS 6.5的机器上有,不过看到编译参数里面的-flto之后心里凉了半截,这东西CentOS 6.5上带的GCC 4.4.7不能编译啊……

好吧,简直就是噩耗,更换GCC实在不是什么省心的事儿,主要是手上测试机性能实在太差(Pentium双核+2G RAM+160GB HDD,10年的台式机……),估计只编译C/C++支持的话就得一个多小时了,无碍,那么就编译吧。

本次使用的是GCC 4.8.4,使用了日本镜像,速度较快。GCC还依赖三个库:

这三个库安装顺序可以为gmp -> mpfr -> mpc,mpc依赖前两者。

同时,需要通过yum安装glibc-devel以及glibc-devel.i686两个包。

在开始config之前,需要添加环境变量:

否则之前安装的gmp等三个库是没法用上的。

之后便是配置安装:

漫长的编译之后,会在先前的gcc目录(/user/local/gcc)生成,备份原有gcc(需要mv操作)之后通过可以考虑通过

切换版本。

GCC准备好了之后自然就要开始编译,编译时原本出现了一些对于比如luajit以及sqlite3的版本要求,但是作者今天在一个issue中提到似乎已经解决这一问题,这里就先略过,实际出现的话,根据出现问题的cmake提示,将软件依赖改为全路径即可。

编译时需要编译安装luajit以及通过yum安装mysql-devel。

在顶级目录编译完成之后,可以看到在顶级目录下的lwan目录中会生成一个名为lwan的二进制文件,将其拷贝到顶级目录,启动之后就可以体验lwan了。

lwan

关于端口的问题,可以通过修改顶级目录下的lwan.conf修改监听端口。

不过,最后要说的是其实自己的测试结果并不尽如人意,ab并发过万会引起lwan不响应其他请求,而Nginx则没有这类问题,还需要再次试验,确定问题的原因。

小试Sigma黑科技

小试Sigma黑科技

Sigma今年频频发力,各种黑科技产品都冒了出来,不过作为一个初学者,感觉自己还是先接着用好手上的设备吧。

昨天TB的时候试用了同事的Sony A99+Sigma 35 1.4之后,看到图片的效果真是惊艳。之后转身一看原厂35 1.4过W的价格,瞬间失去了尝试原厂的勇气。看看Sigma的价格之后甚是心动,最终决定试试Sigma 35 1.4

下面就试着写个来个开箱吧。

开箱

太久没有动相机,重量感觉有点不习惯,结果手抖得不行……拍完之后发现都歪了……

包装盒

一个白色的小盒子,大小大约等同于河马君的肚子。

打开盒子,说明书等各种介绍文件。

说明书等

盒子里面是一个镜头包,说到这里真是要感叹Sigma这一次真是业界良心,这个镜头包还算结实,而且还有一个腰间的挂载点,虽然平时也不用,但是看的出来算是个实用的功能。

打开镜头包,发现不用东西卡着就不能保持打开状态,所以有劳河马君的下巴了。镜头包顶部有泡沫,估计是防撞用。

镜头包打开状态

拿出镜头和里面的遮光罩,下面就是这整个盒子的组成了。

全部组件

拿出镜头本体一看,35mm F1.4标明性能,67mm口径,直接买了个肯高的普通uv放了上去。

35 1.4

这里就是Art系列的标志了。

Art标志

从前面看看镜头,还是蛮通透的。

镜头正前方

从后面看镜头,没什么特别的,感觉和原先的套头差不多,连接部分是金属的,感觉坚固了很多。

镜头正后方

之后赶紧把它和60D合体,这个尺寸还是比较巨大的。

合体1

合体2

合体3

合体5

合体6

这个镜头金属机身带来的质感非常的好,但是也非常有分量,资料说是665g的重量,上机之后发现真的是很重……颈椎在抗议中。

拍摄试验

随手试了一下对焦,惊喜的发现似乎没有发现跑焦的情况(也可能是眼睛不够锐利吧……),对焦很安静,而且速度很快,比先前的小痰盂快了不止一点。

这张对到了SOHOO字母上:

对焦到SOHO的O上

这张对到下面的of单词:

对焦到of上

这张对到下面的Objective单词中的j字母上:

对焦到j上

最后就给河马拍一张结束吧,这张是对到了绿豆眼的中间:

对焦到河马两眼中间

说了这么多,还是赶紧去学习吧……