但是对于程序员来说掌握封装技术本身跟学习使用别人封装好的技术工具是两回事。
“程序员从此不再需要关心XXX”这是evangelist最
常用的宣传语句2B ED看了就很高兴然后拼命去
学习新的“技术”把他们曾经掌握的XXX底层技术给忘掉。
微软所宣传的理念被Hacker理解为“Even monkeys can code”。
ED被evangelist鼓吹的新技术洗脑最终就是成为monkey而已所做的工作毫无技术含量很容易被淘汰。
所谓的程序员30岁必须转行这种说法便是源于ED被洗脑。
这种ED从未掌握真正的编程技术是必然被淘汰的。
而这种ED在大学时就是把cs 1101 / 1102理解成为教 c / 教 java的那群人。
他们从一开始就走错了。
作业编辑说明在技术宅和他老婆的故事中只有女主人公完成作业之后男主人公才会发出新课程。
当然身为看客的您可以无需完成这些作业但如果您仍是学生或者您正在带学生或小弟的话倒是可以做个参考 1. 用500字讲述什么是Programming Methodology 2. 列举10种Data Structure. 3. 列举10种Algorithm. 【作者声明】Katze实际上是正宗计算机系科班出身而且大学成绩甩开Wuvist九条街这其中还包括算法、
计算机架构等传统上被技术宅男垄断的科目。
Katze
毕业后长期于投行从事Unix服务器运维
工作故研发编码水平会被Wuvist嘲笑但Wuvist不会写shell脚本时绝对是第一时间向Katze求助。
Wuvist写的这系列教程以及
作业安排是为Katze量身定做的像第1课的作业便因此会出现Perl这门研发中不常用但在运维中却非常普遍的语言。
这系列Wuvist是写给老婆的私人
课程其中充满了各种主观偏见有缘发布到51CTO来各位看官若看得不爽请尽管抛砖头狠踩但是请尽量喷得准确、到位、凶狠一些 宅男
程序员给老婆的计算机课程之1认清实际 这个系列来自一位宅男程序员这个系列是他写给老婆的电脑课程。
以下开始本系列的第1篇——什么是算法。
“算法”、“数据结构”等是本质很重要需要掌握但一般开发时很少需要自己去实现。
AD “算法”、“数据结构”等是本质很重要需要掌握但一般开发时很少需要自己去实现。
觉得多数开发是“拚积木”。
即便是业务逻辑需要对一些数据进行排序也不可能自己去实现一个quicksort算法而是直接调用quicksort的现成类库。
这也直接造成了2B ED穷其一生都不能掌握真正的编程能力。
他们认为能够“解决”问题就好至于问题是怎么解决的他们并不关心。
对于细节的认识、掌控能力直接造成了水平的天渊之别。
以拍照为例子以前人们用傻瓜相机现在人们用iPhone去拍照很快很方便还可以加滤镜。
但是普通人们在不了解什么是光圈、精深、背光等概念的情况下是没有可能成为摄影师的。
即便他们放下iPhone拿起DSLR。
普通人跟摄影师拍摄同样的东西出来的照片也许会差不多但如果深入去比较景深、角度、光线、取景等等等等细节则都会有差别而这些差别积累起来就造成了普通照片与摄影作品的差别。
画家要画好画必然要对画笔、颜料、纸张的特性有深入的了解。
厨师要做好菜必然要了解食材的特性对调味料、厨具等有娴熟的掌控。
ED的“解决问题就好”跟没有下过厨房的千金小姐拿着菜谱使用微波炉做菜没啥区别。
在大厨手里微波炉也可以是神器但 “有的人纵然神刀在手亦无法成为刀中之神。
” 程序员要“拚好积木”那必然需要对积木的种类、材质、特性有深入的了解。
总得对quicksort的实现有认识才能够用好quicksort。
在有的场景下quicksort的性能反而是最差的。
如果不了解就无法去把quicksort用好。
程序开发中有一个著名的 80 / 20 原则。
我想这个原则也可以适用于ED。
程序员只要花20的努力就可以成为一个混日子的ED80的程序员均是如此。
但如果要成为一个优秀的程序员甚至hacker那么需要花多至少4倍的努力。
有什么积木可以用积木本身是怎么做的积木A比积木B好在哪里 这些是需要花大量的时间去了解。
全部都是实在的经验积累没有捷径。
都是.
NET语言C 跟
VB.Net的差别在哪里对于ED他们偶尔也会对这样的问题感兴趣然后他们会去看介绍看比较文章。
。
。
。
但其实这事完全是木有用的。
他们看了别人的介绍以为自己懂的但实际上他们只是在复读而已完全木有懂。
作为一个ED要了解C跟
VB.Net的差别在哪里最好的方式就是花时间去把两种语言都学了。
用这两种语言分别去写个几万行程序然后就懂了。
当某天ED成为Hacker的时候那就反倒可以去看各种介绍看一眼然后瞬间就可以悟了。
这也就是为什么很牛程序员学习新语言可以那么快因为有太多的知识可以复用而这些知识的积累必然是需要通过在实际中无数行的实际编码无数篇的资料阅读中得来的。
没有捷径。
很多初学者或者说编程的伪爱好者他们会热衷于去四处请教大师下载各种经典书籍企图读一本编程圣经然后一夜脱胎换骨。
这是不可能的。
这种伪爱好者永远不可能成事在学习的过程中抱着去“走捷径”的心态本身就已经是入了歧途最终会花更多的时间。
原来Ruby / 现在 Python的一个光头大牛Zed A. Shaw为了表达“没有捷径”这样的观点特意写了本《Learn Python The Hard Way》 http://learnpythonthehardway.org/ 甚至有一个系列http://learncodethehardway.org/ 从长远来看The Hard Way Is Easier。
我完全同意。
作业 1. 列举10个Python Web框架 2. Python有多少种不同的解释器 3. Perl 跟 Python 有什么不同 宅男程序员给老婆的计算机课程之2:怎么看待牛人 这个系列来自一位宅男程序员这个系列是他写给老婆的电脑课程。
以下开始本系列的第3篇——怎么看待牛人。
那么我们该如何识别“看起来很厉害”跟“真的很厉害”的大牛 AD 【51CTO独家特稿】请看这个帖子 http://blog.csdn.net/hu_zhenghui/article/details/7184799 快速浏览即可无需细读浏览过后再继续往下看。
读后的感觉是不是 “虽然不知道在说什么但是看起来很厉害的样子” 整篇文章的关键是在这句 “作者胡某某。
曾任完美时空现更名为完美世界顾问承担互联网方面的部分管理工作。
现在主要精力研究互联网产品设计是Axure授权的高级咨询顾问和高级培训讲师。
” 这也就是我在第一课中提到的“啥事不做整天四处布道名头都很响亮如XX金牌讲师”“Evangelist本身的技术很多是很差的就好像推销员本身是不会做产品开发、不懂技术的。
他们仅仅是会宣传、鼓吹新技术而已”。
碰巧今天看到这个非常有代表性的帖子整个帖子看下来作者毫无海量数据处理实际开发经验纯粹堆砌这些流行技术名词而已。
他没有用过这些技术随便乱丢技术名词整篇似是而非必然的结果就是“虽然不知道在说什么但是看起来很厉害的样子” 学习技术的人如果受了这种“看起来很厉害的样子”的蒙骗会走很多很多弯路。
那么如何识别“看起来很厉害”跟“真的很厉害” 就好像CSDN虽然有些忽悠人的文章但也是有些好的文章在里面如何辨别 1. 看得多了自然会分辨。
研发知识的最好来源之一是技术博客就我自己而言看了博客园自创办伊始前5年的所有首页文章外加常年订阅400博客twitter fo 400余人等。
我这么做主要是因为看得快没有“看不过来”的问题但实际上是个很笨的办法。
要保持最新技术的了解确实是需要看很多blog除此之外我想不出别的途径但这并非必要。
2. 看书 多看最大的好处是了解最新技术而且这是很土的方法。
很多时候并不需要了解很多“最新技术”很多“最新技术”都是属于第一课中所讲的“封装技术”不了解也完全没有关系。
计算机的经典好书并不多好书是公认、经得起时间考验的。
看完这个豆列也就差不多了 http://book.douban.com/doulist/995755/ 完全可以不去理解“最新”的浮躁去上面的豆列挑几本看仔细的看就可以脱胎换骨了。
就我自己而言对我技术影响最大的一本书倒不在上面豆列的20本书中而是 http://book.douban.com/subject/1467587/ 经典书是必须看并且反复看的如果说有什么“捷径”的话看经典书就是最快的捷径了。
这些经典书中的思想是永远不会过时的任何时候看都不会太晚。
给ED看的书也有经典 http://book.douban.com/subject/1229954/ 首先这是本好书而且这本500多页书的传奇在于它讲了无数企业开发的模式但其中的一页半讲述的Active Record Pattern影响了过去5年多6年的Web开发潮流。
3. 写
代码 看
代码 学习编程是一定要去编程的。
书、资料再好光看不练也很容易把自己看成傻子。
在实际项目中写
代码然后看别人是怎么做的。
别人指的往往是
开源项目而不是Google搜来的某个不知名博客中贴的
代码。
哪个
开源项目比较厉害同样是有目共睹的。
做Web开发几乎所有人都会去造ORM的轮子没事就去造一个然后比较自己的版本跟优秀的
开源ORM在API风格、架构设计、实现细节上有何不同。
作者给的作业 1. 找出一篇看上去很厉害的文章。
2. 找一本书开始看作为期中考书目。
宅男程序员给老婆的计算机课程之3:架构比较 这个系列来自一位宅男程序员这个系列是他写给老婆的电脑课程。
以下开始本系列的第4篇——架构比较。
那么究竟要如何做好 「海量事务高速处理系统」 这个方案 AD 【51CTO独家特稿】承接上文12306的案例是蛮不错的题材看过咨询师“很厉害的样子”那么究竟要如何做好 「海量事务高速处理系统」 这个方案 “Hacker”提出了方案 caoz出自百度的超低调牛人 http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html 云风原网易杭州研究中心总监 http://blog.codingnow.com/2012/01/ticket_queue.html 同样的也有另外一些“ED”在讨论方案 林仕鼎百度首席架构师曾任微软亚洲研究院研究员 http://qing.weibo.com/2244218960/85c41050330009xm.html http://weibo.com/2244218960/y0l4S7Y1d 白硕sse上海证券交易所总工程师 http://weibo.com/1922397344/y0jMo9IaD http://weibo.com/1922397344/y0jP6jNRB http://weibo.com/1922397344/y0jUy2rkf 且不论“Hacker”跟“ED”谁更加牛从他们的解决
问题的手法、角度上看就非常不同。
“Hacker”所追求的是解决问题只要是问题被解决怎么解决的无所谓并发流量太大系统处理不过来caoz / 云风两种的方案实质上都是直接去处理源头 - 避免并发。
caoz把高并发的请求直接分流去非主业务服务器主业务服务器无需面临高并发云凤则提出排队系统避免高并发的出现。
而林仕鼎、白硕则是正儿八经的去讨论在有这样高并发的前提下要怎么处理。
哥伦布的鸡蛋。
能够用手去扶住鸡蛋“Hacker”绝对不会犹豫而“ED”则努力的去把鸡蛋竖起来。
注意牛“ED”未必就不懂得可以用手。
这样“Hacker”精神在云风的blog上还有另一个体现屏蔽垃圾评论的验证码。
博客有很多垃圾评论需要屏蔽有很多很多种方式各种神奇的验证码叶贝斯规则过滤等等。
“ED”可以
设计出来很多
方案并实现。
云风肿么做呢 他在评论发表的时候增加了一个项目为了验证您是人类请将六加一的结果阿拉伯数字七填写在下面 “只要能解决问题就采用最简单的设计。
” 这个验证码插件是我自己写的只有一行 perl
代码。
就是判断输入是不是 7 。
结果它很管用。
从后台 log 看拦截了几万条 spam 。
” http://blog.codingnow.com/2012/01/dev_note_7.htmlcomment-42161 注意牛的“Hacker”未必就不懂得做出庞大架构并实现。
“要如何做好「海量事务高速处理
系统」这个方案”本身就可能是个伪命题 「海量事务高速处理系统」这个需求本身可能根本就不存在。
作业 1. 林仕鼎是百度首席架构师吗 2. 看完caoz所有的blog。
宅男程序员给老婆的计算机课程之4:SQL vs NoSQL 这个系列来自一位宅男程序员这个系列是他写给老婆的电脑课程后来经他老婆的建议决定在51CTO这个平台上公开出来与大家分享。
技术宅的你想看看他们究竟是如何令人发指吗以下开始本系列的第5篇——SQL对决NoSQL。
在几乎所有的web应用中数据库都是核心的一环。
AD 【51CTO独家特稿】在几乎所有的
web应用中数据库都是核心的一环。
Web应用往往都是“Database driven”业务、数据都是由数据库完成而前端页面仅仅是
演示、修改数据的一个“壳”。
因此很多web框架都会标榜自己能够兼容多少多少数据库做CRUD多么多么容易。
一般上提到数据库的时候指的都是关系型数据库但关系型数据库并非唯一的一种数据库类型。
关系型数据库一开始便是设计为通用并有ACID支持的。
Atomicity 原子性、 Consistency 一致性、Isolation 隔绝性、Durability 持久性 杀手欧阳盆栽说“每件事都有它的代价”。
上述四个特性都是有代价的。
对于严谨的商业应用如银行、交易系统为求业务的安全他们不得不或者说能够并且愿意付出这些代价。
回到12306后端数据库传说使用的是Oracle而站出来说吐槽12306的行家往往都会提到 redis
mysql 这样的替代。
有些菜鸟“ED”看到这些吐槽就出来喷了说这些行家不懂神马业务安全性的重要这帮做互联网的弱爆了票务是必须使用 Oracle才能搞定云云。
好像还有人专门去喷了Fenng这实在是太讽刺了。
Fenng实际上是Orcale ACE Directorhttp://www.hudong.com/wiki/E586AFE5A4A7E8BE89国内屈指可数的Oracle专家。
很多人特别是弱“ED”、“专家教授”沉寂在自己所在的领域然后就以为“悟”了实际上仅是把自己变成了井底之蛙。
知识的广博、全面性非常重要。
在某个领域通用的东西成熟之后往往就会有专用的解决方案出现。
而专用的解决方案多了之后又会有新的通用解决方案出现。
天下大势分久必合合久必分。
计算机最早有很多专用系统如王安打字机个人电脑通用之后这些专用设备就湮灭了而iPad、手机的涌现则又是专用系统。
是的传统上需要去购买 Orcale、DB2 等巨贵无比的数据库系统去满足业务需求不是因为它们把问题解决到了极致而是因为没有别的选择。
时代已经变了井底之蛙若把Oracle当成是王道那只能被时代淘汰。
关系型数据库作为通用解决方案是非常非常好的它是一把神刀。
但是它有以下问题 ED总是要写烂SQL 首先. 还是那句话有的人纵然神刀在手亦无法成为刀中之神。
关系型数据库提供的SQL能力是高度抽象的封装了无数层的。
写SQL的人太多太多根本不了解SQL背后所执行的事情烂“ED”都是如此。
这甚至造就了一个职业DBA。
DBA去负责数据库微调、优化听起来很高级但实质上就是给滥用SQL的“ED”擦屁股而已。
对于庞大的企业来说管理者是知道大部分ED都弱爆了他不期望也不需要ED去了解数据库他只需要ED去完成最基本的业务功能然后让DBA去给ED擦屁股。
大部分的ED并没有意识到这一点他们拼命去追求方便快捷的“搞定”滥用SQL的各种高级功能甚至他们把分享SQL的复杂使用当成是乐事。
ED所努力的是把自己变笨把活尽可能的都交给神奇的数据库去解决数据库怎么解决的他们不关心这实质上是在削弱自己工作的技术含量自我贬值而已。
工程师如果能够把数据库给用好了哪里还有DBA什么事 DBA所谓的数据库优化往往就是把工程师不负责任.
相关文章
2013-10-20
