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

谷歌浏览器

Google （谷歌）中国的博客网志，走近我们的产品、技术和文化

谷歌浏览器（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)

算法数学 OJ

算法数学基础：

具体数学

全面介绍算法：

算法导论
计算机程序设计的艺术

图论算法：

组合算法：

数论算法：

计算几何：


一些大学的OJ：

北京邮电大学 Online Judge (BOJ) http://acm.cs.bupt.cn/onlinejudge/

我的母校，呵呵，建得比较晚，不过现在人气越来越旺，最近北邮的ACM也获得了一个赛区冠军

上海交通大学 http://acm.sjtu.edu.cn/

哈尔滨工业大学 http://acm.hit.edu.cn/index.php

（以下是转自看雪论坛的）：

浙江大学 Online Judge（ZOJ）http://acm.zju.edu.cn

国内最早也是最有名气的OJ，有很多高手在上面做题。特点是数据比较刁钻，经常会有你想不到的边界数据，很能考验思维的全面性，现在我主要在这个OJ上做题

北京大学 Online Judge（POJ）http://acm.pku.edu.cn/JudgeOnline/

建立较晚，但题目加得很快，现在题数和ZOJ不相上下，特点是举行在线比赛比较多，数据比ZOJ上的要弱，有时候同样的题同样的程序，在ZOJ上WA，在POJ上就能AC

同济大学 Online Judge http://acm.tongji.edu.cn/index.php

这个OJ题数上不能与上两个相比，推荐这个OJ的原因是它是中文的，这对很多对英文不太感冒的兄弟是个好消息吧。它也因此吸引了众多高中的OIer，毕竟他们的英文还差一些呵呵，上面的题目也更偏向高中的信息学竞赛一些。

西班牙Valladolid大学 Online Judge（UVA）http://online-judge.uva.es/problemset/

世界上最大最有名的OJ，题目巨多而且巨杂，数据也很刁钻，全世界的顶尖高手都在上面。据说如果你能在UVA上AC一千道题以上，就尽管向IBM、微软什么的发简历吧，绝对不会让你失望的。

俄罗斯Ural立大学 Online Judge（URAL）http://acm.timus.ru/

也是一个老牌的OJ，题目不多，但题题经典，我在高中的时候就在这上面做题的。

UsacoGate Online Judge（USACO）http://ace.delos.com/usacogate

全美计算机奥林匹克竞赛（USACO）的训练网站，特点是做完一关才能继续往下做，与前面的OJ不同的是测试数据可以看到，并且做对后可以看标准解答，所 以如果大家刚开始的时候在上面那些OJ上总WA却找不到原因的话，可以试着来这里做做，看看测试数据一般是从什么地方阴你的。

ACM总决赛、区域赛的Problem Set
http://www.acm.inf.ethz.ch/ProblemSetArchive.html

国外大学算法课程的主页：

纽约州立大学Stony Brook教授的算法主页：
http://www.cs.sunysb.edu/~algorith/

匹兹堡大学：
http://www.cs.pitt.edu/~kirk/algorithmcourses/

哈佛大学
Probabilistic Analysis and Algorithms
http://www.eecs.harvard.edu/~michaelm/CS223/index.html


计算几何学：
http://geometryalgorithms.com/

http://www.cs.umd.edu/%7Esamir/754/754.html

http://compgeom.cs.uiuc.edu/~jeffe/compgeom/compgeom.html

http://www.csc.kth.se/tcs/aalg/lectures.html

http://www.cs.brown.edu/courses/cs252/lectures.html

图论算法：
http://theory.stanford.edu/~tim/w08b/w08b.html

Stanford大学图形学相关课程
http://graphics.stanford.edu/courses/#cs268

开源算法库：

代数几何：
http://www.cgal.org/

[转载] 图灵奖中的数学家

数学是所有工科的基础，要想在工程科学上真正严谨的作学问，必须有一个扎实的数学功底。比如计算机科学中，离散数学就是它的精髓。

下面向大家介绍几位学数学出身或者本身就是数学家的计算机图灵奖得主以及他们的主要成就。

1986年获奖的Robert E.Tarjan，在加州理工获数学学士学位，后来在Stanford取得计算机和数学博士学位。是Princeton计算机系教授，主要研究图论，算法和数据结构设计。他发现了判断一个图是否为平面图的线性时间复杂度的算法，在数据库软件，电路设计，航空线路图优化等领域有广泛应用。Tarjan也是 1982年首届Nevanlinna奖得主。

1972年获奖的Edsger W.Dijkstra，在祖国荷兰获数学和物理学学士，理论物理博士学位。在他2000年退休前一直是美国Taxas大学的计算机科学和数学教授。发现了以他名字命名的图论中的最短路径算法。但他获得图灵奖的主要原因却是发明了ALGOL这一第二代编程语言。 （tassadar: Dijkstra绝对是偶像级的人物）

1985年获奖的Richard M.Karp，在Harvard大学获应用数学博士学位。现在是Berkeley大学计算机系教授。最重要的论文是1972年发表的 "Reducibility Among Combinatorial Problems"。他在并行算法，组合优化问题的概率分析方面颇有建树。现在的研究方向是人类基因测序和基因数据表达。他也是美国国家科学院院士，获得过美国国家科学奖。

1974年获奖的Donald E. Knuth，在加州理工获数学博士，退休前是Standford大学计算机系教授。发明数学排版软件TeX，现在正在撰写巨著 The Art of Computer Programming，已出版3卷。（tassadar: 在计算机程序设计的世界里，上帝扮成了Knuth）

1983年获奖的Dennis M.Ritchie，在Harvard大学获应用数学博士学位。毕业后加入Bell实验室，参与发明了Unix操作系统，发明了C,C++编程语言。（tassadar: 个人认为应该是C++标准的参与者，但是Bjarne Stroustrup 应该是真正的C++之父）

1989年获奖的William V.Kahan是加州Berkeley分校的数学教授。他因为在数值计算，特别是浮点运算方面的贡献而获奖，有人评价他是"dedicated himself to make the world safe for numerical computations."

1987年获奖的John Cocke，在Duke大学获数学博士学位。毕业后进入IBM公司工作，同时也在MIT和NYU的Courant研究所做过客座教授。主要贡献是发明了 RISC（reduced instruction set computers），大大改善了芯片的性能。

1969年获奖的Marvin Minsky，在Harvard获数学学士，在Princeton获数学硕士，后在MIT任数学和计算机教授。主要贡献是人工智能。

1971年获奖的John McCarthy，在加州理工获数学学士，在Princeton获数学博士学位。人工智能大师，Lisp语言发明人。

1970年获奖的John Hardy Wilkinson，16岁入Rochester大学数学系学习，后在剑桥大学获博士学位。 主要贡献是数值计算和"backward"误差分析。

1968年获奖的Richard Hamming，在UIUC获数学博士学位，博士论文题目是“线性微分方程中的边值问题”。在数值分析，概率统计，编码理论上有卓有建树。