github
10月份Github上最热门的开源项目
科技创新 • 柠檬^ 发表了文章 • 0 个评论 • 109 次浏览 • 2020-11-04 14:47
10月份GitHub上最热门的Java开源项目排行已经出炉啦，一起来看看上榜详情吧：
https://github.com/huanzi-qch/base-admin Star 1499
Base Admin一套简单通用的后台管理系统，这套Base Admin是一套简单通用的后台管理系统，主要功能有：权限管理、菜单管理、用户管理，系统设置、实时日志，实时监控，API加密，以及登录用户修改密码、配置个性菜单等
2、NewPipe
https://github.com/TeamNewPipe/NewPipe Star 11307
NewPipe是一款Android下的第三方YouTube客户端，支持画中画、后台播放、变速播放、可查看留言、可导入订阅频道、可使用Kodi播放，是一款功能非常完善的油管客户端。
3、Auto.js
https://github.com/hyb1996/Auto.js Star 8415
Auto.js是一款强大的不需要root的类似与按键精灵的软件，可以让你跟电脑中按键精灵一样实现自动点击，打开应用等等功能，能够解放你的双手，以及双眼，轻松的帮助你完成各种日常工作。
https://github.com/doocs/advanced-java Star 493206
本系列知识出自中华石杉，可以作为互联网Java工程师进阶知识完全扫盲。学习本系列知识之前，如果你完全没接触过MQ、ES、Redis、Dubbo、Hystrix等，那么我建议你可以先在网上搜一下每一块知识的快速入门，跟着入门Demo玩一下，然后再开始每一块知识的学习，这样效果更好。
5、eladmin
https://github.com/elunez/eladmin Star 11697
项目基于Spring Boot 2.1.0 、 Jpa、 Spring Security、redis、Vue的前后端分离的后台管理系统，项目采用分模块开发方式， 权限控制采用RBAC，支持数据字典与数据权限管理，支持一键生成前后端代码，支持动态路由。
6、AntennaPod
https://github.com/AntennaPod/AntennaPod Star 3166
AntennaPod播客是Android平台难得的精品播客应用，内置中文，支持曲目下载与iTunes订阅导入。
7、jeecg-boot
https://github.com/zhangdaiscott/jeecg-boot Star 16933
这是一款基于代码生成器的JAVA快速开发平台！提高UI能力的同时，降低前后分离的开发成本，JeecgBoot还独创在线开发模式，No代码概念，一系列在线智能开发：在线配置表单、在线配置报表、在线设计流程等等。
https://github.com/TheAlgorithms/Java Star 31964
该项目用Java实现的所有算法。
https://github.com/hollischuang/toBeTopJavaer Star 18030
Java工程师成神之路，完整大纲如下：
10、Mindustry
https://github.com/Anuken/Mindustry Star 6314
Mindustry是由AnukenDev开发和发行的一款开放式的塔防游戏。在这款游戏中，你的防御塔将不再像一般的塔防游戏一样可以无限开火，而是需要你将炮弹通过传送带运到炮塔上，因此你需要设计一系列合理的供应路线，同时生产基本的材料，保卫你的基地。游戏还支持多人跨平台游戏和PVP模式。
https://github.com/Snailclimb/jsoncat Star 289
这是一个仿仿Spring Boot但不同于Spring Boot的一个轻量级的HTTP框架。
https://github.com/seven332/EhViewer Star5788
EhViewer是一款非常绅士的漫画阅读软件。ehviewer上汇集了海量漫画资源。
开源最前线（ID：OpenSourceTop） 猿妹整编
转载请注明来源作者
懂程序员的产品经理是什么样子？
IM即时通讯 • 王叫兽 发表了文章 • 0 个评论 • 201 次浏览 • 2020-09-16 10:36
在互联网行业，产品经理和程序员之间的关系很微妙。表面看上去水火不容，在一方的眼里看另外一方总是有这样那样的问题，相互吐槽。但现实是，大家都知道和对方在同一条船上。
产品没做好的话，除了公司利益受损，产品经理和程序员也会各回各家各找各妈，重新找新工作去。
产品做得好的话，双方和睦相处、其乐融融？那是不可能的，这个辈子都不可能和睦相处。矛盾会更加严重……（都觉得自己功不可没）
所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员，都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的，而不是一个零和博弈。
这个主题会分别从不同的两个视角展开，今天我们先聊程序员视角，本来想两个视角一起聊，发现内容太多，写到一半还是拆了，先把一个视角写了。
如果你是程序员可以看看以下这些描述是你眼中的产品经理么？
如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。
程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）：
开发过程中频繁修改需求。
验收过程中要求做比较大的修改。
说不清楚需求的价值
替程序员评估工作量
需求整理的不够细。
其中，频繁修改需求是程序员们最反感的，这是毋庸置疑的。
从产品经理的角度来说，虽然无法100%在开发过程中不修改需求，但是如果前期的工作做得足够充分，与业务方的沟通足够到位，至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理，在自己对业务都是一知半解的时候就开始整需求了，这必然会导致后续频繁的需求变更。
第二，验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候，脑子里是一万头草泥马奔过……
产生这个情况的原因有很多。可能是程序员理解偏差，也有可能是产品觉得功能效果不佳。但是大多数时候，产生这个情况的根本原因还是在需求评审阶段的沟通不够充分，双方之间并没有达成真正的共识。
但是如果要说什么时候双方的矛盾最激烈，那还不是修改需求的时候，而是需求评审的时候。
此时，很容易看到的一个景象是“讨价还价”。产品经理站在「价值」一方，程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时，如果产品经理无法阐述出该功能令人信服的价值，那么必然受到吐槽。这是原因三。
原因四，有些产品经理是从程序员转过去的，之前做过一两年的开发工作。这个时长的经验其实是很危险的，很容易陷入到「达克效应」的第一阶段：高估自己的技术能力，低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理，甚至会在需求评审的时候替程序员预估时间，如果高于自己的预估，便会认为他们偷懒。
最后一点。相信每个人程序员都提出过这样的问题“这里如果……，那么要怎么处理？”。这种就是需求考虑不够细致的体现。不过，要做好这点的确挺难的，这也是产品经理花费时间最多的地方。
聊了这么多场景，作为产品经理应该如何应对呢？
从思路上分为以下几步。
01
先明确大方向，并与程序员达成一致。
正如前面所提到的，产品经理站在「价值」方，程序员站在「成本」方，这注定了他们是对立的。最坏的结果就是双方互掐，就算相对好的结果也只是相互妥协做一个半吊子的功能（用系统的人不太舒服）。
但如果你的视野更大，格局更高，就会发现，如果以「投入产出比」角度来切入，双方不但都能理解，而且很容达成共识，毕竟花最小的成本干价值最大的活，是个正常人都能理解和认可不是么。
所以，可以在日常工作中不断的强化这个共识。一旦出现争执，就从这个角度来做最终决定，甚至基于这慢慢地还能建立起相互的信任，程序员真正拥有了产品思维，产品经理真正懂了程序员的难处。
02
将产品经理范畴内的事情做到极致。
所谓术业有专攻，与其相互吐槽，不如多花点时间把对方吐槽的地方做到极致。
03
有时候你虽然做的很好，想的也很仔细，但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在「确认偏误」现象。
确认偏误是指搜寻，解释，偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信，并且在面对相反的证据时可以保持或加强信念。
维基百科
所以，运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成，你就得考虑如何提高协作效率。而产品经理和程序员的协作中，沟通又是最重要的。
下面展开说说具体可以做的一些事。主要是思路中的2和3。
01 提高专业性
我观察过一个现象，需求变更比较多的产品经理，他们的工作习惯往往是直接抄起原型工具就画原型，或者有很多工作时间在原型工具里。
这样非常容易陷入到一个思维惯性里面去，就是过于关注交互层面的事情，而轻视了背后业务流程的设计，甚至是业务的合理性。
我认为产品经理做事的时候一定要以User Story为核心来展开，先构思好一个User Story，然后就是把它真实发生的各种细节阐述清楚。做这事的过程先后分为以下四步：
定义User Story
定义交付标准
提供低保真原型
编写Use Case
这里面最费时费力的就是第四环节。并且，你想把User Story阐述清楚离不开一个专业的 Use Case编写。我之前收藏了一个非常专业的Use Case模版，是从知乎上的张恂老师那看到的，你感受一下。
用例名称：提问
层次：!（用户目标层）
范围：问答网站（以下简称系统）
主用角：注册用户（以下简称用户）
其他干系者：...
后态：
前态：用户已登录。
触发事件：用户选择提问。
基本流：1. 系统显示新建问题框。
输入问题 {
2. 用户输入问题陈述（字数限制？）；系统即时验证输入的有效性，并提示已有答案的类似问题（数量？）以免重复提问。
3. 用户设定该问题的相关话题。
4. 可选项
用户可补充输入问题说明（背景、条件等详细信息）。
5. 可选项
……
6. 用户提交问题。
}
7. 系统验证该问题的有效性。
8. 系统发布该问题，并显示该问题页面。
扩展流：用户放弃提问：...
https://www.zhihu.com/question/48899115/answer/113274323 张恂老师的回答。
作为产品经理的你，如果想要减少被程序员吐槽需求不够细，或者降低开发过程中变更需求的频次，把use case用心做好是必不可少的。
02 沟通方面
与程序员的沟通方面，我总结了五动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。
「齐」就是视角对齐的意思。在聊需求之前，先交代需求的背景、意义。特别在中途需求变更的时候，这点非常重要。
继续搬出之前用过好几次的图。
如果视角不同，你说接下去还怎么聊？
「拉」是拉拢的意思。亚里士多德说过：
我们无法通过智力去影响别人，而情感却能做到这一点。
亚里士多德
所以，在沟通的时候要把程序员当作自己人看待，而不是敌对。比如，可以多用“我们”，“一起”等词语，进入一个协商的氛围。举个例子：“我们一起来看下这个问题”。少用”我觉得“、”我认为“；
「捧」是吹捧的意思，但并不是简单的拍马屁。
人都是有多面性的，针对不同的情况和场景，可能会表现出不同的特质，这会影响到双方的沟通。比如有的人在生活中很温和，但在工作时非常严苛，要求很高，这就是激发了不同的特质。
类似的，为了激活程序员的积极性，你可以在当下需要他发挥的地方吹捧一下。比如，你觉得某个程序员做的东西质量一般，小问题比较多。那么你在和他聊的时候特地捧一句，“我知道做程序员的都或多或少有完美主义倾向，对细节很关注。我这个功能设计的细节可是想了好久呢，不过对你来说应该很容易搞定吧。”
「说」是说服的意思。想要让对方从心底里的认同你，单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。
重视数据的产品经理有可能是优秀的产品经理，但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务，并且还不能仅仅懂个皮毛。比如，
你得知道哪些环节产生的数据是关键。
多个数据之间的间接关系和影响是什么。
你设计的每一个功能会如何影响这些数据。
……
心里一直有着这些概念，程序员还会吐槽你提的需求价值低？
「让」是谦让的意思。俗话说，“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。
原因有两点。
大多数的产品设计背后有很多的知识是通用知识，每个人的生活经历都能成为经验。而每个人的生活经历又是不同的。
专业不同，哪怕站的视角相同，看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发，提出的观点可能会让你眼前一亮。
以上就是「齐、拉、捧、说、谦」五点。最后再送给你一句话：非必要情况，一定不要用“这是老板的要求“！，重复，重复。重要的事情说三遍。
还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如，在领域驱动设计范畴中Event Storming。它就非常适合在前期的需求评审环节去使用。
感兴趣的可以自行了解。
好了，总结一下。
这篇呢，Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。
思路上分为三步：
先明确大方向，并与程序员达成一致。
将产品经理范畴内的事情做到极致
运用一些沟通技巧解决「确认偏误」现象。
关于第二点，给出的具体措施是。以User Story为核心，做好Use Case的编写工作，而不是花很多时间在原型上。
关于第三点，总结了五个动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。
希望对你有所帮助。
作者：Z哥，公众号“跨界架构师”
如何做一个懂产品的程序员？
IM即时通讯 • 王叫兽 发表了文章 • 0 个评论 • 209 次浏览 • 2020-09-16 10:32
两个相爱相杀的岗位，想要更好的达成共识、更好的合作，自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。
直接进入正题吧。
从产品视角是怎么看程序员的呢？我根据我自己的经历以及与其他产品经理的交流下来看，吐槽的主要是以下几点：
这个功能实现不了。
希望所有产品都不要改版，一次性把现在或未来要做的开发完。
只关心要写多少代码，不在乎产品体验。
写完程序从不自测，直接丢给别人测试。
过分追寻新技术潮流，完全不考虑对产品带来什么价值。
第一点，的确存在一些由于技术限制导致实现成本无限大的需求，比如手机屏幕背景色根据手机壳颜色切换……
但是，国内的技术环境不像老美那的技术味道重，大多还是商业导向的，很少企业里需要用到高精尖的技术，所以，真正实现不了的功能微乎其微。
对于大多数的功能需求来说，无非是一个成本大小、价值高低的问题。从立场上看，程序员自然是站在「成本」一方的，但对大多数人来说，决定这个成本的主要因素往往是自己工作的难度和耗时，费时费力的功能就容易得到“实现不了”的结果。
第二点对大多数产品经理来说是他们的对立面。因为大多数产品经理最喜欢“走一步算一步”地高频迭代，甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的，并且内容要非常详细的，心里的想法是，这样的话我一开始就可以设计一个完美架构来支撑它。
而且，内容越详细，产品经理就越不敢乱调整需求，毕竟“证据在手”嘛：D。
第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多，对需要有同理心、需要靠感受的事情的确弱了一些。
第四点的原因主要有两个。
一个是对自己的代码过度自信导致，我自己深有体会。我还记得有一次我交付一个功能，那个功能我单元测试都写了不少，对质量很有信心，觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug。
另一个原因是反正有测试人员在，等他们测出问题我再改不是更轻松。惰性使然，从个人角度的确如此。但是从团队角度来看，徒增了不少的沟通成本。
第五点的原因也有两个。
一个是行业里的新技术迭代的确太快，怕不学新技术被淘汰。
另一个原因是，只有用上新技术才能有谈资，显得自己与众不同、有成就感。
以上就是对这五点的简单分析，那么如何改善呢？继续往下看。
下面这些方法都是我亲测有效的，强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。
01 说实现不了之前，先三思
根据先后可以做以下3个思考：
是觉得这个功能没有价值不想做吗？
真的实现不了？我想全了吗？
这些方案里，有成本比价值低的吗？
第一个问题先确定必要性。我们不是说不能推需求，而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算，但至少这才能算是拒绝的理由。
第二个问题，努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案，那么将会永远在舒适区止步不前。
第三个问题，拒绝需求虽然不用动之以情，但一定需要晓之以理。当你能清楚的阐述利弊、收益比，拒绝需求自然不是一件需要相互扯皮的事情。
经过了这三个问题的思考，不管最终能不能实现，相信可以很好的与产品经理达成共识。
02 明白需求本身也是成本
过度地苛求需求要细、要完整、要全面，这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本，产品经理的也是。
与其等一个“XXXX最终绝对不改版”，不如从已经达成共识的部分开工，在这个过程中再与产品经理「共创」，多一起沟通打磨，此时再让产品完善PRD等文档，形成最终版。
03 刻意练习，多换位到用户视角
平时多去体验一下自家的产品以及竞品，把整个过程中的感受记录下来。比如，哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。结果不重要，重要的是这个过程，慢慢锻炼自己作为用户的感知力。
有些程序员看起来经常把用户体验挂在嘴上，其实提出来的很多反而是脱离大众习惯的“个性化”需求，就是因为平时缺少对同行、外界的关注。
04 交付的东西是自己的「招牌」
“有人的地方就有江湖，有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态，你在别人心中的称号就是负面的。
轻则影响自己的口碑，影响与他人之间的协作关系；重则失去未来的晋升机会。一个对自己的东西都不负责的人，如何负责更多的人、更大的事情呢？
在这件事上，除了多自测外，作为过来人，我建议每一个程序员认真对待单元测试。特别把核心、复杂的方法单元测试给做上，这对交付功能的质量的提升非常明显。
05 不产生价值的新技术是“垃圾”
拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它，这不但给团队在挖坑，也在给自己挖坑。
比如你花了不少的时间在项目里用了某个新技术，但是对团队没有带来什么价值，你说后续公司还会继续投入资源加大新技术的使用吗？大概率并不会。那么之前了解到的一些知识，就会随着时间的推移而淡忘，投入的时间大多数浪费掉了。
所以，对待新技术Z哥的观点是。对于无法在工作中找到价值点的新技术浅尝辄止即可。相反，遇到可以产生价值的新技术，请全身心投入进去，而不是仅仅在应用层面捣腾，不去深入细节。之前发过一篇讲解新技术选用的文章《程序员与新技术之间的「爱」与「恨」》，可以点击文末的链接阅读。
很多程序员对待新技术的习惯是，打一枪换一个地方，经过了几年，发现技术实力还在原地打转，不免有些可惜。
另外，推荐大家可以阅读一两本心理学、行为学相关的书，特别是我们做程序员的。
这不但可以提高自己对用户体验的感觉，还能提高对人性的洞察力，包括对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。
好了，总结一下。
这篇呢，Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议：
1.说实现不了之前，先三思。
2.明白需求本身也是成本。
3.刻意练习，多换位到用户视角。
4.交付的东西是自己的「招牌」
5.不产生价值的新技术是“垃圾”
希望对你有所帮助。
作者：Z哥，公众号“跨界架构师”
英雄会被表彰，这些技术与代码也将载入史册！
科技创新 • 柠檬^ 发表了文章 • 1 个评论 • 137 次浏览 • 2020-09-10 16:14
昨天，我们被「人民英雄」刷屏了。
上午十点，全国抗击新冠肺炎疫情表彰大会，在人民大会堂隆重举行。
大会授予钟南山「共和国勋章」，授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。
除了这些战疫者之外，在今年抗击疫情过程中，还有一批特殊的「功臣」，也在今年的抗疫战中立下汗马功劳，从而被纳入国家博物馆收藏。
历史也将铭记：代码、无人车、外卖服
近日，国家博物馆陆续上新，这批最新纳入的藏品，与以往的有所不同：这些物品都是为纪念抗疫征集而来，将成为历史文物。
国博曾在 3 月向社会公开征集
抗疫相关实物与资料
国博发出抗疫藏品征集公告之后，社会各界都纷纷响应，捐出了各种具有纪念意义的物品。
如今最新加入国博的这些成员，不仅因为见证了这场抗疫历史，而拥有了特殊的意义，也因为其自身鲜明的时代特色，而显得十分别样。
阿里：三段代码
本次藏品征集中，阿里提交了包括 4 本新型冠状病毒肺炎临床救治手册、2 本新冠疫情爆发下的医院应对策略、六大洲捐赠的提单和报关单、等 14 种共 30 件抗疫实物。
这其中，有三件「物品」与众不同，它们分别是：
支付宝团队研发的健康码系统第一行代码； 阿里云研发的全国健康码引擎第一行代码； 阿里巴巴达摩院研发的新冠肺炎 CT 影像 AI 辅助诊断产品第一行代码。
与代码一起纳入收藏的，还有参与该项目的程序员签名
除了体温、核酸检测等线下手段外，健康码这个数字化防疫工具，也成为人人出行的必备凭证。
它们包括：JD40006 号无人配送车、湖北省新冠疫情防控指挥部的感谢信、钟南山院士的感谢信、内蒙古援鄂医疗队医护人员写给京东快递小哥的感谢信、技术抗疫纪录片。
据报道，疫情期间，32 岁的退伍军人付腾虎，组建了一支特别的外卖配送队「飞虎队」，给武汉协和医护人员送餐。他们每天一趟送几十份餐，累计送了万份餐。
「写代码写进国博挺酷的，有点激动，是个纪念。到时候国博有展，我一定会去北京看的。」支付宝前端开发刘志飞说。
收藏代码，是国家博物馆的第一次，却也有例可循。GitHub 在前不久将一部分开源代码，以胶片的形式储存，打包运往北极冷岸群岛。
这批代码胶片被存放在极其干燥的、-5°C 恒温的矿井中
健康码也是一样，这些「摸不着」的代码，是这段重要、特殊的 2020 年里，重要的组成部分。
我们将铭记这段不同寻常的时期，后人也会了解到这段用科技、医疗、人文关怀一起驱动着全体国民，共同抗击疫情的历史时刻。
来源公众号：HyperAI超神经
曲线救国：提高github下载速度到2MB/s
IM即时通讯 • 梅川酷子 发表了文章 • 0 个评论 • 186 次浏览 • 2020-07-29 09:15
因为网络连接的原因，在国内从github上面下载代码的速度峰值通常都是20kB/s。
这种速度对于那些小项目还好，而对于大一些的并且带有很多子模块的项目来讲就很耽误时间。
常见的方法是通过代理连接，但实际用起来并不稳定。
这里提供一种新的思路，下载速度可以达到1~2MB/s
1. 利用开源中国提供的代码仓库
标题已经说的很清楚了，我想对于经常使用git的人来讲，很可能已经知道了。对于新手刚接触git的人来讲，可能你只知道github。
实际上，国内也有很多代码仓库提供方，国外也不只github。只不过国内也是刚刚开始，关注的人不多。
开源中国提供的代码仓库提供了一个功能，就是它可以将github账号中的代码 clone 到开源中国的账户中去。这个代码仓库叫做 码云 ，没错就是 Ma云！
要求你有一个github账户，一个码云gitee账户。
步骤很简单
1.将github上面你想要搞下来的项目首先 frok 到你自己的github的账户中去。耗时:一瞬间
2.登录gitee，没有的自行注册。网页中有添加项目的按钮，一个加号。点击加号，下拉列表里面有 迁移github项目 的选项，点开后按照提示关联自己的github账号，之后选择你要迁移的项目，按提示操作。耗时:不到三分钟。
3.按照 clone github项目方法， clone 迁移到gitee账户中的项目。区别是 clone 链接换成了目标项目在gitee中的链接。通常下载速度是以MB/s为单位的。
按照上面的方法，基本上不再需要整夜挂机 clone 代码了。
最近重新看了下，其实上面的步骤有些繁琐，其可以更简单，新建仓库直接设置远程仓库地址。
第一步：
新建仓库
第二步：
以github仓库https://github.com/PX4/Firmware.git举例
第三步：
第四步
2. 提高下载子模块的速度
有的项目里用到了第三方代码仓库，但是在你使用 clone 指令的时候这些子模块 submodule 并不会自动下载，因为他们在另外的地址中存放。你需要 clone 完目标项目后，执行
git submodule update --init --recursive
才会将目标项目所需要的依赖子模块下载下来。github项目中所用到的子模块依然是放在了github上。这就很悲剧了，这意味着你在执行上面指令后，依然需要面对上面的20KB/s的速度。虽然此时并不会显示出来，然而等待依然很久。
我们同样使用上面加速 clone 的思路。
从下载的项目中找到其使用的 submodule 的链接是哪里。
打开上一步中的链接，将使用的目标子模块的代码同样 frok 到自己的github账户中，之后同样的方法迁移到gitee中去。有多个子模块就多重复几次操作，同样的套路。
将原项目使用的 submodule 模块的链接地址修改为子模块迁移到gitee中后的地址。
这时再去执行
git submodule update --init --recursive
以上就是提高下载子模块速度的思路。具体每步的操作，请自行搜索，网上一搜一大片。
附：关于如何修改submodule连接地址 https://blog.csdn.net/wangjia55/article/details/24400501 https://www.jianshu.com/p/c81e2bd377ad https://blog.csdn.net/qq_22630169/article/details/74236535 https://blog.csdn.net/wangjia55/article/details/24400501
版权声明：本文为CSDN博主「kcx64」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kcx64/article/details/83866633
GitHub推出「打赏」功能，全球最大同性交友平台将迎来更多开源工作？
技术活动 • 大兴 发表了文章 • 0 个评论 • 173 次浏览 • 2020-07-22 15:02
近期，GitHub 发布了一条新功能——GitHub Sponsors，也就是我们熟悉的「打赏」。GitHub 官方表示，打赏的每一分钱都会进开发者的口袋，他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub 都有打赏了，到底是好还是坏？
GitHub 官方表示，「开发者们为我们大家贡献了开源工具，这是对他们的经济支持，新的打赏功能将帮助他们构建更优秀的开源工作。」然而，这不得不让人感叹，作为全宇宙最自由、最神圣的交友社区，GitHub 也开始增加打赏属性。所以为了顺应大流，欢迎 Star 和 Fork 融云GitHub 项目～
项目地址https://github.com/rongcloud-archive
为了启动这一新项目并激发社区打赏积极性，GitHub 还推出了 GitHub Sponsors Matching Fund，每个开发者第一年最多可匹配到 5000 美元的赞助基金。
这是一个开源的世界。如果没有维护者、设计者、编程者、研究者等组成的全球团队促进科技发展，世界就难以运行。这些卓越的开发者现在可以从社区中按劳取酬，通过自己的 GitHub 文件获取经济支持。
中间商不赚差价，打赏功能全球通用
开源是 GitHub 的核心。构建共享数字基础设施的开发者使得这个社区更加强大。GitHub 表示，为了表示对贡献者的感谢，GitHub Sponsors 在用户打赏其他开发者时不会收取平台费用。此外，为了庆祝这一功能的推出，GitHub 还将为前 12 个月的支付处理开销买单。简而言之，你打赏的每一分钱都会进开发者的口袋。
此外，打赏功能没有地域限制，只要在 GitHub 开展业务的国家，这一功能都能使用。
所有贡献者都能赏
在优秀的项目中，很多贡献者（contributor）都会做出至关重要的贡献，但他们的贡献在代码评审中并不可见。GitHub Sponsors 的推出是为了帮助所有类型的贡献和工作，从而进一步帮助开发者构建开源系统。任何对开源项目做出了贡献的人，不论是代码修改、文档编写，还是项目领导、项目设计等，都有可能得到打赏。
目前有一小部分开发者参与了 Sponsors 的测试版，任何开源项目贡献者在未来都有机会受到打赏。当然读者们也能申请下阶段测试的开发者，即填表加入 GitHub Sponsors 的候选者列表：
例如 Go 语言的贡献者，申请成为测试开发者后的赞赏页面大概是这样的：
因此，GitHub Sponsors 是另一种对开源项目做出贡献的方法：为构建和维护项目的开发者提供资金支持。为开发者资金帮助能帮助他们构建更好的开源项目，扩展参与开发的机会，并给予开发者应有的认可。从今天起，任何 GitHub 用户都能资助开源项目的开发者，这也是对项目最好的认可方式。
嵌入 GitHub 工作流
对于我们熟悉的工作流，GitHub Sponsors 现在可以无缝嵌入到里面。当贡献者回答我们的问题、指出我们的错误、或合并我们提交的代码时，我们可以访问他们的资料，或者直接将鼠标放在用户名上来打赏他们的开源工作。
对于新的社区贡献者悬停卡，除了该项目的直接贡献者，我们还能看到该项目传递的依赖性关系。他们虽然没有直接对该开源项目做出贡献，但他们以前的工作或贡献可能为当前项目提供帮助，因此也是我们该赞赏的人。
开源项目还可以直接在 repo 中显示自己的打赏模型。.github/FUNDING.yml 被加到一个项目的主分支上之后，一个新的「Sponsor」按钮就会出现在 repo 的顶端。单击该按钮将打开该文件中列出的打赏模型的本地渲染视图。
YAML 板式非常灵活，因此项目的维护者和贡献者可以根据自己的条件决定如何打赏项目。他们可以展示以下任何（或全部）内容：为该项目做出贡献的开发者的 GitHub Sponsors 文件；包含 Open Collective、Community Bridge、Tidelift、Ko-fi 和 Patreon 在内的流行打赏模型以及其他打赏模型的自定义链接。
影响
GitHub 的这一做法可能会引起一些争议，部分开发者认为打赏可能会影响到开发者的工作方向。经济利益可能驱使开发者更加关注可能获取经济效益的项目，而不是那些有趣、有挑战性但不太会有人打赏的项目。那么读者们怎么认为？快留言写下你的观点吧。
一个靠 GitHub 打赏的码农，年入十万美元!
技术活动 • 大兴 发表了文章 • 0 个评论 • 171 次浏览 • 2020-07-22 14:48
直到撰写本文时，我的 GitHub 年度打赏金额已经达到了 112680 美元。
创建一个很棒的软件；
使其仅对打赏者开放，直到你积累了一定数量的打赏者；
然后将项目开源给全世界。
我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法，同样取得了成功：
我在文档的适当位置嵌入了这些视频的链接，以帮助大家找到它们
几个星期之后，我又为 GitHub 打赏者专门建立了一个「私有」的视频小组：
B站UP主自制的开源OCR翻译器走红Github，用一次就粉了
技术活动 • 梅川酷子 发表了文章 • 0 个评论 • 276 次浏览 • 2020-07-22 09:50
最近一个B站UP主自己撸了一个翻译神器，只要出现在屏幕的东西都可以翻译，关键是操作十分简单，就像下面这样：
适用范围全面，几乎所有出现在屏幕的东西都可以翻译；
翻译接口多，目前有12个翻译接口；
简洁美观的界面；
及其简单傻瓜的操作方式；
相比较其他OCR翻译器配置有自动翻译模式；
需要联网，可能视网速不同翻译速度有差；
PantsuDango为什么要创建这个项目？
PantsuDango本身是个vnr翻译软件的忠实用户，但是遇到某些游戏无法提取文本，然后偶然发现有OCR（文字识别）技术的存在，下载了很多已经有的OCR翻译器还是不满意，于是，索性自己撸了一个。
PantsuDango目前在Github标星 816，累计分支 88 个（Github地址：https://github.com/PantsuDango/Dango-Translator）
来自：开源最前线（ID：OpenSourceTop）
项目地址：https://github.com/PantsuDango/Dango-Translator
我，一个靠 GitHub 打赏谋生的程序员，如何做到年入 10 万美元？
技术活动 • 王叫兽 发表了文章 • 0 个评论 • 192 次浏览 • 2020-07-06 11:51
如果提到靠打赏生活的人，我们首先想到的会是主播。但现实情况是，程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。
在过去的一年里，他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中，他分享了自己靠 GitHub 项目赚钱的经历和技巧。
Caleb Porzio 发推庆祝自己靠 GitHub 打赏（GitHub Sponsors）赚到了 10 万美元。
GitHub Sponsors 是 GitHub 2019 年 5 月份推出的一个功能，允许开发者通过自己的项目获取报酬/赞赏。
创建一个很棒的软件；
使其仅对打赏者开放，直到你积累了一定数量的打赏者；
然后将项目开源给全世界。
转自：机器之心 （张倩、蛋酱）
原文链接：https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it
10月份Github上最热门的开源项目
科技创新 • 柠檬^ 发表了文章 • 0 个评论 • 109 次浏览 • 2020-11-04 14:47
10月份GitHub上最热门的Java开源项目排行已经出炉啦，一起来看看上榜详情吧：
https://github.com/huanzi-qch/base-admin Star 1499
Base Admin一套简单通用的后台管理系统，这套Base Admin是一套简单通用的后台管理系统，主要功能有：权限管理、菜单管理、用户管理，系统设置、实时日志，实时监控，API加密，以及登录用户修改密码、配置个性菜单等
2、NewPipe
https://github.com/TeamNewPipe/NewPipe Star 11307
NewPipe是一款Android下的第三方YouTube客户端，支持画中画、后台播放、变速播放、可查看留言、可导入订阅频道、可使用Kodi播放，是一款功能非常完善的油管客户端。
3、Auto.js
https://github.com/hyb1996/Auto.js Star 8415
Auto.js是一款强大的不需要root的类似与按键精灵的软件，可以让你跟电脑中按键精灵一样实现自动点击，打开应用等等功能，能够解放你的双手，以及双眼，轻松的帮助你完成各种日常工作。
https://github.com/doocs/advanced-java Star 493206
本系列知识出自中华石杉，可以作为互联网Java工程师进阶知识完全扫盲。学习本系列知识之前，如果你完全没接触过MQ、ES、Redis、Dubbo、Hystrix等，那么我建议你可以先在网上搜一下每一块知识的快速入门，跟着入门Demo玩一下，然后再开始每一块知识的学习，这样效果更好。
5、eladmin
https://github.com/elunez/eladmin Star 11697
项目基于Spring Boot 2.1.0 、 Jpa、 Spring Security、redis、Vue的前后端分离的后台管理系统，项目采用分模块开发方式， 权限控制采用RBAC，支持数据字典与数据权限管理，支持一键生成前后端代码，支持动态路由。
6、AntennaPod
https://github.com/AntennaPod/AntennaPod Star 3166
AntennaPod播客是Android平台难得的精品播客应用，内置中文，支持曲目下载与iTunes订阅导入。
7、jeecg-boot
https://github.com/zhangdaiscott/jeecg-boot Star 16933
这是一款基于代码生成器的JAVA快速开发平台！提高UI能力的同时，降低前后分离的开发成本，JeecgBoot还独创在线开发模式，No代码概念，一系列在线智能开发：在线配置表单、在线配置报表、在线设计流程等等。
https://github.com/TheAlgorithms/Java Star 31964
该项目用Java实现的所有算法。
https://github.com/hollischuang/toBeTopJavaer Star 18030
Java工程师成神之路，完整大纲如下：
10、Mindustry
https://github.com/Anuken/Mindustry Star 6314
Mindustry是由AnukenDev开发和发行的一款开放式的塔防游戏。在这款游戏中，你的防御塔将不再像一般的塔防游戏一样可以无限开火，而是需要你将炮弹通过传送带运到炮塔上，因此你需要设计一系列合理的供应路线，同时生产基本的材料，保卫你的基地。游戏还支持多人跨平台游戏和PVP模式。
https://github.com/Snailclimb/jsoncat Star 289
这是一个仿仿Spring Boot但不同于Spring Boot的一个轻量级的HTTP框架。
https://github.com/seven332/EhViewer Star5788
EhViewer是一款非常绅士的漫画阅读软件。ehviewer上汇集了海量漫画资源。
开源最前线（ID：OpenSourceTop） 猿妹整编
转载请注明来源作者
懂程序员的产品经理是什么样子？
IM即时通讯 • 王叫兽 发表了文章 • 0 个评论 • 201 次浏览 • 2020-09-16 10:36
在互联网行业，产品经理和程序员之间的关系很微妙。表面看上去水火不容，在一方的眼里看另外一方总是有这样那样的问题，相互吐槽。但现实是，大家都知道和对方在同一条船上。
产品没做好的话，除了公司利益受损，产品经理和程序员也会各回各家各找各妈，重新找新工作去。
产品做得好的话，双方和睦相处、其乐融融？那是不可能的，这个辈子都不可能和睦相处。矛盾会更加严重……（都觉得自己功不可没）
所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员，都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的，而不是一个零和博弈。
这个主题会分别从不同的两个视角展开，今天我们先聊程序员视角，本来想两个视角一起聊，发现内容太多，写到一半还是拆了，先把一个视角写了。
如果你是程序员可以看看以下这些描述是你眼中的产品经理么？
如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。
程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）：
开发过程中频繁修改需求。
验收过程中要求做比较大的修改。
说不清楚需求的价值
替程序员评估工作量
需求整理的不够细。
其中，频繁修改需求是程序员们最反感的，这是毋庸置疑的。
从产品经理的角度来说，虽然无法100%在开发过程中不修改需求，但是如果前期的工作做得足够充分，与业务方的沟通足够到位，至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理，在自己对业务都是一知半解的时候就开始整需求了，这必然会导致后续频繁的需求变更。
第二，验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候，脑子里是一万头草泥马奔过……
产生这个情况的原因有很多。可能是程序员理解偏差，也有可能是产品觉得功能效果不佳。但是大多数时候，产生这个情况的根本原因还是在需求评审阶段的沟通不够充分，双方之间并没有达成真正的共识。
但是如果要说什么时候双方的矛盾最激烈，那还不是修改需求的时候，而是需求评审的时候。
此时，很容易看到的一个景象是“讨价还价”。产品经理站在「价值」一方，程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时，如果产品经理无法阐述出该功能令人信服的价值，那么必然受到吐槽。这是原因三。
原因四，有些产品经理是从程序员转过去的，之前做过一两年的开发工作。这个时长的经验其实是很危险的，很容易陷入到「达克效应」的第一阶段：高估自己的技术能力，低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理，甚至会在需求评审的时候替程序员预估时间，如果高于自己的预估，便会认为他们偷懒。
最后一点。相信每个人程序员都提出过这样的问题“这里如果……，那么要怎么处理？”。这种就是需求考虑不够细致的体现。不过，要做好这点的确挺难的，这也是产品经理花费时间最多的地方。
聊了这么多场景，作为产品经理应该如何应对呢？
从思路上分为以下几步。
01
先明确大方向，并与程序员达成一致。
正如前面所提到的，产品经理站在「价值」方，程序员站在「成本」方，这注定了他们是对立的。最坏的结果就是双方互掐，就算相对好的结果也只是相互妥协做一个半吊子的功能（用系统的人不太舒服）。
但如果你的视野更大，格局更高，就会发现，如果以「投入产出比」角度来切入，双方不但都能理解，而且很容达成共识，毕竟花最小的成本干价值最大的活，是个正常人都能理解和认可不是么。
所以，可以在日常工作中不断的强化这个共识。一旦出现争执，就从这个角度来做最终决定，甚至基于这慢慢地还能建立起相互的信任，程序员真正拥有了产品思维，产品经理真正懂了程序员的难处。
02
将产品经理范畴内的事情做到极致。
所谓术业有专攻，与其相互吐槽，不如多花点时间把对方吐槽的地方做到极致。
03
有时候你虽然做的很好，想的也很仔细，但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在「确认偏误」现象。
确认偏误是指搜寻，解释，偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信，并且在面对相反的证据时可以保持或加强信念。
维基百科
所以，运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成，你就得考虑如何提高协作效率。而产品经理和程序员的协作中，沟通又是最重要的。
下面展开说说具体可以做的一些事。主要是思路中的2和3。
01 提高专业性
我观察过一个现象，需求变更比较多的产品经理，他们的工作习惯往往是直接抄起原型工具就画原型，或者有很多工作时间在原型工具里。
这样非常容易陷入到一个思维惯性里面去，就是过于关注交互层面的事情，而轻视了背后业务流程的设计，甚至是业务的合理性。
我认为产品经理做事的时候一定要以User Story为核心来展开，先构思好一个User Story，然后就是把它真实发生的各种细节阐述清楚。做这事的过程先后分为以下四步：
定义User Story
定义交付标准
提供低保真原型
编写Use Case
这里面最费时费力的就是第四环节。并且，你想把User Story阐述清楚离不开一个专业的 Use Case编写。我之前收藏了一个非常专业的Use Case模版，是从知乎上的张恂老师那看到的，你感受一下。
用例名称：提问
层次：!（用户目标层）
范围：问答网站（以下简称系统）
主用角：注册用户（以下简称用户）
其他干系者：...
后态：
前态：用户已登录。
触发事件：用户选择提问。
基本流：1. 系统显示新建问题框。
输入问题 {
2. 用户输入问题陈述（字数限制？）；系统即时验证输入的有效性，并提示已有答案的类似问题（数量？）以免重复提问。
3. 用户设定该问题的相关话题。
4. 可选项
用户可补充输入问题说明（背景、条件等详细信息）。
5. 可选项
……
6. 用户提交问题。
}
7. 系统验证该问题的有效性。
8. 系统发布该问题，并显示该问题页面。
扩展流：用户放弃提问：...
https://www.zhihu.com/question/48899115/answer/113274323 张恂老师的回答。
作为产品经理的你，如果想要减少被程序员吐槽需求不够细，或者降低开发过程中变更需求的频次，把use case用心做好是必不可少的。
02 沟通方面
与程序员的沟通方面，我总结了五动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。
「齐」就是视角对齐的意思。在聊需求之前，先交代需求的背景、意义。特别在中途需求变更的时候，这点非常重要。
继续搬出之前用过好几次的图。
如果视角不同，你说接下去还怎么聊？
「拉」是拉拢的意思。亚里士多德说过：
我们无法通过智力去影响别人，而情感却能做到这一点。
亚里士多德
所以，在沟通的时候要把程序员当作自己人看待，而不是敌对。比如，可以多用“我们”，“一起”等词语，进入一个协商的氛围。举个例子：“我们一起来看下这个问题”。少用”我觉得“、”我认为“；
「捧」是吹捧的意思，但并不是简单的拍马屁。
人都是有多面性的，针对不同的情况和场景，可能会表现出不同的特质，这会影响到双方的沟通。比如有的人在生活中很温和，但在工作时非常严苛，要求很高，这就是激发了不同的特质。
类似的，为了激活程序员的积极性，你可以在当下需要他发挥的地方吹捧一下。比如，你觉得某个程序员做的东西质量一般，小问题比较多。那么你在和他聊的时候特地捧一句，“我知道做程序员的都或多或少有完美主义倾向，对细节很关注。我这个功能设计的细节可是想了好久呢，不过对你来说应该很容易搞定吧。”
「说」是说服的意思。想要让对方从心底里的认同你，单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。
重视数据的产品经理有可能是优秀的产品经理，但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务，并且还不能仅仅懂个皮毛。比如，
你得知道哪些环节产生的数据是关键。
多个数据之间的间接关系和影响是什么。
你设计的每一个功能会如何影响这些数据。
……
心里一直有着这些概念，程序员还会吐槽你提的需求价值低？
「让」是谦让的意思。俗话说，“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。
原因有两点。
大多数的产品设计背后有很多的知识是通用知识，每个人的生活经历都能成为经验。而每个人的生活经历又是不同的。
专业不同，哪怕站的视角相同，看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发，提出的观点可能会让你眼前一亮。
以上就是「齐、拉、捧、说、谦」五点。最后再送给你一句话：非必要情况，一定不要用“这是老板的要求“！，重复，重复。重要的事情说三遍。
还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如，在领域驱动设计范畴中Event Storming。它就非常适合在前期的需求评审环节去使用。
感兴趣的可以自行了解。
好了，总结一下。
这篇呢，Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。
思路上分为三步：
先明确大方向，并与程序员达成一致。
将产品经理范畴内的事情做到极致
运用一些沟通技巧解决「确认偏误」现象。
关于第二点，给出的具体措施是。以User Story为核心，做好Use Case的编写工作，而不是花很多时间在原型上。
关于第三点，总结了五个动作，分别是「齐、拉、捧、说、谦」，可以根据情况组合出击。
希望对你有所帮助。
作者：Z哥，公众号“跨界架构师”
如何做一个懂产品的程序员？
IM即时通讯 • 王叫兽 发表了文章 • 0 个评论 • 209 次浏览 • 2020-09-16 10:32
两个相爱相杀的岗位，想要更好的达成共识、更好的合作，自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。
直接进入正题吧。
从产品视角是怎么看程序员的呢？我根据我自己的经历以及与其他产品经理的交流下来看，吐槽的主要是以下几点：
这个功能实现不了。
希望所有产品都不要改版，一次性把现在或未来要做的开发完。
只关心要写多少代码，不在乎产品体验。
写完程序从不自测，直接丢给别人测试。
过分追寻新技术潮流，完全不考虑对产品带来什么价值。
第一点，的确存在一些由于技术限制导致实现成本无限大的需求，比如手机屏幕背景色根据手机壳颜色切换……
但是，国内的技术环境不像老美那的技术味道重，大多还是商业导向的，很少企业里需要用到高精尖的技术，所以，真正实现不了的功能微乎其微。
对于大多数的功能需求来说，无非是一个成本大小、价值高低的问题。从立场上看，程序员自然是站在「成本」一方的，但对大多数人来说，决定这个成本的主要因素往往是自己工作的难度和耗时，费时费力的功能就容易得到“实现不了”的结果。
第二点对大多数产品经理来说是他们的对立面。因为大多数产品经理最喜欢“走一步算一步”地高频迭代，甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的，并且内容要非常详细的，心里的想法是，这样的话我一开始就可以设计一个完美架构来支撑它。
而且，内容越详细，产品经理就越不敢乱调整需求，毕竟“证据在手”嘛：D。
第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多，对需要有同理心、需要靠感受的事情的确弱了一些。
第四点的原因主要有两个。
一个是对自己的代码过度自信导致，我自己深有体会。我还记得有一次我交付一个功能，那个功能我单元测试都写了不少，对质量很有信心，觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug。
另一个原因是反正有测试人员在，等他们测出问题我再改不是更轻松。惰性使然，从个人角度的确如此。但是从团队角度来看，徒增了不少的沟通成本。
第五点的原因也有两个。
一个是行业里的新技术迭代的确太快，怕不学新技术被淘汰。
另一个原因是，只有用上新技术才能有谈资，显得自己与众不同、有成就感。
以上就是对这五点的简单分析，那么如何改善呢？继续往下看。
下面这些方法都是我亲测有效的，强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。
01 说实现不了之前，先三思
根据先后可以做以下3个思考：
是觉得这个功能没有价值不想做吗？
真的实现不了？我想全了吗？
这些方案里，有成本比价值低的吗？
第一个问题先确定必要性。我们不是说不能推需求，而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算，但至少这才能算是拒绝的理由。
第二个问题，努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案，那么将会永远在舒适区止步不前。
第三个问题，拒绝需求虽然不用动之以情，但一定需要晓之以理。当你能清楚的阐述利弊、收益比，拒绝需求自然不是一件需要相互扯皮的事情。
经过了这三个问题的思考，不管最终能不能实现，相信可以很好的与产品经理达成共识。
02 明白需求本身也是成本
过度地苛求需求要细、要完整、要全面，这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本，产品经理的也是。
与其等一个“XXXX最终绝对不改版”，不如从已经达成共识的部分开工，在这个过程中再与产品经理「共创」，多一起沟通打磨，此时再让产品完善PRD等文档，形成最终版。
03 刻意练习，多换位到用户视角
平时多去体验一下自家的产品以及竞品，把整个过程中的感受记录下来。比如，哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。结果不重要，重要的是这个过程，慢慢锻炼自己作为用户的感知力。
有些程序员看起来经常把用户体验挂在嘴上，其实提出来的很多反而是脱离大众习惯的“个性化”需求，就是因为平时缺少对同行、外界的关注。
04 交付的东西是自己的「招牌」
“有人的地方就有江湖，有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态，你在别人心中的称号就是负面的。
轻则影响自己的口碑，影响与他人之间的协作关系；重则失去未来的晋升机会。一个对自己的东西都不负责的人，如何负责更多的人、更大的事情呢？
在这件事上，除了多自测外，作为过来人，我建议每一个程序员认真对待单元测试。特别把核心、复杂的方法单元测试给做上，这对交付功能的质量的提升非常明显。
05 不产生价值的新技术是“垃圾”
拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它，这不但给团队在挖坑，也在给自己挖坑。
比如你花了不少的时间在项目里用了某个新技术，但是对团队没有带来什么价值，你说后续公司还会继续投入资源加大新技术的使用吗？大概率并不会。那么之前了解到的一些知识，就会随着时间的推移而淡忘，投入的时间大多数浪费掉了。
所以，对待新技术Z哥的观点是。对于无法在工作中找到价值点的新技术浅尝辄止即可。相反，遇到可以产生价值的新技术，请全身心投入进去，而不是仅仅在应用层面捣腾，不去深入细节。之前发过一篇讲解新技术选用的文章《程序员与新技术之间的「爱」与「恨」》，可以点击文末的链接阅读。
很多程序员对待新技术的习惯是，打一枪换一个地方，经过了几年，发现技术实力还在原地打转，不免有些可惜。
另外，推荐大家可以阅读一两本心理学、行为学相关的书，特别是我们做程序员的。
这不但可以提高自己对用户体验的感觉，还能提高对人性的洞察力，包括对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。
好了，总结一下。
这篇呢，Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议：
1.说实现不了之前，先三思。
2.明白需求本身也是成本。
3.刻意练习，多换位到用户视角。
4.交付的东西是自己的「招牌」
5.不产生价值的新技术是“垃圾”
希望对你有所帮助。
作者：Z哥，公众号“跨界架构师”
英雄会被表彰，这些技术与代码也将载入史册！
科技创新 • 柠檬^ 发表了文章 • 1 个评论 • 137 次浏览 • 2020-09-10 16:14
昨天，我们被「人民英雄」刷屏了。
上午十点，全国抗击新冠肺炎疫情表彰大会，在人民大会堂隆重举行。
大会授予钟南山「共和国勋章」，授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。
除了这些战疫者之外，在今年抗击疫情过程中，还有一批特殊的「功臣」，也在今年的抗疫战中立下汗马功劳，从而被纳入国家博物馆收藏。
历史也将铭记：代码、无人车、外卖服
近日，国家博物馆陆续上新，这批最新纳入的藏品，与以往的有所不同：这些物品都是为纪念抗疫征集而来，将成为历史文物。
国博曾在 3 月向社会公开征集
抗疫相关实物与资料
国博发出抗疫藏品征集公告之后，社会各界都纷纷响应，捐出了各种具有纪念意义的物品。
如今最新加入国博的这些成员，不仅因为见证了这场抗疫历史，而拥有了特殊的意义，也因为其自身鲜明的时代特色，而显得十分别样。
阿里：三段代码
本次藏品征集中，阿里提交了包括 4 本新型冠状病毒肺炎临床救治手册、2 本新冠疫情爆发下的医院应对策略、六大洲捐赠的提单和报关单、等 14 种共 30 件抗疫实物。
这其中，有三件「物品」与众不同，它们分别是：
支付宝团队研发的健康码系统第一行代码； 阿里云研发的全国健康码引擎第一行代码； 阿里巴巴达摩院研发的新冠肺炎 CT 影像 AI 辅助诊断产品第一行代码。
与代码一起纳入收藏的，还有参与该项目的程序员签名
除了体温、核酸检测等线下手段外，健康码这个数字化防疫工具，也成为人人出行的必备凭证。
它们包括：JD40006 号无人配送车、湖北省新冠疫情防控指挥部的感谢信、钟南山院士的感谢信、内蒙古援鄂医疗队医护人员写给京东快递小哥的感谢信、技术抗疫纪录片。
据报道，疫情期间，32 岁的退伍军人付腾虎，组建了一支特别的外卖配送队「飞虎队」，给武汉协和医护人员送餐。他们每天一趟送几十份餐，累计送了万份餐。
「写代码写进国博挺酷的，有点激动，是个纪念。到时候国博有展，我一定会去北京看的。」支付宝前端开发刘志飞说。
收藏代码，是国家博物馆的第一次，却也有例可循。GitHub 在前不久将一部分开源代码，以胶片的形式储存，打包运往北极冷岸群岛。
这批代码胶片被存放在极其干燥的、-5°C 恒温的矿井中
健康码也是一样，这些「摸不着」的代码，是这段重要、特殊的 2020 年里，重要的组成部分。
我们将铭记这段不同寻常的时期，后人也会了解到这段用科技、医疗、人文关怀一起驱动着全体国民，共同抗击疫情的历史时刻。
来源公众号：HyperAI超神经
曲线救国：提高github下载速度到2MB/s
IM即时通讯 • 梅川酷子 发表了文章 • 0 个评论 • 186 次浏览 • 2020-07-29 09:15
因为网络连接的原因，在国内从github上面下载代码的速度峰值通常都是20kB/s。
这种速度对于那些小项目还好，而对于大一些的并且带有很多子模块的项目来讲就很耽误时间。
常见的方法是通过代理连接，但实际用起来并不稳定。
这里提供一种新的思路，下载速度可以达到1~2MB/s
1. 利用开源中国提供的代码仓库
标题已经说的很清楚了，我想对于经常使用git的人来讲，很可能已经知道了。对于新手刚接触git的人来讲，可能你只知道github。
实际上，国内也有很多代码仓库提供方，国外也不只github。只不过国内也是刚刚开始，关注的人不多。
开源中国提供的代码仓库提供了一个功能，就是它可以将github账号中的代码 clone 到开源中国的账户中去。这个代码仓库叫做 码云 ，没错就是 Ma云！
要求你有一个github账户，一个码云gitee账户。
步骤很简单
1.将github上面你想要搞下来的项目首先 frok 到你自己的github的账户中去。耗时:一瞬间
2.登录gitee，没有的自行注册。网页中有添加项目的按钮，一个加号。点击加号，下拉列表里面有 迁移github项目 的选项，点开后按照提示关联自己的github账号，之后选择你要迁移的项目，按提示操作。耗时:不到三分钟。
3.按照 clone github项目方法， clone 迁移到gitee账户中的项目。区别是 clone 链接换成了目标项目在gitee中的链接。通常下载速度是以MB/s为单位的。
按照上面的方法，基本上不再需要整夜挂机 clone 代码了。
最近重新看了下，其实上面的步骤有些繁琐，其可以更简单，新建仓库直接设置远程仓库地址。
第一步：
新建仓库
第二步：
以github仓库https://github.com/PX4/Firmware.git举例
第三步：
第四步
2. 提高下载子模块的速度
有的项目里用到了第三方代码仓库，但是在你使用 clone 指令的时候这些子模块 submodule 并不会自动下载，因为他们在另外的地址中存放。你需要 clone 完目标项目后，执行
git submodule update --init --recursive
才会将目标项目所需要的依赖子模块下载下来。github项目中所用到的子模块依然是放在了github上。这就很悲剧了，这意味着你在执行上面指令后，依然需要面对上面的20KB/s的速度。虽然此时并不会显示出来，然而等待依然很久。
我们同样使用上面加速 clone 的思路。
从下载的项目中找到其使用的 submodule 的链接是哪里。
打开上一步中的链接，将使用的目标子模块的代码同样 frok 到自己的github账户中，之后同样的方法迁移到gitee中去。有多个子模块就多重复几次操作，同样的套路。
将原项目使用的 submodule 模块的链接地址修改为子模块迁移到gitee中后的地址。
这时再去执行
git submodule update --init --recursive
以上就是提高下载子模块速度的思路。具体每步的操作，请自行搜索，网上一搜一大片。
附：关于如何修改submodule连接地址 https://blog.csdn.net/wangjia55/article/details/24400501 https://www.jianshu.com/p/c81e2bd377ad https://blog.csdn.net/qq_22630169/article/details/74236535 https://blog.csdn.net/wangjia55/article/details/24400501
版权声明：本文为CSDN博主「kcx64」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kcx64/article/details/83866633
GitHub推出「打赏」功能，全球最大同性交友平台将迎来更多开源工作？
技术活动 • 大兴 发表了文章 • 0 个评论 • 173 次浏览 • 2020-07-22 15:02
近期，GitHub 发布了一条新功能——GitHub Sponsors，也就是我们熟悉的「打赏」。GitHub 官方表示，打赏的每一分钱都会进开发者的口袋，他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub 都有打赏了，到底是好还是坏？
GitHub 官方表示，「开发者们为我们大家贡献了开源工具，这是对他们的经济支持，新的打赏功能将帮助他们构建更优秀的开源工作。」然而，这不得不让人感叹，作为全宇宙最自由、最神圣的交友社区，GitHub 也开始增加打赏属性。所以为了顺应大流，欢迎 Star 和 Fork 融云GitHub 项目～
项目地址https://github.com/rongcloud-archive
为了启动这一新项目并激发社区打赏积极性，GitHub 还推出了 GitHub Sponsors Matching Fund，每个开发者第一年最多可匹配到 5000 美元的赞助基金。
这是一个开源的世界。如果没有维护者、设计者、编程者、研究者等组成的全球团队促进科技发展，世界就难以运行。这些卓越的开发者现在可以从社区中按劳取酬，通过自己的 GitHub 文件获取经济支持。
中间商不赚差价，打赏功能全球通用
开源是 GitHub 的核心。构建共享数字基础设施的开发者使得这个社区更加强大。GitHub 表示，为了表示对贡献者的感谢，GitHub Sponsors 在用户打赏其他开发者时不会收取平台费用。此外，为了庆祝这一功能的推出，GitHub 还将为前 12 个月的支付处理开销买单。简而言之，你打赏的每一分钱都会进开发者的口袋。
此外，打赏功能没有地域限制，只要在 GitHub 开展业务的国家，这一功能都能使用。
所有贡献者都能赏
在优秀的项目中，很多贡献者（contributor）都会做出至关重要的贡献，但他们的贡献在代码评审中并不可见。GitHub Sponsors 的推出是为了帮助所有类型的贡献和工作，从而进一步帮助开发者构建开源系统。任何对开源项目做出了贡献的人，不论是代码修改、文档编写，还是项目领导、项目设计等，都有可能得到打赏。
目前有一小部分开发者参与了 Sponsors 的测试版，任何开源项目贡献者在未来都有机会受到打赏。当然读者们也能申请下阶段测试的开发者，即填表加入 GitHub Sponsors 的候选者列表：
例如 Go 语言的贡献者，申请成为测试开发者后的赞赏页面大概是这样的：
因此，GitHub Sponsors 是另一种对开源项目做出贡献的方法：为构建和维护项目的开发者提供资金支持。为开发者资金帮助能帮助他们构建更好的开源项目，扩展参与开发的机会，并给予开发者应有的认可。从今天起，任何 GitHub 用户都能资助开源项目的开发者，这也是对项目最好的认可方式。
嵌入 GitHub 工作流
对于我们熟悉的工作流，GitHub Sponsors 现在可以无缝嵌入到里面。当贡献者回答我们的问题、指出我们的错误、或合并我们提交的代码时，我们可以访问他们的资料，或者直接将鼠标放在用户名上来打赏他们的开源工作。
对于新的社区贡献者悬停卡，除了该项目的直接贡献者，我们还能看到该项目传递的依赖性关系。他们虽然没有直接对该开源项目做出贡献，但他们以前的工作或贡献可能为当前项目提供帮助，因此也是我们该赞赏的人。
开源项目还可以直接在 repo 中显示自己的打赏模型。.github/FUNDING.yml 被加到一个项目的主分支上之后，一个新的「Sponsor」按钮就会出现在 repo 的顶端。单击该按钮将打开该文件中列出的打赏模型的本地渲染视图。
YAML 板式非常灵活，因此项目的维护者和贡献者可以根据自己的条件决定如何打赏项目。他们可以展示以下任何（或全部）内容：为该项目做出贡献的开发者的 GitHub Sponsors 文件；包含 Open Collective、Community Bridge、Tidelift、Ko-fi 和 Patreon 在内的流行打赏模型以及其他打赏模型的自定义链接。
影响
GitHub 的这一做法可能会引起一些争议，部分开发者认为打赏可能会影响到开发者的工作方向。经济利益可能驱使开发者更加关注可能获取经济效益的项目，而不是那些有趣、有挑战性但不太会有人打赏的项目。那么读者们怎么认为？快留言写下你的观点吧。
一个靠 GitHub 打赏的码农，年入十万美元!
技术活动 • 大兴 发表了文章 • 0 个评论 • 171 次浏览 • 2020-07-22 14:48
直到撰写本文时，我的 GitHub 年度打赏金额已经达到了 112680 美元。
创建一个很棒的软件；
使其仅对打赏者开放，直到你积累了一定数量的打赏者；
然后将项目开源给全世界。
我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法，同样取得了成功：
我在文档的适当位置嵌入了这些视频的链接，以帮助大家找到它们几个星期之后，我又为 GitHub 打赏者专门建立了一个「私有」的视频小组：
B站UP主自制的开源OCR翻译器走红Github，用一次就粉了
技术活动 • 梅川酷子 发表了文章 • 0 个评论 • 276 次浏览 • 2020-07-22 09:50
最近一个B站UP主自己撸了一个翻译神器，只要出现在屏幕的东西都可以翻译，关键是操作十分简单，就像下面这样：
适用范围全面，几乎所有出现在屏幕的东西都可以翻译；
翻译接口多，目前有12个翻译接口；
简洁美观的界面；
及其简单傻瓜的操作方式；
相比较其他OCR翻译器配置有自动翻译模式；
需要联网，可能视网速不同翻译速度有差；
PantsuDango为什么要创建这个项目？
PantsuDango本身是个vnr翻译软件的忠实用户，但是遇到某些游戏无法提取文本，然后偶然发现有OCR（文字识别）技术的存在，下载了很多已经有的OCR翻译器还是不满意，于是，索性自己撸了一个。
PantsuDango目前在Github标星 816，累计分支 88 个（Github地址：https://github.com/PantsuDango/Dango-Translator）
来自：开源最前线（ID：OpenSourceTop）
项目地址：https://github.com/PantsuDango/Dango-Translator
我，一个靠 GitHub 打赏谋生的程序员，如何做到年入 10 万美元？
技术活动 • 王叫兽 发表了文章 • 0 个评论 • 192 次浏览 • 2020-07-06 11:51
如果提到靠打赏生活的人，我们首先想到的会是主播。但现实情况是，程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。
在过去的一年里，他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中，他分享了自己靠 GitHub 项目赚钱的经历和技巧。
Caleb Porzio 发推庆祝自己靠 GitHub 打赏（GitHub Sponsors）赚到了 10 万美元。
GitHub Sponsors 是 GitHub 2019 年 5 月份推出的一个功能，允许开发者通过自己的项目获取报酬/赞赏。
创建一个很棒的软件；
使其仅对打赏者开放，直到你积累了一定数量的打赏者；
然后将项目开源给全世界。
转自：机器之心 （张倩、蛋酱）
原文链接：https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it
