iAmFisher 通过 Google 阅读器发送给您的内容：

传世纪 : Twitter记：全世界意识大剧透——Web Trend之一

奥巴马不只用黑莓，他还用Twitter，而他的竟争对手麦凯恩先生连电邮都不会用。不是我事后诸葛，麦凯恩要想登基除非人类史重写。

全世界都在为他们疯狂，他们却躲在房间里逗狗玩。金融危机爆发后，BusinessWeek杂志有次去Twitter公司探班看到一帮穿着短裤的莽汉正围着宠物狗发呆。创立人威廉姆斯翘着脚丫对错愕的记者说，其实我也不知道Twitter会怎样。

外面，整个硅谷的公司都在盼着Twitter没钱，好趁火打劫买下这家下一轮互联网热潮中最有可能成就霸主地位的网络公司。

这时候，Google一边暗渡陈仓洽谈收购Twitter.com，一边由总裁施密特出面对媒体放炮——”Twitter这玩意儿就是穷人的电邮”。我理解，如果拿Gmail的标准衡量Twiiter，它的确够贫的，你要拿东坡肘子比灵芝更可以说它没啥肉味呢。可别管施密特先生怎么唱衰，外面的”谣言”已经一个接一个了。

第一个是Facebook出价5亿美元竞购Twitter，这个价够农民子弟威廉姆斯在老家买不少个农场吧。

第二个传言是威廉姆斯桀骜不驯，对同样来竞购的Google放话，10亿也不卖！

网络百晓生TechCrunch第一时间披露Google竞购Twitter的消息后，引起无数Blogger讨论，所有一厢情愿的意见一致地统一：威廉姆斯你得挺住，看看被Google收购后Blogger.com、Orkut.com的下场吧，好好的《牡丹亭》楞给唱成了《沙家浜》。

威廉姆斯说”我也不知道Twitter会怎样”时，你一定得相信他的无知真的很真诚。从开始到现在，Twitter根本没有一个发展目标。Google从来不做超过半年的计划，到了Twitter已经变成了根本没计划。如果你了解一点Twitter的发展史，一定会明白，互联网发展到今天，不靠谱比靠谱要靠谱得多。

最初的Twitter被称作微博客，因为它只支持发布140个英文字符的即时消息——140个英文字符是美国手机短信的最大容量。人们用IM软件、网页和手机向Twitter发送”我在干啥”之类的废话。没人能想到这个”废话篓子”迅猛发展了起来，到2008年的时候由于数据量过大Twitter的服务器开始频繁宕机。当时网络观察站点读写网络（Readwriterweb.com）发过一个帖子讨论谁能干掉Twitter，结论是Twitter自己。它发展得忒好了，用户越来越多，因为数据库来不及升级而不断宕机，最终会损害用户体验，然后完蛋。

云计算的迅猛发展给了这个新生站点一个机会，Twitter的30个员工在逗狗之余很快解决了数据库问题——当然问题还会发生，在写这篇文章的时候，它又把我至少两天的数据给弄丢了。但我不会因此弃它而去，确切地说我已经被它黏住了。经过3年的发展，Twitter早已经不是废话篓子那么简单了。

从页面（比如我的http://twitter.com/launlee）看来，基本上Twitter还是那个”短信”汇集平台，但它采用了开放应用（API）的策略，几千家工作室和个人程序员围绕在Twitter和上面的海量信息周围开发着自己的应用。有的帮你在世界地图上显示全球推友的最新推送信息，有的帮你寻找同一个机场的推友。Twitter收购了为其提供搜索功能的一个服务，紧接着就宣布禁止Google的搜索蜘蛛来检索自己的信息了。这引发了Google的恐慌。

2008年之前，Twitter还是一个Geek玩具，但现在已经是用户接近千万的大众工具了。今年1月份以来，上面的中国用户开始迅猛增加，follow我的用户量迅速增加了100多个。现在，用户早就不仅仅发送what are you doing这样初级的tweet了。他们已经学会在上面分享链接、图片、音频、视频，把它当作聊天室和社交站点来使用了。

这一切都源于Twitter将信息发布的门槛降到了最低。因为在网站、BBS、博客上发布信息要花费更多的时间，有人会停止发布某些信息，但现在透过桌面、浏览器或者IM插件，任何信息都可以在几秒之间发出。

而且，除了我在哪我在吃什么的废话之后，用户也开始发布新闻。2008年5月12日，我感觉到震感的时候，第一个打开的就是我浏览器上的推送窗口，迅速打下一行字——靠，地震了吗？很快关于地震的消息从全国各地推送出来。不出意外，这应该是汶川地震的第一发布源。2月以来，我使用TwitterFox的时间远远超过了抓取Blog更新的Google Reader阅读器，而信息一个也没错过，反而更迅速。Google不揪心才怪。

Twitter上的信息有一个明确的时间轴，当你在上面搜索时结果呈现的绝对是最新的信息，而这一点以搜索大网站为己任的Google可能永远不能精准做到。Twitter上的信息已经达到海量，人们在进行搜索的时候可能会放弃Google转投Twitter。这是另一个让Google不寒而栗的结果。

撇开潜在的商业市场不谈，Twitter还可能会产生巨大的社会影响。除了搜索和发布即时信息，它同时也是一个社交工具（SNS）或说社交网络。我follow了58个推友，在firefox浏览器的状态栏中安装了TwitterFox插件，每过3分钟，推友的最新消息就会在这里浮现出来。每天我会在这里浏览超过300条信息，有的是纯粹的抱怨，比如昨晚电影院前排的那个胖子多么讨厌，有的则是最新的业界新闻，比如纽约时报公司准备出租本部大楼以抵制广告下滑带来的压力。

Twitter那些貌似鸡零狗碎的信息真的那么废物吗？有研究表明这是一个错觉。社会学家将这些信息营造的感受称作环境知觉（Ambient Awareness）。想像你和恋人相处时，会觉得她的一颦一笑那么废物吗？即使普通朋友，他的语气词、表情、步态这些信息对你是同样有效的，正是通过这些我们感觉到自己是和这个人相处在一起的。Twitter上的那些废话也可以达成这样的效果。有调查表明，Twitter上这种社交环境已经影响到了现实的交往，如果朋友生活的大部分细节你已经了解到了，还用得着去到他的家里拜访吗？

Twitter差不多是跟进朋友状态维护关系成本最低的舞台。这一点所有的社交网站都已经投了赞成票，现在去登录Facebook、msn.com甚至kaixin001.com，它们的首页都已经改成了Twitter式的。

曾几何时，我觉得Google一切皆有可能，现在面对Twitter，我觉得没有不可能。
…………………………………………………………………………………………………………………………………………
本文为launlee为《QUO新探索》杂志所撰写专栏WebTrend文章，教写成时间在Blog刊出有延误。

评论数量(0) | 你来评论
原文标题：Twitter记：全世界意识大剧透——Web Trend之一
原文地址：http://lilao.com/1173.html
© 版权声明： 除非特别声明，传世纪 所有文章均为 launlee 原创。默认自由转摘且遵守 CC 版权协议(署名-保持一致-非商业)。转摘请注明出处，并以超连接形式标明文章原始出处和作者信息。
@ 分享本文： Twitter – del.icio.us – Gmarks – Yahoo! – 更多 More…
@ 订阅本站：Google Reader – 鲜果 – 抓虾 – QQ – 有道 – IM 工具…

可从此处完成的操作：

• 使用 Google 阅读器订阅Communication Next from lilao.com
• 开始使用 Google 阅读器，轻松地与您喜爱的所有网站保持同步更新

CIO ERP项目失败的惨痛回忆

ZDNet CIO频道 更新时间：2009-04-01 作者： 来源：CIOAge
本文关键词: ERP CIO

　　《21世纪经济报道》消息，一个针对各类国企高管薪酬进行统一规范的系统制度，已基本制定完毕并正征求各方意见，有望近期经国务院审批通过后出台。据牵头制定方人力资源和社会保障部（以下简称人社部）知情人士介绍，新规将对国企负责人的薪酬结构、水平、考核发放、列支与管理、补充保险与职务消费等内容进行统一规范。但此消息尚未得到人社部的官方确认。

　　该人士透露，国有企业高管的薪酬水平未来大致分为三部分，即基本年薪+绩效年薪+中长期激励。其中基本年薪由企业所在地区国有企业职工年平均工资乘以 一定倍数，再乘以企业规模系数（或调节系数）构成；绩效年薪则为基本年薪的三倍或三倍以下；中长期激励则将结合企业的实际情况及上市公司有关规定构成。

　　据了解，早在2006年，国资委规定中央企业的高管薪酬控制在不超过职工平均工资的14倍；一些地区也都作出了相关的”倍数”规定，如北京市国资委出台的暂行办法规定，北京国有企业负责人的年薪不应超过本企业平均工资的12倍。

　　查阅数据可知，在2008年北京市城镇职工（含国有企业）的年平均工资为44715元，若假定国企职工平均工资接近该水平，则国企高管年薪的上限水平应不超过54万。

　　业内人士预测，一旦该规定经国务院审批通过后，将改观不同国企因行业属性带来的高薪的局面，特别是金融行业与其他行业的收入差距，有望大幅缩小。

　　除对国企负责人薪酬进行统一规范外，不少专家还建议一并对混合所有制企业负责人薪酬进行规范。上述知情人士介绍，中国现有约960多万户企业，可分为国有企业、混合所有制企业、私有独资企业三大类。”其中相当一部分混合所有制企业系由国企改制而来，且前者的薪酬水平往往直接影响到后者的薪酬确定，故一并规范相当必要”。

　　与国企高管薪酬管理不同，混合所有制企业高管薪酬的确定，需要采取更多的市场手段。该人士建议，在健全内部制衡机制方面，修改《公司法》，明确让上市 公司小股东真正拥有对高管薪酬确定的表决权，”比如占一定比例股份的小股东对所持股公司高管薪酬水平持有疑义时，有权要求召开股东大会重新投票表决，甚至 利用网络投票”。

　　在健全公司治理结构方面，他给出的建议是完善独立董事制度，明确公司董事会薪酬委员会成员均由外部独立董事担任；并由有关监管部门提供独立董事名单，供公司从中随机抽选。

	Introduction to Messaging Channels	Pattern Catalog  Previous   Next
	Site Home • Patterns Home • Table of Contents

In Introduction to Messaging Systems, we discussed Message Channel. When two applications wish to exchange data, they do so by sending the data through a channel that connects the two. The application sending the data may not know which application will receive the data, but by selecting a particular channel to send the data on, the sender knows that the receiver will be one that is looking for that sort of data by looking for it on that channel. In this way, the applications that produce shared data have a way to communicate with those that wish to consume it.

Message Channel Themes

Deciding to use a Message Channel is the simple part; if an application has data to transmit or data it wishes to receive, it will have to use a channel. The challenge is knowing what channels your applications will need and what to use them for.

Fixed set of channels — One theme in this chapter is that the set of Message Channels available to an application tends to be static. When designing an application, a developer has to know where to put what types of data to share that data with other applications, and likewise where to look for what types of data coming from other applications. These paths of communication cannot be dynamically created and discovered at runtime; they need to be agreed upon at design time so that the application knows where its data is coming from and where the data is going to. (While it is true that most channels must be staticly defined, there are exceptions to this theme, cases where dynamic channels are practical and useful. One exception is the reply channel in Request-Reply. The requestor can create or obtain a new channel the replier knows nothing about, specify it as the Return Address of a request message, and then the replier can make use of it. Another exception is messaging system implementations that support hierarchical channels. A receiver can subscribe to a parent in the hierarchy, then a sender can publish to a new child channel the receiver knows nothing about, and the subscriber will still receive the message. These relatively unusual cases notwithstanding, channels are usually defined at deployment-time and applications are designed around a known set of channels.)

Determining the set of channels — A related issue is: Who decides what Message Channels are available, the messaging system or the applications? That is to say: Does the messaging system define certain channels and require the applications to make due with those? Or do the applications determine what channels they need and require the messaging system to provide them? There is no simple answer; designing the needed set of channels is iterative. First the applications determine the channels the messaging system will need to provide. Subsequent applications will try to design their communication around the channels that are available, but when this is not practical, they will require that additional channels be added. When a set of applications already use a certain set of channels, and new applications wish to join in, they too will use the existing set of channels. When existing applications add new functionality, they may require new channels.

Unidirectional channels — Another common source of confusion is whether a Message Channel is unidirectional or bidirectional. Technically, it’s neither; a channel is more like a bucket that some applications add data to and other applications take data from (albeit a bucket that is distributed across multiple computers in some coordinated fashion). But because the data is in messages that travel from one application to another, that gives the channel direction, making it unidirectional. If a channel were bidirectional, that would mean that an application would both send messages to and receive messages from the same channel, which—while technically possible—makes little sense because the application would tend to keep consuming its own messages, the messages it’s supposed to be sending to other applications. So for all practical purposes, channels are unidirectional. As a consequence, for two applications to have a two-way conversation, they will need two channels, one in each direction (see Request-Reply in the next chapter).

Message Channel Decisions

Now that we understand what Message Channels are, let’s consider the decisions involved in using them:

One-to-one or one-to-many — When your application shares a piece of data, do you want to share it with just one other application or with any other application that is interested? To send the data to a single application, use a Point-to-Point Channel. This does not guarantee that every piece of data sent on that channel will necessarily go to the same receiver, because the channel might have multiple receivers; but it does ensure that any one piece of data will only be received by one of the applications. If you want all of the receiver applications to be able to receive the data, use a Publish-Subscribe Channel. When you send a piece of data this way, the channel effectively copies the data for each of the receivers.

What type of data — Any data in any computer memory has to conform to some sort of type: a known format or expected structure with an agreed upon meaning. Otherwise, all data would just be a bunch of bytes and there would be no way to make any sense of it. Messaging systems work much the same way; the message contents must conform to some type so that the receiver understands the data’s structure. Datatype Channel is the principle that all of the data on a channel has to be of the same type. This is the main reason why messaging systems need lots of channels; if the data could be of any type, the messaging system would only need one channel (in each direction) between any two applications.

Invalid and dead messages — The message system can ensure that a message is delivered properly, but it cannot guarantee that the receiver will know what to do with it. The receiver has expectations about the data’s type and meaning; when it receives a message that doesn’t meet these expectations, there’s not much it can do. What it can do, though, is put the strange message on a specially designated Invalid Message Channel, in hopes that some utility monitoring the channel will pick up the message and figure out what to do with it. Many messaging systems have a similar built-in feature, a Dead Letter Channel for messages which are successfully sent but ultimately cannot be successfully delivered. Again, hopefully some utility monitoring the channel will know what to do with the messages that could not be delivered.

Crash proof — If the messaging system crashes or is shut down for maintence, what happens to its messages? When it is back up and running, will its messages still be in its channels? By default, no; channels store their messages in memory. However, Guaranteed Delivery makes channels persistent so that their messages are stored on disk. This hurts performance but makes messaging more reliable, even when the messaging system isn’t.

Non-messaging clients — What if an application cannot connect to a messaging system but still wants to participate in messaging? Normally it would be out of luck; but if the messaging system can connect to the application somehow—through its user interface, its business services API, its database, or through a network connection such as TCP/IP or HTTP—then a Channel Adapter on the messaging system can be used to connect a channel (or set of channels) to the application without having to modify the application and perhaps without having to have a messaging client running on the same machine as the application. Sometimes the "non-messaging client" really is a messaging client, just for a different messaging system. In that case, an application that is a client on both messaging systems can build a Messaging Bridge between the two, effectively connecting them into one composite messaging system.

Communications backbone — As more and more of an enterprise’s applications connect to the messaging system and make their functionality available through messaging, the messaging system becomes a centeralized point of one-stop-shopping for functionality in the enterprise. A new application simply needs to know which channels to use to request functionality and which others to listen on for the results. The messaging system itself essentially becomes aMessage Bus, a backbone providing access to all of the enterprise’s various and ever-changing applications and functionality. You can achieve this integration nirvana more quickly and easily by specifically designing for it from the beginning.

So as you can see, getting applications set up for Messaging involves more than just connecting them to the messaging system so that they can send messages. The messages must have Message Channels to transmit on. Slapping in some channels doesn’t get the job done either. They have to be designed with a purpose, based on the data type being shared, the sort of application making the data available, and the sort of application receiving the data. This chapter will explain the decisions that go into designing these channels.

To help illustrate the patterns, each one has an example from a ficticious, simplified "stock trading" domain. While none of these examples should be used as the basis for implementing a real trading system, they do serve as quick and specific examples of how the patterns can be used.

Home • Patterns • Table of Contents

Previous   Next

2009/05/10 – By 数位之墙 – 关键字／标签：电子商务 搜索引擎 门户网站 网络广告 B2C 品牌

》高阶工作机会《 – 年薪100万台币及15万人民币以上的工作
供应链经理级　Sales/Account Manager (苏州)　电子商务/客户服务主管　电源研发工程师/经理/处长　客服资材主管　客户服务主管(处长级以上)　设备及自动化设计高阶主管 (桃园)　机构技术主管	更多

◎开设分店成本低廉

由于电子商务是「电子」加「商务」，也因此有很多传统商务的运作方式被使用到互联网来。例如我们常听到的直营分店，加盟连锁，代理经销等。这些模式的原理不论在线或线下都一样，但在在线的部分，实际做法则会因互联网擅长处理信息流的特性而有所不同。

建立一个电子商务网站独立经营，基本上就算是直营店模式。看似简单，但是却也面临了「店要开在哪里」的问题。大部分网上直营店面临的困扰是，不做推广就没人潮流量，一旦做推广，购买网络广告的效果很差，成本高又吃不消。

把店面开在深山里，然后到大都市的市中心去发传单，希望消费者到店里购物，这难道不是大部分初创电子商务公司在干的事情吗？如果把「到大型网站购买网络广告」当成销售渠道来看，这种渠道的销售效率是非常低落的。

对比到实体世界的商务，大家都知道开店要开在人潮聚集处，要开在市中心而不是深山里。而「网上的市中心」在哪里？这就难怪有些电子商务网站选择到淘宝去开分店了。在实体世界，开分店的成本很高，而在虚拟的世界里，开分店无非就是另外建立一套系统而已。

这就是直营分店模式搬到网上的差别：你可用低廉成本在网上建立无数分店。然而，人潮聚集处并非只有淘宝。新浪搜狐等门户网站以及百度谷歌等搜索引擎，校内网开心网等社交网络，都可能摇身一变成为新的开店平台，吸引大量B2C 业者来开分店，或乾脆在此开直营店。

◎虚拟加盟的运作方式

在实体世界里，除了直营分店之外尚有加盟模式。由加盟者出资获得 品牌与经营授权，甚至负担店租与店内硬件设施成本，开设与直营店相类似的店面。因为在实体世界里开设分店的成本太高，所以经营者才需要透过加盟模式将这个成本转嫁给加盟者，达到快速展店目的。

由于在网上开分店的成本太低，这种模式在网上比较少见。然而，因为互联网擅长处理信息流的特性，却诞生出新的「虚拟加盟」方式。电子商务经营者与加盟者之间采用销售后分成的方式合作，而加盟者则获得一个自己的授权网店的网址，可用于推广。

例如，网上超市「一号店」（http://www.yihaodian.com）就采取这种方法，开设了「天涯一号店」（yihaodian.tianya.cn ）以及「新浪乐居一号店」（http://yihaodian.house.sina.com ）。这种类似于开设分店的方式，最大的不同在于与合作方采取售后分成的方式。

此外，从加盟店网址来看，加盟者似乎有一个自己的店面。但其实不论开设多少加盟店，最终交易都是发生在原来的直营店，加盟者根本没有自己的系统。当新浪用户来到一号店时，一号店就换上新浪招牌；当天涯用户来到一号店时，一号店就换上天涯招牌，如此而已。

不论交易是怎么发生的，背后的客户服务，物流，金流，其实都是由原来的直营店面完成，加盟者仅需专心在想办法导入人潮流量到加盟店网址去进行消费。这种加盟系统可以再扩大到个人，最终行成加盟体系（Affiliate Program） ，让即使是博客的经营者也可加盟。

◎销售后分成将成主流

Affiliate Program 可以翻译成「夥伴计画」，这个由Amazon发扬光大的推广模式，在西方世界已经行之有年非常成熟，可视为是完全看透了互联网擅长处理信息流特性的典范。在中国，知名的网上男性衬衣销售商Vancl 的发迹部分原因就是靠著Affiliate Program 。

在2005年的时候，有些台湾的电子商务公司到大陆来开疆辟土。当时大陆的电子商务环境还不太成熟，对方很惊讶的跟我说，大陆的网际网络流量很不值钱，流量很大，但是对电子商务公司来说，要的不是流量而是销售，而大陆的互联网流量大部分无法转换成销售。

这个问题相信是目前大部分电子商务公司的问题。你可以花大钱到新浪去买广告，但是新浪的广告所带来的流量最终转化成销售的比例却很低。而，新浪理所当然的不保证效果，他甚至不保证广告有人点击。在这种情况下，依照销售后付款的广告型态，将在中国逐渐兴起。

这种业界称为CPS （Cost Per Sale ，销售后分成）的广告型态，逐渐出现在中国大陆的广告市场，类似的广告联盟也不断冒出。由于广告曝光（CPM ）与广告点击（CPC ）对电子商务公司来讲，如果没有转化成销售都没用的，在B2C 大潮来袭之下，CPS 广告将成一大主流。

有了分店与加盟，还需要网上代理商与经销商吗？由于网上销售等于直接面对终端客户，传统经销代理制度对网上商城来说似乎不再必要。然而，传统行业在开设自己的网上商店时还是引入了这种体系，例如李宁的网上销售战略。这更多是出于价格／品牌／渠道管制的考虑。 （文：数位之墙）