Price: $19.99 - $24.99

Trim size: 9 1/8 by 7 3/8 ("standard" trim size)

Color: 1

Page count: 350-550

Competition: In Record Time Sybex

Hands On Prima

For the beginning programmer looking for an easy and rewarding way to learn how to program. These books assume that the reader knows little more than the name of the programming language/application that the book covers. This audience is looking for a hands-on, results- oriented solution to learning programming that has quick rewards. It is designed to give the reader constant reinforcement by building real-world programs and/or useful code fragments throughout the book along with one real-world application at the end of the book.

The series will assume that the reader wants a fast-tracked, by example learning approach to the language product. Nevertheless, the series will also teach the reader proper coding techniques in the language so the reader can apply the skills learned in the maintainable, professional atmosphere. The reader may not even be familiar with a variable but this series will talk to the reader’s beginning level but not down to the reader.

The author is to keep the reader’s target level at mind throughout the entire writing of the book. If the book is teaching programming using an application, such as Access Programming By Example, assume the reader is familiar with the basics of the application but not with the language or programming platform beneath the application.

While the chapters follow a logical teaching progression, each chapter is designed to stand alone. They should be small, "edible" chapters that a person can get through in the course of an evening (1-2 hour lesson). Each chapter should contain full, real-world, useful code examples that fully demonstrate the concepts discussed in the chapter. These code may be for personal finance, school, home, business, record keeping, utilities, etc.

The goal is to teach proper techniques and practices using accepted methods for programming (following ANSI/ISO standards where applicable). Authors should be accredited professionals who teach or train the subject or were involved in the creation of the standard. Therefore, in addition to teaching coding mechanics, the By Example series will promote proper coding design and techniques. Although the majority of the book will be dedicated to the coding specifics to retain its fast-track learning approach, newcomers to programming or a language must be well-grounded in good programming practices, for example documentation and naming techniques, which this series will teach.

Chapters should describe what the chapter covers (loops, operators, i/o, etc.) and not the project that is built in the chapter. That is, the code presented inside the chapters should teach the language concept and emphasis should not be placed on the code’s purpose. To achieve this, the code must be clear, well-documented, and "self-documenting." This means that the focus should always be on teaching how to code without a lot of the page count consumed by introducing and explaining the goals of each and every code listing. Nevertheless, some description is obviously warranted, more in passing, as in this example code lead-in:

"Consider the name-printing code that appears in Listing 5.7. A For-Next loop retrieves each customer name before printing that name in a formatted output field."

This code in Listing 5.7 might only be a five-line loop but the quick description tells the reader just enough to describe the goal without getting bogged down by the purpose of the code. Obviously, this would appear after a complete description of loops.

Each chapter should conclude with a summary of what the chapter taught. The summary should also place that chapter in perspective with the rest of the book and why it is applicable.

The beginning of the book should be very basic and discuss (briefly) basic programming concepts: how the program works with the OS and the hardware. If there is an IDE, there should be a brief tour of the IDE, with screenshots and callouts to important features. A full discussion is a little too much at this point as it won’t make much sense to the reader. Include enough of the IDE and programming environment and background needed to get started with the first examples of programming taught next. Keep the opening chapters light on IDE coverage. Throughout the book, when a programming topic requires the reader’s use of a new IDE element, teach that IDE element then. This gives the reader a sense that he is learning what is needed, nothing more and nothing less, to do the job. When teaching the IDE, you must still teach by example. Show screenshots with callouts to describe the IDE component at hand. In addition, a by-example usage of the critical IDE elements is needed in the same way that the book teaches a programming concept by example. The example IDE use may mean that the reader enters sample code that the reader does not understand yet, but that’s okay because it’s the IDE that is being taught and not the language at that point.

The final chapter of the book should contain a full working program that demonstrates most of the concepts of the book. This code listing should be well-documented, with comments explaining what the code does and should reference the chapter in which the concept is discussed. This program MUST be a useful, real-world application that a person could use on their own (baseball card record keeper, contact management, project tracker, web program, CD tracker, utility, etc.). This program should be something that they’ll want to send to friends and family. Do not use proprietary files or images, the reader should be able to create the program on their own and customize it however they choose. If controls are used, follow the lowest-common denominator and assume the user has only the controls that are shipped with the most basic version of the product.

An appendix in the back points readers to resources as to where they should go from here. That should be other books, websites, and a discussion of some possible careers/entry level positions they might consider with the new knowledge they’ve gained. Where applicable, it should discuss certification, what it means, and what the person should do to prepare (what books, classes, costs, and what it will get them in the long run).

A second appendix should list resources for compilers and other "goodies" on the internet or elsewhere. Authors should look for deals on compilers, free code, and other useful resources.

Throughout the book, no matter what the topic is, keep the series in mind. Teach everything possible with an example. This will require that you first describe the topic. Follow a What-Why-When-How mode with the What describing the topic, including code syntax, the Why describing why that topic is useful, the When describing when the programmer would use that element, and finally the How would be the actual example of the topic being used. Also, multiple examples are never bad and often required for programming elements that have several different formats.

The following example is one approach to achieve the What-Why-When-How approach:

---------------------------------Begin Sample----------------------------

(c)Financial Functions

Now that you understand how the numeric and string functions work, you will appreciate the job that Access’s financial functions perform. The financial functions calculate several intricate money-based results that greatly simplify and reduce the code that you would otherwise have to write. Access includes financial functions that compute the following:

[1b] Depreciation: Enables you to write off an asset over the life of the asset instead of deducting the cost immediately

[1b] Annuity: Computes the total value and interest rates of streams of payments that you make or receive over time

[1b] Capital Investments: Calculates the cost and return of income-producing assets your company is considering purchasing

(d)SLN() : The Straight-Line Depreciation Function

The most fundamental depreciation function is the straight-line depreciation function that writes off the cost of an asset in equal payments over time. Use SLN() when you cannot use accelerated depreciation calculations. The SLN() function’s format is

SLN(originalCost, salvageAmount, estimatedLifeYrs)

Here is a line that uses SLN():

slAmount = SLN(cost, salvage, life)

SLN() returns each term’s depreciated value when you supply the asset’s dollar cost, salvage value in dollars, and life expectancy in years. Listing 16.4 shows another, more complete SLN() example that might appear inside a larger Access code module.

Listing 16.4. The SLN() function calculates straight-line depreciation.

‘ Computes each year’s depreciated value

‘

cost = InputBox("How much did the asset cost?")

salvage = InputBox("How much is the salvage value?")

life = InputBox("How many years is the asset expected to last?")

‘

slAmount = SLN(cost, salvage, life)

MsgBox "The annual depreciation is " & Str(slAmount)

Here is a sample output from the code shown in Listing 16.4:

How much did the asset cost? 1200.00

How much is the salvage value? 50.00

How many years is the asset expected to last? 6

The annual depreciation is 180.00

---------------------------------End Sample----------------------------

The d-section above does several things. It retains a friendly and respectful tone without the funky nature of Idiots/Dummies books. It quickly gets to the heart of the topic, the SLN function, and shows the format and an actual line that uses the function just to familiarize the reader with it and a one-line example. Therefore, the What and Why is answered quickly, and even the How is beginning to be answered as well. Then, the section explains when the function is to be used. The section then wraps up with the code example of the function.

The reason this financial function is good to demonstrate for the series guidelines is that these functions are extremely industry-specific and require an extra layer of explanation than other functions such as the regular numeric functions like Int(). For example, not only must you explain the syntax, usage, and purpose of a function, but these functions warrant a short explanation of what their financial application is. Even though the goal of a By Example series should not be delving into the mechanics of financial calculations, you can get a sense from this example section that you don’t have to explain the entire background of a function to cover its highlights, even for specialized statements and functions.

Not all code examples will justify showing the output of the code. For example, code that demonstrates a sorting algorithm or a variable declaration will have no output. If, however, you can show a screen shot or other output from a code listing, the output helps reinforce the topic and eliminates all guesswork from the reader. Therefore, include the output when appropriate. If no output is appropriate, at least describe the expected results, such as, "The sorting routine in Listing 22.3 will alphabetize all the customer records by their last name."

Note: The depreciation number used in this example’s output is made up and is not the result the SLN() actually produces but is illustrative for the series guidelines only.

Screen shots with callouts always grabs the readers attention and makes the figures more helpful than they would otherwise be.

The reader is a beginner. Do not get too hung up on the exact syntax rules that include all possible exceptions to the code being described. In other words, the following syntax, although accurate, is far too complex for most "real-world" examples:

If condition1 Then

[Statementblock-1]

[ElseIf condition2 Then

[statementblock-2]]…

[Else

[statementblock-N]]

EndIf

Although this statement syntax is not overly complex as some can get, and although it is technically complete, the syntax is far too complex for the readers of this series. Not that the readers cannot figure it out, but these are not yet professional programmers. Instead of throwing the full syntax, introduce a complex statement such as the If statement a piece at a time. Show a simple If-Then in its own section with its own example(s). Then, introduce the Else. Then, the ElseIf. Therefore, you build along with the reader.

The goal should be to keep the reader moving forward through the book’s examples and topics. A multi-leveled, complex statement syntax will make these readers STOP in their tracks and try to figure out what is being described.

Again, it’s not that these readers are not competent enough to figure out the complex syntax, it’s just that this is not a professional reference book but an introduction to the programming topics. You never want the reader to stop or back up but to move forward through the pages, feeling accomplishment and seeing examples that build on simpler statement constructs, so the reader stays excited about learning a programming language that the reader may have thought they could never understand before this series.

Standard statement syntax conventions can be used in this book, although early in the book the syntax should be explained (optional items in brackets, italicized placeholders, etc.) WITH EXAMPLES.

Tips either point out information often overlooked in the documentation, or help the reader use the software more efficiently. Tips should offer the author's unique insight into the program and should not be used for something as mundane as keyboard shortcuts or toolbar icons.

Notes

Notes represent Tip information of a lengthier nature (unless this information can be included within the body of the text without disrupting the main flow of the prose) and are placed in a special Note box within the body of the text.

Cautions alert readers to potentially negative consequences of an operation or action, especially if the latter could result in serious or even disastrous results, such as loss or corruption of data.

Be sure that your new terms are being italicized on first use where they are defined or explained. DEs and authors should continue to use discretion and judgment in determining what new terms or phrases need to be italicized and explained or defined for the level of their audience. We must have these correctly done in order to correctly execute the inline index element. Here is an example:

If you have a paragraph that mentions features described elsewhere in the book, insert a note to include a cross-reference, which refers to a section in another chapter in the book. Cross references should fall as close after the related material as possible. We will add the page number after the book is folioed. Authors need to provide the chapter number the reference can be located in. A right-facing arrow will precede each cross-reference.

Cross references should include a short description of why the material is of additional interest. This should come before the section title and page reference.

[lbr]To see a how to best use the Online layout View, see[en]"Controlling Your Document’s Appearance on-Screen," p. XXX (chapter X)

These cross-references function like hypertext links and allow users to navigate through the text.

These can also be used to reference specific chapters in other related Que books for more in depth information. When cross referencing other Que books, it is best to set these in Note form.

"Inline Indexes"

(While these are not really an index and should not be referred to as such in the book, this is the name that has stuck for internal use.) These are a convenient way to the reader to find a definition or explanation of a term, without having to look it up in an index. When you have a term used in the current discussion that is defined elsewhere, italicize it and follow it with (p. xxx). The page number will be filled in once the book is follioed. These look like:

Please note that:

• In order for these to work, you must have your new defined terms properly italicized throughout the book
• If a term can have more than one possible meaning within the context of your book, include a production directive pointing to the chapter where the relevant definition is given
• Use discretion when marking these. Not every time a term is used does it need to be marked. Think about what is appropriate for the reader at the level of the current topic being discussed and whether or not it is likely that the reader will already know what this is or whether they may need to look it up
• Don't use an inline index and a cross reference for the same item at the same place. These are different than cross-references as they point to just a specific definition directly used here whereas a cross reference is used for a broader discussion of a related topic

The Inside Front Cover should clearly explain who should read the book. The back cover will include a Starburst that states "This book assumes no programming knowledge, see inside front cover for details" for beginning programming books or "This book assumes a knowledge of C, see inside front cover for details" for a topic such as Linux programming. The Inside Front Cover will then go into details to be found in the book, and will also serve as a jump table. For example:

WE MADE ASSUMPTIONS ABOUT YOU:

A book on X that teaches you about Y isn’t truly a book on X. In order to teach you the most about X, we stuck to the topic at hand in order to allow you the greatest learning curve without wasting your time or money. The following table shows you what we think you want to know from reading this book, as well as what we assumed you already know. We hope this allows you to make an informed purchasing decision.

WHAT WE ASSUME YOU KNOW:

If you are not comfortable with these concepts, it is likely that you will not understand or be able to complete all of the exercises in this book. Please read:

WHAT WE ASSUME YOU DON’T KNOW:

We assume that you are looking to learn the following concepts, each of which will be taught in this book:

X concept Chapter number, page number(s) X concept Chapter number, page number(s) X concept Chapter number, page number(s)