#### 从github的liteos的dev-desert分支移植上云的组件到已经测试过成功的接管中断的liteos，编译通过了，但出现下面报错>求大佬帮帮忙

在该系列的第一篇文章中，主要介绍了Knative的基本概念及诞生背景，并提到 Knative 主要由 Build、Serving 和 Eventing 三大核心组件组成，本文将重点 Build 的使用方法。具体来说，Build 提供源码到容器镜像的构建能力；Serving 提供 Serverless 应用或函数的部署能力，并通过 istio 实现服务管理，同时提供了容器扩缩容能力；Eventing：提供事件触发通道。Knative 的这三个组件提供了一套完善的 Serverless 方案，让开发者可以只关心自己的代码。提交代码以后，Build 会将源码构建成镜像，Serving 会自动实现应用部署，Eventing 提供事件触发入口，接下来就可以访问到最新应用了。对使用者来说，从源码直接到应用，省去了中间复杂的环节。Build 完全基于 Kubernetes，设计非常灵活，用户可以利用 Build 定制构建流程，虽然官方文档宣称现在 Knaitve 还不能提供完整的 CI/CD 方案，但是利用 Build 的灵活性完全可以实现 CI 平台搭建，这部分内容会在后面的实现中着重介绍。本文，我们把 Build 组件拆开揉碎，全面分享给读者。如果现在手头刚好有一个K8s集群，可以跟着文档尝试操作，整个过程甚至不需要占用一杯咖啡的时间。Build 组件安装Build 可以作为一个独立组件单独安装，只需要在 K8s 的集群中执行以下命令即可：kubectl apply --filename https://github.com/knative/build/releases/download/v0.6.0/build.yaml执行成功以后，可以通过以下命令查看：kubectl get pods --namespace knative-build可以看到，在 knative-build 的 namespace 下，新增了两个容器 build-controller 和 build-webhook，build-controller 是 Build 核心模块，其基本业务流程是监控自己创建的 CRD 资源从而实现构建，build-webhook 和大多数的 webhook 功能一样，通过 webhook 的方式对自己的 api 进行校验。到这里恭喜你，Build 组件已经安装成功了，接下来就可以利用它来进行构建。build 和 buildtemplate构建之前，我们需要先了解两个概念：build 和 buildtemplate。这里的 build 不是 knative 的 Buid 组件，而是 Build 组件通过 CRD 定义的一个资源文件，build 通过自己定义资源文件去控制构建流程，所以说，Build 完全基于 K8s 生态，只要有 K8s 集群就可以完成构建而不需要依赖其他外部组件，同时，yaml 定义的资源文件也可以很轻易的移植到其他集群上去。为了方便理解，我们先看一个 build 的 yaml 文件：apiVersion: build.knative.dev/v1alpha1   kind: Build metadata:   name: kaniko-build   spec:     serviceAccountName: build-bot   // 如果源码或者仓库为公开可以不用创建 serviceAccount     source:    git:      url: https://github.com/my-user/my-repo   // 你的源码仓库地址      revision: master                          // 你的源码分支地址    template:       name: kaniko                                     arguments:    - name: IMAGE      value: us.gcr.io/my-project/my-app         // 构建成功以后镜像存放的镜像仓库地址   以下是其中的几个关键配置：如果想在自己的代码仓库尝试用 build 进行构建，只需要修改上面蓝色的部分即可。看起来，build.yaml 非常简单，而且在 yaml 中也没有看到关于构建过程的体现，是因为在这个 build.yaml 里定义了一个 buildtemplate，buildtemplate 中定义了实际构建过程中的 steps（关于 steps 的内容我们稍后会讲到），当我有多个代码库，或者代码库下有多个分支，抑或是代码想用不同的方式去构建，每次都要定义一个完整的 build 文件就显得非常麻烦，这个时候利用 buildtemplate 可以定义很多构建模板，然后只需要像上面的 build.yaml 一样简单指定代码仓库即可。那么，buildtemplate 是必须的么？当然不是，我们可以直接把 steps 写在 buid.yaml 里，但是 buildtemplate 极大的提高了 build 的灵活性和可移植、可重用性。为了方便快速实现构建，knative 的 build-template 代码库中已经预置了大量的 buildtemplate，包括bazel，buildpacks，kaniko等近十个模板，这里我们先用 Kaniko 的 build-template 体验一下 build 的构建过程。Kaniko 是 Google 推出的构建工具，它基于 Dockerfile 进行构建但是却不需要 docker daemon，我们先来看一下 Kaniko 的 buildtemplate 是什么样子。apiVersion: build.knative.dev/v1alpha1   kind: BuildTemplate   metadata:     name: kaniko   spec:    parameters:  - name: IMAGE      description: The name of the image to push  - name: DOCKERFILE      description: Path to the Dockerfile to build.      default: /workspace/Dockerfile    steps:  - name: build-and-push      image: gcr.io/kaniko-project/executor       args:      - --dockerfile=${DOCKERFILE}    - --destination=${IMAGE}     env:       - name: DOCKER_CONFIG      value: /builder/home/.dockerbuildtempate 中也有几个关键配置：kaniko 的 buildtemplate 十分简单，只有一个 step，然后传入两个参数 DOCKERFILE 和 IMAGE 即可，DOCKERFILE 是工程中 dockerfile 所在的文件路径，IMAGE 是要推送的镜像仓库地址。这两个文件都准备好以后你只需要执行以下两条命令, 一切顺利的话一段时间时候以后，你就可以在你的镜像仓库里看到你刚刚构建好的镜像了。kubectl create -f kaniko.yaml   kubectl create -f build.yaml如果只是想体验一次 Build 带来的基于原生 K8S 的快捷构建，到这里你的体验之旅就已经结束了，如果想问到底执行完以后发生了什么，那就再花点时间看看到底发生了什么？Build 构建实现在上述步骤创建完 build.yaml 以后执行kubectl get pod我们发现多出了一个 pod，用 describe 查看 POD 可以看到以下信息：Name:               kaniko-build-pod-a4f897   Namespace:          default   Controlled By:      Build/kaniko-build Init Containers:  build-step-credential-initializer:Image:          gcr.io/knative-releases/github.com/knative/build/cmd/creds-init@sha256:101f537b53b895b28b84ac3c74ede7d250845e24c51c26516873d8ccb23168ce  .......  build-step-git-source-0:    Image:         gcr.io/knative-releases/github.com/knative/build/cmd/git-init@sha256:ce2c17308e9cb81992be153861c359a0c9e5f69c501a490633c8fe54ec992d53    Args:      -url   https://github.com/lihua871205/2048.git      -revision      master   ......    build-step-build-and-push:    Image:         gcr.io/kaniko-project/executor    Args:      --dockerfile=/workspace/Dockerfile      --destination=swr.cn-north-1.myhuaweicloud.com/l00283074/sample:latestPOD 里边包含三个 Init Containers：build-step-credential-initializer， build-step-git-source-0 以及 build-step-build-and-pushbuild-step-credential-initializer：如果 git 和 docker 需要认证的对 git 和 docker 进行认证build-step-git-source-0：负责将代码拉取到 workspace 下build-step-build-and-push：是用户自己定义的构建 step，它负责将源码构建成镜像从这里，我们可能已经猜到 build 的构建实现，利用 Init Containers 的特性，build 先将 source 中的配置生成一个默认的 build-step-git-source-0 接下来再将用户 step 中配置的信息依次解析成多个 Init Containers，当 POD 运行的时候会依次执行所有的 Init Containers 从而实现代码获取，源码构建的流程。这也回答了上面的两个问题：为什么每个 step 都要有一个 builder？这是 Init Containers 的特性决定的，即使是 Source 这个步骤其实也是使用了 Build-Controller 内置的一个镜像；为什么 build 非常灵活？用户可根据自己的场景，自己定制构建镜像，Build 只提供构建流程，但是不提供构建实现，这也是为什么当前有这么多 buildtemplate 的原因。我们再回顾下 Build 的基本流程：总结Knative 的 Build 利用 init container 实现了一个基于 K8s 生态的构建流程，用户可以自己定制构建场景，或者利用丰富的 build-template 实现构建，它可以作为一个独立的组件减少 K8s 构建的烦恼，更重要的是可以嵌入到 serving 中（偷偷预告一下后面的章节会讲到 build 如何和 serving 集成到一起）形成完整的 Serverless 生态，只有通过 Build 快捷地将源码变成镜像，才能让 serving 有源源不断的“粮草”大展身手。

初次使用者角度对比codehub、github与gitee代码托管的差异评价方法分别在codehub、github和gitee的主站上创建账户，浏览并操作，从初次使用者角度主观给出三者的差异，主要从代码托管服务的界面整体效果、初学者操作的难易程度、内容展示和提示信息的完整性、可操作性、文档的支持、语言的支持、团队或多用户协作、操作日志等方面对比判断。分项对比对比项codehubgithubgiteehome页home页是仓库页面，概览页面在Devcloud首页home页是仓库概览，简洁清爽home页是项目概览，模仿github但有些杂乱仓库页列表展示，有更新状态，可直接复制仓库URL列表展示，有更新状态列表展示，有更新状态，可添加标签code页代码列表页，不能自动显示README.md代码列表页+显示README.md代码列表页+显示README.md文件浏览页可浏览、可在线编辑、移除等，移除时需要输入文字确认可浏览、可在线编辑、移除等，移除时需要输入文字确认可浏览、可在线编辑、移除等，移除时不需要输入文字信息创建库优点是可以从模板仓库中选择新建新建和导入新建和导入（有疑问）导出支持git和https，也支持zip和tar包下载支持git和https，支持zip下载，支持github客户端支持git和https，支持zip下载导入可以从github和gitee的项目中导入可以从codehub的项目中导入在导入codehub和github项目时一直处于后台处理状态中分支分支页签中的新建分支流程很清晰在branch里输入分支后，才提示创建分支在branch里点击管理按钮创建分支提交在页面中保存即提交，三个平台相同三个平台相同三个平台相同合并与冲突与github、gitee基本相同，差别不大差别不大差别不大删除删除仓库时需要输入密码删除仓库时需要输入密码删除仓库时需要输入密码提示信息完整性提示的信息很适合国情，比如：在仓库代码页中提示git客户端配置、ssh密钥和https密码设置、推送和异常处理；在分支标签中则提示为什么需要分支、如何操作等等提示信息比较好，不过英文看起来有时候不习惯比较好，与github很像与项目关联通过“关联工作项”与项目任务关联在projects中创建与之对应的项目使用第三方的devops平台页面适应宽屏自适应，使用大屏显示器的时候很舒服固定宽度的页面固定宽度的页面文档支持有比较全的文档支持代码托管有比较全的文档支持book文档支持略显粗糙码云代码管理团队和多用户创建团队成员需要多次认证，相对麻烦从github用户里选择，较为容易提供了二维码和链接的邀请机制，相对比较人性化日志在“设置-安全管理-操作日志”中有非常清晰的日志记录，“仓库统计”和“仓库网络”里有图形显示的记录首页有activities，统计页面采用图形显示首页活动中主要记录创建、删除、推送、star、fork等操作；在统计页面也有较为详细的统计总体评价总体来讲，codehub、github差别不大，在界面展示、文字提示方面，codehub人性化更好，新建仓库时的“从模板仓库中选择”特别优秀，但代码的home页不自动显示README.md，个人觉得有些诧异，另外在团队和用户管理的过程中显得有些复杂，当然安全也提高了；在习惯性方面，可能github有先天优势，总觉得codehub一些功能是对照github的功能后又修改的；也许是gitee的服务器能力优先，在测试过程中gitee始终不能从codehub和github上导入项目，遗憾。具体哪个代码托管平台更加优秀，我觉得还是要看用户的使用习惯，或者用户以往的使用经验，不过对于初学者，简单学习后均能在codehub、github、gitee之间熟练切换，^ - ^。P.S. 偶然使用到了gitee，所以在评测中追加了对比项。BY 志鹏-zhaurora163com

最近GitHub遭遇黑客攻击虽然我们公司没有使用GitHub，而是用gitee(码云)，但对于此次事件后，对代码的安全提到非常高的程度。作为公司核心的资产之一---源代码，一直是公司最高等级的机密之一，正因为GitHub的事件，所以考虑在公司内搭建gitblit（相当于搭私有的github）。但是公司内搭建gitblit，会存在多地协作的问题，虽然可以通过搭建VPN等方式将多地连在一起，但是VPN的维护成本高（SSL VPN按用户收费，某厂家防火墙（不是华为）的IPSec VPN没有MAC端）。不管是GitHub还是gitee也不确保不出事，到底我们的代码应放在那间可信赖的代码呢？我们测试一下华为云代码托管的安全性删除，必须通过输入完整的仓库名称才能删除，这点好评。然而，项目的删除在那里呢？至少我一下子找不到。而根据相关文章的指导，GitHub中开启双因子认证，可以加强安全性。GitHub中开启双因子认证的介绍页和操作并且有相当贴心的操作指引可见github经过这次事件后，对安全十分重视。然而华为云暂时没有找到搜索也没有搜索到算了，先按流程先新建一个吧不过有个问题，是必须要归属项目SSH克隆，这些最常用功能，就驾轻就熟了。并且相信这块华为云也经过大量测试上传：同样，本次GitHub泄密的嫌疑SourceTree同样也是正常使用接下来是基本评测内容：1. 操作体验：在各种使用场景中操作是否流畅，是否出现逻辑上的中断？答：非常流畅，除了必须要归属项目外。界面设计也相当好看，比gitee好看多了。也没有出现逻辑中断2. 性能：页面性能是否感受比较舒服？答：非常舒服，在电信100M光纤是非常快3. 功能特性：对比体验官已用过的Code Review类的产品，是否更加方便易用，功能设置合理？答：只用过github和gitee，感觉华为云做得比这二者都要好（github的访问速度超慢，gitee界面难用爆）4. 满意度及推荐度：体验官是否愿意使用该产品作为自己企业研发过程中的Code Review工具？是否愿意推荐给其他朋友或同事？答：满意，但是安全性有待加强，就算没有双因子认证之类，至少出一份代码安全加固指引。有鉴于github的事件，己经将代码从gitee干掉，并且禁止使用sourceTree一类的工具必须只允许使用原始的git，短期内估计不会用任何公有仓库……但会推荐给其他朋友使用华为云托管，毕竟速度够快，界面漂亮。5. 在使用过程中的页面帮助与文档帮助，是否合理，准确，有参考价值？答：至少找不到在那里删除项目。也没有找到加固指南之类。另外，也没有看到价格表（难道是免费？免费也得写一下啊）5. 对于CodeHub产品的其他意见和建议。答：给一份华为云代码托管服务的安全加固指引，十分急需！特别是经过这次github事件后。

首先，还是很感谢华为体验官部落能给我这么一个体验的机会，当然也是靠我孜孜不倦的在部落中苦苦蹲守，抓住了这次体验官的机会，（哈哈哈，自吹一波）；然后，进入正题，因为体验时间有限，加上不能和部落中一些成名已久，带领成熟团队的大佬相比，所以只能我自己默默的输出这次的评测帖。目前，自己所在团队项目所用的工具是Gerrit，自己也胡乱搭建过Gitlab，使用过Github和Bitbucket，更多的使用的是Gitee（码云），后面比华为Devcloud更早出来的产品就是腾讯推出的Cloud Studio云端开发WebIDE了，这几大产品截图如下：Gerrit：Gitlab：Bitbucket：Gitee（码云）：腾讯Cloud Studio云端开发WebIDE：本人因为是菜鸟小白，平时就喜欢瞎折腾，杂而不精，希望各位观帖大佬海涵。使用感受进入正题，说说这几天使用下来的感受和对比情况；首先，整个华为Devcloud服务中的代码托管服务产品我个人觉得是个不错的产品，虽然在竞品服务如此多的市场中也依然是做出了具有一定自身特色的产品，这点是值得肯定的，但是距离像是github和gitee这种相对来说成熟度较高，活跃人数相对较大的产品来说，差距还是有的，主要存在于以下几点：1、和Gerrit相比而言，UI界面比Gerrit要好很多，但是就提交代码规范程度这点来说，存在不足，因为Gerrit在提交代码的说明信息中强制要求了需要按照一定格式规范进行提交，不然是自动识别提交失败的，但是这个点我在华为代码托管服务产品中未能找到设置的地方，希望能在后续迭代版本中添加该功能；2、和Gitlab、Github和Bitbucket相比，给人的感觉就是UI设计上和使用交互上没有前三者那么紧凑和简洁，感觉华为代码托管服务产品的UI设计上比较松散，简洁度上可能还不够，当然这是我个人意见，哈哈。3、和腾讯Cloud Studio云端开发WebIDE对比，这个竞品出来的比较早，应该是在18年上半年就已经开始招募内测了，本人有幸成为该产品的内测用户，一直体验到现在，就代码托管服务而言，腾讯的产品没有华为做的好，因为腾讯的产品在导入已存在仓库的操作上，比较死板，需要先将已存在的仓库进行本地化，然后再推送到新建的远程仓库上进行代码托管，不能像华为代码托管服务这样自动连接到github或者gitee上进行fork操作，如下图对比：腾讯Cloud Studio云端开发WebIDE华为代码托管服务产品对比结果一目了然；当然，这个问题在和bitbacket和gitlab上也存在，并且github也仅仅只是支持上传和fork，不支持和兼容其他代码托管平台，而在这个方面做得比较好的产品我个人觉得是gitee（码云），对比操作截图如下：对比下来，华为产品的使用说明提示更加显眼，人性化，点赞ing；4、产品使用说明帮助文档以及使用步骤提醒上，个人认为gitee（码云）是要比华为要好一些的，腾讯的产品就比较一般了，见下图：gitee（码云）华为云产品腾讯云产品：整体来说，gitee（码云） 的产品说明使用文档是细节做得是最好的，从指引的出处，到入口的详尽显示，到最后操作的成功图示，都做到了详尽指示，并且通俗易懂，相对而言，华为的帮助文档在整体上比较完备，但是细节指引以及人性化的通俗易懂上会存在一定的不足，这个希望能够在后续版本中进行优化。5、这个部分其实我个**会的并不深，因为纵观我罗列的这些产品，在使用所谓的插件功能，或者说是云IDE开发组件功能的时候，其实都不算顺利，很多情况下是该功能暂未实现，或者是该功能需要特殊申请或者付费才能进一步实现，所以这一块的功能是体验不完整的，对此，我个人建议是可以让华为给我们体验官进行一次专场体验活动，以便展示华为的强大资源整合能力，哈哈哈，希望能采纳。以上就是本人这个小菜鸟的体验报告，希望各位观帖大佬多多指正，不吝赐教，跪谢！！！

华为云代码托管服务产品体验及评测华为云代码托管服务产品体验及评测 - Mike Cao1. 操作体验：在各种使用场景中操作是否流畅，是否出现逻辑上的中断      总体来说，各种使用场景非常流畅，但是如果是在华为官方提供的repo可以提供对应的版权（商业/开源）就好了。。     对于华为与代码托管仓库，我看到目前支持私有和公开只读两种模式，我印象中github上私有是单独收费的，在这个页面我没有看到华为devcloud对两种方式的费用描述,我仔细阅读了下https://support.huaweicloud.com/pg-codehub/codehub_pg_00002.html ，感觉描述的不是太清晰。如果可以写明确下旧好了就好了，如果是免费的恩，当然就更好了。哈哈哈哈        对于华为云代码托管新建仓库，支持一下三种模式。普通创建，模板创建和导入仓库三种关于第一种普通创建，我感觉该创建方式和github 操作流程等都很类似，这里就不做过多的重复关于第二种创建，我个人认为还是比较挺有亮点的，devcloud 云已经提供了很多种已经写好的demo环境。还支持模板预览，非常给力。我自己测试了 python2 demo. 感觉速度什么的都还可以，就是这些官方模板没有写代码copyright(如下接图） .如果可以提供对应的信息可能以后可以免除一些必须要的麻烦。第三种导入仓库更偏向与代码迁移。从其他的托管服务器迁移到devcloud 上。对于repo的功能性操作devcloudUI做的也是比较全面的。也支持代码检查。   2. 性能：页面性能是否感受比较舒服？因为工作的原因，我测试了中国联通和日本VPN的网络，操作上都还可以，没有明显的停顿。但是日本的网络下git pull到 本地的速度我没仔细测试，我感觉对广大的中国用户来说每那么重要3. 功能特性：对比体验官已用过的Code Review类的产品，是否更加方便易用，功能设置合理？功能特性和github 相比，比较完善，github可能需要自己动手去做一些集成。关于代码检查，默认集成了3718个，不少了，但是如果支持可以自己设置的代码检查规则可能会更好。4. 满意度及推荐度：体验官是否愿意使用该产品作为自己企业研发过程中的Code Review工具？对于自己的开源项目，如果没有费用，那相对来说我个人是愿意把代码从github上通过导入仓库的方式去做的。但是对于企业研发流程涉及了太多太多安全性和合规性的要求，华为yun如何能说服所有客户在在上面的私有数据是安全的不被内部人员看到会是一个小小的挑战。5. 在使用过程中的页面帮助与文档帮助，是否合理，准确，有参考价值？文档相对来说格式清晰，看上去就舒服想让人读下去。就是费用描述这段描述不算太清晰6. 对于CodeHub产品的其他意见和建议。总体来说，功能和性能上还是很不错的。如果在提供的官方repo template上可以加上copyright 会更完善一些 代码检查文档没有找到，不知道是不是基于pep8进行检查的，如果有对应的说明就更好了。Mike Cao

黄区是可以访问github的，那上面有很多优秀的开源项目。但是黄区不允许直接git到本地只能直接下载压缩包。那些可以直接下包的都是有专用代理的。希望有什么技术手段能够安全，方便的把通过git工具直接将代码下载下来。（主要是一些开源项目有一些三方库也挂在github上，压缩包无能快速编译这部分。）只是建议安全第一，安全第一

NB-IoT常见入门问题汇集中问：NB-IoT的优势是什么？答：支持单小区50K用户连接，做上传用低功耗优势明显。问：NB-IoT支持定位吗？答：NB-IoT支持基站定位，当前（18年10月）只有电信支持，前提接入电信的物联网平台。问：NB-IoT是否支持短信？答：特性上是支持的，但目前没有开通。问：NB-IoT支持哪些通讯方式？答：支持TCP、UDP协议，应用层通信包含：MQTT、CoAP、LWM2M。问：基站是否可以寻呼终端？答：PSM状态下基站不能寻呼，只能在Connect或Idle状态下。问：NB-IoT有几种工作模式？答：有3种：Active、Idle和PSM。问：NB-IoT模式切换由谁控制？答：由使用的NB卡确认使用不同的APN，APN信息配合和基站协调模式切换时间。问：NB-IoT是否可以切换小区（移动性）？答：支持。问：CoAP协议是什么？答：CoAP协议是建立在UDP基础上，类似于TCP和HTTP的关系。问：NB-IoT是不是都采用eSIM？答：NB-IoT的产品特点是不需要安装配置，直接开机连接网络就能工作，并支持自动登记设备和空中升级等功能。SIM卡和eSIM将会长期共存，运营商拒绝软SIM的模式。有什么问题大家可以在下面提出，知道的愿意和大家一起分享！

炒得沸沸扬扬的微软 Github 收购事件于昨天（06月04日）尘埃落定，微软最终以 75 亿美元正式收购 Github。随后，Gitlab 趁势带了一波节奏，在其官网上祝贺 Github 被微软收购，并表示此次收购代表着软件开发者的影响力的日渐增长，将软件开发的下一个发展看成是每个人都可以贡献的世界。[indent]原文https://about.gitlab.com/2018/06/03/microsoft-acquires-github/[/indent]微软公司的实力不用说，操作系统、办公套件几乎被微软垄断，你没见过国内用 Linux 系统上班的吧，Mac 也只是小众，太贵，也并不是所有普通人能用得起的。有网友称这是一桩最滑稽的收购案，世界上最大的闭源公司收购了世界上最大的开源公司。这 10 年来，Github 并未盈利，其主要盈利来源也只是其私有的个人仓库（7美元/月）及一些企业化的功能，大部分人都是免费使用其公有仓库来托管代码的。我就是公有仓库的受益者，不是我不付费，而免费的替换者实在太多了，Gitlab 还有国内的码云等都是免费支持私有仓库的。所以 Github 卖身微软也说得过去，比起上市，被巨头收购可能更适合 Github 的后续发展。毕竟微软也作为曾经的龙头企业，一直以来也是采用 Git 协议，自身也有许项目需要用到代码托管，目前就已有超过 1000 个微软开发人员在 Github 上贡献代码，已是 Github 的最大贡献者。微软购买 Github 后，可能会有很多开发人员弃坑，而选择其他的代码托管平台。为什么呢？微软在开源上已经是十分保守的，而且有着许多大公司都有的大公司病，后续如何善待 Github 还真不好说，让我们静静期待在微软统领下的 Github 的更多的变化吧。总之，恭喜微软喜当爹，也恭喜 Github 嫁入豪门~~~~~

今日，GitHub 宣布与 Facebook 合作推出了 Atom-IDE —— 它包括一系列将类 IDE 功能带到 Atom 的可选工具包。初次发布的版本包括更智能、感知上下文的自动补全；导航功能，如大纲视图和 goto-definition，以及其他有用的功能；还包括错误、警告提醒和格式化文档功能。查看 Atom 博客以了解更多。Atom-IDE 包括适用于 C#, Flow, Java, JavaScript, PHP, 和 TypeScript 语言的软件包，它们通过使用语言服务器的强大功能为你的代码和项目提供深度的语法分析。在社区的支持下，GitHub 还计划要扩展 Atom-IDE 可支持的语言数量，并可以运行和编辑应用程序，使用 Atom-IDE 成为一个真正的 IDE。