songron · whbjob · Aug 2, 2016 · Aug 2, 2016 · Aug 2, 2016 · Aug 2, 2016
diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-WeBlog
+eBlog
 ======
 
 A simple blog system based on [Flask](http://flask.pocoo.org/)
@@ -11,10 +11,19 @@ Quick Start
 $ git clone https://github.com/ghostrong/weblog.git
 $ cd weblog
 $ pip install -r requirements.txt
-$ python run.py
+$ python create_db.py
+$ python run.py (also you can run shell with: sh start.sh)
 ````
 
-Now, visit `http://127.0.0.1:8888` in a browser.
+Now, visit `http://127.0.0.1:5000` in a browser.
+
+Database with MySQL
+-------------------
+If you use MySQL ,create weblog database before ```python create_db.py```:
+
+* Set **SQLALCHEMY_DATABASE_URI** in config.py
+* Login MySQL and execute script ```create schema weblog charset utf8;```
+* python create_db.py
 
 Requirements
 ------------
@@ -131,12 +140,25 @@ You should provide the markdown file(either file-path or raw-url), the target ap
 **Anyone who know the token could publish articles to your blog system, so keep it secret!!**
 
 After starting the web server locally, you can publish an article like this:
+*You should be change your token in config.py file.
 
 ````
-$ python publish.py -a http://127.0.0.1:8888/publish -p example.md
+$ python publish.py -a http://127.0.0.1:5000/publish -p example.md -t your_token_in_config
 ````
 
+Deploy application
+------------------
+gunicorn -w 4 -b 0.0.0.0:5000 run:app
 
+Delete blogs
+------------
+```
+from weblog import database,models
+db = database.db
+articles=models.Article
+articles.query.filter_by(id=1).delete()
+db.session.commit()
+```
 Features
 --------
 * Writing blogs in Markdown and YAML

diff --git a/Why_ETL_difficult.md b/Why_ETL_difficult.md
@@ -0,0 +1,48 @@
+---
+title: 为什么ETL任务困难
+summary:
+  自传统数据仓库理论形成,ETL 占据其中70%工作量就已经成为常识。可即便经过几十年到今天,各个平台的 ETL 普遍还在初级阶段,这背后深层次的原因是什么?
+tags:
+  - BI
+  - ETL
+  - DW
+  - 大数据
+...
+
+###为什么 ETL 很困难?
+####工具繁多
+从 DataStage到Kettle, ETL 工具覆盖了商业化领域和开源领域, 价格从几十万到免费,起码有几十种选择。
+
+有人要说了,选择多不是一件好事么?如果再早几年,我会同意这是好事,可到现在,我要说 NO!
+
+前面关于决策思维的博文提到一个论点:相比于普通人做出决策,专家是会直接给一种可行方案还是罗列众多方案类比优劣?
+
+答案是前者,也是我反对选择众多是好事这一论点的依据之一。
+
+#####那么选择多有什么坏处?
+* 基础方案混杂。各公司方案不同,甚至一个公司 ETL 环节也采用不同工具及架构,人才无法公用,维护成本高。
+* 数据项目失败案例远多于成功案例, 项目选型越复杂成功概率越低。大量公司做 BI、做大数据,甚至在没有人懂的情况下招人开工!事实上在数据领域,熟手都清楚一个现象,没有成功案例的人很难做成数据项目。很残忍的现实,但也让那些盲目投入资源跟风做项目的公司考虑冷静下来了。
+* 抬高实施门槛。现在大家都想做数据,进入大数据领域,尤其是有很多不具备该领域经验的公司想要做。那么实施前首先就是选型了,如果从三个产品选一个来做还可行的话,那么要从三十个产品中选型,这个工作本身就阻碍了数据项目的开展!
+
+####GUI工具
+说到这里反对的朋友更多了,GUI 所见即所得,降低使用门槛,好处一页都写不完,作为一名数据领域从业者,我决然反对,自己都能感觉到火药味。
+为了论证我的观点,这里要罗列ETL领域那些GUI的罪证了。
+#####ETL 工具的六大问题
+* 工具太大了,卡卡卡!我不是说 SSIS 之类,也不是说 Kettle 相关,我说的是他们所有人……
+* 好用的太贵, 便宜的不好用!
+* 组件式的拖拉开发,性能真的没法起来!尤其是那些依靠组件解决数据变化提取的兄弟们,你们想多了。
+* 我需要一包厕纸而已,你非要给我整个超市。在我蹲之前非得找遍整个超市!大家对比下里面的功能自己使用的比率。
+* 说 GUI 简单好用的,我强烈反对。GUI 好调试么?映射过程报错了大家要怎么办?检查源检查目标也就算了,连映射环节都要排查。除了自己设定的格式类型,还要考虑工具环节自己的转换类型,这不是增加负担么?
+* 部署,我都不想说部署了。一千个任务下来,ETL 工具别谈部署了!这时候有同学开始研究调度,有些关注数据质量,任务数量起来,想什么都是多的,保佑这混乱情况别出岔子就阿弥陀佛了。
+
+####ETL 工具阻碍了设计
+* 直接用工具拉数据的项目,认真找找有没有架构设计,有没有项目文档,有没有扩展性考虑,性能考虑?或者简单点,这项目换人可能接手下来么?
+* 数据项目是团队项目,ETL 工具是个人化工具。如果多个成员不能无缝接替工作,对不起,我认为这不是数据项目。哦不对,不算是一个项目。
+* 组件报错是工具问题,转换异常跟自己没关系。工具的 bug 和我真没关系,我项目做得好好的,ETL 工具崩溃了管我什么事?遇到这种情况不说我也知道做法,崩溃了再起来跑一跑嘛,运气好数据就跑出来了。至于数据质量管理是什么这样的问题,就别问出来了。
+
+[这里有关于 ETL 的一切](http://www.infotrim.cn)  
+
+[这里有直接上手的 ETL 方案](http://www.infotrim.cn)  
+
+[这里有十年数据解决方案的结晶](http://www.infotrim.cn)  
+
diff --git a/about.md b/about.md
@@ -1,16 +1,20 @@
 About Me
 ========
+提供专业 *BI* 解决方案。
 
-My name is Xiaosong Rong. I am interested in search engine, data mining, crawler, web development, and many other topics. I am now living in Beijing, China. I just graduated from Peking University.
+团队编制不足能否做 BI 系统? 能!
 
-If you want to know more about me, you can reach me by:
+没有服务器集群能否建立仓库? 能! 至少单机几十 TB 没问题!
 
-* [email](mailto:[email protected])
-* [github](https://github.com/ghostrong/)
-* [linkedin](https://cn.linkedin.com/pub/xiaosong-rong/45/34/9b5)
-* [weibo](weibo.com/rongxs)
+技术积累不足能否开展 BI 项目? 能!
 
-By the way, the nicknames I used include **cedar**, **cedarrong**, **ghostrong**, **马孔多**, and **Rong**  :-)
+项目中有数千个 ETL 需要整合, 能否只用一两个人完成? 能!
+
+跑跑卡丁车的数仓方案就是例证: 成千上万的 ETL、每日数千个计算任务、600+报表输出、单表承载数十亿容量,加上完整的分析系统输出!
+
+* Wechat: todouwang
+* Email: [email protected]
+* [微信二维码](static/wechat_card.jpg)
 
 
 About this Website

diff --git a/config.py b/config.py
@@ -1,11 +1,12 @@
 #coding=utf8
 
-SQLALCHEMY_DATABASE_URI = 'sqlite:////tmp/test.db'
+#SQLALCHEMY_DATABASE_URI = 'sqlite:////tmp/test.db'
+SQLALCHEMY_DATABASE_URI = 'mysql+mysqlconnector://blog_user:morningdb.@localhost:3306/weblog'
 
-AUTHOR = 'Rong'
+AUTHOR = 'Infotrim'
 
 # this is useful for submitting markdow files
 # when publish new articles
 TIME_FORMAT = '%Y-%m-%d %H:%M:%S'
 
-TOKEN = '123456'
+TOKEN = 'morningdb.'
diff --git a/decision.md b/decision.md
@@ -0,0 +1,16 @@
+---
+title: 决策思维
+summary:
+  我们每个人都被决策所包围，无论是生活中的衣食住行还是工作中的升职加薪，决策思维影响着我们在社会中所  处的位置。我们的决策是否足够理性，是否可以训练？聪明人的决策是否更加高明？一个普通人是否存在通往金字塔顶端的可能性？
+tags:
+  - 决策论
+  - 思维方式
+...
+
+###决策效率
+我们一直做决策系统，那么什么是决策？你买一件上衣，结果在购物网站逛了大半天，最终买了上衣、裤子、  还有一条皮带。在这个过程中，你产生购买上衣的想法是决策么？你逛购物网站是决策么？你买的裤子以及皮带是  否是决策？
+从整个决策流程来看，是否有一个明显的效率问题？买一件衣服需要一个时间单位，但预期之外的裤子、皮带需要两个时间单位。你投入了三个单位时间，收获了三件商品。那么我想问这三个时间单位的价值对等么？或者说购买三件商品所消耗你的资源有差别么？这两个问题回答出来之后，就归结为一个问题：你的决策效率如何？
+对于决策过程来讲，我们是否可以定义出一个“决策率”来衡量决策效率？如果可行，那这个指标又该如何衡量？
+###新手和专家的决策区别
+看到这里，大家停下来考虑下，是不是会觉得新手只能选择一种决策方案并判断可行性？专家呢？是不是会有很多方案比较优劣？通过研究分析，实际情况并不是这样，实际上专家决策往往都是选择一种可行方案，而新手才会关注对比多种方案优劣。
+为什么会是这样的结论？我认为这是经验决策的一个合理解释，专家具备足够的经验，瞬间给出直接可行方案。而新手经验不足以支撑快速决策，才会将精力放在多种方案研究，比较其优劣上面。
diff --git a/decision_about_big_data.md b/decision_about_big_data.md
@@ -0,0 +1,56 @@
+---
+title: 从大数据负责人招聘看决策思维
+summary:
+  大数据被各大企业奉为灵丹妙药,寄予厚望地想要让数据告诉决策者企业的未来在哪里,而大数据负责人作为项目核心要素,企业会提出怎么样的要求?笔者将十余家大数据负责人沟通经验结合决策思维在此梳理分享。
+tags:
+  - 决策思维
+  - 大数据负责人要求
+...
+
+###决策是非理性的
+我们受到的教育是要理性思考,理性决策,信奉理性至上的思维模式。可惜的是现实并非如此,绝大多数的决策都是采用自然主义决策方式,而情景模拟又是其主流方法。对此感兴趣的朋友建议查看亚马逊近期榜单作品《如何做出正确决策:直击决策真相》了解更多。  
+
+简而言之,无论是紧迫条件的救火队员还是军事要务的重大决定,决策的真相都如同我们前面介绍的方式:脑海中假设一条可行道路,一步步证明它是可行的。  
+
+说到专家和普通决策的区别,大家还是要注意这个真相:专家决策都是迅速定下一条可行方案,而非拿出多套方案理性对比!
+###大数据负责人的要求是什么
+1.  有成功大数据经验
+
+大家要注意,我举证论据,至少都是讲三点的,可我这里只给出一条。
+经常查看此类招聘的朋友很容易看出来,另外两点因素是职业素养和对大数据生态的理解,我完全同意这个看法,但此处认为和我举证这一点比,其他的都完全不是问题。
+
+####为什么要有成功大数据经验?
+  1. 因为招聘你去的地方通常是没有成功经验的,不然要你去干吗?  
+  2. 具备成功大数据经验的人真的很少! 这里大家应该慎重考虑下,基于这个观点,跳槽、换团队是大忌。为什么?因为如果你已经有成功经验,机会根本不是问题。而你不幸没有成功经验,跳槽、换团队都不能解决你成功经验的问题。  
+  3. 大数据项目的成功,不会只有一个人,但会取决于核心人物。好好珍惜现有团队,做成项目,并且不要说不懂其他同事的工作。大数据本来就是融合型工作,你永远只会自己做的一块,就不要费时间争取负责人的角色了。  
+
+####为什么工作素养和 hadoop 等生态理解不重要?
+  这个问题起码要说三点:  
+
+  1. 工作素养大部分都能做得很好,极少成为个人瓶颈不是吗?难道不是吗?  
+
+  2. 面试要求的 hadoop、spark、storm……这些不是招聘者的本质要求,招聘你去的真正需求是能将项目做出来,做成功。至于这些细节技术方案,面试者有多少人懂得?再说了,开源系统版本迭代那么快,完全依靠这些方案要踩多少坑招聘者哪里知道?不仅如此,作为负责人是要规避让企业踩坑才合格!  
+
+  3. 我看到好多人转向大数据,学 python 又学 R, 学 Java 又学 Scala, 学数据库又学数据仓库。这样的做法可行吗? 真心奉劝停下来冷静思考下!  
+
+大数据是团队项目,不是单兵作战! 再说了,等你把所有学完, 企业等的花儿都谢了好么? 随便学一个感兴趣的, 找到工作再一步步深入, 各种大会、各种社区适合有经验的人、有方法的人,这些场景只要记住大家推荐的书籍回来好好学任务就完成了。
+
+###补偿机制的使用
+我们常说:"打一个耳光给一个苹果",是不是耳光就没那么疼了?   
+
+这不止是一个心理现象,在面试大数据负责人这样重要岗位时一样可以用于决策。 
+
+通常我们做出决策时,会在自己优势领域选定方案持续推进。要么成功达到目标,要么走不下去调转方向,可最终都是能完成任务的。    
+
+那么为什么就算是专家也会遇到放弃方案跳转方向的情况,一方面是我们的确会遇到各种未知的问题,另一个更重要的方面就是:我们每个人在多个维度都有优点,切记!  
+
+我们总看到话术中说:"同学你工作做得不好,但你在工作过程中表现出来的沟通能力还是很强的。"类似的情况数不胜数,与其说是心理补偿机制,倒不如说展示出我们每个人其实都不只有一个优势领域! 
+
+那么这和大数据负责人招聘又有什么关系呢?  
+
+  1. 大数据负责人也是人,有长处也有短板。就算平时勤快对团队工作都了解, 涉及到每一块深度领域细节所知也是很有限的。  
+  2. 有限的人遇到无知的需求。这里用词不太合适,但其实很多企业寻找人才时对这个领域是一片空白的。那么提出的要求自然是互联网上随处能搜集到的岗位需求模板。虽然大家都理解每个公司、每个团队做数据都有些不同之处,但对于完全不了解行情的公司只能然并卵。除了网上找模板我也想不出更好的办法了。  
+  3. 有限的人要用优点补充缺点。招聘的时候发现你可视化不强,那应该展示自己数据仓库的优势了,如果发现你 hadoop 不熟,你是时候分享对 storm 的研究成果了。  
+大家要考虑清楚团队项目中的个人定位, 一味地追求个人什么都会,项目发展会很有限,企业也会很不放心啊。  
+
+[更多有用信息](http://www.infotrim.cn)  
diff --git a/files/Why_ETL_difficult.md b/files/Why_ETL_difficult.md
@@ -0,0 +1,48 @@
+---
+title: 为什么ETL任务困难
+summary:
+  自传统数据仓库理论形成,ETL 占据其中70%工作量就已经成为常识。可即便经过几十年到今天,各个平台的 ETL 普遍还在初级阶段,这背后深层次的原因是什么?
+tags:
+  - BI
+  - ETL
+  - DW
+  - 大数据
+...
+
+###为什么 ETL 很困难?
+####工具繁多
+从 DataStage到Kettle, ETL 工具覆盖了商业化领域和开源领域, 价格从几十万到免费,起码有几十种选择。
+
+有人要说了,选择多不是一件好事么?如果再早几年,我会同意这是好事,可到现在,我要说 NO!
+
+前面关于决策思维的博文提到一个论点:相比于普通人做出决策,专家是会直接给一种可行方案还是罗列众多方案类比优劣?
+
+答案是前者,也是我反对选择众多是好事这一论点的依据之一。
+
+#####那么选择多有什么坏处?
+* 基础方案混杂。各公司方案不同,甚至一个公司 ETL 环节也采用不同工具及架构,人才无法公用,维护成本高。
+* 数据项目失败案例远多于成功案例, 项目选型越复杂成功概率越低。大量公司做 BI、做大数据,甚至在没有人懂的情况下招人开工!事实上在数据领域,熟手都清楚一个现象,没有成功案例的人很难做成数据项目。很残忍的现实,但也让那些盲目投入资源跟风做项目的公司考虑冷静下来了。
+* 抬高实施门槛。现在大家都想做数据,进入大数据领域,尤其是有很多不具备该领域经验的公司想要做。那么实施前首先就是选型了,如果从三个产品选一个来做还可行的话,那么要从三十个产品中选型,这个工作本身就阻碍了数据项目的开展!
+
+####GUI工具
+说到这里反对的朋友更多了,GUI 所见即所得,降低使用门槛,好处一页都写不完,作为一名数据领域从业者,我决然反对,自己都能感觉到火药味。
+为了论证我的观点,这里要罗列ETL领域那些GUI的罪证了。
+#####ETL 工具的六大问题
+* 工具太大了,卡卡卡!我不是说 SSIS 之类,也不是说 Kettle 相关,我说的是他们所有人……
+* 好用的太贵, 便宜的不好用!
+* 组件式的拖拉开发,性能真的没法起来!尤其是那些依靠组件解决数据变化提取的兄弟们,你们想多了。
+* 我需要一包厕纸而已,你非要给我整个超市。在我蹲之前非得找遍整个超市!大家对比下里面的功能自己使用的比率。
+* 说 GUI 简单好用的,我强烈反对。GUI 好调试么?映射过程报错了大家要怎么办?检查源检查目标也就算了,连映射环节都要排查。除了自己设定的格式类型,还要考虑工具环节自己的转换类型,这不是增加负担么?
+* 部署,我都不想说部署了。一千个任务下来,ETL 工具别谈部署了!这时候有同学开始研究调度,有些关注数据质量,任务数量起来,想什么都是多的,保佑这混乱情况别出岔子就阿弥陀佛了。
+
+####ETL 工具阻碍了设计
+* 直接用工具拉数据的项目,认真找找有没有架构设计,有没有项目文档,有没有扩展性考虑,性能考虑?或者简单点,这项目换人可能接手下来么?
+* 数据项目是团队项目,ETL 工具是个人化工具。如果多个成员不能无缝接替工作,对不起,我认为这不是数据项目。哦不对,不算是一个项目。
+* 组件报错是工具问题,转换异常跟自己没关系。工具的 bug 和我真没关系,我项目做得好好的,ETL 工具崩溃了管我什么事?遇到这种情况不说我也知道做法,崩溃了再起来跑一跑嘛,运气好数据就跑出来了。至于数据质量管理是什么这样的问题,就别问出来了。
+
+[这里有关于 ETL 的一切](http://www.infotrim.cn)  
+
+[这里有直接上手的 ETL 方案](http://www.infotrim.cn)  
+
+[这里有十年数据解决方案的结晶](http://www.infotrim.cn)  
+