23:58 37signals Architecture » High Scalability - Building bigger, faster, more reliable websites.

Update 5: Nuts & Bolts: HAproxy . Nice explanation (post, screencast) by Mark Imbriaco of why HAProxy (load balancing proxy server) is their favorite (fast, efficient, graceful configuration, queues requests when Mongrels are busy) for spreading dynamic content between Apache web servers and Mongrel application servers.
Update 4: O'Rielly's Tim O'Brien interviews David Hansson, Rails creator and 37signals partner. Says BaseCamp scales horizontally on the application and web tier. Scales up for the database, using one "big ass" 128GB machine. Says: As technology moves on, hardware gets cheaper and cheaper. In my mind, you don't want to shard unless you positively have to, sort of a last resort approach.
Update 3: The need for speed: Making Basecamp faster. Pages now load twice as fast, cut CPU usage by a third and database time by about half. Results achieved by: Analysis, Caching, MySQL optimizations, Hardware upgrades.
Update 2: customer support is handled in real-time using Campfire.
Update: highly useful information on creating a customer billing system.

In the giving spirit of Christmas the folks at 37signals have shared a bit about how their system works. 37signals is most famous for loosing Ruby on Rails into the world and they've use RoR to make their very popular Basecamp, Highrise, Backpack, and Campfire products. RoR takes a lot of heat for being a performance dog, but 37signals seems to handle a lot of traffic with relatively normal sounding resources. This is just an initial data dump, they promise to add more details later. As they add more I'll update it here.

read more

23:27 Some Facebook Secrets to Better Operations » High Scalability - Building bigger, faster, more reliable websites.

Kim Nash in an interview with Jonathan Heiliger, Facebook VP of technical operations, provides some juicy details on how Facebook handles operations. Operations is one of those departments everyone runs differently as it is usually an ontogeny recapitulates phylogeny situation. With 2,000 databases, 25 terabytes of cache, 90 million active users, and 10,000 servers you know Facebook has some serious operational issues. What are some of Facebook's secrets to better operations?

read more

Xsstc: Cross-site scripting through CSS dataAjaxian » Front Page » 车东 在 Google 阅读器中共享的项目
由 david 共享
用css实现跨域ajax请求

Wes Biggs has posted on Xsstc, his cross-site scripting solution that uses CSS to hide the data:

It turns out CSS leaks data in a very subtle way. Properties set by an external stylesheet (that is, one that is loaded using a LINK REL="STYLESHEET" tag) are used to style the elements of the host page, and at runtime the page can introspect itself to see what styles have been applied. Most of these tend to be strictly prescribed data, such as background colours for block elements, or some multiple choice items, like left/center/right alignment for text. While you could conceivably come up with a binary (or ternary) system based on that, it would be a pretty nasty job to try to make those into a general-purpose data channel. Fortunately, there are a few places where CSS lets you specify essentially free-text attributes: image URLs.

To make this work, the server has to dynamically send out simple CSS data, with info encoded into it... e.g. note the 'Hello World'

PLAIN TEXT
CSS:
  1.  
  2. #Xsstc {
  3.  background-image: url('about:blank#Hello%20World');
  4. }
  5.  

To tie into the data, you just need to exec away via:

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. Xsstc.exec('http://lbs.tralfamadore.com/test.css', showResponse)
  3.  

You can see the test page to see it at work. An interesting hole indeed....

为什么大多事情会失败 (2008-08-31 11:40:11)jianzhenzi的BLOG » 车东 在 Google 阅读器中共享的项目
由 Sandra 共享
机构、公司、个人和政府在获知战略对彼此到底有何影响的能力非常有限。这个局限不能被聪明的分析来克服,就像我们不能克服生理局限以光速旅行一样。这是为什么大多事情会失败的原因。

  也正因此,欧莫洛希望人们因此不必害怕失败。在他看来,政府和企业就像一个有机体,如果不进化,自然就只有死路一条。尽管人类预测未来的能力极为有限,但商业的潜在回报非常可观(如果你做得对),因此,未雨绸缪永远是值得的。

  欧莫洛无意为人们开出具体药方,而只简单提供了一些常识性的方向指引:对政府来说,则要尽可能地减少干预市场,因为大多数的干预只会使事情变得更糟;对企业来说,则要不断尝试,保持创新——如果接受“失败是企业发展过程的一部分”的前提,那么最终挑战就是失败代价小,要多失败,要尽早失败,而且要按照美国歌舞之王弗莱德·阿斯泰尔的建议去做—“振奋精神,抖落尘埃,重新开始”。
   为什么最聪明的商业规划者都会走麦城

   不可知论者和叔本华悲观哲学的信奉者,都可以从英国“非正统经济学家”、“忧郁科学”的代表人物保罗·欧莫洛(Paul Ormerod)对经济世界的解释中找到安慰。

  在1994年的《经济学之死》(The Death of Economics)中,欧莫洛批判了传统经济学的视角,认为经济行为是如此复杂,以至于它不可被预测;1998年的《蝴蝶效应经济学》(Butterfly Economics)则进一步运用近年来热门的“行为经济学”视角,宣称社会是有生命且可以适应和学习的生物,只能通过其组成部分的复杂互动来理解。

  《为什么大多事情会失败》(Why Most Things Fail)是欧莫洛的最三部野心之作。本书缘起于他几年前的一个研究发现:商业世界中的失败率与自然界物种的灭绝率的趋势竟是惊人的相似。这堪称是一个莫大的反讽:毕竟,企业的领导人一直都在殚精竭虑地应对不断变化的商业环境,而动植物大多数都没有规划意识。欧莫洛由此开始了他对“失败铁律”的探究。在他看来,这个“失败铁律”的动力乃是人们最为忽略的研究领域之一。

  欧莫洛的研究结果可谓非常悲观:在国家政策和企业经营中,失败者远远多于成功者。我们周围的失败无处不在,不可避免。尽管经济世界的演员可能会具备寻求最佳结果的足够智力,但他们最好得习惯这样一个残酷的事实:没有一个成为赢家的主导方案。究其原因,与欧莫洛此前著作的观点一脉相承:世界是一个太复杂的非线性系统,让人们很难作出长期预测。商业结果取决于太多的变量,这使得最聪明的规划者都会走麦城。

  这个基本概念是迷人的,但欧莫洛似乎并没有决定好他到底是应该向公众讲一个用趣闻和案例来串起来的易于理解的概念,还是构建一个让他的经济学同行们信服的数学模型,以表证他即便不能预言但还是能描绘经济世界的随机性。这种骑墙心态使得欧莫洛在阐述时夹杂着大量数理论证,让门外的读者很难去领会,更不用说进行评判了。

  这在很大程度上缘于欧莫洛对数学的迷恋。尽管哀叹现有经济模型的不精确,不能描绘或预测结果,他还是相信某种尚未被发现的法则将会揭示成功的经济赢家与输家的区别,数学则是实现这一过程的非常有用的工具。而要找到合适数学预测工具的最好方法就是研究生物学。

  不过,当用“整个20世纪最叹为观止的品牌失败”的案例来论证书的中心主题时,欧莫洛还是让他的主张达到了清晰易理解的效果:在1980年代,可口可乐面临来自百事的强大压力,管理层决定取消原来的配方,并在1985年4月推出了新配方的可乐。数百万的美国人记得接下来发生的:新可乐销售乏善可陈,不到3个月,可口可乐即恢复了它久经考验的配方。欧莫洛引用了当时可口可乐CEO唐纳德·基奥对失败的解释:“一个非常简单的事实是,我们在为新可乐推出所作的消费者研究上倾注了大量的时间、金钱和技术,却并不能衡量或揭示那么多人对可乐原配方的深久的喜爱……你不能这样来衡量,就像你不能衡量爱情、骄傲或者爱国主义。”

  而对在1998年俄罗斯金融危机中垮台的长期资本管理公司,欧莫洛则极尽嘲笑之能事:它的学富五车的合作者们,包括诺贝尔经济学奖获得者罗伯特·默顿和迈伦·斯科尔斯迷信秩序、线性和均衡,但真实世界却别有安排。

  通过这样很容易让读者共鸣的例子,欧莫洛展示了他的主要论断:机构、公司、个人和政府在获知战略对彼此到底有何影响的能力非常有限。这个局限不能被聪明的分析来克服,就像我们不能克服生理局限以光速旅行一样。这是为什么大多事情会失败的原因。

  也正因此,欧莫洛希望人们因此不必害怕失败。在他看来,政府和企业就像一个有机体,如果不进化,自然就只有死路一条。尽管人类预测未来的能力极为有限,但商业的潜在回报非常可观(如果你做得对),因此,未雨绸缪永远是值得的。

  欧莫洛无意为人们开出具体药方,而只简单提供了一些常识性的方向指引:对政府来说,则要尽可能地减少干预市场,因为大多数的干预只会使事情变得更糟;对企业来说,则要不断尝试,保持创新——如果接受“失败是企业发展过程的一部分”的前提,那么最终挑战就是失败代价小,要多失败,要尽早失败,而且要按照美国歌舞之王弗莱德·阿斯泰尔的建议去做—“振奋精神,抖落尘埃,重新开始”。

 

                振奋精神,抖落尘埃,重新开始!!!

14:59 由抄袭造成的重复内容 » Inside AdSense-中文

转载自:谷歌中文网站管理员博客

重复内容一直是网站管理员们热议的话题之一,我们觉得很有必要对在各种会议上和网站管理员支持论坛中我们被问及的常见问题作以下统一解答。

在做深入探讨之前,我想先简要谈谈网站管理员们经常担忧的一个问题:在大多数情况下,网站管理员往往对擅自抄袭和传播自己内容的第三方无能为力。我们知道这并不能归咎于网站管理员们,这也就意味着同一内容出现在许多不同网站其本身并不理所当然地被认为是违反了网站管理员指南。这仅仅导致了Google必须增加一个额外步骤,即鉴别内容的原创来源,而这正是Google所擅长的,在大多数情况下原创内容源都能被正确地识别出来,从而不会给发布真正原创内容的网站带来任何负面影响。

一般而言,我们把网站内容雷同问题主要分为两种情况:

对于第一种情况,您可以亲自动手解决Google对您网站上的重复内容进行索引的问题。您可以阅读 Adam Lasnik 发表的Deftly dealing with duplicate content以及Vanessa Fox 发表的Duplicate content summit at SMX Advanced 这两篇文章都提供了一些很好的建议,帮助您解决站内内容重复的问题。这里还有一个特别的建议帮助您避免站内内容被重复索引:您可以将您希望被抓取的URL 序列包含在您的站点地图文件中。遇到包含同一内容的不同网页时,这么做有助于我们准确收录您真正想提供给用户的那部分内容。其他有关于站内内容重复的信息 您可以参阅讨论此主题的有关帮助中心文章

二种情形可能是有人剽窃了您网站中的内容,并将其展示在其他网站上牟利。同时,网络代理服务器也经常抓取通过代理方式访问的网站的部分内容。当在不同网站 遇到相同内容的时候,我们会基于许多不同的依据来判断究竟哪个网站才是原创,而这样的判断通常是准确的。这也意味着,当您发现有人剽窃了您的内容时,您大 可不必过分担心它对您的网站在谷歌搜索排名上的负面影响。

如果您将自己网站的内容与他人分享, 但同时还希望自己的网站被识别为原创来源的话,您需要请合作伙伴在其网站内容上添加指向您原创内容的链接。您也可以在Vanessa Fox最近发表的文章Ranking as the original source for content you syndicate找到其他有关处理这一问题的建议。

有些网站管理员会有这样的疑问: 什么原因会导致有时候抄袭内容反而比原创内容的排名还要高呢?这应该是个特例,但如果您真的遇到这种情况,请您务必做到:

最后我想指出的是,在绝大多数情况下,含有雷同重复内容并不会对您的网站在谷歌搜索上的排名有负面影响。这些内容可能已经被过滤出去了。如果您参照上述提到 的一些建议,您会了解到怎样才能更精确地控制搜索引擎抓取的内容以及出现在索引中的内容版本。只有被确认为蓄意或恶意抄袭时,雷同重复内容才有可能会被视 为违反了网站管理员指南。

如果您想更深入地讨论这一话题,请浏览我们的网站管理员支持论坛

14:33 博客大巴团队纵横拓展 - 五泄篇 » 车东@博客大巴

节目是从早上7点赶大巴开始的:前2次拓展沙家浜和玉柱山据说还有帐篷,今年是住在五泄景区的宾馆内,所以我带了wii,午餐后是轻松的热身活动,全体分成了4个组:


11囧(或者说冠军队,他们最后的胜出让我无语……)


皇豹(是的:很黄,很暴力)队,很喜欢他们队的风格;

BB(波波队),队长是我们技术部新来的实习生:小崔同学。他的出场秀是钢管渡小溪;

第四队是:蓝精灵队(明明是蓝海盗嘛)

第一天下午的节目叫团队桥,在规定时间内,找材料按规格用数十张报纸和胶带纸造桥。桥的长宽高都有要求外,还要求能够承重3罐可乐,最后4个队还被要求将各自的作品串联成一个可以滚过可乐罐的长桥;

在完成了一个看上去不太美,实际上也很难维护的一个桥后。各个队都提出了一些看法: 项目开始时的懈怠,缺乏主动领取任务的态度。造桥过程中方法的不专业(事后问了教练才知道还有更好的报纸搭桥方法,而且也更经济,就是用报纸卷成纸棍做结构,但相应的操作复杂程度也会提高),我们使用的纸筒法既不经济也不坚固,要求是“任意位置”都能承重3罐可乐,而且对于目标的理解,更是让很多人有些意外;好的执行团队:必须有人非常主动的去了解最终目的,而不是按照自己主观标准凑活执行;

餐前爬了一座不算太高的山以后,大家的胃口还不错;晚餐后的节目是在会议室中:

第二天一早的交换队员: 让我立刻想到了Survivor;但实际的目的是无间道;因为第一个项目寻宝,高空项目我非常想都尝试一下,可惜时间有限制;原地翻页…… 反正到最后一个水上寻宝项目结束之前,我几乎就再也没有看过项目需求书一次;下午是雨中的龙舟赛: 在比赛开始前稍微训练了2轮,大家已经能够按照统一的节奏进行划船动作了。比赛过程很激烈,但还真想再和对手团队再划一轮更长距离的。由于上午寻宝用时最慢,我所在的BB队最后是以半分输给了冠军队,现在回想起来: 如果有更多人看看任务说明书,还是有可能有人发现其中时间因素对于分值的巨大影响的; 


感谢双胞胎的纵横拓展团队,双胞胎也是微笑图书馆项目的创始人;

拓展结束:多了解每一个同事这个目的还是达到了;为我们的活力大巴再来一次“爱的鼓励”:
靐靐 
靐靐靐
靐靐靐靐
靐靐

收藏到:Del.icio.us
12:37 技术营销:Google Chrome浏览器漫画书 » 大学小容>善用网络,助益成长!

今天最大的科技新闻无疑是Google Chrome浏览器了。关于技术方面的介绍,已经有许多人在讨论。从营销传播角度来那本漫画书或许也很有意思。

官方网站的漫画书在这里:http://www.google.com/googlebooks/chrome/

整个漫画书有39页,按下面的地址更换1-39可以直接看到每一页。
http://www.google.com/googlebooks/chrome/images/26.jpg

有人把这个漫画书做成了一个Slideshow,放在了slideshare.net上了,如果要看的话,请按全屏播放,效果最好。

Google Chrome Beta Comicbook

View SlideShare presentation or Upload your own. (tags: comicbook source)

早些时候,小容在《技术营销:将你的产品信息生动化》中提到技术营销的三个密诀:

要想使信息传达更为有效,技术营销发起者必须注意下列事项:

- Simple 尽量简洁:减少每次传达的信息量

- Vivid 尽量生动:运用视觉的力量,让图片来说话

- Fun 尽量轻松:使用活泼的口吻,或者娱乐化的风格

上次小容随后写了《技术营销:为你的产品拍摄一段微视频》,介绍了Common Craft利用纸艺为几个Web2.0公司制作的微视频。看Youtube.com上的这个帐号:http://www.youtube.com/user/leelefever ,现在已经有Common Craft的58个视频了。

The Common Craft Show is a series of short explanatory videos by Lee and Sachi LeFever. Our goal is to fight complexity with simple tools and plain language. We call our format “paperworks” and publish a new video about once a month.

Google Chrome漫画书的作者是Scott McCloud,下面是来自他的个人网站首页的一张插图。

看这里可以快速了解他的个人履历。联系他可以发邮件到:scott at scottmccloud dot com

他写/画了许多书,其中一本书是《理解漫画》(Understanding Comics),全书224页,其中215页是漫画,用他自己的话说,这是一本用漫画来解释漫画的书:)

他也在个人网站里设立了Google Chrome漫画书专题网页,提供了关于创作这个漫画书的背景资料。他可是采访了20个参与Google Chrome浏览器开发的工程师,才整理和构思出整个故事脚本。

Who wrote the script?

The engineers, for the most part! I helped conduct interviews with about 20 engineers who worked on the project, then adapted what they said into comics form. Some paraphrasing, lots of condensation, and one or two late drop ins, but basically it was a very organic adaptation and I had a lot of latitude.

想到一个好点子不难:用漫画书来做我们的产品介绍吧!听起来是个很酷的主意。可是,如果找错了人,花少了钱,讲错了故事,画起来不好看,漫画书出街后,效果不好。好主意就变成坏事了。

营销传播的细节和技术开发一样,都是技术活,一点也马虎不得。技术营销传播能否成功的挑战在于两个方面:一是技术开发人员要勇于打破常规,学会和营销传播领域的专业服务人士合作,另外一方面则是对于营销传播人士来说,要懂得如何深入理解技术的意义,懂得如何和技术开发人员沟通,理解技术创新的整个故事,并将这个故事用生动化的语言讲给普通大众听。

做好快速消费品等普通产品的营销传播其实已经很难了,而要想做好技术产品的营销无疑是难上加难。


相关贴子:

技术营销:将你的产品信息生动化

技术营销:为你的产品拍摄一段微视频

06:26 Beware of running ANALYZE in Production » MySQL Performance Blog

As you might know ANALYZE TABLE just quickly updates table statistics using index dives, unlike with MyISAM when it scans indexes holding table lock for long period of time.

So ANALYZE TABLE should be very fast and non intrusive operation doing just little update on the data. Right ?

Wrong! There is the bug or rather MySQL Design Feature which causes ANALYZE TABLE to block all accesses to this table while it could be flushed from the table cache.

What does this mean in practice ? If you have some long running query accessing Innodb table and you run ANALYZE TABLE you will be unable to access that table with “Waiting for table” lock until the first query completes.

For applications which run short transactions it may not be the big deal but if you mix long reporting together with real time update queries this can be the real issue.

This is generally the type of gotcha I hate the most. From the glance view there are no reasons Innodb can’t do this without locks but in practice some old mysql design artifacts result in this behavior and the bug can’t be fixed quickly.


Entry posted by peter | 8 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

00:37 Google AppEngine - A Second Look » High Scalability - Building bigger, faster, more reliable websites.

Update 3: BigTable Blues. Catherine Devlin couldn't port an application to GAE because it can't do basic filtering and can't search 5,000 records without timing out: "Querying from 5000 records - too much for the mighty BigTable, apparently."
Update 2: Having doubts about AppEngine. Excellent and surprisingly civil debate on if GAE is a viable delivery platform for real applications. Concerns swirl over poor performance, lack of a roadmap, perpetual beta status, poor support, and a quota system as torture chamber model of scalability. GAE is obviously part of Google's grand plan (browser, gears, android, etc) to emasculate Microsoft, so the future looks bright, but is GAE a good choice now?
Update: Here are a few experience reports of developers using GAE. Diwaker Gupta likes how easy it is to get started on the good documentation. Doesn't like all the limits and poor performance. James here and here also likes the ease of use but finds the data model takes some getting used to and is concerned the API limits won't scale for a real site. He doesn't like how external connections are handled and wants a database where the schema is easier to manage. These posts mirror some of my own concerns. GAE is scalable for Google, but it may not be scalable for my application.

It's been a few days now since GAE (Google App Engine) was released and we had our First Look. It's high time for a retrospective. Too soon? Hey, this is Internet time baby. So how is GAE doing? I did get an invite so hopefully I'll have a more experience grounded take a little later. I don't know Python and being the more methodical type it may take me a while. To perform our retrospective we'll take a look at the three sources of information available to us: actual applications in the AppGallery, blogspew, and developer issues in the forum.

The result: a cautious thumbs up. The biggest issue so far seems to be the change in mindset needed by developers to use GAE. BigTable is not MySQL. The runtime environment is not a VM. A service based approach is not the same as using libraries. A scalable architecture is not the same as one based on optimizing speed. A different approach is needed, but as of yet Google doesn't give you all the tools you need to fully embrace the red pill vision.

I think this quote by Brandon Smith in a thread on how to best implement sessions in GAE nicely sums up the new perspective:

Consider the lack of your daddy's sessions a feature. It's what will make your app scale on Google's infrastructure. 

In other words: when in Rome. But how do we know what the Romans do when the Romans do what they do?

read more

学习这回事之二——个体学习的深层动机与策略蓝色专注 » 车东 在 Google 阅读器中共享的项目

这段时间,得闲回到厦门,和公司很多伙伴进行了交流,公司新人很多,三期四期的,有些刚刚毕业的硕士、MBA,有工作几年回归到咨询行业的,看着大家学习和成长的那股劲头,非常来电,回想起刚来公司那会儿自己的状态,确实这两年,自己的成长和变化太大了,我很感谢希尔这个平台,给了我这样多的锻炼的机会,也感谢那些可爱的客户,是他们在真正敦促我们成长。

个体的学习能力是我这几个月来一直关注的主题,在这个瞬息万变的时代,个体的学习力太重要了,学得快比懂得多更重要!而我们要学的东西又太多太多,工作又非常繁忙,甚至有些时候“学习”成了负担,“学习”成了工作的对立面,面对各种是是非非的学习观,我有一种希望澄清关于学习的认知的冲动,或者说重新把“学习”这个问题抛出来进行更多的探讨。

首先来谈学习的动力,学习的动力源自很多方面,但归纳起来,不外乎基于优势、基于工作、基于困惑几类。

基于优势和爱好的学习:lily从小喜欢跳舞,虽然后来没有做专业舞蹈演员,还是保持着这个爱好,定期不定期去舞蹈班去学习一些专业动作,她发现从小练习舞蹈的她对瑜伽、普拉提都有很浓厚的兴趣,于是她报了个瑜伽班。

基于工作的学习:我在热线做话务员,所以我要学习语音艺术、话务接续流程、基础业务、知识库使用等。我做个体和组织学习的管理咨询工作,所以我要学习咨询的方法、流程、需要掌握个体学习和组织学习的理论知识,并通过实践、辅导、咨询,来丰富我的知识体系。

基于困惑的学习:我总是人际关系很紧张,不知道如何处理好和谐的人际关系,朋友推荐我看看卡耐基《人性的弱点》,学习“有效沟通”课程,

这三种学习是比较常见的学习动力,最有效的学习方式是哪一种呢?答案是:基于“目标”的学习!目标,看得见的标杆,是一个高效能人士的必备的东西,就目标论述的著作也不下千百,基本结论是:一个拥有明确而长远目标的人更容易成功。而基于目标的学习也是最高效的学习方式,比如M老师研究教练技术,目标是成为国内顶尖的管理教练,好了,自从他订立了这个目标之后,他阅读了100本这个领域的专业书籍和文献,电话咨询了几位这个领域的顶尖高手,平时交朋友也辉谈论他的研究领域——教练,和朋友交谈也会倾向使用他所学习到的教练技术来交谈,写博客也主要写教练方面的文章,慢慢的,他的学习、生活、工作、娱乐都和“教练”扯上了关系,升华了。另外,C君从前做直销行业,辞职出来做面点餐饮连锁,立志成为国内顶尖的面点餐饮连锁,创业的决心让他学习了一系列连锁经营的方法、融资方法、整合资源方法、人力资源管理方法,他每天出去吃饭、每天睡觉、和家人交谈都是谈面点餐饮,有点儿像阿甘正传里面那个喜欢谈虾米的黑人,渐渐的,他果真成了这个领域的高手。这种学习是超级高效的,聚焦一个点,迅速突破!

有人会问,这种目标或者学习那份深层次的动力来源于何处呢?NLP(神经语言学)认为,信念系统决定了人们的目标、定位和日常行为,对学习也不例外,我们的内心所持有的信念、价值观、规条,决定了我们的学习的动力,比如小军认为年轻人应该奋发图强,虚度光阴可耻,小辉认为生活平衡最重要,不要把自己搞得太累,这两种信念支持下,两个人的学习动力和强度是不同的,所以要解决学习动力的问题,需要从信念、价值观方面下工夫,这个方面“安东尼.罗宾”《激发心灵的潜能》是本不错的书。

学习的方式方法:

我们要学很多东西,方法千千万,归纳起来,可以有这几种,1.向书本学 2.向牛人学习 3.向自己学习

4.向互联网学...

1.向书本学,阅读是学习的捷径,任何一位高效学习者都在读书,前人的很多经验是可以借鉴的,所以治理国家的人要读历史,治理企业的人要读管理,个人自我管理要读经典等,现状互联网发达,什么信息都可以拿得到,但是这些网络的资讯还是没有办法代替阅读本身,阅读不仅仅在汲取信息,更是一种精神享受,阅读可以陶冶情操,增长见识,修炼心智,拓展思维。我接触过的诸多各个领域的大牛都在读书,读书的时间、方法、效能各有不同,关于读书方法,我会专门写一篇博文。

2.向牛人学,学打篮球找姚明,学说相声找冯巩,有人说姚明靠腿,冯巩靠嘴,有先天优势,学不来,但是他们因为自身优势所带来的技法的提升是其他人无法替代的,要学某项技能和能力,找到这个领域的高手,现实的或者网络的,最好是身边的。比如我要学有效沟通,发现公司内部有位W老师非常牛,沟通能力超强,大家都喜欢找他做深度交流,ok,找他请教要领,再实践,再反思。我要学PPT制作,发现隔壁班级有个女孩子很牛,好!约她一下,讨教PPT制作要领,或者看他的博客。要学讲师技巧,发现文子老师厉害,好,找到她的录像,自己观摩,模仿,然后提问,找到她交流。这些都是单一技能,相对容易,如果要学更难的,比较成体系的能力,比如如何做咨询项目管理,就要多找两个老师,博采众长,并且多多实践。技能层面的东西还是比较容易学到手,比较难的是“信念、价值观、规条”也就是他的信念系统,这是根,也是NLP的核心理念,只有学了这些才真正懂了一个人,这个是一下子学不来的,需要从模仿外在开始,比如模仿周总理抽烟的姿势。牛人之所以牛一定有他牛的原因,找到几个你欣赏的牛人,和他们交谈、和他们共事、替他们工作,这就是在练就吸星大法呢..

3.向自己学。富勒说过,人类的学习很多都是从自己的错误和失败中进行的。没错,一个喜欢反思的人更容易把经历的事情变成智慧,而非让它白白流逝,AAR这个工具是非常好的个人反思工具,没做完一件事情,问自己几个问题,A.目标是什么 B.现实发生了什么 C.为什么会这样,哪里做的好,不好? D.下次再做会怎样,这种学习很简单,但如果能坚持,不得了,曾国藩写日记写了一辈子,就是在做这件事情。反思让人类更成熟.反思是链接经验和智慧的桥梁。

4.向互联网学。web2.0时代,任何知识和资讯都通过一根网线和世界产生了互动,在这样一个10倍速爆炸的时代,能更好的使用互联网的人定能比其他人更鲜明的感受这个时代的脉搏,写博客、使用RSS订阅、使用web2.0平台建立个人电子品牌,这些都是通过互联网学习的实际应用,不信你Google一下:“web2.0 学习”或者干脆“学习2.0”试试。

 

 


随机文章:

推荐书籍《欣赏式探询》 2008-06-21
“学习这回事”——面向未来的学习策略 2008-04-05
明天你不得不知道的几款web2.0工具 2007-11-07
Re-read a book in less than 15 minutes. 2007-04-27
关于思维导图 2007-02-16

收藏到:Del.icio.us

^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2008-09-02
  九月 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          
==> 2008-09-04