PlanetMysql.ru — информация о СУБД MySQL

This is part four of an ongoing series about my experiences while writing the MySQL Admin Cookbook for Packt Publishing. All previous parts can be found under the mysql-admin-cookbook label.

This part will be about more software used in the process of writing the book. The last episode covered writing tools, file/version management and backups. What's up now is graphics programs, virtualization and PDF handling.

Outlining

For outlining and structuring thoughts I like mind-maps. I know they are not for everyone, but if you like them and do not want to spend a lot of money on MindManager, have a look at FreeMind. It is a free, open source, Java based mind mapping application with a large set of features and a really nice UI. In fact, I am using it right now to structure the writing of this series of blog posts. It comes in readily installable versions for Windows, Mac OS X and Linux, which makes it really a good fit if you regularly switch platforms and want to be able to add a thought or two to an existing map without having to dual-boot or fire up a virtual machine.

Graphics and Illustrations

As with any technology, some things in database land are much easier to show as a diagram or schematic drawing than explaining them verbosely in text. Not to forget the occasional – well, the regular – screenshot to show GUIs or console printouts.

Screenshots

As a matter of fact in the first drafts of most chapters Udo and I had a lot of textual presentations of query results and plain text output from the mysql command line client, but the publishing company wanted more screenshots instead to make the book appear less text heavy. There have been mixed reactions to this, but generally I think less would have been more. Several of the screenshots merely show console windows which are not always good to read due to scaling and anti-aliasing.

To take screenshots, Mac OS X is pretty well suited without any additional tools. Even though there are some nice programs that offer advanced features like Layers which can automatically create a PSD file with one layer per open window, usually screenshots were taken of a single Terminal.app window or specific dialogs. For that the built-in features were completely sufficient:

1. ⇧+⌘+3 produces a snapshot of the whole screen
2. ⇧+⌘+4 produces a crosshair that you can drag over a specific area of your screen
3. ⇧+⌘+4 followed by the space bar turns the crosshair into a camera to snapshot a single window

The only adjustment needed was to disable the drop shadow that is otherwise put behind the windows in the screenshot files by default:

defaults write com.apple.screencapture disable-shadow -bool true

That change gets effective after logging out and back in again or by killing the SystemUIServer process.

The screenshots are placed on the desktop by default. Depending on the OS X release the filename and format may differ. For the book we wanted PNG files, because JPGs would have caused compression artifacts. PNG is the default in Mac OS X 10.6 Snow Leopard. Generally this command allows you to change the format of screenshot files:

defaults write com.apple.screencapture type png

Instead of png you can also choose from tiff, gif, jpg, pdf, if I am not mistaken.

For Windows I used is a handy little tool called Screenshot Pilot which has a slightly “nostalgic” GUI style, but it works really well. It is far more pleasant to use than the otherwise necessary Windows style screenshot taking by hitting Alt-PrtScr to copy the current Window to the clipboard and then paste it into mspaint.exe and save it as a file.

Illustrations

Very early in the process we asked Packt about how to go about illustrations. They told us that anything would be fine that worked for us, because they had professional illustrators who would re-draw anything we sent them to give the book a uniform style. For example they would accept drawing made with any of the Office tools, bitmap graphics or just scans of hand-drawn sketches. I was very relieved when I heard this, because if there's one thing that eats up time even more quickly than text formatting it certainly is graphics work. I think of myself as nothing close to an artist, so knowing that someone else with probably lots of experience and routine would take care of this was very comforting and would relieve us of the necessity to find a set of good graphics tools.

Or so we thought at the time... To give you an idea, this is one of the sketches I sent along with a chapter of text:

While certainly no masterpiece I think the idea is brought across well enough for someone to redraw this with a little style. I scribbled together a few of these and sent them off in good faith.

Later in the process, this is what I got back for the sketch above:

Frankly, I was very much disappointed and certainly did I not want graphics of this style and quality to go into the book. Just look at the tunnel entrance and exit symbols… So in the end I decided to take care of the graphics myself. I fooled around a little with OpenOffice's drawing tool but did not manage to create anything that I even remotely liked. Fortunately a friend of mine owns a copy of OmniGraffle, a professional vector based diagramming tool for the Mac, and he let me spend some time on his machine remotely. With this I managed to create new versions of the illustrations in a style that I liked and with a little more attention to detail. This is my version of the same idea:

Making these took quite a lot of time. Once finished with the bulk of the work I sent it off to the publisher in EPS format, because I hoped that would be the easiest way of making sure they had the best possible quality to work with without requiring them to organize a Mac. Turns out the EPS is not as portable as I thought and had hoped. There were lots of troubles with line and arrow styles, transparencies etc. In the end I had to download a trial version of Corel Draw for Windows, because that's what Packt's graphics people use.

With trial and error I managed to get the illustrations to Corel Format with the correct fonts and no strange rasterizing artifacts for partially transparent areas. All in all, had I known I would have to take care of this myself from the beginning, I would have asked for at least one more month in the schedule and prepared them along the way. The same goes for the very few charts included in the book. I made these with a trial version of OmniGraphSketcher, also from OmniGroup. The idea behind this tool is to actually draw diagrams, instead of having them generated by a spreadsheet tool from pure numbers. While I generally like the idea, the tool is still lacking in my opinion. For example getting the X- and Y-scales right was more complicated than I would have thought. Anyway, I will keep an eye on the program - it surely has the potential to become a valuable tool and I will most certainly check it out again if/when the need arises.

A few more words on Corel Draw: I have no option but to rant about it! The last version I remember to be really good was Corel Draw 5, about a millennium ago or so. After that I had a look at Corel Draw 7 and did not like it at all. In my opinion it has suffered form the same feature-creep that most applications that were once lean, fast and powerful, getting bigger and especially buggier all the time (Firefox, Nero anyone?). I am glad I have no need to work with this software on a regular basis. From real crashes - which I saw quite a few of - to annoying user experience problems; this is not a program you would enjoy to work with. The stupidest thing in my opinion was that for virtually any file operation the open or save dialogs would open in my home directory, instead of remembering which directory I had last used. An estimated three hours of my lifetime could have been saved, had I not had to spend them navigating to the right path time and again. Also what is it the myriad of file format versions? As you save a file you have to decide what version (7, 8, 9, 10, 11, 12) you would like to use. Of course they are all called ".CDR", and the program does not remember what you chose for the last file... Better make sure to include the format version in the filename, because once on the disk you have to easy way to tell which is which!

Test setups / Virtual Machines

As it is easy to imagine, for a database cookbook lots of experiments and trying out stuff is required in order to make sure that everything you claim actually works. Anyone who kept reading up to this point is probably technical enough to understand that no matter how well you plan and how carefully you write down any sort of script, source code sample or the like, it will not work unless you copy and paste it from the actual command line window or source code editor. There just is no other way. And also it is (almost) guaranteed that you will break any code by making "one last beautifying change" in the word processor; be it a missing semicolon, a space introduced into a regular expression or a capitalization change, something will go wrong!

The only chance to make sure your readers are not too likely to find a bug in your scripts or command lines is to try them all - each and every one of them. Of course, some of them by design make permanent changes to the test setup, so if anything goes wrong and you cannot just take a screenshot and put it into the manuscript you might be in for varying amounts of resetting the machine and trying again. More than once I made a simple mistake in that, too and ended up with an ever so slight difference in the test setup, messing up the test again. In that light, one wonders why any functioning production systems exist in the first place...

Fortunately this is not 1995 anymore and there are very capable virtualization solutions available for reasonable prices to ease the pain with repeated tests and different setups.

As Mac OS X is not the primary platform most MySQL administrators use - neither as a client, nor as a server - I need a way to test with different versions and setups of Windows and Linux. One way would have been to use bootcamp to dual-boot into Windows, but that would have caused unacceptable roundtrip times. Because performance was rarely an issue, I decided to buy VMWare Fusion 3. Though not very cheap it certainly is a product worth its money. Here you can see my Virtual Machine Library - some of the test VMs have been deleted since the book was finished - but you can still see the Ubuntu, Vista and Windows 7 VMs I primarily used to take screenshots on.

Apart from being able to run different operating systems and MySQL versions, the killer feature for me was snapshots. Basically they allow you to clone a virtual machine and all its state into one or more named copies and reverting back to these "save-games" at a later time, discarding any changes that happened in the meantime. Though not particularly suited for long term operations - performance is degraded quite a bit - they are ideal for what I call "destructive" tests: Those that actually modify system state, like configuration files, database contents, software installations etc. For every VM I would first set up a well-known "good state" and take a snapshot of that. If in the course of writing a recipe I needed to make several attempts to get everything just right I could mess everything up with no worries and go right back to the beginning, without any risk of accidentally missing something important.

If you regularly have to do any sort of software testing you will appreciate the benefits virtualization immediately. The fact that I chose VMware is not too important. As it is often with software, personal preference plays a huge role. Udo got a good deal on Parallels Desktop which is another commercial virtualization solution for the Mac. However you could just as well go with the free VirtualBox from Oracle, available for Windows, Linux and the Mac. They all offer very similar feature sets and would all have been equally suited for the tasks I performed.

PDF Tools

In the later stages of production annotated PDF documents superseded the previously used OpenOffice and Word document files. The reasons for and problems with that will be focused on in a later installment of this series.

Mac OS X incorporates very strong PDF handling facilities right in the operating system's core. Much of the Mac's graphics are based on PDF internally, so it is not too surprising to find advanced PDF handling features in the built-in "Preview.app". Out of the box any Mac can open PDF documents, inspect their meta-data and also create new PDFs from any application without the need for special PDF printer apps or the like. Before the book writing project I had never even bothered to install the Adobe Reader - I just did not have any use for it. Considering the fact that compared to Preview.app it takes ages to load and is a never-ending source of security problems I had no intention of changing that.

But then Packt started to send us PDF versions of the first formatted and laid out chapters, complete with annotations and comments. I blogged about a rather unpleasant episode regarding Preview.app's shortcomings earlier.

I won't repeat everything here, but suffice it to say that you should not trust it to show all the annotations and comments a document contains!

So I needed to download and install Adobe Reader to make sure I could at least see all annotations and meta-information embedded in the PDFs from the publisher. I have not checked again since, but when I last downloaded the installer from their website it was not the latest version. In order to keep your system (reasonably) secure against the many Adobe Reader based exploits circulating the net, make sure to manually run the updater again and again until it tells you there are no more updates left! If there had been updates like this in 1995, I am sure they would have been implemented like this...

The same goes for Acrobat Professional which in the further course of getting the book done was needed as well - again, details will follow later. For reasons beyond logic there is no trial version on Adobe's page for Acrobat Pro as a standalone application on the Mac - only for Windows. As a Mac user you need to download the full CS4 suite to try it... Fortunately I did not have to jump through these hoops, because a version 8 DVD was included in the software bundle with Fujitsu's ScanSnap. That one, too, had to be updated in what felt like 100 individual runs of the Adobe Updater.

While being considerably slower than the Preview.app accompanying Mac OS X, Acrobat and Adobe Reader were much better at handling document commenting, revising and especially comparing! Yes, it is possible to compare two PDFs and have Acrobat highlight changes between the two - a feature that became indispensable in the later project phases:

With that I will conclude this second part of the tool descriptions. I have probably forgotten one or two little utilities that came in handy, but these were the companions that accompanied me along the way constantly. In the upcoming episodes I will refer to them as needed, but you should have a general idea on what kinds of tools it took to complete the project. Be advised though that once my little saga here is complete you will find that quite a few of them shouldn't have been necessary for me to have, but that is for another time.

The next part will resume the more chronological style of describing my experiences. Stay tuned :)

PlanetMySQL Voting: Vote UP / Vote DOWN

This is part three of an ongoing series about my experiences while writing the MySQL Admin Cookbook for Packt Publishing. All previous parts can be found under the mysql-admin-cookbook label.

Even though I said I would be presenting things in mostly chronological order, I think after the previous - rather dry - part, a little more technical and fun information would be nice for a change: The tools used to create the MySQL Admin Cookbook (well, at least those used by Udo and me). To give a detailed account of what software products we used during the whole experience I will split this topic up into multiple posts. Otherwise it would just become either way too long or I would have to leave out too much stuff than I am willing to.

Writing Tools

Packt provided us with both Microsoft Word and OpenOffice.org document templates. Authors are free to choose which format they want to use - if you own MS Office and like Word, you can use that, but if – like us – you did never buy a copy from Microsoft and don't want to do so for the book, OpenOffice is fine as well.

I have been using a Mac as my home computer for quite some time now, and I remembered OpenOffice as being rather slow and not too stable. Admittedly that was the result of only a quick glance at it, because I had bought iWork with the Mac and had been using Pages to write my everyday stuff. I was not too impressed with OpenOffice, but quickly learned that the compatible Mac version called NeoOffice was way more usable.

The document template provided by Packt contained several paragraph and character styles with names like “Code in Text”, “Keyword”, “Command Line” etc. Packt recommended writing with these styles to get a basic idea of what the book's pages would look like in print later. Also the page size was set close to the actual books format, in order to allow for a good estimate of the page count.

Even though NeoOffice was generally doing its job, I soon started looking for alternatives for two main reasons:

1. Speed

   Even though more responsive than OpenOffice for the Mac OS, NeoOffice still did not feel as snappy and responsive as OOo on Windows did. After several writing session during which I cursed more than once about lagging responses to my clicks and typing I decided I had to find something else for the remainder of the book if I wanted not to kill myself or the Mac.

2. Distractions

   While at first glance it might seem like a good idea to write in a way that let's you keep a close eye on the page count and do some basic formatting “in-line” while writing, it turns out to be a huge distraction. Even though I tried very hard to not get lost in fine-grained formatting, I regularly found myself going back a paragraph, because I had forgotten to use the “Code in Text” or “Keyword” template for some SQL example or other element. Also I regularly spent way too much time tweaking table column widths or just plain fighting one or the other obvious bug in the word processor.

   So in addition to the speed issue mentioned earlier I figured it would take me far too long to finish a chapter in this manner. It is quite remarkable how much more productive I got once I stopped letting my thoughts and actual writing be interrupted by this constant formatter “background thread”.

I decided I would first write down the bulk of a chapter's content as a plain text file, using only the formatting tools available there: None. The only thing I did was separating paragraphs with blank lines in between and occasionally inserting easy to find tags in the form of ***INSERT REFERENCE HERE***. As nowhere in the real contents of the book you would find “***” this was very easy to locate later on using simple text search.

However, TextEdit - the Mac's default onboard text editor - even though more comfortable than Windows Notepad did not convince me as a heavy duty writing tool. After trying several options, including WriteRoom and a custom Pages template, I finally decided to buy myTexts which I also blogged about already. It combined the no-distractions-full-screen-writing with a nice automatic file handling which even relieved me of thinking about saving my material. Almost everything after the first chapter was written with this simple but powerful tool.

I kept one file per recipe written instead of one per chapter, even thought the tool would certainly have handled that well. But by keeping the individual recipes separate it became a lot easier to navigate and keep of track what recipes had already been written by just looking at the side-panel.

Once finished, I would just copy and paste the text in its entirety into the NeoOffice document and started a little formatting session. Once I had amended the original document template with some personal keyboard shortcuts for the style templates most commonly used I could manage to format a single recipe in maybe 5-10 minutes. Often I would first write several recipes in myTexts and then bring them over to NeoOffice in one go. I cannot provide any hard timings or comparisons as to how much time I saved writing in this manner, but I can firmly state that material written like that tended to be a lot more “production ready” than what I had written directly in NeoOffice earlier.

In fact, I have not since changed my writing habits again and continue to work like this whenever producing any sort of text longer than an email. I have since bought a license of WriteRoom as well and use them both sort of on a daily-mood basis. As a matter of fact, this very post is being written in WriteRoom right now :-)

Version Control

Both Udo and I being software developers we were already accustomed to the concept of using a version control system (VCS). More than once in my day job was I glad to have easy access to prior versions of files I had locally changed, but not necessarily for the better. So it was very natural for us to start using a VCS right from the beginning. Even before we started the actual writing we checked in all documents and files we had exchanged with Packt so far as well as the outline and all reference materials into a hosted subversion repository.

There are numerous choices for free or paid hosting services. A nice one that allows you to start for free and only pay if you need more than 200MB of space is http://www.unfuddle.com. We created a free account with a Subversion repository and used it till the end of the project. We were expecting to have to upgrade to a paid plan somewhere along the way, but in fact we were able to squeeze everything in this free entry level account until the book was finished. As for the choice of Subversion over other version control systems, it was merely a matter of what was available, and as we were dealing with ODT and other non-mergable file types we figured it would not make much of a difference. Of course, personal preferences vary - any other VCS, be it distributed or centralized, would work just fine. The key aspect just was having a (one more) off-site backup and the aforementioned ability to go back in time should the need arise.

Whenever we sent of a finished chapter or anything else important to Packt we tagged it in Subversion - which turned out to be really helpful during the final stages of the project. More details on how and why will be presented in one of the later incarnations of this series.

As for the Subversion client, this is a matter of taste as much as the VCS itself. If I remember correctly, Udo used TortoiseSVN on Windows, while I – after some attempts with various Mac utilities – stuck with Versions, a very nice and “Macintoshy” application.

  

Backup

If you have ever written a dissertation, thesis or the like you should already be paranoid enough to not trust any single machine to keep your data safe, be it from thieves, fires or even (most dangerous of all) your own stupidity. If you have not, you should quickly become paranoid, because even if you trust (which you should not) that your hardware will not fail anytime soon, and even if your house is right next to the police and fire department headquarters this will not prevent you from accidentally deleting the most recent version of the chapter you were just about to send off to the publisher. Or you overwrite it with an older version. Or you try to move a picture around in the word processor and it crashes horribly, damaging the file, or ... well, you get the point.

The following are the backup measures I take. It is, of course, up to you to decide which of these or others you want to employ, but regarding backup, my take is “the more the better”. I did not include the SVN repository here again, but of course it is a backup, too.

1. File Name Rotation

   The simplest way to guard against yourself destroying your own work accidentally is to regularly save to a new file name. This of course does not play too well together with the myTexts approach where you do not actually see the regular “Save File As” dialog, but it is a good idea anyway. I got used to just append a number to the file name and count it up every hour or so. Of course I would save much more often than once per hour, having Cmd-S hardwired into my spine after every paragraph or so. But using multiple files locally is also a good protection against faulty software corrupting a file.

2. Time Machine / External Hard Drive

   As a Mac user this is a no-brainer. Time machine runs every hour or so, backing up everything that has changed since the last cycle to an external hard drive. As a Windows user you do not have the luxury of having this built in to the OS, but a local external hard disk is a good insurance against a failing internal hard drive.

3. Dropbox

   The free Dropbox service is easy to set up and automatically uploads any files you save in a specified local folder to their servers. Access is protected and it operates silently in the background. This is also great if you work on different computers, because it will keep them all in sync when they are connected to the same account. The free plan gives you 2GB of space, certainly more than you would ever need for your book texts.

4. Offsite Online Backup

   I own a Carbonite subscription which will transparently backup all my files to their cloud service. There are a lot of these services with varying prices and services, but they all send your computer's files (not only one folder like Dropbox) to their servers. While not strictly necessary in addition to Dropbox, it does not hurt either. Any form of cloud-based storage, even if you just copied your files to an FTP server regularly, will protect you from fire, lightning strike or floods, thieves or any other physical damage to or loss of your equipment. I would never work seriously for extended periods of time on a machine that does not use some form of online backup.

One can hardly stress the importance of backups too much. For a very good concept called “3-2-1 backup strategy”, go to http://www.dpbestflow.org/backup/backup-overview#321 and start to live by it.

So much for now. This has already gotten longer than I had planned… The remainder of the tools and programs I used while writing the book will get their mention in the next part of this series.

PlanetMySQL Voting: Vote UP / Vote DOWN

This is part two of an ongoing series about my experiences while writing the MySQL Admin Cookbook for Packt Publishing. All previous parts can be found under the mysql-admin-cookbook label.

While last time I focused on the initial contact with the publishing company (just referred to as "Packt" from now on), this issue is about the process of putting together an outline proposal and coming up with things to write about in the first place. As from this point on in the process Udo was involved with everything, I will be referring to "us" and write "we" most of the time from now on.

The Publisher's Expectations

The only thing we knew about the books would-be content was a chapter template for Packt's cookbook series as well as the general description provided by Sarah earlier:

As I'm sure everyone is aware, MySQL is a relational database management system. Administrators of MySQL will be tasked with things such as maintaining the database, tuning the server, managing users etc etc.
This cookbook will have all the MySQL recipes an administrator could dream of, spanning from creating tables to managing views, from improving performance to securing the database, from using monitoring tools to using storage engines. DBAs of all levels will be catered for with recipes of varying difficulty, allowing the reader to administer MySQL to their hearts' content.

Before actually beginning the outlining process there were a few more emails sent back and forth, mostly questions on our part, for example whether we should include programming related materials or tool descriptions in addition to more "real" database themes, what spectrum of experience to expect from potential readers and so on.

Packt did not provide a list of topics they had in mind - instead we were completely free to make suggestions for what we deemed interesting for MySQL administrators. There were no hard rules on what topics would be out-of-scope, but in general we were asked to find a balance and suggest roughly the same number of topics that would be interesting for relatively inexperienced readers, people already familiar with MySQL and experienced, professional DBAs - with a general tendency toward the latter. At the time I was a little disappointed as to how little guidance they provided, but in hindsight I believe this was definitely for everyone's benefit. Packt's position on this apparently is that their authors generally are closer to their designated audience than someone who can only have so much of an insight into a lot of technical topics; something I can certainly agree on :).

As for the MySQL versions targeted, they naturally asked us to concentrate on the most up-to-date version at that time - which was MySQL 5.1. In our day jobs we are still stuck with 5.0, but it was a good opportunity to get a feeling for what changes we will have to make to our processes and practices when eventually we decide to tackle the upgrade. Considering the fact the writing the whole thing would take its time this was of course a reasonable decision. Midway during the process we thought about looking at 5.4, too, but decided against it - checking everything on 5.0 and 5.1 was enough work already.

The cookbook format as it was described to us would allow for "spin-off" recipes: A general recipe with detailed instructions, followed by shorter, more concise ones that described a variation of the original baseline, sometimes more advanced, sometimes just with a different focus. So in general Packt recommended to go for a greater number of shorter individual recipes, because that would allow the reader of the book to skim through the table of contents and not have to interpret too much into the titles in order to grasp what each recipe would do for her.
While we actually ended up with a few of these in the final book I did relate to the idea too much. As a matter of fact I think we could have better used those pages for genuinely different content, but that might simply be a matter of personal preference.

Brainstorming

On January 23rd, not just yet one month after the initial contact, we sat down together in front of Google Docs and held a little brainstorming session on topics that occurred to us while talking about our experiences with MySQL. Of course some of the "bigger" milestones from our day jobs sprang to mind first, but over the course of a couple hours with some snacks and drinks we came up with quite a lot of individual topics.

Looking back at it I think we might have better used a mind-mapping application like FreeMind, because when working with text documents one is always tempted to format or move around stuff, trying to find structure where there usually is none intended in brainstorming. On the other hand, brainstorming sessions are usually short, so maybe that made up for it :-)
There was lots of random talk about other stuff, too, but we consciously decided not to try and concentrate and focus too hard. Instead whenever someone had an idea - however stupid it might seem at the time - we added it to the list in a very rough sketch sort of way, not thinking about it at all.

Structuring the results

When we were finished, we had compiled a list of about 125 ideas, some being duplicates of others on second thought, some being broad enough to be split again into two or more more specific ones. We went through them all and tried to categorize them logically into rough areas such as "replication", "schema related", "indexing" and so on. We did not try to come up with a list of categories or chapters first, but just made them up on the fly. I think, that worked out very well. The result - after some more minor tweaking - can be found in the final book now as the 9 chapters and the appendix.

The latter one was not really a part of the cookbook format's description, but after combing the list a few items remained that proved very resistant to the idea of being formulated as a "How to do xxx" recipe.

For a short moment we considered dropping these ideas as being "not right" for the cookbook, but quickly decided to propose the idea of an appendix titled "Good to Know" as sort of a collection of interesting and relevant ideas one might find useful despite them being not strictly step-by-step instructions.

During the course of this sorting phase we also spent some time thinking about what level of experience a reader would be expected to have for each of the proposed recipes. We categorized everything as "A" (novice) through "D" (professional) to get an idea if we were anywhere near a uniform distribution among these. After that first pass we saw we had come up with only a very few "A" level topics, roughly the same (higher) amount of "B"s and "C"s and also quite a few "D"s. We took one or two more passes, sometimes splitting up more complicated recipes into two more simple ones to get a few more novice level recipes. In the end we reached an approximate bell curve with a slight tendency toward the more complicated stuff. We decided against trying to cut on the more complicated topics, because we came to the conclusion that this was what we would expect from a book, were we to buy it ourselves.

The end result was compiled into an email and sent to Sarah shortly afterwards on January 26, 2009. At that point we considered it to be sort of a pick list for Packt to choose from. It did not contain estimated page counts at that time and we surely expected a reasonable number of items to be combed out by Packt.

Publisher’s Feedback

Just a day after I had sent the email to Sarah, we got this reply:

Hi Guys,

Thanks for the outline. I've had a look through and its looking good. You have a good mix of basic and advanced recipes which will keep all readers happy.

I don't really have any suggestions to make at this stage. I am happy with the outline and so have presented it to my colleagues who will give us their feedback and suggestions which will help us to finalise the outline.

If possible, could you provide me with the expected page counts of each chapter. This only has to be a rough estimate at this stage, but you will find it useful to know what to aim for when writing each chapter.

[...]

That same email had a contract proposal attached, but I will spare that for a later post, because that's a little story of its own.

Page Count Estimate

The page count issue turned out more difficult than we had imagined. The initial description of the project called for about 300 pages. That's one of the reasons why we assumed the publisher would cut down the number of recipes from our proposed outline quite a bit. Even though we had no per-recipe estimate at that time, we had sort of a "feeling" going in the direction of around 400+ pages, just from the number of topics.

Even before we had sent the estimate Packt came up with a proposed schedule. Unfortunately there was little information on what that was based on, so we assumed it was calculated based on 300 pages with one page per author per day. That would have meant almost no buffer and a writing phase of approximately 5 months.

We had sat down again, thinking about how long each recipe would probably be. This turned out to be quite difficult with no experience to draw from. So we first were quite generous with the estimates. When looking at the final page count we were at about 500 and decided that this was a little over the top, especially when every recipe was intended to provide a quick solution to a clearly defined problem. So we thought about every single one again, this time considering how much we would be willing to read ourselves were this someone else's book. In the end we came up with around 420 pages.

So if the number of pages were to come closer to the 400 we had in mind, that would have meant about 7 months of writing, still with basically no buffer.

I decided to write a sample piece to get a feeling for how long an actual recipe and a chapter introduction would be, and if we had the same level of detail in mind as Packt did. If you'd like to read it, just go ahead: It ended up almost unchanged as the introduction of Chapter 3 (Tools) and the recipe on Sharing MySQL GUI Tools' connections.

In the meantime we had received another email, informing us about the acceptance of the outline proposal we had sent. No word on any cuts or redactions. So along with that content sample we sent our concerns about the schedule and the roughly 100 page difference we expected.

This is what we got back:

[...]

All recipes have been accepted, but if you feel that you need to remove some of them, that would be fine. The outline was approved by the editorial team here, so none of us have extensive technical experience. Therefore, we rely on an author's technical experience when talking about the specific details of the content. We would ideally like to keep the page count as close to 300 pages as possible, as this is what all books in the cookbook series are based on.
Do you imagine that all the recipes in the book will be as detailed as your sample one? I expect that different levels of recipe may need different amounts of explanation, depending on the topic. If you feel that you may need to delete some less-important recipes from the outline, then that would be fine. As long as the page count didn't go over 350 pages, that would be ok.

[...]

The schedule is just based on the first drafts of the chapters. Once a first draft chapter has been written, we will send it to a technical reviewer and, once all first drafts have been written, you will start writing the final drafts based on mine and the reviewers' feedback. [...] On the whole, we estimate the first draft writing stage to take 6-7 months, whilst the final draft stage takes 2-3 months. [...]

However, we do allow 30 days 'breathing room' in our editorial timeline and the schedule will be fairly flexible if needs be.

[...]

At that time we were reluctant to accept the schedule, because we were not quite sure the "1 hour per day and page" rule of thumb would hold very well and we did not want to reserve every moment of free time for writing.

Some more emails flew back and forth.

On February 10, 2009 I wrote:

Sarah,

[...]

We definitely see your point regarding the general 300 to 350-page rule for the cookbooks [...]. Unfortunately we do not see a way to keep all recipes in the outline and stay below that mark. Leaving out details is a path we would be reluctant to follow, because we fear that would mean giving up the really important stuff.

[...] option might be to cut a lot of the easier recipes (probably most if not all marked A and several designated B) and concentrate on the more ambitious ones that are not covered elsewhere at a comparable level of detail or in similar contexts. To do this we would generally assume a slightly higher level of expertise regarding the readership.

[...]

On the very same day I got this reply:

Hi Daniel,

[...]

I would be reluctant to lose the easier recipes as it would cut out a great deal of the audience. I think it's important to include a wide range of recipes to cater for all levels of experience.

Therefore, if you agree, I would like to keep all of the recipes that you mentioned in the outline. I have spoken to the cookbook series editor and he agrees that all the recipes are invaluable and so would be happy to extend the page count if necessary. Obviously, this would mean extending the schedule too. [...]

I'm glad that you both have put so much thought into this and can see that you are committed to quality, which is exactly what I like to see! :-)

[...]

So in the end getting the outline and page count agreed on took more than four weeks, which we would not have believed up front. In retrospect I believe our initial estimates were always a little too high and conservative. Probably if we were to tackle another one of these, both the estimates would be more accurate and the whole process of agreeing on the outlines and schedules would take a lot less time to get done with.

What’s next?

The next part will probably concentrate on the matters of getting our contracts ready - a rather dry and boring experience, but an important one nonetheless.

PlanetMySQL Voting: Vote UP / Vote DOWN

In a few past posts I wrote about different aspects of my book writing project already. However those posts were not very contiguous, and I was asked a few times what my general experiences were and what caveats to look out for when taking on such a project for the first time. It might be of interest to some if I write down my experiences in a little more structured form.

This will be a series of several posts, because for one I do not think it would be feasible to have a single very long one, and also because this allows me to span writing it over a longer time. I will try to keep everything roughly chronological, but will deviate when I think it makes things clearer or better to understand.

Please be aware that I do not have extensive experience with multiple publishers, their processes and so on. This is solely about my personal experiences while writing a single book, with a single publisher, over a time of roughly 15 months. So please do not take anything for granted – should you go on that route and write something yourself, you might find yourself in completely different circumstances and witness the whole matter completely differently.

As for getting in contact with the publishing company, I already wrote down my experiences with that here: http://www.danielschneller.com/2009/12/51-weeks-since-my-book-writing.html

However I will go into a little more "historical detail" for starters.

 

Chapter 1: Getting contacted by the publisher

I do not know how common this is, but in my case the idea for writing a book did not come from me. Instead on December 24th of 2008 I received an email from Kshipra Singh, Author Relationship Manager with Packt Publishing titled "Author MySQL book-Packt Publishing".

Not knowing that name, never having heard of the company and generally being in the progress of getting my GMail inbox cleaned up I almost wanted to delete this mail unread, assuming it was some sort of junk. However, as the subject seemed to have a least some connection to my interests and because I really did not have to do much (Christmas Eve, empty office, fresh coffee, no bugs to fix, …) I opened it anyway.

This is what I read:

Hi Daniel,

I am writing to you for Packt Publishing, the publishers of computer related books.

We are planning to publish a book on MySQL, titled, The MySQL Admin Cookbook. While trying to find some potential authors for this site I came across your blog and saw your interest in MySQL. I also saw your blog entries on various facets of MySQL. These give me an impression that you could be a potential author for this book. The book is planned to be a cookbook with an admin recipe which will help DBAs to successfully maintain and administrate a MySQL database. DBAs of all abilities will benefit from this book as they learn tasks from creating tables to managing views, from improving performance to securing the database, from using monitoring tools to using storage engines. The reader is expected to have existing knowledge of MySQL and will already have their MySQL installed and ready to go.

To give you an idea about the way things work at Packt:

• The editorial team at Packt works with the authors through out the project.
• We pay a royalty of 15% and an advance against the same
• The marketing team at Packt ensures that the book is well promoted.
• We donate a percentage of sales coming from the book to the Open Source project on which it is based and have donated more than 100,000 dollars to various projects since inception in 2004.

Does it sound interesting to author such a book?

I had to read this twice to understand that this was not some random spam, but an actual offer, based on what I had written on the blog. I have to admit, I was rather surprised and also a little flattered, being not really sure about what to do next.

Then it occurred to me that maybe someone had accidentally mistaken me for a full-time DBA. So I wrote back that I am actually a software developer with only a strong side-interest in database matters and asked whether they still wanted me to write something. In fact at that time I was under the impression that the cookbook format was some sort of a compilation of independent articles, contributed by a series of individual authors and that I was offered a chance to write a recipe or two.

Very quickly however it turned out what they had in mind would be a one-, maybe two-author book.

Over the course of the next days between Christmas and the end of year several mails went back and forth, mostly questions on my part about what this whole book writing business was all about, how much time would be needed and so on. I also forwarded the whole conversation so far to Udo Schwedt, a colleague and good friend of mine with his fair share of MySQL knowledge under his belt, too. Turned out that he was very much interested in the prospect of co-authoring, however we were both quite skeptical about the "about 1 hour per day for the next 6-8 months" estimate that was mentioned in one of the early mails from Packt. In the end we decided to go forward together and get some more details - at this point everything was still in its very early stages with no obligations whatsoever.

Back then the Packt website looked a little different and the pages on authoring we looked at have been changed quite a bit. Here is a link to the current version: http://authors.packtpub.com/content/writing-process

I have to say that this current page contains a lot more details than the old one – at least as far as memory serves... You should read it to get a a quick overview of the whole process. But beware: Turns out there is still a lot more to it than one might expect from this rather streamlined description :-)

On January 5th we received a mail from Sarah, the acquisition editor, which included more information in the form of attached Word and PDF files: Author guidelines, a description of the Cookbook series and a description of what the "MySQL Admin Cookbook" (the title being already set) was planned to be like:

Page Count: 300

Executive Summary

• A cookbook focusing specifically on administrative tasks with MySQL.
• A concise collection of admin recipes, which will have no direct competition from the lengthy reference guides currently in the MySQL market.
• MySQL is, and will continue to be the world's most popular open source database.

Description

As I'm sure everyone is aware, MySQL is a relational database management system. Administrators of MySQL will be tasked with things such as maintaining the database, tuning the server, managing users etc etc.
This cookbook will have all the MySQL recipes an administrator could dream of, spanning from creating tables to managing views, from improving performance to securing the database, from using monitoring tools to using storage engines. DBAs of all levels will be catered for with recipes of varying difficulty, allowing the reader to administer MySQL to their hearts' content.

Why a Cookbook?

There is a wealth of MySQL books on the market, but the majority of them are lengthy reference guides which cover anything and everything to do with MySQL. Our closest competitor - MySQL's Administrator's Bible - spends half of its time introducing the reader to MySQL. Our readers will already be up and running and will just want to know how to get things done as quickly and painlessly as possible. A cookbook is the best approach for this, as they can pick and choose which recipes are most applicable to them and won't have to faff around scouring the pages of a very, very, very long (and boring) reference guide.

Target Audience

DBAs who are tasked with maintaining the administration of MySQL.

Style/Approach

A cookbook, with many an admin recipe.

Prerequisites

The reader will have existing knowledge of MySQL and will already have their MySQL installed and ready to go. DBAs of varying abilities should benefit from this book.

[...]

So how will our book be different?

Quite simply, ours will not be as long, will not try to cover every single aspect of MySQL and will focus specifically on admin issues, whilst assuming that the reader has already installed MySQL and is raring to go and do something practical with it. The ranking of each of these books show that MySQL books sell incredibly well, despite there being so many comprehensive books on the subject.

Armed with this knowledge we decided to go on and started working out a draft of the book's outline – everything still without any bindings or obligations.

As for the outline: I think this will be the next issue in this series of posts...

PlanetMySQL Voting: Vote UP / Vote DOWN

Usually I try to avoid the cookbook type of computer books because usually the 'recipies', often messy scripts or pages of obfuscated code, seem only to work for the authors and not for me. So I had a little trepidation when I was asked to review the MySQL Admin Cookbook. Daniel Schneller and Udo Schwedt manage to pack a lot of very solid information into 360 pages of text that would work for novice to intermediate MySQL DBAs and provide some food for thought for seasoned DBAs.

What I liked: The material was presented with the reasons behind the recipe and pointers to useful tools. Yes, all the material is in the manuals but sometimes there are too many trees in the way for a novice so see the trees. In very calm ,concise language, the authors tackle successfully a wide range of DBA chores in a way that is easy to follow.

I would not hesitate to give this book to a novice to intermediate DBA as a tool to help them work through replication, configuration, indexes and tools.

What I did not like: Time has marched on and the references to MySQL Administrator make a few tiny sections seem dated but I am sure only the Workbench team knew what that product would evolve into. Also the section on monitoring is a bit light but then most DBAs do not need to wade in as deeply as the book goes let alone into Enterprise Monitor or other tools.

So this book is a solid four out of five stars and well worth being brought home by those new to MySQL DBA work and those seeking 'recipes' for thie instances.
PlanetMySQL Voting: Vote UP / Vote DOWN

Finally, it is available for orders: The MySQL Admin Cookbook is the first book I have written and it is now ready for shipping. You can find more information about it at the publisher's website, including a free sample chapter! I have yet to receive my sample copy, however that should not keep you from going ahead early and ordering it, e. g. from amazon.de. For your convenience, here is a
PlanetMySQL Voting: Vote UP / Vote DOWN

The book is in its final stages. Right now I am putting the finishing touches to the illustrations and going through the editors’ most recent comments and suggestions. Takes a lot more time than expected, though…
PlanetMySQL Voting: Vote UP / Vote DOWN