• Home
  • Categories
  • WIKI
  • LANGUAGE: en
    • 活跃社区的新想法 - ld的代码贴吧
    Experiences and Insight 2232 views · 12 replies ·
    Tofloor
    poster avatar
    electricface
    deepin
    2013-01-10 06:05
    Author
    LD的社区功能太弱了,没办法团结力量.单纯靠开发者,效率低下,而且让等待的人觉得很没意思.比如现在.
    我认为可以发动在校的计算机专业的学生参加ld社区组织的代码讨论活动,通过参加像贴吧一样的讨论平台,学习编程经验.然后将讨论成果编写为教程,桌面环境或着深度系统的代码就回馈给ld系统.

    开源-协作-项目
    开发者将所有的工作搬到互联网上.每个项目的支持者,都能够看到项目的最新进展,并且说些支持的话语.

    社区中大概有三种角色;
    非开发者:基本看不懂代码
    @关注的东西
    [list:1n85ixbb]
    项目进展
    功能设计
    UI设计
    交互设计
    资源:图片,声音[/list:u:1n85ixbb]
    @经常做的事
    [list:1n85ixbb]将发布包安装到电脑上使用
    反馈区,提交体验
    讨论想要的功能
    提交一些图标,皮肤
    [/list:u:1n85ixbb]

    学习者:更多的是写注解,写少量代码
    @关注的东西
    [list:1n85ixbb]教程
    api文档
    功能设计
    UI设计
    交互设计
    建模
    代码[/list:u:1n85ixbb]
    @经常做的事
    [list:1n85ixbb]给api文档写些注解
    分析源代码
    给源代码写注解
    小幅修改代码[/list:u:1n85ixbb]
    开发者:编写代码
    @关注的东西
    [list:1n85ixbb]支持者的反馈
    功能设计
    UI设计
    交互设计
    架构图
    建模
    代码[/list:u:1n85ixbb]
    @经常做的事
    [list:1n85ixbb]写代码
    写api文档
    给源代码写注解
    编写代码[/list:u:1n85ixbb]
    都需要互联网间的协作.png
    目前,仅仅在发布这一环节能收到用户的反馈
    代码方面,理论上可以接受分支的合并请求,但是因为深度的影响力,和其他开发者对深度项目的兴趣,比较难接收到别人的分支.而其他方面:功能设计,UI设计,交互设计都是不公开的.
    整个开源协作社区的建设与github的产品形态有大差异,但是底层都是利用git进行分布式的版本控制,让网络间的协作不混乱.
    我受到 github everywhere 理念 和 Zoom.Quiet 评论的启发,觉得应该尽可能将可以通过互联网进行协作的工作都散发出去,都通过git控制协作进行.为了让协作更好地进行,ld就应该开发出利于网络协作的各种工具.所以需要的不仅仅是web-IDE了
    如果ld将项目托管于github或gitcafe,只能托管源代码,而且社区人员不一定能习惯github或gitcafe的使用.不作为让社区冷清清地,我也觉得是对社区不负责任的行为.
    github或gitcafe提供的服务有限,如果ld将社区协作的工具开发的很简单易用,参与社区协作的人员将优先被ld的项目吸引,而放手于集中托管平台,将得不到托管平台参与者的同级别重视.
    能做出免费贡献的人很少,同时支持ld又肯贡献的人也更少,贡献人员是所有开源项目需要竞争的资源,比如假如gnome的项目不得人心,那愿意为它贡献人就会骤减.
    免费的贡献者收获的回报不仅仅是支持者的掌声,还应该有其他有价值的东西,github成为程序员的招聘平台,那ld的开源社区也可以成为招聘各方人才的平台,ld可以收拢在社区贡献突出的人才,也可以将人才介绍到他们理想的工作单位.

    deepin-web-ide.png
    deepin-web-IDE
    web版的IDE,有些比较简单的功能,比如加注解,加评论,承认别人的代码,修改自己的代码,高级点的功能没有.
    安装一个浏览器插件,比如改造后的deepin-emacs,就能够完成高级的功能,比如直接运行,调试项目,更智能的代码完成提示,格式化代码,重命名等等成熟IDE所具有的功能.

    还需要"场景构建器",如同javafx场景构建器和netbeans一起开发javafx程序.
    场景构建器,允许布局控件,配置样式,deepin-UI的前端恰好使用浏览器绘制,所以可用基于web的场景构建器布局UI,而且可以设计动态效果.
    某个用户通过web场景构建器设计自己的皮肤,UI布局,交互方式,动态效果,还可以向后端开发者请求支援.然后将它应用于deepin-UI写的应用,比如音乐播放器,成果将通过协作平台生成皮肤包.供其它用户使用.其它用户如果不满意也可以马上通过web版场景构建器修改布局.

    开源协作平台最重要的功能是: 永葆linux deepin的青春,依靠社区的力量能够永远进步.

    注解:对阅读源代码很重要,丰富的注解能让学习者很快了解到代码的意图,而不至于晕头转向,这对协作编程很重要.方便了学习者学习编程经验,他学成,自然更愿意修改下代码作为自己的作业,这些作业可以算作对开源社区的回馈,可以很轻易地为项目的发起人或维护者收集利用.对于有兴趣的开发者,丰富的注解也能方便他明白代码意图,也更容易就利用业余的一点点时间展开项目的开发.

    最基本的注解就是介绍下这个文件是干什么的.介绍某个方法的参数,用途.
    还可以将一个方法划分为更小的代码域,以便拆分大方法.
    最小的注解单位是行.
    有一种机器注解,比如这段代码引用了一个图片资源,然后这一行的机器注解会包含一张图片,可以更直观地理解代码.学习者也可以上传理解图,用图片表达自己对代码意图的理解.还可贴上自己关于这段代码的博客地址.如果嫌麻烦,录音也行.
    我想这会是理解linux内核的学习利器吧,到时候推广到各高校就更好了.

    语言通常为汉语,愿意写英文就写英文吧.

    每一段代码,每个人都只承认有一份,一个项目就是由许许多多的的他所承认的代码组成的,即使是一个不怎么编写代码的人,他也可以先从这个人这里承认一段代码,再从那个人那里承认一段代码,然后自己再简单写几句调用代码,组织好这两个人的代码,自己就可以建立一个新的分支.
    当你觉得别人的这段代码写的比你好,你立马可以先承认他的代码,然后对照着自己原来的代码修改成自己的代码.

    我设想的开源协作编程项目,不区分项目是主支,还是分支,一切由它的支持者(使用者)决定,如果支持者愿意支持你,跟从你,使用了你那支导出的成果,那你的那一支,在支持者的心中就是主支.
    一人一支.png

    看到文章《特性分支是邪恶的？！》http://kb.cnblogs.com/page/113988/
    文章的观点
    这种状态持续时间越长，就越难合并;在分支上的工作越多，在合并到主干时越有可能破坏系统;当多个开发人员同时在这个代码库上工作，并使用特性分支开发时，使代码重构变得很难.
    作者的解决方案是频繁地将代码合并到主干,将工作分解为小块,实现完一小块再做面向用户的接口.
    协作社区的状况好像可以解决fork分支难以合并的问题.而且可以将问题细分.
    某开发者准备给它心爱的应用加上他心爱的特性,首先要承认项目发起人的这个项目内的所有代码和资源(也可以是其他人的分支,同fork).
    承认分两种:一种是持续性地承认,一种是静态承认.
    持续性地承认是 你所承认的代码发生了变化,你都优先考虑接受,如果"被承认方"破坏了你目前所做的修改,让程序运行不起来了,可以立马发起协商.或者你认了,改动自己的代码,适应"被承认方"的变化.<--这样方便于他人合并.像是github中将远程代码合并到本地仓库.
    静态承认是 你无法忍受"被承认方"所做修改破坏了你写的代码,你跟他写的就是要不一样(不一样才有进步嘛).只能够期待被承认方承认你的代码(pull request被接受,代码合并到主支).<--这种承认只发生一次.
    持续性承认保持你的代码与"被承认方"代码持续合并的能力,而静态承认则包含了你的代码与"被承认方"代码不一致的部分,这一部分如果被"被承认方"承认,效果等同于分支合并到主支.
    Reply Favorite View the author
    All Replies
    cxbii
    deepin
    2013-01-10 06:13
    #1
    目前社区化的确不够,以后可以在论坛任务发布小任务让社区参与,目前论坛任务区一直没动静
    Reply View the author
    deepin
    deepin
    2013-01-11 05:54
    #2
    electricface 你的产品想法挺多, 虽然不一定适合ld目前的情况,但是我觉得有机会可以好好交流下.
    你有pm 的潜力,呵呵
    Reply View the author
    electricface
    deepin
    2013-01-11 06:34
    #3
    我的新浪微博是@伪码,可以好好交流的.
    Reply View the author
    musmuhe
    deepin
    2013-01-11 07:30
    #4
    deepin-web-IDE,开发者用不到这个.
    开发者用git.
    linuxdeepin的gitcafe代码托管https://gitcafe.com/LinuxDeepin
    Reply View the author
    158******30
    deepin
    2013-01-11 08:29
    #5
    支持一下！
    Reply View the author
    zhtengw
    deepin
    2013-01-11 09:09
    #6
    github已经足够了，只要Linuxdeepin能够及时提交代码上去～
    Reply View the author
    electricface
    deepin
    2013-01-11 17:21
    #7
    说实话,我也不是编程方面的专家,就懂些基本的,没有实战经验.
    但我觉得开源项目文档很重要,注释很重要,因为不是当作自己营生的工作来做,可能不太愿意写api文档或是注解.
    我设想的开源协作编程项目,至少是提供了程序员的原始渴望"将文档交给其他人去写"的实现可能,也许经验老到的程序员在阅读源代码码的时候只是随意地写下些注解,但是这些注解如果能被收集起来,就能在别人需要注解才能理解时给予参考.而且不懂的话还可以直接发问.
    此种协作编程形式,其实可以成为一种面向开发者,学习者和支持者的一种立体的社交网络形式.大家交个朋友也很不错,而且和朋友一起完成开源项目对程序员来说不是更有娱乐性吗?比枯燥地向git提交代码,然后就什么都不管了要有意义得多,所以我认为我的这种协作编程方式更容易在开源项目的发展中形成一种复杂稳固的关系网,值得大家为之倾注感情.
    很可惜git不具有这种功能,其实它是不给人机会.比方说目前的开源编程方式好像是玩单机游戏,而我设想的编程方式是网络游戏,如果你是游戏开发商,你把游戏做成单机的其实是自己没有好好发掘游戏的盈利能力.程序员通过web-IDE可方便交流,一同使力,能避免做不必要的工作.学习者可以直接向老到的程序员提问.而支持者也可以获得项目的最新进展情况.目前ld一直在微博上放出运行截图和视频,就是为了吸引大家.
    如果git有这种功能,linux内核的源代码在我这种小白的眼里也不会太神奇,因为我通过大家一起努力生成的注解可以很轻易地对照源代码直接理解linux内核的工作原理.如果很复杂我还可以点开贴在注解墙上的博客专题的链接,深入学习.
    6. 写文档

    在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的经验，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发 的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服等)都能理解的文档手册。

    我们可以很容易的看出，有些事情程序员们极不愿意去做。 你可以简单的回顾一下所有的开源项目。 人们百折不挠的对这些项目的一个索求是什么：文档。
    我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会说：“不能让其他人去写吗？“。

    5. 程序 — 缺少文档

    我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。

    当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数 poorlyNamedFunctionA() 和函数 poorlyButSimilarlyNamedFunctionB() 有什么区别？ 在我使用 PropertyX 属性前是否需要测试一下它是不是 null 值？我估计只有通过自己的测试和报错才能弄清楚!。
    Reply View the author
    zhtengw
    deepin
    2013-01-11 17:26
    #8
    此种协作编程形式,其实可以成为一种面向开发者,学习者和支持者的一种立体的社交网络形式.大家交个朋友也很不错,而且和朋友一起完成开源项目对程序员来说不是更有娱乐性吗?比枯燥地向git提交代码,然后就什么都不管了要有意义得多,所以我认为我的这种协作编程方式更容易在开源项目的发展中形成一种复杂稳固的关系网,值得大家为之倾注感情.
    很可惜git不具有这种功能,其实它是不给人机会.比方说目前的开源编程方式好像是玩单机游戏,而我设想的编程方式是网络游戏,如果你是游戏开发商,你把游戏做成单机的其实是自己没有好好发掘游戏的盈利能力.程序员通过web-IDE可方便交流,一同使力,能避免做不必要的工作.学习者可以直接向老道的程序员提问.而支持者也可以获得项目的最新进展情况.目前ld一直在微博上放出运行截图和视频,就是为了吸引大家.
    如果git有这种功能,linux内核的源代码在我这种小白的眼里也不会太神奇,因为我通过大家一起努力生成的注解可以很轻易地对照源代码直接理解linux内核的工作原理.如果很复杂我还可以点开贴在注解墙上的博客专题的链接,深入学习.

    git是没有这些功能，但github有，github是利用git作代码托管的平台，具有一定的社交功能
    Reply View the author
    electricface
    deepin
    2013-01-11 18:04
    #9
    [quote]
    此种协作编程形式,其实可以成为一种面向开发者,学习者和支持者的一种立体的社交网络形式.大家交个朋友也很不错,而且和朋友一起完成开源项目对程序员来说不是更有娱乐性吗?比枯燥地向git提交代码,然后就什么都不管了要有意义得多,所以我认为我的这种协作编程方式更容易在开源项目的发展中形成一种复杂稳固的关系网,值得大家为之倾注感情.
    很可惜git不具有这种功能,其实它是不给人机会.比方说目前的开源编程方式好像是玩单机游戏,而我设想的编程方式是网络游戏,如果你是游戏开发商,你把游戏做成单机的其实是自己没有好好发掘游戏的盈利能力.程序员通过web-IDE可方便交流,一同使力,能避免做不必要的工作.学习者可以直接向老道的程序员提问.而支持者也可以获得项目的最新进展情况.目前ld一直在微博上放出运行截图和视频,就是为了吸引大家.
    如果git有这种功能,linux内核的源代码在我这种小白的眼里也不会太神奇,因为我通过大家一起努力生成的注解可以很轻易地对照源代码直接理解linux内核的工作原理.如果很复杂我还可以点开贴在注解墙上的博客专题的链接,深入学习.

    git是没有这些功能，但github有，github是利用git作代码托管的平台，具有一定的社交功能[/quote]
    能否详细介绍下github的社交功能? 或是给我一些指引.

    github是社交编程网站,和我的想法差不多吧.难道要把github部署到ld社区?
    以下是在一个典型的工作日中的一些数据：
    [list:25428y55]
        10000新用户注册，并创建了第一个库
        Push 140GB新数据
        创建25000个库，7000次Pull Requests
        Push 12.5万个库[/list:u:25428y55]
    github号称程序员的维基百科.
    目前GitHub共有280万注册用户，仅在2012年就增长了133%。
    目前美国是GitHub上最活跃的国家，占总数的28％。其次为德国、英国、中国、日本、法国、印度、加拿大、俄罗斯和巴西。
    其开放平台使得开发者之间的合作更加便利，他们可以在网站上看到其他人已经发布的代码，从而减少了重复工作。
    GitHub的主要业务来自开源社区，但也可以通过付费业务赚钱，最新的融资将帮助该公司进军新市场并吸引用户。GitHub已经开发了简单易用的Mac和Windows版客户端，但普莱斯顿-沃纳还希望为Linux和移动用户开发类似的软件。他希望GitHub的用户不仅包括程序员，还能囊获设计师与科技作者，他将这一理念称作是“GitHub Everywhere”
    github真有野心.
    Reply View the author
    electricface
    deepin
    2013-01-12 00:47
    #10
    我觉得很有价值的评论:http://blog.gitcafe.com/99.html#comments
    九月 25, 2012

    我们接触的几个国内开源项目，还是属于“分布式测试”的模式，没有形成社区对项目在路线图、技术、研发等各方面的推动。其实很多项目都很不错，只是还缺乏来自“散户”的支持。
    九月 25, 2012

    教育+企业,的确是中国开源生长的基础环境,教育方面就不吐糟了,
    以上都是 托总在校期间长期同社会各界碰撞得来的体验,
    俺只对最后一点追加吐糟一下:
    “…将内部优秀的不影响企业业务发展的技术开源出来，社区化”
    - 不能对企业发展提供助力的技术就不是优秀技术
    - 不影响企业发展的技术,企业本身就没有动力来继续发展
    - 没有原创人员加入的社区,不是技术社区,只是垃圾堆!

    中国一线 IT 企业开源出来的项目不少了,几十个是有的
    整体印象是:
    - 相似的非常多,仅仅分布式文件系统,几乎每家都开源出来了一个
    - 大家愿意使用的,都是各家内部也在大规模使用的项目
    - 但是,技术社区是社区,企业开发团队是团队,两者好象从来没尿在一起过
    – 当然,是指国内的中文技术社区
    – 各家大佬,基于的都是国外的技术社区作品进行的深度定制
    – 形式上/情感上/立场上都是从属于人家国外社区的
    – 常常有几个 pull request 被国外社区接受,就很了不起的样子…

    俺想説的,其实云时代了,技术真心退居二线了,由大数据/大服务/大平台组成的生态环境,才是企业的核心竞争力, google 就算将 GFS 整个开源了,也没有谁能复制出个 Google 出来
    所以,
    - 要开源,就开源企业业务紧密相关的核心技术! ~ 当然,不用包含业务代码的
    - 社区化,不仅仅是一堆代码+文档+BBS 完事儿的!
    – 社区化更加重要的是意味着,企业内部开发/管理/发布流程也社区化!
    – 使用开源变化来加速内部团队的进化,将面向 KPI 的开发,转回真正的面向品质的开发!
    – 核心开发人员应该进驻社区,处理/反馈/接受 社区来的 补丁/意见/建议…
    这样, 企业/社区/社会 才能多贏!
    Reply View the author
    musmuhe
    deepin
    2013-01-12 00:56
    #11
    github真有野心.
    这个不是野心的问题.
    山之将顷,匹夫难撑。水之将涌,石破天惊。
    全是"势"的问题
    Reply View the author
    electricface
    deepin
    2013-01-14 18:27
    #12
    我发现用lzx写代码够舒服.好精简
    2. 所有项目 项目*
    3. #只写个框架,余下的交给UI布局工具
    4. 窗体
    5.     表格 列属性"ID,状态,简述"
    6.     列表 列表框
    7.     新建按钮 按钮
    8.     保存按钮 按钮
    9.     删除按钮 按钮
    10.     细节面板 面板
    11.         简述文本框 文本框
    12.         详述文本框 文本框
    13.         状态选择框 选择框"新的,完成,暂停"
    14.     ;细节面板
    15. ;窗体
    16. 窗体加载(){
    17.     所有项目=
    18.         项目 工程'project-1' 简述'简述一下' 详述'描述一下'
    19.         项目 工程'project-1' 简述'简述一下' 详述'描述一下'
    20.         项目 工程'project-1' 简述'简述一下' 详述'描述一下'
    21.         项目 工程'project-2' 简述'简述一下' 详述'描述一下'
    22.     =
    23.     更新列表
    24.     更新表格
    25.     表格选中模式'行
    26. }
    27. 项目{
    28.     jsq _i
    29.     工程 s
    30.     ID s
    31.     简述 s
    32.     详述 s
    33.     状态 "新的,完成,暂停"
    34. }
    35. 项目=(){
    36.     ID='TT-'+jsq
    37.     jsq++
    38.     状态'新的
    39. }
    40. 更新列表=(){
    41.     列表~所有项目//工程.键
    42. }
    43. 更新表格=(){
    44.     表格~所有项目.过滤(a){
    45.         若a工程==列表选中项
    46.             留下a
    47.     }
    48. }
    49. 更新细节=(){
    50.     a=表格选中项
    51.     若a==空
    52.         简述文本框~空
    53.         状态选择框~空
    54.         详述文本框~空
    55.         返回
    56.     ;若
    57.     简述文本框~a简述
    58.     状态选择框~a状态
    59.     详述文本框~a详述
    60. }
    61. 所有项目值改变(){
    62.     添加(){表格..添加的}
    63.     删除(){表格$删除的}
    64.     修改(){表格选中项~修改的}
    65. }
    66. 列表选中项改变(){
    67.     删除按钮禁用
    68.     保存按钮禁用
    69.     新建按钮启用
    70.     更新表格
    71.     更新细节
    72. }
    73. 表格选中项改变(){
    74.     删除按钮启用
    75.     保存按钮禁用
    76.     新建按钮启用
    77.     更新细节
    78.     若*选中项==0
    79.         删除按钮禁用
    80. }
    81. 细节面板鼠标离开(){
    82.     a=表格选中项
    83.     若a==空
    84.         返回
    85.     若a简述~!=简述文本框 或 a详述~!=详细描述文本框 或 a状态~!=状态选择框
    86.         保存按钮启用
    87.     否则保存按钮禁用
    88. }
    89. 新建按钮被单击(){
    90.     所有项目..项目 工程=列表选中项 简述~简述文本框 详述~详述文本框
    91.     表格选中末行
    92. }
    93. 删除按钮被单击(){
    94.     b=表格!选中项
    95.     所有项目$[ID=表格选中项ID]
    96.     若b>1
    97.         表格选中行b-1
    98. }
    99. 保存按钮被单击(){
    100.     b=表格!选中项
    101.     所有项目[ID==表格选中项ID] 简述~简述文本框 详述~详述文本框 状态~状态选择框
    102.     表格选中行b
    103. }
    Copy the Code
    类之序语法还是非常严谨的,而且它给了解析器变聪明的机会.
    Reply View the author