AmourGuo's Album

2010国庆噺彊自驾游计划概要

预计行程为16天，时间大概会在2010年的9月25日--10月10日，
大家提前好好把下半年的工作安排好，做好十月前后请年假的准备。
线路：北京->太原->吕梁->张掖->酒泉/敦煌->哈密->吐鲁蕃->*伊犁
往返里程7千公里左右，每车至少要安排2位司机，
比较理想的车辆数是2-3车，人数为4-12人，
人均费用根据个人的消费情况估计约在3000-5000元，

现有两种方案，两种方案的费用相差应该只在千元以内，在第一次成员碰面会后最终确定：
  1) 直接从北京开车去，一路上一半以上是高速，还有不到一半是国道，不好走的路段很少，小车足矣，当然，如果有越野或SUV更好啦^_^
  2) 北京<->乌市双飞，到乌市后特纳的家人会提前帮着找好车辆，这样会省一些在路上的时间（开车单程北京到新疆要3天），不过相对的也会错失一些沿途看风景的乐趣。

具体计划正在商议之中，欢迎提供宝贵意见！

* P.S.是否考虑找一下车身广告的赞助？嘿嘿～

欢迎登录此次新疆游的官方Blog查看更多更详细的内容：http://sinkiang2010.blogbus.com（内容还在完善中）。

美食↓

美景↓

美女↓

总有一样是你所爱～来吧～加入我们！:-)

想加入我们一起畅游新疆的同学可以在BLOG的评论中留下您的联系方式，我们会联系您；或者直接把你的个人情况发送到邮箱：amourguo(at)gmail.com。只有一个小小的前题：你必须是有独自行为能力的靠谱青年！ 如果你再有辆SUV或是越野那就更完美啦～

又翻译了一篇关于SNS的文章:-)

Top 5 Ways to Make Your Site More Fun |
[译]五大法宝让你的网站/产品更具趣味性

原作：Gabe Zichermann是《游戏式营销》（Wiley出版社，已出版）和《趣味件（Funware）实战》（Manning出版社，预计2010年第三季度出版）的作者。同时他也是新兴的专业移动社区网络公司beamME的CEO，我们可以在http://funwareblog.com上看到很多他关于游戏和世界的想法的文章。
译者：阿木（http://waymangood.spaces.live.com , amourguo(at)gmail.com）

    Just like sex, fun sells. The early proof of that can be seen in the amazing success of location-based networks such as Gowalla(), MyTown and Foursquare(), and in the breakthrough marketing efforts of major brands like Nike, Coke and Chase. Even finance made fun can be a winner — Mint.com’s meteoric rise was in no small part due to the fun, social engagement of its approach. Ever feel elated while using Quicken? I didn’t think so.
    有趣的东西总是很受欢迎。在这一点上，已经有很多令人兴奋的成功案例，比如基于地理定位的社区网络：Gowalla, MyTown 和 Foursquare；再比如在营销上取得巨大突破的公司如Nike, 可口可乐, 和Chase等；甚至是原本枯燥的财经类应用如果设计得富有趣味性的话，也能成为赢家——Mint.com（译者注：知名个人金融网站）的快速成长在很大程度上也归功于他的趣味性和社会融入度，而你在使用Quicken（译者注：一款专统的家庭及个人财务管理软）时会觉得有趣吗？呵呵，反正我不这么认为。

    The trend continues, with an ever-increasing number of startups looking to get an edge with consumers through fun. Their weapons of choice: Game Mechanics.
    这种趋势仍在继续，越来越多的新兴公司依靠趣味性来博得用户的青睐，而他们手中的武器就是：游戏机制。

    When taken together, game mechanics such as points, leaderboards, badges, challenges and levels form part of what we call a Funware Loop. In my latest book I argue that the best and most compelling loyalty programs are built extensively around Funware and when applied creatively, can make any consumer web or mobile app experience more engaging.
    归纳来讲，这些游戏机制诸如积分、排行榜、徽章、挑战和等级，共同形成了一个环，我们称之为趣味件环（译者注：Funware Loop，好像没有什么中文短语可以把这个翻译得恰到好处）。在我的新书中我也谈到了，最好的、最有说服力的用户忠诚度计划（loyalty programs）必定要围绕着趣味件这个核心进行并且要有创造性的去运用它，这能使无论Web应用或是移动应用都获得更加精彩的用户体验。

    Whether you sell organic foods online, develop mobile application or run the world’s largest social network, you can benefit from applying the 5 simple strategies listed below to increase engagement.
    无论你是在线销售有机食品、开发移动设备应用程序或是运营世界顶级的社区网络，你都可以通过推行下面将要提到的这5条简单的策略并从中获得收益。

    After all, who doesn’t like a little fun every once in a while?
    毕竟，谁会不想不经意间生活中能多一些有趣的玩意儿呢？

1. Points | 积分

    Points are an essential part of any Funware Loop, and a great starting point for “gameifying” your site or app. Points allow you to keep track of user activities and make it easy to shape user behavior. Start by listing all the actions that you’d want users to perform and assign relative values to each, taking care to get the balance right.
    积分是趣味件环的一个基本组成部分，积分是“游戏化”你的网站或应用程序的一个绝佳的起点。积分策略让你可以了解用户的行为，并引导用户形成你所期望的更加健康的用户行为。首先你可以列出你期望让用户去做的所有的行为，并给这些行为分配相应的分值，当然，在分配的时候要注意保持一定的平衡。

    In most cases, you’ll want to emphasize user growth and engagement, so be sure to offer healthy point slugs for referrals and activities that generate user interaction (adding friends/followers, for example). Keep your point denominations reasonable: if you begin by giving away millions of points for every activity, you’ll reduce your future room to grow. Also don’t over design to deal with cheaters on day one; you’ll have plenty of time to work on that later.
    在大多数情况下，你都会比较重视你的用户的成长和容入度，所以对于能产生有益的用户交互(如：添加好友、添加关注者等)的用户和行为要给予积分奖励（译者注：即心理学上讲的正激励的引导方式）。确保你的积分体系的制定是合理的：如果你一开始就把上百万的积分都分配了各种行为，这无疑是扼杀了你未来的成长空间。另外在开始时也没有必要针对可能出现的作弊者做过度的设计，首先要关注最重要的部分，你之后还有大把的时间去做这些。

    Once you’ve begun to assign points for various activities, you’ll need to ensure that you’re giving users an easy way to see their score and how they compare against others. The easiest way to accomplish both is with a leaderboard.
    当你开始为各种各样的行为分配积分的时候，你要确保能你给予用户一个简单的途径去查看他们的积分，并方便让用户可以与其他用户进行比较，而最简单的实现方法就是排行榜。

    Points help your users keep track of how they are doing in your app. Here, popular mobile social network MyTown uses dollars in lieu of points (something you should generally avoid unless it’s thematically relevant to your site/app).
    积分策略可以帮助你的用户了解他们在你的应用中的状态。如上图，知名的移动社区网络“MyTown”使用了美元“$”作为他们积分的计量单位（通常来讲，你应当避免这样，而是选择一项跟你的网站/应用相关的积分计量单位，如QQ的Q币、开心网的开心币）。

2. Leaderboards | 排行榜

    Like the scoreboard at a sporting event, leaderboards are a universal way to convey to your fans and customers that a “game” is being played. The key to being successful with a leaderboard mechanic is to ensure that users are motivated by friendly competition while simultaneously not de-motivated by users who are better, faster and have been playing longer than them. There is no better solution to this problem than Facebook Connect.
    就如同一些赛事上的计分榜，排行榜可以让你的用户能够意识到他是正在“玩游戏”。通过排行榜的机制获得成功的关键就在于，要通过友好的竞争让用户得到激励，同时又不能因为其他用户更好、更快或是加入的时间比他更早而让该用户失去希望和动力。对于这个问题，似乎没有比Facebook Connect（译者注：允许用户从外部网站访问 Facebook 数据，这使得普通网站也可以具有社交功能。详见http://developers.facebook.com/connect.php）更好的方案了。

    The easiest option: show the points accumulated by your customers relative to their social graph, giving them a contextual ranking. Through callouts, illustrate how easily they can rise to the level of their next-highest performing friend (e.g. “invite two more people to beat Debbie’s score”). Of course, you should also show a global Top 10 and geo-located leaderboards if you can, but these should actually be somewhat buried in your design.
    最简易的方案：展示相对于用户的社交关系的累加积分，并给予他们一个相应的等级。通过标注（比如那种消息气泡），告诉用户他们如果想让自己的级别超过他的一位当前级别更高的好友是件很简单的事（例如，当用户查看他的好友“Debbie”的时候则提示他：“只需要再邀请2位好友，你就可以超过Debbie的分数”）。当然，你也可以不仅仅展示一个总榜行，还可以展示一个本地排行（比如基于你所在的城市，或是你的好友圈），但是由于信息量会过大，你应该把一些功能巧妙地“藏”在你的设计里。

    Though points and leaderboards are quite powerful (and sufficient for most game-like experiences that target the achiever in us), they lack the ability to create social rewards for parallel or tangential activities. For that, there are badges.
    虽然积分和排行很有用处（并且对于大多数的游戏式体验的应用也已经足够了），但是它依然缺少对平行活动或切向活动提供社会性奖励（例如关注、认可、表扬和感谢等等）的能力。这时，徽章机制就应运而生了。

 
    Social leaderboards, like this one from the wildly successful Facebook game Who Has the Biggest Brain (Playfish/EA), show your score relative to your friends on Facebook, making it easy to both feel successful and competitive at the same time.
    上图中的排行榜，来自最成功的Facebook游戏——Who Has the Biggest Brain(Playfish/EA)，它显示了用户相对于其他Facebook好友的积分，这让人既有成就感又有竞争的压力。

3. Badges | 徽章

    The best way to think about badges is as a demonstrable, fun reward for a specific activity that is easily socialized with others. Much as Boy and Girl Scouts receive merit badges for particular activities, you too can create an almost limitless set of attractive, visual objects that can be “sewn” onto a users’ social graph – typically their Facebook wall or Twitter stream. By giving your customers an easy thing to crow about, you maximize the likelihood that they will evangelize your site/product to others while also creating a positive association for them.
    最好的理解徽章机制的方式就是：他是一种针对特定的社会化行为的可供展示的趣味性的奖励形式。就像美国童子军的奖章一样，你也可以无限量地设定各种诱人的、形象的徽章并把它们“缝合”到用户的社交体系上，比如说用户的Facebook wall或是Titter stream。当你的用户有了这些吹嘘的资本之后，他们在向身边的人炫耀并建立他在他圈子里的地位的过程中，你的网站和产品也就同时得到了宣传。

    Think of badges as rewards for ongoing contests that users are constantly engaged in – whether or not they are directly connected to point balances. In many applications, badges are issued without warning (see Foursquare), leveraging the power of operant conditioning – like slot machines – to keep users playing. Where possible, offer an auto-tweet/post option for your badges – braggarts are a great way to get the word out about your app.
    把徽章作为用户参加各种竞赛的奖赏，无论这些竞赛是否是直接地与积分相关联。在很多的应用中，徽章是在没有预兆的情况下颁发给用户的（如Foursquare），这样可以巧妙地进行用户的可控行为调节，就像老虎机一样，吸引用户有不停地去玩。如果可能的话，为徽章系统提供一个获得徽章后自动发布消息的功能，用户之间的相互夸耀是让你的应用传播到全世界的一个很好的途径。（译者注：QQ会员的徽章系统和开心组件“非常礼遇2010”中的勋章好像就部分遵从了这一原则）

    Where badges are frequently (though not always) given as a reward for a set of non-obvious activities, challenges are a direct way to engage users around a specific task – and are an essential part of the Funware Loop.
    当徽章频繁地（虽然不总是）为一些并非显而易见的活动颁发给用户作为奖赏的时候，挑战机制则是吸引用户来参加某项任务的一条直接的办法，它也是趣味件环（Funware Loop）中的一个基本部分。

    A badge by any other name is… a ribbon? Farmville, the uber-popular Facebook game uses ribbons to offer periodic rewards to users. Where possible, make your badges attractive and relevant to your users.
    徽章的其他形式也可以是...绶带？在Farmville（Facebook中的一款很受欢迎的游戏）中就使用了绶带来为用户提供周期性的奖赏。如果可能的话，把你的徽章做得更具有吸引力一些，并且最好与你的受众用户群的特点相关。

4. Challenges | 挑战

    Most walkathons and sales campaigns start with a challenge: “sign up ten walkers/new customers/friends and receive a reward.” Everyone has, at one time or another, taken up a challenge like this, and they are an essential part of an end-to-end system for customer loyalty. Once you have a sufficient group of users collecting and comparing their points, you can start offering them the option to compete for more points and virtual rewards.
    在大多数的步行马拉松慈善筹款和促销活动中，一般都是以某项挑战作为开始：“发展5个慈善步行者/客户/好友，你就可以得到奖励”。几乎所有的人都曾不只一次地接受过这种挑战，而这种挑战也是用户忠诚度衔接系统的一个基本组成部分。一旦你积累了足够多的用户并允许用户进行积分比较，你就可以开始鼓励他们为更多的积分和虚拟奖励而展开相互竞争。

    For example, you could offer users 10,000 bonus points for signing up 4 friends for your service. Automate the notifications, issue a congratulatory message, and immediately offer another pre-built challenge (e.g., 100,000 points for 20 signups). Consider offering a wide range of challenges tied to your evergreen and time-sensitive business objectives and allow users to access a list so that they can pick their own.
    举例来说，如果用户推荐4个好友注册了你的服务，你可以给用户1万个奖励积分。并自动发送通知，发布一条祝贺消息，并且随即提供下一项预设好的挑战任务（比如，继续推荐20个好友成功注册的话，用户可以得到10万的奖励积分）。你可以提供大量的各种各样的挑战任务来绑定你的长期的或是现时的经营目标，并且可以让用户查看这些挑战的列表和选择他们自己喜欢的挑战项目。

    With all the activity around points, badges and challenges, it seems obvious that users might need some easy way to track and reflect on their achievements within your app/site. Levels, a game mechanic from the earliest of video games, are the perfect solution for creating a constant sense of forward motion and the opportunity for reflection.
    有了所有的这些围绕着积分、徽章和挑战进行的活动，显然用户还可能会需要一种更加直接简便的途径来查看他们在你的应用/网站上所取得的成果。而从最早的电子游戏中借鉴而来的等级体制，就是一个绝佳的方式用以对用户形成一种持续的激励，并提供一个让用户内省的机会。

 
    Gowalla, a mobile social network, has a sophisticated and well-conceived challenge mode, known as trips. Like many winning Funware designs, Gowalla allows users to also see the complete list of challenges to choose the ones they like best.
    移动社区网络公司Gowalla拥有一套成熟完备的挑战模式，称为Trips（旅程）。正如很多的成功趣味件设计一样，Gowalla允许用户查看所有的挑战项目的列表，并且他们可以选择自己喜欢的项目来自由参与。

5. Levels | 等级

    If there is a single mantra we could extract from the multi-billion-dollar casual games industry that has spawned Bejeweled, Diner Dash and Farmville, it’s “Reward Early, Reward Often (and don’t go negative).” While this is relatively easy to do, users in a more complex loyalty program or on Funware-based sites, frequently need levels to create a discrete sense of achievement. Levels allow users to feel like they’ve accomplished something by showing structured progression through the overall experience.
    如果要从催生了诸如Bejeweled, Diner Dash 和 Farmville等几个成功游戏的价值数十亿美元的休闲游戏产业总结出一句话来概括他们的成功的话，那将会是：“即时且时常的对用户进行奖励”。这些是相对容易做到的，用户在一个更加复杂的忠诚度计划或基于趣味件的网站中，经常需要等级来满足他们的成就感。等级让用户觉得如同他们经过一系列的努力而终于取得了一项进展。

    Levels can be complex to design properly, so start with simple breakpoints and leave yourself room to expand. Use numbers or letters to denote your levels and set their breakpoints with increasing degrees of difficulty. A good rule of thumb is that it should be at least twice as hard to complete the fourth level as it is the first, and so on.
    等级体系可以被设计的非常复杂，不过你可以从简单的升级断点机制（即到达某一点即进入更高的级别）开始来设计你的等级体系，以便留有的空间来改进和扩充。你可以使用数字或字母来标示等级，并把各级别的升级断点设为渐增的模式。在这方面，一项基本的原则就是从第1级起，每隔4个等级时升级所需新增的积分至少要翻倍，从而让升级的难度呈渐进的趋势。


    Diner Dash uses a clearly defined level system. Every time you clear the restaurant of patrons, you clear a board; multiple cleared boards gives you a finished level. Imagine doing the same thing with a fitness app: as users perform tasks and improve their health, they ascend the ranks.
    Diner Dash使用了一个定义清晰的等级体系。每个经营档期清场之后，都会清一次盘，几次清盘之后会根据你的分数（所服务的台数）给你一个等级；你也可以试想一下在一个模拟健身的应用程序上使用同样的等级策略：当用户完成任务并改善健康状况之后，他们也提升了在应用程序中的等级。

Conclusion | 结论

    With the breathtaking growth of game mechanics and Funware in the current crop of popular apps and sites, it’s easy to see why so many startups are interested in incorporating points, leaderboards, badges, challenges and levels in their designs.
    游戏机制和趣味件的使用在当前众多的热门应用程序和网站上都呈惊人的增长态势，不难分析出为什么那么多的新兴公司都对在他们的设计中应用积分、排行榜、徽章、挑战和等级等理念兴趣十足。

    Whether you are building a healthcare app, forum discussion site or the next Mint.com, these simple game mechanics can make your consumer-facing mobile or web experience substantially more fun and engaging — all for far less than the cost of a traditional loyalty program, and with far greater satisfaction.
    无论你是在开发一个模拟健身的应用程序、一个论坛网站或是下一个Mint.com，这些简单的游戏机制和策略都会让你的面向移动设备或是Web的产品拥有更高的趣味性和展现更大的吸引力，而所有的这些所花费的成本远比传统的用户忠诚度计划要低得多，但是效果却更令人满意。

原文地址：http://mashable.com/2010/04/07/funware-game-mechanics/

看了一篇Digg的一个负责技术的VP写的关于NoSQL的文章，顺便翻译了一下。

Saying Yes to NoSQL
[译]拥抱NoSQL数据库

原作者：John Quinn（Digg: http://digg.com/users/doofdoofsf, Twitter: http://twitter.com/doofdoofsf）
翻译：阿木（http://waymangood.spaces.live.com）

    The last six months have been exciting for Digg's engineering team. We're working on a soup-to-nuts rewrite. Not only are we rewriting all our application code, but we're also rolling out a new client and server architecture. And if that doesn't sound like a big enough challenge, we're replacing most of our infrastructure components and moving away from LAMP.
    近半年来一直为Digg技术团队中正在进行的事情而兴奋不已，因为我们正着手对Digg进行彻底的重写，不仅仅是重写所有的应用程序，同时也推出了一个全新的C/S架构，如果这些听起来还不够有挑战性的话，那我告诉你，我们还正在替换大部分的基础组件，并且决定不再使用LAMP（译者注：Linux+Apache+Mysql+Perl/PHP/Python，一组常用来搭建动态网站或者服务器的开源软件，本身都是各自独立的程序，但是因为常被放在一起使用，拥有了越来越高的兼容度，共同组成了一个强大的Web应用程序平台。）

    Perhaps our most significant infrastructure change is abandoning MySQL in favor of a NoSQL alternative. To someone like me who's been building systems almost exclusively on relational databases for almost 20 years, this feels like a bold move.
    可能我们最重要的基础架构上的变化，就是放弃使用MySQL，转而使用NoSQL数据库。对于像我一样20多年来一直专注于基于关系数据库来构建系统的人来说，这应该算是一个大胆之举。

What's Wrong with MySQL?
MySQL存在的问题

    Our primary motivation for moving away from MySQL is the increasing difficulty of building a high performance, write intensive, application on a data set that is growing quickly, with no end in sight. This growth has forced us into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead.
    我们放弃MySQL的首要动机是：基于一个无休止高速增长的数据集构建一个高效率、高密集度写入的应用程序的所带来的不断增加的开发难度。这种增长迫使我们不得不同时采用水平分割和垂直分割的策略，而这又使大多数关系数据库的优点都荡然无存，并且也不能完全解决问题。

    Relational database technology can be a blunt instrument and we're motivated to find a tool that matches our specific needs closely. Our domain area, news, doesn't exact strict consistency requirements, so (according to Brewer's theorem) relaxing this allows gains in availability and partition tolerance (i.e. operations completing, even in degraded system states). We're confident that our engineers can implement application level consistency controls much more efficiently than MySQL does generically.
    这样的话关系数据库就变得很鸡肋了，我们就迫切需要寻找一种更加契合我们的具体需求的工具。我们的行业领域（新闻）对一致性的要求并不是非常严格，所以（根据Brewer的理论）适当放宽对一致性的要求可以获得更高的有效性和分割容忍度。我们也有足够的信心我们的工程师可以实现应用级的一致性，而且将会比MySQL更有效地对其进行控制。

    As our system grows, it's important for us to span multiple data centers for redundancy and network performance and to add capacity or replace failed nodes with no downtime. We plan to continue using commodity hardware, and to continue assuming that it will fail regularly. All of this is increasingly difficult with MySQL.
    随着系统的不断庞大，我们需要更多地考虑冗余、网络性能、扩容、以及不停机替换坏的节点，所以设备跨多个信息中心（IDC）对我们来说很重要。我们计划继续使用标准硬件，并假定它们可能时常出现故障，如果使用MySQL的话所有的这些都会变得日益麻烦。

Choosing an Alternative
替代方案

    Digg is committed to the use and development of open source software and we're keen to avoid the cost of proprietary large-scale storage solutions. We were inspired by Google and Amazon's broad use of their non-relational BigTable and Dynamo systems. We evaluated all the usual open source NoSQL suspects. After considerable debate, we decided to go with Cassandra.
    Digg一直热衷于开源软件的使用和开发，我们也尽量回避因使用商用的大规模的存储方案所带来的成本。Google和Amazon已经在广泛地使用他们的非关系型数据库BigTable和Dynamo，我们此举在一定程序上也是受到他们的启发。我们考量了所有常用的开源的NoSQL方案，经过多次讨论，最终决定使用Cassandra（译者注：http://baike.baidu.com/view/1350234.htm?fr=ala0_1_1）。

    Simplistically, Cassandra is a distributed database with a BigTable data model running on a Dynamo like infrastructure. It is column-oriented and allows for the storage of relatively structured data. It has a fully decentralized model; every node is identical and there is no single point of failure. It's also extremely fault tolerant; data is replicated to multiple nodes and across data centers. Cassandra is also very elastic; read and write throughput increase linearly as new machines are added.
    简单地说，Cassandra是一个具有BigTable的数据模型并且运行在类似Dynamo的基础架构之上的分布式数据库。他是列导向的并允许相对构化数据存储。他具有完全分散模型；所有的节点都是同一的，没有单点故障。同样他的故障容忍度很高；数据会被复制到跨数据中心的多个节点。Cassandra也很有弹性；当有新设备加入时读写吞吐量会随之呈线性增长。

    We experimented on our live site, replacing a relatively high scale MySQL component with a Cassandra alernative. These tests went well. You can read more about these experiments here.
    我们在自己的网站上做了实验，用Cassandra替换掉了一个相关的大规模的MySQL组件，测试的结果很令人满意。你可以本文在接下来的内容中了解到更多的细节。

Where We Are
进展

    At the time of writing, we've reimplemented most of Digg's functionality using Cassandra as our primary datastore. We've supplemented Cassandra-based indexing using full text, relational and graph indexing systems. We're getting used to dealing with eventual consistency.
    到笔者撰稿日为止，我们已经以Cassandra作为我们的主数据库对Digg的绝大多数功能进行了重新实现。并添加了基于Cassandra的全文索引，关联索引和图形索引系统。我们也已经熟悉了如何处理可能的一致性问题。

    We've been working on Cassandra itself too. We've made massive performance improvements: increased comparator speed, added better compaction threading, reduced logging overhead, added row-level caching and implemented multi-get capability. We've also implemented native atomic counters using Zookeeper (you can probably guess why were motivated to add that feature :)
    我们同时也进行Cassandra的开发，为Cassandra做了大量的性能改进：提高了comparator（比较工具）的速度，引入了更优的内存紧缩线程控制，降低了日志对资源的消耗，加入了行一级的缓存并实现了multi-get（多线程下载？）的能力。我们还使用Zookeeper实现了原生的原子级的计数器（你应该能猜到我们为什么会加这个功能吧^_^）。

    We've tested and improved the operational capabilities of Cassandra, upgrading its Rackaware capability, added slow query logging, improved the bulk import functionality and implemented Scribe support for improved logging. We've also done a ton of operational testing.
    我们测试并改进了Cassandra的运转能力，升级了他的机架感知能力，加入了slow query logging，改进了批量倒入功能并为了改进日志功能而实现了Scribe支持。我们还做了大量的运行测试。

    We're open sourcing all our work on Cassandra.
    我们对Cassandra所做的所有的改进也都是开源的。

What's Next?
展望

    Currently our main focus is getting Digg's latest release into general availability, but we'll continue to lead the way in championing Cassandra's development and adoption.
    目前我们主要在集中精力确保Digg的最近的GA版本（注：软件的通用版本）的发布，接下来我们依然会一如既往地继续拥护Cassandra的开发和使用，并在这条道路上争做领头羊(注：-_-|||)

    If you're interested in joining a world-class team using cutting edge, NoSQL technology at scale, check out jobs.digg.com
    Take it easy,
    你想加入世界顶级的Digg刀锋战队吗？你想掌握国际尖端的NoSQL技术吗？敬请访问：jobs.digg.com，是的！相信我！！你能！！！（译者注：多么华丽的广告植入，春晚都败给他了）

原文地址：http://about.digg.com/node/564

What UX stands for?
    In most domestic companies, we commonly call User Experience as "UE" for short, but for the worldwide scope, its well-accepted abbreviation is "UX";
    So what's UX Stand for?
    Focus on the target users of the products/services, including who they are, how they behave, what makes them use our products, even their work, life, habits, and all other factors relevant to how will they response to the products or services;
    Focus on our Clients, we learn their business, process, also personas and roles in their products/services/processes;
    Respect users' habits and guide users to cultivate a good habit of using the products/services;
    It's not a single functional specification or a single research study, it's not a fixed process, it's a process of continually learning about users, responding to thier behaviors, and evolving the product or service.
    UX is everywhere in the processes, including end-user interview, product anlysis, interaction design, UI design and UI implementation;
    Simplicity is the best, make rich featured but simple user interface without distracting user's mind, we love both efficiency and effectiveness;
    UX engineers are both liaisons and implementer, we know when to litsen, we know how to act, we balance the client bussiness goals and end-user requirements for the client organization;
    Finally, we help our clients to build highly usable and accessible, effecient, consistent, low dev/maintenance cost products, services or processes;
    UX is not only about technology, but good technologies DO help us to fulfill our goals better.

What we do in a project.
    First, we keep listening, asking, analyzing and iterating, to well learn the requirements from our clients and end-users;
    We help clients to get all the functionalities and workflows into shape;
    We help clients to idetify the roles from their workflow and create personas;
    We provide wireframes with Interaction Diagrams& Specifications;
     - We try to use GUI framework and proper functional block design to keep consistency of visual style and user experience on this product,
     - We use Axure/Visio/Photoshop/Illustrator to compose the prototypes, wireframes, and final visual design screens to show to all the related people and get feedbacks from them,
    Clients know their business/process well, what we need to do is helping them to achieve more goals through proper interaction design and implementation solution;
    We just don’t need always to do what is best for the end users, as UX engineers we have to find the sweet spot between the user's needs and the business goals, while balance business and end users;
    Other than dealing with clients and end-users, UX engineers are also caught in the middle trying to speak the business language, the developer language and the UI designer language to justify why we need to do our job, how to do it, and why it's important to success.
    So someone also says that UX is kind of an art of leverage and compromise:-)

UX Definition Process.
 

References:
    http://www.blogs.com/topten/10-ux-user-experience-blogs-to-watch-in-2010/

    最近刚好聊起一个有关Google的话题，突然想起Google App Engine的帐号申请下来之后除了一个Hello World就没再用过了，就决定试用一下，也不枉申请一回；
    做试用的这个App没什么难度，只是通过用Cron Job定时每天在新闻网站上抓取数据，用SAX过滤出想要的内容，再提交到一个BBS上，所以主要还是共享一下在做App时遇到的一些问题，希望能给也遇到相同问题的朋友做个参考：
    1) App Engine上的应用有一个限制：应用程序代码仅在响应网络请求或 cron job 时运行，且任何情况下必须在 30 秒钟内返回响应数据。刚开始没看到这个，把所有的逻辑都写到一个servlet里了，在本地环境测试OK，一deploy到Engine上，就不行了，最后只能重写，尽量保证应用的响应时间在10秒以内；
    2) 同样一个本地环境测试通过，一但Deploy就不行的问题：在对一个URL进行Fetch的进候，老是会报IOException，追进去之后是在url.openConnection()老是“Can not fetch this URL”，最终查出来是在目标URL的php中的ob_start('ob_gzhandler')所导致，不知道为什么AppEgine的URL Fetch跟PHP的gzip压缩会有冲突，没时间去研究，先把该PHP页的gzip关掉，OK，通过；(如果有对这方面原因了解的朋友希望能指点一下: amourguo[at]gmail[dot]com)
    3) 还是一个Deploy之后才出现的问题，看来Google应该解决一下保持本地测试环境和AppEngine的一致性问题，呵呵。在我的一个DB Entry里有一个字段叫作“newsLink”，用JDOQL做Query的时候("select from Xxxx where newsLink == linkParam parameters com.google.appengine.api.datastore.Link linkParam")就会老是报错说找不到一个叫做"sLink"的class，显然它是把newsLink中的new当做关键字了，不知为何，即便是中间没有空格，它也会把newsLink当做new sLink()，而且在SQL中应该是可以用[newsLink]来解决的，但在JDOQL试了证明行不通，最后不得不把这个字段改名了，所以，在JDOQL中，不但不能使用关键字作字段名，最好也不要包含关键字，以减少不必要的麻烦；
    Google App Engine还是不错的，使用多少资源就付多少费用，很合理，只是开发的时候会有诸多的限制，让人略有不爽，不过还好也不影整体的良好感觉，而且根据需要增加或减少对资源的消费这一点上，也符合节能减排的大潮流(-_-|||)；GAE算是最早的PaaS(Platform as a Service)的大规模实现之一了，后来Sina也搞了一个SAE，不过帐户是邀请制的，我没有搞到邀请，所以没试过:-p

早就在时光网的一次观影活动上订了一张《爱丽丝梦游仙境》在UME首映的票，爸爸妈妈对凌晨去看电影表示很难理解，说我是疯子，其实偶然做做疯子也提好的，只是晚上回家太晚估计会影响爸妈休息了，有些愧疚。
到了电影院了，突然想起来今天是限行的，老是生活在五环以外，对这个都有点淡忘了，不过后来听说11点之后是不在限行之列的。
时光网在UME的放票处还给每个领票的人都照了相，不知干嘛用。

书归正传，说说电影。
电影开始部分，很多原书的影子，看过书的人再去看电影感觉会更好一些(我只看过Alice's Adventures In Wonderland, 没看Through the Looking-Glass, 好像电影中有一些角色也有是取自后者的)，看书的时候虽然也会有插图，但始终不够丰满，总是会继续去想像各个角的样子，而在电影中，你可以一一去印证你的心中的各个角色与电影中的差别，
说一下对电影的比较具体的一些感觉：
最杯具是红心皇后的那只倒霉的鹰怪，
还有一个比较杯具的是Jabberwocky的名字，被翻成了"炸脖龙"，
处理的最传神的是那只偷嘴的青蛙，
最无厘头的就是白心皇后了，
最经典的一句话当然非"Off with his/her/their head(s)!"莫数了，
睡鼠在电影里边一直也没睡觉，
红心武士的马说:"Dogs will believe anything"，觉得我就象那只dog，
最喜欢的角色是柴郡猫，呵呵，优哉游哉，不去做坏事，也不去逞英雄，却总是在该出现的时候出现，
看来迪斯尼挺在意中国市场，最后Alice也象Google一样都跑香港去了，估计如果有续集的话会在中国拍也不是没有可能的了。
回到家已经2:00am了，洗洗睡了，天亮还要上工。

我记得的一些人物列表:
爱丽丝(Alice)
疯帽子(The Mad Hatter)
红皇后(The Red Queen)
白皇后(The White Queen)
红心骑士(The Knave of Hearts)
大白兔(The White Rabbit)
渡渡鸟(The Dodo)
蓝毛虫(The Caterpillar)
柴郡猫(The Cheshire Cat)
三月兔 (The March Hare)
睡鼠(The Dormouse)
红心骑士 (The Knave of Hearts)
胖胖兄弟（Tweedledum and Tweedledee）
炸脖龙(Jabberwocky, 有人喜欢他嘛?)
鹰怪(格里芬/Gryphon?)
鱼仆人(The Fish-Footman)
蛙仆人 (The Frog-Footman)
大狗贝亚德(Bayard)
大毛兽(The Bandersnatch)
其他群众演员...

Lately we got a requirement about CGI Server Push implementation with plain CGI(aka: CGI Comet) from one of our clients,
I'm not familiar with C, so spent a couple of days making some studies,
And here is what I got so far:

First, CGI Server Push is technically feasible, but  it's quite a departure from standard HTTP usage, which leads to several problems:
    1) There are unfortunate memory implications, because the message keep accumulating, and the browser retains all of that. All messages pile up in memory and on my POC app, Firefox got crashed after it keep running for 40 minutes. (A periodic refresh is a workaround here to solve this problem, say every 10 minutes, we should restart the long lived connection, that will be not pure PUSH, it becomes PUSH + PULL, but at least it works);
    2) The Two HTTP Connection Limit Issue, I remember this topic has been discussed in our team before, browsers typically only allow 2 concurrent HTTP connections per server. If a browser session has two HTTP connections already, any further connection requests will have to wait until one of these two HTTP connections is finished, but a long lived connection we use to implement PUSH is endless;
    3) The development cycle will be longer if we use CGI Server Push; Since I haven't found a mature opensource framework for CGI PUSH so far, so we need to do a lot of work by ourselves;

If we really need to do that, here are the 2 options we can choose(actually there are also some other solutions for comet, but do not fit our case, so ignored them):
    1) XmlHttpRequest + Message delimited by a special token;
        The solution here is when XHR status is 3(means there is data comes in), then parse the response string and only look at the last valid value, and then invoke a JS method with the value(in JSON, XML or other data object);
    2) Hidden Iframe + Page Streaming with <script> tag;
        Every time browser engine encounter a </script> tag, the script in the tag pair will be excuted, so we can push script to client in denomination of script tag pair;
    Both of the 2 approaches need to restart the long lived connection in a while(I think 5 to 20 minutes is OK) to avoid the increasing memory consuming issue;

Also attach a snippet of a very simple POC on this subject:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
//amourguo(at)gmail.com
int main()
{
  time_t t;
  struct tm *p;
  //printf("Content-Type:multipart/x-mixed-replace;boundary=amourboundary\r\n\r\n");//for non-IE browsers only
  printf("Content-Type:text/plain;");
  printf("Cache-Control:no-cache\r\n\r\n");
  while(1)
  {
    t = time(NULL);
    p = localtime(&t);
printf("--amourboundarystart");
    //printf("Content-Type: text/plain\r\n\r\n");
    printf("%d-%d-%d %d:%d:%d",p->tm_year+1900,p->tm_mon+1,p->tm_mday,p->tm_hour,p->tm_min,p->tm_sec);
printf("--amourboundaryend");
fflush(stdout);
sleep(1000);
  }
  //printf("--amourboundary--\r\n");
  return 0;
}

P.S.
Since DWR already provide the well-tested mature solution, and we are more fimiliar with that way,
So, if there is any chance, We should not give up talking our client into using DWR, it means LOW risk and agile development for us;
If our client persists in using plain CGI, then we will have a long way to go~