docs/unix-phil: unix-phil.ms comparison

comparison unix-phil.ms @ 54:0a435d76b868

applied corrections by Dieter@be; and did spell checking

author	meillo@marmaro.de
date	Thu, 15 Apr 2010 13:53:12 +0200
parents	14f5ff66ad8a
children	acd63ecc3606

comparison

equal deleted inserted replaced

-:14f5ff66ad8a
+:0a435d76b868
 Its point of view matches to the one of this paper.
 .H 1 "Importance of software design in general
 .LP
 Software design is the planning of how the internal structure
-and external interfaces of a software should look like.
+and external interfaces of software should look like.
 It has nothing to do with visual appearance.
 If we take a program as a car, then its color is of no matter.
 Its design would be the car's size, its shape, the locations of doors,
 the passenger/space ratio, the available controls and instruments,
 and so forth.
 Software that is horrible to use and horrible to maintain.
 These two aspects are the visible ones.
 Often invisible though, are the wasted possible gains.
 Good software design can make these gains available.
 .PP
-A software's design deals with quality properties.
+Software design deals with quality properties.
 Good design leads to good quality, and quality is important.
 Any car may be able to drive from A to B,
 but it depends on the car's properties whether it is a good choice
 for passenger transport or not.
 It depends on its  properties if it is a good choice
 for a rough mountain area.
 And it depends on its properties if the ride will be fun.
 .PP
-Requirements for a software are twofold:
+Requirements for software are twofold:
 functional and non-functional.
 .IP \(bu
 Functional requirements define directly the software's functions.
 They are the reason why software gets written.
 Someone has a problem and needs a tool to solve it.
 Being able to solve the problem is the main functional goal.
 It is the driving force behind all programming effort.
 Functional requirements are easier to define and to verify.
 .IP \(bu
 Non-functional requirements are called \fIquality\fP requirements, too.
-The quality of a software are the properties that are not directly related to
+The quality of software are the properties that are not directly related to
 the software's basic functions.
 Tools of bad quality often do solve the problems they were written for,
 but introduce problems and difficulties for usage and development, later on.
 Quality aspects are often overlooked at first sight,
 and are often difficult to define clearly and to verify.
 .PP
-Quality is hardly interesting when the software gets built initially,
+Quality is hardly interesting when software gets built initially,
-but it has a high impact on usability and maintenance of the software, later.
+but it has a high impact on usability and maintenance, later.
-A short-sighted might see in developing a software, mainly building something up.
+A short-sighted might see in developing software, mainly building something up.
-But experience shows, that building the software the first time is
+But experience shows, that building software the first time is
 only a small amount of the overall work.
 Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
-does soon take over the major part of the time spent on a software.
+does soon take over the major part of the time spent on a software project.
 And of course, the time spent actually using the software.
 These processes are highly influenced by the software's quality.
 Thus, quality must not be neglected.
 However, the problem with quality is that you hardly ``stumble over''
 bad quality during the first build,
 although this is the time when you should care about good quality most.
 .PP
-Software design has little to do with the basic function of a software \(en
+Software design has little to do with the basic function of software \(en
 this requirement will get satisfied anyway.
-Software design is more about quality aspects of the software.
+Software design is more about quality aspects of software.
 Good design leads to good quality, bad design to bad quality.
-The primary functions of the software will be affected modestly by bad quality,
+The primary functions of software will be affected modestly by bad quality,
 but good quality can provide a lot of additional gain,
 even at places where one never expected it.
 .PP
 The ISO/IEC\|9126-1 standard, part\|1,
 .[
 (analyzability, changeability, stability, testability)
 .IP \(bu
 .I Portability
 (adaptability, installability, co-existence, replaceability)
 .LP
-Good design can improve these properties of a software,
+Good design can improve these properties of software,
 bad designed software likely suffers in these points.
 .PP
 One further goal of software design is consistency.
 Consistency eases understanding, working on, and using things.
 Consistent internal structure and consistent interfaces to the outside
 can be provided by good design.
 .PP
 Software should be well designed because good design avoids many
-problems during a software's lifetime.
+problems during a software project's lifetime.
 And software should be well designed because good design can offer
 much additional gain.
 Indeed, much effort should be spent into good design to make software more valuable.
 The Unix Philosophy shows a way of how to design software well.
 It offers guidelines to achieve good quality and high gain for the effort spent.
 each for one task.
 Difficult tasks are solved by combining several of the small, simple tools.
 .PP
 The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
 that are filters on byte streams.
-They are, to a large extend, unrelated in their function.
+They are, to a large extent, unrelated in their function.
 Hence, the Unix toolchest provides a large set of functions
 that can be accessed by combining the programs in the desired way.
 .PP
 There are also advantages for developing small toolchest programs.
 It is easier and less error-prone to write small programs.
 .PP
 The second drawback of a toolchest affects the users.
 A toolchest is often more difficult to use.
 It is necessary to become familiar with each of the tools,
 to be able to use the right one in a given situation.
-Additionally, one needs to combine the tools in a senseful way himself.
+Additionally, one needs to combine the tools in a sensible way himself.
 This is like a sharp knife \(en it is a powerful tool in the hand of a
 master, but of no good value in the hand of an unskilled.
 However, learning single, small tools of a toolchest is easier than
 learning a complex tool.
 And the user will already have a basic understanding of a yet unknown tool,
 if the tools of a toolchest have a common, consistent style.
 He will be able to transfer knowledge over from one tool to another.
 .PP
-Moreover, the second drawback can be removed to a large extend
+Moreover, the second drawback can be removed to a large extent
 by adding wrappers around the basic tools.
 Novice users do not need to learn several tools, if a professional wraps
 complete command lines into a higher-level script.
 Note that the wrapper script still calls the small tools;
 it is just like a skin around them.
 .H 2 "A powerful shell
 .LP
 The Unix shell provides the possibility to combine small programs into large ones.
 But a powerful shell is a great feature in other ways, too.
 For instance by being scriptable.
-Control statements are build into the shell.
+Control statements are built into the shell.
 The functions, however, are the normal programs of the system.
 Thus, as the programs are already known,
 learning to program in the shell becomes easy.
 Using normal programs as functions in the shell programming language
 is only possible because they are small and combinable tools in a toolchest style.
 .[ [
 gancarz
 unix philosophy
 .], page 28 f.]
 .PP
-Prototyping is often seen as a first step in building a software.
+Prototyping is often seen as a first step in building software.
 This is, of course, good.
 However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
 After having built the prototype, one might notice, that the prototype is already
 \fIgood enough\fP.
 Hence, no reimplementation, in a more sophisticated programming language,
 requirements completely and correctly the first time.
 Hence one should not try to; one will fail anyway.
 .PP
 (2) Requirements change during time.
 Hence it is best to delay requirement-based design decisions as long as possible.
-The software should be small and flexible as long as possible
+Software should be small and flexible as long as possible
 to react on changing requirements.
 Shell scripts, for example, are more easily adjusted as C programs.
 .PP
 (3) Maintenance work is hard work.
 Hence, one should keep the amount of code as small as possible;
 .IP \(bu
 As the initial effort is low, one will likely start right away.
 .IP \(bu
 As working parts are available soon, the real requirements can get identified soon.
 .IP \(bu
-When a software is usable and valuable, it gets used, and thus tested.
+When software is usable and valuable, it gets used, and thus tested.
 Hence problems will be found at early stages of the development.
 .IP \(bu
 The prototype might be enough for the moment,
 thus further work can get delayed to a time
 when one knows better about the requirements and problems,
 practice of programming
 .], chapter\|8]
 and avoiding optimizations that introduce dependencies on specific hardware.
 Hardware has a much lower lifetime than software.
 By chaining software to a specific hardware,
-the software's lifetime gets shortened to that of this hardware.
+its lifetime gets shortened to that of this hardware.
 In contrast, software should be easy to port \(en
 adaptation is the key to success.
 .PP
 (2)
 .I "Portability of data
 .PP
 (3)
 A large
 .I "range of usability
 ensures good adaptation, and thus good survival.
-It is a special distinction if a software becomes used in fields of action,
+It is a special distinction if software becomes used in fields of action,
 the original authors did never imagine.
 Software that solves problems in a general way will likely be used
 for many kinds of similar problems.
 Being too specific limits the range of usability.
 Requirements change through time, thus use cases change or even vanish.
 Successful software adapts itself to the changing world.
 .PP
 (4)
 .I "Reuse of parts
 is even one step further.
-A software may completely lose its field of action,
+Software may completely lose its field of action,
-but parts of which the software is build may be general and independent enough
+but parts of which the software is built may be general and independent enough
 to survive this death.
-If software is build by combining small independent programs,
+If software is built by combining small independent programs,
 then these parts are readily available for reuse.
 Who cares if the large program is a failure,
 but parts of it become successful instead?
 .H 2 "Summary
 existing software were given only sparsely.
 In this and the next chapter, concrete software will be
 the driving force in the discussion.
 .PP
 This first case study is about the mail user agents (\s-1MUA\s0)
-\s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP
+\s-1MH\s0 (``mail handler'') and its descendant \fInmh\fP
 (``new mail handler'').
 .[
 nmh website
 .]
 \s-1MUA\s0s provide functions to read, compose, and organize mail,
 .[ [
 salus
 quarter century of unix
 .], page 41 f.]
 It was a small program that either printed the user's mailbox file
-or appended text to someone elses mailbox file,
+or appended text to someone else's mailbox file,
 depending on the command line arguments.
 .[
 manual mail(1)
 .]
 It was a program that did one job well.
 \s-1MIME\s0 support and support for different character encodings
 is available, but only on a moderate level.
 This comes from limited development resources.
 More active developers could quickly change this.
 But \s-1MH\s0 is also limited by design, which is the larger problem.
-\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend.
+\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extent.
 These design conflicts are not easily solvable.
 Possibly, they require a redesign.
 \s-1IMAP\s0 may be too different to the classic mail model,
 which \s-1MH\s0 covers, so that \s-1MH\s0 may never support it well.
 .PP
 .PP
 A web browser's job is to let the user browse the web.
 This means, navigating through websites by following links.
 Rendering the \s-1HTML\s0 sources is a different job, too.
 It is covered by the webkit render engine, in uzbl's case.
-Audio and video content and files like PostScript, \s-1PDF\s0, and the like,
+Audio and video content and files like PostScript, \s-1PDF\s0,
-are also not the job of a web browser.
+and the like, are also not the job of a web browser.
-They should be handled by external applications \(en
+Such content should be handled by external programs \(en
-ones which's job is to handle such data.
+programs that were written to handle such data.
 Uzbl strives to do it this way.
 .PP
 Remember Doug McIlroy:
 .I
 ``Write programs that do one thing and do it well.
 With uzbl, one can use any download manager the user wants.
 To switch to a different one, only one line in a small handler script
 needs to be changed.
 Alternatively it would be possible to query the program to use by
 reading a global file or an environment variable, in the handler script.
+Of course, one can tell uzbl to use a different handler script, too.
+This requires a one line change in uzbl's config file.
 .PP
 Uzbl does neither have its own download manager nor depends on a
 specific one, hence uzbl's browsing abilities will not be lowered by having
 a bad download manager.
 Uzbl's download capabilities will be just as good as the ones of the best
 \f(CW$4\fP expands to the path of the command input pipe of the current
 uzbl instance.
 .PP
 .B "Avoid captive user interfaces" .
-One could say, that uzbl, to a large extend, actually \fIis\fP
+One could say, that uzbl, to a large extent, actually \fIis\fP
 a captive user interface.
 But the difference to most other web browsers is, that uzbl is only
 the captive user interface frontend (and the core of the backend).
 Many parts of the backend are independent of uzbl.
 Some are distributed with uzbl, for some external programs,
 .PP
 As of March 2010, uzbl-core consists of about 3\,500 lines of C code.
 The distribution includes another 3\,500 lines of Shell and Python code,
 which are the handler scripts and plugins like a modal interface.
 Further more, uzbl uses functionality of external tools like
-\fIwget\fP and \fInetcat\fP.
+\fIwget\fP and \fIsocat\fP.
 Up to this point, uzbl looks pretty neat and small.
-The ugly part of uzbl is the web content renderer, webkit.
+The ugly part of uzbl is the web content render engine, webkit.
 Webkit consists of roughly 400\,000 (!) lines of code.
 Unfortunately, small web render engines are not possible anymore
 because of the modern web.
 .PP
 in mind, was discussed.
 .PP
 Throughout the paper, the aim was do explain \fIwhy\fP something
 should be done the Unix way.
 It was tried to give reasons that expose that the Unix Philosophy
-is a preferrable way for designing software.
+is a preferable way for designing software.
 .PP
 The Unix Philosophy is close to the software developer's point of view.
 Its main goal is taming the beast ``software complexity''.
 Hence it strives first and foremost for simplicity, of software.
 It might appear, that usability for people is a minor goal.

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 54:0a435d76b868