晓查 发自 凹非寺量子位 报道 | 公众号 QbitAIVS Code现在居然可以用来谈恋爱了。为了用最硬核的方式找到男（女）朋友，23岁的程序员Ben Awad在VS Code里打造一个约会软件VSinder。顾名思义，VSinder = VS Code + Tinder，就是把约会软件集成到了代码编辑器里，简直太对程序员胃口了。VSinder和Tinder的操作逻辑一样，左滑把不喜欢的人pass掉，右滑收藏喜欢的人。这款插件一上线，就快速赢得程序员们的认可，GitHub上已收获800 Star，3天的下载量超过9000次。从代码中找到真爱既然是面向程序员的约会软件，自然不能和其他约会App一样，一定要有特色。VSinder的特点就是，可以根据编程语言和代码风格筛选对象。比如你用的是Python，她用的是C，那么你们之间可能没有共同语言。（以免将来为哪种语言最好吵架。）对方使用的语言会在人名旁边用一个logo展示出来。当然，即使用同一种语言编程，水平也有高下，如果对方编程水平达不到自己的要求怎么办？别怕，VSinder和只看脸的约会软件不同，它是靠代码吸引异性的。（毕竟代码才是程序员的脸面。）Code Pics一栏填入你最得意的代码，让对方一眼知道你的水平深浅。VSinder也考虑到性取向问题，你也可以选择约会对象的性别。又或者是你只想找个一起交流代码的同性朋友，只需在程序中选择friendship。当然，找对象，脸也是很重要的。VSinder暂不支持手动修改头像，而是自动抓取你的GitHub账户，如果想让自己帅（美）一点，只能去修改GitHub头像了。还有手机App既然是约会软件，怎么可以只在电脑上运行呢？虽然手机不能跑VS Code，但是Ben还开发了VSinder的手机App供下载。现已经支持iOS和Android两大系统。只需登上自己的GitHub账号，完善资料即可使用，和Tinder用起来没啥太大区别，除了没有大量美颜照片。那么这三天来，有没有人在VSinder上找到男（女）朋友？恐怕是没有，有人滑了半个小时，也没有找到一个单身女程序员。不过这种情况也不难预料，毕竟GitHub是“全球最大的同**友社区”。开源地址：https://github.com/benawad/vsinder插件下载地址：https://marketplace.visualstudio.com/items?itemName=benawad.vsinder使用方法介绍：https://www.youtube.com/watch?v=bfd8RyAJh6c—完—量子位年度AI峰会「MEET 2021智能未来大会」定档12.16❤ 李开复博士、尹浩院士、清华唐杰教授，以及来自小米、美团、爱奇艺、小冰、亚信、浪潮、容联、澎思、地平线、G7等知名AI大厂的大咖嘉宾将出席并带来主题演讲。欢迎关注人工智能、前沿科技的小伙伴们报名参会、共探新形势下智能产业发展之路。点击链接锁定席位：量子位MEET 2021智能未来大会www.huodongxing.com——转自知乎/量子位

如题，ModelArts连接github超时导致无法加载预训练权重，想问一下有什么办法能解决？

本次实战营就5个PartMindSpore21天实战营Part1实战笔记——使用MindSpore Lite实现移动端图像分类 https://bbs.huaweicloud.com/forum/thread-85571-1-1.html MindSpore21天实战营Part2实战笔记——使用MindSpore和ModelArts实现Bert中文新闻分类（未完成）https://bbs.huaweicloud.com/forum/thread-86316-1-1.html MindSpore21天实战营Part3实战笔记——使用MindSpore实现Resnet50毒蘑菇识别 https://bbs.huaweicloud.com/forum/thread-86319-1-1.html MindSpore21天实战营Part4实战笔记——使用ModelArts实现YoloV3-DarkNet50篮球检测模型 https://bbs.huaweicloud.com/forum/thread-86369-1-1.html 今天终于迎来了张小白的最后1Part 这次的实验要求是需要到 https://github.com/mindspore-ai/mindspore-21-days-tutorials/tree/main/chapter5 代码仓去取。不过因为众所周知的原因，github不是你想连就能连的：虽然你也能慢速地将其下载下来：（每秒30K的速度）有时候配图就会挂了。。但是总要有解决方案的吧。。目前一个好的办法是：你在gitee.com上导入github的代码仓。你需要到github找到相关的代码仓的位置：将https的地址复制下来：https://github.com/mindspore-ai/mindspore-21-days-tutorials.git然后在gitee导入仓库的界面导入就可以了。好了，下面的文档都在gitee上看，也不会有速度慢，或者图挂掉的问题了。。（未完待续）

实际体验的好处是可以这碰碰，那撞撞，盲人摸象般探测边界在哪儿~昨天看了【操作指南系列】CloudIDE实例中导入Git代码库，今天才try了一下！有了夜读成才的教程，超级顺利~连许久不用的github密码居然一次就蒙对了~23333在github上改了下代码，嗯，没有自动同步到cloudIDE中。再重新import一下，文件夹重名，提示错误。改个文件名，第二次拉取下来。在Cloud IDE修改代码，然后上送git,一直报错鉴权失败，是啊，没有保存github的用户名和密码，这就需要用SSH方式连接github了。密码复制的问题：昨天确实发现代码粘贴不出来，是上面编辑框的代码粘贴不到本地，但是terminal中的文本一直是可以粘贴到剪辑板再到本地的。这里的密码不用使用手册上说的xclip -sel clip < ~/.ssh/id_rsa.pub直接能复制出来就可以了。感觉CloudIDE有点像vmware虚拟机的使用，但VM虚拟机安装了插件后，是可以在虚机和本端自由复制的。

上回说到（一），这回接着说。3.YOLOV3相关代码3.1 python代码代码地址：https://github.com/ultralytics/Yolov33.2 C++代码这里推荐YOLOv4作者的darknetAB代码，代码和原始作者代码相比，进行了很多的优化，如需要运行YOLOv3网络，加载cfg时，使用YOLOv3.cfg即可代码地址：https://github.com/AlexeyAB/darknet3.3 python版本的Tensorrt代码除了算法研究外，实际项目中还需要将算法落地部署到工程上使用，比如GPU服务器使用时还需要对模型进行tensorrt加速。（1）Tensort中的加速案例强烈推荐tensort软件中，自带的YOLOv3加速案例，路径位于tensorrt解压文件夹的TensortX/samples/python/Yolov3_onnx中针对案例中的代码，如果有不明白的，也可参照下方文章上的详细说明：代码地址：https://www.cnblogs.com/shouhuxianjian/p/10550262.html（2）Github上的tensorrt加速除了tensorrt软件中的代码， github上也有其他作者的开源代码代码地址：https://github.com/lewes6369/TensorRT-Yolov33.4 C++版本的Tensorrt代码项目的工程部署上，如果使用C++版本进行Tensorrt加速，一方面可以参照Alexey的github代码，另一方面也可以参照下面其他作者的开源代码代码地址：https://github.com/wang-xinyu/tensorrtx/tree/master/Yolov3

在课件中，有GitHub的链接，西北地区有什么办法可以打开GitHub吗？

主机可以访问github.com。但是在虚拟机和docker中无法访问。网上查询到github的IP为192.30.255.113。也无法ping通查询到解决办法，在在hosts里面加这些东西加了之后，依然无法ping通最后查询到github的ip有更改，更改为了140.82.112.3在ubuntu中做如下操作sudo vi /etc/hosts加上一行140.82.112.3 github.com如下图所示问题解决。

【功能模块】200DK【操作步骤&问题现象】之前我们在Atlas300上运行过 离线视频 推理的sample code： https://github.com/huaweiatlas/samples  现在我们要在Atlas200Dk上运行该 sample，编译成功后，发现运行时 有报如下错误，提示 aclrtMallocHost（）之类的api不支持，请问如何才能跑通 该离线视频 推理程序？【截图信息】【日志信息】（可选，上传日志内容或者附件）[EVENT] DRV(20010,main):2020-09-25-07:40:07.896.046 [hardware/npu_inc/../dev_core/devdrv/devdrv_command.c:192][devdrv] [drvDfxShowReport 192] devid: 0, cq_index: 1, index: 35, slot phase: 0, streamID: 0, taskID: 0.[EVENT] DRV(20010,main):2020-09-25-07:40:07.896.081 [hardware/npu_inc/../dev_core/devdrv/devdrv_command.c:192][devdrv] [drvDfxShowReport 192] devid: 0, cq_index: 1, index: 36, slot phase: 0, streamID: 0, taskID: 0.[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:07.989.971 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:08.990.842 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:09.989.521 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:10.989.346 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:11.990.640 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:12.991.259 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:13.990.494 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:14.989.327 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:15.989.430 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:16.991.130 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"[ERROR] ASCENDCL(20010,main):2020-09-25-07:40:17.990.589 [acl/runtime/memory.cpp:98]20021 aclrtMallocHost:acl/runtime/memory.cpp:98: "current app is not support on device side"

近日，GitHub宣布，自2020年10月1日起，在GitHub平台上创建的所有源代码存储库都将默认命名为 main ，而非原本的 master 。这一变化是什么原因？具体又是怎样的变化呢？接下来为你一一解答。替换 master 等术语，开源项目在行动！今年6月12日，谷歌浏览器开发人员 Una Kravets 的一条 Twitter 火了，内容是建议 GitHub 用 main 之类的中性术语替换 master ，并解释了提出这个建议的原因：main 更短，简洁明了；容易被人记住；会让我的队友们感到舒适；不会让黑人在科技界感到被歧视；GitHub 的 CEO 对此回应到：“提议非常好，我们已经在执行了。”外媒 ZDNet 曾表示：继续使用带有种族色彩的词汇可能会加深种族歧视，这实在令人担忧。一些学者也认为：这些术语不仅反映了种族主义文化，而且还强化、合法化和延续了它。”因为美国 “Black Lives Matter” 运动愈演愈烈，技术界再次掀起了在源码、软件应用开发中删除此类词汇的浪潮。因此 GitHub 于今年6月表示，公司正在努力以 main 之类的中性术语替换 master 一词，以避免不必要的联想到奴隶制。具体的更换有：master 和 slave 将被替换为 main/default/primary 和 secondary，whitelist 和 blacklist 则将被替换为 allow list 和 deny/exclude list 。 除了 GitHub ， Android 移动操作系统、 Go 编程语言， PHPUnit 和 Curl 等都已表示打算用中性词汇替换掉 blacklist/whitelist 。同样，OpenZFS 文件存储管理器也用合适的词语替换了原用于描述存储环境之间关系的 master/slave 术语。与此同时，一些业界知名的开源项目也将其默认 Git 存储库的名称从 master 更改为 main、default、primary、root 等替代名称。不过，值得注意的是，开源项目的名称修改也并非想象中那么简单。在今年6月，React Refresh Webpack Plugin 的开发者迅速将 master 改成 main ，却被一个程序员吐槽：因为在 Git 上下文中，单词 master 的用法与 master/slave 不同，导致所有程序都改变了，最后项目都崩了。由此可见，修改存储库默认分支的名称并非一朝一夕的事，需要循序渐进。这正如同近日 GitHub 官宣的内容：将从10月1日起用 main 代替 master ，但将分阶段进行。GitHub 用 main 取代 master 举措落地，开发者最关心的事情在这里GitHub 以及庞大的 Git 社区都在考虑重命名源代码存储库的默认分支名称，而GitHub 选择用 main 取代 master ，来作为自己存储库的默认分支名称，并将分为几个阶段进行更改，以尽可能减少对现有项目的破坏。GitHub 建议用户：如果您尚未重命名默认分支，可以考虑等到今年年底。我们正在投资开发工具，用来重命名现有存储库的默认分支，从而给维护者和贡献者提供无缝的体验。以下是 GitHub 就此宣布的一些注意事项：已更改部分已更新 GitHub.com ：将包含已删除的分支名称的原版链接重定向到存储库新默认分支中的相应链接；已更新 GitHub Pages ：可以从任何分支构建和部署；注意：发布到特殊的 gh-pages 分支仍可以像以前一样工作，但是现在可以选择存储库中的其他任何分支作为发布源。添加了用户，组织和企业设置：为 GitHub.com 上所有新创建的存储库设置默认分支名称。这些设置涵盖通过 GitHub.com 和 GitHub API 创建的存储库。Git 2.28 添加了类似的设置来控制在命令行上运行 git init 时使用的默认分支。在 Git 2.28 博客文章中可以了解更多有关新的 init.defaultBranch 的设置信息。GitHub Desktop 还将在本月晚些时候为新存储库引入默认分支设置。2020年10月1日：新创建的存储库都将默认为main自2020年10月1日起，新创建的存储库都将使用 main 作为默认分支，而不是原本的 master 。但此更改不会影响任何现有存储库：现有存储库将继续保留与之前相同的默认分支。但此更改可以随时选择退出，通过以下对应网址，可为用户，组织或企业的新存储库设置默认分支：对于用户，请访问 https://github.com/settings/repositories对于组织所有者，请访问 https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults对于企业管理员，请访问 https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges为什么选择用 main 替代？main 是在 GitHub 上看到的最受欢迎的 master 替代词。并且 main 这个词汇很短，可以让用户形成良好的肌肉记忆；在很多种语言中翻译起来也很容易。GitHub 目前正将 main 用于新创建的存储库以及正在迁移的存储库，例如 dependabot-core。今年年底：无缝迁移现有存储库重命名默认分支肯定会对现有存储库带来很多麻烦：打开拉请求需要重新定位到新分支草案发布需要重新定位到新分支分支机构保护策略需要转移到新分支机构今年年底之前，GitHub 将使现有存储库全部无缝重命名其默认分支。当重命名分支机构后，GitHub 会重新定位未完成的PR和草稿版本、移动分支机构的保护政策等等——全部都将自动执行。并且，GitHub 还正在考虑将 git fetch 或 git clone 旧分支名称的用户重定向到新分支名称（带有警告和说明以更新其本地克隆）。对这一举动的思考其实关于计算机术语的政治正确性并不是近几年才出现的话题，GitHub 在公众的督促下换掉 master 也不是首当其冲。早在2004年，master/slave 就曾被全球语言检测机构评为年度最不政治正确的十大词汇之一，只是当时的软件开发和网络发展并没有如今这么发达，所以更换术语这类事就全靠自发。比如，2008年，开源软件 Drupal 宣布将 master/slave 重命名为 client/server ，理由是在有更好的替代方案时，继续使用冒犯性术语很不合时宜。之后一直到2018年，IETF 在草案当中，提出开源软件需要更改 master/slave 和 blacklist/whitelist 两项表述，计算机术语的使用才引起了广泛的关注。因此同年，许多开发者就开始呼吁 Redis、谷歌、Python 这些开源软件厂商修改相关术语。但其实反对的声音也一直很多。其中最重要的两个理由是：计算机源码中的 master、blacklist 等词语，并不包含种族色彩；更改的成本太大。事实上那些倡议者们所追求的，并非完全不能使用“black”这个词，而是呼吁不要把“biack”作为“white”的对立面，传达出“不好”、“需要被限制”等这些负面含义。所以，当 master/slave出现在代码中，表达的又恰好是“主-从”关系，就难免让人想到奴隶制。可是，究其根本，在计算机术语中的master、blacklist等词语，本身并不包含负面和歧视的意思，却因为误解而花费巨大成本修改术语，是否会有些许过犹不及的意味呢？ 参考链接https://baijiahao.baidu.com/s?id=1669620192902455480&wfr=spider&for=pchttps://www.sohu.com/a/405073858_478315https://www.jiangweishan.com/article/hulianwang0234098230948.html转载链接：https://blog.csdn.net/csdnnews/article/details/108765157

【功能模块】【操作步骤&问题现象】1、从github上下载的文件，ls有2、图形化操作界面没了【截图信息】【日志信息】（可选，上传日志内容或者附件）

一、评价指标基本概念评价指标是针对模型性能优劣的一个定量指标。一种评价指标只能反映模型一部分性能，如果选择的评价指标不合理，那么可能会得出错误的结论，故而应该针对具体的数据、模型选取不同的的评价指标。本文将详细的介绍一下在教程中的图片分类项目为什么要用准确率(Accuracy)来作为评价指标。使用准确率(Accuracy)的时候，数据需要满足那些条件。二、混淆矩阵我们从混淆矩阵开始，引出我们所要讲述的评价指标。图1-混淆矩阵TP、FN、FP、TN的解释：（1）若一个实例是正类，并且被预测为正类，即为真正类TP(True Positive )（2）若一个实例是正类，但是被预测为负类，即为假负类FN(False Negative )（3）若一个实例是负类，但是被预测为正类，即为假正类FP(False Positive )（4）若一个实例是负类，并且被预测为负类，即为真负类TN(True Negative )三、准确率那么准确率所表示的意义是什么呢？预测正确的样本数量占样本总数量的百分比，让我们结合混淆矩阵用公式来表示它图2-准确率首先我们分析一下这个公式：分母表示的是样本总量，分子表示的是在正负样本中被预测正确的。然后我们可以分析一下我们图片分类中所使用的数据，一共有6万张图片，运行程序后的结果是将这6万张图片分为了10个类别，统计可得出每一个类别的图片数量大致相等。所以对于这样样本均衡的数据集使用准确率是没有什么问题的。接下来，我们假设有一个10000张男性和女性的图片，其中男性图片9900张，女性图片100张，我们创建了一个模型只会把所有图片都分为男性那一类，我们用准确率去衡量这个模型的性能，哇！！！惊人的99%。这个模型堪称完美。但是显然这个模型太大男子主义了，没有把女性当回事。我们来总结一下准确率的优缺点：优点：公式高效简单，易于理解；缺点：使用场景受限，只有在样本数据集均衡的情况下才能较为准确的评测一个模型。所以在对于正负样本不均衡的数据集，准确率的公式就不能够准确评价一个模型的优劣了。那么，有没有哪一个标准即使在数据集类别不均衡的时候也能准确衡量模型的性能呢？这绝对是当然的有啊！！！四、ROC曲线和AUC值我们再欣赏两个公式：图3-真正率和假正率仔细看这两个公式，发现其实TPRate就是TP除以TP所在的列，FPRate就是FP除以FP所在的列，二者意义如下：TPRate的意义是所有真实类别为1的样本中，预测类别为1的比例。FPRate的意义是所有真实类别为0的样本中，预测类别为1的比例。按照定义，AUC即ROC曲线下的面积，而ROC曲线的横轴是FPRate，纵轴是TPRate，当二者相等时，即y=x，如下图:图4-ROC曲线表示的意义是：对于不论真实类别是1还是0的样本，分类器预测为1的概率是相等的。而我们希望分类器达到的效果是：对于真实类别为1的样本，分类器预测为1的概率（即TPRate），要大于真实类别为0而预测类别为1的概率（即FPRate），即y＞x，因此大部分的ROC曲线长成下面这个样子,举一个简单的例子：图5-数据预测表图6-数据混淆矩阵进而算得TPRate=3/4，FPRate=2/4，得到ROC曲线：图7-数据ROC曲线最终得到AUC为0.625。最理想的情况下，既没有真实类别为1而错分为0的样本——TPRate一直为1，也没有真实类别为0而错分为1的样本——FP rate一直为0，AUC为1，这便是AUC的极大值。此时，我们再看上面举的例子，假设有一个10000张男性和女性的图片，其中男性图片9900张，女性图片100张，我们创建了一个模型只会把所有图片都分为男性那一类，那么用AUC指标评测时，TPRate=9900/(9900+0)=1，FPRate=100/(0+100)=1，AUC=0.5，因此极大的改善了一盖而全的情况。五、总结我们通过上面的分析，对于准确率这个指标，在简单高效易于计算的同时，也受到样本数据类别是否均衡的限制，不同分类样本数量均衡时，准确率可以很好的衡量训练后模型的优劣，但在样本数量不均衡时，便会有些不相符。所以我也介绍了另一种指标AUC，首先我们通过真正率和假正率来组成一个坐标系，然后通过真正率和假正率的计算绘制出ROC曲线，最后AUC的值便是ROC曲线与坐标轴围成的面积。此方法中充分考虑了每一个类别的分类情况。所以能够更全面的表示分类模型的性能。以上是本人的一些见解，欢迎大家指正讨论！

摘自 https://www.oschina.net/news/117545/openjdk-github-migration 局长 发布于 2020年07月29日OpenJDK 项目正在从 Mercurial 迁移到 GitHub，预计在2020年9月完成。切换至 Git 代码版本控制系统的部分预期目的是提升性能和对代码审查的更好支持。OpenJDK 从 2008 年起一直使用 Mercurial 作为源代码管理解决方案，用于存储代码并进行代码审查。如今部分 OpenJDK 项目（如 Loom、Valhalla 和 JMC）已完全从 Mercurial 迁移至 GitHub，还有部分项目例如 JDK 本身正在迁移中，对于这些项目，其仓库已托管在 GitHub 上，但目前仍是只读副本。到 9 月份 GitHub 成为正式的读写主仓库时，JDK 项目将加入其中。OpenJDK 在 2018 年开始评估 Mercurial 在源代码管理方面的可能替代方案，当时还定义了一系列评估标准，宗旨是“提升所有贡献者（无论是新贡献者还是现有贡献者）的生产力”：性能：从主仓库进行克隆操作的时间、本地操作的时间等空间效率在不同地区的可用性支持常见的开发环境，例如 Linux, Mac 和 Windows能够轻松托管 JDK 的整个历史项目文件和未来十年基于其历史的预计增长支持通用的 JDK 代码审查实践提供程序化 API，以实现流程协助以及审查和流程的自动化尽管现有的 OpenJDK 开发者熟悉 Mercurial 以及存在一定的迁移成本，但最后还是决定将 OpenJDK 迁移至 GitHub，原因是看中了 GitHub 的性能、丰富的 API 和日渐扩大的社区环境。查看此 JEP(JEP 369: Migrate to GitHub) 了解迁移至 GitHub 的详细原因。

您好，我要下载  https://github.com/Ascend/sdk-presenter/releases/download/1.1.2/presenteragent-1.1.2.zip和 https://github.com/Ascend/sdk-ezdvpp/archive/1.1.0.tar.gz这两个包，但是页面好像是空的，现在到哪去下载呢？

作者：Nick Kolakowski原文地址：https://insights.dice.com/2020/05/07/github-shows-covid-19-shifting-developer-workflows/GitHub的一份新报告显示，2019年冠状病毒的流行正在影响开发人员的工作流程。GitHub的数据科学团队分析了这家大型网站的活动数据，发现与去年同期相比，2020年前三个月的开发者活动“基本保持一致或有所增加”。尽管保持了相当的工作速度，但是很明显，全世界的开发人员(和公司)都被封锁了。“我们的分析显示，企业资源库中的GitHub issues 数量在COVID-19疫情爆发和居家隔离令下达期间起起落落，”报告中写道。在issues 中看到的变化可能是由于改为分布式的工作方式后，打乱了企业软件开发的仪式、结构和协调。在GitHub上，这种协调通常是与issues一起完成的，团队可以跟踪强化(enhancements)、任务和bug。” 对于许多开发人员来说，工作的实际节奏已经发生了很大的变化。“开发人员的工作时间每天都延长了一个小时，工作日和周末都是如此。更长的工作时间也可能是由于非工作干扰(如家庭或育儿)，因为现在许多人在家工作。”报告补充说。 除非技术专家密切关注他们的工作负荷和日程安排，否则很容易导致精力枯竭:“如果额外的工作是以牺牲用于充电、思考和维持健康的个人时间和休息时间，我们得小心这种权衡可能在长期内是不可持续的。”从这个意义上说，GitHub的发现与Blind公司最近的一项调查相吻合。该调查发现，截至4月底，73%的技术人员感到精疲力竭，远高于2月中旬的61%。在Blind的调查中，约20.5%的受访者表示，他们的工作倦怠源于难以管理的工作量，略高于19%的人因担心工作不稳定而产生的倦怠感。在家工作和精力枯竭之间的联系并不新鲜:去年，DigitalOcean公司的一项调查发现，在家工作的技术人员中，有66%精疲力竭，而定期到办公室工作的技术人员中，这一比例为64%。但2019冠状病毒大流行改变了这只野兽的本性;那些担心自己工作不稳定的技术人员可能会觉得有必要延长工作时间，甚至那些日程安排和工作量固定的人也会发现自己承受着来自家庭和流行病相关事件的额外压力。GitHub的报告直接指出，在经济环境越来越不确定的情况下，开发人员面临的压力。“这一分析表明，对于这些用户来说，他们工作的时间更长，做的开发工作也更多，尤其是在3月份，”报告中写道。”这些开发人员可能会感到更多的压力，从而增加工作量，这主要由于几个因素: 经济不确定性、做好工作并稳定工作的欲望、用工作消遣被困家中的无聊感、 由于产品上市管理层所给与的压力、以及来自于团队规范的推动，这些规范是为了保证快速稳定的产品交付节奏而制定的。”GitHub还在危机初期做了数据快照，当时(至少在美国)企业和各州才刚刚开始锁定并命令员工在家办公。随着企业适应“新常态”，该网站的数据在未来两个季度将如何变化，将是一件有趣的事情。如果你是一名开发人员(或有兴趣成为一名开发人员)，这也是通过在线课程提高技能的好时机。