最近收到一堆VBScript要调试。VBScript是一个很有迷惑性的名字，ASP用的脚本语言可以是VBScript，Office里的VBA在我看来也是一种VBScript，显然这次的一堆.vbs文件不属于以上情况。为什么要在标题中说是“调试WSH“，先把概念搞清楚。
什么是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，指某种把两堆稀泥和成一堆稀泥的高深领域技术。
这是关于ASP.Net常被问到的一个问题，很老很老的概念，但也是一个比较容易一知半解的问题。自问了一下，似乎揣着明白说不清楚，于是做点功课整理一下。
首先，为什么会有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中经典主题模板的移植，也许你现在正在浏览的正是其中之一。
因为是英文的主题模板，某些地方没有翻译可能会让部分浏览者比较困惑，以后学有余力的话再试着翻译并且做一些自定义。
并非是要搞什么开源项目，只是想把一些自己做的东西找地方放一下，也可以方便和别人交流。虽然Dreamhost的空间也提供Subversion的支持，但是要把整个环境搭起来还是需要耗费很多精力的，还是使用现有的成品吧。
需要注意的是这些服务托管的站点一般都是针对开源项目的，也就是说需要遵照一定得开源协议将你的内容开放给大众，如果不了解开源的同学需要先做做功课。当然我没有什么好担心的，因为基本没有什么很有价值的东西，唯一担心的是内容太差被别人鄙视。
其次为什么我要说“内容”而非“源代码”，是因为你不但可以将你的项目程序代码host在托管站点，同样也可以host以文档为重要内容的项目，比如项目的文档手册，比如一本书的翻译，甚至是一本新书（合作编写的情况居多）
言归正传，我们怎样选择
1. 选择站点即是选择社区，决定你会得到怎样的反馈
不同的社区活跃的人群不一样，侧重的技术面也不一样。C++、Java、.Net或者服务器端、桌面端，选择不同的社区你得到的关注、反馈和支持将大不相同。
2. 搞清楚你需要怎样的服务
你是仅仅想要存放你的内容还是要开始一个认真的开源项目？你使用哪种源码管理工具？CVS、SVN还是VSTS，你需要多大的空间？你需要缺陷管理系统、论坛、wiki甚至是项目的网站么？
3. 站点的速度和稳定性很重要
站点的访问速度，特别是源码管理工具的访问速度很重要，服务器所处的位置是需要考虑的因素。另外，基于我们当前所处的环境，某些大的托管站点往往无法保证稳定的访问（比如sourceforge）
那我们有哪些选择
老牌站点，有无数的开源好项目，提供的服务也全面，用起来有点繁琐。更重要的是国内的话，速度比较慢，而且“不稳定”啊。
Google的产品，后起之秀，提供基本的功能，使用简单，而且只需要一个Gmail账号就可以开始使用。
已经有一篇《开源，选择Google Code还是Sourceforge？（修订版）》将以上两者做了详细的比较，就不再啰嗦了
从微软最近对开源的暧昧态度来看，没有这样一个站点是不可能的。其特点是支持VSTS，面向.Net开发人员。
Sun推出的开源托管站点，面向Java的开发者。还是beta，最近这么一收购，前景很不明朗啊。
比较有规模的开源托管站点，比较引人注意的项目有Ubuntu、MySQL和Wordpress。该站点还支持付费的商业软件项目。
看域名是德国的站点，有多语言的支持。
法语站点，没看见多语言的选择，用起来会比较有困难。
结论
上面提到的选择中，后面几个基本就是凑数，一般不太会使用。如果你只用.Net开发，需要VSTS支持，那你的选择基本上只有Codeplex。至于其他的选择主要集中在Sourceforge和Google Code。简单来说Sourceforge复杂、麻烦，如果你想开始一个严肃认真的开源项目，就选择它。Google Code简单易用，如果你只是想有个地方存放代码，和一些人共享，或者尝试性地开始一个开源项目，那就Google Code。
所以我的选择就是Google Code了。
突然发觉不同Linux发行版之间还是有一定得区别的。最近一直在用Ubuntu（从之前的文章可以看出来），也看到了一些对于Ubuntu的炮轰，比如兼容问题，比如对社区的贡献少，比如背后商业公司的利益导向等等，但总的来说Ubuntu的Live CD，简易的安装，打包好的软件，漂亮的界面对于推广Linux还是起了不小的作用的。
当然作为“有追求的专业人士”，将自己在知识方面的精力投资在一个更为通用、更为广泛接受的对象上无疑是明智的选择，所以还是需要介意一下的。
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 2.6安装设置完毕后已经运行了几个月了，近日从空间商Dreamhost那里收到邮件，因为Wordpress 2.6的安全漏洞，建议升级到2.7。如果是使用他们提供的Wordpress一键安装，则一键升级即可，可惜我的是Wordpress mu，只好自己弄。
升级这个事情，可大可小。一般我的态度是，如果一切正常，就不去升级到什么新版本。况且作为一个无名小站来说，看都没什么人看，想来也不会招惹到什么强人来关心我的安全漏洞。不过耐不住连收到两封提醒邮件，警钟长鸣啊，升级就升级吧，总得经历一下，权当是为以后需要升级的时候做预演。
首先到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。
之后将禁用的插件重新启用，尝试各部分功能，如果没有问题的话，升级就告结束了，就这么简单。反之之前的备份就要发挥作用了。
Linux平台上的SVN客户端选择
在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？仍然有待考虑。
