Full disclosure: I was a technical reviewer for this book
This is just a simple but rock-solid book on unit testing in Java 8. I wouldn't let the titleFull disclosure: I was a technical reviewer for this book
This is just a simple but rock-solid book on unit testing in Java 8. I wouldn't let the title fool you - it doesn't seem to be a big Java 8 book, in fact it doesn't really even seem to leverage the features Java 8 introduces very much. I think mostly it's a book about Unit Testing in Java, and Java 8 happened to have been released at the time, so it got thrown in the title. The code definitely IS Java 8 (not 7), but I wouldn't say that it's a book all about how Java 8 introduces new features, and here's how to unit test code that uses them, which is kind of what the title implied to me.
Mostly the book seems geared to people who are brand new to unit testing, maybe people who had never written a unit test before. The different mneumonic devices (CORRECT, FIRST, etc) underscore the targeting of newbies. However, it does NOT seem like it is a book for people new to Java itself, or even Java 8, since very little explanation is provided for any of the code aside from the unit tests themselves and why they are the way they are. If you're a big unit tester, you might find a lot of the book doesn't provide you with anything new, but honestly I actually recommend reading it anyway.
Part I is going to be familiar to anyone with background unit testing - it's just the basic mechanics of testing itself. Part II however might give even unit testing veterans some stuff to think about. It's basically all about how to write effective tests that really stress the system - and it introduces a number of mnemonics to that end. A little cheesy but I actually learned quite a bit here, and was surprised at how useful I found it, given how much experience I have writing tests.
When I first started reading Part III, all about the overall design of your code, my reaction was thinking, gosh, a lot of other books cover refactoring... it seems out of scope for a book on testing. I was very skeptical, and I didn't understand why it was included. But once I kept reading, I saw the point, and saw how using mock objects were going to allow us to refactor the book's primary example code into something more testable, and better-designed because of it (it even fixed an issue I had with the code when I first saw it, the side effects in the scoring method). By the end of the section, I was fully on board, and to be honest an entire chapter about refactoring tests was simply amazing (and easily my favorite chapter). To be frank, these later chapters are worth the price of admission alone for the book, I can't remember any other single book that covers refactoring to improve quality of tests themselves (especially in a step-by-step fashion). I can't even remember a book that covered testing multithreaded code, and for it to just be a chapter at the end of a book on testing in general was a real treat. This book covered absolutely everything, mock objects, refactoring, TDD, SOLID, and of course the basic principles of unit testing in general.
I was pretty impressed with how thorough and useful parts I and II were, but I was blown away by III and IV. Simply put, this is probably my favorite book on unit testing I've ever read. If you're new to unit testing and use Java (even if it's not Java 8), this book is a must-read. If you're a unit testing pro, there might not be that much for you here, but I still recommend giving it a read anyway and just skipping bits and pieces. Parts II and III in particular have a lot of valuable insight to share....more
There's not really a lot to say about this book - if you're interested in CoffeeScript, then it's great. It summarizes a lot of what CoffeeScript is aThere's not really a lot to say about this book - if you're interested in CoffeeScript, then it's great. It summarizes a lot of what CoffeeScript is about, the syntax, and is basically very good documentation on the language.
Full disclosure: I was a technical reviewer for this book....more
Full Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it'sFull Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it's worth reading. The essential idea is exactly what the title says - this seems weird or impossible at first but I assure you, the title is genuine. Effectively what this book is about is using forensic techniques to figure out which spots in a large code base are most in need of improvement/refactoring.
There are lots of different kinds of things to look for and visualize in your code to help figure out dangerous areas in it, and the book takes you through each one, how it works, and how to get at the data to find these areas. It's really, really interesting, in fact it's one of the most interesting books on software I've ever read. At a previous job, we did something similar to find good candidates for our weekly Refactotum meetings - it was a script that used Git and our ticketing system to find files that were frequently modified, very large, and the source of a disproportionate number of bugs - the function for a evaluating the sort order of the files was kind of complex and involved, and I was actually pretty proud of helping develop it because it was such a neat way of viewing a codebase. I had no idea that some day there'd be a book all about stuff like that, with even more techniques. Really cool.
My main complaint with the book is that the author frequently uses a tool he wrote, code maat, to perform the analyses. I'd have much preferred more stress on the actual methods - I often came away feeling like I'd be unable to employ these techniques without code maat because I didn't get enough detail on the thinking behind the tool. In fact, I think the book often comes off as a code maat tutorial that was renamed. The other thing that bothers me is that often the code base analyzed to illustrate one of the book's ideas is the code maat database itself. This just seemed so self-referential to me, weirdly meta or something. It made it hard for me to really understand things - the code itself was already one step removed from the ideas, and then the codebases being looked at wound up kind of having the same leap. It's hard to explain, but the book would be much better if it analyzed popular open source projects that people use every day, and personally I'd have preferred less involvement from code maat itself - maybe a little paragraph or section at the very end showing how code maat could be used to automate a lot of the more manual work that the previous pages employed.
Overall, I actually highly recommend checking this book out - especially if you work on a large codebase and are concerned about its quality. There are lots of cool ideas in the book to help you find the biggest "bang for your buck" areas to improve the codebase....more
Meh, it's fine. Covers some basic stuff, as a first-time dad-to-be I found it useful and informative, but I have no idea what I'm doing so pretty muchMeh, it's fine. Covers some basic stuff, as a first-time dad-to-be I found it useful and informative, but I have no idea what I'm doing so pretty much any book will hit that mark.
The book is very light on details, but it's also very short and very easy to read. It took me two bus rides and I was done with it. Good way to tell the wife (or FPP as this book likes to call her) that I finished a "Dad Book" so that I don't look like a lunk....more
I know I say this every time I read a fiction book but I'm not much of a fiction reader. I generally find fiction written in a way that irritates me -I know I say this every time I read a fiction book but I'm not much of a fiction reader. I generally find fiction written in a way that irritates me - too much describing by an author in love with his or her own writing. Simple descriptions of a location or an object go into far too much detail, droning on and on with flowery prose that I feel like is wasting my time.
But, I loved The Martian movie, and people keep raving about this book so I gave it a shot. I really wound up enjoying it a lot - the vast majority of the book is actually just log entries from the main character, Mark Watney, so the thing that annoys me most about fiction was entirely avoided. All of the writing seemed crucial, and the only time it went into "unnecessary" detail were the explanations of the science behind Watney's decisionmaking. I had no problem with this, because I'm a nerd.
In fact, this really isn't much of a "novel" in a lot of ways. The main character doesn't grow or change, nobody really has anything like an arc. Like the movie, this is just a science geek joyride - nerding out on science and space and problem-solving complex challenges on Mars. It's great.
I found pretty much every part of the book that WASN'T a log entry from Watney somewhat annoying - prose sections on the other ship, or back on Earth, for example. These sections were critical since they gave the reader information Watney didn't have access to (and thus couldn't be in log entries) so I get why they're included, but that doesn't make them enjoyable. Like I said, I really don't like reading fiction much. Luckily, these sections don't make up much of the book - most of it pure science awesomeness.
Anyway, really enjoyed this. I saw the movie first and was worried that I'd find the book boring since I knew what would happen, but there was enough content trimmed out for the movie version that there's still a lot here. If you enjoyed the movie, I highly recommend the book, and I'm really not the type of person who says that about movies and shows adapted from books (seriously, fuck Game of Thrones, the books are exactly what I hate in writing). And if you're into science or space in general, I'd recommend this book to you as well - it's a good time and relatively short and to the point....more