65.9K
CodeProject 正在变化。 阅读更多。
Home

PDC 2003 - 洛杉矶会议中心

starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.85/5 (34投票s)

2003年11月3日

CPOL

16分钟阅读

viewsIcon

154371

简要回顾多年来规模最大的开发者大会

引言

今年的PDC 2003在洛杉矶举行。洛杉矶平常清新的空气,因为森林大火而变得浑浊,浓稠得甚至可以让你在牙齿间感受到它的质感。

今年的焦点是Whidbey、Longhorn和Yukon。或者,对于那些不会说或选择不说微软黑话的人来说,那就是下一版本的Visual Studio .NET和.NET 2.0,即将推出的Windows版本以及新的.NET友好版SQL Server。此外,还有许多新的代号和技术:Avalon和Indigo(用于显示Longhorn桌面和新的通信服务的Windows Presentation Services)。WinFX(Windows UI API),WinFS(基于SQL Server的Windows文件系统),等等。

作为一场会议,PDC 2003无疑规模宏大。而洛杉矶会展中心,则可以用“巨大”来形容。我看到了一些穿着印有“SOLD OUT”字样的PDC T恤的人,我忍不住想,一张票就要几千美元,组织者竟然无法在这个巨大的空间里再挤出几个座位来。

展会期间的网络连接非常糟糕,简直可以说是糟糕透顶。大多数开放区域和休息室都有无线网络,但速度极其缓慢,并且经常断线。酒店也出现了类似的问题,这使得与办公室保持联系变得有些困难。真是讽刺。

让我们开始编码吧!

这次PDC的关键词是:是时候开始疯狂编码了。现在大多数人至少对.NET 1.0和1.1有所了解,但.NET 2.0的推出,希望能为那些希望开始接触.NET的人注入新的动力。

让我们从主旨演讲开始。这是一场相当朴实低调的演示,主席看起来比以前更老,也更疲惫。我喜欢这次主旨演讲的一点是,它没有让比尔·盖茨打扮成奥斯汀·鲍尔斯。我仍然对那次有阴影。不过,它确实持续了三个多小时,比《与狼共舞》还要长。然而,《与狼共舞》中没有史蒂夫·鲍尔默推销假珠宝的场景。还有那个经典的《计算简史》视频,展示了我们过去20年的进步,但带有一点可爱的自嘲,微软承认他们几乎错过了互联网浪潮,并且事实上并不是所有酷炫事物的原创者。

展示过去20年进步的有趣之处在于,它能让演讲者预测我们3年后会达到什么水平。想象一下:1 TB的存储空间,GB级的RAM,强大的显卡,以及连NSA都会垂涎的双核CPU。但这究竟是预测,还是仅仅是Longhorn的最低配置要求?

主旨演讲有点太长了,但包含了很多信息,对新技术进行了精彩的演示,实时编码演示,以及足够的概述让你胃口大开,为接下来四天的密集分会做好准备。Longhorn确实会很有趣。我开始有点厌烦Don Box一遍又一遍地展示他如何熟练地使用emacs打字,尤其是考虑到使用新版Visual Studio .NET进行编码会更有用、更相关,而且速度更快。据我所知,重点在于你不需要昂贵的Visual Studio .NET IDE来创建.NET应用程序。我担心的则是,VS.NET Whidbey非常适合编写.NET应用程序,以至于你使用免费编辑器节省的任何钱都将因为损失VS.NET提供的生产力而白费。总的来说,Visual Studio .NET是一项了不起的成就。微软,展示出来,为之骄傲吧。

安全计算。又一次

微软正在重申安全计算的信息。PDC赠送的资料包中包含了一本微软出版社的书籍《编写安全代码2》。这是前一版本的一个很好的更新,继续强调对输入的怀疑、使用可用的安全API和常识。.NET本身就内置了强大的安全框架,Visual C++也提供了“安全”API来防止缓冲区溢出。有多少人每天都在实际使用它们?

让我思考片刻。我的感觉是,当我们每个人都开始检查NULL句柄并将所有可能的故障点包装在try/catch块中时,安全计算就会实现。我们都想编写安全的应用,编写不可破解的代码。这并不难,但可能很耗时。除非为客户锁定应用程序变成经济上的必然,否则我们不会看到为实现安全计算而投入的相应资源。新的编译器开关来检查代码,底层操作系统中更多的检查数据机制将大有帮助,但这仍然是一个迭代的过程,无论多少指导都无法完全解决。但我们必须尝试。

Longhorn

Longhorn是下一版本的Windows操作系统,它带来的变化堪比Windows 95与Windows 3.1的变革。我的初步想法是:

  1. 购买英伟达(nVidia)和ATI的股票。随着Longhorn和Doom 3的即将发布,*每个人*都将需要皮克斯级别的显卡。
  2. 15英寸显示器正式被淘汰。Longhorn至少需要1024x768的分辨率,而宽屏显示器将更有帮助。
  3. 许多人以前提出过,并且以后还会继续提出一个批评:微软——拜托,*拜托*,不要为了形式牺牲功能。我喜欢你们在Avalon和AERO方面所做的工作,但请不要忘记抓住这个机会,去优化那些自从DOS时代以来一直困扰我们的微小功能性烦恼。
  4. Longhorn中的许多“新”东西其实并非全新。但这也没什么。整合和改进现有技术以提供更无缝的体验是一件好事。只要你们不排斥第三方应用程序。你们以前因此惹过麻烦,还记得吗?

Longhorn由几项新的令人兴奋的技术组成,这些技术将使出版业在未来很多年里都能保持生计。Avalon是桌面,WinFS是存储系统,AERO是用户体验,Indigo是Web服务,WinFX是新的编程模型。

Avalon

Avalon是新的Windows桌面合成引擎,它取代了旧的GDI和GDI+。它在可能的情况下利用图形加速器的强大功能,减轻CPU的负担,并在不增加应用程序成本的情况下提供增强的图形用户体验。硬件要求相当于任何现代多媒体计算机的能力,即能够以32位色彩深度、64MB或128MB显存运行1024x768分辨率的显卡,以及普通的3D功能。

在Avalon中,窗口被渲染到后备缓冲区,然后(以及任何必要的视觉样式,如透明度和阴影)组合在一起,形成最终的屏幕图像。你将不再看到一个窗口在另一个窗口拖动时出现的空白区域。一切都流畅、无缝,而且极其酷炫。

Avalon是基于向量的,这意味着它可以根据你使用的设备或区域进行缩放。以像素或英寸为单位指定坐标——细节将由系统处理。Avalon也基于复用。现有应用程序可以在不重写的情况下嵌入Avalon控件。多媒体可以嵌入任何地方,演示一个在滚动条旁边显示微型视频预览的精彩片段令人印象深刻。墨水(Ink)也是操作系统的一部分,以至于资源管理器中代表文档的图标将显示Ink标签而不是标准文本。太棒了。

Avalon应用程序构建在新的WinFX框架上,该框架复制了最初ASP.NET模型中分离设计和实现层的方式。布局使用XML语法(XAML)来定义控件、它们的属性和事件处理程序,然后由代码隐藏处理细节。Don Box和Chris Anderson演示了新的编程方法。抱歉,C++的开发者们,MFC在Avalon/WinFX/XAML这个生命故事中无处容身。

.NET 1.0和1.1分别提供了Web Forms和Windows Forms模型,分别类似于之前的ASP和Win32/MFC编程模型。Avalon用一个统一的编程模型取代了它们,该模型允许单个应用程序通过更改构建环境就可以编译成Web版或桌面版。

我只希望他们包含一些可用的皮肤和主题。不要再有果冻豆了!

AERO

AERO(据称是“Authentic Energetic Reflective Open”的缩写)是Longhorn的新用户体验(UX)。没错,UI已经out了,UX才in。奇特且不幸的缩写扩展也是如此。这是一种让你体验桌面环境的方式,而不仅仅是使用它。我——我只等着神经接口了。没有截图,因为它还没有完全成型,微软对此有些保密。

请务必查看Paul Thurrott的WinSupersite上的Longhorn Aero rocks视频。有人知道视频背后的音乐名称吗?它最近在丰田的广告中用过,我怎么也想不起来。

WinFS

WinFS(FS代表'Future System')基于新的SQL Server,运行在NTFS之上。文件不再仅仅按目录查看——它们现在可以按作者、项目或你指定的任何其他属性查看和分组。它使Windows资源管理器基于任务而不是文件位置。而且它速度很快。打开一个包含1000个文档的视图,并对文档内容进行全文搜索,搜索结果列表在你输入时就已经准备好了。

Indigo

Indigo是Longhorn通信服务集合的代号。Indigo将.NET Remoting、传统的.NET Web服务和.NET Enterprise服务结合在一个统一的服务导向型设计中。

Visual Studio .NET Whidbey

下一版本的Visual Studio .NET旨在针对.NET 2.0,因此被命名为Visual Studio .NET Whidbey。设计器、语言、编译器和功能的改进无疑将提高开发者的生产力,当然也会惹恼一些开发者。这就是自然规律。然而,如果我再听到一个微软的传道者谈论如何用0行代码(是的,零!)轻松创建一个应用程序,我就会用头脑和身体殴打他们。我们是*开发者*。我们*喜欢*编程。这就是他们*付钱*给我们的原因。我迫不及待地想看到所有那些千篇一律的Windows和Web应用程序……

说真的:Whidbey很棒。它汇集了.NET 2.0的最佳特性,并修复了2002和2003年的一些旧问题。PDC发布的构建版本中没有包含超级酷炫的新C++功能,但它们肯定会在最终版本中出现。

有关VS.NET Whidbey的截图和更多信息,请参阅Visual Studio 'Whidbey' and VSIP - the VSLive keynote in New York

Visual C++ .NET

下一版本的VS.NET基于VS.NET 2003的改进,同时引入了.NET 2.0的新功能。Visual C++和Managed Extensions得到了极大的改进,以至于在托管环境中使用的C++现在真正可用了。我与一些已经将新的.NET项目迁移到C#的C++开发者交谈过,他们现在正在考虑将所有东西移回C++有多难。正如通常情况一样,微软在2.0版本中做对了,但这对于Visual C++来说是不是太晚了?希望不是。

关于C++变化的详细总结将很快发布。

Visual C#

C#的最大新闻是泛型的出现。泛型不是C++意义上的模板。泛型基于CLR,提供了一种类型安全、高性能、编译时验证的方法,可以重用相同的代码块处理不同的数据类型。还包括了匿名方法——对于那些接触过Javascript的人来说,它的形式很熟悉,以及迭代器。迭代器消除了实现枚举器的一些繁琐工作。记住,我们的目标是0行代码,各位。

还支持重构、代码模板和更好的IDE支持。

Visual Basic .NET

VB.NET程序员将获得一系列新功能,例如名为“My”的类,用于访问系统资源,预先构建的代码模板,拼写错误的智能提示,以及改进的调试体验。还将包括语言增强功能,如运算符重载、无符号数据类型和部分类型,以及泛型,当然还有C#风格的XML注释。

ASP.NET 2.0

ASP.NET 2.0是一个重大的改变。我最大的不满是1.0版本,VS.NET 2003对同一个文件中的代码和HTML支持非常有限。如果你只想覆盖单个事件或设置ASP.NET页面中的几个属性,就没有必要为该ASP.NET页面创建一个单独的代码隐藏文件和资源文件。2.0版本解决了这个问题,并引入了对代码和HTML并存于同一文件中的完全支持,而无需抱怨缺少代码隐藏文件。

ASP.NET 2.0的另一个原则是只创建必要的文件。没有.resx文件,没有项目文件。只需将你的IDE指向Web应用程序的根目录,它就会认为该目录中的所有内容都属于该解决方案。这对于快速上手非常方便,但当目录中存在你不希望包含在解决方案中的文件时(例如备份文件或尚未使用的示例代码目录),就会很烦人。本质上,你需要保持目录的干净整洁。哦,而且不要指望Web应用程序目录中的代码隐藏文件会停留在你放置它们的地方。解决方案升级向导会好心地将所有代码隐藏文件移到一个特殊的code/目录(类似于已编译程序集的bin/目录)。微软,抱歉,但这是一个非常、非常烦人的强制性创新。

说到烦人,对于那些希望从ASP.NET 1.1迁移到2.0的人来说,还有一个惊喜。ASP.NET 2.0基于.NET 2.0,并广泛使用部分类——在多个文件中实现的类。部分类在ASP.NET 2.0中的具体用法是在代码隐藏模型中。你的ASP.NET页面不再从你的代码隐藏类派生,而是页面本身是类定义和实现的一部分。这意味着你不再需要将ASP.NET页面中出现的元素隐式声明为代码隐藏类中的公共成员。它们在构成ASP.NET页面的HTML中被隐式声明。我提到的惊喜是,迁移向导会移除.NET 1.1中必需的所有控件声明,让你在代码中留下可疑的空白,并且无法回到1.1。当向导让你备份项目时,它指的是*整个*项目。

同样值得关注的是一个很棒的功能,即开发Web应用程序不再需要IIS。这对于那些使用非服务器操作系统的用户来说尤其方便,因为这些操作系统对IIS托管的Web应用程序数量有限制。

另一个重大改变是ASP.NET应用程序中不再有构建步骤。应用程序在运行时即时构建,使得更新应用程序部分比以前更容易。这意味着如果你想将应用程序的一部分封装在程序集中供ASP.NET页面使用,那么你将不得不为这些程序集创建一个单独的项目。你可以在Whidbey Web应用程序中直接包含中间层组件,但当前的构建版本对此不满意。

Master Pages的概念已被包含在2.0中。这些基本上是模板,允许你从一个主页派生新页面,以确保整个站点的视觉一致性。主页的内置设计非常出色。还包括对皮肤和主题的内置支持。这有多大用处还有待观察。

总的来说,ASP.NET 2.0应该是1.0本该有的样子。它优雅、简单,允许你以自己想要的方式编码,但它也尚未完全准备好投入使用。我甚至有微软的人承认他们未能成功迁移以前的ASP.NET 1.0/1.1应用程序。但很快了。很快。

博客

PDC期间,几乎人人都在写博客。我认为这里说明了一切。

洛杉矶和会议

洛杉矶周围的森林大火极大地影响了会议。消息称,一个控制空中交通的主要指挥塔受到了火焰的威胁而关闭,导致南加州地区所有航班取消。许多与会者在被转飞洛杉矶后,在飞机上度过了数小时的等待,有些人则完全错过了第一天。在我看来,在这个时代,一个单一的塔楼或设施就能影响航空旅行,这真是荒谬。此外,火灾产生的烟雾降低了能见度,使空气变得如此浑浊,以至于持续笼罩着一层薄雾。在本周的大部分时间里,我看到并与一些疲惫不堪的与会者交谈。不是因为会议的快节奏(虽然它本身也很累人),而是因为感觉那一周的空气都不够清新。

出租车司机也很有趣。我们遇到的出租车司机几乎在被呼叫后,就像玩碰碰车一样与其他车辆擦撞,差点造成事故;还有走神的司机,差一点发生碰撞,只靠精妙地踩刹车幸免于难,留下长长的、冒着烟的黑色轮胎印;以及一些司机,他们愉快地在一处单行道上逆向行驶。我还在犹豫,究竟哪一种更危险:出去散步呼吸点新鲜空气,还是坐在一辆洛杉矶的出租车里。

洛杉矶本身让我感到非常沮丧。我不知道是因为时差、烟雾、数量惊人且种类繁多的无家可归者、城市蔓延、灰蒙蒙的天空,还是仅仅缺乏一个令人振奋的(且可见的)焦点,但最终,下面的雕塑和相关的牌匾说明了一切。

我们参加了派对,但由于不想排长队而错过了环球影城派对。我们参加了Standard酒店的派对,在那里我们被Don Box的歌声“攻击”了。Don,还是专注于Web服务吧。拜托。

最后,我们确实见到了CodeProject的一些读者,这很棒。持续的网络连接问题和被打乱的计划意味着这次聚会没有我们希望的那样周密计划,但很高兴见到那些能够到场的人,无论时间多么短暂。谢谢大家!


© . All rights reserved.