GCC 的基本使用

GCC 是一款非常著名的编译器，支持诸如 C, C++, Java在内的多种程序设计语言，并且提供了许多选项，以支持用户不同程度的需求，例如查看编译中间结果，指定语言标准，指定优化程度等等 ，下面的内容就介绍这些最重要的功能。

不要做无谓的坚持和幻想的努力

有时候，你觉得自己一直在坚持和努力，可是从没问问自己这样的坚持和努力有用吗？

其实你就是一只温水里的青蛙，还觉得自己一直都在坚持游泳呢。

最近我有了一个非常明确和重要的启发，就是不要做无谓的坚持和幻想的努力。

我在一个背单词的网站上背了471天单词，不长，不短，再坚持下去我也完全没有问题。但是，这真的就叫坚持，就叫努力吗？

读 《MacTalk 人生元编程》

今天看了一本书，叫《MacTalk 人生元编程》，讲述了Mac，编程，科技与人文还有职场等内容，书是在作者的微信公众号基础上写成的，挺有趣的，感兴趣的可以买来看看。

我记得小时候不管是读书，看电影，还是春游，老师都要求写读后感，当时的感觉已经忘了，不过小孩子谁愿意写这种玩意？而现在看着书就不断地会有感慨，这就叫有感而发吧。

先说读书

从书中可以明显看出，作者虽然是一个70后的老程序员，但是是非常喜欢读书的。我是非常喜欢热爱读书的人的，阅读量大的人明显与其它人拉开一个档次，无论是知识面还是对事物的看法。我这么多年没什么悔恨的事，唯一有一点悔恨的事就是年少的时候没有意识到读书的重要性。

读一本书给我一种什么感觉呢？

使用 GitHub, Jekyll 打造自己的独立博客

GitHub是一个代码托管网站，现在很多开源项目都放在GitHub上。 利用GitHub，可以让全球各地的程序员们一起协作开发。GitHub 提供了一种功能，叫 GitHub Pages, 利用这个功能，我 们可以为项目建立网站，当然，这也意味着我们可以通过 GitHub Pages 建立自己的网站。

Jekyll是一个简单的，针对博客设计的静态网站生成器。使用 GitHub 和 Jekyll，我们可以打造自己的独立博客，你可以自由地定制网站的风格，并且这 一切都是免费的。

这是我在GitHub上自己建立的博客 及源代码 （两个分支），在下文的讲解中，你可以随时查看博客的源代码，以便有直观的认识。

网站截图：

#WSGI 简介

背景

Python Web 开发中，服务端程序可以分为两个部分，一是服务器程序，二是应用程序。前者负责把客户端请求接收，整理，后者负责具体的逻辑处理。为了方便应用程序的开发，我们把常用的功能封装起来，成为各种Web开发框架，例如 Django, Flask, Tornado。不同的框架有不同的开发方式，但是无论如何，开发出的应用程序都要和服务器程序配合，才能为用户提供服务。这样，服务器程序就需要为不同的框架提供不同的支持。这样混乱的局面无论对于服务器还是框架，都是不好的。对服务器来说，需要支持各种不同框架，对框架来说，只有支持它的服务器才能被开发出的应用使用。

这时候，标准化就变得尤为重要。我们可以设立一个标准，只要服务器程序支持这个标准，框架也支持这个标准，那么他们就可以配合使用。一旦标准确定，双方各自实现。这样，服务器可以支持更多支持标准的框架，框架也可以使用更多支持标准的服务器。

Python Web开发中，这个标准就是 The Web Server Gateway Interface, 即 WSGI. 这个标准在PEP 333中描述，后来，为了支持 Python 3.x, 并且修正一些问题，新的版本在PEP 3333中描述。

WSGI 是什么

WSGI 是服务器程序与应用程序的一个约定，它规定了双方各自需要实现什么接口，提供什么功能，以便二者能够配合使用。

WSGI 不能规定的太复杂，否则对已有的服务器来说，实现起来会困难，不利于WSGI的普及。同时WSGI也不能规定的太多，例如cookie处理就没有在WSGI中规定，这是为了给框架最大的灵活性。要知道WSGI最终的目的是为了方便服务器与应用程序配合使用，而不是成为一个Web框架的标准。

另一方面，WSGI需要使得middleware（是中间件么？）易于实现。middleware处于服务器程序与应用程序之间，对服务器程序来说，它相当于应用程序，对应用程序来说，它相当于服务器程序。这样，对用户请求的处理，可以变成多个 middleware 叠加在一起，每个middleware实现不同的功能。请求从服务器来的时候，依次通过middleware，响应从应用程序返回的时候，反向通过层层middleware。我们可以方便地添加，替换middleware，以便对用户请求作出不同的处理。

wsgiref 源代码分析

wsgiref

wsgiref 是Python标准库给出的 WSGI 的参考实现。

WSGI是Python Web 开发中为服务器程序和应用程序设定的标准，满足这一标准的服务器程序和应用程序可以配合使用。我在上一篇博文《WSGI简介》中对此有详细的介绍。在阅读wsgiref源代码之前，一定要对WSGI有一定了解。

WSGI 在 PEP 333 中描述，但是只靠阅读PEP 333 可能在理解上还是不够深入，所以阅读官方给出的参考实现是很有必要的。阅读完这份源代码后，不仅有利于对WSGI的理解。而且会让你对服务端程序如何对客户端请求有一个直观的理解，从相对底层的socket监听请求，到上层对HTTP请求的处理。

当然，这只是对WSGI的参考实现，目的是为了描述清楚WSGI，而不是真正用在产品中。如果想对Python Web开发中服务器端的实现有更广泛，更深入的理解，需要进一步阅读Python常用框架的源代码。

wsgiref 源代码分析

wsgiref 源代码可以在 pypi wsgiref 0.1.2 下载。另外，我在阅读的过程中作了大量注释，包含模块介绍，调用层次关系，demo的运行结果，等 等，还包含了阅读过程中制作的思维导图。GitHub地址注释版wsgiref。

结构

上图描述了wsgiref的所有模块及模块间的调用关系，可以看出，wsgiref有以下模块：

• simple_server
  这一模块实现了一个简单的 HTTP 服务器，并给出了一个简单的 demo，运行：

    python simple_server.py
  

会启动这个demo，运行一次请求，并把这次请求中涉及到的环境变量在浏览器中显示出来。

• handlers
  simple_server模块将HTTP服务器分成了 Server 部分和Handler部分，前者负责接收请求，后者负责具体的处理， 其中Handler部分主要在handlers中实现。
• headers
  这一模块主要是为HTTP协议中header部分建立数据结构。
• util
  这一模块包含了一些工具函数，主要用于对环境变量，URL的处理。
• validate
  这一模块提供了一个验证工具，可以用于验证你的实现是否符合WSGI标准。

simple_server

如何编写高质量的程序

学习任何编程语言都会有一个基本的过程，开始的时候学习基本的语法，然后学习各种库，框架，开始做各种项目。在做项目的过程中，随着代码量的增加，我们会渐渐感到失去对程序的掌控能力，bug开始增加，牵一发而动全身，顾此失彼。这充分说明了编写高质量程序的重要性，这里的“高质量”主要指程序的正确性，可读性，可维护性。

什么是高质量的程序

正确性

程序正确性的重要程度无需多言，尤其在一些特殊领域，例如芯片制造业，航天业，武器制造业，对程序正确性往往有着极其严格的要求，因为一旦程序出错，代价往往是巨大的。在这些领域，需要使用形式化方法(formal methods)来自动验证程序的正确性，也就是说你需要证明程序的正确性，而不仅仅保证程序在大多数情况下是正确的。在其它领域，对正确性没有这么高要求，形式化方法也不适用，但是我们还是需要使用其它手段，例如测试，code review等等来保证软件的正确性。

可读性

可读性可以帮助程序作者理清思路，思路清晰后，程序不容易出错。另外，其它程序员在维护你的代码时，更容易理解你的意思，方便修改bug，方便扩展。

不要浪费自己的时间，更不要浪费别人的时间。

可维护性

这里的可维护性主要指程序应对变化的能力。程序在完成基本功能后，可能会发生各种改变：用户需求变了，性能达不到要求需要重新实现算法，等等。一旦程序的一个点发生改变，其它点如果也需要同时手动改变，那么程序会变的不可控制，出bug的机会会增加。想像一下，我们的程序是一个盒子，在添加新功能时，如果只需要把新模块插到一个地方，新模块就可以被系统使用，这样的程序可维护性是很高的。但是如果添加新功能时，需要把原来的程序盒子拆开，其它模块也需要相应修改，才能加入新模块，这样的程序可维护性就很差。

web.py 项目之 googlemodules

项目说明

项目来自 webpy.org, 这是一个真实的在线上运行的 项目: Google Modules, 可以上传，下载， 一些模块，还有一些评分，打标签等等功能。(不过这网站挺奇怪的。。。)

目录树

src/
    ├── application.py
    ├── forum.py
    ├── config_example.py
    ├── INSTALL
    ├── LICENCE
    ├── app
    │   ├── controllers
    │   ├── helpers
    │   ├── models
    │   └── views
    ├── app_forum
    │   ├── controllers
    │   ├── models
    │   └── views
    ├── data
    ├── public
    │   ├── css
    │   ├── img
    │   │   └── star
    │   ├── js
    │   └── rss
    ├── scripts
    └── sql

18 directories

终于遇到个稍微大一点的项目了，要好好看看。

从目录上看，整个项目分成两个部分，app 和 app_forum,每个部分都使用了 典型的MVC结构，将app分成 controllers, models, views 三大部分。

另外，网站使用的 css, js 文件，图片，也都统一放在了public目录下。

INSTALL 文件描述了如何安装部署项目, 包括在哪里下载项目，哪里下载web.py，如何 配置 lighttpd, 如何配置项目。

config_example.py 文件给了一个配置文件模板，按自己的需要修改其中内容，最后 把文件名改为 config.py 就可以了，其中包括对数据的配置，调试，缓存的开启等等。

LICENCE 文件描述了项目使用的开源协议: GPLv3。

项目使用的脚本放在scripts目录下，创建数据库使用的文件放在了sql目录下。

代码统计

先看看代码统计

application 模块

application.py

#!/usr/bin/env python
# Author: Alex Ksikes 

# TODO: 
# - setup SPF for sendmail and 
# - emailerrors should be sent from same domain
# - clean up schema.sql
# - because of a bug in webpy unicode search fails (see models/sql_search.py)

import web
import config
import app.controllers

from app.helpers import custom_error

import forum

urls = (        
    # front page
    '/',                                    'app.controllers.base.index',
    '/page/([0-9]+)/',                      'app.controllers.base.list',
    
    # view, add a comment, vote
    '/module/([0-9]+)/',                    'app.controllers.module.show',
    '/module/([0-9]+)/comment/',            'app.controllers.module.comment',
    '/module/([0-9]+)/vote/',               'app.controllers.module.vote',
    
    # submit a module
    '/submit/',                             'app.controllers.submit.submit',
    
    # view author page
    '/author/(.*?)/',                       'app.controllers.author.show',      
    
    # search browse by tag name
    '/search/',                             'app.controllers.search.search',    
    '/tag/(.*?)/',                          'app.controllers.search.list_by_tag',
    
    # view tag clouds
    '/tags/',                               'app.controllers.cloud.tag_cloud',
    '/authors/',                            'app.controllers.cloud.author_cloud',
    
    # table modules
    '/modules/(?:by-(.*?)/)?([0-9]+)?/?',   'app.controllers.all_modules.list_by',
    
    # static pages
    '/feedback/',                           'app.controllers.feedback.send',
    '/about/',                              'app.controllers.base.about',
    '/help/',                               'app.controllers.base.help',
    
    # let lighttpd handle in production
    '/(?:css|img|js|rss)/.+',               'app.controllers.public.public',
    
    # canonicalize /urls to /urls/
    '/(.*[^/])',                            'app.controllers.public.redirect',

    # mini forum app
    '/forum',                               forum.app,    

    '/hello/(.*)',                            'hello',
    
    # site admin app
#    '/admin',                              admin.app,    
)

app = web.application(urls, globals())
custom_error.add(app)

if __name__ == "__main__":
    app.run()

可以看出，这是 application 部分的入口，这个模块仅仅是定义了各个请求的处理方式， 并完成程序的启动，所有的实现均不在这里出现，而是通过 import 导入，特别需要 注意 urls 最后定义的 /forum 和 /admin 使用了子程序，而不是通过之前的字符串 实现映射。还需要注意对静态文件,即css,js,img,rss文件的单独处理。

所有这些都与之前分析过的那些小项目不同，回想起我之前写的 BlogSystem, 所有的处理实现都放在 同一个文件中，导致最后一个文件居然 700多行，真是让人潸然泪下。。。 而且之前也不知道使用子程序，所有处理都堆在一起。看来读完这份源代码，真应该重构一 下了。

app 模块

app/
    ├── models # 数据模块，MVC中的 M
    ├── views # 显示模块，MVC中的 V
    ├── controllers # 控制模块，MVC中的 C
    └── helpers # 辅助模块，实现辅助功能

4 directories

controllers 模块

controllers/
    ├── base.py         # 对基本页面，如网站主页,关于网页，帮助等的处理
    ├── all_modules.py  # 显示全部模块
    ├── module.py       # 对模块页面的处理
    ├── search.py       # 对搜索模块功能处理
    ├── submit.py       # 对提交模块的处理
    ├── author.py       # 查看模块作者信息
    ├── cloud.py        # 对标签云页面进行处理
    ├── feedback.py     # 处理反馈信息
    └── public.py       # 对静态文件的处理

这个模块主要是对请求处理的实现，在 urls 里定义的那些映射关系， 很多被映射到这里。

实现过程中，调用 models 模块对数据操作，再送入 views 模块通过模板引擎显示数据内容。

models 模块

models/
    ├── comments.py     # 对评论数据的处理
    ├── modules.py      # 对模块数据的处理
    ├── rss.py          # 对 rss 订阅的处理
    ├── sql_search.py   # 对搜索的数据处理
    ├── submission.py   # 对用户提交内容的处理
    ├── tags.py         # 对标签内容的数据处理
    └── votes.py        # 对用户投票的数据处理

这个模块直接调用 web.py 的db模块对数据库进行操作，对数据库的连接在 config.py 中 已经完成。这里完成数据的获取，处理，返回。可以看出，对不同种类的数据又分成了 很多小的模块。

web.py 项目之 blog

目录树

src/
├── blog.py
├── model.py
├── schema.sql
└── templates
    ├── base.html
    ├── edit.html
    ├── index.html
    ├── new.html
    └── view.html

1 directory, 8 files

项目说明

项目来自 webpy.org, 主要实现一个基于web的博客系统，实现了基本的增删查改。

结构分析

控制模块

控制模块包括 blog.py

```python “”” Basic blog using webpy 0.3 “”” import web import model

Url mappings

urls = ( ‘/’, ‘Index’, ‘/view/(\d+)’, ‘View’, ‘/new’, ‘New’, ‘/delete/(\d+)’, ‘Delete’, ‘/edit/(\d+)’, ‘Edit’, )

web.py 项目之 todolist

目录树

.
└── src
    ├── model.py
    ├── schema.sql
    ├── templates
    │   ├── base.html
    │   └── index.html
    ├── todo.py

2 directories, 8 files

项目说明

项目来自 webpy.org, 主要实现一个基于web的 todolist，就是可以添加删除一些任务。 非常简单

结构分析

控制模块

控制模块只有todo.py

```python

””” Basic todo list using webpy 0.3 “”” import web import model

Url mappings

urls = ( ‘/’, ‘Index’, ‘/del/(\d+)’, ‘Delete’ )