=Father(x)) //这条代码-----其实我定义的是个数组，然而我却用错了括号【】我用了（）, //D:\Microsoft Visual Studio\MyProjects\1...之后我将Father（）-----》Father[]就好了！！，为防止以后再出现这样的错误，特将次单独笔记一下！！
使用Junit测试一个spring静态工厂实例化bean的例子，所有代码都没有问题，但是出现 java.lang.IllegalArgumentException 异常， 如下图所示： ?...开始以为是代码写错了，找来找去，代码没有问题，原来是JDK版本过高，修改项目的JDK版本，把版本从1.8 降为1.7，如下图所示： ? 测试，成功，如下图所示： ?
在之前的真香系列之2-自动录制回放的Hoverfly-java-Junit5 一文中，笔者有提到一个问题，Hoverfly-java-junit5不提供增量录制的问题。...在Junit4中，可以这样使用Hoverfly....这个易用性的问题给笔者在公司推广Hoverfly造成了一定的困难。为此，笔者还专门提了一个issue。...笔者大约一个月前提的Issue，到现在没有任何的回复。再观察一下，发现最近一个合并代码是2020年的最后一天。。。...本着谁提意见谁解决的优良传统，笔者自己参照Hoverfly-java的解决方案，给hoverfly-java-junit5同样增加了这个功能，并且提了一个PR feat: add enableIncrementalCapture
一、背景 技术群里有朋友问了一个比较常见的问题：“提交代码的时候描述有什么规定嘛”？ 对于这个问题，相信大多数人都认为 too simple。 描述一下这次改了什么内容不就好了吗？...一般来说，一个好的提交信息应该包括一个类型（比如 feat, fix, docs 等），一个可选的范围（比如 player, login 等），一个简洁明了的描述，以及一个可选的正文和页脚（比如包含更多细节或引用其他资源...以终为始，提交的 message 给谁看？在什么时候看？ 通常我们会在阅读代码时，发现这段代码有些困惑，不清楚是干啥的，就会看提交描述来帮助理解。...通常我们发现某段代码有 BUG，需要找人背锅的时候，需要看下提交信息。 通常我们代码审查的时候会去看该同学有几次提交，分别是实现什么功能。 2.3 怎么写？...通常就写新增什么功能；优化了功能；修复了什么问题；删除了什么等。
本文开头的第一个代码片段是我之前提交的提交记录，现在来看的话，我已经不知道我写了什么？...提交信息和代码一样，不只是给自己看，也是给团队中其他人看的，同时也是对提交信息的注释。在我过往经历中，看到过很多小伙伴为了方便随便写提交信息。修复一个登陆问题，提交信息却只写了Fix bug。...这就导致了对于代码的回溯和问题排查十分困难，时间久了甚至只能一个一个Commit的排查。要记住一点：提交信息不只是给自己看的，也是给团队看的。...示例 使用 实现单点登陆接口 替代 实现新功能 有个小建议，大家可以在提交代码的时候，如果实在是想不到，可以直接使用需求描述作为提交信息。...Feat: 新功能 Upgrade：功能升级或代码变更 Fix: Bug修复 Doc: 文档或README编写 Style: 主题UI变更 Test：新增测试代码 示例 使用 Feat：实现单点登陆接口
开篇 在团队中代码提交（git commit）会有各种各样的风格，甚至有些人根本没有 commit 规范的概念，所以在我们回头去查找在哪个版本出现问题的时候，就会非常尴尬?，很难快速定位到问题。...下面是我做的代码提交规范插件 vue-cli-plugin-commitlint（对 conventional-changelog-angular 进行了修改/封装）。开箱即用！...:(xxx): xxx' npm run log # 生成 CHANGELOG 代码提交 npm run cz 选择一个类型会自动询问 (非必填）本次提交的改变所影响的范围 (必填）写一个简短的变化描述...改变构建流程、或者增加依赖库、工具等 feat 新增 feature fix 修复 bug merge 合并分支 perf 优化相关，比如提升性能、体验 refactor 代码重构，没有加新功能或者修复...bug revert 回滚到上一个版本 style 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑 test 测试用例，包括单元测试、集成测试等 总结 目前我有好几个项目都在使用这套规范 项目地址
每次数学建模看周老师写的东西都觉得自己很菜，老师可以在课堂上信手拈来一段仿真代码，也可以使用LaTeX绘出让我目瞪口呆的动图，我很少有崇拜他人的时候，所以我什么时候才能和周佬一样，可能就像老师说的，你每天写
我们为什么写不好单元测试 写不好单元测试的情况有很多，很多时候我们也是被需求压着身不由己的就开始 “ 胡编乱写” 了。...及早发现软件缺陷 问题是在早期阶段发现的。由于单元测试是由在集成之前测试单个代码的开发人员执行的，因此可以很早就发现问题，并且可以在不影响其他代码的情况下解决问题。...当然，较早检测到的bug更容易修复，因为稍后检测到的bug通常是许多更改的结果，并且您不知道是哪一个导致了bug。 如何写单元测试 上面讲了这么多啰里啰嗦的问题，那我们应该怎么写呢？...或许当时写代码的时候确实可以用，但是如何检验正确性呢？如果重构的时候，如何发现已经和原来的行为不一致了呢？ 使用 JUnit5 来进行简单的测试 What is JUnit 5?...单元测试图片 自动生成的代码如下（如果你熟悉了就可以自己手写，但是 IDEA 能生成，我就不手写了），被标记 @Test 的方法可以单独测试执行，如果你在 IDEA 上可以看到侧边栏有绿色的带箭头的小圆圈
认识开源协议假如你想自己的项目成为开源仓库，在建仓填写完基础信息后的第一步就是选择开源协议，对于经常写业务代码的我不禁要问：什么是开源协议？ 开源协议是一种明确软件使用、修改和分发权利的规则。...看了这些还是有些迷糊，其实可以考虑在某代码仓库平台上的平台用开源协议向导尝试理解一下：认识项目每个公司有每个公司的流程，同样的每个开源项目也有。无论是想使用开源项目，还是扩展，请先对项目有一定认知。...对于 commit 来说比较通用的 type 类型：test 增加缺失的测试feat 新功能 功能分支一般是feature + 编号fix 问题修复chore 构建过程或辅助工具更改docs 文档更改代码审查流程也很关键每个项目都有一套自己的代码审查机制...比如像后端可能会有 check style 的规范，JUnit 单元测试的需求。2. 与项目社区建立联系如果是大型的开源，一般会有自己的网站，留有交流群或管理者的联系邮箱。...如果只是小问题，可以到issue中去提问。对于小型的项目，可能不够全面，但直接到 issue 去提问也是没什么问题的。提交第一个贡献首先明确什么是贡献。Bug 修复、文档构建或者最佳实践都可以是贡献。
前言 大厂有着数量庞大的代码库以及复杂的权限验证体系，囊括着开发、测试、上线的完整流程。因此必然会有一套代码仓库的管理流程，而不再是个人的代码随意开发、随意提交。...这个时候我们就有了三个仓库，分别是: 线上仓库(发布项目的git仓库，一般是拥有者是团队或TL) 自己仓库(自己fork线上仓库到自己的github) vscode本地仓库(git还在本地有一个仓库)...git-5.png 我把以前写的一篇二叉树相关的文章添加到头条大佬Book中，接着进行commit, commit的内容也应该遵守规范，一般来说是 fix:xx 表示修改了XX代码 feat:xx 新增了...git-7.png 在合并之前我们需要做codereview, 在我们小组所有进行合并的代码必须要进行codereview并且每一个组员都可以参加，codereview是让自己进行提升以及帮助别人纠错的一个重要途径...这样就完成了一次完整的 PR hotfix 有些时候产品会要求紧急上线一个需求，这个时候需要在线上的代码更新，因此我们会从线上分支切一个分支到自己仓库，然后在这个分支上进行修改，修改完以后会提两个PR
在我们部门里，我自己也是一个tech leader的角色，也带着两个项目在身上，我的项目可以说是部门的number one了，我们有自动化构建，部署，和部分自动化测试，在我收集的过程当中，有几个项目也说自己也都做好了自动化构建和部署...开发人员提交代码后是否能得到快速反馈？即是否会运行JUnit去验证代码的正确性，部署后是否会运行E2E测试去验证代码的正确性. 敏捷的一个重要价值观就是持续反馈，但是怎么样实现呢？...在TDD时候，我们是强调先写测试才写代码，但我们知道这样比较难行，因为太少公司能做到这样了，不过我们就因此不写JUnit了吗？不，我们要写，我们不得不写，但写多少呢？...用同一个二进制包进行部署，我相信开发人员对这个深有体会，很多时候我们会遇到这样一个问题，明明在本地可以的呀，为什么上到SIT就不行了, SIT还是可以的呀，UAT怎么可能出问题呢？...当在部署的时候，DEV是不可用的，测试人员是在SIT测试的，所以为了保持稳定的环境，我们会对SIT进行手动控制。
有句话说我们写代码90%的时间在改bug，另外10%的时间在写新的bug。这句话虽然有点夸张，但是也能说明改bug确实占用了非常多的时候。既然单元测试能减少bug，自然也能节约时间。...重构的时候，大大提高重构的正确性，减少手工测试的时间。 所以，我希望大家能去掉”没时间写单元测试”这个印象，如果工作上安排太紧。...首先澄清一下概念，在安卓上面写“测试”，有很多技术方案。...2.2 单元测试的定义 单元测试的定义相信大家都知道，就是为我们写的某一个代码单元（比如说一个方法）写的测试代码。...然而等你熟悉写测试的方法以后，强烈建议先写测试！因为如果你先写了正式代码，那你对这写代码是如何work的已经有一个印象了，因此你往往会写出能顺利通过的测试，而忽略一些会让测试不通过的情况。
在比赛进行的过程中，我在天池进行了一次如何调参上分[6]的直播分享。 直播对应的代码可以在我们的《动手学CV项目》[7]的2.5节找到。...这份代码我相信是帮到了一些刚入门的同学的，提交的成绩大概在0.75分左右。...关于这部分，这位小伙伴写的比赛实验记录[8]对相关的实验进行了很详细的记录，大家感兴趣可以阅读一下~ 1.4 和文本长度相关的探索 baseline方案将识别问题转化为了定长识别问题，那么定多长合适？...具体地，体现在测试集最终的分数反而要比验证集高一些，如果你直接观察数据，也可以看出来，测试集的图片中字符在图片中的占比更大，而训练集中图片的字符占比更小。...可以有很多方案来达到这个目的，最简单有效的方法仅仅需要修改数据增强相关的6行代码，我用TODO作为后缀标注出来，代码如下： train_loader = torch.utils.data.DataLoader
这次只记录我在实验中遇到的情况和略懂的几点，多余的我没有怎么看【笑哭】，一个是因为懒，一个是因为官网介绍页太少了8，有点心塞~~ 开门见山，关于Tensorflow读取数据，官网给出了三种方法，分别是...： 1.供给数据(Feeding)： 在TensorFlow程序训练或者测试的每一个epoch，在tf.Session().run()函数中，以字典的形式通过feed_dict参数进行赋值。...（好像并没有开门见山，尴尬脸） TFRecords是一种二进制文件，这个格式我真的理解无能，据说它不对数据进行压缩,所以可以被快速加载到内存中，要复制和移动的时候也是咻的一下就搞定，所以说人家作为内定格式是有原因的...我们可以写一段代码获取你的数据， 将数据填入到Example协议内存块(protocol buffer)，将协议内存块序列化为一个字符串， 并且通过tf.python_io.TFRecordWriter...但是需要注意的一个地方是，这两个函数都有一个参数是shape，除了字符串类型的特征在取的时候用tf.FixedLenFeature()不用指定要取的特征的shape,其余类型的特征在取的时候要标明取得shape
点击上方↑↑↑“OpenCV学堂”关注我 yolox 推理openvino与c++支持 YOLOX模型ONNX格式说明 我记得大概是在去年七月份的时候我写过一篇文章是介绍YOLOX+OpenVINO推理的...02 什么是8400 模型在数据输入端几乎与YOLOv5的代码一致，没有什么特别之处，唯一不同的在于输出层的解析，是把三个不同的输出层合并在一个里面了，分别是80x80, 40x40, 20x20, 每个特征点预测...OpenVINO推理解析 必须说明一点，参考了官方的部分代码，然后在上面猛改一通（原因是官方代码写的不是很好），改完之后，封装成一个类了，主要的方法跟我封装的YOLOv5的推理类相似，导出了两个函数方法...onnxruntime上面也一样可以，基本上重用了大部分的代码，然后把它们与我之前写YOLOv5+QT的演示整合了一下，这样就变成YOLOv5+YOLOx支持OpenVINO/ONNXRUNTIME全部可行的推理...6.1版本模型推理 OpenVINO2021.4+YOLOX目标检测模型部署测试 比YOLOv5还厉害的YOLOX来了，官方支持OpenVINO推理
组内知识分享 俗话说的好：你有一个苹果，我有一个苹果，我们交换一下，一个人还是只有一个苹果；你有一个思想，我有一个思想，我们交换一下，一人就有了两个思想。这句话同样适用于我们进行软件开发。...提前发现代码的问题 一些经验比较少的开发者在写代码的时候可能考虑问题不够全面，导致一些边缘情况(edge case)没有考虑到，这时候如果code reviewer是一个工作经验比较多的同学的话，就可以帮...作为committer，我们在提交代码的时候需要将改动控制在一个合理的范围，我个人的一个偏好是将改动的文件数控制在5个文件以内，将改动的代码行数控制在150行以内，这样的话reviewer就不需要花费太多时间来帮我们...带上必要的自动化测试 CR还有一个重要的作用就是确保committer在提交代码的时候带上必要的自动化测试，例如单元测试和e2e测试等。...但是我们又不能一点测试都不写，因此测试还是有很多作用的，例如可以帮助我们提前发现问题，好的单元测试还可以当做组件或者函数的文档使用，同时测试也可以帮我们更加高效地进行代码的重构。
原文链接： Git Commit Message 应该怎么写？ 最近被同事吐槽了，说我代码提交说明写的太差。其实都不用他吐槽，我自己心里也非常清楚。...毕竟很多时候犯懒，都是直接一个 -m "fix" 就提交上去了。 这样做是非常不好的，我也是自食恶果，深受其害。...bug 修复的代码改动； perf：优化代码以提高性能； test：增加测试或优化改善现有的测试； build：修改影响项目构建文件或外部依赖项，比如 npm、gulp、webpack、broccoli...如果两者在不同的发布，那么当前 commit，会出现在 Change log 的 Reverts 小标题下面。 最后来看一个例子，算是一个总结，至于具体内容还是要根据实际情况来填写。...可以根据提示信息直接写： 图片 也可以使用表单的方式，有选项可以选择： 图片 这样不仅可以很方便地写提交说明了，还可以使提交说明更加的规范。
当我们的代码库有很多人维护时，经常会出现代码风格不一致或者代码质量不过关，提交信息杂乱的情况，当然啦，即使是一个人的代码库，有的时候，自己写代码时不太注意细节，也会出现风格不一致的情况。...本文正是为了解决这个问题而生，阅读本篇文章并不需要很长时间，如果你的代码库还没有进行这些配置，正是你大展身手的好时机，武装一下你的代码库。 1....虽然，我们现在已经可以规范提交信息了，但是我们可能不喜欢默认的交互，例如，一个精简的描述就可以了，不希望再提示我去写详细的描述，那么就可以使用 cz-customizable 来进行定制。...这里我就不一一演示每个字段修改之后的情况了，根据字段的说明，建议如果想自定义提交规则，在本地进行修改验证，公司内部的代码库不需要管理 issue，另外，我不喜欢写长描述，所以我把 body 和 footer...，在一个代码库中，经常出现2个空格/4个空格混用，有些地方写 ;，有些不写 ;，风格不统一。
三、黑盒测试与白盒测试 3.1 黑盒测试 黑盒测试又称功能测试。它通过测试来检验程序是否能正常使用。在测试过程中，我们把程序看作为一个打不开的盒子，黑黑的什么也看不见，内部代码怎么写的也不知道。...上一步骤为什么需要把测试过的数据注释掉呢？ 答案来了，的确很麻烦，至于为什么注释掉，那是因为我们在写项目代码的时候，需要测试，不可能在同一个测试类测试这么多数据。...如果我们需要一个预期值呢？那么测试的结果不是我想要的预期值，而程序还是绿色的，证明程序没有问题怎么办呢？...有些聪明的小伙伴会说，我们可以把它提到类的里面与方法同级。对，这个处理方式也是一个正解。 但是我们在Junit单元测试中，有一个@Before注解，是用作资源的申请。...这时，我们在Junit单元测试中，有一个@After注解，是用作资源的关闭。也就是说被@After注解修饰的方法会在测试方法之后自定执行。
我在资源国际化的时候就发现了这个问题了。...还有个便捷查看值的方法：ALT+鼠标左键即可看到具体的值 这里写图片描述 Intellij idea使用Junit 之前使用idea做Junit测试的时候，都是一个一个方法来写，然后在方法名@Test这样测试...后来发现eclipse有直接把整个类的方法都可以抽取出来，自动生成Junit测试方法…于是在找Idea下有没有类似的功能…....这里写图片描述 解决：在项目中直接把对象的encoding.xml配置文件删除了就行了 这里写图片描述 使用Idea更新数据库表的数据 我们在做案例的时候，经常需要改变数据表中的数据来进行简单测试。...网上的教程很多，但是不是所有的教程都能成功的… 就只在IDEA上使用Git就用了我一个多小时了…哎呀。。。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
