Search results matching tag 'Book Reviews'

Pro SQL Server 2012 Practices Chapter 8: Release Management Review

drsql — Fri, 18 Jan 2013 21:06:14 GMT

This past year, I contributed a chapter to an anthology book of best practices for working with SQL Server 2012 entitled Pro SQL Server 2012 Practices (http://www.apress.com/9781430247708). As authors, for publicity we decided to do summary reviews one another's chapters. There are lots of great technical sounding chapters, but when I picked, I picked a chapter that I hoped to help me learn more about a process that is not in my favorite normal design or coding techniques area. Of the parts of the software development process I despise, release management is definitely one of them. As an architect, my primary love in software development starts with design, and starts to really drop off during testing. And I certainly did learn more about the process… TJay Belt (https://twitter.com/tjaybelt) wrote his chapter on release management. (I should also divulge that I have been friends with TJay through SQL PASS for quite some time, along with many of the authors of the book too.)

TJay does a great job of describing the process of release management, talking about the process he uses and even admitting mistakes he and his teams have made along the way as well. The focus of the chapter is very much from the point of view of the releasing DBA role in the process (most of the book is very DBA centric topics) and contains a lot of tremendously good advice about getting release management right starting with having great documentation and a rollback plan be able to restart or put a release on hold if things go awry. In addition, he covers many of the the topics around the entire process of coding/releasing software, including version control, proper (and quite reasonable) documentation, coding standards, and most of all a set of well-defined processes that all of the varied players in the process have agreed to and work on as a team.

My favorite part of the chapter was the approximately four pages of thought provoking questions that should be covered when doing a release, ranging from understanding the databases that will be affected, capacity planning, tuning, standards, code, jobs, etc. etc. Great food for thought for defining or refining your own release process.

Of course, one of the concerns of a book with lots of different topics is that you don't get tremendously deep coverage of any subject (and this is also true in my chapter on database design.) However, in some ways this liberates the writer from having to cover every detail and instead provide a thoughtful discussion of the overall release management process. This is very much a blessing, because every organization is different and already has some process in place already. Maybe your defined process is awesome or awful, but this chapter can help you think of ways to refine your process. You are left to find your own tools and processes to meet your company's needs, but what you get is quite thought provoking and will likely be useful whether this is your first time doing a release, or if it your hundredth.

Book Reviews – Again

drsql — Mon, 20 Apr 2009 04:53:00 GMT

I have gotten a few more reviews in, and interestingly I appreciate the negative ones almost as much as the positive ones. I prefer the negative ones that have decent star ratings better… but what are you going to do.

The most recent review was critical of the book for not having mentioned testing. I actually think that this was really good criticism and have already started my planning for how to rectify this. The only thing I wish this reviewer had done was mention the rest of the book. This person has three reviews on Amazon and some cool stuff on his wish list (if we ever meet, I will be happy to buy you an expresso/cup of coffee and discuss the rest of the book, which pretty much goes for anyone, if you want. I will also buy you lunch at my favorite restaurant: Prince’s Hot Chicken Shack. Only rule is that we have to talk about the book at least a little).

Please, if you have read the book, oh please (am I begging), I beg you (yes, I am begging) to please email me your feelings on the book or post reviews. I would love to know what you thought of it. I just want to make the book better and who knows, I usually give out a few copies of the next book (no guarantees) if the advice is really constructive.

The real problem here is that writing is a VERY slow process. If my book was electronic, I could start writing and shoehorn in the new material and be done with it. But a book is not like a website. I wrote the book as a cohesive 650+ pages that are supposed to work together as a unit. Unlike a set of web pages, my hope is that you will skim 1/2 of the book and read at least half (which half depends on you, but I like both halves.) And in each edition, I try to give more and more information as I find it, learn it, and on a few shining occasions, make something up.

In the first edition, the process was simply that I wrote what I thought I wanted to say, and editor(s) hacked that to bits. So about 10 people were involved in the creation. Now, working on the fifth edition I have had hundreds of people give me feedback, and a fairly small percentage tell me stuff that was missing that ruined the experience for them. I take these comments VERY seriously, especially if I agree with them. If you compared version one to the fourth version, a lot of the stuff I was really enthused about didn’t make too many people all that excited, so I cut it. In this last version, I have more examples, more code, and more technique, because it was asked for.

Now if I just knew if this reviewer liked anything else about, or if there was more that was disliked I could possibly make the next book even better. So if you have any ideas/feelings/criticism/etc email them to louis@drsql.org. Thanks!

Book Reviews…

drsql — Thu, 08 Jan 2009 05:59:03 GMT

When I wrote the 2005 book, I promised that I would take the time to respond to reviews as much as possible. From the good ones if I didn’t really believe that the person read the book (there were a few I have seen, but not too many people tend to write good reviews that clearly haven’t read the book unless they are paid to.) In fact, I am constantly surprised with good reviews, mostly because it is so difficult to write a book. I just spent an hour yesterday tracking down 20+ typos that the Chinese translator found.

I will also comment on the less good ones that are posted by people who clearly don’t like the material. You aren’t required to like the book, and when I am writing it I purposefully will ruffle the feathers of certain groups of people (particularly the ones who don’t believe normalization matters!) In fact, I think that the 2005 book was significantly better than the first primarily because of a few reviews that smacked me around and made me realize some of the errors in judgment that I made. My favorite review of the 2005 book was a private review that was scathing in a few important points that I applied to the 2008 book.

What burns my feathers is bad reviews that have no information whatsoever. I mean, take this review of the book on Amazon (http://www.amazon.com/review/R29BAGXMZMIC7Y/ref=cm_cr_rdp_perm):

Waste time to reading this book.,
“Since nobody publish a review for this book, I would like to say something. I have to say: Don't read it. It just waste your time.”

Now, I won’t make any kind of fun of the reviewers grammar, as it is very likely that he is not a native English speaker. But if I were to review a remake of Bio-Dome where Pauly Shore spoke with an English accent in Shakespearean-style rhyme and stopped watching the film 5 minutes inI could say more than this about than “it will waste your time.” I will also admit that there are probably a million people that would plunk down a tenner and happily watch this movie (and not just because movie theater popcorn is so much better than you can make at home.) Part of a good book review is to identify the type of reader. If this person is a DBA, this might be that he read the first chapter and said “bleh,” then fair enough. If he read the words “database” and thought that there would be dating tips, well, yeah, it would be a waste of time.

I might not be able to speak for every author out there, but I am sure that almost any author loves to get honest feedback on their work, particularly us who write trade literature. I want to target what people want to read, and with new editions likely for new versions of SQL Server, it is important to provide new/fresh/useful upgrades to the material. The best place to determine what to add are reviews: public, private , whatever, as long as they are from people who have read the material and know what they were reading.

As always, if you want to contact me, go to the contact form on my website: http://drsql.org/contactus.aspx (you can contact me anoymously there too) or email me at louis@drsql.org. Just please give honest feedback about what you have seen, not just post a review because no one has published a review yet.

SQL Server 2005 Integration Services using Visual Studio 2005: A Beginner's Guide

ktegels — Sat, 09 Feb 2008 19:14:00 GMT

In short: This is an example of a good idea in the wrong format -- a good book if you are starting at absolute zero and need specific step-by-step procedures. Being printed hurts more than it helps.

Let me begin by saying Kshipra Singh, from PACKT Publishing send me an e-mail via my blog with a simple request. In return for a complimentary copy of this book, would I post a review of it on my blog? I am hardly one to turn down a free book and I have been looking for one that I could recommend to my students and others who are just getting started with SQL Server Integration Services (SSIS). This, then, is my keeping of that bargain.

Jayaram Krishnaswamy's book is one example of a growing class of books that I believe should not have been printed. It is not a bad book, but rather, the content of it would probably be a lot better suited to its targeted reader had it been an e-book or as a DVD screen capture with a video and voice-over by the author. As many technical books that I have seen of the years -- and like ones that will admit, I have written -- the text is step-by-step procedural and makes up volume with screenshots. Knowledge presented like this I found is best done live (where interaction encourages questions), next done best by recorded demonstration (to maintain step-sequential context) lastly in a scrollable, random access method like an e-book. Print books really do not allow those types of interactions

Something else is missing too. Let me make an analogy. Let us say that you know very little about how to prepare a cake. You might already familiar with the hardware required: a stove, a pan and mixing bowl. You may also be familiar with the software needed: a cake mix, some eggs, some oil and some water. You can follow the directions in a cookbook (or the back of the mix box) and produce a cake. Just like the directions from the cookbook or box-back, this book is fair treatment of how to use the package designer to accomplish a given set of data integration tasks if that's need to do.

However, what did really learn about "making a cake" from the process?

Based on my personal experiences and those related to me by my students, the hardest part of "getting" SSIS is not how to accomplish a certain task, its understanding why the parts of it do what it does. Going back to our cake analogy, the cookbook does very little to explain why should mix the batter in a separate bowl before pouring into the baking pan. It does not bother to explain the delicate chemical interactions between the egg proteins, the salts, sugar, fats, water and heat that take place during the mixing and baking process. In just the same sense, this book comes up short when explaining essentials such as the dataflow pipeline, buffers and what many of the tasks and components actually do or can be used for.

Nor is there much here that would help go from "baking a cake" to "baking bread." These are similar processes but with some different tools used and some different steps used. This book will help you do the tasks it talks about, but it offers little more than that, especially when it comes to analyzing a problem and synthesizing a different solution. In my opinion, those are the two most important things to master about SSIS and that is, ideally, what a beginner's book would cover.

Of course, that might seem like I am saying that you should have to have a course in organic chemistry and thermodynamics before you can make a cake. Well, obviously, that is not the case. After you have baked a few cakes, learned from your mistakes and maybe even read a book like Shirley Corriher's Cookwise: The Secrets of Cooking Revealed you get enough down of science to be effective at baking cakes, breads and other pastries. If there is a parallel to Cookwise for SSIS, it is Kirk Haselden's Microsoft SQL Server 2005 Integration Services.

So would I recommend this book? In certain cases, yes. If you need to do something which this book particularly addresses quickly and with a minimum of cost, it is a good fit. However, if need to invest your time and money in really learning SSIS because it is a key part of your project or job then no, I would not recommend it. There are more appropriate books to be had.

Search results matching tag 'Book Reviews'

Pro SQL Server 2012 Practices Chapter 8: Release Management Review

Book Reviews – Again

Book Reviews…

Recommended readings: 2008 update

Business Intelligence

General data and programming topics

GIS and spatial topics

SQL Server

SQL Server 2005 Integration Services using Visual Studio 2005: A Beginner's Guide