又一个Mac与Windows处理时相反的习惯:彻底删除文件

On

简而言之,在Windows下删除一个文件首先放入垃圾箱,再到垃圾箱选择某个文件,按下Delete键,将永久删除该文件;但是在Mac按下Command+Delete键把文件放入垃圾箱,再到垃圾箱选择某个文件,按下Command+Delete键,却是将该文件恢复。Mac下永久删除好像只有清空垃圾箱才行,甚至连单独永久删除一个文件的功能都没有提供。 由于不知道到这个细节,昨天浪费了很多精力。 事情是这样的,我和Yoyo这两天在家里玩,拍了些照片,通过iPhoto倒入到了Mac里。然后两个人一边欣赏自己的作品,一边删除那些垃圾照。看完之后,对留下来的这些照片还算满意。 然后,我到iPhoto的垃圾桶,由于一下子没想起Mac清空垃圾箱的快捷键Command+Shift+Delete,也没有通过菜单去清空垃圾箱,而是按下了Command+A全选,然后按了Command+Delete,结果却是把所有垃圾箱里的照片全部都又放了回去!悲哀啊。 看来Mac的使用还要慢慢的习惯啊,操作系统这东西不是一下子就能适应。

iFile是如何管理垃圾箱的

On

昨天通过iFile往iPhone上传了一个4GB的文件,用完以后删除掉,iPhone里的容量居然没有多出来. 以前也没有注意过这个问题,现在想想是因为iFile上删文件的时候,是提示使用垃圾箱的. 那iFile这个垃圾箱在哪里呢,跟OSX上的垃圾箱一回事吗,如何清空垃圾箱呢? 其实iFile这个垃圾箱只是一个目录,当我们删除文件时,iFile只是把文件移动到了这个目录下. 这个目录位于: /var/mobile/Library/iFile/Trash/. 所以要真正删除文件,只要把这里的文件删除就行了. 当然iFile在删除文件时是有选择的,你也可以直接删除. 关于清空垃圾箱,iFile的操作设计的有点别扭.只有当你删除文件的时候,在删除文件的对话框上有一个清空垃圾箱的按钮. 参考: http://forums.macrumors.com/showthread.php?t=1095614

jQueryMobile快速原型工具Codiqa

On

这两天试用了一下手机应用快速原型工具Codiqa. Codiqa的基本想法是在jQueryMobile的基础上做一些包装,提供一个可视化的工具,使产品设计人员能快速的搭建一个应用原型.进一步,如果以后的应用的开发是基于jQueryMobile的,Codiqa希望这个原型可以作为应用开发实际使用的基础代码. 类似想法的工具网站应该不少,但是基于jQueryMobile的却不多,或者我不知道. 我挺喜欢这类的原型工具的, Codiqa现在的功能还比较少, 甚至对jQueryMobile的支持也不全面, 但是以后应该会逐渐成熟, 希望Codiqa以后能在现在jQueryMobile的基础上能加入更多的组件和特性. 下面是我Codiqa使用下来的一些感受: 优点 快速构建原型,基本上就是拖拽,填填属性 可以创建多个jQueryMobile页面,支持配置页面间的跳转 可以上传自定义的jQuery Mobile theme, 可惜仅支持jQuery Mobile Themeroller生成的CSS,不能上传图片资源 30天内免费试用. 在免费期内把3个免费的项目都建出来,过了免费期就不能创建项目了,但是已有项目还是能正常使用. 可以在线共享,可以在移动设备上直接体验 可以导出Html代码,作为项目开发的基础 缺点 不支持UI元件的拷贝粘贴,配置一个数据多点的列表框需要很多次鼠标操作 不支持对话框元件, Dialogs 只有Page支持背景图片, 其他元件不支持背景图片设置, 不支持image sprite 不支持 Grouped buttons 没有一个好的列表内容元件. List 不支持 Nested list, Numbered list, Split button…

把Gmail的联系人同步到iPhone

On

今天用上了电信版的iPhone。配置好Gmail,联系人居然不能自动同步,只能同步日历,很郁闷。Google跟Apple的关系不至于僵到这样吧。 还好这只是个配置问题,解决办法就是在iPhone上配置Gmail账户时,不要选中Gmail,而当成Exchange来配置。 具体步骤如下: 添加账户时选择 Microsoft Exchange. Email字段输入Gmail的email地址 Domain字段空着,不必填 Username字段输入Gmail的email地址 Password输入Gmail密码 点击顶上的Next按钮,进入Exchange服务器配置页面 Server字段里填入m.google.com 点击顶上的Next按钮,选中要同步的内容:邮件、联系人、日历都可以选。 参考: http://support.google.com/mobile/bin/answer.py?hl=en&answer=138740

CSS3 transform 在webkit内核浏览器下的锯齿问题

On

前两天一个同事作业面时,碰到一个锯齿问题。他使用了一个css的transform方法,把一张图旋转了4度,-webkit-transform: rotate(-4deg);-moz-transform: rotate(-4deg);,结果在Firefox里很正常,但是在Chrome和Safari边缘都有严重的锯齿。 后来在StackOverflow上找到了答案。原来webkit内核的浏览器的CSS变换普遍有这个问题,只有在OSX下的新版本的Chrome里已经修复了。现在的解决办法是通过使用css的3D变换来启用GPU加速,通过GPU渲染的变换是进行了防锯齿处理的,效果好很多。具体方法就是在transform属性里加一句translateZ(0)。看看对比图吧: 还有一个问题,感觉经过GPU渲染出来的页面,整个页面都有影响,字体比没经过GPU渲染的页面要淡和细一些。不知道这有什么说法吧。 您可以在这个页面试试,删除translateZ(0)能看到“HTML render with/without CSS 3D”这段字的显示效果有明显变化。 也截两张图放这里对比一下: 参考: http://stackoverflow.com/questions/5078186/webkit-transform-rotate-pixelated-images-in-chrome http://stackoverflow.com/questions/6846953/wonky-text-anti-aliasing-when-rotating-with-webkit-transform-in-chrome

流动水果摊的骗术

On

这几年收到过几次100元的假钞,每次基本上都是在路边的流动水果摊上被骗的。 他们先收入你的真币,然后找各种借口让你调换,其实是把他们的假币调换给了你。 唉,只能感慨大家的演技都越来越高了,演艺圈不好混了啊。 故事通常是这样的。上海街头巷尾有很多开着卡车,在路口卖水果的水果摊。 这样的卡车流动水果摊,一般有两个摊主,通常是一男一女,像是一对夫妻。 给人感觉是地道的农民,开着自家的车,拉着自家的货,自产自销。 车上一般都是卖些时令水果,比如现在是卖西瓜,过几个月就是卖橘子什么的。 当你买好水果,准备付钱的时候,骗局就开始了。 如果你付的是零钱,摊主会先把你的钱收了,然后马上告诉你你的钱缺了一个角之类的,让你换一下。 这时如果你没有零钱了,就只好付100元的了。摊主会先把你的钱收下,然后做出找零钱的样子。这时另一个摊主通常就会过来,一起找零钱,其实都是为了扰乱你的视线。然后告诉你算了,还是给他们那个缺角的钱吧,并把100元退给你。其实这时候的100元已经是他们调换的假币了。 如果你一开始给的就是100元,那就更简单了,两个摊主,一个会不停的跟你说话,你个作出检验你的纸币的样子,然后告诉你能不能给换一张。让你感觉好像自己在使用假币一样,其实你原来的纸币已经被他们换掉了。 上了几次类似的当了,吃一堑要能长一智才行,不能老是上类似的当呀。 纪录一下,希望大家遇到类似情况是心理有个准备。 上当的原因其实主要还是自己贪小便宜,觉得这种流动水果摊上的水果既新鲜又便宜。 其实这些水果摊上的水果通常品种不好,而且称水果时用的称也不标准。 现在摊主又开辟了这种换假钞骗钱的新生意,真心建议大家尽量改掉这种贪小便宜的心理。 防范手段 尽量不要在路边的流动水果摊上买了 付钱时自己先看清楚自己的钱有没有破损 再路边不要使用面额比较大的纸币,甚至自己可以做些标记,比如按一定的规则折一下纸币 最后祝愿卡车流动水果摊的摊主们早点找到更有效的营收手段,别再坑蒙拐骗了。

开发人员无法重现生产环境上的问题怎么办?

On

最近碰到了一个比较奇怪的问题,一个用rewrite实现的Wordpress分页功能在测试和开发服务器上都没有问题,但是上线以后在生产环境上有问题。而且时有时无,很难找出规律,确定不了到底是什么地方出了问题。 已经采取的一些尝试,但是没有解决问题: 查看生产环境错误日志 同步生产环境上的数据库、各类配置,在测试服务器上试图重现 让IT配合,修复生产服务器上的一些可能的潜在问题 添加一些额外的运行日志 但是这些过程,由于要经过公司开发、PM、测试、IT等几个部门,效率非常低。反复几次大家之后没有结果,大家的情绪也都比较失落。最终也没有找到问题的所在,两周之后PM决定放弃解决这个问题,尝试别的实现方式。 虽然问题没解决,但是感觉以下几点以后还是要注意的。 1.争取在线调试的权限 虽说平常,开发人员不应该直接接触生产环境(应该通过工具,自动提交、测试、发布、验证)。但是在出现一些棘手问题时,开发人员有环境能重现问题是必要的,即使是在生产环境。在遵循一定的规范,谨慎小心的前提下,对生产环境有一定的访问处理权限,将有利于尽快找出问题所在,在以后的代码或者环境中避免类似问题。 2.开发发布流程有没有有缺失什么? 现在比较流行的开发部署模式是CI(持续集成开发),很多公司能做到每天向生产环境发布部署多次代码(有的甚至是几十次上百次)。 现在我们公司离这个水平还很远。我们现在的流程是QA和IT在配合部署更新,通常是一周为单位的。 即使我们不提CI,我们实际上还缺少一个staging server环境。简而言之,staging = production – users 。staging上应该能重现生产上能出现的问题,staging更重要的意义在于可以在部署更新到生产之前拦截可能出现的问题,在问题出现在生产环境之前暴露并解决。 我们没有一个几乎等同于生产环境的调试环境,测试和开发服务器跟生产环境有这样那样的差别。 当然更重要的是,我们的发布更新过程有还有很多手工过程,这不但易出错,而且也是造成环境差别的来源之一。 只有不断的把手工过程变成脚步,变成每个人随时都能使用的工具,才能提高发布效率,向CI看齐。不过这需要一个工程师主导的企业文化环境,在我们公司现在还很难。 3.换种方法实现,或者放弃吧。 当在一个问题上纠结太久时,也许该放下来想一想。这个功能必须这样做吗?换种方法行不行?这个功能真的有必要吗?不做行不行? 虽然有时候这些问题也不是我们能决定的,但是建议建议,也许会有意想不到的有好处。 参考 Different methodologies for solving bugs that only occur in production Staging Servers, Source Control &…

IT必杀技:重启

On

The IT Crowd里有句名言:”Hello IT, have You Tried Turning It Off And On Again?”。这里有相关的视频。 最近我也有幸做一把IT,用了一次这个必杀技。 事情是这样的。最近Yoyo在一个小朋友家里,家里除了他们两个八九岁的小朋友,还有两个60岁左右的老人。老人有时候上上网看新闻,小朋友有时候在电脑上玩游戏,好像他们会到4399上去找游戏玩。 前段时间他们的电脑坏了,显示器没显示,碰巧我在,就帮着开机箱,乱测试。最后也不知道怎么好的,反正好了,大概是电源有些地方松了。 前几天,上班的时候,突然接到他们家来的电话,结果是Yoyo打过来的。 Yoyo说,电脑又坏了,让我去修。我以为还是硬件问题,就说晚上下班来看看。 Yoyo又说,显示器没显示,找游戏时显示网络连接失败。 看来不是硬件坏了,大概是网络断了。 但是我怎么跟Yoyo说,让他检查哪里出了问题吗?难啊,他们家里就两个娃娃加两个老人,都讲不清楚啊。 我愣了一会儿,硬着头皮说,“你先把电脑关了,再把接着网络的接线板电源关掉。等一会。再把电源打开,再把电脑打开。” 小朋友们也不知道懂没懂,后来我就把电话挂了。不过Yoyo也没有再打过来,难道好了? 晚上回去,见了Yoyo,说起这件事,还真的好了。 呵呵,其实有时候,不必太关心细节,直奔主题,用最简单的方法把问题解决了才是重要的。 Hello IT, have You Tried Turning It Off And On Again…

再谈破解Snoopy’s Street Fair小狗币,兼App Store应用内购买的破解

On

有时候换个思路想问题,得到的结果会很不一样,很简单。 比如破解Snoopy’s Street Fair小狗币时,我是按照以前玩单机电脑游戏的思路:游戏的纪录都保持在本地,只要找到了保存纪录的文件,就可以通过玩游戏时该文件数据的变化来找到保存数据的具体内容和位置。 这招确实管用,但是就是太繁琐了,而且要借助些文件比较的工具,耐心的找想要的数据。 当数据变化不是很明显时,这个方法就不太管用了。 其实类似Snoopy’s Street Fair的这种购买方式在Apple的应用商店上叫做应用内购买。 现在很多App采取这种销售方式:允许免费使用App,但是只是基本功能或者有限的道具,当需要更高级的功能、更多的道具时,就会引导用户进行购买。 关于应用内购买的破解,其实早就有了。原理我猜大概是截获App Store的应用内购买接口,永远返回购买成功。具体步骤不清楚。 所以在玩Snoopy’s Street Fair时,如果你想获得更多的小狗币,其实不必像我之前那样那么麻烦,你只需要安装相关的软件,就可以一劳永逸的破解很多应用内购买了。 具体的步骤是这样: 首先你必须确保你的iPhone或iPad是已经越狱过了的 如果你符合条件1,那么就可以进入Cydia 进入Manage,进入Sources;点击Edit,然后点击add。添加这个源到Cydia: cydia.xsellize.com 。如后图所示。 现在在Cydia里搜索iAP Cracker,并安装。 OK,如果一切顺利,应用内购买破解就完成。 值得注意的是如果破解成功,在进行应用内购买时是不需要输入App Store的密码的!所以如果提示输入密码,说明破解不成功,输入密码将会扣费,谨记。 破解有风险,后果请自负。 这里有一份iAP Cracker支持的App列表。 不过看来iAP Cracker还不支持Where’s My Water?,玩小鳄鱼的同学们还要等。知道如果破解小鳄鱼应用内支付的方法的请赐教啊。 参考自:http://www.technobolt.com/2011/12/24/how-to-get-free-crack-in-app-purchase-on-iphone-and-ipad-apps/

软件项目的任务积压管理

On

这是一篇关于如何管理软件项目需求、任务、缺陷的文章,来自大名鼎鼎的Joel Spolsky, StackOverflow的创始人。 想像一下你生平第一次来的一家面包工厂。开始这里看起来像是一个无法理解的杂乱不堪的机器,一些工人在里面东奔西跑的忙碌着。仔细再看看,你就会看到一些你认识的东西。一些桶装的芝麻,大桶大桶的面团,一些小面球,还有些烤好了的面包条。 这些都是库存,或者叫积压。积压逐渐的堆在机器之间。在机器边上,是大桶的将被撒在汉堡面包片上的芝麻。生产线的尽头,是些装满面包的箱子和空箱子。它们在等着被卡车运到商店去。 维持积压需要费用。假设你的面包厂有6个50吨的面粉贮仓。贮仓空下来时,你就会把它填满。这意味着平均你有150吨面粉积压。按照现在的价格计算,你需要73000美刀来维持这个积压。一直需要占用这么多钱。 积压还有别的消耗,比如腐烂、变坏。面粉可以储存几个月,但是面包从它们出炉的那一刻起价值就在不断的降低;24小时之后,基本上就一文不值了。 为什么还要要保持有库存,有积压呢?因为缺货也会造成损失。如果订购芝麻需要2天,在你的芝麻用光的时候,你就2天没办法生产面包。库存可以防止类似的生产流程上的阻塞。丰田汽车的精益生产系统和限制理论,可以指导我们优化每一个生产环节上需要多少缓冲库存。 为什么我会关心这些呢?因为软件开发流程上也有几个主要的积压堆积点。这些环节上的堆积,会造成大量的时间和金钱的浪费。 你也许会问:“什么?软件怎么能跟工厂比呢?” 好吧,想像一下,把产品想法当作生产原料。根据你的流程不同,产品想法可能会经过下面这几个开发阶段,才最终完成为客户看到的软件的特性。 特性决策阶段 (我们真的需要实现这个特性吗?) 设计阶段 (特性描述, 白板讨论, 原型测试, 等等) 实现阶段 (软件编码) 测试阶段 (抓虫) 修复阶段 (杀虫) 部署阶段 (把代码发送给客户,或者部署到WEB服务器,等等) (备注: 不是,这可不是“瀑布式开发”。真的不是。 真不是。 闭嘴。) 在这些阶段之间,就可能产生积压。比如:当程序员完成了代码开发(阶段3 实现阶段),把代码交给测试人员去测试(阶段4 测试阶段)。任何时候,都有一定量的的代码等着被测试。这就是代码积压。 代码积压的代价是巨大的。它很可能累积成6到12个月的工作量,导致生产线卡壳,产品交不到客户手里。这甚至有可能造成巨大的差别,就像时髦的尖端产品(如iPhone)跟永远在别人屁股后面追赶的产品(如Windows Phone)这样的差别。几乎不会有人会去购买Windows Phone,尽管iPhone其实仅仅比它先进6个月而已。很多市场都有网络效应,领先者意味着赢取几乎所有的份额。所以在开发流程上消除积压,能创造或毁掉一个产品。 现在我们来回顾一下积压累积的3个主要环节。 1.产品特性点子库 每个产品都有很多新点子,你实现点子的速度永远赶不上新点子涌现的速度,所以你就把他们记录下来,这就形成了产品特性点子库。点子库里很多点子其实是坏点子,你把他们记录下来,只是为了避免伤害想出这些点子的人的感情而已。点子库看起来能让每个人都感觉良好。 问题是,这些点子中90%的点子永远也不会被实现。所以花在这些永远也不会被实现的点子上的分分秒秒,记录、设计、思考、讨论,都是浪费时间。当我听说产品团队定期的开展“点子库梳理”会,在会上仔细的研究这些永远也不会被实现每一个点子,每天、每周细心的浪费着自己的时间和精力,我戳瞎自己眼睛的心都有。 建议:不要让点子库里的工作超过一或两个月。如果点子库满了,不要加入新的项目,除非你删除掉一些别的项目。不要花时间细化说明、设计、讨论这些点子库里的项目。产品特性点子库事实上应该被视为是一个关于你现在还不用讨论或开始工作的项目的列表。 2.缺陷数据库…