是什么阻碍了 Drupal 的主流应用?

1 位读者喜欢这篇文章。
open source work experience

Opensource.com

坊间传闻, Drupal 正在招聘。确切地说,是 Drupal 商店。但是,缺乏经验丰富的 Drupal 开发人员和主题制作者正在损害生态系统。

很有可能,您最近访问过一个运行 Drupal 的网站。(这个网站就是其中之一。)有多少项目想要使用 Drupal,但却没有内部人才?或者他们联系了 Drupal 商店,却发现他们在未来几周甚至几个月内都已排满了其他项目!

我们决定向 Drupal 社区的培训顾问 Doug Vann 询问是什么阻碍了 Drupal 的主流应用,以及其他一些有趣的问题。Vann 一直在培训个人和组织如何利用 Drupal 的强大功能。他还定期参加各种 Drupal 活动。让我们看看 Vann 有什么要说的。

您是如何参与 Drupal 的?

Doug Vann我当时在一个风险投资资助的社交网络站点工作。风险投资公司正在聘请一家 .NET 商店来构建大量的自定义功能。这非常残酷。每当我们要求他们不提供的功能时,他们就会以巨大的成本慢慢构建它,然后他们会转过身来,将这项新功能作为其服务产品的一部分。我们实际上是在资助他们的研发部门,而且这花费了很长时间。我当时实际上是 Joomla 的拥护者,我试图将这个项目从 .NET 转移到 Joomla(当时是 Joomla1.5rc2)。我实际上赢得了那场战斗,我们开始招募个人和商店,组建一支令人印象深刻的团队来快速完成这项工作。我们已经在这个项目上浪费了一年多和 100 万美元!

当我在 JoomLancer、Guru 和其他网站上发布广告时,我用我那长长的、连珠炮似的、列出我们想要构建的所有功能的项目符号列表吸引了很多关注。我们负担得起,而且我们将要构建它!就在这时,一家商店在办公室给我打电话,说他们使用 Drupal。我不知何故错误地认为 Drupal 是 Mambo 在成为 Joomla 之前的旧的、被遗忘的分支。我从哪里得到的这个想法?我完全不知道!哈哈... 无论如何... 这家商店告诉我,他们已经看到了我所有长长的、连珠炮似的项目符号列表,并且我所要求的许多功能在 Drupal 中开箱即用。

长话短说,7 天后,他们向我们展示了一个他们在 Drupal 5 中快速构建的原型。天哪!我和团队都惊呆了!事实上,我们想要的很多东西实际上在 Drupal 5 中是开箱即用的。我们在 70 天后启动了我们的网站,而且没有再花费 100 万美元!

是什么阻碍了 Drupal 的广泛应用?

人才流失。

我们真的需要在 Drupal 领域有更多有才华的参与者。现在我们有一些项目无法启动,因为组织发布了 RFP(需求建议书),但没有得到他们需要的合格结果。我们有商店拒绝工作,因为内部人才不足,也没有足够的人才库来供应商店。有多少网站想要用 Drupal 构建,但找不到人才,也不愿意等待?这种情况太频繁了。Drupal 社区正在把钱留在桌子上,部分解决方案是接触大学生、应届毕业生以及愿意将他们的 C++、Java 或 RoR 等技能转移到 Drupal 的人。

您在 Drupal 社区中扮演什么角色?

正如我提到的... 合格的、技术娴熟的 Drupal 人员很难找到。这就是我的培训业务 Synaptic Blue Inc. 真正切中痛点的地方。我在 DrupalCons、DrupalCamps、LinuxFests 以及任何其他需要 Drupal 培训的地方提供各种收费和免费的公开培训。在这里,人们出现,他们迫切希望了解 Drupal 的工作原理以及如何使其为他们工作。有些人只是想启动一个网站来娱乐或盈利,另一些人则想以此为职业,并且他们知道自己需要技能。

除了公开培训外,我还经常被邀请到组织机构进行现场培训,以提高他们内部的 Drupal 知识库。我曾为 NASA、纽约州总检察长办公室、《Highlights Magazine for Children》(寓教于乐!)、美国联邦法院以及许多主要的大学和学院以及其他组织提供过培训。

Drupal 社区最好的部分是什么?

“社区”是社区最好的部分!哈哈,我这是什么意思... 嗯... 人们是社区。他们聚集在当地的团体、商店或地区,但归根结底,社区是由个人组成的。这些个人投入了不懈的时间,使核心变得更好,加强了贡献的模块或文档。有些人活动上口才出众,有些人写书,有些人组织活动。正是这个高效的个人群体使 Drupal 成为强大而受欢迎的解决方案,并将永远如此!

您将参加一些即将举行的活动。请告诉我们您将在哪里,以及您将做什么。

我的下一个活动是 DrupalCamp Atlanta。自 2009 年我参加第一次以来,这是我从未错过的一次。那是我参加的第四个营地。现在,2012 年亚特兰大 DrupalCamp 将是我的第二十八个!这个营地的独特之处在于组织者 David Terry 和他的 MediaCurrent 团队举办了一个非常专业的营地。许多营地感觉像是随意的聚会,这很好,但我总是以精神饱满的状态来到亚特兰大,期待着开展业务。事实上,今年是他们提供商业峰会的第二年。Drupal 商业峰会去年在亚特兰大得到了完善。它为 Drupal 的运作带来了非常需要的商业重点,同时也为西装革履的人士提供了一整天的活动。其价值令人惊叹,其他营地都在试图效仿这一事实就证明了这一点。

亚特兰大之后是 BADCamp 或海湾地区 DrupalCamp——11 月初在旧金山加州大学伯克利分校举行。这将再次是规模最大的一个,人数将超过 2000 人。在那之后是 12 月的 DrupalCamp Ohio。这将使我在 48 个月内参加 30 个营地!

标签
Avatar
Jason Hibbets 是红帽公司数字社区团队的社区总监。他与 Enable Architect、Enable Sysadmin、Enterprisers Project 和 Opensource.com 社区出版物合作。

41 条评论

再次感谢您的采访!
自从我们将这次采访整理在一起以来,发生了一些令人着迷的事件。我参与 Drupal 品牌和营销委员会扩大了我对许多事情的看法。
作为一个委员会,我们正在与 Drupal 协会合作,采取协调一致的行动,以吸引更多对 Drupal 的关注和客户,以及更多开发人员加入 Drupal。目前没有什么可宣布的,但我们非常清楚 Drupal 人才的短缺,并且正在探索解决此问题的方案。
要及时了解情况,请访问、加入并参与 http://groups.drupal.org/marketing-drupal 。我们真的希望听到社区对这些问题的广泛意见。
我的另一个观察是,Drupal 工作的积压并不是全面的。项目的预算、规模和类型决定了客户是否可以轻松或困难地为其项目找到合格的解决方案提供商。
我们希望同时扩大用户群、客户群和开发人员群,这是一个非常有趣的局面。我们期待社区真正参与进来。我们已经看到 DrupalCamps、用户组和其他组织正在采取行动,使其活动成为 Drupal 的绝佳首次体验,不仅作为一种 Web 解决方案,而且还作为一项职业。

这个话题只会变得越来越有趣!
- Doug Vann [Drupal 培训师、顾问、开发人员、Synaptic Blue Inc. 总裁]
- http://dougvann.com

这非常令人兴奋!感谢分享。我认为这只是开源社区自然成长过程中的一部分。最棒的是,Drupal 社区正在使用开源的方式来解决问题。这本身就很棒!
Jason

我担心的是,“愿意将他们的 C++、Java 或 RoR 等技能转移到 Drupal 的人”可能比您想象的要少。

我对情况的印象是,要成为一名有价值的 Drupal 雇员,您需要相当多的经验,但是要在没有学徒或代码猴子职位的情况下获得这种经验,您需要在某种程度上喜欢它。然而,由于 Drupal 是用 PHP 编写的,我不认为这些人群会认为转移到 Drupal 是一件可取的事情。

<ol>
<li>喜欢 C++ 的人可能更喜欢专注于 C++ 最擅长的事情,例如 CPU 密集型本机应用程序。(游戏、多媒体应用程序、任何同时复杂且底层的应用程序等)我不确定他们中有多少人愿意学习 PHP 和 Javascript 来进行 Web 应用程序开发,而他们可以只学习 Javascript 与 Node.JS,并在 C++ 或客户端 Javascript 中完成任何非 I/O 密集型任务。</li>
<li>根据我的经验,Java 主要是在大学/学院课程中学习的,这意味着由于缺乏具有通过在线资源进行自学经验的学生,迁移路径可能会很坎坷。</li>
<li>我可以亲自证明,习惯了 RoR 和 Python 的人会觉得 PHP 有多不舒服。我尽可能避免使用它,并且在我确实使用它时坚持使用 FatFree Framework(它需要 PHP 5.3 匿名函数),因为它给了我一个更像 Python/Javascript 等风格的 API。</li>
</ol>
我对 Drupal 没有任何意见,但我给人的印象是,由于 PHP 携带的所有设计和文档包袱,它处于明显的劣势。
<ul>
<li>真的吗?在任何早于 5.3 的版本中使用字符串作为函数引用?</li>
<li>由于 PHP 将 API 包裹得如此紧密,以至于您必须解引用指针才能获得原始图像数据,因此无法在 GD 中获取原始图像数据?</li>
</li>在这个时代,将模板引擎构建到语言语法中,仍然期望模板设计人员手动跟踪数据是否已被转义?</li>
<li>为什么 PHP 文档的面向对象部分仍然索引如此糟糕,以至于您必须首先通过 Google、博客文章和他们必须存在的顽固信念来查找确切的类和方法名称?(例如,opendir/readdir 的替代方案)</li>
</ul>

谢谢 Stephan,
您提出了一些非常有效的观点。我确实提到了我希望其他技术 [C、Java 等] 的开发人员能够进入 Drupal 领域。我没有提到的是,我也希望高中生和大学生选择 PHP 和 Drupal 作为一份利润丰厚的职业。
至于您对 PHP 在许多层面的反对意见。您并不孤单。尽管 PHP 有一些缺点,但它仍在以惊人的速度推动 Web 向令人兴奋的方向发展。作为当今 Web 应用程序需求的解决方案,以及作为商店或个人的赚钱工具,PHP 经受住了时间的考验,并证明了自己在许多层面上的有效性。
但正如我所说... 您的批评得到了许多人的认同,并且每个诚实的 PHP 开发人员都有许多痛点。PHP 在不断改进,我很高兴 Drupal 将如何在未来继续利用它!

还请记住,程序员喜欢... 编程。越来越多的人离开 Drupal 去从事“真正的编程”。例如 http://mikecr.it/ramblings/drupals-golden-handcuffs 和 http://berk.es/2012/10/01/farewell-drupal

根据后一篇帖子,这是 Dries 的意图:他希望 Drupal 对非程序员更有用。这实际上意味着 Drupal 正在疏远构建它的人。这意味着出现了一种新的“Druplist”职位,即能够点击构建网站的人,了解一些(足够的?)编程知识来构建新功能,并可能委托程序员在需要的地方构建新模块。但是,90% 的网站可以通过预构建模块主要构建。它们可能需要稍微调整一下,但很少有项目真正需要您从头开始构建大量模块功能。

Drupal 用 PHP 编写并且变得越来越复杂这一事实意味着,对具有高度 Drupal 专业知识的、越来越专业的程序员的需求正在增长。随着 Drupal 8 迁移到 Symfony,它变得更加复杂。这意味着您将需要更多正是那些正在离开(或从未加入)的人,因为他们不喜欢 PHP。Stephan 谈论的那种人。

我不认为问题出在 PHP 本身;尽管它名声不好。PHP 完成了很多非常棒的项目。例如 CakePHP,在 PHP 之上构建一个干净的 OOP MVC 框架,在 PHP 甚至没有合适的 OOP 功能的时代:一项巨大的壮举。或者像 CodeIgniter 和 Laravel,它们具有非常流畅的 API 和 DSL。

构建它的 Web 专业人员就是使用它的人。他们是他们的主要目标受众。
因为肯定有很多 PHP 专业人员;尽管 Ruby、Python 等的赶时髦的开发人员让您相信事实并非如此。当然,这些干净、漂亮的 PHP 框架可能不如 Django/Python 或 Rails/Ruby 那样时髦或友好,但仍然比 Drupal 迈进了一大步。

我不会不同意 CakePHP 是一个优雅的框架。我自己也曾尝试过。但是,我必须在 PHP 在其中的作用上与您意见相左。

如果我要使用一个足够重的框架,除非使用字节码缓存,否则它会比裸 PHP 慢一个数量级,我最好使用 FastCGI 和一种具有列表推导、函数和类装饰器、更干净的标准库、简洁明了的语法来表示具有可变关键字参数的函数,以及显式指定哪些代码只需要在初始化时运行,哪些代码应该为每个请求运行的能力的语言。

每当我将 PHP 与 FatFree Framework 一起使用时,都是因为 FatFree 会在不提供这些技术的共享主机上为我提供与 Django/Pylons/Pyramid+FastCGI/mod_wsgi 相同水平的性能。

至于 Ruby,我给人的印象是,我与赶时髦的人截然相反,因为尽管了解它可能很有用,但我就是无法克服它的设计美学冒犯了我的感官。(我想我曾经在与朋友聊天时称它为 Perl、BASIC 和 Java 的私生子。)

我认为我们在这里是站在同一边的。我出于您提到的确切原因从 Drupal 切换到 Rails(根据我博客 berk.es 上的上述链接):因为有一些语言和框架比 PHP 更适合。

我认为,特别是当开发人员成长时,他们会为了这些语言而离开 PHP(及其工具)。我认为,这确实是对 Drupal 的一种威胁:那些“智力”,那些发明和构建好的模板系统、高性能 ORM、干净 API 等的人正在离开。

对我来说,原因是:为什么要在一种次优的语言中,尝试使像 Drupal 这样混乱的东西变得漂亮,而已经有现成的、干净的并且用更适合现代 Web 开发的语言编写的替代方案。

我们在这里的立场是一致的。

我还想说的是,PHP 远未消亡,如果真的会发生这种情况;当对 PHP 有需求时,就会有 PHP 开发人员。但是那些在 PHP 世界中流动的开发人员会选择比 Drupal、Joomla 或 Wordpress 更干净、更现代的框架。

另外:这就是阻碍 Drupal 应用的原因:http://labs.talkingpointsmemo.com/2011/07/the-twilight-of-the-cms.php

很棒的采访/文章,一如既往,感谢 Doug 为 Drupal 社区所做的工作!

Stephan 提出了非常关键的观点,我的经验确实与他所说的一致,即试图引诱可靠的 C、Java、RoR 等开发人员跳槽到 PHP/Drupal 开发。我确实看到开发人员撤离其当前平台的一个机会领域是 .NET。仍然有很多面向 Microsoft 开发人员专业人士的工作,但根据我作为公司招聘人员的经验,他们似乎更愿意(并且准备好)做出改变。

我真的希望在未来一年看到更多在现代大学中提供的更强大的开源开发课程,并可能在高中阶段也提供。我希望 Drupal 协会能够在未来几个月和几年内帮助向系主任/课程设计师宣传开源的好处。

嗨,
Drupal 需要营销方面的帮助,小型 Drupal 开发商店也需要。我有 2-3 名设计师/开发人员,我在每个项目的基础上与他们合作,但我们不够忙。Doug,您能帮我找到收入不错的 Drupal 项目吗,3000 美元以上?

这种人才匮乏是否可能来自 Drupal 正在增长的市场?中型到大型企业。如果它更普及到普通人群,例如博客和小型企业网站呢?

我很惊讶这是一个问题 - 我看到 Drupal 在各种地方涌现,从大型高流量网站到小型商店。我想潜力比可用人才更大!
公平地说,我以前尝试过做一个稍微高级的 Drupal 设置,但完全大脑短路了,所以... 不太容易上手。

我对 Drupal 很感兴趣已经有一段时间了,我一直没有真正采用它的唯一原因是因为我在 php 方面的经验。我用 Java 和 C++、C# 编程过,甚至曾经使用过 asp.net。然而,我花了一段时间才采用 CMS。我最近采用了 WordPress,并为客户构建插件和网站。但是,我还没有能够像我想要的那样玩转 Drupal,并且对它了解不多。我在 WordPress 方面的知识是中级的,并且还在增长。总之,这篇文章让我更想学习 php 和 drupal 开发技能。谢谢...

嘿... 在我的联系表上联系我 http://dougvann.com/contact,我很乐意花半小时左右的时间与您屏幕共享,向您展示它的强大功能!
Drupal 社区真正学到的一件事是,最好在导师的指导下学习 Drupal。
;-)

我不理解“人才流失”的答案。

最近有几个人在博客文章中宣布他们离开了 Drupal。似乎写这些文章的人需要给自己许可才能继续前进。几篇博客文章绝不意味着“人才流失”。人们来来往往是很正常的。

实际情况是,对于每个“离开” Drupal 的程序员,都有更多人加入该项目。对于加入 Drupal 的人来说,这是一个非常大的机会。

说得对,Dries!
对于加入 Drupal 的人来说,确实有非常大的机会!
我个人不认识很多“离开” Drupal 的人。我认识一些人把它当作爱好,他们从中获得了业余爱好者的结果。但是那些在领域中工作的人正在与我们一起收获,这真是令人兴奋!
我现在最大的目标是尽我所能帮助鼓励开发人员社区的更多增长。我非常广泛地使用这个术语来表示我想看到更多的设计师、主题制作者、项目经理、网站构建者、编码人员、活动演讲者、更多活动本身等等。我想看到更多的商店、更多的创新、更多的发行版和更多的模块。
我喜欢 Drupal 的市场份额正在飙升这一事实。我很高兴将更多人拉入一个不仅具有爆炸性采用率增长,而且拥有所有开源领域中一些最优秀人才的社区!:-)

Doug Vann [Drupal 培训师、顾问、开发人员]
http://dougvann.com

嗨,Dries!

我没有那样理解“人才流失”的答案。我不能代表 Doug 发言,但我认为他的意图不是要强调您提到的社区中的一些人员流动。

对于阅读本文的其他朋友,是的,我同意,开源(和其他)社区总是存在人员流动。人们的生活在改变,优先事项在改变,兴趣在改变。正如您指出的那样,这是正常的。

我将该评论理解为试图表达人才需求大于人才供给。对于 Drupal 生态系统来说,这是一个好问题(某种程度上)。其他开源甚至一些商业组织现在甚至无法销售他们的一些产品。我认为 Doug 真正想说的是,如果您有一些编程技能,那么 Drupal 生态系统中有很多机会。如果您需要编程技能,请考虑可以使您成为 Drupal 专家的技能!

Jason

“我当时在一个风险投资资助的社交网络站点工作。风险投资公司正在聘请一家 .NET 商店来构建大量的自定义功能。这非常残酷。”
我确信有人说过,但问题不是 .NET,听起来像是项目经理和/或技术主管的选择不当。或者... .NET 开发供应商的选择不当。问题是人,而不是技术。至于 Drupal,它很好,但正如另一位发帖者提到的... 一个可靠的 C#、MVC3/TwitterBootstrap 开发人员不会在没有强制推动的情况下跳槽。

Mickey,
您说得太对了。.NET 不是主要问题。如果这个项目是用纯 PHP 完成的,并且使用了相同数量的自定义代码,那么对网站进行更改也会同样困难。
我的观点是,“自己动手”虽然在一定程度上给了您自由,但也让您受限于您自己的最佳实践意识。在没有 Drupal 经过时间考验的最佳实践的情况下,纽约证券交易所的项目正在全速驶向一个几乎每个解决方案都是自定义的世界,这就是我所说的残酷之处。
有些人 [我不是说您是其中之一] 嘲笑像 Drupal 这样高质量的企业 CMS 的即插即用模块化方面。那些嘲笑的人似乎不明白为什么纽约证券交易所的项目将超过 50 个站点从 .NET 迁移出来,他们也不明白为什么佐治亚州放弃了 Oracle、Java 和 Vignette,转而采用基于 PHP 构建的解决方案 [最重要的是]。他们认为是一些狡猾的销售人员向某人推销了一堆商品,但实际上 Drupal [不是自定义 .NET 解决方案,也不是 Java、Oracle、Vignette 解决方案] 正在授权这些大型 [我可以称它们为企业级吗?] 用户真正成为其内容和呈现内容的页面的主人。
我的信息很明确。如果有人正在考虑一个大型项目,并且您正在考虑在该项目上安排十几名 .NET 开发人员,请等一下!同样,如果 Vignette 的许可费看起来可以容忍,因为其背后的技术听起来很大、令人印象深刻且速度很快... 请等一下!还有很多需要考虑的。

警告....
当 Drupal 是您的锤子时,一切看起来都像钉子。我见过一个不应该使用 Drupal 的 Drupal 项目失败了。幸运的是,我是在做出决定后才加入的。我想明确表示,我不认为网络上的每个站点都应该使用 Drupal。
哈哈

@Mickey:您确定吗?我的工作主要是 .NET,但也涉及相当多的 WordPress 和 GNU/Linux 管理,以及尽可能多的 Perl。我花了几年时间从事程序员、Web 程序员和 DBA/DB 开发人员的万金油工作,这只会加剧我对 .NET 的不信任。

在我看来,C# 对于大型应用程序开发来说是一种不错的语言,但它永远不会是首选。对象模型和语言都太复杂了,但它们不需要这么复杂。

PHP,尤其是 Perl,允许您快速轻松地完成一些事情,并将更难的事情放在触手可及的范围内。Perl 特别包含一些非常有用的强大功能,并且语法简洁。C# 几乎可以完成所有事情,但与上述两者相比,它的编程难度要大得多。它对 Web 开发不是很友好。感觉好像 Hejlsberg 故意决定尽可能绕远路,而不是创建强大的语法。它很灵活但很笨重,就像一条巨大的金属链。

我在创建 SharePoint 2007 Web 部件方面有很多经验,它是构建 Web 应用程序和门户功能的主要工具。这是一个痛苦的过程。SharePoint 是 .NET Web 应用程序开发的旗舰工具,我迫不及待地想看到它的背影(希望通过找到一份新的 Perl 开发人员工作)。2010 年据说会更好,但您可以对 2007 年进行很多改进,但它仍然会非常糟糕。

在使用 WordPress、Joomla! 和 Movable Type 多年后,我最近终于安装了 Drupal,并对其提供的与 SharePoint 类似但更好的功能感到震惊。例如内容类型。

区别是什么?Drupal 灵活、有弹性、文档齐全,并且基本上可以正常工作。它看起来也更酷。SP2007 大约有 20,000 个问题,但我最喜欢的是
<ul>
<li>用户界面损坏 - 缺少编辑工具,迫使用户在 HTML 中编写代码,表单上缺少按钮(!!!)等 - 令人难以置信!</li>
<li>由于需要锁定使用 M$ 平台的每个可能部分(SQL Server 数据库、IIS Web 服务器、Windows Server、MS Office 等等等)而导致的跛脚架构</li>
<li>无法用纯文本编写代码,需要使用 MS SharePoint Designer - 一款糟糕且过于复杂的产品,当我将其用于其广告宣传的主要目的(对母版页模板进行细微更改!)时,它破坏了我的 SP 测试版本</li>
<li>基于表格的默认设计(希望至少在 2010 年已经解决了这个问题)</li>
<li>极其复杂的 CSS 意大利面条式架构</li>
<li>保存的 HTML 代码被转换为带有大写字母的 HTML 4.01 - 老派!</li>
<li>笨拙、痛苦的管理界面。</li>
<li>某些管理功能(例如,拖放 Web 部件)仅在 Internet Explorer 中可用!但我仍然放弃了 IE8(我保留它是为了我们的用户使用它),因为它最终停止加载页面。IE9 在访问 SP 方面的性能仍然是迄今为止最差的。我使用 FF、GC 和 Opera。</li>
</ul>

我曾经尝试查找如何将 HTML 页面标题元素从愚蠢的默认值“Pages - Default”更改为更合理的东西。 有两种非常复杂的方法可以做到这一点,而我离下班只有大约一个小时了,所以我决定不费这个劲了。 为了彼得的缘故,<em>页面标题 </em>。 尝试更改 Drupal 或 WordPress 中任何页面或帖子的标题。 这只需几秒钟,并且是一种愉快的操作,因为这两个 Web 应用程序框架都是由热爱和理解 Web 的人构建的。 微软害怕和误解它——至少如果你使用 SP07,你会这么认为。

SharePoint 非常笨重。 你可能会在几台足够强大的虚拟服务器上运行 Drupal 安装,用于大型组织的 Intranet 或主要的、高流量的网站——特别是如果你有一个单独的数据库服务器。 将其与我们的 SharePoint“服务器场”进行比较,后者运行在 <strong> 四台虚拟服务器 </strong> 上,并配有由两台服务器组成的集群专用数据库后端。(诚然,任何时候只有一台在使用)。 此外,这一切都连接到一个巨大的 SAN。

这是推荐的配置——微软的解决方案总是要求你付出最高的代价,但提供的功能却可以通过免费和开源软件更好地提供。 哦,顺便说一句,那还是一个“轻量级”配置——我们被鼓励使用更大的 SAN,以防万一。

尝试编写 .NET Web 部件代码。 弄清楚两种 ASP.NET 服务器控件之间的区别非常费力,特别是当 www.asp.net 上的官方文档也出奇地不完整时。 此外,没有关于如何在 Web 部件而不是代码隐藏页面中使用 ASP.NET 的文档。

对于 .NET Web 应用程序开发人员来说,还有其他选择吗? DotNetNuke? 我听说它也很糟糕——但它不可能比 SharePoint 更糟糕,而且不会花费你每台服务器 700 英镑(= 1500 美元?)(如果用于公共网站,则另加 5000 英镑)。

如果你在 IT 行业杂志上听到公司喜欢 SharePoint,你知道为什么吗? 因为这是许多普通人第一次有机会使用协作式 Web 内容应用程序。 如果他们先看到 Drupal 就好了。

Drupal 是一个很棒的产品。 WordPress 也很棒,但它主要针对博客(即使它可以做完整的 CMS),并且不包括开箱即用的可锁定区域。

全力支持 Drupal 社区,他们正在为这个值得的世界带来成熟、高质量的 FLOSS 产品。

@Bill Rose。 同意 SP2007 是一团糟。 SP2010 好一点。 C# 很棒,如果你是做这个的。 页面标题,我一定是错过了什么,不就是一个文本更改吗。 如果你正在构建企业应用程序,C#、带有 WCF 的 MVC 是最佳选择(除非你是 Java 商店)。 Drupal 没有什么问题,但我可以在 MVC/C# 中做到那里的一切,并遵循任何其他 .NET 开发人员都可以在第一天走进并接受的良好、干净的编程实践。

Mickey 说:“……一个可靠的 C#、MVC3/TwitterBootstrap 开发人员不会在没有强制推动的情况下跳槽。”
我听到了你的话,你在这里说到了点子上。
我不是为了 Drupal 而推销 Drupal。 如果一个解决方案不适合 Drupal,那么我就不会投标。 我更感兴趣的是看到客户的需求得到满足。 在这个时代,客户变得非常精明。 他们对自己的网站期望很高。 他们在 YouTube 上观看视频,在那里你可以找到主要政府和私营部门网站的案例研究。 他们看到管理内容和管理用户是多么容易,他们想知道为什么他们的自定义 CMS 没有这些功能。 答案是,当他们要求 JAVA 或 .NET 开发人员构建网站时,他们没有要求这些功能。 然后他们自然会想,他们是否应该选择 Drupal 而不是自定义 JAVA 或 .NET 解决方案。
从这个意义上讲,那里的客户要求更多地控制他们的网站。 许多人甚至希望能够培训内部人员学习 Drupal,并对网站进行小的 [或不太小的] 更改。 为了配合这种思路,许多客户希望投资书籍、活动和咨询,以真正教育他们的营销和/或 IT 部门关于 Drupal 的知识,以便他们可以启动和管理自己的微型网站或其他项目。 [这正是我花费大量时间的地方;在现场培训客户,让他们更好地利用 Drupal 为他们提供的服务。 我曾为 NASA、许多大学、BlueCross BlueShield 以及更多机构这样做过。]

随着越来越多的“可靠的 C#、MVC3/TwitterBootstrap 开发人员”意识到客户想要这种解决方案,我希望他们能看到树上的果实,爬上梯子,开始摘取一些!
在某个时候,许多这些程序员将意识到,每周 40 多个小时在代码编辑器中工作只是构建客户网站的一种方式。 另一种方式是致力于具有高质量社区支持的高质量 CMS。 并知道你不必收拾你的编辑器,用鼠标完成一切。 许多 Drupal 站点包含大量使用 Drupal API 和框架编写的自定义代码。
如果 .NET、C# 和 JAVA 程序员真正致力于为客户的 Web 需求提供最先进、一流的解决方案,他们中的一些人 [不是全部或大多数,而是一些人] 会意识到 Drupal 的持续创新和不断扩展的解决方案库是一个令人兴奋且利润丰厚的职业选择。
归根结底,这一切都是为了提供解决方案。 我相信 Drupal 具有明显的优势,它对开发人员、设计师、最终用户和潜在客户都具有吸引力。
捷豹使用了标语“性能的艺术”。 按照这个思路,我会说“Drupal,基于 Web 的解决方案的艺术!” 我们为任何想要为最终用户提供全新类型解决方案的程序员提供了很多东西; 越来越多的用户点名要求的解决方案!
Doug Vann [Drupal 培训师、顾问、开发人员]
http://dougvann.com

<cite>答案是,当他们要求 JAVA 或 .NET 开发人员构建网站时,他们没有要求</cite>
为了它。 然后他们自然会想,他们是否应该选择 Drupal 而不是自定义 JAVA 或 .NET 解决方案。 </cite>

正确。 直到你把 Drupal 嫁接到这个故事中。 Drupal 实际上和可行的方式都无法解决这个问题。 当然,也许街角的那个奶酪商,现在可以创建一个新页面并嵌入一个谷歌地图。 或者更懂技术的用户,他们实际上可以在他们**简单而干净**的 Drupal 网站上尝试新的模块。

但其余的只是理论上的。 一个大约 1 万美元的 Drupal 站点并没有那么灵活,以至于网站管理员可以随意添加新模块。 不是那样,并且保持一个理智、可维护的环境。 Drupal 配备了 strongarm、features、drush 等工具:在这方面,它与 Rails、Django、Java、.net 等没有什么不同。 在网站和应用程序上工作的人是专家; 很可能是一个程序员。 使用 RCS、命令行、编写代码、通过 ssh 部署东西;等等。

主要的区别在于,在我平均较大的 Drupal 项目中,PM 几乎总是不得不对客户说“对不起,不行”。 对不起,该模块不好; 该解决方案无法运行; 您提出的这个新视图在不重构主题的这一部分的情况下无法工作。 等等。
因此,Drupal 与您提到的工具相比,几乎没有优势。

只有在低预算、少量定制的情况下,Drupal 才会胜过这些工具。 但我怀疑有人会建议他们的客户编写一个基于 Java-springs 的 CMS,供街角的奶酪商发布她的菜单。

你是对的,Drupal 可以提供一些不错的 CMS 解决方案,并且在某些方面比其他解决方案更好,而且肯定比自己滚动开发更快。 我也理解 Bers 的意思。 大多数企业(中大型公司)都在寻找 CMS 和具有思考能力的交互式仪表板、数据驱动的内容以及非常具体的业务线应用程序。 如果营销部门想要建立一个简单的 CMS 的内部/外部站点,Drupal 通常会在列表中的某个位置。 与 SlamCMS、Orchard 等一起... 它们提供了一些不错的系统。 当客户要求一个订单管理系统,具有自定义的、灵活的定价(实时)、交付管理、特定于其行业的仓库管理、在接收室运行扫描仪和条形码打印机的代码等时,你会转向自定义 .NET、Java 等...
就像你说的,如果客户正在寻找 Drupal 解决方案,我就不会投标……但还没到时候。 :)

我说的是,“我不是为了 Drupal 而推销 Drupal。 如果一个解决方案不适合 Drupal,那么我就不会投标。”
至于奶酪商是什么,我不知道。 本文和本主题并非旨在为 1 万美元的网站和花费超过 100 万美元的网站正在享受 Drupal 提供的控制级别辩护。
我不知道客户在什么价位开始或停止成为奶酪商。
让我说清楚。
所有现有的解决方案和即将出现的新解决方案都有其位置。 我不相信 Drupal 会或甚至可能取代 Vignette、原始代码、Wordpress、Drupal 或任何语言。
事实不会说谎。 Drupal 在政府部门和私营部门的各个大陆的采用是一个简单的事实。 我们正在取得进展,而且我们没有放慢脚步。 Drupal 8 将使这种增长升级。 与此同时,C# 和 .NET 以及 JAVA 以及其他任何东西也将继续增长。 我不是在谈论世界统治。 这不是零和博弈。
Drupal 提供力量。 客户想要力量。 客户愿意学习 Drupal,以便从他们的网站中获得更多力量。 这在 1 万美元的级别和超过 100 万美元的级别都是如此。
对于不想使用 Drupal 的客户,有很多优秀的选择可供选择。
为了回到预期的主题……我们需要更多想要赚大钱的人,以便完成所有这些工作
;-).

说得好。 始终是编码的粉丝,学习新代码,并且始终是赚更多钱的粉丝。
一切都归结为你希望你的 Web 应用程序做什么,你希望如何完成它,已经有哪些技术到位……等等。

从我构建网站的经验来看。 这实际上取决于他们想要网站有多大。 对于小型非常简单的网站,我只会硬编码它们,因为它们没有太多功能,或者它们都是静态的。 然而,对于内容总是会发生变化的大型项目,我已经停止抱怨 CMS,并开始使用它们。 截至目前,WordPress 完成了这项工作,因为客户希望在他们的网站上添加博客,这使得它变得容易得多。 我对 Drupal 的兴趣来自于为网站找到最佳解决方案。 例如,一个企业系统,我相信 Drupal 可以处理它。 我不会为这样的网站推荐 WordPress。

至于企业选择 .net 和 Java 等语言用于网站。 我认为企业没有考虑什么是最佳解决方案,而是我们现在拥有这个,为什么不使用它呢。 我编写过一些网站,我知道他们拥有的不是最佳解决方案。 我曾尝试建议其他解决方案,但没有成功,但我确实听说仅仅更改 .NET 和 Java 中的需求有多么昂贵。

在关于 Drupal 人才与机会平衡的讨论背景下,存在开发人员是否注册速度不够快或是否正在逃离现场的问题。 同样在背景讨论(不是在这篇文章中)中,存在关于以更大的用户为中心的导向是否与开发人员的利益相悖,从而导致他们离开的问题。

所有这些都非常有趣,值得考虑,但我不认为它们是 Drupal 特有的。 作为一名拥有 20 多年经验的开发人员、拥有 16 年经验的 UX 专家和拥有 4 年经验的“Drupaller”,我看到 Drupal 社区中开发人员和用户之间的“紧张关系”与其他任何地方都相同。 它一直存在,并且将永远存在。 这种紧张关系通常归结为在对开发人员方便和对用户方便之间的一场拉锯战。 在我为用户奔走的这些年中,我一直在争论、恳求、劝说和说服开发人员(及其经理)为用户做正确的事情。 花费额外的努力和投入(以及金钱)来使功能可用确实需要付出努力和投入(以及金钱)——这就是业务的本质。

好消息是,我发现大多数专业开发人员不仅想要编写干净、功能正常的代码,而且也确实想要服务于用户的利益。 有时他们无法看到如何同时实现这两个目标。 这就是为什么我们需要 UI 系统设计师。 我发现在 Drupal 中也是如此。

所以,是的,在 Drupal 世界中,<a href="http://www.tuag.ca/blog/small/user-narratives-video" target="_blank">当前开发实践与可用性要求之间存在明显的“冲突”</a>——通过正确的 <em> 系统级别 </em> UI 设计方法,我认为这些可以得到解决,从而使开发人员和用户都受益。

<cite>我看到 Drupal 社区中开发人员和</cite>
用户之间的“紧张关系”与其他任何地方都相同。 它一直存在,并且将永远存在。</cite>

不。 并非如此,并非在所有地方都是如此。

区别,以及 Drupal 特有的问题是,Drupal 想要为 <em> 我的客户 </em> 和 <em> 我的特定案例、应用程序和项目 </em> 解决 UX 问题。 别来烦我!

作为一名开发人员,我想要一个工具,让我能够为我的特定案例构建完全合适的 UX(是的,有很多这样的工具)。 这种开发方式最有助于开发人员,而不会产生“拉锯战”。 因为当一个系统 <strong> 为我提供有效且高效的工具,为我的客户案例、我的项目或我的应用程序制作最佳 UX 时 </strong>,我 <em> 与 </em> “前端人员”合作,我与 UX 专家并肩工作; 而且我实际上可以实施我的客户从 UX 审查中获得的建议。

不过,我不认为这会阻碍 Drupal 的发展。 但我确实看到一个因素让我的项目和客户感到沮丧:我、我的团队或我的(分包)承包商交付的网站在 UX 方面简直太糟糕了。 当 CMS 的交付具有糟糕的内容管理 UX 时,这无济于事。 当为了修复它,你不得不通过如此多的胶水代码模块、主题覆盖等来破解你的方法时,这无济于事; 只是为了获得某种体面的工作流程、界面和体验。

这可能部分是因为我的心态优先考虑 UX 而几乎忽略其他一切,但我认为这是一个 <b> 巨大 </b> 的问题。

不合适的管理 UX,不值得努力自定义以匹配特定网站的工作流程和概念模型,这可能是我在评估 CMS 对各种项目的适用性时拒绝它们的首要原因。

Bèr,你提出了非常好的观点,谢谢。 我当然可以理解你所说的关于拥有正确工具的内容,我当然同意 Drupal 缺少一些关键要素——在我看来,它缺少整个 UX 设计师层(这与摆脱困境或构建自定义胶水模块的能力不同。)

我不会反驳你说的任何话,但我确实想更清楚地说明我的立场。 以我的经验来看,技术能力或局限性只是导致糟糕 UX 的众多潜在原因之一。 我遇到的其他因素包括糟糕的产品管理、缺乏 UX 人才、缺乏资金等。 但我最关心的首要问题是我认为的功能优先于用户体验的文化。 这就是造成开发人员和用户之间紧张关系的原因,我在我工作过的所有环境中都看到了这一点。 不,并非每个人都有这个问题,但它确实会出现。 这是许多软件供应商犯下的代价高昂的错误(我在这方面做了很多 UX 救援)。

因此,在这方面,我将 Drupal 的“状况”(糟糕的 UX 和缺乏足够的 UX 控制系统)视为历史上偏向于功能而不是用户体验的后果。 这里有两个例子:(A)FAPI 是开发人员构建单体表单以用于用户数据在表之间来回传输的便捷方式——但在大多数情况下,单体表单不是我推荐的 UX 策略。 (B)t() 函数是开发人员帮助 UI 可翻译的便捷方式——但它对达到更微妙的习语用法上下文毫无作用,而这些上下文非常常见。

我认为这些具体示例是 Drupal 开发社区迄今为止为解决一些基本问题所做的最大努力,它们本质上是功能性策略。 作为一名开发人员,我发现它们非常有用。 但作为一名 UX 设计师,这些技术就目前而言,远未达到满足许多 UX 要求的水平。

我认为 Drupal 社区越来越重视用户体验,这很棒。 我们面前确实有很多挑战。 好消息是,正如你在评论中说的那样,有方法让后端、前端和 UX 设计师高效地合作,以满足客户的需求。 我希望我们能在 Drupal 世界中实现这一点。

我认为我们达成一致。 :)

但还需要进一步澄清

<cite>以我的经验来看,技术能力或局限性只是导致糟糕 UX 的众多潜在原因之一。 我遇到的其他因素包括糟糕的产品管理、缺乏 UX 人才、缺乏资金等。</cite>

我的观点是,当一切都到位时:适当的管理、人才、预算等,那么技术可能是一个非常限制性的因素。 一个来自很久以前的 Drupal 5 站点的真实案例,为一个大型媒体公司(那是他们的第一个 Drupal 站点)。

两位 UX 专家设计了整个应用程序。 然后在 UX 实验室中进行了测试; 眼动追踪、故事、整个过程。 一位学生(UX 专家之一)在 UX 教授的指导下获得了优异的毕业成绩。 他们提出了更好的设计、线框图、模型、概念验证。 我们然后也对 SEO 进行了优化,另一位毕业生将这两个结果结合起来,提出了一个理论上是最佳 UX/SEO 优化的东西。

进入 Drupal。 进入我。 我们开发了大量的模块,只是为了接近这些报告中建议的 80%。 我们破解了核心代码。 添加了更多模块。 主题化了几乎所有可以想到的 theme() 函数。 结果是平庸的。 它通过了另一次 UX 实验室测试。 结果几乎和我们预料的一样:所有我们无法实施的东西,因为 Drupal 对它们的想法不同,都得到了“需要更改”的建议。

最终,一年多之后,我们在没有 UX 专家、SEO 专家的情况下重建了整个站点,只是采用了我们称之为“Drupal 的方式”。 节省了很多钱,SEO 还不错,UX 还算可以,而且网站的开发过程少了很多挣扎和斗争。

我学到的是:以这种方式工作:构思完美的网站,需要一个对其做事方式没有“想法”的工具。 例如,一个合适的、公正的框架。

这就是你所说的 <cite> 功能优先于用户体验 </cite>。 我认为我们(开发人员)认识到这是错误的。 但我们(开发人员)也必须保持现实,并指出所用工具的灵活性在哪里结束。 即,我们经常不得不告诉 UX 人员“对不起,但这在 Drupal 中不容易/不可能”。

你提到了 Drupal 的 FAPI。 我要提出 Drupal 中缺少任何适当的状态机,这是一个构建实际向导和表单流程所需的技术东西。 使开发人员和 UX 人员之间产生紧张关系的不是 FAPI 的“技术优点”,而是 FAPI 中缺乏适当的、现实的架构和功能,这使得你构建的 80% 的 Drupal 表单都很糟糕。

你提到了 t(),我要提出一个适当的、基于树的、上下文感知的 *本地化* 系统。 最简单的解释示例:t("registration.messages.thank-you"); 但实际上显然更高级和详细。

对于你所说的由于“技术限制”而导致紧张关系的大多数 UX 问题,确实有很好的解决方案; 只是它们在 Drupal(或 Joomla!,或者,是的,甚至是 Wordpress)中不存在。

是的,我认为我们达成一致。 感谢你的精彩回复 :)

我可以预见到我们会在这个问题上聊很久,但我不会再劫持这次讨论了。 如果你有兴趣联系,我的 Twitter 账号是 @useradvocate。 :)

干杯

<cite>我学到的是:以这种方式工作:构思完美的网站,需要一个对其做事方式没有“想法”的工具。 例如,一个合适的、公正的框架。</cite>

当使用预制组件时,总是需要权衡取舍——无论你是建造办公楼还是 Web 应用程序。

它们(可以)在功能/成本比率方面提供优势,但代价是精确的契合度。 好处:你无需构建核心。 坏处:你对核心的工作方式几乎没有发言权。

如果你愿意为了速度和生产成本而牺牲“完美的解决方案”(无论是在 UX 还是技术方面),并且(!) 要求 Drupal 在进行适度调整后是合适的——它可能是一个很好的选择。 如果它不适用于你的要求,那么弯曲 Drupal 可能是一个坏主意。 它最终仍然不会成为理想的解决方案,并且会在过程中造成高昂的成本和挫败感。

这样看来,Drupal 可能更像是那些制定预算的人的朋友,而不是那些编写代码的人的朋友。

说得好。
如果有人有预算来构建他们设想的确切 UX 和 UI,那么他们可以将这笔钱花在覆盖任何需要覆盖的特定 Drupal 原生功能上,或者他们可以付费使用他们选择的任何语言从头开始构建它。
在早期,我们看到 Drupal 的采用是因为它是“免费的”。 随着时间的推移,我们看到 Drupal 的采用是因为 Drupal 是“强大的”。
那些大胆声明 Drupal 的 UX 和 UI 问题的人也声明,没有其他 CMS 解决过这个问题。
归根结底,我们剩下的是 [我看到的] 明确的结论,即当一个组织开始 Drupal 之路时,他们将受益于其他人构建的大量代码和功能,并且该组织将对其内容和网站功能拥有巨大的控制权。
这对我来说听起来像是一个“双赢”局面。 ;-)

我买了一本 Drupal 6 的书,并尝试让一个网站工作,以匹配我已经用 Perl、C# 或 PHP 创建的干净简单的网站。 我遇到了一些功能,这些功能的原始目的显然已被重定向,因此这些名称与它们的目的不再很好地匹配。 我遇到了一些结构,这些结构显然是为一种特定效果而设计的,但不适合通用用途,或者涉及对代码的深入混乱的重新解释。 Drupal 是一团糟,它不需要成为一团糟,也不应该成为它所用于的通用目的的一团糟。 而且,由于向后兼容性问题,它基本上不可能修复,并且每次发布都不会变得更好。 作为一名程序员,我喜欢干净、逻辑和高效的东西。 这使得 Drupal 对我来说很不愉快,而不是我想投入大量精力的东西。 不幸的是,由于它的增长变得复杂,如果从头开始重新设计,这种复杂性是不必要的,因此,对于任何不适合可用模板的内容,使用 Drupal 都需要花费大量精力。 Drupal 的消亡不会让我感到难过。 作为一个相关的旁注,SharePoint 的兴起(请参阅关于它的其他评论)让我非常难过。 顺便说一句,我喜欢 Yii,我已经决定在不久的将来使用它。

Sorgfeit...
你“遇到了函数……”你用函数做了什么? 你遇到了哪些函数?
你是试图审计代码并更改它,还是试图按照本书推荐的方式构建网站? 我不知道有哪本书会告诉你去仔细阅读核心代码并评估命名约定并追溯其历史。
如果你指的是像我的朋友 Matt Butcher 在 2008 年 5 月发布的 Drupal 6 模块开发书籍,那么我可以再次向你保证,那本书没有揭示任何关于遗留命名函数的问题。 函数的名称不是我从人们那里听到的抱怨。
我确实听到过关于程序代码与 OO 代码的优势的抱怨。 我确实听到过关于文档缺乏或未针对较新版本更新的抱怨。
我会第一个告诉你,Drupal 本身可以关闭很多开发人员。 我们一直在进行内务处理,并有意识地努力使我们的生活更轻松,更不用说使它对潜在的新员工更具吸引力了。
但你刚才描述的经历对我来说是第一次。
这次采访中的问题是
“是什么阻碍了 Drupal 的主流采用?”
答案不是遗留命名函数,也不是“显然是为一种特定效果而设计的结构,但不适合通用用途”,也不是因为向后不兼容而无法修复的问题。
我们 [作为 Drupal] 有我们的缺点,但我不得不相信你所看的镜头非常模糊。 我不希望你再试一次。 正如我永远不会再用 XSLT 看 EZ-Publish 一样。 我不喜欢它,我不想使用它。
Drupal 发展得非常好,我尊重你不喜欢它并做其他事情的权利。
;-)

那是一年前的事了,我忘记了细节。 也许它们不是函数,而是对象。 无论如何,它们对我来说并非都说得通,我无法制作一个页面来匹配我已经用其他方式完成的页面。 可用的模板不合适,所以我尝试直接自定义页面。 我还没有完全放弃,只是决定先做其他工作一段时间。

我认为 Drupal 只是成为了自己成功的受害者。

在我加入社区的 4 年多时间里,我看到它经历了惊人的、加速的增长。 与此同时,它也成为公众越来越熟悉的名字和参与者。 公共部门和私营部门都知道它的存在,并且在货比三家时经常将 Drupal 放在他们的潜在列表的首位。

因此,与其“抱怨”人才匮乏,不如从实际情况来看待它。 这是对 Drupal 的需求不断增长的结果,也是新人才以此为生的机会。

对我来说,这一切都非常积极,因为它表明 Drupal 将在未来几年内继续存在,因此每个人都可以安全地将自己的未来押在它身上。

社区面临的真正挑战是如何处理 Drupal 的长期增长,并停止过多地寻找短期解决方案。 每个人都知道 Drupal 的学习曲线非常陡峭。 解决这个问题的唯一方法是着眼长远,以及需要做些什么才能实现目标。

在慕尼黑的 DrupalCon 大会上,我一遍又一遍地听到 Drupal 8 核心倡议负责人谈论他们获得所需资源有多么困难,仅仅是资金方面,才能在功能/代码冻结之前尽可能地做好他们的倡议。 看看 Drupal 生态系统包含多少资金,他们需要的几乎可以被视为咖啡钱。

那么,我们如何解决资助 Drupal 长期发展的问题呢? 如果我们找到这个问题的答案,那么对我们所有人来说,很多事情都会变得容易得多。

我也发现了这个问题,Thomas。 我脑海中浮现出一个想法,Drupal 协会可以在这里提供帮助。 如果有一个中心地点,人们和公司可以捐款,Dries(与倡议负责人或其他人员)可以根据需要分配这笔钱,那会怎么样? 那么我们也许能够更快、更好地完成重要但不太“性感”的倡议。 目前一些倡议负责人为获得资金和资源而付出的努力令人痛心。 如果你明白我的意思……他们应该专注于让 Drupal 变得更好,而不是项目管理如何让 Drupal 变得更好。

Doug... 感谢 Drupal 入门培训。 我喜欢 Drupal 开箱即用的功能,而不是其他 CMS。 我会为那些将从其功能中受益的网站推荐它。 再次感谢。

Creative Commons License本作品根据知识共享署名-相同方式共享 3.0 未本地化许可协议获得许可。
© 2025 open-source.net.cn. All rights reserved.