最新

介绍 sqlxport：在几秒钟内将 SQL 查询结果导出为 Parquet/CSV，并可选择上传至 S3 或 MinIO。<p>支持 PostgreSQL 和 Redshift 以命令行优先，适合云环境 非常适合数据管道和工程师使用

AI搜索结果正迅速变得比SEO更为重要，但作为企业，我们对此却没有任何可见性！这就是我正在构建“AI搜索结果的Ahrefs”的原因。<p>跟踪在ChatGPT、Claude、Perplexity等AI工具上的关键词表现。

在数字干扰无处不在的今天，我们常常需要在标签、消息、电子邮件、文献、提示大型语言模型等之间频繁切换，这让我觉得在高优先级任务上保持深度专注变得比以往任何时候都更加困难。对于那些在这方面感到挣扎的人来说，主要的压力来源是什么？你是如何应对这些压力，以最大化工作时的生产力的？

我28岁，老实说，到目前为止我在生活中并没有做太多事情。最近，我在网上偶然接触到了编程和网络安全，这两个领域的积极面貌真的吸引了我的注意。我一直对解决问题保持耐心，实际上我也很享受这个过程。这让我有一种成就感。我也算是比较懂技术，经过一段时间，我感觉自己可能找到了一个我可以真正擅长的领域。 问题是，我并没有条件去上大学或参加任何正式的机构。我看到过一些关于人们在线学习并进入科技行业的故事，但我也读到过很多负面的看法。即使是毕业生，有时也很难找到工作。 所以我真的很想知道：如果我下定决心学习并努力工作，实际上我有机会在没有学位的情况下改变我的生活，进入编程或网络安全领域吗？

我一直在申请一些在“谁在招聘”上发布的职位（EM），结果连面试都没有就被拒绝了，然后这些职位又一次又一次地重新发布。我能接受自己不是最佳候选人，但我无法理解在几个月内竟然没有一个候选人足够优秀，这到底是怎么回事？

嗨，HN！我们刚刚发布了一个开源的 React 打包插件，使应用程序在构建时支持多语言，而无需修改代码。 React 应用程序的本地化通常需要实现国际化（i18n）框架、将文本提取到 JSON 文件中，并将组件包裹在翻译标签中——基本上是在开始翻译之前，需要重写整个代码库。 我们的 React 打包插件完全消除了这种摩擦。您只需将其添加到现有的 React 应用中，指定所需的语言，它便会自动使您的应用程序支持多语言，而无需触及组件代码的任何一行。 以下是一个展示其工作原理的视频： [https://www.youtube.com/watch?v=sSo2ERxAvB4](https://www.youtube.com/watch?v=sSo2ERxAvB4)。文档可以在 [https://lingo.dev/en/compiler](https://lingo.dev/en/compiler) 找到，示例应用在 [https://github.com/lingodotdev/lingo.dev/tree/main/demo](https://github.com/lingodotdev/lingo.dev/tree/main/demo)。 去年，我们 Twitter 社区的一位开发者告诉我们：“我不想用 `<T>` 标签包裹每个 React 组件，也不想将字符串提取到 JSON 中。我能否只包裹整个 React 应用并使其支持多语言？” 我们最初的反应是：“这不是 React 中 i18n 的工作方式。”但几个小时后，我们发现自己深陷技术难题，开始思考如果这真的是可能的呢？ 这个问题促使我们构建了“本地化编译器”——一个用于 React 的中间件，它接入代码库，处理 React 代码的抽象语法树（AST），确定可翻译的元素，将每个上下文边界输入到大型语言模型（LLMs）中，并将翻译结果嵌入构建中，使用户界面在几秒钟内实现多语言支持。 所有操作都在构建时本地进行，保持 React 项目作为真实来源。无需修改代码、提取内容或维护单独的翻译文件，但可以通过 data-lingo-* 属性进行覆盖。 构建这个插件比我们预期的要复杂。除了遍历 React/JS 的抽象语法树外，我们还必须解决一些具有挑战性的问题。我们希望找到一种方法，确定应该一起翻译的元素，以便例如，包裹在 `<a>` 链接标签中的短语不会因为被孤立处理而被误翻译。我们还希望检测内联函数调用，并在编译时代码生成过程中优雅地处理它们。 例如，这整个文本块被我们的本地化编译器识别为一个单一的翻译单元，保留了 HTML 结构和上下文，以供大型语言模型使用。 ``` function WelcomeMessage() { return ( <div> Welcome to <i>our platform</i>! <a href="/start">Get started</a> today. </div> ); } ``` 最大的挑战是使我们的编译器与热模块替换（Hot Module Replacement）兼容。这使得开发者可以用英语编写代码，同时即时看到西班牙语或日语的用户界面，这对于捕捉由于文本扩展或收缩而导致的布局问题非常重要，因为不同语言在屏幕上占用的空间不同。 为了提高性能，我们实现了激进的缓存机制，存储 AST 分析结果，并仅重新处理已更改的组件。增量构建在大型代码库中依然保持快速，因为开发者在任何时候只更新有限数量的组件，并且我们对大型语言模型的调用进行了大量并行化。 在大型语言模型出现之前，这种方法在技术上是可行的，但在实际中几乎没有用，因为要获得精确的翻译，仍然需要熟悉产品领域的人类翻译者。然而，现在，借助上下文感知模型，我们可以自动生成不错的翻译。 我们很高兴终于使其准备好投入生产，并与 HN 社区分享这一成果。 运行 `npm i lingo.dev`，查看文档 [lingo.dev/compiler](https://lingo.dev/compiler)，尝试破坏它，并告诉我们您对这种 React 国际化方法的看法！