非常开心能够申请成功DolphinScheduler的项目，今天起早贪黑刨土种地回家心血来潮，想记录一下在准备期间的一点点心得。Proposal的申请结果在6月15号已经出来了，这次我一共申请了两个项目，两份Proposal都写了接近1W字，一共大概准备了半个月，因为6月5号期末考试，所以我必须在这之前也就是6月30号解决战斗，中途真的好累好累，我有无数次放弃的念头。在编写文档的时候真的非常煎熬，因为不知道该怎么写，事无巨细的话就会写得非常多，篇幅很大，很累，只写大概思路的话又怕抓不住重点，导致申请失败，最后经过我颅内的一番左右互搏，我选择了第一种事无巨细（主要还是太菜了，不会抓重点！不过写文档真的非常累... /(ㄒoㄒ)/~~ 哭），Proposal的准备过程包括熟悉项目功能，源码阅读这些，不过其中最重要的还是要多和这个项目的Mentor沟通，了解项目的具体需求，通常它们都会给你提供一些文档资料，这些东西对准备过程帮助非常大。 两篇Proposal和个人简历我已经在Github上开源并且都放在了文章末尾，不想看我扯淡的同学可以直接下载文档（逃
Seata rpc协议扩展-实现grpc
这是一款蚂蚁金服开源的分布式事务框架，相信不少小伙伴看到rpc三个字母就开始眼中冒光了，确实，作为一个程序员来，心中或多或少都会有一个追求高效率的情结，不过这个项目除了rpc还有不少别的坑要踩。这个项目我从5月15号开始准备的，5月21号的时候在OSPP官网提交了Proposal,刚和Mentor了解完需求后，我对这个项目的看法就是简单有趣，但是随着接下来几天对seata-core模块rpc包的阅读深入，我发现事情并没有想象的那么简单。朋友们或多或少都听过SPI吧，它是一种服务发现机制，通常用来对系统做横向扩展，不可否认，seata在很多地方都使用了这个技巧来对功能进行扩充，但是很遗憾rpc包没有，也许因为最初的设计者认为基于Netty的rpc实现在以后不会再进行扩展，所以并没有预留这样的接口，写出了对修改开放，对扩展关闭的代码，这就导致了现有代码的高耦合。所以想要完成这个项目的第一步就是对原有接口进行重构。怎么样，大家是不是开始觉得这个项目并不简单了。而重构的第一步是对系统的依赖关系进行分析，我的Proposal中对rpc模块的依赖分析，重构方案，扩展方案都进行了详细的解说，所以就不再赘述了。
DolphinScheduler Java任务类型扩展
这是一款国内公司开源的大数据任务调度平台，具体哪个公司我忘了，不过我认识的多数维护者都是国人，DS社区对新人真的非常非常友好，我5月22号开始准备的这个项目，到提交Proposal的时间一共提了8个issue，9个pull request，每个pr都有及时大佬帮忙review，而且还会提出很多宝贵的修改建议，真的哪怕最后没有申请成功都能在这个社区收获很多。上面说seata的时候提到了SPI，其实我就是拿它来和DS比的，在这一块DS做的真的是非常非常非常好，就我申请的这个项目而言，接口定义非常清晰，功能非常明了，只需要debug一下代码了解一下任务的执行流程就可以很好理解项目需求和Proposal编写思路了。真的对我这种开源生手十分友好！
