workflow

缘起 Nebula Graph 最早的自动化测试是使用搭建在 Azure 上的 Jenkins ，配合着 GitHub 的 Webhook 实现的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运行相应的 UT 测试，效果如下： 因为是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且任务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在考虑寻找替代的方案，准备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。 调研了一圈现有的产品主要有： TravisCI CircleCI Azure Pipeline Jenkins on k8s（自建） 虽然上面的产品对开源项目有些限制，但整体都还算比较友好。 鉴于之前 GitLab CI 的使用经验，体会到如果能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出世，Nebula Graph 便勇敢的入了坑。 这里简单概述一下我们在使用 GitHub Action 时体会到的优点： 免费。开源项目可以免费使用 Action 的所有功能，而且机器 配置较高

碎碎念： 最近本来在研究SubstancePainter。突然发现maya里有多出来Substance程序纹理插件。查了一下，居然在maya2012就添加进来了，只不过需要在插件管理器里加载，所以一直都没注意到。（哎呀，我快被知识抛弃了，55555要快速召回它啦。） 现在maya附带的版本1.2.2.0已经过时，官方支持的版本是1.3.0.0 。使用Substance插件可以直接在Maya中加载在Substance Designer中创建的Substance材质（*.sbsar）。该插件将创建一个Maya材质，并将substance纹理输入到材质通道输入中。可以更改substance参数，纹理将自动更新。 试用下来觉得还是挺不错的，如果有材质库，真是分分钟出效果啊。只不过支持的最高分辨率为2048*2048，但程序纹理嘛，可以提高重复值啊，先用用再说咯。官方正在写2.0版本，可以期待一下新的内容。 Substance官方帮助文档： https://support.allegorithmic.com/documentation/integrations/maya-149291349.html 基础设置方法： 打开Hypershade材质编辑器，并创建 Substance节点。 选择Substance节点，然后设置Workflow工作流程。 加载Substance文件*.sbsar

前言 　　一般来说在游戏开发的过程中，声音这一模块是相对独立的。因此会有一些编辑器用于辅助sound designer进行设计，这些编辑器再提供一些API方便集成到引擎中。目前在我所有所接触过的一些游戏中，大部分使用的是Wwise以及FMod。由于最近的项目里面使用的是Wwise和UE4，所以这篇文章我将就Wwise在UE4中是如何使用展开，当作一个记录，毕竟以后可能还会再用到。 将Wwise集成到UE4中 　　 Wwise以插件的方式集成在UE4中，从WwiseLauncher中下载下来的Wwise integration具有UE4插件的一贯结构： 　　所以将这个文件夹copy到plugins目录下。 　　还没完，Wwise所依赖的SDK的源代码以及静态库放在哪里呢？ 　　在和*.uplugin同一级的目录的目录下新建文件夹ThirdParty，以Win64下VS2017为例，ThirdParty下应具有结构： 　　---- ThirdParty 　　 |-- include 　　 |-- x64_vc150 　　其中的子文件夹 include 和 x64_vc150 来自 ..\Wwise 2019.1.0.6947\SDK\ 　　更详细的可以参照plugin中的 AkAudio.Build.cs 文件和文档 Wwise_UE4_Integration 中的

Oozie知识框架： 理性认知： Oozie (驯象人) 2、Oozie简介： 一个基于工作流引擎的开源框架，有Cloudera公司贡献给apache，提供对hadoop、Mapreduce、Pig jobs 的任务调度和协调 oozie需要部署到java servlet容器中运行 3、oozie在集群中扮演的角色： 定时调度任务，多任务可以按照执行的逻辑顺序调度 4、oozie的功能模块：4.1： workflow 顺序执行流程节点，支持fork(分支多个节点)，join(合并多个节点为一个) 4.2： coordinator 定时触发workflow 4.3: bundle job 绑定多个coordinator 5、Oozie的节点：5.1： 控制流节点（control Flow Nodes）控制流节点一般都是定义在工作流开始或者结束的地方，比如start、end、kill等，以及提供工作流的执行路径机制，如decision,fork,jioin等 5.2、动作节点（Action，Nodes） 就是执行具体任务调度的节点 6、Oozie的安装与部署 6.1、解压Oozie $ tar -zxf /opt/softwares/oozie-4.0.0-cdh5.3.6.tar.gz -C /opt/modules/cdh/ 6.2、Hadoop配置文件修改

SD-WAN（Software Defined Wide Area Network）是近年来网络技术创新的一个热点，笔者结合自己的体会，和大家一起回顾这一领域的发展过程，对现状作一总结，对未来作一展望。篇幅所限，文中的示例以Cisco的解决方案为主，兼顾其它厂商。欢迎大家发表评论，共同切磋探讨。 一、广域网优化回顾 SDWAN通过转发面与控制面的分离，简化广域网的运行和管理。其技术涵盖两个方面：一是广域网优化，即通过压缩、缓存、传输层和应用层的协议优化等传统广域网优化技术加上广域网接口的流量调度，实现广域网传送效率的最大化。在以前广域网带宽受限的条件下（如MPLS链路～10M带宽），压缩、缓存、协议优化曾经是广域网优化的重点，如今得益于Internet 广域网接口千兆级（Gigabit ）的带宽，广域网优化的重点是流量调度；二是广域网的部署、配置与运维的自动化，即所谓的软件定义（Software Defined）部分，例如策略下发的自动化、设备配置的模版化。 广域网优化的代表厂商有Riverbed、Cisco等。Riverbed更专注压缩、缓存、协议优化，Cisco则兼而有之，其流量调度的历史可以追溯到Cisco企业业务路由器ASR/ISR/CSR的两个功能：基于策略的路由控制（Policy Based Routing）和基于性能的路由控制（Performance Routing)

　　大概是从寒假的时候开始正式的赚取github，从github上面学习一些开源的文档，我记得我注册github账号到现在已经9个月了，但只有最近的2个月才发现github这个新世界，写这篇文章是为了刚入门且毫无方向的程序员(若是大神，这篇文章可能不适合你) 主要内容 1.如何赚取github的学习资料 2.了解github的两种工作流 1-1直接从github赚赚赚 　　如果你将来打算从事软件开发这个行业的话，没有一个github账号，是说不过去的，所以说赶紧注册(若不懂，请自寻搜索)吧！！ 首先打开 github 会发现导航栏有以下内容 左边的搜索栏就不说了（其实你只要会英文都懂或者浏览器一键翻译…）,对于刚入门的同学来说 Explore 是最有用的(也是本小结的 重点 )，其他三个简单的叙述一下 Pull requsets 会在下面的 工作流 有所提及 Issues 我自己没有用过[捂脸]，这里稍微解释一下(每个仓库都有一个 Issues ，是为了给使用者提问或者讨论的地方，因为我自己没有参加过话题，所以 可惜 …)， Markeplace 我粗略的看了一下，大概是为了方便开发者在 github 的一些简单的APP(提高生产力)，感兴趣的可以了解了解 这个在侧边栏，github会根据相关的算法，然后给你推送一些你感兴趣的东西，下面就开始讲述从 Explore