关于使用大型语言模型（LLMs）学习是否能让你成为一个优秀程序员，是否有共识？还是说，或许你应该采用传统的方式，通过阅读手册和不断攻克问题来学习？
返回首页
最新
嗨，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 仓库。