What about making a real professional job using a [Postgre|My]SQL database instead and a web server? Instead of something that will just break by itself with time?
FWIW, Chapter 23 explains how to do exactly that - using Excel as the fun, friendly and flexible front-end that all your users know well for the client-side data-entry and presentation, but communicating (2-way) with a web service for remote access to the data. The web service then stores the data in any format you like.
Part of my confusion about the premise for this book is (like I said) what it's supposed to buy you.
A great many applications start in Excel for no better reason than that's what's on the desk of the business user (i.e. not a trained IT developer) starting out recording and writing VBA code to make their main job easier. As their knowledge of VBA increases, they do more and more complex and involved things, but typically don't think about many of the topics 'professional' developers would consider - such as whether the solution is scalable, maintainable, robust, secure, etc.
It's not until people realise that their application has become business-critical that they start to think about the risks, and might even ask the IT Dept to help in managing it. The first time IT see the application, it's a mess of unstructured, uncommented, undocumented code.
The premise for the book, then, is to try to get those 'developers' to think about the bigger issues early on, and provide the techniques and mindset for them to approach their development in a manner that will (hopefully) result in their Excel-based applications being much higher quality and easier for IT to adopt, if that need arises.
Lots of the comments here have been about whether or not it is 'right' to develop applications based around Excel. As one of the authors of this book, I think that misses the point. The simple fact is that in the real world, there are lots of people who do develop such applications and really need to know some techniques that can make their programs much more robust, maintainable, etc.
When teaching our children about the facts of life, we can lecture them about abstinence, let them know about lifestyle choices that might or might not be relevant, or we can teach them how to be prepared (physically and emotionally), safe, considerate and responsible. The latter is the attitude we've taken towards Excel development, while also teaching some advanced techniques that might help their activities.
The business reasons for using Excel as a development platform may be misguided, but it doesn't mean you shouldn't use the same practices that you would use to write anything in any other dev platform. I would think that the goal of the reviewed book is to ensure that.
Exactly that. And realising that in some cases, the business reasons are quite valid too, such as your application having an almost entirely user-configurable UI.
That's exactly what drove us to write the book. Over and over again, we've been called in to fix such Excel applications. Rather than say "Don't do that", we recognised that a great many people *do* develop business-critical applications using Excel, but don't have the toolset and mindset to write code that is robust, maintainable, etc. This book attempts to teach much of the discipline and techniques that that we'd expect in 'proper' development environments.
Slashdot Mirror
What about making a real professional job using a [Postgre|My]SQL database instead and a web server? Instead of something that will just break by itself with time?
FWIW, Chapter 23 explains how to do exactly that - using Excel as the fun, friendly and flexible front-end that all your users know well for the client-side data-entry and presentation, but communicating (2-way) with a web service for remote access to the data. The web service then stores the data in any format you like.
Part of my confusion about the premise for this book is (like I said) what it's supposed to buy you.
A great many applications start in Excel for no better reason than that's what's on the desk of the business user (i.e. not a trained IT developer) starting out recording and writing VBA code to make their main job easier. As their knowledge of VBA increases, they do more and more complex and involved things, but typically don't think about many of the topics 'professional' developers would consider - such as whether the solution is scalable, maintainable, robust, secure, etc.
It's not until people realise that their application has become business-critical that they start to think about the risks, and might even ask the IT Dept to help in managing it. The first time IT see the application, it's a mess of unstructured, uncommented, undocumented code.
The premise for the book, then, is to try to get those 'developers' to think about the bigger issues early on, and provide the techniques and mindset for them to approach their development in a manner that will (hopefully) result in their Excel-based applications being much higher quality and easier for IT to adopt, if that need arises.
Firstly, thanks for the review!
Lots of the comments here have been about whether or not it is 'right' to develop applications based around Excel. As one of the authors of this book, I think that misses the point. The simple fact is that in the real world, there are lots of people who do develop such applications and really need to know some techniques that can make their programs much more robust, maintainable, etc.
When teaching our children about the facts of life, we can lecture them about abstinence, let them know about lifestyle choices that might or might not be relevant, or we can teach them how to be prepared (physically and emotionally), safe, considerate and responsible. The latter is the attitude we've taken towards Excel development, while also teaching some advanced techniques that might help their activities.
FWIW, more information about the book and a few sample chapters are available from my web site at http://www.oaltd.co.uk/ProExcelDev.
The business reasons for using Excel as a development platform may be misguided, but it doesn't mean you shouldn't use the same practices that you would use to write anything in any other dev platform. I would think that the goal of the reviewed book is to ensure that. Exactly that. And realising that in some cases, the business reasons are quite valid too, such as your application having an almost entirely user-configurable UI.
That's exactly what drove us to write the book. Over and over again, we've been called in to fix such Excel applications. Rather than say "Don't do that", we recognised that a great many people *do* develop business-critical applications using Excel, but don't have the toolset and mindset to write code that is robust, maintainable, etc. This book attempts to teach much of the discipline and techniques that that we'd expect in 'proper' development environments.
Regards
Stephen Bullen