| 
Title: ASP.NET AJAX in Action
Authors: Alessandro Gallo, David Barkol, and Rama Krishna Vavilala
Published: August, 2007
Pages: 576 pages
ISBN: 1-933988-14-2
Ajax revolutionized how users interact with web pages. Gone are frustrating page refreshes, lost scroll positions, intermittent interactions, and flat, boring pages. Instead we have a new generation of fast, rich, and intuitive web applications. The ASP.NET AJAX framework puts the power of Ajax into the hands of Microsoft ASP.NET developers. ASP.NET AJAX, formerly called Atlas, is a new free framework from Microsoft designed to easily add Ajax features to ASP.NET applications. With this technology, ASP.NET developers can easily build more interactive and highly-personalized web applications that work across all most popular browsers.
ASP.NET AJAX in Action is a fast-paced, example-rich tutorial designed for ASP.NET web developers and written by ASP.NET AJAX experts Alessandro “Garbin” Gallo, David Barkol, and Rama Krishna Vavilala. This book introduces you to Ajax applications and to the ASP.NET AJAX technology. Beginners will appreciate the clear explanations of key ideas and terminology. Intermediate and advanced ASP.NET developers will find a no-nonsense learning source and well-organized reference.
ASP.NET AJAX in Action offers a rich set of examples and meticulous explanations. The extensive code samples are accompanied by accurate and rigorous explanations of the concepts behind development with ASP.NET AJAX. In this book, you will discover how to use
Microsoft Ajax Library
Partial rendering with UpdatePanels
Advanced client and server techniques
Ajax Control Toolkit
If you are a web developer looking to bring your web pages to life and to enhance the user experience, this book is for you.
ASP.NET AJAX in Action will give you with the knowledge and tools you need to more easily craft the next generation of Ajax applications. With the help of the Microsoft ASP.NET AJAX framework, Ajax development has never been easier and more instinctive for both client-script developers and ASP.NET developers alike.
WHAT'S INSIDE:
Lots of code examples
Deep coverage of ASP.NET AJAX Extensions
Covers the ASP.NET AJAX Futures CTP
Partial page rendering with UpdatePanels
Advanced client and server techniques
About the Authors
Alessandro “Garbin” Gallo is a Microsoft MVP in the Visual ASP/ASP.NET category and has been an active contributor for the Ajax Control Toolkit project. As a .NET developer/consultant with a primary focus on ASP.NET application design and development, Alessandro has been developing with ASP.NET AJAX since the very first CTP. Notably, he won the Grand Prize at the Mash-it-up with ASP.NET AJAX contest held by Microsoft in 2006.
David Barkol is a Principal Consultant for Neudesic, one of Microsoft's leading .NET professional services firms and a Gold Certified Partner. At Neudesic David specializes in providing custom .NET solutions that leverage technologies such as ASP.NET, Web Services, Windows Forms, SQL Server, and C#. He is an MCSD in .NET and a member of the Microsoft ASP.NET Advisory Council. David resides in tropical La Palma, CA.
Rama Krishna Vavilala is a senior software developer/architect at 3C Software, a leading supplier of Cost Management Solutions. He has designed and developed three different versions of Impact:ECS™ (3C Softwares product suite). Currently, he is designing an Ajax-based web application using ASP.NET AJAX. This application will be a part of the Impact:ECS™ suite. He is a regular contributor at The Code Project and has contributed around 20 articles on wide ranging subjects
Table Of Contents
Part 1 ASP.NET AJAX basics
1 Introducing ASP.NET AJAX
1.1 What is Ajax?
1.2 ASP.NET AJAX architecture
1.3 ASP.NET AJAX in action
1.4 Summary
2 First steps with the Microsoft Ajax Library
2.1 A quick overview of the library
2.2 The Application model
2.3 Working with the DOM
2.4 Making development with JavaScript easier
2.5 Summary
3 JavaScript for Ajax developers
3.1 Working with objects
3.2 Working with JSON
3.3 Classes in JavaScript
3.4 Understanding inheritance
3.5 Understanding interfaces and enumerations
3.6 Using type reflection
3.7 Working with events
3.8 Summary
4 Exploring the Ajax server extensions
4.1 Ajax for ASP.NET developers
4.2 Enhancing an existing ASP.NET site
4.3 ScriptManager: the brains of an Ajax page
4.4 Partial-page updates
4.5 Summary
5 Making asynchronous network calls
5.1 Working with ASP.NET Web Services
5.2 The asynchronous communication layer
5.3 Consuming external Web Services
5.4 Using ASP.NET application services
5.5 Summary
6 Partial-page rendering with UpdatePanels
6.1 With great power comes great responsibility
6.2 Getting to know the UpdatePanel
6.3 Triggers
6.4 Advanced techniques
6.5 Live GridView filter
6.6 Summary
Part 2 Advanced techniques
7 Under the hood of the UpdatePanel
7.1 The PageRequestManager: the unsung hero
7.2 A client-side event viewer
7.3 UpdatePanel cookbook
7.4 Caveats and limitations
7.5 Summary
8 ASP.NET AJAX client components
8.1 The client component model
8.2 Working with client components
8.3 Behaviors
8.4 Controls
8.5 Summary
9 Building Ajax-enabled controls
9.1 Script descriptors
9.2 Introduction to Ajax-enabled controls
9.3 Extenders
9.4 Script controls
9.5 Summary
10 Developing with the Ajax Control Toolkit
10.1 A world of extenders
10.2 The Ajax Control Toolkit API
10.3 Animations
10.4 Summary
Part 3 ASP.NET AJAX Futures
11 XML Script
11.1 XML Script basics
11.2 Actions
11.3 Bindings
11.4 Summary
12 Dragging and dropping
12.1 The drag-and-drop engine
12.2 A drag-and-drop shopping cart
12.3 Summary
Part 4 Mastering ASP.NET AJAX
13 Implementing common Ajax patterns
13.1 Script versioning
13.2 Helpers, help me help you!
13.3 Logical navigation and unique URLs
13.4 Declarative data binding
13.5 Declarative widgets
13.6 Summary
Source code (12MB)
Sample Chapter 2
Sample Chapter 4
Amazon Link: ASP.NET AJAX in Action
Monday, August 27, 2007
ASP.NET AJAX in Action
Sunday, July 8, 2007
An Interview With Ken Henderson About The Book SQL Server 2005 Practical Troubleshooting: The Database Engine
I posted this on my SQL Server blog but decided to post it here also.
I am a big fan of Ken Henderson’s books, I believe that every SQL Server developer should have a copy of his books. When I noticed on Amazon.com that the book SQL Server 2005 Practical Troubleshooting: The Database Engine which listed Ken Henderson as its editor would be coming out soon I got very excited. I decided to send Ken an email to see if he would be willing to answer some questions I had about the book. To my surprise Ken was more than willing to accommodate my request.
The question-and-answer session with Ken that follows was conducted via email.
Denis: What is the audience for this book, is it the enterprise user or can a small department benefit from the tips in this book?
Ken: Both types of users would benefit. Anyone who’s ever had a problem with SQL Server has probably noticed how few resources there are out there for troubleshooting SQL Server issues. There are plenty of resources that talk about how it works. There are many that discuss how to write code for it. But there are scant few that talk about what to do when something goes wrong. This book is intended for that audience. It is also intended for those who want to better understand how the product works and to be prepared in the event that something does go wrong with it. SQL Server doesn’t break often, but, when it does, this book will help you deal with it.
Denis: For a customer who has a performance problem that is not hardware related, what would you say are the most important chapters in this book (in order of importance)?
Ken: The Query Processor Issues chapter and the Procedure Cache Issues chapter are the two best for this type of problem.
Denis: Seven developers from the SQL Server development team and three support professionals from Microsoft Customer Support Services wrote this book. What took so long to write a book like this, and why wasn’t there a SQL Server 2000 version? Is it because SQL Server has truly grown to be a major player in the enterprise market and there is a definitive need for a book like this now?
Ken: The book took so long because all of the authors are first-time authors, and they are very busy people. There was no SQL Server 2000 version because I was too busy with my own projects to begin this project back then. SQL Server is indeed a major player in the enterprise, but I believe it has been since SQL Server 7.0. That particular aspect had nothing to do with the timing of this book.
Denis: I noticed you are listed as editor of this book. Have you written any chapters in this book?
Ken: No, I did not write any of the chapters of the book. I also tried to preserve each author’s writing style. Each chapter includes its own byline, and I have edited them as little as possible. Because some of the authors were more capable than others, I necessarily had to be involved to varying degrees with each chapter. Some chapters needed lots of editing; some very little. I think each individual perspective represented in the book is a valuable one, but I also think they speak in unison on the important points of practical troubleshooting with SQL Server.
Denis: What new technologies in SQL Server 2005 do you think are the most beneficial for performance?
Ken: There are really too many to list. A few that come to mind at the moment: instant file growth, improved wildcard support, more sophisticated cache management, improved scaling on big hardware, the XML data type and richer XML support in general, CLR integration, etc.
Denis: This book as I understand has a lot of internals information from the people who either wrote the product or have supported it that currently is not available anywhere else--is that right?
Ken: Yes, the majority of the authors were actually developers on the product. A few were support engineers who supported the product. All have had full access to the SQL Server source code for many years.
Denis: What will a person who reads this book gain in terms of understanding how to performance tune a server?
Ken: They will better understand both how the server works and also how to recognize and troubleshoot common performance problems.
Denis: Is the book geared towards a beginner/intermediate level user or do you have to be an advanced user to really utilize the information in this book?
Ken: There is something in this book for everyone. I’d like to think that beginners, intermediates, and advanced users alike would benefit from reading it.
Denis: What are the most important things a person can do to master SQL Server?
Ken: Naturally, the best thing a person could do would be to do what the authors of this book did: study the SQL Server source code. Studying the SQL Server source gives you insight into how the product works that is impossible to gain through any other means. But, given that that excludes pretty much everyone outside of Microsoft, here are some general thoughts:
#1, understand how Windows works at a very low level and how SQL Server utilizes the many facilities it offers
#2, understand how the product was designed and how it was intended to be used
#3, explore it not only as a user, but as a developer. Fire up a debugger and see how it works under the hood
#4, build real apps with it, using its various components as they were intended to be used
Denis: What are the most important things a person can do to master Transact-SQL?
Ken: My initial thought is that, again, studying the SQL Server source code is the shortest path to the deepest understanding of the language. That said, here are some general thoughts in no particular order:
#1, understand how SQL Server works. Understand the intricacies of performance tuning on SQL Server. Know how data is stored. Understand memory management and scheduling at a very low level. Understand logging and tempdb semantics. Remember that SQL Server is just an application. It’s not magical and can be misused and abused just like any other app
#2, learn the syntax and semantics of the language inside-out. Get a feel for its strengths and weaknesses, and code to those strengths. Always lean toward writing set-oriented code when you can
#3, study solutions to hard problems that are available in various forms, and apply the techniques you learn to solve your own problems
#4, learn other SQL dialects so that you can become familiar with their unique attributes and understand how T-SQL compares with them. Gain an understanding of where T-SQL fits in the general taxonomy of SQL dialects
#5, learn other languages besides SQL. If your favorite programming language is T-SQL, you probably don’t know many languages. Learn C#, VB, Perl, Ruby, C++, or any others you can work into your research so that you can better understand software engineering as a discipline and so that you can more clearly see T-SQL’s strengths and weaknesses when compared with those other languages. Try to see where you might apply techniques from those other languages to solve problems you encounter in T-SQL. Familiarize yourself with what a design pattern is, what an idiom is, what refactoring is, and apply these concepts in T-SQL just as you would in any other “real” language
#6, understand the various SQL Server components and other technologies so that you can accurately ascertain when it’s appropriate to use T-SQL. It’s not the solution for every problem. As the old saying goes, “When all you have is a hammer, everything starts to look like a nail.” By broadening your knowledge of the tools and problem solutions available to you, you’ll be more likely to choose the best one when deciding how to design a piece of software or solve a particular problem. T-SQL may turn out not to be the best way to go in a given situation
And I will end with 9 questions for Ken not related to this book
Denis: What SQL Server books are on your bookshelf?
Ken: I have Celko’s books, Darren Green’s book, and a few others. Unfortunately, I don’t have time to read as much as I’d like. I spend most of my time either writing code for the product or studying code written by others on the SQL Server development team. The majority of my research into how SQL Server works happens via studying its source code directly.
Denis: Why do you write technical books?
Ken: I write technical books because I enjoy passing on what I’ve learned as a developer. That’s different from enjoying teaching people. I do enjoy teaching people, but that’s not why I write books. Some of the things I’ve learned about SQL Server took me years to master. I enjoy passing that on to people so that they don’t have to travel the same arduous roads that I did. I enjoy helping people. That’s different from teaching for the sake of teaching. I could never train people for a living. I am a programmer by trade, and everything else is an offshoot of that.
If I didn’t think I had something unique to bring to the discussion, I don’t think I’d write books. I don’t ever want to do what has already been done. I want to bring a fresh perspective to technical books, and I want to explore things in ways most other authors wouldn’t. If my work was exactly like everyone else’s, there’d be no reason for it to exist, and I wouldn’t bother. Given that I’ve never written fulltime but have always held down a regular day job while writing my books, the work itself is simply too hard to do just to be a clone of someone else. When people pick up one of my books, I hope they know right away that it’s one of mine, that it speaks with a distinctive voice, and I hope they think they might learn something from it simply because they trust me as an author.
Denis: Why did you join Microsoft?
Ken: I joined Microsoft to get inside SQL Server. I felt that the only way to go beyond the books and whitepapers currently out there on SQL Server was to see the source code for myself, and the only way that was going to happen is if I joined the company. I wanted to approach the exploration of SQL Server from a career developer’s standpoint, something that I had not seen done before. Most SQL Server books were written by professional trainers and former DBAs. As a career developer, I thought I could bring a fresh perspective to the coverage of SQL Server, and I felt the only way to really do that was to “go live with the natives” for a few years.
Denis: Who are your favorite authors?
Ken: Mark Twain, Kurt Vonnegut, Bart D. Erhman, Robert Price, Dean Koontz, Stephen King, Joe Celko, Sam Harris, Richard Carrier, Don Box, David Solomon, Charles Petzold, Kent Beck, Martin Fowler, Bruce Eckel, and many others.
Denis: Who do you consider your rival authors?
Ken: I don’t really think of anyone else out there as a rival. When I write a book, I mainly measure my work against my concept of the perfect book. I write for me. There’s a great book out there titled On Writing Well where the author, William Zinsser, repeats the old truism that quality is its own reward. It really is. I love the fact that people enjoy my books, but, really, the day I finish the final draft of a book and can say that I’m really done with it (at least for the moment :-) ), I’ve accomplished my goal. If it never sold a copy, I’d still feel fulfilled. I do care how it sells against other books, but I don’t really focus on it and don’t get caught up in any type of rivalries with other authors or other books.
Because I always want to write a better book than I wrote last time, I necessarily compete with my previous work and I compete against what I think the ideal technical book is. I think there’s enough room out there for lots of technical authors (it’s not as though people only buy one technical book and no others), and I have special empathy for my comrades out there who have to slog along in the middle of the night to crank their books out.
Denis: Where did the “Guru’s Guide” concept come from?
Ken: Wayne Snyder, one of the MVPs reviewing the manuscript for the first Guru’s Guide (which was at that time unnamed), wrote in the margin, “Hey, Ken, this is really a guru’s guide to solutions to hard T-SQL problems!” at which point the marketing folk at Addison-Wesley saw this and seized upon it. We had kicked around several titles, but hadn’t settled on any of them. As soon as they saw this, they pushed me hard to use it, and I reluctantly agreed. I didn’t like it initially because I thought the title of a technical book should focus on either the subject material or its intended audience, not its author. There was an understanding that we’d revisit the title when we did the second book (I was originally under contract to do three SQL Server books for Addison-Wesley), but then sales of the first book exploded, and there was no way we could change it at that point.
Denis: What do you think of all the accolades the Guru’s Guide books have received?
Ken: I am appreciative of them, but continue to be surprised by the longevity of the books and the reception they’ve garnered. I thought I was writing a niche book when I wrote that first Guru’s Guide book. I just wanted to get down everything I knew about T-SQL before I forgot it ;-). I will continue to write the kinds of books I like to read as long as people will buy them, so I hope that people continue to enjoy my work.
Denis: Will you be updating your Guru’s Guide books for SQL Server 2005? If so, when will they be out?
Ken: Yes. The second editions of the Guru’s Guide books should be out in 2007.
Denis: Describe your most unpleasant experience as an author.
Ken: I had a particularly unpleasant experience during the work on my architecture book when I had to send one of the technical reviewers packing. He was someone who’d provided useful feedback on my work in the past and someone I’d handpicked to review the book for technical issues. I usually appreciate negative feedback during the technical review process and generally consider it the most useful type of feedback, but this reviewer focused more on arguing with me about what should and shouldn’t be in the book than reviewing what was there for technical accuracy. He had a problem with the fact that I spent the first 300 pages of the book (the book ended up being over 1000 pages long) covering fundamental concepts (e.g., Windows internals) that I thought people needed to understand in order to understand the rest of the book.
I had seen people within Microsoft struggle to understand SQL Server internals because they did not have a good grasp of how Windows worked or how XML worked or how COM worked, or whatever, and, assuming readers would likely face the same types of challenges, I set out to remedy that in my book. I also wanted to go deeper than any SQL Server book ever had, and that necessitated being able to assume a certain amount of fundamental knowledge going in. I wrote him back after his first objection to the section and told him that, while I respected his opinion, I had my reasons for including it, and I explained those reasons as best I could.
He suggested I just refer people to authors like Richter and Solomon and those guys, and I told him I’d considered that, but that ultimately I felt that would be cutting corners and would be a huge inconvenience since readers would have to purchase several other books just to understand mine. No single other book had all the technical fundamentals I felt were essential, nor did any of them cover the material the way that I wanted it covered--in a manner that was designed especially for DBAs and database people. At the same time, most readers wouldn’t be able to skip the fundamentals coverage in some form or fashion because they wouldn’t be able to understand my SQL Server internals coverage without it. While it was certainly a huge amount of work for me to include this section (it was much like writing a whole separate book), I felt it was the right thing to do.
He persisted with his objections and continued to voice them not only to me but also to the editing team at Addison-Wesley. I told him on several occasions that I respected his opinion, but that, as the author, the call was mine to make and that I’d made it. This seemed to irritate him, and he continued to consume a certain amount of my time with correspondence related to the subject. At one point, I counted 7 separate threads from him on that one subject in my Inbox, and the folks at Addison-Wesley had begun to complain about him. The fundamentals section, and his negative remarks regarding it, came to dominate all the feedback we got from him. While other reviewers were either indifferent to the coverage of Windows internals in a SQL Server book (it was certainly a novel approach) or embraced it outright, he became increasingly more negative as we went along. We got useful feedback on the entirety of the manuscript from all the other reviewers, but he seemed unable to move on from the fundamentals issue. Eventually, I had my fill of dealing with him and cut him loose from the project. I’m a fairly patient person, but I just didn’t have time to deal with him anymore.
Technical reviewers sometimes get on crusades and attempt to usurp the role of the author to some extent. Until this happened, I’d never personally experienced it, but I’d heard of it. At the end of the day, the decision as to what is and isn’t in a book is the author’s to make, and the role of the technical reviewer is to identify technical issues with whatever it is that will be in the book. Decisions about content belong to the author, and, to a lesser extent, the publisher and the publisher’s editing team. I guess the lesson I learned here was to be more careful with whom I select for involvement with my projects. I always want honest feedback, and, fortunately, I know a lot of people who will happily point out every technical issue they find with my work without trying to become a de facto coauthor.
About the book:
Paperback: 456 pages
Publisher: Addison-Wesley; 1ST edition
Language: English
ISBN: 0321447743
Contents
Preface
Chapter 1 Waiting and Blocking Issues
Chapter 2 Data Corruption and Recovery Issues
Chapter 3 Memory Issues
Chapter 4 Procedure Cache Issues
Chapter 5 Query Processor Issues
Chapter 6 Server Crashes and Other Critical Failures
Chapter 7 Service Broker Issues
Chapter 8 SQLOS and Scheduling Issues
Chapter 9 Tempdb Issues
Chapter 10 Clustering Issues
Index
Thanks to Ken for answering all these questions and if there is one reason this year to buy your own holiday gift then SQL Server 2005 Practical Troubleshooting: The Database Engine is it
Amazon Links: 
Monday, July 2, 2007
Beautiful Code Leading Programmers Explain How They Think
First Edition: June 2007
Series: Theory In Practice
ISBN 10: 0-596-51004-7
ISBN 13: 9780596510046
Pages: 618
How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes.
This is not simply another design patterns book, or another software engineering treatise on the right and wrong way to do things. The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules. Beautiful Code is an opportunity for master coders to tell their story. All author royalties will be donated to Amnesty International.
Table Of Contents
Foreword
by Greg Wilson
Preface
1. A Regular Expression Matcher
by Brian Kernighan
The Practice of Programming
Implementation
Discussion
Alternatives
Building on It
Conclusion
by Karl Fogel
Version Control and Tree Transformation
Expressing Tree Differences
The Delta Editor Interface
But Is It Art?
Abstraction As a Spectator Sport
Conclusions
by Jon Bentley
The Most Beautiful Code I Ever Wrote
More and More with Less and Less
Perspective
What Is Writing?
Conclusion
Acknowledgments
by Tim Bray
On Time
Problem: Weblog Data
Problem: Who Fetched What, When?
Search in the Large
Conclusion
by Elliotte Rusty Harold
The Role of XML Validation
The Problem
Version 1: The Naïve Implementation
Version 2: Imitating the BNF Grammar O(N)
Version 3: First Optimization O(log N)
Version 4: Second Optimization: Don't Check Twice
Version 5: Third Optimization O(1)
Version 6: Fourth Optimization: Caching
The Moral of the Story
by Michael Feathers
An Acceptance Testing Framework in Three Classes
The Challenge of Framework Design
An Open Framework
How Simple Can an HTML Parser Be?
Conclusion
by Alberto Savoia
That Pesky Binary Search
Introducing JUnit
Nailing Binary Search
Conclusion
by Charles Petzold
by Douglas Crockford
JavaScript
Symbol Table
Tokens
Precedence
Expressions
Infix Operators
Prefix Operators
Assignment Operators
Constants
Scope
Statements
Functions
Array and Object Literals
Things to Do and Think About
by Henry S. Warren, Jr.
Basic Methods
Divide and Conquer
Other Methods
Sum and Difference of Population Counts of Two Words
Comparing the Population Counts of Two Words
Counting the 1-Bits in an Array
Applications
by Ashish Gulhati
The Heart of the Start
Untangling the Complexity of Secure Messaging
Usability Is the Key
The Foundation
The Test Suite
The Functioning Prototype
Clean Up, Plug In, Rock On . . .
Hacking in the Himalayas
The Invisible Hand Moves
Speed Does Matter
Communications Privacy for Individual Rights
Hacking the Civilization
by Lincoln Stein
BioPerl and the Bio::Graphics Module
The Bio::Graphics Design Process
Extending Bio::Graphics
Conclusions and Lessons Learned
by Jim Kent
The User Interface of the Gene Sorter
Maintaining a Dialog with the User over the Web
A Little Polymorphism Can Go a Long Way
Filtering Down to Just the Relevant Genes
Theory of Beautiful Code in the Large
Conclusion
by Jack Dongarra and Piotr Luszczek
The Effects of Computer Architectures on Matrix Algorithms
A Decompositional Approach
A Simple Version
LINPACK's DGEFA Subroutine
LAPACK DGETRF
Recursive LU
ScaLAPACK PDGETRF
Multithreading for Multi-Core Systems
A Word About the Error Analysis and Operation Count
Future Directions for Research
Further Reading
by Adam Kolawa
My Idea of Beautiful Code
Introducing the CERN Library
Outer Beauty
Inner Beauty
Conclusion
by Greg Kroah-Hartman
Humble Beginnings
Reduced to Even Smaller Bits
Scaling Up to Thousands of Devices
Small Objects Loosely Joined
by Diomidis Spinellis
From Code to Pointers
From Function Arguments to Argument Pointers
From Filesystems to Filesystem Layers
From Code to a Domain-Specific Language
Multiplexing and Demultiplexing
Layers Forever?
by Andrew Kuchling
Inside the Dictionary
Special Accommodations
Collisions
Resizing
Iterations and Dynamic Changes
Conclusion
Acknowledgments
by Travis E. Oliphant
Key Challenges in N-Dimensional Array Operations
Memory Models for an N-Dimensional Array
NumPy Iterator Origins
Iterator Design
Iterator Interface
Iterator Use
Conclusion
by Ronald Mak
The Mission and the Collaborative Information Portal
Mission Needs
System Architecture
Case Study: The Streamer Service
Reliability
Robustness
Conclusion
by Rogerio Atem de Carvalho and Rafael Monnerat
General Goals of ERP
ERP5
The Underlying Zope Platform
ERP5 Project Concepts
Coding the ERP5 Project
Conclusion
by Bryan Cantrill
by Jeffrey Dean and Sanjay Ghemawat
A Motivating Example
The MapReduce Programming Model
Other MapReduce Examples
A Distributed MapReduce Implementation
Extensions to the Model
Conclusion
Further Reading
Acknowledgments
Appendix: Word Count Solution
by Simon Peyton Jones
A Simple Example: Bank Accounts
Software Transactional Memory
The Santa Claus Problem
Reflections on Haskell
Conclusion
Acknowledgments
by R. Kent Dybvig
Brief Introduction to syntax-case
Expansion Algorithm
Example
Conclusion
by William R. Otte and Douglas C. Schmidt
Sample Application: Logging Service
Object-Oriented Design of the Logging Server Framework
Implementing Sequential Logging Servers
Implementing Concurrent Logging Servers
Conclusion
by Andrew Patzer
Project Background
Exposing Services to External Clients
Routing the Service Using the Factory Pattern
Exchanging Data Using E-Business Protocols
Conclusion
by Andreas Zeller
Debugging a Debugger
A Systematic Process
A Search Problem
Finding the Failure Cause Automatically
Delta Debugging
Minimizing Input
Hunting the Defect
A Prototype Problem
Conclusion
Acknowledgments
Further Reading
by Yukihiro Matsumoto
by Arun Mehta
Basic Design Model
Input Interface
Efficiency of the User Interface
Download
Future Directions
by T. V. Raman
Producing Spoken Output
Speech-Enabling Emacs
Painless Access to Online Information
Summary
Acknowledgments
by Laura Wingerd and Christopher Seiwald
On Being "Bookish"
Alike Looking Alike
The Perils of Indentation
Navigating Code
The Tools We Use
DiffMerge's Checkered Past
Conclusion
Acknowledgments
Further Reading
by Brian Hayes
The Nonroyal Road
Warning to Parenthophobes
Three in a Row
The Slippery Slope
The Triangle Inequality
Meandering On
"Duh!"-I Mean "Aha!"
Conclusion
Further Reading
by Andy Oram
index
Sample Chapter: Chapter 4: Finding Things (PDF Format)
Amazon Link: Beautiful Code: Leading Programmers Explain How They Think
Tuesday, June 26, 2007
Five Books Every Developer Should Read No Matter What Language You Program In
Which books should you read/buy when you are a programmer? I have listed 5 books that have helped me a lot. The books that I have chosen are not specific to any language although some of the books have examples in one language only. Design Patterns has examples in smalltalk and C++ but since the code is not very complicated you should have no problem converting it to your language of choice. I have included links to sample chapters for the books where I could find them. For some of the books I have also provided links to the author's site; some of them have additional material so that you can look at that. I have also provided Amazon links so that you can read reviews. All of these books are rated 4 stars or higher. I have also provided alternate books if I felt that there were more choices for the same subject
Design Patterns
This book is one of the seminal books on patterns in software development. If you are a professional software developer, you must read this. If you are learning to write good software, this is a book that you will need to take on at some point
Design Patterns Site
Code Complete
Code complete provides the reader with an insight into how
to write good and easy to understand code. You will come away from this book with an appreciation of the thought process that should go into writing every class, routine, comment etc...
Software development steps are outlined clearly. Pitfalls to avoid are discussed and rewards obtained from good code is explained. The author tells you what you need to know and most importantly why you need this information. If one applies the ideas in this book, I think you will be a better programmer.
Sample Chapter: Chapter 1: Welcome (pdf)
Sample Chapter: Chapter 5: Design in Construction (pdf)
Code Complete Author's Site
The Pragmatic Programmer
The pragmatic programmer provides invaluable advice to those who are just starting to program, and those who have been programing for years. By following the authors' simple rules you should have gained some programming wisdom that a programmer would realize in a decade.
Extracts from the book
The Preface
Software Entropy
Programming by Coincidence
Evil Wizards
Balance Resources
Summary of the book's tips
Contents
Refactoring
This book will change the way you think about and working with exisiting code. It'll teach you that changing/modifying software is a fact of life. Martin Fowler does a awesome job of describing how to improve the design of existing code by performing various refactorings. Various design patterns are mentioned throughout the text, that is another reason why the design patterns book is so important
Sample Chapter: Refactoring, a First Example
UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design, 2nd Edition
UML has grown. A few years ago, when UML was just getting accepted, a book on how to use it would have been much thinner. But the successful broad uptake of UML led to its semantic notation being expanded. What the authors give us here is a thorough exposition of UML 2.0 and how to use it. It also goes into the Unified Process for running a project, and how this can be documented in UML
Sample Chapter: Relationships
And here are a couple of more choices instead of the books above
Agile Software Development, Principles, Patterns, and Practices
AntiPatterns
Prefactoring
Ajax in Action
Head First Design Patterns
