We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backend-api 发布 1.1.0 版本
[feat] 新增设置统一的前置处理方法 [feat] 新增设置统一的成功处理方法 [feat] 新增业务错误 [feat] 新增设置处理异步操作的方式(callback or promise), 只允许使用某一种方式 [feat] 完善代码的注释并增加测试用例来确保代码的质量
防止 iframe 页面中的链接重定向父级页面
iframe 页面中的链接是可以让父级页面重定向的, 要防止这种情况, 可以通过 iframe 的 sandbox 属性来控制.
ConEmu
Customizable Windows terminal with tabs, splits, quake-style 需要经常用到命令行的 Windows 用户, ConEmu 是个不错的选择
Customizable Windows terminal with tabs, splits, quake-style
需要经常用到命令行的 Windows 用户, ConEmu 是个不错的选择
听“JavaScript 疲乏”听疲乏了
极限编程方法论创造者在 1983 年所说的： “让它工作，用正确的方法做，还要快，”——肯特·贝克(Kent Beck) 如果你正在地狱中穿行，请继续保持前行。——丘吉尔
极限编程方法论创造者在 1983 年所说的：
“让它工作，用正确的方法做，还要快，”——肯特·贝克(Kent Beck)
如果你正在地狱中穿行，请继续保持前行。——丘吉尔
在 2016 年学 JavaScript 是一种什么样的体验？
前端技术名词快速科普帖, 标题可以改为，《前端开发从入门到放弃》 我竟然知道所有的这些名词... react大方向没错，模块化，es6这些等等都是未来的必然趋势。而且前端一直以来就是需要不断有活力注入，至于要学到什么程度，我觉得基本的东西掌握了，再多的新库也是建立在之前的基础上，也不可能掌握所有的新技术。 重要的应该是要做的东西是不是需要用到这些新的东西，更好更高效能解决问题的技术才是着眼点吧。 有更好的工具，我为什么不用呢？当然兼容性，跨平台这些一直都是要考虑的，这取决于要做的东西的需求，面向群体等。 我要开发一个网页，用来展示用户的最新动态。我想我应该通过后端接口获取数据，然后用一个 table 来展示数据，用户可以对数据进行排序。 如果服务器上的数据变化了，我还需要更新这个 table。我的思路是用 jQuery 来做。 可别用 jQuery！现在哪还有人用 jQuery。现在是 2016 年了，你绝对应该用 React。 jQuery React JSX Babel ES2016 模块管理器(AMD 或者 CommonJS ) 打包(Browserify) npm 仓库安装依赖 用 npm 安装 React 然后用 Browerify 来打包就好了？ 任务管理工具(Grunt/Gulp/Broccoli/Makefiles/Webpack) 是的，不过显然我们做 Web 开发的，喜欢先把事情搞复杂，然后回归到最朴素的状态。每年我们都是这么搞的。你就看着吧，过不了两年，我们就可以在网页上写汇编了。 刚才不是说应该把所有依赖打包成一个文件吗？ 但是等 HTTP/2 普及之后，不打包反而更好 强类型语言(Typescript) Flow 函数式编程很叼的 Ramnda Fetch API 回调地狱 Promise 天呐我到底需要多少个库？ 这是 JS，同一件事情有上千个库在做。我们了解库，而且我们有最好的库，我们有海量的库，要什么有什么。 await 用 Typescript 写代码，用 Fetch 发起异步请求，所有代码编译成 ES6，然后用上 Babel 的 stage–3 配置项，把 ES6 转译成 ES5。所有代码用 SystemJS 加载。如果你用不了 Fetch，就加个 polyfill，或者用 Bluebird、Request 或者 Axios，这样你就可以用 await 来处理 Promise 了 状态变更(Flux/Redux) 如果你只是想展示数据，其实你不需要 React。你只需要一个模板引擎 我不做了，我不做 Web 了，我也不想再碰 JS 了 没事，过不了几年，我们都会用 Elm 或者 WebAssembly 了 我要回后端去了，我受不这些变动、版本更新、编译和转译了，JS 社区如果觉得有人能跟上它的脚步，那这个社区就是疯了 我理解你。我建议你去 Python 社区 听说过 Python 3 吗？ 译者注：最后一句「听说过 Python 3 吗？」是讽刺 Python 3 发布已经 8 年了，Python 社区却依然在使用 Python 2.7。而 JS 社区正好相反，把还没有实现的语言特性都用到生成环境中了！
前端技术名词快速科普帖, 标题可以改为，《前端开发从入门到放弃》
我竟然知道所有的这些名词...
react大方向没错，模块化，es6这些等等都是未来的必然趋势。而且前端一直以来就是需要不断有活力注入，至于要学到什么程度，我觉得基本的东西掌握了，再多的新库也是建立在之前的基础上，也不可能掌握所有的新技术。
重要的应该是要做的东西是不是需要用到这些新的东西，更好更高效能解决问题的技术才是着眼点吧。
有更好的工具，我为什么不用呢？当然兼容性，跨平台这些一直都是要考虑的，这取决于要做的东西的需求，面向群体等。
我要开发一个网页，用来展示用户的最新动态。我想我应该通过后端接口获取数据，然后用一个 table 来展示数据，用户可以对数据进行排序。 如果服务器上的数据变化了，我还需要更新这个 table。我的思路是用 jQuery 来做。
可别用 jQuery！现在哪还有人用 jQuery。现在是 2016 年了，你绝对应该用 React。
译者注：最后一句「听说过 Python 3 吗？」是讽刺 Python 3 发布已经 8 年了，Python 社区却依然在使用 Python 2.7。而 JS 社区正好相反，把还没有实现的语言特性都用到生成环境中了！
JavaScript fatigue fatigue
Don’t try to know everything Go for depth in areas you love When in doubt about what to learn next, you can always go back to fundamentals: HTML/CSS/JavaScript/HTTP (which technologies are fundamental depends on your work) Non-technological skills: time management, social skills (communication, team building, …), health, management processes and so on.
技术的执念
过载的信息 身处这样的信息过载环境，我们很难不为自己对信息的缺乏而感到不安，担心自己错过了什么重要的信息，这种担心和焦虑会促使我们进一步将时间消耗在对信息的获取上，从而更无暇思考什么是真正重要的。 《如何阅读一本书》将书分为两类：一种是提供资讯/信息（known）的，一种是帮助你理解（understand）信息的。相对于理解来讲，资讯本身其实并不那么重要。 我们大部分人目前采用的碎片化的阅读方式无法提供给我们足够的“理解力”。我们都有这样的体验，有些书特别耗费脑力，读起来很累，而另一些书则非常轻松，易于消费。 碎片话的阅读方式易于消费，只需要很少的思考就可以读懂，但是危害严重，它们并不会让帮助你提升理解力。 但是直觉上我们会选择容易的事情来做，虽然这种浅层次的阅读只对扩展信息/资讯有帮助，对提升理解力则几乎无用。 而我们在处理日常工作中的问题时，能真正帮助的，只有理解了的那部分知识。 在成为一个专家之前，你需要先对要学习的领域有一个全面的认识 对于过载的信息 你无法掌握所有的知识，你只需要采取先建立广度，再建立深度的原则即可： 做减法（在建立了知识框架之后，有针对性的学习） 主动，深度阅读经典 为那些有趣但非自己关注方向的知识赋予较低的优先级
过载的信息
身处这样的信息过载环境，我们很难不为自己对信息的缺乏而感到不安，担心自己错过了什么重要的信息，这种担心和焦虑会促使我们进一步将时间消耗在对信息的获取上，从而更无暇思考什么是真正重要的。
《如何阅读一本书》将书分为两类：一种是提供资讯/信息（known）的，一种是帮助你理解（understand）信息的。相对于理解来讲，资讯本身其实并不那么重要。 我们大部分人目前采用的碎片化的阅读方式无法提供给我们足够的“理解力”。我们都有这样的体验，有些书特别耗费脑力，读起来很累，而另一些书则非常轻松，易于消费。 碎片话的阅读方式易于消费，只需要很少的思考就可以读懂，但是危害严重，它们并不会让帮助你提升理解力。
但是直觉上我们会选择容易的事情来做，虽然这种浅层次的阅读只对扩展信息/资讯有帮助，对提升理解力则几乎无用。 而我们在处理日常工作中的问题时，能真正帮助的，只有理解了的那部分知识。
在成为一个专家之前，你需要先对要学习的领域有一个全面的认识
对于过载的信息
你无法掌握所有的知识，你只需要采取先建立广度，再建立深度的原则即可：
运营活动规范
由于运营活动的零散性，导致了团队不同人员所开发的页面在维护层面上很难形成统一，也增加了相互协助的难度，从而造成不同人员之间修改代码存在安全隐患的风险。为此，制定统一开发规范，方便团队后期协作、提高开发效率。 活动目录命名规范: promote/201606/xxxx(活动英文名) REM标准 页面的尺寸适配统一使用 REM 与 px 结合来完成，定高不定宽（通常布局使用rem，模块大小采用px）,示例Demo；可以辅助地使用 zoom/scale 375px 宽度下，<html>节点的 font-size 为 20px z-index 标准 z-index 最大值不得超过 700 z-index 取值范围 普通元素: 0～100 floating/吸顶/吸底: 101～200 弹窗: 201～300 loading/分享蒙层: 301～400
由于运营活动的零散性，导致了团队不同人员所开发的页面在维护层面上很难形成统一，也增加了相互协助的难度，从而造成不同人员之间修改代码存在安全隐患的风险。为此，制定统一开发规范，方便团队后期协作、提高开发效率。
活动目录命名规范: promote/201606/xxxx(活动英文名)
promote/201606/xxxx(活动英文名)
REM标准
375px
<html>
font-size
20px
z-index 标准
700
0～100
101～200
201～300
301～400
从域名到网站，只需四步，轻松访问
注册域名 准备服务器和网站 服务器备案 根据规定，只要是用于网站服务的服务器，都需要进行备案（约 20 个工作日），只有备案成功网站才可以使用 绑定域名，并设置域名解析 服务器上绑定您的域名 通过域名解析将域名与服务器 IP 地址绑定 网站可访问
注册域名
准备服务器和网站
服务器备案
根据规定，只要是用于网站服务的服务器，都需要进行备案（约 20 个工作日），只有备案成功网站才可以使用
绑定域名，并设置域名解析
服务器上绑定您的域名
通过域名解析将域名与服务器 IP 地址绑定
网站可访问
前后端分离了，然后呢？
即使通过API来解耦前端和后端开发过程，前后端通过RESTFul的接口来通信，前端的静态内容和后端的动态计算分别开发，分别部署，集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行，但是集成起来却不工作。我们需要花费大量的精力来调试，直到上线前仍然没有人有信心所有的接口都是工作的。 前后端仅仅通过接口来编程，这个接口可能是JSON格式的RESTFul的接口，也可能是XML的，重点是后台只负责数据的提供和计算，而完全不处理展现。而前端则负责拿到数据，组织数据并展现的工作。这样结构清晰，关注点分离，前后端会变得相对独立并松耦合。 在这样一个复杂的系统中，后台任意端点的失败都可能阻塞前端的开发流程，因此我们会采用mock的方式来解决这个问题 这个mock服务器可以启动一个简单的HTTP服务器，然后将一些静态的内容serve出来，以供前端代码使用。这样的好处很多: 前后端开发相对独立 后端的进度不会影响前端开发 启动速度更快 前后端都可以使用自己熟悉的技术栈（让前端的学maven，让后端的用gulp都会很不顺手） 提供mock数据是远远不够的。我们需要的mock应该还能做到： 前端依赖指定格式的mock数据来进行UI开发 前端的开发和测试都基于这些mock数据 后端产生指定格式的mock数据 后端需要测试来确保生成的mock数据正是前端需要的 简而言之，我们需要商定一些契约，并将这些契约作为可以被测试的中间格式。然后前后端都需要有测试来使用这些契约。一旦契约发生变化，则另一方的测试会失败，这样就会驱动双方协商，并降低集成时的浪费。 前后端分离是一件容易的事情，而且团队可能在短期可以看到很多好处，但是如果不认真处理集成的问题，分离反而可能会带来更长的集成时间。通过面向契约的方式来组织各自的测试，可以带来很多的好处：更快速的End2End测试，更平滑的集成，更安全的分离开发等等。
即使通过API来解耦前端和后端开发过程，前后端通过RESTFul的接口来通信，前端的静态内容和后端的动态计算分别开发，分别部署，集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行，但是集成起来却不工作。我们需要花费大量的精力来调试，直到上线前仍然没有人有信心所有的接口都是工作的。
前后端仅仅通过接口来编程，这个接口可能是JSON格式的RESTFul的接口，也可能是XML的，重点是后台只负责数据的提供和计算，而完全不处理展现。而前端则负责拿到数据，组织数据并展现的工作。这样结构清晰，关注点分离，前后端会变得相对独立并松耦合。
在这样一个复杂的系统中，后台任意端点的失败都可能阻塞前端的开发流程，因此我们会采用mock的方式来解决这个问题
这个mock服务器可以启动一个简单的HTTP服务器，然后将一些静态的内容serve出来，以供前端代码使用。这样的好处很多:
提供mock数据是远远不够的。我们需要的mock应该还能做到：
简而言之，我们需要商定一些契约，并将这些契约作为可以被测试的中间格式。然后前后端都需要有测试来使用这些契约。一旦契约发生变化，则另一方的测试会失败，这样就会驱动双方协商，并降低集成时的浪费。
前后端分离是一件容易的事情，而且团队可能在短期可以看到很多好处，但是如果不认真处理集成的问题，分离反而可能会带来更长的集成时间。通过面向契约的方式来组织各自的测试，可以带来很多的好处：更快速的End2End测试，更平滑的集成，更安全的分离开发等等。
我们真的缺前端工程师吗？
其实我们并不缺前端工程师，我们缺的是优秀的前端工程师 不从系统的角度来思考，不真正做一些后端开发/配置，并不能算是前端工程师，或者可以被称为偏前端工程师（partial frontend developer） 开发工作不应该仅仅局限在编码上，作为开发者/工程师，应该尽可能的多了解一些上下文：比如我们的项目最终是给谁用的，需求从何而来，项目是如何部署在线上的等等。 简而言之，开发者视野应该放开开阔一些。不要将自己局限在某种角色上，不但不要局限在前端/后端开发上，压根就不要局限在开发这种角色本身上，你在系统中，可以是设计师，还可以是业务分析师。虽然不一定最终要你去转行做BA，或者UX，但是更广阔的视野可以使你更加高效的发挥自己的作用，也可以在和别的角色互动式，快速的了解上下文。 我所理解的，前端不一定要熟知所有这些知识和技能，但是一定不要认为自己做好了前端的一亩三分地就足够了，不要给自己设限。跨界会给你带来难以估量的好处，一个角色做久了，难免会产生一些盲点。这时候，换个视角，从其他角色的角度来看待你的工作，又会有很多新的发现。而且不仅如此，很可能你会发现之前很麻烦，很难搞定的事情，在新的方法/视角下变得很容易。 尝试从系统级别去解决一个问题，而不是将问题抛给另外一个角色（后端工程师，UX或者QA） 我们缺的从来都不是前端/后端工程师，而是工程师(或者那些会系统思考，并总是想着解决问题的人)
其实我们并不缺前端工程师，我们缺的是优秀的前端工程师
不从系统的角度来思考，不真正做一些后端开发/配置，并不能算是前端工程师，或者可以被称为偏前端工程师（partial frontend developer）
开发工作不应该仅仅局限在编码上，作为开发者/工程师，应该尽可能的多了解一些上下文：比如我们的项目最终是给谁用的，需求从何而来，项目是如何部署在线上的等等。
简而言之，开发者视野应该放开开阔一些。不要将自己局限在某种角色上，不但不要局限在前端/后端开发上，压根就不要局限在开发这种角色本身上，你在系统中，可以是设计师，还可以是业务分析师。虽然不一定最终要你去转行做BA，或者UX，但是更广阔的视野可以使你更加高效的发挥自己的作用，也可以在和别的角色互动式，快速的了解上下文。
我所理解的，前端不一定要熟知所有这些知识和技能，但是一定不要认为自己做好了前端的一亩三分地就足够了，不要给自己设限。跨界会给你带来难以估量的好处，一个角色做久了，难免会产生一些盲点。这时候，换个视角，从其他角色的角度来看待你的工作，又会有很多新的发现。而且不仅如此，很可能你会发现之前很麻烦，很难搞定的事情，在新的方法/视角下变得很容易。
尝试从系统级别去解决一个问题，而不是将问题抛给另外一个角色（后端工程师，UX或者QA）
我们缺的从来都不是前端/后端工程师，而是工程师(或者那些会系统思考，并总是想着解决问题的人)
互联网项目架构经验分享
项目的质量指标:功能，性能和扩展性 架构设计的主要过程 确定问题域 以我的的经验来看，扩展把我关键问题，优先满足关键问题的性能，确定最小功能集。确定最小功能集的优势可以快速实现，快速验证需求的准确性，每次需求开发都完成最小和最关键的需求 数据建模 数据建模时的几个心得: 数据表包含自增id,创建时间createTime,更新时间updateTime和版本号version 不使用外键 不使用id作为表关联，虽然我们不创建外键约束，但是不代表表之间没有关联关系, 表间的关联使用全局的唯一id的方式一个更好的选择 应用最初的设计最符合设计原则和设计思想的, 我们应该尽量的坚持最初的设计，克服其他因素的影响 最初设计系统时尽量少的使用冗余字段去提供查询的方便性和性能. 如果系统真的流量比较大，查询性能太低，可以通过把读服务从业务系统中分离 以下是电商应用部分表(商品和订单业务相关)设计，仅供参考: 模块划分 如果数据模型主要为满足功能目标的话，模块划分会比较多的兼顾性能和扩展性 单实例结构 集群结构 分布式结构 混合结构 如何选择系统结构，可以从如下几方面考虑： 系统是否能满足未来2-3年的增长 人力因素, 量力而行 时间因素，很多互联网公司的工期不是技术评估的，是由”市场”确定的，所以火烧眉毛的时候就别讲究性能和扩展了，上线再说。 架构不是一成不变的，不断增加的访问和不断变化的需求改变着系统的架构。快速响应，不断迭代才是互联网应用的方式。所以最初的架构，尽量的做到高内聚低耦合，这样不断的提高系统的短板，逐渐完善系统结构 关键流程描述 关键流程描述是检查系统架构是否满足需求和指导开发的必要条件。关键流程描述是使用流程图解决关键问题的过程，它的使用者是团队其他成员和自己，所以格式不重要，其他人能明白就好。 技术选型 如果非必要请使用常用的技术，框架等 熟悉的优于强大的，尽量采取团队比较熟悉的技术或者使用团队中有人可以指导的技术 代码实现 代码首先是给人读的，其次才是给机器读，所以良好的代码结构是项目存活更长时间的良药 代码分层：功能单一原则 命名规范 注释风格 验收测试 积极配合测试团队对项目的测试，他们是为项目健康上线保驾护航的人，不是挑刺的人 总结 同样的题目有多种解法，我们做的只是其中的一种，所以要接受别人的质疑和建议，这样才能使系统完善。 没有银弹，没有解决一切问题的方法，那么也不可能使用一种方法解决所有问题，所以要根据需求，团队，时间等选择合适的方式方法。
项目的质量指标:功能，性能和扩展性
架构设计的主要过程
确定问题域
以我的的经验来看，扩展把我关键问题，优先满足关键问题的性能，确定最小功能集。确定最小功能集的优势可以快速实现，快速验证需求的准确性，每次需求开发都完成最小和最关键的需求
数据建模
数据建模时的几个心得:
以下是电商应用部分表(商品和订单业务相关)设计，仅供参考:
模块划分
如果数据模型主要为满足功能目标的话，模块划分会比较多的兼顾性能和扩展性
如何选择系统结构，可以从如下几方面考虑：
关键流程描述
关键流程描述是检查系统架构是否满足需求和指导开发的必要条件。关键流程描述是使用流程图解决关键问题的过程，它的使用者是团队其他成员和自己，所以格式不重要，其他人能明白就好。
技术选型
代码实现
代码首先是给人读的，其次才是给机器读，所以良好的代码结构是项目存活更长时间的良药
验收测试
积极配合测试团队对项目的测试，他们是为项目健康上线保驾护航的人，不是挑刺的人
总结
如何从菜鸟成长为(伪)架构师
如何更高效的学习？ 大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点 体系化的学习 更有效率的学习方法: 带着问题学习 沟通的核心不是你说了什么，而是你想要让对方了解什么、让他做什么 想要恰到好处的进行沟通简单来说有几条原则： 确保各方对背景的理解一致 去掉对方不能/不需要理解的内容 确保在对方失去注意力前尽快说出重点 不要说没有意义的内容浪费其他人的时间 程序的生命力 大部分程序都能实现功能，但是如果把“时间”这个也作为一个考虑的维度的话，就会意识到一个合格的项目需要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。而想要毁掉程序的生命力也很简单：做的更复杂，更定制化，让更少的人参与。
如何更高效的学习？
大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点
体系化的学习
更有效率的学习方法: 带着问题学习
沟通的核心不是你说了什么，而是你想要让对方了解什么、让他做什么
想要恰到好处的进行沟通简单来说有几条原则：
程序的生命力
大部分程序都能实现功能，但是如果把“时间”这个也作为一个考虑的维度的话，就会意识到一个合格的项目需要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。而想要毁掉程序的生命力也很简单：做的更复杂，更定制化，让更少的人参与。
如何持久化你的项目经历
对上一个项目的总结，真正会为帮助我们在将来的项目中做决策，甚至会影响我们学习效率，解决问题能力的是：深度回顾 深度回顾可以帮助我们梳理知识，将实际的案例归纳总结为实际可用的知识 我在项目里学到了什么？ 项目的背景介绍 该项目以何种方式，为那些用户，带来了什么样的价值？（business model是什么） 该项目的实际用户数量是什么级别？ 项目的部署，运维是如何操作的？ 项目的监控是怎样做的？ 当遇到系统故障，项目组是如何反应的？ 遇到的最大的挑战是什么？ 这个挑战是如何被解决的？ 如果有机会重做，你会如何考虑？ 辅助性的练习可以帮助你更好的梳理项目上学到的技能、知识，并且转换成你自己的知识 记笔记 写博客 在办公室内演讲 去社区贡献话题 从项目上下来之后，需要深入思考并总结之前的经验，这种深入思考会帮助你建立比较完整的知识体系，也可以让你在下一项目中更加得心应手，举一反三。 如果只是蜻蜓点水般的“经历”了若干个项目，而不进行深入的总结和思考，相当于把相同的项目用不同的技术栈做了很多遍一样，那和我们平时所痛恨的重复代码又有什么不同呢？
对上一个项目的总结，真正会为帮助我们在将来的项目中做决策，甚至会影响我们学习效率，解决问题能力的是：深度回顾
深度回顾可以帮助我们梳理知识，将实际的案例归纳总结为实际可用的知识
辅助性的练习可以帮助你更好的梳理项目上学到的技能、知识，并且转换成你自己的知识
从项目上下来之后，需要深入思考并总结之前的经验，这种深入思考会帮助你建立比较完整的知识体系，也可以让你在下一项目中更加得心应手，举一反三。 如果只是蜻蜓点水般的“经历”了若干个项目，而不进行深入的总结和思考，相当于把相同的项目用不同的技术栈做了很多遍一样，那和我们平时所痛恨的重复代码又有什么不同呢？
技术人生 | 技术人如何打造个人品牌
来自携程框架研发部高级经理魏晓军在内部活动中分享，介绍了其在撰写国内第一本React Native相关书籍《ReactNative入门与实战》时的经历和感想，从中我们或许可以一窥技术人该如何打造个人品牌。 写书这事不比写文章，更需要花时间、花精力去琢磨。写之前罗列提纲，写之后校验几遍，还要配上简单易懂的示例。 现在好多人写博客，我觉得这是个很好的习惯。写技术文章，对我们自身提高是很有帮助的，尤其是一些总结性文章。 写文章，是对某个知识点梳理，而写书，是对某个技术的梳理，让你对该技术整个生态、未来方向发展非常了解，对个人是很大的提升。 作为技术人，要懂得营销自己，在Github、论坛、博客上，常写总结性文章 当你在写作的时候，是你对这个知识点的整理，不仅要理清它的来龙去脉，还要考虑要怎么写出来，被人看懂。 通过写文章，做总结，也可以被更多圈内小伙伴、媒体、出版社关注到，逐渐打造个人品牌。 常参加一些会议，做分享 我们每个人的精力是有限的，如果你有10门技术要学，一个1年，那你要学10年；而如果10个人学习，每人学一门，大家经常一起交流、分享，这样也许1年你就把这些技术都掌握了
来自携程框架研发部高级经理魏晓军在内部活动中分享，介绍了其在撰写国内第一本React Native相关书籍《ReactNative入门与实战》时的经历和感想，从中我们或许可以一窥技术人该如何打造个人品牌。
写书这事不比写文章，更需要花时间、花精力去琢磨。写之前罗列提纲，写之后校验几遍，还要配上简单易懂的示例。
现在好多人写博客，我觉得这是个很好的习惯。写技术文章，对我们自身提高是很有帮助的，尤其是一些总结性文章。
写文章，是对某个知识点梳理，而写书，是对某个技术的梳理，让你对该技术整个生态、未来方向发展非常了解，对个人是很大的提升。
作为技术人，要懂得营销自己，在Github、论坛、博客上，常写总结性文章
当你在写作的时候，是你对这个知识点的整理，不仅要理清它的来龙去脉，还要考虑要怎么写出来，被人看懂。
通过写文章，做总结，也可以被更多圈内小伙伴、媒体、出版社关注到，逐渐打造个人品牌。
常参加一些会议，做分享
我们每个人的精力是有限的，如果你有10门技术要学，一个1年，那你要学10年；而如果10个人学习，每人学一门，大家经常一起交流、分享，这样也许1年你就把这些技术都掌握了
设计模式总结
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性 每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工作。即模式是在特定环境中解决问题的一种方案。 简单地说，就是从前辈们在程序设计过程中总结、抽象出来的通用优秀经验。主要目的一方面是为了增加程序的灵活性、可重用性。 另一方面也有助于程序设计的标准化和提高系统开发进度。 设计模式分类 根据其目的（模式是用来做什么的）可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三种： 创建型模式主要用于创建对象 Singleton Prototype Factory Method Abstract Factory Builder 结构型模式主要用于处理类或对象的组合 Composite Adapter Facade Bridge Decorator Flyweight Proxy 行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。 Chain of Responsibility Command Observer Strategy Interpreter Iterator Mediator Memento State Template Method Visitor 根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种： 类模式： 处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。 对象模式：处理对象间的关系，这些关系在运行时刻变化，更具动态性。
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性
每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工作。即模式是在特定环境中解决问题的一种方案。
简单地说，就是从前辈们在程序设计过程中总结、抽象出来的通用优秀经验。主要目的一方面是为了增加程序的灵活性、可重用性。 另一方面也有助于程序设计的标准化和提高系统开发进度。
设计模式分类
关于烂代码的那些事上、中、下
关于烂代码的那些事[上]早在班会第 12 期就已经分享过了 中篇: 如何尽可能高效和客观的评价代码的优劣, 什么是好代码 下篇: 如何应对这些身边的烂代码, 如何提高自己的代码质量
关于烂代码的那些事[上]早在班会第 12 期就已经分享过了
中篇: 如何尽可能高效和客观的评价代码的优劣, 什么是好代码
下篇: 如何应对这些身边的烂代码, 如何提高自己的代码质量
穷人的持续集成与持续交付上、下
本文将使用一些免费的服务来为你的项目搭建持续交付平台，这些服务包括 持续集成环境 持续部署环境 服务端应用托管 周期时间（cycle time），就是一个需求从产生到最终上线所需要的时间。其中包括了需求分析，设计，编码，测试，部署，运维等活动，可能还会包含后续的监控。 持续交付包含了自动化构建，自动化测试以及自动化部署等过程，持续改进开发流程中的问题，并促进开发人员，测试人员，运维人员之间的协作，团队可以在分钟级别将变更发布上线。 持续交付相关技术及实践 版本控制（配置管理） 持续集成CI 自动化测试 构建工具及构建脚本 部署流水线 团队通过版本控制来进行协作，所有的代码会在持续集成环境中编译，代码静态检查/分析，自动化测试（还可能产生报告等）。除此之外，CI还还需要有自动化验收测试，自动化回归测试等。 持续交付则更进一步，它将环境准备，持续集成，自动化部署等放在了一起。通过全自动（有些过程可以设置为手动，比如发布到产品环境）的方式，使得软件可以一键发布。如果上线后发现严重defect，还支持一键回滚的机制（其实就是将之前的一个稳定版本做一次发布，由于发布流程已经经过千锤百炼，所以发布本身就变得非常轻松，安全） 一个前后端分离的架构，如何做到静态内容的托管，打包，部署，并和后端API集成起来 持续集成（单元测试，集成测试等） 持续部署/持续交付 静态站点托管 现在前后端应用完全独立，发布也互不影响。不论是服务器端新增加了API，还是添加了新数据，客户端的发布都不受影响；同样，修改样式，添加新的JavaScript也完全不会影响后端。更重要的是，所有的发布都是一键式的，开发者只需要一个git push就可以享受这些免费服务提供的自动构建，自动化测试以及自动部署的功能。
本文将使用一些免费的服务来为你的项目搭建持续交付平台，这些服务包括
周期时间（cycle time），就是一个需求从产生到最终上线所需要的时间。其中包括了需求分析，设计，编码，测试，部署，运维等活动，可能还会包含后续的监控。
持续交付包含了自动化构建，自动化测试以及自动化部署等过程，持续改进开发流程中的问题，并促进开发人员，测试人员，运维人员之间的协作，团队可以在分钟级别将变更发布上线。
持续交付相关技术及实践
团队通过版本控制来进行协作，所有的代码会在持续集成环境中编译，代码静态检查/分析，自动化测试（还可能产生报告等）。除此之外，CI还还需要有自动化验收测试，自动化回归测试等。
持续交付则更进一步，它将环境准备，持续集成，自动化部署等放在了一起。通过全自动（有些过程可以设置为手动，比如发布到产品环境）的方式，使得软件可以一键发布。如果上线后发现严重defect，还支持一键回滚的机制（其实就是将之前的一个稳定版本做一次发布，由于发布流程已经经过千锤百炼，所以发布本身就变得非常轻松，安全）
一个前后端分离的架构，如何做到静态内容的托管，打包，部署，并和后端API集成起来
现在前后端应用完全独立，发布也互不影响。不论是服务器端新增加了API，还是添加了新数据，客户端的发布都不受影响；同样，修改样式，添加新的JavaScript也完全不会影响后端。更重要的是，所有的发布都是一键式的，开发者只需要一个git push就可以享受这些免费服务提供的自动构建，自动化测试以及自动部署的功能。
5分钟了解Material Design
看似平面实则3D, 在平面中具有明确的Z轴概念 在表现元素的重叠与层次上阴影的效果功不可没 与现实中的影子同理，阴影的表现会根据Z轴上的位置发生变化 Material Design不能在同一个视图内使用过多的颜色 colorPrimary（主色） colorPrimaryDark (与colorPrimary是同系色) colorAccent (与colorPrimary相比较醒目的颜色，重点色) windowBackground (白色或透明的黑色，与colorPrimary是同系色) 舒服的变换/接触反馈/有意义的动画: 用户进行的按下按钮等操作与随后出现的动画，前后必须有紧密的关联性
看似平面实则3D, 在平面中具有明确的Z轴概念
在表现元素的重叠与层次上阴影的效果功不可没
与现实中的影子同理，阴影的表现会根据Z轴上的位置发生变化
Material Design不能在同一个视图内使用过多的颜色
舒服的变换/接触反馈/有意义的动画: 用户进行的按下按钮等操作与随后出现的动画，前后必须有紧密的关联性
项目经理是大傻B吗？
PM其实就是一个轮询器：识别所有的项目风险，然后不断跟进。项目风险可能是技术风险，比如某个技术上压根搞不定的问题。也可能资源风险，比如人手不够，或者开发者很多，但是没有足够的设计师协助，这些风险都会导致项目无法按照时间交付。 PM的一个重要职责就是在项目之初将项目范围定下来，这个范围的划分非常依赖经验 如何合作？ 理解PM的工作 不要因为一个人不会某个技术而鄙视他, 就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样 学习如何报告进度 站会前自己花3分钟整理一下昨天做的工作 进行合理的任务划分（tasking技能） 合理估算 明确告诉PM，有哪些需求是不可能按时交付的，PM会根据实际情况来重新定计划，并和客户确认 明确告诉PM一些可能的风险，团队整体对交付负责，而不是PM，或者开发 按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。 简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？
PM其实就是一个轮询器：识别所有的项目风险，然后不断跟进。项目风险可能是技术风险，比如某个技术上压根搞不定的问题。也可能资源风险，比如人手不够，或者开发者很多，但是没有足够的设计师协助，这些风险都会导致项目无法按照时间交付。
PM的一个重要职责就是在项目之初将项目范围定下来，这个范围的划分非常依赖经验
如何合作？
按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。
简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？
Adobe Portfolio | Build your own personalized website
Adobe 的设计每次都是极好的
Tilda
Create a website for free. Introducing Tilda Publishing website builder
The text was updated successfully, but these errors were encountered:
No branches or pull requests
backend-api 发布 1.1.0 版本
防止 iframe 页面中的链接重定向父级页面
ConEmu
听“JavaScript 疲乏”听疲乏了
在 2016 年学 JavaScript 是一种什么样的体验？
JavaScript fatigue fatigue
技术的执念
运营活动规范
从域名到网站，只需四步，轻松访问
前后端分离了，然后呢？
我们真的缺前端工程师吗？
互联网项目架构经验分享
如何从菜鸟成长为(伪)架构师
如何持久化你的项目经历
技术人生 | 技术人如何打造个人品牌
设计模式总结
关于烂代码的那些事上、中、下
穷人的持续集成与持续交付上、下
5分钟了解Material Design
项目经理是大傻B吗？
Adobe Portfolio | Build your own personalized website
Tilda
The text was updated successfully, but these errors were encountered: