云打包所使用到的JavaWeb、.netWeb、androidapk,iOS等项目的构建环境是一样的，不同之处在于，CI系统直接拉取源代码进行构建，而云打包，需要增加Setting服务、程序模板库，通过Setting+程序模板库生成客户定制好的源代码，接下来就是使用生成好的源代码进行构建，完成云打包。
云打包平台搭建教程
在CI系统搭建教程的基础上，增加云打包面板、软件模板仓库(SoftTpl)、客户产品仓库（SoftPrd），其中云打包面板提供Setting服务，收集用户对软件的个性定制信息，比如logo、包名、提示语、欢迎页等等，SoftTpl仓库存放软件模板，SoftPrd存放整合了用户定制信息的软件源代码仓库，是以SoftTpl为基础，加入了用户定制信息的源代码仓库。
云打包与CI基础设施共享
从本文封面以及安装部署教程上简易的推导就能得到一个合理的结论，云打包可以完全重用CI系统的基础设施，只是需要一个云打包管理后台，利用CI所提供的打包构建环境进行个性化打包操作。当然如果云打包面向全网提供打包服务，打包服务器的数量要求上会有很大的不同。没有太大的服务压力的话，与CI共享基础设施是不错的选择。
看到这里，你应该可以：
4.为xxx打包个性化APP
今天就写到这里，先小睡一会儿~
技术岛公众号
个人参与JBlog预期收获
企业参与收获
将公司团队打造成一支敏捷开发团队，构建全自动的CI系统，理顺研发流程，持续的产品研发交付能力！
正文
每个开源项目的背后，都有一群为梦想执着的人！从asp+access到.net+mssql到php+mysql到java+mysql，见证技术变迁！用过wordpress，用过blogengine，用过phpcms，用过dedecms，各式各样的建站系统！随着版本的迭代，很多产品越来越成熟，也离梦想越来越远！很多时候，功能越多，并不意味着适合自己。
对于写博客来说，WordPress是很流行，我也是一名wordpress用户，但是一直磨灭不了自己要写一个自己的博客小系统，感觉自己写的，才能真正满足使用需求，而不是被别人所牵引。
相信很多人都有这么一个小小梦想，就是拥有一个自己的小系统，亲手打造，能被众多“信徒”所喜爱。很多人没有亲眼见证过一个系统从无到有，从无人使用到广受欢迎的历练过程。或许JBlog是一个小白成长的不错选择。
JBlog发起人是一位技术大佬，拥有15年工作经验，从大佬的博客上所见，在大数据搜索、游戏开发、自动构建、技术管理、CMS系统架构、网络管理等领域都有深入的研究。
JBlog将从无到有，从一个简单的小博客逐渐壮大起来！这个过程是漫长的，值得期待了，更是小白的一次历练机会！学会从无到有，从0基础到掌握系统研发、架构、管理！
如何参与？
JBlog部署
JBlog的文档在大佬的公众号里都有提到，不再赘述！
代码贡献
JBlog采用Github管理，代码贡献要通过大佬审核，大胆的fork，push吧！
理财的方式是多种多样的，储蓄也算是一种理财，股票、基金、黄金、白银网货也不例外。对于理财来讲，都存在一定的风险！从收益与风险的平衡来讲，个人比较倾向于网货产品。即能获得稳定的收益，风险也在可控范围内。目前宜信推出的新人专享加注册红包，折算出来的预期年化率可达30%，新人体验福利首选！
一、为啥排除股票、基金、黄金、白银
搞IT，基本上等同于加班族！盯盘，宏观经济分析，业务趋势研究，这些经济方面的东西，并不是所擅长的。何况，故事有1挣2平7亏的“魔咒”，即只有10%的人能挣到钱，余下的都是炮灰。风险还是比较大的。
二、网贷
网贷产品，选择一个靠谱的平台，还是比较省心的。预期的收益也比较稳定，也用研究这研究那的。当然，选择平台也是一门学问。选择网贷创始平台，选择三证齐全的平台，算是给自己的血汗钱找个安心稳定的家。
网贷行业是一个发展迅猛又有争议的行业，经历了快速发展，行业洗牌！行业的乱想也引来了各种监管措施，从资金存管到等级保护，从存量控制到良性清退！每当一个新型的行业出现，都会引来一波跟风的，洗牌再所难免！我的选择是网货创始平台宜信，其他平台都是跟风的。
网货平台资质
开户流程
今天介绍的宜信网贷开户流程！目前宜信提供的不仅仅是网贷，涵盖了全球资产配置、海外游学、投资置业、全球移民、家族信托等服务！
一、选择出借产品
新客户注册时会送292元红包，首次出借时，可以选择新手专享产品！
二、完成实名认证
首次出借时，点击产品页的“确认出借”后，APP会提示您进行实名认证。
三、绑定银行卡
实名认证通过后，APP会提示您绑定银行卡
四、风险测评
绑定银行卡后，APP会提示您进行风险测评
六、确认订单并支付
七、查看我的财富
宜信不仅提供网贷服务，还有更多全球资产配置服务！涵盖了移动、资产配置、家族信托等等。
离岸家族信托
离岸信托流程
图书云公众号二维码
图书云共享图书
一、为什么要使用elasticsearch
选elasticsearch,冲着开源免费，内置Lucene分词，在主自搜索引擎这块，es还是很有名气的。相比较于关系型数据库，elasticsearch倒排索引，能有更加高效的搜索性能。对于一般企业来讲，重复造轮子的成本太大，使用es算是一个不错的选择。
二、自主搜索引擎的基本组成
自主搜索引擎主要由elaticsearch安装、数据同步服务与ElasticSearchHighlevelAPI三大块组成。下面分别介绍这三大块。
2.0安装elasticsearch
安装教程之前有专门写了一个小白序列，可以参考。
2.1数据同步服务建立es索引
数据同步服务，即将需要用于搜索展示的数据组装好，同步到es，这个过程是利用es建立索引的过程。服务一般以后台服务的形式定时执行。我们的做法是，针对需要查询的数据，写操作日志，包括增、删、改操作，同步服务定时检查日志，将数据同步到es上。一般是多个表组合好的业务数据，对应es上的一个索引类型。若是同步服务写得好，应该可以将同步服务做成透明的，通过配置，直接将数据对接到es，显然，我们没有造这种“面包机”，我们在mysql里有建立操作日志，专门用于es同步。同步服务会记录操作日志进度，不断同步业务数据到es.基本上，写完这个服务，基本上就完成很大一块工作了，成功的希望就在眼前。
2.2使用elasticsearchHighLevelAPI查询数据
你可能会见到的包引用，以java为例
POM包
本文从应用的角度介绍了如何运用Elaticsearch搭建自主的搜索引擎解决方案，从环境安装、索引建立、同步索引数据，到使用ElasticHighLevelAPI进行数据查询，覆盖了一个简易自主搜索引擎的全生命周期，小白可参考本文实现一个自主搜索引擎，遇到问题可回复ChinaHadoop，得到指导与帮助。
活动介绍
活动礼包：292元活动红包
活动亮点：新人抢月标，折合预期年化近30%！
宜信介绍
宜信创建于2006年，总部位于北京。宜信是一家从事普惠金融和财富管理事业的金融科技企业，在支付、网贷、众筹、机器人投顾、智能保险、区块链等前沿领域积极布局，通过业务孵化和产业投资参与全球金融科技创新。成立十一年以来，始终坚持以理念创新、模式创新和技术创新服务中国高成长性人群、大众富裕阶层和高净值人士，真正的让金融更美好。
宜信荣誉
GlobalView
宜信星火平台可提供专业一站式全球资产配置服务。资产配置的优势：可以拥有更多的投资机会，最大限度提高收益，加强投资流动性；保障子女教育、养老规划、投资移动等各类支出需求。
强大风控实力
宜信凭借13年丰富行业经验与数据积淀，以“4+1道防线”进行资产管理，科技建模、信用评分、信息整合、智能防欺诈等，全流程风控体系科技完备抵御风险！
智库
宜信坚持从本源出发积淀发展能量，严选全球数十家顶级智库，建立长期深度合作，通过与强大外脑的知识经验碰撞，辨别行业前景，解析发展方向。
第三方资金存管
宜信是全国最早进行资金存管的平台之一！2015年7月，宜信即与广发银行达成合作，2018年3月，存管帐户再次安全升级。客户可在宜信星火直接开户，出借更安心！
国际化精英团队
宜信拥有行业顶尖的管理与服务团队，曾任职顶级团队国际银行的风控牛人，国际名校，500强名企出身的技术大加，以一流经验和顶级水准推动企业进步发展！
信息系统安全等级保护备案证明
在信息系统安全等级评测中，宜信成功取得“等保三级”认证，这是我国对非银行金融机构的最高认证，也被誉为“史上最难认证”！
电子签章
宜信已全面上线电子签章功能，通过网络技术实现签章管理高度技术化，为用户提供更便捷高效的安心服务体验。电子签章优势，合规有效，具备法律效应享合法权益；高效便捷，客户可随时随地调取查验；安全保障，加密护防篡改伪造销毁！
快捷支付限额表
网银支付限额
投资有风险理财请谨慎
一、私人图书馆
每个IT人士，或多或少都会有些图书，这些书一点也不便宜！尤其是外文原版图书，看完也舍不得丢了，当废品卖了，更是心疼！建立一个自己的私人小图书馆，让朋友邻居借着看，感觉就是不一样！
1.1巧用扫码录入
图书云支持扫码录入图书，扫图书的条形码，可直接将图书录入到平台，结合lbs技术，可让周围的朋友看到自己的图书！快速高效录入！
1.2巧用书单码
二、图书云企业图书馆
图书云不仅支持私人图书馆、企业图书馆，也支持更多应用场景，可建立社区图书馆、微群图书馆、俱乐部图书馆、社区图书馆！更多的应用场景等着大家去发现！ChinaHadoop欢迎各位小伙伴共享Hadoop大数据图书，共同建立以大数据为主题的线上虚拟图书馆！
图书云共享创建价值
有人的地方，就有江湖，有输入框的地方，就有注入风险！有输入框的地方，就有敏感词！敏感词就像一个平台杀手，可能直接导致平台被封锁！
敏感词可能是脏话，也可能是不同文化背景下的禁词，也可能是政治敏感词汇，等等，敏感词可能导致平台遭受法律或政策的制约。举个简单的例子，非法涉黄的网站可能直接被取消网站备案，无法在中国大陆访问。不做敏感词的后果是相当严重的。
做为一个程序员，一个开发工程师，一定要掌握敏感词算法么？工程师分为很多派系，对于做搜索的工程师，算法，b树，敏感词过程，应该要从底层，从设计到实现都不能放过！做为应用工程师（小白程序员），能掌握算法原理，并能使用，我觉得就好了，树叶有专攻！来来来，来一段算法描述。目前查到的敏感词过滤算法。
一、敏感词少的情况
如果敏感词少的话，就直接使用replace,indexOf等等来搞定吧，只是这种情况存在的可能性太小了。敏感词可以说是很多很多。不过，不讲究效率的地方，能实现业务要求的话，使用这种方式也可以。
二、敏感词较多的情况
敏感词受政治、人文、种族各种因素影响，词汇量较多，要做到全面的过滤，自然要考虑考虑算法的设计，以保证过滤的高效性。在这里介绍网上流行的一种敏感词过滤算法。深入了解专业算法已经超出了本文的范畴，请自行找其他资料查看。网上流传的算法，主要是将敏感词库放到树型数据结构中，将带过滤的文本投射到敏感词树上，命中的就是踩到敏感词。用树型结构体加速匹配速度。
2.1构建敏感词树
2.2投射文本
把文本填充到敏感词树上，就能直观的看到哪些敏感词覆盖到了。如果有人在平台发布违禁信息，可以快速识别出来。在这里使用投射文本描述，只是为了描述算法，具体实现就看代码。如图所示，投射到树上文本“傻逼”，就是被发现的敏感词。
敏感词过滤算法的核心就是这两步！一棵敏感词树，一次投射文本，就能把敏感词全遍找过来，高效！
说到WebSerivce，会想到很久很久前的SOAP，第一次看到的时候，觉得就一个神马。在.Net环境下使用过，导入WebService，直接使用，似乎也是很实用的一种跨平台跨系统的操作体验。单纯在.net体系，是感受不到WebService的阵痛，在java下，才是WebService爬坑的最佳土壤。这个故事的主题在于java与.net两个平台实现的差异，在于厂商实现的异常。
一、.NetvsJava
相比较于java，.net体系下的WebService，选择更单一，用ms的就好，直接用ide导入webservice。玩java的话，axis1,axis2,ide导入，wsimport命令生成，还有wsdl2java命令。
二、厂商之争
就实战经验来看，不同的厂商对soap的实现，还有差异。.net发起的soap报文是
方案一ide导入
直接使用eclipse导入WebService，同样的方式导入，STS却导入不了。所以实操过程中，选择eclipse导入。针对java平台的WebService调用，调用正常。但是调用一个神秘的WebService，一直报soap报文格式不对。如果没有记错的话，当时eclipse导入WebService，生成的是axis1的实现。网查axis1对于soap请求头处理，就是一个Bug。所以方案一，被丢掉了。
方案二前辈方案+axis2
想着axis1搞不了的事情，兴许axis2能做。当被告之有方案借鉴时，感觉看到了希望。不过，没有看到操作手册，也不知道代码是怎么生成的。从包引用上来讲，用的是axis2，这个就是为什么有axis2方案尝试的原因了。也是迷惑人的地方。因为引入的包，压根没有使用到。但是从代理类的生成风格上来讲，还是具备排版精良的影响。使用axis2的代理类生成工具，生成完代理类之后，吓死了，感觉生成的代码就是一团芝麻糊，于是，直接丢掉了。为什么别人生成的axis2代理类这么优秀，而我生成的惨不忍睹？
方案三wsimport方案
绕了半圈，回到了javasdk自带的wsimport，直接在命令行输入wsimport，会有提示。存放代理类的文件夹不存在的话，还不给生成，这个有点小小的坑。
wsimportcommand
采用wsimport生成的代理类竟然跟4年前同事留下的对接项目代码是一样的，于是修改soap:env就有着落了。实战证明，前辈们留下的代码管用。关键的代码就是自己实现一个报文处理的Handler，然后在Soap代理类调用时，先设置Handler!
方案不足之处
采用wsimport生成的代理类指定了wsdl位置，这个看起来怪怪，但是这种方案能修改soap请求报文，可以默认接受了这个让人心头有点痒痒的方案。
WebService优化
采用单例优先代练类的创建，能提升压测值。在未使用单例优化时，空接口也无法通过5000/min压测，采用单例优化后，可以通过。最终的优化方案为：
受控环境下的WebService联调技术
WebService与区服切换
思考
今天的思考题：sonarqube报很多漏洞很多bug的代码是不是好代码？请留下您的思考答案。
结束语
WebService从诞生到现在，越来越不受待见了，越来越多的人喜欢采用更轻量级的WebAPI来代替WebService，采用JSON，采用更加透明的跨平台方案。但是WebService并没有死，因为生成代码还是一个优点。如果再次在java平台下对接WebService，请优先考虑jdk自带的wsimport进行代理类生成，可通过自定义SOAPHandler达到更好的兼容性。如有更好的方法，请留言告之。
一、压测反推工程结构
压测与代码工程结构的千丝万缕关系。从压测的角度来看，代码至少要分成两部分，一是可控代码，简单的说，就是项目中的业务代码，因为是自己写的，所以可控性很强，压测的时候，可以针对性优化；二是不可控代码，像调用的第三方接口，这种没法自主控制。如图示，agent中存放与第三方交互的代理类。压测的时候，区分开可控代码与不可控代码。可控的代码就自己优化，不可控的代码，如果是公司团队提供的，就去沟通一下吧，对于外部公司的Agent，那真的是超级不可控了，直接忽略吧。在工程结构上来分析，建议Agent的异常要及时抓住并记一条神奇的【甩锅】日记，看看日志，就能快速定伴Agent对应的团队人员，找到快速处理问题。最好，把第三方的交互统一加上try-catch，记下异常。这样子，可控与不可控就划得很清楚了。
二、不要迷信核心代码
这次压测，压到一个神奇的核心库Bug。具体表现为,controller捕获了2%左右的失败，有时候又没有错，这个错误一直在0%到2%的样子。为了查这个压测失败的问题。查看失败日志，能定位到Ip获取环节。但是不知道为什么会失败，断点调试，一切都是正常的，只是压测的时候，总能重现异常。
难道核心库有问题？这个简直不敢想，对于核心库，一直以来都是膜拜啊，拿来用，没有想过核心库会有Bug。但是面对压测的数据，又没法排除核心库的嫌疑，只能对核心库代码进行排查了。
如果构建核心库的时候，把源代码打进去，我觉得对于使用者来讲，绝对是一个福音。可惜我面对的这个核心库没有，还好之前把源代码打进去了。单个调试一切显示正常，压根调试不出任何问题。简单就是诡异到头了。
肿么办，抓掉几根头发后，突然灵光一闪。直接把代码Copy出来，将ip获取的代码逻辑加上步骤日志，从第一步到第六步，一一打出来，进行压测，日志显示，所ip获取的时候，步骤都是正常的。但是期间能出现还是出现了异常。看步骤的话,从request中取ip的代码逻辑并没有出现bug。面对诡异的压测结果，那就再想想。
看样子，从reqeust中取ip的逻辑没有问题，那就把取ip的地方加上try-catch抓一下日志。果真发现Bug了，使用ip的时候，出现了ip为空，导致异常了。
static误用示范publicclassIp{privatestringaddress;privateintipNumber;privateIpip;privateIp(){//sonarqube说禁止外面创建实例}publicstaticgetIp(Requestreqeust){ip=newIp();.......//相信我，这里是复杂的ip识别与获取逻辑......}publicStringgetIpString(){returnip.address;}}压测的时候，不要迷信核心类库，把工程分成三大块，业务代码，核心类库，agent，对应三种不可控级别的代码。业务代码自己搞定，核心类库慎重的找人处理，并[AT]尽量多的人，Agent找人处理或者直接排除掉。
三、压测与机器配置
压测就像一面照妖镜，英雄不问出处，是驴是马，拉出来溜溜就知道了。面对事实的标准，如何才能将压测做得更好呢？
1、压测环境与压测要匹配
在一个标准性能环境下，达到一个预期的压测值。这个标准环境，比如cpu,硬盘读写性能，可以是一个标准的。或者拿一个基准接口进行压测定值，先测算出环境本身适合的压测值。这样子，压测才能正常的进行。
2、压测环境最好有多个
接口多，接口要一个一个压，一个环境不好并行压。能有多个环境最好。不知道下次压测能不能实现，毕竟要有机器。
3、核心类库必过压测
核心类库都过不了压测的，放在核心类库里，这个有点点坑啦。又要用核心类库，又要过压测，没解。核心类库打上源代码，压测的时候，还可以用源代码进行压测调试。但是希望是通过压测的才放进核心类库，不要等业务代码进行压测的时候，再来找出核心类库的Bug.
4、核心类库必过sonarqube
为什么又扯到sonarqube，其实这个工具的强大之处在于，能分析出很多坏味道与bug，人不同于工具，工具在于将所有可性能全面覆盖分析，人没人注意到的地方，sonarqube可以注意到。这次压测就发现，核心库代码的规范性，并没有想像的美好。sonarqube找出了一堆坏味道，还有bug.
这次压测实战，感觉收获还是很大的。对于工程结果的理解，对于异常的捕获处理，对于核心库的优化改进，都有了新的认识，对于压测，也有了自己一套方案。希望你也能从中学到宝贵的经验！
单元测试，问问自己写不写单元测试？
第一次写单元测试的时候，老把测试驱动开发混在一起。第一次看到powermock出来的单元测试代码，都想吐。这代码看起来真心的“恶心”至极。10行代码，也许得造100行单元测试代码出来，这可能说得稍微有些夸张，就是单元测试代码量超级多的感受。如果要实现100%的单元测试，简单会是一个极大的挑战。代码量会指数级增加。
关键词：Powermock
写单元测试，我说的是java，我们使用powermock、mock、testng这种东东，相信你知道怎么去了解更加详细的信息。这里就不帖一些没有态度没有温度没有人文感受的文字过来了。
秀几行
UserBeanuser=mock(UserBean.class);when(user.getUserById(anyInt())).thenReturn(newUserBean());doNothing().when(user).sayHello();这是最常用的几行代码，基本上就是依靠他们，模拟所有代码行为进行单元测试。
恶心？
是的，第一次见到他们，不恶心才怪，得一点一点mock，对于静态类等特殊的成员，还得找法子去mock,把每个分支都覆盖到，最后实现100%的覆盖率。
单元测试的意义
之前我的感觉是单元测试是帮我们找出当前代码问题，而写完单元测试之后，到没有这种感觉，反而是，防止今后别人不小心破坏了当前已经验收通过的代码。如果按我们写mock的方式进行全面覆盖的话，别人只要改变一个逻辑，都可能导致单元测试失败，从而发现风险。
单元测试的权衡
因为我们只要求单元测试在service层实现100%的覆盖，所以我会爱上，单元测试，如果要在bll层，覆盖的话，我可能会改变哦。bll层太多的细枝末节，mock起来遇到一股意想不到的代码风暴。而service层则不同，对于我们来讲，service层是负责组装的，mock的时候就能巧妙的实现快速覆盖，避免mock中常见的特殊的静态类啊，还可以避免过多的if要覆盖。如果想要挑战自己的单元测试实力，那就是去写bll层的单元测试，嗯，相信是史无前例的挑战！
单元测试与sonarqube相爱相杀
单元测试要覆盖所有的逻辑分支，按copy复制再修改修改的写法，重复代码会直接捅破sonarqube的底线，直接不给过啊，重复率太高了。写单元测试的时候，都有种冲突，把sonarqube关掉，哈哈！不关sonarqube，那就得重用重用自己的代码，不能复杂一口气复制一遍testcase出来。
一招让单元测试powermock与sonarqube和平相处
单元测试可以看着源代码，一点一点mock，遇到一个if就给个开关控制，一路下来，就产生了很多开关，这样子就能通过参数来控制一个公用的testcase实现全分支覆盖，同时又不会引起powermock报警。
秀一下伪代码
@Test[name="登陆失败-验证码错误",enable=true]publicvoidlogin_whenVerifyCodeError_thenFailed(){login(false,false,false,false,false,verifyMessage);}@Test[name="登陆失败-帐号锁定",enable=true]publicvoidlogin_whenAccoutLocked_thenFaild(){login(true,false,false,false,false,verifyMessage);}......privatevoidlogin(booleanisVerifyCodeOk,booleanisAccountLocked,...){when(verifyAgent.check(verifyCode)).thenReturn(isVerifyCodeOk);....}这段伪代码是秀出最近摸索出来的，用来防止单元测试出现大量重复代码。通过传参，控制代码分支走向，达到即能覆盖到所有支付，又不会惹恼sonarqube.
巧用只在Service层写单元测试原则
service层写单元测试，也就是把琐碎的具体的业务代码放到bll层，service层保持一种组装bll业务的对单元测试友好的状态，就可以巧妙的避免写复杂的service层单元测试。为了，能快速搞定单元测试，这个原则可以合理的利用利用。还有一些小经验: