Site_Of_R

突然又觉得说是坑有点太过了，定位为trick应该比较合适

研究了一下午，结果发现跟所有linux产品的windows移植（or阉割）版一样：想要用jekyll，就免不了——折腾

整个折腾过程如下：

1. 安装jekyll（废话）
2. 一来就遇到个编码的问题，google了半天还是stackoverflow靠谱，环境变量里改一下就可以解决了：

set LC_ALL=en_US.UTF-8
	set LANG=en_US.UTF-8
	

1. 为了格式化上面那段代码又产生了另一个蛋疼的问题：jekyll依赖于python
2. 然后就是最新的pygments竟然有BUG
3. 终于折腾完毕，终于可以在我大windows上调试了

一是因为国内的VPS都挺坑的，二是觉得还是要写点东西(总不能用QQ空间吧……) 下定决心还是不再继续租VPS了，把所有博文转过来(一是原来的blog本来就没流量，也不在乎评论。二是用github装逼犯儿更足)

deadline：7月26

开始研究jekyll

他代码是这样写的：

[SuppressMessage("Microsoft.Design", "CA1054:UriParametersShouldNotBeStrings", MessageId = "0#", 
Justification = "Response.Redirect() takes its URI as a string parameter.")]
public RedirectResult(string url, bool permanent) {
    if (String.IsNullOrEmpty(url)) {
        throw new ArgumentException(MvcResources.Common_NullOrEmpty, "url");
    }

    Permanent = permanent;
    Url = url;
}

然后metadata里的注释写的是：

// Summary:

//     Initializes a new instance of the System.Web.Mvc.RedirectResult class.

//

// Parameters:

//   url:

//     The target URL.

//

// Exceptions:

//   System.ArgumentNullException:

//     The url parameter is null.

public RedirectResult(string url);

我就呵呵了，不是说好的只有在url是null的时候抛ArgumentNullException么，为啥连string.Empty也抛？

Long story in short：当使用JavaScriptSerializer去序列化一个DateTime值的时候，如果这个值的Kind是unspecified，则会根据Timezone去序列化DateTime。

这就包含了一个隐含的BUG：如果DateTime做了持久化操作在还原时，比如从String “2013-3-1 12:00:00”中初始化DateTime的时候，不会有Kind。此时如果在用JavaScriptSerializer去序列化，则有可能得到的result是“2013-3-1 12:00:00” +- N

顺手吐槽：有源代码就是好，开始就误解Asp.Net MVC3了，原以为Json Response有啥特别的处理，结果发现只是一句简单的

if (Data != null) {
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    response.Write(serializer.Serialize(Data));
}

###Gains[0]###

得Jolt奖的书都很NB，毋庸置疑。只算是比较认真的读了一遍，书中的自习题都没做过（估计做了就真要用七周了），周末断断续续在读，被喷了好几次zhuangbility了（去满记甜品也在看、starbucks也在看），用了N周总算是看完了。

作者也很NB，不但能玩转这么多种语言，而且还能直接找到好几种语言的作者直接交流，段位略高。书中对每种语言的介绍也很厉害，从语法基础到核心竞争力再到drawback一气呵成，所以基本上每种语言都可以流畅的在两个小时左右读完。

写书厉害的大牛才是真大牛，反过来，如果你不能很好的表达你对技术的理解，那么你一定不是真大牛

###先说结论：###

1. Google最牛逼。
2. 利用浏览器缓存的最佳实践是： 让response header里的Cache-Control：max-age=天长地久 给每个静态资源打上fingerprint（有proxy挡在前面就用改文件名，没proxy改querystring就够了）

再来开始扯

http://stackoverflow.com/questions/631609/ajax-synchronous-callbacks

上面的那个SO的帖子里解释的很清楚了，反思一下，有时候真心有点异想天开了，jsonp本来就是一个script tag的hack，哪有可能像真的ajax请求一样做到很多事情

BTW：jquery中的async:false还木有怎么看懂，都怪1.5以后的$.ajax改了很多还和deferred关联到一起了——

// if we're in sync mode or it's in cache

// and has been retrieved directly (IE6 & IE7)

// we need to manually fire the callback

if (!s.async || xhr.readyState === 4) {
	callback();
} else {
	handle = ++xhrId;
	if (xhrOnUnloadAbort) {
		// Create the active xhrs callbacks list if needed

		// and attach the unload handler

		if (!xhrCallbacks) {
			xhrCallbacks = {};
			jQuery(window).unload(xhrOnUnloadAbort);
		}
	// Add to list of active xhrs callbacks

		xhrCallbacks[handle] = callback;
	}
	xhr.onreadystatechange = callback;
}

本来想吐槽一下jquery的，明明$.ajax({jsonp:"callback",async:false}); 就是个错误的调用方式（伪命题），为何还要允许这种方式存在？

不过一想到jquery本来就是个javascript的库，心下也就释然了。

难得能在周一早上来这么早的。

难得在周一早上能看到这么有营养的东西：http://news.cnblogs.com/n/162954/

先写标题

再编辑的时候已经过了两个星期了。。

###透明### 跟其他部门打交道时的体会——A调用B，B再去调用C帮A完成某些操作，如果A反而感觉不到B（或者是忽略了B）的存在，其实也是一种挺厉害的设计的。好像说的有点抽象，说白了就是如果可以让customer忽略掉了中间过程的存在，可能会使问题更加清晰和简单。再白一点：化简中间过程，隐藏非主要逻辑。上升到哲学的高度就是——程序就是输入变输出。

###弱类型的致命伤### 不可靠什么都是坑爹的，用的好的话，javascript这种渣语言都能写操作系统呢！虽然可能是偏激了些，但就我感觉弱类型最致命的还是intellicense不好做啊（比方说function的参数就没法点出东西来），编程体验有些差劲（其实也可以理解为不可靠好像）。

###好记性不如烂笔头### 真理啊，我还想到个啥来着，直接就忘了。。。 看来还是至少要记个标题啊

吐槽先：尼玛的还是成都好啊

###Fn() Fn.call Fn.apply### 吐槽+感悟：想要NB，还是要造轮子。

javascript实现callback的三种方式：fn()最直白；call能让你用this用的爽；apply不但能顾及this，还能让arguments也爽。

最后我还是用的fn()，无他，但KISS耳。

###耍花枪### 跟某牛K交流时感悟到的东西：既然程序员又名“搞技术的”，肯定是爱玩些新技术的，但玩火玩过了肯定是要烧身的。把控力是其一：你不一定有足够的能力把新技术真正的玩转（虽然你以为||他告诉你很简单）；可维护性是其二：你天资聪慧自诩天下第一，难免接手的人不是路人甲

###JSLint### 还挺好用，但是这个问题：http://stackoverflow.com/questions/1450721/solution-for-jslint-errors 有点蛋疼

尼玛的，明年8月count一下字数，一年不够10000字的话就拿服务器和域名的钱吃饭了。

###上层保护下层，下层不相信上层### 听个培训的时候听到的，本来是指服务器之间请求和调用的保护，防止系统雪崩的。联系到防御式编程，什么参数检查之类的code，肯定是越早越好，BUT，下层的实现，应该还是Defence First的

###为啥Windows不给力### 越来越有感觉，在不考虑一些成本，足够YY的前提下——Linux：U can do whatever you want VS Windows：U can do whatever Windows want you do。到一定程度的时候，比如需要自己定制操作系统或者是服务器的时候，Windows就会完全无力了

###Talk is cheap，show me the code### Linus大神说的绝对没错，code first（做demo在前）绝对比仔仔细细读完所有书和文档有效率的多

###Do One Thing### 似乎是Unix设计理念里提到的东西，真的NB的东西就只是把Do One Thing这件事情做到了极致而已。比如我现在隐隐觉得自己前端水平有点见长的趋势了，就是因为我能感知到一些东西的One Thing了——jQuery就只是sizzle的加强版；Knockoutjs——提供映射，绑定dom和javascript的对象；underscore——补全javascript的util函数；sammyjs——浏览器路由。

好吧，我就是这样用他们的。

###DRY KISS### 干吻在手，天下我有。

真能做到这两大原则了，也就无敌了

–edit：想了一下还是多加点东西写成个UL吧，正式开始工作也一年了，写个几千字的长文不太可能，就稍微多记点东西充数吧

• 介于我还是太菜！心得只有一句话：你觉得perf没问题的地方——可能会有问题；你自己都觉得有问题的地方——一定有问题！
• 我真的太尼玛菜了！数据库的字段浪费太严重了，各种nvarchar(200)起码浪费180
• 彩笔我是！想了半年了，单元测试还是没写起来，到12月为止，再不写unittest就不买新PC了
• 菜比！做一堆垃圾操作，明明是DB=>DB就完事的，非要从DB=>APP=>APP=>DB，还多select一堆不需要的column浪费带宽。不要求perf就不去管perf了吗？
• 但是彩笔不会迷信大神！这段可能略长，我就再多一个p

大神经常会告诉凡人各种Best Practice，类似于写JS都用===不用==，记下来了并且常常实践肯定没错。但是如果不知道===是为了

1. 避免cast的消耗
2. 可能会有潜在的BUG的话，

那彩笔永远也变不了大神，永远也不能写Best Practice给人家看的。（我自己的BP就是——如果不是大循环，我都用==的，一来不熟JS的人看了我代码不会疑惑、至少减少了一次baidu的耗时，二来有时候我并不要求精确，我就是需要implicit cast）

天下之水。

只有像写tweet一样写：

####Log4Net文件名Trick（paranoid向）#### http://stackoverflow.com/questions/10798985/log4net-rollingfileappender-filename-just-with-datetime

###Stringbuilder的Clear### 在 <= .Net3.5 的时候用sb.Length = 0 来代替sb.Clear()感觉最好了