最新大日本帝国是如何被低智商民粹主义反噬的？
转自微信公众号 “种豆包Chong”，视频版发布在 B 站和 Youtube，均为同 ID。 大家好，本期我们来讲讲大日本帝国的低智商民粹主义。 在20世纪初，为了应对来自海的对面的敌对势力，大日本帝国不惜放任国内媒体和 “网红”大肆发布极具煽动性、误导性、欺骗性的内容，自作聪明的玩弄低智商民粹主义，之后惨遭反噬引发了灾难级后果，后果之严重不亚于二二六兵变。 低智商民粹主义就和泡沫一样，狂热的极端氛围迟早会有爆的一天，尤其是当爱国被盈利化，靠着爱国就能赚大钱，使得爱国饭、民粹饭、煽动饭、被各路妖魔鬼怪视为香饽饽，利用媒体一个比着一个的看谁更爱国更民粹更极端来吸引关注，其结果只会是害了国家坑了百姓。 1894年甲午战争爆发，大清惨败。作为大日本帝国的第一次对外战争，经过了以皇国史观为核心的臣民化教育、集体主义教育，以及对曾经的顶级东亚霸主在军事制度和政治制度上都取得了压倒性的胜利彻底塑造了日本人的国家意识。 且甲午战争战前、战时、战后的大日本帝国国内均出现了大量针对清国人的例如“猪尾辫人”等蔑称，对于这么明显的民族歧视舆论的流行，大日本帝国却放任其野蛮发展。 一种通过贬低对手来达 ...
以后的一点计划
本来想写24年的年度总结，但是想了半天，写了半天，写不出来一点东西，于是删掉，干脆写点以后的计划。 今年年中的时候我好像说过“不清楚自己以后是要考研还是找工作”，但是现在摆在我面前的已经不止这两条路了，大致来讲还是能分成两条路，就业和升学，但就业和升学依次还能在分出两条路或者若干条路。 我现在一直在忧虑自己以后到底要干什么。目前的打算是过几年去日本，留学或工作都可以，然后争取拿永驻。现在日语n2水平，英语托福和托业还没考。 由此看来，摆在我面前的就只有这么些路了。优先级从上到下依次为 毕业去日本读研，然后留日工作，拿日本永驻，长期驻日 在国内工作，攒点钱再去日本读研，然后参考第1点 毕业直接去日本工作，然后参考第1点 毕业在国内读研，然后在国内工作，长期留国内 只要是去日本的选项，优先级都是偏高的。至于我为什么要去日本，一方面是国内失业率越来越高，且国内互联网行业几乎无人能逃出35岁的魔咒，而在日本工作可以靠年功序列制嗯造高龄工资，不用担心35岁失业，真正的越老越吃香；另一方面是我本人确实对日本有一种奇妙的滤镜——毕竟作为互联网行业的人，去美国才是最合适的，毕竟美国的互联网行业也很 ...
天气转寒，注意身体
f58fadda878fbfed22556385e845a685939af906f680f019549cfb53a68c0a7ffbeff95d759846710380c76e62f2880d9055c3fbb702da35716d5648eff13eeb853aebdd2a24864220f8e323d0c32cdc5e62e87a8d522cccaaf01bc16f8219bcf717a8b26ac3c92104c4212e1653d84741f612ac79e2f574e001d5fe4cca6bb7635cea2d08f228ff22350aabd21761148da0d393620c637aed054e5475c0fac99e4f378012f8653a4582b8f7a013060d23474229a168c831186d0351d6790dc63a37cc43117cba5041f12f061b22635ebc7e18768c714efd0ab79bc38db4e5a63884cbc82a23afdbf82488eece9c8658b0ae5011d47b907bd ...
运营商的推销电话太烦人？看我如何制裁他们
最近半年以来天天接到来自中国移动的骚扰电话，大概内容为推销套餐、流量包、宽带等产品，开启手机的骚扰拦截功能之后依然无效，一天仍然能接到好多电话。最后实在忍无可忍，只好打开b站，看看有没有类似的情况，结果发现这种情况真是屡见不鲜了。有些视频提出可以去工信部举报，举报之后颇有成效，我一开始是不相信的，但是也想不出更好的方法，于是照着做了，结果真的有效果。 这是我最近三个月以来接到的部分骚扰电话，有些骚扰电话没有被手机系统拦截，所以没有包含在内 你可以发现，基本上都是来自于0663790这个号段的。我曾经完全没有怀疑过是运营商的问题，一直以为是高利贷/推销/诈骗分子的骚扰方式升级了，根据目标的手机号归属地自动选择对应归属地的座机号码，结果有一次拨通了，才知道是中国移动在搞鬼。 那么是时候该出重拳让中国移动吃吃铁拳了。如果你和我一样也有这样的困扰，不妨学着做起来，哪怕不是来自运营商的骚扰电话也可以试一试，说不定也有效果。 打开 工信部的投诉网站，选择“我要申诉”。进入申诉页面之后，根据需要，选择“基础电信运营商”或“其他企业”。“是否向企业投诉过”选“是”，“企业反馈结果满意程度”选“不满意 ...
半天的广州小旅行
其实也不算真正意义上的旅行，只不过是借着笔试的机会出来玩玩。兜兜转转，居然花了半天的时间逛了小半个广州。 前段时间在投简历，很幸运地收到了一家公司的线下笔试邀约。公司地点位于海珠琶洲，是个好地方，毗邻珠江，不远处就是广州塔、珠江新城、东西双塔。因为是新开发的区域，所以道路条件也远比天河要好。这块区域主要是互联网公司的办公地，所以路上随处可见的是各大互联网公司的打工人。 笔试约在昨天下午。昨天上午我有一门理论课和实验课，下课已经12点钟了，吃完饭再回到宿舍已经是12点半。笔试的开始时间是下午两点半，考虑了一下以前从大学城去琶洲的耗时，遂决定下午1点15分从大学城出发，到达大学城北地铁站之后再坐地铁去琶洲。 结果1点15分出发，看了下高德地图，提示需要1小时20分钟后到达目的地。“这下完蛋了，要迟到了。”我这么想着，一面想着一面小跑以赶上即将到达公交站的公交车，幸运的是没有错过这趟车。假如错过了这趟车，再选择等下一辆开往地铁站的公交车，那就一定会迟到了。坐了差不多10分钟，公交车到达了大学城北地铁站。 大学城北地铁站的站厅面积十分狭小，刷卡进入付费区之后就是两个电梯出入口，分别导向大学城 ...
面对频发的恐怖袭击案件，我们该怎么办
本文仅为表面闲谈，不涉及更深层次原因。 今年一年可谓是多事之秋，而今年的下半年更是如此。从9月份的深圳大学杀人案，到10月份的深圳日本人学校的学生被捅，再到同样是10月份的上海某商场门口的随机杀人案，再到前几天珠海的体育场开车碾压无辜群众，再到昨天（11月16日）无锡工艺职业技术学院发生的随机杀人事件，再到今天（11月17日）的广东工业大学的宿舍杀人案，这一切让我们不禁为社会的安全产生了担忧。现在这个社会真的如同宣传所说的这么“安全”吗？今天笔者不想讨论更深层次的原因，只想简单聊聊——面对频发的恐怖袭击案件，我们该怎么办。 这里简单贴一个来自“深圳反恐”公众号的推文。 五大场景逃生教学（二）：车辆冲撞恐怖袭击 很明显，这则推文应该是在珠海体育场事件之后发布的。对于懒得点开的读者，这里直接给出省流： 碰到极端驾车冲撞时，牢记三个技巧： 躲。往树木、石桌石凳、建筑物、摊位、大型车辆、大件物品后面躲，注意留出缓冲空间。切记不要往路灯、玻璃橱窗躲避，避免物品被撞倒或破碎导致二次伤害 避。千万不要背对汽车逃窜，应该面向或侧向来袭汽车，连续向左向右移动，做“之”字形或“O”字形运动 掷。把 ...
个人博客对繁体自动化镜像搬运的反制
在网上冲浪，偶然看到这么一篇文章 我也中招了！大量简中博客站点被镜像，并翻译成了繁体中文 文章的内容就是一位站长发现自己的网站在未经许可的情况下被海外的繁体镜像搬运。我个人对这种行为是极其深恶痛绝且不齿的，搬运他人的文章构建“内容农场”，不仅侵害了他人的著作权，还会影响原站的SEO权重，时间长了搞不好搜索引擎也会把假的镜像站当成真的网站，而把真的网站当成假的网站。 文章给了一些反制措施，事不宜迟，跟着做起来。虽然我的网站还没有出现这种情况，但是防范于未然。 1. 在网站中添加防盗链代码 镜像站的特点就是无脑搬运原站的内容，既然如此，那就在网站中添加这么一段Javascript代码，如果当前网站的域名不是笔者的域名，就直接跳转到笔者的网站 <scirpt> (function() { var encodedValidDomain1 = 'eW9uYWdpMDQuZ2l0aHViLmlv'; // 使用Base64编码替代明文字符串`yonagi04.github.io` var encodedValidDomain2 = ' ...
简谈布谷鸟过滤器：它是比布隆过滤器更好的选择吗？
其实我一直想研究一下布谷鸟过滤器，但苦于找不到一个合适的契机。真正促使我查找布谷鸟过滤器相关的资料并决定写这篇博客的原因，还要追溯到半个月之前欢聚时代的一场面试。 面试官：“你的xxxxx功能用到了布隆过滤器，但假如是xxxx从数据库中删掉了，布隆过滤器里面的数据怎么处理？” 我：“如果是这样的话，因为布隆过滤器是无法删除数据的，所以只能在删数据之前做一个特判，然后拿一个Set之类的数据类型存起来……其实还有一个更好的解决方案，就是布谷鸟过滤器，它可以实现元素的删除，解决了布隆过滤器无法删除元素的问题……”说到这里就断了，究其本质还是对布谷鸟过滤器不太熟悉。所以想借着这个契机，和大家简单聊聊布谷鸟过滤器，以及——布谷鸟过滤器真的是比布隆过滤器更好的选择吗？ 在布谷鸟之前：布隆过滤器的缺点与展望 在开讲布谷鸟过滤器之前，我想先简单回顾一下布隆过滤器。 布隆过滤器（Bloom Filter）是一种特殊的数据结构，其本质是一个位数组和若干个哈希函数的组合。在元素存入布隆过滤器时，首先要对元素进行哈希运算，得到哈希值hash 1、hash 2、...、hash n ，然后将坐标为hash 1 ...
非常好合奏
昨晚躺在床上刷Tiktok，刷到了Ado和初音未来在最近的一次Live上的合唱……非常好合唱，使我泪流满面，平板不由自主旋转
Yonagi's Sekai祝大家1024程序员节快乐
冒泡排序，选择排序，插入排序，快速排序，堆排序，归并排序，希尔排序，桶排序，基数排序帮您排忧解难。 有向图，无向图，有环图，无环图，完全图，稠密图，稀疏图，拓扑图祝您宏图大展。 最长路，最短路，单源路径，所有节点对路径祝您路路通畅。 二叉树，红黑树，van Emde Boas树，最小生成树祝您好运枝繁叶茂。 最大流，网络流，标准输入流，标准输出流，文件输入流，文件输出流祝您顺顺流流。 线性动规，区间动规，坐标动规，背包动规，树型动归为您的规划精彩。 散列表，哈希表，邻接表，双向链表，循环链表帮您在表达喜悦。 O(n!),O(2^n), O(n3),O(n2), O(nlog n) , O(n), O(log n) , O(1) 祝大家渐进步步高 !
简谈设计模式之迭代器模式、访问者模式、备忘录模式、解释器模式
迭代器模式 迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示，类似于C++和Java的迭代器 迭代器模式结构 迭代器接口：规定了遍历元素的方法 具体迭代器：实现迭代器接口，包含遍历逻辑 聚合类：定义一个接口用于返回一个迭代器对象 迭代器结构实现 // 迭代器接口public interface Iterator { public boolean hasNext(); public Object next();}// 聚合类public interface Container { public Iterator getIterator();}public class NameRepository implements Container { public String[] names = {"Robert", "John", "Julie"}; @Override public It ...
简谈设计模式之状态模式、观察者模式、中介模式
状态模式 状态模式允许对象在内部状态改变时改变其行为, 使得对象在不同的状态下有不同的行为表现. 通过将每个状态封装成独立的类, 可以避免使用大量的条件语句实现状态切换 状态模式结构 状态接口: 声明行为方法 具体状态类: 实现状态接口, 封装具体行为 上下文类: 维护一个状态对象, 并提供方法以改变其状态 状态模式实现 // 状态接口public interface State { public doAction(Context context);}// 实现状态接口的实体类public class StartState implements State { public void doAction(Context context) { System.out.println("Player is in start state"); context.setState(this); }}public class StopState implements Sta ...
深入RocketMQ消息队列——消息原理
本文主要讲解 RocketMQ 的消息原理方面相关理论，不涉及消息的底层存储过程 消息在 RocketMQ 中流转的过程与消息可靠性的保证 在研究 RocketMQ 的消息原理之前，我们必须先了解 RocketMQ 的领域模型，以及消息在 RocketMQ 中流转的过程 RocketMQ 领域模型 如上图所示，RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费三大流程。生产者生产消息并将其发送到 RocketMQ 服务端，消息被存储在服务端的主题中，消费者通过订阅主题来消费消息 消息生产 生产者（Producer）：RocketMQ 中用于产生消息的实体，一般继承于业务调用链路的上游。 消息存储 主题（Topic）：RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平拓展是由主题内的队列实现的 队列（MessageQueue）：RocketMQ 消息传输和存储的实际单元容器。RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征 消息（Message）：RocketMQ 的最小传输单元，消息具备 ...
大刀阔斧砍掉了一些东西
文如其名，我把博客中一些不常用又影响使用体验（比如访问速度）的功能or资源给“砍”掉了 比如Chatra，这个功能自从引入之后就从来没有使用过，但是会影响正常用户的使用体验（根据我个人的实测，获取+加载Chatra的JavaScript脚本大概需要20s左右的时间，这无疑是严重影响用户使用体验的）（当然，我这个破站恐怕也没有什么用户）；比如unpkg的CDN，虽然服务器节点就在香港，但是速度并不是很理想——有时候会出现加载了十几秒甚至几十秒都加载不完资源的情况。 所以我大概做了以下几点改进： 砍掉了Chatra的实时聊天功能，毕竟作为静态博客站点，不需要也没必要使用实时聊天功能（是上周有个用户看了我的文章，通过qq私信我之后，才想到这个功能根本就用不到，毕竟我已经留了我的联系方式了） 把静态资源的CDN从原来的Unpkg修改为国内的某公益CDN 删除了一些已经不需要的资源 或许可以让本站的访问速度变得更快一点
本周面试总结
顾名思义，这篇blog就是来总结这周的面试的 这周的面试真的拉满了。上周三摔了车之后，周四就开始陆陆续续约面试。首先是广州的一家小厂和字节跳动约了面试，小厂我放在了这周一，字节放在了周二。周四的时候快手也约了面试，我放在了周六。 周一一大早我就坐着b25公交车出发去天河面试，小厂的面试体验真的很糟糕，首先就是面试官迟到，迟到了接近20min（当然，我可以接受，据说是面试官在开会），然后就是他“拷打”的一些方向让我难以理解，可能我和他解决问题的思路不太一样吧，所以最后自然也就没了下文。 周二就是字节跳动的面试，字节给我的印象就非常好：首先是HR，约面试的时间比较能尊重候选人（也就是我）的意见，在约一面之前也能介绍部门的主要工作内容；然后是一面的面试官，和我以前在acm队的时候认识的一个师兄非常相像。我和一面的面试官倒是“相谈甚欢”，所以一面结束之后很快就约了二面；二面的面试官是一个女面试官，看起来气色不太好，发际线也非常高，二面就没有那么顺利了，感觉自己缺的东西还是有点多，面试的表现也不太好，最后倒在了二面，有点可惜。希望之后还能打复活赛，打赢复活赛了再进字节吧 周六（也就是今天）下午是 ...
数据库与缓存一致性的解决方案
数据库和缓存的数据一致性问题一直是老生常谈的话题了，它不仅在面试中十分常见，而且在实际开发中也是需要加以考量的因素。借着难得的空暇时光（其实是晚上不太想写代码），笔者今天想和大家简单讨论一下，数据库和缓存的数据一致性问题，以及如何避免or解决数据库和缓存的数据不一致的问题。 为什么要引入缓存？ 在我们的后端系统没有引入缓存之前，我们的后端系统大致来讲应该是类似于这样的模型。 应用服务器中的数据库驱动通过网络I/O向数据库发增删改查操作的请求，数据库通过硬盘I/O在硬盘读/写相应数据之后，再通过网络I/O返回给应用服务器的数据库驱动，然后完成后续的业务操作。 这个模型在请求量较小的时候，是行得通的。但是当请求量变大，就会出现性能问题，而这个性能问题的瓶颈就出在硬盘I/O上。 我们都知道，内存的读写速度大于磁盘的读写速度，那么我们可以考虑将一些数据放到内存中，这样就能有效加快整体的响应速度。此时的模型应当是这样的。 对于缓存，我们有以下几个疑问： 对于缓存中存放的数据，是存放全部数据，还是存放热点数据？ 假如数据库中的数据发生了更新/删除，缓存中对应的数据要怎么处理？ 最简单的思路 ...