标签归档:编程

openerp8.0开发进展分享(转)

原文via

邮件列表里大家表示对新版本期待的同时,质疑OpenERP没有明确说明8.0会包含什么,每次都是fp像挤牙膏一样说这个我们在做,那个我们在做,你们等着好戏吧。作为最终用户这确实是个最好的答案,保持饥渴么。对于我们这些靠openerp吃饭的人,谁知道他到时候发布的是惊喜还是惊讶

于是openerp公司的CTO Antony Lesuisse 回复了一下,很多人对这个回复比较满意,希望能把全文贴在网页上。开阖软件义不容辞提供中译。

what's in 8

首先要对OpenERP的进展未做充分沟通表示抱歉。我们更愿意把时间花在修复缺陷和开发超棒的新功能:)

如您所知,我们做的所有事情都公开在launchpad网站和runbot.openerp.com上,但是上面有上千个代码库,对门外汉来说这简直是迷宫。

我们也吃自己的狗粮:我们一直在用OpenERP的项目管理模块,结合看板视图、EtherPad和SNS功能,每个任务都对应一个代码库的链接。

任务有以下阶段:
– 需求(新创意或愿望)
– 设计(功能设计、技术设计及易用性设计)
– 开发
– 功能和易用性设计
– 代码审查和合并
– 发布和推广(修改描述文件和更新日志、写博客文章等)
– 部署

这些任务被分隔成6个项目。
有三个长期固定项目:
– 框架(如接口规范、新BI模型/图表)
– 易用性和功能改善(如游戏化机制、问卷、群发邮件、base_action_rules里的工作日历以及很多小的改善)
– 平台(我们自己的OpenERP以及在线租用云管理)

有三个临时项目(不过可能会延续几个月甚至几年):
– 建站系统(内容管理系统、电子商务)
– 仓库(新的WMS系统)
– 零售点(pos硬件和很多改善)

一部分重要任务现在正在进行中(在runbot上测试一下后,您可以问我关于他们的所有问题)

打开http://runbot.openerp.com/找到这个代码库单击链接后的向下箭头,点击“All addons”

新日程表和google同步(已经合并)
服务器动作和base_action_rule改善(已合并)
OpenERP数据转google电子表格(已合并)
游戏化(已合并)

trunk-website-al(将在近日合并)
– 建站系统
– 博客引擎
– 电子商务
– 仿照eventbrite
– 业务伙伴和推荐目录
– hr直接生成“我们的团队”页面
– 与招聘功能相连的职位列表
– 新的邮件模板构建器

trunk-new-graphview-ged(将在明天合并)
– 新的图表视图和多维分析
– read_group支持分组粒度,如创建日期(按年、按月、按日)

trunk-quote-roller(将在近日合并)
– 仿照quoteroller网站的在线报价系统

trunk-pos-ugly-but-fast(将在明天合并)
– 100倍的速度提升
– 原生支持硬件:打印机、扫描枪、钱箱
– 平板和手机支持及修复大量缺陷

trunk-survey2-rim(大概一个月完成)
– 基于旧的问卷模块和建站系统仿照serveymonkey

trunk-bs3-jke(大概三个月完成)
– 网页客户端由css向boostrap3转化
– 响应式设计,支持从手机到4K屏幕的自动适应

trunk-wms(大概两个月完成)
– 用“份”的概念大量重构
– 先进先出、后进先出
– 很多简化和缩减代码(去掉一些工作流)
– 和SAP一样强大(我们现在能处理所有SAP的用例)

trunk-apiculture(大概三个月完成)
– 新的应用程序接口(新字段类型,不需要id列表,没有cr,uid,ids参数)
– 修正 onchange

我知道大家对OpenERP公司的非我所创(Not Invented Here)综合征有抱怨很正常,但我认为我们多数情况下是正确的。但首先请允许我分享我在做这些决策时的四个原则(我也和Fabien分享过)。这些原则并非固定(因为我时常改变想法,他也是)。

1、在软件系统中集成的价值

我在这里考虑的并非简单独立的工具,而是由不同组件和功能组成的软件系统。

仿照梅特卡夫定律,我这里要来个Lesuisse定律(我也可能是未来规则制定者,嘿嘿):

“软件系统的价值是集成的功能数量和集成程度的乘积”

我喜欢的几个软件系统已证实了这一点:
传统的unix工具集,一个强大的系统包含很多命令,但他们是松散集成的(靠单向的字节流)。
Debian发新版,大量的功能,不同的软件包集成程度不同。
集成的软件包如微软Office,Adobe套件,功能少但集成程度很高。
我也喜欢一切功能都内置上手即用的软件,姑且叫它厨房水槽软件(我不懂emacs所以无法用它来举例),例如Blender, facebook, chrome, Ableton live……

Ableton Live是个好例子,在用它之前我们总要花时间下载VSTi或者VST音效,用不同的的软件做midi序列、取样跟踪,适应不用的用户界面,开着好多个窗口。Live改变了玩法,一切都集成在一起,使用相同的用户界面无缝地完成midi生成部分、取样部分、伴奏和音效。

我也喜欢通用并包含多种解决方案的软件,例如:
Linux – 从嵌入式到大型机的架构,所有的设备驱动都在一个代码库里
ffmpeg – 所有的视频和音频解码器在一个代码基里
mess/mame – 包含所有计算机设备的模拟器
qemu – 每一个源到目的cpu指令翻译/模拟功能都包含

当然包括ERP系统

2、内部整合与异构集成
您可能会注意到一些伟大的程序员(法布里斯贝拉德,约翰·卡马克,
的Linux Torvalds的…还有更多)会尽量保持最小的依赖列表。您
可以说,他们不符合NIH综合症,但是从他们的角度来看,这样做
意义重大。

首先我要比较一下两种集成方式:
内部整合是指当你调用一个链接库或从另一个系统复制代码、创意或模式。他们在相同的内存空间运行,靠函数调用来通信,使用相同的数据模型和类型,并非异步执行。你让他们在你的执行控制之下,让他们遵循你的规则、设计和架构。

异构集成是指你和其他使用不同平台、框架、数据模型和类型的系统做接口,或许它在另一台电脑上或者在同一台电脑的另一个内核进程上。

这很难,可行但是非常难,所以这样的集成成本应该与内部整合相比对,即使这意味着重复建设。

特别是协议很复杂的时候,UDDI WSDL SOAP这三个缩写足以让任何人理智的程序员感到恐惧和厌恶。

我们还得考虑用户体验,显性地从一个系统切换到另一个系统对最终用户来说总是个痛苦的体验。

我们在决策的时候要考虑这些方面。我还认为复制并不差,没有什么东西本身就很复杂(即使是高级工具),通常把这些东西集成起来就复杂了。比如我听说 john carmack 总是从头开始他的项目。

凡事都有例外,用HTTP和JSON这种通用协议和数据类型系统就容易多了。有时我们不得不在浏览器和服务器之间、在openerp和postgresql之间用rpc

异构集成的模块质量总是不高,因为需要大量工作:webdav, document_ftp, caldav, import_sugarcrm, auth_openid,
event_moodle…所以我们尽量少开发这种。

我也不喜欢不必要的依赖,说实话我希望python库的依赖限制在最新的Debian所提供的范围内。我们包含了一些javascript库,但我倾向于让这个越少越好。

3、保持简单

4、只有傻子和死人才不会改主意

openerp的战略是高效地提供集成度最高的企业应用系统,对最终用户和程序员来说都是如此。

悟空注:在技术这条路上,我准备适可而止,但对于编程这项爱好的心不会死,毕竟英语和手工都已经慢慢在做了,有得也算做的有点起色了,所以始终放不下“编程”这一项。而对于“编程”这项爱好,我的具体目标就是掌握wordpress和openerp这两样工具。

wordpress作为一个内容发布平台,在后台使用以及一些简单修改使用上,已经完全完全没问题了,下一步的重点应该是在网页改版、主题重构重新设计的时候,能过对wordpress有一个更系统全面的了解,以便把自己的网站运营思想、和内容架构规划在wp的页面设计上能更好的体现出来。wordpress还有足够多的扩展插件,比如实现电商功能的购物车程序woothemes(已经假设但未使用)、实现移动互联网端展现的wptouch(已在使用中)、实现社交功能的buddypress官方插件,各种newsletter插件,总之,如果不是一个项目团队企业需要更多后端运营端的系统支撑,单单是个人的小前端,那么wordpress足够了。

openerp才是我“编程”爱好能否达标的重点,因为我始终有一个没有说出来的“系统梦”。分步骤来说,首先要通过阿里云或本地来熟悉openerp在生产环境的部署,这个不需要熟练掌握,只需要大致了解,这部分完全可以交给专业的运维人员来完成;第二阶段应该是基于营销功能和有限业务层面的功能前端使用和后端逻辑的掌握,需要通过架设环境或租赁saas来在生产环境中实践;第三阶段是掌握所有与运营业务流程相关的功能模块业务逻辑、使用场景、代码实现,需要通过实践积累、并配合必要的培训来加快技能的掌握以推进实践。