这个星期可是忙死了。制做了一份电子院刊。虽然那院刊是用iebook制作的，并且很多贴图和flash动画是从网上下的。可是真正做起来也是蛮费力的。

本来说是和报纸版的一样的样式。可是后来加的东西越来越多。最后做成了40页的杂志。里面有军训日记、军训照片、招新启示等等内容。特别是校庆信息。我大改了3次，“发布了”近40个版本。最后终于可以拿出去见人了。

可能要贴到我们的院网上去吧。本来是在科技部做事的，现在改转到编辑部了。最后或许也可以把编辑部发生的事情拍成电视剧叫做“新编辑部的故事”。

面对着十一，我现在可以放松一下了。

对了有兴趣的可以到 http://ss.hnu.cn/newweb/students/yuankan/index.htm上下载院刊。具体的网址我还不太清楚，反正会挂在那个网上的。

创新实践者——What matters is not innovation , but useful innovation。

跨领域合成者——What matters is not analysis but synthesis。

三商合作者——EQ is 9 times more important than IQ。

高效能沟通者——The man who can think and does not know how to express what he thinks is at the level of him who cannot think。

热爱工作者——If you find a job you love , you will never work a day in your life。

积极主动者——In a few hundred years , the most important event those historians will see is that for the first time , people will have a choice. They will have to manage themselves。

乐观向上者——The glass is half full or half empty depending on whether you’re pouring in or out

昨天上午听了微软工程院和微软研究院的研发部的高级经理的讲座。晚上在体育馆参与google的李开复的湖大googlecamp的开营仪式。这种机遇恐怕在大学的短
短4年里也顶多只有这一次了。

i’m a lucky dog…

当了googlecamp的志愿者混了件T-shirt和李开复的签名。。。

虽然自己对李开复没有太多的崇拜情节，但是这个签名却可以在那些开复的fans前炫耀一翻。。。。

上个星期五找小宁博士谈了谈.有人问他PM(program manager)的任务是什么…

他这样认为:(下面掺了些我的话…)

1. PM就是负责整个项目按时按质的完工.
2. 交流是PM的重要技能.
3. 需求分析的高手.
4. 要成为PM,先做到有责任心,喜欢与人交流,能协调好团队里各种人际关系.当有两个人吵架时,能迅速的把风波平定下来.
5. 能将一群人组织成一个真正的团队.(可以在业余时间搞点小活动)

小卒观点:

PM其实就是协调开发和测试两组来保质保量的完成项目.除此指望PM要做需求分析要画界面原型.不过不必要编码.

最近blog也没有什么好写的,写点老师布置的作业吧.

上个星期老师布置了一次需求作业,摘录如下:

1. 查阅一些有关介绍需求工程或软件项目管理的网站，读一篇写得不错的文章，用1－2页概括文章的内容（要求注明文章来源）。
2. 人们已经认识到软件项目失败的直接原因主要是
   • 缺乏用户的参与；
   • 不完整的需求描述；
   • 不完整的 SRS ；
3. 将三个层次的需求混淆在一起。请你结合客户的10项权利和10项义务，谈一谈做好软件需求应该注意的问题。

自己的第3题的回答就将第2道题当成为客户的需求分析了一遍…

原文如下:

如果把做作业也可以看成一个项目的话，作业要求就是客户的需求，对作业要求的分析就是需求分析，客户是老师，用户是批改作业的助教，我就是需求分析员。客户的需求并不很明确。

1－2页纸

写1－2页纸，每一个人都不同的理解方法。五号字写1－2，或者是一号字写1－2？是word的A4纸写1－2页，还是800字格子纸写1－2页？

客户认为这是很日常的问题，如同怎么洗澡。开发方可能与客户的理解完全不同。模糊的需求造成了需求的歧异性。而且我做作业并没有向老师询问什么，没有做好需求调研，只是按照自己的想法去理解写1－2页纸。开发方与客户缺乏良好的沟通，就立即动手开始做项目，这是一种非常危险的行为。

因为开发时，自己觉得very cool的功能，很有可能不被用户和客户们认可。如果按照自己的理解用一号字写了1－2页纸，恐怕下次上课自己的名字就会被老师打到ppt里去了。

假设我去做进一步的调研（询问老师）：“请问老师1－2页什么意思？”

如果老师很忙，没有什么时间，可能这样回答：“就是1－2页作业纸。”如果这样就完成了一次调研，其实我什么东西也没有得到。

我当时如果认为客户方清晰的描述需求是项义务，但是客户方有可能也认为“作业纸”的回答已经是清晰的描述。我当然需要进一步的要求客户方加以描述，这时老师可能不耐烦的拿出过去别人做过的作业让我看。我必须从那堆作业中对作业纸的概念做一个概括。

如果老师拿出来的作业纸只是过去上交作业纸的某种特殊的类型（例如无格纸），这就有可能使我对“作业纸”这个概念的概括产生偏差。最后交的作业就会用无格纸写。

在项目审批阶段，助教认为本次作业的作业纸不符合作业的规定，作业应当重新完成。这种严重的后果是谁造成？

其实当初我可以这样提问：“作业纸是指的这种纸吗？”（我可以事先准备几种可能的作业纸）老师会对此进行选择。如果老师对这些纸都不满意，可以让老师讲出这种纸到底是什么样式，什么大小，有什么具体要求。也可以让老师找到相似的纸样。

我要纸的具体信息，老师有可能不知道，或者不耐烦，或者知道也说不清楚。老师那里可能再也得不到什么有用的信息。

下面去调查助教们。助教可能很多，可能权利还不一样。得到的信息可能五花八门。有要求用 800 字方格纸；有希望用湖大作业本；有的认为交上来就行，不管什么纸。

我认为要求最苛刻的是需求的最好的约束条件。到底用什么作业纸的矛盾冲突应该由助教，老师和我协商解决。

假设我们开了一次会议，我在会上提出我的解决方案：用 A4 纸写（这种方案对我有利）。老师和助教也都认为这个方案不错。于是我们定下用 A4 纸写。这样为以后留下的一点隐患。我如果当时有很好的洞察力就应该发现以后还要引入另外的附加问题：用什么字体，用什么字号写，用不用斜体、粗体、下划线写，有没有什么格式等等遗漏的需求问题。

可以这样认为：一旦提出了更好的解决方案，就一定会带来新的问题。需求是无穷无尽的，完美的需求是不存在的。只要做到客户满意即可。

假设以上问题都已经搞定，那么看看现在我已经收集到什么信息：

“查阅一些有关介绍需求工程或软件项目管理的网站”得到题目范围是“需求工程”和“软件项目管理”的领域。如果我还不知道这两个概念，可以上网查阅。反正一句话：每个词我都要明白，并且能用清晰的术语向老师和助教表达我的观点。

“读一篇写得不错的文章”，这句话有很大的迷惑性。首先写得不错是什么概念？

这是一个模糊词。

我感觉我这篇文章也写的不错，贴到网上应该也也符和以上要求。假如我们不能对这个“写的不错”有什么准确的理解，可以用“写的很差”的反面定义。

总之，需求的过程就是将模糊的东西明确下来的过程。我对写的不错的定义是：阅读此篇文章的人超过千人，并且有60％以上的评论者认为有指导意义。

下面我进一步分析：读一篇其实是一种暗示，老师的意思应该是至少读一篇，虽然只是写一篇文章的概括。我认为已经将这个潜在的需求挖掘出来。

“用1－2页概括文章的内容”这一个限制条件，经过我先前做的调研，可以这样清晰的描述。用 A4纸，白纸黑字，字体：宋体，字体大小：五号，常规字体无加粗等特殊表现形式，无特殊文体格式。字数限制： 1 － 2页，无其他特殊要求。文字内容：对需求工程或软件项目管理的写的不错的文章（前有定义）的内容概括。

“（要求注明文章来源）”这也是约束条件。而且是必须做到的。

此外还有特殊的规定：“2004-9-13号上交”这是时间约定。

现在我来区分业务、用户、功能和非功能需求。

业务需求：老师的作业要求；用户需求：各个助教对本次作业的要求。可以看到各个助教对老师的作业要求并没有异议。更多的用户需求：字迹工整，页面整洁等等。但是我是用A4纸打印出来，这些需求都可以满足。

我的功能需求：有对以上老师布置作业的详尽解答。非功能需求：解答简单易懂，符合软件需求这门课的专业术语。（省略SRS的制作和签约）

假设我现在有台高智能的计算机，我只要将以上的规约转变为它能懂的字符即可，现在一切搞定。就差这台计算机了 ……

从纯理论来说，在需求这个阶段，客户和需求分析员两个角色就像是在下棋，最终的目标是要走成和棋。

下棋的过程，便是更改需求的过程。客户不会谦让你，每次更改需求都有可能对项目造成不可估量的后果。那你就必须是下棋的高手。

每走一步都要小心谨慎，走错一步都有可能成为死棋。不管将死谁，对于项目组来说，都是种损失。如果需求分析员能够预测到客户下一步棋，那么走和棋的概率将增加。

现在所有的方法论的东西都只能增加你走和棋的概率，不能保障你一定能走成和棋。下棋用的棋谱是这样，关于软件需求的各种期刊杂志也是这样。

“一是理论，二是实践经验。这两者在任何时候都缺一不可。”这真要感谢我的马哲老师和我的良好记忆力。

需求分析员这一角色不是单靠某某理论就能胜任的。没有和客户打交道的经验，没有宏观和微观把握事情的能力，很难担当这一角色。

能够从细节中推出正确的需求，也能从客户和用户的利益冲突的地方找到潜在的需求。如此看来，这一种角色很难担当，甚至不可能有人担当这一角色。

但实际的情况并非如此。这就想我们编程一样：操作系统里有bug，编译环境中也有bug，谁能保证自己的程序中没有bug呢？需求的缺陷就向bug一样难以排除。

既然我们可以控制bug的数量，就也可以控制需求的缺陷。从另一个角度看，其实需求缺陷就是bug。

首先我们必须明确一个结论：“没有完美的需求”。现在我们用一大堆的约束条件来约束需求，我们只是在满足客户的条件下达到一种可行解，而不是最优解。

虽然客户希望随时随地改变这些约束条件，然而开发方却希望将这些约束条件尽可能固定下来。需求的变动将对项目的完工产生致命的影响。

除非客户非要对需求修改，并承担项目延期发布造成的后果。而且项目的后期，确保需求不被改动。否则这个项目可能永远都完成不了。如果非要改动，就放到下一个版本去吧。

不管怎么说，需求是最耗费脑力活动的事情。也是软件工程的起始，如果起点就错了，最后的项目不可能让客户满意。但是即使起点对了，最后的项目也不一定会让客户满意。因为需求这个环节毕竟是软件工程流程中的一环而已。

当初为了把字数限制在3页字以内,就省略了很多需求的过程。现在感觉这份需求分析的作业题目还是有许多要改进的地方。

今天晚上突然19:00通知要交篇1500字的暑假调查报告.整个暑假没有人通知这件事,不知道为什么突然通知并且今天晚上10:30就要交.自己整个暑假都没有做过什么调查.不过做了一个.net项目,修改了一个J2ee的项目.在项目中还查到了不少相关的信息.就决定写一下.

于是用一个小时的时间写了一篇,自我感觉还不错.最近也没有写blog,于是贴到网上来算了.还能增加下点击率呢…

以下是原文:

写这篇文章是希望对以后即将从事IT业 的人员在选择.net和j2ee这两种不同风格的架构时提供一定的参考性.

开发速度:

vs2003/vs2005 PK JBuilder2006/myeclipse3.0

asp.net开发web网站的速度大幅提高,多半是因为visual studio的原因.加上vs的可视化编程和占据地利的windows平台的支持,web网站的制作速度越来越快.Jbuilder2006功能的确很强大,是开发j2ee项目的首选工具之一.但是运行速度奇慢.myeclipse3.0虽然在速度上略胜一筹,但是功能上比jbuilder2006差太多,即使装上了各种插件.如果在短时间内开发一套系统的话,并且并没有要求使用.net开发还是j2ee开发,我个人意见还是使用vs2005来开发.因为它太容易上手了.并且.net比j2ee开发的相同项目的时间短的多.

开发项目的大小:

根据我的调查:在湖南至少90%以上的中小企业都是使用.net开发出来的系统.大约70%的公司使用.net进行开发.对于国有企业,如:银行,电信等大型企业.一般使用j2ee开发出来的系统.

j2ee的项目一般面向大中型企业,并且这些企业非常需要一种分布式较高的系统的时候,j2ee当之无愧的成为首选.而且使用j2ee开发,代码较.net透明.并且网上还要大量的开源代码.所以企业不必担心开发出来的项目在安全上留下因为操作系统等软件环境留下的隐患.并且j2ee开发出来的项目,一经运行,便到处均可运行.不管是unix,linux还是windows.

发布难易:

只要用vs在windows平台下开发的网站,都可以在装有iis的windows上跑起来.当然在跑起来之前,要做些傻瓜式的配置.

如果用j2ee开发出来的项目也是这样就好了.我花了大约一个星期的时间搭建我的weblogic服务器.将weblogic的服务器换为jboss的服务器又耗费了我大约5天的时间。虽然在这期间通读了源码,改掉了t3协议,重写了ejb.但是感觉就是没有.net的发布顺利.ejb和jboss的重新配置搞的我几乎崩溃.原因有三:

1. 我是j2ee的新手.无人特殊指导,全凭自学. (当然也有团队的贡献)
2. 我的机子运行jbuilder和jboss的速度超慢,每次运行大约要等6分钟左右.如果在这期间运行聊天工具或开web浏览器,那机子一定死掉了.(终于看到了系统死锁的发生) 这个过程真的和郁闷.人的耐心总是有限的.一个上午运行10次左右,就该去吃饭了.劝各位同仁:机子内存小于512M或cpu低于1.5GHZ最后不要做j2ee项目.
3. ejb和jboss的配置比较繁琐.初学的过程真正体会到了这一点.光连数据库就更换了4-5次jboss.

控件 PK 组件

.net的世界里,最受关注的就是控件.因为大部分的程序员都是拖拖控件然后再编几行代码就将一个web application搞定.于是很多的.net开发人员都在致力于开发控件.

组件是j2ee的重头戏.组件的重用省却了很多的开发时间.但很可惜,组件还没像.net的控件那样可见.对于初学者来说,这又是一道难关.

.net和j2ee两种不同的架构思想,特别是.net的三层–web页面/业务逻辑/数据底层和j2ee的典型4层思想–jsp/servlet/ejb/数据底层.由于j2ee提供的jndi的机制使系统更具有分布性.这些思想在各种的领域里各占优势.暂时还没有谁能取代谁的趋势.在这一个open的年代,应该没有什么技术隔阂的.多学一点,让技术互补,总是没有什么坏处.

以上是个人看法.希望各位看blog的高手多多指正…

如何成为一位 hacker

为何有这份文件？

身为 Jargon File 的编辑, 常有一些网络新手发 mail 问我 “如何成为一个厉害的hacker?”. 但, 很奇怪的, 似乎没有任何的
FAQs 或 Web documents 说明这么重要的问题, 所以我写了一份我自己的看法.

如果你是以 offline 的方式在看这一份文件的某一个版本, 那么你可以在
“http://www.ccil.org/~esr/faqs/hacker-howto.html” 找到这份文件的目前最新版本.

怎么样才算是一位 Hacker ??

在 Jargon File 有一堆关于 `hacker’ 这个名词的定义, 大部份必须是技术上的行家或热衷于解决问题, 克服限制的人. 然而,
如果你想知道如何成为一位 hacker,有两件事是很有关连的.

这可以追溯到几十年前第一台 minicomputer 刚诞生, ARPAnet 实验也刚展开的时代. 那时有一个由程序设计专家和网络名人所组成的,
具有分享特质的文化族群.这种文化的成员创造了 `hacker’ 这个名词. 这些 Hacker 建立了 Internet,创造出我们现在使用的 UNIX
操作系统, 他们也使 Usenet 运作起来, 并且让 WorldWide Web 动起来. 如果你是这个文化的一部分, 如果你对这些种种有所供献,
而且这个文化的其它成员也认识你, 并称你为 hacker, 那么你就是一位 hacker.

在精神上, hacker 并不单指(限制于)这种软件 hacker 的文化. 有人也把 hacker的特质发挥在其它领域, 例如: 电子或者音乐方面.
事实上你会发现, 在任何一种科学或艺术的最高境界, 你都可以发现 hacker 的特质. 软件 hacker 们认为,那些类似的精神也都可以称为
“hacker”. 有些人还主张 hacker 的通性是独立于任何媒介之上的, 不特别属于任何一种 hacker 所在的环境. 但是,
在这份文件,我们将把重点放在软件 hacker 们所需的技能、态度和发明`hacker’ 这个词的分享文化的传统.

在另一个团体, 他们的成员也很大声的称自己为 hacker, 但是他们不是真的 hacker.这些人(大部分是男性青年)专门闯入电脑和入侵电话系统, 真正的
hacker 们称他们为 cracker', 并且不愿意和他们在一些做任何事. hacker 们认为这些人都是懒惰, 不负责, 并且不够光明正大的, 并且认为能破解安全系统并不能使你成为一位hacker. 但是很不幸的, 很多记者和作家不明究理的使用 hacker’ 这个字来描述cracker 们;
这让真的 hacker 们很忿怒.

基本上, hacker 和 cracker 之间最主要的不同是: hacker 们创造新东西,cracker 们破坏东西.

如果你想要成为一位 hacker, 继续读下去吧. 如果你是想要成为一位 cracker, 那么就去读 alt.2600 newsgroup
并准备在你发现自己并不如想像中那么行时, 给自己一点评价. 所有关于 cracker 的事情就只有这些了.

Hacker 态度

Hacker 们解决了问题并创造新东西, 他们相信自由并自愿的互相帮助. 想要被别人接受成为一位 hacker, 你必须发自内心的表现出这种态度.
为了要很自发的表现出这种态度, 你就必须先完全认同这些态度.

如果你只是把学习 hacker 态度这件事当作一种能在这个文化赢得认同的途径,那么你己经乎略了真正的重点. 由衷的接受这些态度是很这要的,
这能帮助你学习并维持你的动机. 就像那些具创造性的艺术一样, 成为一位大师的最有效方法是学习大师们的精神; 并不只是学习知识和情绪而己.

所以, 如果你想要成为一位 hacker, 请反复的做下面的事情, 直到你完全领会它们:

1. 这世上充满著等著被解决的迷人问题.

作为一个 hacker 是充满快乐的, 但这是一种因为努力得到成果所带来的快乐. 努力的成果则带来动机. 成功的运动家的动机则来自于,
使他们的身体不断进化,并把自己推向物理上的极限所带来的快乐. 类似的情形, 要成为 hacker, 你必须要能从解决问题, 精进技术,
和运用知识的过程中感受到一种悸动.

如果你不是天生就能感受到这种悸动的人, 那么, 为了要成为 hacker, 你必须使自己变成这样的人. 否则, 你会发现你的 hacking energy
就会像性, 金钱, 和社交活动一样, 因为分心而被消磨掉.

(你也必须为你的学习能力建立一种信念直到你完成你的工作 – 即使你只处理一小部份, 而你也不知道你到底还要学些什么东西才有辨法解决你的问题,
但是你会努力学习, 准备充足, 以应付下一个问题.)

2. 没有任何人必须一再的解决同一个问题.

富创造力的头脑是贵重而有限的资源. 有这么多迷人的新问题在那等著被解决.因此富创造力的头脑不该被浪费的用来重复发明轮子.

身为一位 hacker, 你必须了解到其它 hacker 们的时间也是很宝贵的 – 所以,分享资讯, 解决问题和提供解决方案给其它 hacker
以解决新的问题, 这些几乎算是道义上的责任.

( 即使 hacker 们所拥有的大多是从其它 hacker 的身上得来的, 但这并不意谓你必需把你创造的作品全部交出来, 你可以卖出足够数量的产品,
以求得温饱, 给付房租和买电脑设备, 这和 hacker 的价值观并不相违背. 使用你的 hacking 技能以供给一个家庭的生活, 甚至是致富,
只要你仍不忘记你是一位 hacker, 那么这些行为并不会产生予盾. )

3. 无聊而单调的工作是有害的.

Hacker 们(有创造力的人也是一样)永远不该做一些无聊而单调并且愚蠢的反复性工作. 因为, 如果这样的事情发生的话,
这表示他们正在做一些不是他们该做的事-- 解决新的问题. 这样的浪费对任何人而言都是一种伤害. 无聊单调的工作不只是无趣而己, 而且是一种有害的物质.

要做为一位 hacker 要能尽可能的自动避免无聊, 对此你必须有相当的认知. 这不只是为了你自己而已, 也是为了所有的人(尤其是其它的 hacker).

(这有一些例外. 有时侯 hacker 们会去做一些被认为无聊或重复性的工作, 当做脑力的训练, 或是为了要学习得某种技能或某种你所没有的特殊经验.
不过这是一种选择, 任何人都不该被强迫面对无聊事. )

4. 自由才好.

hacker 们天性上是反对独裁的. 任何一个给你命令的人就能给你一个独裁式的工作,并且可以给你一些笨的可以的理由, 停止你解决任何吸引著你的问题.
所以任何独裁式的行为都会被挑战, 以免会危害到你和其它的 hacker 们.

(这和为反对而反对是不同的, 小孩子是需要被指导和阻止他们犯错. hacker 也会同意接受某些权威, 照著指示做以较短的时间得到他想要的.
不过那是一种有限且理性的协定; … )

专制在监察和保密这些事上是很有效的方法. 这些行使专制的人并不相信自愿性质的合作和资讯分享 – 他们只相信在他们控制之下的合作关系. 所以, 身为一位
hacker,你必具有一种敌对的天性, 以对抗监察, 秘密和使用外力强迫或迷惑可以信任的人等行为. 你必须以互信做为你行为的基础.

5. 态度并非不等效于能力

要成为一位 hacker, 你必须开始培养这些态度. 但, 如果你只是单独的模仿某一种态度, 这并不能使你成为一位真正的 hacker,
也不会使你成为一位运动冠军或摇滚明星.

因此, 你必须学会猜疑态度和尊敬各种能力. Hacker 们不会想浪费时间在虚华的人的身上, 他们尊敬的是能力 – 特别是身为 hacker 的能力,
但对于其它方面的能力也是充满敬意. 如果有能力追求一些很少人能弄懂的技术,追求精神上的技巧, 并能集中精神, 那就再好不过了.

如果你尊敬各种的能力, 那么你就会乐于自己发展这些能力 – 这会使的努力工作和奉献成为一种剌激性的消遣而非一份苦差事. 这对于想要成为 hacker
的人而言, 是很重要的.

一位 Hacker 所需的基本技能

hacker 的精神态度是很重要的, 但技术则更是重要. hacker 的态度虽然是无可取代,但在梦想别的 hacker 开始也叫你 hacker 前,
有些基本的工具和技术是必备的.
随著新科技的发明和旧技术的取代, 这些工具随时间在慢慢的改变. 例如: 以往总是会学会用机器码写程序, 直到最近我们开始使用 HTML. 不过, 在
1996 年末,下面所举的工具是很明显的被需要的:

1. 学习程序设计.

当然, 这是基础的 hacking 技能. 在 1997 年, 理所当然的, 你必须学会 C. 但,如果你只是学一种语言, 那么你不能算是一位
hacker, 了不起只能算是一个programmer. 除此, 你还必须学会学会以独立于任何程序语言之上的概括性观念来思考一件程序设计上的问题.
要成为一位真正的 hacker, 你必须要能在几天之内将manual 内容和你目前己经知道的关连起学会一种新的语言. 也就是说, 你必会学会数个不同的语言.

还了 C 之外, 你至少还要会 LISP 或 Perl (Java 也正在努力的挤上这个名单;译者注: 我很怀疑这份名单说 :p ). 除了几重要的
hacking 常用语言之外,这些语言提供你一些不同的程序设计途径, 并且让你在好的方法中学习.

程序设计是一种复杂的技术, 我没辨法在这提供完整的学习步骤. 但是我能告诉你一些在书本上和课堂上所没有的东西 (有很多, 几乎全部最好的 hacker
们都是自习而来的). (a) 读别人的程序码 和 (b) 写程序, 这两项是不错的方法.

学习写程序就像在学习写一种良好的自然语言, 最好的方法是去看一些专家们所写的东西, 然后写一些你自己的东西, 然后读更多, 再写更多 … 然后一直持续,
一直到你发展出一种属于自己的风格和特色.

要找到好的程序码来看是很一件很困难的事, 因为, 对菜鸟 hacker 们而言, 适于供他们阅读和努力的大型程序的 source 数量很少.
但这事己有了戏剧性的变化了;现在免费的供应的软件、程序设计工具和操作系统(大都公开提供 source, 而且全都是由 hacker 们写成的)到处可看.
进入下一个主题…

2. 取得一个免费的 UNIX , 并学习使用和维护.

我先假设你己经有一部个人电脑或者是可以使用任何一部 (现在的小孩子真幸福，可如此轻易的拥有). 取得 hacker 技巧的第一个步骤是取得一份
Linux 或者一份免费的 BSD-Unix, 并将它安装在自己的机器, 并使之顺利的运作.

没错, 在这个世界上除了 Unix 之外, 还有其它的操作系统. 但是他们只提供 bianry, 你不能看到他们的程序码, 你也不能修改他们. 想要在
DOS 或 Windows或 MacOS 开始 hacking, 无疑就是要你绑著枷锁跳舞一样.

除此之外, Unix 是 Internet 上的操作系统. 当你在不懂 Unix 的情况下学习使用Internet 时, 你没辨法在不懂 Unix
的情况下成为 Internet 的 hacker. 因为这个原故, 现在的hacker 文化还是很牢固的以 Unix 为中心绕著. (这并不完全是正确的,
而且有些活在旧时代的hacker 甚至也不喜欢这种情形, 但是 Unix 和Internet 之间的共生共成己经到了牢不可破的地步, 即使是
Microsoft 的大块肌肉也没能在上面留下明显的伤痕.)

因些, 把 Unix 装起来吧! (我自己是喜欢 Linux, 但是还有其它的东东可用.) 学习它, 让它运作起来, 让它陪你努力精进. 用他向整个
Internet 喊话. 看程序码,改程序. 有一天你成为一位高竿的 hacker, 你回头往后看时会发现, 你得到比Microsoft
操作系统所能提供的还要好的程序设计工具(包括 C, Lisp和 Perl).而且得到快乐, 并学到比你想像中的还要多的知识.

关于学习 Unix, 在 Loginataka 有更多的资料.(http://www.ccil.org/~esr/faqs/loginataka.html)

看一下 Linux distribution 的目录或 Linux CD, 并把自己交付给它.

3. 学习使用 World Wide Web 并学会写 HTML.

在 hacker 文化创造出来的东西, 大多在他们的活动范围外被使用著, 如, 在工厂和辨公室或大学被漠漠的使用著. 但 Web 是一个很大的例外, 这个
hacker 眼中的大玩具甚至还被政客们接受, 并巧巧的在改变这个世界. 因此(还有很多好的理由),你必须学习 Web.

并不只是学习使用 browser (这太容易了)而己, 还要学会写 HTML 这个 Web 的标签语言. 如果你不知道如何设计程序, 写 HTML
也可以给一些习惯上的帮助.嗯!! 建立 home page 吧!

不过, 有一个 home page 并没任何特别之处能让你成为一位 hacker. Web 上到处都是 home page, 而且大部份都没什么重点,
没什么内容的烂泥 – 很好看的烂泥巴,但是看起来都一样, 差不多.
(http://www.ccil.org/~esr/html-hell.html)

为了让你的 page 有其价值, 它必须是有内容的东西 – 它必须是有趣并且(或者)对其它 hacker 有用处的.

Hacker 文化的状况

就像大多数没有经济活动的文化一样, hackerdom 的运作是建立在名望之上. 当你尝试去解决一个有趣的问题时, 你所做事是否有趣,
你的解决方案是不是真的好用, 这些只有你的技术上的同好或前辈准备好为你做评价.

因此, 当你开始玩起 hacker 的游戏时, 你的主要分数是来自其它 hacker 们对你的技术的看法(这就是为什么只当其它的 hacker 都认为你是
hacker 时, 你才算是一位真正的 hacker). 这个事实被人们认为 hacking 是一种孤独的工作的印象所朦敝了; 也被hacker
文化的禁忌(现在己渐渐的朽坏了, 但依然存在) 和存在人们内心动机的自大或特权之间的冲突所朦敝.

具体的说, hackerdom 就是人类学家所说的「天才文化」.你在其中所得到的地位和名望并不来自于支配其它人, 或是因为长的漂亮,
或因为你有一些别人想要的东西, 而是因为你送出东西. 特别是, 你给送出你的时间,你的创造力和你的技术成果.

下面有五种事, 你会因为做了这些事而爱到 hacker 们尊敬:

1. 写免费的软件.

第一种是写那些其它 hacker 们觉的有趣或好用的程序, 并把 source 公开开放给整个 hacker 文化中的人使用.

hackerdom 最爱尊敬的是写出大而功能强的程序的人, 而且这程序是广为大家需要的,所以大家都在做用这些程序.

2. 帮忙 test 和 debug 免费的软件

hacker 们也尊敬帮忙 debug 免费软件的人. 在这个不是很完美的世界, 你不可避免的必须花掉大部分的软件发展周期在 debug 阶段上.
这就是为什么在任何免费软件发展者的脑子都会告诉你一件事, 好的 beta 测试者(能很很清楚的描述发生的状况,正确的发现问题出处, 可以容忍测试版本的
bug, 并且能进行一些简单的诊断程序)和红宝石一样贵重.

如果你是一只菜鸟, 试著开始去找一个你有兴趣的正在发展中的程序, 并且成为一位好的 beta 测试者. 从帮忙测试开始, 很自然的你开始帮忙 debug,
进而开始帮忙修改程序. 你将在这过程中学习到很多东西, 并,且和以后可以帮助你的人结下因果.

3. 公布有用的资讯.

另一项好事是收集和过滤有用和有趣的资讯, 整理成 Web page 或 FAQ 之类的文件, 让大家能很容易的收得.

几种主要技术 FAQ 的维护者都能得和免费软件的作者几乎一样多的尊敬.

4. 帮忙维持一些简单的工作.

hacker 文化是由一群自愿者维持运作著. 有一些工作很无趣但却必须维持正常运作的, 如: 管理 mailing list, 维护 newsgroup,
维持大的软件供应站台, 推动RFC 和其它技术标准.

做这类的事将会得到很多的尊敬, 因为大家都知道这些工作是很花时间, 但又不像玩弄程序码般有趣.

5. 为 hacker 文化而努力.

最后一项, 你可以为这个文化效劳, 并推广这个文化(例如, 写一份正确的入门手册,教别人如何成为一位 hacker 😃).
在你因为做了前面四件事之一而出名之前, 这不是你该做的事.

正确的说, hacker 文化并没有任何的领导者, 但在这文化有所谓的文化英雄,族群历史学家. 当你在其中混的够久之后, 你也许会成为这之中的一员.
注意:hacker 们并不相信族群, 喧骚自大的长者, 所以成为这样的长者是非常的危险.与其去和别人竞争, 你宁可为自己定位, 给自己一个亲切谱虚的身份.

Hacker 和 Nerd(怪胎) 的关系

成为一位 hacker, 你不需要成为令人讨厌的人(Nerd), 反于社会常态. 然而, 这对你而言却是非常有帮助的, 而且有很多 hacker
也是让人讨厌的人. 当一个社会的浪人有益于让你专心在真正重要的事情上面, 例如: 思考和 hacking.

因此, 有很多 hacker 们接受了 nerd' 这种称呼, 甚至是使用 geek’(杂耍演员) 这个字眼, 并引以为傲 –
这是一种说明他们独主于世俗习惯之外的方法. 在 The GeekPage 可找到更多相关的讨论。
(http://samsara.circus.com/~omni/geek.html)

如果你能够适当的专注于 hacking 这事上面, 并且还保有你的生活, 那很好. 而且现在要做到这样, 比起以前我还是个菜鸟时容易. 主流文化现在也较为
techno-nerd (技术怪胎)所接受. 甚至有越来越多的人认为 hacker 们可以是很好的男朋友, 女朋友,老公和老婆. 在 Girl’s
Guide to Geek Guys 可找到更多相关的讯息。
(http://www.bunnyhop.com/BH5/geekguys.html)

如果你是因为没有生活而想开始 hacking, 那也没关系, 至少你就没有不能专心的问题了. 也许不久之后你就是一位 hacker 了.

风范要点

再一次的强调, 要成为 hacker 就要了解 hacker 的精神. 如果你并不玩电脑, 那么还是有一些事情可以帮助你. 这些不能成为 hacker
的代替品, 不过有不少的 hacker经常做这些事, 并认为这些事和 hacking 的本质有某种基本的关连.

• 阅读科学小说, 并参加小说的聚会(这是一个遇到 hacker 和原始 hacker们的好方法).
• 学禅, 并且(或者)接触战争的艺术. (钢铁般的纪律似乎很重要.)
• 训练你的耳朵对音乐的分析能力, 试著欣赏某种特殊的音乐, 并好好的玩一些乐器或者唱歌.
• 增加对于俏皮话和文字游戏的认识.
• 加强你的母语写作能力. (有很惊人数量的 hacker, 都是不错的作家. 这包括一位我所知道的最好的 hacker.)

你做越多这些事, 那么你就愈是天生 hacker 的料。

最后, 有一些事千万不要做.

• 不要使用愚蠢而夸张的代号(user ID)或化名.
• 不要加入 Usenet 的战火 (或者任何地方的).
• 不要自称为 `cyberpunk’(电脑捣蛋玩家),也不要浪费任何时间在这么做的人身上.
• 不要 post 或 email 一些充满错字或文法错误的文章.

做了这些事的结果只是为你招来大家的责难和批评. Hacker 们的记忆力都很好, 他们会
一直记住你的所做所为, 你可能要花数年的时间才有辨法让他们重新接受你.

其它的资源

Loginataka 有提到一些关于 Unix hacker 的训练和态度.
(http://www.ccil.org/~esr/faqs/loginataka.html)

我也写了关于 Hackerdom 历史的简介.
(http://www.ccil.org/~esr/faqs/hacker-hist.html)

Peter Seebach 也维护了一份很不错的 Hacker FAQ, 这份文件是专门给不知道
如何和 hacker 们相处的经理人们看的.
(http://www.solon.com/~seebs/faqs/hacker.html)

我也写了一份 paper「Cathedral and the Bazaar」, 上面解释 Linux 文化的运作
方式. 你可以在我写的page 上找的到.
(http://www.ccil.org/~esr/writings/index.html)

常被提出的问题 (FAQ)

Q: 你能教我如何 hack 吗?

自从公开这个 page 以来, 我每周都收到很多人来信问"请告诉我所有关于 hacking的事". 但很不幸的, 我没有这个时间或者是精力去做这件事; 我的
hacking project已经用掉我 110% 的时间了.

就算我愿意, 但是基本上, hacking 是一种必须自习而成的生活态度和技术. 你会发现,当真正 hackers
愿意帮助你的同时，你将得不到他们的尊敬，若你求他们把会的东西都直接给你的话。

先学一点东西吧! 表现出你正在努力尝试, 你有能力独立学习的. 然后再带著你所遇到的难题去和 hacker 见面.

Q: 我要在那才能找的到一位真的 hacker 并和他们交谈?

很好, 不过很确定的, 不会在 IRC. 就我所能看到的, 那除了骗子和 cracker 之外什么也没有. 最好的方法是找到一个在你附近的 Unix 或
Linux 的使用群, 并加入他们,参加他们的聚会 (在 Linux Users’ Group page on Sunite 有一份目录).
(http://unc.sunsite.edu/linux/ldp/lugs.html)

Q: 我应该从那一种语言开始学呢?

如果你真的不懂 HTML 的话, 那就从它开始吧. 市面上有很多外表光鲜亮丽的 HTML烂书. 我最喜欢的一本是 HTML: The Definitive
Guide.
(http://www.ora.com/catalog/html2/)

如果你已经准备好开始学 programming 了, 我会建议你从 Perl(http://www.perl.com/)或
Python(http://www.python.org/)开始. 而 C 是真的很重要, 不过它也真的很难.

Q: 我要如何开始呢? 在那能拿到免费的 Unix 呢?

我在这 page 内到处都有指向取得 Linux 的地方. 要成为一位hacker, 你必须要有动机并且主动进取还要独立学习. 就从现在开始吧…
原著 Eric S. Raymond [email protected]

译者 [email protected]

下载文件一般有两种实现方法
方法1：
将要下载的文件的相对路径保存在数据库中，页面的链接得到数据库中的相对路径即可。
方法2：
将要下载的文件的绝对路径保存在数据库中，页面的链接得到数据库中的绝对路径即可。

如果使用.net的话，页面层用dateGrid绑定数据源即可。数据层写些select语句就能轻松的实现。

如果使用j2ee方法。其原理同上。不过页面要得到EJB传来的参数。
不过如果使用Weblogic做为服务器的话，可以使用t3协议来搞定上传与下载。
如果使用JBoss做为服务器的话，因为文件流写的文件都会写在Jboss/bin中。而一般的页面文件，servlet和Ejb一般打包发布，所以在数据库中写入绝对路径较好实现。

几个星期前接到了一个系统。那个系统其实已经发布使用，只是要让我们改改系统环境。按道理来说也没有什么。
并且交给我们项目的人说这个系统以前经过严格的测试。于是我认为应该改动的地方也不多，bug可以说是微乎其微。

而且几个星期过去，当这个系统改完配置后再此运行的时候，我才发现：几乎每一个页面都有几个bug。再加上系统本来带有的bug，整个系统的bug应该超过30几个。
没有想到过去经过严格测试的系统，其bug数量竟然如此之多。想想可能是自己移植系统的时候处错了吧。调来过去的系统看看，bug还是那么多。看样不是自己移植的问题。

还有些bug很奇怪.举个简单的例子，如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<script language="JavaScript">  
<!--  
    function verifyInput(){  
        strUserName = document.adduserForm.name.value;  
        if ((strUserName == ""))  
        {  
            alert("用户名不为空");  
            
            return false;  
        }

        return true;

    }

\-->

</script>

<form method="get" name="adduserForm" action ="/userlogin/controller" onsubmit="return verifyInput()" >

我页面提交的时候要判断true还是false才能提交。结果是不论false还是true都能提交表单。。

最后还是在源script代码中添加了

1
2
3
4
5

document.adduserForm.name.value="";  
document.adduserForm.name.focus();  
return false;

才使得页面不能提交。

有时候自己在想：

一个环境（windows）有bug，一个编译器（jvm）可能有bug，一个集成编译环境（jbuilder）可能有bug，一个数据库（mysql）也可能有bug，
那自己的编出来的程序如果真的是一个bug没有，恐怕这也是奇迹了。

表中列的类型定义为TIMESTAMP

oracle的语句实现：

1
2
3

select * from table where to_char(CREATE_DATE,'yyyy-mm-dd') > '1998-07-12' and
to_char(CREATE_DATE,'yyyy-mm-dd') < '1999-12-20';

这里的table为表名，CREATE_DATE为时间的字段名。转换格式为’yyyy-mm-dd’，查找的是’1998-07-12’到 '1999-12-20’之间的记录。

mysql的语句实现：

1
2

select * from table where date_format(CREATE_DATE,'%Y-%m-%d')> '1998-07-12'
and  date_format(CREATE_DATE,'%Y-%m-%d')< '1999-12-20';

解释同上。