请尊重原创，转载请注明来源网站以及原始链接地址
安装jieba分词工具
在下载jieba-0.38.zip
解压后执行：
python setup.py install
试验切词效果
创建testjieba.py文件内容如下：
# coding:utf-8
#!/usr/local/bin/python
import jieba
seg_list = jieba.cut("www.shareditor.com全栈工程师教程、讲述程序猿自己的故事，shareditor涉及机器学习、深度学习、大数据相关知识的系统学习方法及热文推荐")
for str in seg_list:
输出分词结果如下：
shareditor
shareditor
jieba.cut返回的是python的generator结构，遍历后得到分词结果中包括：中文词汇（单字、多字）、英文单词、标点符号
请尊重原创，转载请注明来源网站以及原始链接地址
对批量文档分词
我们之前抓取的微信公众号文章都保存到了mysql的page表里，并且提取纯文本内容保存在了content列中，所以我们从mysql加载content并做切词，之后再利用scikit-learn计算tf-idf值
创建cut_and_cal_tfidf.py，内容如下：
# coding:utf-8
from sklearn.feature_extraction.text import CountVectorizer
from sklearn.feature_extraction.text import TfidfTransformer
import jieba
import MySQLdb
conn = MySQLdb.connect(host="127.0.0.1",user="myuser",passwd="mypasswd",db="mydb",charset="utf8")
cursor = conn.cursor()
sql = "select content from page"
cursor.execute(sql)
for content in cursor.fetchall():
seg_list = jieba.cut(content[0])
for str in seg_list:
line = line + " " + str
corpus.append(line)
conn.commit()
conn.close()
vectorizer=CountVectorizer()
csr_mat = vectorizer.fit_transform(corpus)
transformer=TfidfTransformer()
tfidf=transformer.fit_transform(csr_mat)
word=vectorizer.get_feature_names()
print tfidf.toarray()
执行后输出结果如下：
Building prefix dict from the default dictionary ...
Loading model from cache /var/folders/tq/c0kp5y857x138x5vf8bzxfc80000gp/T/jieba.cache
Loading model cost 0.447 seconds.
Prefix dict has been built succesfully.
先说下代码逻辑：首先加载数据库的content数据，如果对于page数据库表不熟请回过头来看《》，然后用jieba.cut对每一条content做分词，把分词按空格分隔存到二维数组corpus中，最后用scikit-learn计算tfidf，如果对这部分不熟请回过头来看《》
再说下输出的内容，前面几行文字是jieba分词器自动打印的加载词典的信息，下面是整个tf-idf矩阵，因为维度太高，scikit-learn库自动帮我们用...做了省略
官方微信公众号
系列:教你成为全栈工程师(Full Stack Developer)
三十四-基于python的高效中文文本切词
Copyright (C)
| 京ICP备号 | shareditor.com^_^gmail.comAccess denied | www.ruanyifeng.com used Cloudflare to restrict access
Please enable cookies.
What happened?
The owner of this website (www.ruanyifeng.com) has banned your access based on your browser's signature (ea7886-ua98).青青子衿, 悠悠我心, 但为君故, 沉吟至今
全栈工程师到底有什么用
　　最近国内外都在流行一个词叫Full Stack，中文翻译过来叫全栈工程师，也叫全端工程师。微博上很多专业人士都在讨论全端工程师，有赞有毁的。我对全端工程师的定义是：掌握多种技能，并 能利用多种技能独立完成产品的人。打外比方，全栈工程师就是一个能独立盖一幢10层小洋楼的人，而普通工程师，则是可以和一群人盖一幢摩天大楼的人。至于 要掌握哪些技能，我觉得这个要跟从事的行业与技术方向有关，做互联网的和做软件的是不一样的，即使是做互联网的，后端也可以分为很多种技术流派。　　8/2定律在哪都适用，全栈工程师就是掌握20%常用技能的人，但这20%的技能会有80%的几率被用到，剩下那80%不常用的，让我们Google吧。　　有人说，全栈工程师在中国已经很多年了，他们叫站长。这个说话有点靠谱但又不那么靠谱，我自己也做过站长，深知作为一名站长需要掌握很多种技术。不靠谱的是，很多站长其实并没有真正写过多少代码，而是熟练利用一些建站软件来建站。　　全栈工程师的价值　　有人说了，你再牛逼，你懂五种技术，你能干五个人的活吗？全栈工程师并不是说一个人能干几个人的活，而是要从多个方面来看这个问题。　　全局性思维　　现代项目的开发，很少说只用到一两种技术的，特别是移动互联网大潮下。随便一个互联网项目中用到的技术，就会需要用到后端开发、前端开发、界面设 计、产品设计、数据库、各种移动客户端、三屏兼容、restFul API设计和OAuth等等，一些比较前卫的项目，可能会用到Single Page Application、Web Socket、HTML5/CSS3这些技术，还有像第三方开发像微信公众号微博应用等等。　　Web前端也远远不是从前的切个图用个jQuery上个AJAX兼容各种浏览器那么简单了。现代的Web前端，你需要用到模块化开发、多屏兼容、MVC，各种复杂的交互与优化，甚至你需要用到Node.js来协助前端的开发。　　所以说一个现代化的项目，是一个非常复杂的构成，我们需要一个人来掌控全局，他不需要是各种技术的资深专家，但他需要熟悉到各种技术。对于一个团队特别是互联网企业来说，有一个全局性思维的人非常非常重要。　　像如果是我经手的项目，我肯定会注意到网页优化，也会考虑到API来兼容各种客户端，更会考虑到三屏兼容的问题。不会说项目中完全使用AJAX而不顾SEO，也不会为了功能性而忽略访问速度，我会很好的把握这个平衡，因为我知道它们的权重与实现成本。　　沟通成本　　项目越大，沟通成本越高，做过项目管理的人都知道，项目中的人力是1+1&2的，人越多效率越低。因为沟通是需要成本的，不同技术的人各说各话，前端和后端是一定会掐架的。每个人都会为自己的利益而战，毫不为已的人是不存在的。　　而全栈工程师的成本几乎为零，因为各种技术都懂，胸有成竹，一不小心自己就全做了。即使是在团队协作中，与不同技术人员的沟通也会容易得多，你让一 个后端和一个前端去沟通，那完全是鸡同鸭讲，更不用说设计师与后端了。但如果有一个人懂产品懂设计懂前端懂后端，那沟通的结果显然不一样，因为他们讲的， 彼此都能听得懂。　　创业公司　　对于创业公司来说，全端工程师的价值是非常大的，创业公司不可能像大公司一样，各方面的人才都有。所以我们需要一个多面手，各种活都能一肩挑，独挡 多面的万金油。对于创业公司，不可能说DBA前端后端客户端各种人才全都备齐了，很多工作请人又不饱和，不请人又没法做，外包又不放心质量，所以全端工程 师是省钱的一妙招。虽然说全端工程师工资会比一般的工程师会高很多，但综合下来，成本会低很多。　　全栈工程师的困境　　我讲技术有两个发展方向，一种是纵向一种是横向的，横向的是瑞士军刀，纵向的是削铁如泥的干将莫邪。这两个方向都没有对与错，发展到一定程序都会相互溶合，就好比中国佛家禅修的南顿北渐，其实到了最后，渐悟与顿悟是一样的，顿由渐中来。　　如果一个公司不太懂全栈工程师的价值，那么全栈工程师的地位将会很尴尬，说得不好听一点，全栈工程师就是什么都会，都么都不会。曾经有一次面试，对 方问我很基础的问题，我答不上来，我能做出产品，也知道什么是怎么一回事，我也不会犯那些错误，但我就是答不上概念，要考倒我非常容易。所以在应聘面试的时候，有些时候会吃亏，你可能会不如哪些在某一方面钻得很深的人工资拿得高。　　由于经常在各种技术穿梭，我会经常忘记代码的语法和一些API，所以我经常需要去查API甚至查语法，我觉得没有Google我几乎没法工作。这在某些人的眼里，是技术不够的表现。我记的只是一个Key，一个如何找寻答案的索引，而不是全部，人脑不是电脑，我不可能要求我能记下所有的东西。　　有一次面试官问我一个问题，我说我不知道，但我猜大概是如此这般，对方问我，你为什么这么猜，我说凭直觉，对方笑了笑没说话。面试完后我一查，果然和我猜的差不多。没错，我就是凭直觉，但这种直觉和女人的直觉不一样，这种直觉是技术上的直觉，是你过去技术经验累积的一个反射。　　为什么我会成为全栈工程师　　我相信很多全栈型工程师会和我一样，是因为要创业才成为全栈型工程师的。我有一颗创业和做产品的心，而且我又是一个不愿意麻烦别人的人，有些人擅长整合资源，空手套白狼，但我显然不是这种人，所以我只好自己做了。　　在经历过两次孤独的创业之后，我发现我并不是一个适合独立创业的人，所以，我成为了一个全端工程师。我最初是做ASP，后来自己创业写客户端用 Delphi，然后写了三年的ASP.Net，2010年的时候因为公司需要开始做iOS开发。Web前端是一直自己在做，项目中的的 Javascript基本都是我自己在做。　　我热爱写代码，热爱重复发明轮子，热爱新技术，我想这也是我成为一个全栈工程师的重要原因。　　于我自己来说，我觉得全端工程师的乐趣要比一般工程师来得多，因为你知道一个产品的形态，你可以去设计一个产品，你是从全局的视野来做事情，你得到的成就感会更多一些。　　来源：投稿，。
　　除非注明，文章均为原创，转载请以链接形式标明本文地址
　　本文地址：
我相信很多全栈型工程师会和我一样，是因为要创业才成为全栈型工程师的。我有一颗创业和做产品的心，而且我又是一个不愿意麻烦别人的人，有些人擅长整合资源，空手套白狼，但我显然不是这种人，所以我只好自己做了。原来我也是全栈工程师
才看到这篇文章 深有感触 我也算是这类程序员吧
什么方面的技术都有涉猎 最早做web相关的 html css js php asp都会一些 后面又开始做桌面应用程序 主要是winform和wpf 还有做过一点silverlight的东西
有时候需要写一些服务端和数据库 以及网络通信相关的
去年对游戏开发感兴趣 又学了下unity3d 还会点3dmax建模
现在打算把c++学精通 研究游戏引擎和图像相关的知识 唉 这么多技术 还真没一样敢说精通的 好多学过后又忘得差不多了 但不得不说 知识面广 对遇到的很多问题都有很大的帮助 知道怎么去寻找解决办法 这么多年来一直一个人做编程 所有问题都是靠自己找资料解决的 可能大家奇怪我是干啥的 我算是一个自由开发者吧
一直也梦想创业
深表同感，从大公司出来，很清楚各个岗位，各个位置螺丝钉是干嘛的，但是如果要创业，或者去创业团队，那么你必须从运维，DBA,coding,架构师，产品经理，策划各个角色中变换，有时候觉得会很多，有时候觉得又什么都不会好恐惧，如今终于明白，其实什么都懂一点什么都能做的好处只在一点，就是可以随时投入任何新的领域，不会有任何的自我束缚，懂一点不代表不能学精，而在于是否有价值，学精需要的只是时间，而学新东西的能力来源于求知欲和天赋，两者并不冲突也不矛盾。
这篇文章是原创的吗?我跟楼主有太多的相似经历并且文章中最后的心里路程和总结，我都非常赞同
如果我说中国大部分人看到这篇文章都会深有感触的说，自己在公司就是什么都做的全栈工程师，你信吗？Sigma 于
0:32:44 回复有所好转吧。现在公司成规模了，分的比较细了。刚细分，看样子又要合并了...想起一个笑话：我们农村人刚吃上肉，你们城里人又要吃菜了。
.qiankunli
您面试的感觉我真是感同身受，我qq是，不知道有没有机会跟您交流一下
我怎么觉得这里的 全端工程师不就是 不写代码的架构师吗？ Sigma 于
0:35:05 回复我到觉得是个写代码的架构师。
怎么看都忍不住看成金钱工程师我这是多缺钱啊
对这篇文章深有同感，我大概也算四分之三个全栈工程师吧，一直在做UI设计和中前端开发的工作，也会折腾一下数据库，在工作中也还算吃得开，但始终觉得找一份真正契合自己能力和兴趣的工作太难了，还是希望有朝一日可以碰到志同道合的人，一起创业。Sigma 于
0:34:06 回复兄弟牛X，UI设计和数据库兼并，这够跨界的~
啊哈..原文链接却打不开了..404..
.yukon12345
其实这种人适合做项目经理或者CTO不适合做程序员。因为效率太低了。投稿人有点面试错了方向。
潜力股都是被逼出来的啊···
不仅技术好，文采也不错，赞!我还是一名小菜鸟，非常希望向你学习~
不能用一两句话说清楚深表理解，希望网站越来越好。。。
太杂了，无法一两句说清楚， 深表理解
赞助商广告
本站采用创作共用版权协议, 要求署名、非商业用途和相同方式共享. 转载本站内容必须也遵循“署名-非商业用途-相同方式共享”的创作共用协议.&&5873 阅读
谨以此文献给每一个为成为奋斗的人。
技术在过去的几十年里进步很快，也将在未来的几十年里发展得更快。今天技术的门槛下降得越来越快，原本需要一个团队做出来的Web应用，现在只需要一两个人就可以了。
同时，由于公司组织结构的变迁，以及到变化的适应度，也决定了赋予每个人的职责将会越来越多。尽管我们看到工厂化生产带来的优势，但是我们也看到了精益思想带来的变革。正是这种变革让越来越多的专家走向全栈，让组织内部有更好的交流。
你还将看到专家和全栈的两种不同的学习模式，以及全栈工程师的未来。
技术的革新史
从开始的CGI到MVC模式，再到前后端分离的架构模式，都在不断地降低技术的门槛。而这些门槛的降低，已经足以让一两个人来完成大部分的工作了。
二十年前的网站以静态的形式出现，这样的网站并不需要太多的人去维护、管理。接着，人们发明了CGI(通用网关接口，英语：Common Gateway Interface)来实现动态的网站。下图是一个早期网站的架构图：
当时这种网站的URL类似于： https://www.phodal.com/cgi-bin/getblog
(PS：这个链接是为了讲解而存在的，并没有真实存在。)
用户访问上面的网页的时候就会访问，cgi-bin的路径下对应的getblog脚本。你可以用Shell返回这个网页：
echo Content-type: text/plain
echo hello,world
Blabla，各种代码混乱地夹杂在一起。不得不说一句：这样的代码在2012年，我也看了有一些。简单地来说，这个时代的代码结构就是这样的：
这简直就是一场恶梦。不过，在今天好似那些PHP新手也是这样写代码的。
好了，这时候我们就可以讨论讨论MVC模式了。
我有理由相信Martin Fowler的《企业应用架构模式》在当时一定非常受欢迎。代码从上面的耦合状态变成了：
相似大家也已经对这样的架构很熟悉了，我们就不多解释了。如果你还不是非常了解的话，可以看看这本书后面的部分。
后台服务化与前端一致化架构
在今天看来，我们可以看到如下图所示的架构：
后台在不知不觉中已经被服务化了，即只提供API接口和服务。前端在这时已经尽量地和APP端在结合，使得他们可以保持一致。
软件开发的核心难题：沟通
软件开发在过去的几十年里都是大公司的专利，小公司根本没有足够的能力去做这样的事。在计算机发明后的几十年里，开发软件是大公司才能做得起的。一般的非技术公司无法定制自己的软件系统，只能去购买现有的软件。而随着技术成本的下降，到了今天一般的小公司也可以雇佣一两个人来做同样的事。这样的演进过程还真是有意思：
在这其中的每一个过程实质上都是为了解决沟通的问题。从瀑布到敏捷是为了解决组织内沟通的问题，从敏捷到精益不仅仅优化了组织内的沟通问题，还强化了与外部的关系。换句话说，精益结合了一部分的互联网思维。
在最开始的时候，我们预先设计好我们的功能，然后编码，在适当的时候发布我们的软件：
然而这种开发方式很难应对市场的变化——当我们花费了几年的时间开发出了一个软件，而这个软件是几年前人们才需要的。同时，由于软件开发本身的复杂度的限制，复制的系统在后期需要大量的系统集成工作。这样的集成工作可能要花费上大量的时间——几星期、几个月。
当人们意识到这个问题的时候，开始改进工作流程。出现了敏捷软件开发，这可以解释为什么产品经理会经常改需求。如果一个功能本身是没必要出现的话，那么为什么要花功夫去开发。但是如果一个功能在设计的初期就没有好好设计，那么改需求也是必然的。
现有的互联网公司的工作流程和敏捷软件开发在很多部分上是相似的，都有迭代、分析等等的过程：
但是据我的所知：国内的多数互联网公司是不写测试的、没有Code Review等等。当然，这也不是一篇关于如何实践敏捷的文章。敏捷与瀑布式开发在很大的区别就是：沟通问题。传统的软件开发在调研完毕后就是分析、开发等等。而敏捷开发则会强调这个过程中的沟通问题：
在整个过程中都不断地强调沟通问题，然而这时还存在一个问题：组织结构本身的问题。这样的组织结构，如下图所示：
如果市场部门/产品经理没有与研发团队坐一起来分析问题，那么问题就多了。当一个需求在实现的过程中遇到问题，到底是哪个部门的问题？
同样的如果我们的研发部门是这样子的结构：
那么在研发、上线的过程中仍然会遇到各种的沟通问题。
现在，让我们回过头来看看大公司的专家与小公司的全栈。
大公司的专家与小公司的全栈
如果你经常看一些关于全栈和专家的技术文章的时候，你就会发现不同的人在强调不同的方向。大公司的文章喜欢强调成为某个领域的专家，小公司喜欢小而美的团队——全栈工程师。
如我们所见的：大公司和小公司都在解决不同类型的问题。大公司要解决性能问题，小公司都活下去需要依赖于近乎全能的人。并且，大公司和小公司都在加班。如果从这种意义上来说，我们可以发现其实大公司是在剥削劳动力。
我们所见到的那些关于技术人员应该成为专家的文章，多数是已经成为某个技术领域里的专家写的文章。并且我们可以发现很有意思的一点是：他们都是管理者。管理者出于招聘的动机，因此更需要细分领域的专家来帮助他们解决问题。
相似的，我们所看到的那些关于成为全栈工程师的文章，多数是初创公司的CTO写的。而这些初创公司的CTO也多数是全栈工程师，他们需要招聘全栈工程师来帮助他们解决问题。
两种不同的学习模型
而不知你是否也注意到一点：专家们也在强调“一专多长”。因为单纯依靠于一个领域的技术而存在的专家已经很少了，技术专家们不得不依据于公司的需求去开拓不同的领域。毕竟“公司是指全部资本由股东出资构成，以营利为目的而依法设立的一种企业组织形式；”，管理人们假设技术本身是相通的，既然你在技术领域里有相当高的长板，那么进入一个新的技术也不是一件难的事。
作为一个技术人员，我们是这个领域中的某个子领域专家。而作为这样一个专家，我们要扩展向另外一个领域的学习也不是一件很难的事。借鉴于我们先前的学习经验，我们可以很快的掌握这个新子域的知识。如我们所见，我们可以很快地补齐图中的短板：
在近来的探索中发现有一点非常有意思：如果依赖于20/80法则的话，那么成为专家和全栈的学习时间是相当的。在最开始的时候，我们要在我们的全栈工程和专家都在某个技术领域达到80分的水平。
那么专家，还需要80%的时间去深入这个技术领域。而全栈工程师，则可以依赖于这80%的时候去开拓四个新的领域：
尽管理论上是如此，但是专家存在跨领域的学习障碍——套用现有模式。而全栈也存在学习障碍——如何成为专家，但是懂得如何学习新的领域。
解决问题的思路：不同的方式
有意思的是——成为专家还是成为全栈，取决于人的天性，这也是两种不同的性格决定的。成为管理者还是技术人员看上去就像一种简单的划分，而在技术人员里成为专家还是全栈就是另外一种划分。这取决于人们对于一个问题的思考方式：这件事情是借由外部来解决，还是由内部解决。下面这张图刚好可以表达我的想法：
而这种思维依据于不同的事情可能会发生一些差异，但是总体上来说是相似的。当遇到一个需要创轮子的问题时，我们就会看到两种不同的方式。
对于全栈工程师来说，他们喜欢依赖于外部的思维，用于产生颠覆式思维。如Angular.js这样的框架便是例子，前端结合后端开发语言Java的思维而产生。而专家则依赖于内部的条件，创造出不一样的适应式创新。如之前流行的Backbone框架，适应当时的情况而产生。
全栈工程师的未来：无栈
全栈工程师本身不应该仅仅局限于前端和后台的开发，而可以尝试去开拓更广泛的领域——因为全栈本身是依赖于工程师本身的学习能力，正是这种优秀的学习能力可以让他们可以接触更广泛的知识。
全栈的短板
如果你也尝试过面试过全栈工程师，你会怎么去面试他们呢？把你知道的所有的不同领域的问题都拿出来问一遍。是的，这就是那些招聘全栈工程师的公司会问你的问题。
人们以为全栈工程师什么都会，这是一个明显的误区——然而要改变这个误区很难。最后，导致的结果是大家觉得全栈工程师的水平也就那样。换句来说，人们根本不知道什么是全栈工程师。在平时的工作里，你的队伍都知道你在不同领域有丰富的知识。而在那些不了解你的人的印象里，就是猜测你什么都会。
因此，这就会变成一个骂名，也是一个在目前看来很难改变的问题。在这方面只能尽可能地去了解一些通用的问题，并不能去了解所有的问题。在一次被面试全栈工程师的过程中，有一个面试官准备了几个不同语言（Javascript、Java、Python、Ruby)的问题来问我，我只想说Ciao——意大利语：你好！
除了这个问题——人们不了解什么是全栈工程师。还有一个问题，就是刚才我们说的成为专家的老大难问题。
让我毫不犹豫地选择当全栈工程师有两个原因：
这个世界充满了未解的迷，但是我只想解开我感兴趣的部分。
没有探索，哪来的真爱？你都没有探索过世界，你就说这是你最喜欢的领域。
当我第一次看到全栈工程师这个名字的时候，我发现我已然是一个全栈工程师。因为我的学习路线比较独特：
中小学：编程语言 -& 高中：操作系统、内核、游戏编程 -& 大学： 硬件、Web开发 -& 工作：后端 + 前端
而在当时我对SEO非常感兴趣，我发现这分析和Marketing似乎做得还可以。然后便往Growth Hacking发展了：
而这就是全栈学习带来的优势，学过的东西多，学习能力就变强。学习能力往上提的同时，你就更容易进入一个新的领域。
《精益企业： 高效能组织如何规模化创新》
《企业应用架构模式》
《敏捷软件开发》
《技术的本质》
更多内容欢迎关注我的微信公众号(搜索Phodal)：
Phoenix or dragon as life.
我是黄峰达，1991年出生于闽南，双子座，毕业于西安文理学院。
农村长大，热爱大自然，热爱生活。和哈比特人一样喜欢土地里长出来的东西。
是一个文艺控。喜欢读书，喜欢纸的质感，喜欢用笔铭刻记忆和思想。
是一个设计控，一个DIY爱好者。喜欢自行设计一些小东西，相比理论而言更喜欢动手实践，比如拆装自己的手机、电脑等。
最喜欢折腾与计算机相关的东西：SEO、前端开发、硬件相关(如：Raspberry Pi,51,Arduino,OpenWRT,uCOS...)。
在编程的路上已经走了较长一段，但始终相信前路更长更加广阔。}