Archive for July, 2012

phonegap android service develop https://groups.google.com/forum/?fromgroups=#!searchin/phonegap/serviceandroid/phonegap/jLoVppraXc4/hke42KLipigJ BackgroundService class which extends android.app.Service I’ve added a Service node (within Application) in AndroidManifest.xml for the BackgroundService In my Activity (extends DroidGap) I call startService for the BackgroundService BackgroundServicePlugin class which extends Plugin BackgroundServicePlugin binds a ServiceConnection the background service BackgroundServicePlugin.js to expose functions to the html This all seems […]

  http://stackoverflow.com/questions/7110173/sencha-touch-how-to-avoid-slowing-down-ios-apps-inside-phonegap   Here are some nuggets: PhoneGap/Mobile Web Performance Tips * How Diary.com increased the performance of their PhoneGap app running Sencha: http://www.phonegap.com/2011/06/21/building-the-diary-com-ios-app-using-pg-sencha-touch/ * http://floatlearning.com/2011/03/developing-better-phonegap-apps/     * http://jslint.com/ – to debug your javascript     * http://zeptojs.com/ and http://xuijs.com/ – minimal alternative frameworks to jquery and jqtouch * Disable the accelerometer and location […]

交易方面 程序执行时间过长 Profile 解决Sql阻塞 + – 使用索引(定位,group,order) 简化sql 不要依赖sql完成计算工作(file sort,join,tmptable、求和) 严格控制那种随着历史数据的积累,exam rows越来越大的查询 当数据量放大到千万级别,exam rows是否能小于2k No sql 数据库是个同时应对很多很多服务(交易、数据、账户、票务、等等)的单点 预先计算 后台计算,并存入Memcache Lucence索引 变化触发索引更新 缓存 缺点:更新慢,缓存失效瞬间会有较大压力 Java或c重构 简化过于复杂的业务需求 要坚信:过于复杂的逻辑会让用户头晕并转身走掉 越来越大的访问量带来的压力 首先、要知道每个程序的负载能力(Requests/Sec)和scale能力(及瓶颈) + – 然后、要知道实际访问量(Requests/Sec),及趋势 要有预警机制 最后、及时扩充服务器 单期方案越来越多 方案列表对db压力大 简化列表逻辑 缓存 外部索引(lucene) 更新方案表时,造成锁表 永远可读 永远可写 过关统计、开奖慢 + – 基于任务的网格分布式计算 注数越来越大的单式方案 + – Map-reduce分布式计算 越来越多的程序,越来越多的故障点 在故障中生存 一次请求的失败不能影响其他请求 坚持做到运维友好 统一、易懂的配置文件 完整的安装、部署文档 做简单的程序 Keep it simple, […]

Gmail成功的秘密

Posted: 2012-07-08 in Uncategorized
Tags: , ,

以下内容是从某人从 斯坦福UI课程视频中摘录的, 这里描绘的是蓬勃发展期的Google,现在的Google已经不是昨天那个了。 今天的案例是 Gmail的UI Gmail刚推出的时候, hotmail yahoo等都还在10MB空间的等级, Gmail直接就是1G空间. 设计团队为了突出空间大, 广告就写”你永远不需要删除任何邮件”, 没有删除邮件的功能.结果, 遭到无数用户的强烈要求, 最后还是加上了删除按钮. Gmail最初的UI是由工程师team完成的, 后来UE团队才加入. Gmail设计团队中有专业的视觉设计师和交互设计师, 还有专门的研究员去分析用户行为, 分工倒是很细致 Gmail设计师说,他们通常喜欢用极小的团队来做项目, 办公室都是选特别小的, 似乎这样的沟通成本最低, 协作效率最高. 在我的实际工作中,深有体会, 十个妇女也不能生出孩子, 必须有正确的team才能够成功! 在IT领域, 一个天才的成就是100个普通员工都无法比拟的. Gmail团队所有人, 包括程序员,设计师,项目经理,客服都挤在一个小办公室,随时都进行沟通 Gmail的小办公室给团队很强的归属感, 里面有各种圣诞彩灯,有单独的冰箱,许多小吃,许多出色的想法,都是在晚上大家一起工作的时候才想出来 Gmail成功的一个哲学理念是,Encourage ownership, 要给团队创造一种归宿感, 对产品的有一种强烈的ownership,是成功的关键 Gmail team在2007年有80个成员, 但是只有1个manager. 管理效率之高,惊人 在google, 公司的层级非常扁平. Gmail设计经典案例, 在内置的IM窗口中, 最初的设计是没有send按钮的. 许多没有用过IM的用户,在到处找send按钮,但是IM窗口是在是太小了,只有200像素尺寸,加上发送按钮是在是太难看了. 并且本地化,各个国家语言中”发送”长度非常不一样 Gmail最后成功的让一个65岁老太太, 几乎没有用过电脑, 在5分钟内,就开始用内置的聊天功能和朋友聊天. 这个老太太甚至不知道这就是即时通讯 google 创始人经常对项目组说: 事情应该这样做xxx, 而Gmail […]