之前写过《Android｜集成 slf4j + logback 作为日志框架》，最近在给手上的另外一个 Android 项目添加 logback 日志框架时，遇到一个导致无法输出日志到文件的问题，也耽误了不少时间，这里记录一下。 现象 代码里通过 @Slf4j 注解注入 logger，正常 log.info(xxx)，但是程序启动后，发现没有生成日志文件。 排查 检查配置文件 有前一个项目的成功经验，我直接复制了之前项目的配置文件，只是将日志存储文件夹修改为了 ${DATA_DIR}/log，其中 DATA_DIR 变量是指代 Context.getFilesDir()，它也不存在权限申请之类的问题。测试了将它写死成一个绝对路径，也没有日志文件生成。 基本排除配置文件的问题。 打开 logback 的 debug 模式 将 logback.xml 文件的根元素 <configuration> 添加 debug="true" 属性，重启程序，查看 logcat 输出，发现如下异常： 11:34:06,785 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[local_file] - Failed to create parent directories for [/log/app.log] 11:34:06,786 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[local_file] - openFile(/log/student.log,true) failed java.io.FileNotFoundException: /log/app.log: open failed: ENOENT (No such file or directory) at java.io.FileNotFoundException: /log/student.log: open failed: ENOENT (No such file or directory) ... at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:416) at at org.mazhuang.OnlineApplication.<clinit>(OnlineApplication.java:21) 初始化日志文件路径失败，但是输出的日志文件路径是 /log/app.log，而不是我配置的 ${DATA_DIR}/log/app.log，这里有问题。 可以看出是 logback 没有正确解析 ${DATA_DIR} 变量，导致日志文件路径错误。但是为什么会这样呢？并没有什么头绪，难道是 logback 的 bug？ 检查 logback-android 的 wiki 在想了好久仍然没有头绪之后，浏览 logback-android 的 wiki，发现在介绍 DATA_DIR 等变量的地方，有这么一段以前没留意的描述： Note these special properties are initialized when the first logger is instantiated (i.e., via LoggerFactory.getLogger()), but that must be done when the application context is available (e.g., in the onCreate method of your Application class or at any point thereafter). Otherwise, the special properties will resolve to empty strings. 这段话大意是，DATA_DIR 等这些变量，是在第一次调用 LoggerFactory.getLogger() 时初始化的，但是必须在 application context 可用之后（例如在 Application 类的 onCreate 方法中或之后的任何时候）。否则，这些变量将解析为空字符串。 结合上面异常堆栈里的信息，可以判断是因为在 Application 类的类初始化（clinit）过程中调用了 LoggerFactory.getLogger()，此时 application context 还不可用，导致 logback 无法正确解析 ${DATA_DIR} 变量。 进一步探究 而为什么 Application 类的类初始化过程中会调用 LoggerFactory.getLogger() 呢？检查代码，发现是在自定义 Application 类及其基类中使用了 @Slf4j 注解，这个注解会生成一个静态的 logger，而这个 logger 的初始化会调用 LoggerFactory.getLogger()——太早了。 参见 @Slf4j 注解源文件里的注释： Causes lombok to generate a logger field. Complete documentation is found at the project lombok features page for lombok log annotations . Example: @Slf4j public class LogExample { } will generate: public class LogExample { private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class); } 解决 去掉自定义 Application 类及其基类上的 @Slf4j 注解，如果需要在 Application 类里打印日志，改为在 onCreate 方法中手动初始化 logger。 又一次印证了认真阅读文档的重要性。:cry: 参考 https://github.com/tony19/logback-android/wiki#special-properties-for-xml-config
在一个早醒的清晨，思绪突然蔓延到「听歌」这个词上。 印象里是上初中后才喜欢上听歌，那时候音乐介质还是磁带。印象比较深的是有一次和几个小伙伴骑自行车去相邻的镇上玩，到地方之后下起了毛毛细雨，他们在喧闹的小摊边买吃的，我囊中羞涩，只好谎称不饿，在背过身等他们的时间里，被不知道哪个方向传来的歌声所吸引，其中有两首的旋律听着挺带劲，不久后在一张盗版磁带里又听到了它们，是《雨一直下》和《单身情歌》。 盗版磁带的好处之一是一盒磁带里能给你凑齐年度金曲，坏处之一是歌词可能印错，《兄弟》的第一句印的是「轻轻的风，像旧梦的声间」，让我纳闷了好久，等到学会五笔打字后才反应过来他是把「音-ujf」打成了「间-uj」。 后来上了高中，周末的晚自习前可以用班里听英语听力的大录音机放歌，那是最松弛的时光。有自告奋勇者也可以上讲台去唱，那时的我远比现在还要自卑又内向，但竟然能壮着胆子上去唱歌，堪称人生的几大奇观之一。 高一时同学带我去上网，申请了个人的第一个 QQ，网名叫做「痛哭的人」，那是伍佰的一首歌。还写过歌词，偷偷给老林的邮箱投稿，结局当然是音信全无。几年间省吃俭用，买齐了所有能买到的伍佰和那时才出道不久的老林的专辑，谁料 MP3 开始流行，高中毕业后不久，连同单放机都不知道被丢到哪个角落去了。 中学时期可能是青春里最迷惘的一段岁月，有一些夜里我总是戴着耳机入睡，拼命地听歌，仿佛听懂了那旋律，就能驱散心头的迷雾，读懂了那歌词，就能明白了爱情。不过现在想来，那时候虽然迷茫，但未来却像问号一样，未知的同时仿佛有着无限可能。如今，过去的未来已成过去，现在的未来却很难说有多么令人期待。 时间轴上离现在最近的大学、参加工作的阶段，在听歌这件事上，留下的能轻易唤起的回忆却并不算多。没有了来自师长和学业的压力，它自然而然地融入了生活，成为了日常的一部分，就像现在读小说，远没有上晚自习时偷偷在书桌下读，生怕被班主任发现那么紧张刺激了。 第一次去听演唱会是在大四，同学临时搞到两张便宜的黄牛票，去洪山体育馆听羽泉，离舞台老远，但结束时嗓子还是喊哑了。后来伍佰到长沙开演唱会，斥巨资买了内场票，和媳妇一起从武汉过去听，兴奋地拍了好多视频，回酒店一听全是我自己的声音。 到现在歌单里最多的，还是年少时最喜欢的那几位歌手的歌，再加上一些影视金曲。不知是缺失了对新生代音乐的兴趣，还是它们确实少了些味道，除了能偶尔被动学会哼唱几句当前的抖音神曲副歌，很少学会什么新歌了。 而今最常见的听歌场景，是在最不想被人打搅的编码时刻，打开播放器，戴上耳机，任手指翻飞，沉浸在和机器的交互里，耳边传来的旋律都很熟悉，熟到不用分心去分辨歌词与音符。 为什么听歌这件事会突然闯进思绪，我想，无非是想起了和它有关的那些人和那些事吧。
这是这个系列的第四篇文章，之前写了： 读书｜程序员如何传书到 Kindle 读书｜通过 Git 管理 Kindle 屏保图片，一键自动同步 读书｜通过 SSH & SFTP 管理 Kindle 上的文件 本文介绍如何通过免费云盘传书到 Kindle——这已经成为我目前最喜欢的传书到 Kindle 的方式了。 使用效果 在电脑/手机等设备上，通过坚果云 APP 或 网站，上传书籍到云盘； 在 Kindle 上，从云存储下载书籍。 一上一下之间，摆脱了 USB 线缆的束缚，Kindle 和电脑/手机之间也不受地理位置、局域网和时空限制，非常方便。 配置方法 KOReader 官方 Wiki 上对此有说明，链接：https://github.com/koreader/koreader/wiki/%E4%BA%91%E7%9B%98%E5%AD%98%E5%82%A8 大意就是 KOReader 支持 Dropbox、FTP、WebDAV 三种云存储，其中在国内可用又免费的，可以选择坚果云提供的个人免费版 WebDAV 服务。 前提 Kindle 已经越狱，并且已经安装了 KOReader。这部分如有需要，可以参考书伴网站上的相关链接来操作： https://bookfere.com/post/311.html 坚果云配置 网址：https://www.jianguoyun.com/ 注册并登录后，点击网站右上角用户名，选择「账户信息」，然后打开「安全选项」，在「第三方应用管理」里，「添加应用」，名称随意，如「koreader」，然后生成密码，可以得到 服务器地址、账户、应用密码。 在「我的文件」里，创建一个文件夹，取名 ebooks。 Kindle 配置 打开 KOReader，在非书籍阅读状态下，调出顶部主菜单，点击「设置」-「云存储」： 点击左上角的 + 号，选择 WebDAV： 填入 WebDAV 信息，服务器显示名称随便取，如 jianguoyun，WebDAV 地址、用户名、密码分别填入上面坚果云生成的信息，注意密码是应用密码，起始目录填入 /ebooks，然后「保存」。 至此，配置其实就已经完成了。 使用 在找到所需的电子书资源后，可以随时通过坚果云网站或 APP 上传到 ebooks 文件夹下。 然后在需要的时候，在 Kindle 上打开 KOReader，非阅读书籍状态调出顶部菜单，点击「设置」-「云存储」，选择 jianguoyun，即可看到 ebooks 文件夹下的书籍，点击下载即可。 坚果云个人免费版服务，每月有 1GB 的上传流量和 1GB 的下载流量，对于传书来说，绰绰有余。有条件也可以升级付费服务，将坚果云用于更多的用途。 工具只是为了提升体验，Kindle 的意义在于阅读，希望大家都能享受到阅读的乐趣。
我在去年八月份给 GitHub 写信，举报了一个滥用「Used by」特性的事件，GitHub 一直没有给我回信。但是实际上，他们已经悄悄地更新了。 原始事件可以参考当时的记录：发现一种增加在 GitHub 曝光量的方法，已举报，简单来说就是有人在自己的项目里虚假声明自己依赖了大量知名项目，包括很多无法作为依赖包的项目，从而让自己的头像展示在这些知名项目的「Used by」栏目里。 最近留意了一下，发现我的一个 Star 数量较多的项目 awesome-adb 旁边已经不再展示「Used by」栏目了——本来就不应该展示。 翻阅了 GitHub 的 docs 更新记录，发现了这样一次 提交： 从这段文档里可以看到，一个项目是否展示「Used by」栏目，原本是需要满足以下三个条件： 项目的 dependency graph 是启用的； 项目包含有发布在受支持的包管理系统里的 package； package 在包管理系统上的资料里，源码链接指向该公开项目； 其实……原本这三个条件如果都认真执行的话，那些无法作为依赖包的项目是不会展示「Used by」栏目的，可事实是在我发信举报的那段时间，是会展示的，这就给滥用行为提供了空间。 而这次更新，GitHub 给「Used by」栏目展示又加上了一个条件： 超过 100 个项目依赖你项目的 package； 这样做的效果，至少能让那些滥用者的头像不会作为几分之一，显眼地出现在知名项目的「Used by」栏目里了，要么不出现，要么就与至少上百个人一起出现，也就是说，他们的滥用行为的曝光/收益会大打折扣了。 虽然跟我期待的处理不太一样，但好歹也算是有进步了。希望 GitHub 这次不只是加上了这个第四条，而是将前面三条也更认真地执行了，这样才能更好地避免滥用。 当然我还有个疑惑，为什么不给我回信？:thinking:
距离推送 《GitHub 用户福利，符合条件可领取约 1500 元现金》 这篇文章已经过去快一个月了，虽然 STRK 空投到六月份才过期，但我领过以后就没再继续关注了，几乎已经淡忘了此事。 今天查收了一下 Gmail 邮件，却意外发现了这个： 这应该是有人根据 GitHub 上的资格名单，批量获取到有资格领取空投的人的邮箱地址，然后群发的邮件。 按当时一份空投最终能领取到 RMB 1500 元左右计算，如果有一个人愿意让他帮忙领取，就可以收益约 300 左右。超广撒网，应该也有一部分人嫌麻烦，愿意找人帮忙操作的。 如果群发了一万封邮件，有百分之一的人愿意通过他来领取，无本套利三万块到手，是自己能领的一千五的几十倍了，妙啊……活该别人赚大钱 :laughing: 这带来了一点点启发： 当发现好的机会时，应当果断地参与其中； 即使无法直接参与，也可以思路打开一点，看看有没有什么配套/上下游可以做，也许就能从趋势的洪流里，分到一杯羹； 保持对每个机会都进行以上思考和分析。
我们先来看一下现象： 实际上 1900 年不是闰年，没有 2 月 29 日，所以很明显 这是 Excel 的一个 Bug。 发现 我之所以会留意到这个，是因为最近在做一个绩效核对的小工具，需要用 Python 读取和处理销售交上来的 Excel。 销售交上来的东西总是稀奇古怪，比如有一列是要填日期，交上来的表格里，有的读出来是日期类型，有的读出来是字符串类型，这都还好说，日期类型直接用，字符串按格式解析成日期，就好了。但这天发现有个销售交上来的表格里，这一列读出来是数字类型。 比如 2024-02-01，读出来对应数字 45323。 怎么将这个数字转换成日期呢？ 首先搜索了微软的官方文档，找到关于 Date systems in Excel 的说明： Excel supports two date systems, the 1900 date system and the 1904 date system. Each date system uses a unique starting date from which all other workbook dates are calculated. All versions of Excel for Windows calculate dates based on the 1900 date system. Excel 2008 for Mac and earlier Excel for Mac versions calculate dates based on the 1904 date system. Excel 2016 for Mac and Excel for Mac 2011 use the 1900 date system, which guarantees date compatibility with Excel for Windows. … In the 1900 date system, dates are calculated by using January 1, 1900, as a starting point. When you enter a date, it is converted into a serial number that represents the number of days elapsed since January 1, 1900. 就是说，除了 Excel for Mac 的早期版本外，都是默认采用 1900 date system，以 1900-01-01 作为起点（第 1 天）。 于是根据这个信息写一个函数来将数字转换成日期，但是 翻车了…… from datetime import datetime, timedelta def int_to_date(s): date_zero = datetime(1900, 1, 1) delta = timedelta(days = s - 1) return date_zero + delta print(int_to_date(45323)) # 输出 2024-02-02 00:00:00 Excel 表格里是 2024-02-01，读出来是 45323，咋按 1900-01-01 作为第一天，反算出来 45323 却是 2024-02-02 了呢？ 探究 于是一番搜索，先是找到了 OpenOffice 论坛里的讨论 Why the base date is 1899-12-30 instead of 1899-12-31?，里面有如下信息： The earliest date Excel handles sensibly is 1900-01-01, which is “day 1” (not zero). This makes “Excel epoch” (day zero) 1899-12-31. However, Excel inherited an error from previous spreadsheet apps which assumed that 1900 was a leap year. The nonexistent 29th of February 1900 is counted in Excel time spans, just like it used to be in Lotus 123 and (IIRC) SuperCalc, and probably in most other relevant spreadsheet apps. 有意思了……于是继续在维基百科的 Microsoft Excel 词条上找到了佐证信息： Excel的时间系统中，会认为1900年2月29日是有效日期，也就是1900年为闰年，但实际上并不是。这是源于模仿早期竞品Lotus 1-2-3上的缺陷而引入的特性，由于Lotus 1-2-3的时间纪元以1900年起始，之后的时间为差值累加，导致其时间体系一开始就认为1900年是闰年，而Excel为了兼容Lotus 1-2-3的文件格式，也保留了这个缺陷作为特性而不进行修复，即使至今最新版本已不需要兼容Lotus 1-2-3。 里面还给出了微软官方的相关解释链接：Excel incorrectly assumes that the year 1900 is a leap year，并且讲述了 Excel 的发展历史，挺有趣的，可以一读。 至此，就破案了。 数字到日期的换算 我们上面提供的数字到日期的换算的方案，做个小修正就能使用了： from datetime import datetime, timedelta def int_to_date(s): date_zero = datetime(1899, 12, 30) delta = timedelta(days = s) return date_zero + delta print(int_to_date(45323)) # 输出 2024-02-01 00:00:00 当然这个程序并不完美，比如计算 60 以内的数字，算出来的就与 Excel 上显示的日期不一致，但 who cares……毕竟 Excel 上有 1900-02-29 这种你永远不会用到的日期 :laughing: 参考链接 https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487 https://forum.openoffice.org/en/forum/viewtopic.php?t=108820 https://zh.wikipedia.org/wiki/Microsoft_Excel https://learn.microsoft.com/en-US/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year
背景 我的公众号里前几天发的一篇文章小火了一把，阅读量到了 5000+（看官您别笑，对于我这种没什么流量的号，这已经是顶流了）。 想着看看我的号里哪些内容最受欢迎，于是翻了一下历史群发文章的数据统计，阅读量最高的是这两篇： GitHub 用户福利，符合条件可领取约 1500 元现金 ——2024/02/27 GitHub 用户专属福利，实际到账 3K+，Namebase Airdrop ——2020/02/21 都是关于空投和钱的，而且最近也陆续有一些网友加我微信，咨询如何能获得类似空投的领取资格——和家人交流了一下，猜想可能是因为经济下行，大家关心的都是如何搞钱存钱。 我算是比较幸运的，这两次空投都有领取资格，在不需要额外付出什么成本的前提下，合计入账了 RMB 5000+，在如今挣点钱并不容易的大环境下，还是很香的。 我猜想后续这样的空投应该也还会出现。我就趁机在此，就大家普遍关心的话题，把我的理解小结一下，供大家参考。 分析 首先看一下作为一名 GitHub 用户，这两次空投领取资格 门槛 分别是怎么样的。 2024 年初的 Starknet 空投： 你在 2023-11-15 前，向整个 GitHub 上 star 数 top 5000 之一的项目至少贡献过 3 次 commit； 至少有一次 commit 发生在 2018 年及以后。 2020 年初的 Namebase 空投： 在 2019-02-04 这一天所在的那一周，你的 GitHub 账号有 15 个以上的 followers； 保留有当时的 SSH / PGP 私钥。 从中我提取到的关键词是 贡献 和 影响力。 这些机构空投给 GitHub 用户，我估计一方面是回馈开发者，特别是参与构建与它们的项目相关的基础设施和技术项目的开发者，鼓励创新，另一方面也是借此扩大它们项目的影响力，吸引更多的人关注和参与进来。 建议 虽然说不准未来的空投会采取什么样的角度来制定领取资格门槛，但我们从现在开始着手「埋伏笔」肯定是必要的。 接下来是对在 GitHub 活动的建议，其实就是三板斧——从 GitHub 学、在 GitHub 练、向 GitHub 作贡献。 一、从 GitHub 学： Follow 你感兴趣的领域厉害的人物，持续关注他们在 GitHub 上的活动，学习他们的协作方式，了解他们关注的优秀项目和资料； 找到与你工作和学习相关的有影响力的项目，挑选感兴趣的，进行深入学习； 学习并掌握 GitHub 的工作流，学习版本控制、Issues、Pull Request 的规范； 在需要寻找开源库或工具时，优先上 GitHub 搜索。 二、在 GitHub 练： 将你自己的玩具项目源码大胆发上去，不断用你学习到的优秀的模式和架构对它们进行重构，形成你个人比较固定的流程和规范； 使用 GitHub Pages 搭建自己的个人主页和博客，勤记录和分享笔记与心得。 三、向 GitHub 作贡献： 创建你自己的实用项目，并长期维护——可以是代码，也可以是清单、文档、手册； 在发现你使用的开源项目的问题或漏洞时，参考下面的流程去寻求帮助或协助解决，即使只是帮助修正了文档里的一处语法错误，这个世界也因你而变得更加完美了一点点： 小结 看到这里，可能有的朋友会问，「如果我都有这个能力和影响力了，还在乎空投这仨瓜俩枣？」 是的，你说得对，如果你依上面的建议提升了自己的能力，构建了自己的项目和影响力，给开源社区贡献了自己的力量，你所获得的有形和无形的收益可能远超自己的想象。 面对新的空投，你将有选择的自由。
后端程序员的前端笔记，含金量，你懂的 :-P 需求 网页端实现动态搜索选择框，要求： 下拉选项列表能根据用户输入内容动态刷新； 最终提交的值必须是由选项列表中点选的； 基于 Layui。 方案 一开始根据印象里常见的搜索选择框的样式，一直在探索如何基于 <select> 来实现。Layui 的搜索选择框并没有暴露监听输入内容的事件接口，在网上找到了两个思路，但实现得都不够完美。 一是参考 https://www.cnblogs.com/zqifa/p/layui-select-input-1.html，在 <select> 上覆盖一个 <input>，监听 <input> 的输入内容然后触发模糊搜索，进而触发更新 <select> 的选项列表。可以基本达成需要的效果，有一个问题是选择列表展示后，必须选择一项才能关闭选项列表，而期望是点击空白区域选项列表自动关闭。 二是参考 https://gitee.com/layui/layui/issues/I6N5MZ，监听经过 Layui 渲染 <select> 后生成的 <input> 元素的事件，进而触发选项列表的刷新。这个方案的思路是挺好的，但是同样有一些小问题，比如下拉选项的展示/隐藏、输入焦点、输入内容保持等，都需要自己一一去干预。 这时在 Layui 的仓库找到 这个 Issue，贤心大大这样回应网友「能不能在选择框上加上可输入可下拉可搜索」的提问： select 组件的定位就是只能赋值选项列表中的值，包括搜索，也只是从选项中匹配。若要支持自定义输入的值，可以借助 input + dropdown 组件来自定义实现哦。 受此启发，我又思考了一下需求里的「搜索」： 我们的下拉选项列表完全由后端根据输入内容返回； Layui 的 select 搜索选择框的搜索，是根据输入内容匹配现有候选列表，纯前端行为； 看了下 Layui 文档后发现 dropdown 有专门的 reloadData 的 API，经尝试后最终选择了基于 Layui 的 dropdown 组件来实现。 实现 效果如下： 示例代码如下： 其中 mockData 实现应按需替换成 ajax 请求，成功拿到数据之后再 reloadData； 表单提交时需要使用 id 作为参数值，可以在 click 的时候给 input 添加自定义属性如 data-id，在输入监听事件里删除该属性值。 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Demo</title> <link href="https://unpkg.com/layui@2.9.6/dist/css/layui.css" rel="stylesheet"> </head> <body> <div class="layui-inline layui-padding-5"> <input name="" placeholder="请搜索或选择" class="layui-input" id="ID-dropdown-demo"> </div> <script src="https://unpkg.com/layui@2.9.6/dist/layui.js"></script> <script> layui.use(function(){ var dropdown = layui.dropdown; var $ = layui.$; var inst = dropdown.render({ elem: '#ID-dropdown-demo', data: [], click: function(obj){ this.elem.val(obj.title); this.elem.attr('data-id', obj.id) } }); $(inst.config.elem).on('input propertychange', function() { var elem = $(this); var value = elem.val().trim(); elem.removeAttr('data-id'); var dataNew = mockData(value); dropdown.reloadData(inst.config.id, { data: dataNew }) }); $(inst.config.elem).on('blur', function() { var elem = $(this); var dataId = elem.attr('data-id'); if (!dataId) { elem.val(''); } }); function mockData(value) { return [ {id: 1, title: value + '1'}, {id: 2, title: value + '2'} ]; } }); </script> </body> </html> 小结 冷静地想清楚自己的需求和场景，有助于更快找到合适的组件和方案。
看到公众号沉默王二发的一篇文章 《GitHub赚了211美刀后的感触》，用自己的 GitHub 账号尝试了一下，1500 元现金到账，有兴趣的朋友们可以一试。 省流 Starknet 基金会启动了第一轮 Starknet 供应计划，将向近 130 万个地址分发超过 7 亿个 Starknet 代币（STRK），其中有 2.1% 分发给开源开发者。STRK 可以理解为一种数字货币，领取到后可以通过交易转换成现金。 可以通过 https://provisions.starknet.io 网站查询是否有资格领取 STRK。 Update 2024/02/29 ref https://www.guozaoke.com/t/107113#reply7 符合条件的 GitHub 用户可以在下面两个文件之一搜到自己的 ID： https://raw.githubusercontent.com/starknet-io/provisions-data/main/github/github-0.json https://raw.githubusercontent.com/starknet-io/provisions-data/main/github/github-1.json 如果发现有资格，可以继续阅读；如果没有资格，就不用浪费时间继续看了。另外，可以推荐给你在 GitHub 活跃的朋友试试。 领取资格查询 打开 https://provisions.starknet.io/ 网站； 往下翻，找到 Eligibility check only 链接，点击打开： 切换到 GitHub，输入 GitHub 用户名，点击 Go： 如果有资格，会看到如下界面： 点 See your allocation，会看到能领取的 STRK 数量： 领取 STRK 在上面领取资格查询的最后一步点击 Disconnect，会回到第 2 步界面，点击 Claim STRK； 勾选，Confirm： 选择钱包，我这里用的 Argent X，根据提示下载安装浏览器插件，生成一个钱包地址： 选择 GitHub，Sign in： 按提示操作，看到如下界面就是领取成功了： 转换成现金 注册一个数字货币交易所账户，建议选择头部交易所，如币安、欧易，我使用的是 欧易（OKX）； 在 OKX 的资金账户里 充币-选择 STRK-生成充币地址，选择将资金充入交易账户，复制充币地址： 打开之前安装的 Argent X 钱包浏览器插件，点击 Send，输入充币地址，填入 STRK 数量（可以点击 Max 选择最大转出数量），点击 Review send： 稍等一小会，刷新 OKX 应该就能看到 STRK 充进来了，在交易菜单里找到 币币，搜索 STRK/USDT，点击后输入数量，市价卖出： 资金划转，将 USDT 从 交易账户 转到 资金账户； 买币-快捷买币-出售，USDT to CNY，全部出售，支付宝收款，支付宝到账后确认并放币即可，我最终到账 1533.8 元人民币。 小结 天上不会掉馅饼，但是定向投放的合法福利，我们要接住！ 类似的空投，2020 年初也经历过一次，当时也有记录：GitHub 用户专属福利，实际到账 3K+，Namebase Airdrop，当时是将 HNS 转换到 BTC 然后提现的，本次操作时看了下，BTC 的价格相对当时翻了约五倍，所以……将数字货币留着不提现，等增值也是一种思路。 在 Starknet 的网站上，有提到空投给 GitHub 用户的原因： In addition, STRK will be distributed to those who helped to develop the larger ecosystem of open-source software and infrastructure, as their work has become a public good and contributed to the emergence of a more open and inclusive web. 所以如果你符合领取资格，你必然也曾为构建有影响力的开源软件和基础设施贡献过力量，这是你应得的！ 参考链接 https://www.starknet.io/en/content/starknet-provisions-program https://provisions.starknet.io https://zhuanlan.zhihu.com/p/683415610 https://mp.weixin.qq.com/s/bnHpkDMzUyIFzmGk9r4ByA
前一阵把家里的 Filco 圣手二代机械键盘单模改三模后，体验挺不错，想着改装的工具买了只用一回也比较浪费，顺手把放公司用的 ikbc C87 也改了吧。 本次仍然使用与之前相同的方案，具体方案及操作过程可以参考 DIY｜Filco 圣手二代机械键盘单模改三模，以及里面列举的参考链接，在此不展开，重点小结一下改装过程及使用过程中的一些新的体会。 改装过程因为有了改装上一把的经验，本次更加熟练和顺利，但也得到了两点新经验： 为了开拓底板上安装模块和电池的空间，一般会干掉一些栅格，使用美工刀+尖嘴钳能很轻松完成； 钻孔的时候，把底板和上盖扣在一起后再钻，可以避免孔位没对齐的尴尬。 施工图： 改装完到现在也使用了一个多月了，结合我自己的体验以及网友在上一篇文章的留言，有个痛点是续航。 续航应该是取决于电池容量、使用强度、键盘本身和改装模块的耗电情况等，与厂家量产的原生三模还是有非常明显的差距的。比如我手上的两把： Filco 圣手二代 87 键，塞进 5000mAh 电池，放在家低频度使用，充一次电用两个月应该没问题； ikbc C87，使用 3000mAh 电池，放在公司高强度使用，充一次电只能使用一星期左右。 有点电量焦虑。 所以，现在如果有人问我要不要把手上的键盘自己有线改无线，我的建议是，如果能找到手感合适价钱合适的，直接买一把新的吧 :-P