来源于：http://aoxuis.me/posts/2013/08/07/git-subtree/
例如，在项目Game中有一个子目录AI。Game和AI分别是一个独立的git项目，可以分开维护。为了避免直接复制粘贴代码，我们希望Game中的AI子目录与AI的git项目关联，有3层意思：
用git subtree可以轻松满足上面的需求。
如何在不同屏幕分辨率自动显示适宜尺寸的高清图片？opera这篇引导文告诉你。
传送门：Responsive Images: Use Cases and Documented Code Snippets to Get You Started
Loading提示应该是广泛也普通的应用了，其意义都明白。
这里我想说的是，在资源载入速度很快的情境下，loading提示往往一闪而过，所以其实是没必要显示loading的。这应该是可以优化的一个点。
如何优化呢？假设提供loading的两个方法：loading() 和 loaded()，只需loading设置一个比较理想延迟的setTimeout，loaded里面清除timeoutId即可。
据说 Google和Facebook的Git库，代码只有最新版(trunk)，没有 release 版本，没有版本号。
其实我很能理解，像我们的项目也不是按照特定git flow(初学者应该借鉴git flow)进行管理的，根据实际情况来使用，这就是实用。
对我们的项目来讲，基本有用的分支就是master和test，develop基本废弃，而master和test是互不干涉的，test可以随意删除和重建，各类新功能从master开出分支，合并到test测试，最后合并到master上线。develop或许有用的地方就是成为开出test分支的基础分支。
引用来自：http://fex.baidu.com/blog/2014/03/G-ossip/
1、从官网下载osx系统的mongodb包到目录/home/soft，并解压。
cd /home/soft curl -O http://downloads.mongodb.org/osx/mongodb-osx-x86_64-2.6.3.tgz tar -zxvf mongodb-osx-x86_64-2.6.3.tgz
2、建立一个软连接，并创建一个数据库目录
ln -s ~/home/soft/mongodb-osx-x86_64-2.6.3 /usr/local/mongodb mkdir -p /usr/local/mongodb/database
这几天一直在想的事儿，曾经也有这样的念头一闪而过：全站基于WebSocket的网站应用。
首先是前后端分离的开发模式，借用REST的api做数据交互，那么如果根本不用rest api，而是页面一旦打开就建立一个WebSocket，页面数据的产生和更新全通过socket连接而不是ajax，前后端就完全基于scoket事件来开发，尤其对于Single-Page-App来说, 都用不着angular.js这样的MVVM框架。
比如 UI-1， UI-2…UI-n等共同使用到一条数据data，当data在任意UI上发生了改变并传回了后端，后端处理后更新数据回推到前端，前端基于scoket事件的机制，可以自动响应这一事件的UI更新操作，UI-1，UI-2，UI-3都可以及时得到渲染更新。
socket可以做到单独数据块的传输，细分数据，前端组合数据或可以“逐行”更新界面，BigPipe。
这种开发模式还存在一些待定的问题，比如长期打开一个连接对后端是怎样的一个压力，相比较普通开发模式（大量短期连接）有没有优势。
不知道这种模式是否已经存在于现有网站应用上。当然游戏界应该是有的了，我只是想网站开发也这样呢？
一、网络安全
机密性（加密）、完整性（防伪造）、来源可靠性（签名）
程序漏洞
二、web前端安全
XSS：Cross Site Script（跨站攻击脚本）
往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行。
做网站的或应用的，从一开始就想到要对用户内容做安全处理的，真的很少，我们的产品也无法避免，有经验的都未必会想到，更何况很多人还对此无知。但是我们必须知道这些东西，尤其是用户内容会面向公众可见的那些功能页面。有人已经介绍的很好了，故直接转来记录一下，源自：关于XSS（跨站脚本攻击）和CSRF（跨站请求伪造）。 11年我记过的一种解决java方案，参见：用Jsoup对用户输入内容的HTML安全过滤
下面是转载正文：
我们常说的网络安全其实应该包括以下三方面的安全：
1、机密性，比如用户的隐私被窃取，帐号被盗，常见的方式是木马。
2、完整性，比如数据的完整，举个例子，康熙传位十四子，被当时四阿哥篡改遗诏：传位于四子，当然这是传说，常见的方式是XSS跨站脚本攻击和csrf跨站请求伪造。
3、可用性，比如我们的网络服务是否可用，常用的攻击方式是dos和ddos，拒绝服务和分布式拒绝服务攻击。
所谓的 cookie-free domains 就是在浏览器发送静态内容的请求时不会发送cookies 的域名。
查了查资料，要做到请求静态资源无Cookie，最简单的做法就是: 使用和当前网站域名完全不同的另一个域名来存放js, images, css等资源。比如当前网站是cssor.com，那么静态资源都放在 umitime.com上，在cssor.com请求umitime.com上的资源时，完全不会有Cookie传递。
还有通过二级域名来做Cookie-free domain的，不过稍有些条件限制。域名那么便宜，随便注册一个做Cookie-free domain就行了。
资料来源：
http://farlee.info/archives/yslow-used-cookie-free-domains-wordpress-blog-website-speed.html
http://undefinedblog.com/cookie-free-domain-configuration-nginx/
http://blog.s-shadow.com/?p=285
基本设想是三层（描述并非面面俱到，理解就好）：
PS： 该分层模式为本人原创定义（如有雷同，纯属天赋），转载者或引用者请注明作者：听雨~。