摘要: 一个小时如何编写一个支持七牛上传的 markdown 编辑器的客户端。本地主要是讲解下最后的打包发布，和里面的一些注意内容。本篇的内容不会太多，就是几个打包命令的执行。我们打开 Gruntfile.js 这个文件。会看到有很多 grunt.registerTask 这样的代码，用过 grunt 的应该知道，这就是注册的任务，grunt.registerTask('dist-win' 例如这个，执行grunt dist-win就会打包成 window 平台的文件，对应的也就有 mac 平台 、linux 平台的。注意打包的时候，要注意是否下载了对应的平台包。在第一篇 文章中，有说明下载平台的包，否则是无法打包成功的。注意打包的时候，把'jshint',给注释掉。这个是Javascript代码验证工具，用来检测你的代码规范性，合理性的。比如你在 js 中写a==b，用jshint的时候，就必须是a===b，采用恒等的方式。还有很多要求，用jshint，你的代码习惯会越来越好。如果对这些不是特别严格，也可用去掉。未来计划目前已经足够我使用，但是还有很多缺点，比如打开文章，没有插入 hexo 的文章模板，有些弹出框显示不完整等等。在以后，会慢慢加进来的。
摘要: 记录一下建博的历程,再记录一下从wordpress转移到hexo的步骤.从08年开始博客后,用过不少的博客程序,pjblog zblog typecho wordpress gae,还用过一些博客服务,35blog Google博客 点点博客 sae等.各有各的优势,反正是掏钱的稳定放心,免费的不稳定.最近用过的sae,用sae原因是当时有微博认证,用sae基本可以免费使用.自从sae修改了策略之后,送得1万豆也在前几天用完了.现在的我懒得折腾这些,就开始寻找了屌丝使用.一个免费,能绑定域名,还能少折腾的方式.选择 github 的好处github 免费提供了一个 github Pages 服务,300M 的空间,足够屌丝们使用.可以绑定域名.现在流行使用这个,程序员用这个感觉有点 B 格.可以使用 markdown 来编写.选择哪种 github pages 的博客程序可以选择有 jekyll octopress hexo 等一些, 我调查了一些, jekyll octopress 使用比较复杂, hexo 生成静态文件速度快,但我700多篇文章,也用了1分多钟.从 wordpress 转移到 hexo进入 wordpress 后台设置,选择导出,会打出一个wordpress.xml 文件.安装 hexo-migrator-wordpress 插件,执行hexo migrate wordpress wordpress.xml, 就会转化成 .md 格式化的文件.这个过程中,可能会有些错误,无法转换的问题,一般都是 wordpress 文章有一些特殊字符的问题,根据错误修改吧!如果成功,那么你只需要执行 hexo g 和 hexo d 就可以发布了.注意重要的事情要说三次,从 wordpress 转成 hexo 会丢失留言数据. 重要的事情要说三次,从 wordpress 转成 hexo 会丢失留言数据. 重要的事情要说三次,从 wordpress 转成 hexo 会丢失留言数据.
推荐一款漂亮、简洁的在线编辑器 Quill# Quill 支持常见的所见即所得编辑模式，易于扩展、方便定制、轻量，与 Bootstrap 框架融合的很好，外观简洁、关键功能完备。网址: http://quilljs.com/[repo owner=”quilljs” name=”quilljs”]
第1集:锦绣华南 http://t.cn/zWZF3Er第2集:云翔天边 http://t.cn/zWZF13x第3集:神奇高原 http://t.cn/zWZFB3A第4集:风雪塞外 http://t.cn/zWZFrmJ第5集:沃土中原 http://t.cn/zWZFdYW第6集:潮涌海岸[去旅行]
离站提示JS工具：Ouibounce,当离开网站时给出一个提醒,从jobbole看到的.tip:和bootstrap的model 结合时要在参数的callback中 手动 用$('#share').modal();触发，官网没说，这个要注意.demo如下:[repo owner=”carlsednaoui” name=”ouibounce”]
从@蔡学镛看到的数据库的一些设计原则,可以考虑考虑.梳理数据库时，你会很惊讶地发现，各种数据都被塞进数据库，所以做数据库梳理的第一步是把它们区分出来，我的区分方式是：核心数据、业务数据、核心缓存数据、业务缓存数据、Session 数据。核心数据及其缓存都要再根据领域（domain）来区分，业务数据及其缓存都要再根据业务（business）来区分。梳理数据库或设计数据存储时,可以考虑数据的属性：1. 访问频率 (高/中/低)2. 读写比 (只读/读多/读少)3. 重要性 (重要/普通/不重要)4. 保密性 (保密/普通/不需保密)5. 数据笔数 (多/一般/少)6. 数据体积 (大/中/小)7. 一致性要求 (强/中/弱)8. 热点现象 (强/中/弱)9. 索引方式 ( ____ )
from: http://z.ihu.im/u/BZp(71、依赖倒置原则依赖倒置的意思，是不要想象别人应该怎么用你的API、以及用你的API做什么；而是“倒”过来想，我的API对外提供了一个什么样的抽象、这个抽象是否够好、够简洁，有没有把不必要的细节暴露给用户。比如说，之前我所在的公司做了个类似电子商城的东西，其它项目组做出产品，就放在这个商城里面销售。那个商城团队就犯了干涉他人实现的大忌：他们非要了解其他项目组的逻辑，才知道如何才能把别人的产品上架销售。不要这样。这种做法就导致两个团队耦合过重；且新产品和老产品逻辑无法兼容、甚至因为修改逻辑去迎合新产品，导致老产品销售逻辑出现问题——又因为怕老产品出现问题，于是不得不逼新产品去适应老产品的流程，而不管两者差别有多大。这就导致，我们经常花1个月实现了一个新产品；为了把它上架却经常需要3个月甚至超过半年——并且，商城团队和其它项目团队都必须加班、修改逻辑，甚至经常因为商城方提出的诡异逻辑/需求而出现摩擦（这伙人傻的……我都忍不住发过几次火……实在看不下去，我就给了一个方案，要求商城团队修改。这个方案基于依赖倒置原则，要求商城对外提供一个商品的抽象；商品的定义是有名字有价格、通过销售转移所有权的逻辑实体。如此一来，任何项目想要上架，只要给自己起个名字、定个价格、用html或某种富文本格式或商城项目组喜欢的任何格式提供一段商品介绍、最后再提供一个“所有权成功转移给xx用户”的回调接口即可。双方从此再不需要哪怕一个字的交流。这个接口可以永远不修改哪怕一个字节，足以支持任何商品种类的交易。（事实上，我们团队就是按这个要求写程序的。写完再和商城团队扯皮。这可以避免他们动辄增加的猪逻辑/需求影响到我们的内部结构：随便他们要什么，我们都可以弄个空逻辑或者不同商品规格搪塞过去）但商城团队觉得一旦做成这样，他们以后就没事可干了，所以拒绝修改……好在，后来他们集体辞职了。——如果你的接口不能稳定，那么你一定违反了依赖倒置原则，或者是做了一个超烂的抽象。——至于什么叫好抽象，请参考KISS原则2、完整且最小原则完整，就是接口的功能要完整，该有的功能必须有；最小，是接口功能没有冗余，不要接口A提供的功能，用一点外部逻辑再加上接口B或者接口B+接口C也能实现。当然，这是一个比较理想化的指标。某些时候，为了易用性或者性能，是可以甚至必须做一些更简单、方便、易用，但加起来却不是最简的接口的。但，这个完整且最小的接口必须找出来。它是一切的基础，也体现了开发者是否已经做出了一个清晰的抽象。有了它，其它可以以后慢慢补；但如果没有这个基础，什么易用、简洁，都不过是扯淡。我宁可用一个繁琐、难用、难理解，但可保证不变的接口，也不想碰做点简单的活计非常方便、易用，但根本没法实现稍难的需求、并且不能保证稳定的接口。事实上，两者的差别就在于有没有好的抽象；而一旦有了好的抽象，哪怕想做得繁琐、难用、难理解，都不是容易的事。总结：有了好的抽象，接口才可能稳定；然后找出完整且最小的接口，那么只要抽象不变，这个接口就绝对稳定；最后，在这个基础之上，做出易用、易理解的接口。
