技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 乱象,印迹
    许多尚未投身的读者谈起“降级论”却满怀憧憬,真正敢于“降级下凡”并成功的却寥寥无几。仔细想想,无论从逻辑上分析,还是从自身经验来看,“降级”之路都不算坦途。根据我的归纳总结,IT从业者(“精英”这个说法略带刺激性,我觉得“从业者”更合适)走上降级之路,有几大困难是必然要经历的。 业务模式的探索可算降级路上的第一大困难。
    前几天在Twitter上有朋友问:ln的参数顺序要怎么记忆比较好,因为总是搞错。这个问题我也遇到过,以前每次都记不住两个参数的先后顺序,最终办法是花了点时间背诵命令模板,每次用到时心里默念就好了: ln option target linkname 我没想到的是,搞混顺序竟然是个普遍问题,我本来以为哪怕有疑问,背背模板也好了,大家都应该是如此。
    先提出创意,再开发产品,然后内测公测,最后正式发布。在不少公司里,这是再正常不过的流程;每一天,它都在无数地方重演。至于发布之后会怎么样,就撞大运吧,反正之前已经按部就班跑完了整个流程,换句话说,能做的,已经都做了。 但我分明又看到,无数的产品(尤其是新产品),无数的公司(尤其是创业公司),就这样看似正常地落难了,而且让人百思不得其解——创意、开发、测试、发布,每一步都走得稳稳的,到头来,为什么落得一败涂地呢? 按照《四步创业法》的作者Steven Gary Blank的分析,用这种方法开发产品,尤其是创业公司用这种办法开发产品,必然是一条不归路。
    我在招聘时常问的一个问题是:在你过去的工作中,遭遇过哪些印象深刻的困难,最后是怎么解决的?依我的经验,简历写得再漂亮的人,如果这个问题答不好,大都可以直接忽略。为什么会有这种结论?因为我们需要招聘的不是“经历丰富”的人,而是“有职业素养的人”。你遇到的问题可能很容易也可能很难,但我看重的并不是问题的难度,而是解决问题的方式、步骤,以及反思的深度。拿恢复误删数据来说,这可能算非常简单的任务,我更感兴趣的是怎样分析问题,找了怎样的资料,采取了怎样的步骤,此后做了哪些措施来避免这种错误再次出现。在我看来,相比问题本身的难度,解决问题的方式和步骤,以及反思的深度,都体现出一个人的职业素养。 是的,上面我两次提到了“职业素养“。
    如今,市面上关于“领导”和“领导力”的文章、书籍已经数不胜数,大家似乎并没有厌烦的感觉,新的资料仍然层出不穷;另一方面,对相当一部分人来说,“领导”和“领导力”又确实难以捉摸,看书似乎明白了,做起来却全然不对劲。为什么会出现这种情况呢?据我的观察和思考,主要的原因是:领导和领导力,都是主要与人有关的学问,一旦与人有关,就不能依靠简单的条条框框来行事。下面,我结合自己的经验和思考,谈谈领导和领导力的若干问题。 首先的问题是,为什么要有领导呢?或者说,什么样的人是领导呢?一个人被上级任命为“领导”,他就是领导了吗?不。他如果做得好,才可以成为领导,做不好,不过是“空有个领导的架子”而已;相反,民间的很多“领导”(领袖、领头人物),并不需要任命,大家都认可他。
     其实所谓编码问题,不外乎若干概念,弄明白了这些概念,编码问题就可以迎刃而解了,所以这里按照概念来展开讲解。 字符和字符集 字符,就是我们日常使用的各种文字,比如中文的你、我、他,英文的A、B、C,日文的に、ほ、ん、ご,都是字符。手写可以用到的字符几乎是无限的,但在计算机中,必须事先约定好字符的范围,也就是穷举出所有“可以使用”的字符。这个范围,就是通常说的“字符集”(Character Set)。 ISO8859-1是开发中常见的字符集(MySQL默认就采用这种字符集),它支持的语言有英语、德语、法语等,也即包含了英语、德语、法语中的字符。
    应人民邮电出版社图灵公司的邀请,我有幸参与了Bob大叔所著Clean Coder的翻译。 与前作Clean Code不同,这本书着重讲述的是开发人员的“职业素养”,也即职业开发人员应当如何做事。在阅读中,我时常会忍俊不禁,也会拍案叫绝,感叹Bob大叔把深刻的道理讲得这样通透。我虽然没有Bob大叔那样好的文笔,不过对“开发人员的职业素养”这个话题,仍然有很多话想说,索性分几个方面写下来。 学习 开发人员在工作之前,一般都已经经过大学阶段的专业学习。众所周知,大学的很多课程已经相当落后,教材也非常保守,所以我见过的好开发人员,不少都是自学成才。但是,这些问题并不能否认通过专业课程学习知识的意义,职业开发人员理解的“学习”,应当明确地区分知识、课程、教材:知识是重要的、稳定的,课程和教材是不那么重要的、变化的。
    总的来说,程序员可算是英语水平比较好的群体,因为在这个行业,英文资料是最全面、最及时,对英文资料的需求也最迫切的。因此,就我的观察,即便刚入门不久的程序员,面对陌生的问题,一般也能查阅英文文档,找到需要的信息。但是另一方面,我也发现,经常阅读英文文档的程序员,英语水平许多时候却不像“经常阅读英文”的样子。应《程序员》的编辑邀约,我在这里列几点自己的学习心得,供大家参考。 第一,读文档不能只读代码。 读文档只读代码,是很多程序员的习惯,也是导致程序员虽然读了很多英文资料,英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍阅读技术图书方法的文章,提出过“先代码后文字”的方法,也就是“先看代码,看不明白再看文字”。这种阅读法能极大提高阅读效率,但如果技术图书只看代码就足够,还要文字干什么呢?
    我的朋友韩磊曾说:跨界(工作)真是一件刺激好玩的事情。彼时我还无法体会这句话的真义,直到去年因缘际会自己也投身跨界,终于有机会切身体会到其中的滋味,所以有这篇文章。 其实在此之前,我一直混迹于互联网的圈子,自认为接触过一些真正的东西,比如大规模数据的抓取,海量数据的存储和处理,在线系统的维护……客服、文案等等工作也有涉及。我想,太阳底下没有新鲜事,跨界虽然是在不同的领域,做的事情大抵还是这些。但是真正投身实业,才发现事实远非自己想象的那样。 这方面突出的例子之一,就是虚拟世界和现实世界的交流。从某种方面来说,互联网或者纯软件开发,更像在理想的虚拟世界中进行,可以脱开现实的束缚,只关心核心的模型。“发一条确认的消息”是非常普通而且常用的操作,你用Java也好,C#也好,PHP也好,只要按照约定发送这条消息,结果都不会有多大差别;落实到现实世界中,情况要复杂许多:消息必须有实际的载体,有发送的
    卡尔波普曾说:“生活就是解决问题”。确实,在生活中,我们时时、处处都在解决问题――吃饭问题、睡觉问题、学习问题、工作问题……由是推之,“解决问题”本身也成了需要解决并且极有价值的问题。迪特里希・德尔纳的《失败的逻辑》,就是论述“如何解决问题”的一本小书。 解决问题的第一步,是认识问题。许多人认为“问题就摆在那里”,或者上来就着手解决,结果怎么努力都收效不佳,就是因为没有认识问题。比如听到有人说“要...
    算起来,我也算有一些翻译经验的人了,最近接连做了两次关于翻译的分享,发现很多人都对翻译有兴趣,索性将分享中关于翻译的经验做个总结。 我是在2003年接触翻译的,当时美国对伊拉克动武,国内的报道非常奇怪,为了在论坛上争论,加上自己还在读书,时间比较多,就开始翻译一些外国媒体的报道,发在论坛里。初做翻译的最大感受是堵得慌,从来没想过要把意思表达明白会这样困难,就好像要说话,却发现舌头不受自己控制。所以一千...
    或许未来的微博更像一种基础设施,一条消息总线,消息可以很方便地发布,而没有太多私密性(真正私密的信息价值往往不大),也可以很方便地追溯到人,又可以很方便地从这个人的历史发言,做出评价。至于在此之上,如何按照不同的维度(时间、话题、人物),整理、归纳各种消息,这就是各种应用该做的事情了。
    前段时间,与豆瓣网友伊卡洛斯聊,他问我是否有书推荐,书没推荐几本,文章倒是推荐了一篇《刘瑜的秘密书架:从经典到经验》,他看过之后感觉很好。其实,我第一次看也有豁然开朗的感觉,索性就着刘瑜的文章,说说自己的阅读经验吧。在我看来,“读书”和“会读书”是两回事,如何才叫“会读书”,至少要保证几点,下面一一道来。 首先,读书一定要有明确的目的性。此处的“目的性”,准确来说就是真正关心的问题,循着这些问题,...
    今天我的同事老赵 @jeffz_cn 问我,有没有办法用正则表达式匹配“不包含某个字符串”的文本,正好,我在写作的《正则表达式傻瓜书》中也提到了这类问题,就把这一节放出来,给大家参考,也希望大家多提建议(尤其是配图方面)。 正则表达式的与或非 我们都知道,写正则表达式有点像搭积木,复杂的功能总可以拆分开来,由不同的元素(也就是子表达式)对应,再用合适的关系将它们组合起来,就可以完成。在这一节,我们讲解常见的与...
    提高自己的效率,做到事半功倍,是我们都希望达到的目标。如何达到这个目标呢?根据我的经验,不断反思、总结自己做过的事情,是很有成效的办法。翻译,也是这样,下面是我自己总结提炼的翻译步骤,给有兴趣的朋友作参考。 第一步,通读 通读很重要,却被许多译者忽视,他们往往认为,自己已经了解原文的“意思”,可以直接下笔,遇到问题“见招拆招”即可,翻译前通读原文,完全是浪费时间。 但是,事实似乎并非如此。我们翻译文...
    常做翻译的人都知道,英文讲究结构严密、成分齐整,我们遇到再长的英文句子(哪怕是多个从句,或者有长长的插入语),只要能正确解析结构,都不难理解;中文则更追求“写意”,不太受形式规则的拘束,好的中文能营造出“行云流水”的感觉。单独看这两种语言的特点,各有理由,但是做起翻译来,就难免出现冲突,“尾大不掉”就是突出现象之一。 这里的“尾大不掉”,借用了余光中的说法,问题并不在并不是“尾大”,而在于“身躯臃...
    今天金山的刘鑫老师在邮件里谈到了“工程师思维”(工程师的思维能力,就是一种可以把想法实现出来,一步步的变成现实的思维和实践训练),借题发挥一下吧。 我上高中的时候,学校算是本市最好的中学,班主任物理老师也是特级教师,但我一直不是觉得,他讲课说不上多好,无非是循规蹈矩的套路,甚至有点死板――就拿受力分析的题目来说吧,多简单的题目,都要画坐标系,而且就只有那么几个力:重力、摩擦力、牵引力等等,来来去去...
    英文中的否定句,大致可分为两种,一种是对单词的否定,也就是“特殊否定”(Special Negation),比如She is unhappy;另一种是对整句的否定,也就是“句子否定”(Nexal Negation),比如She is not happy。两种类别,在最简单的情况下,意思是没有多少区别的,都是“她不高兴”,但如果加入了其它词语,分别就显现出来了。比如,我们加入单词very,前者就成了She is very unhappy,意思是“她很不高兴”,后者则是She is not v...
    1.长期的任务,要尽早开始一般来说,长期任务总是比较麻烦,而人心里总有逃避困难的趋势,最后的结果或者是最后干脆放弃,或者留下一点时间手忙脚乱地赶工;我自己之前也有这样的教训,自欺欺人地说“要轻松生活,抛开烦扰”,到最后几天才着急办理,搞得狼狈不堪。后来我发现,自己的做法其实是事与愿违的,只要调整好心理状态,尽早了解情况并不必然带来的心理压力,反而因为时间充裕,有信心把握进度,即便中间遇到突发的问题...
    It is…that…的句型,在英文中非常常见,大家都知道,这表示强调,理解的时候,要把that后面的部分放到前面来,比如: It is no wonder that she is so ill. 她病得这么厉害,并不奇怪。 It is strange that she should have failed to see her own shortcomings. 她竟然看不到自己的缺点,这真奇怪。 It is arranged that the class meeting will be held next week. 据安排,下周召开班会。但语言是非常奇妙的东西,例外的情况...
[ 共54篇文章 ][ 第2页/共3页 ][ 1 ][ 2 ][ 3 ]
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1