Category Archives: Backend

2018年 DevOps 学习路径图

DevOps 目前非常热门，我认识的大多数朋友，同事和高级开发者都在努力成为 DevOps 工程师，并将自己作为组织中的 DevOps 拥护者。 虽然我承认 DevOps 的好处，它与改进的软件开发和部署直接相关，但从我有限的经验来看，我可以说这不是一件容易的事。在如此多的工具和实践中选择正确的路径是非常困难的。 作为一个 Java 博主，我的读者经常会问到一些问题，例如：如何成为 DevOps 工程师，我应该学些什么？我应该进行什么样的训练？学习 Maven 和 Jenkins 一定是为了成为 DevOps 工程师吗？Dcoker 和 Kubernetes 怎么样？DevOps 如何建设基础的自动化流程？我是否应该学习 Chef、Puppet 或者 Ansible？读者们不断向我提出各种各样的问题，这些只是其中的一部分。 我在自己有限的经验中搜索答案，尽已所能回答那些问题。我不能使用一种简单、有效、可复用的方式把回答记录下来，不过没关系。 今天我将与大家分享一个很棒的资源，它将帮助你成为你一直想成为的 DevOps 工程师，2018年 DevOps 路线图。 昨天我在网上闲逛的时候，偶然发现了 Kamranahmedse 的 GitHub 页面，上面有一些有用的路线图，可以帮助我成为前端开发人员、后端开发人员、全栈 web 开发人员，最后也是最重要的，DevOps 工程师。 这个路线图在任何意义上都是非常棒的，因为它不仅强调了 DevOps 工程师的角色，而且还告诉了你需要学习哪些工具和技术来涵盖这个领域。 最重要的是，它在视觉上很吸引人（你喜欢黄色和奶油色的蓝色线条吗？），所以你可以打印出来并粘在桌子上以便于参考。 虽然路线图很好，但它告诉你要学什么，但它没有告诉你如何学习和在哪里学习。 为了完成路线图，我分享了一些有用的在线课程，包括免费和付费，以便你可以学习和改进你想要的工具或领域。 开发人员 2018 年的 DevOps 路线图 我谈到 2018 DevOps 路线图是这个： Kamran Ahmed (kamranahmedse) 制图 (https://github.com/kamranahmedse/developer-roadmap) 现在，我们按照路线图逐步了解在 2018 年该如何掌握 DevOps 的基本技能： 1. 学习一门编程语言 Java、Python 和 JavaScript 是三种主要的编程语言，我相信你们至少知道一种。 如果你一种都不知道，也没关系。你可以通过下面的介绍的教程来选择一种语言。但我仍然强烈建议你至少学会上述三种通用的主流编程语言中的一种。 Java 如果你想学习 Java，Java 大师养成是门不错的教程，最近它刚针对 Java 10 时行了更新。 Python 如果你想学习 Python，我推荐一门自己最喜欢的课程：完全 Python 训练营。它能教会你 Python 3 这个最流行的 Python 版本。 JavaScript 如果你想学 JavaScript，那千万不要错过 Mosh Hamdani 在 Udemy 上的 JavaScript 基础入门。 如果你需要更多选择，而且愿意通过免费的资源来学习，那么你可以在我列出的清单中找到免费的 Java、Python 和 JavaScript 教程。 2. 了解不同的操作系统概念 这是 Ops 部分开始的地方，早些时候它只是由知道操作系统和硬件的系统管理员支持，但是对于 DevOps，现在开发人员也需要了解它们了。 您至少需要了解路线图中建议的流程管理、线程和并发、套接字、I/O管理、虚拟化、内存存储和文件系统。 由于我们大多数人都在 Linux 工作，我建议你通过 Udemy 上的 Linux Administration BootCamp 课程来更好地学习和理解 Linux 操作系统。 如果您需要更多选择并且不介意从可用资源中学习，那么您还可以查看此 免费的 Linux 课程。 3. 掌握终端生存大法 作为 DevOps 人，能在命令行终端中熟练的使用命令那必须要掌握的，尤其是在 Linux 环境中。必须要了解，Linux 的 shell，如 Bash、或者 Ksh；一些小工具比如 find、grep、awk、sed、lsof；还有网络命令像 nslookup […]

15个最佳的代码评审（Code Review）工具

代码评审可以被看作是计算机源代码的测试，它的目的是查找和修复引入到开发阶段的应用程序的错误，提高软件的整体素质和开发者的技能。代码审查程序以各种形式，如结对编程，代码抽查等。在这个列表中，我们编制了15个最好的代码审查工具，这将有助于开发者节省代码审查时间。 您可能感兴趣的相关文章 Web 前端开发人员和设计师必读精华文章推荐 精心挑选的优秀jQuery Ajax分页插件和教程 12个让人惊叹的的创意的 404 错误页面设计 让网站动起来！12款优秀的 jQuery 动画插件 8个前沿 HTML5 & CSS3 效果【附源码下载】   1. Gerrit Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer. Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be […]

学习ES6零基础-彩票项目中，解决项目代码中运行错误的问题

最近在学习ES6，在B站上看了一些视频再结合阮一峰老师的《ES6标准入门》基本上对ES6的各特性过了一遍，那就开始动手练项目咯，在找到视频对应的代码后，下载并运行出现了几个问题，通过百度又没查到相关的解决思路，这不还得科学上网，毕竟你询问的人群是全世界，总有适合的哪一个。话不说，开始叙述问题，并一步步的解决问题。项目的源代码在我的github上：https://github.com/sun2013126370/es6-lottery-master，视频的话去B站找咯。 先说一下我的相关配置吧

1 2 3 第一个问题： Failed to load external module @babel/register 网上说gulp的版本变成3.9.0（命令：npm install -g gulp@3.9.0）就可以，可以解决这个问题，但是至今还没找到出现这个问题的原因。还好，这个问题并不影响项目的运行，因此选择忽略这个错误或者将gulp的版本换成3.9.0都可以。 第二个问题：TypeError: require.extensions.hasOwnProperty is not a function 这个问题是由版本造成的，打开项目中的package.json，将0.3.1版本改成0.3.2即可，并执行npm install 命令。 重新执行gulp --watch命令，又发现了如下错误，go on! 第三个问题：gulp[13772]: src\node_contextify.cc:628: Assertion `args[1]->IsString()’ failed. 具体什么原因，还没有搞明白，后续再补充。解决这个问题的办法就是npm install natives，再次运行 gulp --watch，OK啦，项目起来了。在浏览器输入localhost：3000，就看到效果了。那接下来就是敲敲项目代码，把出现问题的原因找出来。   from:https://blog.csdn.net/a2013126370/article/details/84102343

Nodejs Sass安装报错一招解决

背景： 这个问题不是一天两天了，有时候是网速不行，有时候是被墙了，有时候是github把node-sass的包转移目录导致下载失败。 Cannot download "https://github.com/sass/node-sass/releases/download/xxx/binding.node的问题 另附node-sass的binding.node各个版本的安装包，哪里少，就单独下载哪个，下载完了之后，跟着我，一起把文件放在指定位置即可解决这个问题 https://github.com/sass/node-sass/releases/tag/v4.7.2 1.本机位置 C:\Users\Administrator\AppData\Roaming\npm-cache\node-sass\ 这个里面是各种版本，报错提示你哪个版本下载失败，你就塞到哪个版本的文件夹里，如图所示 2.删除项目的node_moduls目录 3.重新npm install 4.另附全局安装命令

qq 43163707 落雨 本文地址:http://www.cnblogs.com/ae6623/p/8711853.html

Java Platform Standard Edition 8 Documentation

Oracle has two products that implement Java Platform Standard Edition (Java SE) 8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8. JDK 8 is a superset of JRE 8, and contains everything that is in JRE 8, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 8 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language. Note that the JRE includes components not required […]

高并发接口设计思路

并发队列的选择 Java的并发包提供了三个常用的并发队列实现，分别是：ArrayBlockingQueue、ConcurrentLinkedQueue 和 LinkedBlockingQueue  。 ArrayBlockingQueue是**初始容量固定**的阻塞队列，我们可以用来作为数据库模块成功竞拍的队列，比如有10个商品，那么我们就设定一个10大小的数组队列。 ConcurrentLinkedQueue使用的是CAS原语无锁队列实现，是一个异步队列，入队的速度很快，出队进行了加锁，性能稍慢。 LinkedBlockingQueue也是阻塞的队列，入队和出队都用了加锁，当队空的时候线程会暂时阻塞。 在请求预处理阶段，由于我们的系统入队需求要远大于出队需求，一般不会出现队空的情况，所以我们可以选择ConcurrentLinkedQueue来作为我们的请求队列实现 1. 请求接口的合理设计 一个秒杀或者抢购页面，通常分为2个部分，一个是静态的HTML等内容，另一个就是参与秒杀的Web后台请求接口。 通常静态HTML等内容，是通过CDN的部署，一般压力不大，核心瓶颈实际上在后台请求接口上。这个后端接口，必须能够支持高并发请求，同时，非常重要的一点，必须尽可能“快”，在最短的时间里返回用户的请求结果。为了实现尽可能快这一点，接口的后端存储使用内存级别的操作会更好一点。仍然直接面向MySQL之类的存储是不合适的，如果有这种复杂业务的需求，都建议采用异步写入。 当然，也有一些秒杀和抢购采用“滞后反馈”，就是说秒杀当下不知道结果，一段时间后才可以从页面中看到用户是否秒杀成功。但是，这种属于“偷懒”行为，同时给用户的体验也不好，容易被用户认为是“暗箱操作”。 高并发下的数据安全 我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。 1. 超发的原因 假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景） 在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。 2. 悲观锁思路 解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。 悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。 虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。 3. FIFO队列思路 那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。 然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。 4. 乐观锁思路 这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。 有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。   from:https://my.oschina.net/momisabuilder/blog/2992962

为什么Scrum不行？

导语：此前小编发了一篇《Scrum敏捷价值观与原则》阅读量杠杠的，发现产品汪们对这种开发方式还是很感兴趣的。 so,小编又去挖掘了一篇老文章，《为什么Scrum不行？》 如果还不知道Scrum敏捷开发的朋友们，同理，还是请出门左转，点击 Scrum 了解下。 以下是原文中提到的9个Scrum不行的理由。除此之外，作者陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。 Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？ Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。 Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。 Reason 4:Scrum只不过是一个流程。这世上有太多的流程，尤其是那那些执行CMMI的公司。几乎所有玩CMMI流程的公司，你都能看到的是员工都是那一副副难看的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发出来的，而是上面管你喜欢不喜欢按给你的。Scrum根本不可能增进你的软件质量和技术，只能是优秀的人才才可能！使用Scrum的公司都是些吝啬鬼，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。 Reason 5:Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西（如：backlog）或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。 Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗？让他们不得不去想想自己和团队怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就搬的事，也许那样做令人讨厌，但是人家还是能干点东西出来。如果你逼着人家改变，你就是在压迫人家，人家自然会反抗。 Reason 7:Product Owner专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以轰走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗？你觉得建立信任可能吗？ Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢？我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以，这根本不可能。 Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”，为什么这世上总是会有这些幼稚的人？这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格（可能还会有回扣），为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价格时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。 有人看到这篇文章后也分享了团队实践Scrum后的心得，他觉得在他的团队里不适用Scrum有几个原因： 1.大家对技术不熟悉，因为目前主要的工作量在前端。大家以前都是做java后台的，对js不熟悉，把js当作java来面向对象。而且没有一个成熟的控件库使用。 2.没有在项目开始前做足够的技术调研。本来，应该有个architector来做这些事情。我觉得什么TDD，就是胡扯。没有前期调研，什么都是假设我们能做到，然后就去break down,然后就是估时间，只能是瞎估。估完了，真正implement的时候才发现，一堆东西stand in my way。 3.人的本性就是利己。如果一个team的performance，不和salary挂钩，大家凭什么会齐心协力，deliver更快，更好。目前情况下，scrum只是pm push developers的工具。现在，大家都想到偷懒的方法，就是尽量多估一些时间，或者implement的时候粗一些，反正都是一个个task领的，谁知道bug是谁的code导致的。以前如果一个人responsible for one module,就很容易知道谁的代码质量不高。 4.user story 拆分的不好，容易漏掉很多东西。大家现在都关注task,只想着做完就拉倒，根本不会想着各个task之间的边界和交叉影响。而且，大家现在就习惯看看task就做了，根本不会去看case,所以有些重要的flow全都漏掉了。 5.pm就是scrum master,整个team就是在一个不平等的环境下，scrum只不过是pm试验的工具，能在她的简历上添砖加瓦。我们只不过是小白鼠。 另一种观点认为，Scrum适用于一帮资深程序员组成的team，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家只是干活拿工资，没什么激情，很不适合Scrum。 Scrum就是一把双刃剑，如何用、是否合适还是要看具体的情况。那么，您的团队是否采用过Scrum模式，效果如何呢？   英文原文出自：《Why Scrum will never work》（很抱歉原英文链接小编已经找不到了，如果有哪位找到了这篇原英文链接，请告诉小编哦！） from:http://www.woshipm.com/pd/85814.html

Scrum敏捷价值观与原则

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。如果还不知道Scrum敏捷开发的朋友们，请出门左转，点击 Scrum 了解。 敏捷价值观 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客服合作 高于 合同谈判 响应变化 高于 遵循计划 敏捷的原则 1.我们最重要的目的，是通过持续不断地及早交付有价值的软件使客户满意。 2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 3.经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4.业务人员和开发人员必须相互合作，项目中得每一天都不例外。 5.激发个体的斗志，以他们为核心搭建项目。提高所需的环境和支援，辅以信任，从而达成目标。 6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 7.可工作的软件是进度的首要度量标准。 8.敏捷过程倡导可持续发。责任人、开发人员和用户、要能够共同维持其步调稳定延续。 9.坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。 10.以简洁为本，它是极力减少不必要工作量的艺术。 11.最好的架构、需求和设计出自组织团队。 12.团队定期地反思如何能提高成效，并依次调整自身的举止表现。   参考文献 《Scrum要素》作者：Chris Sims & Hillary Louise Johnson from:http://www.woshipm.com/discuss/84052.html

敏捷开发之Scrum扫盲篇

现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP…   为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希望对初学者有帮助。    什么是敏捷开发？ 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；   为什么说是以人为核心？ 我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。   什么是迭代？ 迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。   关于Scrum和XP 前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。   什么是Scrum？ Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。 而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。   【Scrum开发流程中的三大角色】 产品负责人（Product Owner） 主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。   流程管理员（Scrum Master） 主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。   开发团队（Scrum Team） 主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。     Scrum流程图   //———————— 下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。 什么是Sprint？ Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。   如何进行Scrum开发？ 1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的； 2、Scrum Team根据Product Backlog列表，做工作量的预估和安排； 3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog； 4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）； 5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）； 6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员； 7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）； 8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；     下面是运用Scrum开发流程中的一些场景图： 上图是一个 Product Backlog 的示例。   上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。 任务看版包含 […]

CDN的combo技术能把多个资源文件合并引用，减少请求次数

CDN的combo技术能把多个资源文件合并引用，减少请求次数。比如淘宝的写法：

采用??形式。 参考： http://blog.csdn.net/function_basi/article/details/8809378 http://www.cnblogs.com/zhengyun_ustc/archive/2012/07/18/combo.html   from:https://www.cnblogs.com/EasonJim/p/6216594.html