在前两帖的基础上,继续从USPTO上搜索了一下Yahoo!在社会化网络SNS方面的专利。其中几个新的专利申请涉及SNS与移动结合的应用领域。
基于社会化网络活动信息的情景移动本地搜索(CONTEXTUAL MOBILE LOCAL SEARCH BASED ON SOCIAL NETWORK VITALITY INFORMATION)。
涉及移动搜索领域,但至少部分地以社会化网络的活动信息为基础。
主要内容是一种通过网络运行搜索的方法,包括:从客户端设备接收至少含有该设备所处地点的活动信息;利用地点和日期时间(如用户的日程安排)等活动信息,限定社会化网络的情景;再向客户端设备提供基于社会化网络情景的搜索结果。
在我的社会化网络中向他人提供我的状态信息(PROVISIONING MY STATUS INFORMATION TO OTHERS IN MY SOCIAL NETWORK)。
涉及移动通信,通过一种网络向社会化网络的其他用户提供某个用户在社会化网络中的状态。
主要内容是一种通过网络运行通信的一种方法,包括:通过一种应用协议,接收一个用户在社会化网络中的状态;以接收者在社会化网络中的会员资格为基础,选择接收者;以该用户与接收者之间的关系,区分该用户的状态;通过另一种应用协议,向选定的接收者发送被区分的状态。
UCDChina预组建”UCD翻译小组”,现征募志愿者加入本小组。为打通东西方UCD理论方法渠道,尽快缩短国内外产品从业人员的差异,尽自己一份绵薄之力。
我们目前只从国外设计师的博客文章中挑选适合国内环境的内容来翻译,不打算翻译书籍。
报名联系:angela.fan@msn.com
翻译小组规则:
1. 小组成员自愿加入、自愿退出;
2. 小组成员可向Group推荐值得翻译的文章;
3. 小组成员可自愿翻译自己感兴趣的文章;
4. 翻译的文章发表在自己的博客内,由UCD大社区收录;
5. 如没有自己的博客,可直接提交到UCD大社区;
6. 大约每月每人1~2篇文章,每篇文章需要你牺牲大约1~2个小时的私人时间。
我们能为你提供以下支持:
1. UCD大社区优先录入,话题/分类优先推荐;
2. 享受各种UCDChina团队成员的待遇;
你需要:
1. 对UCD方法和流程、互联网产品市场、交互设计、界面设计有一定了解,有相关工作经历更好;
2. 有一定的英文阅读和理解能力,较强的中文表达能力(翻译和阅读不是一个难度级别哦);
3. 自我约束力较强,对质量要求高,认真负责;
4. 有毅力,能坚持。
转载请注明出自UCDChina.com,谢谢。
两年前初识豆瓣,就被这个不一样的网站吸引,这不是一个喧嚣的网络社区,也不是大杂烩式的网络媒体,更像是一杯茶,需要在下雨天一个人静静地,伴着荧光显示屏,慢慢品;直到水木上那个招聘广告的出现,让我与豆瓣,不再隔着那个小小的荧光屏了。
豆瓣初印象:一如那个低调精致的网站,豆瓣工作室隐秘在兆维工业园区密丛深处,宽敞明亮的办公室将钢筋水泥混合体的压抑感一扫而空,各种绿色植物、书籍杂志、饮料咖啡,还有画板上随意写下的只言片语,无不向我传递着这样一条信息--热爱生活,热爱工作。
精英团队:处于快速成长期的豆瓣,来自于其背后强大的精英团队。电影、新闻、计算机……各个领域的佼佼者汇集一堂,为着同样的梦想和理念,每个人都发挥出自己最大的热情和潜力,还有什么力量比这更强大?
成长空间:我没有专业的产品经历,也没有UI素养,阿北说,这是最不重要的。就是这样一句话,让我相信我可以在豆瓣得到我想要的空间,让我在开始怀疑自己的时候坚定了“做自己喜欢做的事”的信念。
帮助中心讨论会上,能在大家面前展示自己构思已久的计划是我最开心的事情,尤其当自己的设计和理由能够说服别人的时候。当然,在得到部分肯定的同时,必然也会发现考虑疏漏的地方,K以站务论坛老管理员的身份提出我遗漏的需求,T以专业UI的角度提供有价值的界面设计意见,产品组各位老大则在产品设计角度上提出各自的建议和理由,B大侠最后进行了文案的把关。在互相补充意见和需求的不断迭代中,帮助中心在不断完善,我的思路也得到不断拓展,对产品设计流程的概念也越来越清晰。在产品构想被肯定和批判的过程中,我逐渐明白一个职业的产品经理是从什么角度思考的,如何把一个产品需求考虑完备,以及细节的推敲是多么的重要。
广场改进讨论会上,由对广场这个产品的不同期望,产生了不同的定位,从而导致了不同的产品设计思路。两方各抒己见,各有道理,讨论会不断升温……在这样“唇枪舌剑”的沟通中,我学会了如何虚心倾听,又如何将自己的想法清晰表达,即使最后自己的意见不能被采纳,各位产品老大周全的考虑、充足的理由也让我心服口服,得到一条条宝贵的经验和真传,仿佛我有多位老师,远比猫在家里读十本《产品设计教程》要实惠得多。更重要的是,每当遇到这种分歧情况(事实上经常遇到),最后的决策往往来自于用户的真实数据—–产品设计永远是不断迭代发展的过程,没有谁的决策是永远正确的。
初步确定产品需求后,就进入了技术沟通的环节。开发人员从技术实现的难度和性价比对产品设计进行了重新的审视,经过反复讨论技术方案,我开始更多地了解了如何在需求和实现难度之间权衡,如何根据需求选择高效的技术方案。在这样不断的沟通和产品改进过程中,我也体会到了开发人员的辛苦,也深深感受到整个豆瓣团队在追求产品完美的过程中,互相体谅、紧密合作的氛围。
当然,在为了一个产品“绞尽脑汁、互相辩驳”之后,doubaners 永远不忘工作之外的休闲,与对面公司的足球联谊赛、周期性的看电影活动,还有午饭后的桌上足球和wii,甚至讨论会结束后桌上的零食饮料残骸,都在诉说着doubaners丰富多彩的生活……
已近三个月的实习期,每时每刻都让我感受到自己的成长:从讨论需求和产品设计时的头脑风暴,到产品细节功能设计时的谨慎和专业审视,每一次思维火花的碰撞,每个人对产品以不同角度的理解和阐述,都是我最精彩的课堂。在产品团队对我幼稚想法的不断批判和纠正下(Orz),还有技术团队的支持下,我负责的项目陆续上线了,这对于一个实习生来说,是最好的锻炼和鼓励--感谢每一位同事的耐心和帮助,正是信任、平等、独立的团队合作关系让我实实在在地进步着,和豆瓣一起成长着。
在路上,我是,豆瓣也一样。
此刻,我们的2009年校园招聘也拉开了序幕,请访问:campus.douban.com
再来攒个人品,介绍下产品团队面经吧^_^:
1. 准备好简历;首先做到尽量match,当初我就是对着招聘要求一条一条想自己有哪些可以match的哦~;但更重要的是展示真实的自己,千万不要牵强,豆瓣喜欢diversity, so just show yourself!
2. 接着就是更重要的了—求职信(必不可少哦),注意不是自己经历的重复哦,这些在简历里都有了;这封特殊的求职信要写上自己对豆瓣的使用感受、意见或建议,有什么说什么就成,如果是发现了问题,那么说清楚是什么问题,怎么改进,为什么这样改~;记得和简历一起发到team(a)douban.com
3. 简历这关过了以后~就是第一轮面试了~我有幸见到了2位pp和nice的产品经理^_^ (稍带手拍一下,表砸我。。。),第一位主攻细节上的产品设计,第二位则侧重宏观的对互联网的了解和想法,平时在上网的时候从产品设计和用户体验角度多思考,关注互联网动态基本就具备了基本的素质了。
4. 最后一关就是见阿北,一开始阿北严肃的表情确实比较煞人。。。。不过开始面试进入状态就好了,主要是从了解你这个人入手,在产品方面也会考查一下,不过不用怕,阿北还是很和蔼滴~
总之,对于有志加入豆瓣这个大家庭的各界人士,豆瓣都是欢迎的,大家赶紧投啊!
The trouble with slave lag is that you often can't see it coming. Especially if the slave's load is pretty uniform, a slave that's at 90% of its capacity to keep up with the master can be indistinguishable from one that's at 5% of its capacity.
So how can you tell when your slave is nearing its capacity to keep up with the master? Here are three ways:
One: watch for spikes of lag. If you have Cacti (and these Cacti templates for MySQL) you can see this in the graphs. If the graphs start to get a little bumpy, you can assume that the iceberg is floating higher and higher in the water, so to speak. (Hopefully that's not too strange a metaphor.) As the slave's routine work gets closer and closer to its capacity, you'll see these spikes get bigger and "wider". The front-side of the spike will always be less than a 45-degree angle in ordinary operation[1] but the back-side, when the slave is catching up after lagging behind, will become a gentler and gentler slope.
Two: deliberately make a slave fall behind, then see how fast it can catch up. This is sort of related to Method One. The goal here is to explicitly see how steep the backside of that slope is. If you stop a slave for an hour, then start it again and it catches up in one hour, it is running at 1/2 of its capacity. (In case that's confusing: if you stop it at noon and restart it at 1:00, and it's caught up again at 2:00, it played all statements from 12:00 to 2:00 in 1 hour, so it went at 2x speed.)
Three: measure it more scientifically. Use our patched server, which gives you a USER_STATISTICS table.
You can compare the BUSY_TIME to one-half the CONNECTED_TIME (because there are two replication threads on the slave) to see how much of the time the slave thread was actively processing statements. If the slave threads are always running, you can just use the server's uptime instead.
[1] There are cases where this isn't true, especially if you're monitoring Seconds_behind_master instead of using mk-heartbeat, which is immune to this anomaly.
Entry posted by Baron Schwartz | 5 comments
十月 2008 | ||||||
一 | 二 | 三 | 四 | 五 | 六 | 日 |
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |