在使用 Moment.js 转换为 UTC 格式的时候，我们可能会遇到 2 个小问题。 如果你使用 ('2021-11-01T19:39:00.000').utc().format(); 来进行 UTC 时间转换的话，你会发现你输入时间和输出时间是不同的。 转换时区 如果上面所描述的，在结果中，我们看到如下图     输入的时间，我们实际上使用 UTC 的时间，但是在转换成功后，我们会发现 2 个时间有偏差。 有这个偏差的原因就是当前你的计算机的时间。 从下图我们可以看到：     在对象初始化的时候，是否是 UTC 的时间参数选项是 false。 因此才会出现偏差。 如果你已知的输入时间是 UTC 时间的话，你可以使用下面的代码： moment.utc('2021-11-01T19:39:00.000').format();     这样的方式初始化对象的话，对象的时间标记将会标记为 UTC 时间。 format 函数没有毫秒 聪明的你可能会看到，如果你使用 format() 函数进行格式化 ISO 时间的话是没有毫秒的。 如果你希望你的时间对象格式化输出后有毫秒数据。 你应该使用的方法是： toISOString() 考察下面的代码： moment.utc('2021-11-01T19:39:00.000').toISOString() 如下图所示，下面的代码格式化输出后将会有毫秒数据：     这是在实际使用的时候需要注意一下的地方。 https://www.ossez.com/t/moment-js-utc-2/13807

TypeScript is JavaScript with syntax for types (TypeScript 是一个使用了 types 类型的 JavaScript 语言)。 添加了类型系统的 JavaScript，适用于任何规模的项目。 上面的英文是从官方网站 [1] 上抄录下来的。     从上面的文字，可以简单的理解就是针 JavaScript 语言，TypeScript 添加了「类型（types）」。 如果你写过或者了解 Java 程序的，你会知道 Java 在定义 变量的时候需要对变量的类型进行定义。 在实际使用的时候，因为变量的类型进行了定义，因此 Java 语言就涉及到类型转换，比如说要把 String 转换为 Int，虽然 Java 对其类型转换进行了一些包装，但是整个转换过程还是有点学习曲线的。 对比 Java 而言，JavaScript 就完全不需要对类型进行定义了，JavaScript 会在运行的时候帮你进行类型的自动判断和转换。这个就导致 JavaScript 非常灵活，灵活的同时就会带来困惑， 原因是你在程序运行的时候，完全不知道你的变量是什么类型的，这会导致一些莫名其妙的错误发生，而且 Debug 的时候也是比较纠结。   https://www.ossez.com/t/typescript/13806

有时候你在运行文档的时候，可能会遇到下面的问题： AppData\Roaming\npm\docsify.ps1 is not digitally signed. You cannot run this script on the current system.     解决 这个问题是原因是脚本执行权限的问题。 可以通过运行下面的命令： Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass 来解决。   https://www.ossez.com/t/docsify/13805

在一次开发 NodeJS 项目的时候，我们希望包的导入是用 import 导入的方式。 但是在具体导入的时候发现是使用 @types 导入的。     如果上面的图显示的导入方式，结果结果是导致程序错误无法运行。 问题和原因 尽管我们在包的配置文件中添加了需要导入的包的版本。 "bluebird": "^3.5.1", 但是我们发现还是没有正确的使用，还是使用的是 @types 的方式。 @types 经过一些研究，有时候 @types 这个的使用是因为在 JS 世界中有很多的包不是通过 TypeScript 进行开发的，使用是普通的 JS 。 为了让使用 JS 的库能够在 TypeScript 上使用，那么我们在导入的时候需要添加 @types 但是我们的这个问题是，我们并没有添加需要的 @types/bluebird, 但是这个是从哪里来的呢？ 这个时候，我们需要找到这个包导入的依赖了。 在导入这个包所在项目的文件夹中，打开 package.json 这个文件。 在这个文件中也没有找到这个包的依赖，也不是使用types 定义的。 只能从项目中的依赖找原因了。 在这个文件中，我们会看到 "_requiredBy": [ "/@types/request-promise" ], 这个就是让 @types/bluebird 导入的元凶了，因为这个类型是 @types 的，所以我们按照 @types 导入了 bluebird。 但是实际使用的时候，我们的程序使用的是另外的一种导入方式。 因此，针对这个问题，我们最简单的办法就是将 /@types/request-promise 从你的包的依赖中删除。     这样就能解决我们上面遇到的问题了。 https://www.ossez.com/t/nodejs-types/13801

相信很多人在运行第一个可以运行的 Java 程序的时候都会要求写一个主函数。 然后很多人都会照葫芦画瓢的写一个下面的函数： public static void main(String[] args) { } IJ 甚至非常贴心的给你 main 的代码提示：     这个函数里面有几个定义和关键字，估计可能会有些绕，和为什么这么写？ 近期在学习的时候才翻出来再看看，其中可能比较难理解的是关键字 static public 这个关键字在这个函数中很好理解，就是表示这个函数是可以被其他类访问到。 void 表示这个函数不返回任何数据。 这个也比较好理解，因为这个函数是主程序的入口，通常是不需要返回结果的。使用 void 也没关系。 String[] args 这个表示的是这个函数可以从执行的时候获得的输入参数。 就是告诉这个函数在执行的时候，你可以在命令行中定义一些参数，然后这个函数通过获得这些参数来对运行进行调整。 通常我们对输入参数的控制会使用。 Apache 的 commons-cli-1.4.jar 来进行处理，因为这个 API 帮我解决了对出入参数进行处理的常用方法，能够简化我们的操作。 这个内容我们在其他地方再单独拿出来说。 static 这个就是我们需要说明一下的重点了。 我们都知道 static 是表示静态的意思，为什么在 main 函数里面需要静态关键字修饰？ static 主要用途是告诉编译器 main 函数是一个静态函数。同时也就是说main 函数中的代码是存储在静态存储区的，即当定义了类以后这段代码就已经存在了。 这个所谓的静态存储区，就是我们常说 JVM 中的堆（Heap），这个 Heap 就是 JVM 垃圾回收管理的区域，也是你经常看到内存溢出的区域。 static关键字主要用于内存管理。我们可以应用 ava static关键字在变量，方法，块和嵌套类中。 static关键字属于类，而不是类的实例。 被 static 关键字修饰的不需要创建对象去调用，直接根据类名就可以去访问。 在 main() 方法中使用静态（static）这个关键字，JVM 将会为这个方法开辟内存空间，你不需要对这个方法进行实例化，因此能够节省不必要的开销。 如果 main 方法不声明为静态的，JVM 就必须创建main类的实例，因为构造器可以被重载，JVM就没法确定调用哪个 main 方法。 因此，在这里这个 static 关键字是必须要有的，否则你的程序可以编译，但是无法运行。 如果使用上面的代码： public void main(String[] args) { System.out.println("RUN"); } 运行的时候将会有错误： Error: Main method is not static in class com.ossez.codebank.algorithm.Main, please define the main method as: public static void main(String[] args) Process finished with exit code 1 但是编译是不会有错误的。   https://www.ossez.com/t/java-main-static/13796  

如果让你计算 1 到 100 万的和是多少，你应该会这样写： @Test public void testSum() { int sum = 0; for (int i = 1; i <= 1000000; i++) { sum = sum + i; } logger.debug("SUM - {}", sum); } 程序不长，但是你如果进行计算的话，你得到的结果很有可能是这样的： 00:38:51.312 [main] DEBUG com.ossez.codebank.algorithm.tests.BlankTest - SUM - 1784293664 是不是发现上面的结果不对？ 这是因为在 int 已经溢出了。 在 Java 中，int 只能存储 2147483647 这么多的数字，如果你在上面的代码中使用 int 那么肯定会溢出的。 所以你需要使用 long 来进行计算。     上面的运算结果才是你要的结果。   https://www.ossez.com/t/java-1-1-000-000/13794

Java 的内部类可能在实际使用的时候用得并不是非常多，但是如果要说起来应该也不陌生。 用土话来说就是一个类里面还有一个类。 看看下面的代码就知道什么叫内部类了。 class OuterClass { ... class InnerClass { ... } static class StaticNestedClass { ... } }     为什么要内部类 主要考虑有： 这是一种逻辑上将类进行分类，并且只在一个地方使用的方法 能够更好的增加封装性 能够让代码更容易阅读和维护 要点 说了上面这么多，相信对内部类应该有一些比较大致的了解了。 在使用的时候和面试的时候，初级阶段应该会问到对内部类如何进行访问。 简单来说，必须要对内部类的外部类进行实例化后才能访问，你不能直接访问内部类。   https://www.ossez.com/t/java-nested-class/13795

RSA 265:107-a Effective January 1, 2014 新罕布什尔州的儿童安全座椅法律是在 2014 年 1月 1 日更新了。 简单点说当孩子小于 7 岁或者 57 英寸（1米44）的时候必须使用正确的儿童安全座椅。 当儿童小于 18 岁的话，必须要使用安全带和在后排。 Rear-facing（2 岁以前） 在两岁以前的时候，需要朝向座椅的安全提篮。 优势孩子如果安全提篮坐不下的话，应该可以改成朝前的安全座椅。 Forward-facing （age 2 到 6岁 ） 在 2 到 6 岁之间，孩子需要使用安全座椅。 Booster seat（7 岁到 1 米44） 如果你的孩子已经超过 7 岁了，但是还没有 1 米 44 的身高的话，将会要求使用 Booster seat。 总结 简单来说 NH 的儿童安全座椅法律更多的是按照升高来的，貌似 57 英寸是个槛，超过 57 英寸后基本上使用车上的安全带就可以了。 当孩子在 6 岁左右的时候，通常已经可以开始使用 Booster seat。     因为 Forward-facing 安全座椅会在车上占用一个座椅，还是希望孩子快快长大吧。   https://www.usreio.com/t/topic/190

在需要删除的 Google 项目中，选择边上的设置按钮。 然后选择项目设置。 删除项目 在项目设置页面中的最下面有一个删除项目按钮，然后单击这个删除按钮。 然后选定后进行删除。 至此，针对这个项目的所有配置就被删除完全了。   https://www.ossez.com/t/google-firebase/13792

这次面试没有获得需要的职位。 公司背景 公司也不属于初创型公司了，公司在市场上已经发展了 20 多年了。 主要产品是为小型设备提供监控和管理并且有些特殊的用途。 因为公司前期的产品都是基于本地的，很多时候都是没有办法进行联网的，因此公司想在这方面开发一些基于云服务相关的产品。 职位需求 这个职位需要应聘的人有比较深入的软件开发设计功底，能够实现云平台的设计和开发。 同时这个职位并对语言的选择没有什么要求，可能还是希望使用 Node 或者 Python 这类的轻量型语言吧。 同时这个职位需要能够独立完成云平台的设计，个人感觉要求的东西还是有点多的。 面试过程 在面试的过程中，主要先是介绍了公司的基础架构，在当前的情况下，这个公司的 IT 部门的人几乎是没有的。 这个公司从一个比较大的公司挖来了一个管理人员，希望能够完善整个 IT 的架构和设计等。 负责面试的就是从外面挖来的这个人了，应该是由他来负责组建团队和选择合适的人才等等。 在面试过程中主要考察了 AWS 的设计，因为当前公司的 IT 部门没有任何人，所以至于数据是什么样的，结构是什么样的，需要什么的云计算方案可以说是没有任何方案。 在具体面试的时候他一直在纠结 aws 中 lambda 和 ec2 的对比。 说实在话对这个问题确实没有研究过，所以回答有点绕。 后来经过一些了解和研究就是： AWS EC2 是IaaS，认为它是在虚拟机上运行还是在云上运行服务器。使用EC2，您可以有更多的控制权，但需要做更多的工作，例如打补丁，维护等。使用ec2时，即使代码可能至少不会执行一次，也必须为运行实例（服务器）付费。 AWS Lambda 是与 EC2不同的技术，后者没有服务器，基本上，您只是在运行代码而未显式运行服务器。认为这只是将代码上传到云，而AWS正在为您运行服务器。您不必为服务器付费，但是无需花费任何时间执行代码。 简单来说 Lambda 使用无服务的方式来完成计算，通常对于一些内部的数据调用，转换，更新使用 Lambda 会更加高效。 因为没有实际的服务器，因此你也不需要为你的服务器去进行任何部署，甚至进行 CI/CD 集成代码了。 另外我的理解是 Lambda 只是实现某一些功能的快速部署，在一些时候，应该还是需要 EC2 本来部署的，比如说 API 的调用等等。 总结 整体来说这次面试的结果还是比较糟糕的。 在面试的过程中，对方提出了一个观点就是我们一直在 Lambda 和 EC2，数据之间绕来绕去。 当我听到这句话的时候，我基本上可以确定没有下文了。个人的感觉就是丢开数据谈方案都是耍流氓，就几百万的数据，随便你怎么折腾都可以。 所以我更多的是在考虑数据量和数据结构，对方考虑的是在没有数据设计的情况下如何选择，感觉这个选择题也是怪怪的。 可能是因为是初创 IT 团队，没有数据模型也很正常，但没有数据模型又如何选择架构呢？也许他只想知道面试的人到底有多了解 AWS 中的几个服务罢了。   https://www.ossez.com/t/2021-iot/13791