Send 是 Firefox 提供的文件加密共享工具，特点是端到端加密分享文件，链接到期即焚
Firefox 官方称其为「简单、私密的文件分享服务」，我个人认为 Firefox Send 适用于非内网环境下的短期文件分享，不适用于需要长期分享的文件。
例如，你想跟你朋友分享一个自己制作的视频，但是你们俩没在一起，微信传输不了太大的文件，QQ 和邮箱附件下载又比较慢，视频网站还要审核内容，那就可以上传到 Firefox Send 分享给朋友下载。
同一个文件多次上传不会有「秒传」的感觉，Firefox Send 的定位是短期文件分享，所以不去验证服务器上是否有相同的文件，文件分享到期后应该也会删除服务器上的文件，相对还是比较安全的。
项目地址： https://github.com/mozilla/send
fastmock可以让你在没有后端程序的情况下能真实地在线模拟ajax请求，你可以用fatmock实现项目初期纯前端的效果演示，也可以用fastmock实现开发中的数据模拟从而实现前后端分离。在使用fastmock之前，你的团队实现数据模拟可能是下面的方案中的一种或者多种
上面的方式中，不管哪一种方式，都会要求开发人员写一些跟项目本无任何关联的代码，第一个和第二个方式还会需要前端项目在本地引入不必要的js文件。比如下面的mock数据
// 产品配置
{
url: '/pms/product/list',
on: true,
type: 'get',
resp: Mock.mock({
'body': {
'currentPage': 1,
'isMore': 0,
'pageSize': 15,
'resultList|10': [
{
'productNo': '11111',
'productName|1': ['产品名称1', '产品名称2', '产品名称3', '产品名称4', '产品名称5'],
'productType|1': ['1', '2', '3', '4', '5'],
'status|1': ['1', '2'],
'gmtCreate': '@DATETIME("yyyy-MM-dd HH:mm:ss")',
'gmtModified': '@now("yyyy-MM-dd HH:mm:ss")',
'createUserCode': '@name'
}
],
'startIndex': 0,
'totalNum': 100,
'totalPage': 1
},
'reCode': '0000',
'reMsg': '成功',
'success': true
})
},
// 产品配置-贷款材料配置
{
url: '/pms/cfgLoanDoc/list',
on: true,
resp: Mock.mock({
'body': {
'currentPage': 1,
'isMore': 0,
'pageSize': 15,
'resultList|10': [
{
'loanDocCode|+1': 1,
'loanDocName': /[测试字体]{4,30}/
}
],
'startIndex': 0,
'totalNum': 100,
'totalPage': 1
},
'reCode': '0000',
'reMsg': '成功',
'success': true
})
},
// 产品配置-费用类型配置
{
url: '/pms/productFeeDetail/queryByProductNo',
type: 'get',
on: true,
resp: Mock.mock({
'body': {
'currentPage': 1,
'isMore': 0,
'pageSize': 15,
'resultList|10': [
{
'feeTypeNo|+1': 1,
'feeTypeCode': /[A-Z]{4,8}/,
'feeTypeName': '@name',
'incomeType|1': ['1', '2'],
'feeType|1': ['C', 'D'],
'ratio|1': ['0.5', '0.25'],
'productChargeBasis|1': ['1', '2', '3'],
'fixedAmount|1-100': 5
}
],
'startIndex': 0,
'totalNum': 100,
'totalPage': 1
},
'reCode': '0000',
'reMsg': '成功',
'success': true
})
}
上面的代码为mockjs的事例代码，更多mockjs相关资料参考链接mockjs文档
为此，我们将mock层独立出来，通过中间服务的形式在前端和后端服务之前建立一道围栏，使用fastmock，前端只需要修改自己的XHR请求地址，后端只需要在开发前和前端约定好接口文档即可。等到后端服务开发完成，前端再将XHR请求地址替换回来进行联调测试即可。
tip:当然，你也可以通过npm script不同命令加载不同配置文件的形式切换你的XHR地址，这里不作详细介绍。
如果你经常需要模拟接口请求，请点此快速通道
abel是一个基于goland实现的百万高并发及时通讯聊天工具。
阿贝尔来自英语中abel，感觉和本人很像，所以起名abel。英文中解释：诚实、可靠而且喜欢摸索新事物。 个性严谨，有责任心，情绪稳定。社交能力强，容易相处。渴望了解他人的内心世界，适合与人打交道的工作。富有爱心，家庭责任感强。处理问题较犹豫。
abel-im采用GO语言开发；底层实现技术gorilla/websocket、存储目前使用mysql(后续会改进)简单存储。采用ETCD服务注册发现；gRpc方式消息扩散；abel-im支持集群部署；自定义日志实现。
目前系统还停留在起步阶段，软件开发者对go语言理解还不够深技术水平有限。所以在阿贝尔还有很多的改进和优化地方。作为一个高性能的Im即时通讯系统来说分布式部署是至关重要，怎样能做到更好的扩容和应对紧急情况该如何处理，希望能得到网友指点。
目前消息存储是实时存储，如果高并发这种100%不行。单台机器这种长连接，连接数问题。突然间网络不稳定，客户端如何保证消息100%接收成功。
项目地址： https://github.com/kingmajun/abel-im
EDL 是一个弹性深度学习框架，其包含一个 KubernetesController、PaddlePaddle auto-scaler（可以根据集群中的空闲硬件资源改变分布式任务进程的数目）以及一个新的容错计算架构。
该项目致力于解决深度学习任务弹性的在资源通常不足的生产环境集群执行，尽可能早的帮助深度学习开发者分析出潜在算法问题，同时，Fluid 通过 API 与 Kubernetes 交互，以理解全局集群状态，并据此调整不同任务的进程数量。
从设计理念和实现思路来看，Paddle EDL和KubeFlow有非常多的相似之处。从开源的时间来看 ，二者也是同一时段，百度和谷歌的工程师对同一主题的几乎一样的理解。不过二者的确存在一些差别。
首先，KubeFlow目前只支持Tensorflow，而Paddle EDL目前只支持PaddlePaddle。而它们底层都依托于Kubernetes。Paddle EDL似乎对Kubernetes的整合更深入一些，比如利用可定制的资源分配方式，和自定义逻辑与Kubernetes API交互。而KubeFlow似乎直接使用Kubernetes一般性的功能。因此，在弹性调度这个功能上，PaddlePaddle采取的是前文讨论的EDL方式，而 KubeFlow现在是HPA方式。这是二者最大的不同。
另外，虽然二者都支持一般的Kubernetes+docker环境，KubeFlow和Google在深度学习生态系统中的其它开源项目一样，非常推崇在GCE上布署，深度整合Google云服务。而Paddle EDL并没有强调布署云的供应商服务。
由于Paddle EDL和KubeFlow都是刚刚开源的项目，更多的细节还在演化当中，我相信开源社区对它们的使用和理解会不断加深的。不过有一点可以肯定，Kubernetes和深度学习系统的结合将会越来越紧密，一个抽象层的，和Kubernetes API结合更紧密的，可调度不同后端训练系统(不再绑定Tensorflow或者PaddlePaddle)的项目也许正在孕育中。
项目地址： https://kubernetes.io/docs/concepts/architecture/controller/
Microserver 是一个零配置的库，用来运行 Java REST 微服务，通过 Java 标准 main 类执行。从 2014 年开始就一直在 AOL 生产环境中使用。
MicroServer.Instance文件夹下面存放的是微服务实例，至于微服务颗粒度的拆分得结合实际的业务情况。
Microserver 中的项目结构比较简单：MicroServer.Instance文件夹下面存放的是微服务实例，至于微服务颗粒度的拆分得结合实际的业务情况；Demo.MicroServer.IdentityServer4统一鉴权中心；Demo.MicroServer.Infrastructure 基础设施，可以自行在里面添加内容；Demo.MicroServer.Ocelot 这一层是Api网关；Demo.MicroServer.Repository 通用的数据访问层，包含MySQL，Mongo，Redis等，之所以抽离出来，是方便各个服务实例可是直接使用这些通用方法。
上面提到的有一些东西还未能实现，它们分别是 Consul，Polly，Exceptionless，Apollo，SkyWalking，这里还是分别介绍下：
Consul是一种服务网格解决方案，提供具有服务发现，健康检查，Key/Value存储，多数据中心等功能。在这里我们主要使用到服务发现，健康检查，启动场景是：微服务实例启动的时候。
Polly是.NET弹性和瞬态故障处理库，与Ocelot天然友好集成，使用也只需要在Ocelot 层添加少数配置即可使用。
Exceptionless是一款开源的实时的日志收集框架，可以使用在线或者本地搭建好的服务（如果只是本地测试建议直接使用在线的很方便），然后在微服务中配置好Url和应用的ApiKey就可以使用。
Apollo是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景，搭建好Apollo服务后，我们代码配置文件就可以变得相当干净了，只用留Apollo的配置就行，其他的配置几乎全部可以放在Apollo里面了。
项目地址： https://github.com/PeyShine/Demo.MicroServer
最近公司准备研究一些比较新颖的web技术，但是这些api兼容性无法考究，开发好以后只能一个一个的去测试，费时费力，如果我们在开发前就能了解到调用的api都兼容到什么程度，那整体的兼容性测试工作就好做了
工具地址
