ruby - 是否可以使用 MagLev for ruby​​ 构建生产 Web 应用程序？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




总的来说，我是 Rails 和 ruby​​ 的粉丝，可能会着手为金融机构构建企业应用程序。我真的很喜欢磁悬浮的想法，不知道是否值得考虑。我还没有找到太多关于 maglev 是否​​被用于生产中的信息，更不用说用于高安全性目的了。

有没有人使用 MagLev 成功部署过关键任务应用程序？如果是这样，您能否提供有关您的体验的详细信息并可能命名该应用程序？

Answer 1

TL;DR:我们即将在 MagLev 上发布一个生产应用程序。你应该等待。

我为长度道歉；我对此有很多断开连接的想法，我仍在尝试连接。

我的团队即将在 MagLev 上启动第一个生产应用程序。这是一条崎岖不平的道路，但我们非常有信心最终证明这是一个正确的决定。我在今年的一些 session 上谈论我们的经验，我很高兴更详细地谈论它，但这里有一个(长)概述。

您可能已经知道，GemStone 拥有支持金融行业公司的悠久而自豪的历史。我们主要是一家 Ruby 商店，我们开发金融应用程序。我们关心我们的数据，所以 GemStone 对我们来说是一个明显的选择。 MagLev 允许我们使用我们现有的 Ruby 知识和我们的大部分代码，并将我们的数据存储在 GemStone 中。这是(看似)完美的婚姻。

我们选择从一个小应用程序开始，它对我们的用户来说是新的，并且移动起来最容易且风险最低。我们选择了与托管结账平台相关联的发票展示应用程序。能够简单地持久化对象而不用担心映射或转换使开发变得非常快速和愉快，并且我们避免了许多与 ORM 和持久性相关的问题。我们计划继续将我们现有的其余应用程序转移到 MagLev。

也就是说，除非以下所有情况都为真，否则您应该等待:

您是(或与之合作的)Ruby 专家，他们对语言及其实现足够熟悉，可以调查和修复实现细节，其中许多细节是用 Smalltalk 编写的。

您是(或与)开发人员一起了解在 Smalltalk 中工作的细微差别，但通常是基于图像的环境。

您能够非常熟悉 GemStone/S 平台、语言、部署机制和工具。

如果遇到砖墙，您已准备好废弃所有内容并在 Smalltalk 中重新编写您的应用程序。 (我承认:我希望 MagLev 有时会完全掉下去，只是为了找个借口。)

我们一直在处理一些问题。因为，对我们来说，上述所有内容都是正确的，所以我们继续了。我们经常解决以下每个“问题”。有时每天。

回溯几乎不可能自己阅读，当您遇到许多异常时，您必须使用 GemStone Smalltalk 的命令行调试器。这里有一个学习曲线。

Ruby 库的兼容性……比您希望的要少。基本上，您可以指望大多数用纯 Ruby 编写的东西都很好。基本上任何使用 C 扩展而没有 ffi 的东西都被淘汰了。这是数量惊人的东西。过度使用元编程的库让 MagLev 感到困惑。这是 Rails 领域的很多事情。

代码重新加载和迁移是手动的。当您更改磁盘上持久对象的类定义时，您必须手动管理加载新代码和迁移现有持久实例。

综上所述，对我们帮助最大的是，我与大多数(所有？)在 GemStone 了解(并且曾经)了解 MagLev 的人是 friend 。他们对我们来说太棒了。 HPI 的学生在修复错误和帮助我们解决问题方面也做出了宝贵的贡献。

关于我的团队，因为我拥有的团队基本上使这成为可能。我们是四个开发人员。我们每个人都有十多年的经验(我认为我们实际上都超过 12-15 岁)。我们中的一些人(至少是我)有十多年的 Ruby 经验。我们在 Smalltalk 方面有不同程度的经验，尽管我们没有人发布通过它赚钱的生产应用程序。我活跃于 Ruby 和 Smalltalk 社区(并且有点从前者“过渡”到后者)。

我们的经历有点坎坷，但大多是愉快的。如果我当时知道我现在所知道的，我会再做一次。我希望我们在这方面的工作将帮助其他人在 future 做同样的事情。我将 MagLev 视为 future 的宝贵工具。