github

github

10月份Github上最热门的开源项目

科技创新柠檬^ 发表了文章 • 0 个评论 • 83 次浏览 • 2020-11-04 14:47 • 来自相关话题

10月份GitHub上最热门的Java开源项目排行已经出炉啦,一起来看看上榜详情吧:1、base-adminhttps://github.com/huanzi-qch/base-admin Star 1499Base Admin一套简单通用的后台管理系统,这套... ...查看全部

10月份GitHub上最热门的Java开源项目排行已经出炉啦,一起来看看上榜详情吧:


1、base-admin

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

微信图片_20201104144432.jpg

Auto.js是一款强大的不需要root的类似与按键精灵的软件,可以让你跟电脑中按键精灵一样实现自动点击,打开应用等等功能,能够解放你的双手,以及双眼,轻松的帮助你完成各种日常工作。

4、advanced-java

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代码概念,一系列在线智能开发:在线配置表单、在线配置报表、在线设计流程等等。



8、Java

https://github.com/TheAlgorithms/Java Star 31964

微信图片_20201104144525.jpg

该项目用Java实现的所有算法。



9、toBeTopJavaer

https://github.com/hollischuang/toBeTopJavaer Star 18030


Java工程师成神之路,完整大纲如下:

微信图片_20201104144544.jpg

10、Mindustry

https://github.com/Anuken/Mindustry Star 6314


Mindustry是由AnukenDev开发和发行的一款开放式的塔防游戏。在这款游戏中,你的防御塔将不再像一般的塔防游戏一样可以无限开火,而是需要你将炮弹通过传送带运到炮塔上,因此你需要设计一系列合理的供应路线,同时生产基本的材料,保卫你的基地。游戏还支持多人跨平台游戏和PVP模式。



11、jsoncat

https://github.com/Snailclimb/jsoncat Star 289


这是一个仿仿Spring Boot但不同于Spring Boot的一个轻量级的HTTP框架。



12、EhViewer

https://github.com/seven332/EhViewer Star5788

微信图片_20201104144614.jpg

EhViewer是一款非常绅士的漫画阅读软件。ehviewer上汇集了海量漫画资源。


开源最前线(ID:OpenSourceTop) 猿妹整编

转载请注明来源作者




懂程序员的产品经理是什么样子?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 153 次浏览 • 2020-09-16 10:36 • 来自相关话题

在互联网行业,产品经理和程序员之间的关系很微妙。表面看上去水火不容,在一方的眼里看另外一方总是有这样那样的问题,相互吐槽。但现实是,大家都知道和对方在同一条船上。产品没做好的话,除了公司利益受损,产品经理和程序员也会各回各家各找各妈,重新找新工作去。产品做得好... ...查看全部

在互联网行业,产品经理和程序员之间的关系很微妙。表面看上去水火不容,在一方的眼里看另外一方总是有这样那样的问题,相互吐槽。但现实是,大家都知道和对方在同一条船上。

产品没做好的话,除了公司利益受损,产品经理和程序员也会各回各家各找各妈,重新找新工作去。

产品做得好的话,双方和睦相处、其乐融融?那是不可能的,这个辈子都不可能和睦相处。矛盾会更加严重……(都觉得自己功不可没)

所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员,都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的,而不是一个零和博弈。

这个主题会分别从不同的两个视角展开,今天我们先聊程序员视角,本来想两个视角一起聊,发现内容太多,写到一半还是拆了,先把一个视角写了。

如果你是程序员可以看看以下这些描述是你眼中的产品经理么?

如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。

程序员吐槽产品经理最多的原因主要是以下几个(以下内容可能会引起程序员们的极度舒适~):

  1. 开发过程中频繁修改需求。

  2. 验收过程中要求做比较大的修改。

  3. 说不清楚需求的价值

  4. 替程序员评估工作量

  5. 需求整理的不够细。

其中,频繁修改需求是程序员们最反感的,这是毋庸置疑的。

从产品经理的角度来说,虽然无法100%在开发过程中不修改需求,但是如果前期的工作做得足够充分,与业务方的沟通足够到位,至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理,在自己对业务都是一知半解的时候就开始整需求了,这必然会导致后续频繁的需求变更。

第二,验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候,脑子里是一万头草泥马奔过……

产生这个情况的原因有很多。可能是程序员理解偏差,也有可能是产品觉得功能效果不佳。但是大多数时候,产生这个情况的根本原因还是在需求评审阶段的沟通不够充分,双方之间并没有达成真正的共识。

但是如果要说什么时候双方的矛盾最激烈,那还不是修改需求的时候,而是需求评审的时候。

此时,很容易看到的一个景象是“讨价还价”。产品经理站在「价值」一方,程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时,如果产品经理无法阐述出该功能令人信服的价值,那么必然受到吐槽。这是原因三。

原因四,有些产品经理是从程序员转过去的,之前做过一两年的开发工作。这个时长的经验其实是很危险的,很容易陷入到「达克效应」的第一阶段:高估自己的技术能力,低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理,甚至会在需求评审的时候替程序员预估时间,如果高于自己的预估,便会认为他们偷懒。

最后一点。相信每个人程序员都提出过这样的问题“这里如果……,那么要怎么处理?”。这种就是需求考虑不够细致的体现。不过,要做好这点的确挺难的,这也是产品经理花费时间最多的地方。

聊了这么多场景,作为产品经理应该如何应对呢?

从思路上分为以下几步。

01

先明确大方向,并与程序员达成一致。

正如前面所提到的,产品经理站在「价值」方,程序员站在「成本」方,这注定了他们是对立的。最坏的结果就是双方互掐,就算相对好的结果也只是相互妥协做一个半吊子的功能(用系统的人不太舒服)。

但如果你的视野更大,格局更高,就会发现,如果以「投入产出比」角度来切入,双方不但都能理解,而且很容达成共识,毕竟花最小的成本干价值最大的活,是个正常人都能理解和认可不是么。

所以,可以在日常工作中不断的强化这个共识。一旦出现争执,就从这个角度来做最终决定,甚至基于这慢慢地还能建立起相互的信任,程序员真正拥有了产品思维,产品经理真正懂了程序员的难处。

02

将产品经理范畴内的事情做到极致。

所谓术业有专攻,与其相互吐槽,不如多花点时间把对方吐槽的地方做到极致。

03

有时候你虽然做的很好,想的也很仔细,但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在「确认偏误」现象。

确认偏误是指搜寻,解释,偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信,并且在面对相反的证据时可以保持或加强信念。

维基百科

所以,运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成,你就得考虑如何提高协作效率。而产品经理和程序员的协作中,沟通又是最重要的。

下面展开说说具体可以做的一些事。主要是思路中的2和3。

01 提高专业性

我观察过一个现象,需求变更比较多的产品经理,他们的工作习惯往往是直接抄起原型工具就画原型,或者有很多工作时间在原型工具里。

这样非常容易陷入到一个思维惯性里面去,就是过于关注交互层面的事情,而轻视了背后业务流程的设计,甚至是业务的合理性。

我认为产品经理做事的时候一定要以User Story为核心来展开,先构思好一个User Story,然后就是把它真实发生的各种细节阐述清楚。做这事的过程先后分为以下四步:

  1. 定义User Story

  2. 定义交付标准

  3. 提供低保真原型

  4. 编写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 沟通方面

与程序员的沟通方面,我总结了五动作,分别是「齐、拉、捧、说、谦」,可以根据情况组合出击。

「齐」就是视角对齐的意思。在聊需求之前,先交代需求的背景、意义。特别在中途需求变更的时候,这点非常重要。

继续搬出之前用过好几次的图。

640.jpg

如果视角不同,你说接下去还怎么聊?

「拉」是拉拢的意思。亚里士多德说过:

我们无法通过智力去影响别人,而情感却能做到这一点。

亚里士多德

所以,在沟通的时候要把程序员当作自己人看待,而不是敌对。比如,可以多用“我们”,“一起”等词语,进入一个协商的氛围。举个例子:“我们一起来看下这个问题”。少用”我觉得“、”我认为“;

「捧」是吹捧的意思,但并不是简单的拍马屁。

人都是有多面性的,针对不同的情况和场景,可能会表现出不同的特质,这会影响到双方的沟通。比如有的人在生活中很温和,但在工作时非常严苛,要求很高,这就是激发了不同的特质。

类似的,为了激活程序员的积极性,你可以在当下需要他发挥的地方吹捧一下。比如,你觉得某个程序员做的东西质量一般,小问题比较多。那么你在和他聊的时候特地捧一句,“我知道做程序员的都或多或少有完美主义倾向,对细节很关注。我这个功能设计的细节可是想了好久呢,不过对你来说应该很容易搞定吧。”

「说」是说服的意思。想要让对方从心底里的认同你,单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。

重视数据的产品经理有可能是优秀的产品经理,但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务,并且还不能仅仅懂个皮毛。比如,

你得知道哪些环节产生的数据是关键。

多个数据之间的间接关系和影响是什么。

你设计的每一个功能会如何影响这些数据。

……

心里一直有着这些概念,程序员还会吐槽你提的需求价值低?

「让」是谦让的意思。俗话说,“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。

原因有两点。

大多数的产品设计背后有很多的知识是通用知识,每个人的生活经历都能成为经验。而每个人的生活经历又是不同的。

专业不同,哪怕站的视角相同,看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发,提出的观点可能会让你眼前一亮。

以上就是「齐、拉、捧、说、谦」五点。最后再送给你一句话:非必要情况,一定不要用“这是老板的要求“!,重复,重复。重要的事情说三遍。

还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如,在领域驱动设计范畴中Event Storming。它就非常适合在前期的需求评审环节去使用。

感兴趣的可以自行了解。

好了,总结一下。

这篇呢,Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。

思路上分为三步:

  1. 先明确大方向,并与程序员达成一致。

  2. 将产品经理范畴内的事情做到极致

  3. 运用一些沟通技巧解决「确认偏误」现象。

关于第二点,给出的具体措施是。以User Story为核心,做好Use Case的编写工作,而不是花很多时间在原型上。

关于第三点,总结了五个动作,分别是「齐、拉、捧、说、谦」,可以根据情况组合出击。

希望对你有所帮助。

作者:Z哥,公众号“跨界架构师” 

如何做一个懂产品的程序员?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 165 次浏览 • 2020-09-16 10:32 • 来自相关话题

两个相爱相杀的岗位,想要更好的达成共识、更好的合作,自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。直接进入正题吧。从产品视角是怎么看程序员的呢?我根据我自己的经历以及与其他产品经理的交流下来看,吐槽的主要是以... ...查看全部

timg.jpg

两个相爱相杀的岗位,想要更好的达成共识、更好的合作,自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。

直接进入正题吧。

从产品视角是怎么看程序员的呢?我根据我自己的经历以及与其他产品经理的交流下来看,吐槽的主要是以下几点:

  1. 这个功能实现不了。

  2. 希望所有产品都不要改版,一次性把现在或未来要做的开发完。

  3. 只关心要写多少代码,不在乎产品体验。

  4. 写完程序从不自测,直接丢给别人测试。

  5. 过分追寻新技术潮流,完全不考虑对产品带来什么价值。

第一点,的确存在一些由于技术限制导致实现成本无限大的需求,比如手机屏幕背景色根据手机壳颜色切换……

但是,国内的技术环境不像老美那的技术味道重,大多还是商业导向的,很少企业里需要用到高精尖的技术,所以,真正实现不了的功能微乎其微。

对于大多数的功能需求来说,无非是一个成本大小、价值高低的问题。从立场上看,程序员自然是站在「成本」一方的,但对大多数人来说,决定这个成本的主要因素往往是自己工作的难度和耗时,费时费力的功能就容易得到“实现不了”的结果。

第二点对大多数产品经理来说是他们的对立面。因为大多数产品经理最喜欢“走一步算一步”地高频迭代,甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的,并且内容要非常详细的,心里的想法是,这样的话我一开始就可以设计一个完美架构来支撑它。

而且,内容越详细,产品经理就越不敢乱调整需求,毕竟“证据在手”嘛:D。

第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多,对需要有同理心、需要靠感受的事情的确弱了一些。

第四点的原因主要有两个。

一个是对自己的代码过度自信导致,我自己深有体会。我还记得有一次我交付一个功能,那个功能我单元测试都写了不少,对质量很有信心,觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug。

另一个原因是反正有测试人员在,等他们测出问题我再改不是更轻松。惰性使然,从个人角度的确如此。但是从团队角度来看,徒增了不少的沟通成本。

第五点的原因也有两个。

一个是行业里的新技术迭代的确太快,怕不学新技术被淘汰。

另一个原因是,只有用上新技术才能有谈资,显得自己与众不同、有成就感。

以上就是对这五点的简单分析,那么如何改善呢?继续往下看。

下面这些方法都是我亲测有效的,强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。

01  说实现不了之前,先三思

根据先后可以做以下3个思考:

是觉得这个功能没有价值不想做吗?

真的实现不了?我想全了吗?

这些方案里,有成本比价值低的吗?

第一个问题先确定必要性。我们不是说不能推需求,而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算,但至少这才能算是拒绝的理由。

第二个问题,努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案,那么将会永远在舒适区止步不前。

第三个问题,拒绝需求虽然不用动之以情,但一定需要晓之以理。当你能清楚的阐述利弊、收益比,拒绝需求自然不是一件需要相互扯皮的事情。

经过了这三个问题的思考,不管最终能不能实现,相信可以很好的与产品经理达成共识。

02  明白需求本身也是成本

过度地苛求需求要细、要完整、要全面,这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本,产品经理的也是。

与其等一个“XXXX最终绝对不改版”,不如从已经达成共识的部分开工,在这个过程中再与产品经理「共创」,多一起沟通打磨,此时再让产品完善PRD等文档,形成最终版。

03  刻意练习,多换位到用户视角

平时多去体验一下自家的产品以及竞品,把整个过程中的感受记录下来。比如,哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。结果不重要,重要的是这个过程,慢慢锻炼自己作为用户的感知力。

有些程序员看起来经常把用户体验挂在嘴上,其实提出来的很多反而是脱离大众习惯的“个性化”需求,就是因为平时缺少对同行、外界的关注。

04  交付的东西是自己的「招牌」

“有人的地方就有江湖,有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态,你在别人心中的称号就是负面的。

轻则影响自己的口碑,影响与他人之间的协作关系;重则失去未来的晋升机会。一个对自己的东西都不负责的人,如何负责更多的人、更大的事情呢?

在这件事上,除了多自测外,作为过来人,我建议每一个程序员认真对待单元测试。特别把核心、复杂的方法单元测试给做上,这对交付功能的质量的提升非常明显。

05  不产生价值的新技术是“垃圾”

拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它,这不但给团队在挖坑,也在给自己挖坑。

比如你花了不少的时间在项目里用了某个新技术,但是对团队没有带来什么价值,你说后续公司还会继续投入资源加大新技术的使用吗?大概率并不会。那么之前了解到的一些知识,就会随着时间的推移而淡忘,投入的时间大多数浪费掉了。

所以,对待新技术Z哥的观点是。对于无法在工作中找到价值点的新技术浅尝辄止即可。相反,遇到可以产生价值的新技术,请全身心投入进去,而不是仅仅在应用层面捣腾,不去深入细节。之前发过一篇讲解新技术选用的文章《程序员与新技术之间的「爱」与「恨」》,可以点击文末的链接阅读。

很多程序员对待新技术的习惯是,打一枪换一个地方,经过了几年,发现技术实力还在原地打转,不免有些可惜。

另外,推荐大家可以阅读一两本心理学、行为学相关的书,特别是我们做程序员的。

这不但可以提高自己对用户体验的感觉,还能提高对人性的洞察力,包括对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。

好了,总结一下。

这篇呢,Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议:

1.说实现不了之前,先三思。

2.明白需求本身也是成本。

3.刻意练习,多换位到用户视角。

4.交付的东西是自己的「招牌」

5.不产生价值的新技术是“垃圾”

希望对你有所帮助。


作者:Z哥,公众号“跨界架构师” 

英雄会被表彰,这些技术与代码也将载入史册!

科技创新柠檬^ 发表了文章 • 1 个评论 • 110 次浏览 • 2020-09-10 16:14 • 来自相关话题

昨天,我们被「人民英雄」刷屏了。上午十点,全国抗击新冠肺炎疫情表彰大会,在人民大会堂隆重举行。大会授予钟南山「共和国勋章」,授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。除了这些战疫者之外,在今年抗击疫情过程中,还有一批特殊的「功臣」,也在今年的抗疫战中立... ...查看全部

昨天,我们被「人民英雄」刷屏了。

上午十点,全国抗击新冠肺炎疫情表彰大会,在人民大会堂隆重举行。

大会授予钟南山「共和国勋章」,授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。

除了这些战疫者之外,在今年抗击疫情过程中,还有一批特殊的「功臣」,也在今年的抗疫战中立下汗马功劳,从而被纳入国家博物馆收藏。

历史也将铭记:代码、无人车、外卖服

近日,国家博物馆陆续上新,这批最新纳入的藏品,与以往的有所不同:这些物品都是为纪念抗疫征集而来,将成为历史文物。

2.png

国博曾在 3 月向社会公开征集

抗疫相关实物与资料

国博发出抗疫藏品征集公告之后,社会各界都纷纷响应,捐出了各种具有纪念意义的物品。

如今最新加入国博的这些成员,不仅因为见证了这场抗疫历史,而拥有了特殊的意义,也因为其自身鲜明的时代特色,而显得十分别样。

阿里:三段代码 

本次藏品征集中,阿里提交了包括 4 本新型冠状病毒肺炎临床救治手册、2 本新冠疫情爆发下的医院应对策略、六大洲捐赠的提单和报关单、等 14 种共 30 件抗疫实物。

这其中,有三件「物品」与众不同,它们分别是:

  • 支付宝团队研发的健康码系统第一行代码;
  • 阿里云研发的全国健康码引擎第一行代码;
  • 阿里巴巴达摩院研发的新冠肺炎 CT 影像 AI 辅助诊断产品第一行代码。

3.png

与代码一起纳入收藏的,还有参与该项目的程序员签名

众所周知,自 2020 年初新冠肺炎疫情爆发之后,疫情防控成为全国上下第一要务。

除了体温、核酸检测等线下手段外,健康码这个数字化防疫工具,也成为人人出行的必备凭证。

4.png

出入公共场所,健康码已必不可少
据介绍,健康码项目需要阿里旗下的支付宝、阿里云和钉钉团队三方合作完成,因此,这三方团队的工程师组成了健康码团队。
阿里云团队的核心任务是开发码引擎,支付宝和钉钉团队则提供查询获取入口、和核验等功能。
注:码引擎是健康码的后端,它会将用户的个人身份信息通过公安数据库转换化成系统中的唯一代码,指挥红黄绿三码的判断和实时发放。
在三方团队协作下,健康码的第一行代码,于 2 月初的一个凌晨提交,2 月 11 日便在杭州上线。随后,因其方便出示与使用,很快便被推广至全国各地。
如今,这行代码正式被国家博物馆收藏,不仅仅在于其技术上带来的突破,其收藏意义更在于这是中国数字化抗疫的见证、包含着全国人民一段刻骨铭心的记忆。
京东:无人配送车 
京东共有五件物品入选国博藏品,被称为「五件套」。

它们包括:JD40006 号无人配送车、湖北省新冠疫情防控指挥部的感谢信、钟南山院士的感谢信、内蒙古援鄂医疗队医护人员写给京东快递小哥的感谢信、技术抗疫纪录片。

5.png

该无人配送车由京东智能行驶部研发
这辆 JD40006 号无人配送车,是首个成为京东正式员工的机器人。在疫情初期,JD40006 成为京东智能科技应急小组的成员之一,被亲切地称为「大白」,负责疫情期间无接触配送物资。
它依托 L4 级别自动驾驶技术和北斗卫星定位系统,以及远程部署,使整个无人配送过程实现全自动化。抗疫期间,它往返行驶总里程超过 6800 公里,运送包裹约 1.3 万件。
饿了么:骑士外卖服 
外卖,已经成为这个时代不可或缺的一部分。根据易观数据,当前中国一天的外卖规模就超过 20 亿元。如今,外卖早已不限于餐饮,还延伸到生鲜、日常用品、医疗用品等的配送。
如果说,此前外卖带给我们的是便捷与时间自由,那么疫情期间,外卖还带给我们更多的安全感。

据报道,疫情期间,32 岁的退伍军人付腾虎,组建了一支特别的外卖配送队「飞虎队」,给武汉协和医护人员送餐。他们每天一趟送几十份餐,累计送了万份餐。

6.png

「飞虎队」所有骑手签名的外卖服
在这些科技抗疫的代表作中,代码作为一项最为特殊的藏品,也在网络上引起热议。

「写代码写进国博挺酷的,有点激动,是个纪念。到时候国博有展,我一定会去北京看的。」支付宝前端开发刘志飞说。

7.png

刘志飞为参与健康码项目成员之一
代码:现代科技的载体,人类的共同遗产
中国国家博物馆作为中华文物收藏量最丰富的博物馆之一,收藏着上百万件珍贵藏品,而这些藏品无一不蕴藏着厚重的历史气息。
从远古时期的人面鱼纹陶盆,到明清时期的郑和铜钟。这些藏品,都是能够摸得着的实实在在的物体。

收藏代码,是国家博物馆的第一次,却也有例可循。GitHub 在前不久将一部分开源代码,以胶片的形式储存,打包运往北极冷岸群岛。

8.png

这批代码胶片被存放在极其干燥的、-5°C 恒温的矿井中

据介绍,这些代码至多可以保存一千年。GitHub 官方启动这个计划的原因,便是:世界由开源软件提供动力。这些代码是现代文明的隐藏基石,也是全人类的共同遗产。

健康码也是一样,这些「摸不着」的代码,是这段重要、特殊的 2020 年里,重要的组成部分。

9.png

来自知乎用户@克里姆林之主的观点
将这段代码纳入国博藏品,不仅理所应当,也更兼具时代意义。

我们将铭记这段不同寻常的时期,后人也会了解到这段用科技、医疗、人文关怀一起驱动着全体国民,共同抗击疫情的历史时刻。


来源公众号:HyperAI超神经

曲线救国:提高github下载速度到2MB/s

IM即时通讯梅川酷子 发表了文章 • 0 个评论 • 162 次浏览 • 2020-07-29 09:15 • 来自相关话题

因为网络连接的原因,在国内从github上面下载代码的速度峰值通常都是20kB/s。这种速度对于那些小项目还好,而对于大一些的并且带有很多子模块的项目来讲就很耽误时间。常见的方法是通过代理连接,但实际用起来并不稳定。这里提供一种新的思路,下载速度可以达到1~2... ...查看全部

因为网络连接的原因,在国内从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举例

第三步:

3.png

第四步

4.png

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 个评论 • 126 次浏览 • 2020-07-22 15:02 • 来自相关话题

近期,GitHub 发布了一条新功能——GitHub Sponsors,也就是我们熟悉的「打赏」。GitHub 官方表示,打赏的每一分钱都会进开发者的口袋,他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub&nbs... ...查看全部
近期,GitHub 发布了一条新功能——GitHub Sponsors,也就是我们熟悉的「打赏」。GitHub 官方表示,打赏的每一分钱都会进开发者的口袋,他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub 都有打赏了,到底是好还是坏?


GitHub 官方表示,「开发者们为我们大家贡献了开源工具,这是对他们的经济支持,新的打赏功能将帮助他们构建更优秀的开源工作。」然而,这不得不让人感叹,作为全宇宙最自由、最神圣的交友社区,GitHub 也开始增加打赏属性。所以为了顺应大流欢迎 Star 和 Fork 融云GitHub 项目~

项目地址https://github.com/rongcloud-archive

为了启动这一新项目并激发社区打赏积极性,GitHub 还推出了 GitHub Sponsors Matching Fund,每个开发者第一年最多可匹配到 5000 美元的赞助基金。

这是一个开源的世界。如果没有维护者、设计者、编程者、研究者等组成的全球团队促进科技发展,世界就难以运行。这些卓越的开发者现在可以从社区中按劳取酬,通过自己的 GitHub 文件获取经济支持。

微信图片_20200722150039.jpg

中间商不赚差价,打赏功能全球通用


开源是 GitHub 的核心。构建共享数字基础设施的开发者使得这个社区更加强大。GitHub 表示,为了表示对贡献者的感谢,GitHub Sponsors 在用户打赏其他开发者时不会收取平台费用。此外,为了庆祝这一功能的推出,GitHub 还将为前 12 个月的支付处理开销买单。简而言之,你打赏的每一分钱都会进开发者的口袋。


此外,打赏功能没有地域限制,只要在 GitHub 开展业务的国家,这一功能都能使用。


所有贡献者都能赏


在优秀的项目中,很多贡献者(contributor)都会做出至关重要的贡献,但他们的贡献在代码评审中并不可见。GitHub Sponsors 的推出是为了帮助所有类型的贡献和工作,从而进一步帮助开发者构建开源系统。任何对开源项目做出了贡献的人,不论是代码修改、文档编写,还是项目领导、项目设计等,都有可能得到打赏。


目前有一小部分开发者参与了 Sponsors 的测试版,任何开源项目贡献者在未来都有机会受到打赏。当然读者们也能申请下阶段测试的开发者,即填表加入 GitHub Sponsors 的候选者列表:

微信图片_20200722150055.jpg例如 Go 语言的贡献者,申请成为测试开发者后的赞赏页面大概是这样的:微信图片_20200722150106.jpg

因此,GitHub Sponsors 是另一种对开源项目做出贡献的方法:为构建和维护项目的开发者提供资金支持。为开发者资金帮助能帮助他们构建更好的开源项目,扩展参与开发的机会,并给予开发者应有的认可。从今天起,任何 GitHub 用户都能资助开源项目的开发者,这也是对项目最好的认可方式。


嵌入 GitHub 工作流


对于我们熟悉的工作流,GitHub Sponsors 现在可以无缝嵌入到里面。当贡献者回答我们的问题、指出我们的错误、或合并我们提交的代码时,我们可以访问他们的资料,或者直接将鼠标放在用户名上来打赏他们的开源工作。

微信图片_20200722150117.jpg对于新的社区贡献者悬停卡,除了该项目的直接贡献者,我们还能看到该项目传递的依赖性关系。他们虽然没有直接对该开源项目做出贡献,但他们以前的工作或贡献可能为当前项目提供帮助,因此也是我们该赞赏的人。微信图片_20200722150127.jpg

开源项目还可以直接在 repo 中显示自己的打赏模型。.github/FUNDING.yml 被加到一个项目的主分支上之后,一个新的「Sponsor」按钮就会出现在 repo 的顶端。单击该按钮将打开该文件中列出的打赏模型的本地渲染视图。


YAML 板式非常灵活,因此项目的维护者和贡献者可以根据自己的条件决定如何打赏项目。他们可以展示以下任何(或全部)内容:为该项目做出贡献的开发者的 GitHub Sponsors 文件;包含 Open Collective、Community Bridge、Tidelift、Ko-fi  和 Patreon 在内的流行打赏模型以及其他打赏模型的自定义链接。

微信图片_20200722150158.jpg

影响


GitHub 的这一做法可能会引起一些争议,部分开发者认为打赏可能会影响到开发者的工作方向。经济利益可能驱使开发者更加关注可能获取经济效益的项目,而不是那些有趣、有挑战性但不太会有人打赏的项目。那么读者们怎么认为?快留言写下你的观点吧。


一个靠 GitHub 打赏的码农,年入十万美元!

技术活动大兴 发表了文章 • 0 个评论 • 139 次浏览 • 2020-07-22 14:48 • 来自相关话题

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,码农也可以。这位活成主播的码农名叫 Caleb Porzio。在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在这篇自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧... ...查看全部
如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,码农也可以。这位活成主播的码农名叫 Caleb Porzio。

在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在这篇自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧。

微信图片_20200722144328.jpg

Caleb Porzio 发推庆祝自己靠 GitHub 打赏(GitHub Sponsors)赚到了 10 万美元。

GitHub Sponsors是 GitHub 2019 年 5 月份推出的一个功能,允许开发者通过自己的项目获取报酬。

全职开发转自由职业,是怎样一种体验?以下是Caleb的故事。

我要分享一下自己走上自由职业的经历。

2018 年是我做全职开发的最后一年,当时我的年收入大概是 9 万美元。

微信图片_20200722144351.jpg

嗯,虽然说现在开发人员的薪资水平比较疯狂,但 9 万美元对我来说也是一笔可观的收入了。再加上我妻子的收入,以及「胡子主义」生活哲学的指导,我们可以省下很多的钱。

2019 年 1 月 11 日,我离开原来的公司开始「休假」,想要换种心情,做自己想做的一切。几个月后,我正式开始了自由职业者的生活。

「休假」期间,我读到了这篇文章:《Phoenix LiveView: Interactive, Real-Time Apps. No Need to Write JavaScript》,并从中受到启发。我发现自己也可以做出类似的成果。

当时我还发了一条推特:

微信图片_20200722144406.jpg

「决定开发一个类似 Laravel 的东西。我感觉这可能是个重大改变。」

现在看来,这确实改变了我的生活。

也是在这一天,我的「休假期」结束了。我完全被这个后来叫做 Livewire 的项目迷住了,并开始全身心地投入于此,这种沉迷一直持续到现在。

我也创建了一个非常流行的 JS 框架,叫做 AlpineJS,目前也是由我在管理和维护。但那是另外一个故事了……

做开源软件不能完全养活自己,所以我也接过一些小型的代码指导方面的需求,让 2019 全年的收入维持在一个稳定的状态。

这张图是我 2019 年通过自由职业方式获得的收入:

微信图片_20200722144423.jpg

我的收入减少了 7 万美元,看起来是比较冒险的举动。但我知道,如果此刻不开始做这件事,以后可能就更没有机会了。

一路走来,有很多好心人联系我,询问他们是否能够提供项目上的帮助。比如这种:

微信图片_20200722144437.jpg

很长一段时间我没有更新 Patreon(一个众筹创作网站),那里会有一些人每个月给我五美元。如此也很好,但对我来说没有意义。

然后,我发现了 GitHub 的打赏功能,把项目直接托管在 GitHub 上即可。2019 年 12 月 12 日,我成为了 GitHub Sponsors 的一员。

微信图片_20200722144451.jpg

这是我的第一个打赏者,Brian,谢谢你!

迄今为止,我已经从 GitHub sponsors 那里收到了 2.5 万美元打赏金。

微信图片_20200722144504.jpg直到撰写本文时,我的 GitHub 年度打赏金额已经达到了 112680 美元。微信图片_20200722144519.jpg

是运气,还是实力?我有点不敢相信我在开源社区里做开源软件,赚的钱比以往任何时候都多。

掐我一下,我是在做梦吗?

是因为我开发的软件太过优秀?让 535 位开发者每个月都打赏我 14 美元。不管怎么说,继续努力吧!

接下来,我想分享一些过程中的经验,希望能帮到也想从事类似开发工作的人们。

通过 GitHub 打赏赚钱的三个阶段

阶段 1:热心人士

最初,GitHub Sponsors 是一个让忠实粉丝能够资助他们所支持项目的平台。这些人的数量,和真正使用软件以及从中赚钱的人数比起来,并不算多。

基于开源的前提,人们本来就可以免费获得该软件。所有收入完全是来自那些友善热心肠的人们。

微信图片_20200722144536.jpg

首先,非常感谢这些人。然后我们谈谈第一个高峰是怎么到来的。

阶段 2:打赏软件

这个阶段,事情开始变得奇妙。

微信图片_20200722144549.jpg

当时,我和我的兄弟 Daniel 录制了一期《No Plans To Merge》。在思考如何将其变现时,我们想到了一个新颖的想法:「打赏软件」。

它的工作方式如下:

  1. 创建一个很棒的软件;

  2. 使其仅对打赏者开放,直到你积累了一定数量的打赏者;

  3. 然后将项目开源给全世界。



这是一种双赢。效果很好,几天之内我的收入就增加了 1.1 万美元。

微信图片_20200722144602.jpg我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法,同样取得了成功:微信图片_20200722144614.jpg

这种方法很棒,但是需要不断地提供新的想法,所有的这些都将成为我必须持续进行的项目。长远来看,我需要更合理的东西。

阶段 3:教学视频

我得到的大部分打赏金都是这个阶段来的:

微信图片_20200722144625.jpg

这里边有什么秘诀吗?答案是:录制教学视频。

构建有用的软件是一回事,但教别人怎么用完全是另一回事。

我尽力创建高质量的文档,但总有人需要更加高级的内容。

为了满足这些需求,我录了一系列教学视频。在这之后的三个月里,我的总收入从 4 万美元涨到了 10 万美元以上。

微信图片_20200722144638.jpg我在文档的适当位置嵌入了这些视频的链接,以帮助大家找到它们微信图片_20200722144653.jpg几个星期之后,我又为 GitHub 打赏者专门建立了一个「私有」的视频小组:微信图片_20200722144703.jpg

这就是我的秘诀(为了做到以上这些,我利用 GitHub 认证构建了一个 Laravel app 来调用 GitHub API,以验证用户是否为打赏者)。

现在,那些看免费视频的人自然会遇到这些「私有」视频,如果他们喜欢前面那些免费的内容,他们就会给我打赏来获取后面的视频。

每次有新特性出现,我都会放出一批新视频。此外,我还会给每位打赏者提供访问每节课源代码的入口。

在 90 天的时间里,我的年收入增长了大约 8 万美元。

现在我有了连续的收入,不用再将所有时间都花在课程发布上了。我将用空出来的时间继续开发这个软件,同时放出新的视频。

如何通过打赏赚更多钱?

实力是第一位的

要做到靠打赏谋生,首先离不开日益月累的磨练,你做的东西要真正有用才行。我把我所有的一切都投入到工作中,这点没有捷径。

你可以发现,我在一个开源项目中全职工作了整整一年才看到收入。能得到人们赞助的工作必须是高质量的,而且始终是排在第一位的。

积极寻找用户

你可以在网上创建最伟大的工具,但如果没有人关注,再伟大的工具也无法为你带来收入。因此,找到用户是赚钱的关键。在这方面,你的 Twitter 粉丝和邮件订阅者都是潜在的挖掘对象。

打赏金额设置不要太保守

很多 GitHub 开发者犯的最大的一个错误就是在初级打赏设置中写的钱数太少。

如果打赏者能选 1-5 美元 / 月,谁还会选更高的打赏金额。

我很早就意识到,如果我真的想做这件事,只有 5 美元的打赏肯定是不够的,所以我后来涨到了 14 美元。

给打赏等级取一个好名字

在给打赏等级取名的时候,记得取一个能描述打赏者类型的恰当名字。

举个例子,对于一个高级打赏等级来说,它的标签应该是「The Agency(代理)」或其他能够暗示一个公司应该给予高级打赏的标签,而不是「Platinum(白金)」这种模糊的说法。

这样一来,人们看到这个标签首先想到的会是:「我的用途到底属于哪一类」,而不是:「我每个月要花多少钱」。

不要羞于谈钱

在我的成长过程中,我一直认为谈钱是不礼貌的,但其实这是一个谎言。有一次,我一股脑涨了 1 万美元,因为一个合作者告诉我他们都赚多少钱。在得知他们的收入情况后,我对自己的要价感到心安理得。但如果他们不告诉我这个情况,什么都不会发生。

透明是一个健康的现象。

我不会隐瞒自己的收入,因为别人也不对我隐瞒他们的收入,这让我从中获利。

即使他们赚的比我多得多,我也不会感到心痛或想分一杯羹。相反,我只会感到激动和鼓舞。我希望其他人也能保持这种心态。

直接告诉别人你完全依赖这笔钱生活也没什么不礼貌的,而且这笔钱帮你打造出了人们每天都在用且从中受益的软件。

不要因为赚了很多钱而感到内疚

我一直都在提醒自己,我不是一个码农传教士。如果我的打赏收入超过了平均生活水准,那也不错。我经营的也不是非营利组织。

我的收入和我的软件所带给别人的价值成正比,这没什么问题。

我做的不是什么神圣的工作,那些软件是企业拿来赚钱的,他们从中牟利,所以我从中赚钱也是 OK 的。

网友:我也能这么做吗?

Caleb Porzio 的这份经历也引起了许多开发者的关注,讨论最热烈的问题是:在我的国家或者地区,这个方法行得通吗?

微信图片_20200722144720.jpg

「看到这些,我为自己国家芬兰的法律而感到难过。我们有一项名为筹款法的法律,其中规定,要想收取捐款(即无任何回报的支付)必须获得许可。这个许可证是付费的,而且不发给个人,只授予非营利活动。」

这就意味着,如果你在软件项目上看到捐赠按钮,并且该笔资金流向芬兰人,这个过程是违法的。

所以这位芬兰的开发者表示,他自己托管了一个免费项目,为此不得不成立一家公司(独资经营)并出售一些其他的东西,以便从服务中获利。即便人们有捐赠的意愿,他也不能「合法地」接受这些钱。

    微信图片_20200722144739.jpg

有人表示,在大多数西方国家都有类似的规定。因此,对于这些国家的人来说,自由职业虽然「自由」,但也同样需要花费更多的精力去管理琐事。

微信图片_20200722144750.jpg

但在美国,这种做法的门槛要低得多。「如果是在美国的话,你可以作为个人接受无偿礼品,也可以作为个体经营者接受营业收入,无需额外注册什么。与往常一样,你需要精确缴纳税费,包括预扣税。」

原文链接:https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it


B站UP主自制的开源OCR翻译器走红Github,用一次就粉了

技术活动梅川酷子 发表了文章 • 0 个评论 • 205 次浏览 • 2020-07-22 09:50 • 来自相关话题

最近一个B站UP主自己撸了一个翻译神器,只要出现在屏幕的东西都可以翻译,关键是操作十分简单,就像下面这样:和其他翻译软件相比,Dango-Translator有以下优点:适用范围全面,几乎所有出现在屏幕的东西都可以翻译;翻译接口多,目前有12个翻译接口;简洁美... ...查看全部

最近一个B站UP主自己撸了一个翻译神器,只要出现在屏幕的东西都可以翻译,关键是操作十分简单,就像下面这样:

1.jpg

和其他翻译软件相比,Dango-Translator有以下优点:
  1. 适用范围全面,几乎所有出现在屏幕的东西都可以翻译;

  2. 翻译接口多,目前有12个翻译接口;

  3. 简洁美观的界面;

  4. 及其简单傻瓜的操作方式;

  5. 相比较其他OCR翻译器配置有自动翻译模式;

  6. 需要联网,可能视网速不同翻译速度有差;


这个OCR翻译利用了百度AI的文字识别,通过识别图片上的外文文字进翻译,使用方法十分简单:

2.jpg

第一页是API设定界面,需要注册自己的API码才可以使用翻译器:

3.png

接着,你还可以设置翻译源,这里面有12个翻译接口,你可以根据自己需要选择:

4.jpg

就连翻译样式也可以自定义设置,设定不同翻译源翻译时的文字颜色,字体样式,以及翻译时是否显示原文,是否将原文自动复制到剪贴板。

当然,还有其他的一些设置,比如你还可以启用竖排文字翻译模式。

5.jpg

简单来说,该软件为OCR翻译器,OCR利用了百度AI的文字识别,原理为通过识别图片上的外文文字并进行翻译。

它不仅适用于galgame、rpg游戏、模拟器游戏、外文视频、网页游戏、pdf图片版文献等等,还适用于一切能显示在电脑屏幕上的文字。支持的语种,目前仅支持日语、英语、中文,相信后期创建者会持续完善,加入更多语言支持。

PantsuDango为什么要创建这个项目?


PantsuDango本身是个vnr翻译软件的忠实用户,但是遇到某些游戏无法提取文本,然后偶然发现有OCR(文字识别)技术的存在,下载了很多已经有的OCR翻译器还是不满意,于是,索性自己撸了一个。

6.jpg


PantsuDango目前在Github标星 816,累计分支 88 个(Github地址:https://github.com/PantsuDango/Dango-Translator)


来自:开源最前线(ID:OpenSourceTop) 

项目地址:https://github.com/PantsuDango/Dango-Translator


我,一个靠 GitHub 打赏谋生的程序员,如何做到年入 10 万美元?

技术活动王叫兽 发表了文章 • 0 个评论 • 169 次浏览 • 2020-07-06 11:51 • 来自相关话题

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和... ...查看全部

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。


在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧。

2-1.jpg

Caleb Porzio 发推庆祝自己靠 GitHub 打赏(GitHub Sponsors)赚到了 10 万美元。


GitHub Sponsors 是 GitHub 2019 年 5 月份推出的一个功能,允许开发者通过自己的项目获取报酬/赞赏。


全职开发转自由职业,是怎样一种体验?以下是 Caleb 的故事。

我要分享一下自己走上自由职业的经历。

2018 年是我做全职开发的最后一年,当时我的年收入大概是 9 万美元。
2-2.jpg
嗯,虽然说现在开发人员的薪资水平比较疯狂,但 9 万美元对我来说也是一笔可观的收入了。再加上我妻子的收入,以及「胡子主义」生活哲学的指导,我们可以省下很多的钱。

2019 年 1 月 11 日,我离开原来的公司开始「休假」,想要换种心情,做自己想做的一切。几个月后,我正式开始了自由职业者的生活。

「休假」期间,我读到了这篇文章:《Phoenix LiveView: Interactive, Real-Time Apps. No Need to Write JavaScript》,并从中受到启发。我发现自己也可以做出类似的成果。

当时我还发了一条推特:
2-3.jpg
「决定开发一个类似 Laravel 的东西。我感觉这可能是个重大改变。」

现在看来,这确实改变了我的生活。

也是在这一天,我的「休假期」结束了。我完全被这个后来叫做 Livewire 的项目迷住了,并开始全身心地投入于此,这种沉迷一直持续到现在。

我也创建了一个非常流行的 JS 框架,叫做 AlpineJS,目前也是由我在管理和维护。但那是另外一个故事了……

做开源软件不能完全养活自己,所以我也接过一些小型的代码指导方面的需求,让 2019 全年的收入维持在一个稳定的状态。

这张图是我 2019 年通过自由职业方式获得的收入:
2-4.jpg
我的收入减少了 7 万美元,看起来是比较冒险的举动。但我知道,如果此刻不开始做这件事,以后可能就更没有机会了。

一路走来,有很多好心人联系我,询问他们是否能够提供项目上的帮助。比如这种:
2-5.jpg
很长一段时间我没有更新 Patreon(一个众筹创作网站),那里会有一些人每个月给我五美元。如此也很好,但对我来说没有意义。

然后,我发现了 GitHub 的打赏功能,把项目直接托管在 GitHub 上即可。2019 年 12 月 12 日,我成为了 GitHub Sponsors 的一员。
2-6.jpg
这是我的第一个打赏者,Brian,谢谢你!

迄今为止,我已经从 GitHub sponsors 那里收到了 2.5 万美元打赏金。
27.jpg
直到撰写本文时,我的 GitHub 年度打赏金额已经达到了 112680 美元。

2-8.jpg

是运气,还是实力?我有点不敢相信我在开源社区里做开源软件,赚的钱比以往任何时候都多。

掐我一下,我是在做梦吗?

是因为我开发的软件太过优秀?让 535 位开发者每个月都打赏我 14 美元。不管怎么说,继续努力吧!

接下来,我想分享一些过程中的经验,希望能帮到也想从事类似开发工作的人们。

通过 GitHub 打赏赚钱的三个阶段

阶段 1:热心人士

最初,GitHub Sponsors 是一个让忠实粉丝能够资助他们所支持项目的平台。这些人的数量,和真正使用软件以及从中赚钱的人数比起来,并不算多。

基于开源的前提,人们本来就可以免费获得该软件。所有收入完全是来自那些友善热心肠的人们。
2-9.jpg
首先,非常感谢这些人。然后我们谈谈第一个高峰是怎么到来的。

阶段 2:打赏软件

这个阶段,事情开始变得奇妙。
2-10.jpg
当时,我和我的兄弟 Daniel 录制了一期《No Plans To Merge》。在思考如何将其变现时,我们想到了一个新颖的想法:「打赏软件」。

它的工作方式如下:

  1. 创建一个很棒的软件;

  2. 使其仅对打赏者开放,直到你积累了一定数量的打赏者;

  3. 然后将项目开源给全世界。


这是一种双赢。效果很好,几天之内我的收入就增加了 1.1 万美元。
2-11.jpg
我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法,同样取得了成功:
2-12.jpg
这种方法很棒,但是需要不断地提供新的想法,所有的这些都将成为我必须持续进行的项目。长远来看,我需要更合理的东西。

阶段 3:教学视频

我得到的大部分打赏金都是这个阶段来的:
2-13.jpg
这里边有什么秘诀吗?答案是:录制教学视频。

构建有用的软件是一回事,但教别人怎么用完全是另一回事。

我尽力创建高质量的文档,但总有人需要更加高级的内容。

为了满足这些需求,我录了一系列教学视频。在这之后的三个月里,我的总收入从 4 万美元涨到了 10 万美元以上。
2-14.jpg
我在文档的适当位置嵌入了这些视频的链接,以帮助大家找到它们:
2-15.jpg
几个星期之后,我又为 GitHub 打赏者专门建立了一个「私有」的视频小组:
2-16.jpg
这就是我的秘诀(为了做到以上这些,我利用 GitHub 认证构建了一个 Laravel app 来调用 GitHub API,以验证用户是否为打赏者)。

现在,那些看免费视频的人自然会遇到这些「私有」视频,如果他们喜欢前面那些免费的内容,他们就会给我打赏来获取后面的视频。

每次有新特性出现,我都会放出一批新视频。此外,我还会给每位打赏者提供访问每节课源代码的入口。

在 90 天的时间里,我的年收入增长了大约 8 万美元。

现在我有了连续的收入,不用再将所有时间都花在课程发布上了。我将用空出来的时间继续开发这个软件,同时放出新的视频。

如何通过打赏赚更多钱?

实力是第一位的

要做到靠打赏谋生,首先离不开日益月累的磨练,你做的东西要真正有用才行。我把我所有的一切都投入到工作中,这点没有捷径。

你可以发现,我在一个开源项目中全职工作了整整一年才看到收入。能得到人们赞助的工作必须是高质量的,而且始终是排在第一位的。

积极寻找用户

你可以在网上创建优秀的工具,但如果没有人关注,再出色的工具也无法为你带来收入。因此,找到用户是赚钱的关键。在这方面,你的 Twitter 粉丝和邮件订阅者都是潜在的挖掘对象。

打赏金额设置不要太保守

很多 GitHub 开发者犯的最大的一个错误就是在初级打赏设置中写的钱数太少。

如果打赏者能选 1-5 美元 / 月,谁还会选更高的打赏金额。

我很早就意识到,如果我真的想做这件事,只有 5 美元的打赏肯定是不够的,所以我后来涨到了 14 美元。

给打赏等级取一个好名字

在给打赏等级取名的时候,记得取一个能描述打赏者类型的恰当名字。

举个例子,对于一个高级打赏等级来说,它的标签应该是「The Agency(代理)」或其他能够暗示一个公司应该给予高级打赏的标签,而不是「Platinum(白金)」这种模糊的说法。

这样一来,人们看到这个标签首先想到的会是:「我的用途到底属于哪一类」,而不是:「我每个月要花多少钱」。

不要羞于谈钱

在我的成长过程中,我一直认为谈钱是不礼貌的,但其实这是一个谎言。有一次,我一股脑涨了 1 万美元,因为一个合作者告诉我他们都赚多少钱。在得知他们的收入情况后,我对自己的要价感到心安理得。但如果他们不告诉我这个情况,什么都不会发生。

透明是一个健康的现象。

我不会隐瞒自己的收入,因为别人也不对我隐瞒他们的收入,这让我从中获利。

即使他们赚的比我多得多,我也不会感到心痛或想分一杯羹。相反,我只会感到激动和鼓舞。我希望其他人也能保持这种心态。

直接告诉别人你完全依赖这笔钱生活也没什么不礼貌的,而且这笔钱帮你打造出了人们每天都在用且从中受益的软件。

不要因为赚了很多钱而感到内疚

我一直都在提醒自己,我不是一个开发者布道师。如果我的打赏收入超过了平均生活水准,那也不错。我经营的也不是非营利组织。

我的收入和我的软件所带给别人的价值成正比,这没什么问题。

我做的不是什么神圣的工作,那些软件是企业拿来赚钱的,他们从中牟利,所以我从中赚钱也是 OK 的。

网友:我也能这么做吗?

Caleb Porzio 的这份经历也引起了许多开发者的关注,讨论最热烈的问题是:在我的国家或者地区,这个方法行得通吗?
2-18.jpg
「看到这些,我为自己国家芬兰的法律而感到难过。我们有一项名为筹款法的法律,其中规定,要想收取捐款(即无任何回报的支付)必须获得许可。这个许可证是付费的,而且不发给个人,只授予非营利活动。」

这就意味着,如果你在软件项目上看到捐赠按钮,并且该笔资金流向芬兰人,这个过程是违法的。

所以这位芬兰的开发者表示,他自己托管了一个免费项目,为此不得不成立一家公司(独资经营)并出售一些其他的东西,以便从服务中获利。即便人们有捐赠的意愿,他也不能「合法地」接受这些钱。
2-19.jpg
有人表示,在大多数西方国家都有类似的规定。因此,对于这些国家的人来说,自由职业虽然「自由」,但也同样需要花费更多的精力去管理琐事。
3-17.jpg
但在美国,这种做法的门槛要低得多。「如果是在美国的话,你可以作为个人接受无偿礼品,也可以作为个体经营者接受营业收入,无需额外注册什么。与往常一样,你需要精确缴纳税费,包括预扣税。」




转自:机器之心  (张倩、蛋酱)


原文链接:https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it


10月份Github上最热门的开源项目

科技创新柠檬^ 发表了文章 • 0 个评论 • 83 次浏览 • 2020-11-04 14:47 • 来自相关话题

10月份GitHub上最热门的Java开源项目排行已经出炉啦,一起来看看上榜详情吧:1、base-adminhttps://github.com/huanzi-qch/base-admin Star 1499Base Admin一套简单通用的后台管理系统,这套... ...查看全部

10月份GitHub上最热门的Java开源项目排行已经出炉啦,一起来看看上榜详情吧:


1、base-admin

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

微信图片_20201104144432.jpg

Auto.js是一款强大的不需要root的类似与按键精灵的软件,可以让你跟电脑中按键精灵一样实现自动点击,打开应用等等功能,能够解放你的双手,以及双眼,轻松的帮助你完成各种日常工作。

4、advanced-java

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代码概念,一系列在线智能开发:在线配置表单、在线配置报表、在线设计流程等等。



8、Java

https://github.com/TheAlgorithms/Java Star 31964

微信图片_20201104144525.jpg

该项目用Java实现的所有算法。



9、toBeTopJavaer

https://github.com/hollischuang/toBeTopJavaer Star 18030


Java工程师成神之路,完整大纲如下:

微信图片_20201104144544.jpg

10、Mindustry

https://github.com/Anuken/Mindustry Star 6314


Mindustry是由AnukenDev开发和发行的一款开放式的塔防游戏。在这款游戏中,你的防御塔将不再像一般的塔防游戏一样可以无限开火,而是需要你将炮弹通过传送带运到炮塔上,因此你需要设计一系列合理的供应路线,同时生产基本的材料,保卫你的基地。游戏还支持多人跨平台游戏和PVP模式。



11、jsoncat

https://github.com/Snailclimb/jsoncat Star 289


这是一个仿仿Spring Boot但不同于Spring Boot的一个轻量级的HTTP框架。



12、EhViewer

https://github.com/seven332/EhViewer Star5788

微信图片_20201104144614.jpg

EhViewer是一款非常绅士的漫画阅读软件。ehviewer上汇集了海量漫画资源。


开源最前线(ID:OpenSourceTop) 猿妹整编

转载请注明来源作者




懂程序员的产品经理是什么样子?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 153 次浏览 • 2020-09-16 10:36 • 来自相关话题

在互联网行业,产品经理和程序员之间的关系很微妙。表面看上去水火不容,在一方的眼里看另外一方总是有这样那样的问题,相互吐槽。但现实是,大家都知道和对方在同一条船上。产品没做好的话,除了公司利益受损,产品经理和程序员也会各回各家各找各妈,重新找新工作去。产品做得好... ...查看全部

在互联网行业,产品经理和程序员之间的关系很微妙。表面看上去水火不容,在一方的眼里看另外一方总是有这样那样的问题,相互吐槽。但现实是,大家都知道和对方在同一条船上。

产品没做好的话,除了公司利益受损,产品经理和程序员也会各回各家各找各妈,重新找新工作去。

产品做得好的话,双方和睦相处、其乐融融?那是不可能的,这个辈子都不可能和睦相处。矛盾会更加严重……(都觉得自己功不可没)

所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员,都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的,而不是一个零和博弈。

这个主题会分别从不同的两个视角展开,今天我们先聊程序员视角,本来想两个视角一起聊,发现内容太多,写到一半还是拆了,先把一个视角写了。

如果你是程序员可以看看以下这些描述是你眼中的产品经理么?

如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。

程序员吐槽产品经理最多的原因主要是以下几个(以下内容可能会引起程序员们的极度舒适~):

  1. 开发过程中频繁修改需求。

  2. 验收过程中要求做比较大的修改。

  3. 说不清楚需求的价值

  4. 替程序员评估工作量

  5. 需求整理的不够细。

其中,频繁修改需求是程序员们最反感的,这是毋庸置疑的。

从产品经理的角度来说,虽然无法100%在开发过程中不修改需求,但是如果前期的工作做得足够充分,与业务方的沟通足够到位,至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理,在自己对业务都是一知半解的时候就开始整需求了,这必然会导致后续频繁的需求变更。

第二,验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的”。每当程序员听到这6个字的时候,脑子里是一万头草泥马奔过……

产生这个情况的原因有很多。可能是程序员理解偏差,也有可能是产品觉得功能效果不佳。但是大多数时候,产生这个情况的根本原因还是在需求评审阶段的沟通不够充分,双方之间并没有达成真正的共识。

但是如果要说什么时候双方的矛盾最激烈,那还不是修改需求的时候,而是需求评审的时候。

此时,很容易看到的一个景象是“讨价还价”。产品经理站在「价值」一方,程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时,如果产品经理无法阐述出该功能令人信服的价值,那么必然受到吐槽。这是原因三。

原因四,有些产品经理是从程序员转过去的,之前做过一两年的开发工作。这个时长的经验其实是很危险的,很容易陷入到「达克效应」的第一阶段:高估自己的技术能力,低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理,甚至会在需求评审的时候替程序员预估时间,如果高于自己的预估,便会认为他们偷懒。

最后一点。相信每个人程序员都提出过这样的问题“这里如果……,那么要怎么处理?”。这种就是需求考虑不够细致的体现。不过,要做好这点的确挺难的,这也是产品经理花费时间最多的地方。

聊了这么多场景,作为产品经理应该如何应对呢?

从思路上分为以下几步。

01

先明确大方向,并与程序员达成一致。

正如前面所提到的,产品经理站在「价值」方,程序员站在「成本」方,这注定了他们是对立的。最坏的结果就是双方互掐,就算相对好的结果也只是相互妥协做一个半吊子的功能(用系统的人不太舒服)。

但如果你的视野更大,格局更高,就会发现,如果以「投入产出比」角度来切入,双方不但都能理解,而且很容达成共识,毕竟花最小的成本干价值最大的活,是个正常人都能理解和认可不是么。

所以,可以在日常工作中不断的强化这个共识。一旦出现争执,就从这个角度来做最终决定,甚至基于这慢慢地还能建立起相互的信任,程序员真正拥有了产品思维,产品经理真正懂了程序员的难处。

02

将产品经理范畴内的事情做到极致。

所谓术业有专攻,与其相互吐槽,不如多花点时间把对方吐槽的地方做到极致。

03

有时候你虽然做的很好,想的也很仔细,但是还是会出现无法说服程序员认可你方案的情况。这是因为我们每个人本身都会存在「确认偏误」现象。

确认偏误是指搜寻,解释,偏爱和回想确认或支持一个人先前信念或价值观的信息的倾向。会导致对个人信念的过度自信,并且在面对相反的证据时可以保持或加强信念。

维基百科

所以,运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成,你就得考虑如何提高协作效率。而产品经理和程序员的协作中,沟通又是最重要的。

下面展开说说具体可以做的一些事。主要是思路中的2和3。

01 提高专业性

我观察过一个现象,需求变更比较多的产品经理,他们的工作习惯往往是直接抄起原型工具就画原型,或者有很多工作时间在原型工具里。

这样非常容易陷入到一个思维惯性里面去,就是过于关注交互层面的事情,而轻视了背后业务流程的设计,甚至是业务的合理性。

我认为产品经理做事的时候一定要以User Story为核心来展开,先构思好一个User Story,然后就是把它真实发生的各种细节阐述清楚。做这事的过程先后分为以下四步:

  1. 定义User Story

  2. 定义交付标准

  3. 提供低保真原型

  4. 编写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 沟通方面

与程序员的沟通方面,我总结了五动作,分别是「齐、拉、捧、说、谦」,可以根据情况组合出击。

「齐」就是视角对齐的意思。在聊需求之前,先交代需求的背景、意义。特别在中途需求变更的时候,这点非常重要。

继续搬出之前用过好几次的图。

640.jpg

如果视角不同,你说接下去还怎么聊?

「拉」是拉拢的意思。亚里士多德说过:

我们无法通过智力去影响别人,而情感却能做到这一点。

亚里士多德

所以,在沟通的时候要把程序员当作自己人看待,而不是敌对。比如,可以多用“我们”,“一起”等词语,进入一个协商的氛围。举个例子:“我们一起来看下这个问题”。少用”我觉得“、”我认为“;

「捧」是吹捧的意思,但并不是简单的拍马屁。

人都是有多面性的,针对不同的情况和场景,可能会表现出不同的特质,这会影响到双方的沟通。比如有的人在生活中很温和,但在工作时非常严苛,要求很高,这就是激发了不同的特质。

类似的,为了激活程序员的积极性,你可以在当下需要他发挥的地方吹捧一下。比如,你觉得某个程序员做的东西质量一般,小问题比较多。那么你在和他聊的时候特地捧一句,“我知道做程序员的都或多或少有完美主义倾向,对细节很关注。我这个功能设计的细节可是想了好久呢,不过对你来说应该很容易搞定吧。”

「说」是说服的意思。想要让对方从心底里的认同你,单凭打感情牌可不行。所以需要多用数据和用户反馈来提高你观点的可信度。

重视数据的产品经理有可能是优秀的产品经理,但不重视数据的产品经理一定不是优秀的产品经理。因为要看得懂数据的前提是得懂业务,并且还不能仅仅懂个皮毛。比如,

你得知道哪些环节产生的数据是关键。

多个数据之间的间接关系和影响是什么。

你设计的每一个功能会如何影响这些数据。

……

心里一直有着这些概念,程序员还会吐槽你提的需求价值低?

「让」是谦让的意思。俗话说,“三个臭皮匠顶一个诸葛亮”。可以给程序员留有表达他们观点的空间。

原因有两点。

大多数的产品设计背后有很多的知识是通用知识,每个人的生活经历都能成为经验。而每个人的生活经历又是不同的。

专业不同,哪怕站的视角相同,看到的同一个事物也会有些差别。用高端的说法叫“看到的本质不同”。基于这个本质出发,提出的观点可能会让你眼前一亮。

以上就是「齐、拉、捧、说、谦」五点。最后再送给你一句话:非必要情况,一定不要用“这是老板的要求“!,重复,重复。重要的事情说三遍。

还有一些比较成熟的方法体系也能改善产品和开发之间共识达成问题。比如,在领域驱动设计范畴中Event Storming。它就非常适合在前期的需求评审环节去使用。

感兴趣的可以自行了解。

好了,总结一下。

这篇呢,Z哥和你分享了我对产品经理如何更好地与程序员达成共识这件事的看法。

思路上分为三步:

  1. 先明确大方向,并与程序员达成一致。

  2. 将产品经理范畴内的事情做到极致

  3. 运用一些沟通技巧解决「确认偏误」现象。

关于第二点,给出的具体措施是。以User Story为核心,做好Use Case的编写工作,而不是花很多时间在原型上。

关于第三点,总结了五个动作,分别是「齐、拉、捧、说、谦」,可以根据情况组合出击。

希望对你有所帮助。

作者:Z哥,公众号“跨界架构师” 

如何做一个懂产品的程序员?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 165 次浏览 • 2020-09-16 10:32 • 来自相关话题

两个相爱相杀的岗位,想要更好的达成共识、更好的合作,自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。直接进入正题吧。从产品视角是怎么看程序员的呢?我根据我自己的经历以及与其他产品经理的交流下来看,吐槽的主要是以... ...查看全部

timg.jpg

两个相爱相杀的岗位,想要更好的达成共识、更好的合作,自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。

直接进入正题吧。

从产品视角是怎么看程序员的呢?我根据我自己的经历以及与其他产品经理的交流下来看,吐槽的主要是以下几点:

  1. 这个功能实现不了。

  2. 希望所有产品都不要改版,一次性把现在或未来要做的开发完。

  3. 只关心要写多少代码,不在乎产品体验。

  4. 写完程序从不自测,直接丢给别人测试。

  5. 过分追寻新技术潮流,完全不考虑对产品带来什么价值。

第一点,的确存在一些由于技术限制导致实现成本无限大的需求,比如手机屏幕背景色根据手机壳颜色切换……

但是,国内的技术环境不像老美那的技术味道重,大多还是商业导向的,很少企业里需要用到高精尖的技术,所以,真正实现不了的功能微乎其微。

对于大多数的功能需求来说,无非是一个成本大小、价值高低的问题。从立场上看,程序员自然是站在「成本」一方的,但对大多数人来说,决定这个成本的主要因素往往是自己工作的难度和耗时,费时费力的功能就容易得到“实现不了”的结果。

第二点对大多数产品经理来说是他们的对立面。因为大多数产品经理最喜欢“走一步算一步”地高频迭代,甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的,并且内容要非常详细的,心里的想法是,这样的话我一开始就可以设计一个完美架构来支撑它。

而且,内容越详细,产品经理就越不敢乱调整需求,毕竟“证据在手”嘛:D。

第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多,对需要有同理心、需要靠感受的事情的确弱了一些。

第四点的原因主要有两个。

一个是对自己的代码过度自信导致,我自己深有体会。我还记得有一次我交付一个功能,那个功能我单元测试都写了不少,对质量很有信心,觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug。

另一个原因是反正有测试人员在,等他们测出问题我再改不是更轻松。惰性使然,从个人角度的确如此。但是从团队角度来看,徒增了不少的沟通成本。

第五点的原因也有两个。

一个是行业里的新技术迭代的确太快,怕不学新技术被淘汰。

另一个原因是,只有用上新技术才能有谈资,显得自己与众不同、有成就感。

以上就是对这五点的简单分析,那么如何改善呢?继续往下看。

下面这些方法都是我亲测有效的,强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。

01  说实现不了之前,先三思

根据先后可以做以下3个思考:

是觉得这个功能没有价值不想做吗?

真的实现不了?我想全了吗?

这些方案里,有成本比价值低的吗?

第一个问题先确定必要性。我们不是说不能推需求,而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算,但至少这才能算是拒绝的理由。

第二个问题,努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案,那么将会永远在舒适区止步不前。

第三个问题,拒绝需求虽然不用动之以情,但一定需要晓之以理。当你能清楚的阐述利弊、收益比,拒绝需求自然不是一件需要相互扯皮的事情。

经过了这三个问题的思考,不管最终能不能实现,相信可以很好的与产品经理达成共识。

02  明白需求本身也是成本

过度地苛求需求要细、要完整、要全面,这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本,产品经理的也是。

与其等一个“XXXX最终绝对不改版”,不如从已经达成共识的部分开工,在这个过程中再与产品经理「共创」,多一起沟通打磨,此时再让产品完善PRD等文档,形成最终版。

03  刻意练习,多换位到用户视角

平时多去体验一下自家的产品以及竞品,把整个过程中的感受记录下来。比如,哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。结果不重要,重要的是这个过程,慢慢锻炼自己作为用户的感知力。

有些程序员看起来经常把用户体验挂在嘴上,其实提出来的很多反而是脱离大众习惯的“个性化”需求,就是因为平时缺少对同行、外界的关注。

04  交付的东西是自己的「招牌」

“有人的地方就有江湖,有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态,你在别人心中的称号就是负面的。

轻则影响自己的口碑,影响与他人之间的协作关系;重则失去未来的晋升机会。一个对自己的东西都不负责的人,如何负责更多的人、更大的事情呢?

在这件事上,除了多自测外,作为过来人,我建议每一个程序员认真对待单元测试。特别把核心、复杂的方法单元测试给做上,这对交付功能的质量的提升非常明显。

05  不产生价值的新技术是“垃圾”

拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它,这不但给团队在挖坑,也在给自己挖坑。

比如你花了不少的时间在项目里用了某个新技术,但是对团队没有带来什么价值,你说后续公司还会继续投入资源加大新技术的使用吗?大概率并不会。那么之前了解到的一些知识,就会随着时间的推移而淡忘,投入的时间大多数浪费掉了。

所以,对待新技术Z哥的观点是。对于无法在工作中找到价值点的新技术浅尝辄止即可。相反,遇到可以产生价值的新技术,请全身心投入进去,而不是仅仅在应用层面捣腾,不去深入细节。之前发过一篇讲解新技术选用的文章《程序员与新技术之间的「爱」与「恨」》,可以点击文末的链接阅读。

很多程序员对待新技术的习惯是,打一枪换一个地方,经过了几年,发现技术实力还在原地打转,不免有些可惜。

另外,推荐大家可以阅读一两本心理学、行为学相关的书,特别是我们做程序员的。

这不但可以提高自己对用户体验的感觉,还能提高对人性的洞察力,包括对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。

好了,总结一下。

这篇呢,Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议:

1.说实现不了之前,先三思。

2.明白需求本身也是成本。

3.刻意练习,多换位到用户视角。

4.交付的东西是自己的「招牌」

5.不产生价值的新技术是“垃圾”

希望对你有所帮助。


作者:Z哥,公众号“跨界架构师” 

英雄会被表彰,这些技术与代码也将载入史册!

科技创新柠檬^ 发表了文章 • 1 个评论 • 110 次浏览 • 2020-09-10 16:14 • 来自相关话题

昨天,我们被「人民英雄」刷屏了。上午十点,全国抗击新冠肺炎疫情表彰大会,在人民大会堂隆重举行。大会授予钟南山「共和国勋章」,授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。除了这些战疫者之外,在今年抗击疫情过程中,还有一批特殊的「功臣」,也在今年的抗疫战中立... ...查看全部

昨天,我们被「人民英雄」刷屏了。

上午十点,全国抗击新冠肺炎疫情表彰大会,在人民大会堂隆重举行。

大会授予钟南山「共和国勋章」,授予张伯礼、张定宇、陈薇「人民英雄」国家荣誉称号。

除了这些战疫者之外,在今年抗击疫情过程中,还有一批特殊的「功臣」,也在今年的抗疫战中立下汗马功劳,从而被纳入国家博物馆收藏。

历史也将铭记:代码、无人车、外卖服

近日,国家博物馆陆续上新,这批最新纳入的藏品,与以往的有所不同:这些物品都是为纪念抗疫征集而来,将成为历史文物。

2.png

国博曾在 3 月向社会公开征集

抗疫相关实物与资料

国博发出抗疫藏品征集公告之后,社会各界都纷纷响应,捐出了各种具有纪念意义的物品。

如今最新加入国博的这些成员,不仅因为见证了这场抗疫历史,而拥有了特殊的意义,也因为其自身鲜明的时代特色,而显得十分别样。

阿里:三段代码 

本次藏品征集中,阿里提交了包括 4 本新型冠状病毒肺炎临床救治手册、2 本新冠疫情爆发下的医院应对策略、六大洲捐赠的提单和报关单、等 14 种共 30 件抗疫实物。

这其中,有三件「物品」与众不同,它们分别是:

  • 支付宝团队研发的健康码系统第一行代码;
  • 阿里云研发的全国健康码引擎第一行代码;
  • 阿里巴巴达摩院研发的新冠肺炎 CT 影像 AI 辅助诊断产品第一行代码。

3.png

与代码一起纳入收藏的,还有参与该项目的程序员签名

众所周知,自 2020 年初新冠肺炎疫情爆发之后,疫情防控成为全国上下第一要务。

除了体温、核酸检测等线下手段外,健康码这个数字化防疫工具,也成为人人出行的必备凭证。

4.png

出入公共场所,健康码已必不可少
据介绍,健康码项目需要阿里旗下的支付宝、阿里云和钉钉团队三方合作完成,因此,这三方团队的工程师组成了健康码团队。
阿里云团队的核心任务是开发码引擎,支付宝和钉钉团队则提供查询获取入口、和核验等功能。
注:码引擎是健康码的后端,它会将用户的个人身份信息通过公安数据库转换化成系统中的唯一代码,指挥红黄绿三码的判断和实时发放。
在三方团队协作下,健康码的第一行代码,于 2 月初的一个凌晨提交,2 月 11 日便在杭州上线。随后,因其方便出示与使用,很快便被推广至全国各地。
如今,这行代码正式被国家博物馆收藏,不仅仅在于其技术上带来的突破,其收藏意义更在于这是中国数字化抗疫的见证、包含着全国人民一段刻骨铭心的记忆。
京东:无人配送车 
京东共有五件物品入选国博藏品,被称为「五件套」。

它们包括:JD40006 号无人配送车、湖北省新冠疫情防控指挥部的感谢信、钟南山院士的感谢信、内蒙古援鄂医疗队医护人员写给京东快递小哥的感谢信、技术抗疫纪录片。

5.png

该无人配送车由京东智能行驶部研发
这辆 JD40006 号无人配送车,是首个成为京东正式员工的机器人。在疫情初期,JD40006 成为京东智能科技应急小组的成员之一,被亲切地称为「大白」,负责疫情期间无接触配送物资。
它依托 L4 级别自动驾驶技术和北斗卫星定位系统,以及远程部署,使整个无人配送过程实现全自动化。抗疫期间,它往返行驶总里程超过 6800 公里,运送包裹约 1.3 万件。
饿了么:骑士外卖服 
外卖,已经成为这个时代不可或缺的一部分。根据易观数据,当前中国一天的外卖规模就超过 20 亿元。如今,外卖早已不限于餐饮,还延伸到生鲜、日常用品、医疗用品等的配送。
如果说,此前外卖带给我们的是便捷与时间自由,那么疫情期间,外卖还带给我们更多的安全感。

据报道,疫情期间,32 岁的退伍军人付腾虎,组建了一支特别的外卖配送队「飞虎队」,给武汉协和医护人员送餐。他们每天一趟送几十份餐,累计送了万份餐。

6.png

「飞虎队」所有骑手签名的外卖服
在这些科技抗疫的代表作中,代码作为一项最为特殊的藏品,也在网络上引起热议。

「写代码写进国博挺酷的,有点激动,是个纪念。到时候国博有展,我一定会去北京看的。」支付宝前端开发刘志飞说。

7.png

刘志飞为参与健康码项目成员之一
代码:现代科技的载体,人类的共同遗产
中国国家博物馆作为中华文物收藏量最丰富的博物馆之一,收藏着上百万件珍贵藏品,而这些藏品无一不蕴藏着厚重的历史气息。
从远古时期的人面鱼纹陶盆,到明清时期的郑和铜钟。这些藏品,都是能够摸得着的实实在在的物体。

收藏代码,是国家博物馆的第一次,却也有例可循。GitHub 在前不久将一部分开源代码,以胶片的形式储存,打包运往北极冷岸群岛。

8.png

这批代码胶片被存放在极其干燥的、-5°C 恒温的矿井中

据介绍,这些代码至多可以保存一千年。GitHub 官方启动这个计划的原因,便是:世界由开源软件提供动力。这些代码是现代文明的隐藏基石,也是全人类的共同遗产。

健康码也是一样,这些「摸不着」的代码,是这段重要、特殊的 2020 年里,重要的组成部分。

9.png

来自知乎用户@克里姆林之主的观点
将这段代码纳入国博藏品,不仅理所应当,也更兼具时代意义。

我们将铭记这段不同寻常的时期,后人也会了解到这段用科技、医疗、人文关怀一起驱动着全体国民,共同抗击疫情的历史时刻。


来源公众号:HyperAI超神经

曲线救国:提高github下载速度到2MB/s

IM即时通讯梅川酷子 发表了文章 • 0 个评论 • 162 次浏览 • 2020-07-29 09:15 • 来自相关话题

因为网络连接的原因,在国内从github上面下载代码的速度峰值通常都是20kB/s。这种速度对于那些小项目还好,而对于大一些的并且带有很多子模块的项目来讲就很耽误时间。常见的方法是通过代理连接,但实际用起来并不稳定。这里提供一种新的思路,下载速度可以达到1~2... ...查看全部

因为网络连接的原因,在国内从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举例

第三步:

3.png

第四步

4.png

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 个评论 • 126 次浏览 • 2020-07-22 15:02 • 来自相关话题

近期,GitHub 发布了一条新功能——GitHub Sponsors,也就是我们熟悉的「打赏」。GitHub 官方表示,打赏的每一分钱都会进开发者的口袋,他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub&nbs... ...查看全部
近期,GitHub 发布了一条新功能——GitHub Sponsors,也就是我们熟悉的「打赏」。GitHub 官方表示,打赏的每一分钱都会进开发者的口袋,他们不会作为中间商赚取差价。神圣不可侵犯的 GitHub 都有打赏了,到底是好还是坏?


GitHub 官方表示,「开发者们为我们大家贡献了开源工具,这是对他们的经济支持,新的打赏功能将帮助他们构建更优秀的开源工作。」然而,这不得不让人感叹,作为全宇宙最自由、最神圣的交友社区,GitHub 也开始增加打赏属性。所以为了顺应大流欢迎 Star 和 Fork 融云GitHub 项目~

项目地址https://github.com/rongcloud-archive

为了启动这一新项目并激发社区打赏积极性,GitHub 还推出了 GitHub Sponsors Matching Fund,每个开发者第一年最多可匹配到 5000 美元的赞助基金。

这是一个开源的世界。如果没有维护者、设计者、编程者、研究者等组成的全球团队促进科技发展,世界就难以运行。这些卓越的开发者现在可以从社区中按劳取酬,通过自己的 GitHub 文件获取经济支持。

微信图片_20200722150039.jpg

中间商不赚差价,打赏功能全球通用


开源是 GitHub 的核心。构建共享数字基础设施的开发者使得这个社区更加强大。GitHub 表示,为了表示对贡献者的感谢,GitHub Sponsors 在用户打赏其他开发者时不会收取平台费用。此外,为了庆祝这一功能的推出,GitHub 还将为前 12 个月的支付处理开销买单。简而言之,你打赏的每一分钱都会进开发者的口袋。


此外,打赏功能没有地域限制,只要在 GitHub 开展业务的国家,这一功能都能使用。


所有贡献者都能赏


在优秀的项目中,很多贡献者(contributor)都会做出至关重要的贡献,但他们的贡献在代码评审中并不可见。GitHub Sponsors 的推出是为了帮助所有类型的贡献和工作,从而进一步帮助开发者构建开源系统。任何对开源项目做出了贡献的人,不论是代码修改、文档编写,还是项目领导、项目设计等,都有可能得到打赏。


目前有一小部分开发者参与了 Sponsors 的测试版,任何开源项目贡献者在未来都有机会受到打赏。当然读者们也能申请下阶段测试的开发者,即填表加入 GitHub Sponsors 的候选者列表:

微信图片_20200722150055.jpg例如 Go 语言的贡献者,申请成为测试开发者后的赞赏页面大概是这样的:微信图片_20200722150106.jpg

因此,GitHub Sponsors 是另一种对开源项目做出贡献的方法:为构建和维护项目的开发者提供资金支持。为开发者资金帮助能帮助他们构建更好的开源项目,扩展参与开发的机会,并给予开发者应有的认可。从今天起,任何 GitHub 用户都能资助开源项目的开发者,这也是对项目最好的认可方式。


嵌入 GitHub 工作流


对于我们熟悉的工作流,GitHub Sponsors 现在可以无缝嵌入到里面。当贡献者回答我们的问题、指出我们的错误、或合并我们提交的代码时,我们可以访问他们的资料,或者直接将鼠标放在用户名上来打赏他们的开源工作。

微信图片_20200722150117.jpg对于新的社区贡献者悬停卡,除了该项目的直接贡献者,我们还能看到该项目传递的依赖性关系。他们虽然没有直接对该开源项目做出贡献,但他们以前的工作或贡献可能为当前项目提供帮助,因此也是我们该赞赏的人。微信图片_20200722150127.jpg

开源项目还可以直接在 repo 中显示自己的打赏模型。.github/FUNDING.yml 被加到一个项目的主分支上之后,一个新的「Sponsor」按钮就会出现在 repo 的顶端。单击该按钮将打开该文件中列出的打赏模型的本地渲染视图。


YAML 板式非常灵活,因此项目的维护者和贡献者可以根据自己的条件决定如何打赏项目。他们可以展示以下任何(或全部)内容:为该项目做出贡献的开发者的 GitHub Sponsors 文件;包含 Open Collective、Community Bridge、Tidelift、Ko-fi  和 Patreon 在内的流行打赏模型以及其他打赏模型的自定义链接。

微信图片_20200722150158.jpg

影响


GitHub 的这一做法可能会引起一些争议,部分开发者认为打赏可能会影响到开发者的工作方向。经济利益可能驱使开发者更加关注可能获取经济效益的项目,而不是那些有趣、有挑战性但不太会有人打赏的项目。那么读者们怎么认为?快留言写下你的观点吧。


一个靠 GitHub 打赏的码农,年入十万美元!

技术活动大兴 发表了文章 • 0 个评论 • 139 次浏览 • 2020-07-22 14:48 • 来自相关话题

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,码农也可以。这位活成主播的码农名叫 Caleb Porzio。在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在这篇自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧... ...查看全部
如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,码农也可以。这位活成主播的码农名叫 Caleb Porzio。

在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在这篇自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧。

微信图片_20200722144328.jpg

Caleb Porzio 发推庆祝自己靠 GitHub 打赏(GitHub Sponsors)赚到了 10 万美元。

GitHub Sponsors是 GitHub 2019 年 5 月份推出的一个功能,允许开发者通过自己的项目获取报酬。

全职开发转自由职业,是怎样一种体验?以下是Caleb的故事。

我要分享一下自己走上自由职业的经历。

2018 年是我做全职开发的最后一年,当时我的年收入大概是 9 万美元。

微信图片_20200722144351.jpg

嗯,虽然说现在开发人员的薪资水平比较疯狂,但 9 万美元对我来说也是一笔可观的收入了。再加上我妻子的收入,以及「胡子主义」生活哲学的指导,我们可以省下很多的钱。

2019 年 1 月 11 日,我离开原来的公司开始「休假」,想要换种心情,做自己想做的一切。几个月后,我正式开始了自由职业者的生活。

「休假」期间,我读到了这篇文章:《Phoenix LiveView: Interactive, Real-Time Apps. No Need to Write JavaScript》,并从中受到启发。我发现自己也可以做出类似的成果。

当时我还发了一条推特:

微信图片_20200722144406.jpg

「决定开发一个类似 Laravel 的东西。我感觉这可能是个重大改变。」

现在看来,这确实改变了我的生活。

也是在这一天,我的「休假期」结束了。我完全被这个后来叫做 Livewire 的项目迷住了,并开始全身心地投入于此,这种沉迷一直持续到现在。

我也创建了一个非常流行的 JS 框架,叫做 AlpineJS,目前也是由我在管理和维护。但那是另外一个故事了……

做开源软件不能完全养活自己,所以我也接过一些小型的代码指导方面的需求,让 2019 全年的收入维持在一个稳定的状态。

这张图是我 2019 年通过自由职业方式获得的收入:

微信图片_20200722144423.jpg

我的收入减少了 7 万美元,看起来是比较冒险的举动。但我知道,如果此刻不开始做这件事,以后可能就更没有机会了。

一路走来,有很多好心人联系我,询问他们是否能够提供项目上的帮助。比如这种:

微信图片_20200722144437.jpg

很长一段时间我没有更新 Patreon(一个众筹创作网站),那里会有一些人每个月给我五美元。如此也很好,但对我来说没有意义。

然后,我发现了 GitHub 的打赏功能,把项目直接托管在 GitHub 上即可。2019 年 12 月 12 日,我成为了 GitHub Sponsors 的一员。

微信图片_20200722144451.jpg

这是我的第一个打赏者,Brian,谢谢你!

迄今为止,我已经从 GitHub sponsors 那里收到了 2.5 万美元打赏金。

微信图片_20200722144504.jpg直到撰写本文时,我的 GitHub 年度打赏金额已经达到了 112680 美元。微信图片_20200722144519.jpg

是运气,还是实力?我有点不敢相信我在开源社区里做开源软件,赚的钱比以往任何时候都多。

掐我一下,我是在做梦吗?

是因为我开发的软件太过优秀?让 535 位开发者每个月都打赏我 14 美元。不管怎么说,继续努力吧!

接下来,我想分享一些过程中的经验,希望能帮到也想从事类似开发工作的人们。

通过 GitHub 打赏赚钱的三个阶段

阶段 1:热心人士

最初,GitHub Sponsors 是一个让忠实粉丝能够资助他们所支持项目的平台。这些人的数量,和真正使用软件以及从中赚钱的人数比起来,并不算多。

基于开源的前提,人们本来就可以免费获得该软件。所有收入完全是来自那些友善热心肠的人们。

微信图片_20200722144536.jpg

首先,非常感谢这些人。然后我们谈谈第一个高峰是怎么到来的。

阶段 2:打赏软件

这个阶段,事情开始变得奇妙。

微信图片_20200722144549.jpg

当时,我和我的兄弟 Daniel 录制了一期《No Plans To Merge》。在思考如何将其变现时,我们想到了一个新颖的想法:「打赏软件」。

它的工作方式如下:

  1. 创建一个很棒的软件;

  2. 使其仅对打赏者开放,直到你积累了一定数量的打赏者;

  3. 然后将项目开源给全世界。



这是一种双赢。效果很好,几天之内我的收入就增加了 1.1 万美元。

微信图片_20200722144602.jpg我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法,同样取得了成功:微信图片_20200722144614.jpg

这种方法很棒,但是需要不断地提供新的想法,所有的这些都将成为我必须持续进行的项目。长远来看,我需要更合理的东西。

阶段 3:教学视频

我得到的大部分打赏金都是这个阶段来的:

微信图片_20200722144625.jpg

这里边有什么秘诀吗?答案是:录制教学视频。

构建有用的软件是一回事,但教别人怎么用完全是另一回事。

我尽力创建高质量的文档,但总有人需要更加高级的内容。

为了满足这些需求,我录了一系列教学视频。在这之后的三个月里,我的总收入从 4 万美元涨到了 10 万美元以上。

微信图片_20200722144638.jpg我在文档的适当位置嵌入了这些视频的链接,以帮助大家找到它们微信图片_20200722144653.jpg几个星期之后,我又为 GitHub 打赏者专门建立了一个「私有」的视频小组:微信图片_20200722144703.jpg

这就是我的秘诀(为了做到以上这些,我利用 GitHub 认证构建了一个 Laravel app 来调用 GitHub API,以验证用户是否为打赏者)。

现在,那些看免费视频的人自然会遇到这些「私有」视频,如果他们喜欢前面那些免费的内容,他们就会给我打赏来获取后面的视频。

每次有新特性出现,我都会放出一批新视频。此外,我还会给每位打赏者提供访问每节课源代码的入口。

在 90 天的时间里,我的年收入增长了大约 8 万美元。

现在我有了连续的收入,不用再将所有时间都花在课程发布上了。我将用空出来的时间继续开发这个软件,同时放出新的视频。

如何通过打赏赚更多钱?

实力是第一位的

要做到靠打赏谋生,首先离不开日益月累的磨练,你做的东西要真正有用才行。我把我所有的一切都投入到工作中,这点没有捷径。

你可以发现,我在一个开源项目中全职工作了整整一年才看到收入。能得到人们赞助的工作必须是高质量的,而且始终是排在第一位的。

积极寻找用户

你可以在网上创建最伟大的工具,但如果没有人关注,再伟大的工具也无法为你带来收入。因此,找到用户是赚钱的关键。在这方面,你的 Twitter 粉丝和邮件订阅者都是潜在的挖掘对象。

打赏金额设置不要太保守

很多 GitHub 开发者犯的最大的一个错误就是在初级打赏设置中写的钱数太少。

如果打赏者能选 1-5 美元 / 月,谁还会选更高的打赏金额。

我很早就意识到,如果我真的想做这件事,只有 5 美元的打赏肯定是不够的,所以我后来涨到了 14 美元。

给打赏等级取一个好名字

在给打赏等级取名的时候,记得取一个能描述打赏者类型的恰当名字。

举个例子,对于一个高级打赏等级来说,它的标签应该是「The Agency(代理)」或其他能够暗示一个公司应该给予高级打赏的标签,而不是「Platinum(白金)」这种模糊的说法。

这样一来,人们看到这个标签首先想到的会是:「我的用途到底属于哪一类」,而不是:「我每个月要花多少钱」。

不要羞于谈钱

在我的成长过程中,我一直认为谈钱是不礼貌的,但其实这是一个谎言。有一次,我一股脑涨了 1 万美元,因为一个合作者告诉我他们都赚多少钱。在得知他们的收入情况后,我对自己的要价感到心安理得。但如果他们不告诉我这个情况,什么都不会发生。

透明是一个健康的现象。

我不会隐瞒自己的收入,因为别人也不对我隐瞒他们的收入,这让我从中获利。

即使他们赚的比我多得多,我也不会感到心痛或想分一杯羹。相反,我只会感到激动和鼓舞。我希望其他人也能保持这种心态。

直接告诉别人你完全依赖这笔钱生活也没什么不礼貌的,而且这笔钱帮你打造出了人们每天都在用且从中受益的软件。

不要因为赚了很多钱而感到内疚

我一直都在提醒自己,我不是一个码农传教士。如果我的打赏收入超过了平均生活水准,那也不错。我经营的也不是非营利组织。

我的收入和我的软件所带给别人的价值成正比,这没什么问题。

我做的不是什么神圣的工作,那些软件是企业拿来赚钱的,他们从中牟利,所以我从中赚钱也是 OK 的。

网友:我也能这么做吗?

Caleb Porzio 的这份经历也引起了许多开发者的关注,讨论最热烈的问题是:在我的国家或者地区,这个方法行得通吗?

微信图片_20200722144720.jpg

「看到这些,我为自己国家芬兰的法律而感到难过。我们有一项名为筹款法的法律,其中规定,要想收取捐款(即无任何回报的支付)必须获得许可。这个许可证是付费的,而且不发给个人,只授予非营利活动。」

这就意味着,如果你在软件项目上看到捐赠按钮,并且该笔资金流向芬兰人,这个过程是违法的。

所以这位芬兰的开发者表示,他自己托管了一个免费项目,为此不得不成立一家公司(独资经营)并出售一些其他的东西,以便从服务中获利。即便人们有捐赠的意愿,他也不能「合法地」接受这些钱。

    微信图片_20200722144739.jpg

有人表示,在大多数西方国家都有类似的规定。因此,对于这些国家的人来说,自由职业虽然「自由」,但也同样需要花费更多的精力去管理琐事。

微信图片_20200722144750.jpg

但在美国,这种做法的门槛要低得多。「如果是在美国的话,你可以作为个人接受无偿礼品,也可以作为个体经营者接受营业收入,无需额外注册什么。与往常一样,你需要精确缴纳税费,包括预扣税。」

原文链接:https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it


B站UP主自制的开源OCR翻译器走红Github,用一次就粉了

技术活动梅川酷子 发表了文章 • 0 个评论 • 205 次浏览 • 2020-07-22 09:50 • 来自相关话题

最近一个B站UP主自己撸了一个翻译神器,只要出现在屏幕的东西都可以翻译,关键是操作十分简单,就像下面这样:和其他翻译软件相比,Dango-Translator有以下优点:适用范围全面,几乎所有出现在屏幕的东西都可以翻译;翻译接口多,目前有12个翻译接口;简洁美... ...查看全部

最近一个B站UP主自己撸了一个翻译神器,只要出现在屏幕的东西都可以翻译,关键是操作十分简单,就像下面这样:

1.jpg

和其他翻译软件相比,Dango-Translator有以下优点:
  1. 适用范围全面,几乎所有出现在屏幕的东西都可以翻译;

  2. 翻译接口多,目前有12个翻译接口;

  3. 简洁美观的界面;

  4. 及其简单傻瓜的操作方式;

  5. 相比较其他OCR翻译器配置有自动翻译模式;

  6. 需要联网,可能视网速不同翻译速度有差;


这个OCR翻译利用了百度AI的文字识别,通过识别图片上的外文文字进翻译,使用方法十分简单:

2.jpg

第一页是API设定界面,需要注册自己的API码才可以使用翻译器:

3.png

接着,你还可以设置翻译源,这里面有12个翻译接口,你可以根据自己需要选择:

4.jpg

就连翻译样式也可以自定义设置,设定不同翻译源翻译时的文字颜色,字体样式,以及翻译时是否显示原文,是否将原文自动复制到剪贴板。

当然,还有其他的一些设置,比如你还可以启用竖排文字翻译模式。

5.jpg

简单来说,该软件为OCR翻译器,OCR利用了百度AI的文字识别,原理为通过识别图片上的外文文字并进行翻译。

它不仅适用于galgame、rpg游戏、模拟器游戏、外文视频、网页游戏、pdf图片版文献等等,还适用于一切能显示在电脑屏幕上的文字。支持的语种,目前仅支持日语、英语、中文,相信后期创建者会持续完善,加入更多语言支持。

PantsuDango为什么要创建这个项目?


PantsuDango本身是个vnr翻译软件的忠实用户,但是遇到某些游戏无法提取文本,然后偶然发现有OCR(文字识别)技术的存在,下载了很多已经有的OCR翻译器还是不满意,于是,索性自己撸了一个。

6.jpg


PantsuDango目前在Github标星 816,累计分支 88 个(Github地址:https://github.com/PantsuDango/Dango-Translator)


来自:开源最前线(ID:OpenSourceTop) 

项目地址:https://github.com/PantsuDango/Dango-Translator


我,一个靠 GitHub 打赏谋生的程序员,如何做到年入 10 万美元?

技术活动王叫兽 发表了文章 • 0 个评论 • 169 次浏览 • 2020-07-06 11:51 • 来自相关话题

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和... ...查看全部

如果提到靠打赏生活的人,我们首先想到的会是主播。但现实情况是,程序员也可以。这位活成主播的程序员名叫 Caleb Porzio。


在过去的一年里,他靠 GitHub 项目的打赏赚到了 10 万美元。在他的自述文章中,他分享了自己靠 GitHub 项目赚钱的经历和技巧。

2-1.jpg

Caleb Porzio 发推庆祝自己靠 GitHub 打赏(GitHub Sponsors)赚到了 10 万美元。


GitHub Sponsors 是 GitHub 2019 年 5 月份推出的一个功能,允许开发者通过自己的项目获取报酬/赞赏。


全职开发转自由职业,是怎样一种体验?以下是 Caleb 的故事。

我要分享一下自己走上自由职业的经历。

2018 年是我做全职开发的最后一年,当时我的年收入大概是 9 万美元。
2-2.jpg
嗯,虽然说现在开发人员的薪资水平比较疯狂,但 9 万美元对我来说也是一笔可观的收入了。再加上我妻子的收入,以及「胡子主义」生活哲学的指导,我们可以省下很多的钱。

2019 年 1 月 11 日,我离开原来的公司开始「休假」,想要换种心情,做自己想做的一切。几个月后,我正式开始了自由职业者的生活。

「休假」期间,我读到了这篇文章:《Phoenix LiveView: Interactive, Real-Time Apps. No Need to Write JavaScript》,并从中受到启发。我发现自己也可以做出类似的成果。

当时我还发了一条推特:
2-3.jpg
「决定开发一个类似 Laravel 的东西。我感觉这可能是个重大改变。」

现在看来,这确实改变了我的生活。

也是在这一天,我的「休假期」结束了。我完全被这个后来叫做 Livewire 的项目迷住了,并开始全身心地投入于此,这种沉迷一直持续到现在。

我也创建了一个非常流行的 JS 框架,叫做 AlpineJS,目前也是由我在管理和维护。但那是另外一个故事了……

做开源软件不能完全养活自己,所以我也接过一些小型的代码指导方面的需求,让 2019 全年的收入维持在一个稳定的状态。

这张图是我 2019 年通过自由职业方式获得的收入:
2-4.jpg
我的收入减少了 7 万美元,看起来是比较冒险的举动。但我知道,如果此刻不开始做这件事,以后可能就更没有机会了。

一路走来,有很多好心人联系我,询问他们是否能够提供项目上的帮助。比如这种:
2-5.jpg
很长一段时间我没有更新 Patreon(一个众筹创作网站),那里会有一些人每个月给我五美元。如此也很好,但对我来说没有意义。

然后,我发现了 GitHub 的打赏功能,把项目直接托管在 GitHub 上即可。2019 年 12 月 12 日,我成为了 GitHub Sponsors 的一员。
2-6.jpg
这是我的第一个打赏者,Brian,谢谢你!

迄今为止,我已经从 GitHub sponsors 那里收到了 2.5 万美元打赏金。
27.jpg
直到撰写本文时,我的 GitHub 年度打赏金额已经达到了 112680 美元。

2-8.jpg

是运气,还是实力?我有点不敢相信我在开源社区里做开源软件,赚的钱比以往任何时候都多。

掐我一下,我是在做梦吗?

是因为我开发的软件太过优秀?让 535 位开发者每个月都打赏我 14 美元。不管怎么说,继续努力吧!

接下来,我想分享一些过程中的经验,希望能帮到也想从事类似开发工作的人们。

通过 GitHub 打赏赚钱的三个阶段

阶段 1:热心人士

最初,GitHub Sponsors 是一个让忠实粉丝能够资助他们所支持项目的平台。这些人的数量,和真正使用软件以及从中赚钱的人数比起来,并不算多。

基于开源的前提,人们本来就可以免费获得该软件。所有收入完全是来自那些友善热心肠的人们。
2-9.jpg
首先,非常感谢这些人。然后我们谈谈第一个高峰是怎么到来的。

阶段 2:打赏软件

这个阶段,事情开始变得奇妙。
2-10.jpg
当时,我和我的兄弟 Daniel 录制了一期《No Plans To Merge》。在思考如何将其变现时,我们想到了一个新颖的想法:「打赏软件」。

它的工作方式如下:

  1. 创建一个很棒的软件;

  2. 使其仅对打赏者开放,直到你积累了一定数量的打赏者;

  3. 然后将项目开源给全世界。


这是一种双赢。效果很好,几天之内我的收入就增加了 1.1 万美元。
2-11.jpg
我另外一位朋友 Nuno Maduro 最近在他的 Pest 项目中复制了这一方法,同样取得了成功:
2-12.jpg
这种方法很棒,但是需要不断地提供新的想法,所有的这些都将成为我必须持续进行的项目。长远来看,我需要更合理的东西。

阶段 3:教学视频

我得到的大部分打赏金都是这个阶段来的:
2-13.jpg
这里边有什么秘诀吗?答案是:录制教学视频。

构建有用的软件是一回事,但教别人怎么用完全是另一回事。

我尽力创建高质量的文档,但总有人需要更加高级的内容。

为了满足这些需求,我录了一系列教学视频。在这之后的三个月里,我的总收入从 4 万美元涨到了 10 万美元以上。
2-14.jpg
我在文档的适当位置嵌入了这些视频的链接,以帮助大家找到它们:
2-15.jpg
几个星期之后,我又为 GitHub 打赏者专门建立了一个「私有」的视频小组:
2-16.jpg
这就是我的秘诀(为了做到以上这些,我利用 GitHub 认证构建了一个 Laravel app 来调用 GitHub API,以验证用户是否为打赏者)。

现在,那些看免费视频的人自然会遇到这些「私有」视频,如果他们喜欢前面那些免费的内容,他们就会给我打赏来获取后面的视频。

每次有新特性出现,我都会放出一批新视频。此外,我还会给每位打赏者提供访问每节课源代码的入口。

在 90 天的时间里,我的年收入增长了大约 8 万美元。

现在我有了连续的收入,不用再将所有时间都花在课程发布上了。我将用空出来的时间继续开发这个软件,同时放出新的视频。

如何通过打赏赚更多钱?

实力是第一位的

要做到靠打赏谋生,首先离不开日益月累的磨练,你做的东西要真正有用才行。我把我所有的一切都投入到工作中,这点没有捷径。

你可以发现,我在一个开源项目中全职工作了整整一年才看到收入。能得到人们赞助的工作必须是高质量的,而且始终是排在第一位的。

积极寻找用户

你可以在网上创建优秀的工具,但如果没有人关注,再出色的工具也无法为你带来收入。因此,找到用户是赚钱的关键。在这方面,你的 Twitter 粉丝和邮件订阅者都是潜在的挖掘对象。

打赏金额设置不要太保守

很多 GitHub 开发者犯的最大的一个错误就是在初级打赏设置中写的钱数太少。

如果打赏者能选 1-5 美元 / 月,谁还会选更高的打赏金额。

我很早就意识到,如果我真的想做这件事,只有 5 美元的打赏肯定是不够的,所以我后来涨到了 14 美元。

给打赏等级取一个好名字

在给打赏等级取名的时候,记得取一个能描述打赏者类型的恰当名字。

举个例子,对于一个高级打赏等级来说,它的标签应该是「The Agency(代理)」或其他能够暗示一个公司应该给予高级打赏的标签,而不是「Platinum(白金)」这种模糊的说法。

这样一来,人们看到这个标签首先想到的会是:「我的用途到底属于哪一类」,而不是:「我每个月要花多少钱」。

不要羞于谈钱

在我的成长过程中,我一直认为谈钱是不礼貌的,但其实这是一个谎言。有一次,我一股脑涨了 1 万美元,因为一个合作者告诉我他们都赚多少钱。在得知他们的收入情况后,我对自己的要价感到心安理得。但如果他们不告诉我这个情况,什么都不会发生。

透明是一个健康的现象。

我不会隐瞒自己的收入,因为别人也不对我隐瞒他们的收入,这让我从中获利。

即使他们赚的比我多得多,我也不会感到心痛或想分一杯羹。相反,我只会感到激动和鼓舞。我希望其他人也能保持这种心态。

直接告诉别人你完全依赖这笔钱生活也没什么不礼貌的,而且这笔钱帮你打造出了人们每天都在用且从中受益的软件。

不要因为赚了很多钱而感到内疚

我一直都在提醒自己,我不是一个开发者布道师。如果我的打赏收入超过了平均生活水准,那也不错。我经营的也不是非营利组织。

我的收入和我的软件所带给别人的价值成正比,这没什么问题。

我做的不是什么神圣的工作,那些软件是企业拿来赚钱的,他们从中牟利,所以我从中赚钱也是 OK 的。

网友:我也能这么做吗?

Caleb Porzio 的这份经历也引起了许多开发者的关注,讨论最热烈的问题是:在我的国家或者地区,这个方法行得通吗?
2-18.jpg
「看到这些,我为自己国家芬兰的法律而感到难过。我们有一项名为筹款法的法律,其中规定,要想收取捐款(即无任何回报的支付)必须获得许可。这个许可证是付费的,而且不发给个人,只授予非营利活动。」

这就意味着,如果你在软件项目上看到捐赠按钮,并且该笔资金流向芬兰人,这个过程是违法的。

所以这位芬兰的开发者表示,他自己托管了一个免费项目,为此不得不成立一家公司(独资经营)并出售一些其他的东西,以便从服务中获利。即便人们有捐赠的意愿,他也不能「合法地」接受这些钱。
2-19.jpg
有人表示,在大多数西方国家都有类似的规定。因此,对于这些国家的人来说,自由职业虽然「自由」,但也同样需要花费更多的精力去管理琐事。
3-17.jpg
但在美国,这种做法的门槛要低得多。「如果是在美国的话,你可以作为个人接受无偿礼品,也可以作为个体经营者接受营业收入,无需额外注册什么。与往常一样,你需要精确缴纳税费,包括预扣税。」




转自:机器之心  (张倩、蛋酱)


原文链接:https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it