Protocol buffer 这东西真的很轻便吗？     Protocol buffer 这东西一点都不轻便，定义文件后需要重新编译一次，编译出来的代码没有可读性，没有可调试的可能。 版本不兼容 Protocol buffer 的版本是不会向后兼容的，你必须要保证版本一致。 如果版本升级了，恭喜你，所有的文件都需要重新编译一次。如果你的项目在 Maven 的依赖定义的有点乱，比如说一个项目中有 2 个版本，那大概率会出问题。 这个问题不是编译问题，是运行时的问题，出了问题非常不好调试。 滥用 曾经一个公司可以说一个教科书基本的滥用典范。 为了调用另外一个服务的服务层方法，定义了 Protocol buffer，然后从另外一个服务的服务层调用。 这个项目有 10 多个微服务，本地调试有可能需要启动 3 到 4 个服务才能真正拿回来一个数据，在 DevOps 定义的时候端口定义不明确，经常让开发人员搞不清楚要那个端口。 启动的时候需要占用一个端口，我们在定义 Protocol buffer 的时候需要为 Protocol buffer 单独开一个端口，这要求令人发指，本地上经常的端口冲突。 为了重用方法，很多方法不加思索的就给了一个 Protocol buffer 定义，后来发现这个方法要修的话，参数一改，另外的地方就出错，数据调用异常，空对象。 Protocol buffer 这东西看起来很美好，用起来步步惊心。 效率 Protocol buffer 标称的就是效率高。 Protocol buffer 其实本身也是基于 JSON 的数据传输格式，而且在数据传输的消息上是有大小限制的。 默认可传输的大小不大，别指望返回以几万的 List ，大概率会报错。 Protocol buffer 的数据传输是通过压缩进行传输的，JSON 数据格式因为是文本，通常压缩比还是蛮高的，只是压缩也会消耗计算能力和资源，因此有时候压缩后的传输比较难分析真正 API JSON 调用中的数据。等于是开盲盒。 对于一些定义不明确的引用，方法老改的微服务，就那么几个服务在跑的项目，就别折腾了。 直接用 JSON 吧。 https://www.ossez.com/t/protocol-buffer-json/14214/1

美签数据跟踪网站（usvisatrack.com）正经上线能看了。标准的前后端分离技术， Java+VUE。 我们在内测和吸取改进建议，你的需求我们来实现。   这是我们前后端分离技术实践的一个框架。     任何软件开发需求，有关数据的，业务的，我们都可以实现。   欢迎联系我们。   https://www.ossez.com/t/topic/14211

Windows 11 更新到最新版本后的任务管理器也变样了。 一下子都不知道怎么玩了。 https://www.ossez.com/t/windows-11/14207

驻纽约领事馆的证件申请邮箱地址改了。 自美东时间2022年11月1日起，中国驻纽约总领馆将启用新的领事证件业务专用咨询邮箱，变更后的新邮箱分别为： 签证业务：ny_visa@csm.mfa.gov.cn 护照、旅行证业务：ny_hz@csm.mfa.gov.cn 公证、认证、《在境外居住人员领取养老金资格审核表》（健在证明）业务：ny_gzrz@csm.mfa.gov.cn 如果发送邮件到老邮箱的话，大概率会收到一个自动恢复邮件上面包含有这个信息。   https://www.usreio.com/t/topic/326

硅谷裁员潮的影响还在持续，结合一个程序员和公司的情况来聊聊。 裁员潮存在吗 我的理解裁员是存在的，谈不上裁员潮。 科技公司有收缩战线的需求。Meta 营收不及预期，这个又不是新鲜事，从 FB 开始转型开始就没有顺利过，好不容易搞了个 FB 的 facebook marketplace，但又因为放鸽子的情况横飞，让人非常懊恼。 这次 Mata 下定决心要裁员削减开支，只要是正常人都会这样做吧。 Meta 裁员会释放出挤兑效应，各个公司都开始考虑是不是真的需要那么多人，后来发现招聘来的很多人不能进入角色，很多人也不能干活，天天在公司混吃等死。 那么第一步肯定就是要清理掉这部分的员工，硅谷里面 有一个非常令人讨厌的 PIP，现在已经不是 PIP 这么回事情，就直接把项目砍掉，把不赚钱的业务丢掉。 捅破这层纸的是 Twitter。 Twitter 本来影响力就一直在下降，搞得自己和网警一样的，这样肯定会失去年轻用户的喜欢。 新老板一进来，看看这不对呀，这公司这么大问题，已经不是说修修补补就能解决的了。 那只能换血吧，如果说对华人影响大的话，其实对印度裔的影响更大。从上届美国总统开始的打击 ICC ，到这次裁员的情况，对印度裔程序员影响可见一斑。     寒潮吗 可能这还只是入冬前的打了下霜呢。 还没有到寒潮那个程度，这次更是感觉是个挤水分的过程。淘汰掉一些不需要的功能，淘汰一些不需要的人力资源，这个是正常的过程。 大家都可能都知道美联储一直在进行加息，这个加息对流动性影响还是非常大的，不仅仅是个人，不少公司也会因为债务问题会削减开支。 其中也包括有广告开支，IT 应用支出等等，这个势必会传导到科技公司上面。 自我感觉 我一直对大公司没少好感，也没啥缘分。 一般都在中小公司里面。就算是这样，当前所在的公司在 3 个月之前就已经通知我们冻结大规模招聘，削减 IT 开支，收缩外包规模。 感觉这次对印度裔的打击会比华裔打击更大。 因为华裔通常不会特别安于在一个公司里面工作到头，更多人会有自己的想法，同时还会做一些其他的小 PRJ，反而这种不安于现状的状态会带来意想不到的效果。 努力提升自己，在进入这个行业之前仔细想想，你的需求是什么，这个行业能够给你带来什么，早做准备。 更主要的是做好思想上的准备，系好安全带不是坏事。   https://www.ossez.com/t/topic/14203

就冲着这个价格去种的草。     该有的都有了，Chrome Book 这个价格也难搞定呀。 https://www.usreio.com/t/topic/325  

裁员是痛苦但是不得不经历的一个过程。 互联网经济在 2000 年泡沫危机过后，都没有疼过，这次被 Twitter 搅局了，虽然 Twitter 也面临着一大堆问题，没有那么多人天天刷这些东西了。 应该是互联网公司早就开始想裁员了，但是碍着面子和名声和越来越严重的扎堆抱团不干活一时找不到突破口，谁也不想当第一个靶子，这下好了，正好一鼓作气把这个问题解决干净。 几十年来互联网一直没有什么太大的创新，能想明白的基本上也想得差不多了，FB 本来自己也一堆麻烦，这个裁员是早晚的事情，没啥好稀奇的。     招聘过程中，各种所谓的刷题，拿 Offer 的奇葩存在，很多程序员或者 IT 从业人员早就没有激情了，盼望着一鼓作气刷题 30 天，年薪百万不是梦的想法来进入这个行业的。 这个是整个行业的问题，这次裁员也是整个行业由破而立的过程，短期是痛苦的，长期来看未必是坏事。   https://www.ossez.com/t/topic/14202

ISO 8601 持续时间格式。 ISO 8601 中定义了一个时间间隔， 格式如下： ISO 8601持续时间格式如下： P(n)Y(n)M(n)DT(n)H(n)M(n)S 其中： P是持续时间指示符，始终放置在持续时间的开头位置 T是表示时间元素开始的指示符 (n)为时间值 符号 含义 Y 年 M 月 D 日 W 星期 H 时 M 分 S 秒 示例 P3M 上面的时间表示的是时间间隔为 3 个月。 通常我们在 Java 项目中可以用来计算 2 个时间的不同。 例如我们当前有一个需求为，我们需要对数据进行处理，但是数据处理时间为当前的时间减去 3 个月的这个时间间隔。 在 API 中，我们可以直接定义数字 3 ，但是我们觉得这样不够标准化，所以我们就可以在 API 中传入参数 P3M，然后在后端进行计算就可以了。 例如我们使用下面的代码： Period p = Period.parse("P3M"); LocalDate currentDate = LocalDate.now(); log.debug("{}", currentDate.minus(p).toString()); 程序将会输出当前的日期减去 3 个月。     尽量使用标准的表示吧，系统的处理更加方便。   https://www.ossez.com/t/iso-8601/14201

Discourse 项目是默认支持语法高亮的，Discourse 会默认使用 highlight.js 来显示语法高亮。 如果你的代码没有正确使用语法高亮的话，你可以在代码块中强制使用你希望使用的语言，例如下面： ``` ruby 3.times do |stuff| stuff.do end ``` 显示结果： 3.times do |stuff| stuff.do end 设定的语言，必须满足平台中设置的，可以查看 highlighted_languages 配置选项来检查 Discourse 网站中的语言设置。 如果你的帖子还是没有办法显示的话，你需要联系的站点管理员了。     通常在默认的安装下 Discourse 都能够显示语法高亮的。 不显示语法高亮 如果你不希望的代码显示任何语法高亮，你可以选择在代码块后面输入字符 “text” ： ``` text Your text to NOT highlight here ``` Your text to NOT highlight here 如上面的显示结果。   https://www.ossez.com/t/discourse/14200

我们都知道，在开发的时候有些包可能是没有办法从 Central 仓库中下载下来的。 因为一些项目会有自己的仓库，这些内容并没有推送到 Central 中。 根据网站：https://mvnrepository.com/repos 中的索引，他们索引了超过 1821 个仓库。 总计的包大小超过 102TB     Nexus 如何处理 Nexus 没有办法在一个仓库中添加多个仓库的远程链接。 可以采取的方法就是 Group 的方式。 首先可以对远程的仓库创建 一个 Proxy。     然后再创建一个 Group。 在这个 Group 里面把我们需要的多仓库放在一起。 例如，我们创建了一个 Public Group， 然后把可用的仓库移过来后保存，在前端 Maven 的时候直接用 Group 的地址就可以了。     这样我们就可以实现多仓库的统一地址下载。   https://www.ossez.com/t/sonatype-nexus/14196