IT博客-哈库拉玛塔塔——tjitty-随笔分类-软件开发

eclipse集成svn提示This client is too old to work with解决方案

tjitty — Tue, 22 Jun 2010 09:53:00 GMT

http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA

这个网站有明确的说明,

Changelog: http://subclipse.tigris.org/subclipse_1.6.x/changes.html
Eclipse update site URL: http://subclipse.tigris.org/update_1.6.x
Zipped downloads: http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240

另外有网站也有解决办法:http://wuaner.javaeye.com/blog/569285

项目中使用的是1.4.7,作为eclipse的插件装的；后来又在机子上装了个TortoiseSVN 1.6.5。遇到的问题：

引用

This client is too old to work with working copy 'D:\MyEclipseWorkspace\projectName\WebRoot\WEB-INF\lib'; please get a newer Subversion client.

估计是不经意中使用了1.6.5做了提交导致的问题。

官方解决办法：
http://subversion.tigris.org/faq.html#working-copy-format-change
http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py
所以，装python先：
http://code.google.com/p/smallfish/（python 官网下载被屏蔽）
安装后记得在环境变量的path中追加python安装路径："安装盘符:\Python26"

然后cmd下运行：

Python代码
1.CMD >change-svn-wc-format.py D:\MyEclipseWorkspace\projectName\WebRoot\WEB-INF\lib 1.4 --verbose
CMD >change-svn-wc-format.py D:\MyEclipseWorkspace\projectName\WebRoot\WEB-INF\lib 1.4 --verbose

关于svn官网提供的版本转换方式：

引用

CMD:\>change-svn-wc-format.py --help
usage: change-svn-wc-format.py WC_PATH SVN_VERSION [--verbose] [--force] [--skip-unknown-format]
change-svn-wc-format.py --help

Change the format of a Subversion working copy to that of SVN_VERSION.

--skip-unknown-format : skip directories with unknown working copy
format and continue the update

tjitty 2010-06-22 17:53 发表评论

使用 UNIX find 命令的高级技术

tjitty — Wed, 20 Jan 2010 01:55:00 GMT

转载自：http://www.ibm.com/developerworks/cn/aix/library/es-unix-find.html#listing1

没有什么能比得上探索和发现新的人、地方、事物所带来的刺激。领域可能有所不同，但有些原则却是一样的。在这些原则中，有一条是记录下您的旅程，另一条则是了解和使用工具。

UNIX® 操作系统很像一片广阔的、未经标识的荒野。当您在这样的领域中旅行时，可以选择一些日后能够给您带来帮助的工具。find 命令便是这样一种工具。find 命令不仅能够简单地用来定位文件，正如本文将介绍的那样，它还可以自动地执行其他 UNIX 命令的序列，其中使用所查找到的文件名作为输入。

Find 的有关限制

所有称职的操作系统都具有协助您查找相关内容的工具。与大多数工具不同的是，UNIX 中的 find 命令可以自动地对其查找到的文件执行许多操作。

图形用户界面 (GUI) 中的标准 find 工具允许您对所查找到的文件进行一些常规操作任务：您可以将它们标记为剪切、复制和粘贴，您可以将它们移动到一个新的位置，并且可以使用创建它们的应用程序来打开它们。这些操作涉及到两个或更多的步骤，并且不是自动完成的，即首先查找到文件，然后使用 GUI 为下一步的操作对它们进行标记。这种方法对许多用户来说没有问题，但是 Explorer 需要的不仅是这些。

UNIX 的 find 命令可以删除、复制、移动和执行其查找到的文件。另外，使用 -exec 参数可以根据您所需要的 UNIX 命令的序列来自动地运行这些文件。它甚至可以在对任何文件执行这些操作前，进一步让您进行确认。

简化文件系统的管理

与大多数 UNIX 命令一样，UNIX find 命令具有一长串令人生畏的选项和开关，它们会阻碍人们深入地学习该命令，但正是因为其范围广阔，真正的 Explorer 并不会被它们吓倒。一条好的通用原则在简化一个复杂问题时都会经过漫长的过程。启动一个 xterm，并尝试执行下面的命令：

$ find . -name *.gif -exec ls {} \;

-exec 参数中包含了真正有价值的操作。当查找到匹配搜索条件的文件时，-exec 参数定义了将对这些文件进行什么操作。该示例告诉计算机进行如下操作：

从当前文件夹开始往下搜索，紧跟在 find 之后，使用点号 (.)。
定位所有名称以 .gif 结尾的文件（图形文件）。
列出所有查找到的文件，使用 ls 命令。

需要对 -exec 参数进行更深入地研究。当查找到匹配搜索条件的文件名时，find 命令执行 ls {} 字符串，用文件名和路径代替文本 {}。假设在搜索中查找到 saturn.gif 文件，find 将执行如下所示的命令：

$ ls ./gif_files/space/solar_system/saturn.gif

本文余下的内容建立在这条一般原则之上：仔细地使用 find 命令可以让 UNIX 文件系统的管理工作变得更加容易。例如，如果您使用了 -fstype 参数，find 命令可以根据查找到的文件所处的文件系统的类型来对命令进行相应的处理。在 find 命令对查找到的文件执行相应命令前将对您进行提示，这通常是非常有用的，您可以使用 -ok 参数告诉它继续执行该操作，接下来我们将对其进行介绍。

可选的执行

-ok 是 -exec 参数的一个重要的替代项，它的行为和 -exec 一样，但它会提示您是否要对文件运行相应的命令。假设您想要删除 home 目录中的大部分 .txt 文件，但希望能够逐个文件地执行该操作。像 UNIX 中的 rm 命令那样的删除操作是很危险的，因为当使用像 find 这样的自动化处理方式来查找文件时，它可能一不小心会删除重要的文件，您也许希望在删除这些系统查找到的文件之前对其进行仔细检查。

下面的命令列出了您的 home 目录中所有的 .txt 文件。要删除这些文件，必须在 find 命令通过列出文件名提示您确认操作时输入 Y 或者 y：

$ find $HOME/. -name *.txt -ok rm {} \;

它列出了查找到的每个文件，并且系统将暂停以等待您输入 Y 或者 y。如果您按下 Enter 键，系统将不会删除该文件。清单 1 显示了一些示例结果：

清单 1. 示例结果

< rm ... /home/bill/./.kde/share/apps/karm/karmdata.txt > ?
< rm ... /home/bill/./archives/LDDS.txt > ?
< rm ... /home/bill/./www/txt/textfile1.txt > ?
< rm ... /home/bill/./www/txt/faq.txt > ?
< rm ... /home/bill/./www/programs/MIKE.txt > ?
< rm ... /home/bill/./www/programs/EESTRING.txt > ?
.
.
.

系统将在每个问号之后暂停，在本示例中，每次都按下了 Enter 键以继续处理下一个文件。（没有删除任何文件。）-ok 参数允许您控制每个查找到的文件的自动化处理过程，这样就添加了一种避免自动删除文件的安全措施。

如果在使用 -ok 参数时涉及到过多的文件，那么一个好的方法是先运行带 -exec 的 find 命令以列出所有将要删除的文件，然后在经过检查确保其中不会删除重要的文件后，再次运行该命令，其中用 rm 代替 ls。

-exec 和 -ok 都非常有用，您必须确定在当前情况下哪一个能够更好的工作。请记住，安全第一！

创造性地使用 find

您可以使用 find 命令执行各种各样的任务。本部分内容提供了使用 find 命令来管理文件系统的几种方式的示例。

为了保持简单，这些示例都避免了使用涉及通过管道将一个命令的输出传递到另一个命令的 -exec 命令。然而，您完全可以根据自己需要在 find 命令的 -exec 子句中使用这样的命令。

清除临时文件

您可以使用 find 命令来清除目录或子目录中在正常使用过程中生成的临时文件，这样可以节省磁盘空间。要实现该操作，请使用下面的命令：

$ find . \( -name a.out -o -name '*.o' -o -name 'core' \) -exec rm {} \;

括号中的文件掩码 标识出了需要删除的文件类型，每个文件掩码的前面都有 -name。该列表可以扩展为包括您需要清除的系统中的任何临时文件类型。在代码的编译和连接过程中，程序员及其工具会生成示例中的那些文件类型：a.out、*.o 和 core。其他的用户通常也会生成类似的临时文件，可以使用如 *.tmp、*.junk 等文件掩码来对命令进行相应的编辑。您可能还发现将命令放入一个称作 clean 的脚本中非常有用，当需要清除一个目录中的内容的时候就可以执行该脚本。

复制目录中的内容

find 命令允许您复制目录中的全部内容，同时保持每个文件和子目录的权限、时间和所有权。要完成该操作，需要组合使用 find 和 cpio 命令，如下所示：

清单 2. 组合使用 find 和 cpio 命令

												
$ cd /path/to/source/dir

$ find . | cpio -pdumv /path/to/destination/dir

cpio 命令是一个复制命令，它设计用来将文件复制到或复制出一个 cpio 或 tar 存档文件，并自动地保持文件和子目录的权限、时间和所有权。

列出文本文件的第一行内容

有些人使用每个文本文件的第一行作为标题或者文件内容的描述。可以使用列出文件名和所有文本文件第一行内容的报表更方便地对大量的文本文件进行筛选。下面的命令在报表中列出了您的 home 目录中所有文本文件的第一行内容，便于进一步地根据需要使用 less 命令进行检查：

清单 3. less 命令

												
$ find $HOME/. -name *.txt -exec head -n 1 -v {} \; > report.txt

$ less < report.txt

维护 LOG 和 TMP 文件的存储空间

要为生成大量文件的应用程序维护 LOG 和 TMP 文件存储空间，可以将下列命令放入到每天运行的 cron 任务中：

清单 4. 维护 LOG 和 TMP 文件存储空间

												
$ find $LOGDIR -type d -mtime +0 -exec compress -r {} \;

$ find $LOGDIR -type d -mtime +5 -exec rm -f {} \;

第一个命令找到 $LOGDIR 目录中所有包含在 24 小时内 (-mtime +0) 进行了修改的数据的目录 (-type d)，并对它们进行压缩 (compress -r {}) 以节省磁盘空间。如果这些目录超过了一个工作周 (-mtime +5)，第二个命令则将其删除 (rm -f {})，以便增加磁盘上的可用空间。通过这种方式，cron 任务自动地根据您所指定的时间窗口对目录进行维护。

复制复杂的目录树

如果您想要将复杂的目录树从一台计算机复制到另一台计算机，同时保持副本权限以及 User ID 和 Group ID（UID 和 GID——操作系统所使用的标记文件的所有权的数值），并且不复制用户文件，那么就需要再次使用 find 和 cpio：

清单 5. 复制复杂的目录树

$ cd /source/directory

$ find . -depth -print | cpio -o -O /target/directory

查找不指向任何地方的链接

要查找不指向任何地方的链接，可以使用带 find 的 perl 解释器，如下所示：

$ find / -type l -print | perl -nle '-e || print';

该命令从最顶层目录 (/) 开始，列出由 perl 解释器确定不指向任何地方 (-nle '-e || print') 的所有链接 (-type l -print)，关于 Unix Guru Universe 站点中这个技巧的更详细的信息，请参阅参考资料部分。如果您想要删除这些文件，可以进一步使用管道将输出传递到 rm -f {} 命令。当然，Perl 可以在大多数的 UNIX 工具包中找到，它是许多功能强大的解释性语言工具中的一种。

定位和重命名无法打印的目录

在 UNIX 中，可能会有错误的或恶意的程序创建包含无法打印的字符的目录。定位和重命名这些目录，这样就可以更容易地检查并删除它们。要完成该操作，您首先需要在 ls 中包含 -i 开关，以获取该目录的索引节点的数值。然后，使用 find 将索引节点的数值转换为一个可以使用 mv 命令进行重命名的文件名：

清单 6. 定位和重命名无法打印的目录

$ ls -ail

$ find . -inum 211028 -exec mv {} newname.dir \;

列出长度为零的文件

要列出所有长度为零的文件，请使用下面的命令：

$ find . -empty -exec ls {} \;

在查找到空文件之后，您可以选择用 rm 命令来代替 ls 命令，以删除这些文件。

很明显，您对 UNIX find 命令的使用受到知识和创造性的限制。

结束语

使用 find 命令，可以轻松地浏览 UNIX 文件系统中丰富的内容。很值得花时间来试验该命令，并了解它能为您做些什么。正如本文中所列出的示例，您可以通过许多创造性的方式来使用 find，这样可以轻松地浏览和管理文件系统，并且充满乐趣。

tjitty 2010-01-20 09:55 发表评论

Agile Scrum - Understanding Scrum Rules

tjitty — Fri, 30 Oct 2009 05:17:00 GMT

A gile Scrum - Understanding Scrum Rules

Feb 2008: Agile Scrum - An Overview
http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm

Mar 2008: Agile Scrum - Team Composition
http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm

Understanding Scrum Rules
For Agile Scrum to be successful, you must have buy-in from the highest stake holders to the individuals doing the work and every individual must follow the rules. Below are the rules for Scrum:

Obtain Number of Hours Commitment up Front - Before beginning an Agile 30-day sprint, each team member must commit to a certain number of hours for the 30 day sprint.
Gather Requirements / Estimates up Front - The Product Manager will specify the sprint goal and the team will gather the requirements and provide an estimate up front. Once the estimates are done, the requirements are prioritized and only the ones that will fit into the sprint are worked on (based on estimated hours of all tasks vs. hours committed to by team members).
Enter Time Daily - Each person on the team agrees to enter their actual hours and estimated hours remaining EVERY DAY.
Daily Builds - Each programmer will check code in daily or more frequently if possible. The checked in code must be compilable. An automated process will create daily builds to prevent manual merging of code and allowing the Quality Assurance Engineer to test features of the sprint.
No new Requirements for a Sprint - No new requirements can enter into the sprint unless all features of the sprint are completed. Management and other parties that are not directly involved in completing the features for the sprint are not allowed to direct actions of team members on items not included in the sprint. If an emergency feature is required by management, the sprint must be aborted and a new sprint must begin with the new feature set.
Keep the Daily Scrum Meetings Short - Daily Scrum meetings are held to determine what things were done since the last Scrum meeting, what things will be done in the next Scrum meeting and what impediments stand in the way of any person on the team. The Daily Scrum meeting is designed to be completed in 15 minutes. If it takes 30 minutes, this is OK, but it should not extend longer than that without a solid business reason for it. Team members that show up to Daily Scrum meetings late are required to pay the Scrum Master a $1 fine.
Code Inspections are Paramount - Upon completing a particular feature, the programmer should illustrate the feature to the team and show the code that drives the feature. The team should inspect the code for re-usability, cleanness, and adherence to established coding standards.

What's Next?
Upcoming newsletters will discuss the following topics:

Agile Scrum - Scrum Kickoff and Product Backlog
Agile Scrum - The Daily Scrum Meeting
Agile Scrum - Reporting and Metrics
Agile Scrum - Retrospectives
Agile Scrum - Site specific variants of Scrum

Helpful Templates

Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf

Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Software Planner - http://www.SoftwarePlanner.com

Agile Training - http://www.PragmaticSW.com/Services.asp

About the Author

Steve Miller is the President of Pragmatic Software (http://www.PragmaticSW.com). With over 23 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software. You can read other newsletters at http://www.PragmaticSW.com/Newsletters.asp.

tjitty 2009-10-30 13:17 发表评论

Agile Scrum - Scrum Kickoff and Product Backlog

tjitty — Fri, 30 Oct 2009 05:01:00 GMT

A gile Scrum - Scrum Kickoff and Product Backlog

Feb 2008: Agile Scrum - An Overview
http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition
http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules
http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm

30 Day Sprints
Agile differs from standard Waterfall development in that development has a smaller timeframe with a smaller feature set. Agile Scrum implements releases every 30 days (called 30 day sprints). Upon completing a sprint, you can move the software to production (if production-ready) or move into another 30 day sprint to implement additional features.

Pragmatic Agile Development (PAD) and Agile Scrum
It is important to note that the way we use Agile Scrum varies from a purist version of Scrum as we have made modifications to Agile Scrum to work well for our development environment. Our version of Scrum is called Pragmatic Agile Development (PAD) and differs from a more purist Scrum implementation in these ways:

Scrum Planning - In Scrum, planning for an upcoming sprint is accomplished in 1 day, in PAD the planning spans 1 week. This is because we write more detailed specifications than a purist Scrum does (see next bullet item).
User Stories vs. Specifications - In Scrum, requirements are written on index cards (called User Stories) and does not contain prototypes or detailed explanations of the feature set. In PAD, we spend time detailing the requirement specifications with prototypes to ensure that time is well spent on the feature, reducing rework.
30 Day Sprints - In Scrum, development is done in 30 calendar days. In PAD, development is done in 30 working days, skipping holidays. This provides us with more evenly distributed sprints.
Team Composition - In Scrum, developers are expected to perform all duties (analysis, design, coding, test case development, execution, and documentation). In PAD, developers help with analysis and design and perform all the coding. We have specialized team members (Software Quality Engineers) for test case development and specialized team members for documentation. We do this because our experience has shown that we need specialists in these areas.

The goal of software development is to deliver your software quickly and with high quality, so tweaking a methodology to meet your needs makes sense.

Product Backlog
As your existing clients request new features or as you come up with new features that make the product more marketable, these items are called the Product Backlog. In the PAD Scrum Planning week, you will set the goal for the sprint and prioritize product backlog items to determine which ones can fit within the sprint.

Scrum Kickoff and Planning Week
In the purest version of Scrum, you have only 1 planning day for the sprint and requirements are written on index cards (called User Stories). We believe this is not enough time or detail to deliver quality features, as we have shown that taking the time to fully detail the feature saves time once the client (or your internal team) receives the features, it takes less re-work. So you should devote a week to planning.

Each release (or sprint) will begin with a PAD Planning Week. The first day of the PAD Planning week will begin with defining the goal for the sprint and identifying features you wish to have in the release (from the product backlog), in priority order.

In the purest version of Scrum, releases are done in 30-day sprints. The 30 days are calendar days, so with holidays and weekends, this may equate to 19 to 23 working days. We have found that sprints are best implemented in 30 working day sprints (excluding holidays), as this provides more evenly distributed sprints. The 30-day sprint begins after the PAD Planning week concludes.

During the first day of the PAD Planning Week, each team member will identify the number of hours they can contribute to the sprint, allowing you to determine the maximum velocity for the sprint (velocity simply means the number of hours that can be worked in the sprint). By knowing the maximum velocity, you can determine what features will fit in the sprint. After the high level features are identified in the first day of PAD Planning, you will assign specific work order numbers to each high level feature and assign a set of work orders to each team member.

The team members will spend the week defining the detailed requirements for their assigned work orders. Note: Work Orders are simply a hard copy document of each functional specification.

User Interface Design Guidelines
Because you will have multiple team members creating requirements, it is critical for your team to define your user interface styles in a style guide and ensure all your team members adhere to those standards.

Decomposing Work Orders
Since sprints are limited to 30 working development days, you will be forced to make hard decisions about the features that can fit into the sprint. When you are assigned a work order for a feature of the sprint, you should decompose the feature into multiple work orders so that you can prioritize specific pieces of the feature.

For example, let’s assume that you are redesigning your user interface for a more pleasing look and feel, and the aesthetics are the most important issue for the sprint. You also would like the screens to be more user-friendly, so you have some issues you wish to address (like prompting to save changes when changes are made and they switch between tabs on the screen). In this case, you should decompose these into 2 separate work orders (one for the aesthetics and another for the tab switching). By doing this, it allows you to prioritize the tab switching lower than the aesthetics.

User Stories vs. Work Orders
As mentioned, we favor work orders over a user story. Here is an example of a user story written on an index card:

Here is an example of a work order, notice how much more detail is presented and how having a prototype of the item you are delivering reduces ambiguity of the feature:

If you would like an example of a work order, download one here: http://www.pragmaticsw.com/Template_WorkOrder.doc. Other templates for the PAD process are available at http://www.pragmaticsw.com/templates.

What's Next?
Upcoming newsletters will discuss the following topics:

Agile Scrum - The 30 Day Sprint and the Daily Scrum Meeting
Agile Scrum - Reporting and Metrics
Agile Scrum - Retrospectives
Agile Scrum - Site specific variants of Scrum

Helpful Templates

Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf

Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Software Planner - http://www.SoftwarePlanner.com

Agile Training - http://www.PragmaticSW.com/Services.asp

tjitty 2009-10-30 13:01 发表评论

How to determine that your OS is 64-bit compliant

tjitty — Tue, 14 Jul 2009 14:05:00 GMT

How can I determine if my computer/operating system is 64-bit?

Title		How to determine that your OS is 64-bit compliant
Author		Pete Huckelba, StataCorp
Date		June 2005; updated February 2009

Windows

If you are using Windows Vista, click Start -> Control Panel -> System and Maintenance -> System. The System type: line will give you the Operating System type:

If you are using Windows XP, click Start -> Run and type dxdiag. If a Windows dialog box is displayed asking if you want to verify your drivers, you can safely click No and continue. When the program has finished loading, you should see something similar to one of the following images:

The Operating System line, refers to Windows x64 or 64-bit edition. The last image above specifies the processor Itanium, which is a 64-bit processor.

Mac

Select About this Mac from the Apple menu. The text below Mac OS X will give the operating system version, and the Processor line will give you the processor type.

Mac OS X 10.5 (or greater) is a 64-bit operating system. Intel Core 2 Duo, Intel Xeon, and PowerPC G5 are 64-bit processors. However, 64-bit Stata for Mac is available only for 64-bit Intel-based Macs.

All currently shipping Macs have a 64-bit processor and a 64-bit operating system.

Unix (IBM-AIX, Sun Solaris)

IBM-AIX

The getconf command will return the configuration of your machine. Since you are looking only for the kernel parameters, you should type

[cph@anna ~]$ getconf -a | grep KERN
KERNEL_BITMODE: 64

If that fails or does not return a result, try the file command.

[cph@anna ~]$ file /usr/lib/boot/unix*
/usr/lib/boot/unix: 64-bit XCOFF executable or object module not stripped
/usr/lib/boot/unix_64: 64-bit XCOFF executable or object module not stripped
/usr/lib/boot/unix_mp: executable (RISC System/6000) or object module not stripped
/usr/lib/boot/unix_up: executable (RISC System/6000) or object module not stripped

[cph@ozona ~]$ file /usr/lib/boot/unix*
/usr/lib/boot/unix: symbolic link to /usr/lib/boot/unix_up.
/usr/lib/boot/unix_kdb: executable (RISC System/6000) or object module not stripped
/usr/lib/boot/unix_up: executable (RISC System/6000) or object module not stripped

We can see that 'anna' is a 64-bit capable platform, and 'ozona' is only 32-bit.

Sun Solaris

Sun's platforms transitioned to 64-bit over a period of time, making identifying the platform for 64-bit compliance tricky. Sun has stated:

Sun has implemented its 64-bit operating system in phases. The Solaris 2.5 Operating Environment provided support for increased precision with 64-bit math and also included support for 64-bit asynchronous I/O. The Solaris 2.6 Operating Environment added support for large datasets with large (1 Terabyte) filesystems while allowing co-existence of 32-bit and 64-bit files. Beginning with the Solaris 7 Operating Environment, Sun introduced support for large virtual address spaces with a full 64-bit operating system. Sun began shipping 64-bit hardware in 1995. By phasing in operating system support for 64-bits Sun has provided 64-bit features as the market has demanded them while guaranteeing compatibility for existing 32-bit applications.

To determine what kind of binaries your Solaris machine can run, try the following:

								
										eden:/home/cph: isainfo -v
										
										64-bit sparcv9 applications

   32-bit sparc applications

You can see that this Solaris machine is capable of running 32-bit as well as 64-bit applications. If isainfo fails, running a 64-bit application on your Sun will generally not be possible, unless of course isainfo is not in your path or has not been installed. You can also use the uname command to glean more information:

								
										eden:/home/cph: uname -a
										
   SunOS eden 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-5_10

								
										lagrange:/usr/users/cph: uname -a
										
   SunOS lagrange 5.5.1 Generic_103640-29 sun4u sparc SUNW,Ultra-1

SunOS/Solaris versions map to the following:

SunOS	SOLARIS
5.3	2.3
5.4	2.4
5.5	2.5
5.5.1	2.5.1
5.6	2.6
5.7 or greater is 64-bit compliant	2.7 or greater is 64-bit compliant

While all UltraSparc processors are capable of 64-bit computing, the OS release level may be the limiting factor. In the above excerpt, 'eden' (SunOS 5.8) is a fully compliant 64-bit platform, and 'lagrange' (SunOS 5.5.1) is a 64-bit UltraSparc limited to 32-bit computing.

Linux

Linux users should type the uname command. Depending on the platform, you may see

				
						[cph@gaylord ~]$ uname -a
						
Linux gaylord.stata.com 2.6.11-1.27_FC3 #1 Tue May 17 20:24:57 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

				
						[cph@caddo ~]$ uname -a
						
Linux caddo.stata.com 2.6.9-5.0.5.EL #1 SMP Fri Apr 8 14:20:58 EDT 2005 ia64 ia64
ia64 GNU/Linux

				
						[cph@tango ~]$ uname -a
						
Linux tango.stata.com 2.6.10-1.771_FC2smp #1 SMP Mon Mar 28
01:10:51 EST 2005 i686 i686 i386 GNU/Linux

In the above listing, 'gaylord' (x86_64 GNU/Linux) and 'caddo' (ia64 GNU/Linux) are 64-bit compliant. 'tango' (i386 GNU/Linux) is only a 32-bit platform.

tjitty 2009-07-14 22:05 发表评论

Scrum + Manual Testing methodology (for WEB apps.)

tjitty — Fri, 13 Feb 2009 06:16:00 GMT

Scrum + Manual Testing methodology (for WEB apps.)

Submitted by Ainars Galvans on Fri, 19/09/2008 - 07:51. agile

I believe there are two wrong ways to add the formal QA to Scrum: to give up manual testing skills and learn automation or give up agile principle of quick feedback and test one iteration behind. There is a better way and I’ve seen some articles struggling around with generic phrases like collaboration, optimization, exploratory testing. But none describing the methodology.
What follows is a theoretical research (based on different resources) trying to define such a methodology. The main idea is to add new role (beside the team, scrum master and project owner) called a tester. The methodology sounds very logical. Why nothing like this has been published beforehand? Am I missing a lot of issues with this methodology? Anyone willing to apply it?! Please e-mail ojnjars@inbox.lv if you are willing to contribute this research.

Context – Assumptions
To make things easier we make several assumptions – clarification of development project specifics. So we will describe them as assumptions here:
1. Development Scrum consists of 2 week sprints
2. The software is a web based with certain data in database. The role of tester will include testing software in “QA environment”, while developers are still doing unit tests in their environment which is not as close to production one.
3. It is decided that software deployment in “QA environment” should follow the manual installation process the same as it will take place in production environment. It optionally needs smart decision if to redeploy data into database. The process may take up to 30 minutes and is never done this way by developers in their environment
4. The process of creating installation package (build process) may also take up to 30 minutes, so will be executed once per night (nightly build)

Day 1. Sprint Planning
During the first day of a spring – sprint planning meeting – tester participates in order to help to define acceptance criteria (by asking what if questions to product owner) and estimating testing effort for stories. It may appear that there are stories requiring a little development effort but a lot of testing effort. Story selection may be changed to disallow too much stories of such type into one sprint. Alternatively part of testing activities may be postponed, creating a separate story (adding what I would call “quality debt”) and adding to backlog.

Day 2. Test Case Drafting
A tester works: one day behind” the team. The second day of a sprint is dedicated by tester to draft initial set of test cases for each features included in the sprint.

Day 3-8. Normal days
Each day starting day 3 of sprint in the morning tester installs latest nightly build (manually using installation procedure/instructions supplied by development team) to QA environment, do fast smoke tests if they fail and emergency fixes are applied by the team.
Features developed yesterday shall be tested today by tester. As required tester communicates with each developer to transition the knowledge of the feature functionality. Tester must also update (complete) Test Cases in the process of testing as more test ideas may come out during Exploratory Testing. If a feature testing requires too much effort or tester discovers too much ideas and can’t accomplish testing within the day he create new story ticket for further feature investigation. If the ticket is not closed by the end of a sprint it appears to be “Quality Debt” and must be announced to product owner for prioritization.
Because developers do unit testing most of the features should pass acceptance criteria. However if for any reason they do not pass them in QA environment, QA may return ticket to the team. If acceptance criteria are met but there are more bugs around, tester reports them separately, sending the initial story to End-To-End testing. Tester also has to do wider investigation (based on project quality goals) and report any usability suggestions, performance, security or other potential treats. Such bugs must be assigned to Product Owner if they don’t directly break the acceptance criteria of a story. Bugs that (developer) team disagrees with or appears to require too much effort also get assigned to Product Owner. They have to be addressed during sprint retrospective meeting. So it appears that during sprint retrospective no feature could be demonstrated if it has an open bug against it assigned to anyone but product owner.

Day 9 – The QA day
Because tester works one day behind, the day 8 of the sprint shall be the last day of a new feature development. That is the reason why day 9 can be dedicated by team to bug fixing, re-factoring and analysis of new features which might be included into next sprint i.e. next sprint preparation.

Day 10 - retrospective meeting
In order to demonstrate a feature in retrospective meeting it should be implemented; tested and all bugs either fixed or assigned to Product Owner for clarification (otherwise feature is postponed to next sprint). Tester should demonstrate that features meet acceptance criteria and demonstrate the issues assigned to product owner if any. Product Owner should decide and prioritize those features/defects. The team participates in the meeting to qualify their performance and probably counter tester’s negative opinion. Tester also describes “Quality Debt” changes – what was not tested due to lack of time. Product owner may prioritize the postponed tests or even allow skipping them.

More QA stuff after sprint
Test Cases created during sprint shall be peer-reviewed by another tester at any time later. For example by End-To-End tester if there are any. Ideally review should be done during or by end of the day 10 so that tester has the feedback by next planning meeting, but it may be impossible. In any case tester is not forced to respond to review feedback (fix test cases and run additional test if identified) until the end of sprint (so that tester commitment during sprint planning is not compromised).
If more tests are identified during review they must be executed later and any defects discovered should be assigned to product owner (added to backlog).

Testing outside sprints
Still there are types of tests that are not directly related to functionality implemented by sprints. For example non-functional tests: to validate that given architecture satisfies high availability requirements. Actually the tester may not have enough skills to do performance tests and a separate team or person may be assigned to do performance testing based on agreed schedule.
More over it is highly welcome to develop system-level automated regression tests (based on, but not necessarily repeating manual test cases) along with developer created unit tests. Those tests will aim for different type of regression bugs. This activity may also take place with a significant delay to feature implementation.
The tester should make a smart decision to nominate the build that was especially successful (without critical bugs) to be installed to the special environment such as for performance test or test automation environment.

From: http://www.testingreflections.com/node/view/7378

tjitty 2009-02-13 14:16 发表评论

Agile Scrum - An Overview

tjitty — Fri, 13 Feb 2009 06:13:00 GMT

A gile Scrum - An Overview

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is the first in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

So what is Agile?
According to Wikipedia, Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration. By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner. This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production. Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.

So what is Scrum?
Scrum is process of implementing Agile, where features are delivered in 30 day sprints. Scrum borrows its name from Rugby, where a sprint is the process of stopping play, then vigorously playing until the sprint ends and a new one begins. The same idea applies here, where you define the requirements for a 30 day sprint and work on them with vigor for 30 days without being sidetracked by other things or having things re-prioritized. A specific feature is not recognized as being completed until it is analyzed, designed, coded, tested, re-factored and documented. At the end of the 30 day sprint, most features defined in the 30-day sprint should be completed. If some did not get finished (because of being underestimated), the uncompleted features can be moved to a later sprint. A sprint is considered successful if all the completed features have high quality and can be put into production (or beta) upon ending the sprint.

Do Team Member Responsibilities Change?
Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspection, and ensuring everyone plays by the rules.
The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation.

So how does Scrum Work on a Day-by-Day Basis?
Scrum begins with an 8 hour Scrum Kickoff Meeting. The Scrum Kickoff meeting is divided into (2) 4 hour segments, where you first determine what features are desired for the 30 day sprint. The last 4 hours are used to provide rough estimates for the items identified for the sprint. If the estimates exceed the available resources, the features are prioritized and less important features are dropped from the sprint. An important component of Scrum is using a time-box approach, where meetings and events have a definite time period (e.g. no more than 8 hours for the kickoff meeting) and this time-box is strictly enforced. Once the features are locked in for the 30-day sprint, no changes are allowed (new features can not be introduced until the next sprint). When estimating features for a sprint, the estimates must include time for analysis, design, coding, testing, re-factoring, and documentation. A feature is not considered complete until all those things are done.

Each day, a Daily Scrum Meeting is held to determine how the features are progressing. The meeting is no longer than 15 minutes, and each team member is asked 3 questions:

What have you accomplished since the last Daily Scrum Meeting?
What will you do before the next Daily Scrum Meeting?
Is there anything that is impeding your progress (and remedies are discussed)?

From a programmer's perspective, Scrum development is a new paradigm which is very empowering but does require them to follow specific rules:

Code is only checked out for the duration needed to complete a feature. No exceptions. Most code will be checked in daily, as most features are broken down into small feature sets.
Time must be entered daily. For each feature, you will have estimated hours, actual hours and hours remaining to complete the feature. This information must be updated at the end of every day so that the ScrumMaster can determine if the release progress is trending as required.
Programmers are not allowed to be pulled off on tangent projects, they must stick to the features they have been assigned for the sprint.
All team members must attend the Daily Scrum Meeting and must be on time.
Code is compiled and deployed to a test server daily. Teams can use automated build tools to speed this process. Automated tests should be run against the daily releases to discover any issues introduced by the release.

Once a Scrum 30 day sprint is completed, all features that were completed can then been moved to a beta or production environment. Following the sprint is a Retrospective (post mortem), where team members discuss and document things that went well and things that can be improved upon in the next sprint.

What's Next?
Upcoming newsletters will discuss the following topics:

Agile Scrum - Team Composition
Agile Scrum - Understanding Scrum Rules
Agile Scrum - Scrum Kickoff and Product Backlog
Agile Scrum - The Daily Scrum Meeting
Agile Scrum - Reporting and Metrics
Agile Scrum - Retrospectives
Agile Scrum - Site specific variants of Scrum

Helpful Templates

Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Software Planner - http://www.SoftwarePlanner.com

Defect Tracker - http://www.DefectTracker.com

tjitty 2009-02-13 14:13 发表评论

转贴：高效率编辑器 VIM－操作篇，非常适合 VIM 新手

tjitty — Wed, 26 Mar 2008 12:09:00 GMT

虽然从很久前就开始用 VIM 了，但一直都是半

调吊子，翻来覆去只用自己会的命令。最近为了提高书写代码的效率，还有 coding 时候的乐趣，又重新钻研了一下 VIM，发现了一篇很好的 VIM 入门的文章，原文是英文版的，我觉得非常适合 VIM 使用入门，所以翻译了过来。这里是简单的介绍了 VIM 的操作方式，并没有说为什么要用 VIM，如果你想知道答案可以去 Google，VIM 被誉为编辑器之神。

这篇教程写了在不同工作模式下使用 VIM 的一些基本技巧——即插入模式（insert mode），命令模式（command mode），存取文件等。目的是帮助刚刚接触 VIM 的新手更加有效率的使用这个出色的编辑器。

说明：在这篇文章里面，代表 Ctrl + X——就是按住 Ctrl 键然后再按 X。而且你可以在很多情况下使用 :help command 来获得大部分命令的帮助，这个是 VIM 的内部帮助文件命令。

高效率移动

在插入模式之外

基本上来说，你应该尽可能少的呆在插入模式里面，因为在插入模式里面 VIM 就像一个“哑巴”编辑器一样。很多新手都会一直呆在插入模式里面，因为这样易于使用。但 VIM 的强大之处在于他的命令行模式！你会发现，在你越来越了解 VIM 之后，你就会花越来越少的时间使用插入模式了。

使用 h、j、k、l

使用 VIM 高效率编辑的第一步，就是放弃使用箭头键。使用 VIM，你就不用频繁的在箭头键和字母键之间移来移去了，这会节省你很多时间。当你在命令模式时，你可以用 h、j、k、l 来分别实现左、下、上、右箭头的功能。一开始可能需要适应一下，但一旦习惯这种方式，你就会发现这样操作的高效之处了。

在你编辑你的电子邮件或者其他有段落的文本时，你可能会发现使用方向键和你预期的效果不一样，有时候可能会一次跳过了很多行。这是因为你的段落在 VIM 看来是一个大的长长的行。这时你可以在按 h、j、k 或者 l 之前键入一个 g，这样 VIM 就会按屏幕上面的行如你所愿的移动了。

在当前行里面有效的移动光标

很多编辑器只提供了简单的命令来控制光标的移动（比如左、上、右、下、到行首/尾等）。VIM 则提供了很多强大的命令来满足你控制光标的欲望。当光标从一点移动到另外一点，在这两点之间的文本（包括这两个点）称作被“跨过”，这里的命令也被称作是 motion。（简单说明一下，后面会用到这个重要的概念）

这里是常用到的一些命令（motion）：

fx：移动光标到当前行的下一个 x 处。很明显，x 可以是任意一个字母，而且你可以使用 ; 来重复你的上一个 f 命令。
tx：和上面的命令类似，但是是移动到 x 的左边一个位置。（这真的很有用）
Fx：和 fx 类似，不过是往回找。
w：光标往前移动一个词。
b：光标往后移动一个词。
0：移动光标到当前行首。
^：移动光标到当前行的第一个字母位置。
$：移动光标到行尾。
)：移动光标到下一个句子。
( ：移动光标到上一个句子。

在整个文件里面有效移动光标

VIM 有很多命令，可以用来到达文件里面你想到达的地方。下面是一些在文件里面移动的命令：

：向下移动一屏。
：向上移动一屏。
G：到文件尾
numG：移动光标到指定的行（num）。（比如 10G 就是到第 10 行）
gg：到文件首
H：移动光标到屏幕上面
M：移动光标到屏幕中间
L：移动光标到屏幕下面
*：读取光标处的字符串，并且移动光标到它再次出现的地方。
#：和上面的类似，但是是往反方向寻找。
/text：从当前光标处开始搜索字符串 text，并且到达 text 出现的地方。必须使用回车来开始这个搜索命令。如果想重复上次的搜索的话，按 n。
？text：和上面类似，但是是反方向。
ma：在当前光标的位置标记一个书签，名字为 a。书签名只能是小写字母。你看不见书签的存在，但它确实已经在那里了。
`a：到书签 a 处。注意这个不是单引号，它一般位于大部分键盘的 1 的左边。
`.：到你上次编辑文件的地方。这个命令很有用，而且你不用自己去标记它。

高效的输入

使用关键词自动完成

VIM 有一个非常漂亮的关键词自动完成系统。这表示，你可以输入一个长词的一部分，然后按一下某个键，然后 VIM 就替你完成了这个长词的输入了。举个例子：你有一个变量名为 iAmALongAndAwkwardVarName 在你写的代码的某个地方。也许你不想每回都自己一个一个字母的去输入它。

使用关键词自动完成功能，你只需要输入开始几个字母（比如 iAmAL），然后按（按住 Ctrl，再按 N）或者。如果 VIM 没有给出你想要的词，继续按，直到你满意为止，VIM 会一直循环它找到的匹配的字符串。

聪明的进入插入模式

很多新手进入插入模式都只是用 i。这样当然可以进入插入模式，但通常不是那么合适，因为 VIM 提供了很多进入插入模式的命令。下面是最常用的一些：

i：在当前字符的左边插入
I：在当前行首插入
a：在当前字符的右边插入
A：在当前行尾插入
o：在当前行下面插入一个新行
O：在当前行上面插入一个新行
c{motion}：删除 motion 命令跨过的字符，并且进入插入模式。比如：c$，这将会删除从光标位置到行尾的字符并且进入插入模式。ct！，这会删除从光标位置到下一个叹号（但不包括），然后进入插入模式。被删除的字符被存在了剪贴板里面，并且可以再粘贴出来。
d{motion}：和上面差不多，但是不进入插入模式。

有效的移动大段的文本

使用可视选择（visual selections）和合适的选择模式

不像最初的 VI，VIM 允许你高亮（选择）一些文本，并且进行操作。这里有三种可视选择模式：

v：按字符选择。经常使用的模式，所以亲自尝试一下它。
V：按行选择。这在你想拷贝或者移动很多行的文本的时候特别有用。
：按块选择。非常强大，只在很少的编辑器中才有这样的功能。你可以选择一个矩形块，并且在这个矩形里面的文本会被高亮。

在选择模式的时候使用上面所述的方向键和命令（motion）。比如，vwww，会高亮光标前面的三个词。Vjj 将会高亮当前行以及下面两行。

在可视选择模式下剪切和拷贝

一旦你高亮了选区，你或许想进行一些操作：

d：剪贴选择的内容到剪贴板。
y：拷贝选择的内容到剪贴板。
c：剪贴选择的内容到剪贴板并且进入插入模式。

在非可视选择模式下剪切和拷贝

如果你很清楚的知道你想拷贝或者剪切什么，那你根本就不需要进入可视选择模式。这样也会节省时间：

d{motion}：剪切 motion 命令跨过的字符到剪贴板。比如，dw 会剪切一个词而 dfS 会将从当前光标到下一个 S 之间的字符剪切至剪贴板。
y{motion}：和上面类似，不过是拷贝。
c{motion}：和 d{motion} 类似，不过最后进入插入模式。
dd：剪切当前行。
yy：拷贝当前行。
cc：剪切当前行并且进入插入模式。
D：剪切从光标位置到行尾到剪贴板。
Y：拷贝当前行。
C：和 D 类似，最后进入插入模式。
x：剪切当前字符到剪贴板。
s：和x类似，不过最后进入插入模式。

粘贴

粘贴很简单，按 p。

使用多重剪贴板

很多编辑器都只提供了一个剪贴板。VIM 有很多。剪贴板在 VIM 里面被称为寄存器（Registers）。你可以列出当前定义的所有寄存器名和它们的内容，命令为“:reg”。最好使用小写字母来作为寄存器的名称，因为大写的有些被 VIM 占用了。

使用寄存器的命令为双引号 “。

比如：我们要拷贝当前行到寄存器 k。你应该按 “kyy。（你也可以使用 V”ky。为什么这样也可以呢？）现在当前行应该已经存在了寄存器 k 里面直到你又拷贝了一些东西进入寄存器 k。现在你可以使用命令 “kp 来粘贴寄存器 k 里面的内容到你想要的位置。

避免重复

令人惊奇的 . 命令

在 VI 里面，输入 . (小数点符号），将会重复你输入的上一个命令。比如，你上个命令为“dw”（删除一个词），VI 将会接着再删除一个词。

使用数字

使用数字也是 VIM 强大的而且很节省时间的重要特性之一。在很多 VIM 的命令之前都可以使用一个数字，这个数字将会告诉 VIM 这个命令需要执行几次。比如：

3j 将会把光标向下移动三行。
10dd 将会删除十行。
y3″ 将会拷贝从当前光标到第三个出现的引号之间的内容到剪贴板。

数字是扩展 motion 命令作用域非常有效的方法。

记录宏

有时候，你会发现你自己在文章的每段或者每行都重复相同的一系列动作。VIM 允许你记录一个宏来完成你的特殊需要。

qregister：记录宏到寄存器 register，这里 register 是任意的你的寄存器的名字。比如 qa，将会记录并且把宏存在寄存器 a 里面。
q：结束宏的记录。
@register：使用存在寄存器 register 的宏。比如 @a，将会使用存在寄存器 a 里面的宏。

必须要记住的是，宏只记录了你的系列按键并且重复执行它们。它们不是魔法。因为在 VIM 里面完成目的的方法有很多，所以有时候你要小心选择命令来记录你的宏。因为它们会在所有你要执行它的地方执行。

用 VIM 写代码

VIM 是一个用来写代码的绝好编辑器，因为它有一些特性是专门为程序员而设计的。这里是一些常用的：

]p：和 p 的功能差不多，但是它会自动调整被粘贴的文本的缩进去适应当前代码的位置。试一下！
%：匹配花括号、方括号、括号等。在一个括号的上面，然后按 %，鼠标就会出现在匹配的另外一半括号处。
>>：缩进所有选择的代码
<<：和上面类似，但是反缩进
gd：到达光标所在处函数或者变量的定义处。
K：在 Man 里面查找光标当前所在处的词。

tjitty 2008-03-26 20:09 发表评论

VI命令指导

tjitty — Wed, 26 Mar 2008 10:21:00 GMT

进入vi的命令

vi filename: 打开或新建文件，并将光标置于第一行首

vi +n filename: 打开文件，并将光标置于第n行首

vi + filename: 打开文件，并将光标置于最后一行首

vi +/pattern filename: 打开文件，并将光标置于第一个与pattern匹配的串处

vi -r filename: 在上次正用vi编辑时发生系统崩溃，恢复filename

vi filename....filename: 打开多个文件，依次进行编辑

移动光标类命令

h: 光标左移一个字符

l: 光标右移一个字符

space: 光标右移一个字符

Backspace: 光标左移一个字符

k或Ctrl+p: 光标上移一行

j或Ctrl+n: 光标下移一行

Enter: 光标下移一行

w或W : 光标右移一个字至字首

b或B : 光标左移一个字至字首

e或E : 光标右移一个字至字尾

): 光标移至句尾

(: 光标移至句首

}: 光标移至段落开头

{: 光标移至段落结尾

nG: 光标移至第n行首

n+: 光标下移n行

n-: 光标上移n行

n$: 光标移至第n行尾

H: 光标移至屏幕顶行

M: 光标移至屏幕中间行

L: 光标移至屏幕最后行

0: 光标移至当前行首

$: 光标移至当前行尾

屏幕翻滚类命令

Ctrl+u: 向文件首翻半屏

Ctrl+d: 向文件尾翻半屏

Ctrl+f: 向文件尾翻一屏

Ctrl＋b: 向文件首翻一屏

nz: 将第n行滚至屏幕顶部，不指定n时将当前行滚至屏幕顶部。

插入文本类命令

i: 在光标前

I: 在当前行首

a: 光标后

A: 在当前行尾

o: 在当前行之下新开一行

O: 在当前行之上新开一行

r: 替换当前字符

R: 替换当前字符及其后的字符，直至按ESC键

s: 从当前光标位置处开始，以输入的文本替代指定数目的字符

S: 删除指定数目的行，并以所输入文本代替之

ncw或nCW: 修改指定数目的字

nCC: 修改指定数目的行

删除命令

ndw或ndW: 删除光标处开始及其后的n-1个字

do: 删至行首

d$: 删至行尾

ndd: 删除当前行及其后n-1行

x或X: 删除一个字符，x删除光标后的，而X删除光标前的

Ctrl+u: 删除输入方式下所输入的文本

搜索及替换命令

/pattern: 从光标开始处向文件尾搜索pattern
?pattern: 从光标开始处向文件首搜索pattern
n: 在同一方向重复上一次搜索命令
N: 在反方向上重复上一次搜索命令
:s/p1/p2/g: 将当前行中所有p1均用p2替代
:n1,n2s/p1/p2/g: 将第n1至n2行中所有p1均用p2替代
:g/p1/s//p2/g: 将文件中所有p1均用p2替换

选项设置

all: 列出所有选项设置情况

term: 设置终端类型

ignorance: 在搜索中忽略大小写

list: 显示制表位(Ctrl+I)和行尾标志($)

number: 显示行号

report: 显示由面向行的命令修改过的数目

terse: 显示简短的警告信息

warn: 在转到别的文件时若没保存当前文件则显示NO write信息

nomagic: 允许在搜索模式中，使用前面不带“\”的特殊字符

nowrapscan: 禁止vi在搜索到达文件两端时，又从另一端开始

mesg: 允许vi显示其他用户用write写到自己终端上的信息

最后行方式命令

:n1,n2 co n3: 将n1行到n2行之间的内容拷贝到第n3行下
:n1,n2 m n3:将n1行到n2行之间的内容移至到第n3行下
:n1,n2 d: 将 n1行到n2行之间的内容删除
:w: 保存当前文件
:e filename: 打开文件filename进行编辑
:x: 保存当前文件并退出
:q: 退出vi
:q!: 不保存文件并退出vi
:!command: 执行shell命令command
:n1,n2 w!command: 将文件中n1行至n2行的内容作为command的输入并执行之，
 若不指定n1，n2，则表示将整个文件内容作为command的输入
:r!command: 将命令command的输出结果放到当前行

寄存器操作

"?nyy: 将当前行及其下n行的内容保存到寄存器？中，其中?为一个字母，n为一个数字

"?nyw: 将当前行及其下n个字保存到寄存器？中，其中?为一个字母，n为一个数字

"?nyl: 将当前行及其下n个字符保存到寄存器？中，其中?为一个字母，n为一个数字

"?p: 取出寄存器？中的内容并将其放到光标位置处。这里？可以是一个字母，也可以是一个数字

ndd: 将当前行及其下共n行文本删除，并将所删内容放到1号删除寄存器中

在Vi 中移动光标

  k        上
h   l    左  右
  j        下

^        移动到该行第一个非空格的字符处
w        向前移动一个单词，将符号或标点当作单词处理
W        向前移动一个单词，不把符号或标点当作单词处理
b        向后移动一个单词，把符号或标点当作单词处理
B        向后移动一个单词，不把符号或标点当作单词处理
(        光标移至句首
)        光标移至句尾
{        光标移至段落开头
}        光标移至段落结尾
H        光标移至屏幕顶行
M        光标移至屏幕中间行
L        光标移至屏幕最后行 
0        到行首
$        到行尾
gg       到页首
G        到页末
行号+G   跳转到指定行
n+       光标下移n行
n-       光标上移n行 
Ctrl+g   查询当前行信息和当前文件信息

fx       向右跳到本行字符x处（x可以是任何字符）
Fx       向左跳到本行字符x处（x可以是任何字符）

tx       和fx相同，区别是跳到字符x前
Tx       和Fx相同，区别是跳到字符x后

C-b      向上滚动一屏
C-f      向下滚动一屏
C-u      向上滚动半屏
C-d      向下滚动半屏
C-y      向上滚动一行
C-e      向下滚动一行

nz       将第n行滚至屏幕顶部，不指定n时将当前行滚至屏幕顶部。

进入和退出Vi命令

vi filename               打开或新建文件，并将光标置于第一行首
vi +n filename            打开文件，并将光标置于第n行首
vi + filename             打开文件，并将光标置于最后一行首
vi +/pattern filename     打开文件，并将光标置于第一个与pattern匹配的串处
vi -r filename            在上次正用vi编辑时发生系统崩溃，恢复filename
vi filename ... filename  打开多个文件，依次进行编辑 

ZZ                        退出vi并保存
:q!                       退出vi，不保存
:wq                       退出vi并保存

重复操作

.        重复上一次操作

自动补齐

C-n      匹配下一个关键字
C-p      匹配上一个关键字

插入

o        在光标下方新开一行并将光标置于新行行首，进入插入模式。
O        同上，在光标上方。

a        在光标之后进入插入模式。
A        同上，在光标之前。


R        进入替换模式，直到按下Esc
set xxx  设置XXX选项。

行合并

J        把下面一行合并到本行后面

Vi中查找及替换命令

/pattern         从光标开始处向文件尾搜索pattern
?pattern         从光标开始处向文件首搜索pattern
n                在同一方向重复上一次搜索命令
N                在反方向上重复上一次搜索命令
%                查找配对的括号
:s/p1/p2/g       将当前行中所有p1均用p2替代，若要每个替换都向用户询问则应该用gc选项
:n1,n2s/p1/p2/g  将第n1至n2行中所有p1均用p2替代
:g/p1/s//p2/g    将文件中所有p1均用p2替换

.*[]^%~$ 在Vi中具有特殊含义，若需要查找则应该加上转义字符"\"

查找的一些选项

设置高亮

:set hlsearch    设置高亮
:set nohlsearch  关闭高亮
:nohlsearch      关闭当前已经设置的高亮

增量查找

:set incsearch   设置增量查找
:set noincsearch 关闭增量查找

在Vi中删除

x        删除当前光标下的字符
dw       删除光标之后的单词剩余部分。
d$       删除光标之后的该行剩余部分。
dd       删除当前行。

c        功能和d相同，区别在于完成删除操作后进入INSERT MODE
cc       也是删除当前行，然后进入INSERT MODE

更改字符

rx       将当前光标下的字符更改为x（x为任意字符） 
~        更改当前光标下的字符的大小写

键盘宏操作

qcharacter  开始录制宏，character为a到z的任意字符
q           终止录制宏
@character  调用先前录制的宏

恢复误操作

u        撤销最后执行的命令
U        修正之前对该行的操作
Ctrl+R   Redo

在Vi中操作Frame

c-w c-n  增加frame
c-w c-c  减少frame
c-w c-w  切换frame
c-w c-r  交换两个frame

VIM中的块操作

Vim支持多达26个剪贴板

  选块   先用v，C-v，V选择一块，然后用y复制，再用p粘贴。
  yy     复制当前整行
  nyy    复制当前行开始的n行内容
  ?nyy   将光标当前行及其下n行的内容保存到寄存器?中，其中?为一个字母，n为一个数字
  ?nyw   将光标当前行及其下n个词保存到寄存器?中，其中?为一个字母，n为一个数字
  ?nyl   将光标当前行及其下n个字符保存到寄存器?中，其中?为一个字母，n为一个数字
  ?p     将寄存器?中的内容粘贴到光标位置之后。如果?是用yy复制的完整行，
         则粘贴在光标所在行下面。这里?可以是一个字母，也可以是一个数字 
  ?P     将寄存器a中的内容粘贴到光标位置之前。如果?是用yy复制的完整行，
         则粘贴在光标所在行上面。这里?可以是一个字母，也可以是一个数字 
  ay[motion]
            ay$    复制光标位置到行末并保存在寄存器a中
            ayft   复制光标位置到当前行第一个字母t并保存在寄存器a中

以上指令皆可去掉a工作，则y,p对未命名寄存器工作（所有d,c,x,y的对象都被保存在这里）。

剪切/复制/粘贴

所有删除的内容自动被保存，可以用p键粘贴

Vi的选项设置

all         列出所有选项设置情况
term        设置终端类型
ignorance   在搜索中忽略大小写
list        显示制表位(Ctrl+I)和行尾标志($)
number      显示行号
report      显示由面向行的命令修改过的数目
terse       显示简短的警告信息
warn        在转到别的文件时若没保存当前文件则显示NO write信息
nomagic     允许在搜索模式中，使用前面不带“\”的特殊字符
nowrapscan  禁止vi在搜索到达文件两端时，又从另一端开始
mesg        允许vi显示其他用户用write写到自己终端上的信息

tips

对代码自动格式化 gg=G

tjitty 2008-03-26 18:21 发表评论