Category Archives: Books

Books

Meet The Author: C# Smorgasbord

Posted by on

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

Posted by on

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…

Posted by on

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?