嗨，HN，
我开发了MBCompass，这是一款轻量级、注重隐私的Android指南针应用。它完全离线工作，不请求不必要的权限（不使用GPS，也不需要互联网），并且是开源的。
市面上大多数指南针应用都臃肿或广告繁多。我想要一个简洁、快速且功能丰富的应用，所以我做了这个！
它的大小仅约1.7MB，并使用低通滤波器来平滑传感器读数。
我非常希望能收到反馈或想法，特别是来自其他开发简单、以隐私为先的应用的朋友们！
返回首页
最新
我们正在构建TheorIA——一个开放的、高质量的理论物理结果数据集：包括方程、推导、定义和解释——所有内容都以结构化、机器可读和人类可读的JSON格式呈现。
<p>为什么要这样做？
物理学充满了美丽而严谨的结果，但大多数结果都被困在PDF、LaTeX或讲义中。这使得以下工作变得困难：
<p>- 训练符号/物理感知的机器学习模型，
<p>- 构建推导检查工具，
<p>- 甚至只是以互动方式教授物理。
<p>THEORIA填补了这一空白。每个条目包括：
<p>结果名称（例如，洛伦兹变换）
<p>清晰的方程（AsciiMath）
<p>简单明了的逐步推导及其推理
<p>符号定义和假设
<p>使用sympy进行程序验证
<p>参考文献、arXiv风格的领域标签和贡献者元数据
<p>所有内容都在开放的、自包含的JSON文件中。没有抓取，没有PDF，只有清晰的结构化数据，供物理学习者、教师和机器学习开发者使用。
<p>征集贡献者：
我们目前很小，正在努力成长。如果你对物理或符号机器学习感兴趣：
<p>添加一个条目（任何你喜欢的结果）
<p>审查其他人的推导
<p>在数据集上构建工具
<p>GitHub
<a href="https://github.com/theoria-dataset/theoria-dataset/">https://github.com/theoria-dataset/theoria-dataset/</a>
<p>本项目采用CC-BY 4.0许可，我们欢迎教育工作者、学生、机器学习从业者，或任何认为物理学值得拥有更好数据的人参与。
哪些工作将变得普遍？哪些工作将变得稀缺？
我并不预测普通程序员会被淘汰，但新冠疫情期间的招聘热潮已经过去，大型科技公司在很大程度上成功地缩减了在疫情期间招聘的员工队伍，包括前端、后端和全栈工程师。我认为，针对这些职位所需的代码模式已经被大型语言模型（LLMs）成功识别。在许多情况下，一名经验丰富的员工工程师配合一个可靠的LLM，其生产力与五年前由一名资深工程师带领的2-4名初级工程师团队相当。我不指望“传统”网页开发领域会有太多扩展（这些职位在现代形式上大约只存在了20年，差不多是在Rails首次发布的时候）。
许多人，如Amjad Masad和Beff Jezos认为，对于那些曾经会担任这些职位的人来说，选择要么是深入技术栈，向底层硬件靠拢，原因在于嵌入式工程的相对难度。我们很难想象像SpaceX火箭、波音飞机或Anduril无人机这样的高风险软件，主要依赖于匆忙编写并迅速投入生产的“感觉编码”。因此，要求大量正式、模拟或物理验证的软件似乎仍然是必要的，但这比编写网页要困难得多。在操作系统、嵌入式系统、微控制器、驱动程序等领域，编写C、C++、Rust的劳动市场扩展似乎是可能的。
另一个选择似乎是完全离开技术栈，利用小团队为小部分用户创建小众和针对性的应用程序。在这一领域也取得了一些成功，但这需要比单纯成为一名专家程序员和理解一些计算机科学更广泛的技能。
选择似乎是开始阅读Bjarne Stroustrup或Peter Thiel的书。但无论哪条路径的技能上限都相当高，短期内我预测软件工程劳动市场将持续收缩，同时人们调整他们的教育和长期职业目标。我认为FAANG公司的员工人数短期内不会恢复，甚至可能永远不会恢复。这对传统创业路径有更广泛的影响，以前在FAANG积累经验后再创业，但我偏离了主题……
我创建了 oauth2_capture（<a href="https://github.com/heysamtexas/django-oauth2-capture">https://github.com/heysamtexas/django-oauth2-capture</a>），这是一个 Django 包，旨在简化从多个提供商捕获、存储和刷新 OAuth2 令牌的过程。
该包目前支持 Twitter/X、LinkedIn、GitHub、Reddit、Pinterest 和 Facebook，未来还计划支持更多提供商。它处理整个 OAuth2 流程，从授权到令牌存储和自动刷新。
主要技术特性：
<pre><code> * 支持 PKCE（对需要此功能的提供商）
* 带重试逻辑的令牌刷新，以应对速率限制（429 响应）
* 干净的 Django 模型和管理集成
* 正确处理令牌过期
</code></pre>
我之所以构建这个包，是因为我在不同的项目中不断重新实现 OAuth2 流程，希望能有一个可重用的解决方案。该包设计得易于扩展，以支持更多提供商。
我非常希望社区能对 API 设计、代码质量或其他有用的功能提供反馈。
是的，django-allauth 在 OAuth 和用户注册/管理方面做得非常出色，但这不是它的功能。
何时使用 oauth2_capture
当您的应用需要以下功能时，请选择 oauth2_capture：
<pre><code> * 代表用户向社交媒体平台发布内容
* 使用用户权限访问提供商 API（如 GitHub、LinkedIn 等）
* 执行需要特定范围内新鲜 OAuth 令牌的操作
* 通过自动令牌刷新维持长期的 API 访问
</code></pre>
何时使用 django-allauth
当您主要需要以下功能时，请选择 django-allauth：
<pre><code> * 用户登录的社交身份验证
* 用户注册和管理
* 邮件验证工作流
* 社交提供商之间的账户关联
</code></pre>
它们可以一起使用吗？
当然可以！您可以使用 django-allauth 进行用户身份验证，而使用 oauth2_capture 进行 API 交互。它们解决不同的问题，互为补充。
简单来说：django-allauth 管理用户，oauth2_capture 管理令牌。
目前，尚无明确的方法来弃用 DockerHub 仓库。向用户传达容器镜像不再维护的信息至关重要，原因有很多。<p>DockerHub 提供了归档功能，可以将仓库标记为只读，但当你在 DockerHub 上托管超过 2 万个基础镜像时，这一过程难以自动化。<p>为了解决这个问题，我编写了一个 Playwright 脚本，自动化 DockerHub 用户界面，并批量归档 DockerHub 仓库。
是的，应该是“操作失误”而不是“搞砸了” :)
<p>临时账户
<p>---
<p>背景：一家小型初创公司，3名开发人员。公司规模在10到20人之间。
<p>我的老板因疲惫而离职，这让我实际上成为了临时首席技术官。我们称他为赫淮斯托斯[1]。我更像是一个开明的个人贡献者，某种程度上感到自己有些力不从心。
<p>当雨下起来时，倾盆而下。我们的前首席技术官离开时，我们的项目经理——她非常出色——也开始了产假。我们有了新的项目经理，但她并不能完全胜任。除了我和非技术背景的首席执行官，组织中的其他成员在这里的时间还不够长，尚未能分担重任——他们正在努力适应！我还有一位非常棒的开发人员，另一位则是在我老首席技术官的影子角色下被聘用的——他是在合同签署之前就被招募的。不幸的是，经验表明他经验不足，我发现自己不仅要在他作为开发者的贡献上弥补不足——他充其量也只是中级水平。我们称他为科阿莱莫斯[2]。
<p>*好的方面：*
我们设法保持了工作的进展——我们找到了一种适合大家的方式来组织待办事项，因此项目进展顺利。
<p>*坏的方面：*
我感到力不从心的地方是……我们可以称之为行政管理？当我的首席技术官离开时，科阿莱莫斯负责赫淮斯托斯的离职手续，我认为他做得很糟糕。
赫淮斯托斯是我亲密的朋友，但在他离开后的头几个月，我甚至无法和他进行对话——他不清晰，常常在同一个小时内重复同样的故事多次。
现在他好多了，至少能说话和表达，但我尽量不和他谈太多工作上的事情，以便他能安静恢复。
有一次，我们在工作中经历了一些……痛苦的事情后交谈，他说他已经指示科阿莱莫斯：
1. 永远不要停用Google工作区管理员账户，
1.1. 而是将他们从所有设备上注销
1.2. 为该账户移除双重身份验证
1.3. 为该账户设置密码。
<p>然而，科阿莱莫斯却停用了赫淮斯托斯的账户，并将赫淮斯托斯的所有邮件重定向到他自己的收件箱。
<p>这只是科阿莱莫斯做过的多项事情之一，而这些事情他显然被指示过“不要”去做。
<p>对于Google账户和其他账户，有没有一些通用的经验法则可以帮助我避免今后出现这些操作失误？
<p>比如，如果我必须自己处理科阿莱莫斯的离职，我应该怎么做？
<p>我的经验更多是在清理`authorized_ssh_keys`和Shamir密钥轮换方面。这……并不相同。
<p>---
<p>[1] 赫淮斯托斯是希腊的疲惫之神： https://paleothea.com/gods-and-goddesses/hephaestus-god-of-burnout
[2] 科阿莱莫斯是愚蠢的化身 https://en.wikipedia.org/wiki/Koalemos#:~:text=In%20Greek%20mythology%2C%20Koalemos%20(Ancient,in%20Parallel%20Lives%20by%20Plutarch.