Tairan's Story

定制软件开发中陷阱重重，主要的原因是客户对自己的需求不清楚。很奇怪吧？ 客户竟然对自己想要什么东西说不清楚。事实上，在软件开发领域这是常有的事情。软件这玩意抽象，看得见摸不着，甚至看都看不见。让对技术一无所知的人来描述自己想要什么样的软件，太困难了。 这样的事实对乐天派的程序员来讲就是一个噩梦，这里引用西乔姐在 Twitter 上发表的一段话：

@arthur369: 千万不要相信那些在谈需求的时候说：“做一个和XX一样的就行了” 的人。其实这种人最好就不要和他一起做事。因为最后结果只有2种，1、你白做了（需求一定会变动数次）；2、做出来一个垃圾。”

最近我就接到一个这样的项目，刚开始的版本是对照着某软件的前一个发行版做，然后又变成了要具有此软件当前版本的某些功能，最后又发现客户的客户已经有一个类似的软件，于是乎又开始向模仿此软件+改进的方向前进，漫漫长路多折腾，如此多的波折才算拿到最终的需求。真正的需求拿到了开始加班加点的做了，可麻烦的事情还有。

这是一个远程的项目，我在南边，客户在北面, 还好在同一个国家，都说中国话。沟通的次数那叫一个寒碜，三、五天都不一定能接上头，接头的方式基本是邮件和IM，电联不多，软件本身的开发经费就不高，如果直接电联估计都支援给中国移动了。

在项目进行中第一次改变需求的时候，我是做好了心理准备的，毕竟那么多前辈的经验摆在那里。此时我在想借由着自己快速迭代，不断的改进软件原型来拿到真正的需求，理论上这种方式是可行的，总会拿到最终的需求，然后做下去就是了。可现实是残酷的，没有充足的时间，即使你承接项目不要多少钱，客户那边随着时间的流逝也会损失很多本该赚到的利润，咱都是凡人，耗不起呐。

和此类不甚明白软件开发的客户打交道还有个问题，软件里面的实现似乎并那么重要，漂亮好用的UI才是让他们看起来软件是如此美妙的东西。作为独立工作的程序员，大多对外在美没有多少的品味，黑客们更是喜欢默默无闻、稳定可靠后台运行的程序。缺少在美的层次上的交流，后端代码交流更是一团糟，客户说在这里加个东西然后这样动，你后端的东西写的不好则会伤筋动骨。

总之，定制软件开发的项目成本很高，劳神费力不讨好。因为程序员不但要保证有一个很快的开发速度来适应软件的变化，同时也要担负起教育客户的重任，还要培养出对美欣赏的品味。通常此类软件开发过程中得到的物质报酬不多，好处是对于软件开发的新手来讲，通过那么几次定制软件开发的折腾可以快速成长，怎么说也能成为一个快速山寨的熟手。如果你是一个拿着不错的薪水的在职人员，我看还是算了，与其浪费如此之多的精力和少的可怜的报酬，还不如好好钻研自己本身工作上的业务，或者干脆多陪陪身边的人吧。

Update
现在Adobe已经提供正式版本下载 http://get.adobe.com/flashplayer/

INSTALL

#!/usr/bin/env bash
 
FLASH=http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_2_p3_64bit_linux_111710.tar.gz
 
cd /tmp
wget -c $FLASH
tar zxf flashplayer10_2_p3_64bit_linux_111710.tar.gz
 
# apply plugins for firefox
cp libflashplayer.so /usr/lib64/mozilla/plugins/libflashplayer.so
 
# remove cache
rm -rf libflashplayer.so
rm -rf flashplayer10_2_p3_64bit_linux_111710.tar.gz

UNINSTALL

rm -rf /usr/lib64/mozilla/plugins/libflashplayer.so

EC2 Nginx PHP FastCGI MySQL WordPress

关于 Amazon EC2 的教程已经铺天盖地了，有英文也有中文。现在EC2对新注册的用户有优惠，及Micro Instance级别的会有1年的免费份额。注意只是对新注册用户，如果你已经注册了 AWS 账户，即使并没有开通任何服务也不属于新注册用户，意思就是只要你使用就没有免费的。这一点我是用了$2美金的账单换来的教训。网上也有其他同学遇到，看来不仔细阅读文档就是没文化的代表。这里是账单查询地址https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=activity-summary 一旦发现产生莫名其妙的费用，赶紧查。

我这次使用 Amazon EC2 的目的是把即将到期的博客迁移到这里，并且让手中的一些闲置域名也利用起来。其中还有一个更重要的目的就是为部署一个很重要的网站，基于Django的。

首先要做的是迁移博客。
进入 EC2 后需要安装一些软件，因为Micro Instance只能使用Amazon Linux(redhat系)，所以包管理器使用的是yum。

sudo yum install mysql mysql-libs mysql-server php php-mysql spawn-fcgi nginx

启动MySQL后，并更改root用户的密码

sudo service mysqld start
/usr/bin/mysqladmin -u root -p -h localhost password 'newpassword'

配置 Nginx， 在这里我遇到了一些问题，折腾了一天才搞定。这里要十分的感谢网友 hfw_1984 的帮助。遇到的问题主要集中在fastcgi部分，如果要让Nginx支持我博客的URL格式如http://www.tairan.net/index.php/2011/03/30/follow-the-right-way/ 则必须参照以下配置：

    location ~ ^.+\.php {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;  # 这一行必须放在 SCRIPT_FILENAME 上面，否则会被覆盖。
        fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        #fastcgi_param   PATH_INFO   $fastcgi_path_info; # 这两行并不需要
        #fastcgi_param   PATH_TRANSLATED $document_root$fastcgi_path_info;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
    }

Micro Instance 默认提供的Nginx Version: 0.8.53

以上就是这两天的战果，还有其他的一些东西已经被写成自动化脚本，为方便备份数据，再次迁移、部署提供方便。

总的来说在墙内，使用EC2也不错，性价比不是最好，但是绝对值得试用。:-)

规矩是无处不在的，使用工具也有使用工具的规矩，就像你不能拿个榔头去拧螺丝一样。 就算是软件也有其使用的规矩， 经常看到有人抱怨某个软件怎么样的难用，其实大多数情况下他是用使用其他软件的习惯去使用另一个软件，也就是因为没有遵守使用此软件的规矩而带来的诸多不便。当然也有极少部分的软件真的很难用，那么就打破规矩，重新建立一个。

举几个例子，
Windows 上的软件管理，如果不用第三方的软件管理工具的话，那么使用MSI安装，卸载就是它的规矩。
Debian/Ubuntu 则是 apt-get 进行软件的管理，如果你使用咒语的话 ./configure & make & make install 那么就要自己去管理软件的诸多文件。
Mercurial 如果你要删除或者移动文件那么就使用 hg rm / hg mv 的命令来做，而不是直接的 rm / mv

有时我们需要在程序第一次启动的时候进行一些初始化工作，如何识别程序是部署后第一次运行呢？ .net framework就提供了这样的功能。

参考这里 http://msdn.microsoft.com/zh-cn/library/system.deployment.application.applicationdeployment.isfirstrun.aspx

这里还有更多的关于.net 程序部署相关的技术说明 。http://msdn.microsoft.com/zh-cn/library/system.deployment.application.aspx

Alwaysdata是一个法国的ISP，提供相当不错的VPS，共享主机等服务，而且免费的项目也相当的好，可惜你需要在墙外才能享受到如此高档的服务。

在Alwaysdata的wiki上已经详细说明了如何部署Django的应用，但是如果一丝不苟的依葫芦画瓢你未必能一次成功，因为这篇文档还遗漏了一点。

你还需要在project的根目录中放一个.htaccess 如下

project
     |-- apps
     |-- public
            |-- django.fcgi
            |-- .htaccess
     |-- .htaccess
     |-- settings.py
     |-- manage.py

而这个 .htaccess 的内容是：

AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ public/django.fcgi/$1 [QSA,L]

今天在公司里出现了一件事情，让我认真的思考了下Windows平台的易用性和安全。

事情是这样的，我们需要远程登录到一台德语的机器上工作。为了设置可以同时有两个相同用户名的用户远程登录，我们修改了组策略。两个德语文盲想当然的把一个和英语环境相同位置的选项给禁止了，然而那是拒绝远程用户登录的选项。刚改好的时候还很高兴马上用另外一台机器远程登录试用，很不幸将另外一个已经在上面的用户踢掉后自己也无法登录。

根据以前使用Windows的经验加上问Google，发现Windows远程维护是如此的强大。不仅仅是远程注册表编辑，还可以远程编辑组策略，AD，等等一大堆的东西。这一切在MMC中就可以完成。

如此强大的远程管理，却把我引入到为什么Windows不安全的地方去了。因为如果这是在Linux上把唯一的SSH关闭了，我还真的没辙。

在Windows上的这些远程控制是可以管理的，你可以选择让它不提供这些服务，然而这一切是Windows的默认设置。没有不安全的系统，只有不靠谱的管理员。默认开启了如此之多的远程服务，又遇到了不靠谱的管理员，在互联网上这个服务器绝对是挂了。

为什么是互联网？互联网就是一个狂野丛林，一不小心就成了别人口中的美味。既然那么危险，为什么Windows还开启了那么多的默认服务？让我们来看看Windows的主要用户吧。企业用户，企业内部和外界的联系至少有道墙，或者根本就不和外界联系。个人用户，虽然它们经常暴露在外面，但是即使他们受到伤害，通常损失也不会太大。这两种用户都有共同点，就是不太关心计算机的技术问题。

了解了Windows的使用者，那么Microsoft®有足够的理由开启这些默认服务，让他们的客户更简单的使用Windows，如果遇到问题，可以让IT远程配置即可。这一切的代价就是开启了很多潜在风险。Microsoft®的人当然不都是傻瓜，解决不了问题，只是这个世界有条准则就是做的越多错的越多。在你不真正了解Windows的时候冒然用它作为互联网服务器，那你会得到很多不错的教训！

在这里我并不是声讨Microsoft®和Windows，而是想提醒自己和大家，浅尝辄止害死人！你懂的。

在家使用ADSL拨号上网，并使用一台电脑作为Home Server，这样以来可以在工作的时候发现什么好东西，就可以远程连接到家中的电脑进行下载，也可以在家托管自己的代码仓库等，工作学习生活都不耽误。

使用ADSL有个问题，ADSL使用DHCP服务动态分配的，可能每一次拨号得到的IP都不一样。为了跟踪当前所获得的IP地址，我设计了一个简单的IP跟踪解决方案。下面是结构图：

整个架构分为3个部分
1. Home Server, 定时向 App Engine 发送请求告知自己当前的外网IP
2. Google App Engine, 管理用户和IP地址
3. 用户, 提供预定义的口令后就可以看到当前Home Server的外网IP

我的Home Server使用的是 Gentoo Linux, 每一个小时向 App Engine 发送一次请求，如果使用Windows XP，可以使用系统自带的计划任务，但计划任务的最小执行单位是每天。

Home Server 发送请求，是通过 cURL 来实现的，Windows 需要单独下载。我推荐在Windows上安装 GoW 来使用*nix命令提供的便利。

1

curl http://xxx.appspot.com/collector?key=GUID

App Engine 预置了一个字典，用来记录使用者的信息以及GUID

1

auth_data = {'auth_name': GUID}

用户访问 http://xxx.appspot.com/ ，填入自己的 auth_name 提交即可看到 App Engine 最后一次接收到IP信息。

这只是一个简单的解决方案，暂时够我使用。有兴趣研究 Google App Engine 的朋友可以来交流。

Kohana 是一个PHP的开放框架，所以在学习之前需要深入了解PHP。另外Kohana也是一个遵循MVC模式的开发框架，同样在学习之前还需要深入了解什么是MVC，最好动手写过MVC模式的页面，一个练习也行。

接下来我们从那里开始呢？

在动手练习之前，需要阅读文档。先哲说：闲时读手册，忙时问Google。刚开始我们有充裕的时间，那么开始阅读文档吧。

作为入门，属于Getting Started的文档需要优先阅读。通过阅读What is Kohana?，来了解下Kohana都有哪些东西。而 Model View Controller则告诉你Kohana使用了一种改良型的MVC模式。接下来 Cascading Filesystem 告诉你这个改良型的MVC模式是怎么工作的。最后通过阅读Request Flow来了解从浏览器发出请求后Kohana在服务器端是怎么处理的。okay，通过阅读以上的文档就入门了。

阳明先生说，知是行之始，行是知之果，知行功夫不可离。意思是光看文档并不代表你知道，需要动手操练一番才算真知道。

Kohana安装还是很容易的，将整个工程放到web服务器上就可以工作了。如果遇到问题跑不起来怎么办？Fix it! 安迪教授也说了，当你在工作过程中没有得到想要的东西时你就获得了经验。

程序员动手的第一招是”Hello World”，Kohana已经提供了这一招，所以通过阅读源码来学习这一招是如何发出的，因为Kohana是改良的MVC(也就是HMVC)，那么需要多注意项目的目录结构，看看这些源文件是以什么样的方式组织的。在观摩Kohana提供的入门招数后，让我们来破解这个招式。尝试着修改文件名，类名，以及改变文件目录位置等来验证这一招在什么情况下会失效，这对你加深理解有帮助。

入门招数，学了也拆了，开始模拟演练吧。

新手入门第一课，留言板。很多前辈都推荐新手来实现一个留言板用以学习新的开发环境。动手之前，我们要有个蓝图，不用大，将期望了解的知识点囊括进去即可。web开发的知识点通常有，Session,Cookie的管理，数据库的操作，URL的管理，Ajax，表单验证，异常处理等。限定已经有了，那么就开始来实现留言板吧。

演练开始我们就忙了起来，这时Google就发挥作用了，遇到疑难杂症问Google。作为修炼内力，阅读API加深理解各个类是如何工作。

最后，先哲也说了，尽信书不如无书。文档也有bug，当实际操作和文档描述的行为不相符的时候，那么我们就要玩外科手术了。这就是开源的好处，有bug直接解剖，肚皮划开后一目了然！

Python内置了一个简单的Web服务器可以用来建立一个HTTP Server来共享某个目录下的文件，尤其是在Unix-Like+windows的混合网络中更是方便快捷。

Server
假设 IP 为 192.168.1.1

首先进入到需要共享的目录，如

cd ~/share/

python -m SimpleHTTPServer 8000 #Python 2.6

OR

python -m http.server 8000 #Python 3.0

Client
访问http://192.168.1.1:8000就可以看到Server共享出来的文件了。