由自

待过几天为域名交了费, 就会取消动态主机的服务.

一些有用的文章可能会贴出来. 静态空间可能反而会搞的很简洁. 现在看来用xml+xslt+css的方案也许还不错. 不过各位需要RSS的, 估计就要等我研究了RSS的格式之后再才有了.

惟一的问题是还不知道什么地方的静态主机比较好用.

在每年一次交费的时候，我决定要关闭本博克了。

一位同学说，他很闷骚的时候才会很想写博克。想想自己两年前开始写这个博克的时候，的确是闷骚的。

今天看完的小说中有一段话，如下：
一位背负着沉重行囊的老者走下山，被一位寻求悟道的人看见，认为这位老者就是他要找的人。所以跑上前去，问道，老者请问悟道是什么？老者微笑的放下行囊，站直身子。这人看见了，大喜。“谢谢！”他叫到。那么悟道之后呢？老者微笑着又背上了行囊。

一切都变了，一切又都没有变。

- - - - - - - - - - - -
博克关闭之后，域名也许还会保留，也许会启用angke.info。

不过不知道还会不会再租用单独的主机。因为不再需要动态的页面。只会放一些于别人有用的信息，作为网络上的一处服务地点。虽然小，也许对过客有用。而想到网路不是路，从来就没有无心过客，只有顺着链接爬的网虫，那么这处服务，也就是放在孤岛之一处吧。

就快要看完Dreaming in Code了, 在书的最后, 作者终于进入了理论的层次, 讨论先前各种问题, 比如工期无限延长的原因.

作者也是引用业界大牛的话, 问题看起来是这样的:

我们在用写Hello World程序的基本思路在写大型程序.

程序的每一个部分之间紧密连接, 遵从一些预先设定的输入输出格式(协议). 部件越多, 规范就越复杂, 忘记规范而出错的可能性就越大.

所以一些人说程序的各个部件之间应该有更松散的结合和对错误的检查. 各个部件之间的联系应该就像人和程序界面的联系一样. 虽然这样多余的错误检查会消耗额外的计算资源, 但是考虑到计算能力的持续增长, 也就无所谓了.

最近觉得心里比较嘈杂, 乱翻翻的没有秩序, 所以就又开始看万能钥匙系统. 对其中一点有些感触.

这一点是: “不要关注负面的东西”.

根据作者的引力法则, 关注负面的东西会让负面的东西越来越多, 最终一叶障目, 不见泰山. ‘关注’ 的意思不只是同意或者肯定, 即使是否定的关注, 也是关注.

作者举的一个例子, 大致是那些嫉俗的人, 他们厌恶社会阴暗面, 却因此被这些阴影所困. 想想看性手枪, 鲁迅 …, 而一些人则关注阳光的一面, 他们最终能够得以创造. 想想看甘地, RMS等人. RMS和一些单纯的微软/专有反对者不同的地方在于, 他更多的是去建设GNU而不是骂专有.

正如所有事情都可以通过不同的观点来看待, 为什么不用一种快乐而有建设性的观点来处理呢?

所以, 今后生活的一些小改动:
1. 不再看cnBeta的新闻. (GNU下的3D可以复制自己的打印机 CB有报道么?)
2. 挑选积极的小说看
3. 监视自己的思维模式, 去掉消极的方式. 比如针对积极想法的讽刺.

http://cnbeta.com/articles/52864.htm

I’ve been working on extending Django’s User class for a while, trying to take advantage of the built-in authentication functions while having the freedom of defining my own class fields. It turned out that Django doesnt support subclassing for the it Models, and a popular solution I found that bypasses this issue(somehow) is to use a ForeignKey(unique = True) in the class definition. (read: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/, to get a general idea of how to bypass the issue exactly)

For example, an Employee class extending the User class will probably look like this:

from django.contrib.auth.models import User
from django.db import models

Class Employee(models.Model):
  user = models.ForeignKey(User, unique = True) #the workaround described above
  EmployeeId = models.IntegerField()

However, using the above method doesnt make the class interface as pretty as a subclass: Using the statement employeeObj = Employee() to create an Employee object wont create a counter part User object for you, which is essential if one wanted to create an employee object using the natural Employee() way. Also, Employee.objects.get(id = 2) will fail too. This is far from pretty, we gotta override a few methods to make the Employee Class to be more aware of its parent class: User.

1.1 Overriding the __init__ method to create a User class
To create a User class the moment we create a Employee class, we need to override the Employee’s __init__. Note that to create a User class, you need to specify a unique username.

def __init__(self, *args, **kwargs):
    if (kwargs):
      if (kwargs['username']):
        userObj = User(username = kwargs['username'])
        userObj.save()
        kwargs.pop('username')
        super(Student, self).__init__(user_id = userObj.id, *args, **kwargs)
      else:
        raise ValueError, "have to use username to initiate an Employee method"
    else:
      super(Student, self).__init__(*args, **kwargs)

Look at the first if…else. I used if(kwargs) to test if Django is trying to create a new object, or merely try to re-create projects from the retrieved value from its database. The latter typically happens when Django is answering a query such as objects.all(). If kwargs is empty, this modified __init__ calls the original __init__ to recreate objects. One plus point: Django seems to be able to recreate the User object according to the values from database, so there’s no need to create them yourself and then attach it to employeeObj.user

After overriding Employee’s __init__, you can do this now:

e = Employee(username = 'angke')
e.user.first_name = 'angke' #this is stored in the auth_user table comes with the class User
e.user.last_name = 'chen' #this is stored in the auth_user table comes with the class User

Isn’t it cool?

Sadly however, a django-style lookup like this:

e = Employee.objects.get(username = 'angke')

will lead to error because django only try to look at the username field within the Employee class, while this field actually lives in the User class. This involves overriding the object: objects, which is an object of class django.db.models.manager.Manager. It will be covered in the next section.

1.2 Fixing Employee.objects.get() lookup
Darn, it’s already 2:11AM in chengdu and I have to work on my Archaeology undergraduate thesis before my mentor kicks my butt. I will update this section soon. Hope you find the previous section helpful.

Anyways I’ll post the code I end up using for fixing the lookup:

So you define a separate class outside of Employee:

class objectsClass(models.manager.Manager):
  def get(self, *args, **kwargs):
        userObj = User.objects.get_query_set().get(*args, **kwargs)
  return userObj.student_set.all()[0]

and then you add this line in the Employee class definition:

objects = objectsClass()

and then you’re fixed!

only works for objects.get() though. objects.all() magically works even before this fix. someone has a nice dispatcher to make all the search functions working?