14

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

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

4

1 回答 1

24

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

我为篇幅道歉；我对此有很多不连贯的想法，我仍在尝试连接。

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

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

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

也就是说，除非满足以下所有条件，否则您可能应该等待：

  1. 您是（或与）Ruby 专家一起工作，他们对语言及其实现非常熟悉，可以调查和修复实现细节，其中许多是用 Smalltalk 编写的。

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

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

  4. 如果你碰壁了，你准备放弃一切并在 Smalltalk 中重新编写你的应用程序。（我承认：我希望 MagLev 有时会完全倒下，只是为了找个借口。）

我们经常遇到一些问题。因为，对我们来说，以上所有内容都是正确的，所以我们继续前进。我们经常解决以下每个“问题”。有时每天。

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

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

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

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

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

我们的经历有点艰难，但大多是愉快的。如果我当时知道我现在知道的，我会再做一次。我希望我们在这方面的工作将帮助其他人在未来做同样的事情。我认为 MagLev 是未来有价值的工具。

于 2013-04-17T02:18:38.383 回答