preload
6 09

最近在使用Django开发一个小站点,初版要接近尾声了。由于初次使用,中间零零碎碎遇到不少问题,挑一些认为比较重要的问题。简单地总结一下。
1. 如何和前台人员配合?
项目中我负责后台和前台的javascript。另外一人写css代码,负责前台的显示。那么模板文件该如何维护,两人之间如何更好地配合,对此颇为伤神。这个主要涉及两个问题:
a. 谁负责维护模板文件?显然前台人员要参与进来。但我又要写js,有要保证有正确的数据扔到模板页面上。所以也同样需要不停地修改模板文件。所以,项目初期,不可避免都需要参与维护。这里我们的解决方案是:在svn上走两个版本,各自维护模板文件,然后每天去做一次归并。
b. 前台如何看到修改css后的效果?前台人员需要修改一点css代码,就可以立马看到效果,好进一步做不断地修正。如果手写填充,然后再有我根据填充的内容去替换成Django模板文件,这样出错的几率太大,最终又要返回给前台修改。针对这个我们采取的方法是:在前台人员的本机上也搭一个Django环境,和我的开发环境共用一个数据库。感谢Python的跨平台特性,让我很方便地在前台人员windows机器上也很顺畅地跑通程序。
2. 多读文档,细读文档
Django的文档还是蛮丰富的。几乎遇到的所有问题都可以从文档中得到解决。有时候就回过头来重读一下,就会发现对一些问题更好的解决方案,或者很细节但很重要的问题。试举几例:
a. 调用model的delete()方法,一定要多加注意。它会自动删除掉以该对象作为主键的其他关联对象。比如下面两组关系:


class  Article(model):
pass
class ArticlePicture(model):
article =  model.GenericForeignKey(Article)

删除掉article对象是,就会自动删除掉关联的ArticlePicture对象。
如果包含GenericRelation关系,则需要显示声明才能删除掉关联对象。比如:


class Article(model):
pass
comments = generic.GenericRelation(UserComment, object_id_field="object_pk")
class Comment:
content_type = models.ForeignKey(ContentType, verbose_name='content type')
object_pk    = models.PositiveIntegerField('object pk', db_index=True)
object       = generic.GenericForeignKey('content_type', 'object_pk')

body = models.TextField(max_length=COMMENT_MAX_LENGTH, verbose_name="评论内容")

对于这种,comments = generic.GenericRelation(UserComment, object_id_field=”object_pk”) 才叫显示声明。删除Article就会删除指向它的所有相关评论。一切都是如此地方便,不用多操心!
b. 模板中的for标签。for标签远不止一个循环那么简单。还提供了不少很贴心的功能。比如forloop.first ,它可能判定那个元素是这个序列中的第一个。这个有时候非常关键,比如我们要一个切tab的操作。我一开始是这么做的:


{% for item in items %}
{% if item.is_first %}
<div class="first">{{ item.something }}</div>
{% else %}
<div >{{ item.something }}</div>
{% endif %}
{%  endfor %}

我就必须在views函数中,将序列中第一个元素:
items[0].is_first = True
这样的操作。虽然python的动态特性,很方便地解决了这个问题,但整个代码显得非常丑陋。细读文档,发现有forloop.first,这样就简单,优雅多了,如下:


{% for item in items %}
{% if forloop.first %}
<div class="first">{{ item.something }}</div>
{% else %}
<div >{{ item.something }}</div>
{% endif %}
{%  endfor %}

所以,一定要没事多读文档!
3.  模块化,不光是程序,还包括模板。

Django的按照app和template天生就具备极强的模块化特性。整个结构看起来非常规整,有序。仔细划分项目的功能,将不同的app分化出来,app的共同部分还而已抽取出来。另外对于模板文件,应该分析整个页面元素的特性,尽量把不同的内容独立出来,然后用extend 和 include 继承和包含进来。这样便于以后的维护和扩展。因为重复=易错+难改。

Tagged with:
4 23

已然忘记第一次在什么地方看到这句话,反正一映入眼帘就给记住。嗯,这个从某种意义上要感谢小四同志的那句:左手年华右手倒影。

闲来无事在网上闲逛发现Bruce Eckel大牛(写Thinking in c++/ Java的家伙,能写如此畅销的技术书,我觉得算是牛人)的一篇新文章:Writing Software is Like … Writing。 探讨程序开发到底是个什么玩意儿。

文中指出,最初的Programmer大都是数学家或者工程师。貌似很自然地可以把程序开发类比于科学或者工程。但深究之,却发现他们异巨大。因为数学都是可计算,可论证,对错选其一而已,但程序却常常broken 掉。又如果说程序员就是一工程师,但我们却常常发现不同的程序员产生的结果差异巨大。而且软件工程的标准化是如此之难。所以,这两种类比显然都不太合适。

所以程序员既不是科学家,也不是工程师。这也可以解释程序之间,诸多项目中间,成功与失败,为什么有如此大的差异。那我们是什么呢?

作家,另外一种作家,这个称呼最符合我们。

大多数的人都很容易将词语组合成句子,而且不需要成为作家就可以毫无障碍地交流。君不见,博客大兴,几乎出现全民写作的盛况。而大多数程序员都能写些特定地,凑合能用用得程序出来。很多非专业的程序员,学个html语言,javascript写几个网页还是很简单的事情。

同是受过基本的文字训练,好的作家却能把大家所熟识的词语,组合起来,或行云流水,或妙笔生花,强大之处以致直指人心,千古流传。但大多数人的文字却是索然无味,枯燥干涩。而反观程序员,计算机大牛们能够用相同的程序语言写出更加简洁,优雅的代码或者更要好的工具出来。

二者的成长过程也非常类似。先接受基本的训练(不一定要走传统的教育模式,很多程序大牛均自学成才,正如很多作家走的是夜路数),然后不断地模仿,学习各家地所长,通过大量的训练,摸索出自己的风格和套路。最终,独步于江湖。所以,Programming仍然是相当具有创造性的一项劳动。

对于自己而言,人生之最大理想莫过于这句”左手程序,右手诗“。

Tagged with:
3 30

筹划设计一个站点已经很有一段时间,多次的争吵之后,终于开始进入最终的设计阶段。准备这次的设计稍微不太山寨,不是脑袋一拍,想到啥功能就直接上。希望能走版本控制,得有需求文档。需求文档咋写呢?我很愁。

excel是我第一个想到的工具,弄个总的功能表,再针对每个大功能进行细化。写上各种功能说明。但写了一个大提纲之后,就无法进行下去了。光有文字描述,过于空洞,每个图片,页面的大致布局,一点感觉都没有。估计,写完之后,连我都不想多看。

放弃excel之后,我转到visio,这可是个强大的玩意儿,我们前期的讨论一直基于由它画出来的图片而来。还学习了一篇专讲如何用visio设计网站的文档,但那个用起来太不顺手了,页面之间的链接和跳转极难组织。我只好又转向mindmanger。

mindmanger在长于思路的整理,还可以设定事情的完成度。一张图表下来,从可以全局观察,可以局部观察,整个非常清晰,比excel罗列的一大堆文字强多了。但几个topic下来,发现它实在是不适合网站的设计需求,粗粒度的组织还不错,但稍微详细点,就没法表达。

哎,我相当愁。只要借助于google,终于我发现了:Axure RP。啊,真是很强大,很专业的东东。

它是网站原型设计的定制工具。目前为止我觉得它最好用的功能数:

1. 强大的页面组织能力。通过链接和表单点击事件,把页面之间的关联和跳转自动维护起来。从一个页面很方便地点击进入另外一个页面。

2. 定制master。把一坨页面元素放在一起,生成一个自定义master,然后像普通的页面元素一样直接拖到其他页面上。比如:我定义一个sidebar页,然后所有的其他页面就可以直接用,不需要在一个个地绘制sidebar的样子。很强大的复用概念。非常符合现在web开发框架中模板设计的概念。这个设计好了,以后的模板设计,整个就可以更着走。

真的是非常好的工具,不敢独享,跟大家分享一下,使用之前,不妨先在这里,花上一个小时,看一个简单地教程,相信用起来更加事半功倍!

Tagged with:
3 16

Jquery之父在《精通Javascript》一书中,一再强调要写分离式的JavaScript代码,简单而言就是把页面上各种元素的事件相应之类的全部挪出来,放在单独的js文件中。这样的好处在于便于代码的维护和支持某些不支持js的浏览器。

分离式,很cool啊,我新近设计的站点中,就采用这种方法,整个页面看不到一个js事件。但导致的结果是,有些响应点击的地方,很容易失效。仔细分析问题所在,发现是页面显示解析成功之后,加载js事件时,耗时在秒级。所以,导致在页面刷新很快时,页面元素的事件还没有来得及加载上去,从而,点击失效。

最后,我又不得不把关键性的事件挪到页面上,整个页面虽然乱点,但只要页面显示出来,相应的事件肯定已经加载好,不会出现点击失效的情况。

看来完美的设计总是不存在的,我们总需要牺牲一些东西,权衡,然后折中。不过,听说新版本的jquery已经在dom选择器的速度上有很大改进,但怕存在兼容性问题,不敢轻易试用。

Tagged with:
3 07

37signals(http://www.37signals.com/)团队写了的一本名为《Getting Real》的书,专讲如何做web产品,不少地方很具有借鉴意义。

 

这两天读了一下,做了一个简单地笔记,原文可以见:http://gettingreal.37signals.com/GR_chn.php

 

37signals团队在这一波web2.0大潮中,名气响亮。开发了Ruby on Railsweb framwork,深受开发者的喜爱。而且基于Ruby on Rails

做了几个web产品,很受欢迎。

 

 

建构从简(2

·  做得要比竞争对手少少做的含义:

·  更少的功能

·  更少的选择项和首选项

·  更少的配备人员和企业架构

·  更少的会议和抽象讨论

·  更少的承诺

 

·  为自己而做这个软件(这点适合我啊,我有不少的需求)

·  准时地早预算范围内推出产品:定额定量,绝对不要在一个难题上多投时间和金钱。要么缩小规模,要么缩小范围

·  了解你的应用程序应该做成什么样子的最佳方式就是:认识到它不应该成为什么

·  不要跟在竞争对手后面跑。要创建一个不同的故事来说服听众,告诉他们你的故事比他们在其它地方听到的更重要。

·  只看大方向,时时提醒自己什么是我们想要解决的问题关键,怎样去解决它。

·  不应该成为一种交易,要保持激情,如果你做这个软件一点都不兴奋,那就什么地方出问题了。

保持精益(3)

·  做得越精益,改变越容易

·  让限制带领你到创新的解决方法

首要任务(4)

·  竭尽全力将你的软件定位在一个点上。保持简洁的理念,所有的行动都要在这个理念的指引之下。

·  组织需要指导原则。需要有一个纲要;员工每天醒来时应该要知道他们为什么而工作。这个纲要最好言简意赅,富有激情:为什么你会在这里?是什么激励了你?

·  不能过早地限于细节。细节是你在使用的过程中才会显露出来的。只有在使用中你才能看到什么需要进一步关注,在使用中你在感到缺了些什么。

·  当问题成为问题的时候才去担心。

·  要清楚地知道你的产品是为谁服务的,然后集中精力去讨好这部分人。

·  先把一个伟大的产品推出,然后才去担心它无比成功了以后改怎么办的问题。(大规模问题,遇到了在考虑)

·  伟大的软件必须要有自己的理想,必定是有倾向的。对于不认同你的理念的用户,可以舍弃掉。

挑选功能(5)

·  部分而不是残缺不全:摆出产品应该成为什么样字的任何点子,然后砍掉一半。

·  只留精髓,去掉无所谓的功能需求。

·  从说“不”开始: 不轻易实现功能; 不要成为yes-man;不要试图去讨好任何人

·  构建你有把握的产品和服务,不做能力之外的事情

·  为一般概念构建软件,并且鼓励人们创建自己的解决方案

·  对于客户的需求,say no Just read them and then throw them away(因为真正核心的需求客户会不断地提醒你,以至你无法忘却。)

·  询问客户他们不需要什么功能,而不是总问他们需要什么功能

·  Innvoations comes from saying no

We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.

Steve Jobs, CEO, Apple (from The Seed of Apple’s Innovation)

操作(6)

·  尽快地推出一个真实的产品

·  更快地推出一个积极的产品,而不是一味追求完美的产品。通过真实世界的反馈,来引导产品的发展。

·  Geting Real的过程:从灵感,到草稿,到HTML 到代码

·  少用设置选项,帮用户做出决定。有抱怨,再修改不迟。这样在减少用户负担的同时,也减少了开发成本。

·  快速决断,搞定之,不行,回头在修改之。

·  在使现实中测试你的软件。

·  任务尽量细化

组织(7)

·  整合团队。不要分离成独立的小单位

·  深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法的地方。

·  在工作中建立一条规定:一天中一半的时间作为独处的时间。Just shut up and get to work

·  会议有毒:通过emailIM来快速讨论。

·  会议原则:设定30分钟的计时器;邀请尽可能少的人;没有明确议程的时候不要开会

·  没事多发布点什么,以提高团队的积极性和成就感。

人员配备(8)

·  不要随便招人。

·  通过测试项目的协作来摸底候选员工

·  通过开源社区去寻找所需要的人(可惜,在中国很难)

·  选择能快速学习的多面手,而不是专攻一面的专家(我喜欢)

·  选择快乐和技术水平中等的,而不是令人不满的专家。(热情很重要)

·  招文字功底好的人。

界面先行(9)

·  开始编程之前先设计界面:编程是构建应用的过程中最笨重的部分,也是改动起来最复杂,成本最高的地方。

·  震中设计:先设计核心的内容,再向外拓展,比如:导航栏,页脚,用色,边栏,标识等。给用户一个更友好、重点清晰的界面

·  每个界面考虑三种情况:常规,初始,错误。缺一不可

·  忽略初始界面的节点是你会犯的最大错误之一。初始界面是第一印象,失败就完。

·  初始界面应该包括:

    * 利用它作为添加新手指南和热门推荐的机会。

    * 给出一个填满内容的页面截图,这样能让人们有所期待。

    * 讲解如何上手,页面最终会像什么样子等。

    * 回答第一次来的访客会问到的关键问题:这是什么页面?我在干什么?页面有内容的时候是什么样子?

    * 做好预期准备,帮助减少挫折感、恐惧感和大的迷惑。

·  必须做好保护性设计。

·  细节的一致性没有必要。重要的是It depends

·  好的文案工作也是设计的重要部分

·  整体界面保持一致

代码(10)

·  保持代码的简单

·  幸福最大化

·  Listen when your code pushes back

·  开放接口:Get data out into the world via RSSAPIs etc

 

 

文字(11)

·  功能定义一点用都没有,坚决抵制功能文档

·  Dont Do Dead Documents

·  Tell Me a Quick Story

·  Use Real Words

·  个性化你的产品

结论(16)

·  执行力: 成功仅在于优秀的执行力

·  人:有工作热忱的人

Tagged with:
3 07

我发现自己在寻找学习资料方面真是非常擅长,到处逛悠逛悠,就能发现不少好东东。最近在调研和学习Django,把主站上的文档大致看了一下, Django Book也挑重点看来一些,另外还有一本Practical Django Projects的电子书(技术电子书,建议去http://download.csdn.net 上去找,一般都能找到。群众的力量是强大的)也看了大部分。觉得还是不过瘾,无意间竟然发现了Pinax。

Pinax,基于Django之上给出许多社区开发元素,比如:tag,blog,friends,twitter clone,group,bookmark,wiki等。非常丰富,全面。去官方站点下载一个源码包下来,根据说明文档,修改一下配置,几条命令就可以搭建出一个功能全面的社区来。虽然是丑陋了一点。但功能太齐全了。另外,不想搭建想体验一下效果不然看看一小伙儿把它中文化的站点:pinaxcn

可惜的是文档少了一点,只有深入源码。熟悉Django的很多Conversion,看看具体它的设计中,如何把一个社区元素给独立划分成单独的引用,又如何拼接起来。还有一些Django的高级引用。如自定义Field, Template tags,  Signals是如何用的,等等,都大有裨益。

Django自动化和复用方面做得非常好,换来的代价是需要很好地熟悉里面的Conversion,了解很多tricky的地方,这样才能发挥它的最大效能。

嗯,现在还只停留在学习的阶段,等实际搭建出一个站点之后再来谈谈具体的感受。

Tagged with:
2 20

新的项目估计要用上memcached,老早听说它就大致对mysql的数据做内存备份,可以加快数据的访问速度,提高网站的影响速度。这次算比较深入地做了一番了解。

首先·把其官方首页,浏览一遍,大致知道它是什么东西。简单而已,就是把缓存的数据按照key,value做了一个大的hash表。然后定义了一套很方便的数据访问协议。有server和client之分。server负责缓存数据,接受client的请求。而且,支持分布式。

分布式,我每次听到这个名字都觉得异常高深。头脑就会冒出:分布式,N台机器,调度,协调,map/reduce,等一堆词,最后归结于一个词:复杂。但Memcached的分布式之简单,大出意料。我们看图说话:


上图中的node1,node2,node3就是server端,中间有一个客户端程序库的中间层,应用程序直接通过客户端程序库来访问server端的数据。其分布式就在于服务器列表那里。一个查询key过来,根据key,分配到对应的服务器列表中的某个服务器端node(i),然后跟node(i)通信,获取相应的数据。

简而言之,将不同的key映射到不同的服务节点上存储,服务节点本身不通信。真是非常简单明了。我觉得这样的好处在于,保证服务端设计的简单。只是建立hash,影响简单地key的建立,查询,更新请求。这样的可扩展性很强。缓存不够,加几台机器,加内存就OK,服务端没有任何新的负担。服务端只需要保证查询的高效和稳定。由于不需要全局的调度服务, 因而也不会有单点失效的问题。但这样就把分布式的任务转移到客户端,只需要客户端做一个key到服务节点的映射。

你看,整个设计是不是相当之简单?但正式这么简单地一个设计,Memcached大行其道,被很多站点所采用。facebook在一篇文章中,还重点讨论了很多关于如何优化它的好文,见这里,中文翻译见这里,总结可以见这里。而且可以看到facebook用Memcached在800台机器上,做了整整28T的缓存,那可是28T的内存数据,真的很夸张!所以,设计和运营这种大型的网站真是一件非常有挑战和有意思的工作。

哦,对了,本文中的图来自于文档《memcached全面剖析》,此文相当不错,把Memcached的方方面面讲述得很清晰,是运营日本的mixi站点的技术人员所写。日本人做事之细致和专注还是很值得我们学习的。

Tagged with:
2 15

但凡以技艺混饭吃,必有上下、高低之分。如此区别待之,倒不是社会不公平现象,而是发展使然。因为唯有此次,才能使在下者,有奋斗之目标,在上者则有危机之感,各自不断奋发向前,促进社会整体地发展。

程序员十层楼:

程序员的十层楼(1~3层)

程序员的十层楼(4~5层)
程序员的十层楼(6~7层)
程序员的十层楼(8~9层)
程序员的十层楼 10层(上)
程序员的十层楼 10层(下)
程序员的十层楼 11层(上帝)

就是一系列论述程序员技艺高低之文。虽然文中的分类有诸多不妥之处,往上区分,已然超出程序界,至纯科学,哲学的范畴。但从中也可以循迹到自己身在 何处,也可估量一下,以自身的精力和才情可以发展至那层,以此明晰奋斗目标。而且文中诸多程序界的8g、趣闻,读来也是盎然有趣。故推荐之。

Tagged with:
12 31

Lucene真的是一个很强大的东东。把索引和检索这么复杂的处理,抽象出来,包装成一个库,提供几个简单地接口就可以搞定很多事情。其接口的简洁和优雅,非常值得我们去学习。

相对于其他的开源库,Lucene的各种开发文档,还算比较丰富。《Lucene in Action》(其中文版,我查阅各大书店都没找到,看来买的很火爆)这本书上面也把各种示例讲的比较详细。但要想用好,仍然不是件容易的事情。有许多tricky的地方。需要针对自己的需求,采取一些优化的手段。这样就不得不读这两篇文章:
ImproveIndexingSpeed
ImproveSearchingSpeed

就在Lucene官方站点的wiki里面找到的。嗯,谨记!一定要多读官方文档。在网上搜寻各种优化策略,大致脱离不来这两篇文章中总结的几个要点。我对其中“在搜索中多用filter”体会颇深。

在我的搜素第一跑起来时,那个慢啊,搜索一个结果比较多的内容,需要2秒左右,非常吓人。经分析和测试在知道,时间都耗费在我的Collector器中的collect(id, score)中。因为我在其中做了很多通过id获取文档内容,在根据其中字段的值来过滤id的操作。这样导致每。获取一个id,就需要去获取整个文档的内容,然后取出某个域的内容来做过滤逻辑。如果搜索词有上万的结果的话,这个操作就非常吓人。而把这些过滤利用filter来做,速度一下子就上来了,每个查询就在几毫秒级。虽然好像还是不够理想,但暂时已经足够用了。进一步的优化可以放在后面来做。

另外很都时候需要搜索数据库的很多个字段,这样每个字段去建立一个域,然后去每个字段搜素一遍,也是很不靠谱的事情。第二篇中就清晰地指出:多域查找,在建立索引的时候放在一起,而且存储属性设置为不存储。这样既可以提高搜索效率,又对索引的大小没影响。非常好使。

Tagged with:
12 31

Apache做为功能强大的web服务器,经常把用来作为前端服务器,服务的处理逻辑通过module传递给后台的服务。大致这样一个结构:
 client <—-> Apache<—>Module<—>Server
这样做的好处在于:
1. 服务器省掉负责的并发处理环节,把这些交给久经考验的Apache。
2. 服务走标准的http协议,扩展能力强,便于分布式处理。而且服务不容易不防火墙、杀毒软件之类的封掉。部署和配置起来也很方便。便利多多啊
3. 把连接和处理逻辑分离开。保持各自的简单性。

ApacheModule的开发就属于中间比较重要的环节了。把一个东西,插入Apache中,来处理请求。听起来有点复杂,高深的样子,不过做上两个module就明白不是什么艰难的事情。说白了,就是要弄清楚Apache的工作模式和处理请求的链,然后把自己的module插入到某一个处理环节之中。可以见《The.Apache.Modules.Book.2007》,讲的比较详细。另外在写module的时候,Apache就是你的工作平台,需要熟悉它的内存分配,IO处理、日志处理、读取配置之类的东西。这方面最让人郁闷的就是没有详细的文档,不像jdk或者python的文档那样分类详细,具体。不明白只有看源码,看示例。它自带的几个示例还是很有得看的。

当然了,非常重要的一点是需要知道http协议,至少有一个大致了解。http请求头,回复格式, cache控制之类的。

嗯,大致这么多,一些泛泛而谈的东西,希望对你有所帮助。

Tagged with:
登录