Beginning Backbone: My First Book

BookCoverIt’s been a long time ambition of mine to write a technical book. In the second half of 2013, I finally got the opportunity to do that, publishing Beginning Backbone.js with Apress. The book is available to purchase now, in all the usual formats.

Read (or scroll, but I’d prefer you read!) to the end of this post to get an excellent 30% off the ebook price until January 23)

Who’s The Book For? Everyone

When planning this book, I had a number of different readers in mind. As such, I feel that I’ve written this book to appeal across the board. JavaScript novices will find the book useful, as it starts at the simplest level. At the same time, experts should find this to be an excellent way to learn Backbone inside out.

I also wanted this book to appeal to CTOs, who are hearing that Backbone is (or isn’t) the next best thing for their web app: this book will help them form their own opinion. Finally, the book will assist teams who are getting to grips with large scale JavaScript application development.  With chapters covering test driven development, best practices and continuous integration, the book shows the level of maturity that JavaScript has reached.

What’s Backbone?  

At this point, I’m sure most people have heard about Backbone, a library that helps organise your JavaScript code in a structured Model View * format. The thing that I like most about Backbone is that it is un-opinionated, unlike Angular and Meteor. While this results in the developer needing to write more boilerplate code, it gives a very comfortable level of control. More about this later, as it is one of the most contentious issues in JavaScript framework selection these days.

What’s in the Book?

There are a number of different sections in the book that deal with different issues.

The Introductory Section

The first two chapters are designed to ease the reader into the web application development world. This first group of chapters introduce Backbone and similar libraries, along with going back-to-basics on object oriented JavaScript. If you’re rusty,it’s worth reading through this chapter to strengthen your understanding of what the language provides before diving into the library itself.

The Nuts & Bolts Section 

The next batch of three chapters bring in the main concepts that exist in Backbone: Models, Collections, Views, Routers and Events. When going through the code examples in these chapters, a node.js server is used to provide a  REST API. While the depth in which node.js is explored is limited, I feel this a bonus for front-end developers. Each of these chapters iterates from the simplest possible version and then shows how additional configuration add more power.

I am particularly proud of the chapter that discusses Backbone Views. In true un-opinionated fashion, I explain how to use three of the leading template libraries for your views: Underscore, Handlebars and Mustache. Using a template library means that you get to avoid polluting your JavaScript with HTML strings. All three libraries listed have their own brilliances, but I find it difficult to beat Handlebars.

With this knowledge, Chapter 6 goes from start to finish with a complete application example. For this I went with Twitter, as it provides an easily understandable API. This gives the opportunity to use a Models, Collections, Routers and many different views on a single page. You end up with something that looks like the picture below.

app

The Extending Backbone Section

From the point, the book changes tone slightly. First I take a look at the huge number of extensions that have been written by the Backbone developer community. Here’s where the naysayers should look, if they feel that Backbones lack of data-view binding is hampering their progress. There are extensions available to help you out of almost any problem that you feel Backbone has. The beauty of this is that you can easily integrate most of these plugins in your Backbone applications. And it’s just as simple to take them out.

Similar to this chapter, Chapter 10 looks at Backbone Marionette and Thorax. These are amazing additions to Backbone, and deserved their own chapter. To put both through their paces, the Twitter sample application is refactored to utilise the features they provide.

The Discipline Section

With all this code, you’re going to need some discipline. That’s where the test driven development chapter will help. The most popular JavaScript testing frameworks out there are Jasmine and QUnit, so these are both described in detail, illustrating how to test out that sample Twitter application.

The next chapter shows how to use Grunt to add continuous integration to your JavaScript development. Grunt is an amazingly powerful tool that no JavaScript developer should be without. As a developer who has come from the Java world, it’s great to see something that easily surpasses the power of Maven or Ant.

The Doing-It-Better Section

For anyone who is already using Backbone, the chapter on best practices will help them to improve on what they already know. These tips were gathered from a wide variety of sources, as well as from my own experiences. Then the book closes out with tips on making your code even more manageable by using Require.js to created a modular codebase.

That final chapter also shows how to use the amazing Yeoman when you need to start from scratch in your development. The Backbone generator that’s included is brilliant. And once you discover the starting point that Yeoman provides, you’ll never look back.

So, In Summary

As you can see, while to book focuses on Backbone as the core topic, it extends much further. It’s a book that covers everything that you need to know about using JavaScript, along with Backbone, in a professional software development environment. I really hope you do enjoy reading it, and using anything that you learn, as much as I enjoyed writing it.

If you like the sound of this, why not buy the book. Or how about this:  I can give you 30% off the price of the ebook if you purchase the book from the Apress site using the code BCKJ14.  
 
BookCover

Meet The Author: C# Smorgasbord

About two months ago, Filip Ekberg sent me a preview copy of his upcoming book, C# Smorgasbord. His timing couldn’t have been better – although I’m traditionally a Java developer, I had started looking a writing an app for Windows 8, and had decided to use C#. This book is structured and presented in a way that helped me learn what I needed to know really easily.

About The Book

The book is neatly structured so that you can digest one chapter at a time, depending on what you want to solve. For example, there’s a chapter purely dedicated to unit testing, while another looks at parallel extensions. Dynamic programming, inversion of control and mocking are all given their own chapters. The fact that the chapters were so focussed and could be read in isolation, in any order, is one of the best features of the book. 

Filip shows his depth of knowledge and experience, guiding the reader with good examples and an easy to follow commentary throughout.  The book acts as an essential reference for any developer working with C#. As someone who wasn’t very familiar with the language before, I feel that I have a much better understanding now.

An Interview With The Author

I also had to chance to ask Filip some questions about the book and the whole process behind writing it. Here’s what Filip had to say

DZone: Could you please introduce yourself and your experience?

Filip Ekberg: I am Filip Ekberg and I work as a professional Software Engineer. My primary focus has been C# development ever since I started my own company in 2005. Computers have always been my biggest hobby and ever since I discovered programming when I was a kid it has been my greatest passion.

During the years, I’ve had the pleasure to work with a variety of different things that have given me a great experience. Other than C# I’ve also worked with Java, PHP and C++, among others.

Teaching others have always been something I’ve enjoyed. During the time that I studied for my bachelor degree in software engineering I also worked as an amanuensis; teaching a program called “Creative Mobile Development”. This is somewhat where my blogging started to take form; I started to write articles for the class that I also wanted to share with the rest of the world.

DZone: Is this your first book? What inspired you to write it?

Filip Ekberg: This is my first, but hopefully not my last book.

Most of my inspiration came from my own articles that were re-published on DZone, my screencasts and different presentations that I’ve had for colleagues.

I felt that I had covered so much interesting topics in all the material that I had written so I wanted to explore that and see if it could evolve into something else.

DZone: Can you tell us a little about the writing process? How long did it take and what were the most difficult parts of the process?

Filip Ekberg:  This is actually something that I’ve thought about a lot; I think I could write an entire book on how to self-publish a technical book.

It all started out when I took all my raw material that I had and just put it in a Word document that had a template that I liked. But I soon realized that this posed some problems and difficulties. For instance, the content needed a lot of work to become perfect for “offline-reading”.

During the work on my book I’ve shared hundreds of screenshots with people on IRC, Twitter, Facebook and other places. This has led to a lot of positive and negative comments on the type-setting and such.

Very early in the process I got a tip that I should try out LaTeX and so I did. Basically LaTeX helps you typeset your document by allowing you to write some pretty nice markup. The reason I wanted to try something else than Word was because it posed some difficulties, since I got a lot of feedback from the people that saw my screenshots. I wanted to be able to change the entire layout of the book in just one click. So by using LaTeX, it made it all as easy as writing HTML and CSS.

This also gave it a professional look out of the box with good print ready fonts and such. But there were still lots of work to do on both the layout and the content. Meanwhile when I wrote, I shared more and more screenshots, resulting in a lot of very good feedback. Which led to what the book looks like today.
Also very early in the process I invited a handful of people to help me review the content as I wrote it, so that I would get lots of more feedback during the writing process. This is where one of the most difficult parts of the writing process was; distinguishing between objective and subjective opinions. But thanks to the proof readers Chris Anzalone, Wyatt Lyon Preul, Justin Rusbatch, Alexander Rydberg and Andreas Strid it all turned out very good.

Almost all of the raw material that I had before I started writing the book, was re-written. This means that while I had already put probably 100s of hours into creating good material for articles, screencasts and presentations, this material did not fit into the book without a lot of re-work. So I think it is safe to say that I put down probably not less than 1000 hours type-setting and writing after I had the raw material.

DZone: What sets your book apart from other C# books?

I think the title gives this away “C# Smorgasbord”. In most books you’re focusing on one technology, pattern or a bunch of practices, but you never combine all these together in a nice mix.

All the chapters in C# Smorgasbord can be read independently from each other. The idea behind this is that after reading each chapter, you will have some new knowledge that you can apply in your everyday work.

Explore your possibilities with C# and improve your skills while you will be inspired to challenge yourself. Talking about everything from LINQ to Productivity, Quality and Readability to Roslyn, Dynamic and Asynchronous programming.

DZone: What chapter are you most proud of?

Filip Ekberg: This is very difficult to answer, because of the layout of the book where each chapter is independent and cover a different technology, pattern or practice.

But if I have to choose one, I would say Chapter 9 – “Creating things at runtime”. In this chapter we look at how to create things in runtime using MSIL and how the evaluation stack works.

DZone: Where can people purchase the book?

Filip Ekberg:  Amazon primarily, but also CreateSpace and for a digital copy you can visit http://books.filipekberg.se/.

It will also be available on Kindle later this year.

DZone: What are your plans for next projects / books?

Filip Ekberg: Next up is getting this book ready for Kindle and I also want to get back to blogging more frequently and maybe start collecting material for a new book. I’ve got some ideas but I need to do some more research before I can disclose too much about that!

DZone: Finally, what are your opinions on Windows 8 and the Metro style?

I thought the cover would give that away!

I’ve been running Windows 8 on my work computer since the consumer preview and I really like it.

Regarding Metro, I think it is a great idea going back to the basics; less is more. But as I’ve been using Windows 8 on my work computer, I’ve noticed that I’m rarely in the Metro view at all, just when searching for an installed application that I want to start.It is going to be really interesting trying this out on the surface and see how it feels on a touch device.

 

I Don’t Write Unit Tests Because…. : The Excuses

As someone who’s seen the benefits of the approach, I’m a huge believer in test driven development. It adds a level of quality and maturity to the field of software development, yet it’s still not a widespread practice across development projects. When it comes to a choice between the features, time and quality, it’s always the quality that suffers. We don’t want to add extra time for testing and we don’t want to compromise on the feature set of the delivery. If you haven’t set out to do test driven development at the start of the phase, then it’s difficult to fit in.

We’ve all heard excuses for not taking the test driven approach, but nowhere compiles them better than “Pragmatic Unit Testing in Java With JUnit“, from the Pragmatic Bookshelf.  I read the book a few years ago, and afterward I thought there was no way that any responsible developer could read the book without truly believing that unit tests were one of the most important aspects of the development activity.

The most worrying excuse I’ve heard is that it’s too difficult to test my code. This can be for one of two reasons. One is that your code is mainly UI related, and automating the UI tests is too difficult. I’ll concede that UI automation is a tricky area (but not impossible, as we’ll see in a later article), but every effort should be made to automate it if possible: think about regression tests. If you have a fully automated test suite, including the UI behaviour, you can make a change to your code, and have full confidence that you haven’t broken anything if you have tests to re-run.

The second reason that your code is too difficult to test is that you’ve messed up your design. Maybe your logic and UI code are too tightly coupled, and without that automated UI layer existing, the dependency between the logic and the UI will cause a problem. This is where test driven development helps to ensure a clean design, following best practices. Using JUnit is simple, so if I can just point my test at a clean logic layer, I can test all logic that the UI will ever touch.  What’s that? You’re missing your data model? Well then just use mock objects – there are many frameworks for that!

For those who haven’t read the book yet, I’ll give a quick summary of the excuses for not testing as outlined in the introduction chapter:

  • It takes too much time to write tests
    As the number one reason that developers give, and thinking back on my own education, I think this is down to the way computer science is taught. For the most part, we’re lead to believe that testing happens at the end of the process, not all the way through. 

    Pragmatic Unit Testing encourage the “pay as you go” model, where having tests written as you are developing means that you don’t have that crunch time at the end where you try to cram all your unit tests in.

    Anyway, if you’re not writing tests as you go along, how are you checking if the code behaves as you expect? You run it manually? Wouldn’t it make sense to invest some of that manual testing time into writing a JUnit test for it? I mean you’ll have to run that piece of code again sometime – it’s not going to remain untouched for the lifetime of the product.

    In fact, there are many more time penalties that happen if you don’t write unit tests. You’ll have to spend time debugging code trying to work out why something doesn’t work. Or you’ll refactor the code, and then find that nothing works as it used to after the refactor. If you had the unit tests written, you have a base of confidence.

  • It takes too long to run the tests
    I’ll admit, there can be a good amount of time taken running tests that involve external entities, or the user interface. But you’re supposed to have more than one level of test. The unit level tests should run quickly, and there may be a level of integration tests that can run without a big time impact. If there are higher level integration tests that are taking time, just run them less frequently – maybe even in a nightly build. That’s not to say you should ignore the lower level unit tests. These should always run fast enough that it becomes a natural part of your own development process.
  • It’s not my job to test code
    I don’t know at what stage a software developer decides that he can just throw code over the wall. If your job title was simple Coder than maybe there’s an excuse. But as your job is to develop working software, you need to be able to say that your code is functional.  The book makes a good point that if the QA development finds it difficult to find bugs in your code, it will do wonders for your reputation.
  • I don’t really know how the code is supposed to behave so I can’t test it
    This is a difficult one to react to without incredulity. If you don’t know how the code is supposed to behave, you shouldn’t have started writing it. You need to understand the requirements first.

There are a few more excuses listed in the book, but these are the main ones. What are the excuses that you’ve heard for not writing tests.

If I Could Recommend Eight Books For Java Developers…

There are many books that are essential for your bookshelf if you’re a Java developer. But if I had space for just five books, which ones would I recommend? This question came into my head when I read this post about book recommendations.

Going Back To Basics


Topping the list of essentials for me has to be A Programmer’s Guide to Java Certification. I bought it before I did the certification exam years ago. Even though the edition I have refers to Java 1.4, it’s always been an excellent reference for the basics of the language. Without doubt, it’s the best book available to get going in Java.

Improving Performance


A few years back, I was working on some performance intensive features. I thought I knew threads well enough – I was wrong! This seems to be a common trend among all developers, we don’t have a great grasp on concurrency. Thankfully, Brian Goetz does and published Java Concurrency In Practice

As well as simply explaining threading you’ll find how to design and test your applications for concurrency. As multiple cores become more common this book is a must have for Java developers – especially as we dispel the myth that Java can’t be fast.

Becoming A Better Developer

The Pragmatic Programmer surprised me when I read it first. While not being specific to any language it sets out some great principles, habits and approaches for developers. I still read it every year or so to refresh. It’s been good for my own growth as a developer, and for the growth of development processes I’ve been involved in.

This book should be used in all computer courses, as it would lead to a higher percentage of graduates with a practical view on development.

 

 

I only recently read the highly acclaimed Clean Code by Robert C Martin, and that has proven to another valuable addition to my developer bookshelf. From the very beginnings of the book, you will notice common themes that lead to a poor code base.
If every developer took the time to read this book, I’m sure that software development would have a much better reputation.

Becoming a Java Expert


The second edition of Effective Java has been a welcome addition to my developer bookshelf. It has some great tips that I wouldn’t have picked up had I not read the book. And with such high praise from James Gosling, it’s a book that can’t be ignored.
“I sure wish I had had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.”

The Classics

While this book is outdated in some aspects, if you can afford it, it’s a useful reference to have on your bookshelf. will always be seen as the classic book for software design.

Designing With The Future In Mind


The original GoF Design Patterns book has has set the scene for other books on patterns and design in general. Emergent Design: The Evolutionary Nature of Software Development really caught my attention recently. It has a nice concise appendix of design patterns giving a non-software analog for each, which really helps with understanding them.

It’s a great book for architects and developers to read to make designs more futureproof, stable and helps answer the question How Much Design Is Enough. It easy reading and shows how the software development industry can mature, and what you can do to improve your own practices.

 

Practical Design Patterns


The Head First series really focuses on making it easy to learn the concepts. While the original GoF book can be a bit daunting, I would certainly recommend that software developers, especially novice coders, get this book to see practical implementations of design patterns, written in Java.

 

I’m sure this isn’t the definitive list for all developers so I’d be happy to see your own opinions. What books related to software development have you found indispensable?