WPF开发简介
要赢得世界，必须在恰当的时间做出恰当的事。这一点，微软做到了。历经微软DOS，Win 31, Win95, Win 98, Win 2k, WinXP, 一路走来，一次比一次热闹，一个比一个精彩、炫丽。Vista的宣传更是轰轰烈烈，喧嚣日上。
Microsoft总是有能力在恰当的时间制造出意料中的轰动，Vista一经推出便让IT业界趋之若鹜。
一、掀起你的盖头来，让我看看你的脸——.NET Framework 3.0
与微软对Vista锣鼓宣天的推广相比，对与之相伴的.NET Framework 3.0却显得非常低调。微软没将它作为宣传重点。所有的幕后英雄总是默默无闻。对普通用户而言，他们不关心舞台背后的一切，它们更关心的是前台的表现，是那种炫丽奢华的感觉。真正热捧幕后英雄的，也是我们这群在幕后默默耕耘的程序员们。我们对.NET Framework 3.0有种自然而然的亲切感，因为我们将在此架构上为Vista编写各种程序。
作为微软精心打造的新一代.NET架构，.NET Framework 3.0在Vista时代担当最主要的应用程序接口。.NET曾被微软寄予厚望和重托，比尔·盖茨先生欲用之来实现一统江湖之志。事实证明，微软对.Net的推出是成功。越来越多的应用程序开发者已从Win32和JAVA架构转向.NET开发，越来越多的网站开发人员爱上了asp.net。这让微软看到了希望，他们踌躇满志，他们加紧了对.NET的研发，升级速度越来越快，.NET Framework 3.0就是微软在.NET Framework 2.0后最重要的升级。甚至有人惊呼，我们象刘翔一样地飞奔也跟不上微软的速度！
到了.NET Framework 3.0，.NET令程序员更称心、并逐渐“倾心”。在众多的开发环境，微软的开发系列产品，让它在与其它架构的较量中逐渐抢得上风而独在鳌头。
Vista集成.NET Framework 3.0，可谓珠联璧合。可以这么讲，没有.Net Framework 3.0这个幕后英雄，Vista会黯淡很多。
.NET Framework 3.0（原代号“WinFX”），它构建于.NET Framework 2.0之上，同时新增了四个大组件：Windows Presentation Foundation（WPF），Windows Workflow Foundation（WWF）、Windows Communication Foundation（WCF）和Windows CardSpace，而这些恰是NET Framework 3.0最具价值的部分。
其中，最令人瞩目的是WPF（原来代号为“Avalon”），它是微软全新的图形界面引擎，为各种应用提供统一的界面技术。程序员在WPF的帮助下，要开发出媲美Mac程序的酷炫界面已不再是遥不可及的奢望。Windows Workflow Foundation用于开发基于工作流的应用程序；Windows Communication Foundation则用于开发面向服务的应用程序，它是新一代通讯和网络开发框架，为不同类型的网络应用程序提供了一个通用的编程模型，尤其是包含其中的PeerChannel模块，以难以置信的方式消除了开发P2P应用程序的复杂性和困难度；而Windows CardSpace提供数字标志用户控件。如果把这些林林总总小巧精美的产品比做是珍珠的话，那么，需要一根金线将这些珍珠串起来，珍珠才更有价值，珍珠才熠熠生辉。而串起这颗珍珠的金线，就是.NET Framework 3.0。
二、搭建Vista程序的开发环境
1. 如果你使用的是Vista操作系统，那么，由于Vista已集成了.NET Framework 3.0，所以不必再单独安装.NET Framework 3.0。但是，如果你是Windows XP或Windows 2003下开发，则必须安装.NET Framework 3.0。
2. 要开发Vista应用程序，则必须有Vista SDK开发包的支持。Windows SDK for Windows Vista and .NET Framework 3.0包含了大量库文件、头文件、文档、示例和工具。由于Vista操作系统的推出时间比Visual Studio 2005开发工具要晚，因此，针对Windows Vista开发的Windows SDK和.NET Framework 3.0并未集成到Visual Studio 2005中。因此，必须下载此SDK，个头不小（当前最新版本是1.15GB），下载和安装时需要你足够的耐心和毅力，相信这个对于我们这些一向好脾气的程序员产不在话下。
3. 安装Visual Studio 2005(中/英文版均可，建议你习惯使用英文版，因为所有版本都是英文版的首先投放市场，而英文版到中文版，现实有三个月以上的时间差，而对于我们这些母语非英语的开发人员，英语关是一个必须跨越的槛，缘引鲁迅老先生的名言改编一下：世界并没有自己熟悉的路，走得多了，也就熟了路！英文看得多了，自然也就熟悉了）。
4. 下载并安装Visual Studio 2005 SP1，Visual Studio 2005 SP1 Update for Windows Vista。Visual Studio 2005 SP1修补Visual Studio 2005许多错误，并增强了一些性能，由于该补丁包要对Visual Studio 2005和Vista进行详细检测，安装比较耗时。
5.为了方便程序员开发.NET Framework 3.0下的新型应用，微软还推出了VS 2005 Extensions for .NET Framework 3.0（Workflow）和VS 2005 Extensions for .NET Framework 3.0（WCF&WPF）扩展组件，为Visual Studio 2005提供开发Windows Workflow Foundation、Windows Communication Foundation和Windows Presentation Foundation类型应用程序的模版。
6. 如果要学WPF，特别建议你安装Expression Blend（目前版本是Expression Blend 2 Agust Preview版）。这样，你可以在vs2005新建一个WPF项目，然后用Blend打开此项目，在Blend中对它进行界面设计和美化等工作，然后再转到vs2005下进行程序编码（两个程序之间支持来回切换）。
三、WPF简介
Windows Presentation Foundation（WPF）是微软新一代图形系统，运行在.NET Framework 3.0架构下，为用户界面、2D/3D 图形、文档和媒体提供了统一的描述和操作方法。基于DirectX 9/10技术的WPF不仅带来了前所未有的3D界面，而且其图形向量渲染引擎也大大改进了传统的2D界面，比如Vista中的半透明效果的窗体等都得益于WPF。微软还提供了专门的界面开发语言XAML（eXtensible Application Markup Language，可扩展应用程序标记语言），使得界面描述代码和程序代码得以分开，从而提高了开发效率并有利于团队开发。
XAML是微软为构建下一代应用程序界面而创建的一种新的基于XML的描述性语言，它可对WPF程序的所有界面元素进行定制，从而构成具有WPF风格的界面，并最终形成一个组织良好的XML文档。由于它最新会被编译成.Net后台代码，因此它能够同后台进行逻辑处理的.NET语言如C#、J#、C++、VB等协同工作，其工作性质类似于ASP.NET中的HTML。同HTML一样，XAML既可以直接编码，也可以由专门的工具生成。目前最好的XAML编辑器就是上面我建议你安装的Expression Blend了，但你也可以使用Windows SDK for Windows Vista中的XAMLPad，但功能却显得非常简单。
实际上，大多数WPF程序将同时包含XAML代码和程序代码，首先使用XAML定义程序界面，然后再用.NET语言编写相应的逻辑代码。跟ASP.NET类似，逻辑代码既可以直接嵌入XAML文件中，也可以将它保存为独立的代码文件。尽管XAML并非设计WPF程序所必须，按照传统方式使用程序代码来实现界面依然有效，但是如果使用XAML，界面设计和逻辑设计可以完全分离，不但使程序的开发和维护更加方便，而且在团队开发中，可以使程序员专注于业务逻辑的实现，而将界面设计交由专业人员来完成，从而使各类人员在项目中各尽其能各展其长，开发出功能强大、界面一流的WPF程序。
2008年11月10日星期一
WPF开发简介
WPF开发简介
要赢得世界，必须在恰当的时间做出恰当的事。这一点，微软做到了。历经微软DOS，Win 31, Win95, Win 98, Win 2k, WinXP, 一路走来，一次比一次热闹，一个比一个精彩、炫丽。Vista的宣传更是轰轰烈烈，喧嚣日上。
Microsoft总是有能力在恰当的时间制造出意料中的轰动，Vista一经推出便让IT业界趋之若鹜。
一、掀起你的盖头来，让我看看你的脸——.NET Framework 3.0
与微软对Vista锣鼓宣天的推广相比，对与之相伴的.NET Framework 3.0却显得非常低调。微软没将它作为宣传重点。所有的幕后英雄总是默默无闻。对普通用户而言，他们不关心舞台背后的一切，它们更关心的是前台的表现，是那种炫丽奢华的感觉。真正热捧幕后英雄的，也是我们这群在幕后默默耕耘的程序员们。我们对.NET Framework 3.0有种自然而然的亲切感，因为我们将在此架构上为Vista编写各种程序。
作为微软精心打造的新一代.NET架构，.NET Framework 3.0在Vista时代担当最主要的应用程序接口。.NET曾被微软寄予厚望和重托，比尔·盖茨先生欲用之来实现一统江湖之志。事实证明，微软对.Net的推出是成功。越来越多的应用程序开发者已从Win32和JAVA架构转向.NET开发，越来越多的网站开发人员爱上了asp.net。这让微软看到了希望，他们踌躇满志，他们加紧了对.NET的研发，升级速度越来越快，.NET Framework 3.0就是微软在.NET Framework 2.0后最重要的升级。甚至有人惊呼，我们象刘翔一样地飞奔也跟不上微软的速度！
到了.NET Framework 3.0，.NET令程序员更称心、并逐渐“倾心”。在众多的开发环境，微软的开发系列产品，让它在与其它架构的较量中逐渐抢得上风而独在鳌头。
Vista集成.NET Framework 3.0，可谓珠联璧合。可以这么讲，没有.Net Framework 3.0这个幕后英雄，Vista会黯淡很多。
.NET Framework 3.0（原代号“WinFX”），它构建于.NET Framework 2.0之上，同时新增了四个大组件：Windows Presentation Foundation（WPF），Windows Workflow Foundation（WWF）、Windows Communication Foundation（WCF）和Windows CardSpace，而这些恰是NET Framework 3.0最具价值的部分。
其中，最令人瞩目的是WPF（原来代号为“Avalon”），它是微软全新的图形界面引擎，为各种应用提供统一的界面技术。程序员在WPF的帮助下，要开发出媲美Mac程序的酷炫界面已不再是遥不可及的奢望。Windows Workflow Foundation用于开发基于工作流的应用程序；Windows Communication Foundation则用于开发面向服务的应用程序，它是新一代通讯和网络开发框架，为不同类型的网络应用程序提供了一个通用的编程模型，尤其是包含其中的PeerChannel模块，以难以置信的方式消除了开发P2P应用程序的复杂性和困难度；而Windows CardSpace提供数字标志用户控件。如果把这些林林总总小巧精美的产品比做是珍珠的话，那么，需要一根金线将这些珍珠串起来，珍珠才更有价值，珍珠才熠熠生辉。而串起这颗珍珠的金线，就是.NET Framework 3.0。
二、搭建Vista程序的开发环境
1. 如果你使用的是Vista操作系统，那么，由于Vista已集成了.NET Framework 3.0，所以不必再单独安装.NET Framework 3.0。但是，如果你是Windows XP或Windows 2003下开发，则必须安装.NET Framework 3.0。
2. 要开发Vista应用程序，则必须有Vista SDK开发包的支持。Windows SDK for Windows Vista and .NET Framework 3.0包含了大量库文件、头文件、文档、示例和工具。由于Vista操作系统的推出时间比Visual Studio 2005开发工具要晚，因此，针对Windows Vista开发的Windows SDK和.NET Framework 3.0并未集成到Visual Studio 2005中。因此，必须下载此SDK，个头不小（当前最新版本是1.15GB），下载和安装时需要你足够的耐心和毅力，相信这个对于我们这些一向好脾气的程序员产不在话下。
3. 安装Visual Studio 2005(中/英文版均可，建议你习惯使用英文版，因为所有版本都是英文版的首先投放市场，而英文版到中文版，现实有三个月以上的时间差，而对于我们这些母语非英语的开发人员，英语关是一个必须跨越的槛，缘引鲁迅老先生的名言改编一下：世界并没有自己熟悉的路，走得多了，也就熟了路！英文看得多了，自然也就熟悉了）。
4. 下载并安装Visual Studio 2005 SP1，Visual Studio 2005 SP1 Update for Windows Vista。Visual Studio 2005 SP1修补Visual Studio 2005许多错误，并增强了一些性能，由于该补丁包要对Visual Studio 2005和Vista进行详细检测，安装比较耗时。
5.为了方便程序员开发.NET Framework 3.0下的新型应用，微软还推出了VS 2005 Extensions for .NET Framework 3.0（Workflow）和VS 2005 Extensions for .NET Framework 3.0（WCF&WPF）扩展组件，为Visual Studio 2005提供开发Windows Workflow Foundation、Windows Communication Foundation和Windows Presentation Foundation类型应用程序的模版。
6. 如果要学WPF，特别建议你安装Expression Blend（目前版本是Expression Blend 2 Agust Preview版）。这样，你可以在vs2005新建一个WPF项目，然后用Blend打开此项目，在Blend中对它进行界面设计和美化等工作，然后再转到vs2005下进行程序编码（两个程序之间支持来回切换）。
三、WPF简介
Windows Presentation Foundation（WPF）是微软新一代图形系统，运行在.NET Framework 3.0架构下，为用户界面、2D/3D 图形、文档和媒体提供了统一的描述和操作方法。基于DirectX 9/10技术的WPF不仅带来了前所未有的3D界面，而且其图形向量渲染引擎也大大改进了传统的2D界面，比如Vista中的半透明效果的窗体等都得益于WPF。微软还提供了专门的界面开发语言XAML（eXtensible Application Markup Language，可扩展应用程序标记语言），使得界面描述代码和程序代码得以分开，从而提高了开发效率并有利于团队开发。
XAML是微软为构建下一代应用程序界面而创建的一种新的基于XML的描述性语言，它可对WPF程序的所有界面元素进行定制，从而构成具有WPF风格的界面，并最终形成一个组织良好的XML文档。由于它最新会被编译成.Net后台代码，因此它能够同后台进行逻辑处理的.NET语言如C#、J#、C++、VB等协同工作，其工作性质类似于ASP.NET中的HTML。同HTML一样，XAML既可以直接编码，也可以由专门的工具生成。目前最好的XAML编辑器就是上面我建议你安装的Expression Blend了，但你也可以使用Windows SDK for Windows Vista中的XAMLPad，但功能却显得非常简单。
实际上，大多数WPF程序将同时包含XAML代码和程序代码，首先使用XAML定义程序界面，然后再用.NET语言编写相应的逻辑代码。跟ASP.NET类似，逻辑代码既可以直接嵌入XAML文件中，也可以将它保存为独立的代码文件。尽管XAML并非设计WPF程序所必须，按照传统方式使用程序代码来实现界面依然有效，但是如果使用XAML，界面设计和逻辑设计可以完全分离，不但使程序的开发和维护更加方便，而且在团队开发中，可以使程序员专注于业务逻辑的实现，而将界面设计交由专业人员来完成，从而使各类人员在项目中各尽其能各展其长，开发出功能强大、界面一流的WPF程序。
要赢得世界，必须在恰当的时间做出恰当的事。这一点，微软做到了。历经微软DOS，Win 31, Win95, Win 98, Win 2k, WinXP, 一路走来，一次比一次热闹，一个比一个精彩、炫丽。Vista的宣传更是轰轰烈烈，喧嚣日上。
Microsoft总是有能力在恰当的时间制造出意料中的轰动，Vista一经推出便让IT业界趋之若鹜。
一、掀起你的盖头来，让我看看你的脸——.NET Framework 3.0
与微软对Vista锣鼓宣天的推广相比，对与之相伴的.NET Framework 3.0却显得非常低调。微软没将它作为宣传重点。所有的幕后英雄总是默默无闻。对普通用户而言，他们不关心舞台背后的一切，它们更关心的是前台的表现，是那种炫丽奢华的感觉。真正热捧幕后英雄的，也是我们这群在幕后默默耕耘的程序员们。我们对.NET Framework 3.0有种自然而然的亲切感，因为我们将在此架构上为Vista编写各种程序。
作为微软精心打造的新一代.NET架构，.NET Framework 3.0在Vista时代担当最主要的应用程序接口。.NET曾被微软寄予厚望和重托，比尔·盖茨先生欲用之来实现一统江湖之志。事实证明，微软对.Net的推出是成功。越来越多的应用程序开发者已从Win32和JAVA架构转向.NET开发，越来越多的网站开发人员爱上了asp.net。这让微软看到了希望，他们踌躇满志，他们加紧了对.NET的研发，升级速度越来越快，.NET Framework 3.0就是微软在.NET Framework 2.0后最重要的升级。甚至有人惊呼，我们象刘翔一样地飞奔也跟不上微软的速度！
到了.NET Framework 3.0，.NET令程序员更称心、并逐渐“倾心”。在众多的开发环境，微软的开发系列产品，让它在与其它架构的较量中逐渐抢得上风而独在鳌头。
Vista集成.NET Framework 3.0，可谓珠联璧合。可以这么讲，没有.Net Framework 3.0这个幕后英雄，Vista会黯淡很多。
.NET Framework 3.0（原代号“WinFX”），它构建于.NET Framework 2.0之上，同时新增了四个大组件：Windows Presentation Foundation（WPF），Windows Workflow Foundation（WWF）、Windows Communication Foundation（WCF）和Windows CardSpace，而这些恰是NET Framework 3.0最具价值的部分。
其中，最令人瞩目的是WPF（原来代号为“Avalon”），它是微软全新的图形界面引擎，为各种应用提供统一的界面技术。程序员在WPF的帮助下，要开发出媲美Mac程序的酷炫界面已不再是遥不可及的奢望。Windows Workflow Foundation用于开发基于工作流的应用程序；Windows Communication Foundation则用于开发面向服务的应用程序，它是新一代通讯和网络开发框架，为不同类型的网络应用程序提供了一个通用的编程模型，尤其是包含其中的PeerChannel模块，以难以置信的方式消除了开发P2P应用程序的复杂性和困难度；而Windows CardSpace提供数字标志用户控件。如果把这些林林总总小巧精美的产品比做是珍珠的话，那么，需要一根金线将这些珍珠串起来，珍珠才更有价值，珍珠才熠熠生辉。而串起这颗珍珠的金线，就是.NET Framework 3.0。
二、搭建Vista程序的开发环境
1. 如果你使用的是Vista操作系统，那么，由于Vista已集成了.NET Framework 3.0，所以不必再单独安装.NET Framework 3.0。但是，如果你是Windows XP或Windows 2003下开发，则必须安装.NET Framework 3.0。
2. 要开发Vista应用程序，则必须有Vista SDK开发包的支持。Windows SDK for Windows Vista and .NET Framework 3.0包含了大量库文件、头文件、文档、示例和工具。由于Vista操作系统的推出时间比Visual Studio 2005开发工具要晚，因此，针对Windows Vista开发的Windows SDK和.NET Framework 3.0并未集成到Visual Studio 2005中。因此，必须下载此SDK，个头不小（当前最新版本是1.15GB），下载和安装时需要你足够的耐心和毅力，相信这个对于我们这些一向好脾气的程序员产不在话下。
3. 安装Visual Studio 2005(中/英文版均可，建议你习惯使用英文版，因为所有版本都是英文版的首先投放市场，而英文版到中文版，现实有三个月以上的时间差，而对于我们这些母语非英语的开发人员，英语关是一个必须跨越的槛，缘引鲁迅老先生的名言改编一下：世界并没有自己熟悉的路，走得多了，也就熟了路！英文看得多了，自然也就熟悉了）。
4. 下载并安装Visual Studio 2005 SP1，Visual Studio 2005 SP1 Update for Windows Vista。Visual Studio 2005 SP1修补Visual Studio 2005许多错误，并增强了一些性能，由于该补丁包要对Visual Studio 2005和Vista进行详细检测，安装比较耗时。
5.为了方便程序员开发.NET Framework 3.0下的新型应用，微软还推出了VS 2005 Extensions for .NET Framework 3.0（Workflow）和VS 2005 Extensions for .NET Framework 3.0（WCF&WPF）扩展组件，为Visual Studio 2005提供开发Windows Workflow Foundation、Windows Communication Foundation和Windows Presentation Foundation类型应用程序的模版。
6. 如果要学WPF，特别建议你安装Expression Blend（目前版本是Expression Blend 2 Agust Preview版）。这样，你可以在vs2005新建一个WPF项目，然后用Blend打开此项目，在Blend中对它进行界面设计和美化等工作，然后再转到vs2005下进行程序编码（两个程序之间支持来回切换）。
三、WPF简介
Windows Presentation Foundation（WPF）是微软新一代图形系统，运行在.NET Framework 3.0架构下，为用户界面、2D/3D 图形、文档和媒体提供了统一的描述和操作方法。基于DirectX 9/10技术的WPF不仅带来了前所未有的3D界面，而且其图形向量渲染引擎也大大改进了传统的2D界面，比如Vista中的半透明效果的窗体等都得益于WPF。微软还提供了专门的界面开发语言XAML（eXtensible Application Markup Language，可扩展应用程序标记语言），使得界面描述代码和程序代码得以分开，从而提高了开发效率并有利于团队开发。
XAML是微软为构建下一代应用程序界面而创建的一种新的基于XML的描述性语言，它可对WPF程序的所有界面元素进行定制，从而构成具有WPF风格的界面，并最终形成一个组织良好的XML文档。由于它最新会被编译成.Net后台代码，因此它能够同后台进行逻辑处理的.NET语言如C#、J#、C++、VB等协同工作，其工作性质类似于ASP.NET中的HTML。同HTML一样，XAML既可以直接编码，也可以由专门的工具生成。目前最好的XAML编辑器就是上面我建议你安装的Expression Blend了，但你也可以使用Windows SDK for Windows Vista中的XAMLPad，但功能却显得非常简单。
实际上，大多数WPF程序将同时包含XAML代码和程序代码，首先使用XAML定义程序界面，然后再用.NET语言编写相应的逻辑代码。跟ASP.NET类似，逻辑代码既可以直接嵌入XAML文件中，也可以将它保存为独立的代码文件。尽管XAML并非设计WPF程序所必须，按照传统方式使用程序代码来实现界面依然有效，但是如果使用XAML，界面设计和逻辑设计可以完全分离，不但使程序的开发和维护更加方便，而且在团队开发中，可以使程序员专注于业务逻辑的实现，而将界面设计交由专业人员来完成，从而使各类人员在项目中各尽其能各展其长，开发出功能强大、界面一流的WPF程序。
2008年11月9日星期日
PowerShell and WPF: WTF
PowerShell and WPF: WTF
A number of people are confused by the WPF/PowerShell series and are "asking WTF?". Aaron has a blog entry, WPF and PowerShell Series - I don't get it. Caywen left a comment on the first in posting saying, "Ugh, I could make a peanut butter and squid sandwich, but that doesn't mean you should." (I like the visual on that one!).
I thought I would take a couple of minutes to explain a couple of points and provide some context.
PowerShell is NOT a CLI
I bet that one took you by surprise. Yup - it's true PowerShell is not a CLI. PowerShell is an AUTOMATION technology. Cmdlets are units of automation. Jim Truher recently reminded me that my original term for these were Functional Units (FUs) [No prizes for guess why that term got dropped]. The PowerShell engine is an automation engine that then get exposed through various ways: CLI, API, GUI, late-bound Web Services and at some point - early bound Web Services.
Now clearly we believe that the CLI is a critical piece of this picture. We've had a shockingly bad shell and pathetic command line coverage for decades and I was personally committed to fixing that. That said, if we just transformed a click click click of the mouse to a click click click of the keyboard - we would not have moved IT forward all that much. The point of CLIs is that you can AUTOMATE operations which can dramatically lower TOC costs while increasing IT quality through repeatability.
One of the key turning points in the project came when Mark Brown convinced me that layering GUIs over the automation had to be a top priority in order to become the mainstream of Microsoft. He pointed out that over the long term this might change but for now, we were a GUI dominated culture and that unless we could help people layer GUIs on top of PowerShell, automation would stay in the backwaters of the company. From that point on, we really focused on ensuring that the CLI was merely one of many consumers of the API. A number of groups starting with Exchange have decided that the PowerShell API is their developer story because it provides remoting, security, logging, etc.
TCL/TK
People like to talk about Unix's influence on PowerShell. That is absolutely true but I also try to point out the huge influence of unsung super engineers behind VMS/DCL and AS400/CL. I used to talk about this a lot but for some reason I haven't in a while but Tcl/TK had a huge influence on me and thus on PowerShell. John Ousterhout invented Tcl which was an embeddable scripting language. The first time I saw it, I fell in love. The language was OK but the architecture just captured my imagination - it just made sense. John also invented TK which provided a GUI toolkit for TCL. TK made it simple to throw together quick and dirty GUIs using Tcl.
Admins and ad hoc developers use Tcl/TK to produce some of the most god-awful looking GUIs and then absolutely LOVE them. Why? Because it allows them to easily produce a tool that exactly matches the problem that they have and they way they think about the problem. WHEN the problem changes, they just edit the file and a couple minutes later, their tool is again perfectly suited to their needs. Using these GUIs are like slipping on that baseball mitt you've been using for last 25 years, it feels like a perfect extension of your body and mind. Gone are the hideously complex "professional" tools that try to solve everyone's problems but have so many features that you can't find the one you need when you need it. Given the choice, I've seen a lot IT Pros choose ugly-but-useful.
PowerShell/WPF
While I love Tcl/TK, I also think we can do a lot better. The clock has moved forward and we have new technologies available. WPF is just a glorious UI surface. It provides a simple surface with incredible compositional power and utility. WPF's use of XAML means that we can leverage experienced designers using professional tools to take our quick and dirty tools and put them on par with the best of best. Because these are scripts, they are easy to share and customize to meet your specific needs. Advanced scripters can produce PowerShell / WPF scripts for others and then when you get it and decide that you need to add an extra button or two, you have the source code to see how it does what it does and can easily tweak it to meet your needs. The point I'm making is that with PowerShell/WPF the skill set required to TWEAK a GUI is very much lower than the skill set to CREATE the GUI.
I predict that the early adopters will pick up PowerShell/WPF, love it, and start producing some amazingly cool (but maybe ugly) GUIs. After a while, the next layer of people will start tweaking those scripts. After they've done that a couple of times, they'll have enough examples to start creating their own. Once that happens, you are going to see an explosion of custom tools. If you don't like the tools that MSFT delivers to you, you could try to convince us to change them and then wait a couple years till we re-release them or you could take a couple of hours and write yourself a custom tool that exactly meets your needs. THAT is going to be fun.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
Published Sunday, May 25, 2008 2:43 PM by PowerShellTeam
Filed under: WPF, PowerShell, Tcl, Tk
A number of people are confused by the WPF/PowerShell series and are "asking WTF?". Aaron has a blog entry, WPF and PowerShell Series - I don't get it. Caywen left a comment on the first in posting saying, "Ugh, I could make a peanut butter and squid sandwich, but that doesn't mean you should." (I like the visual on that one!).
I thought I would take a couple of minutes to explain a couple of points and provide some context.
PowerShell is NOT a CLI
I bet that one took you by surprise. Yup - it's true PowerShell is not a CLI. PowerShell is an AUTOMATION technology. Cmdlets are units of automation. Jim Truher recently reminded me that my original term for these were Functional Units (FUs) [No prizes for guess why that term got dropped]. The PowerShell engine is an automation engine that then get exposed through various ways: CLI, API, GUI, late-bound Web Services and at some point - early bound Web Services.
Now clearly we believe that the CLI is a critical piece of this picture. We've had a shockingly bad shell and pathetic command line coverage for decades and I was personally committed to fixing that. That said, if we just transformed a click click click of the mouse to a click click click of the keyboard - we would not have moved IT forward all that much. The point of CLIs is that you can AUTOMATE operations which can dramatically lower TOC costs while increasing IT quality through repeatability.
One of the key turning points in the project came when Mark Brown convinced me that layering GUIs over the automation had to be a top priority in order to become the mainstream of Microsoft. He pointed out that over the long term this might change but for now, we were a GUI dominated culture and that unless we could help people layer GUIs on top of PowerShell, automation would stay in the backwaters of the company. From that point on, we really focused on ensuring that the CLI was merely one of many consumers of the API. A number of groups starting with Exchange have decided that the PowerShell API is their developer story because it provides remoting, security, logging, etc.
TCL/TK
People like to talk about Unix's influence on PowerShell. That is absolutely true but I also try to point out the huge influence of unsung super engineers behind VMS/DCL and AS400/CL. I used to talk about this a lot but for some reason I haven't in a while but Tcl/TK had a huge influence on me and thus on PowerShell. John Ousterhout invented Tcl which was an embeddable scripting language. The first time I saw it, I fell in love. The language was OK but the architecture just captured my imagination - it just made sense. John also invented TK which provided a GUI toolkit for TCL. TK made it simple to throw together quick and dirty GUIs using Tcl.
Admins and ad hoc developers use Tcl/TK to produce some of the most god-awful looking GUIs and then absolutely LOVE them. Why? Because it allows them to easily produce a tool that exactly matches the problem that they have and they way they think about the problem. WHEN the problem changes, they just edit the file and a couple minutes later, their tool is again perfectly suited to their needs. Using these GUIs are like slipping on that baseball mitt you've been using for last 25 years, it feels like a perfect extension of your body and mind. Gone are the hideously complex "professional" tools that try to solve everyone's problems but have so many features that you can't find the one you need when you need it. Given the choice, I've seen a lot IT Pros choose ugly-but-useful.
PowerShell/WPF
While I love Tcl/TK, I also think we can do a lot better. The clock has moved forward and we have new technologies available. WPF is just a glorious UI surface. It provides a simple surface with incredible compositional power and utility. WPF's use of XAML means that we can leverage experienced designers using professional tools to take our quick and dirty tools and put them on par with the best of best. Because these are scripts, they are easy to share and customize to meet your specific needs. Advanced scripters can produce PowerShell / WPF scripts for others and then when you get it and decide that you need to add an extra button or two, you have the source code to see how it does what it does and can easily tweak it to meet your needs. The point I'm making is that with PowerShell/WPF the skill set required to TWEAK a GUI is very much lower than the skill set to CREATE the GUI.
I predict that the early adopters will pick up PowerShell/WPF, love it, and start producing some amazingly cool (but maybe ugly) GUIs. After a while, the next layer of people will start tweaking those scripts. After they've done that a couple of times, they'll have enough examples to start creating their own. Once that happens, you are going to see an explosion of custom tools. If you don't like the tools that MSFT delivers to you, you could try to convince us to change them and then wait a couple years till we re-release them or you could take a couple of hours and write yourself a custom tool that exactly meets your needs. THAT is going to be fun.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
Published Sunday, May 25, 2008 2:43 PM by PowerShellTeam
Filed under: WPF, PowerShell, Tcl, Tk
谷歌浏览器
Google （谷歌）中国的博客网志，走近我们的产品、技术和文化
谷歌浏览器（Google Chrome）, Chromium 以及竞争
2008年9月2日 下午 10:59:00
发表者：谷歌公关部
你的互联网体验本质上依赖于将你与互联网连接在一起的浏览器。在很长一段时间里，尽管网站变得越来越直观和越来越互动，浏览器的创新却一直没有跟上——浏览器很少更新，而且标准不统一，开发者不得不调整他们的网站，以适应各种各样的浏览器。
对每个人来说非常幸运的是，竞争终于引发了新一轮的浏览器创新。这一轮创新的核心是开源模式，这让开发者可以清晰地看到浏览器的开发过程，并且改进用户的浏览体验。这种模式已经产生了令人难以置信的成果，例如现在无处不在的紧邻地址栏的搜索框，以及允许使用特定功能定制浏览器的“扩展”概念。谷歌一直是开源计划的坚定支持者，我们的工程师与全球其他的技术社区一起，为无数项目做出了贡献。
不过，在我们为全球项目贡献力量的同时，我们也开始讨论我们认为会真正有益于用户的浏览器技术的革新。为了达成浏览器的技术革新，有些时候我们不得不从零开始，最终，我们开发了谷浏览器。我们的产品集合了我们的最新开发成果——例如多线程 JavaScript 引擎 V8，它的一些组成部分是由其他开源项目开发完成，这些项目包括 Apple's WebKit 和 Mozilla's Firefox。
这些工作使我们很快开发完成了一个强大的浏览器。为确保我们所推动的每一个进展都有益于整个互联网社区——不仅仅是我们自己，谷歌浏览器完全开源。谷歌浏览器的源代码放在 Chromium 之下，任何人都可以在他们的项目中使用谷歌浏览器的源代码——即使他们意图开发一个与我们形成竞争的浏览器（“Shrome”，或者其它名字？）。
我们所说的“开源”并不仅限于开放源代码。我们的意思还包括开放选择，而不是将人们局限于一个封闭的系统。这就是为什么我们允许用户在第一次启动谷歌浏览器时选择搜索引擎——如果你不想，你不必一定选择谷歌。
有竞争力的开源项目有利于互联网，有利于每个人，因为正是这些项目推动互联网的前进——同时，这些项目让每个人得益。开源项目鼓励激烈竞争，竞争激发创新，创新驱动演进，最后，演进正是互联网的生命线。
谷歌浏览器（Google Chrome）, Chromium 以及竞争
2008年9月2日 下午 10:59:00
发表者：谷歌公关部
你的互联网体验本质上依赖于将你与互联网连接在一起的浏览器。在很长一段时间里，尽管网站变得越来越直观和越来越互动，浏览器的创新却一直没有跟上——浏览器很少更新，而且标准不统一，开发者不得不调整他们的网站，以适应各种各样的浏览器。
对每个人来说非常幸运的是，竞争终于引发了新一轮的浏览器创新。这一轮创新的核心是开源模式，这让开发者可以清晰地看到浏览器的开发过程，并且改进用户的浏览体验。这种模式已经产生了令人难以置信的成果，例如现在无处不在的紧邻地址栏的搜索框，以及允许使用特定功能定制浏览器的“扩展”概念。谷歌一直是开源计划的坚定支持者，我们的工程师与全球其他的技术社区一起，为无数项目做出了贡献。
不过，在我们为全球项目贡献力量的同时，我们也开始讨论我们认为会真正有益于用户的浏览器技术的革新。为了达成浏览器的技术革新，有些时候我们不得不从零开始，最终，我们开发了谷浏览器。我们的产品集合了我们的最新开发成果——例如多线程 JavaScript 引擎 V8，它的一些组成部分是由其他开源项目开发完成，这些项目包括 Apple's WebKit 和 Mozilla's Firefox。
这些工作使我们很快开发完成了一个强大的浏览器。为确保我们所推动的每一个进展都有益于整个互联网社区——不仅仅是我们自己，谷歌浏览器完全开源。谷歌浏览器的源代码放在 Chromium 之下，任何人都可以在他们的项目中使用谷歌浏览器的源代码——即使他们意图开发一个与我们形成竞争的浏览器（“Shrome”，或者其它名字？）。
我们所说的“开源”并不仅限于开放源代码。我们的意思还包括开放选择，而不是将人们局限于一个封闭的系统。这就是为什么我们允许用户在第一次启动谷歌浏览器时选择搜索引擎——如果你不想，你不必一定选择谷歌。
有竞争力的开源项目有利于互联网，有利于每个人，因为正是这些项目推动互联网的前进——同时，这些项目让每个人得益。开源项目鼓励激烈竞争，竞争激发创新，创新驱动演进，最后，演进正是互联网的生命线。
OJ题目 简单
一.基本算法:
(1)枚举. (poj1753,poj2965)
(2)贪心(poj1328,poj2109,poj2586)
(3)递归和分治法.
(4)递推.
(5)构造法.(poj3295)
(6)模拟法.(poj1068,poj2632,poj1573,poj2993,poj2996)
二.图算法:
(1)图的深度优先遍历和广度优先遍历.
(2)最短路径算法(dijkstra,bellman-ford,floyd,heap+dijkstra)
(poj1860,poj3259,poj1062,poj2253,poj1125,poj2240)
(3)最小生成树算法(prim,kruskal)
(poj1789,poj2485,poj1258,poj3026)
(4)拓扑排序 (poj1094)
(5)二分图的最大匹配 (匈牙利算法) (poj3041,poj3020)
(6)最大流的增广路算法(KM算法). (poj1459,poj3436)
三.数据结构.
(1)串 (poj1035,poj3080,poj1936)
(2)排序(快排、归并排(与逆序数有关)、堆排) (poj2388,poj2299)
(3)简单并查集的应用.
(4)哈希表和二分查找等高效查找法(数的Hash,串的Hash)
(poj3349,poj3274,POJ2151,poj1840,poj2002,poj2503)
(5)哈夫曼树(poj3253)
(6)堆
(7)trie树(静态建树、动态建树) (poj2513)
四.简单搜索
(1)深度优先搜索 (poj2488,poj3083,poj3009,poj1321,poj2251)
(2)广度优先搜索(poj3278,poj1426,poj3126,poj3087.poj3414)
(3)简单搜索技巧和剪枝(poj2531,poj1416,poj2676,1129)
五.动态规划
(1)背包问题. (poj1837,poj1276)
(2)型如下表的简单DP(可参考lrj的书 page149):
1.E[j]=opt{D+w(i,j)} (poj3267,poj1836,poj1260,poj2533)
2.E[i,j]=opt{D[i-1,j]+xi,D[i,j-1]+yj,D[i-1][j-1]+zij} (最长公共子序列)
(poj3176,poj1080,poj1159)
3.C[i,j]=w[i,j]+opt{C[i,k-1]+C[k,j]}.(最优二分检索树问题)
六.数学
(1)组合数学:
1.加法原理和乘法原理.
2.排列组合.
3.递推关系.
(POJ3252,poj1850,poj1019,poj1942)
(2)数论.
1.素数与整除问题
2.进制位.
3.同余模运算.
(poj2635, poj3292,poj1845,poj2115)
(3)计算方法.
1.二分法求解单调函数相关知识.(poj3273,poj3258,poj1905,poj3122)
七.计算几何学.
(1)几何公式.
(2)叉积和点积的运用(如线段相交的判定,点到线段的距离等). (poj2031,poj1039)
(3)多边型的简单算法(求面积)和相关判定(点在多边型内,多边型是否相交)
(poj1408,poj1584)
(4)凸包. (poj2187,poj1113)
中级:
一.基本算法:
(1)C++的标准模版库的应用. (poj3096,poj3007)
(2)较为复杂的模拟题的训练(poj3393,poj1472,poj3371,poj1027,poj2706)
二.图算法:
(1)差分约束系统的建立和求解. (poj1201,poj2983)
(2)最小费用最大流(poj2516,poj2516,poj2195)
(3)双连通分量(poj2942)
(4)强连通分支及其缩点.(poj2186)
(5)图的割边和割点(poj3352)
(6)最小割模型、网络流规约(poj3308, )
三.数据结构.
(1)线段树. (poj2528,poj2828,poj2777,poj2886,poj2750)
(2)静态二叉检索树. (poj2482,poj2352)
(3)树状树组(poj1195,poj3321)
(4)RMQ. (poj3264,poj3368)
(5)并查集的高级应用. (poj1703,2492)
(6)KMP算法. (poj1961,poj2406)
四.搜索
(1)最优化剪枝和可行性剪枝
(2)搜索的技巧和优化 (poj3411,poj1724)
(3)记忆化搜索(poj3373,poj1691)
五.动态规划
(1)较为复杂的动态规划(如动态规划解特别的施行商问题等)
(poj1191,poj1054,poj3280,poj2029,poj2948,poj1925,poj3034)
(2)记录状态的动态规划. (POJ3254,poj2411,poj1185)
(3)树型动态规划(poj2057,poj1947,poj2486,poj3140)
六.数学
(1)组合数学:
1.容斥原理.
2.抽屉原理.
3.置换群与Polya定理(poj1286,poj2409,poj3270,poj1026).
4.递推关系和母函数.
(2)数学.
1.高斯消元法(poj2947,poj1487, poj2065,poj1166,poj1222)
2.概率问题. (poj3071,poj3440)
3.GCD、扩展的欧几里德(中国剩余定理) (poj3101)
(3)计算方法.
1.0/1分数规划. (poj2976)
2.三分法求解单峰(单谷)的极值.
3.矩阵法(poj3150,poj3422,poj3070)
4.迭代逼近(poj3301)
(4)随机化算法(poj3318,poj2454)
(5)杂题.
(poj1870,poj3296,poj3286,poj1095)
七.计算几何学.
(1)坐标离散化.
(2)扫描线算法(例如求矩形的面积和周长并,常和线段树或堆一起使用).
(poj1765,poj1177,poj1151,poj3277,poj2280,poj3004)
(3)多边形的内核(半平面交)(poj3130,poj3335)
(4)几何工具的综合应用.(poj1819,poj1066,poj2043,poj3227,poj2165,poj3429)
高级:
一.基本算法要求:
(1)代码快速写成,精简但不失风格
(poj2525,poj1684,poj1421,poj1048,poj2050,poj3306)
(2)保证正确性和高效性. poj3434
二.图算法:
(1)度限制最小生成树和第K最短路. (poj1639)
(2)最短路,最小生成树,二分图,最大流问题的相关理论(主要是模型建立和求解)
(poj3155, poj2112,poj1966,poj3281,poj1087,poj2289,poj3216,poj2446
(3)最优比率生成树. (poj2728)
(4)最小树形图(poj3164)
(5)次小生成树.
(6)无向图、有向图的最小环
三.数据结构.
(1)trie图的建立和应用. (poj2778)
(2)LCA和RMQ问题(LCA(最近公共祖先问题) 有离线算法(并查集+dfs) 和 在线算法
(RMQ+dfs)).(poj1330)
(3)双端队列和它的应用(维护一个单调的队列,常常在动态规划中起到优化状态转移的
目的). (poj2823)
(4)左偏树(可合并堆).
(5)后缀树(非常有用的数据结构,也是赛区考题的热点).
(poj3415,poj3294)
四.搜索
(1)较麻烦的搜索题目训练(poj1069,poj3322,poj1475,poj1924,poj2049,poj3426)
(2)广搜的状态优化:利用M进制数存储状态、转化为串用hash表判重、按位压缩存储状态、双向广搜、A*算法. (poj1768,poj1184,poj1872,poj1324,poj2046,poj1482)
(3)深搜的优化:尽量用位运算、一定要加剪枝、函数参数尽可能少、层数不易过大、可以考虑双向搜索或者是轮换搜索、IDA*算法. (poj3131,poj2870,poj2286)
五.动态规划
(1)需要用数据结构优化的动态规划.
(poj2754,poj3378,poj3017)
(2)四边形不等式理论.
(3)较难的状态DP(poj3133)
六.数学
(1)组合数学.
1.MoBius反演(poj2888,poj2154)
2.偏序关系理论.
(2)博奕论.
1.极大极小过程(poj3317,poj1085)
2.Nim问题.
七.计算几何学.
(1)半平面求交(poj3384,poj2540)
(2)可视图的建立(poj2966)
(3)点集最小圆覆盖.
(4)对踵点(poj2079)
八.综合题.
(poj3109,poj1478,poj1462,poj2729,poj2048,poj3336,poj3315,poj2148,poj1263)
(1)枚举. (poj1753,poj2965)
(2)贪心(poj1328,poj2109,poj2586)
(3)递归和分治法.
(4)递推.
(5)构造法.(poj3295)
(6)模拟法.(poj1068,poj2632,poj1573,poj2993,poj2996)
二.图算法:
(1)图的深度优先遍历和广度优先遍历.
(2)最短路径算法(dijkstra,bellman-ford,floyd,heap+dijkstra)
(poj1860,poj3259,poj1062,poj2253,poj1125,poj2240)
(3)最小生成树算法(prim,kruskal)
(poj1789,poj2485,poj1258,poj3026)
(4)拓扑排序 (poj1094)
(5)二分图的最大匹配 (匈牙利算法) (poj3041,poj3020)
(6)最大流的增广路算法(KM算法). (poj1459,poj3436)
三.数据结构.
(1)串 (poj1035,poj3080,poj1936)
(2)排序(快排、归并排(与逆序数有关)、堆排) (poj2388,poj2299)
(3)简单并查集的应用.
(4)哈希表和二分查找等高效查找法(数的Hash,串的Hash)
(poj3349,poj3274,POJ2151,poj1840,poj2002,poj2503)
(5)哈夫曼树(poj3253)
(6)堆
(7)trie树(静态建树、动态建树) (poj2513)
四.简单搜索
(1)深度优先搜索 (poj2488,poj3083,poj3009,poj1321,poj2251)
(2)广度优先搜索(poj3278,poj1426,poj3126,poj3087.poj3414)
(3)简单搜索技巧和剪枝(poj2531,poj1416,poj2676,1129)
五.动态规划
(1)背包问题. (poj1837,poj1276)
(2)型如下表的简单DP(可参考lrj的书 page149):
1.E[j]=opt{D+w(i,j)} (poj3267,poj1836,poj1260,poj2533)
2.E[i,j]=opt{D[i-1,j]+xi,D[i,j-1]+yj,D[i-1][j-1]+zij} (最长公共子序列)
(poj3176,poj1080,poj1159)
3.C[i,j]=w[i,j]+opt{C[i,k-1]+C[k,j]}.(最优二分检索树问题)
六.数学
(1)组合数学:
1.加法原理和乘法原理.
2.排列组合.
3.递推关系.
(POJ3252,poj1850,poj1019,poj1942)
(2)数论.
1.素数与整除问题
2.进制位.
3.同余模运算.
(poj2635, poj3292,poj1845,poj2115)
(3)计算方法.
1.二分法求解单调函数相关知识.(poj3273,poj3258,poj1905,poj3122)
七.计算几何学.
(1)几何公式.
(2)叉积和点积的运用(如线段相交的判定,点到线段的距离等). (poj2031,poj1039)
(3)多边型的简单算法(求面积)和相关判定(点在多边型内,多边型是否相交)
(poj1408,poj1584)
(4)凸包. (poj2187,poj1113)
中级:
一.基本算法:
(1)C++的标准模版库的应用. (poj3096,poj3007)
(2)较为复杂的模拟题的训练(poj3393,poj1472,poj3371,poj1027,poj2706)
二.图算法:
(1)差分约束系统的建立和求解. (poj1201,poj2983)
(2)最小费用最大流(poj2516,poj2516,poj2195)
(3)双连通分量(poj2942)
(4)强连通分支及其缩点.(poj2186)
(5)图的割边和割点(poj3352)
(6)最小割模型、网络流规约(poj3308, )
三.数据结构.
(1)线段树. (poj2528,poj2828,poj2777,poj2886,poj2750)
(2)静态二叉检索树. (poj2482,poj2352)
(3)树状树组(poj1195,poj3321)
(4)RMQ. (poj3264,poj3368)
(5)并查集的高级应用. (poj1703,2492)
(6)KMP算法. (poj1961,poj2406)
四.搜索
(1)最优化剪枝和可行性剪枝
(2)搜索的技巧和优化 (poj3411,poj1724)
(3)记忆化搜索(poj3373,poj1691)
五.动态规划
(1)较为复杂的动态规划(如动态规划解特别的施行商问题等)
(poj1191,poj1054,poj3280,poj2029,poj2948,poj1925,poj3034)
(2)记录状态的动态规划. (POJ3254,poj2411,poj1185)
(3)树型动态规划(poj2057,poj1947,poj2486,poj3140)
六.数学
(1)组合数学:
1.容斥原理.
2.抽屉原理.
3.置换群与Polya定理(poj1286,poj2409,poj3270,poj1026).
4.递推关系和母函数.
(2)数学.
1.高斯消元法(poj2947,poj1487, poj2065,poj1166,poj1222)
2.概率问题. (poj3071,poj3440)
3.GCD、扩展的欧几里德(中国剩余定理) (poj3101)
(3)计算方法.
1.0/1分数规划. (poj2976)
2.三分法求解单峰(单谷)的极值.
3.矩阵法(poj3150,poj3422,poj3070)
4.迭代逼近(poj3301)
(4)随机化算法(poj3318,poj2454)
(5)杂题.
(poj1870,poj3296,poj3286,poj1095)
七.计算几何学.
(1)坐标离散化.
(2)扫描线算法(例如求矩形的面积和周长并,常和线段树或堆一起使用).
(poj1765,poj1177,poj1151,poj3277,poj2280,poj3004)
(3)多边形的内核(半平面交)(poj3130,poj3335)
(4)几何工具的综合应用.(poj1819,poj1066,poj2043,poj3227,poj2165,poj3429)
高级:
一.基本算法要求:
(1)代码快速写成,精简但不失风格
(poj2525,poj1684,poj1421,poj1048,poj2050,poj3306)
(2)保证正确性和高效性. poj3434
二.图算法:
(1)度限制最小生成树和第K最短路. (poj1639)
(2)最短路,最小生成树,二分图,最大流问题的相关理论(主要是模型建立和求解)
(poj3155, poj2112,poj1966,poj3281,poj1087,poj2289,poj3216,poj2446
(3)最优比率生成树. (poj2728)
(4)最小树形图(poj3164)
(5)次小生成树.
(6)无向图、有向图的最小环
三.数据结构.
(1)trie图的建立和应用. (poj2778)
(2)LCA和RMQ问题(LCA(最近公共祖先问题) 有离线算法(并查集+dfs) 和 在线算法
(RMQ+dfs)).(poj1330)
(3)双端队列和它的应用(维护一个单调的队列,常常在动态规划中起到优化状态转移的
目的). (poj2823)
(4)左偏树(可合并堆).
(5)后缀树(非常有用的数据结构,也是赛区考题的热点).
(poj3415,poj3294)
四.搜索
(1)较麻烦的搜索题目训练(poj1069,poj3322,poj1475,poj1924,poj2049,poj3426)
(2)广搜的状态优化:利用M进制数存储状态、转化为串用hash表判重、按位压缩存储状态、双向广搜、A*算法. (poj1768,poj1184,poj1872,poj1324,poj2046,poj1482)
(3)深搜的优化:尽量用位运算、一定要加剪枝、函数参数尽可能少、层数不易过大、可以考虑双向搜索或者是轮换搜索、IDA*算法. (poj3131,poj2870,poj2286)
五.动态规划
(1)需要用数据结构优化的动态规划.
(poj2754,poj3378,poj3017)
(2)四边形不等式理论.
(3)较难的状态DP(poj3133)
六.数学
(1)组合数学.
1.MoBius反演(poj2888,poj2154)
2.偏序关系理论.
(2)博奕论.
1.极大极小过程(poj3317,poj1085)
2.Nim问题.
七.计算几何学.
(1)半平面求交(poj3384,poj2540)
(2)可视图的建立(poj2966)
(3)点集最小圆覆盖.
(4)对踵点(poj2079)
八.综合题.
(poj3109,poj1478,poj1462,poj2729,poj2048,poj3336,poj3315,poj2148,poj1263)
订阅：
博文 (Atom)
博文
