我为长度道歉;我有很多不连贯的想法,我仍然试图连接.

我的团队即将在MagLev上推出首个生产应用程序.这是一条颠簸的路,但我们相信,最终证明是正确的决定.我在今年的几次会议中谈到我们的经验,我很乐意更详细地聊天,但这是一个(长)的概述.

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

我们选择了一个对我们的用户来说是一个新的应用程序,并且将是最简单和最低的移动风险.我们选择我们的托管结帐平台上的发票申请表.能够简单地保持对象而不用担心映射或转换,使开发变得非常快速和愉快,并且我们已经避免了与ORM相关的许多问题和一般的持久性.我们计划继续将其余的现有应用程序移至MagLev.

也就是说,除非下列所有内容都是真实的,否则您应该等待

>您(或与其合作)熟练使用该语言及其实现的Ruby专家,以调查和修复实施细节,其中许多内容以Smalltalk编写.
>你是(或与)了解在Smalltalk中工作细微差别的开发人员,但是一般而言,这是基于图像的环境.
>您可以熟练掌握GemStone / S平台,语言,部署机制和工具.
>如果你打砖墙,你准备废弃所有东西,并在Smalltalk中重写你的应用程序. (我承认：我希望马格洛夫有时候会完全平坦,只是为了有一个借口.)

有一些我们持续存在的问题.因为对于我们来说,上述都是正确的,所以我们继续下去.我们经常处理以下每个“问题”.有时每天.

>返回几乎不可能自己阅读,当遇到许多异常时,您必须使用GemStone Smalltalk的命令行调试器.这里有一个学习曲线.
Ruby库兼容性比您希望的少.基本上,你可以指望用纯Ruby编写的大部分内容都可以.基本上使用没有ffi的C扩展的任何东西都是出来的.这是一个惊人的数量的东西.可笑的过度使用元编程的图书馆混淆了MagLev.这是Rails土地上的很多事情.
>代码重新加载和迁移是手动的.当您更改磁盘上持久化对象的类定义时,必须管理加载新代码并手动迁移现有持久化实例.

所有这一切都说,帮助我们最大的事情是,我是大多数(所有的)谁是(并且是)知道Maglev在GemStone的人的朋友.他们对我们来说太棒了HPI的学生也是非常宝贵的修复错误,帮助我们解决问题.

关于我的团队,因为我所拥有的团队基本上是这样做的.我们是四个开发人员.我们每个人都有十几年的经验(我认为我们都超过了12-15岁).我们中的一些人(至少我)有十多年的Ruby经验.我们与Smalltalk有不同程度的经验,虽然我们没有人运送生产应用程序赚钱.我在Ruby和Smalltalk社区活跃(而且从前者到后者都是“过渡”的).

我们的经历有点摇滚,但是大多是愉快的.如果我知道现在我知道的话,我会再做一次.我的希望是,我们在这方面的工作将有助于其他人在未来做同样的事情.我认为马格勒夫是未来的宝贵工具.