2006年7月31日

Coder to Develpoer - Nailing Down a Feature Set

How exciting it is! Yesterday, I just post an entry about the book "Coder to developer". This noon, I began to read it. Although I had read only few pages, I had to say that it was heuristic for my mind. When I read the pure English words with some help of KingSoft Ciba, I figured out one viewpoint of the author: there were so many Computer Science department could not actually teach you software development skill, like teamwork. All the students should learn the related skills by themselves. Yeah. To, my own experience, I had not been really taught any software development skills. All the things I should learn by myself. And currently, I am still a beginning learner of software development. In the developing process of LTP, I should keep learning everyday.

How to develop good software not only writing good code? You can take part into some practical project in some software corporation. But to the little experienced students, one good book about it is also good. So now, I believed the book "Coder to developer" was such one.

To software development, as we know the first step is requirement analysis, namely features including. In chapter one: planning your project, the first section is "Nailing Down a Feature Set". I think it is visualized for requirement analysis. And then how to nail down the feature set? There is an advanced and simple technique: The Elevator Pitch. Yeah, maybe you are confused by the new concept. So what is "The Elevator Pitch"?

Suppose you were finding some venture capital for your new and wonderful software idea, and you had prepared enough with a 15 minute presentation about it, you were coming into a big building to ask help of a senior partner. And as usual, he was so busy that he could only talk with you in the 30-second elevator ride. So what should you say to the VC now? You should use very few words to express your new idea. And whether the words can attract the listener's attention is crucial to your software. For example, the author showed us a paragraph about his software Download Tracker, as following:


Download Tracker builds a personal catalog of all the software that you download from the Internet. You can add descriptions and keywords to identify each software package. Later on you can edit this information and add your own ratings. With Download Tracker, you’ll never forget where you saved a program again, or lose track of the name of the file that installs your favorite freeware application. If you run a website, you can even use Download Tracker to automatically generate a list of your favorite downloads, complete with hyperlinks.



The main points about how to use words are:


Short is better than long. A long and rambling elevator pitch probably means you haven’t really decided what you’re building yet.

Functionality trumps technology. Potential customers care about what your software will do. They usually don’t care how your software does it.

Solve a problem. If you can’t explain what problem your application will solve, customers won’t know why they should buy it.

Pitch the benefits, not yourself. Customers won’t be buying you, your superior knowledge, or your development team (if you’re lucky enough to be working with a team). They’ll be buying the software.

Figure out what’s important to your audience, and make sure you address that. Are the people buying your product most interested in cost, innovation, features, compatibility, or something else entirely?



Yeah! In my mind, I believed that the Elevator Pitch was just like the summarization of research papers. You should use fewest words to attract the attention of the readers.

There was another point about the feature set: Feature creep—the continuing addition of new functionality while you’re still writing the code—is one of the biggest enemies that keep you from actually finishing a project.

Now, to my project of LTP, I felt little like feature creeping now. So the most important thing was to nail down the feature set of LTP, then I could do the right things.

2006年7月30日

[Collection]从Coder到Developer

从Coder到Developer

你是否对软件开发已经了如指掌?如果是,那么就请别往下读了。
Coder(编码人员)与Developer(开发人员)的区别是什么?Coder是指那些熟练掌握了某门计算机语言的人。而Developer是指那些人,能拿起需求或概念来,组成一支团队,应用现代开发过程,做出合乎需求的设计,然后制造出来高质量的产品来。

Mike Gunderloy在他的新书《Coder To Developer -- Tools and Strategies for Delivering Your Software》里告诉我们,想成为一个合格的软件开发人员,应该掌握什么东西。

在该书的15章里,Mike Gunderloy以一个.NET程序开发为例,深入浅出地谈及了软件开发中的方方面面,从计划,组织,应用源码控制,防卫性编程,使用单元测试,熟练掌握和武装IDE,深入理解/重用代码,使用工具生成编码,缺陷追踪,记录程序行为,团队合作,产生文档,精通运行代码的生成过程,保护知识产权,到交付与产品的安装/部署,在每个方面都提出了非常可借鉴的看法和经验。

譬如,在第三章《Using Source Code Control Effectively(有效地使用源码控制)》里,他谈及源码控制里的三个层次,现有市面上的种种源码控制工具,如何据于需求(价格,开发风格,代码repository,网络友好性,与IDE的集成,所需高级指令,跨平台支持等等)做出选择。

在第五章《Pumping Up the IDE(如何武装IDE)》里,他谈及怎么用户化IDE,设置有用选项,使用VS.Net PowerToys,编写Macros,选择Add-Ins,怎么使用工具浏览和分析你的源码,更换编辑器等等。

在第九章《Logging Application Activities(记录程序行为)》里,他从.Net里现有的类(System.Diagnostics.Debug 和Trace)出发,谈到微软的Enterprise Instrumentation Framework以及The Logging Application Block,最后论及开放源代码的log4net。

在第十三章《Mastering the Build Process(精通Build过程)》里,他谈及自动Build 过程,以及该过程的简洁性和可靠性,分析比较了当前市面上高低档Build 工具,如何使用开发源代码的NAnt等等。

虽说自己开发软件也有不少年了,但惭愧的是,涉及的方面很有限。通过阅读这本书,了解到了自己与一个全面的软件开发人员间的距离,认识到在哪些方面还有待进一步提高。

比较欣赏书尾的几句话:

If there's one thing that distinguishes good developers from the rest of the pack, it's an attitude toward learning. Good developers just don't stop learning. There's always some new part of the software universe to explore, some new languages to learn, or some new tool to test-drive. As you hone your own developing skills, I urge you to make use of the resources of the Internet to continue learning and exploring.



2006年7月29日

[Collection]Charles Petzold给撰书人的建议

Charles Petzold给撰书人的建议
Charles Petzold 的千页著作《Applications = Code + Markup -- A Guide to the Microsoft Windows Presentation Foundation》已经交付印刷了,不久就会出版。

在他的博客里,他给想写书的人以下建议(粗浅翻译):

Book-Writing Advice
http://www.charlespetzold.com/blog/2006/07/240338.html

1。保持一个平稳的时间表。每星期5-6天,每天大概6个小时,这样的安排,每个月足以写出100页来。
2。别无谓耽搁,别指望在最后几个星期内写完一本书,除非你是那位快笔作家西默农。
3。买个舒服的显示器,舒服的键盘,舒服的坐椅。这些是写书的最重要的计算机部件,处理器,内存,和储存都是次要的。
4。吃好,睡足。
5。千万别在写作当天把东西写尽,留点余味,下次再写时好上手(这是我从海明威那里学来的好建议)。如果写作当天结束时留下问题的话,空闲时你就会琢磨,也许等你下次坐到桌子前时,你已经在你的脑海里把问题解决了也没准。
6。试着保持一个平衡的生活。如果你一天内用功写书了,那么你做其他跟写书无关的事情时也不会有负罪感。
7。尽量避免大的分心,譬如新的电子玩具,一个新的关系,或者动手术。
8。也尽量避免小的分心。有些工作是可以在听电话和写电邮时同时进行的,但写书不属于这类工作
9。先写编码,然后写相关文字。
10。别怕跳跃。除非你知道以后章节都包含些什么内容,你是不知道前面章节应该写些什么的。
11。只求有进展,不求完美。
12。书写完后,给自己送个礼物,譬如一个新电子玩具,开始一个新的关系,甚至做个手术什么的。
13。书写完之前别理发。

-----上述经验对于个人完成一个大的编码项目或者撰写论文,我认为同样有效的。

2006年7月28日

LTP: socket模式 八十一难

唐僧西天取经经历了八十一难才取回真经。到目前为止,我所负责的LTP估计也快要经历八十一难的,但是还没有能完全达到理想的状况。为了解决旧版中资源重复加载而使得每次处理时间都比较长的问题,我们采用了资源常驻内存的Socket访问方式。原本在实现第一种访问模式的时候我已经经历了很多的困难。但是现在摆在面前的困难依旧有很多的。


此刻,我的头又一次出现了4月末开发LTP第一版的时候的那种情况,感觉有点电发疼。这种情况的原因不是因为呆在实验室编写程序的时间过长,因为我最近锻炼身体很到位的;而是因为面对的问题总是不能解决,在经历了好多种可能的解决方案后还是存在这样的问题。今天的问题有两个:socket通信的长字符串传输串位,以及TinyXML DOM的文本格式不能存放到char*中。到刚才截止,第二个问题找到了最终的解决方案,但是第一个问题还是不能找到原因。

没有办法,还得继续做呀,争取早日做完,早日解放呀!神啊,粗糙集概况和Name Disambiguation还在等待着我呢,我又一次陷入了项目的漩涡。现在的办法是把项目的需求明确到100%,当成是明确的编程人任务,而不是永无止境的研究。

在这里也要感谢我的偶像陈儒大虾和我的师弟刘龙,他们给了我编程方面很大的帮助并且提供了耐心的讨论。呵呵,八十一难就快满了,继续努力的啦!

2006年7月27日

哈工大机器学习小组第三次活动-粗糙集概况

经过一个月左右的酝酿,哈工大机器学习小组第三次活动——“粗糙集概况”终于要举行了,讨论时间:2006年8月5日,地点:哈工大。
本着“让交流成为习惯,让每位成员100%交流”的原则,这次活动有个小小规则。就是要求每位参与者都要准备一个相关的ppt(粗糙集研究相关即可,论文学习、研究成果、对粗糙集的心得和体会均可),请在8月3日前发送ppt给bill_lang@ir-lab.org,之后会回复开会的具体时间和地点。请希望参加讨论的朋友遵守这个规则。

本次讨论已经确认的第一个报告如下:

报告题目: 处理混合数据的若干粗糙集模型
讲座人:胡清华
时间:2006-8-5
听众要求:需要有一定的粗糙集理论基础和研究经验,作者不会花时间介绍粗糙集理论的基础知识。
内容简介:Pawlak粗糙集模型基于经典的等价关系和划分进行构造,适合于处理符号型数据。然而现实应用的数据库中,往往保存的是数值型数据或符号型与数值型数据共存。如何处理该类数值型或混合型数据成为近年来粗糙及理论研究的一个热点。本次讲座将综述当前各种解决方案,分析各种方案存在的问题,然后展示近两年作者在此方面进行的一些探索。作者提出了模糊信息熵、邻域模型、模糊邻域和一类改进的模糊粗糙模型解决这一问题,本次讲座将展示各种方法的理论模型、算法设计和试验效果,并且提供程序代码共大家对比分析。

到目前为止,还有叶玉玲、姚平、郎君报名参加本次活动。希望参加这次活动的同学请在如下wiki中登记报名(便于进一步通知时间和地点)。
http://ltp.ir-lab.org/mywiki/moin.cgi/%E7%B2%97%E7%B3%99%E9%9B%86

另外,欢迎大家在我们的机器学习论坛上讨论相关事宜:
http://bbs.ir-lab.org/cgi-bin/topic.cgi?forum=20&topic=741

2006年7月26日

灌篮高手-激情与坚持

灌篮高手中到处闪光着两个字——激情,不计成败的热爱这那手触篮球的感觉。樱木花道失败过,在挑战流川枫时,在多次犯规时,在头破血流时,在背脊摔伤时,但这个对失败没有概念的家伙在失败后的进步是令对手可畏的。流川枫失败过,挑战仙道,无法破尺北。宫城呢,每次以绝对矮的身体进攻着不断的进攻时,其中受阻也不会少。最令人感动的还算是三井了。原来的那个三井败于嫉妒和自负掌下。随后远离球队的二年是他最痛苦,最颓废的两年。但这个经历也促使了他的成熟。印象特别深的是在一次与流川枫的一对一对抗失利后,三井洒脱的神情,尽管他从不承认那次是他失败。年轻会有失败,热情会淡化失败,而激情会使失败变得成功。人的一生总该有一种坚持,总该有一些东西会令你激动,令你沸腾,令你热泪盈眶吧!

终于看完了着长达101集的动画片。我用了那么多的日夜去经营一份份喜悦,一次次感动,一秒秒惊奇。看着漫画动画中的每一个人的成长,每一个人的成熟,我觉得自己也在与他们一同为了梦想,为了生命这份天赐的珍贵礼物而努力,勇敢,不计失败。

看每一集的时候我的心中都在感动着。这种激情就是对篮球的热爱。换成我现在的状况就是对机器学习的热爱。"一旦你放弃,比赛就结束了." 安西教练的话让我很难忘记。是的,对于现在我所面临的研究,一定要在激情的催动下不断的坚持下去,天上不会掉馅饼,成果都是自己努力得到的。篮球练习中每天都必须有篮球的基本功训练。对于我们从事的科学研究,基本功是什么呢?我想,应该包括:查新,阅读,思考,实验,撰写论文吧。嗯,练好基础,不断夯实,一切都会顺理成章的。

朋友,你对什么不断的拥有激情和坚持呢,继续下去吧,然后咱们一起分享喜悦!

2006年7月25日

从逛街的“购物狂”看科学研究中交流的重要性

今天早上起了个大早,出去和女友、及其妈妈、两位姐姐和两位侄女一起逛了整整一天街。晚上五点半她们踏上回家的火车才算我们的逛街行程结束。在我感觉来说确实有点累,因为这是迄今为止我一次逛街时间最长的一次。

疲倦之余,细细回想全天的过程,我想到了一个较为深刻的问题。那就是今天一位侄女说的“购物狂”的话。当然,当时的这句话只是小孩子的一个玩笑似的评论。但是其中却折射出了一种情况。那就是为什么她们会在哈尔滨一次买这么多衣服呢?

基本情况是这样的。两位姐姐家那里衣服价格比较贵,而且款式不如哈尔滨的多。她们到哈尔滨来乘办一些事之余闲逛了哈尔滨的好多个卖衣服的地方。看到这边的衣服物美价廉,在家平时觉着比较贵的衣服在这边却比较便宜,自然出现了很强烈的消费的愿望。

这个情况让我联想到了机器学习研究中的一种现象(或者说是我所了解的科学研究中的一种现象,我们以机器学习为例来说明)。一位机器学习初学者在无人指点或较少指点的情况下,会学习机器学习相关的很多文章。进而会整理出这个领域中的各个研究方面,比如按照机器学习算法类型列举:神经网络、支持向量机、粗糙集、决策树、遗传算法、蚁群算法等等。然后很可能会进一步阅读各种算法相关的文献,形成对各个算法的直观和算不上非常深入的学习。由于不专,从而学习理解不深。对每种算法的理解算是一种片面的认识。这就像是在一个城市里调查每种衣服的价格情况,虽然也算是对这个城市的情况了如指掌。当这位研究者在将来指导学生的时候又会让他的学生对机器学习的理解也像是在同一个城市中调查一样。这就是所谓的高校学生培养和教职员工近亲繁殖的情况。现在很多著名高校都在尽量避免近亲繁殖的情况出现。我觉得这种做法是相当正确的。

说到上面的那位当初是初学者的研究人员,如果他能够得到一些高人的指点或者在接触一些其他的领域知识后,就可能出现彷佛到另外一个城市调查先前城市中商品价格的感觉。多种观点和学问的交融,会产生很多思想的火花。这些火花是第一线的,因为只有直接接触人员才会有非常深刻的感悟。从而可以开启很好研究题目。这就是所谓的出现“购物狂”的欣喜。

科学研究需要这种多知识体系的交融以及创新想法的迸发。这不禁又让我想起了去年组织的第一次机器学习小组活动上的开幕词——“让交流成为习惯”。是的,交流真是太重要了。想到这里,我希望将近期即将举行的第三次机器学习小组活动——“粗糙集概况”认真的组织好。也欢迎感兴趣的朋友报名登记参加。报名登记地址:http://ltp.ir-lab.org/mywiki/moin.cgi/%E7%B2%97%E7%B3%99%E9%9B%86