写递归函数的正确思维方法
递归是编程中一个相对难以理解但是却又很重要的概念. 对于从命令式语言开始学习编程的程序员天生对此有理解缺陷, 而对于从类似C++这种对函数式编程范式不友好的语言开始学习编程的程序员就更加如此了.(比如我自己) 碰巧(其实不巧)最近在读
语言的界限就是一个人世界的界限
语言的界限就是一个人世界的界限 -- 维特根斯坦
Ruby on Rails的世界
很多人会告诉你, 学习不同编程语言能够让你看到新的世界, 改变你思考的方式, 在程序员修炼之道中甚至会建议’每年至少学习一门新语言’, 也有Peter Norvig在十年学会编程中提出的那样, 学会至少半打语言. 我是比较赞同这种观点的.
用Markdown + VimPress写博客
这次把CSDN的文章移过来的时候, 发生了格式混乱的不愉快体验. 虽然以前的那些文章有些很稚嫩, 早期的文章现在看来甚至很可笑, 但是, 这种记录还是很值得保留, 毕竟是成长的过程.
整理一些文章格式的时候, 还发现一个有趣的故事, 原来我现在这么喜欢Vim, 来自于当时刚到北京, 用一个巨老无比的笔记本, 图形界面几乎没法用, 所以才无奈之下真正的耐下心来学习Vim, 见买了个新显示器. 而这已经是我第3次开始尝试使用Vim了, 从那以后, 我几乎没有Vim就没法工作了.
闲话少说, 综上所述, 我决定好好的管理一下自己的博客, 虽然现在已经用上了自己可以控制的Wordpress, 但是谁知道将来会不会再发生忘记缴费, 数据被删的事情呢, 即使我用上了Wordpress的备份, 我还是需要给自己写的文章做一个自己的备份, 并且可以用Git来管理, 这个才叫真的备份, 连历史记录都备份了. 同时, 因为格式上的原因, 我决定用某种文本格式来保存我的文章, 当然, 我可不准备手写HTML, 这样才不会出现用Windows Live Write写博客那样的悲剧, 并且, 作为离线写博客的方式, 用Vim来处理文本就方便了, 不用再去找各个平台的啥离线工具.
做一些新尝试
感慨优秀博客的衰落，作者反思了创作困境与“围墙”问题，决定拓宽自己博客的内容，尝试技术与生活分享的新方向。
UnityScript程序设计语言
UnityScript（即javaScript for Unity）的教程网上千千万, 中文的也不少, 但是讲Unity3D界面操作的多, 讲UnityScript这个语言的少, 同时对于UnityScript的描述部分, 也是入门的教程多, 对语言特性的描述少, 能够成系统的我就根本没有找到过. 连续的看了不少的Unity3D的文章, 书籍, 但是发现写代码的时候, 对UnityScript的细节掌握仍然不甚了了, 也就是对怎么写UnityScript效率更高, 更加符合语言设计的目的, 风格等事情并还没有清晰的认识. 这个对于习惯写脚本的人来说, 可能是常态, 对于习惯C++我来说, 简直难以忍受.
看到这样的名字, 学过编程的人都知道我是模仿了经典的C语言教材, 目的也是一样. 本文的目的不是再多写一个教程, 而是希望对UnityScript这个语言进行一个较为深入细节, 并且准确的描述. 也就是说, 相对于教程, 本文会更加像一个语言说明书. 同时, 更不用说的就是, 本文会甚少涉及Unity3D本身的界面操作, 仅仅关注于UnityScript这个语言, 不要希望通过本文学会Unity3D, 但是, 当你对Unity3D有了些基本的了解后, 希望写一个大型游戏时, 本文会对你该怎么写脚本, 怎么写对脚本, 怎么样写好脚本, 并且避免掉进语言的陷阱中有一些帮助.
更进一步的说, 因为UnityScript完全是Unity3D控制的语言, 同时仅在Unity3D中可用, 所以对于UnityScript来说, 甚至于连哪些是属于语言本身的特性, 哪些属于库的扩展, 这些都分不清楚. 这比Objective C还混乱… 在Unity里面想要完全的区分开库和语言几乎不可能, 但是本文还是会尽量做这方面的尝试, 尽量将本文的主要关注点放在语言上, 而不是库上.
怎样在Unity3D中使用Json
Unity3D中的javascript有些特异，和普通的javascript差异很大，其中eval就没法在iOS下使用（其实我在桌面版本也没有使用成功过）使得Json解析这种在javascript中非常原生态的事情变得不那么直接了。
直接使用eval后Unity3D给的错误信息很高端，我是没有看懂，应该是没有找到eval这个通用的函数：
Mono: AssemblyAssets/Scripts/Example/JTianLingExample.js(1,1): BCE0172: `UnityScript.Scripting.IEvaluationDomainProvider’ interface member implementation must be public or explicit.
在网上找到了litjson库，通过这个支持.Net的库来曲线救国，折腾了一下，基本搞定。看网上讲litjson的资料很少，并且以C#居多，我这里就记录一下。
UnityScript风格指南(UnityScript Style Guide)
公司最近要开新的Unity3d项目了，Google虽然有JavaScript Style Guide,但是UnityScript和JavaScript的区别实在大到了几乎不是同一种语言的地步，这个只能自己动手了。好在起码还能参考一下Google的style guide。
CocosBuilder可用性分析
最近写博客的时间的确是少了，Keynote倒是写了不少，其中的一个是CocosBuilder刚开源时，在公司分享时做的Keynote，关于CocosBuilder的，在这里跟大家分享，内容其实不多。
下载地址：CocosBuilder可用性分析
疯狂猎鸟项目小结 -- 技术篇（主要是cocos2d-x相关）
上次写了篇关于自己浅薄的管理经验的博客，被一些筒子们批评了，这次还是写篇技术贴吧，这样就不会有人说了，因为……那些人看不懂。该文早就和肖寒泉说了要写，但是因为写完后感觉好话不多，技术不多，就一直没有发布，现在我们又要开新项目了，而且不使用cocos2d-x了，那就发布了吧。
新的转变
2012总归是来了，这句话因为某种原因，听起来很悲壮。而这个时候，似乎也是该总结下2011的时候了，虽然过去的一年，我写的博客是越来越少了。 过去的一年对于我个人来说，应该算是工作以来最具有历史意义的一年吧，人生的轨迹在这里算是有了一个转折，或者说，有了一个比较突兀的变化。在年初的时候，我做了一个不那么艰难的决定，离开了那个曾经做出艰难决定的公司，加入了一家不到十人的初创企业，而这，决定了我将经历对于我个人来说最不平凡的一年，事实上，的确不平凡。 以前的工作对于我来说太容易，太没有挑战了，我需要一些更有难度的工作，这话由我说来似乎太过于自负或者自大，但是，这个话是前领导在年初的时候想要让我做出一些改变，给我的一个评价。背后的故事就不多说了，现在想想这个话说的的确有道理，假如我能够在每天晚上学习到半夜2~3点，因为兴趣去研究一些与工作不甚有关系的技术问题，写一堆乱七八糟的技术文章，而第二天半晕着去工作，但是工作却还总是不错的，甚至能够常常受到上级的认可，那这个工作对于我来说，的确有些过于容易了。 说这些没有啥自我膨胀的意思，虽然知道在中国当前环境下说这个话有些危险, 其实，说这些只是用于感叹今年我个人角色的一些转变，以及逐渐不那么容易的工作历程。