在编译的时候有下面的警告提示： Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings CONFIGURE SUCCESSFUL in 14s   如何进行查看和操作？ 其实这是一个比较简单的问题。 上面的提示信息已经告诉你怎么运行了。 你可以运行命令 gradlew --warning-mode all 在输出中，你可以看到下面的信息 > Configure project : The compile configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 7.0. Please use the implementation configuration instead. Consult the upgrading guide for further information: https:// docs.gradle.org/6.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations at build_45djmc9u5bi478od1utks361r$_run_closure1$_closure8.doCall(C:\WorkDir\Ossez-Com\USData\Source-Code\covid-19\build.gradle:53) (Run with --stacktrace to get the full stack trace of this deprecation warning.) 上面的内容已经很明确的告诉你存在兼容性问题的地方在哪里。 根据提示的内容进行修改就可以了。   https://www.cwiki.us/display/GradleZH/questions/57938688

谭浩强的 C 语言在我们大学的时候是必学课程。 给我的阴影到现在还磨灭不了，学的第一门语言就是 C，后来一直用的 Java，感觉世界真好。后来发现这些人真是“大牛”呀，牛到写的东西是天书，一直到现在都不怎么碰 C 语言。 把对计算机的所有美好都磨灭殆尽了。   后来发现有这么多 API 其实可以用的，谁会去写那么难懂的 ++i，谁会去写那么复杂的 ++++。 C 语言里面比较重要的指针，说得特别难搞明白，特别晦涩难懂。但是 C 里面的指针却又是灵活性非常强的地方，工作后才知道 C 的指针，游标这些是非常容易出错，并且导致系统出问题，内存容易溢出的地方。但是这本书对这部分的内容明显显得不够。让学生知道了这个东西，但是没有告诉学生这个好东西怎么才能用好，别把自己突突了。 相对重要的文件读写，字符串处理，科学计算，等等又说简单潦草。   让 C 语言在我们大学里全面倒退到石器时代，这本书功不可没。   说白了，计算机语言就是工具，你需要用工具去解决问题罢了，有病才会用那么晦涩难懂的语句，你写不出来，别人也看不懂。在工作场所这样搞的话，相信大部分你的同事会冲你发飙的，不利于团结。因为你的代码你自己都看不明白。   其实特别不明白为什么大学要选用这本书，难道是装逼专用，还是老师害怕学生完成作业时间太短，防止大家沉溺于抖音？ 说实在的，与其花时间去了解这本书的这些东西，还不如搞搞算法。比如说我们学校选的一本离散数学和数据结构就非常好。 有关计算机数据结构，算法以及二叉树的内容基本上都在离散数学和数据结构这几本书上。 对学生的逻辑思维能力，算法演算能力，编程能力的帮助要远比这个号称印刷量最大的书靠谱得多。   现在想想估计可能是大学里面怕计算机教学计划不够吧。比如说一个学年的 Java 语言的话，真正 1 个星期说环境，2个星期说类型，2个星期说流程，2个星期说 API ，估计有 3 个月差不多就能写个小东西了。 再弄点框架，跑个 APP 不是问题。那么多教授，还有那么多课时咋办呀。  

有关构建扫描的定义为： 构建扫描（build scan）是一个中心化并且可以共享的构建记录。这个构建记录通常能够告诉在构建中发生了什么并且为什么会发生。 通过应用构建扫描插件到你的项目中，你可以将你的构建扫描发布到 https://scans.gradle.com 网站中，并且这个服务是免费的。 具体内容，请参考： Creating Build Scans 页面中的内容。 简单来说，你可以在你已有的构建中运行命令： gradlew build --scan 当提示需要发布的时候，这里需要输入 Yes 拷贝发布的链接到浏览器中进行访问： Publishing build scan... https://gradle.com/s/42nadqpqgayro 如果是第一次登陆的话，在界面中将会要求你输入你的邮箱地址，然后系统将会把信的链接发送到你邮箱中进行验证。 如果你已经验证过了。 那么你直接访问将会看到下面的界面了。 有不少的详细内容可以供你查看。 当然，你也可以将这个构建删除掉。 对于开放项目，这个功能提供了一个更好的协作和共享方式。   https://www.cwiki.us/display/GradleZH/questions/57938672

Gradle 6 尝试 build 的时候没有执行测试。 这个问题是什么问题？   当你的 Gradle build 的时候没有执行 test。 你需要看看你的 build.gradle 文件中有没有 test { useJUnitPlatform() } 这个 task。 如果没有的话，你需要将这个添加进来。 https://www.cwiki.us/display/GradleZH/questions/57938653

人类对待疫情肯定是最后都可以控制住的。 问题是多长时间，是否在拖垮医疗系统的情况下控制住。这个问题应该是时间问题。 比较关注一个点是测试量，首先说明不是专业人士，勿喷。 虽然看美国现在数据增加很快，但是也要看到他们的测试量也非常大。假设所有数据都是可信的，假设测试结果都是准确的。根据 wiki 上面的数据：https://en.m.wikipedia.org/wiki/COVID-19_testing 美国 30 号的测试量已经过百万了。基本测试量在每天10 万 + 的样子，相对很多国家，美国的测试能力还是在快速提升中。 现在重点应该是筛查NYC，等 NYC 都弄得差不多了，测试量继续增加的话，就会继续把隐藏在其他地区的人找出来并隔离的话，那么确诊数就出现下降了。因为你把所有人都找出来了。 前几天新闻报道，雅培火线批准的分子检测仪投入使用的话会继续加大检测能力。 所以疫情是肯定可以控制住，只是什么时候可以控制住，还需要多少天的问题。民众自我隔离意识有多高，检测能力有多大，医疗系统能撑多久，整个国家实力，等等多个因素来共同来决定的。 假设有超能力，把全世界人全部测一次，马上隔离感染者，那明天数据肯定新增就是 0 了。 可惜人类没有这个能力在短期内做到，怎么取得平衡，决定曲线怎么走。

商业软件的对象是尽量对公司少对个人，尤其是这种使用对象非常明确，软件使用门槛比较高的软件。 针对个人的盗版使用，公司基本上都睁只眼闭只眼，甚至还鼓励你使用，因为这种软件本身就有使用门槛，并且还有比较陡峭的学习曲线。 这个就是因为他们希望通过用户的使用系统来强化系统在市场上的占用率。 这些公司甚至针对大学生都是免费开放使用的，一旦使用的人多了，设计公司就会不得不用。   要起诉公司使用盗版那就太容易了，这些公司的起诉也是抓大不抓小。小的基本上就是警告下，然后让你买个版权就完了。 如果对一些规模性公司，那就不但要补版权，还有罚款了。 起诉个人没有太大的意义，绝大部分情况就是睁只眼闭只眼让你用，悬着一个达摩克利斯之剑就行了。

在使用 Gradle 进行 build 的时候运行测试，提示 build 不能完成，测试不能进行。 错误信息： Caused by: org.junit.platform.commons.PreconditionViolationException: Cannot create Launcher without at least one TestEngine; consider adding an engine implementation JAR to the classpath org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not complete execution for Gradle Test Executor 19. at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:63) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.stop(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:132) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164) at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:412) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.junit.platform.commons.PreconditionViolationException: Cannot create Launcher without at least one TestEngine; consider adding an engine implementation JAR to the classpath at org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296) at org.junit.platform.launcher.core.DefaultLauncher.<init>(DefaultLauncher.java:58) at org.junit.platform.launcher.core.LauncherFactory.create(LauncherFactory.java:91) at org.junit.platform.launcher.core.LauncherFactory.create(LauncherFactory.java:67) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:97) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61) ... 25 more Wrap lines       这里有关 Junit 5 进行 Gradle 配置的时候需要配置测试引擎。 请参考下面的链接中的说明： https://docs.gradle.org/current/userguide/java_testing.html#using_junit5 首先你需要在你的依赖中添加下面的内容： testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.1' testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.1' 同时，如果你使用的是 Junit 5 的话，你还需要指定测试： test { useJUnitPlatform() } 如果你这里不指定这个 test 测试的话，你项目的测试是不会运行的。   https://www.cwiki.us/display/GradleZH/questions/57938645  

Gradle 是一个开源的构建自动化（build automation）工具。有关构建自动化的定义请参考：https://en.wikipedia.org/wiki/Build_automation。同时 Gradle 被设计得足够灵活可以被用来构建几乎任何类型的软件。 下面的一些特性是从宏观上来对 Gradle 的一些特性进行阐述： 高性能 Gradle 通过运行需要运行的任务来避免不必要的工作。因为输入和输出可能会改变。你还可以通过启用构建缓存来让上一次构建运行的状态可以被重用，甚至你可以在不同的机器上这样做（通过共享构建缓存）。 同时 Gradle 还有很多优化的实践，Gradle 开发小组坚持开发使用来提高 Gradle 的性能。 基于 JVM Gradle 是运行在 JVM 虚拟机上的，所以你的机器必须要安装 JDK。针对使用 Java 平台的用户来说，这会带来非常大的好处，这些用户可以在他们的构建（build）逻辑中使用标准的 Java API。包括使用自定义任务类型和插件。同时也能够让 Gradle 更加容易的在其他平台上运行。 请注意，Gradle 并不仅仅限制于构建 JVM 项目，甚至被打包用来支持构建原生项目。 可转换 针对 Java 项目，Gradle 去掉了 Maven 的很多繁琐功能，能够更加容易的实现 Maven 的转换。通过引用合适正确的插件，你可以为你的项目减轻构建脚本的复杂性。 但是这些转换并不是为了局限你的使用：Gradle 运行你对它们进行重载（override），添加你的自定义任务，为你基于转换的项目提供更多的自定义功能。 可扩展 你可通过提供你自己的任务类型或者构建模型来对 Gradle 进行扩展。请参考针对 Android 的构建支持为样本的示范：可能会添加一些新的构建概念，例如 flavors 和 build types。 支持 IDE 一些主流的 IDE 都能够允许你导入 Gradle 的构建同时能够对其进行转换：Android Studio， IntelliJ IDEA， Eclipse 和 NetBeans。同时 Gradle 也能够支持创建导入Visual Studio 项目需要的 solution 文件。 自扫描和修复 构建扫描（Build scans）提供了一个帮助你识别构建错误和问题的扩展工具。同时这个工具也能够更好的帮助你识别和找到可能存在的构建性能问题。 你也可以和其他的用户分享你的构建扫描，这个分享功能在你希望获得其他开发人员帮助的时候就非常有用和高效。   https://www.cwiki.us/display/GradleZH/What+is+Gradle

这个问题就好像是围城的问题，当你学了一个学科后，你会发现越学越难学，越学越难精通。混日子的基本上那个学科都行。 然后就产生了一种厌恶感，不想再深入了，甚至不想让自己下一代和朋友都去接触自己现在的学科了。 这个东西主要还是看自己的兴趣，兴趣是最好的老师，你有兴趣就能学得进去，而且进步也会很快。 从转换的角度来看，计算机相对好转换，你如果从医学到计算机，花个几个月，基本上入门写几行代码还是问题不大的，要接触到架构，系统设计，其他很多学科的话那可能还要继续努力了。 但是如果从计算机到医学，花几个月，估计自己是一脸懵逼。 这 2 个专业都是实践性非常强的学科，相对医学来说还是要求门槛更高点。还是那句话，看你自己真正喜欢什么，挑你自己喜欢的不会错的，至于报酬那些其实并不是现在这个阶段需要重点考虑的内容。

都自嘲叫码农了，都叫农民了。 精英这个词就是标签了，比如说城市白领可以人为是精英吗？ 那大农场主，开着飞机播种那个是否被定义成稻田精英呢？ 个人认为不算精英，只是说目前随着 IT 技术的发展，在这个大分工的前提下需要大量的程序猿来保证系统的运行和开发一些新的功能，将他人的想法变成现实。可以叫做工程师，或者梦想构建者？ 同时因为行业相对比较激进，收入相对较其他行业平均收入偏高一点点而已罢了。离精英还是有不少差距。