November 7, 2012 9:40 PM
Posted by: Michael Tidmarsh
, Prentice Hall
This excerpt is from the new 3rd Ed. of ‘A Practical Guide to Linux: Commands, Editors, and Shell Programming’, authored by Mark Sobell, published by Pearson/Prentice Hall Professional, Sept. 2012, ISBN 013308504X. For more info, please visit http://www.sobell.com/
The term redirection encompasses the various ways you can cause the shell to alter where standard input of a command comes from and where standard output goes to. By default,
the shell associates standard input and standard output of a command with the keyboard and the screen. You can cause the shell to redirect standard input or standard output of any command by associating the input or output with a command or file other than the device file representing the keyboard or the screen. This section demonstrates how to redirect input/output from/to text files and utilities.
Redirecting Standard Output
The redirect output symbol (>) instructs the shell to redirect the output of a command to the specified file instead of to the screen (Figure 5-6). The syntax of a command line that redirects output is
command [arguments] > filename
where command is any executable program (e.g., an application program or a utility), arguments are optional arguments, and filename is the name of the ordinary file the shell redirects the output to.
Figure 5-7 uses cat to demonstrate output redirection. This figure contrasts with Figure 5-5, where standard input and standard output are associated with the keyboard and screen. The input in Figure 5-7 comes from the keyboard. The redirect output symbol on the command line causes the shell to associate cat’s standard output with the sample.txt file specified following this symbol.
October 26, 2012 6:02 PM
Posted by: Michael Tidmarsh
, Book excerpt
These excerpts are from the book, ‘Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams’ authored by Mickey Mantle & Ron Lichty, published by Pearson/Addison-Wesley Professional, Sept. 2012, ISBN 032182203X, Copyright 2013 Pearson Education, Inc.
For more info please visit http://www.informit.com/title/032182203X%20or%20managingtheunmanageable.net
Want the whole thing? We’re giving away a free copy to one lucky member — find details on the Community Blog.
The Challenges of Managing
Managers must manage.
—Andy Grove, Former Intel chairman and CEO
I’ve used Andy Grove’s phrase innumerable times to coach my managers and directors of programming teams. When confronted with a problem, they can’t just “raise a red flag.” I’m always available when needed, but good software managers find ways to solve problems without my involvement or executive management direction.
Management is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant.
Drucker, born in 1909, is the man who has been called the “father of modern management.” He coined the term knowledge worker and predicted the rise of today’s information society and its need for lifelong learning.
A manager of years ago gave sage career advice: When you land at a new company, pick a gnarly problem—one that people have been avoiding—and solve it. It gets you up the learning curve,and it gains you credibility and respect, both of which you’ll need to be an effective developer and influencer.
—Dave Smith, agile software development coach
People hate change but love progress.
—Terry Pearce, author, Leading Out Loud
It is not enough to respond to change; we must lead change or be left behind.
—Pollyanna Pixton, Founder, Agile Leadership Network (ALN)
You miss 100 percent of the shots you never take.
—Wayne Gretzky, hockey Phenom
I have missed more than 9,000 shots in my career. I have lost almost 300 games. On 26 occasions I have been entrusted to take the game-winning shot and I missed. I have failed over and over again in my life. And that’s precisely why I succeed.
—Michael Jordan, Basketball Phenom
Trust your feelings, young Luke. The Force will be with you.
—Obi-Wan Kenobi, Jedi Master in Star Wars
We counsel many managers and programmers to listen to their intuition carefully; it’s usually right. The older I get, the more I regret those times when I don’t listen to my intuition. Programmers usually know the right things to do—if they allow themselves to trust their feelings.
Accountability is not micromanagement.
The author of 100 Questions to ask Your software Organization, speaking to the Best Practices SIG of the East Bay Innovation Group in 2006. We’ve always hated being micromanaged and thus have avoided being managers who micromanage. The challenge is to realize the line between micromanaging and holding your people accountable. Giving up micromanagement is not giving up expecting accountability.
Trust but verify.
President Reagan was referring to the Soviets during the Cold War with his frequent use of this translation of a Russian proverb that had been equally frequently quoted by Soviet founding father Vladimir Lenin. Perhaps it was because of that context that I didn’t pay attention until I heard another VP of Engineering use the expression in describing how he managed his team—and realized that it described my goal-state management style: my goal is absolutely no micromanagement, but enough checking to know that the delegation I’d done was appropriate.
One of the surest sources of delay and confusion is to allow any superior to be directly responsible for the control of too many subordinates.
—V. A. Graicunas
Graicunas was an early-twentieth-century management consultant and the first to mathematically analyze the complexity of increasing management responsibility. Graicunas showed that as span of control increases, the number of interactions among managers and their reports—and thus the amount of time managers must spend supervising—increases geometrically. His formula takes into account manager-to-report, report-to-report, and manager-to-all-combinations-of-reports interactions, and he posits that supervision time increases proportionately with interactions. He showed that by adding a fifth report, while the potential for accomplishing more work may increase by 20 percent, the number of potential interactions increases from 44 to 100— by 127 percent! Eight reports increases to 1,080 potential interactions and 12 reports to 24,564 to track and manage! Graicunas recommended that managers have a maximum of five reports, ideally four.
Managing Teams to Deliver Successfully
Software is hard.
Knuth is the acclaimed author of the art of Computer Programming. Here, he was quoted speaking to an audience of 350 people at the Technische Universitat Munchen.
Software isn’t released, it’s allowed to escape.
—Project management lay wisdom
. . . you’re not here to write code; you’re here to ship products.
Hofstadter’s Law: It always takes longer than you expect, even when you take Hofstadter’s Law into account.
Always take redundancy over reliability.
Too much data could be worse than no data at all.
The secret of software development has always been good people and lots of Chinese food.
— Jeff Kenton, Consulting developer and development manager
Lots of Chinese food or pizza. Critical projects or milestones often require extraordinary effort to be exerted by the programming team. It’s a simple thing that should be obvious: Programmers under schedule pressure will work long hours unless they are interrupted. Bringing in meals—Chinese food, pizza, or even meals from a great restaurant—keeps the programming team going. If you allow them to go out for food, their will to continue will erode and the extra effort will diminish.
Projects should be run like marathons. You have to set a healthy pace that can win the race and expect to sprint for the finish line.
—DD Catmull, CTO, Pixar animation studios
At Pixar, Ed Catmull, its co-founder, president, and CTO, encouraged me to manage my projects this way, and I’ve used this as a rule of thumb ever since. When interviewing new candidates, I make sure I find a way to bring this up so that I set the expectation that there will be times when the programmer will need to work very hard and sprint for the finish line and project completion, but also to set the expectation that I don’t expect them to “sprint” all the time.
October 4, 2012 4:40 PM
Posted by: Ben Rubenstein
, Book excerpt
The following is an excerpt from C++ Primer, Fifth Edition, by Stanley B. Lippman, Josee Lajoie and Barbara E. Moo, available from Addison-Wesley Professional.
For more information, read Jaideep Khanduja’s review of the full book.
1.2 A First Look at Input/Output
The C++ language does not define any statements to do input or output (IO). Instead, C++ includes an extensive standard library that provides IO (and many other facilities). For many purposes, including the examples in this book, one needs to know only a few basic concepts and operations from the IO library.
Most of the examples in this book use the iostream library. Fundamental to the iostream library are two types named istream and ostream,which represent input and output streams, respectively. A stream is a sequence of characters read from or written to an IO device. The term stream is intended to suggest that the characters are generated, or consumed, sequentially over time.
Standard Input and Output Objects
The library defines four IO objects. To handle input, we use an object of type istream named cin (pronounced see-in). This object is also referred to as the standard input. For output, we use an ostream object named cout (pronounced see-out). This object is also known as the standard output. The library also defines two other ostream objects, named cerr and clog (pronounced see-err and see-log, respectively). We typically use cerr, referred to as the standard error,for warning and error messages and clog for general information about the execution of the program.
Ordinarily, the system associates each of these objects with the window in which the program is executed. So, when we read from cin, data are read from the window in which the program is executing, and when we write to cout, cerr, or clog, the output is written to the same window.
A Program That Uses the IO Library
In our bookstore problem, we’ll have several records that we’ll want to combine into a single total. As a simpler, related problem, let’s look first at how we might add two numbers. Using the IO library, we can extend our main program to prompt the user to give us two numbers and then print their sum:
std::cout << “Enter two numbers:” << std::endl;
int v1= 0, v2 = 0;
std::cin >> v1 >> v2;
std::cout << “The sum of ” << v1 << ” and ” << v2
<< ” is ” << v1 + v2 << std::endl;
This program starts by printing
Enter two numbers:
on the user’s screen and then waits for input from the user. If the user enters
followed by a newline, then the program produces the following output:
The sum of 3 and 7 is 10
The first line of our program
tells the compiler that we want to use the iostream library. The name inside angle brackets (iostream in this case) refers to a header. Every program that uses a library facility must include its associated header. The #include directive 7 Sectio n 1. 2 A Firs t Loo k a t Input/Outpu t
must be written on a single line—the name of the header and the #include must appear on the same line. In general, #include directives must appear outside any function. Typically, we put all the #include directives for a program at the beginning of the source file.
Writing to a Stream
The first statement in the body of main executes an expression.In C++ an expression yields a result and is composed of one or more operands and (usually) an operator. The expressions in this statement use the output operator (the « operator) to print a message on the standard output:
std::cout << “Enter two numbers:” << std::endl;
The << operator takes two operands: The left-hand operand must be an ostream object; the right-hand operand is a value to print. The operator writes the given value on the given ostream. The result of the output operator is its left-hand operand. That is, the result is the ostream on which we wrote the given value.
Our output statement uses the << operator twice. Because the operator returns its left-hand operand, the result of the first operator becomes the left-hand operand of the second. As a result, we can chain together output requests. Thus, our expression is equivalent to
(std::cout << “Enter two numbers:”) << std::endl;
Each operator in the chain has the same object as its left-hand operand, in this case std::cout. Alternatively, we can generate the same output using two statements:
std::cout << “Enter two numbers:”;std::cout << std::endl;
The first output operator prints a message to the user. That message is a string literal, which is a sequence of characters enclosed in double quotation marks. The text between the quotation marks is printed to the standard output.
The second operator prints endl, which is a special value called a manipulator.Writing endl has the effect of ending the current line and flushing the buffer associated with that device. Flushing the buffer ensures that all the output the program has generated so far is actually written to the output stream, rather than sitting in memory waiting to be written. Programmers often add print statements during debugging. Such statements should always flush the stream. Otherwise, if the program crashes, output may be left in the buffer, leading to incorrect inferences about where the program crashed.
Using Names from the Standard Library
Careful readers will note that this program uses std::cout and std::endl rather than just cout and endl.The prefix std:: indicates that the names cout and endl are defined inside the namespace named std. Namespaces allow us to
avoid inadvertent collisions between the names we define and uses of those same names inside a library. All the names defined by the standard library are in the std namespace.
One side effect of the library’s use of a namespace is that when we use a name from the library, we must say explicitly that we want to use the name from the std namespace. Writing std::cout uses the scope operator (the :: operator)tosay that we want to use the name cout that is defined in the namespace std.§ 3.1
(p. 82) will show a simpler way to access names from the library.
Reading from a Stream
Having asked the user for input, we next want to read that input. We start by defining two variables named v1 and v2 to hold the input:
intv1 = 0, v2 =0;
We define these variables as type int, which is a built-in type representing integers. We also initialize them to 0. When we initialize a variable, we give it the indicated value at the same time as the variable is created.
The next statement
std::cin >> v1 >> v2;
reads the input. The input operator (the » operator) behaves analogously to the output operator. It takes an istream as its left-hand operand and an object as its right-hand operand. It reads data from the given istream and stores what was read in the given object. Like the output operator, the input operator returns its left-hand operand as its result. Hence, this expression is equivalent to
(std::cin >> v1) >> v2;
Because the operator returns its left-hand operand, we can combine a sequence of input requests into a single statement. Our input operation reads two values from std::cin, storing the first in v1 and the second in v2.In other words, our input operation executes as
std::cin >> v1;std::cin >> v2;
Completing the Program
What remains is to print our result:
std::cout << “The sum of ” << v1 << ” and ” << v2<< ” is ” << v1 + v2 << std::endl;
This statement, although longer than the one that prompted the user for input, is conceptually similar. It prints each of its operands on the standard output. What is interesting in this example is that the operands are not all the same kinds of values. Some operands are string literals, such as “The sum of “.Others are int values, such as v1, v2, and the result of evaluating the arithmetic expression v1+v2. The library defines versions of the input and output operators that handle operands of each of these differing types.
September 28, 2012 7:18 PM
Posted by: Michael Tidmarsh
, Book excerpt
, Requirement Process
Book image via Shutterstock
This excerpt is from the new 3rd Ed. of ‘Mastering the Requirements Process: Getting Requirements Right‘ authored by Suzanne Robertson and James Robertson, published by Addison-Wesley Professional, Aug. 2012, ISBN 0321815742, Copyright 2013 Pearson Education, Inc. For more info please visit the publisher site: http://www.informit.com/title/0321815742
The Requirements Process
This book is a distillation of our experience. In it, we describe a requirements process that we have derived from our years of working in the requirements arena—working with clever people who do clever things, and working on projects in wonderfully diverse domains. We have also learned much from the experience of the many people around the world who use various parts of our techniques.
We developed the Volere Requirements Process and its associated specification template from the activities and deliverables that had proved themselves to be most effective in project and consulting assignments with our clients. The result of this experience is a requirements discovery and specification process whose principles can be applied—and indeed have been applied—to almost all kinds of application types in almost all kinds of development environments.
We want to stress from the very beginning that while we are presenting a process, we are using it as a vehicle for discovering requirements; we do not expect you to wave this process around and tell your co-workers that it is “the only way to do things.” However, we have high expectations that you will find many useful things from this process that will, in turn, help you to discover and communicate your requirements more productively and accurately. We have personally seen hundreds of companies adapt the process to their own cultures and organizations, and we know of thousands more that have done so.
Our clients who use the Volere Requirements Process are those who develop their products using RUP, incremental, iterative, spiral, Scrum, or other variations of iterative development; more formalized waterfall processes; and a variety of homebrewed development processes. Over the years, all of these clients agreed with us: If the right product is to be built, the right requirements have to be discovered. But requirements don’t come about by fortuitous accident. To find the correct and complete requirements, you need some kind of orderly process.
The Volere Requirements Process is shown in Figure 2.1. Each of the activities included in the figure, along with the connections between them, is described in detail in subsequent chapters of this book.
The Requirements Process in Context
We need to point out—indeed, we need to stress—that this process is not intended to be a waterfall approach. At various stages throughout this book, we will point out how you might modify the process if you are using some kind of iterative development.
This map of the Volere Requirements Process shows the activities and their deliverables. We have used a stylized data flow notation. Each activity (the bubbles) and its deliverables (named arrows or documents) are explained in the text. The dotted lines represent how this process is used with iterative projects.
Requirements discovery should be seen as a necessary forerunner of any construction activity, but it should also be viewed as something that can be conducted quite quickly, sometimes quite informally, sometimes overlapping with subsequent design and construction activities, but never ignored.