最新

过去几天，我一直在听 Lex 采访 DHH（只听了编程部分，我对他在其他话题上的观点不太感兴趣）。 这已经不是我第一次听到人们称赞 Ruby on Rails 了，但每次我查看文档时，我都会想：“我不明白为什么人们会喜欢它。” 我对 Ruby 的主要批评是： * 语法不太好：它使用了大量的特殊字符，这使得编写代码的速度变慢。 * 没有静态类型：当我刚开始编程时，动态类型（比如 JavaScript 中的）似乎很酷。但在大型企业项目中工作之后，我再也不会选择动态类型语言了（根据 DHH 的说法，这可能让我成为一个“糟糕的开发者”）。 我还没有亲自尝试过它，主要是因为将编程语言用于业余项目和专业产品是完全不同的体验（有人可能会尝试 JavaScript 并认为它比 TypeScript 更好，直到他们不得不重构某些东西）。 所以我想知道，这是否是那种工具主要被一小部分狂热爱好者使用的案例，所以所有的反馈都是正面的？还是说，一旦你深入了解 Rails，它真的像 DHH 说的那样好用？

作为一个没有 STEM 学位，并且主要靠自学的人，我很想听听你们的类似经历。 你的故事是什么？ 你现在在做什么？ 你做这件事多久了？ 等等，等等。

我的网站在登录后跳转到其他页面时会丢失会话，但只有在打开开发者工具时才会出现！我读到这可能是因为开发者工具管理缓存的方式导致的，但我已经禁用了缓存，问题依旧存在。这就像光、波或粒子，取决于观察者。有什么帮助吗？

我用纯 C 语言编写了一个轻量级的 GIF 解码器，非常适合嵌入式或对性能有较高要求的环境。它仅包含头文件，不进行动态内存分配，并且完全与平台无关。支持静态和动态 GIF，具有 Turbo 和安全解码模式。在微控制器、物联网设备以及任何带有帧缓冲区的设备上都能完美运行。欢迎提供反馈或想法，告诉我它还能用于哪些方面。 Github: <a href="https:&#x2F;&#x2F;github.com&#x2F;Ferki-git-creator&#x2F;TurboStitchGIF-HeaderOnly-Fast-ZeroAllocation-PlatformIndependent-Embedded-C-GIF-Decoder">https:&#x2F;&#x2F;github.com&#x2F;Ferki-git-creator&#x2F;TurboStitchGIF-HeaderOn...</a>

去中心化架构：<a href="https:&#x2F;&#x2F;positive-intentions.com&#x2F;blog&#x2F;decentralised-architecture" rel="nofollow">https:&#x2F;&#x2F;positive-intentions.com&#x2F;blog&#x2F;decentralised-architect...</a> 虽然我在这里的方法可能被认为过于复杂（因为，确实如此），但我正在尝试一些新的东西，而且这种策略很可能无法长期可行。我的理念是“只有一种方法可以找到答案”。我并不一定推荐这种方法，只是分享我的旅程和我在做什么。 潜在的好处 我已经确定了这种方法的一些有趣的优点： 静态文件作为聊天应用基础设施：<a href="https:&#x2F;&#x2F;positive-intentions.com&#x2F;blog&#x2F;statics-as-a-chat-app-infrastructure" rel="nofollow">https:&#x2F;&#x2F;positive-intentions.com&#x2F;blog&#x2F;statics-as-a-chat-app-i...</a> 虽然我经常在在线讨论中看到模块联邦和微前端被劝退，但我认为它们非常适合我特定的方法。我对这些好处持乐观态度，并想分享详细信息。 在提供联邦模块时，我还可以托管 Storybook 静态文件。我认为这可能是以隔离方式记录模块的一个好方法。 模块和应用程序 以下是一些模块的示例以及它们的使用方式： 密码学模块：<a href="https:&#x2F;&#x2F;cryptography.positive-intentions.com&#x2F;?path=%2Fdocs%2Fcryptography-introduction–docs" rel="nofollow">https:&#x2F;&#x2F;cryptography.positive-intentions.com&#x2F;?path=%2Fdocs%2...</a> P2P 框架：<a href="https:&#x2F;&#x2F;p2p.positive-intentions.com&#x2F;?path=%2Fdocs%2Fe2e-tests-connectionstatus–docs" rel="nofollow">https:&#x2F;&#x2F;p2p.positive-intentions.com&#x2F;?path=%2Fdocs%2Fe2e-test...</a> 这种设置允许我创建使用这些模块的微前端，使我能够在不同的应用程序之间共享功能。以下应用程序，它们具有不同的代码库（以及开源和闭源之间的区别），将能够利用这一点： P2P 聊天：<a href="https:&#x2F;&#x2F;chat.positive-intentions.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chat.positive-intentions.com&#x2F;</a> P2P 文件传输：<a href="https:&#x2F;&#x2F;file.positive-intentions.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;file.positive-intentions.com&#x2F;</a> 共享这些依赖项应该可以更容易地在这些不同的应用程序中推出核心机制的更新。 此外，当使用 Tauri 创建 Android 构建时，此功能也适用。这可以简化创建使用这些已建立模块的新应用程序的过程。 考虑事项和未来 我确信这种架构会带来一些独特的测试和维护开销。但是，根据它的实现方式，我相信它可能会奏效，并使改进当前功能变得更容易。 重要的是要注意，关于这个项目的一切都远未完成。有些人可能认为这是一种过于复杂的方式来实现 npm 已经做的事情。但是，我认为这种方法提供了更大的灵活性，允许分离 Web 的开源和闭源代码。当然，作为 JavaScript，"源代码"将始终可访问，尤其是在人工智能时代，逆向工程比以往任何时候都更有可能。