7/01/2008

Linux下添加硬盘、分区、格式化任务详解

给硬盘分区

在slackware下有两个分区软件fdisk和cfdisk,例如我们已经有一个硬盘了,现在添加另一个硬盘到系统,那么我们根据命名规则知道这个新添加的硬盘应该是hdb。我们用下面命令给硬盘分区

fdisk /dev/hdb


你也可以用cfdisk来分区,命令如下:

cfdisk /dev/hdb


格式化硬盘

格式化成ext3格式

mkfs.ext3 /dev/hdb1


格式化成reiserfs的格式

mkfs.reiserfs /dev/hdb1


让硬盘启动自动挂载

例如挂载/dev/hdb1分区到/mnt/hd目录下

用vi编辑/etc/fstab文件,加入如下内容

/dev/dhb1  /mnt/hd  reiserfs defaults  1  1

6/30/2008

Uncomplicated Firewall ufw in Ubuntu

The Linux kernel includes the Netfilter subsystem, which is used to manipulate or decide the fate of network traffic headed into or through your server. All modern Linux firewall solutions use this system for packet filtering.

The kernel's packet filtering system would be of little use to administrators without a userspace interface to manage it. This is the purpose of iptables. When a packet reaches your server, it will be handed off to the Netfilter subsystem for acceptance, manipulation, or rejection based on the rules supplied to it from userspace via iptables. Thus, iptables is all you need to manage your firewall if you're familiar with it, but many frontends are available to simplify the task. Howto: Use, setup, and Take advantage of the New Ubuntu Uncomplicated Firewall UFW

6/29/2008

binding multiple IP addresses on a single ethernet on Ubuntu 8.10

It is essential for us to configure a multiple IP addresses on my working PC as a web application developer , so , I done, see the following

Working Environment

  • Ubuntu 8.10
  • LAN : 192.168.1.1 - 224
  • GateWay: 192.168.1.1

Todo

1 setting the Ip is static, then reboot the network

# sudo /etc/init.d/networking restart

2 edit the interfaces config file

#sudo gedit /etc/network/interfaces

you will see the following

auto lo
iface lo inet loopback

3 add the eth0:0 at the bottom of the file

iface eth0 inet static
address 192.168.1.118
netmask 255.255.255.0
gateway 192.168.1.1
auto eth0

iface eth0:0 inet static
address 192.168.1.119
netmask 255.255.255.0
gateway 192.168.1.1
auto eth0:0

4 Saving it,then reboot the network again

#sudo /etc/init.d/networking restart

5 testing our change

#ping 192.168.1.118

#ping 192.168.1.119

5/11/2008

读林斌博士写好代码十个秘诀

软件的质量属性
鲁棒 - Solid and Robust Code
简洁 - Maintainable and Simple Code
高效 - Fast Code
简短 - Small Code
共享 - Re-usable Code
可测试 - Testable Code
可移植 - Portable Code
集百家之长, 归我所用 - Follow Basic Coding Style
1.代码能够清晰的表达你的思路
2.代码应该具备自解释能力,注释代码别是单纯解释语句,这种注释毫无意义
3.编码的缩进和排版规范
4.所有的函数和变量应有他人容易理解的名字
5.将Tab键改用为4个空格字符
6.减少单个函数的长度,控制在50-100行以内
7.避免幻数,多使用枚举和常量的定义
取个好名字 - Use Naming Conventions
1.采用匈牙利命名法对变量进行命名
2.名字要清晰表达含义,不要怕长
凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用应该遵循原则,而不是全盘否定
2.不用写高深晦涩的语句,不要一味追求性能忽视代码可读性
3.模式并不是一味正确,特定问题更需要考虑反模式
先发制人, 后发制于人- Practice Defensive Coding
1.尽量保持代码的简洁和简单
2.调用其它接口和函数时候首先对返回值进行检查
3.避免有符号/无符号,32位/16位,被零除等误算情况
见招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通过异常处理机制来保证程序代码的健壮性
2.异常处理中一定要注意资源的释放
3.异常处理要关注日志的详细记录,便于后续BUG分析
4.不用把后台编码或系统异常直接抛给用户
熟习剑法刀术, 所向无敌 - Learn Win32 API Seriously
1.Win32 API是微软平台编程根本
2.对系统强大的公用类库的熟悉和整理将事半功倍
双手互搏, 无坚不摧 - Test, but don’t stop there
1.如果你没有进行测试,你完成的代码将仅仅是个半成品
2.尽可能多的对自己的代码进行测试
3.编码人员应该更专注于白盒测试和单元测试
4.要善于使用JUnit,NUnit,PureCoverage,Compuware,NCover等测试工具
5.相互间的Review和走查是对代码可维护性的重要测试手段
6.有特殊性能要求时候需要对相关功能或模块单独进行性能测试
活用断言 - Use, don’t abuse, assertions
1.断言可以很好的描述假设和不可能的情况
2.断言对程序Debug很有用,可以尽早的发现程序问题
草木皆兵, 不可大意 - Avoid Assumptions
1.考虑到用户使用的各种场景
2.不用假设用户会正确输入数据,要做好各种完整性和边界的检验
3.程序中70%左右代码是为了保证这种完整性服务的,正常条件下功能可能30%代码就实现了
最高境界, 无招胜有招 - Stop writing so much code
1.一味拷贝粘贴代码就是在制造拷贝BUG,这种代码对系统无任何意义
2.编码过程注意重用,函数级->组件级->系统级
3.通过重构持续改进代码质量,改进自我逻辑思维
最后总结下:
1.养成良好编码习惯,你面试的一小段代码可能就足以展现你全部陋习。
2.熟练使用好各种辅助工具,但不要全部依赖工具,最主要是学习分析和设计的思考方式
3.注重单元测试,关注程序性能,可维护性,可测试性是编码技能提升重要手段
4.通过重构使编码过程形成完整闭环的反馈回路,重构能力可以很好体现自己的设计能力
5.养成良好习惯,形成自己的编码过程检查单,多请教老员工可能事半功倍。

5/10/2008

Eclipse Process Framework: a new tool for porject process management

Eclipse Process Framework (EPF)提供了一个可订制的软件过程控制框架,这个框架集成了一些典型的过程控制的理念和工具,以此来支持各类工程和开发风格。

项目目标:

1. 为过程控制提供一个可扩展的框架和一些代表性工具。如方法和过程的分配,库管理,配置和发布一个过程
2. 提供典型的并且可扩展的过程概念,他们能为各种软件的开发和管理过程提供迭代的、灵活的和递增的开发,并且能应用于更广泛的开发平台和应用。

Some advices for API designing

设计需要进化
API的价值就在于能够帮助你完成许多功能,但请不要忘记要持续的改善它,否则它的价值就会逐渐减少。而且要根据用户的反馈信息,来改善API,或者说是 对API进行演化,另外改进API时要注意的就是在不同版本间要保持兼容性,这点至关重要,它也是一个API是否成功的重要标识之一。 如果一个功能以API的方式公布出来,那么在发布以后,它的对外接口就已经固定,无论什么情况,都不能取消,而且一定要能够按照原有的约定功能正确执行。 如果API不能在版本间保持兼容性(译注:这里应该指的是向下兼容),用户将会难以接受这样一个千变万化的API,最终的结果只能是让用户放弃使用你的 API。如果你的API被大量的软件或者模块所使用,又或者被大型软件使用,这个兼容问题也就愈加严重。
通常情况下,你不知道用户如何使用API来完成工作。除非能够确认API的修改对用户的代码不会造成破坏,才可以考虑修改API。,反之如果API的改变 会影响用户现在的代码,就必须有一个足够的理由。只有意识到对API的修改,会严重的破坏用户现有的代码,在修改API时才会谨慎地,尽量地保证API兼 容性。修改API的时候要尽量避免以下几种情况,以免对用户的代码产生破坏:
降低方法的可见性,如将public变成proteced,又或者将protected变成private。
修改方法的参数,如删除一个参数、添加一个参数、或者是改变参数的类型,尤以后两者更为严重。
当API的设计和开发到了一定阶段以后,可能会发现以前的版本已经出现了一些问题,又或者需要添加新的功能,此时设计人员完全可以重新创建新的API,并 放到新的包中,这样就可以保证那些使用老版本的用户可以很轻松的移植到新版本上,而不会产生问题。请牢记一点:添加新的功能,请不要修改原有的内容。


API的设计目标

设计一个API要达到哪位目标呢?除了兼容性以外,也从Elliotte的讨论中提出一些目标。
API的正确性必须保证:
无论用户如何调用API,都不应该产生错误。

API的易用性:
API必须易于使用。通常易用性一向难以评价。但是有一个办法可以有效的提高易用性,就是编写大量范例代码,并将其很好的组织在一起,从而为用户提供API参考。(译注:个人认为一个好的FAQ可以提供各种API使用的范例。)
API必须易学:
很大程度上,API的易学和易用性是相似的,一般来说,易用也就易学。如果要使API易学,下列基本原则要遵循的:
API越小就容易学习;
文档应该有范例;
如果方便的话,尽可能将API与一些常用的API保持一致。例如如果要做一个资源访问的API,尽可能与J2SE中的IO使用一致,自然很容易学习。
(译注:如果你要关闭一个资源,就象Java的File,Connection一样,使用close,而不是destroy。)

API的运行速度必须够快:
Elliotte也是考虑了很久,才给出这一条。但是要在保证API简单而且正确的前提下,再来考虑API的性能问题。

API必须足够的小:
这里所说的小不仅是指编译后代码的文件比较小,而且更重要的是运行时占用的内存要小。之所以提出最小化的概念,还有一个原因:就是因为很容易为API添加 新的内容,但是要将一个内容从API中移出就很困难,所以不要随便向API中添加内容,如果不确定一项内容,就不要将它加入到API中。通过这样一个建议 或者说是限制,可以提醒一个API设计人员更加关注API中最重要的功能,而非一些枝节的问题。

因为考虑的过于详细,功能边界也就越大,所面对的需求也就越多,因此要提供的功能和可供用户调整的功能也就更加庞大,也就是说这种方法会使得API包含很多的功能,最终就是API膨胀性的增长。



如果设计的API过于庞大,必然会包含了许多不必要的方法,至少有许多public的类和方法,对于大部分用户是用不到,也会占用更多的内存,并降低运行效率。这违反了通常的一个设计原则:“不要让用户为他使用不到的功能付出代价”。




下面在设计API时的一些技巧
不变类是一个很好的设计,如果一个类可以设计成不变类,就不要用可变类!如果详细了解这样设计的原因,请参见《Effective Java》的第十三条。如果没有读过这本书,很难设计出好的API。

另外字段信息应该是private的,只有static和final修饰的字段信息才能变成public,允许外部访问。这一条是一个非常基础的原则,这里提到这个原则,只是因为在早期的API设计时,有些API违反了这个原则,这里不再给出一个例子了。

避免奇怪的设计。对于代码,已经有了许多约定俗成的方法了,如get/set方法,标准的异常类。即使觉得有了更好的方法,也尽量避免使用这些方 法。如果使用了一些奇怪的方法名称,这样使用API的用户必须学习新的内容,不能按照原有的习惯来理解代码,会增加学习成本,也会增加误用的可能。

一个类如果不是抽象类,就应当是final类不可被继承。《Effective Java》第15章给出了足够的理由,同时也建议每个方法在默认情况下都应该是final(目前Java正好相反)(译注:这点我也赞成,觉得方法默认为 final更好,但是目前Java发展到当前情况下,已经不可能大规模的更改了,不能不说是Java语言的一个遗憾之处,C#这一点处理的更好,默认为 final,后面的留言也提到这个了)。如果一个方法可以被覆盖,一定要在文档中清楚的描述这个方法被覆盖后带来的后果,最好还能提供一些例子程序进行演 示以避免开发人员误用。

总结:
设计需要演化,否则会降低它的价值。
先保证API的正确性,在此基础上再追求简单和高效
接口并不如想像中的那么有用。
谨慎分包可以带来更多的价值。
不要忘记阅读《Effective Java》(译注:难道作者和Josh Bloch's有分赃协议不成。)

5/09/2008

Tunapie - Linux下的网络电台

Tunapie,一个可以自动从网络上下载网络电台和视频流媒体的列表软件。在Windows下用过WinAMP的用户应该都有印象WinAMP有一个可 以从网络更新列表,用户可以选择电台或视频流媒体。Tunapie就是WinAMP这个功能的独立软件,当然是For Linux的。
要播放 Tunapie提供的列表里的网络电台或视频流媒体,你需要保证系统里安装有XMMS音频播放器和totem/xine/mplayer任意一个视频播放 器,这样子才可以播放Tunapie提供的列表里的资源。当然,如果你有其它类似的软件同样播放能力,你可以在Tunapie的Preferences里 选择设置播放器。
官网:
http://tunapie.sourceforge.net/

How To Design a (module) API

A description of good design practices when design any APIs with especially closer look to the case of an API based on NetBeans infrastructure is content of this evolving document.

What is a API?
As the reason why API is used is to allow communictation between teams and applications in order to allow separated and distributed development the answer to question what is API shall include everything that influences such kind of development.

The API is everything that another team or application can depend on:

  • method and field signatures - communication between applications is usally about calling functions and passing data structures between each other. If there is a change in the names of the methods, in their arguments or in structure of exchanged data, the whole program often does not even link well, nor it can run.

  • files and their content - many applications read various files and their content can influence their behaviour. Imagine application relying on the other one to read its configuration file and modifying its content prior to invoking the application. If the format of the file changes or the file is completely ignored, the communication between those applications gets broken.

  • environment variables - for example behaviour of cvs can be influenced by the variable CVSEDITOR.

  • protocols - opening a socket and being prepared to interpret streams sent there, or putting or reading a data to clipboard or during drag and drop again establishes an API that others can depend on.

  • behaviour - a bit harder to grip, but important for the separation as well is the the dynamic behaviour. How the program flow looks like - what is the order of execution, what locks are being held during calls, in which threads a call can happen, etc.

  • L10N messages - because the localization to a certain language is usually developed and distributed by somebody other than the person that writes the code, yet both of them have to use the same keys (NbBundle.getMessage ("CTL_SomeKey")), there is inherently a contract between the writer of the code and the translator - an API of sorts.
The important thing with respect to distributed development is to be aware of possible APIs - of possible things other code can depend on. Only by identifying such aspects of own application one can develop it in a way that will not hurt cooperation with seperately developed applications.

web resource:
google video:http://video.google.com/videoplay?docid=-3733345136856180693
book in amzoe The Definitive Guide to API Design (The Definitive Guide) (Hardcover)