IT牛人博客聚合

+0 一些前端框架的比较（下）——Ember.js和React

四火发于 2016年12月26日 04:44 | 点击: 498 | 展开摘要

这是前端框架比较和吐槽的第二篇。

Ember.js

Ember.js的extend的写法很类似于JQuery或者是Backbone.js，创建Application，然后在它下面创建相应的Model（Object）、Controller、Router、View和Template，这些都是非常类似的。但是它更为先进的地方在于，一些重复的样板代码，比如给template注入上下文并渲染，如果命名按照CoC的原则正确完成的话，都由框架自动完成，这就省去不少体力活。CoC还体现在

查看全文: http://www.udpwork.com/item/16035.html

---

+0 一些前端框架的比较（上）——GWT、AngularJS和Backbone.js

Tag: JavaScript | Recommended | AngularJS | Backbone | GWT

四火发于 2016年12月23日 08:11 | 点击: 608 | 展开摘要

和一些前端框架打过交道，想起来这也是技术选型中经常面对的内容。我把我的经验、思考、感受，甚至是吐槽，记录在这里，有些零散，并且更多的是个人的感悟。而且由于技术所限，可能部分内容不够深入，或者不甚客观。当然，网上有很多分析对比，视角可能更为全面和系统。如果你在技术选型，或者在考虑要学习使用哪一款MVC／MVP／MVVM框架的时候，此文能够给你有价值的信息，就更棒了。如果你觉得我哪些部分说得不正确，或者需要补充，也烦请告知。

需要预先说明的是，这篇文章不是教程，因此如果你对其中

查看全文: http://www.udpwork.com/item/16027.html

^..^

+0 技术光谱

Tag: Learning & Thinking | Recommended | 比较

四火发于 2016年12月22日 02:45 | 点击: 650 | 展开摘要

最近在做一些技术选型的工作，忽然想到，可以把接触过的一些技术通过“相互比较”的方式整理起来，知其利弊，也把知识内容线索化。这其中大部分是我使用过的，但是也有一些是因为某些原因而学习过的。有一些文章因为时间的关系，比较起来现在我的看法已经发生了改变，但我还是原封不动保留着。对于想做但还没有完成的部分，我会放置一个“TODO”的标记。这个列表会不断更新。

编程：

编程语言：《从Java和JavaScript来学习Haskell和Groovy》

编程范型：《编程范型详解》

查看全文: http://www.udpwork.com/item/16025.html

---

+0 工作流系统的设计

四火发于 2016年08月19日 15:28 | 点击: 586 | 展开摘要

几年前曾经写过一点点对于缓存框架设计的体会，这大半年和工作流系统打交道颇为丰富，因此想总结一点关于工作流系统的设计。

首先，明确工作流（workflow）系统的定义。维基百科上有极其简单的介绍。我记得以前在文章里面说过，作为大公司里面的小team，为了做一些有趣的东西，从而更好的招人，通常有几个众人皆知的突破口：比如一个更符合业务需求的storage，再比如一个自定义的工作流系统。在Amazon内部，我接触过好多个workflow，而且大多以Amazon SWF为原型（当时

查看全文: http://www.udpwork.com/item/15753.html

^..^

+0 Spark的性能调优

Tag: Distributed System | Recommended | Spark | 性能

四火发于 2015年12月21日 14:55 | 点击: 673 | 展开摘要

下面这些关于Spark的性能调优项，有的是来自官方的，有的是来自别的的工程师，有的则是我自己总结的。

基本概念和原则

首先，要搞清楚Spark的几个基本概念和原则，否则系统的性能调优无从谈起：

每一台host上面可以并行N个worker，每一个worker下面可以并行M个executor，task们会被分配到executor上面去执行。Stage指的是一组并行运行的task，stage内部是不能出现shuffle的，因为shuffle的就像篱笆一样阻止了并行task的运

查看全文: http://www.udpwork.com/item/15067.html

---

+0 七年工作，几个故事

Tag: Career | Recommended | 亚马逊 | 加班 | 华为 | 找工作 | 故事 | 离职

四火发于 2015年08月22日 12:42 | 点击: 860 | 展开摘要

从毕业工作到现在，已经有七个年头，年头虽然不久，但是回过头来看看那些经历的好的坏的有趣的扯淡的事情，还是有很多东西可以总结。所有人都会或多或少走弯路，本来成长就是这样一个过程，有时候想起来会感叹，有时候会唏嘘，有时候会一笑而过。我的前一半时间是在华为，这段时间留给我很多回忆（比如这几个瞬间）；后半时间在亚马逊，也给了我不少感慨的机会。下面这些故事都是我经历的真真实实的事，有的事情已经过去好久，但我不想把它永远尘封。也许你和我在某些方面，会有共同的体会。

在我说这些故事

查看全文: http://www.udpwork.com/item/14531.html

---

+0 从Java和JavaScript来学习Haskell和Groovy（汇总）

四火发于 2015年07月24日 08:09 | 点击: 743 | 展开摘要

这是这个系列的最后一篇，从编程范型的角度概览，前面几篇的链接在文章后半部分有汇总。

我在之前已经介绍过编程范型的概念，而事实上，我们到现在为止，纠结在这四门迥异的语言上面，浅看是各种语言特性，深看就是编程范型和思维方法。

下面这张“神图”来自于这里，可以说是对于范型和语言归类的概览，从左往右从更强的声明式向着更弱的声明式发展；依据状态分为Unnamed state（串行或并发，包含逻辑式和函数式这几种分类）、Nondet. state（所谓的不确定性状态）和Named s

查看全文: http://www.udpwork.com/item/14427.html

---

+0 LeetCode算法题目解答汇总

Tag: Algorithm & Data Structure | Recommended | LeetCode

四火发于 2015年01月19日 22:12 | 点击: 20370 | 展开摘要

只要不是特别忙或者特别不方便，最近一直保持着每天做几道算法题的规律，到后来随着难度的增加，每天做的题目越来越少。我的初衷就是练习，因为一方面我本身算法基础并不好，再一方面是因为工作以后传统意义上所谓算法的东西接触还是太少。为了题目查找方便起见，我把之前几篇陆陆续续贴出来的我对LeetCode上面算法题的解答汇总在下面，CTRL+F就可以比较方便地找到。一共154道题，这个数量大概是两个月前的数量，现在其实题目的数目已经超过这个数了（【2015-02-06】注：做了一次更新，新

查看全文: http://www.udpwork.com/item/13778.html

---

+0 层次

Tag: Engineering Culture | Recommended | 层次 | 工程师 | 问题

四火发于 2014年07月19日 15:40 | 点击: 972 | 展开摘要

以下文字，看看就好，笑笑就好。

最近在被一个问题折磨，大致上是，公司内部某些技术更替的关系，要把原有的一个鉴权的组件A淘汰掉，迁移到一个新的替代品B上，我估摸着也就一天时间搞定它绰绰有余了。没料想一猛子扎进去就没那么容易出来了，替换完成以后的测试傻了眼，发现了一个诡异的问题，于是追根溯源，把牵涉进来的林林总总一一拖出来检查排除枪毙，环境比较复杂，debug起来又比较头疼，折磨了三天半的时间；最后还靠这个替代品B的问题列表里面，有某下游产品的工程师跳出来说是这个替代品自身有问

查看全文: http://www.udpwork.com/item/12756.html

^..^

+0 也谈谈全栈工程师

Tag: Engineering Culture | Recommended | 全栈工程师 | 前端 | 后端

四火发于 2014年03月29日 17:35 | 点击: 959 | 展开摘要

纵使目标再大，人的精力有限，于我来说，早些时候远大目标隐约是“成功的软件工程师”这个样子，但是目标是需要逐渐细化的。这些年我渐渐对自己的定位和未来有了一个清晰一点的认识。确实我有很强的观点，觉得软件工程师需要有足够的全面性，在《我眼中的工程师文化》中我也说“工程师文化，不是只有权力的一面，它对工程师的要求，是每个人都要足够能干，都要做许多的事”……

但是，全面性不代表没有专精、没有方向。深度和广度统一的问题已经有许许多多过往的人和我说过了，不存在一个在某一领域精深的牛人但是

查看全文: http://www.udpwork.com/item/12031.html

---

+0 多重继承的演变

四火发于 2014年03月19日 14:45 | 点击: 1125 | 展开摘要

本来想告一段落别写编程范型的东西，但是这个话题最近发现很有意思，就拣出来唠一唠。从中除了能看出很多有趣的语言特性，观察不同语言的设计，还可以发现程序语言的发展过程。这里谈到的语言特性，都是从C++的多重继承演变而来的，都没法完整地实现和代替多重继承本身，但是有了改进和变通，大部分功能保留了下来，又避免了多重继承本身的问题。

C++的多重继承

这个问题我觉得需要从老祖宗C++谈起，我记得刚开始学C++的时候老师就反复教育我们，多重继承的问题。比如说二义性问题，也就是说，两个

查看全文: http://www.udpwork.com/item/11974.html

---

+0 编程范型：工具的选择

四火发于 2014年03月10日 19:19 | 点击: 959 | 展开摘要

这是我写的关于编程范型的文章中最后一篇。

在《编程的未来》里面提到过，很多时候脑子里的算法还是不容易转变成代码，大部分情况下这不是你编码技巧的问题，而是编程语言的问题，或者更严格地说，是编程语言选择的问题。除了复杂性这个软件唯一的敌人，其它真正的困难，早就被数学家们解决了，如果问题和它的解决能够用数学轻松地表述出来，那计算机只是工具而已。极端地说，如果有合适的工具，那么就选择一个；如果没有，那么可以创造一个。仅此而已。

工程师的乐趣，大抵在解决实际问题上，既有解决问题的成

查看全文: http://www.udpwork.com/item/11923.html

|<<<12 3 4 >>>| 一共4页, 41条记录

+0 一些前端框架的比较（下）——Ember.js和React

+0 一些前端框架的比较（上）——GWT、AngularJS和Backbone.js

+0 技术光谱

+0 工作流系统的设计

+0 Spark的性能调优

+0 七年工作，几个故事

+0 从Java和JavaScript来学习Haskell和Groovy（汇总）

+0 LeetCode算法题目解答汇总

+0 层次

+0 也谈谈全栈工程师

+0 多重继承的演变

+0 编程范型：工具的选择

JS 在线图表制作

RSS 订阅

微信订阅

Tags

Random Sites

Hot Items

Site Reviews

Item Reviews