iKcamp｜基于Koa2搭建Node.js实战（含视频）☞ 视图Nunjucks
视频地址：https://www.cctalk.com/v/15114923888328视图Nunjucks彩虹是上帝和人类立的约，上帝不会再用洪水灭人。客户端和服务端之间相互通信，传递的数据最终都会展示在视图中，这时候就需要用到『模板引擎』。什么是模板引擎？模板引擎是为了使用户界面与业务数据分离而产生的，可以生成特定格式的文档。例如，用于网站的模板引擎会生成一个标准的HTML文档。市面上常见的模板引擎很多，例如：Smarty、Jade、Ejs、Nunjucks等，可以根据个人喜好进行选择。koa-views、koa-nunjucks-2等支持Koa的第三方中间件也可以自行选择。本项目中，我们使用koa-nunjucks-2作为模板引擎。Nunjucks是Mozilla开发的，纯js编写的模板引擎，既可以用在Node环境下，也可以运行在浏览器端。koa-nunjucks-2是基于Nunjucks封装出来的第三方中间件，完美支持Koa2。Nu
你真的会使用XMLHttpRequest吗？
看到标题时，有些同学可能会想：“我已经用xhr成功地发过很多个Ajax请求了，对它的基本操作已经算挺熟练了。”我之前的想法和你们一样，直到最近我使用xhr时踩了不少坑儿，我才突然发现其实自己并不够了解xhr，我知道的只是最最基本的使用。于是我决定好好地研究一番xhr的真面目，可拜读了不少博客后都不甚满意，于是我决定认真阅读一遍W3C的XMLHttpRequest标准。看完标准后我如同醍醐灌顶一般，感觉到了从未有过的清澈。这篇文章就是参考W3C的XMLHttpRequest标准和结合一些实践验证总结而来的。Ajax和XMLHttpRequest我们通常将Ajax等同于XMLHttpRequest，但细究起来它们两个是属于不同维度的2个概念。以下是我认为对Ajax较为准确的解释：（摘自whatisAjax）AJAXstandsforAsynchronousJavaScriptandXML.AJAXisanewtechniqueforcreatingbetter,faster,andmorein
javascript成神之路(3)：到底有没有json对象
摘要：每天坚持一点点，胜利就会在你眼前(文章后面有惊喜)前言：在我工作的过程中，很多小伙伴多会说：把字符串转化为JSON对象，把JSON对象转化成字符串等类似的话，前一段时间，我看了一篇关于JSON方面的文章，是一个外国大神写的，让我也深有体会，在这里我就谈一下我的感受。很多的javascript开发人员都错误地把javascript对象字面量（ObjectLiterals）称为JSON对象（JSONObjects），因为他的语法和JSON规范里描述的一样，但是该规范里也明确地说了JSON只是一个数据交换语言，只有我们将之用在string上下文的时候它才叫JSON。在这里我们在这里了解几个概念：一、什么是字面量他们是固定的值，不是变量，让你从“字面上”理解脚本。字符串字面量是由双引号（"）或单引号（'）包围起来的零个或多个字符组成的。对象字面量是由大括号（{}）括起来的零个或多个对象的属性名-值对。二、序列化与反序列化2个程序在交互通信的时候，他们倾向于使用string字符串因为string在很多语言里解析的方式都差不多。复杂的数
vue-music 音乐 App 之 cube-ui 重构
背景去年6月初，我在慕课网上线了一门Vue.js2.0的高级实战课程音乐WebApp课程，教同学们如何去开发基础组件和业务组件。在一般大公司的实际项目中，并不会为每一个项目都去开发基础组件，他们往往会把基础组件收敛成一个组件库，供各个项目复用。滴滴也是如此，我们在去年初使用Vue.js去重构了我们的打车WebApp，也抽象出了一套移动端组件库，在经过一年多的业务考验后，我们决定做开源，一方面是想把好的东西分享出去，并通过社区的反馈去完善我们的组件库；另一方面也是想让大家了解滴滴的前端，能吸引一些优秀的人才加入滴滴。于是在去年的11月份，我们团队开源了cube-ui，到现在为止收到的反馈还算不错，也陆续有一些同学在生产环境也开始使用。cube-ui和其它同类型的开源组件库有一个很大的不同，它内部了使用了一个我们团队玩出来的“后编译”技术，它能帮我们玩出很多花样，比如减少组件包体积、支持rem、支持自定义组件颜色等等，但带来好处的同时也会有一些不便（webpack的配置会略显复杂），因此我们团队也为cube-ui
CSS经典布局之Sticky footer布局
我们常见的网页布局方式一般分为header（页头）部分,content（内容区）部分和footer（页脚）部分。当页头区和内容区的内容较少时，页脚区不是随着内容区排布而是始终显示在屏幕的最下方。当内容区的内容较多时，页脚能随着文档流撑开始终显示在页面的最下方。这就是传说中的Stickyfooter布局。是不是很容易理解。不理解的小伙伴也没关系下面我就举个简单的例子。举个栗子当内容较少时，正常的文档流显示如下图：在正常文档流中，当内容较少时，页脚部分不会始终固定在屏幕的最下方。这时候就该让传说中的sitckyfooter布局出现了。stickyfooter布局效果如下图所示：不管内容区有多少内容，页脚始终显示在屏幕的最下方，当内容区域超过屏幕的高度时。页脚会始终显示在页面的最底部。现在小伙伴们彻底认识stickyfooter的真面目了吧，下面让我们一起看看它是如何实现的。Stickyfooter布局实现负margin布局方式html代码：
原生的Ajax实现
1.原生js中的构造函数XMLHTTPRequest()构造实例；考虑兼容问题：if(window.XMLHttpRequest){varxhr=newXMLHTTPRequest();}else{varxhr=newActiveXObject();}2.实例化为对象后，要创建一个请求，准备好一个请求的发射窗口状态；xhr.open("get/post","请求地址",true);3.send方法发出请求，参数是发送的报文体，get方法时报文体为空null，post方法才有内容；xhr.send(null);4.JS中需要监听数据什么时候回来的机制，使用一个事件监听就绪状态，当xhr的状态改变是触发；xhr.onreadystatechange=function(){if(xhr.readyState==4){//xhr的readyState有5个数值，表示不同状态，4表示接受文件完成，{}内表示接受完成之后执行的操作document.getElementById().innerHTML=xhr.r
C#设计模式之二十三解释器模式（Interpreter Pattern）【行为型】
C#设计模式之二十三解释器模式（InterpreterPattern）【行为型】一、引言今天我们开始讲“行为型”设计模式的第十一个模式，也是面向对象设计模式的最后一个模式，先要说明一下，其实这个模式不是最后一个模式（按Gof的排序来讲），为什么把它放在最后呢？因为我们在业务系统中写一个解释器的机会并不是很多，实践比较少，理解和应用该模式就有些困难，所以就放在最后来说。该模式就是【解释器模式】，英文名称是：InterpreterPattern。按老规矩，先从名称上来看看这个模式，个人的最初理解“解释器”和Google的中英翻译功能类似。如果有一天你去国外旅游去了，比如去美国吧，美国人是讲英语的，我们是讲汉语的，如果英语听不懂，讲不好，估计沟通就完蛋了，不能沟通，估计玩的就很难尽兴了，因为有很多景点的解说你可能不明白（没有中文翻译的情况下，一般情况会有的）。所以我们需要一个软件，可以把中英文互译，那彼此就可以更好的理解对方的意思，我感觉翻译软件也可以称得上是解释器，把你不懂的解释成你能理解的。我们写代码，需要编译器把我们写的代码编译成机器可
CsvHelper文档-6类型转换
CsvHelper文档-6类型转换CsvHelper使用类型转换器来转换string到对象，或者对象到string；ITypeConverter类型转换器的结构，必须实现；publicinterfaceITypeConverter{stringConvertToString(objectvalue,IWriterRowrow,MemberMapDatamemberMapData);stringConvertFromString(stringtext,IReaderRowrow,MemberMapDatamemberMapData);}ConvertToString转换一个对象到string参数value:被转换的对象可以是值类型也可以是引用类型。row:允许转换器写入的IWriterRow接口可以访问configuration和上下文。memberMapData:设置的映射数据，映射被转换的成员ConvertFromString把string转换为对象参数text:要转换的字符串r
Dotnet Core Windows Service
在dotnet中有topshelf可以很方便的写windows服务并且安装也是很方便的，命令行运行.exeinstall就直接把exe程序安装成windows服务。当然代码也要做相应的修改，具体的可以参照例子。在dotnetcore2.0中我们也有一个很方便的dll来试用https://github.com/PeterKottas/DotNetCore.WindowsService通过Nuget来安装Usingnuget:Install-PackagePeterKottas.DotNetCore.WindowsService方便多个服务我们先定义一个接口publicinterfaceIBaseService{voidStart();voidStop();}具体的实现呢我举个例子，在例子中我们试用了个Timer，定时的完成某些任务，这样我们就可以同时写好几个service只要继续IBaseService就
利用Service Fabric承载eShop On Containers
利用ServiceFabric承载eShopOnContainers从模块化到微服务化从PetShop到eShoponContainer都是Microsoft在技术演进的路径上给开发者展示.Net的开发能力和架构能力的Sample工程，Petshop的时候更多的是展现应用的分层架构，设计的抽象与模块间的通讯。到了eShoponContainer更多的关注在架构设计与微服务化的，下面我们先来看看eshoponContainer的架构图在上图，我们可以看到后端服务分成了Identitymicroservice(验证服务)Catalogmicroservice（商品分类服务）Orderingmicroservice（订单服务）Basketmicroservice（购物车服务）Marketingmicroservice（市场营销服务）Locationsmicroservice（地理位置信息服务）在以前的分层架构中，通常这些服务都是以某一模块来体现的，为什么现在要将他们拆分成了各个服务呢？当我们从业务场景上
Rabbitmq--topic
一、前言前面讲到direct类型的Exchange路由规则是完全匹配bindingkey与routingkey，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到bindingkey与routingkey相匹配的Queue中，但这里的匹配规则有些不同，它约定：routingkey为一个句点号“.”分隔的字符串（我们将被句点号“.”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”bindingkey与routingkey一样也是句点号“.”分隔的字符串bindingkey中可以存在两种特殊字符“*”与“#”，用于做模糊匹配，其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）以上图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routin
程序员，你迷惘吗？
图片来自网络文/JamFF程序员的职业规划，在工作2到3年时确立最佳。这时褪去新人的标签，有一定代码的积累，可以得心应手的完成工作，完整的做过几个项目，对产品运作以及行业知识有了一定了解。这个时候就要去想一想，自己擅长做什么？未来要做什么？职业规划的重要性很多人说程序员是个青春饭，随着年龄的增长，30岁以后，脑子反应变慢，加不起班，身体处于下坡路，恨不得拿着一把冒蓝火的加特林，守着公司前台，生怕被刚毕业的学生抢了饭碗。刚入行时，很反感这句话，几年下来，慢慢的也就认同了。不是你没有实力，而是公司认为你没有年轻人的精力和激情去完成工作。Java之父在Facebook上也曾吐槽过，自己在面试时受到了年龄歧视。由此可见，尽早的进行职业规划，绝对是有必要的。正视自己，直面人生知人者智，自知者明。清楚的认识自己，不断的自我修正，才能得以进步。下面列出一些品质，但不局限于此，大家可以对号入座。高智商，表现为工作效率高，学习能力强，同事经常向你请教问题，并且能很快的给出思路、定位bug、解决问题。高情商，表现为乐观开朗，抗压能力强
视频演讲： 京东商城无线端运营后台（通天塔）架构演变
40:01概要京东商城无线端运营平台（通天塔）是一个服务于京东商城移动端用户及京东集团运营人员／采销人员／设计师／前端开发工程师的大型分布式在线电商页面生成系统（包含安卓，ios，h5页面搭建生成）。系统承接京东商城无线端618及其他重大运营项目需求，日访问量峰值超过10亿。本次分享以近两年通天塔系统后台架构演变为实例，介绍如何设计高并发，高可用的适应电商敏捷运营在线运营系统。个人简介王宁，京东商城，后台开发Leader，8年互联网行业从业经验，先后供职于EA，腾讯。专注于各类后台系统架构设计及实践。目前为京东商城后台开发leader，从0开始设计架构亿级京东无线端运营后台（通天塔）系统。目前主要负责京东商城无线端运营后台（通天塔）及京东商城无线端各类综合促销项目后台。QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开
中小型研发团队架构实践：如何规范公司所有应用分层？
一、写在前面应用分层这件事情看起来很简单，但每个程序员都有自己的一套，哪怕是初学者。如何让一家公司的几百个应用采用统一的分层结构，并得到大部分程序员的认同呢？这可不是件简单的事情，接下来以我们真实案例与大家一起探讨，先问大家两个技术问题：服务的调用代码你觉得放到哪一层好呢？A表现层B业务逻辑层C数据层D公共层如何组织好VO(ViewObject视图对象)、BO(BusinessObject业务对象)、DO(DataObject数据对象)、DTO(DataTransferObject数据传输对象)呢？不同的人会有不同的答案，所以要统一公司应用分层，以减少开发维护学习成本。统一应用分层要可大可小、简单易用、支持多种场景，我们采用IPO方式：I是Input、O是Output、P是Process，一进一出一处理。应用系统的本质是机器，是处理设备，一进一出一处理。IPO原理图二、统一逻辑架构统一应用分层的逻辑架构图职责说明：
迷你书： 架构师（2018年1月）
卷首语：程序员的中年危机还未到来作者徐川2017年12月10日，中兴研发主管欧建新，在公司大楼一跃而下，在程序员群体里也掀起了对中年危机的讨论。需要指出的是，当事人所处的行业是通信业，并不是互联网与IT业。真正席卷行业的中年危机，是整个行业高度成熟，进入洗牌阶段、不需要那么多的研发来开拓进取才会发生，其它的，只能看做是危机管理没有做好的个案。国内互联网高速发展已经有二十余年，在可预见的将来，还会如火如荼的发展下去。越来越多的行业主动拥抱互联网，越来越多的创业公司发生在互联网，只要这样的趋势持续，我们仍然有大量的编程需求，手里有真功夫的程序员不会愁没有饭吃。现在那么多的程序员中年危机论，要么是无病呻吟，要么是危言耸听。不过，程序员需要具备危机意识，未雨绸缪。一年经验可以用十年，但二十年三十年则必然被抛弃。互联网的技术更新很快，程序员必须终身学习，这是选择了这个职业的宿命。架构对于程序员来说是一座山，入行时只关心自己的几亩地，只有到处多走，才有机会得窥山的全貌。只有站在山顶，程序员的修行才算圆满。很多思想和理念是通用的，
架构师必须掌握的知识看这三张图就够了
我们在网上经常看到如何成为架构师？怎样才算一个合格的架构师？为什么你不是架构师？却很少有人告诉你如何脚踏实地的一步一步的学习架构的知识，具体的知识点如何知道?哪些才算是架构师必须知道的知识点？下面几张图为你归纳了系统的知识点：我们一起来看看我们看过了前两个系统的知识图的时候我们已经大致的了解需要知道什么知识，这仅仅只是开始而最重要的是如何获得：我们可能具有1-5工作经验的，面对目前流行的技术不知从何下手，遇到技术瓶颈，也可能在公司待久了，过得很安逸，但跳槽时面试碰壁。想要拿更高的薪资，自己所学的知识点没有系统化，很难在技术领域继续突破。需要大神讲解知识点，分享知识，那么Java大神交流群5-6-1-6-1-4-3-0-5每天给你们免费分享一个知识点。下面的知识你愿意与我们一起学习嘛而下面是多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知！
深入理解MySQL 5.7 GTID系列（一）
摘要：MySQLGTID特性是5.6加入的一个强大的特性，它的目的在于使用GTID的MySQL能够在整个复制环境中能够自动地切换，而不像以前需要指定文件和位置，这也一定是未来发展的方向，我们熟知的MGR也是基于GTID的，所以了解GTID的原理也是必要的。MySQLGTID特性是5.6加入的一个强大的特性，它的目的在于使用GTID的MySQL能够在整个复制环境中能够自动地切换，而不像以前需要指定文件和位置，这也一定是未来发展的方向，我们熟知的MGR也是基于GTID的，所以了解GTID的原理也是必要的。GTID的维护是完全自动的，但是实际使用上确实有较多的坑，也导致很多朋友对GTID还是觉得畏惧，本系列文章将从GTID模块的源码出发分析，并且给出总结，然后结合运维和案例进行综合的解析，我希望抛砖引玉让希望了解源码的朋友也有所收获，但是能力有限特别是源码部分如果有错误请指出，并且能够一起交流，如果有朋友有更好的案例也欢迎一起探讨。当然留下这么一个系列也有自己的原因，好记性不如烂笔头嘛，因此也当自己的一个笔记了。一、GTID事务的生命周
教你用webpack搭一个vue脚手架[超详细讲解和注释！]
在自己对webpack有进一步了解的同时,也希望能帮到一些刚接触webpack的同学.脚手架已放上github,不想听我啰嗦的同学可以直接去download或clone下来看哦.脚手架里都有详细注释！https://github.com/webfansplz/xc-cli.git觉得有帮助到你的同学给个star哈,也算是对我的一种支持！3.脚手架结构├──build构建服务和webpack配置|——build.jswebpack打包服务|——webpack.base.conf.jswebpack基本通用配置|——webpack.dev.conf.jswebpack开发环境配置|——webpack.prod.conf.jswebpack生产环境配置├──config构建项目不同环境的配置├──public项目打包文件存放目录├──ind
2018前端值得关注的技术
1.前言2017悄然过去，2018已经来到。人在进步，技术在发展。2018年前端有哪些领域，技术值得关注，哪些技术会兴起，哪些技术会没落。下面就我个人的判断进行一个预测判断，希望能对大家起到一个参考作用！下面提及的技术，只是建议大家关注，也不是建议大家全部的都要学，而是建议大家按需学，自己觉得哪些需要学，对哪些有兴趣就学哪些！如果大家有什么工具，框架，库觉得可以推荐的，欢迎在评论区提点，让大家相互进步，学习！2.PWAPWA(ProgressiveWebApps)由谷歌提出，用前沿的技术开发，让网页使用如同App般的体验的一系列方案。明确的一点就是：PWA就是一个网页,可以通过前沿的技术开发出一个网页应用。自从谷歌提出PWA后，就持续的获得了业界的关注，热度可见一斑。就在今年，谷歌也宣布：PWA将获得与安卓原生应用同等的待遇与权限。这就意味着以后的网页基本和APP将越发将近，那么关注度将会进一步的上升。资料参考：PWA入门:写个非常简单的PWA页面【转载】你的首个ProgressiveWebApp
记一次封装Axios的经历
前端开发中，如果页面需要与后台接口交互，并且无刷新页面，那么需要借助一下Ajax的http库来完成与后台数据接口的对接工作。在jQuery很盛行的时候，我们会使用$.ajax()，现在，可选择的就更多，例如：SuperAgent、Axios、Fetch…等等。有了这些http库，我们不在需要关注太多与ajax底层相关的细节的问题。很多时候和场景下，只需要关注如何构建一个request以及如何处理一个response即可，但即便这些http库已经在一定程度上简化了我们的开发工作，我们仍然需要针对项目的实际需要，团队内部技术规范对这些http库进行封装，进而优化我们的开发效率。本文将结合我们团队使用的一个http库Axios和我们团队开发工程的一些场景，分享我们前端团队对http库进行封装的经历。对http库进行基本的封装服务端URL接口的定义以用户管理模块为例。对于用户管理模块，服务端通常会定义如下接口：GET/users?page=0&size=20-获取用户信息的分页列表GET/users/all