什么是WSH

　　WSH(Windows Script Host)，基于Windows的脚本语言宿主（运行）环境，好比cmd.exe之于batch命令。使各种语言（VBScript、JScript，如果没记错还有Perl之类的）能够在其中运行，执行Windows的管理等自动化工作。

　　至于真正提供操纵Windows的对象模型，来自于如WMI(Windows Management Instrumentation)和ADSI(Active Directory Service Interfaces)

　　概念就简单地说说，需要严谨的理论的请查找MSDN。Microsoft TechNet Script Center是汇集了相关的资源。话说现在MS又推PowerShell，学无止境啊。

如何调试WSH脚本

　　需要用到cscript.exe和wscript.exe，两者的区别是控制台输出和窗口输出。文件位置在\windows\system32目录下，如果旧的Windows版本找不到此文件，可以下载安装Microsoft Windows Script。

　　以VBScript脚本为例，如果要调试Sample.vbs

　　运行

　　　　cscript  yourscript.vbs //X

　　或者

　　　　wscript  yourscript.vbs //X

　　会弹出Just-in-Time Debugger选择窗口

　　选择更“高级”的Visual Studio 2005。（如果不能弹出此窗口，请部分参考该链接的修改注册表的部分）

　　标准的Visual Studio的调试界面，该有的调试功能都有，比逐行加Msgbox要强多了，好好享受吧。

　　他们虽然不勤劳，但他们诚实，而且勇敢。

　　某日一非专业人士终于鼓起勇气问某程序员：

　　　　“你们每天都说磨叽一下是什么意思啊？”

　　程序员：

　　　　“~！@#￥%……&*”

　　场景重现

　　　　程序员A对程序员B：“你做好了么，你做好了我们磨叽一下。”

　　　　程序员B对程序员A：“马上就好，不要着急，只要最后磨叽一下就OK了。”

　　小贴士

　　　　理论上程序员的统一语言是英语，没有统一学习某种方言的倾向。当然有口音的同学除外。

　　　　Merge：读音类似me-ji非mo-ji，指某种把两堆稀泥和成一堆稀泥的高深领域技术。

首先，为什么会有Web服务器控件、Html服务器控件和Html控件

　　Html控件无需多说，最常用的控件，ASP时代的唯一选择，世界开始的时候它就在那。当微软推出.Net后，为了提供ASP.Net Web Form开发以和Win Form开发相似的开发体验，推出了Web服务器控件（Server Control），又称ASP.Net服务器控件。而Html服务器控件（Html Server Control），则可以看做是为了向下兼容，便于原本基于ASP系统的移植而推出的一种介于Html控件和Web 服务器控件的权宜产物。

Web服务器控件、Html服务器控件和Html控件的区别

• Html控件的标签：<input id=”Button” type=”button” value=”Button” />
• Html服务器控件的标签：<input id=”Button” type=”button” value=”Button” runat=”server” />
• Html服务器控件其实就是Html控件的基础上加上runat=”server”所构成的控件
• Web服务器控件的标签：<asp:Button ID=”Button” runat=”server” Text=”Button”/>
• Web服务器控件会根据情况在浏览器端产生一个或多个对应的Html标签。

• Html服务器控件位于System.Web.UI.HtmlControls
• Web服务器控件位于System.Web.UI.WebControls
• Web服务器控件与Code Behind的Class文件相结合，提供了包含属性、方法和事件的完整对象模型。

• Html控件不能在服务器端控制，只能在浏览器端通过javascript等脚本语言操作。
• Html服务器控件设定了runat=”server” 属性后，页面对象会将该控件载入控制器，服务器端的代码就能对其进行控制。
• Html服务器控件在页面执行完毕后会被转换成Html标注，然后当成字符串流发送到浏览器端，浏览器端的脚本能够进行操作。
• Web服务器控件的操作则是由页面把Form发回服务器，然后完全由服务器端代码处理。

• Html控件的事件处理发生在浏览器端，除非Submit，否则不会发生Postback
• Html服务器控件的事件处理发生在浏览器端。
• Html服务器控件如果要Postback到服务器端，调用服务器端的方法，需要添加onserverclick之类的事件。
• Web服务器控件部分默认为AutoPostback，或者可以设置AutoPostback。

• 在产生Postback或是重新生成页面时，Web服务器控件自动保存状态到ViewState。
• Html控件和Html服务器控件需要自己编码实现。

Web服务器控件、Html服务器控件和Html控件的优缺点

• Html控件和Html服务器控件需要编码以保持浏览器兼容。
• Web服务器控件能够检测浏览器的兼容性，保持表现的一致。

• Html服务器控件通过为Html控件添加runat=”server”以实现ASP程序的移植。
• 将ASP程序移植成使用Web服务器控件的ASP.Net程序相当于重写新的应用。

• Html控件和Html服务器控件是标准控件，能够用浏览器端脚本语言操作。
• 使用Web服务器控件提供的对象模型，能够得到和Win Form类似的编程体验，而且无需再学习不同的脚本语言。
• Web服务器内部的代码并不开放，你无法获得比较直接的控制。

小结

　　个人认为，Html服务器控件作为一个过渡的实现，虽然能够兼顾浏览器端和服务器端，终究是一个奇怪的存在，尽量少使用为妙。从微软的角度，良好封装的Web服务器控件提供了大量的便利，同时Web Form和Win Form开发模式的差异使得相互的经验能够互通，当然是多使用Web服务器控件为好。不过Web服务器控件的缺点是占用服务器资源，页面Postback过多（Ajax啊Ajax）。所以现实是存在的就是合理的，Html还是要会地，Javascript当然是要好好学地，Web开发各种奇奇怪怪的标签共存于Page中的场面短时间内是不可能消失地。

参考资料

《html控件、html服务器控件和web服务器控件的区别》 （原出处不详，请Google）
<Difference Between ASP.NET Server Controls,HTML Server Controls and HTML Intrinsic Controls>

按照来源区分，可分为兼容MU的Wordpress插件和针对MU开发的插件

　　Wordpress MU是Wordpress的多用户版本，因为程序结构的关系，Wordpress MU并不一定能兼容Wordpress的插件。这里我们谈到的兼容，是指无需做任何修改即可在MU中直接使用的Wordpress插件。针对MU开发的插件中，分为在原Wordpress插件基础上修改的和针对MU全新开发的两种。

按照作用范围区分，可分为全局插件和分站点插件

　　Wordpress中按照影响范围将插件分为两类，全局的插件和针对单个站点的插件，分别存放在不同的目录。

　　/wp-content/mu-plugins/ 目录下存放的是全局的插件。此类插件一般属于比较简单的插件，没有插件目录，而只是由一个php文件组成。上传后该类插件后不会出现在各个博客后台的Plug-ins菜单里，而是出现在Site Admin菜单里（必要的话）。此类插件无需逐个博客激活插件，默认就已经自动调用。

　　/wp-content/plugins/ 目录下存放的是分站点的插件。此类插件上传到后，需要用户手动在Plug-ins菜单的管理面板中启动（前提是管理员为该用户开启了该权限）。用户启用该插件仅影响该站点，而不会影响其他站点。

Wordpress MU插件的管理

　　如果是单文件的简单插件，则直接作为全局插件上传即可，无须也无法做任何管理。（有一个为含目录的插件创建调用的文件并作为全局插件的方法，查询无果，略过）

　　对于分站点的插件，如果管理员不想把启用和禁用插件的权限下放给用户，而想统一地为特定的博客启用和禁用插件，可以使用Plugin Commander或者WPMU Plugin Manager插件（两者孰优孰劣还没来得及比较）。

Wordpress MU插件的选择

　　首先当然是选择针对MU开发的插件，相当部分在WP平台上广受欢迎的插件都有针对MU的修改版本，既经受过时间的考验而且在使用习惯上能够得到延续。无论有无WP的经验，首先查询WP的相关插件，然后查询在MU平台上是否有衍生品是不错的方法。

　　当然针对WPMU全新开发的插件也有其优势，就是完全定制，在跨博客的兼容性方面会有比较全面的考虑。WPMU的官方站点的插件列表在这里。可惜的是数量与WP相比相差太多，活动也并不十分活跃，反倒是有相当一部分不错的插件被放在了需要付费的Premium区，当然这个WPMU的定位有关。

　　至于那些默认兼容的插件，需要注意的就是不会有任何跨站点兼容的支持。比如通过Tag获取相关文章，其影响范围只能限于单个博客，在不修改的前提下想跨博客建立关联是不可能的，这很显而易见。

兼容性的问题

　　因此Wordpress的部分简单的插件虽然可以默认兼容到Wordpress MU，但是还要谨慎对待。如何辨别是否兼容，区分的尺度方面，比如涉及到数据库的表，文件目录的操作，由于程序结构的关系，不修改恐怕是难以兼容的。其它的无非是多查询现有的资料以及自己尝试了。

　　即使功能运行正常，在比如升级、创建新用户、创建新博客时还是将插件先关闭为好，同时要注意不同插件之间冲突的可能。

　　博客运行了一年左右，WPMU升级过一次，插件也用过若干，但总体还是抱着尽量简单的态度，博客么，内容为王。

　　因此主题一直使用的是默认的Kubrik，蓝白色，二栏式，支持Widgets，支持目录的树形显示。除了单调了一些，唯一的缺点就是默认的字体稍小了一些。

　　这两天准备稍微收拾收拾，因为WP和WPMU的主题模板并不完全兼容的缘故，到WPMU官方提供模板的地方看了看。首先模板的选择不是很多，其次更新也不是很频繁。其中有一位Farms提供的多个主题的打包相当不错，有多次的更新，最新的版本是Farms 100 big ones theme pack，里面有近百个主题模板，都针对WPMU进行了修改以兼容。

　　容量不小，其中的个别还有些显示的问题，比如不显示Slogan，不能树形显示目录，有多余的换行，正文部分宽度不够同时不支持图像缩放导致越界等等，大家可以在本地的环境测试后再有选择性地上传。上传的目录是/wp-content/themes。

　　经过一番比较，没有上述问题且个人比较喜欢的主题模板有Bluebird、Connections、Contempt、Edublogs Default、GloriousDay、Jakarta、LetoPrime、Ocean Mist、OceanWide、RadMod、Rubric、WordPress II Silver。这之中有一些应该是WP中经典主题模板的移植，也许你现在正在浏览的正是其中之一。

　　因为是英文的主题模板，某些地方没有翻译可能会让部分浏览者比较困惑，以后学有余力的话再试着翻译并且做一些自定义。

　　需要注意的是这些服务托管的站点一般都是针对开源项目的，也就是说需要遵照一定得开源协议将你的内容开放给大众，如果不了解开源的同学需要先做做功课。当然我没有什么好担心的，因为基本没有什么很有价值的东西，唯一担心的是内容太差被别人鄙视。

　　其次为什么我要说“内容”而非“源代码”，是因为你不但可以将你的项目程序代码host在托管站点，同样也可以host以文档为重要内容的项目，比如项目的文档手册，比如一本书的翻译，甚至是一本新书（合作编写的情况居多）

言归正传，我们怎样选择

1. 选择站点即是选择社区，决定你会得到怎样的反馈

　　不同的社区活跃的人群不一样，侧重的技术面也不一样。C++、Java、.Net或者服务器端、桌面端，选择不同的社区你得到的关注、反馈和支持将大不相同。

2. 搞清楚你需要怎样的服务

　　你是仅仅想要存放你的内容还是要开始一个认真的开源项目？你使用哪种源码管理工具？CVS、SVN还是VSTS，你需要多大的空间？你需要缺陷管理系统、论坛、wiki甚至是项目的网站么？

3. 站点的速度和稳定性很重要

　　站点的访问速度，特别是源码管理工具的访问速度很重要，服务器所处的位置是需要考虑的因素。另外，基于我们当前所处的环境，某些大的托管站点往往无法保证稳定的访问（比如sourceforge）

那我们有哪些选择

Sourceforge.net

　　老牌站点，有无数的开源好项目，提供的服务也全面，用起来有点繁琐。更重要的是国内的话，速度比较慢，而且“不稳定”啊。

Google Code

　　Google的产品，后起之秀，提供基本的功能，使用简单，而且只需要一个Gmail账号就可以开始使用。

　　已经有一篇《开源，选择Google Code还是Sourceforge？（修订版）》将以上两者做了详细的比较，就不再啰嗦了

Codeplex

　　从微软最近对开源的暧昧态度来看，没有这样一个站点是不可能的。其特点是支持VSTS，面向.Net开发人员。

Project Kenai

　　Sun推出的开源托管站点，面向Java的开发者。还是beta，最近这么一收购，前景很不明朗啊。

Launchpad

　　比较有规模的开源托管站点，比较引人注意的项目有Ubuntu、MySQL和Wordpress。该站点还支持付费的商业软件项目。

BerliOS

　　看域名是德国的站点，有多语言的支持。

CodingTeam

　　法语站点，没看见多语言的选择，用起来会比较有困难。

结论

　　上面提到的选择中，后面几个基本就是凑数，一般不太会使用。如果你只用.Net开发，需要VSTS支持，那你的选择基本上只有Codeplex。至于其他的选择主要集中在Sourceforge和Google Code。简单来说Sourceforge复杂、麻烦，如果你想开始一个严肃认真的开源项目，就选择它。Google Code简单易用，如果你只是想有个地方存放代码，和一些人共享，或者尝试性地开始一个开源项目，那就Google Code。

　　所以我的选择就是Google Code了。

　　当然作为“有追求的专业人士”，将自己在知识方面的精力投资在一个更为通用、更为广泛接受的对象上无疑是明智的选择，所以还是需要介意一下的。

　　Novell的SUSE Linux版本没什么研究，只知道大致上是SUSE Enterprise和OpenSUSE两个分支。版本的定位和Redhat差别不大，之后再讨论。

　　Mandriva Linux，法国的发行商。最初基于Redhat，后来分道扬镳。使用GNOME、KDE桌面，使用rpm包，部分兼容Redhat/Fedora。这个基本没怎么见周围的人用过。

　　剩下的就是基于Redhat和Debian两种发行版的居多。最近很火的Ubuntu就是基于Debian内核（Debian本身反倒关注的人少了），简单来说就是预编译的.deb软件包可以兼容。Ubuntu分为针对服务器的Server版，针对桌面用户的Destop版，针对专本设备的MID和Netbook版。

　　Redhat方面，在与Fedora Project合并后，分为两条线路，RHEL（Redhat Enterprise Linux）和Fedora Linux。两者的区别在于Fedora由社区支持，每6个月更新；RHEL由Redhat公司支持，每18个月更新，面向企业用户，提供需要付费的subscription服务，相对于Fedora经过认证的软件包较少一些。具体的比较请看这里。总的来说，可以把Fedora看做是RHEL的基础，试验田，两者在定位上有区别导致在发行版内容的侧重上会有区别，但是技术基础没有区别。在RHEL上能干的事情，在Fedora上应该都能干，区别是RHEL上出了问题，你可以找Redhat支持，Fedora上除了问题，你得靠自己（还有社区）

　　到Redhat的网站上看了看，RHEL也分为Server和Destop版本，需要Buy，但是有30天的试用。但是请注意，Linux是Open Source的，RHEL也不例外。你购买的是7年的技术支持服务，而不是Linux本身，这意味着你在试用30天之后可以继续合法地使用RHEL，当然是在你不需要支持自己能搞定的情况下。

　　当然也有一些定位于RHEL替代的“免费”的Redhat分支，如CentOS、Tao Linux等。

　　RHEL下载还需要注册，感觉麻烦。跑到Fedora那看了看，一张光盘的Live CD，只有Desktop版本（当然你把它配成Server也没问题），可以Live CD直接引导，也可以配置成USB引导（不知道是不是学Ubuntu的）。于是中午下载了一个，决定之后开始玩起来。

　　总的来说各个发行版对于初级的应用来说差别不大，无非是桌面的使用习惯、预编译软件包的数量、对硬件驱动的支持。考虑到这么多年，公司里还是Redhat应用得比较多，所以最近有从Ubuntu叛逃到Redhat线路的意图。（当然其实学好了都一样，这个纯属个人问题）

　　PortableApps.com将很多实用工具打包为Portable版本，以下是部分开发工具。

Firefox Portable

　　没错，就是Firefox。没有插件，Firefox一无是处，有了插件，Firefox无所不能。作为一名“业内人士”，如果你在用Firefox但是没装过插件，那千万让别人知道。具体的以后在《Firefox插件 - 开发篇》介绍。

NotePad++

　　Linux平台上有Vi、Emacs等强大的编辑器，但是相信我，学习成本很高，除了跨平台的使用习惯统一之外，专注于Windows的可以略过。

　　Windows平台上开源免费的有NotePad2和NotePad++，两者都支持相当多的编程语言。相比较之下NotePad++个人感觉略强，而且有Portable版本。大家可以用来替代需要注册的UltraEdit。

　　曾经有人说一款编辑器如果不支持脚本就算不上真正的编辑器，这个就见仁见智了。

KompoZer Portable

　　Nvu是一款类似于FrontPage和Dreamweaver的免费的网页编辑器，但是目前已经停止更新。KompoZer是Nvu的非官方修正版本，并且继续保持更新。

　　我用它来代替用了很久的Dreamweaver UltraDev。

WinMerge Portable

　　版本比较工具，写代码的都应该知道干嘛的。

FileZilla Portable

　　开源免费的FTP客户端，网站开发都会用到。虽然不是很完美，但是够用。不要忘记FlashFXP和CuteFTP是要注册地。

WinSCP Portable

　　支持SFTP、FTP和SCP的客户端（FileZilla也已经支持SFTP），所以和FileZilla孰优孰劣是见仁见智的问题。

PuTTY Portable

　　telnet和SSH客户端，网站开发操作远程主机的时候用得到。

PortableApps.com AppCompactor

　　应用程序压缩工具，用来减可执行文件体积的，向来也就只有开发人员用，就归到开发篇里了。

　　升级这个事情，可大可小。一般我的态度是，如果一切正常，就不去升级到什么新版本。况且作为一个无名小站来说，看都没什么人看，想来也不会招惹到什么强人来关心我的安全漏洞。不过耐不住连收到两封提醒邮件，警钟长鸣啊，升级就升级吧，总得经历一下，权当是为以后需要升级的时候做预演。

　　首先到Wordpress mu官网下载安装包，解压后找到readme.txt，跳到Upgrading部分，根据提供的链接打开Upgrading WPMU的说明页面。

　　因为Wordpress mu是基于Wordpress的多用户版本，所以首先需要阅读一下Upgrading_WordPress。

　　总得来说从2.6到2.7代码没有结构性的变化，升级过程很简单，唯一需要注意的是如果使用了太多的插件的话，可能有不兼容的情况产生，建议首先禁用插件。

　　如果不想读太多的文档，按照以下步骤即可

升级步骤

1.备份数据库，备份程序文件
2.将新文件上传，覆盖源文件
3.用admin登录，点击Site Admin –> Upgrade升级，完成升级。

　　2.7将Site Admin的界面做了重新组织，其它部分没有太明显的感觉。

　　如果想要启用用户cookie加密的话，还需要按照管理页面上的说明修改wp-config.php。

　　之后将禁用的插件重新启用，尝试各部分功能，如果没有问题的话，升级就告结束了，就这么简单。反之之前的备份就要发挥作用了。

　　在Windows上常用的SVN图形化客户端是TortoiseSVN，那么在Linux平台上呢？<Comparison of Subversion clients> 列举了Subversion的客户端。

　　当然用不着在这么多选择里一一比较，从搜索的结果来看，比较多用到的是RapidSVN和eSvn（这两款都是跨平台的，支持Win、Linux、Mac OS平台）。至于选择RapidSVN的原因么，是因为RapidSVN在Subversion的老巢Tigris.org可是受到推荐的，而eSVN的主页我没打开，理由就是这么简单。

RapidSVN的特点

• Simple - provides an easy to use interface for Subversion features
• 简单 - 为Subversion的功能提供易用的界面
• Efficient - simple for beginners but flexible enough to increase productivity for experienced Subversion users
• 高效 - 对于初学者很简单，同时对于有经验的Subversion用户足够灵活以提高生产率
• Portable - runs on any platform on which Subversion and wxWidgets can run: Linux, Windows, Mac OS/X, Solaris, etc.
• 可移动 - 能在任何Subversion和wxWidgets能够运行的平台上运行：Linux、Windows、Mac OS/X、Solaris及其它（个人认为应该是Cross-platform跨平台比较贴切）
• Fast - entirely written in C++
• 快速 - 完全用C++编写
• Multilingual - it has been translated to many languages already: German, French, Italian, Portuguese, Russian, Ukrainian, Simplified Chinese, Japanese
• 多语言 - 已经被翻译为多国语言
• Full support for Unicode
• 完全支持Unicode编码

在Ubuntu上安装RapidSVN

　　在大多数主要的Linux发行版本中都提供预编译的RPM格式的RapidSVN安装包，相关的信息请参考RapidSVN关于Linux/Unix安装的在线帮助。

　　RapidSVN已经是Debian发行版（也包括Ubuntu）的一部分，可以简单地使用Package Manager进行安装。

　　比如在Ubuntu Server的桌面环境下，从菜单栏运行[Applications] –> [Debian] –> [Applications] –> [System] –> [Package Management] –> Synaptic Package Manager，找到RapidSVN并选择安装，系统会添加其它需要所需组件，提示插入系统的安装盘，然后到官方网站下载并完成安装。

　　之后打开[Applications] –> [Programming]，就会发现RapidSVN的快捷方式。

　　整个安装过程很简单，就像在Windows里添加/删除Windows组件一样简单。

TortoiseSVN vs RapidSVN on Windows?

　　TortoiseSVN只支持Windows，RapidSVN支持Windows和Linux。

　　初步使用，RapidSVN的所有操作都集中在主窗口，远程的repository和本地的working copy都以bookmark的形式表示，和TortoiseSVN与操作系统的右键菜单以及文件管理器整合的方式不同。在使用习惯上不小的差异。

　　是否需要把Windows上的Subversion客户端也统一为RapidSVN？仍然有待考虑。