Slashdot Mirror

theodp writes "Having cut his programming teeth on an Apple ][e as a ten-year-old, Mark Pilgrim laments that Apple now seems to be doing everything in their power to stop his kids from finding the sense of wonder he did: 'Apple has declared war on the tinkerers of the world. With every software update, the previous generation of "jailbreaks" stop working, and people have to find new ways to break into their own computers. There won't ever be a MacsBug for the iPad. There won't be a ResEdit, or a Copy ][+ sector editor, or an iPad Peeks & Pokes Chart. And that's a real loss. Maybe not to you, but to somebody who doesn't even know it yet.'"

theodp writes "Using Amazon CEO Jeff Bezos' own words against him, Mark Pilgrim offers his chilling take on The Future of Reading with a mash-up of Bezos' Open Letter to the Authors Guild, the Amazon Kindle Terms of Service, Steven Levy's Newsweek article on the Kindle, 1984, and Richard Stallman's 'The Right to Read.'"

Mindpicnic writes "The recent switch of two lifelong Mac nerds to Ubuntu hasn't escaped Tim O'Reilly's radar. He cites Jason Kottke: 'If I were Apple, I'd be worried about this. Two lifelong Mac fans are switching away from Macs to PCs running Ubuntu Linux: first it was Mark Pilgrim and now Cory Doctorow. Nerds are a small demographic, but they can also be the canary in the coal mine with stuff like this.'"

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

prostoalex writes "The question of the best weblogging system out there arises quite often, especially after the new licensing scheme introduced by MovableType. Here's a rather detailed breakdown of currently popular blogging and content management systems. Out of 11 software packages, 10 run on any server with variations of Perl/PHP and MySQL/PostgresSQL, and one requires Windows and .NET Framework. 4 are licensed under GPL, 3 are under BSD. Mark Pilgrim explains why licensing is suddenly important."

Joe Clark writes "Screen readers for blind Mac users have been nonexistent since 2003 when development was halted on the only one in existence. On Windows they cost up to $1,295. This week, Apple announced the upcoming Spoken Interface for Mac OS X, the long-rumoured Apple screen reader and more, we are told. Apple is looking for beta-testers for this technology preview. Already, a developer muses that IBMs accessible Java software could work with the screen reader. No mention of Braille-display support yet, which many blind and deaf-blind people need and want."

Cheese Man writes "Mark Pilgrim describes a simple way to identify email-harvesters: "In each page I serve, I include a bogus email address, encoded with the date of access as well as the host IP address ... This has allowed me to trace spam back to specific hosts and/or robots." There's even a simple one-line example done with PHP. (Thanks to BoingBoing for the links.)"

EchoMirage writes "The World Wide Web Consortium (W3C) has been quietly working on drafts for a proposed XHTML 2.0 standard. But some well-known and well-respected web authors are balking at the proposal, because it invalidates several well-used tags. Given that XHTML 1.1 hasn't even seen any wide use yet, and many browsers are still working on basic HTML 4 and CSS1 compatibility, many people are questioning the W3C's push to create new standards before the old ones are solidly in place."

We sent 10 of your questions to usability guy Joe Clark, and he took it upon himself to go a bit beyond simply answering them. In his reply he said, "Answers attached in a valid XHTML file. I would suggest at least retaining the id attributes. I copy-edited all the questions, but the words are all the same; they are now merely spelled and capitalized correctly. I think all the links work." Whatever. We left Joe's formatting intact. It's a little different from our usual style, but variety is the spice of Slashdot. Ask the Expert: Accessibility 1) How far should it go?

by newsdee

Macromedia Flash has integrated many accessibility features in an effort to promote development of content for special needs. However, can we realistically try to turn any multimedia feature into its accessible equivalent? Is it even feasible other than providing a text-only equivalent?

There seems to be a stereotyped understanding of Flash content at work here. Flashturbation is not the only usage of that authoring tool.

I believe the question really intends to ask Are artistic uses of Flash, like Josh Daviss Praystation, really amenable to accessibility? The answer is a qualified yes, and I say that because Praystation-like Flash experimentation is essentially a form of cinema that merely uses the Web as a delivery mechanism. Cinematic experiments of this sort are indisputably a different species from other forms of Flash development.

In that example, the solution is to treat the Flash objects as a movie and apply standard movie accessibility features, namely captioning and audio description. Im not one of those people who believes that abstract, experimental, or non-narrative cinema cannot be captioned and described lots of music videos fall into that category, and theyve been captioned for nearly 15 years. (Description of experimental audiovisual artworks has not really been attempted to my knowledge, but description of abstract art in museums and of non-narrative plays and dance performances in theatres have all been going on for years. Its perfectly possible.)

The challenges, then, are two: Infrastructure and interface. There isnt really a very good way of including captions or descriptions in a Flash file as yet (an infrastructure problem). Macromedia knows all about this (Ive discussed it with them at length, and also written about it), and it will eventually be fixed. (Even finding an example of Flash with captioning is difficult today. Youd think Id have a complete list at the tip of my fingers, but I dont. The Macromedia Contribute feature tour is one case.) I dont know of any Flash animation that was ever described.

The interface problem is: How does the viewer turn captions and descriptions on and off? This isnt like a TV set, where you can manipulate onscreen menus (and how do you manage that if youre blind?) to turn captions and/or descriptions on and off. Browsers are not smart enough to automatically turn access features on and off, though I think a future upgrade of one file format that shall remain nameless will be the first to include such a capacity. At any rate, this may be one of the rare cases where an overt visual change must be made to accommodate accessibility actual selectable buttons to turn CC and DX on and off. (The buttons themselves have to be accessible, i.e., part of the tabbing order and with alternate texts and so forth.)

Now, lets consider other examples of Flash.

Banner ads the really big skyscraper ads that bug your arse on so many sites The usual Flash accessibility features can be used, and you can be smart and include the Flash object inside, say, an iframe element, which provides vast options for accessibility. (You can add a long description to the iframe, though thats questionably useful, and include alternate content in case the main content cannot be loaded, which could be an ordinary animated GIF or still image with alt and title.) Comics Flash-based comics can be relatively straightforward to make accessible (Apocamon doesnt seem too tricky its essentially a panel-based comic strip with a wee bit of animation) or could require full-on cinematic techniques, as with Broken Saints. User interfaces Flash can be and is used as a tidier means of providing a user interface, as at FoxSports.com or in the Neuros audio-player demo. The temptation, as in that last example, is also to use motion graphics and audio, which may require the same CC and DX as before, but many user interface can be made adequately accessible with todays Flash accessibility tools (text equivalents, making objects visible or invisible in the document structure, etc.). Manipulable objects Games (including the Royal National Institute for the Blinds ill-advised consciousness-raising game, no longer online) and even some interfaces (like History of Health Care) may include objects youre intended to grab and manipulate with the mouse. The current Flash accessibility tools are not really up to the challenge of adding keyboard equivalents for such manipulable objects. You could hack it together yourself, but there are no built-in commands or primitives you could use in a standards-compliant way. Intros Skippable intros are just as awful today as the day they were invented. Unfortunately, we cant make value judgements about which information should and should not be made accessible. Even skippable intros have to be made accessible, either by treating them as cinema or simply giving them a few text equivalents. The skip-intro link has to be selectable by keyboard, of course. Tools These interfaces let you do something. One I like a lot, if only because I am a typography queen, is Jeremy Tankards font viewer, though it is admittedly overkill because other font-viewing miniprograms do not require Flash. It may be possible to make the inputs to such tools accessible (you can place the cursor in the right place, operate controls, and so forth), but the results might be intrinsically inaccessible. (Note that artists portfolio sites, font and clip-art vendors, stock-photo houses, and other sites that sell visual imagery using ordinary HTML can be made passably accessible even to a blind person. In the Tankard case, perhaps only the name of the font and the text entered would be rendered to a screen reader or other device.) E-commerce Perhaps the most credible Flash instance, E-commerce sites like Ted Baker (see its Footwear store) may include all the features of the other instances Ive listed here. Since E-commerce is a convenient way to shop for many disabled people, I would strongly emphasize the need for accessibility. But it might be stretching the limits of current Flash access tools, since you have to make an interface, product shots and other images, and text all accessible. Thats not difficult in HTML, but I dont have any examples to point to of accessible Flash-based E-commerce sites that we could use as a comparison; I dont know how hard it would be to make such sites accessible. Aside: The most sophisticated Flash site Ive ever seen is DirtyBastards.com. (No direct hyperlink; consider this the strongest possible warning of adult content. Be very sure you want to look at it.) The usability could use an update, but in general its astounding. Should we ever be in the same city, Ill take anyone who can update that site for accessibility to dinner at the restaurant of their choice.

I would add a proviso here. Accessibility does not relate solely to blind people. As mentioned above, any quasi-cinematic work with audio requires captioning; deaf people need accessibility, too. There is much more attention being paid now to the Web-accessibility needs of people with learning disabilities (the most famous of which is dyslexia), which well get to later.

Learning-disabled people are by far the hardest to accommodate online, and for many HTML pages, they are probably impossible to accommodate in any really helpful way. Flash animations could be a good solution for that group because you can build in many levels of information, use audio and graphics, and provide really good controls for pacing (because having too much information coming at you all at once is a barrier for many people). Inevitably, accessible Flash in that context would limit itself to custom-engineered animations specifically made for that audience; I doubt that general uses of Flash will be upgraded for that kind of accessibility.

Text-only sites are not the alternative to accessible sites. Text-only is not accessible. Well discuss graphic sophistication later.

Biggest problem

by robbo

What, in your opinion, is the most common complaint concerning accessibility and Web sites? In other words, if in the interests of accessibility you could encourage site owners to change only one thing about how they operate, what would it be?

Images. Seriously, if youve got an ordinary HTML Web page and you make absolutely all your images accessible including, crucially, adding alt="" to every spacer GIF and every other meaningless graphic youre four-fifths of the way to being an accessible Web site for the group with the greatest single need, the blind and visually-impaired.

I emphasize coding to standards. Unless you have an airtight reason (like youre stuck using an old content-management system you cannot afford to replace), I really dont want to have anything to do with you unless youreproducing valid HTML. Now, tiny invalidities are just that, tiny: <hr> and <hr/> really are the same thing. And Im sure that ultra-purist geeks will now launch a hypocrisy hunt and comb through my entire Web presence to locate pages with non-valid markup. (Knock yourselves out. I make small mistakes, and have not updated scores of very old pages. Im also a vegan with some shoes and accessories made of leather. Complete purity is sometimes unattainable.) In one of the many ironies of Web development, it is indie developers like me who have a higher success rate in achieving valid, accessible sites even though larger commercial operations are the ones where valid HTML and accessibility are more urgently needed.

In any event, if youre producing tag soup, as far as Im concerned youre demonstrably not all that interested in responsible Web development.

The upside? If you do write valid pages, you have to include at least an alt text for every graphic. For no extra effort (you have to do it anyway), you get basic accessibility.

Number two on the list is navigation. Left-hand and top navbars stacked with link after link are a nightmare to wade through if you have a mobility impairment that reduces your ability to use a mouse or keyboard. (Screen-reader users are not so heavily affected; they can skip entire table cells, for example. I suppose all-CSS layouts are harder to skip through. But thats not the page authors problem; its incumbent on the adaptive technology and browser to clean up their act.)

If youre able to use a mouse, you can just avoid the entire navbar. But a mobility-impaired person may be stuck tabbing from one link to another and thats the best-case scenario. Quite possibly, a mobility-impaired visitor may be using software that cycles through a set of input choices for example, the mouse; then the alphabet keys of keyboard; then the number keys; then the function keys. You may have to wait until the keyboard option cycles back again in order to type repeated keystrokes. (You may have a mental image of a sip-and-puff switch or Christopher Reeve using speech-input software. The principles are the same and so is the inconvenience.)

If you, the page designer, stack 20 or even a hundred links in a left-hand navbar and assume that people can simply tab through them, well, (a) tabbing 20 or a hundred times is something youd never expect a nondisabled person to put up with, and (b) some people will have to wait 20 or a hundred cycles of their software in order to do the equivalent of pressing the Tab key.

The solution? Put skip-navigation links on top of every navbar with, say, ten or more links. (Or fewer. Use your judgement. Section 508 regulations technically require a skip link in every navbar, even for a page footer.)

Note that skip-navigation links have to be visible; a lot of people use hyperlinked single-pixel GIFs with alt texts, but those are invisible to mobility-impaired people, most of whom have normal vision. The links dont have to be ugly or intrusive, but they have to be plainly visible and selectable. (If you want to be thorough, you can give them accesskey and tabindex values.)

Do those two things and your site becomes vastly more accessible to two large disability groups right then and there.

Accessible Slashdot?

by ictatha

How does Slashdot stack up? What about blog-type sites in general? What can be done on these types of sites to make them more accessible?

Mark Pilgrim has fully strip-mined this topic. (He also tech-edited my book and is generally formidable.)

The issue here is random vs. serial access. A nondisabled site visitor can jump around the page. If you can see, its very easy to skim the page, and it is also very easy to zip to what interests you if you can operate a mouse or keyboard well. Nondisabled people have random access to the contents of a page. Many disabled people the blind and the mobility-impaired in specific experience a Web site serially, with one item after another articulated (as in speech or Braille) or selected. The page author can make skipping around easier, and so can relevant software like screen readers, but its still going to be harder to navigate than for a nondisabled person.

Slashdot is dominated by words. The page introducing this interview carried about 6,900 words even with minimal comment expansion. The issue, then, becomes navigation, which I discussed in the previous answer. Adding hyperlinks to skip various navbars would be a good first step.

Slashdot could certainly use better semantic markup. Valid code is a must; I want Slashdot to eat my own dog food. Subject lines of postings could and should be marked up as headings (h1 through h6); font elements could be eliminated; Im not wild about table markup to achieve indention, though making structural hierarchies apparent is not easy at all (perhaps unordered lists with a style declaration of list-style-type: none might suffice). It would then be possible to navigate from heading to heading.

If youre running a more limited Weblog with just a couple of screenfuls of text at a time, then my advice is simple: Write valid code, provide a text equivalent for every image, work on navigation a bit, and youve made a big dent in the problem.

Photoblogs or those containing multimedia are, of course, more complicated, but as long as every photo has an alt text and your multimedia is captioned and described, youre doing well. It is certainly easy to add alt texts to your photos, but captioning and description are hard to do well and are technically difficult to implement. Im mentioning the multimedia case merely for completeness; I dont read any blogs that regularly post video and audio. (I suppose The Ben Brown Show was an example.)

Accessibility

by acehole

Do you think that where companies are being sued or forced into updating their Web pages at great expense to include accessibility for the blind in their Web pages when the blind could easily find another similar service offline is reasonable?

You have inadvertently stumbled across an extensive issue in disability law the question of providing equivalent or comparable access, or access that is equal in dignity to that afforded a nondisabled person.

You can draw parallels with the physical world. Think of barrier-free entrances to buildings. If the main entrance is at the centre of the buildings face but uses a staircase you cant remove, then providing a barrier-free entrance at the left side of that building would probably be considered comparable or equivalent access. But if you force a mobility-impaired person to walk through an alleyway and take a rear service elevator that is otherwise used for garbage, your accessibility probably is not comparable or equivalent. (Thats in the case of a relatively new building. A historic building or another exceptional case might permit different treatment of that sort.)

If we consider information media, theres a distinction to be drawn between old and new media, or non-electronic and electronic forms. Books are the canonical example: They cannot be made intrinsically accessible to a blind person because a book embodies a single immutable form. You have to provide accessibility elsewhere, as through a large-print edition (its a separate form), a Braille edition (also separate), or a talking book (separate yet again).

Electronic (or audiovisual) media can carry accessibility along with themselves:

• You can add closed captions and closed descriptions to a television program, DVD, online video segment, or first-run movie. (Im skipping some technical details in the movie example.)
• You can add closed captions to a videotape.
• You can add accessibility features to a Web site.

(In the first two cases, you could instead add open captions or descriptions that everyone sees or hears, but thats a very unusual practice, and by doing so you essentially create a separate work, just like publishing a large-print, Braille, or talking-book edition of a printed book.)

In all the examples above, you the viewer can activate the accessibility if you need it or ignore it if you dont. Because Web sites are electronic and can carry hidden access features, the answer to aceholes question is no, it is not reasonable to expect disabled people to go somewhere else to get the same information or enjoy the same experience.

Accordingly, yes, Southwest Airlines reservation Web site should be accessible, and no, it is not OK to expect blind people to call a telephone number when nondisabled people do not have to do so. (Read various other reasons why.)

Thats unequal treatment right there. It is not comparable or equivalent treatment, and, I argue, it impugns the dignity of a visually-impaired person who has already made a commitment to independence by using the Web with adaptive technology.

I also reject, in the strongest possible terms, the offensive and offhand claim that accessibility can be achieved at great expense. I believe the colloquial term for a claim like this is bullshit. Updating or retrofitting a site for accessibility does cost more than designing it properly in the first place, but thats true everywhere: Have you costed out adding barrier-free access to an old building vs. including it in the original designs? Retrofitting may cost more, but I deny that the expense is great. Even very extensive sites with huge swaths of multimedia can be made accessible, and it is doubtful that, given the budgets of such sites, the expense would be great.

In any event, developers always find a justification for what they like to do, whether it be Flashturbation or coding custom JavaScript features or whatever else. Its a bit late in the day, in Web-development terms, to claim that accessibility is not one of the arrows in the quiver of the competent practitioner.

Now, another of the subtexts in this question really, it is a spiders web of half-truths, barely-suppressed resentments, and ignorance suggests that the only way to achieve Web accessibility is by being sued or forced. I have consistently argued that lawsuits are the worst way to achieve accessibility, particularly in the U.S., with its poisonous atmosphere. Lawsuits merely get peoples backs up and sour the defendant on the entire concept. Defendants are forced to belittle and invalidate the concerns of people with disabilities merely in order to provide an adequate defense in the case. This is no way to run a railroad.

But lawsuits (and human-rights complaints and other actions) are still necessary from time to time. Disability law is old and tends not to expressly include the Web. (Sometimes it doesnt even include established accessibility techniques for old media, like audio description on TV.)

Its unrealistic to wait around forever for clueless lawmakers, who can barely use a cellphone let alone surf the Web, to update the legislation. To get some kind of jurisprudence on the books, lawsuits and complaints have to be filed from time to time. Sometimes it works, sometimes it doesnt, but the law is a tool that must be available to everyone, including people with disabilities, whose rights have legal standing.

A competent Web developer builds accessible Web sites and does not wait to be asked to do so, let alone sued or forced.

Market for Web developers

by ragnar

Im considering a starting up a Web development firm with a focus on accessibility. I have good relations with the principals of an accessibility testing firm and believe the businesses can complement each other well. Im a part owner of a Web development firm at the moment that isnt interested in pursuing this market, but I believe there is a significant market.

Can you elaborate on the market for Web development firms that focus on accessibility? Aside from the normal perils of launching a new business (which Im fairly acquainted with), can you expound on the market need for firms that endeavor to deliver accessible content?

Deliver[ing] accessible content and starting up a Web development firm with a focus on accessibility are two different things, so lets focus on the latter.

I would say that the market for accessibility-specific Web consultancies is rather small and will have a short lifespan. I can say this with some confidence as I am an authority on accessibility, with a published book to prove it, and I hardly get any business. Even taking other factors into account, I think its the nature of the work. I have various reliable indications that other consultants arent flush with activity, either.

Why?

• Accessibility is neglected. People cant hire you to do what they never knew needed to be done anyway. Nor will they hire you to do what they resent having to do in the first place and will resist doing until their dying breath.
• Contracts are small. Even very large sites tend to be run by CMSs or templates. Once you clean those up, boom, tens of thousands of pages become accessible. There is often not a lot of billable work involved, as I know myself all too well.
• Attainable expertise. If, as I contend, accessibility is merely one of the skills a competent developer must have, eventually all the competent developers will gain that expertise. They wont need outside experts. Even if in-house access knowledge is demonstrably worse than outside consultants, there are all sorts of precedents for companies making do with barely-passable accessibility because its cheaper. There is a preference for meeting the letter of any requirements (whether self- or externally-imposed) rather than doing accessibility well.

Now, what may work massively better is, in fact, accessibility testing (and certification). It is extremely difficult and time-consuming to test site accessibility with actual disabled persons using actual adaptive technology. A firm that updates Web sites to accessibility standards, advises on how to write new sites that conform, and tests them to prove it may be a winning combination.

The issue of then certifying a site as being accessible (or meeting certain requirements) becomes a bit trickier, but Id really like to see someone give it a go. Note that any venture like this will require thoroughgoing knowledge of the Web Content Accessibility Guidelines, the Section 508 regs, adaptive technology, and multimedia accessibility, and that knowledge definitely includes an understanding of exceptions to the rules. I deal with too many people who literally read and literally apply whatever guideline theyve decided is gospel. Accessibility requires human judgement based on knowledge and experience. Dont set up shop without it.

What of dynamic images (charts and graphs)?

by kuwan

I see that Chapter 6 addresses the image problem which you state is a core concern in accessibility. My question is, what is your solution to data-intensive sites that display their information using graphs? For sites that have constantly changing data (stock charts, for example), what solutions/tools are there to make their graphics accessible?

The answer is that such information, in certain cases, cannot be made meaningfully accessible to a blind or visually-impaired person, or probably to a learning-disabled person. Other disability groups should be unaffected.

This, of course, leads me to my perennial complaint about the Web Accessibility Initiative and accessibility advocates generally: Theyve got no style. They have no understanding of graphic design and typography, and they project this ignorance onto the rest of the world.

To use one of my maxims, accessibility opponents think accessibility means a text-only Web site and hate the idea, while accessibility advocates also think it means a text-only site and love the idea. Theyre both wrong.

One consequence of this ignorance of visual design? The implicit claim that every illustration can be epitomized in words. You could only make this claim if you were so visually unsophisticated that you couldnt differentiate one kind of illustration from another. Of course, this is hogwash: The reason why we use illustrations is because words (or numbers) are sometimes too hard to understand by themselves.

A graph of stock performance, radar weather maps, ultrasound images any picture that is worth much more than a thousand words presents a quandary. The goal here is accessibility a disabled visitor must have equivalent access to the information conveyed by the graphic. If the underlying data is numeric, in theory you could provide the underlying data (as through the longdesc attribute of the img element just set up an HTML file, or, theoretically, a spreadsheet or a PDF, that could be loaded to describe the illustration at length).

But remember, all that numeric data was so hard to understand for nondisabled people that it was turned into a chart; now youre expecting screen-reader users to wade through those numbers one at a time? Like packing, unpacking, and repacking a suitcase, converting data to graphics and back again tends to leave something behind in the transformation.

You may have provided a text equivalent in such a case, but you have not provided accessibility.

I am not giving a carte-blanche exemption here. Many charts and graphs have one or two key points that could, in fact, be added to something as simple as an alt text: alt="Graph shows 12.2% increase in HIV seroconversion in gay males 18 to 24, 1996 to 2001". Even severely complex illustrations require at least a structural placeholder, like alt="Hubble photograph of Jupiter, its rings, and its satellites".

Its true that genuinely equal access to the information embodied in complex illustrations can be unattainable. These are exceptional cases, but they do come up.

Useful links:

• National Braille Associations recommended practices for converting illustrations into accessible forms
• PopChart by Corda attempts to automatically write long descriptions of (numerical) graphs

Deaf-blind

by gmhowell (26755)

Text-to-speech works fine for blind people (mostly). Deaf people can see most Web content. What the heck are deaf-blind people supposed to do?

One of the joys of Delphi, GEnie, Compuserve, etc. is that the discussion boards worked fine with simple telnet access, and Braille TTYs. The various Web boards that have supplanted them dont seem like they would work as well (sorry, havent tried any yet; those Braille TTYs aint cheap).

Yes, this is a personal question (see .sig).

I need help with tech solutions for the deaf-blind. Please contact me via E-mail if you have any experience in this.

Well, deaf-blind people are difficult to accommodate. Theyre also rare: Though adequate population numbers are hard to find, perhaps 11,000 deaf-blind people live in the U.S. But in some contexts, the fact that theyre deaf has no bearing on accessibility. Blindness is the issue.

Screen readers (manufacturer list) not only can turn Web sites and computer software into voice, they can also typically output text to Braille displays. (I wouldnt call them Braille TTYs, since those are used to communicate by telephone.) Braille displays are fascinating, rarefied, and costly devices. Tieman, Freedom Scientific, and ALVA are notable manufacturers. Not all that many people use them, in part because not all that many people read Braille (maybe 10% of blind people), though essentially all deaf-blind people read Braille.

Anyway, for a Web site that does not include multimedia, the fact that youre also deaf has no influence on accessibility if youre already blind. For a deaf-blind person using a screen reader with a Braille display, ordinary Web accessibility becomes the issue, though Id say that navigation help becomes much more important there. Experienced speech-output users run speech at superhuman speeds (300 words a minute is not uncommon), meaning you can burn through a page, albeit in serial fashion, pretty quickly. Given that Braille displays provide one or a couple of lines of Braille at a time, its a more time-consuming procedure.

Now, for sites that do contain multimedia, there is no viable option. An obvious course of action (requested by one activist group) would be to combine caption transcripts and audio-description scripts so that one could essentially read a text rendering of a videoclip, but there is no technology that can actually do that yet. (Yet. I have plans.) Combined script-transcripts of this sort have been attempted manually a couple of times (and I mentioned the idea back in 1999), but I dont know of any research on how well it all worked.

Alternative (non-computer) devices

by superflippy

Increasingly, people are using non-computer devices (cell phones, PDAs) to browse Web sites. What alternative devices are disabled people using, and how are they using them in ways Web developers might not have considered (e.g. voice browser in cell phone)?

Im not really up on that topic. The PAC Mate is one such device; its essentially a screen reader without a screen or free-standing computer.

Accessible site, or accessible browser?

by vofka

I am a partially-sighted person, and I have to admit that I do frequently have difficulty with accessibility issues, particularly with large corporate Web sites which all seem to be full-flow multimedia blitzes which require 1600x1200 resolution or higher, and usually override the default browser fonts to make them smaller.

However, there are a number of browsers, such as Mozilla (just one example, Im sure there are others!) which allow the user to zoom the text on a page, to override colour settings etc.

Though it is undoubtedly important for Webmasters to pay great thought to the design of their sites in terms of colour, font size and multimedia content, how much relative importance should be placed on browser design, and the browsers ability to override the design decisions of the creator of a site?

Its important and overlooked. It would be nice if we had a browser that actually supported all of HTML; we dont (no, not even Mozilla). Then it would be nice if CSS1 and CSS2 were fully supported admittedly an onerous task what with the myriad interactions and the various ambiguities in the spec.

At that point, yes, the user customizability in CSS and the many options available in HTML would presumably be up to the user to control. I think its ridiculous that the only really effective way to override a page authors CSS is for you, the harried, humble Web-surfer, to write your own CSS declarations (dont forget !important!) and activate the file in your browser, if thats even possible. This is the sort of thing that should be built into browser preferences, available for easy use. The first time you start up a browser, it should explicitly ask you if you have any accessibility requirements; a lot of people dont even know about what few customization features browsers currently offer.

Ill make another of my analogies. Remember the lack of visual sophistication of accessibility advocates? They want designers to work at their level by providing accessibility, but they never seem to understand that the converse is also true accessibility activists must learn to work at designers level by providing good site design. By the same token, if page authors are expected to use every practical accessibility feature, then browser makers must be expected to support all of them and support them well.

In the immortal words of Comedy Central, Weve upped our standards. Up yours!

See also: User Agent Accessibility Guidelines.

Physical vs. cognitive political clout

by Aquitaine

Dear Mr. Clark,

I am a Web developer for the Program on Employment and Disability at the School of Industrial Labor Relations at Cornell University. Web accessibility is a serious issue for us, and we try to keep abreast of innovative approaches to design so we can find that elusive place where universal accessibility meets intelligent and aesthetically pleasing layout. We recently spoke with Cynthia Waddell (one of 8 authors of Constructing Accessible Web Sites, also out fairly recently) on this subject, but I found her unwilling to commit to anything other than suggestions rather than real technical solutions.

There are two sticky issues that I have encountered. The first is the notion of universal access. Mrs. Waddell indicated that, working with the W3C, she was coming up with a list of Web sites that met Priorities 13 of the W3C WAI and were still aesthetically impressive (she did not have a list ready). As you are no doubt aware, many sites that tout universal access are themselves victims of poor design -- the problem of Yes, its W3C/WAI compliant across the board, but its ugly as sin. Do you believe that a site can have a single interface that is truly universally accessible, or do you believe that sites should have alternate interfaces? (The Web equivalent of Do we have a ramp and stairs or just a ramp?)

Along those lines, it is apparent to me that the accessibility guidelines are designed to be useful in a manner proportional to the lobbying power of disability rights groups. That is to say, blind people and deaf people, although they comprise extraordinarily small percentages of people with disabilities, have an enormous amount of political clout when compared to people with cognitive disorders -- ADD, ADHD, dyslexia, autism, schizo-affective disorder, schizophrenia, et cetera. Because these disability groups lack the considerable power of a strong advocacy group, do you feel that they have been left by the wayside when it comes to Section 508 or WAI? (And do you personally believe that total-WAI compliance is necessary, or just Section 508?)

My apologies for several questions at once, but we take this issue very seriously here and your answers will go a long way to helping us do what we do to better suit the community that ILR serves.

Thanks so much, Samuel W. Knowlton

To answer your first question: A single interface works for most Web sites. You can simply make the site itself intrinsically accessible to most disability groups.

The only alternative the question seems to envisage is specifically custom-designing an alternative interface for disabled users. In other words, a site would exist in two or more predesigned forms. Thats not the only way.

Some work is being done to permit people and the devices they use to specify formats and capabilities they may possess or require. Have a look at Composite Capabilities/Preferences Profiles. It all boils down to semantic markup again. A single HTML page, if marked up properly, could be visited by a plain-Jane browser and displayed in a way thats familiar to nondisabled users; nothing special would happen.

But if you had a CC/PP-compliant browser or other device, and if the page were coded correctly, and if the server understood CC/PP protocols, then the page would automatically reconfigure itself to your needs without the original page authors having to do anything special. In fact, authors could not predict what kind of transformations would occur, nor would they care.

So a few things could happen. If youre totally blind, your page could be rearranged so the search box and content are at the top, with sidebars, navbars, and anything else uninteresting at the end and no images loaded at all. A low-vision person could ask for larger type on content sections and normal-sized type everywhere else, unless a command were issued to blow up, say, a navbar. (There could be continuous interaction between the user and the server.)

XHTML 2.0 might push this concept along a little, what with its section element, but its all still a pipe dream, really.

Now, as to the second question, putting blind and deaf people together in a group claimed to have an enormous amount of political clout is not really applicable to Web accessibility. Deaf people face very few accessibility barriers in using the Web multimedia is pretty much it. Blind people face very large barriers because the Web is a visual medium. Theres a qualitative difference.

Its true that people with cognitive disabilities have been neglected in Web accessibility. Why? Few people in the wider accessibility field have expertise on the topic. The Web Content Accessibility Guidelines 2.0, when its finished, will contain many more provisions for this group.

The qualitative difference remains. It is arguably difficult or impossible to make Web sites most of which are dominated by text genuinely accessible even to certain specific groups with cognitive disabilities. Remedies proposed in the Web Content Accessibility Guidelines 2.0 drafts would not guarantee access for learning-disabled people. Some of those remedies involve adding illustrations (non-text content) to every single page (yes, the Web Accessibility Initiative may issue that requirement) or rewriting the page according to some kind of half-arsed, doctrinaire editing scheme.

There wouldnt be the same jump in accessibility between a noncompliant site and one that meets those guidelines as you would find with, say, visual impairment. Sites would end up being merely less confusing as opposed to not confusing. You might have met the spec, but you could not be sure you had achieved accessibility.

Certain cognitive disabilities do not even require accommodation online.

Moreover, while accessibility for many other disability groups almost never alters the visual appearance of a page (visible skip-navigation links are a counterexample), it could be argued that a page thats truly accessible to people with learning or cognitive disabilities would have to be custom-created by experts. Thats the stark truth involved in achieving high accessibility for this group. You have to alter content as opposed to metadata or presentation. To accommodate other disabilities, you add information, like alt texts; to accommodate certain learning disabilities, you must remove or alter information.

I am in favour of improved accessibility for cognitively-disabled persons, but Ill only support proposals that can be shown to actually make sites accessible to that group. Im also not willing to destroy the Web as we know it ostensibly in order to save it for a disability group whose needs might not even be met in the process.

Nobody has presented credible evidence that current proposals actually will work, and certainly the evidence supporting the current WCAG 2.0 proposals is weak. In other words, if we want to fix this problem, its going to take a lot more work.

And to answer the final question, Section 508 regulations backhandedly incorporate almost all of the Web Content Accessibility Guidelines 1.0, but go beyond the latter in certain respects. Both guideline sets have all sorts of problems, but complying with either of them will assure reasonable accessibility for large numbers of people.

skunkeh writes: "Amazon have launched a brand new web service interface to their huge database of products. The interface can be used through SOAP or by requesting XML pages via URL, and their development kit comes with example code in Java and Perl. A Python wrapper is also available, and I have released some sample code in PHP."