获得徽章 0
赞了这篇文章
赞了这篇沸点
赞了这篇沸点
✍️Gridea v0.8.3 发布!「全新体验,助你妙笔生花」
· 全新的内置编辑器,全新的编辑体验与快捷键
· 增加 Emoji 输入面板与文章信息统计
· 增加未保存提示,内容不丢失
· 修复操作 BUG,更改预览模式
· 升级 Electron 版本到 6.0+
· Markdown 渲染支持 Emoji 与 implict-figures
· 更多细节优化,等你发现
· 增加 GA 统计,为了更好的优化产品
· 新上架一款精致的付费主题「Tech」
官网:
gridea.dev
项目:
github.com
· 全新的内置编辑器,全新的编辑体验与快捷键
· 增加 Emoji 输入面板与文章信息统计
· 增加未保存提示,内容不丢失
· 修复操作 BUG,更改预览模式
· 升级 Electron 版本到 6.0+
· Markdown 渲染支持 Emoji 与 implict-figures
· 更多细节优化,等你发现
· 增加 GA 统计,为了更好的优化产品
· 新上架一款精致的付费主题「Tech」
官网:
项目:
展开
6
33
赞了这篇沸点
Morning! 这里是「怎么又是你」的 HG 每日推荐,今天推荐给大家一款用 JS 写的桌面全能下载工具:Motrix。它是由 Electron、Vue + VueX + Element 和 Aria2 组成的技术栈,用于支持下载 HTTP、FTP、BT、磁力链、百度网盘等资源,那最主要的肯定还是开源精神啦,如果你是一个爱学习的人,不妨 fork 一下源码深入学习一下里面的逻辑,肯定会对你大有帮助的!【今日不知道怎么互动的互动:听说妹子产品经理比汉子产品经理提的需求更能让大部分程序员接受,但是如果遇到扯淡的需求,哪怕产品经理长得再好看,请再多客,也会被喷一脸,那么请问~你中了嘛?】
hellogithub.com
展开
7
45
赞了这篇沸点
关于开发者运营
其实我作为开源社区的活跃分子,会有人问我,作为企业,我如何才能做好开发者运营呢?
首先你要明白,开发者为什么要用你的产品,或者说,开发者用你的产品,图啥?首先,最核心的是,图完成我自己的业务。基于这样的一个看法,我们再看我们的开发者运营,做的事情是什么?是送礼、是给奖品,这些很好、但是没有解决开发者的核心问题,对于开发者来说,有这些很好,但没有也无所谓。可如果你的产品不符合我的需求,那就拜拜了您内。
其次,目前国内的开发者运营都还是运营在做,并不是开发者在做,这就有一个问题、运营其实不懂开发,很多时候沟通起来会有 Context 不同的问题,造成极高的沟通成本,绝大多数优秀的开发者都是很在意效率的,如果你和他的沟通不畅通,会让他十分崩溃,拒绝沟通。这也是为什么我们看到越来越多的开发、运营双栖人才进入运营岗位,做开发者运营。
这会有一个问题,开发者来做运营,那之前的这些运营怎么办?失业了么?并不会,因为我自己在做相关的工作,在工作中我会发现,即使我尝试将自己的心态向运营靠拢,但长期的开发依然将我的心态向开发者靠拢,我无法做到完全切换到运营的 sense,一些活动、一些运营在意的 Point、我需要一些时间学习和适应。
此外,我们可以对比 DevOps,开发者运营本质上是开发者借助自己的开发者经验,做运营的工作。而 DevOps 则是开发做运维的工作,或运维做开发的工作,那我们看一看,DevOps下,我们是如何做工作的切分的:
1. DevOps:我们常规意义上的 Dev + Ops ,双面娇娃。
2. SRE :在运维层面上做细化,深化,探索更多的可能。
3. ...
其实运维的岗位依然还在,只是换了个角度、换了个方向存在,同时,因为领域的细化,运维能够在某个单点上做的更加出色。
对于运营来说,以后可能是这样的配比,一个团队中有一个开发者运营主导,其本身其实是开发,随后,团队内存在各种强力的单项运营,比如内容运营、活动运营。对于更大的企业、可能进一步抽象,有专门的活动运营团队、内容运营团队,来完成相应的通用化需求。将像如今的 SRE 团队不再归属于业务部门,大多是集团内统一联系 SRE 部门进行协作。就开发者运营这条路来看,未来的形态可能就按照 DevOps 的方式进行。
其实我作为开源社区的活跃分子,会有人问我,作为企业,我如何才能做好开发者运营呢?
首先你要明白,开发者为什么要用你的产品,或者说,开发者用你的产品,图啥?首先,最核心的是,图完成我自己的业务。基于这样的一个看法,我们再看我们的开发者运营,做的事情是什么?是送礼、是给奖品,这些很好、但是没有解决开发者的核心问题,对于开发者来说,有这些很好,但没有也无所谓。可如果你的产品不符合我的需求,那就拜拜了您内。
其次,目前国内的开发者运营都还是运营在做,并不是开发者在做,这就有一个问题、运营其实不懂开发,很多时候沟通起来会有 Context 不同的问题,造成极高的沟通成本,绝大多数优秀的开发者都是很在意效率的,如果你和他的沟通不畅通,会让他十分崩溃,拒绝沟通。这也是为什么我们看到越来越多的开发、运营双栖人才进入运营岗位,做开发者运营。
这会有一个问题,开发者来做运营,那之前的这些运营怎么办?失业了么?并不会,因为我自己在做相关的工作,在工作中我会发现,即使我尝试将自己的心态向运营靠拢,但长期的开发依然将我的心态向开发者靠拢,我无法做到完全切换到运营的 sense,一些活动、一些运营在意的 Point、我需要一些时间学习和适应。
此外,我们可以对比 DevOps,开发者运营本质上是开发者借助自己的开发者经验,做运营的工作。而 DevOps 则是开发做运维的工作,或运维做开发的工作,那我们看一看,DevOps下,我们是如何做工作的切分的:
1. DevOps:我们常规意义上的 Dev + Ops ,双面娇娃。
2. SRE :在运维层面上做细化,深化,探索更多的可能。
3. ...
其实运维的岗位依然还在,只是换了个角度、换了个方向存在,同时,因为领域的细化,运维能够在某个单点上做的更加出色。
对于运营来说,以后可能是这样的配比,一个团队中有一个开发者运营主导,其本身其实是开发,随后,团队内存在各种强力的单项运营,比如内容运营、活动运营。对于更大的企业、可能进一步抽象,有专门的活动运营团队、内容运营团队,来完成相应的通用化需求。将像如今的 SRE 团队不再归属于业务部门,大多是集团内统一联系 SRE 部门进行协作。就开发者运营这条路来看,未来的形态可能就按照 DevOps 的方式进行。
展开
评论
6
赞了这篇沸点
赞了这篇沸点
赞了这篇沸点
赞了这篇沸点
主要更新:
- 文章编辑增加快捷键保存
- 繁体中文
- 增强 Markdown(mark、sup、abbr、footnote、image size...)
- Notes 显示优化,增加目录显示
- Reading time
- more...
主页:
项目地址:
展开
23
92
赞了这篇沸点
赞了这篇文章
赞了这篇文章