Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 468

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 483

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 490

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 526

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/theme.php on line 618
Real Life Debugged » Book Info

Archive for the Category ◊ Book Info ◊

Jack Ganssle’s Review of My Book
Friday, February 27th, 2009 | Author: lisaksimone

JackGanssle presented a book review of my book, If I Only Changed the Software, Why is the Phone on Fire? in his latest Embedded Muse Newsletter #174.

An except from Jack’s review:

Engineers are famous for being very bright but also for lacking basic writing skills. Yet writing is still our primary means of communication, so we buy heavy tomes created without the benefit of basic grammar and often bereft of a coherent structure. Storyline? Character development? Forget it.

Welcome to a very different kind of technical book. Lisa Simone’s work isn’t the usual dreary tome stuffed with arcane wisdom buried beneath paragraph-length sentences seemingly written by someone just learning English as a second language. This is certainly the first embedded book with characters. The first with action, and with interesting and cool stories.

Bad code that makes a phone burst into flames?

What fun!

And yes, at one point in my sordid technical past, I did have to debug a very hot phone.

After successfully (I hope!) hiding the problem from potential customers at an international trade show in Singapore. Thankfully, the phones were displayed on marble tables - very good for heat dissipation between hurried demonstrations!

Subtitle: “An Author’s Relationship with Amazon, Google and Search Engine Optimization (SEO)”

I admit, when the book first came out, I was so antsy to see it on Google. In the beginning I was secretly disappointed to keep finding it behind pages and pages of cell phone battery horrors … “Girl burned when cell phone catches fire” … “cell phone sparks fire that leaves California man severely burned.”

But after the the book came out and gained publicity, my attitude (and my mental status) buoyed happily seeing it at or near the top of search results. Then at international Amazon sites, and in lists in industry journals and college libraries. And the reviews - I printed out page after page to save for posterity!

But … my amusing and somewhat sarcastic writing style didn’t win me this international publicity. Nope.

It’s all about Google and Amazon. And SEO - search engine optimization.

more…

Thanks to my publisher, Elsevier/Newnes, the first chapter of the Phone on Fire Technical Mysteries is available online! I am including a link to it here, and also to the Elsevier website.

Excerpt from Chapter 1:

It was an odd-looking line of code, awkward in its form and syntax, dovetailed between well-formatted lines that marched up his computer screen. The pleasant left-and-right rhythm of indentation was marred by this single line, positioned brazenly flush with the left margin.

Not appropriate at all.

It was the offending line’s placement that first caught his attention, as if it had been cut-and-pasted by mistake. Closer inspection added to his unease. The original author of this code was not the author of this line - a hack interloper had destroyed the beauty of this software. Oscar raked a hand through his hair as he pulled his focus away from the individual characters and syntax and let awareness of the code’s function flood his brain.

It was a command to store a block of data into memory.

He scanned the comment section of the function and found no reference to the change. He wasn’t surprised; someone writing sloppy code generally didn’t pause to add comments.

But could this line be the source of the emergency, the reason why he’d been summoned back to work at 10 p.m. last night? And then spent the day alternately hunched over a lab computer and being dragged into various managers’ offices to estimate when he could fix a bug that he hadn’t yet had time to understand?

Three days before the final hardware and software were to be finished and delivered to manufacturing, the display on the Friend-Finder Communicator device suddenly turned red.

For no apparent reason.

Red.

Find the entire chapter here - with my shameless permission to link to it as well!:

Chapter 1) The Case of the Irate Customer - Debugging Other People’s Code, Fast!

Cover Art: The Acid Flashback Big Reveal
Friday, January 16th, 2009 | Author: lisaksimone

Back when I was emailing Newletters to folks in the pre-production days, one of my anguishes was the book’s cover art. Now that I have recovered over the past year or so, I can talk about the whole trial less emotionally (… I lament in that totally weak wilty female whisper of delicateness while fanning flushed face quite rapidly).

** Rolls eyes **

Anyway, in Phone on Fire Newsletter #4, “Author Anguish,” I had relayed that the publisher forwarded three concepts for the cover, and that I had been underwelmed by all three. I also admitted,

One was downright awful. I think I used the phrase “acid flashback” in my feedback to the publisher on that one.

I refused to show anyone that concept. I think after all this time I will reveal the cover art that nearly scarred me with the idea that they were actually considering it.

more…

“Phone on Fire” Foreword by Jack Ganssle
Sunday, December 14th, 2008 | Author: lisaksimone

Foreword by Jack Ganssle

The oldest known book about engineering is the 2000-year-old work De Architectura by Marcus Vitruvius Pollio. One historian said of Vitruvius and his book, “He writes in atrocious Latin, but he knows his business.” Another commented, “He has all the marks of one unused to composition, to whom writing is a painful task.”

Does that sound like the last ten technical books you’ve read?

Engineers are famous for being very bright but also for lacking basic writing skills. Yet writing is still our primary means of communication, so we buy heavy tomes created without the benefit of basic grammar and often bereft of a coherent structure. Storyline? Character development? Forget it.

Welcome to a very different kind of technical book. Lisa Simone’s work isn’t the usual dreary tome stuffed with arcane wisdom buried beneath paragraph-length sentences seemingly written by someone just learning English as a second language. This is certainly the first embedded book with characters. The first with action, and with interesting and cool stories.

Bad code that makes a phone burst into flames?

What fun!

This is a James Patterson-style fast-paced book with dialog as close to gripping as one can imagine for a computer book. Its uniquely embedded focus twists together elements of hardware and software just as we engineers do in our daily design activities. One can’t be understood without the other. Code makes the hardware smoke. That’s unheard of anywhere but in the embedded industry.

more…

Should you read at your desk at work, or under the covers before bed?

This book can be enjoyed in a number of ways - it was written for folks of all experience levels from students and new engineers to seasoned technologists. Each mystery is a window into technical team dynamics and provides a “Day In The Life” for folks curious about the field. Each mystery stands alone, although the Hudson team is the thread that weaves the stories together.

I invite you to grab a pencil and work through the examples to solve the mysteries before the team at Hudson Technologies does. Write in the margins. Think of other solutions. If you get stuck, work through the symptoms and the evidence side-by-side with Oscar’s team and verify what they conclude. Or, just glide along with the team as they tackle one technical mystery after another. (I’ll state upfront that none of the bugs are caused by minutiae like missing semicolons or misspelled variable names!)

While you get caught up in the mysteries, I hope some of the team’s tricks get lodged in your brain and come floating back out when you find a similar bug or symptom in your own technical travels. When that happens, check out the appendix - everything you’ve learned is nicely summarized with references back to each mystery.

It’s all about your approach to problem solving.

Make your next step a logical one instead of a random one.

This book also targets a very wide audience. Several types of folks will enjoy these mysteries. All kinds of engineers, students interested in science and technology as a career, technical and support staff who have to debug and understand embedded systems.

And maybe best of all - your FAMILY and FRIENDS! Never know what to buy for your favorite techies? How about a neat technical mystery book!

more…

What’s in the “Phone on Fire” Mystery Book?
Sunday, October 26th, 2008 | Author: lisaksimone

What this book ISN’T

This book is not a hardcore textbook or a manufacturer-specific or toolset-specific “how to” book. It isn’t a book that becomes dated after a few years. It isn’t a book that guilt-trips you into reading it just because you bought it.

What this book IS

This book contains a series of technical mysteries for readers to solve. It’s fiction, and it’s nonfiction. “CSI for Embedded Systems” if you will. Machines crash, products catch fire - the engineers at Hudson Technologies race to fix the problems before it is too late!

more…

In the past, learning and teaching debugging was, perhaps, only somewhat more haphazard than it is now. Learning from a mentor, a teammate, trial-and-error at 4 am before a customer demo. I’ve pulled double all-nighters. Painful, with a stomach-churning donut-induced sugar high.

This “approach to problem-solving” - it is really such a big deal? Donuts are pretty tasty…

more…

Life breaks when you least expect it.

This blog shares all kinds of real life situations that need a good fixing beating. Typical stuff that goes wrong at all the wrong times. And how to have a little fun fixing them rather than running screaming into the night.

What was the impetus for these meanderings?  I wrote a collection of technical mysteries of products gone bad, and wanted to share them as humorous and interesting stories of how to solve these real life problems.

If I Only Changed the Software, Why is the Phone on Fire?
Embedded Debugging Methods Revealed
Technical Mysteries for Engineers

Through my years as an engineering technologist and product developer, I discovered we technical folks can always learn new ways to solve problems. “Phone on Fire” is a series of neat technical mysteries - like CSI-for-engineers - that reveals these skills in a fun-to-read format.

The book is both fiction and non-fiction, an interesting combination that challenges book stores to ponder which shelf it goes on. My publisher, Elsevier/Newnes, pondered the same concept. As a result, the book’s name grew somewhat unmanageably to allow Amazon and online search engines to find the book for interested folks seeking one or the other.

Authors are never completely in control of the name chosen for a book; unless, perhaps, if said author is Michael Creighton or Stephen King. So, stretch your mouth out to say the whole title, or as most of us do, refer to it fondly as Phone on Fire.

And what other interesting (and unexpected) publicity and marketing influences do authors find? I’d like to explore here as my journey continues in the Foreign Land of Book Marketing for Engineers.