photoKandy Studios LLC

News and Updates

Posts

  • Jun 30, 2014
  • Kerri Shotts

Packt Publishing $10 e-book sale

So Packt Publishing is celebrating its 10th birthday, and in honor of the event, they are making every one of their e-books and videos available for $10. In 10 years, they’ve published 2,000 books – which is absolutely amazing, and you can get as many e-books as you want for $10 until July 5th, 2014.

So if you need to stock up on some good technical reading, now’s the time!

What are you waiting for? Go Get!

Note: If you don’t see the $10 price, make sure you go through the link directly above and scroll down to the categories.

Read more...

  • Jun 29, 2014
  • Kerri Shotts

PhoneGap 3.x Mobile Application Development Hotshot Giveaway

PhoneGap 3.x Mobile Application Development HotShot

I am pleased to announce that I have teamed up with Packt Publishing and we are organizing a giveaway especially for you. All you need to do is just comment below the post to have a chance of winning a free e-copy of PhoneGap 3.x Mobile Application Development Hotshot. Two lucky winners stand a chance to win an e-copy of the book. Keep reading to find out how you could win!

Overview of PhoneGap 3.x Mobile Application Development Hotshot

  • Use PhoneGap 3.x effectively to build real, functional mobile apps ranging from productivity apps to a simple arcade game
  • Explore often-used design patterns in apps designed for mobile devices
  • Fully practical, project-based approach to give you the confidence in developing your app independently
  • More Information:

How to Enter?

Simply post what you hope the book will allow you to do with PhoneGap, or post what you find most interesting about PhoneGap in comments section below. Two commenters will be selected at random to receive a free e-copy of the book. Of course, if you like the book (or not), it would be most appreciated if you would leave a review on Amazon or even your blog – but this is not at all required to win a free e-copy.

DeadLine:

The contest will close on July 14th, 2014 . Winners will be contacted by email, so be sure to use your real email address when you comment!

Read more...

  • Jun 8, 2014
  • Kerri Shotts

Writing a Technical Book

This is part 1 of a series regarding technical writing. See other related posts.

As you may or may not know, I’ve now written two pretty large technical books (one was the second edition of the first). If you want to know more about those books, you can see all my books here. This post is more about the process of writing technical books, and later posts will go into more detail about my experiences with Packt Publishing (the publisher).

You Won’t Get Rich Writing Technical Books

First off, let’s make something very clear: technical books are mostly niche products. They aren’t going to make you rich, and only a very few writers are going to either have enough name recognition or will have written enough books in order to generate significant income. This is a fact, and you shouldn’t approach writing a technical book with “getting rich” in mind. It probably won’t happen.

There are several reasons for this fact:

  • Technical books often apply to a very narrow audience (by their very nature)
  • Technical books are commodities
  • Technical books are instantly obsolete
  • Advances, royalties, and e-books

Technical Books Apply to a Very Narrow Audience

It should be pretty obvious that the very nature of a technical book inherently limits the number of people who will purchase it. It’s not like the book you are writing is a fiction book that’s going to be the next Harry Potter and will sell millions and millions of copies. Even if your book is about a widely used programming language or other well known topic, the number of people who are going to buy your book are far less than those who are going to buy typical fiction (or even non-fiction) books.

Technical books are Commodities

That is to say that the publisher has no incentive to spend a huge sum of money on a technical book, nor do they have an incentive to take their time with more than a couple editing passes and such. Most of this is due to the next point, but I think you should already understand why this is generally true: technology often moves far too quickly for typical publishing. Technology is fast, writing and publishing is slow.

Now, this isn’t to say that the publisher doesn’t want to put a good book on the shelves – of course they do. But neither do they have any incentive to pay you a large advance for it, nor do they have any incentive to allow you to take three or four years to “make it perfect” (much to the chagrin of perfectionists everywhere). In the first case, there’s always someone else willing to do the writing “just for fun” (and that isn’t meant to be derogatory – I like writing just for fun), and there’s always the chance that the technology will quickly move on, leaving you in a perpetual state of editing and playing catch-up.

Technical Books are Instantly Obsolete

Just to underscore the point, my book was about PhoneGap / Cordova 3.x. By the time the book was done, Cordova was at 3.4, and all the examples had been tested on that version. Two days after publication, Cordova 3.5 was released. Now, as far as I can tell, it broke nothing – but there were occasions during the writing process where changes were released that did break things. And of course, there’s still the chance that Cordova 3.6 or a plugins release will still break the book. And, of course, being in print, there’s no way to fix it, short of submitting errata and hoping that readers will look at them.

Advances, Royalties, and E-books

Now, Packt generally offers a pretty good advance for their technical publishing, especially for first editions. (Later editions get lower advances, because it is assumed one won’t have to rewrite the whole thing. Which was not the case for the second edition of my book, but oh well!) Packt’s royalty rate is pretty good too, but it comes out to a few dollars per unit. Furthermore, you won’t see any royalty payments until your advance is paid off, so if a book sells slowly or poorly, it may be quite some time before you see any more income from your efforts.

Not that I’m complaining in all of this, I’m not. I love writing, and do it for fun, so I have no problem with the economies involved here. But if I were to be honest, and I were to value the book based on the time it took and the amount I would charge a client, the book would easily have cost between $50,000 and $100,000 (USD). I won’t go into what my advance was, or what I expect my royalties to be, but let’s be blunt: it won’t pay for itself, or even come close. And I don’t care. But if you were going into this caring about breaking even or making goodly amounts of money, you are going to be in a world of hurt.

Furthermore, e-books and retailers add another wrinkle in this. The suggested price for my book is in the $50 range, while the price on Amazon is $33. The e-book price is even lower: $20. Obviously the royalties generated from these purchases are going to be lower. If the rest of the world is anything like me, I buy nearly all my books as e-books, and I suspect most people buying my book would do so as well. Again, not complaining, but pointing out the economies involved.

Writing Technical Books

The process of writing a technical book is… intense. Most publishers will indicate that you can do write a technical book alongside of your full-time job, with only a few additional hours dedicated to the book. O, if that were true. It isn’t. (Maybe someone can, but not me.)

What’s true is that you’ll be working at least an additional part-time job (around 20 hours per week). Now, I’m sure this varies based on the type of book being written, but here’s how my process typically went:

  • Create the sample application for the chapter.
  • Debug the sample application.
  • Test the sample application on various devices, and fix any issues.
  • Write the first pass of the text, applying special styles as necessary to mark certain parts as keywords, code, URLs, etc.
  • Create the necessary graphics for the chapter (diagrams, screenshots, etc.).
  • Copy in the code samples from the application for the book, adjust formatting, add useful comments.
  • Review the text to ensure that everything makes sense, is in the right order, etc.
  • Package the text and code and send it to the publisher.

This was the process for the first few chapters, but after a while, one hears back from the publisher (and other technical reviewers – life-savers, them!) with comments about the earlier chapters: about what didn’t make sense or didn’t work, etc. These comments are invaluable, and the book wouldn’t be half as good without them. But now the process becomes all of the above (for the current chapter), and then add the following:

  • Review comments from publisher / reviewer.
  • Revise text accordingly (using best judgement – there isn’t always room to respond to every comment).
  • Revise the code and graphics if necessary.
  • Update the code and text for the chapter to reflect any breaking changes (and test, again!), especially if the underlying platform has changed since the original writing.
  • Repackage code, graphics, and text, and send to the publisher.

Now, all of this goes on while you are doing your regular job. Although I’m a consultant that gets to work remotely and gets to manage her time much more flexibly than others, even I found it difficult to manage both my “day job” and my “book job”. I’m not sure I could have done it working a 40-60 hour/week job alongside.

Needless to say, there were many coding and writing marathons going on each week: quite often the weekend would receive the brunt of this – with 10-12 hour days for two or three days in a row to meet the deadline. Of course during the week there were often long evenings as well – it’s extremely difficult to write a sample app in a week or two for a book, especially when it usually takes much, much longer to push an app to an app store.

Of course, no one is perfect, and so there were inevitably going to be errors in the book that neither me, nor the publisher, nor the reviewers were going to catch. This is a fact of writing books: we’re all human. Some of these errors were my mistake – others were issues caused by trying to keep up with the evolving technology stack I was writing about. In the case of this book, it is absolutely true when I tell you that I was submitting changes to the text a couple days before it was to be uploaded to the printers.

That’s enough for part 1 of this series, I think. In the next section, I want to cover some of the tools I used in writing the book, and then I will go on to get into details regarding working with Packt Publishing and address areas where the process could use improvement, but also address the overall good experience of publishing with Packt.

Until next time, keep writing/coding!

Read more...

  • Jun 1, 2014
  • Kerri Shotts

PhoneGap 3.x Mobile Application Development Hotshot Released

I’m so proud to announce that my new book, PhoneGap 3.x Mobile Application Development Hotshot is now available for purchase. It’s an update to my earlier book, and it has been modernized and updated for Cordova 3.x. Although the title includes “PhoneGap” in the name, it generally uses the Cordova Command Line Interface (“PhoneGap” is more recognizable in the market).

The book will guide you through the installation of the Cordova and PhoneGap CLIs and will also guide you through the development of three fully functional and interesting mobile apps. These apps are cross-platform (they work on iOS 6+ and Android 4.x) and support multiple form factors (phone and tablet).

Filer

The first app is the most complex and is the one we spend seven chapters with. What starts out as a simple note-taking app is grown over the course of several chapters into a app that can play and record audio, take photos, and record video. When we’re done, it can also share content to social networks, and it can also adapt to different screen sizes.

PathRec

The second app focuses on Google Maps and GPS – it allows the user to record their location over a period of time. This path then shows up on the map using Google’s polylines. There’s also an online chapter where we extend the app to use native controls (for iOS 7 only).

Cave Runner

The final app proves that we can learn and have fun doing it, too. The app is a simple arcade-style game that uses the HTML5 Canvas and the accelerometer. The second version of the app adds support for a high score table (stored using Parse, a backend-as-a-service).

Throughout the book we also focus on technologies related to mobile application development. We introduce RequireJS, which makes building large, complex apps easier with dependency management. We utilize Hammer.js to provide gesture recognition (for swipe-to-delete and fast touch recognition). We also utilize CSS3 transitions and transforms for smooth animation.

One possibly controversial decision is the use of the YASMF-Next framework in the book. First, I wanted to write a book about PhoneGap, not a book about a specific framework like jQuery or Sencha Touch. Unfortunately, although it’s possible to write apps without any framework, one quickly builds up a repository of reusable components that, over time, morph into a framework themselves. And that’s YASMF-Next – a framework I’ve designed that meets most of my needs when it comes to creating apps in PhoneGap. It’s young and immature, but it is being worked on heavily. An earlier version of this framework was used in the prior edition of the book, but my coding has grown in the last several months, and the new version of the framework reflects this. Furthermore, the framework is small – it’s not terribly complicated, which means that it can be used as a learning tool as well (much as Minix can be used as a learning tool for operating system design). In addition, the book usually explains how YASMF-Next is accomplishing everything and shows similar code for accomplishing the tasks if you don’t want to use the framework. And, of course, you can always take the skills learned in the book and apply them to many of the other popular frameworks.

Finally, I wanted to thank all the reviewers who participated in making sure the content going into the book was accurate (and that it made sense), and Steve Husting in particular who was roped into testing the code (Thanks – you’re a trooper!). I also wanted to thank all the hard workers at Packt Publishing who put everything together, kept me on task, limited my ramblings (sometimes to no avail, sorry!), and got this out the door.

So what are you waiting for? Use those “buy” buttons at the top of this post, or visit the following links to purchase the book! And if you’d be so kind to leave a review, that would be amazing!

Read more...

  • May 28, 2014

Welcome to the new site!

So, it’s 2014, and this site has been due for a redesign. As such, we’ve completely redone the look and feel of the site and made it even more responsive. We also started using Jekyll to generate the site rather than use a single page design as the prior design used.

While we’ve tested in several browsers and on many different devices, if you do find something that is broken, let us know.

Read more...