iPhone中png图片格式处理

众所周知,iPhone中应用自带的png图片已经是经过压缩处理的,无法直接查看,但是可以通过工具转换为原图。 转换为原图的方法 在安装好Xcode之后(我安装的版本是4.3),可使用命令行转换 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush -revert-iphone-optimizations src.png dst.png 这个命令行太长,不好记,所以我在~/.bash_profile中加入一个alias。 alias pngcrush=\”/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush -revert-iphone-optimizations \” 所以之前的命令可以简化为 pngcrush src.png dst.png 批量转换png 用简单的shell就可以批量转换png图片为原图。 for i in `ls *.png`; do pngcrush $i /tmp/$i; mv /tmp/$i $i; done

git flow使用经验小记

我在半年前开始在公司内推广使用git flow,控制版本发布流程,到目前为止效果令人满意。 但是实际使用过程中有一些小小的意外流程,完全照搬git flow的模型不太容易处理好。好在git本身就很灵活,碰到问题基本上都有办法绕过去。下面是我总结的一些特例情况下的处理办法。 测试/共享单独一个feature 有时候我们需要将一个feature独立测试,或者share给多人一块开发,那么可以将这个feature推到远程git库上,这可以利用git flow的publish功能搞定: git flow feature publish my_cool_feature 这会将 feature/my_cool_feature 分支push到远程git库,多人开发或者单独测试毫无压力。 feature在development分支测试完成,准备release的时候有另外一个未经测试的feature合并进来 已经完成测试的development被未经测试的提交污染了,这时候可以先本地回滚development分支,然后再进行git flow的release流程,例如: git checkout development git reset –hard 5cbadfe885d1eb514b3f07b3f269ca1a7f261e21 #假设测试通过的git rev是这个 git flow release start v1.0.1 git flow release finish v1.0.1 development上有个feature需要测试比较长时间,影响了一些耗时较短的feature发布 development分支上有个feature测试时间比较长一直释放不了,怎么办?—— 果断采用hotfix功能 git br -m feature/another_cool_feature hotfix/another_cool_feature 把耗时短的feature直接转换为hotfix,然后采用git flow的hotfix流程可以直接合并到master分支发布。

设置自动重连的ssh代理通道

我目前常用的翻墙办法就是拿ssh搭个代理通道,然后chrome + switch!插件一起配合,这就算翻墙了。这法子只要拿个机器跑一小脚本,比如: ssh -D 7070 -qnN [username]@[server] 但是ssh通道如果闲置了一段时间,就会自动断连,等我需要用到代理的时候往往又得蛋疼的重新跑一遍,非常麻烦。所以我刻苦学习前辈的经验,找到一个解决办法,在mac或linux下都可使用,分享如下: 把ssh配置为免密码登录,这个一搜一大把,略过不提 在/etc/inittab的最后一行加上: tunl:345:respawn:/usr/bin/ssh -D 7070 -qnN [username]@[server] > /dev/null 2>&1 让修改的inittab马上生效 sudo init q 在/root/.ssh/config里加上几行 Host * ServerAliveInterval 60 然后这个ssh通道就会自动重连了。 Update 增加了一个ssh配置,要不然这个进程虽然在,但是通道已经连不上了 .ssh/config的配置是关键,/etc/inittab的配置只是让服务器开机即启动ssh通道

mac下的tree命令

在默认安装安装的mac下没有找到tree命令,找了一下原来有个比较流氓的解决办法: find . -print | sed -e ‘s;[^/]*/;|____;g;s;____|; |;g’ 这个命令行跑起来类似平常tree的效果,比如: . |____extra | |____httpd-autoindex.conf | |____httpd-dav.conf | |____httpd-default.conf | |____httpd-info.conf | |____httpd-languages.conf | |____httpd-manual.conf | |____httpd-mpm.conf | |____httpd-multilang-errordoc.conf | |____httpd-ssl.conf | |____httpd-userdir.conf | |____httpd-vhosts.conf |____httpd.conf |____magic |____mime.types |____original | |____extra | | |____httpd-autoindex.conf | | |____httpd-dav.conf | | |____httpd-default.conf | | |____httpd-info.conf | | |____httpd-languages.conf […]

LightCloud的设计原理

LightCloud是最近看到的一个比较轻巧的分布式key-value数据库,尽管这类软件已经让人觉得审美疲劳,但我仍然觉得它的设计思路值得一提。 特色 除开其项目主页上列出来的特点不提,我觉得还能数得上的特色有: 理论上可以用任意key-value数据库做为底层存储,现在支持以tokyo tyrant或者redis作为底层的存储,如果使用redis可以获得更好的性能(大概提升30%~50%) 没有定制服务器端,基本上靠客户端语言来实现键值查找。优点是部署起来比较简单,缺点也是显而易见的,效率会有损失。 可以很方便的移植到其它语言上,我已经在github上找到一个ruby版本,甚至还有个php版本的实现。 可以方便的增加节点。 结构简单,方便hack LightCloud的设计原理 Hash ring LightCloud不能免俗的使用了一致性hash算法(Consistent Hashing),这是为了避免新增数据节点时发生集体拆迁事件。Consistent Hashing算法的原理请参考这里。 last.fm的工作人员写的ketama算法算是比较常见的一致性算法,在libmemcached里大量使用。而LightCloud的作者当时还没发现合适的ketama python版,所以干脆自己捋起袖子写了个python版本的hash_ring,不到50行。这个是量身定制的,所以效率也还过得去,但是兼容ketama就别想了。 献上hash圈圈一个以明志: LightCloud的hash环有什么与众不同? 其它分布式key-value数据库采用的办法是复制数据到多个节点上,例如Amazon Dynamo的复制策略图: Dynamo用了许多办法解决consistent问题,系统相当复杂。而LightCloud直接使用tokyo tyrant的master-master复制功能,大幅简化了这部分的逻辑。所以在它的hash环上,单个节点其实是一对master-master的tokyo tyrant,焦不离孟不离焦。 在新增数据节点时,如果没有路由服务找到正确的服务器,可能会损失数据。那么LightCloud继续采用流氓手段解决这个问题,他又给上了个环,保证不会发生意外。这两个hash环里的节点仍然是之前提到的tokyo tyrant双人组,一个环叫lookup,记录了每一个key保存在哪个storage节点上;另外一个环叫storage,这是真正存放数据的地方。于是它的结构图变成了下面这个样子: 这部分比较难以理解,试着就上图阐述一下: 一个名叫A的家伙,住在storage_SB地区(storage ring)。同时,我们还告诉记性好的lookup_B(lookup ring),A君的地址为storage_SB。 很不幸或很幸运,咱们的数据膨胀到需要扩容了,于是新增了一个违章建筑storge_X,这个该死的建筑正好影响了我们找到A君。这时候,我们还可以问起记性好的lookup_B,A君住在哪个角落里啊? —— lookup_B日道:他就住在sotrage_SB一带~ lookup这群家伙记性虽然好,但是也架不住人多,再也记不住这么多人的住址,所以又新来了几个记性好的lookup。这个会影响咱们找到storage住哪吗?答案是不会,因为没有新增别的违章storage建筑,咱们不需要问路也能找着人。 按照以上推论,一定要避免同时增加lookup和storage节点,这很可能会损失数据。 参考网页 http://opensource.plurk.com/LightCloud/

git的代码review工具

facebook在GitHub上托管了大量的开源项目,足足有26个。其中hiphop-php以及xhp在这阵子炒的比较热,的确是让人印象深刻的东西。顺手把别的项目翻出来看,也有很实用的工具,比如git-review。 git-review为git新增了一个很方便的代码review途径,利用这个命令,可以调用别的工具比如vimdiff来review代码的改动。下面简单记录一下使用的过程: 下载并安装 首先确认已经装好了git,剩下的事情比较简单。 git clone git://github.com/facebook/git-review.git cd git-review python setup.py install 这几步为git新增了一个review命令。 git-review的使用 查看指定版本的改动 git review 58e2fb834793f5c6c1fdd900a1c0224a44735962 出现提示 Now processing modified file foo.php foo.php [diff]> 由于我配置了diff工具为vimdiff,所以接下来就可以用vimdiff查看foo.php在58e2fb834793f5c6c1fdd900a1c0224a44735962这个版本与最新版本之间有什么不同。 查看两个版本之间的改动 git review 5b744bdc5f5bcbcfd6bb65f815aebe6bdce8c427 58e2fb834793f5c6c1fdd900a1c0224a44735962 在review每个代码之前,都可以使用help查看git review命令的帮助,如果放弃review,那么直接敲退出就可以了。

用git从svn里clone最后几个版本

一般情况下git svn clone这个操作会从第一个版本开始同步,如果版本号已经到了好几万(或更高?),这个操作会相当的费时。 当时还想着能不能hack一下git-svn脚本,其实后来看看文档,clone操作可以使用参数-r$REVNUMBER:HEAD检出指定版本后的代码,因此,更好的步骤应该是这样: svn info http://your-svn, 并记录最后的版本号,假设是260 假设要检出最后10个版本,做个简单的减法: 260 – 10 = 250 开始clone操作了 git svn clone -r250:HEAD –prefix=svn/ http://your-svn 按这个办法,clone的时间的确是减少了许多。

subcon使用笔记

在温习flickr的ppt时,看到里面提到了一个叫subcon的工具。由于这个工具已经在google code上开源,所以我毫不客气的下载回来细细端详: 这工具用python写的 用svn保存配置文件,用subcon比较容易的部署到多台服务器上 既然是用svn保存,那么回滚到指定版本也是支持的 SystemImager工具的集成是做为添头附送的,理论上你可以利用这个工具做到一步安装服务器 初印象就是如此,实际的使用时,你首先要在svn上创建两个目录 base roles 然后可以试着提交一些服务器配置文件例如/etc/hosts到base下,再通过简单命令把配置同步到服务器上 subcon -n 也可以指定别的类型的配置文件例如www或者memcache,以服务器apache配置文件/etc/httpd为例: 创建目录roles/www 提交/etc/httpd目录到roles/www目录下 十来个字符就可以部署这些文件到服务器上 subcon -n -owww 同样的道理,只要在roles路径下新增各种类型的配置文件,就能比较快捷的部署到服务器上。还有些小功能,需要使用中自己挖掘了: 更改某个配置文件之后,自动执行指定的命令行,参看/etc/subcon.conf 回滚配置文件到指定版本的功能,这功能一般是在悲剧发生时才会使用吧?所以这个功能也很悲剧的有bug,手工hack一下才能使用。提示:在代码中找到revision字样,用int转换一下类型,命令行参数到了python里面估计都算string了。 如果有多个服务器共用部分配置文件,可以利用svn:externals属性创建一个链接 subcon实际上是python的svn客户端 + rsync 工具很简单,也有些bug,但是足够用了。

Git-svn on cygwin

开始试用最近比较红的git,我看中的是它的本地版本库功能,即便网络比较烂的时候,也可以在本地提交,等到了合适的时候一并传上去。由于以前的代码版本控制使用的是svn,所以我用git-svn过渡一下。 目前在windows下,最好的git客户端恐怕就是装一个cygwin。鼓捣了一个时辰,整理好一些可用的配置文件,陈列一下以备下次使用: ~/.bash_profile 偶尔还会使用svn验证一下check in的情况,刚转过来不放心啊,下面的配置是为了防止svn命令行乱码。命令行git-svn在/usr/sbin/git-core/路径下,是一个perl脚本,为了方便,我把这个路径加入了PATH环境变量。 export PATH=$PATH:/usr/sbin/git-core/ export SVN_EDITOR=vim export LC_ALL=en_US.UTF-16 export LC_CTYPE=en_US.UTF-16 export LANG=en_US.UTF-16 export XMODIFIERS=@im=Chinput3 stty cs8 -istrip stty pass8 export LESSCHARSET=latin1 ~/.inputrc 去掉注释即可 set meta-flag on set convert-meta off set input-meta on set output-meta on ~/.gitconfig [user] name = muhaha email = aa@bb.cc [color] diff = auto status = auto branch = […]

trac使用经验两则

最近开始使用trac进行项目管理,和svn同步。使用过程中解决了两个并不常见的问题,贴出来和大家分享。 如何修改trac的assign to下拉列表 让trac的ticket和bugzilla有同样的状态 如何修改trac的assign to下拉列表 trac ticket的assign to下拉列表中的名单,没有保存在配置文件里头。读一下TracFaq有下面发现: This will change the Assign To ticket filed into a select box that only contains existing users. However as it says on the TracTickets page, the user must have logged, in at least once, and set their email address. If you run multiple Trac sites, and […]