一个CEO日记-真正困难的部分
如果你只是通过本文，您可能要阅读以前的分期（S）。 简介
决定服务器的机制，并与客户的沟通背后的一般方法后，它是时间开始测试一些代码。客户端应用程序的设计是在所有尚未解决，但其余的原型。事实证明，这比设计更具挑战性。作为一个初步的实验项目，这是一个相对较低的优先次序，但前几尝试一点相似不耐烦所期望的最终目标。当时，德尔福内部的首选开发平台，从程序员/分析师的早期产品大多使用远程数据集。 "嗯，你说你想多层次，以及如何德尔福它！"他们会说。最后，有必要创建一个简单的例子，以证明所需要的（开始）从演示程序。有了这些样品，样机相当迅速地走到了一起。1＃假开始
第一阶段的原型是创建一个硬编码的屏幕，请执行以下步骤:接受输入值。将其放置在客户端容器。更新服务器的容器与该信息。运行使用更新后的数据（在这一点上硬编码）的业务规则。更改服务器的容器中的不同领域。回报给客户端。更新客户端的显示。
所示:
这当然听起来很简单，一旦概念很清楚，原来是相当简单。大障碍仍然笼罩，但。独立程序员被分配在接下来的两个任务:想出了一个办法来识别和运行没有编译到应用程序的业务规则。创建一个用户自定义的屏幕，可以连接到新的数据对象。
业务规则突然对自己的生活。相对简单的要求，成为一个XML规范的高度令人费解的设置（本质上是一种新的编程语言）的推动下，由用户屏幕驾驶控制流，变量（包括一个完整的表达式计算器），数据库访问和运行存储过程的能力转让。此外，很死板，这也追平申请到一个单一的数据库平台，并会已经很难移植到其他操作系统，有了一点点的工作人员洗牌（一对夫妇（这是设计的目标之一。）离港），焦点返回到原来的目标。假开始＃2
开始，所有的业务规则竟然是一个很好的举措。简单的脚本与Python最近的实验确定了它作为一个很好的选择。它可以在运行时加载库提供两个调用脚本，并通过与Delphi数据来回。业务规则的名称将Python文件的名称。
决定对这一行动方针，并奠定了基本计划了一天。描述它的程序员了新的一天。在一个星期之内，整个过程的工作就像一个魅力。表现相当好（考虑所提供的灵活性）。测试运行，万调用的业务规则和结果是可以接受的，足以鼓励继续发展。
虽然业务规则分心又起，发展耕提前对用户界面的一部分。程序员/分析师分配给这一任务是同一个创造了出色的用户域和用户文件的能力，在应用程序中，我们试图取代。当然，他的方法是使用新系统相同的机制。所需的一些重大变化:所有屏幕需要用户定义。即使可以修改标准画面。在屏幕上的数据可能是标准的应用程序数据或用户定义的数据。菜单选项需要用户定义，并运行服务器端业务规则。所有屏幕需要非模态。
几个月内，一个应用程序放在一起，会见了新的要求。它跑了相当迅速，并允许用户直接从正在运行的程序，这一进展感到鼓舞（进入"图层"这些留在后面的练习。）改变屏幕设计，它是决定在2月的贸易展展示的原型在2004年。由于跨平台的兼容性的设计目标之一，它是决定测试这个概念。两个星期之内，服务器和客户端已用Kylix（Delphi的Linux的双）编译服务器和客户端在展会上展出。通过简单地改变服务器的连接字符串，可以运行相同的应用程序在Windows Server，SQL Server和Linux上使用MySQL。 Python的业务规则的实施，以及这两个平台上。
由于这些事态发展令人兴奋的是，仍然是一个唠叨的怀疑，并非所有的设计目标已经达到。它似乎客户端不断被"调整了"增加新的功能。仔细观察，证明此客户端可以做什么，想用户，只要用户想正确的事。虽然非常灵活，在什么样的信息显示，控制流是非常刻板的，屏幕的外观和感觉几乎一成不变。此外，Python的业务规则运行良好，但也有一些告诉客户，他们需要使用Python开发自己的规则（虽然是一个简单的用户界面计划）的关注。这也是一个有点令人费解的安装过程。
由于痛苦的，因为它是，这些决策点之一已经达到。这是重新开始的时间。这一分析的一部分，我们正在使用的开发工具。我们需要平台独立性。那个漂亮的善意C，或者像Java，Perl或Python的环境之一。 C是几乎完全消除，因为开发周期，并在运行时连接新的业务逻辑的难度。剩下的虚拟机和口译。性能是一个与所有这些平台的关注，加上编程帮助。似乎像世界移动。NET中，但是这只是微软，权呢？。NET中进入图片
就在那时，Mono项目进入画面。虽然在。NET Framework是微软的产品，他们开设了规范和有一个积极的项目发布一个版本，将在Linux上运行。由于被取代目前的产品只能在Windows上跑，这是确定的新产品从这里开始。这是必要的，还有其他环境的发展道路。 。NET中，让我们收集的业务规则，并在运行时加载它们。它看起来像答案。技能设置问题
说服现有的工作人员开始，各地将是一个挑战。首先，他们没有任何。NET的经验。此外，他们是有理由的，他们迄今所做的工作感到自豪，并不愿意放弃它。最后，其他优先事项（任务，实际上是支付账单）占用所有的可用时间。聘请额外人手一个新项目的程序员，只有一个解决方案:外包。
外包
作为一个孤立的项目与一个明确的最终结果，这似乎是一个完美的外判项目。在内部员工进行培训。NET中，他们将准备接管交付应用程序开发的基础平台。搜索开始了。
没有在外包的经验，这是必要的领域有所缩小。在互联网上有大量的企业广告，来自世界各地。从另一个技术上没有办法区分，完全非技术性的考虑开车的决定。我们内部的程序员之一是俄罗斯本土。有外包在俄罗斯的公司。我们将使用其中的一个。
2004年7月期间，许多公司进行了接触，对一个非常小的一部分，项目的。创建一个数据容器，数据对象。实现IsDirty标志同步两个。使用一个简单的TCP客户机/服务器发送命令数据包的机制。确保这个简单的任务将在Mono下运行，以及Windows。征求想几种反应:你怎么价格您的服务？多少这种小型项目的成本？如果这是真的很琐碎，随意写这篇文章作为示范系统的一部分。
被送往十二募捐，几乎所有的回答。这五个足够的信心，产生一个测试项目。这两个其实是想提问，以澄清什么是真的想。最后，其实只有三个方案所需要的（套接字的远程处理，而不是使用其他）。这是确定的项目之一，似乎是最接近所需的样式，和他们沟通。由于是一个伟大的事要做，这个开发团队被提上固定在2004年8月，月底开始的持续工作。如市场预期，其利率是非常合理的。用户界面抽象
现有资源，工作又开始在用户界面上。这一次，目标是创建一个接口，使客户在任何平台上的工作与新的服务器。例如，新系统是一个基于浏览器的产品，将镜内联网的桌面客户端版本的所有功能。保持两个单独的用户界面逻辑的前景是没有吸引力，即使业务逻辑是相同的。这一要求，导致决定分开的用户界面规范及其实施。简单来说，我们需要能够奠定屏幕设计和"线"没有实际编码到任何特定的平台数据和处理。
正如早前，出现了跨平台开发取得长足进步。用户界面已被后来者这个党。虽然一些用户界面在多个平台上运行，他们很少看起来像本地应用程序。 "随处运行"的目标的方法之一，是实现浏览器的用户界面内。虽然这并提供运行的能力上配备任何浏览器的系统接口，浏览器的不兼容性是多方面的。这是特别真实时，试图以"推信封"。大多数浏览器可以处理简单的HTML屏幕。不幸的是，限制应用程序的功能，简单的层面，产生一个非常基本的应用程序多可怕的用户界面。许多最近已作出努力，生产的"富客户端"（指的经验，而不是成本。）这些结果已经很不错了，但最好还是不比较一个内部的桌面客户端上的本地应用程序。
它是如何可能创建一个客户端，将提供一个本地应用程序的感觉，许多平台上可用，提供出色的性能，还可以很容易建立呢？答案涉及的几项决定:在浏览器中一样，在一个平台中立的形式提供的显示规格。分开显示"客户端的处理逻辑"。在一个平台中立的方式传达到服务器。实现特定于平台的客户端，利用与特定的显示界面与平台无关的部分。
就像站在一堆的多米诺骨牌，推一端，每个决策几乎不可避免地导致下。设计开始走到一起。浏览器使用HTML指定的屏幕布局。虽然这是一个平台中立的屏幕布局，这是非常有限的和冗长。由于我们使用XML（即使是在我们原来的画面布局企图），它可能是有意义的这里，但我们需要一个标准的方式来描述布局。该标准的机制开始搜查。XML的再
不幸的是，有相当数量的"标准"指定的屏幕布局。一个最近的一次是，这是从微软Longhorn项目的一部分。这是正确的想法，但是，它高度依赖于Avalon的命名空间，非常。NET框架的具体，并鼓励（至少在当时）在屏幕上放置代码，这是没有什么设计要求。 XAML的Avalon的命名空间的纠缠，这意味着它没有这样做是必要的，相反，没有必要太多的一切。它看起来像我们创造我们自己的布局和解析引擎。
的布局并不困难的部分，但是。一旦创建XML布局，它需要由客户解释，以创建屏幕显示。在为工具，以帮助在这项工作中进行搜索，发现了将永远改变项目的路径。
的