分类目录归档:编程

随机迷宫生成算法

在线迷宫游戏地址: lbmaze@sae
项目地址: lbmaze@github
最近研究了下迷宫的生成算法,然后做了个简单的在线迷宫游戏。游戏地址和对应的开源项目地址可以通过上面的链接找到。开源项目中没有包含服务端的代码,因为服务端的代码实在太简单了。下面将简单的介绍下随机迷宫的生成算法。一旦理解后你会发现这个算法到底有多简单。

  • 将迷宫地图分成多个房间,每个房间都有四面墙。
  • 让“人”从地图任意一点A出发,开始在迷宫里游荡。从A房间的1/2/3/4个方向中的任选一个方向前进。在从A房间走到B房间的过程中,推倒A/B房间之间的墙。
  • 如果方向x对面的房间已经走过,则选择其他方向。如果所有方向的房间都已经走过,则退回上一个房间看是否还有可选道路。
  • 走到真正无路可走时,说明已经走过了所有房间,迷宫也生成好了。

下面是该算法的python实现(核心部分)

def gen_map(self, max_x=10, max_y=10):
    """ 生成迷宫 """
    self.max_x, self.max_y = max_x, max_y  # 设置地图大小
    self.mmap = [[None for j in range(self.max_y)] for i in range(self.max_x)]  # 生成原始地图
    self.solution = []  # 迷宫解法
    block_stack = [Block(self, 0, 0)]  # 从0,0开始生成迷宫(同时将这点作为起点),将起点放到栈里
    while block_stack:
        block = block_stack.pop()  #取出当前所在的房间
        next_block = block.get_next_block()  # 获取下一个要去的房间
        if next_block:  # 如果成功获取下一走发,将走过的房间放回到栈里
            block_stack.append(block)
            block_stack.append(next_block)
            if next_block.x == self.max_x - 1 and next_block.y == self.max_y - 1:  # 走到终点了,栈里的路径就是解法
                for o in block_stack:
                    self.solution.append((o.x, o.y))
def get_next_block_pos(self, direction):
   """ 获取指定方向的房间号 """
    x = self.x
    y = self.y
    if direction == 0:  # Top
        y -= 1
    elif direction == 1:  # Right
        x += 1
    if direction == 2:  # Bottom
        y += 1
    if direction == 3:  # Left
        x -= 1
    return x, y
def get_next_block(self):
    """ 获取下一要去的房间 """
    directions = list(range(4))
    random.shuffle(directions)  # 随机获取一个要去的方向
    for direction in directions:
        x, y = self.get_next_block_pos(direction)
        if x >= self.mmap.max_x or x < 0 or y >= self.mmap.max_y or y < 0:  # 房间号在许可范围内
            continue
        if self.mmap.mmap[x][y]:  # 如果已经走过
            continue
        self.walls[direction] = False
        return Block(self.mmap, x, y, direction)
    return None  # 没找到有可用的房间

注: 由于采用该方法生成的迷宫道路的分支数量并不是太多,coffeescript版在生成迷宫的过程中增加了随机处理,对应算法也稍微复杂一点点。

让你的python程序同时兼容python2和python3

python邮件列表里有人发表言论说“python3在10内都无法普及”。在我看来这样的观点有些过于悲观,python3和python2虽然不兼容,但他们之间差别并没很多人想像的那么大。你只需要对自己的代码稍微做些修改就可以很好的同时支持python2和python3的。下面我将简要的介绍一下如何让自己的python代码如何同时支持python2和python3。

  • 放弃python 2.6之前的python版本
    python 2.6之前的python版本缺少一些新特性,会给你的迁移工作带来不少麻烦。如果不是迫不得已还是放弃对之前版本的支持吧。
  • 使用 2to3 工具对代码检查
    2to3是python自带的一个代码转换工具,可以将python2的代码自动转换为python3的代码。当然,不幸的是转换出的代码并没有对python2的兼容做任何的处理。所以我们并不真正使用2to3转换出的代码。执行 2to3 t.py 查看输出信息,并修正相关问题。
  • 使用python -3执行python程序
    2to3 可以检查出很多python2&3的兼容性问题,但也有很多问题是2to3发现不了的。在加上 -3 参数后,程序在运行时会在控制台上将python2和python3不一致,同时2to3无法处理的问题提示出来。比如python3和python2中对除法的处理规则做过改变。使用-3参数执行4/2将提示 DeprecationWarning: classic int division 。
  • from __future__ import
    from __future__ import”后即可使使用python的未来特性了。python的完整future特性可见 __future__ 。python3中所有字符都变成了unicode。在python2中unicode字符在定义时需要在字符前面加 u,但在3中则不需要家u,而且在加u后程序会无法编译通过。为了解决该问题可以 “from future import unicode_literals” ,这样python2中字符的行为将和python3中保持一致,python2中定义普通字符将自动识别为unicode。
  • import问题
    python3中“少”了很多python2的包,在大多情况下这些包之是改了个名字而已。我们可以在import的时候对这些问题进行处理。
try:#python2
    from UserDict import UserDict
    #建议按照python3的名字进行import
    from UserDict import DictMixin as MutableMapping
except ImportError:#python3
    from collections import UserDict
    from collections import MutableMapping
  • 使用python3的方式写程序
    python2中print是关键字,到了python3中print变成了函数。事实上在python2.6中已经带了print函数,所以对print你直接按照2to3中给出的提示改为新写法即可。在python3中对异常的处理做了些变化,这个和print类似,直接按照2to3中的提示修改即可。
  • 检查当前运行的python版本
    有时候你或许必须为python2和python3写不同的代码,你可以用下面的代码检查当前系统的python版本。
import sys
if sys.version > '3':
    PY3 = True
else:
    PY3 = False
  • six
    six 提供了一些简单的工具用来封装 Python 2 和 Python 3 之间的差异性。我并不太推荐使用six。如果不需要支持python2.6之前的python版本,即使不用six也是比较容易处理兼容性问题的。使用six会让你的代码更像python2而不是python3。

python3的普及需要每位pythoner的推动,或许你还无法立即升级到python3,但请现在就开始写兼容python3的代码,并在条件成熟时升级到python3。
注:

将VIM的配置文件切换到janus

janus是一个非常流行的VIM配置脚本,其中集合了很多优秀的VIM插件。
此前我一直都是用自己收集的VIM配置以及插件,到现在之前的某些插件已经出现了更优秀的替代品。索性将janus fork了一份(vicalloy’s janus),针对自己的使用习惯做了少许的定制。
janus具体加载了哪些插件,做了哪些默认配置,大家还是直接去看官方的README吧。
我主要做了下面一些改动:

  • 取消了Tab、空格等不可见字符的提示功能。
  • 取消行号显示。在vim中直接 :num 即可跳转到对应的行,所以我一直感觉行号显示并不是太有用。
  • 关闭supertab插件。这个插件似乎和某些插件有冲突。
  • 增加部分插件
    • FencView 国人写的自动识别文件编码的插件。
    • ZenCoding Zen Coding简单的说就是用css来写html,至于具体怎么用还是去找些Zen Coding的文章来看吧。
    • eclim 将Eclipse的功能集成到vim的插件。其中有很多很好用的vim scripts,比如htmldjango的语法高亮以及缩进处理等。将其中的部分脚本打包到了我的vim配置中。
    • jedi vim的代码补全能力非常的弱。jedi相比来说要强大很多,不过对动态语言来说补全想做到非常智能并不容易。
    • vim-powerline 状态栏定制插件

注:

  • janus并不支持windows系统,如果你需要在windows下使用janus需要自己做些小改动。
  • 加了一堆的插件后VIM的启动速度明显变慢,此前都是秒开,现在要个2~3秒的启动时间。

编程语言们各自的哲学

曾有同事打算将ZOPE和PLONE啃下,我是不建议的。同事说我不够开放,对自己不喜欢的技术都很排斥。我承认,每个人都会有自己的偏好。但我不赞成使用ZOPE恰恰不是因为偏好问题,我也不会因个人偏好而建议采用或不采用某项技术。
在我看来ZOPE是一个很变扭的技术。ZOPE引入了接口/容器等概念,给人感觉ZOPE在很多方面都在有意的模仿JAVA。Python和JAVA在语言哲学方面有着比较大的差异,试图以Java的方式来做一个Python的WEB开发框架无疑是有些别扭的。如果ZOPE真的学的特别象,那我为什么不干脆直接使用Java?
这世界上存在各种编程语言,每种编程语言都有着自己的特点,正是这些差异满足了各类人的不同需求。这些编程语言都有着自己最核心的思想,这个核心思想就是所谓的“哲学”。没有自己“哲学”的编程语言是无法在这个世界上存活的。有些编程语言看上去问题很多,却很流行。或许它的那些问题也正是它流行的原因。

PHP

PHP的使用门槛非常的低,而且通常用PHP写出来的东西代码都不是那么的“漂亮”。于是有些人将PHP看成是业余程序员用的东西。然而就是这么一个看似不怎么专业的东西统治了大半个互联网。PHP的“哲学”是“quick and dirty”。在一定程度上beauty和quick并不容易并存。PHP将quick和简单作为第一要求,代码的漂亮退居第二。dirty的代码并不容易维护,所以通常在系统在复杂后,复杂业务逻辑功能将交由其他技术实现。PHP则安心做着自己表现层的事。

Java

有人说Java是给笨人用的语言。这话虽然很难听,不过在一定程度上这还真就是Java的哲学。Java充分利用语言特性和IDE等自动化工具来避免程序员犯错,让人海战术成为可能。对于大多Java项目只需要少数的牛人来设计系统构架和主要接口,下面的具体实现用“笨人”来做就可以了。

Python

python的哲学是“quick and clean”。在一定程度上说python确实非常clean也很quick。不过python的clean可让也让python变的有些平庸。python号称什么都能做,却又没在哪个领域特别突出。

Ruby

Ruby强调人文关怀,编程是一件有乐趣的事,你可以按照自己喜欢的方式去使用ruby。相对而言ruby可能更容易发挥个人的创造性,但在团队协作时则容易遇到麻烦。

国内代码托管网站不完全列表

可以说GitHub的出现完全颠覆了以往大家对代码托管网站的认识。GitHub不但是一个代码托管网站,更是一个程序员的SNS社区。在GitHub出现后,国内外有的代码托管网站也都开始引入GitHub的某些元素。
GitHub真正迷人的是它的创新能力与Geek精神,这些都是无法模仿的。
有朋友想做基于HG的代码托管网站,所以对国内的代码托管网站有过一些关注。下面是我知道的国内类Github的代码托管网站。

要想在国内做一个成功的代码托管网站并不容易。如果你是一个小团队,且缺乏足够的魄力和觉悟,我是不建议去折腾这个的。

  • 对开发者而言GitHub已是一种流行文化,如果你的特色不够显著很难说动人来。
  • 小团队关门的事情经常发生,如何让人相信你的服务是长久可信赖的是一个挑战。
  • Github没有被墙,或者说不能访问的概率还是太低。如果之是速度快一点点,不足以做为卖点。而且对git而言,需要真正和服务器同步的时间很少。

MongoDB介绍以及Python的相关库

MongoDB是一个高性能,开源,无模式的文档型数据库,是当前NoSql数据库中比较热门的一种。MongoDB提供了比较丰富的数据库查询接口,是目前最接近关系数据库的NoSql数据库。
近两年MongoDB的发展速度非常的快,不少公司已经将MongoDB应用到实际产品中。在这些公司中最著名的应当是foursquare,国内的淘宝等公司也部分使用了MongoDB。MongoDB更完整的应用列表可以在MongoDB的Production Deployments找到。
技术人员普遍有追新的爱好,看到一个不错的东西就想在自己的项目中用少。在对MongoDB做了些了解后,感觉使用MongoDB作为普通web应用的主数据库或许并不是一个很好的主意。

  • MongoDB的优势是速度以及海量数据的支持,另外一个有点就是schemeless。真正需要用到schemeless的地方似乎并不是太多。目前很多 MongoDB 封装,也都增加了scheme的定义功能,基本上放弃了schemeless特性。另外如果过度的schemeless,日子久了后可能自己都搞不清楚自己到底在数据库里放了什么东西。
  • MongoDB的特性决定了某些关系数据库很容易做的操作在MongoDB中会很不容易实现(比如多表关联查询等,而且据说分页性能也不怎么样?)。为配合MongoDB,在构架设计乃至产品功能需求方面都需要做些调整。
  • MongoDB的另外一个问题是太费内存,在内存不够大的时候性能很可能还不如mysql。所以有人称MongoDB是有钱人用的东西。
  • 可能大多人都不太会有机会遇到真正需要MongoDB的海量数据。

在V2EX上发了一个关于MongoDB的帖子(有谁在用 MongoDB 体验怎么样),引来不少关于MongoDB的吐槽。不是说MongoDB不够优秀。MongoDB有着自己特定的应用场景,如果只是为了尝鲜而贸然使用,可能并不会得到预想的效果。
下面简单的介绍一下MongoDB相关的一些Python库:

  • PyMongo MongoDB的Python接口开发包。PyMongo提供了最原始的MongoDB访问接口,其他的Python MongoDB库基本上都是基于该库进行开发的。
  • MongoEngine 为MongoDB提供了类似Django ORM的API。支持定义Scheme定义,同时提供DynamicDocument类用于支持schemeless。MongoEngine内置了Django提供支持。如果你之前使用过Django,MongoEngine会让你觉得非常舒服。
  • MongoKit 和MongoEngine类似的一个库。个人更倾向于MongoEngine所以对MongoKit没有太多了解。

[django-ajax-validation]Django表单AJAX校验及提交的APP

项目地址https://github.com/vicalloy/django-ajax-validation
django-ajax-validation是一个使Django支持表单AJAX校验的第三方APP。我做了一些修改,增加了表单的AJAX提交以及twitter-bootstrap的支持。

安装

  • pip install git+git://github.com/vicalloy/django-ajax-validation.git
  • 在Django settings的INSTALLED_APPS中加上”ajax_validation”。

一个简单的使用范例

views.py

from ajax_validation.views import validate_form
from ajax_validation.utils import render_json_response
...
class TimelineForm(forms.ModelForm):
    class Meta:
        model = Book
def add_book(request):
    #创建表单并进行校验。返回表单以及校验结果。
    form, validate = validate_form(request, form_class=BookForm)
    if validate['valid']:#如果校验成功,执行保持操作
        book = form.save()
    return render_json_response(validate)//返回JSON

模板

进阶

django-ajax-validation的原始文档就写的非常糟糕,我也偷懒,所以想了解更多还是直接看代码吧。

Node.js相关知识

简单的说Node.js是一个使用Javascript作为开发语言的web开发框架。凭借JS良好的用户基础以及Node.js的高性能等优势Node.js迅速的流行了起来。
此前我一直以为Node.js只是一个使用JS作为开发语言的类ROR开发框架。在对Node.js做过简单的了解后发现这确实是一个很酷的东西。如果有机会非常希望将系统的部分功能改由Node.js实现。
由于Node.js的资料已经不少,这里就不再多费唇舌。想对Node.js有更多了解可以参考下面的一些文档。

  • Node.js 究竟是什么 让你对哦Node.js有个总体概念。Node.js是什么,适合做什么,不适合做什么。
  • Node入门 一本(篇)免费的Node.js入门教程。可以用于了解Node.js一些基础使用以及相关概念。
  • Node.js官方文档(API文档) 可以看前几节,对Node.js的Global Objects有些了解。其他的东西可以用的时候再查。
  • 深入浅出Node.js InfoQ关于Node.js的系列文章。
  • Node Club@GitHub Node Club 是用 Node.js 和 MongoDB 开发的新型社区软件。这是一个开源项目,可以用于熟悉Node.js。简单的阅读过Node Club的代码,感觉用Node.js做传统WEB开发的体验并不是太好。
  • npm Node.js使用的包管理工具。在这里你可以找到很多优秀的JS库。很多JS库不但可以用于Node.js还可以直接用于前端。Node.js的社区非常活跃,第三方库的增长速度非常的快。在这些第三方库中不乏一些很有创意的东西。
    • express 构建在Node.js之上的WEB开发框架。
    • lesscoffee-script 这两个已经太出名了
    • jade 非常酷的一个JS模板语言,看上去有些类似zenCODE。
    • ejs 另一个JS模板语言。相比jade,ejs更适合普通人的使用习惯。
#jade
html
  body
    h1 User &lt;em>#{name}&lt;/em>

题外话(About WebSocket&Django)
WebSocket的良好支持是Node.js的一大优势。WebSocket是HTML5里出来的新东西。WebSocket的实质是在浏览器与服务器间建立一个socket连接从而实现客户端与服务端的双向通信。由于Python的WSGI协议无法支持WebSocket,所以包括Django在内的大多WEB框架要支持WebSocket并不是一件容易的事(注:Evented Django这篇文章里有介绍如何使Django支持WebSocket,不过总的来说有些折腾)。Tornado和Node.js一样同为非阻塞的WEB服务框架不需要使用到WSGI,所以不存在这个问题。

web服务器的同步与异步

最近几年node.js和tornado的流行和他们采用的是非阻塞(异步)模式有很大的关系。传统的web服务器通常采用的是同步方式,服务器的每个进程/线程每次只能处理一个请求,在遇到高并发的情况时为即使处理请求必须创建足够多的进程/线程来处理每个请求。举个简单的例子,如果每个请求的处理时间为4秒,为了支持每秒100次请求,你必须为此创建4*100个进程。创建400个进程,这个成本无疑是有些太高了。
node.js和tornado等异步服务器在接收到用户请求后,先将请求放到后台处理,等处理完成后再处理结果返回给用户。node.js和tornado都采用了类似的事件机制,可以在一个进程里并行的处理多个用户请求。在遇到高并发的情况下不需要创建多个进程/线程就可以轻松应对。也真是因此许多人认为异步模式肯定比同步模式要强,异步模式肯定要更好。
Gunicorn是一个Python WSGI HTTP服务器,同时支持同步以及异步模式。Gunicorn默认采用的是同步模式,在它的Design一节中有关于同步以及异步模式的选择说明。前面讲到同步模式下为处理高并发需要创建大量的进程,但如果每次请求的处理时间都非常短就不会出现需要创建大量进程的情况。如前面的例子中,如果每次请求的处理时间为0.1秒,则只要创建0.1×100个进程即可支持每秒100次的请求。node.js、tornado的事件机制虽然要比创建进程和线程的成本要低的多,但也不是完全没有开销的。
最后总结下:
如果服务满足一下特点时可以考虑异步服务器,不然就不是很有必要了

  • 大量的并发请求
  • 每个请求处理的耗时都比较长

将LBForum、“似水流年”的部署环境切换到Gunicorn+Supervisor

Gunicorn 是一个Python WSGI UNIX的HTTP服务器。Gunicorn有着不错的性能以及稳定性。Gunicorn对WSGI、Django、Paster提供了很好的支持,使用起来非常的简单。
此前 LBForum似水流年 使用apache+wsgi的方式部署在webfaction上。为了给服务器节约些内存将部署方式切换到Gunicorn。不过似乎效果并不明显。除工作进程外,Gunicorn还会另外启动一个master进程用于管理子进程。master进程加一个子进程的内存耗用量加在一起大概在40M左右。
注:在一些评测里Gunicorn的性能并不是太好。Gunicorn支持多种 worker-class ,默认的worker-class使用的是同步模式。在将worker-class切换到gevent或tornado性能会好出不少。