Technology


Mar17

调教你的Mac键盘

做为一个Mac使用者,我不喜欢Caps Lock,而它占用了一个极好的位置,从十年前开始用VIM开始,我就想尽一切办法把这个键换成Esc。我喜欢用外界的机械键盘,而很多都是windows键位布局(不要跟我说HHKB,我真心不喜欢那手感,当然还有价格)。 如果你在Mac有关于键盘布局和设置的问题,本文就是帮你解决这些问题的。 Karabiner 这是一个比较生僻的单词,意思是「弹簧钩」。相比之前,这个app之前的名字特别直截了当:KeyRemap4MacBook。软件主页在这里。 他能帮忙做绝大多数键盘映射: 修改键盘映射,将任何一个按键映射成其他的按键,比如将cmd和opt键对换一下,你就可以正常使用windows外接键盘了 在不同的程序下对键盘做映射或者修改。比如Chrome的cmd+shift+w(你可以试试这个比较容易误按又讨厌的快捷键) 很多贴心小功能,比如不重映射笔记本自带键盘,插入外接鼠标接收器时disable内置触摸板等等。 很多内置的键盘映射组合,比如vi mode、Emacs mode等等… 调整不同按键的Key repeat Seil 有了Karabiner,其实绝大多数键位映射你都可以打几个勾就搞定了,可是……Caps lock它还是搞不定,这时候再装一个app叫seil,问题引刃而解。 他能帮助你: 将Caps lock换成任何其他键(几乎是唯一功能) 启用键盘或者手柄的多媒体键功能 这两个app都是一装即忘的,你甚至可以配置他们不显示在Status Bar中。

trackback Tags: 评论 (1)

Jul9

BlendUI,让webapp的体验和交互得到质的提升

上个月底,在hangjs上进行了一次演讲,这是最近半年我的主要技术工作。遂成此文,本文首发于Div.IO。 故事背景 百度轻应用已经推出半年多了,在市场上已有一定的影响力。但同时我们发现,开发者之所以使用轻应用,看中的是百度的渠道分发能力,而在体验上和Native app有比较大的差异,这个问题在应用复杂以后变得尤为明显。 前些年,在做移动web站点时,我们都会追求一些无刷新的跳转、换页效果,但后来发现这样做在市场顶级的手机上尚不能运行流畅,就更不用说那些相对廉价和低端的智能机了。所以近一年来,大家倾向于不在移动web站点中采用复杂的特效,只在最关键的部分,用最小的代价来实现。 现在你已经很少在Android中看到用Javascript实现的换页效果了;又比如百度的多数产品线放弃了Javascript实现的局部滚动效果,转而采用原生滚动实现,或者只应用到页面的少数交互元素中。与此同时,很多公司已经将重点精力投入到Native原生应用的开发中,减缓了在web端的投入。 而对我们,当然希望轻应用的体验和交互能够和Native媲美,那我们要做什么才能达到这个目标呢?做什么才是最有效的呢? 调研 我们首先看到了w3c的(一份报告)[http://www.w3.org/wiki/Closing_the_gap_with_native],这是来自缩短与本地应用差距(closing the gap with native) 的任务组产出。这份报告指出了webapp相对Native app的优势与劣势。 我们接着寻找了很多份数据,概括得最好、数据量也很丰富的是Developer Economics的这份调研数据详细说说其中两组关键的数据: 为什么开发者不使用HTML5技术开发应用? 多少Native app可以用web技术实现? 经过对6000+开发者的调查,他们发现,46%的开发者认为性能是影响他们选择的因素,这也是在所有因素中占比最高的,其次是API的缺乏,占37%,再次是与Native元素的整合,占29%。这和做为移动开发者的我们的主观感受相当一致,性能是Webapp的巨大瓶颈,不流畅的app一定不受用户喜欢;其次是一些功能无法用web实现,比如语音、定位等;再次,即使这些功能可以用Native原生代码实现,也无法将他们整合到Webapp中。 而第二个问题是第一个问题的延展:抛开性能问题,webapp的能力和Native app相比有多大差距呢?他们调研了Google Play中的30339个app。如果只使用HTML5技术,能实现37%的app,如果使用Phonegap,能实现49%,如果使用Appcelerator,能实现63%。这个结果让人觉得很乐观,只要我们能用一些技术,将设备的一些基础功能开放到web中,能大幅提高webapp的应用范围。 与此同时,我们调研了百度内部的16款webapp,希望了解做为国内一线厂商的工程师,他们认为webapp的瓶颈所在。结论出奇的简单和一致,有87.5%的工程师认为,在自己的业务场景中,转场和动画问题是最首要的问题。 其实移动web站点经过这些年的发展(我在2010年就参与过百度内部移动前端基础库的研发工作),工程师和产品经理已经很清晰地认识到什么交互是web无法实现的,比如3D转屏,动态的卡片式操作,他们会灵活地调整产品设计,避免这些交互。 但有一点是无法避开的,那就是页面的转场动画。web是基于链接构建的,从一个页面点击链接跳转到另一个页面,如果通过有刷新的打开方式,用户要面对一个空白的页面等待,如果通过无刷新的方式,用Javascript移入DOM节点,在Demo状态下能做得很好,但一旦产品化,就要冒着很高的性能风险:页面太大,可能转场不流畅甚至浏览器crash;单个webview中DOM节点过多,同时还要保存多个场景的状态,会占用过多内存,在使用的过程中会变得越来越卡;更不用提那些低端机型和低端浏览器了…… 所以,我们面临的首要目标是,如何能webapp的转场能像Native那般流畅。 实现思路 在说实现思路之前,要先给大家说说轻应用的业务场景,以便理解。 轻应用的业务场景 轻应用有两大入口:移动搜索和百度搜索app,接入轻应用的开发者他们最为看重的就是这个入口,尤其看重百度搜索app的入口。因为在普通浏览器中,通过移动搜索到达轻应用,这跟普通的webapp没有本质区别;而在百度搜索app中,由于轻应用的运行环境是百度框,我们能为轻应用的开发者暴露一些Native API的接口,这就是Clouda API,包括提供设备能力的Device API,提供百度云服务能力的MBASS API。 技术选型 由于轻应用的使用场景天然和Native结合得很好,我们很自然地想到利用Native技术来做转场。相对用web技术,这条路更为现实:市面上有很多转场相关的Javascript库,百度内部也有若干实现,但最后产品化以后是否成功,完全取决于具体业务开发者。开发者能否有效地缩减DOM数量和层次,能否找到性价比较高的方案是关键。而轻应用开发者的水平良莠不齐,用web技术来解决此问题显然不可行。 而用Native技术来做转场,我们也经历了一些波折。最初,我们重点考虑的是类似Appcelerator的方案,不过我们不像Appcelerator那么激进地将Javascript编译成Native code,而希望暴露一组基本的Native API,供前端工程师调用以实现流畅的app效果。但这样随之而来的问题是,开发者的可定制性会变得特别差,极其依赖Native API,而且开发感受也会很糟糕,毕竟他操作的不再是DOM,而是一个Java like的东西。这个方案很快被我们否定。 根据前面所说的调研,我很快发现其实大家对普通的web元素,并没有太多性能方面的担忧。不管页面多复杂,很少有会担心页面内部的性能,而担忧统统来自跨页面的转场效果。因此,我提出了一个概念:Every element can be a webview. Every element can be a webview […]

trackback Tags: 评论 (2)

Dec27

2013 前端技术盘点

本文曾发表于2013年12月《程序员》,个人收集和一些拙见,难免有错误和疏漏,请各位补充。文中加粗的关键字不少,没有一一添加链接,Google一下即可找到相关资料。 2013年,尽管前端技术在无线领域受到了挫折,但这无法减缓其发展势头。在基础技术方面,规范和标准的发展、浏览器的快速演进为将来的Web应用打好了根基;随着网站规模的进一步变大,交互变得更复杂,大家更关注用新的开发模式来解决问题;更重要的是,经过多年积累,在前端工程实践上我们有了丰富的成果。本文将从多个角度介绍今年前端技术的发展,其中会穿插若干对前端发展的思考。 方兴未艾的规范和标准 自从HTML5推出后,W3C和各大浏览器厂商都在加紧推动规范发展和实现,尤其是手机浏览器对规范的支持程度,已成为国内浏览器宣传的卖点。对于W3C的正式规范,大多数都已经被现代浏览器实现,而我们更应关注快速发展中的Working Draft规范。它们不仅对实际开发有帮助,更重要的是它们代表了Web未来的发展方向。 Web Components规范定义了未来的HTML组件,其中最重要的部分是Shadow DOM和Custom Element,除此之外还包括HTML模板、HTML imports和Decorators。Shadow DOM能将组件的代码和使用者的代码彻底分离,通过在文档渲染时插入一颗DOM子树,但这子树并不在主DOM树中,因而外部的CSS无法直接影响Shadow DOM中的元素;当然,Shadow DOM能提供事件API、Javascript API、CSS API供外部控制。Custom Element则允许开发者自定义HTML标签,让页面更语义化的同时,还能为元素加入属性和方法,以提供特定的功能供外部调用。 WebDriver规范和 Selenium 2 WebDriver 自动化测试框架 API 十分类似,它取代了嵌入到被测Web应用中的Javascript,由浏览器直接支持的WebDriver,避免了Javascript安全模型的限制,还能利用操作系统级的调用来模拟用户输入。Firefox、IE、Opera 和 Chrome 都对其有一定支持,也能通过 WebDriver 完成 Android 和 iPhone 的移动web应用测试。 Webapp Working Group今年很活跃,前文提到的 Web Components 规范就是来自这个小组。它们今年的进展还包括 Push API、Streams API、UI Events 等规范。 W3C去年还成立了System Applications Working Group,目标是定义运行环境、安全模型和相关的API用来构建能与原生应用匹敌的web应用。他们在今年提出了一系列规范,其中比较重要的有:用来定义和引用Webapp的App URI规范;能定期唤醒应用的Web Alarms API;和系统短信服务通讯的Messaging API。 W3C所有规范都会公开发布,在 http://w3.org 上可以找到各个工作组的当前进展,你也可以订阅他们的邮件组。 除了W3C规范,另一个重点是 […]

trackback Tags: 评论 (12)

Jun17

Using PCKeyboardHack & Parallels Desktop on Maverick(OSX 10.9)

上周Apple发布了OSX 10.9,代号Maverick,我尝鲜后发现,大多数软件没有兼容性问题,运行良好。 主要的兼容性问题依然是在kext方面,这里包括Parallels Desktop和PCKeyboardHack;另外,MplayerX无法正常工作,换用MplayerX Extended工作正常。此外,由于accessibility运作方式的改变(猜测是由于多屏幕的全屏方式做了升级) 此外,所有基于accessibility接口的软件都工作不正常,包括:BetterTouchTools,sizeup,moon等。但由于我是在一台Mac mini上升级到Maverick,影响不大,我的MBA依然是10.8,暂时不打算升级。 下面说说如何在10.9下正常使用PCKeyboardHack 和 Parallels Desktop。 Parallels Desktop 7即使注册了kext也无法正常工作,只好购买了个升级包升级到8,然后使用下面的命令注册kext便可正常工作。 cd “Applications/Parallels Desktop/Contents/Library/Extensions/10.6″ sudo kextutil prl_hypervisor.kext/ sudo kextutil prl_vnic.kext/ sudo kextutil prl_hid_hook.kext/ sudo kextutil -d ./prl_hypervisor.kext prl_netbridge.kext/ sudo kextutil prl_usb_connect.kext 而PCKeyboardHack只要让之使用10.7的kext就可以正常工作了,至少我的keymapping是正常的,我在PCKeyboardHack的github issues里面也添加了这条解决方案,事实上,在10.8就有人提过类似的解决办法。 sudo vim /Applications/PCKeyboardHack.app/Contents/Library/scripts/kext.sh (在 10.9下,用10.8的 kext,修改内容见后文) 重启即可 #!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin; export PATH basedir=”/Applications/PCKeyboardHack.app/Contents/Library” kextfile=” uname=`uname -r` case “${uname%%.*}” in 11) […]

trackback Tags: 评论

Feb12

Apple TV连接电脑显示器和音箱使用

买了一个Apple TV (3rd gen),主要是我妈来北京过年,用iPad看片太累,家里又没有电视剧……Apple TV似乎能满足我的要求:成本低,界面简单,有遥控,还能利用现有网络。 收到货以后,兴冲冲地接上显示器。傻眼了,没有声音。简单介绍一下我的设备: Dell U2412M。这是U2410被撞坏以后的替补,所有输入口都不带音频。 漫步者R1900TII。只有模拟音频输入,没有数字光纤输入口。 如果显示器带音频输入,或者音箱带数字光纤输入,就不用折腾了,直接用Apple TV自带接口就可以正常使用。 上网寻觅一会儿,国外几乎没有关于此问题的说明,而国内的朋友给出了几个解决办法: 买一个HDMI音频分离器,将音频分离出来以后接上音箱。但声音偏小,同时影响视频质量。 将光纤信号通过数字音频解码器,转换成模拟音频信号。相对完美的方案。 大过年的,我有功夫淘宝,卖家也没功夫发货啊。只好自己琢磨DIY方案。想到了Airplay,搜索一圈下来,找到一个软件Airfoil Speakers,它将Mac模拟成一个Airplay音频设备,Apple TV设置好以后,视频仍然在Apple TV的显示器上播放,声音已从电脑音箱中传出来了。 但还有一个小问题。我妈看清宫戏,我坐在电脑前干点啥时,那声音真让人煎熬!刚好,Airfoil还有一个iPhone版,在iPhone上装好,可以将任何一个软件的声音继续用Airplay协议重定向到iPhone中去;或者,也可以在Mac上接个蓝牙耳机,将Airfoil Speakers的输入设备设置成蓝牙耳机。大功告成。 一句话总结:Mac用户,可以用Airfoil Speakers模拟一个音频设备,接受Apple TV的声音,这样,ATV就能在电脑显示器和音箱上正常工作了。 BTW,Apple TV 3虽然不能越狱,但是用DNS大法之后,看国内片源,速度唰唰的。操作简单,老人也能轻松上手。

trackback Tags: 评论 (1)

Aug22

Velocity 2012 Day three

六月二十七日,是Velocity 2012的第三天。今天早上的会议就更加软,更加吹水了,一上午12个session,只有2个和性能相关,其中一个是DEMO展示,另一个是讲在智能机上web和Native app的差别。我们干脆没去会场,在Hotel好好的睡了一觉。 在旧金山地区罕有出租车,但在这个会议中心,出租车反而变得比较常见。 下午的内容相对昨天含金量也稍低了一些,Mobile的场变成了Velocity Culture,其实就是一些偏软素质方面的session。另外,赞助商的场次也多了很多。 web性能的第一场是Opera、Chrome、Firefox的Demo,我便转战到Velocity Culture大厅。这边是一个金发美女 —— 是Delve Networks的CTO —— 在讲职业成长的内容:Leveling Up – Taking Your Operations and Engineering Role to the Next Level.,演讲风格很有轻松,尤其是美女,所以大家乐得开心。不过内容就比较粗浅了,更像是给职场新人的鼓励和打气。如果你有相关需求,还是去看看《程序员修炼之道 —— 从小工到专家》吧。 回到web性能大厅,是Nicholas Zakas(《High Performance JavaScript》的作者)在讲Javascript timer的性能:JavaScript Timers, Power Consumption, and Performance,研究得真够细的!整个演讲都是在介绍JS语言中的计时器性能。包括setTimeout、CSS的动画在各个平台下的实现原理、效率和耗电量(针对移动设备),以及简单介绍了几项新技术:W3C的web workers草案,IE的setImmediate。对Timer有兴趣的可以看看他的slide。 接着是Etsy的人来讲A Picture Is Worth a Thousand Logs,基本思路是将数据尽量地可视化,举的例子很有冲击力。不过在现在来看,不管是大公司和小公司,把数据从log日志里面具体化成图表已经成为RD的标配了。 后面是一个女顾问讲测试UI性能的工具:5 Essential Tools for UI Performance,都是一些常用的工具,而且会后迟迟没有放出slide,有些让人失望。 最后一个session是JSPerf的人来讲各种Javascript执行的性能,过程很激烈,如果对JS内部一些细节优化点有兴趣,建议看看视频。JSPerf是一个做Javascript性能测试的平台,能够覆盖到各种浏览器,各种平台,并且能做多次测试,做统计平均。 在我看来,很多在本机测试的Javascript执行效果是很不靠谱的,测试的结果会受到当前cpu利用率、杀毒软件、电池还是外接电源等等因素影响,并且每次测试的偏差会很大。当然了,你更不可能测全所有的浏览器。因此JSPerf这个网站的出现倒是能让我们做更靠谱的性能测试。 三天的Velocity就这么结束了,第一次来国外开会,而且是这么经典的会议。简单谈一下自己的感受: 国外的研究通常会做得很细致,总能从一些细节之处挖出能对产品产生影响的点。 […]

trackback Tags: 评论 (2)

Aug21

Velocity 2012 Day Two

6月26日开始就是正经的velocity 2012了,会场里面的人明显比前一天多很多,转场的时候人山人海。美国的胖子真够多的,我经常能在会场或者路上看到超级大吨位的胖子,男女老少都有。 最开始是Steve Souders的吹水和开场。一上午的主题演讲几乎和性能没啥关系,基本上是赞助商和运维的话题。 中间Steve Souders介绍了httparchive.org从2010年10月就开始跟踪网站的性能指标,这样就能看到网站的历史性能状况,或许对我们了解自己的网站和竞争对手的网站有一定帮助。当然,对中国的网站参考意义又会小一些,不过,文件体积这些硬指标还是值得参考的。 中午仍然是不变的自助餐,下午整个大会的“正餐”终于来了。 首先是Google带来的SPDY介绍,这一场略微有点扫兴。主要是介绍了他们自己研发的SPDY技术,里面的优化点很多,包括对连接、加载、前后端运行的优化。唯一也是最重要的不便是,这个技术要求服务端和客户端同时具备相应的支持才能完成性能优化,他们开发了各大web server的mod,但是浏览器只有chrome支持。在国内来说,花这么大的成本,受益却颇小。 接着是LogNormal和Facebook三个人混搭讲RUM for Breakfast – Distilling Insights From the Noise。这个session的入手点很细,这也是老外们比国人钻研的更深入的一个体现,他们主要的思路是从一大堆数据里面,找到和收益(PV、跳出率)存在明确关系的部分,然后有针对性的优化。 对CDN做优化,他们不是用传统的ip库来解决问题,而是通过对没一个用户随机的请求一个anyname.dns.fb.com 的空图片,计算请求时间,来为所有的ip段寻找最优的服务器。 在做数据分析的时候,他们发现很多时候,曲线并不服从正态分布,他们认为是由于数据噪音引起的。他们做了一些简单的过滤,把异常数据去除。 将性能数据和收益数据结合来做分析,他们统计了跳出率和加载、DOM load等时间的关系,并且发明了一个LD50的指标,就是当跳出率大于50%时,这些性能指标的值,这样能更精确地来进行优化。 接下来是Google的人讲Selecting and Deploying Automated Optimization Solutions。这个session内容比较少,就介绍了一个自动做web前端代码优化的思路,以及相应的服务提供商。 他的主要思路是通过在前端服务器之前架一个代理,用户从这个代理请求到的代码是经过自动优化的,主要是优化可以通过机器来自动化的部分: 为不同的浏览器生成不同的代码 图片转成URI、WebP 自动压缩图片,cache 根据用户访问路径预加载 此外,他还提出了一些通过修改原有页面逻辑的方法来做优化的思路,包括根据用户的行为,来对页面的不同部分做优先级判断,然后将代码重组。不知道这块他们具体效果怎么样,很科幻啊。 他们的思路和FIS的相似,只是把我们线下处理放到了线上。好处是能做到更好的实时和动态性,不过这让线上服务的复杂度提高了很多,运维更难了。 下面一个Session是讲CDN优化的:Getting A Grip On CDN Performance: Why And How,前面的一堆数据和中国国情差距比较大,主要是为每个关键国家、州找到最快的CDN,没太细听。后面的测量方式还有点意思: 不要用服务器到服务器的速度来做测量,要用真实用户 不要用Google Analytics来做测量,用Resource Timing API 测量的文件应该是16kB,这是他们统计中占比最大的文件大小 排除那些不靠谱的数据(今天多个session都提到了这一点) CDN和我现在的工作距离比较远,中间跑到隔壁的Using Node.js to […]

trackback Tags: 评论 (2)

Aug12

Velocity 2012 Day One

第一天的内容是tutorials,来参会的人也不多,想来主要是以介绍概念为主。 我主要听的是Web Performance。第一场Understanding and Optimizing Web Performance Metrics,分五部分: 介绍和网络请求相关的基本知识,包括DNS,连接建立,SSL握手时间等; HTML解释过程,包括DOM树的建立,JS和CSS的加载过程; 和渲染相关的度量指标:loading、interactive、DOMContentLoaded,DocumentLoaded 和用户感受时间相关的指标,元素开始渲染时间,可交互时间什么的 听了这一场以后,基本上就对今天的内容失去信心了 —— 果然很tutorial嘛。 第二场是A Web Perf Dashboard: Up & Running in 90 Minutes,主要介绍的是收集性能数据,然后展现成一个dashboard的实践过程。中间简单介绍了Piwik这个分析工具,唯一的优势是能架在自己的服务器上,看功能远远没有GA强大。 上午的会议没有什么让人兴奋的点,中午在会场吃了自助午餐,可是午餐没有咖啡,下午就有点疲劳了。 下午第一场是Dev vs. Prod: Optimizing Your Site Without Making Your Build Process Suck,一个有点冷幽默的小伙子在讲。里面的内容很浅显,主要是靠nginx的几个插件来解决问题,但是提出的核心概念值得借鉴:性能优化不应该让源码和系统构建过程复杂化。 第一场完了后有下午茶,终于有久违的咖啡了。 下午的第二场是关于无线方面的 The 90-Minute Mobile Optimization Life Cycle,前面介绍了一堆关于无线的数据,市场数据,流量数据等,国外的增速明显比中国要快得多;然后是和性能有关的数据,主要是性能对pv,跳出率,转换率的影响,看数据挺惊人的。其实我们也应当加上这部分监控。接着介绍了一堆用于性能分析的工具,教大家如何看瀑布图和数据表格。从DNS开始,一直到页面渲染结束,介绍了一些简单的性能优化规则和方法。 总的来说,第一天没有什么值得圈点的内容。但每个slide都是很用心的总结和归类过的,如果你还没有接触过性能优化,不妨找到里面的slide看一遍,你会对整个性能优化的过程产生全面的初步认识。 我的twitter是 @cnberg ;新浪微博是 @berg ,后面两天的会议总结也会很快发出,请勿错过。

trackback Tags: 评论

Jul8

[技术分享]让前端开发更高效

最近两天我在杭州参加D2,会上见到了一大圈熟悉的面孔,阿里举办这样的会议不仅仅是树立自身的技术形象,也创造了一个让各路工程师集中到一起的好机会。昨天去了一趟淘宝,很感谢圆心的招待;今天和玉伯一块吃饭,也是相聊甚欢。 下午我主要分享是的《让前端开发更高效》,刚才搜了一下,发现CSDN简直神速,已经有新闻稿发出来了。我也趁热放出Slide吧:D2分享:让前端开发更高效。 这次分享主要介绍的是我现在主要在负责的百度前端集成解决方案(FIS),我们希望能通过FIS,简化开发、快速解决需求。主要分成组件化、自动化两大部分来展开 —— 这也是FIS的两大核心。由于时间很有限,分享只能浅尝辄止,希望思路对大家有所帮助。将来也会找机会分享其中的实现细节,并且FIS也已经有开源计划。 我的twitter是 @cnberg ;新浪微博是 @berg ,如果大家有什么问题也可以在下面留言或者微博联系我。

trackback Tags: 评论 (13)

Apr30

编程乌托邦

“While we pursue the unattainable, we make impossible the realizable.” – Robert Ardrey. 程序员都有完美主义倾向,在某种程度上,这是好事。完美主义让我们追逐细节,仔细地编写自注释的代码,不放过任何一个可能bug的语句。 然而,在设计系统时,如果仍抱守着“乌托邦”式的梦想,这便是程序员的噩梦。正如文首引用Robert Ardrey所言,如果我们追求不可达的事物,我们会将可能之事变做不可能。这篇短文便是介绍乌托邦给程序员带来的梦魇。 程序员面对问题时,如果自认已经找到(或可以找到)最终的,最完满的解决办法,就很容易陷入这种极端主义。我们总希望这个系统是最终版,不用再重构;总认为正在设计的API是最好的API,以后永远可以不用变化;总想着这个架构拥有最好的灵活性,能适应未来所有的需求。 在我看来,乌托邦式的目标,只会给程序员带来三种可怕的梦魇。 第一种是自卑。设计者觉得之所以无法实现理想,是自己的能力问题,他不将无法达成目标怪罪于目标的不可实现,而是自己的无能。 第二种是拖延。他们觉得,既然目标这么遥远,那么实现目标的过程也就很艰难,需要长期的准备。我们希望接二连三的评审,能够使设计方案达到完美;指望着找到大块的时间来做事情,却不利用零碎的时间开工;过分考虑,设计臃肿而不自知。 第三种是敌意。这个乌托邦的目标在他们心中是神圣不可侵犯的,所有对这个目标有疑问的人都会被他们毫不留情地消灭。在实现目标过程中,遇到的挫折也都怪罪到其他人身上:之所以系统没有扩展性,是因为经理不给我足够的时间;之所以bug频出,是PM老是变更需求。 抱有乌托邦梦想的人,无不被上面的一种或两种梦魇困扰着。其中,拖延是最常见,最“无害”,却最难治愈的。 你有没有乌托邦式的编程梦想?最后它们结果如何?欢迎各位留言分享!也欢迎follow我的twitter@cnberg 或者新浪微博@berg与我交流。

trackback Tags: 评论 (3)