jaconey

游戏开发– 寻路系列之三

tech No Responses »

Nov 212011

上周讲了A* 的基本原理, 不知道有人能看懂不? 其实原理并不是非常复杂, 但实现起来的方案倒是有不少, 就像所有算法一样, 一般来说, 实现都比原理难得多.不过篇幅有限, 这里就不谈实现了, 只谈原理.

寻路算法介绍完了之后, 就来讲讲如何生成数据, 就和人的双腿一样, 数据就是寻路模块的另一条腿.

这里我尽量简单的用我自己的表达方式来描述, 由于过程很多, 我也没有能非常好的理解, 所以有遗漏还请大家补充.

我们的网格生成主要是用了这个方法Navmesh, 原理介绍我主要参考了这个网站, 有兴趣的同学也可以了解一下: http://www.critterai.org/nmgen_study

navmesh的生成主要有这么几步:

Voxelization – Create a solid heightfield from the source geometry.
Generate Regions – Detect the top surface area of the solid heightfield and divide it up into regions of contiguous spans.
Generate Contours – Detect the contours of the regions and form them into simple polygons.
Generate Polygon Mesh – Sub-divide the contours into convex polygons.
Generate Detailed Mesh – Triangulate the polygon mesh and add height detail.

体素化Voxelization

这一步是向量空间(vector space) 到体素空间(voxel space) 的转换. 用到的是叫保守体素化(Conservative voxelization) 的算法, 它保证了每个多边形面都能完全被生成的三维象素(voxel)包裹, 如下图:

体素化后, 生成的都是可寻路的高度场(heightfield)信息, 不可寻路部分被剔除.这一步是从一个固态高度场(solid heightfield) 生成一个开放高度场(open heightfield) 的过程, 一个开放高度场表示在一个固态空间上可能寻路的平面.

这个概念有点抽象, 请往下看…

区域生成Region Generation

这一步的目标是进一步的定义,那部分的面是可以寻路的, 并且把寻路区域分隔成连续的平面以供最后生成简单寻路多边形.

最终结果如下图, 墙体,围栏, 柱子, 桌子底等不可能寻路的平面在这步根据邻居信息和分水岭算法(the watershed algorithm) 被剔除, 一些孤立的小局域(比如桌子表面) 也被剔除.

留意楼梯, 虽然是多级, 个平面并没有连通, 但是也会被当做一个平面(绿色). 楼梯扶手等平面也被剔除.

轮廓生成Contour Generation

这一步将完成从体素空间回归到向量空间的转换. 区域(region) 的轮廓将被"遍历(walk)", 形成简单的多边形.

其中, 有些区域被合并, 多边形的边更平滑, 边长度被优化.

这一步结束后, 可寻路区域已经被一些简化的多边形所表示

凸多边形生成Convex Polygon Generation

凸多边形生成算法很多,这里就不多介绍, 这里主要是使用了把多边形切分为三角形, 然后尽量合并的方式做, 结果如下图:

精细网格生成Detailed Mesh Generation

这是navmesh的最后一步, 凸多边形通过"德劳内三角化"(Delaunay triangulation) 算法三角化成包含高度信息的三角形(注意楼梯)

顶点信息也会在这里补到各个三角形上, 以保证高度信息和模型保持一致.

至此, 寻路的数据生成完毕, 可以用于简单寻路系统. 各部分数据都有可能被寻路算法使用, 有多种方法去获取到数据以用于决定寻路的各个步骤.

其实上面的每一步都可以展开很多, 整个navmesh的生成非常复杂, 而且用到了许多算法, 完全可以写几篇论文以介绍, 这里就不展开了(我也没这实力),

有兴趣深入的同学可以参考下面的几个网站, 里面都非常专业的提供了实现方面的介绍(包括实现):

http://digestingduck.blogspot.com/2010/05/constrained-movement-along-navmesh-pt-2.html

http://code.google.com/p/recastnavigation/

游戏开发– 寻路系列之二

tech No Responses »

Nov 142011

上次说到，寻路算法主要是使用A* 算法，而算法的简单流程也已经介绍过，这里贴一下更具体一点的算法内容。

A*（A-Star)算法是一种静态路网中求解最短路最有效的方法。

公式表示为： f(n)=g(n)+h(n),
其中f(n) 是节点n从初始点到目标点的估价函数，
g(n) 是在状态空间中从初始节点到n节点的实际代价，
h(n)是从n到目标节点最佳路径的估计代价。

保证找到最短路径（最优解的）条件，关键在于估价函数h(n)的选取：

估价值h(n)<= n到目标节点的距离实际值，这种情况下，搜索的点数多，搜索范围大，效率低。但能得到最优解。
如果估价值>实际值, 搜索的点数少，搜索范围小，效率高，但不能保证得到最优解。
估价值与实际值越接近，估价函数取得就越好。
例如对于几何路网来说，可以取两节点间欧几理德距离（直线距离）做为估价值，即f=g(n)+sqrt((dx-nx)*(dx-nx)+(dy- ny)*(dy-ny))；这样估价函数f在g值一定的情况下，会或多或少的受估价值h的制约，节点距目标点近，h值小，f值相对就小，能保证最短路的搜索向终点的方向进行。明显优于Dijstra算法的毫无无方向的向四周搜索。

主要搜索过程：

创建两个表，OPEN表保存所有已生成而未考察的节点，CLOSED表中记录已访问过的节点。
遍历当前节点的各个节点，将n节点放入CLOSE中，取n节点的子节点X,->算X的估价值->
While(OPEN!=NULL)
{
从OPEN表中取估价值f最小的节点n;
if(n节点==目标节点) break;
else
{
if(X in OPEN) 比较两个X的估价值f //注意是同一个节点的两个不同路径的估价值
if( X的估价值小于OPEN表的估价值 )
更新OPEN表中的估价值; //取最小路径的估价值
if(X in CLOSE) 比较两个X的估价值 //注意是同一个节点的两个不同路径的估价值
if( X的估价值小于CLOSE表的估价值 )
更新CLOSE表中的估价值; 把X节点放入OPEN //取最小路径的估价值
if(X not in both)
求X的估价值;
并将X插入OPEN表中; //还没有排序
}
将n节点插入CLOSE表中;
按照估价值将OPEN表中的节点排序; //实际上是比较OPEN表内节点f的大小，从最小路径的节点向下进行。
}

上图是和上面Dijkstra算法使用同一个路网，相同的起点终点，用A*算法的情况，计算的点数从起始点逐渐向目标点方向扩展，计算的节点数量明显比Dijkstra少得多，效率很高，且能得到最优解。

游戏开发– 寻路系列之一

tech No Responses »

Nov 072011

上周对寻路做了一些原理和API上的了解，由于寻路算法实在是博大精深，涉及很多知识，一周时间太短，理解尚浅，就以我现在了解到的归纳一下，如有理解不对的地方，欢迎跟帖指正~

寻路算法属于人工智能的范畴，分静态和动态两种，动态的太高端，暂时没有了解，静态的话也有好几种，Dijkstra，A*和D*等。在网上搜寻了一下，3d 游戏的寻路算法主要还是A* （a-star，A星）使用的比较广泛，它有快速、路径短，不成环等优点，在orge，unity等引擎中得到了广泛的使用。

A*的最初设计是基于2d平面，对于3d 寻路就需要先对场景进行处理，我们游戏貌似一般叫它navmesh，简而言之就是把场景网格化，生成一个可寻路的平面，把3d的问题转化为2d的问题，然后就可以通过A*进行寻路。

所以3d 游戏寻路大致分为2部分：

navmesh
A*

navmesh比A* 要复杂很多，而由于A*可以在2d平面进行，理解起来会更简单一些，所以这里先简单介绍一下A*的原理。

先做一下术语的说明：

开启/关闭列表：算法的过程变量。可简单理解为临时记录区
G值：从起点A，沿着产生的路径，移动到网格上指定方格的移动耗费。
H值：从网格上那个方格移动到终点B的预估移动耗费。
F值：G + H
父节点：记录最短路径用

下面是算法过程(可直接导成伪代码）：

1，把起始格添加到开启列表。
2，重复如下的工作：
a) 寻找开启列表中F值最低的格子。我们称它为当前格。
b) 把它切换到关闭列表。
c) 对相邻的8格中的每一个？
* 如果它不可通过或者已经在关闭列表中，略过它。反之如下。
* 如果它不在开启列表中，把它添加进去。把当前格作为这一格的父节点。记录这一格的F,G,和H值。
* 如果它已经在开启列表中，用G值为参考检查新的路径是否更好。更低的G值意味着更好的路径。如果是这样，就把这一格的父节点改成当前格，并且重新计算这一格的G和F值。如果你保持你的开启列表按F值排序，改变之后你可能需要重新对开启列表排序。

d) 停止，当你
* 把目标格添加进了关闭列表，这时候路径被找到，或者
* 没有找到目标格，开启列表已经空了。这时候，路径不存在。
3.保存路径。从目标格开始，沿着每一格的父节点移动直到回到起始格。这就是你的路径。

原理不是非常复杂，但是看上去有点抽象，更详细的下周继续，敬请留意。

记账软件

tech No Responses »

Oct 312011

一直觉得“理财”这个词很高端，也总想自己可以高端，于是就总想理理。虽然财很少，但据说理理可以有变化，变多变少不一定，但改变才是永恒。

又据说记账是理财的第一步，还必不可少，于是尝试找一些软件来协助一下。

碰巧周末又看见一微博，让我觉得还有教育下一代的必要，自己不懂就更说不过去：

【洛克菲勒家族的零花钱教育】洛克菲特家族的孩子每周都能领到三角钱零花钱，但必须分成三份：自己花、储蓄、施舍。孩子们每一分钱的用途和时间都必须记录在小账本上，周末进行检查。如果谁漏记了一笔帐，罚五分钱；而记录无误的则可得到五分钱的奖励，以此培养孩子勤劳节俭的美德和艰苦自立的品格。

简单理了下，我的记账需求大致如下：

方便，可以随时随地
有明细
可输出报表
跨平台
UI 能用（中文版软件，要求“好用”貌似有点过分。。。）

由于第一点，所以基本目标锁定了手机软件。芸芸android市场中，看见一个是由金蝶开发的，叫”随手记“，虽然从来没用过金蝶，但知道ERP，知道好多财务都是用它，大厂，名气大，我看行。于是就下载了来试试。

几番把玩，发现有几个优点：

软件不算很大，apk大概4M多，启动比较快。
记账方便，分类较细，属性有金额，帐户，商家。。。这点很关键，我不希望花费太多时间在”记"这个动作上，我更希望把时间放在月终的数据整理上。
跨平台同步。这个功能也很关键，特别是现在大家每天都在各种设备上不停的切换迁移，不跨平台太痛苦。没Mac是一缺陷，但可用web版补救，也算方便。
可输出各种报表。通过各种属性进行筛选，分类，比较清晰，不愧是做ERP出身，这点小case 还是too simple。
UI 做得还不错，主界面分类较清晰
还可以为账目添加照片

总体感觉这个软件还不错，免费版基本能满足需求。VIP 版也就20RMB, 也在合理范围之内，可以接受。

不过有几个功能一直很希望能有一款软件支持，可惜没有。。。顺便吐槽一下：

根据信用卡消费明细自动记账。招行专业版有这个功能，但太独立了，总不能我两个地方分开记吧？这点很不给力。
和B2c， C2C?的电商整合。现在好多金钱都是在taobao，京东，当当这样的电商网站上消费走的，如果能导出上面的数据自动分类记账，那就很赞！

在这个高聚合的互联网时代，能出一个这样的产品，市场应该还是不小的，至少我自己是很看好这样的应用，可惜自己没这个时间和精力去做。。。哪位如果开发了，记得通知我，只要保密和隐私能保护的好，我一定属死忠用户!

最后补充一些界面的介绍（点击看大图）：
记账界面，看见那个摄像头的图标没有？那就是为这条流水附加的照片入口：

这是进入的主界面，可以看到汇总数据：

可以设置各种帐户：

分类汇总，类别很细，很清晰：

这是预算的分类，具体可以定制：

备份功能也很强大，直接搞到sd卡上，可以存到自己的电脑中。

Linus谈软件开发

tech No Responses »

Oct 212011

原文: http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440

如果让我选 "谁是世界上最天才的软件项目经理", 我会认为Linus 当之无愧. Linux 内核, 一个集千万程序员智慧的结晶, 现在已经给广泛用于各种设备, 而发起者和项目最高管理者一直没有变过, 都是Linus Torvalds.

在linux 之前, 开源项目几乎从来没有如此强烈的影响力, 而如何聚拢全球开发者, 有条不紊的开发一个成功的产品, 曾经被认为是mission impossible, 但Linus 做到了.

查了下linux kernel的发布流程, 大致如下:

2.6.x 内核树
2.6.x 内核树是有Linus Torvalds维护的，可以在kernel.org的pub/linux/kernel/v2.6目录里找到。它的开发流程是这样的：
－当一个新的内核发布之后，一个为期两个星期的窗口打开，在这段时间里维护者可以提交大的补丁给Linus，通常是已经在-mm内核中存在了一定时间的补丁。推荐的提交补丁的方式是通过git（有关git的更多信息可以在http://git.or.cz/找到），但是普通的补丁也是可以的
－两个星期之后一个-rc1内核发布，然后现在只可以再加入不会为内核添加新功能的补丁，因为那样的补丁可能会影响这个内核的稳定性。请注意这个时候一个整的新驱动（或者文件系统）可以被接受。因为只要这个变动是自成一体的并且不影响它之外的代码的话，就不会有产生回归的危险。在-rc1发布之后，git可以用来发送补丁给Linus，但是这些补丁也需要发到一个公开的邮件列表里以备审查。
－当Linus确信当前的git（内核代码管理工具）树已经处于一个合理的健全状态，足够测试时，一个新的-rc就会发布了。目标是每周发布一个新的-rc内核。
－这个过程将会持续到内核被认为可以发布为止，整个流程会持续大概6个星期。
Andrew Morton在linux-kernel邮件列表里写的有关内核发布的一句话值得提一下： “没有人知道什么时候一个内核会发布，因为它发布的依据已经掌握的bug状态，而不是事先设想好的一个时间线。

可以看到, Linux 的内核发布是很神奇的一个存在! 最终节点只有一个: Linus!

记得有一次linux 2.6 有一个严重的bug, 导致部分显卡无法正常工作, 但是没法做hotfix, 原因是: Linus 去美国度假了…

Linus 是一个传奇, 就像 Steve Jobs 一样, 是一个无法复制的神一般的存在…

well, 仰慕到此为止, 看看这次他老人家又说了什么.

对于开源项目, 他的意见是: You make it public, and then you assume that you’ll have to do all the work, and ask people to come up with suggestions of what you should do, not what they should do. 为何大多数开源项目最终都是失败, 也许就是因为出发点没有找对. 忘记那个哲学家说过: 人本自私. 这也是西方普世价值之一, 不要一开始就奢望项目一放出来就会有很多人热心的加入, idea 再好, 没实实在在的东西, 没人会想着投入的.
对于有人觉得代码很重要, Linus认为: “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.” 他还提到, 很多公司对代码质量很关注, 我经历过华为当时那种几乎苛刻的对代码风格的追求, 所以深有感触. Linus 认为对代码的追求胜过对用户体验的追求这个想法本身就是错误的. 他举的例子也很有代表性: 如果一个bug的fix 会影响到用户体验, 那么你就已经破坏了这个规矩. 他认为很多公司都自以为是的在破坏用户体验, 为得就是fix 一个bug.
对于开发工具, Linus觉得工具并不是必须的. if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand. (一个release几百个patch, 他都觉得可以by hand… 这是一种什么样的DIY 精神啊!!= =)
对于版本管理, Linus的一个想法比较体现他的性格: I personally tend to think tar-balls and patches are actually preferable to that – if only because they make all developers ‘equal,’ and you don’t get the kind of model where certain people have ‘commit access,’ and the rest are second-class citizens. 这个众生平等的观念也放到了他设计的git 上. git 完全没有类似svn/cvs 的那种对读写限制的权限管理模块, 如果要做, 就是通过linux本身的权限系统来管理, git不做这种dirty work.

总体来说Linus 是IT界比较出名的愤青, 同样的Jobs 也是出了名的苛刻. 也许伟大的人总是有那么点和常人不同的地方

有兴趣的同学还可以回顾一下Linus 大神当年对C++的狂喷: http://blog.csdn.net/turingbook/article/details/1775488 我觉得还是骂得挺对的, 我也曾经对C++热衷过, 还做过一个template嵌套的项目, 但那种痛不欲生的感觉让我再也不想再深入这苦逼语言之中去, 从此也走上了anti-cpper 的这条不归路…

还可以说什么

life No Responses »

Oct 182011

周末看到一个新闻:”女童两次遭车压十余路人漠视”

可能是心理上的应激反应, 我没有点开视频看. 对生命的漠视, 已经不能算是新闻, 已经忘记了听到过多少次世人的冷漠, 人也慢慢的开始麻木

而在终于点开视频, 看完后, 我依然还是忍不住想问: 这个社会究竟怎么了??!!

女童被碾压的过程我始终没有能看完, 不敢… 不忍… 没有勇气

有时候, 我们看着网上的视频, 已经练就一身好本事, 没有任何代入感, 感觉就像在看电影, 好像一切都离自己很遥远, 自己总会是幸运的一个, 厄运永远不会发生在自己身上…

我不认同.

让我想起美国波士顿犹太人屠杀纪念碑上所铭刻的马丁·尼莫拉的话：

在德国，起初他们追杀共产主义者，我没有说话——因为我不是共产主义者；接着他们追杀犹太人，我没有说话——因为我不是犹太人；后来他们追杀工会成员，我没有说话——因为我不是工会成员；此后他们追杀天主教徒，我没有说话，因为我是新教教徒；最后他们奔我而来。却再也没有人站出来为我说话了。

看了视频, 我有很强烈的代入感. 身为人父后, 多了一份责任. 而经历过几次生离死别后, 我更加珍惜生命, 更懂得活着的可贵. 看到这种对生命的漠视, 而且是如此幼小的一个生命…而且冷血的人还不只一个! 还看到一位带着小朋友的母亲….

语塞, 不知道还可以说什么…

下面是网上的视频片段, 没看的请补:

珍惜生命, 善待身边的人, 纵使素未谋面, 但是, 那是一个生命啊! 希望尚存良知的人会越来越多, 而不是慢慢灭绝….

也希望小朋友能够坚强, 我依旧相信着奇迹… UPDATE: 可怜的小悦悦已经被诊断为”脑死亡”…. 哀…

1岁的纪念(待续)

life No Responses »

Oct 142011

不知不觉, bb已经一岁多了, 今天把妈咪整理出来的照片全部上传到了相册中. 看着他一天一天的变化, 百感交集. 感触良多, 来不及一点一点的描述, 放几张上来, 也算是测试一下外链吧.

刚从医院出来

回家以后(开始古灵精怪了)

很有领导范儿吧?

妈咪怀中微笑

P1030025
喝个水都这么不正经…

Golang笔记

tech No Responses »

Oct 122011

go lang, google重金召集的几个牛人自主开发的语言, 如Thompson, Unix和Plan9作者; Pike, UTF-8 字元编码作者; Robert Griesemer, 曾协助制作Java的HotSpot编译器，和Chrome浏览器的JavaScript引擎V8; 还有gcc作者等. 一帮重量级人物能做出来一个什么样的语言呢? 好奇的去体验了一下.

基础语法比较符合C的习惯, 记录点自己觉得特别的地方:

很少的语法关键字. 我认为这点很重要, 一个语言设计的好坏, 我个人认为从这点就可以看到一个端倪. 怎样用更少更简洁的关键字去清晰的表达逻辑, 需要的看设计者的功力. 所以我看一个语言的时候, 一开始都会去数一下它一共有多少个关键字以判断这个语言是否容易学习. go的语法关键字是比较少的, 共25个, 作为一个编译型语言来说, 应该算是比较容易学习的了. 而lua 是20个, python是35个.而那个变态且无耻的C++是80个(不完全统计)! 大学教材真是害人, 我现在都不知道当初是怎么学的C++…
goroutine, 这个基本上是go 最大的亮点. 学习不深, 基本上我是理解为和lua coroutine类似的东西, 但从语言层面对这个特性有支持的语言不多, 也是因为这个特性, 让go的程序编写变得很不一样. 需要时间去调整习惯.
“非面向对象”. 曾几何时, OO的概念深入民心, 但最近几年, OOP 开始走下坡, 以erlang, lisp等为代表的FP的兴起, 让更多的人反省OO 是否适合程序开发. Go 也基本上改变了python或者说C++的那套模仿smalltalk的oo方式, 改成类似Objective-C 的那种消息机制(曾经写过一篇周记谈Objective-C的OO, 我认为这种机制更加符合OO的本质). Go 的描述中, 数据不再和逻辑绑定, 一个type可以在任何地方添加”方法”, 而这个type 也只是叫做”receiver” 而不是对象, 而且Go 完全抛弃了class 这个关键字, 意味着也不会有instance的这个我们耳熟能详的概念. 传统意义上为了所谓的”封装”而存在的关键字 public private等也被舍弃.
代码可以没有”;”. 这点有点像脚本语言, 但编译器会在代码生成过程中把这个;补上. 作者不建议程序员使用”;”, 因为会把代码看上去的不那么的简洁. 除非一些非用不可的地方, 如for.
“{” 必须在一行的结尾. 这点的原因据说同上, 为的是让代码更好看. 不过过分的是, 如果不写在行尾, 编译器就报错了…
没有了while, do. 取而代之的是for的单独用法: for true{ }.
更强大的switch. switch是我个人比较喜欢的C 语言关键字, 它可以把一些工作变得简单(至少我可以少写好多个if else了…). go的switch 支持int 以外的所有类型, 而且有开关, 如 switch a;False{} 那么这个switch 就不会被执行.
支持指针. 如果作为一个脚本语言去理解, 那么它很强大; 但作为一个编译型的语言来说, 它貌似又不那么nb, 但是在写go的时候, 往往会忘记了它原来是一个编译型语言…
- gofmt 很好很强大. 许多语言都需要为代码风格发愁, 项目中不同的人会写出不同风格的代码, 有的项目使用Xlint 来保证代码风格, go则原生提供了gofmt 用于重新排版成prettty 的代码. 使用起来非常方便, 效果也很好.
- godoc 简单的文档输出. 没有doxygen 的语法, godoc 提供的是最简单的文档输出, 包括系统库文档都是通过这样的方式输出的
- 完美支持unicode. 可以这样用…
```
for pos, char := range "中国人" {
fmt.Printf("character %c starts at byte position %d\n", char, pos)
}
```
prints
```
character 中 starts at byte position 0
character 国 starts at byte position 3
character 人 starts at byte position 6
```
而对go的效率, 有人做过测试. 和C还是有不小的距离. 普遍c语言速度在go的2倍以上, 在一些测试(regex 实现) C领先30倍. 让不少人担心Go的性能是否能够支撑住系统级应用.

而和python3 相比, go最多领先了165倍. 编译型的优势还是表现了出来. 但是能否在线更新这个问题还没有深入去了解.

另外, 对于不少人关心的go和C 对接的问题, go 已经支持直接在代码中嵌入C 代码, 免去了在不同文件中切换的烦恼. 从初步的感觉上来看, 这个对接的功能很强大, 但能否满足所有的调用需求还需要深入了解才能给答案.

总体来说, Go 的goroutine 和channel 让并发程序的开发变得更加简单, 从语言的级别对并发进行设计的语言不多, 函数式的erlang 算一个, 但它函数式的编程风格需要较长的时间适应, Go过程式语言的学习曲线要更加平顺一些. 现在还有一些问题, 比如社区中有人反应go 处理web 请求的速度不如node.js, 社区太小支持不及时等. 要说的是node.js是专业做web server的, 如果go 一出来就把行业最快的比下去了, 那做node.js的哥们估计也大郁闷了. 短短2年中, go有现在这样的成绩已经不易, 库函数也足够丰富, 只是在性能的优化上还有一些路要走, 而一帮大拿坐镇, 加上有google这样的一个强大的背后支持, 相信Go 还是会很有前途的!

RubyOnRails初探

tech No Responses »

Oct 112011

redmine是用ruby on rails 写的, 由于有时候需要修改它的源码, 所以这周空余时间对ror 做了一点点的了解, 随意帖一下…

Ruby，一种为简单快捷的面向对象编程（面向对象程序设计）而创的脚本语言，在20世纪90年代由日本人松本行弘（まつもとゆきひろ/Yukihiro Matsumoto）开发，遵守GPL协议和Ruby License。它的灵感与特性来自于 Perl、Smalltalk、Eiffel、Ada 以及 Lisp 语言。由 Ruby 语言本身还发展出了JRuby（Java 平台）、IronRuby（.NET 平台）等其他平台的 Ruby 语言替代品。Ruby的作者于1993年2月24日开始编写Ruby，直至1995年12月才正式公开发布于fj（新闻组）。因为Perl发音与6月诞生石pearl（珍珠）相同，因此Ruby以7月诞生石ruby（红宝石）命名。

ruby的语法不是非常复杂, 而且有点点lisp的味道, 比如调用不需要括号, 最后一次调用默认作为返回等. 但是有些语法又比较特别, 我还不是掌握的很好, 比如这样的一个语法:

respond_to do |format|

format.html

end

就有点让我莫名其妙

rails 是ruby 上的一个开源的web框架, 也是目前为止唯一的一个. 在java 基本上垄断了企业级应用的情况下, ror的应用有些许抬头的迹象, twitter 最早就曾经用过ruby 2.0的版本, 但是由于性能问题最终还是放弃了, 换成了java.

简单接触后, 感觉rails 最大的一个特点是开发非常快速,

装好ror 之后只要简单几步, 就可以完整的建立起一个可用的网站. 如下:

$ cd ~/rails_project
$ rails demo_app
$ cd demo_app
$ script/server

然后访问主机的3000端口就可以访问

扩展也很简单, rails中有script/generate 这个脚本, 其中包括一些简单的框架生成器, 还可以从网上下载各种新的生成器, 基本上一步即可建立一个使用ajax的web 2.0 博客.

为何rails 能够快速开发, 快速部署, 主要是因为它提供了,也仅仅提供了一种开发模式, 也是我一直很稀饭的: MVC 模式.

帖个图:

这个图画的也很清楚了,就不解释了.

因此在修改应用的时候, 基本上只要换V 就可以支持不同的表现, 换C 就可以适应不同的应用.

基本上我觉得更多的时候 no choice is good choice! 像java那种, 有很多的框架也不一定是件好事. 就像mac 上的开发一样, 没有选择, 逼着你用mvc 也不一定是一件坏事

苹果IPhoneSDK有感

tech No Responses »

Oct 112011

最近苹果IPhone/IPad 的开发火热非常, 当然, 也可以说最近移动平台的开发都很火热. 于是在空余的时间, 大概了解了一下IPhone SDK 以及上面App的开发.

大致了解了一下皮毛之后, 我对苹果的敬仰又加深几分. 有这么几点很值得学习:

完善的文档. IPhone 的SDK 非常庞大, 不亚于Win32 的SDK, 但是它的文档非常全面, .h 文件也写的非常详细. 作为一个经历了这么长时间磨练的产品, 文档的完整性绝对是给它的成功奠定了坚实的基础.
从架构上严格保证MVC 模式的应用. 众所周知, MVC 模式是UI 开发非常重要的一个设计模式, 无论在哪个写界面的SDK 都会使用这个模式, 但Apple 做的非常的严格, 如果不使用MVC 模式, 我几乎无法开发. 虽然引入模式总是会比直接操作更复杂, 不直观(没什么比hack代码更简单轻松的了… ), 但就是因为这种严格的限制, 保证了这个平台上的代码更容易维护, 更容易扩展.
编辑器无比强大. 相信大家都用过Vs, 新版本中它也非常强大, 但和苹果的Xcode相比, 它真的只是刚上路! (linux上的各种蹩脚编辑器就更是不入流了…) 强大的UI 编辑界面, 快捷智能的自动补全, 模板的生成, 帮助文档的关联…. 一个好的编辑器, 对于程序员来说, 至少可以提高30% 的效率
统一的样式设计. 在IPhone 上, 已经为各种应用设计好了统一的行为, 比如"书签", "列表", "图片" 等, 包括控件"进入""退出"的动画, 所有这些都早已经在SDK 中写好, 开发者所需要的只是把它们拉出来, 和Contorller 关联上, 设置好Model, 就基本上可以工作, 就和堆积木一样简单. 就因为这种统一, 只要这个应用中用到系统控件, 就和其他的App没有任何差别. 这也是为何IPhone上的软件, 操作习惯上都惊人一致的原因.

从上面几点可以看到, 苹果的SDK 并不是毫无限制的让开发者去发挥的, 某些自由度是被系统收回. 某些sdk 只会把一些涉及到安全问题的功能留给系统, 但苹果甚至把操作习惯都作了限制. 从开放的角度, 这也许是一个很不好的practice, 但是, 从最终的产品来看, 这个设定的效果非常的好. android的应用也是五花八门, 但为何无论如何都还是不如Apple上的舒服? 因为它们无法统一. 每个设备都是厂商定制的, 每个App 也是开发者定制的, 于是在不同的设备上, 甚至同一个App 都会产生不一样的用户体验. 而对于这种电子消费品来说, 用户体验比功能更加重要, 我认为.

建议做UI 做客户端的同学也去了解, 体验一下Apple 的开发, 我认为绝对会有不少收获.

Older Entries Newer Entries

Life N' Tech

jaconey