在默认的 Discourse 配置中，我们左侧的边栏可以根据自己的要求进行修改吗？     解决办法 针对自己登录的用户，你是可以自己调整左侧边栏的配置。 单击右上角你的个人头像，然后选择属性。     在切换的界面中，选择属性。 在出现的配置界面中，选择 Sidebar【边栏】。     在弹出的界面中，选择分类选项。 你可以在这个选择选项中对自己希望显示的分类进行调整。     然后单击保存就可以了。 无法进行排序 需要注意的是，这部分的调整是没有办法进行排序的。     如果上图显示，新添加的分类在这里标记显示了。   https://www.ossez.com/t/discourse/14221

新的边栏界面如下图：     官方有关这个边栏的说明和解释文章请参考链接： Try out the new sidebar and notification menus! - announcements - Discourse Meta 中的内容。 在这个新设计的边栏中包含了一些所有人都需要使用的快捷链接，同时还包括一些定义的快捷分类链接和 Tag 链接。 通过这个新设计的边栏，用户可以快速的对网站中的内容进行导航。 同时，用户还可以对自己的边栏进行调整。 在默认的界面中提供的分类是系统管理员在后台提供的，如果用户不进行调整的话，默认将会使用上面的分类。 这是因为针对不同的用户，用户可能有自己的喜好。 管理员开启新的边栏设置 在管理员界面中，选择开发，然后选择 Allows experimental sidebar and user hamburger dropdown menu to be enabled. 这个选项然后保存退出。     在网站的首页中，我们会看到新的边栏被移动到网页的左上角了。     单击左上角的这个按钮，边栏就可以显示出来了。 如你没有自定义需要的边栏的话，系统将会显示默认的边栏。   https://www.ossez.com/t/discourse-2022-11/14220

推特要走的路还很长。 推特这个产品已经开始比较边缘化，抱着手机刷 Twitter 的人在下降，更多的是一些公司或者机构发布一些更新。 但，这些机构的更新又常常缺乏价值，导致现在 Twitter 上面的有效价值信息并不多。 在用户群组上的单一信息传播能力确实还不如微信群组来得快。 举一个非常实际的例子： 我想去滑雪，我需要周边滑雪场的情况，大概有 4 到 5 个雪场的情况以便于我决定去哪个滑雪场。 在 Twitter 的信息模式上，我需要先订阅群组，或者订阅滑雪场的 Twitter 号，然后从历史的信息中过滤出我需要的有效信息。 在微信群组的模式下，需要做的就是提问，然后有人回复即可，这也就是为什么很多人把微信群作为快速获得信息来源的第一步，然后使用其他工具对获得的信息进行验证。在美国这边微信通常还不是非常主流，但是也有类似的替代产品，比如说 Line 或者电报群，整体看起来没有微信群用得这么顺手。 在产品和使用上，Twitter 这个产品 N 年没有更新了，连界面都没怎么换过，已经是审美疲劳了，如果不是前任总统喜欢在 Twitter 上 BB 找骂，估计很多人都已经快不怎么使用了，说句话不好听的话，生动性和趣味性都比不上小红书（虽然也是各种垃圾，误导，营销信息满天飞），抖音就更没法比了。 印度高管，估计没有认真想明白这个产品到底应该怎么发展，或者确实也想不明白怎么弄，只是抱着已有的用户基数炒冷饭。最后干脆把前总统的账号给封了，这下子漂亮国就炸锅了，漂亮国人醒过梦来，原来这账号都不安全呀。连总统账号说封就封，估计自己的这个也差不多。 小马哥首先要解决人心问题，人心散了，队伍不好带了。只能先换血下刀子呗。 至于印度 CEO 和高管的问题，肯定要先解决掉，下面就会慢慢好办了，毕竟他的政策还是需要人执行的，然后就是解决下面一堆代码写得不咋的，天天混日子的这种。 RPC 调用 1000 次，没有想去怎么变得更好，还怼老板不懂技术，就算老板不懂技术，这 RPC 调用 1000 次是人干的事情吗？不过这个很印度。 Twitter 要重现曾经的辉煌，应该不容易，现在除了天天流失的用户基数，也余不下什么了。对比下鹅厂，虽然是我不要脸，我抄我开心，但鹅厂敢于推出一个和 QQ 正面竞争的微信，并且慢慢的把 QQ 边缘化，而构造了一个微信生态圈，还是比现在被印度人玩死的 Twitter 好点。   https://www.ossez.com/t/twitter/14219/1

Discourse 在发布主题的时候，在默认情况下会遇到： An error occurred: Title seems unclear, did you mean to enter it in ALL CAPS? 的提示。     问题和解决 出现这个问题的原因是 Discourse 在默认的情况下是不允许标题和正文全部为大写字母的。 可以在后台搜索 allow all. 然后选择 Allow all caps in a topic title or a post body. 这个选项后保存退出。     在前台再尝试更新下标题，就可以解决这个问题了。   https://www.ossez.com/t/discourse-an-error-occurred-title-seems-unclear-did-you-mean-to-enter-it-in-all-caps/14217

根据 Discourse 的官方推荐，我们使用的是 MailGun 的服务。 在大部分情况下都没有问题，但是在一些特定的邮件地址，例如 iCloud，我们在发送激活邮件的时候有提示为： "message": "5.5.1 Error: need MAIL command - MAIL FROM error: 450 4.1.8 <bounce+6712f2.21c8873-lucas.hu=@mail.visafn.com>: Sender address rejected: Domain not found",     下面的图片显示了邮件服务提供商提供的错误日志信息：     问题和解决 上面问题的主要原因是一些特定的邮件服务商有垃圾邮件校验策略。 尤其是 iCloud，在 iCloud 中对发送电子邮件的域名地址会进行校验。 因为我们的服务使用了子域名的发送，我们发送的域名地址实际为：mail.visafn.com 而不是传统的 visafn.com 因此，iCloud 没有办法校验上面的地址，而认为系统发送的邮件为垃圾邮件而拒收了。 解决办法 解决的办法也非常简单，需要确定 mail.visafn.com 我们发送邮件使用的这个二级域名的 MX 记录在 DNS 上要存在。     如上图标记的内容。 二级域名的 MX 记录需要添加到你的 DNS 上，并且上面的记录要显示为被校验。 当然更新 DNS 不会马上生效，你如果继续往 iCloud 中发送的话，可能还是会出现间歇性错误。 等待几个小时后再进行测试，通常能够解决发送邮件被标记为垃圾邮件的问题。   https://www.ossez.com/t/discourse/14216

JWTs是JSON对象的编码表示。JSON对象由零或多个名称/值对组成，其中名称为字符串，值为任意JSON值。 JWT有助于在clear(例如在URL中)发送这样的信息，可以被信任为不可读(即加密的)、不可修改的(即签名)和URL - safe(即Base64编码的)。 JSON Web Token (JWT) 作为一个开放的标准 (RFC 7519) 定义了一种简洁自包含的方法用于通信双方之间以 JSON 对象的形式安全的传递信息。因为有数字签名，所以这些通信的信息能够被校验和信任。 JWT 可以使用秘钥（secret）进行签名 (使用 HMAC 算法) 或使用 RSA 或 ECDSA 算法的公钥/私钥对（public/private key）。 尽管 JWT 可以在通讯的双方之间通过提供秘钥（secret）来进行签名，我们将会更多关注 **已签名（signed）**的 token。 通过签名的令牌可以验证其中数据的 完整性（integrity） ，而加密的令牌可以针对其他方 隐藏（hide） 申明。 当令牌（token）使用 公钥/私钥对（public/private key）进行签名的时候，只有持有私钥进行签名的一方是进行签名的。 JWT 定义了一个标准，JJWT 是 JWT 基于 Java 的一个实现。 如下图，我们返回的一个 JWT。     JWT 是可以解码的。     JJWT JJWT 是基于 JWT 的一个实现。 JJWT很容易使用和理解。它被设计成一个以建筑为中心的流畅界面，隐藏了它的大部分复杂性。 JJWT的目标是最容易使用和理解用于在JVM上创建和验证JSON Web令牌(JWTs)的库。 JJWT是基于JWT、JWS、JWE、JWK和JWA RFC规范的Java实现。 JJWT还添加了一些不属于规范的便利扩展，比如JWT压缩和索赔强制。 因为 JWT 的官方库不那么好用，那么JJWT 就是一个目前用得比较多的实现 JWT 的库了。 如果在你的项目中需要使用 JWT，那么用 JJWT 就没有什么问题。   https://www.ossez.com/t/jwt-jjwt/14130

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

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