C#的发展是很快很快的，C#的设计目的是成为一个有趣有用通用的程序语言，并因此让使用该语言的用户能获得更大的成功。所以，C#除了面向对象的基本特征外，现在引入了相当多的其他特征喔！

动态，动态。动态是目前超级流行的词汇。C#也要动起来了喔！

C# 4.0的主要主题是动态编程。对象的意义变得越来越“动态”，它们的结构和行为无法通过静态类型来捕获，或者至少编译器在编译程序时无法得知对象的结构和行为。

相关的特性有动态查找、命名参数、可选参数等。

还有，简化了与COM的互操作。

还有，协变和逆变 Covariance and contravariance 。

这些都在白皮书里可以找到介绍。我在这里整理一下协变和逆变的一些参考资料，本来数学就不好，怕过一两天就又忘了，俗话说，好记性不如烂笔头嘛。

首先看看问题的引入。

这里有两个类型，T 和 U，在这两个类型间，以下伪表达式肯定有一个是“真”：

• T > U
• T < U
• T = U
• T 和 U 没有任何关系

例如有这些类型：动物 Animal、哺乳动物 Mammal、爬行动物 Reptile、长颈鹿 Giraffe、老虎 Tiger、蛇 Snake和海龟 Turtle，它们之间的继承关系（应该来个UML就一目了然了）有：哺乳动物是动物的一个子类，长颈鹿是哺乳动物的一个子类等等……

看图：

那么就有：哺乳动物比长颈鹿大，比动物小，等于哺乳动物，和爬行动物却没有关系（这里的比较都不是对象之间的比较，要注意哦。）

呃，如果这个难于理解，我们再看看程序中的情况。假设有一个变量，这个变量在C#中有一个容身之处（不是说的存储区的物理地址），每一个变量在C#中的容身之处都对应一个类型（强类型语言就是这样的），那么，在运行时你可以在一个特定的容身之处存储对应类型的实例或者小于这个类型的类型的实例（拗口-,-）。所以呢，哺乳动物对象对应的容身之处可以存储一个长颈鹿，但是不能存储一个海龟。（考虑面先接口编程和抽象基类的思想）

容身之处这个例子说明的是“交换原则”，跟面向接口编程和抽象基类的机制很类似，也就是在很多地方，我们用子类代替基类（或接口或抽象类）来使用。

现在来定义什么是协变：一个操作如果在 T 和 U 两个类型上执行后返回的 T' 和 U' 之间的关系跟原来的 T 和 U 之间的关系（上面那4个伪表达式）相同，则这个操作就叫做协变。英文名：Covariance。

再看看什么是逆变：一个操作如果将 T 和 U 的大小关系改变了（大变小，小变大 - 逆转），但是不改变 T 和 U 之间的相等或不相干这两个关系，则这个操作就叫做逆变。英文名：Contravariance。

呃呃。变来变去，头已经晕了。

（还没完，等我喔！）

在中文的编码上有太多的差异，有的系统喜欢用GB2312，有的系统却采用UTF-8。

还有在网页上，Content-Type也有多种写法，有的爱好GB2312，其他的喜欢UTF-8等等。

很多系统中会用到MD5哈希进行数据校验，尤其是提供接口的时候，当这个时候编码不相同的话，就会出现很多头疼的问题，如果找不到原因，你或许还会埋怨这谁发明的C#语言，竟然MD5算法的结果不一样？！

当然，如果在接口间传递的数据不是非英文的话，一般是不会出现的，但是成产环境中，非英文的数据是很多的。

因此我们需要找到真正的解决办法来融合不同的系统。这里举一个小例子。

有一个第三方接口以HTTP方式提供，程序是用JAVA写的，提供的数据是GB2312编码的xml文件，现在你要用.NET来封装这个接口的实现，其中有些方法需要中文数据和MD5哈希校验，而你的系统是UTF-8编码。

找到问题在于编码的不同，就已经解决了90%，剩下的就只有需要一个算法了。

Code
/// <summary>
/// 指定字节流编码计算MD5哈希值，可解决不同系统中文编码差异的问题。
/// </summary>
/// <param name="source">要进行哈希的字符串</param>
/// <param name="bytesEncoding">获取字符串字节流的编码，如果是中文，不同系统之间请使用相同编码</param>
/// <returns>32位大写MD5哈希值</returns>
public static string ComputeMD5(string source, Encoding bytesEncoding)
{
    byte[] sourceBytes = bytesEncoding.GetBytes(source);

    MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();

    byte[] hashedBytes = md5.ComputeHash(sourceBytes);

    StringBuilder buffer = new StringBuilder(hashedBytes.Length);
    foreach (byte item in hashedBytes)
    {
        buffer.AppendFormat("{0:X2}", item);
    }

    return buffer.ToString();
}

编码问题其实真的很头疼。

网站A和网站B都是ASP.NET的应用程序，采用ASP.NET FormsAuthentication，网站B有受保护的文件夹，通过web.config配置了权限。网站C是纯ASP网站，受保护的页面是通过Session来维持用户登录状态。

存在这么一种现象：

网站A的页面1上有一个到网站B的受保护页面2的一个目标是新窗口(target="_blank")的链接a，点击这个链接会在新窗口打开页面2，之后转向到网站B的登录页面，正常登录之后关闭(按浏览器关闭按钮或Alt+F4)网站B的页面2；

再次从网站A的页面1上点击链接a，会再次在新窗口打开网站B的受保护页面2。此时并没有转向到网站B的登录页面，而且你会发现已经是先前的登录状态了。

同样，网站A的页面1上还有另外一个链接a2，点击会在新窗口打开网站C的受保护资源，第一次会要求登录，登录之后关闭网站C的页面，然后再点击链接a2，打开了网站C的受保护页面，并且也是已经登录的状态。

现象回显：

在网上搜索了许多关键字，其中发现FormsAuthentication存在许多问题，比如地址里的“/”替换成“\”或“%5C”就能蒙混过关而绕过认证等。但以上描述的现象之前还没有遇到过，我这里创建了两个web app，有兴趣的朋友可以实际运行下看看效果，我还把Trace打开了，这样可以看到认证Cookies的状态。请从这里下载它：http://files.cnblogs.com/shinyzhu/Spectral.zip

项目里有两个Web Application：web1和web2，web1上有个到web2的back文件夹的链接，按照上面的流程来运行，然后请告诉我你是否也遇到了这个现象。更进一步来说，你也可以把这两个web app部署到不同的服务器来测试。在这里我非常非常急切地希望听到大家的意见，或者有朋友知道这个原因，也请立即告诉我吧。非常非常地感谢！

垂直居中
by michael lascarides
针对 block 对象的更容易的垂直居中设置。（div + css 让人既爱且恨的一个重要原因就是垂直居中，让一个对象垂直居中显示在 block 容器中，且兼容所有主流浏览器简直就是一个噩梦 - 译者）

兼容所有主流浏览器的 CSS 2.1 与 CSS 3
by Erik
能兼容所有主流浏览器的 CSS 2.1 与 CSS 3 是 Erik 的梦想，但其中的某些功能在某些浏览器中总是磕磕绊绊。

更好的嵌入字体
by Webmonkey
不要 sFIR, 不要图片，要真正的字体。

CSS 变量
by Jeffrey Jordan Way, via css-tricks.com
能定义诸如色彩值一类的变量

更好地支持 100% height
by JLR
设置了 100% height 的容器的顶部和底部真正附着在页首和页尾，页面中间部分匹配内容并准确显示滚动条。搜索“100% height css”能找到各种解决方法，但事情原本不该这么复杂。

可重复使用变量
by Neal Lindsay
比如:
@var mycolor = #0080FF
h1 { color: mycolor; }
div.containbox { border: 1px mycolor; }

浏览器一致性与定义顺序
by JML
浏览器一致性非常重要。某些 CSS 在某些浏览器被忽略或部分忽略使 CSS 只有借助 JavaScript 才能正常使用。同时，对里面的 CSS 定义应该可以覆盖全局定义。

一句话复原
by Chris Pitzer
很多设计者要写40多行代码才能清除浏览器默认 CSS 定义，应当有一个简单的声明一次性将所有 CSS 复原，比如：
body { clear-default-styles:true; }

图形旋转与反转
by Stephen Bell
在设置图形圆角效果时候，我们需要同一个圆角图片的4个旋转版本来实现。应该有一个简单的声明实现旋转，如：
img .horiz { rotate:90; }

成组的 CSS 简化定义
by Volkan Görgülü, via css-tricks.com
如:
#foo h1, #foo h2, #foo h3
改为:
#foo [h1, h2, h3]

渐变
by Anonymous
以避免一条线一条线地实现渐变。

定位计算
by Anonymous
不使用 JavaScript 而是直接在 CSS 中实现：
left: ID1.Left + ID1.Width + 2px;

网格布局
by Kurt Krumme
table 布局曾经流行一时，因为 table 布局更接近网格布局的原理。CSS 的设置者们为什么要推出一个不伦不类的 box 模型？
div + css 在 Web 设计界已经红得发紫，尽管 div 有众多缺陷（比如垂直居中，比如在 IE 中的众多 BUG），如果哪个设计师胆敢使用 table，被人查出源代码，是会被耻笑的。然而译者从不畏惧使用 table + css，且愿意告戒那些盲目追随 div 并被折磨得半死的人，至少在目前，table 是被各种浏览器支持得最完美的容器对象。

使用 image 作 border
by Anonymous
应当可以用 image 作为 border，如：
border-right: url('image.png')

支持多个背景图
by Brad
这个 CSS 功能非常有用，有了这个功能，完美实现 CSS 圆角就变得十分简单了。

所有浏览器支持统一标准
by Anonymous
这里特指 IE<8 的版本。CSS 有成型的标准，但有些浏览器一定要搞一些自己的东西出来。

以上来自cb。大师们的期望果然很独特，相当多的期望也非常有用，如果实现了，Web开发就是多么轻松愉快的一件事情啊！比如变量、清除定义和定位计算，是我认为非常有用的。目前IE下可以用一些IE特有的表达式，但用起来太复杂。

还是期望CSS3更好更强大。也期望各个浏览器尽快支持CSS3。

技术是为业务提供支持的，但我觉得技术在一个IT公司的重要程度不亚于其它任何组成部分，有了稳定扎实的技术保障，展开业务就会得心应手了。而现在我感受 到的是在技术层面和其它的一些痛苦…

新公司新的环境，每个公司有自己的企业文化。当你进入新公司的时候，应该能听到“习惯了就好”之类的话。那你是要去习惯这些痛苦还是努力去改变些什么呢？ 习惯之后或许痛苦也就消失了，但改变之后能更好的话，你要去尝试吗？

我想听听大家的意见。

Here, There, Everywhere

Live Mesh的目标是作为一个中心平台，管理您的设备和文件等等。目前登录进去后不用在PC上安装程序就可以访问一个叫Live Desktop的管理中心：

看图（点击放大）：

可以在这里管理文件夹和文件，打开一个文件夹（点击放大）：

文件夹右边有一个显示最近消息的小窗口，图片文件夹还可以浏览，采用Silverlight实现的图片幻灯片效果噢！

从手机上也可以访问(http://m.mesh.com/)，可以管理文件夹，上传图片。手机上传的图片都在Mobile Pictures文件夹里：

上传方式我很喜欢，非常直接（不用发邮件），目前Flickr和校内也有这样的上传方式：

这样我就可以随时上传照片了，并和家里的电脑保持同步，让家里的人同时看到我拍的照片，哈哈！~~~

慢着，家里的电脑怎么同步呢？

这，就需要安装一个小软件啦，在Devices的圈圈里选择Add Device，点击Install，会下载一个目前只支持XP或Vista的小软件，叫LiveMesh.exe。

这个小软件体积不大，却很挑剔：

在控制面板将区域选项设为“英语（美国）”之后就可以正常安装了，安装的时候是在右下角提示的：

大概下载一些文件，自动安装好之后，就出现登录框：

然后会让你给你这个设备命名，这个时候再去看Mesh.com，会发现设备已经更新了。

这样在“我的电脑”里就会发现Live Mesh Folders，还有桌面上会有你在Live Desktop里的文件夹，这就是跟其他设备共享同步的地方了！

打开更新看看：

文件夹右边也有一个显示最近消息的窗口，不过还有问题-,-

不过，不过我可以向文件夹里添加文件同步了：

添加进去的文件会同步更新到Live Desktop里，这个时候用手机访问的话也会看到更新。以后会支持更多的设备，比如你有个MP3，也可以看到Update喔！

目前吧，还需要继续等待：

现在，jQuery已经成为ASP.NET的一部分了，很快就会通过ASP.NET MVC发布微软官方版本，还会发布一个具有Visual Studio智能感知的版本，非常值得期待啊。

看看Scott的图，jQuery的智能感知：

JQuery资源推荐

• jQuery - 下载
  • 插件
  • jQuery UI
  • jQuery团队
  • John Resig's Blog
• jQuery博客
• jQuery文档

一、问题回显

出问题的页面是一个注册页面。里面用到很多验证控件、输入框、下拉框，其中包含多个自定义验证控件，客户端的验证方法同时用到了jQuery。

出问题的症状是：当用户填写了用户名，点击了“检查用户名是否可用”，结果显示在一个id为accountHolder的span里，然后填完其他项，点击注册按钮，就出现错误页面了。

黄色经典错误页面如下：

一句“没有相关源行”将我们狠狠推开，无从调试。

通过各种途径（包括删掉控件、删掉验证、禁用脚本等等方法，花了一天多时间哦。结果在这里一句话就叙述完了，太不甘了）最后将视线定位在了一个用ajax实现的校验重复用户名的javascript方法上。这个javascript方法代码如下：

Code
function checkAccountExists(){
    var name = $("#nameBox").val();
    
    if (validateName(name)){
        $.ajax({
            type:"POST",
            url:"handlers/account.ashx",
            cache:false,
            data:"name=" + name,
            success:function(data){
                $("#accountHolder").html(data);
            },
            error:function(data){
                $("#accountHolder").html("系统异常，未能核对帐户名。");
            }
        });
    }else{
      $("#accountHolder").html("");
    }
}

其中validateName(name)是一个正则测试方法。

由于这个错误难以调试，现在就寄希望于HttpWath能给我们一些提示了。

二、HTTP请求和响应信息

用HttpWath可以跟踪请求，来看一个出现错误后的截图吧：

ajax请求的地址是CheckAccountExists.aspx，这个页面用Response.Write返回校验的结果，我以为是POST的问题，把方法改成了GET(点击看大图)：

无论POST还是GET获取校验结果，都返回500，也就是都返回黄色页面。到这里我已经很着急了，无论怎么调整控件和禁用脚本，它依然出错。

后来把ajax的请求换了一种方式处理，换成了一个Handler（实现IHttpHandler）来处理用户名校验，居然没有出错了。可以看看监测到的请求响应流：

上面是POST获取，下面是GET方式(点击看大图)：

由于每次测试的时候我都清空了浏览器Cache和输入的相同数据，保证每次POST back的数据相同，你可以从上面的截图里看出来，用aspx作为ajax响应端的时候发送的数据是2058b，而用Handler的时候是1987b。这多出来的一部分是哪里来的呢？

三、结论

可能你已经发现了，可是我却经过了千辛万苦才发现啊。

从前两张HTTPWatch的截图看出，在用aspx页面当后台ajax响应的时候，不仅仅请求了aspx页面，还有两个css文件，这是因为aspx页面里有HTML代码，把css文件包含了进来，而且HTML代码里还有一个服务器端的form，问题就在这里！

用一般处理程序就不会存在这样的问题。因为它返回的东西必须由你来完成，因而也有了全部的控制权。

当然你也可以用aspx来作为ajax的后台处理程序，那么请把aspx页面的所有HTML代码删除掉，只保留@Page声明这一行即可，结果是：

谜题终于解开了。

结论是，修改别人的程序真的是很恼火的一件事，更恼火的是别人的程序还写得不好。合作的烦恼也因此而生。

另外关于排错，有的时候要到最后才能发现错误的根源，这也是相当郁闷的一件事。我之前就很不喜欢ASP.NET的Post back机制，原因之一是因为ViewState等控件在页面上太影响美观了。

四、参考资源

关于视图状态，或许你要参考如下地址：

ASP.NET 视图状态概述

TRULY Understanding ViewState

微软中文技术论坛（MSDN and TechNet）

Windows 平台的编程语言已经多得数不过来了，很大一部分是运行在 CLR 上的，CLR 的目标就是要在一个兼容的生态系统中将语言和 API 无缝集成在同一运行时中达到百花齐放、百家争鸣的效果，从而方便了任何有特殊爱好的程序员轻松选择自己钟意的语言开始快乐地coding，多么惬意的一件事啊。F# 就是这多种语言中的一种，它是一种函数化语言。

面向对象有什么问题？

面向对象是我们最熟悉的编程方式，从大学课程到培训，无一不把OO作为重头戏来开展。通过面向对象可以描述对象与绑定这些对象之间交互的约定所构成的环境。OO 利用类型约定、多态性以及精细的可见性等多种功能来提供出色的重用和封装特性。通常面向对象的语言采用静态类型系统，所以这些语言被称为静态类型语言，这意味着程序创建和使用的所有类型都在编译时进行检查；这可防止您对 Duck 类型的对象调用方法 Moo（在此方法不存在的情况下）。在代码运行之前，编译器可检测各种类型之间被破坏和误用的约定，从理论上讲，这样做可减少运行时错误。

但是 OO 也存在一些缺陷。类型安全性可能会使编程人员过分依赖编译器来捕获错误，而不是亲自创建必要的测试基础结构。同时，OO 还会促使编程人员预先定义自己的约定，而这往往是与快速原型编程和多用户编程环境背道而驰的。在大型软件项目中，组件之间的约定（通常由不同的团队所拥有）往往在整个开发周期中不断演变，这就要求约定的使用者不断更新其代码。由于上述这些问题，OO 语言可能显得有些复杂和冗长。

函数式编程将程序计算视为数学函数的计算。将两个数字相加即为一个函数。假定有两个输入值 5 和 10，则输出值为 15。为解决某个问题，函数式编程将该问题细分为多个可使用函数表示的较小的块，然后再将这些函数进行组合以生成预期的输出。

函数式编程通常会避开状态（类似于变量和对象等内容）和状态变异。这实际上是与 OO 相左的，后者的主要目的恰恰是为了创建和操作状态（对象）。由于避开了状态，函数式程序往往更加准确、精密而且可验证。这是由于它很少会产生不可预知的副作用——当程序（如某个变量）的内部状态在各操作之间发生变化时可能会产生一些副作用，这些副作用会导致在一个或多个操作中产生非预期的结果。面向对象的语言和动态语言依赖编程人员来封装和保护状态，以减少不可预知的副作用，因为这些副作用会不可避免地导致更多错误的发生。函数式语言可以是很纯粹的，也就是说没有任何副作用或状态。但是，大多数流行的函数式语言都具有状态操作功能，这有利于促进与外部 API、操作系统以及其他语言的互操作性。针对某些程序必须使用一定量的状态信息来表示问题这一事实，它们也有相应的考虑。
有一些很有用的功能，它们对函数式语言是通用的。高阶函数可以将另一个函数作为参数，并且返回结果可以是函数，这为代码重用提供了强大的支持。
下面的例子对数组或数据列表中的每个元素都执行（或映射）一个函数。
假定没有变异的状态（为返回的结果创建一个新数组），并且没有函数结果依赖于先前的结果，则现在即可开始考虑将这一映射示例扩展到多个处理内核（通过将数组分成两部分并将得到的两个数组连接起来）乃至多个计算机（跨 n 个计算机拆分序列化数据、将代码函数传递到计算机、在一个单独主机中执行并连接序列化结果），而不必担心诸如状态管理等并发操作问题。这就是最酷的地方噢！

Code
// increment function
let increment x = x + 1

// data
let data = [1 .. 5]

// map (func, myList)
let map func myList = { for x in myList -> func x }

print_any (map increment data)

第一行定义一个简单的递增函数，它有一个参数 x，此函数将计算 x + 1。然后，将数据定义为一个不可变异的列表，其中包含整数 1 到 5。此映射函数以函数和列表作为参数，使用传统编程中的喷淋方法来遍历列表并执行 func 函数参数，然后将列表中的当前元素传递给它。接下来，print_any 函数使用增量函数和数据列表作为参数来执行映射函数，随后将结果打印到屏幕。

类型在哪里？在本例中并不存在。实质上，变量（数据）实际被类型化为 System.Int32 的列表，但并不需要将此告知编译器，因为它使用类型推断功能即可推断出这一情况。编译器做的工作越多，您的工作就会越少。这听起来非常不错。使用列表推导功能，您在一行内就可以轻松地重写先前的部分代码：

Code
print_any { for x in 1..5 -> x + 1 }

另一个很酷的 F# 功能是模式匹配：

Code
let booleanToString x = match x with false -> "False" | _ -> "True"

此函数具有一个 Boolean 类型，此类型可与 false 或任何其他值匹配，并返回相应的字符串。如果向 booleanToString 函数传递一个字符串，会出现什么结果？同样，编译器承担了繁重的工作，将 x 参数的类型定义为类型 bool。它通过 x 在此函数中的用法推断出这一点（在这种情况下，它仅与 bool 类型相匹配）。
模式匹配还可以用于构建强大的函数调度机制，以便在 OO 及其他环境中轻松地重现虚拟方法调度。当您需要根据接收方（将在此对象中调用虚拟方法）和方法参数的变化来改变行为时，虚拟方法才真正开始起作用。访问者模式即是为了帮助解决这种情况而设计的，但是在 F# 中基本不需要（已包含在模式匹配中）。

支持用户定义的类型，通常由记录（类似于 OO 环境中的类）或聚合（通常是一种有序序列类型）提供。以下是用户定义的队员和球队记录：

Code
type player = 
  { firstName : string; 
    lastName : string;
  }

type soccerTeam = 
  { name : string;
    members : player list;
    location : string;
  }  

延迟计算是另一种常见的函数式语言功能，其功能源自这样一种理论，即函数化编程中没有明显的副作用。延迟计算依赖于编译器和编程人员选择表达式计算顺序的能力，它可以使计算延迟到所需的时间点。编译器和编程人员都可以使用延迟计算技术作为精确的性能优化手段，因为它可以避免一些不必要的计算。在处理无限（或极大）数据集的计算时，它也是一种有用的技术。实际上，Microsoft Research 的 Applied Games 研究组曾在 F# 中使用此技术解析过数 TB 字节的 Xbox LIVE® 日志数据。

以下是 F# 中的延迟计算：

Code
let lazyTwoTimesTwo = lazy (2 * 2)
let actualValue = Lazy.force lazyTwoTimesTwo

此代码执行时，lazyTwoTimesTwo 只是在运行时充当指向执行 2 * 2 的函数的轻型指针。仅当实际强制执行此函数时，才能获得结果。
虽然函数化编程模型可能不太容易理解（可能需要 30-40 小时的准备时间），但一旦掌握它，您的编程能力就会有质的飞跃。您只需使用很少的代码就可以解决问题并减少错误。此模式通过最大程度减少意外的副作用来保护代码的安全，并通过执行积极的优化措施使其保持快速运行状态。此外，简单性往往代表出色的扩展性——您只需看一下 Map 代码，想想该代码如何能够轻松分布到成千上万台计算机中，就可以了解其中的缘由了。
至此，您已经看到了函数化编程的一些非常出色的功能，例如类型推断、高阶函数、模式匹配和用户定义类型等。

在hubFS有很多热门的讨论，推荐去看看http://cs.hubfs.net。

说明：这个皮肤是基于“简约”皮肤的，下面是我添加的CSS：（撑太大了。我把图片地址改了。）

Code
a:hover{color:#f60}
body{background:#fff}
iframe{display:none}
#main{margin:10px;background:#f3f3f3;border:1px solid #999}
.headermaintitle{padding:5px 0 5px 55px;line-height:34px;color:#fff}
.postTitle a, .postTitle a:link, .postTitle a:visited{padding:0;color: #03c;font-size: 14px;}
.postTitle a:hover{padding:0;color: #f60;text-decoration: none;border:none;}
#header{background:#801e2b url(...msdn.BG1.jpg) no-repeat left top}

#blogTitle{padding:0 16px 0}
#blogTitle h2{color:#fff;font-size:12px}
.blogStats{color:#fff}
#navigator{background:#9b4342 url(...msdn.glassBG1.jpg) no-repeat left top;
border:none;border-top:1px solid #d09291;border-bottom:solid 1px #253e53}
.menu{color:#fff}

#mainContent{}
#sideBar{border:none;}
.forFlow{}
.clear{clear:both;}

.day{margin:5px;padding:5px;border:1px solid #999;border-top:none;
background:#fff url(...box_BG_repeater.jpg) repeat-x top}
.dayTitle{display:block;font-size:16px;font-weight:bold}
.postTitle,.entrylistPosttitle,.feedback_area_title{border-bottom:none;margin:0;}
.postDesc,.entrylistItemPostDesc{border-bottom:none;}

#sideBar li{margin:1px 0;text-indent:0}
#sideBar li a{display:block;padding:0 2px;background:#e6e6e9;border:1px solid #e6e6e9;}
#sideBar li a:hover{border:1px solid #7a1312}