设计稿预览神器PsMirror发布2.0版本

自2016年6月1号发布PsMirror1.0版本之后,此工具便受到了广大设计师小伙伴的大力欢迎。
随着期间根据用户反馈的一些细节,功能和问题,版本一直升级到1.2.3之后,逐渐趋于稳定,半年多的时间累积用户达到2w+,也是大家对Cut君的大力支持。

然而1.x版本的Mirror仍然存在很多不完美的地方:

  • 有些用户总是连接不成功
  • 预览过程中偶发、频繁的掉线不刷新
  • 安装过程繁琐
  • 预览速度还不够快
  • 切换画板不够方便

等一些功能性的或者体验性的问题……

借着这些问题,Cut君也在重新思考这款产品,如何打造一款最好用的预览工具~~

 

在重新思考产品体验的时候,Cut君也在重新思考技术架构,为了满足更高更优秀的体验和扩展,旧的代码已经无法再支撑了,一场重构势在必行。Cut君也借此重构的机会,引入并学习了两门新的编程语言(javascript -> typescript,  java -> kotlin)。

2.0版本重点解决、优化了这样几个大的问题:

1. 简化安装步骤

1.x的版本,需要同时安装Apollo和插件面板,并且Apollo的安装依赖PS的安装路径,很多用户在第一次安装的时候,总是被卡主导致安装不成功。

2.0版本,Cut君将Apollo和插件面板整合在了一起,全部打包成一个安装程序,并且可以自动识别您电脑中ps的位置,自动为你安装,所有你需要做的……就是点一下安装按钮就可以了

 

2. 优化Wifi连不上的问题

市面上,众多预览工具基本上都使用了PS的内置远程连接机制,然后用手机去连接Photoshop

这个机制是PS内置的,所以相对来说,开发成本要低很多,市面上的PsPlay, Canvas, Pixl preview此类的App就是这个原理。

但是这种机制存在一个很严重的问题是电脑的防火墙会限制外部访问,以及电脑存在动态IP的情况,导致App经常连不成功,另外连成功之后,刷新机制也受限于PS自身,导致刷新过程比较慢。

于是在PsMirror1.0设计之初,Cut君就没有打算采用这种机制,而是反其道行之,让PS去连接手机

由于手机上基本没有所谓防火墙的限制,只要能够找到手机的ip和端口,就可以通信了,这也是为什么mirror连接成功率高的原因

尽管原理说起来非常简单,但是在技术实现上,仍然存在很多障碍,比如如何才能让PS知道手机的ip和端口,如何判断局域网之间能否进行通信等。在1.0发布之后,仍然有一些用户反馈无法连接,发现很多公司的办公网络,因为接入设备很多,所将路由器划分成了多个网段,导致手机和电脑虽然连接的名称是同一个wifi,但是接入的其实是不同的网段,这种情况下,App发送的广播电脑就无法接收到了,而且根据网络的配置不同,有些时候能通信,有些情况无法通信……

这就是为什么,很多童鞋在家里就非常好连接,但是去公司就连不上的原因了。

为了优化解决这个问题,2.0采用了局域网广域网两种连接方式,通过长连接与服务器保持通信,通过服务器发送广播让PS第一时间发现App,优先通过局域网(即内网)进行尝试连接,如果仍然无法通信,则会使用广域网(即外网)通过服务器中转进行连接,最大程度保证连接的成功率。

 

 

3. 优化USB连接

USB连接算是Mirror的一大特色了,当你的网络无法使用,或者想要寻求更高速度的传输,这时候只要插上usb线,就可以使用usb传输预览了。

然而1.x版本的mirror在识别usb设备的时候并没有做的很理想,尤其针对win+android的条件下,很多安卓设备的usb资源被其它手机助手占用了,导致mirror获取不到usb连接。另外当第一次连接断开之后,经常需要重启PS才能再次连接,甚是忧伤……

2.0版本对此做了许多优化,增加了手动刷新设备的机制,只要在插件面板上点一下按钮,就可以识别到手机设备了,稳定且高效,只要想连接,就点按钮;要想连接,点按钮;想连接,按钮;连接,钮……

 

4. 优化画板预览

PsMirror支持CC2015及之后的画板功能,很多用户在使用中反馈切换画板的体验不好,需要点好多下,希望能够提供滑动切换画板的功能。Cut君针对这种吃着碗里,看着锅里还想着灶上的无理需求,只有一个回应:统统满足你!!!

2.0版本,新增的画板预览,不仅仅局限于PS的画板,即使是普通文档,也一样可以通过滑动、列表切换,并且PS选中哪个文档,自动切换到该文档,贴心的像个良家媳妇……

    

5. 新增图片上传功能(限IOS)

ios版本的app新增了本地图片上传的功能,选择一张本地图片,秒秒中就直接在PS中打开了,就是这么酷炫狂暴吊炸天……

—————————–  我是义正言辞的分割线 ———————————–

除了以上那些重大升级和优化之外,2.0版本还在细节体验上做了很多工作

重新设计优化的插件面板,界面更清爽,操作更简单

App加入了账号登陆的功能,避免同一办公网络下出现串稿的情况

插件面板做了系统环境检测等诸多让你用起来更顺畅的功能,总而言之,言而总之,2.0版本真的是预览神器中的战斗鸡~~~

你值得拥有!

将近一年的时间里,mirror用户在群里头给我反馈很多非常好的功能和优化点,细细想来,作为一个码农的Cut君,本身并不知道如何做好一款产品,是你们一直在教我如何去把它做好,你们才是Mirror的主人,谢谢你们!

btw:补充一下收费政策的问题,psmirror是收费产品,提供15天试用期,60rmb终身使用,提供技术支持,免费享受升级。所以安心下载升级吧~~

by 小强

2017/03/08

CC2015下安装插件的正确方式

前段时间Adobe发布了新一代的系列产品CC2015(尼玛更新要不要别这么快,2014还没用熟悉……)
不过PS2015确实新增了很多不错的特性,小伙伴们都打着鸡血:升级升级升级升级升级!

兴奋的安装完撸一把UI之后,发现尼玛插件全没了有木有!!!!
那时候的心情就跟这几天的股市一样一样滴,没有了Cutterman,还怎么切图???

Cut君也是为这是困扰的多日,虽然我的一系列产品都已经支持了2015,但是无奈Extension Manager总是识别不出PS……这真的和插件没关系啊啊啊啊啊,作死的阿逗比!

Cut君经过多翻了解和翻查,从官方那里了解到,Adobe即将放弃Extension Manager的支持了,也就是说,以后安装插件,不会再使用Manager这种方式了。从CC开始Adobe在主力推Creative Cloud,想在云上有所建树,于是,后续的插件,也都会通过Cloud来进行安装,所以,以后大家的使用方式是这样滴:
1.  去adobe的Addon官方站点,浏览插件,看到中意的,点击安装(没错,就在网页上点击,当然前提要登录你的adobe帐号)
2.  之后Creative Cloud就会自动将此插件安装到你的电脑上

没错,就这样简单!
不得不说,这个体验还是非常值得表扬的~~
所以大家以后可以忘记Extension Manager这个烦人的玩意了

——————   上面是美好的未来  ————————

老姿才不管以后咋地呢,妈蛋明天要把图切出来给研发了,我的Cutterman还装不上呐!!!

Cut君经过多翻摸索,找到了一种可以不需要Exntesion Manager来安装插件的方法,全程也是自动化、傻瓜化,不用担心会暴露自己小学毕业的学历……

好了,下面是安装方法,仔细看不要眨眼!

1.  从这里下载安装包
2.  解压该zip包,会看到里头有2个文件夹,一个installer.jsx文件
3.  打开PS,在菜单栏里头  文件 -> 脚本  -> 浏览
4.  在打开的对话框选中installer.jsx

接着在弹出的警告窗口,点击OK就好啦~~
重启PS,就会发现神奇的Cutterman神奇的出现在你的PS2015中了

备注: win下的同学,如果弹出下面这个错误,请无视,应该已经成功了,重启PS看看插件在不在就好

小伙伴们终于可以拜托CC2015无法安装插件的阔扰啦~~哇咔咔

One more thing…
介于CC2015即将废弃Extension Manger,直接导致很多伙伴的其它插件也可能安装不上,如果你愿意的话,Cut君提供付费技术解决方案,让你想要的插件,也都可以安装成功!

【转】设计师如何为 Android 应用标注尺寸

下面这篇文字是转载来的,版权归原作者所有

—————-

对追求高还原的产品来说,设计稿上的精确尺寸标记是必不可少的。但 Android 生态中各种尺寸和密度不同的设备让这件事情变得麻烦,设计师好不容易搞清楚了什么是 dp ,什么是 sp,但 Photoshop 里没有这些单位啊,还要换算?这就要了命了。

如果你不想搞清楚这件事的来龙去脉,就先拿这个结论去用吧。

设计 Android 应用的最佳实践
1. 画布大小定位 720 x 1280,72 dpi
2. 只使用偶数单位的尺寸,比如 96 px 的列表项高度,16 px 的边距,64 px 的图标边长
3. 只使用 24 pt,28 pt,36 pt 和 44 pt 的字体
4. 设计完成以后,所有尺寸的 px 值除以 2 作为 dp 数值交给工程师
5. 所有字体的 pt 值除以 2 作为 sp 数值交给工程师
6. 所有切图变成三份,分别是原始大小、缩小 1.5 倍,缩小 2 倍,分别作为 xhdpi,hdpi,mdpi 的资源交给工程师

如果你还有好奇心,可以继续往下看这个结论是怎么来的。
相信你已经看过这篇文档中关于 Android 中各种尺寸单位的介绍,没看过的最好看一下

http://developer.android.com/guide/topics/resources/more-resources.html#Dimension

在 Android 应用设计中涉及到的单位都是密度无关像素(Density-independent Pixels),这个说法太拗口了,通俗点讲,Android 应用设计中只用物理尺寸,类似厘米,英寸这种单位,不用像素。之所以这样,是由于像素在手机领域说不清楚问题,比方说规定列表项高度是 48 px,在 HTC C510e 上看起来就不错,但在三星 Galaxy SIII 上看起来就会非常矮,导致很难看,这是因为这两个机器的屏幕的 dpi 相差很大,前一个大约 160 dpi,后一个大约 320 dpi。这就是手机屏幕不同带来的问题,如果不考虑平板,不同主要是密度不同,而不是尺寸不同,也不是分辨率不同,给设计带来困扰的根本是屏幕密度不同。不幸的是,很少人对这个有概念,通常介绍手机,会说屏幕尺寸,3.5 寸还是 4 寸,会说分辨率,480 x 800 还是 720 x 1280,但通常不会介绍屏幕密度是多少。其实通过尺寸和分辨率可以算出密度来,dpi 的 定义是 dot per inch,即每英寸的像素点,把分辨率和尺寸除一除就能得到。一个不确切的分法是,720 x 1280 的手机很可能接近 320 dpi (Android 里的 xhdpi),480 x 800 的手机很可能接近 240 dpi (Android 里的 hdpi)。

Android 选择的单位是 dp 和 sp,dp 的定义是「在 160 dpi 的屏幕上,1 dp 大约等于 1 px」。这个说法也很拗口,简单点说,1 dp ≈ 1 / 160 inch,他就是物理界的一长度单位。用这个单位设计就统一了,比方说规定列表项高度是 48 dp,在所有手机上看起来都差不多是 48 / 160 inch 那么高,虽然在不同手机上它对应了不一样多的像素点,但这个转换是 Android 手机完成的,每个 Android 手机都得知道在我这 1 dp 对应多少像素。sp 也是同样解释,18 sp 的字在所有手机上看起来应该都差不多大(自己改了字体大小设置的除外)。看到这里,可能有人会想,那岂不是不同手机显示的内容不同。确实是这样,同样一个列表,在 A 手机上只能显示五行,但在 B 个手机上就能显示六行;还是这个列表,在 A 手机上文字左边的留白就显得没有 B 手机多。

铺陈完了,逐条解释开始的最佳实践。

设计师在设计的时候是用不了 dp 的,他不可能拖一个 48 x 48 dp 的框,不可能设置一个 8 dp 的边距,Photoshop 里全是 px。于是我们就只有挑一个特定密度的屏幕,在这个特定密度的屏幕上,dp 和 px 的关系是确定,把设计做了,再把 px 转换成 dp 给工程师。另外有一点是,长度可以乘除一下就解决,图片是不能除的,图片必须手动缩放。

我们挑哪一个密度好呢?答案是挑密度最大的,因为图片缩小比放大好,放大会失真,选 320 dpi 作为目标屏幕,为其他屏幕提供图片时,只需要缩小。而 320 dpi 屏幕的分辨率最常见的是 720 x 1280,以这个尺寸作为画布尺寸,是最带感的,这样的设计稿就和应用在最多数的 320 dpi 的机器上运行起来的样子一样。当然你可以选其他画布大小,但再大也不见得方便,这个大小也够施展了。72 dpi 是 Photoshop 的默认设置,不要改就好,这个数字和后面的换算有关系。

字体的问题,Android 4.0 以后的设计规范中建议只使用四种字号,分别是 12 sp,14 sp,18 sp 和 22 sp,这也是 Android framework 用到的全部字号。我们需要找到在这个画布上,这些字号和 pt 的对应关系,以及,px 和 dp 的对应关系。有两种算法:

  • 算法一
    根据 dp 的定义「在 160 dpi 的屏幕上,1 dp 大约等于 1 px」,那么在 320 dpi 的屏幕上,1 dp 约等于 2 px,我们就是为 320 dpi 做的设计,所有 px 值除以 2 就是 dp 值。字体略复杂一点,1 pt = 1 / 72 inch,即在 72 dpi 的画布上,1 pt = 1 px,我们的画布就是 72 dpi,又有 1 sp 约等于 2 px(同 dp 的定义),所以 1 sp = 2 pt,所有 pt 值除以 2 就是 sp 值。
  • 算法二
    可以想象是把一个 320 dpi 的手机屏幕放大到了 Photoshop 里,放大倍数是 320 / 72,即手机上的 1 dp,在画布上就是 320 / 72 dp,而 1 dp = 1 / 160 inch,所以在画布上就是 2 / 72 inch,而画布是 72 dpi,所以在画布上就是 2 px,即手机上的 1 dp 对应画布上的 2 px。字体的计算一样,只是多一个在 72 dpi 上,1 pt = 1 px 的转换。

至此,都算清楚了,在这个画布上,px 到 dp,pt 到 sp 都是除以 2 的关系。

最后,给 320 dpi 做的图片,到 240 dpi,160 dpi 上就要分别缩小 1.5 倍和缩小 2 倍。120 dpi 的机器已经很罕见,可以不考虑了。

讨论一下Cutterman的“出柜模式”

在苹果老板库克喊出“bigger than bigger”之后,后面的事情大家都知道了

iphone出了两款大屏机器之后,切图工作应该怎么办?
我到底是应该用640的图来做设计呢,还是750呢,还是1242呢?真TMD烦淫……

关于设计稿最佳尺寸相关的知识这里就不写了,网上相关文章很多

今天主要讨论的是,cutterman是如何切@3X图的

1. 假设当前设计稿是640的尺寸

那么cutterman会认为当前的图是@2X的尺寸,于是会将当前的图原封不动输出为name@2x.png,然后将当前图放大1.5倍输出name@3x.png。这个放大的过程中有可能导致图片变虚。
如下图:

2. 假设当前设计稿是750的尺寸

750作为iphone6的屏幕分辨率,其折算的结果是仍然归位@2X的比例,所以如果以该尺寸作图,切图的结果和上面是一样一样滴,不过图会稍大一些而已。

3. 假设当前设计稿尺寸是1242

那么问题来了!
1242与640的比例是1.94,大于1.5
如果我把当前的尺寸认为是@3X,那除以1.5之后的@2X尺寸就会偏大
所以cutterman的@2X图的尺寸是当前尺寸除以1.94,以保证在640的屏幕下是合理的。像这样:

cutterman最初就是这样实现的……

直到有一天,一个小伙伴找上门来(就称呼A同学吧),告诉我这样不对
他的理由是这样的:

@3x的尺寸不应该是@2X的屏幕等比例放大,而应该是严格的1.5倍关系,这样的话,对于6plus而言,图就会偏小,但这是合理的,这样能够给内容流出更多的展示空间,符合6p的设计原则,而不是简单的把5的界面等比例放大到6的界面

然后我被说服了……觉得这样是有道理的
于是,cutterman的实现变成这样:

改成这种方案之后,cut不断地被问:

怎么我切不出@3x的图了,@3x的图不对等等

因为你再也无法切出120px的图了……每到这个时候,我就需要给大家解释以上那么多内容,而且经常都是没有人能够理解。

然后我发现,大部分同学的理解,还是以@3X为当前设计稿尺寸,来进行缩小展示的,所以……cutterman现在的策略是这样:

这样的策略基本就满足广大切图小伙伴的需要了~
不过,为了满足之前A同学的那种需求,cut君加入了一个开关,即是大家看到的“出柜模式”

默认,该开关是关闭的,如果你认同A同学的理论,并且觉得它是正确的,你就打开出柜模式,进入出柜状态~~

—————————  邪恶的分割线  ——————————-

最后,我希望大家都看明白了……sigh

Cutterman2.5版本升级日志

今天对cutterman做了个简单的升级,新增了一个“选区切图”的功能。
该功能详细介绍如下:

比如我们有这样一个ICON

然后我们希望把它切出来一个100×100尺寸的图片。
用过cutterman的童鞋都知道,这个可以通过设置“固定尺寸” 来实现。但是固定尺寸有一个问题,就是它默认会把icon居中显示,如下:

但有时候,我们不希望icon居中显示,我们希望它可以偏上一点……偏左一点等等,这个时候,固定尺寸就搞不了了~~

为此,“选区切图”功能就可以派上用场了!
它的使用方法如下:
用“选区”工具,在你想要输出的元素周围拉一个矩形,即你想要输出
的尺寸,和元素对应的位置,如下图:

该icon距离选区的位置,即是icon被切出来之后的位置,如下图:


基本流程就是:拉一个选区,点导出!没错,就是这么简单~~

—————————— 邪恶的分割线 —————————— 

除了选区切图的功能升级之外,本次还修复了窗口出滚动条和底部出现白条的UI展现问题,解开了众多强迫症设计师的心头结……乌拉乌拉乌拉……

请注意!本次升级需要广大童鞋到官网下载最新的安装包进行覆盖安装~~

2014年11月11日  晚23:58

晚安

Cutterman是如何诞生的

我这会正坐在武汉去北京的高铁上,后天出发去美国出差。漫漫旅程,我觉得可以写篇日志……

08年的夏天,我以web前端工程师的角色进入了互联网这个行业。工作职责是将设计稿转化成web页面,并将数据库的数据输出显示到页面上。用html编写界面,CSS来实现布局和视觉效果,用javascript实现用户的交互操作,同时也关注网络、性能、可用性等内容。这些大体就是前端工程师的主要工作内容了。

从软件开发流程的环节来看,web前端属于设计的下游,设计师在完成设计稿之后,将作品转交给工程师,由工程师实现设计稿到web页面的转换工作。这个交付的过程,就涉及到了一个“切图”问题。

很多的大公司,会将软件工程的各个环节做很细的划分,从而衍生出了许多角色以及部门。比如做市场推广的产品,做产品设计的产品,做界面设计的视觉设计师,做交互设计的交互设计师,做纯静态页面的前端,做交互、功能的前端等等等等。

细粒度的角色划分,有利于分工明确和专业化,但是很多时候在明确分工这个问题上会有些纠缠不清,因为有些工作的耦合性非常强,强行做拆分会增加人员的沟通协作成本。我在刚加入的时候,就存在一个叫UT的部门,也就是刚才提到的做纯静态页面的前端,该部门的同学负责从设计师那里拿到设计稿,然后切图,用html和css完成纯静态页面的制作,偶尔也会用JS实现一些如轮播图这样的交互动画。完成这样的工作之后,再将写好的静态页面代码,交给web前端工程师(也就是我这样的角色),将纯静态页面转换成比如smarty模板,将文案替换程后端变量,再编写一些用户的交互逻辑,请求逻辑等等……

这样持续了一段时间之后,我们发现效率其实非常低下,我们发现静态页面的代码无法满足动态数据输出的要求,或者会吐槽写静态页的工程师搞出了一坨烂代码不能忍,于是经常会把静态页面的代码改的面目全非,造成大量的重复工作和人力浪费,于是在持续了不到一年之后,我们两个部门合并了,于是所有的前端工程师,都需要做切图,写页面的工作。

在我当时的web前端工程师而言,切图是一件及其Easy的工作,大家可能对ps的其它功能不大了解,可是切片工具还是用的相当熟练的。而且很多优秀的前端工程师,会对设计稿做分析,什么样的图应该如何切,做到心中有数,甚至还会给设计师反馈,哪里哪里换一种效果会更好之类的。

在做了4年左右的前端之后,我开始接触客户端的开发工作,最初是从IOS开始。和web端很类似的是,我们都需要将设计稿转化为用户操作的界面,但是ios由于需要兼容3GS的机型,需要提供单倍和双倍图,我当时得知这个情况之后还蛮郁闷的,无形之间,工作量增加一倍。不过由于客户端的开发工作量太大,于是切图的工作交给设计师来完成了,让我唏嘘做web的设计师童鞋都是多么幸福!

但是幸福并没有这么容易,我们发现很多时候设计师切出来的图有问题!比如一个带渐变效果的按钮,其实只需要切一个1px的竖条就可以了,但是设计师会把整个按钮切下来,诸如此类。所以作为研发,我们依然会对切图工作做研究和分享。

就在一次组内分享中

我们组的一个研发同学推荐了一个photoshop脚本,名叫Export For IOS 它可以输出单倍和双倍的图片,我们都很激动,要知道当时设计师童鞋都是手动将设计稿缩小,再切一次图片的!于是我自己也用上了这个脚本,心里惊叹原来PS还可以有外部脚本这样神奇的东东……但是这个脚本用起来稍微不大方便,每次需要点击菜单,脚本,选定等几个鼠标操作,然后一次只能切出一个图层……

直到有一天,我们组的一位美丽的设计师mm找到我,给我介绍了一款切图的PS插件,没错,如果你之前用到过的话,Cut&SliceMe  ,我当时就斯巴达了,尼玛世上还有这么牛逼的东东!原来PS还可以搞插件的哇~~于是我就和设计师mm说:真好哇,有这个牛叉玩意,你们就轻松多啦!可是没想到设计师mm是来和我抱怨的,说这个东东不大好用,要记住一堆的规则,还有输出的图片也有些不理想,总是处于想用却又不敢用的纠结状态……

作为优秀的研发,设计师mm找上门来了,当然不能不理!于是,我决定去弄一款好用的出来……

我最早接触PS可以追溯到04年,那时还是PS6的版本,可是只觉得它是一款牛逼的作图软件,没曾想到,这玩意还能支持插件和扩展开发!于是开始google对应的开发资料。不得不说,adobe在开发平台上的投入,真的是烂到不行,只提供了非常简单的一些文档和碎片资料,而且PS的各种版本特性错综复杂,我摸索的很长时间,都没能把开发环境搭建起来……

在CS6的版本及以前,插件是基于flash平台的,然后我也没有学习过ActionScript,也没有时间学,装好FlashBuilder之后,就上手写helloword,总算是跑通了开发环境……

这里有个插曲,Adobe这个抠门,开发插件的IDE:Extension Builder要收费,卖10刀,不然只提供1个月的试用期,结果我cutterman开发了一小半,到期了,不让用了!我心想,买就买吧,都准备掏钱了,发现购买需要美国的银行帐号!你妹!没有办法,打电话让美国的好朋友第二天帮我购买,最后,也没有买成,因为我在当天晚上花了2个小时把它破解了……只想说:no zuo no die

我边写边学边Google,在花了3个周末的时间,终于把cutterman的第一个版本做出来了。我不喜欢Cut&SliceMe那种规则的模式,需要使用者记住一堆规则,生活本来就很幸苦了,我连女朋友生日都老忘,还能记住你那么多东西?另外,切图的动作本身不是高频的,你就算今天要切图记住了,等下周要切图的时候,你肯定也就忘光了。所以Cutterman的宗旨是:简单+可视化!

所有的功能都一目了然,一个按钮,完成所有工作!要让设计师觉得,没有切图这样的事情存在!

当然,目前的Cutterman还没有达到我理想中的目标,后续会归一化所有功能,只提供一个按钮,在保证功能强大的同时,让所有的配置更清晰易懂,更高效!

Just wait and see.

关于本博客

其实在很早很早以前就是开始写博客了。

从最初的QQ空间,到后来的百度空间,接着是自己建站搭wordpress。然而总是写着写着,就不再更新了……

写博客确实是一件很辛苦的活,需要有大段完整的时间,需要思考,需要整理,还需要用优雅的文字表现出来。以为会有很多观众,会有很多掌声,其实终究还是孤芳自赏罢了。

于是,久而久之,时间都被生活的琐碎给冲淡了,无法静下心来思考,也没心思去整理,就这么浑浑噩噩地,看着钟表不停的旋转,边唏嘘时光飞逝,边抱怨前途暗淡。

于我而言,写博客和画素描一样。心情和环境具有重大的影响,首先是环境是很关键的,我需要有优美的写字载体,我不喜欢在浏览器Wordpress的后台编辑器里头码字,所以在以前,我都是用VIM编辑器进行博客的撰写,然后通过XML-RPC远程发到站点上面。我还为此找到了一个对应的vim plugin,搞的非常geek!可是这种方法,对于图片等资源就比较无能为力了,需要自己手动上传,非常烦人……

到最后,我发现我还是在QQ空间写的文章最多。

今天,无聊打开了Mac的AppStore,想看看有什么好玩的软件,于是就看到了一个叫Blogo的软件,它是Mac下的一款桌面写文章的App,能够支持Wordpress站点。也就是说,你可以在mac下用一款优雅的码字软件来写博客,动态发布到wp站点上了~~

抱着试用下下的态度,想着之前也打算为Cutterman建立一个博客,记录PS插件的开发历程,于是花了几十分钟,又一个wordpress站点出来了……好久没见,wp版本都升级到4.0了

安装好之后,打开Blogo,输入博客地址,和后台登录用户名密码,就可以开始码字了。Blogo界面简洁清爽,文本编辑器支持文字加粗、斜体、引用、链接的基本功能,界面如下图:

插入图片也非常方便,直接insert Image就可以啦,有点word的味道。

接下来,我会以PS插件为主体,定期发布一些文章,讲述cuttermanparker,等等优秀工具的开发升级过程和一些有价值的内容分享。

时间是无法储存的,所以要抓紧用。